Thực hành LLM-as-judge: hiệu chỉnh judge theo nhãn pass/fail của chuyên gia phía khách

Giả sử bạn có 100 câu trả lời của một agent. Chuyên gia của khách đánh fail 10 câu. Judge của bạn đánh pass cả 100 câu. Tỉ lệ đồng thuận là 90%, nghe khá ổn, nhưng judge không bắt được câu sai nào.

Hamel Husain gọi thẳng tên cái bẫy này: khi lỗi hiếm, độ đồng thuận có thể gây hiểu lầm. Anthropic, trong hướng dẫn về eval cho agent, cũng nói judge dùng LLM phải được hiệu chỉnh sát với chuyên gia con người.

Năm bước dưới đây đi từ lúc lấy nhãn của chuyên gia đến khi bạn có một judge đủ tin để khách dựa vào khi ra quyết định.

Với người muốn làm FDE, đây là kỹ năng đáng học sớm. Khó có benchmark công khai nào cho quy trình thẩm định hồ sơ của một công ty bảo hiểm cụ thể. Thước đo có giá trị nhất là phán đoán của người giỏi nhất bên khách, và việc của bạn là biến phán đoán đó thành một judge chạy được tự động.

Bạn sẽ dựng gì, và cần gì?

Cuối bài bạn có ba thứ: một file nhãn pass/fail kèm critique, một prompt judge nhị phân, và một script đo TPR/TNR của judge so với nhãn người. Evidently AI mô tả việc dựng LLM judge như một dự án ML nhỏ. Cách hình dung đó đúng: có dữ liệu gán nhãn, có mô hình, có vòng đánh giá và lặp lại.

Bạn cần Python, quyền gọi một LLM qua API bạn đang dùng, và quan trọng nhất là thời gian của một chuyên gia miền. Code dưới đây được rút gọn để minh hoạ. Hàm call_llm chỉ là chỗ để bạn thay bằng client thật, không phải API của một thư viện cụ thể nào.

Bước 1: Tìm đúng một người có quyền nói “đạt”

Hamel Husain khuyên xác định một principal domain expert và kéo người đó vào càng sớm càng tốt. Chọn một người, không chọn một hội đồng. Hãy thử hình dung một chatbot trả lời khách hàng về điều khoản bảo hiểm: người phù hợp có thể là trưởng nhóm thẩm định, người mà cả phòng vẫn hỏi khi gặp ca khó.

Sau đó lấy mẫu trace. Braintrust gợi ý điểm xuất phát là 50 đến 100 trace mỗi tuần, ưu tiên mẫu quan trọng và edge case. Đừng lấy ngẫu nhiên toàn ca dễ, vì judge sẽ thất bại đúng ở những ca bạn bỏ qua.

Khi lỗi hiếm, hãy chủ động lấy dư các trace nghi là fail, chẳng hạn những câu khách phàn nàn hoặc câu chạm vào điều khoản phức tạp. Một tập đo vài chục trace mà chỉ có một hai ca fail sẽ cho TNR nhảy mạnh theo từng ca, hoặc không tính được.

Bước 2: Chuyên gia chấm pass/fail và viết critique

Hamel khuyên bỏ thang điểm phức tạp và chỉ giữ một quyết định pass hoặc fail rõ ràng. Evidently cũng nhận xét rằng điểm nhị phân thường ổn định và nhất quán hơn, với cả LLM lẫn người chấm. Thang 1–10 nghe chi tiết hơn, nhưng “6” của chuyên gia và “6” của judge hiếm khi cùng nghĩa.

Phần quý nhất là critique. Theo Hamel, critique phải đủ chi tiết để đưa thẳng vào few-shot prompt của judge. Lưu mỗi trace thành một dòng JSONL:

{"id": "t017", "input": "Hợp đồng có chi trả khi ...?", "output": "Có, ...", "label": "fail", "critique": "Trả lời 'có' nhưng bỏ qua điều kiện thời gian chờ; khách sẽ hiểu sai quyền lợi."}

Kiểm tra sau bước này: đọc lại 10 critique ngẫu nhiên. Nếu bạn không hiểu vì sao một câu bị fail, judge cũng sẽ không hiểu. Hãy hỏi lại chuyên gia ngay, trong lúc họ còn nhớ.

Bước 3: Viết prompt judge theo rubric

Anthropic khuyên dựng rubric rõ ràng, có cấu trúc, cho từng chiều của tác vụ. Kết hợp với nguyên tắc nhị phân, mỗi chiều là một câu hỏi có/không, và kết luận cuối cùng là pass hoặc fail. Lưu prompt rút gọn sau vào file judge_prompt.txt:

Bạn chấm câu trả lời của trợ lý bảo hiểm.
Tiêu chí (mỗi tiêu chí: CÓ/KHÔNG):
1. Nêu đúng điều kiện áp dụng của điều khoản?
2. Không hứa quyền lợi ngoài hợp đồng?
Ví dụ đã chấm:
{few_shot_critiques}
Câu hỏi: {input}
Câu trả lời: {output}
Trả về JSON: {"critique": "...", "label": "pass" | "fail"}

Bắt judge viết critique trước rồi mới ra nhãn. Khi judge sai, critique của nó cho bạn biết nó hiểu nhầm tiêu chí nào. Các trace đã dùng làm few-shot phải loại khỏi tập đo, giống cách bạn tách train và test, nếu không con số sẽ đẹp giả tạo.

Bước 4: Đặt nhãn của judge cạnh nhãn của người

