Trong nhiều dự án Machine Learning, nhóm phát triển thường dành nhiều thời gian thử mô hình mới, tinh chỉnh tham số, tăng dữ liệu, nhưng lại ít đặt câu hỏi: “Ta đang tối ưu đúng thước đo chưa?”. Một mô hình có accuracy cao chưa chắc hữu ích, một chatbot trả lời nghe trôi chảy chưa chắc giải quyết đúng việc, và một hệ thống dự đoán rủi ro có điểm trung bình tốt vẫn có thể gây thiệt hại nếu bỏ sót các trường hợp quan trọng. Bài viết này tập trung vào một việc tưởng đơn giản nhưng rất dễ sai: chọn metric đánh giá mô hình phù hợp với mục tiêu thực tế. 1. Metric không chỉ là con số kỹ thuật Metric là cách ta biến chất lượng mô hình thành con số để so sánh. Nhưng con số đó chỉ có ý nghĩa khi nó phản ánh đúng mục tiêu sản phẩm hoặc nghiệp vụ. Ví dụ: một mô hình phân loại email spam đạt accuracy 98%. Nghe rất tốt. Nhưng nếu dữ liệu có 98% email bình thường và 2% spam, mô hình chỉ cần đoán tất cả là “không spam” cũng đạt 98%. Trong trường hợp này, accuracy gần như vô dụng. Thay vào đó, ta cần xem: - Precision: trong các email bị đánh dấu spam, bao nhiêu email thật sự là spam? - Recall: trong toàn bộ email spam, mô hình bắt được bao nhiêu? - F1-score: cân bằng giữa precision và recall. Nếu sản phẩm không được phép chặn nhầm email quan trọng, precision cần được ưu tiên. Nếu mục tiêu là không để spam lọt vào hộp thư, recall quan trọng hơn. 2. Bắt đầu từ chi phí sai lầm Một cách thực tế để chọn metric là liệt kê các kiểu sai lầm và chi phí tương ứng. Ví dụ với mô hình phát hiện giao dịch gian lận: - Dự đoán gian lận nhưng thực tế hợp lệ: khách hàng bị làm phiền, giao dịch bị trì hoãn. - Dự đoán hợp lệ nhưng thực tế gian lận: doanh nghiệp mất tiền. Nếu bỏ sót gian lận gây thiệt hại lớn hơn nhiều so với kiểm tra nhầm, ta có thể ưu tiên recall cao, sau đó dùng quy trình xác minh thủ công để giảm tác động của cảnh báo sai. Ví dụ với mô hình hỗ trợ chẩn đoán bệnh: - Bỏ sót ca bệnh có thể rất nghiêm trọng. - Cảnh báo nhầm có thể dẫn đến xét nghiệm thêm, tốn chi phí và gây lo lắng. Trong bối cảnh này, recall thường được xem xét rất kỹ, nhưng không thể bỏ qua precision vì cảnh báo quá nhiều cũng làm hệ thống mất giá trị. 3. Đừng chỉ nhìn một metric duy nhất Một metric đơn lẻ thường không đủ mô tả chất lượng mô hình. Nên có một bộ metric gồm: - Metric chính: dùng để quyết định mô hình nào tốt hơn. - Metric phụ: dùng để phát hiện tác dụng phụ. - Metric theo từng nhóm dữ liệu: dùng để kiểm tra mô hình có yếu ở phân khúc nào không. Ví dụ với bài toán dự đoán khách hàng rời bỏ dịch vụ, nhóm có thể chọn: - AUC hoặc average precision để đánh giá khả năng xếp hạng rủi ro. - Recall trong top 10% khách hàng rủi ro nhất, vì đội chăm sóc chỉ có nguồn lực gọi cho một phần nhỏ khách hàng. - Precision trong nhóm khách hàng giá trị cao, vì nhầm lẫn ở nhóm này có thể gây lãng phí ngân sách ưu đãi. Cách nhìn này gần với thực tế hơn việc chỉ báo cáo một con số accuracy chung. 4. Với mô hình hồi quy, sai số trung bình chưa chắc đủ Trong bài toán dự đoán giá nhà, thời gian giao hàng, doanh thu hoặc nhu cầu tồn kho, các metric phổ biến gồm MAE, MSE, RMSE, MAPE. Mỗi metric có cách “phạt lỗi” khác nhau. - MAE dễ hiểu: trung bình mô hình sai bao nhiêu đơn vị. - MSE/RMSE phạt mạnh các lỗi lớn, phù hợp khi sai lệch lớn gây hậu quả nghiêm trọng. - MAPE biểu diễn lỗi theo phần trăm, nhưng có vấn đề khi giá trị thực gần bằng 0. Ví dụ dự đoán thời gian giao hàng: sai 5 phút thường chấp nhận được, nhưng sai 2 giờ là trải nghiệm rất tệ. Khi đó RMSE hoặc các metric tập trung vào lỗi lớn có thể hữu ích hơn MAE. Ngoài ra, nên xem phân phối lỗi thay vì chỉ lấy trung bình. Mô hình có MAE thấp nhưng thỉnh thoảng sai cực lớn vẫn có thể không dùng được trong sản phẩm thật. 5. Với ứng dụng LLM, cần kết hợp đánh giá tự động và đánh giá con người Ứng dụng dùng mô hình ngôn ngữ lớn thường khó đánh giá hơn phân loại truyền thống. Một câu trả lời có thể đúng về ý nhưng khác cách diễn đạt; hoặc nghe tự tin nhưng sai sự thật. Tùy ứng dụng, có thể xây dựng các tiêu chí như: - Đúng thông tin: câu trả lời có bám vào dữ liệu được cung cấp không? - Đầy đủ: có trả lời hết câu hỏi không? - An toàn: có tránh đưa hướng dẫn nguy hiểm hoặc thông tin nhạy cảm không? - Hữu ích: người dùng có thể hành động dựa trên câu trả lời không? - Định dạng: có tuân thủ yêu cầu JSON, bảng, danh sách hay giọng văn không? Với chatbot nội bộ dùng RAG, một bộ đánh giá thực tế có thể gồm các câu hỏi mẫu, tài liệu gốc liên quan, câu trả lời kỳ vọng và tiêu chí chấm điểm. Không nên chỉ đọc vài câu trả lời hay rồi kết luận hệ thống đã tốt. 6. Đặt ngưỡng quyết định cũng là một phần của đánh giá Nhiều mô hình trả về xác suất, nhưng sản phẩm cần quyết định: duyệt hay chặn, gửi cảnh báo hay không, ưu tiên khách hàng nào trước. Ngưỡng 0.5 không phải lúc nào cũng hợp lý. Nếu cảnh báo gian lận, ngưỡng có thể thấp để bắt nhiều trường hợp nghi ngờ. Nếu tự động khóa tài khoản, ngưỡng cần cao hơn hoặc phải có bước kiểm duyệt. Một cách làm thực tế: - Vẽ precision-recall theo nhiều ngưỡng. - Chọn vài ngưỡng ứng viên. - Ước lượng số cảnh báo mỗi ngày và nguồn lực xử lý. - Thử nghiệm trên dữ liệu quá khứ hoặc chạy shadow mode trước khi áp dụng thật. 7. Lời khuyên áp dụng cho dự án thực tế Trước khi huấn luyện mô hình, hãy trả lời các câu hỏi sau: - Quyết định kinh doanh hoặc sản phẩm nào sẽ dùng đầu ra của mô hình? - Sai lầm nào đắt hơn: false positive hay false negative? - Có giới hạn vận hành nào không, ví dụ mỗi ngày chỉ xử lý được 500 cảnh báo? - Metric chính là gì, metric phụ là gì? - Có nhóm người dùng, nhóm dữ liệu hoặc tình huống nào cần theo dõi riêng không? - Metric offline có liên hệ rõ với kết quả online không? Một quy tắc đơn giản: nếu bạn không thể giải thích vì sao chọn metric đó cho người không chuyên, có thể bạn chưa chọn xong. Kết luận Chọn metric không phải bước phụ sau khi mô hình đã chạy. Nó là một quyết định thiết kế quan trọng, ảnh hưởng đến dữ liệu, thuật toán, cách đặt ngưỡng và cả cách triển khai sản phẩm. Tối ưu sai metric có thể tạo ra mô hình “đẹp trên báo cáo” nhưng kém hữu ích ngoài thực tế. Thay vì hỏi “mô hình nào có điểm cao nhất?”, hãy hỏi “điểm cao này có nghĩa gì đối với người dùng và quy trình thật?”. Khi metric phản ánh đúng mục tiêu, mọi nỗ lực cải tiến mô hình mới đi đúng hướng.