LLM-as-a-judge: dùng model chấm model, đúng cách

Bạn sửa prompt và muốn biết chất lượng tốt hơn hay tệ đi. Với output dạng văn bản tự do (tóm tắt, trả lời khách hàng, bài viết), không có đáp án đúng để so khớp, còn nhờ người chấm từng mẫu thì chậm và đắt. Giải pháp phổ biến là LLM-as-a-judge: dùng một model để chấm output của model khác. Nghiên cứu nền tảng của Zheng và cộng sự (2023, nhóm LMSYS với MT-Bench và Chatbot Arena) cho thấy cách này hiệu quả, nhưng cũng chỉ ra các thiên lệch bạn phải biết.

Kết quả chính của nghiên cứu

• Giám khảo mạnh (GPT-4 thời điểm đó) đạt mức đồng thuận với người đánh giá trên 80%, tương đương mức hai người đánh giá đồng ý với nhau.
• Như vậy LLM judge là cách mở rộng đánh giá khả thi, dễ giải thích, thay cho việc thuê người chấm toàn bộ.

Ba kiểu chấm

Bốn thiên lệch cần biết

Prompt giám khảo mẫu

Bạn chấm câu trả lời hỗ trợ khách hàng trong <answer>.
Rubric (mỗi mục đạt/không đạt):
1. Trả lời đúng câu hỏi trong <question>
2. Không hứa điều chính sách không cho phép (xem <policy>)
3. Có bước tiếp theo rõ ràng cho khách
Không thưởng điểm cho độ dài. Phân tích ngắn từng mục, sau đó
trả về JSON: {"pass": true/false, "failed": [số mục]}

Kinh nghiệm từ hệ thống Research của Anthropic cũng tương tự: một prompt giám khảo duy nhất, rubric rõ, output điểm 0.0–1.0 kèm đạt/không đạt cho kết quả nhất quán nhất.

Rủi ro và lưu ý

• Giám khảo cũng cần được kiểm định: lấy 30–50 mẫu có người chấm, đo mức đồng thuận trước khi tin điểm của model.
• Tối ưu theo giám khảo: sửa prompt chỉ để làm hài lòng giám khảo có thể làm hỏng trải nghiệm thật.
• Đừng bỏ hẳn người chấm: định kỳ cho người xem mẫu ngẫu nhiên để bắt lỗi giám khảo bỏ sót.

Áp dụng thế nào?

• Dev: Viết rubric dạng đạt/không đạt theo từng tiêu chí thay vì thang 1–10 mơ hồ; chạy giám khảo trong CI khi đổi prompt.
• Tech Lead: Hiệu chỉnh giám khảo với bộ mẫu do người chấm; theo dõi tỷ lệ đồng thuận như một chỉ số.
• PM: Định nghĩa "tốt" bằng tiêu chí kinh doanh cụ thể; đó chính là rubric cho giám khảo.