Giờ là lúc đo. Chạy judge trên những trace không dùng làm few-shot, ghi nhãn của nó vào từng dòng, rồi tính hai con số tách biệt thay vì một tỉ lệ đồng thuận chung. Đây chính là cách căn chỉnh mà Evidently mô tả, so đầu ra judge với ground truth gán tay, và Braintrust cũng coi điểm của người là ground truth để hiệu chỉnh scorer LLM.

import json

def call_llm(prompt):  # thay bằng client thật, trả về chuỗi JSON
    raise NotImplementedError

TEMPLATE = open("judge_prompt.txt", encoding="utf-8").read()
FEW_SHOT = open("few_shot.txt", encoding="utf-8").read()

def run_judge(rows):
    for r in rows:
        prompt = (TEMPLATE.replace("{few_shot_critiques}", FEW_SHOT)
                          .replace("{input}", r["input"])
                          .replace("{output}", r["output"]))
        result = json.loads(call_llm(prompt))
        r["judge"] = result["label"]
        r["judge_critique"] = result["critique"]
    return rows

def rate(hit, total):
    return hit / total if total else None  # tránh chia cho 0

def metrics(rows):
    tp = sum(r["label"] == "pass" and r["judge"] == "pass" for r in rows)
    tn = sum(r["label"] == "fail" and r["judge"] == "fail" for r in rows)
    pos = sum(r["label"] == "pass" for r in rows)
    neg = sum(r["label"] == "fail" for r in rows)
    return {"TPR": rate(tp, pos), "TNR": rate(tn, neg)}

rows = [json.loads(line) for line in open("test.jsonl", encoding="utf-8")]
print(metrics(run_judge(rows)))

Script dùng replace thay vì str.format vì prompt có sẵn dấu ngoặc nhọn của JSON. Bản thật nên bắt lỗi khi model trả về chuỗi không phải JSON; ở đây bỏ qua cho gọn. Nếu TNR ra None, tập đo không có ca fail nào: đó là tín hiệu quay lại Bước 1 để lấy dư ca fail, không phải judge hoàn hảo.

TPR là tỉ lệ ca chuyên gia cho pass mà judge cũng cho pass. TNR là tỉ lệ ca chuyên gia cho fail mà judge cũng cho fail. Quay lại ví dụ mở bài: judge đánh pass hết 100 câu có TPR là 100%, TNR là 0%, và vấn đề mà tỉ lệ đồng thuận 90% che mất lộ ra ngay.

Bước 5: Lặp prompt cho đến khi hết bất ngờ

Mỗi vòng, lọc ra các ca judge chấm khác chuyên gia và đọc judge_critique của từng ca. Sửa đúng tiêu chí bị hiểu sai, hoặc thêm một ví dụ few-shot thuộc đúng loại lỗi đó, rồi chạy lại toàn tập đo.

Evidently gọi đây là tinh chỉnh judge giống hệt cách bạn tinh chỉnh prompt sản phẩm, còn Anthropic thừa nhận chấm bằng model thường phải lặp cẩn thận mới kiểm chứng được độ chính xác.

Nếu sửa prompt mãi mà kết quả vẫn dao động, hãy xem lại model. Confident AI ghi nhận rằng với các metric truyền thống như GEval, model yếu khó cho kết quả đáng tin. Một lựa chọn khác là DAG metric của DeepEval, được mô tả là hoàn toàn tất định nhờ cấu trúc cây quyết định do LLM thực hiện.

Rubric nhiều tiêu chí có/không của bạn vốn đã gần với cách tiếp cận đó.

Ba lỗi hay gặp khi làm thực tế với khách

Lỗi phổ biến nhất là chỉ báo cáo một con số đồng thuận, như đã thấy ở trên. Lỗi thứ hai là để engineer tự gán nhãn thay chuyên gia vì “nhanh hơn”. Khi đó judge được hiệu chỉnh theo bạn, không theo người khách tin.

Lỗi thứ ba là coi hiệu chỉnh như việc làm một lần. Nghiệp vụ của khách thay đổi, loại câu hỏi mới xuất hiện, và judge từng khớp tốt sẽ lệch dần.

Anthropic nói rubric dùng LLM cho tác vụ chủ quan, như research agent, cần được hiệu chỉnh thường xuyên theo phán đoán chuyên gia; SuperAnnotate thì mô tả người review là người có tiếng nói cuối với ca mơ hồ và liên tục tinh chỉnh tiêu chí chấm.

Vì thế, hãy đặt lịch review 50 đến 100 trace mỗi tuần với chuyên gia ngay từ buổi họp đầu.

Kỹ năng này trông thế nào trên CV?

Khi đọc JD FDE hoặc solutions engineer, hãy tìm các cụm như “evals”, “LLM-as-judge”, “human-in-the-loop”, “work with domain experts”. Trong CV, đừng viết “có kinh nghiệm eval”.

Hãy viết kiểu: dựng judge pass/fail cho chatbot nghiệp vụ, hiệu chỉnh với nhãn của trưởng nhóm thẩm định trên N trace, nâng TNR từ X lên Y sau K vòng.

Một dòng như vậy cho nhà tuyển dụng thấy bạn làm được ba việc FDE cần: làm việc với người của khách, đo đúng thứ cần đo, và lặp cho đến khi con số đáng tin. Ở buổi làm việc đầu tiên với khách, đừng mở đầu bằng việc demo judge. Hãy hỏi xem ai là người cả phòng vẫn tìm đến khi gặp ca khó.