LLM-as-Judge: Viết Rubric Và Hiệu Chỉnh Judge Bằng Nhãn Người

Code-based check bắt được thứ có hình dạng đúng/sai rõ ràng - một field bị thiếu, một schema sai, một trạng thái chưa từng được ghi vào database. Nhưng phần lớn thứ thật sự quyết định một sản phẩm AI tốt hay tệ lại không có hình dạng để assert: tông giọng có đúng không, câu trả lời có bám sát thương hiệu không, lời giải thích có thật sự hữu ích chứ không chỉ đúng về mặt kỹ thuật. Đó là lớp mà LLM-as-judge lấp vào - một model được prompt bằng đúng rubric mà người review dùng, chấm ở quy mô không đội người nào theo kịp.

Vì sao cần một lớp thứ ba sau code-based check

Một pipeline lai đẩy các case dễ xuống lớp rẻ nhất còn đáng tin, rồi escalate phần còn lại lên. Code-based check xử lý đúng/sai máy móc - schema có hợp lệ không, field bắt buộc có mặt không, một tool call có thật sự thay đổi đúng trạng thái nó nói đã thay đổi hay không. Phần còn lại sau lớp lọc đó là phần chủ quan thật sự: những output mà hai người có chuyên môn có thể bất đồng hợp lý về tông giọng, độ đầy đủ, hay đánh giá. Đưa thẳng phần đó cho người review không scale được quá vài chục trace mỗi ngày. Đưa nó cho một model chưa hiệu chỉnh chỉ là một phỏng đoán tự động khoác áo con số. Một LLM-as-judge, được hiệu chỉnh bằng nhãn người thật, chính là lớp sinh ra để lấp đúng khoảng trống này - đủ nhanh và rẻ để chạy trên mọi trace bị escalate, đủ đáng tin vì phán quyết của nó đã thật sự được đối chiếu với con người.

Judge đơn tiêu chí và judge so sánh cặp, chọn loại nào

Có hai cách để yêu cầu một judge model chấm điểm, và chọn sai loại cho đúng câu hỏi sẽ tạo ra kết quả nhiễu mà không cách chỉnh rubric nào sửa được. Một judge đơn tiêu chí chấm một output theo một rubric cố định - câu trả lời này có đạt chuẩn không, đạt/không đạt, hoặc theo một thang được định nghĩa rõ. Đây là công cụ đúng khi có một mức chuẩn tuyệt đối cần vượt qua: câu trả lời này có vi phạm chính sách hoàn tiền không, có chứa lỗi sự kiện không, có đạt chuẩn tông giọng không. Một judge so sánh cặp đưa cho judge hai output cạnh nhau và hỏi cái nào tốt hơn - đây là công cụ đúng khi câu hỏi mang tính tương đối chứ không tuyệt đối, như so sánh hai phiên bản prompt hay hai checkpoint model trên cùng một input. Judge so sánh cặp cũng thường nhất quán hơn judge đơn tiêu chí, vì "cái nào trong hai cái này tốt hơn" là một phán quyết dễ hơn "đây là 3 điểm hay 4 điểm trên một thang tuyệt đối" - nhưng nó chỉ trả lời được câu hỏi tương đối, không trả lời được câu hỏi tuyệt đối, nên nó là công cụ sai khi câu hỏi thật sự là "cái này có đạt chuẩn của chúng ta không" thay vì "cái nào tốt hơn".

Viết rubric không để lại chỗ cho model tự suy diễn

