Bài 6 — LLM-as-a-Judge

Phần lớn output của agent là văn bản tự do — không có "đáp án đúng duy nhất". Bạn không thể exact-match "Chính sách hoàn tiền của chúng tôi là 7 ngày". Giải pháp: dùng một LLM khác làm giám khảo chấm điểm. Đây là kỹ thuật lõi của eval hiện đại, cả ba nền tảng đều hỗ trợ.

Nguyên tắc: giám khảo cần tiêu chí rõ ràng

LLM-judge chấm tốt hay tệ phụ thuộc hoàn toàn vào prompt chấm điểm. Nguyên tắc:

• Một tiêu chí một judge: đừng bắt một judge vừa chấm đúng-sự-thật, vừa chấm giọng văn, vừa chấm an toàn. Tách ra.
• Dùng thang rời rạc, có mô tả: thay vì "chấm 0–10", hãy định nghĩa từng mức.
• Yêu cầu lý do trước, điểm sau (chain-of-thought): buộc judge giải thích rồi mới kết luận → ổn định hơn.
• Trả về cấu trúc để parse được.

Ví dụ prompt judge cho "độ đúng sự thật"

Bạn là giám khảo đánh giá câu trả lời của trợ lý.
Tiêu chí: câu trả lời có ĐÚNG SỰ THẬT so với tài liệu tham chiếu không?

Tài liệu tham chiếu: {reference}
Câu hỏi: {question}
Câu trả lời cần chấm: {answer}

Hãy phân tích ngắn gọn, rồi chấm theo thang:
- "correct": khớp hoàn toàn tài liệu
- "partially_correct": đúng phần chính nhưng thiếu/thừa nhỏ
- "incorrect": mâu thuẫn tài liệu hoặc bịa

Trả JSON: {"reasoning": "...", "label": "..."}

Ánh xạ label → điểm: correct=1.0, partially=0.5, incorrect=0.0.

Bước triển khai (dùng chung mọi nền tảng)

• Viết rubric (bảng tiêu chí) rõ ràng, kèm ví dụ mỗi mức điểm.
• Chọn model judge mạnh hơn hoặc ngang model đang eval (giám khảo yếu chấm sai).
• Cắm judge vào scorer: LangSmith có evaluator LLM, Langfuse có LLM-as-judge tích hợp, Braintrust có autoevals (Factuality, ClosedQA...).
• Hiệu chỉnh (calibrate): cho judge chấm 20 ca mà con người đã chấm sẵn; đo mức đồng thuận. Đồng thuận thấp → sửa rubric.
• Chạy judge trên dataset và/hoặc trên sample traffic production.

Ví dụ scorer LLM-judge (Braintrust autoevals)

from autoevals import LLMClassifier

tone_judge = LLMClassifier(
    name="tone",
    prompt_template=(
        "Câu trả lời có lịch sự và chuyên nghiệp không?\n"
        "Answer: {{output}}\n"
        "Chọn: polite hoặc rude"
    ),
    choice_scores={"polite": 1, "rude": 0},
)

Khung: khi nào KHÔNG dùng LLM-judge

• Có đáp án xác định (mã, số, boolean) → dùng exact/rule, rẻ và chắc hơn.
• Cần độ chính xác pháp lý tuyệt đối → cần người rà.
• Chi phí/độ trễ là nút thắt → giới hạn judge trên sample nhỏ.

Checklist judge đáng tin

• [ ] Mỗi judge chỉ đo MỘT chiều chất lượng.
• [ ] Rubric có mô tả từng mức + ví dụ.
• [ ] Judge trả reasoning trước, label sau.
• [ ] Đã calibrate với nhãn người thật, đồng thuận > ~80%.
• [ ] Có theo dõi chi phí/độ trễ của bản thân việc chấm.

Sai lầm thường gặp

• Judge quá mơ hồ ("câu này có tốt không?"): điểm nhiễu, vô dụng.
• Không calibrate: bạn tin điểm judge nhưng nó lệch với người dùng thật.
• Position/verbosity bias: judge thiên vị câu trả lời dài hoặc option đầu; giảm bằng rubric chặt và tráo thứ tự.
• Dùng judge yếu chấm model mạnh: giám khảo không đủ trình, kết quả sai hệ thống.
• Chấm 100% traffic bằng judge đắt tiền: cháy ngân sách; hãy sample và kết hợp scorer rẻ.

Giờ bạn biết đo chất lượng "mềm". Bài 7 dùng nó để so sánh phiên bản và ngăn regression khi ship.