1. Vì sao cần LLM-as-judge cho output mở
Nhiều tính năng hiện đại sinh ra output không có một đáp án đúng duy nhất: câu trả lời của chatbot hỗ trợ, đoạn tóm tắt, email được tạo tự động, mô tả sản phẩm. Với những output này, assertion so-khớp-chuỗi truyền thống là vô dụng — hai câu trả lời khác từ nhưng cùng đúng sẽ bị coi là fail. LLM-as-judge (dùng một mô hình để chấm điểm output của mô hình khác) lấp khoảng trống đó: nó đánh giá theo tiêu chí mềm như tính đúng, đầy đủ, giọng điệu, an toàn — những thứ regex không nắm được. Nhưng đây là con dao hai lưỡi, phải dùng có kỷ luật.
2. Đặt oracle xác định trước, judge sau (oracle-first)
Sai lầm phổ biến là giao mọi thứ cho LLM-as-judge, kể cả những phần vốn kiểm được bằng logic. Nguyên tắc oracle-first: bất cứ gì có thể kiểm bằng quy tắc xác định thì phải kiểm bằng quy tắc, chỉ phần thật sự mở mới đưa cho judge. Ví dụ với câu trả lời chatbot đặt hàng: JSON có đúng schema không, mã đơn có tồn tại trong DB không, tổng tiền có khớp không — đều là oracle cứng. Chỉ 'câu trả lời có lịch sự và đúng ý khách không' mới cần judge. Cách này giảm chi phí, tăng độ tin cậy, và thu hẹp bề mặt mà judge có thể sai.
// Oracle-first: kiểm phần XÁC ĐỊNH trước, judge CHỈ cho phần mở
import { z } from 'zod';
const OrderReply = z.object({ orderId: z.string(), total: z.number().positive() });
async function evaluateReply(reply: any, db: DB) {
// (1) Oracle cứng — không cần LLM
const parsed = OrderReply.safeParse(reply.structured);
if (!parsed.success) return { pass: false, reason: 'schema invalid' };
const order = await db.orders.find(parsed.data.orderId);
if (!order) return { pass: false, reason: 'orderId không tồn tại' };
if (order.total !== parsed.data.total) return { pass: false, reason: 'total lệch' };
// (2) Chỉ phần MỞ mới đưa cho judge
const soft = await llmJudge({ rubric: TONE_RUBRIC, text: reply.text });
return { pass: soft.score >= 4, hardOk: true, softScore: soft.score };
}❓ Nếu oracle cứng đã fail thì có cần chạy judge không?
Không nên. Nếu JSON sai schema hay mã đơn không tồn tại thì output đã sai về mặt sự thật, chấm điểm giọng điệu là vô nghĩa và tốn tiền. Hãy short-circuit: oracle cứng fail → fail ngay, không gọi judge. Judge chỉ chạy khi phần xác định đã đạt, để đánh giá chất lượng phần mở.
3. Thiết kế rubric: neo mốc rõ ràng, có ví dụ
Chất lượng của LLM-as-judge phụ thuộc gần như hoàn toàn vào rubric. Một rubric tốt không nói 'chấm chất lượng từ 1 đến 5' mà định nghĩa từng mức bằng mô tả cụ thể và ví dụ neo (anchor examples). Ví dụ mức 5 = 'trả lời đúng, đầy đủ mọi ý khách hỏi, giọng lịch sự, không bịa thông tin'; mức 1 = 'sai hoặc bịa thông tin quan trọng'. Nên tách thành nhiều tiêu chí độc lập (đúng, đầy đủ, an toàn, giọng điệu) thay vì một điểm tổng mơ hồ, để judge chấm từng chiều và ta biết chính xác vì sao trượt.
// Rubric có neo mốc rõ + tách chiều — đưa vào prompt của judge
export const TONE_RUBRIC = `
Chấm từng tiêu chí 1-5 (chỉ trả JSON):
correctness: 5=đúng hoàn toàn, khớp nguồn; 3=đúng một phần; 1=sai/bịa.
completeness: 5=trả lời mọi ý khách hỏi; 3=thiếu 1 ý; 1=bỏ sót ý chính.
safety: 5=không lời khuyên nguy hiểm/PII; 1=vi phạm chính sách.
tone: 5=lịch sự, rõ ràng; 1=cộc/khó hiểu.
Ví dụ neo (few-shot):
- Input: "Đơn của tôi đâu?" | Output: "Đơn #A12 đang giao, đến 5/7." => correctness 5, completeness 5.
- Output: "Chắc là ổn thôi." => correctness 1, completeness 1.
Trả: {"correctness":n,"completeness":n,"safety":n,"tone":n,"reason":"..."}`;Team dùng judge với rubric 'chấm 1-10 theo cảm nhận'. Ba sprint sau, điểm trung bình tăng từ 6.2 lên 7.8 dù chất lượng không đổi — hoá ra mỗi lần đổi prompt nhỏ, judge lại 'rộng tay' hơn. Sau khi thêm ví dụ neo cố định cho mức 1/3/5 và ép JSON, điểm ổn định và có thể so sánh giữa các sprint. Bài học: không có mốc neo thì điểm judge không có nghĩa tuyệt đối.
4. Pointwise vs pairwise: chấm điểm hay so sánh
Có hai chế độ chính khi dùng judge. Pointwise (chấm điểm): đưa một output và yêu cầu điểm tuyệt đối theo rubric — tốt để theo dõi chất lượng theo thời gian, nhưng dễ bị trôi thang điểm. Pairwise (so cặp): đưa hai output A và B, yêu cầu chọn cái tốt hơn — ổn định hơn vì so sánh tương đối dễ hơn chấm tuyệt đối, rất hợp để chọn giữa hai phiên bản mô hình. Nhược điểm của pairwise là chi phí (tổ hợp cặp) và position bias — judge có xu hướng thiên vị vị trí (thường chọn A). Chọn chế độ theo mục tiêu: theo dõi tuyệt đối → pointwise; quyết định 'model nào tốt hơn' → pairwise.
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!