Tóm tắt
Câu hỏi chính của bài viết là: doanh nghiệp có đang nhận lại nhiều giá trị hơn từ số tiền bỏ vào AI hay không. OpenAI cho rằng cách đo cũ của software như số ghế, số user active, hay license renewal không đủ tốt cho AI; thước đo nên xoay quanh lượng công việc thật sự hoàn tất.
Ý tưởng trung tâm là “useful intelligence per dollar”: AI phải tạo ra nhiều kết quả dùng được hơn trên mỗi đô chi ra. Muốn đo nghiêm túc, đừng chỉ nhìn cost per token; hãy tính cả retry, thời gian con người review, sửa lỗi, độ tin cậy và giá trị của task hoàn tất.
Bốn câu hỏi trong scorecard
1. AI hoàn tất bao nhiêu việc có giá trị?
OpenAI đề xuất bắt đầu từ workflow cụ thể, không bắt đầu từ dashboard token. Ví dụ:
- Bao nhiêu ticket hỗ trợ khách hàng được giải quyết?
- Bao nhiêu code change được ship và pass test?
- Bao nhiêu hợp đồng được review đúng hạn?
- Bao nhiêu quyết định tốt hơn vì context xuất hiện đúng lúc?
Với đội kỹ thuật, định nghĩa “done” nên nằm trong system nơi công việc thật diễn ra: PR pass test, issue được đóng, customer ticket được resolve, hoặc tài liệu được review xong. Nếu model chỉ tạo draft nhưng vẫn đẩy phần khó sang người review, scorecard phải phản ánh điều đó.
2. Một task thành công thật sự tốn bao nhiêu?
Bài viết nhấn mạnh rằng token rẻ không đồng nghĩa với outcome rẻ. Một model có token price thấp nhưng cần nhiều lần thử, nhiều tool call, hoặc nhiều giờ review vẫn có thể đắt hơn model mạnh hơn hoàn tất đúng ngay lần đầu.
Cách tính được đề xuất khá thẳng:
- Cộng toàn bộ chi phí để hoàn tất công việc.
- Đếm số task đạt chuẩn chất lượng.
- Chia tổng chi phí cho số task thành công.
OpenAI dùng phần này để nói về model family GPT-5.6: Sol là tier flagship, Terra cân bằng hiệu năng và chi phí, Luna là tier nhanh và rẻ nhất. Họ cũng tuyên bố GPT-5.6 Sol với max reasoning đạt 72,7% trên Artificial Analysis Coding Agent Index / DeepSWE v1.1, cao hơn Claude Fable 5 ở mức 69,9%, với chi phí API ước tính thấp hơn 36,2%. Đây là số từ bài công bố của OpenAI, nên dev nên chờ benchmark độc lập trước khi coi nó là chân lý vận hành.
3. AI làm đúng thường xuyên đến mức nào?
OpenAI gọi yếu tố này là dependability. Khi AI chuyển từ viết nháp sang tìm context, dùng tool, hành động trong system, và xử lý exception, yêu cầu về độ tin cậy tăng rất nhanh.
Một cách đo dễ đưa vào sản phẩm là gắn nhãn outcome:
- Ready to use: kết quả đạt chuẩn ngay khi trả về.
- Needs correction: cần retry hoặc sửa bởi con người.
- Needs escalation: phải chuyển cho người xử lý tiếp.
Ba nhãn này hữu dụng hơn accuracy tổng quát vì chúng đo trực tiếp lượng việc còn lại cho con người. Với agents, đây cũng là dữ liệu routing: task nào được tự động hóa, task nào cần human-in-the-loop, task nào không nên cho model đụng vào.
4. Mỗi đô AI có mua được nhiều việc hơn khi scale không?
Scorecard cuối cùng là theo dõi cùng một workflow qua thời gian: số task đạt chuẩn, tổng chi phí, và cost per successful task. Nếu số việc hoàn tất tăng nhanh hơn chi phí trong khi chất lượng giữ nguyên hoặc tốt hơn, economics đang đi đúng hướng.
OpenAI đặt compute ở giữa phương trình này. Training compute tạo capability mới; inference compute biến capability đó thành công việc hằng ngày. Các cải tiến như inference hiệu quả hơn, routing thông minh hơn, hardware phù hợp hơn, và product design tốt hơn đều phải hiện ra thành kết quả con người cảm nhận được: câu trả lời tốt hơn, ít sửa hơn, latency thấp hơn, và chi phí thấp hơn cho cùng một outcome.
Ý nghĩa với Dev
Dev nên quan tâm vì đây là checklist khá tốt để đánh giá LLM feature trước khi rollout. Thay vì báo cáo “model X rẻ hơn 30%”, hãy báo cáo “workflow Y tăng từ 42% lên 68% task ready-to-use, escalation giảm 15%, cost per successful task giảm 22%”.
Với team đang build coding agents, scorecard này cũng gợi ý telemetry nên có ngay từ đầu:
- task objective và tiêu chí done;
- model/tier được chọn;
- số lần retry;
- tool calls;
- test pass/fail;
- thời gian human review;
- outcome label: ready, correction, escalation.
Không có các số này, cuộc tranh luận model nào “tốt hơn” rất dễ biến thành cảm giác cá nhân hoặc benchmark xa workflow thật. Có telemetry rồi, bạn mới biết nên dùng model rẻ hơn, model mạnh hơn, hay routing theo loại task.