Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Technical PM của một ngân hàng số tại Việt Nam. Team data science báo cáo đầy tự hào: "Model phát hiện gian lận giao dịch của bọn em đạt accuracy 99,2%!". Bạn gật gù, ký duyệt cho lên production. Ba tuần sau, bộ phận vận hành réo lên: model gần như không bắt được giao dịch gian lận nào, trong khi tổng thiệt hại đã lên tới 800 triệu đồng.
Chuyện gì đã xảy ra? Trong tập dữ liệu, cứ 1.000 giao dịch thì chỉ có khoảng 3 giao dịch gian lận. Một model "ngu ngốc" chỉ cần đoán "tất cả đều hợp lệ" cũng đã đạt accuracy 99,7% — cao hơn cả model thật. Con số 99,2% mà bạn ấn tượng thực ra là một cái bẫy.
Đây chính là lý do bài học này tồn tại. Là Technical PM, bạn không cần tự tay train model, nhưng bạn là người quyết định model nào được lên production, model nào bị loại, và quan trọng nhất: đo bằng thước nào. Nếu bạn chọn sai metric, cả team có thể tối ưu rất chăm chỉ cho một mục tiêu hoàn toàn lệch với giá trị kinh doanh. Chọn đúng metric là một trong những đòn bẩy âm thầm nhưng mạnh nhất mà một Technical PM có thể tác động lên sản phẩm AI.
Bài này tập trung vào một câu hỏi duy nhất nhưng cốt tử: làm sao đánh giá một model đúng cách, và chọn metric phản ánh đúng điều bạn thực sự quan tâm?
Khái niệm cốt lõi
Confusion Matrix — bảng nền tảng của mọi thứ
Mọi metric phân loại đều xuất phát từ một bảng 2x2 đơn giản gọi là confusion matrix (ma trận nhầm lẫn). Với bài toán phân loại nhị phân (positive/negative), ta có bốn ô:
| Dự đoán Positive | Dự đoán Negative | |
|---|---|---|
| Thực tế Positive | True Positive (TP) | False Negative (FN) |
| Thực tế Negative | False Positive (FP) | True Negative (TN) |
- TP: giao dịch gian lận, model bắt đúng — tốt.
- TN: giao dịch hợp lệ, model thả đúng — tốt.
- FP (báo động giả): giao dịch hợp lệ nhưng model chặn — khách hàng bực mình vì bị khóa thẻ oan.
- FN (bỏ lọt): giao dịch gian lận nhưng model thả qua — ngân hàng mất tiền.
Accuracy — và vì sao nó hay lừa người
Accuracy = (TP + TN) / tổng số mẫu, tức tỉ lệ dự đoán đúng. Nó dễ hiểu, nhưng cực kỳ nguy hiểm khi dữ liệu mất cân bằng (imbalanced) — như ví dụ mở đầu. Khi một lớp chiếm tỉ lệ áp đảo, accuracy bị "ru ngủ" bởi lớp đa số. Quy tắc của PM: nếu tỉ lệ các lớp lệch nhau đáng kể, đừng bao giờ chỉ nhìn accuracy.
Precision và Recall — cặp đôi cốt lõi
Đây là hai metric quan trọng nhất bạn phải nắm thật chắc:
- Precision = TP / (TP + FP). Trong số những trường hợp model kêu là positive, bao nhiêu phần trăm đúng? Precision cao nghĩa là model ít báo động giả.
- Recall (còn gọi Sensitivity) = TP / (TP + FN). Trong số những trường hợp thực sự positive, model bắt được bao nhiêu phần trăm? Recall cao nghĩa là model ít bỏ lọt.
- Phát hiện ung thư qua ảnh chụp: bỏ lọt một ca bệnh (FN) là thảm họa → ưu tiên recall.
- Lọc email gửi vào hộp thư chính của khách VIP: đánh nhầm email quan trọng vào spam (FP) là không chấp nhận được → ưu tiên precision.
F1-Score — khi cần một con số duy nhất
Khi bạn muốn cân bằng precision và recall trong một con số, dùng F1-score = trung bình điều hòa (harmonic mean) của hai chỉ số: F1 = 2 × (Precision × Recall) / (Precision + Recall). Trung bình điều hòa "phạt" nặng nếu một trong hai quá thấp, nên F1 chỉ cao khi cả precision lẫn recall đều ổn. Nếu doanh nghiệp coi trọng một bên hơn, có thể dùng F-beta (ví dụ F2 nghiêng về recall).
ROC-AUC và PR-AUC — đánh giá xuyên ngưỡng
Hầu hết model thực ra xuất ra một xác suất (ví dụ 0,73), rồi ta đặt ngưỡng (threshold) để quyết định positive/negative. Mọi metric ở trên đều phụ thuộc ngưỡng. Để đánh giá model độc lập với ngưỡng, ta dùng:
- ROC-AUC: diện tích dưới đường ROC, đo khả năng phân biệt giữa hai lớp. 0,5 là đoán mò, 1,0 là hoàn hảo.
- PR-AUC (Precision-Recall AUC): với dữ liệu mất cân bằng nặng, PR-AUC phản ánh chất lượng tốt hơn ROC-AUC, vì nó không bị "thổi phồng" bởi lượng lớn true negative.
Metric cho bài toán hồi quy
Nếu model dự đoán một con số (giá nhà, doanh thu, thời gian giao hàng) thay vì nhãn, ta dùng nhóm khác:
- MAE (Mean Absolute Error): sai số tuyệt đối trung bình — dễ giải thích cho stakeholder ("trung bình lệch 12 phút").
- RMSE (Root Mean Squared Error): phạt nặng các sai số lớn — dùng khi sai lệch lớn gây hậu quả nghiêm trọng.
- MAPE (sai số phần trăm): tiện khi muốn nói theo %, nhưng cẩn thận khi giá trị thật gần 0.
Offline metric không phải là thước đo cuối cùng
Tất cả những metric trên là offline metric — đo trên tập test cố định. Nhưng cái doanh nghiệp thực sự cần là business metric online: tỉ lệ chuyển đổi, doanh thu, số khiếu nại, retention. Một model có F1 cao hơn 2% chưa chắc làm tăng doanh thu. Đây là tư duy PM quan trọng: offline metric chỉ là proxy (đại diện), còn phán quyết cuối nằm ở online metric đo qua A/B test.
Tình huống thực tế
Tình huống 1: Tiki và bài toán lọc đánh giá giả
Giả định Tiki xây model phát hiện review giả (fake review) do seller tự bơm. Trong 100.000 review, chỉ khoảng 2.000 là giả (2%). Team đầu tiên báo accuracy 98% — nghe rất ổn, nhưng PM nhận ra ngay đó là con số vô nghĩa vì model "đoán tất cả là thật" cũng đạt 98%.
PM yêu cầu nhìn precision và recall. Model thực tế có recall 45% (bỏ lọt hơn nửa số review giả) và precision 60%. PM ngồi với team risk để định lượng chi phí: gỡ nhầm một review thật (FP) làm seller chân chính khiếu nại; bỏ lọt review giả (FN) làm khách mua nhầm hàng kém, hại lòng tin sàn về dài hạn. Họ thống nhất ưu tiên recall vừa phải nhưng giữ precision tối thiểu 70% để không gây làn sóng khiếu nại. Cuối cùng model được tinh chỉnh ngưỡng để đạt recall 68%, precision 72%.
Bài học: con số accuracy 98% suýt khiến cả team tự mãn. Chính việc PM đào sâu confusion matrix và định lượng chi phí FP/FN mới dẫn tới quyết định đúng.
Tình huống 2: MoMo và phê duyệt khoản vay nhỏ
Giả định MoMo triển khai model chấm điểm tín dụng cho sản phẩm trả góp. Hai model được đưa ra: Model A có ROC-AUC 0,82, Model B có ROC-AUC 0,80. Nếu chỉ nhìn AUC, ai cũng chọn A.
Nhưng PM hỏi một câu khác: "Ở mức tỉ lệ duyệt mà chúng ta thực sự vận hành — duyệt khoảng 30% hồ sơ tốt nhất — model nào cho tỉ lệ nợ xấu thấp hơn?" Khi cắt tại điểm vận hành đó, hóa ra Model B lại có tỉ lệ nợ xấu thấp hơn 0,4 điểm phần trăm, tương đương tiết kiệm vài tỉ đồng mỗi năm. ROC-AUC là chỉ số tổng hợp trên toàn dải ngưỡng, nhưng MoMo chỉ vận hành ở một vùng ngưỡng cụ thể.
Bài học: đừng chọn model bằng một metric tổng quát nếu sản phẩm chỉ chạy ở một điểm vận hành nhất định. Hãy đánh giá metric tại đúng ngưỡng kinh doanh của bạn.
Tình huống 3: Grab và dự đoán thời gian giao đồ ăn (ETA)
Grab dự đoán thời gian giao món để hiển thị cho khách. Team báo RMSE giảm từ 6,5 phút xuống 5,8 phút — một cải thiện rõ rệt. Nhưng PM nhận ra RMSE phạt đều cả hai chiều, trong khi với khách hàng, dự đoán quá ngắn rồi giao trễ gây bực bội hơn nhiều so với dự đoán dài rồi giao sớm.
PM đề xuất bổ sung một metric bất đối xứng: tỉ lệ đơn bị giao trễ so với ETA hứa hẹn (late rate), và đo riêng MAE cho nhóm bị trễ. Khi nhìn theo lăng kính đó, model RMSE thấp hơn lại có late rate cao hơn — tức làm khách thất vọng nhiều hơn. Team cuối cùng cộng thêm một "đệm an toàn" (buffer) và tối ưu theo late rate.
Bài học: metric phải phản ánh trải nghiệm thực tế và tính bất đối xứng của chi phí, không chỉ là sai số toán học trung bình.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho mọi dự án ML với tư cách Technical PM:
- Xác định loại bài toán: phân loại (nhãn) hay hồi quy (số)? Điều này quyết định nhóm metric bạn dùng.
- Định lượng chi phí của từng loại lỗi: ngồi với business để trả lời — một FP tốn bao nhiêu? một FN tốn bao nhiêu? Đây là bước quan trọng nhất và thường bị bỏ qua. Nếu FN tốn gấp 10 lần FP, metric phải nghiêng về recall.
- Kiểm tra cân bằng dữ liệu: hỏi tỉ lệ các lớp. Nếu lệch hơn 80/20, loại bỏ accuracy khỏi danh sách metric chính, chuyển sang precision/recall/F1/PR-AUC.
- Chọn một metric chính (north-star) và 1-2 metric phụ (guardrail). Ví dụ: tối ưu recall (chính) nhưng đặt sàn precision ≥ 70% (guardrail) để không gây hệ lụy.
- Đặt baseline: model mới phải so với cái gì? Một quy tắc đơn giản (rule-based), model cũ, hay đoán theo lớp đa số. Không có baseline thì con số metric vô nghĩa.
- Yêu cầu đánh giá tại điểm vận hành thực tế, không chỉ metric tổng quát như AUC. Hỏi: "Ở ngưỡng chúng ta định chạy, precision/recall là bao nhiêu?"
- Lập kế hoạch validate online: offline metric chỉ là proxy. Chốt rõ sẽ A/B test và đo business metric nào (chuyển đổi, doanh thu, khiếu nại) trước khi rollout toàn bộ.
- Theo dõi sau khi lên production: model suy giảm theo thời gian khi dữ liệu thay đổi. Đặt dashboard cảnh báo khi metric tụt dưới ngưỡng.
Lỗi thường gặp & mẹo
Lỗi: chỉ nhìn accuracy. Đây là cái bẫy phổ biến nhất. Mỗi khi nghe "accuracy cao", phản xạ đầu tiên của PM phải là hỏi tỉ lệ các lớp và đòi xem confusion matrix.
Lỗi: tối ưu metric không gắn với tiền hoặc trải nghiệm. Team có thể đẩy F1 lên rất cao mà doanh thu không nhúc nhích. Luôn nối metric kỹ thuật về một con số kinh doanh cụ thể.
Lỗi: data leakage làm metric đẹp giả tạo. Nếu tập test vô tình chứa thông tin từ tương lai hoặc trùng với tập train, metric sẽ đẹp lung linh trên giấy rồi sụp đổ trên production. Mẹo: hỏi team "tập test được tách như thế nào, có theo thời gian không?".
Lỗi: so sánh hai model bằng metric khác nhau hoặc tập test khác nhau. Mọi so sánh phải trên cùng một tập test cố định.
Lỗi: quên ngưỡng. Một model "tốt" với ngưỡng mặc định 0,5 có thể tệ ở ngưỡng vận hành thực tế. Threshold là một quyết định sản phẩm, không phải mặc định kỹ thuật.
Mẹo: luôn yêu cầu một bảng confusion matrix kèm vài ví dụ lỗi thật. Đọc 10 trường hợp FP và 10 FN cụ thể giúp bạn hiểu model sai ở đâu nhanh hơn mọi con số tổng hợp.
Mẹo: đặt metric vào bối cảnh chi phí bằng tiền. Thay vì "recall 68%", hãy nói "bỏ lọt 32% gian lận, tương đương khoảng X triệu/tháng". Stakeholder hiểu tiền nhanh hơn hiểu phần trăm.
Bài tập thực hành
Bài 1 — Đọc confusion matrix. Một model phát hiện spam có: TP=180, FP=20, FN=120, TN=9.680. Hãy tính accuracy, precision, recall, F1. Sau đó trả lời: accuracy có phản ánh đúng chất lượng model không? Vì sao? (Gợi ý: tính recall và bạn sẽ thấy model bỏ lọt phần lớn spam dù accuracy rất cao.)
Bài 2 — Chọn metric. Cho ba bài toán sau, hãy chọn metric chính và giải thích nên ưu tiên precision hay recall:
- (a) Hệ thống gợi ý sản phẩm trên trang chủ Shopee.
- (b) Model sàng lọc CV ứng viên để loại sớm hồ sơ không phù hợp.
- (c) Cảnh báo sớm sự cố máy chủ trước khi sập.
Bài 4 — Phản biện. Team báo cáo ROC-AUC 0,91 và đề nghị lên production ngay. Viết ra 3 câu hỏi bạn sẽ hỏi trước khi ký duyệt.
Tóm tắt
- Mọi metric phân loại bắt nguồn từ confusion matrix (TP, FP, FN, TN). Hiểu chắc bốn ô này là nền tảng của tất cả.
- Accuracy hay lừa người khi dữ liệu mất cân bằng — luôn hỏi tỉ lệ các lớp trước khi tin con số.
- Precision (ít báo động giả) và Recall (ít bỏ lọt) thường đánh đổi nhau; chọn ưu tiên dựa trên việc FP hay FN tốn kém hơn. F1 cân bằng cả hai.
- ROC-AUC đánh giá xuyên ngưỡng, nhưng với dữ liệu hiếm hãy ưu tiên PR-AUC; và luôn kiểm tra metric tại điểm vận hành thực tế, không chỉ chỉ số tổng quát.
- Bài toán hồi quy dùng MAE, RMSE, MAPE, và nên cân nhắc tính bất đối xứng của chi phí sai lệch.
- Offline metric chỉ là proxy — phán quyết cuối cùng phải đến từ business metric đo qua A/B test online.
- Vai trò Technical PM không phải tính metric, mà là chọn đúng thước đo gắn với chi phí và trải nghiệm thực, đặt guardrail, và đòi hỏi đánh giá trung thực. Chọn sai metric, cả team tối ưu chăm chỉ cho mục tiêu sai.