Mở đầu — vì sao bài này quan trọng
Có một câu nói bạn sẽ nghe đi nghe lại trong suốt sự nghiệp làm AI Product Manager: "If you can't measure it, you can't improve it." Nhưng với sản phẩm AI, vấn đề còn nghiêm trọng hơn thế. Bạn không chỉ khó cải thiện thứ mình không đo được — bạn còn rất dễ tự lừa dối bản thân rằng sản phẩm đang chạy tốt, trong khi thực tế nó đang âm thầm làm hỏng trải nghiệm của hàng nghìn người dùng.
Tôi đã chứng kiến nhiều đội ngũ ở Việt Nam rơi vào cái bẫy này. Họ tích hợp một con LLM vào sản phẩm, demo chạy mượt, sếp gật gù, và rồi họ tuyên bố "AI feature đã xong". Ba tháng sau, chi phí token đội lên gấp năm lần dự kiến, người dùng phàn nàn câu trả lời "lúc đúng lúc sai", và không ai trong đội biết chính xác nó sai ở đâu, sai bao nhiêu phần trăm, sai vì lý do gì. Lý do gốc rễ rất đơn giản: họ chưa bao giờ xây dựng một metrics framework — một khung đo lường có hệ thống.
Bài học hôm nay tập trung vào tầng đầu tiên và nền tảng nhất của khung đo lường đó: Model Metrics — các chỉ số đo lường chính bản thân mô hình AI. Đây là những con số kỹ thuật mà nếu bạn không hiểu, bạn sẽ luôn phải gật đầu theo lời kỹ sư mà không biết mình đang đồng ý với điều gì. Khi bạn nắm được nhóm chỉ số này, bạn sẽ nói chuyện ngang hàng với đội data science, ra quyết định build/buy/model selection có cơ sở, và quan trọng nhất — bạn biết khi nào nên ăn mừng và khi nào nên lo lắng.
Khái niệm cốt lõi
Trước khi đi vào từng chỉ số, bạn cần một bức tranh tư duy: metrics của sản phẩm AI chia thành nhiều tầng (layer). Tầng dưới cùng là chất lượng kỹ thuật của mô hình. Tầng giữa là chất lượng trải nghiệm hệ thống. Tầng trên cùng là tác động kinh doanh. Bài này đào sâu Layer 1 — Model Metrics, vì đây là nền móng. Một sản phẩm có business metrics đẹp nhưng model metrics tệ là một quả bom hẹn giờ.
Model Metrics tự nó lại chia thành hai nhóm con: chỉ số chất lượng (quality) và chỉ số hiệu năng (performance/operational). Đừng nhầm lẫn hai nhóm này — chúng đo hai thứ hoàn toàn khác nhau.
Nhóm 1 — Chỉ số chất lượng: mô hình trả lời ĐÚNG đến đâu
Chất lượng phụ thuộc vào loại tác vụ (task). Cùng một con số "85%" có ý nghĩa rất khác giữa bài toán phân loại và bài toán sinh văn bản. Bạn cần chọn đúng thước đo cho đúng việc.
Accuracy (độ chính xác) — Tỷ lệ dự đoán đúng trên tổng số dự đoán. Đơn giản, dễ hiểu, phù hợp với các bài toán phân loại (classification) khi các lớp cân bằng. Ví dụ: mô hình phân loại email thành "spam / không spam", accuracy 95% nghĩa là cứ 100 email thì phân đúng 95. Nhưng accuracy có một cái bẫy chết người: khi dữ liệu mất cân bằng (imbalanced). Nếu 99% giao dịch là hợp lệ và chỉ 1% là gian lận, một mô hình "lười" luôn đoán "hợp lệ" sẽ đạt accuracy 99% mà chẳng bắt được vụ gian lận nào. Vô dụng.
Precision và Recall — Đây là cặp đôi giải quyết cái bẫy trên. Precision trả lời: trong những lần mô hình kêu "đây là gian lận", bao nhiêu phần trăm thực sự là gian lận? (đo độ "trong sạch" của cảnh báo). Recall trả lời: trong tất cả các vụ gian lận thực tế, mô hình bắt được bao nhiêu phần trăm? (đo độ "không bỏ sót"). Hai chỉ số này thường đối nghịch nhau: muốn recall cao (bắt hết) thì hay báo nhầm (precision giảm), và ngược lại. Là PM, bạn phải quyết định nghiêng về bên nào dựa trên chi phí của lỗi: với phát hiện ung thư, bỏ sót (recall thấp) nguy hiểm hơn báo nhầm; với gửi tin nhắn marketing, báo nhầm (precision thấp) gây phiền và tốn tiền hơn.
F1 Score — Khi bạn cần một con số duy nhất cân bằng cả precision và recall, F1 chính là nó: trung bình điều hòa của hai chỉ số. F1 cao chỉ khi cả precision và recall đều cao. Đây là chỉ số "vàng" cho các bài toán phân loại mất cân bằng, và bạn nên quen dùng nó thay vì accuracy trong hầu hết tình huống thực tế.
BLEU và ROUGE — Khi mô hình sinh văn bản (text generation) chứ không phân loại, bạn cần thước đo khác. BLEU (Bilingual Evaluation Understudy) đo độ trùng khớp giữa văn bản máy sinh ra và văn bản tham chiếu của con người, chủ yếu dùng cho dịch máy. Nó đếm xem các cụm từ (n-gram) trong bản dịch máy có khớp với bản dịch chuẩn không. ROUGE (Recall-Oriented Understudy for Gisting Evaluation) thiên về recall và thường dùng cho tóm tắt (summarization) — đo xem bản tóm tắt máy có "phủ" được các ý quan trọng trong văn bản gốc không. Điểm quan trọng bạn phải nhớ: cả BLEU và ROUGE đều đo độ trùng từ ngữ bề mặt, không đo ý nghĩa. Một câu trả lời đúng ý nhưng diễn đạt khác từ chuẩn vẫn bị điểm thấp. Vì vậy trong kỷ nguyên LLM, chúng dần được bổ sung bởi các phương pháp đánh giá ngữ nghĩa và LLM-as-a-judge (bạn sẽ học sâu ở các bài về AI Evaluation Framework).
Nhóm 2 — Chỉ số hiệu năng: mô hình trả lời NHANH và NHIỀU đến đâu
Chất lượng cao mà chậm như rùa thì người dùng cũng bỏ đi. Đây là nhóm chỉ số vận hành mà PM thường bỏ quên nhưng lại ảnh hưởng trực tiếp đến trải nghiệm và chi phí.
Inference Latency (độ trễ suy luận) — Thời gian từ khi gửi yêu cầu đến khi nhận được kết quả. Điều cốt lõi bạn phải hiểu: đừng bao giờ chỉ nhìn giá trị trung bình (average/mean). Trung bình che giấu sự thật. Thay vào đó, hãy đọc theo percentile:
- p50 (median): một nửa số request nhanh hơn con số này. Đây là trải nghiệm của người dùng "điển hình".
- p95: 95% request nhanh hơn con số này; tức 5% chậm hơn. Đây là trải nghiệm của nhóm người dùng "kém may mắn".
- p99: chỉ 1% request chậm hơn. Đây là phần đuôi (tail latency) — nhóm nhỏ nhưng thường gồm khách hàng lớn, request phức tạp, hoặc thời điểm cao tải.
Throughput (thông lượng) — Lượng công việc hệ thống xử lý được trong một đơn vị thời gian. Với LLM, đơn vị thường là tokens/giây (token là đơn vị nhỏ của văn bản, xấp xỉ 0,75 từ tiếng Anh; tiếng Việt thường tốn token hơn). Throughput quyết định bạn phục vụ được bao nhiêu người dùng đồng thời với hạ tầng hiện có. Latency và throughput có quan hệ đánh đổi: tăng batch size để throughput cao hơn thường khiến latency từng request tăng lên.
Với LLM streaming, có thêm hai chỉ số con cực quan trọng: TTFT (Time To First Token) — thời gian đến token đầu tiên xuất hiện, quyết định cảm giác "phản hồi tức thì"; và TPS (Tokens Per Second) — tốc độ chữ chạy ra sau đó, quyết định cảm giác "trôi chảy". Người dùng cảm nhận TTFT mạnh hơn nhiều so với tổng thời gian.
Tình huống thực tế
Tình huống 1 — Tiki và bài học accuracy "ảo" trong kiểm duyệt review
Giả định một đội ngũ tại một sàn thương mại điện tử lớn ở Việt Nam (lấy bối cảnh kiểu Tiki) xây dựng mô hình tự động phát hiện review độc hại — review chửi bới, spam, quảng cáo trá hình — để ẩn trước khi hiển thị. Đội báo cáo lên ban giám đốc: "Mô hình đạt accuracy 97%, sẵn sàng go-live."
Con số nghe tuyệt vời. Nhưng PM phụ trách đặt một câu hỏi đúng: "Tỷ lệ review độc hại trong dữ liệu thực tế là bao nhiêu?" Câu trả lời: khoảng 3%. Nghĩa là 97% review là sạch. Một mô hình ngớ ngẩn luôn đoán "review sạch" cũng đạt accuracy 97% mà không bắt được con review độc hại nào.
Khi đội đo lại bằng F1 trên riêng lớp "độc hại", con số tụt xuống còn 0,52. Đào sâu hơn: recall chỉ 41% — tức mô hình bỏ sót gần 60% review độc hại. Bài học rút ra: với dữ liệu mất cân bằng, accuracy là chỉ số gây ngộ nhận nguy hiểm nhất. PM phải luôn hỏi về phân bố lớp và yêu cầu báo cáo precision/recall/F1 cho lớp thiểu số — vốn mới là lớp mà sản phẩm thực sự quan tâm.
Tình huống 2 — Một fintech và cái đuôi p99 nuốt chửng khách VIP
Một công ty fintech ở Đông Nam Á (bối cảnh kiểu MoMo hoặc một ví điện tử khu vực) triển khai trợ lý AI trả lời câu hỏi về giao dịch trong app. Dashboard giám sát hiển thị latency trung bình 1,1 giây — đội kỹ thuật yên tâm. Nhưng tổng đài chăm sóc khách hàng liên tục nhận phàn nàn "AI bị treo, không chịu trả lời".
PM yêu cầu chuyển dashboard từ average sang percentile. Sự thật lộ ra: p50 = 0,9s (rất tốt), p95 = 3,2s (chấp nhận được), nhưng p99 = 14 giây. Phân tích nhóm p99 cho thấy đó chính là các khách hàng có lịch sử giao dịch dày (khách VIP), vì câu hỏi của họ kéo theo context dài hơn, mô hình phải xử lý nhiều token hơn. Nhóm tạo ra giá trị cao nhất lại đang nhận trải nghiệm tệ nhất.
Đội xử lý bằng cách cắt ngắn context, cache lịch sử, và đặt cảnh báo (alert) tự động khi p99 vượt 5 giây. Bài học rút ra: giá trị trung bình của latency gần như vô dụng cho quyết định sản phẩm. Luôn theo dõi p95/p99, và luôn hỏi "ai nằm trong cái đuôi đó?" — vì cái đuôi thường không phải khách hàng ngẫu nhiên.
Tình huống 3 — Startup edtech chọn mô hình dịch dựa trên BLEU mà quên nghĩa
Một startup edtech Việt Nam làm tính năng dịch tài liệu học thuật Anh–Việt. Họ so sánh hai mô hình bằng điểm BLEU trên một bộ test, chọn mô hình A vì BLEU cao hơn (31,5 so với 28,2). Nhưng khi giáo viên dùng thực tế, họ lại thích bản dịch của mô hình B hơn rõ rệt.
Lý do: BLEU thưởng cho việc trùng khớp từ ngữ với bản dịch tham chiếu. Mô hình A dịch sát từ chuẩn nên BLEU cao, nhưng câu cú cứng nhắc, khó đọc. Mô hình B diễn đạt tự nhiên hơn, đúng ý hơn, nhưng dùng từ khác bản tham chiếu nên bị BLEU "phạt". Bài học rút ra: các metric trùng-khớp-từ như BLEU/ROUGE là công cụ định lượng tiện lợi để theo dõi xu hướng, nhưng không phải chân lý cuối cùng về chất lượng. Luôn bổ sung đánh giá của con người (human evaluation) trên một mẫu, đặc biệt với tác vụ sinh ngôn ngữ. Đừng để một con số đẹp ra quyết định thay bạn.
Hướng dẫn từng bước
Đây là quy trình thực dụng để bạn — với vai trò AI PM — thiết lập Layer 1 Model Metrics cho một tính năng AI:
- Xác định loại tác vụ. Hỏi rõ: đây là classification, generation, translation, summarization, hay retrieval? Loại tác vụ quyết định bộ chỉ số phù hợp. Đừng chọn metric trước khi biết task.
- Chọn chỉ số chất lượng tương ứng. Classification mất cân bằng → F1, precision, recall (không dùng accuracy đơn lẻ). Translation → BLEU + human eval. Summarization → ROUGE + human eval. Generation tự do → kết hợp human eval / LLM-as-judge (đào sâu ở bài Evaluation).
- Định nghĩa ngưỡng chấp nhận (threshold) gắn với chi phí lỗi. Đừng đặt "F1 phải > 0,8" một cách tùy tiện. Hãy hỏi: lỗi false positive tốn gì, false negative tốn gì? Từ đó cân precision/recall.
- Thiết lập đo hiệu năng theo percentile. Yêu cầu dashboard hiển thị latency ở p50, p95, p99 — không chỉ average. Thêm TTFT nếu là trải nghiệm streaming. Đo throughput (tokens/sec) để biết giới hạn năng lực.
- Xây tập đánh giá vàng (golden set). Một bộ dữ liệu test cố định, đại diện cho người dùng thật, có nhãn chuẩn. Mọi thay đổi mô hình hoặc prompt đều chạy lại trên golden set này để so sánh công bằng (apples-to-apples).
- Đặt cảnh báo và lịch rà soát. Alert khi p99 hoặc F1 vượt/tụt ngưỡng. Rà soát định kỳ vì model metrics có thể trôi theo thời gian (chủ đề của bài AI Drift Detection).
Lỗi thường gặp & mẹo
- Lỗi: dùng accuracy cho dữ liệu mất cân bằng. Đây là sai lầm phổ biến nhất. Mẹo: bất cứ khi nào nghe "accuracy cao", hãy hỏi ngay tỷ lệ phân bố lớp.
- Lỗi: chỉ nhìn latency trung bình. Average che giấu cái đuôi. Mẹo: ép mọi dashboard latency phải có p95 và p99; coi p99 là chỉ số sức khỏe trải nghiệm.
- Lỗi: tin tuyệt đối vào BLEU/ROUGE. Chúng đo từ ngữ, không đo nghĩa. Mẹo: luôn kèm human eval trên mẫu nhỏ trước khi ra quyết định lớn.
- Lỗi: đo trên dữ liệu test không giống thực tế. Mô hình đẹp trên test, vỡ trận khi go-live. Mẹo: golden set phải lấy từ phân bố người dùng thật, cập nhật định kỳ.
- Lỗi: lẫn lộn chỉ số chất lượng và hiệu năng. Một mô hình F1 cao nhưng latency p99 = 20s vẫn là sản phẩm tồi. Mẹo: luôn báo cáo song song cả hai nhóm, không đánh đổi ngầm.
- Mẹo vàng: một metric tốt phải hành động được (actionable). Nếu con số tụt mà bạn không biết phải làm gì, đó là vanity metric. Mỗi chỉ số nên gắn với một quyết định cụ thể.
Bài tập thực hành
- Chọn metric đúng task. Cho ba tính năng sau, hãy viết ra bộ chỉ số chất lượng bạn sẽ dùng và giải thích vì sao: (a) phát hiện giao dịch gian lận (1% là gian lận); (b) tóm tắt tin tức tự động; (c) chatbot dịch hội thoại Việt–Anh thời gian thực.
- Đọc percentile. Một API trả về: average latency = 1,2s; p50 = 0,7s; p95 = 2,8s; p99 = 11s. Hãy viết một đoạn 4–5 câu giải thích cho sếp non-tech tại sao con số "trung bình 1,2 giây" đang khiến bạn lo lắng, và bạn sẽ đề xuất hành động gì.
- Bóc trần accuracy ảo. Một mô hình phân loại đạt accuracy 96% trên dữ liệu mà lớp tích cực chỉ chiếm 4%. Hãy tính accuracy của một mô hình "luôn đoán lớp âm". So sánh và viết câu hỏi bạn sẽ đặt cho đội data science.
- Thiết kế dashboard. Phác thảo (bằng gạch đầu dòng) một dashboard Layer 1 cho một tính năng AI bạn đang hình dung: liệt kê đủ chỉ số chất lượng + hiệu năng, ngưỡng cảnh báo, và quyết định gắn với mỗi chỉ số.
Tóm tắt
Model Metrics (Layer 1) là nền móng của mọi khung đo lường sản phẩm AI. Bạn cần nắm hai nhóm: chất lượng và hiệu năng. Về chất lượng, chọn thước đo theo loại tác vụ — accuracy cho phân loại cân bằng (nhưng cảnh giác dữ liệu mất cân bằng), F1/precision/recall cho phân loại thực tế, BLEU cho dịch máy, ROUGE cho tóm tắt, và luôn bổ sung human eval vì các metric trùng-từ không đo được ý nghĩa. Về hiệu năng, đừng bao giờ chỉ nhìn giá trị trung bình: đọc latency theo p50/p95/p99 để thấy cái đuôi, thêm TTFT cho trải nghiệm streaming, và theo dõi throughput (tokens/sec) để biết giới hạn năng lực.
Ba tình huống thực tế cho thấy cùng một bài học cốt lõi: một con số đẹp tách rời ngữ cảnh là cái bẫy. Accuracy 97% có thể che giấu recall 41%; latency trung bình 1,1s có thể che giấu p99 = 14s nuốt chửng khách VIP; BLEU cao có thể che giấu bản dịch cứng nhắc. Vai trò của bạn — AI PM — không phải tự tính các con số này, mà là hỏi đúng câu hỏi, chọn đúng thước đo, và gắn mỗi chỉ số với một quyết định. Khi bạn làm được điều đó, bạn đã đặt nền móng vững chắc để leo lên các tầng metrics cao hơn trong những bài tiếp theo.