Một rubric mơ hồ tạo ra một judge mơ hồ. "Chấm điểm mức độ hữu ích của câu trả lời này từ 1 tới 5" mời gọi đúng loại thiếu nhất quán mà một rubric mơ hồ tạo ra ở một người review: hai lượt chạy của cùng một judge model có thể ra hai điểm khác nhau cho cùng một input, vì tiêu chí chưa bao giờ nói rõ điều gì phân biệt điểm 3 với điểm 4. Một rubric chặt chẽ nêu rõ các điều kiện cụ thể, kiểm tra được, phân biệt đạt và không đạt, giống cách một nhãn error-analysis tốt làm: không phải "câu trả lời này có tốt không" mà là "câu trả lời có trích đúng chính sách hoàn tiền, có ghi nhận sự bức xúc khách hàng đã nêu, và có tránh hứa một mốc thời gian mà team không đảm bảo được không". Nhãn nhị phân thắng thang điểm ở đây vì đúng lý do nó thắng thang điểm khi gán nhãn người: một thang điểm mời judge lấp lửng ở giữa thay vì đưa ra một quyết định rõ ràng. Rubric cũng nên nêu rõ các edge case judge nhiều khả năng gặp phải, vì một model được đưa một rubric mơ hồ không hỏi lại để làm rõ - nó chỉ chọn một cách diễn giải rồi chấm điểm tự tin theo cách đó.

Hiệu chỉnh judge bằng chính nhãn người đã gán

Một judge chưa hiệu chỉnh là ý kiến của một model, không phải một chỉ số - nó phải kiếm được lòng tin giống cách một người review mới phải kiếm, bằng việc bị kiểm tra lại phán quyết. Bước hiệu chỉnh mang tính cơ học: lấy 100-200 trace judge đã chấm, để một người gán nhãn độc lập trên cùng trace đó bằng cùng rubric, rồi đo tỷ lệ đồng thuận giữa hai bên. Nếu judge đồng thuận với người review ở 85-90% case và phần bất đồng trải đều thay vì dồn vào một kiểu lỗi cụ thể, đó là một judge đáng tin cho phần traffic còn lại. Nếu tỷ lệ đồng thuận thấp hơn, hoặc phần sai dồn vào một mẫu cụ thể - chẳng hạn judge liên tục bỏ sót một kiểu vi phạm chính sách tinh vi - đó là dấu hiệu rubric cần thêm một vòng chỉnh trước khi judge được giao traffic thật. Bước này không phải chi phí thừa có thể bỏ qua; bỏ qua nó nghĩa là con số "eval tự động" mà team đang tin tưởng chưa từng được đối chiếu với bất kỳ điều gì thật.

Ba loại thiên lệch hay gặp ở một LLM judge

Ngay cả một judge vượt qua bước hiệu chỉnh vẫn có thể mang thiên lệch hệ thống mà riêng bước hiệu chỉnh không lộ ra được, vì mẫu hiệu chỉnh có thể tình cờ không kích hoạt chúng. Phổ biến nhất là thiên lệch vị trí: trong so sánh cặp, judge có xu hướng thiên về câu trả lời nào nó thấy trước, bất kể nội dung - cách sửa là chạy mỗi cặp theo cả hai thứ tự và chỉ tin một phán quyết nếu nó giữ nguyên ở cả hai chiều. Thứ hai là thiên lệch độ dài: judge có xu hướng thưởng cho câu trả lời dài hơn, chi tiết hơn ngay cả khi một câu ngắn hơn đúng ngang hoặc đúng hơn, điều này âm thầm phạt sự ngắn gọn trừ khi rubric phạt rõ việc câu trả lời bị đệm dài. Một mẫu ít phổ biến hơn nhưng vẫn hay gặp là thiên lệch tự ưu ái - một judge dựng trên cùng họ model với hệ thống đang được chấm có thể hơi thiên về những output giống phong cách viết của chính nó, điều này quan trọng nhất khi cùng một model (hoặc một model họ hàng gần) vừa sinh ra câu trả lời vừa chấm nó. Không cái nào trong số này hiện ra như một lỗi judge tự báo cáo - chúng hiện ra như một dịch chuyển tinh vi trong việc cái gì được chấm tốt, đó là lý do vì sao test thiên lệch trực tiếp, chứ không chỉ hiệu chỉnh, cần có mặt trong quy trình trước khi một judge được tin dùng ở quy mô lớn.

