Khi xây dựng ứng dụng dùng mô hình ngôn ngữ lớn, nhiều nhóm thường đánh giá chất lượng bằng cách đọc vài câu trả lời rồi kết luận “ổn” hoặc “chưa ổn”. Cách này nhanh, nhưng rất khó lặp lại, khó so sánh giữa các phiên bản prompt, và dễ bị cảm tính. Một cách thực tế hơn là dùng rubric: bộ tiêu chí chấm điểm rõ ràng cho từng loại đầu ra. Rubric không cần phức tạp ngay từ đầu. Mục tiêu là biến kỳ vọng mơ hồ thành các câu hỏi cụ thể: câu trả lời có đúng không, có đủ không, có bịa không, có đúng giọng văn không, có tuân thủ ràng buộc không. Ví dụ: với chatbot hỗ trợ khách hàng về chính sách đổi trả, một rubric đơn giản có thể gồm: - Độ chính xác: câu trả lời có khớp với tài liệu chính sách không? - Độ đầy đủ: có nêu đủ điều kiện, thời hạn, ngoại lệ quan trọng không? - Không bịa: có thêm thông tin không có trong tài liệu không? - Tính hành động: người dùng có biết bước tiếp theo cần làm gì không? - Giọng văn: có lịch sự, ngắn gọn, không đổ lỗi cho khách hàng không? Mỗi tiêu chí có thể chấm theo thang 0-2 hoặc 1-5. Với giai đoạn đầu, thang 0-2 thường dễ thống nhất hơn: 0 là sai hoặc thiếu nghiêm trọng, 1 là chấp nhận được nhưng còn lỗi, 2 là đạt tốt. Một lỗi phổ biến là chỉ chấm “câu trả lời hay không”. Điều này khiến bạn khó biết cần sửa gì. Nếu điểm tổng thấp, nguyên nhân có thể là retrieval lấy sai tài liệu, prompt yêu cầu không rõ, mô hình quá dài dòng, hoặc câu hỏi người dùng nằm ngoài phạm vi. Rubric tách nhỏ vấn đề để bạn tìm đúng chỗ cần cải thiện. Quy trình áp dụng có thể bắt đầu như sau: 1. Thu thập 30-100 câu hỏi đại diện Không nên chỉ chọn câu dễ. Hãy có cả câu hỏi phổ biến, câu mơ hồ, câu ngoài phạm vi, câu có thông tin gây nhiễu, và câu đòi hỏi mô hình phải từ chối trả lời. 2. Viết câu trả lời kỳ vọng hoặc ghi chú kiểm tra Không nhất thiết phải viết đáp án mẫu hoàn hảo cho mọi câu, nhưng cần biết câu trả lời đúng phải dựa vào đâu. Với ứng dụng RAG, nên lưu kèm đoạn tài liệu liên quan. 3. Tạo rubric ngắn, dễ dùng Mỗi tiêu chí nên có mô tả rõ. Ví dụ “không bịa” nghĩa là không đưa ra chính sách, số ngày, mức phí, cam kết hoặc quy trình không có trong nguồn được cung cấp. 4. Chấm độc lập một số mẫu Nếu có nhiều người chấm, hãy để họ chấm thử cùng một tập nhỏ rồi so sánh. Nếu cùng một câu mà người chấm cho điểm rất khác nhau, rubric đang chưa đủ rõ. 5. Dùng kết quả để ra quyết định Đừng chỉ nhìn điểm trung bình. Hãy xem nhóm lỗi nào xuất hiện nhiều nhất. Nếu nhiều câu đúng nhưng thiếu bước tiếp theo, sửa prompt. Nếu nhiều câu bịa theo tài liệu không liên quan, kiểm tra lại tìm kiếm vector hoặc bộ lọc dữ liệu. Nếu câu trả lời quá dài, thêm ràng buộc định dạng. Có thể dùng LLM để hỗ trợ chấm tự động, nhưng không nên tin tuyệt đối. Cách an toàn hơn là dùng mô hình chấm như một lớp lọc ban đầu, sau đó con người kiểm tra các trường hợp điểm thấp, điểm bất thường, hoặc các câu thuộc nghiệp vụ quan trọng. Với lĩnh vực nhạy cảm như y tế, tài chính, pháp lý, cần có người có chuyên môn tham gia đánh giá. Một mẹo hữu ích là lưu lịch sử điểm theo phiên bản: version của prompt, mô hình, dữ liệu retrieval, và ngày chạy đánh giá. Khi thay đổi hệ thống, bạn có thể biết phiên bản mới tốt hơn thật hay chỉ tốt hơn ở vài ví dụ được chọn thủ công. Rubric không làm mô hình thông minh hơn ngay lập tức, nhưng giúp đội phát triển học nhanh hơn từ lỗi. Thay vì tranh luận “câu này nghe ổn mà”, cả nhóm có thể nói cụ thể: “đúng nội dung nhưng thiếu điều kiện ngoại lệ”, “có bịa thời hạn”, hoặc “không hướng dẫn bước tiếp theo”. Đó là nền tảng quan trọng để cải thiện ứng dụng AI một cách có kiểm soát.