--- title: "Đo một tính năng AI: chất lượng, chi phí, niềm tin" url: https://www.thinnd.site/tu-duy-san-pham/do-mot-tinh-nang-ai/ language: vi author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "Tư duy sản phẩm" tags: ["sản phẩm AI", "chỉ số", "evals", "chi phí", "niềm tin", "đo lường"] summary: "Một tính năng AI nên được đo theo ba lớp cùng lúc. Chất lượng: tỷ lệ đạt theo từng nhóm lỗi, lấy từ phân tích lỗi và evals. Chi phí: chi phí cho mỗi kết quả thành công, gồm cả công người duyệt, cùng độ trễ ở mức p95 chứ không chỉ trung bình. Niềm tin: tỷ lệ chấp nhận, chỉnh sửa và ghi đè của người dùng, số lần người dùng báo sai và số ca chuyển cho người. Đo riêng một lớp tạo điểm mù. Các ngưỡng trong bài chỉ là minh họa, chưa có chuẩn chung." license: "Cite with the author name and the canonical URL above." --- # Đo một tính năng AI: chất lượng, chi phí, niềm tin > 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](https://www.thinnd.site/ky-thuat/viet-bai-kiem-tra-tinh-nang-ai/) (lớp chất lượng) và [Đừng đo năng suất bằng số dòng code](https://www.thinnd.site/tu-duy-san-pham/dung-do-nang-suat-bang-so-dong-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](https://www.antoinebuteau.com/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](https://posthog.com/product-engineers/llm-product-metrics) (thứ cấp) - [Hamel Husain và Shreya Shankar: LLM Evals, Everything You Need to Know](https://hamel.dev/blog/posts/evals-faq/) - [Stack Overflow Developer Survey 2025, phần AI](https://survey.stackoverflow.co/2025/ai) - Bài liên quan trong blog: [Viết bài kiểm tra cho tính năng AI](https://www.thinnd.site/ky-thuat/viet-bai-kiem-tra-tinh-nang-ai/), [Đừng đo năng suất bằng số dòng code](https://www.thinnd.site/tu-duy-san-pham/dung-do-nang-suat-bang-so-dong-code/), [Vibe coding làm prototype trong một ngày](https://www.thinnd.site/tu-duy-san-pham/vibe-coding-prototype-mot-ngay/)