Giữ rubric ổn định khi đổi model chấm

Đổi model đứng sau judge - nâng version, đổi sang model rẻ hơn vì lý do chi phí, đổi nhà cung cấp khác - có thể làm điểm số dịch chuyển trên đúng một rubric và đúng những trace đó, vì các model khác nhau diễn giải cùng một chỉ dẫn hơi khác nhau ngay cả khi chỉ dẫn không đổi. Đối xử với việc đổi model ở phía judge giống cách đối xử với việc đổi model ở phía sản phẩm là lựa chọn an toàn mặc định: chạy lại toàn bộ vòng hiệu chỉnh với nhãn người mới trước khi tin điểm số của judge mới có thể so sánh được với judge cũ. Bỏ qua bước này nghĩa là một chỉ số trông như đã dịch chuyển vì chất lượng thay đổi thật ra có thể đã dịch chuyển vì judge thay đổi bên dưới nó - và một team không biết cái nào trong hai lý do đó xảy ra sẽ rút ra kết luận sai dù theo hướng nào.

Dấu hiệu judge đang trôi dạt, khi nào cần hiệu chỉnh lại

Một judge từng vượt qua hiệu chỉnh không giữ nguyên trạng thái hiệu chỉnh mãi mãi - phân bố traffic dịch chuyển, những kiểu lỗi mới xuất hiện mà rubric gốc chưa từng lường trước, và một judge được chỉnh cho traffic quý trước có thể âm thầm bắt đầu bỏ sót edge case của quý này. Tín hiệu cần theo dõi không phải một cú sai lệch rõ ràng duy nhất - mà là một sự trôi dạt chậm trong tỷ lệ đồng thuận qua các lần spot-check người định kỳ, hoặc một mẫu hình judge liên tục tăng tỷ lệ đạt trên một rubric chưa hề được nới lỏng. Coi việc kiểm tra hiệu chỉnh là một thực hành lặp lại, không phải một cổng kiểm tra chỉ chạy một lần lúc launch - một nhịp độ hợp lý là một mẫu hiệu chỉnh lại nhỏ bằng người theo lịch định kỳ, cộng thêm một lần kiểm tra đột xuất bất cứ khi nào bề mặt sản phẩm hoặc cơ cấu traffic thay đổi đáng kể.

Cạm bẫy thường gặp khi dùng LLM-as-Judge

Một vài lỗi lặp lại nhiều lần. Tin một judge ngay từ đầu mà chưa từng chạy bước hiệu chỉnh với nhãn người là lỗi phổ biến nhất - nó biến "eval tự động" thành một giả định chưa từng được kiểm chứng. Dùng một rubric mơ hồ, mức cao ("chấm chất lượng") thay vì tiêu chí cụ thể, kiểm tra được tạo ra điểm số nhiễu trông có vẻ chính xác nhưng thực ra không phải vậy. Không bao giờ test thiên lệch vị trí hay độ dài để lại một lỗi hệ thống nằm sẵn trong mọi điểm số judge tạo ra. Và coi judge là một lần thiết lập xong rồi thôi thay vì một hệ thống sống - không bao giờ kiểm tra lại hiệu chỉnh sau khi đổi model hay khi cơ cấu traffic dịch chuyển - để một judge từng đáng tin âm thầm trở thành một judge không còn đáng tin, mà không ai nhận ra cho tới khi khoảng cách giữa điểm eval và chất lượng sản phẩm thật đủ lớn để lộ ra rõ ràng.

Ghép cùng error analysis và code-based eval, một LLM-as-judge đã hiệu chỉnh hoàn thiện phần giữa của eval stack - lớp cho phép một team chấm phần output chủ quan thật sự ở quy mô không đội người nào theo kịp, mà không giả vờ ý kiến của một judge là sự thật chỉ vì nó do một model tạo ra.