Đo một tính năng AI: chất lượng, chi phí, niềm tin
Một tính năng AI thành công không chỉ ở số lượt dùng. Bài này đề xuất đo theo ba lớp là chất lượng, chi phí và niềm tin, kèm bảng một trang gồm chín chỉ số, công thức chi phí cho mỗi kết quả thành công có tính cả công người duyệt, cách đọc tỷ lệ chấp nhận mà không bị đánh lừa, và các bẫy hay gặp.
Dành cho người làm sản phẩm, trưởng nhóm và lập trình viên đang đưa AI vào sản phẩm. Từ kỹ thuật nào cũng có giải thích ngắn.
Cách chia ba lớp và các chỉ số lấy từ các bài hướng dẫn của người làm nghề (blog, tài liệu của công cụ theo dõi), là nguồn thứ cấp. Các ngưỡng và con số trong bài đều là minh họa, không phải chuẩn. Ví dụ cửa hàng "Hồng" là dựng lại.
Tóm tắt nhanh#
- Số lượt dùng không phải thành công. Hãy đo kết quả của công việc.
- Đo ba lớp cùng lúc: chất lượng, chi phí, niềm tin. Một lớp đơn lẻ tạo điểm mù.
- Chi phí đúng là chi phí cho mỗi kết quả thành công, gồm cả công người duyệt.
- Tỷ lệ chấp nhận cao có thể là tin quá mức. Đặt nó cạnh tỷ lệ đạt từ evals.
- Dùng một bảng một trang và quyết định trước điều gì xảy ra khi chỉ số xấu đi.
Từ khó, nói dễ#
| Thuật ngữ | Nói dễ hiểu |
|---|---|
| Evals | Bài kiểm tra đo chất lượng tính năng AI (xem bài viết riêng). |
| Tỷ lệ chấp nhận | Phần đầu ra AI mà người dùng nhận và dùng luôn. |
| Tỷ lệ chỉnh sửa | Phần đầu ra người dùng sửa lại trước khi dùng. |
| Tỷ lệ ghi đè | Phần đầu ra người dùng bỏ đi và tự làm. |
| Độ trễ p95 | Thời gian mà 95% yêu cầu nhanh hơn. Cho thấy những lần chậm nhất, thứ người dùng thật sự nhớ. |
| Token | Đơn vị chữ mà mô hình xử lý và tính tiền. |
| Chi phí cho mỗi kết quả thành công | Tổng chi phí chia cho số lần AI thật sự giúp được việc. |
1. Vì sao không đo một con số#
Rất dễ bắt đầu bằng thứ dễ đếm: số lượt gọi, số người dùng. Nhưng một tính năng AI có thể được dùng rất nhiều mà vẫn tệ: trả lời sai, tốn nhiều tiền, hoặc bị người dùng âm thầm bỏ qua.
Các hướng dẫn thực hành (mình đọc qua tóm tắt) đều đồng ý ở hai điểm: đếm lượt gọi là nông, thứ cần đo là công việc được hoàn thành; và nên xếp chỉ số theo lớp vì tập trung vào một lớp tạo điểm mù. Một ví dụ hay gặp: một mô hình đúng 95% vẫn vô ích nếu người dùng không tin nó.
Vì vậy mình chia ba lớp:
| Lớp | Câu hỏi | Nguồn dữ liệu |
|---|---|---|
| Chất lượng | Đầu ra có đúng và có ích không? | Phân tích lỗi, evals |
| Chi phí | Mỗi kết quả thành công tốn bao nhiêu và nhanh không? | Hóa đơn, nhật ký, đo thời gian |
| Niềm tin | Người dùng có tin và dùng nó không? | Hành vi người dùng, phản hồi |
Bài này nối với Viết bài kiểm tra cho tính năng AI (lớp chất lượng) và Đừng đo năng suất bằng số dòng code (vì sao chỉ số hoạt động dễ đánh lừa).
2. Lớp chất lượng#
Chất lượng không phải một con số "độ chính xác". Hãy lấy từ phân tích lỗi: gom lỗi thành nhóm và đếm, như trong bài về evals.
Các chỉ số gợi ý:
- Tỷ lệ đạt theo từng nhóm lỗi. Ví dụ "hiểu nhầm ý", "bịa thông tin", "giọng quá cứng". Mỗi nhóm một con số.
- Số lỗi nghiêm trọng. Một lỗi bịa giá khác hẳn một lỗi giọng văn. Đếm riêng lỗi có hậu quả thật.
- Tỷ lệ đạt tổng, nhưng không dùng làm con số duy nhất.
Chỉ số tổng "đạt tất cả" rồi khoan xuống từng nhóm. Hướng dẫn về evals cũng khuyên chấm đạt hoặc không đạt thay vì thang điểm.
Cách theo dõi: chạy lại bộ evals mỗi khi đổi mô hình, đổi lời nhắc hoặc đổi dữ liệu. Nếu bạn đổi mô hình mà không chạy lại, bạn không biết chất lượng thay đổi thế nào.
3. Lớp chi phí#
3.1. Chi phí cho mỗi lượt gọi và cho mỗi kết quả thành công#
Chi phí mỗi lượt gọi là con số dễ lấy. Nhưng một tính năng có thể gọi mô hình rẻ mà cần người sửa lại nhiều, hoặc cần gọi nhiều lần mới ra một kết quả dùng được. Vì vậy chi phí đáng so sánh là:
Chi phí cho mỗi kết quả thành công = (chi phí mô hình + hạ tầng + công người duyệt hoặc sửa) ÷ số kết quả thành công
Ví dụ minh họa (số dựng lại): trợ lý trả lời khách của cửa hàng "Hồng", một tháng.
| Mục | Giá trị minh họa |
|---|---|
| Số câu hỏi khách | 10.000 |
| Chi phí mô hình và hạ tầng | 20 triệu đồng |
| Số câu trả lời dùng được ngay | 6.500 |
| Số câu cần nhân viên sửa (mỗi câu 3 phút, 60 nghìn đồng/giờ) | 2.500 câu, tức 7.500 phút, tức 125 giờ, tức 7,5 triệu đồng |
| Số câu phải chuyển hẳn cho nhân viên | 1.000 |
| Tổng chi phí | 20 + 7,5 = 27,5 triệu đồng |
| Kết quả thành công (dùng ngay hoặc sửa nhanh) | 6.500 + 2.500 = 9.000 |
| Chi phí mỗi kết quả thành công | khoảng 3.060 đồng |
Nếu chỉ nhìn chi phí mô hình, 20 triệu chia 10.000 lượt, ra 2.000 đồng mỗi lượt, bạn sẽ bỏ sót công người sửa và 1.000 ca thất bại. Đó là lý do "chi phí cho mỗi kết quả thành công" lộ ra nhiều hơn.
3.2. Độ trễ#
Hãy đo độ trễ ở mức p95 (và p99), không chỉ trung bình. Trung bình che mất những lần chậm nhất, mà đó là lúc người dùng bỏ đi. Với tính năng trò chuyện, thời gian đến chữ đầu tiên ảnh hưởng nhiều tới cảm giác nhanh.
4. Lớp niềm tin#
Đây là lớp hay bị bỏ qua. Nhìn từ hành vi người dùng:
| Chỉ số | Ý nghĩa |
|---|---|
| Tỷ lệ chấp nhận | Người dùng nhận và dùng luôn |
| Tỷ lệ chỉnh sửa | Người dùng sửa lại rồi mới dùng |
| Tỷ lệ ghi đè | Người dùng bỏ và tự làm |
| Số lần báo sai | Người dùng chủ động nói "câu này sai" |
| Số ca chuyển cho người, và cách xử lý | Có chuyển đúng ca cần chuyển không |
| Tỷ lệ mở lại hoặc khiếu nại | Việc đã "xong" nhưng quay lại |
Xem xu hướng chứ không chỉ mức tuyệt đối. Một số hướng dẫn nêu rằng một cú nhảy đột ngột của tỷ lệ chỉnh sửa là dấu hiệu chất lượng tụt, không phải do cá nhân hóa.
Bối cảnh: khảo sát Stack Overflow 2025 (hơn 49.000 người trả lời) ghi nhận 46% người dùng không tin độ chính xác của AI và chỉ 3% rất tin. Người dùng sản phẩm của bạn cũng có thể có thái độ tương tự. Niềm tin cần được kiếm, và cần được đo.
5. Cạm bẫy: tỷ lệ chấp nhận cao có thể là tin quá mức#
Đây là điểm mình thấy quan trọng nhất của bài. Nếu người dùng chấp nhận 90% đầu ra nhưng evals cho thấy chỉ 75% thực sự đúng, thì khoảng cách 15 điểm là người dùng đang tin quá mức, không phải tính năng tốt.
Cách đọc: đặt tỷ lệ chấp nhận cạnh tỷ lệ đạt từ evals.
| Tình huống | Có thể có nghĩa |
|---|---|
| Chấp nhận cao, đạt cao | Tính năng tốt và được tin đúng mức |
| Chấp nhận cao, đạt thấp | Tin quá mức, rủi ro cao |
| Chấp nhận thấp, đạt cao | Người dùng chưa tin, có thể do giao diện hoặc thói quen |
| Chấp nhận thấp, đạt thấp | Tính năng chưa đạt, đúng là nên ít dùng |
Mình không có dữ liệu để nói tỷ lệ này thường là bao nhiêu. Đây là cách đọc các chỉ số, không phải kết quả đo.
6. Bảng một trang#
Một bảng chín chỉ số, ba lớp, ghi theo tuần.
| Lớp | Chỉ số | Cảnh báo khi |
|---|---|---|
| Chất lượng | Tỷ lệ đạt theo nhóm lỗi | Một nhóm tụt, hoặc có lỗi nghiêm trọng mới |
| Chất lượng | Số lỗi nghiêm trọng | Bất kỳ lỗi nào có hậu quả thật |
| Chi phí | Chi phí cho mỗi kết quả thành công | Tăng khi lượng dùng tăng |
| Chi phí | Độ trễ p95 | Dài ra, hoặc chữ đầu tiên chậm |
| Chi phí | Công người duyệt hoặc sửa (giờ) | Tăng nhanh hơn số kết quả |
| Niềm tin | Tỷ lệ chấp nhận so với tỷ lệ đạt | Chấp nhận vượt xa đạt |
| Niềm tin | Tỷ lệ chỉnh sửa và ghi đè | Nhảy đột ngột |
| Niềm tin | Số lần người dùng báo sai | Tăng |
| Niềm tin | Ca chuyển cho người | Quá ít (bỏ sót) hoặc quá nhiều |
Ghép đôi: mỗi chỉ số tốc độ hoặc chi phí đi cùng một chỉ số chất lượng. Chi phí giảm mà tỷ lệ đạt tụt không phải tiến bộ.
7. Quyết định trước khi chỉ số xấu đi#
Một bảng không có quy tắc hành động chỉ là trang trí. Ví dụ minh họa, ngưỡng là dựng lại:
| Nếu | Thì |
|---|---|
| Có lỗi nghiêm trọng (như bịa giá) | Tạm tắt phần đó, sửa rồi mới bật lại |
| Tỷ lệ đạt một nhóm tụt dưới mức đã đặt | Dừng triển khai thêm, xem lại lời nhắc |
| Chấp nhận vượt xa đạt | Thêm bước xác nhận, hiển thị nguồn |
| Chi phí mỗi kết quả vượt ngân sách | Xem lại mô hình, cách gọi, hoặc phạm vi |
| Độ trễ p95 dài | Rút ngắn đầu ra hoặc đổi cách gọi |
Ngưỡng cụ thể tùy rủi ro của tính năng. Tính năng trả lời về tiền cần ngưỡng nghiêm hơn tính năng gợi ý tiêu đề.
8. Những bẫy hay gặp#
- Chỉ đo lượt dùng. Dùng nhiều không có nghĩa là tốt.
- Chỉ có thích hoặc không thích. Phản hồi này ít người bấm và lệch về hai cực. Hãy kết hợp với hành vi (chỉnh sửa, ghi đè).
- Quên công người duyệt trong chi phí. Chi phí mô hình có thể rẻ mà tổng chi phí không rẻ.
- Trung bình che mất đuôi. Hãy xem p95 và các ca tệ nhất.
- Đổi mô hình mà không chạy lại evals.
- Biến chỉ số thành mục tiêu (luật Goodhart): nếu thưởng cho tỷ lệ chấp nhận, người ta sẽ làm nó đẹp lên mà không cải thiện chất lượng.
9. Nhìn cân bằng#
- Nguồn thứ cấp. Cách chia ba lớp đến từ các hướng dẫn của người làm nghề (blog, tài liệu của công cụ theo dõi), không phải nghiên cứu độc lập.
- Không có chuẩn về ngưỡng. Mọi con số trong bài là minh họa. Mình không biết mức tỷ lệ chấp nhận hay chỉnh sửa "bình thường" cho từng loại tính năng.
- Đo lường tốn công. Với một thử nghiệm nhỏ, bảng một trang rút gọn (chất lượng, chi phí, một chỉ số niềm tin) là đủ.
- Chỉ số không thay được việc nghe người dùng. Hãy đọc vài cuộc trao đổi thật mỗi tuần.
- Ví dụ cửa hàng "Hồng" là dựng lại, các con số do mình tạo ra để minh họa công thức.
10. Kết luận#
Một tính năng AI tốt không phải tính năng được gọi nhiều nhất, mà là tính năng cho kết quả đúng, với chi phí hợp lý và được tin đúng mức. Hãy đo ba lớp cùng lúc, tính chi phí cho mỗi kết quả thành công, và đọc tỷ lệ chấp nhận cạnh tỷ lệ đạt.
Việc nhỏ làm ngay: chọn một tính năng AI bạn đang chạy, tính chi phí cho mỗi kết quả thành công (nhớ cộng công người sửa), và so với số bạn vẫn dùng.
Nguồn tham khảo#
- Antoine Buteau: AI product metrics, economics and support burden (thứ cấp, hướng dẫn của người làm nghề)
- PostHog: Product metrics to track for LLM apps (thứ cấp)
- Hamel Husain và Shreya Shankar: LLM Evals, Everything You Need to Know
- Stack Overflow Developer Survey 2025, phần AI
- Bài liên quan trong blog: Viết bài kiểm tra cho tính năng AI, Đừng đo năng suất bằng số dòng code, Vibe coding làm prototype trong một ngày
Câu hỏi thường gặp
- Đo một tính năng AI nên bắt đầu từ đâu?
- Từ ba lớp: chất lượng (đầu ra có đúng không, tính theo nhóm lỗi), chi phí (mỗi kết quả thành công tốn bao nhiêu, kể cả công người duyệt, và độ trễ ở mức p95) và niềm tin (người dùng chấp nhận, chỉnh sửa hay ghi đè bao nhiêu). Đo riêng một lớp thì có điểm mù: mô hình đúng 95% vẫn vô ích nếu người dùng không tin.
- Chi phí cho mỗi kết quả thành công tính thế nào?
- Lấy tổng chi phí (mô hình, hạ tầng và công người duyệt hoặc sửa) chia cho số kết quả thành công, chứ không chia cho số lượt gọi. Cách này lộ ra những tính năng gọi mô hình rẻ nhưng cần người sửa nhiều, hoặc cần gọi nhiều lần mới ra một kết quả dùng được.
- Tỷ lệ chấp nhận cao có nghĩa là tính năng tốt?
- Chưa chắc. Tỷ lệ chấp nhận cao có thể do người dùng tin quá mức và chấp nhận cả kết quả sai. Hãy đặt cạnh tỷ lệ đạt từ evals: nếu người dùng chấp nhận nhiều hơn mức kết quả thực sự đúng, đó là dấu hiệu tin quá mức. Cũng nên xem xu hướng chứ không chỉ mức tuyệt đối.
- Ngưỡng nào là chấp nhận được?
- Không có chuẩn chung. Các ngưỡng thấy trong các hướng dẫn thực hành (như tỷ lệ chỉnh sửa dưới 0,3) chỉ là ví dụ minh họa. Hãy đặt ngưỡng theo rủi ro của tính năng, và quyết định trước điều gì xảy ra khi vượt ngưỡng.