Khi xây dựng mô hình Machine Learning, nhiều nhóm thường nhìn vào một vài chỉ số tổng quát như accuracy, F1-score, AUC hoặc loss trung bình rồi kết luận mô hình đã đủ tốt. Cách làm này tiện, nhưng dễ che giấu một vấn đề quan trọng: mô hình có thể hoạt động rất tốt trên toàn bộ tập kiểm thử, nhưng lại thất bại trên một nhóm dữ liệu nhỏ nhưng quan trọng. Đây là lúc ta cần đánh giá mô hình theo từng lát cắt dữ liệu, hay còn gọi là slice-based evaluation. Một lát cắt dữ liệu là gì? Lát cắt dữ liệu là một nhóm mẫu có chung đặc điểm nào đó. Ví dụ: - Người dùng mới và người dùng cũ - Đơn hàng giá trị thấp, trung bình, cao - Văn bản ngắn và văn bản dài - Ảnh chụp ban ngày và ban đêm - Câu hỏi tiếng Việt có dấu và không dấu - Khách hàng đến từ từng khu vực địa lý - Log hệ thống từ từng phiên bản phần mềm Thay vì chỉ hỏi “mô hình đúng bao nhiêu phần trăm trên toàn bộ dữ liệu?”, ta hỏi thêm: “mô hình đúng bao nhiêu trên từng nhóm cụ thể?”. Ví dụ thực tế: mô hình phân loại phản hồi khách hàng Giả sử bạn xây dựng mô hình phân loại phản hồi khách hàng thành ba nhóm: tích cực, trung lập, tiêu cực. Trên tập kiểm thử, mô hình đạt F1-score khá tốt. Tuy nhiên khi triển khai, đội chăm sóc khách hàng phàn nàn rằng nhiều phản hồi tiêu cực nghiêm trọng bị bỏ sót. Nếu chỉ nhìn chỉ số tổng, bạn có thể không thấy vấn đề. Nhưng khi chia dữ liệu thành các lát cắt, có thể phát hiện: - Phản hồi ngắn dưới 10 từ: mô hình nhầm nhiều hơn - Phản hồi có tiếng lóng: kết quả kém - Phản hồi về hoàn tiền: dễ bị phân loại sai thành trung lập - Phản hồi viết không dấu: độ chính xác giảm rõ rệt Như vậy, lỗi không nằm đều trên toàn bộ dữ liệu. Nó tập trung ở một số nhóm cụ thể. Đây là thông tin rất có giá trị để cải thiện hệ thống. Vì sao chỉ số trung bình có thể gây hiểu nhầm? Chỉ số trung bình thường bị chi phối bởi nhóm dữ liệu lớn. Nếu 90% dữ liệu thuộc nhóm dễ dự đoán, mô hình có thể đạt điểm rất cao dù hoạt động kém trên 10% dữ liệu còn lại. Trong nhiều bài toán thực tế, nhóm nhỏ lại có ý nghĩa lớn. Ví dụ: - Giao dịch gian lận thường chiếm tỷ lệ nhỏ nhưng rất quan trọng - Khiếu nại nghiêm trọng ít hơn phản hồi thông thường nhưng cần xử lý nhanh - Ca bệnh hiếm có ít mẫu nhưng hậu quả dự đoán sai có thể lớn - Truy vấn dài và phức tạp ít hơn truy vấn đơn giản nhưng thường là nơi LLM dễ trả lời sai Vì vậy, đánh giá trung bình là cần thiết nhưng chưa đủ. Cách bắt đầu đánh giá theo lát cắt Bạn không cần hệ thống phức tạp ngay từ đầu. Có thể bắt đầu bằng vài bước thực tế: 1. Xác định các thuộc tính quan trọng Hãy liệt kê những yếu tố có thể ảnh hưởng đến chất lượng mô hình. Ví dụ với dữ liệu văn bản: độ dài câu, ngôn ngữ, có lỗi chính tả hay không, chủ đề, nguồn dữ liệu, thời gian tạo dữ liệu. Với dữ liệu ảnh: ánh sáng, góc chụp, thiết bị, độ phân giải, bối cảnh. 2. Tạo báo cáo chỉ số theo từng nhóm Thay vì chỉ tính một F1-score tổng, hãy tính thêm F1-score cho từng nhóm. Nếu là bài toán phân loại nhị phân, nên xem cả precision, recall và số lượng mẫu trong từng lát cắt. Một lát cắt có điểm thấp nhưng chỉ có 3 mẫu thì chưa đủ kết luận; ngược lại, lát cắt có hàng nghìn mẫu và điểm thấp là tín hiệu cần ưu tiên. 3. So sánh với chỉ số tổng Hãy tìm các nhóm có hiệu năng thấp hơn đáng kể so với mức trung bình. Ví dụ mô hình có accuracy tổng là 92%, nhưng với dữ liệu từ người dùng mới chỉ đạt 78%. Chênh lệch này đáng được điều tra. 4. Xem mẫu lỗi cụ thể Chỉ số giúp phát hiện vấn đề, nhưng không giải thích đầy đủ nguyên nhân. Sau khi tìm ra lát cắt yếu, nên đọc hoặc kiểm tra thủ công một số mẫu sai. Bạn có thể phát hiện nhãn bị sai, dữ liệu thiếu ngữ cảnh, đặc trưng chưa đủ tốt, hoặc prompt chưa xử lý đúng tình huống. 5. Đưa lát cắt quan trọng vào quy trình kiểm thử định kỳ Khi đã biết một số nhóm dữ liệu nhạy cảm, hãy biến chúng thành một phần của bộ đánh giá cố định. Mỗi lần huấn luyện lại mô hình, đổi embedding, chỉnh prompt hoặc thay phiên bản LLM, cần kiểm tra lại các nhóm này. Áp dụng với ứng dụng LLM và RAG Slice-based evaluation không chỉ dành cho mô hình Machine Learning truyền thống. Với ứng dụng LLM, cách này càng hữu ích. Ví dụ một chatbot nội bộ dùng RAG để trả lời tài liệu công ty. Nếu chỉ thử vài câu hỏi phổ biến, bạn có thể nghĩ hệ thống đã ổn. Nhưng nên chia bộ câu hỏi kiểm thử theo các nhóm như: - Câu hỏi có câu trả lời nằm trong một tài liệu duy nhất - Câu hỏi cần tổng hợp từ nhiều tài liệu - Câu hỏi có thuật ngữ viết tắt - Câu hỏi về chính sách cũ và chính sách mới - Câu hỏi không có thông tin trong kho tài liệu - Câu hỏi dài, chứa nhiều yêu cầu cùng lúc Mỗi nhóm cần được đánh giá riêng: truy xuất có đúng tài liệu không, câu trả lời có bịa không, có trích đúng ngữ cảnh không, có từ chối hợp lý khi thiếu thông tin không. Lời khuyên thực tế - Đừng tạo quá nhiều lát cắt ngay từ đầu. Hãy bắt đầu với 5 đến 10 nhóm có ý nghĩa nghiệp vụ rõ ràng. - Luôn ghi kèm số lượng mẫu trong từng lát cắt. Chỉ số không có cỡ mẫu rất dễ gây hiểu nhầm. - Ưu tiên lát cắt có rủi ro cao, không chỉ lát cắt có nhiều dữ liệu. - Khi cải thiện một lát cắt yếu, nhớ kiểm tra lại chỉ số tổng và các lát cắt khác để tránh sửa nhóm này nhưng làm hỏng nhóm kia. - Nên lưu lịch sử kết quả theo thời gian để phát hiện chất lượng mô hình suy giảm sau các lần cập nhật. Kết luận Một mô hình tốt không chỉ là mô hình có điểm trung bình cao. Trong sản phẩm thật, điều quan trọng là mô hình có hoạt động ổn định trên những nhóm dữ liệu quan trọng hay không. Đánh giá theo lát cắt giúp đội phát triển nhìn rõ nơi mô hình đang yếu, ưu tiên cải thiện đúng chỗ và giảm rủi ro khi triển khai. Nếu bạn đang xây dựng hệ thống AI, hãy thêm một câu hỏi vào mỗi lần đánh giá: “Mô hình đang thất bại nhiều nhất ở nhóm dữ liệu nào?”. Câu hỏi này thường đem lại nhiều giá trị hơn một con số tổng quát đẹp mắt.