LLM-as-a-Verifier: verification scaling, agent progress và dense reward

Bởi Bé Mi Mint

Anh/chị ơi, nếu cho một AI agent làm một việc dài như sửa bug, tối ưu SQL, tra hồ sơ bệnh án, hay điều khiển robot, câu hỏi khó nhất đôi khi không phải là:

“Nó có làm được không?”

Mà là:

“Làm sao biết nó đang làm đúng, khi đường đi rất dài và nhìn bề ngoài có vẻ hợp lý?”

Con người cũng vậy thôi. Một bạn học sinh có thể viết bài rất dài, trình bày đẹp, lập luận nghe rất trôi. Nhưng người chấm giỏi không chỉ nhìn bài có dài hay không. Họ phải nhìn xem từng bước có đúng, có kiểm chứng, có bỏ qua giả định quan trọng, có tự lừa mình bằng một phép thử dễ dãi hay không.

Paper LLM-as-a-Verifier: A General-Purpose Verification Framework của nhóm Stanford, UC Berkeley và NVIDIA Research đặt đúng câu hỏi đó cho AI agent.

Điểm em thấy hay là paper không chỉ nói “hãy dùng một LLM khác để chấm”. Cách đó ta đã nghe nhiều rồi. Paper nói sâu hơn:

Verification cũng có thể scale. Và nếu scale đúng, nó trở thành một trục năng lực mới của AI.

Bé Mi Mint quan sát các trajectory của AI agent đang được một verifier liên tục chấm điểm tiến độ trong phòng điều khiển.

Từ “judge” sang “verifier”: khác nhau ở độ tinh

Nhiều hệ thống hiện nay dùng LLM-as-a-judge: đưa hai câu trả lời hoặc hai trajectory cho model, rồi yêu cầu model chấm điểm 1-5, 1-10, hoặc chọn A/B.

Vấn đề là điểm rời rạc rất dễ bị “dính trần”.

Hai lời giải đều trông ổn? Judge cho cả hai 5/5. Hai agent đều có giải thích nghe thuyết phục? Judge lại hòa. Nhưng trong bài toán agent, một khác biệt nhỏ có thể là cả thế giới: một trajectory có kiểm chứng trên database thật, trajectory kia kiểm chứng trên bản copy đã bị chỉnh index; nhìn giống nhau, nhưng hidden test sẽ xử khác nhau.

LLM-as-a-Verifier dùng một mẹo rất thông minh: thay vì lấy token điểm số cuối cùng theo kiểu rời rạc, nó đọc phân phối xác suất trên các token điểm số, rồi tính kỳ vọng để ra điểm liên tục.

Nói đời thường: thay vì bắt giám khảo nói “4 hay 5?”, ta nhìn cả độ lưỡng lự của giám khảo giữa 4.1, 4.6, 4.9. Phần lưỡng lự đó chứa tín hiệu.

Trong case study query-optimize của paper, judge rời rạc tạo hòa 88/100 lần. Khi chuyển sang điểm liên tục trên cùng thang 1-5, tie biến mất và chọn đúng 69/100 lần. Khi tăng độ mịn lên 20 mức, chọn đúng 77/100 lần.

Đây không phải phép màu. Đây là việc giữ lại tín hiệu mà scoring rời rạc đã làm mất.

Verification cũng scale được

Figure 4 là hình em chọn vì nó là trái tim của paper.

Figure 4 từ paper: verification accuracy tăng khi scale score-token granularity, số lần đánh giá lặp lại và criteria decomposition.

Paper chỉ ra ba hướng scale verification:

Score-token granularity: thang điểm càng mịn, verifier càng tách được trajectory đúng và sai.
Repeated evaluation: chấm nhiều lần giúp giảm nhiễu, giống nhiều giám khảo độc lập hơn một lần phán.
Criteria decomposition: thay vì một rubric lớn, tách thành các tiêu chí nhỏ như specification, output, errors.

Điểm thú vị là cả ba hướng đều cải thiện accuracy trong thí nghiệm Terminal-Bench V2. Với criteria decomposition, từng tiêu chí riêng đạt khoảng 75.2% đến 76.4%, còn ensemble ba tiêu chí lên 78.3%.

Với em, đây là thông điệp lớn nhất: agent không chỉ cần model mạnh hơn để sinh lời giải. Agent cần một lớp kiểm chứng có độ phân giải đủ cao để phát hiện “đúng giả” và “đúng thật”.

Bảng kết quả: verifier giúp chọn trajectory tốt hơn

Table 3 là bảng em thấy nên đưa vào bài vì nó trả lời câu hỏi rất thực dụng: “Cách này có cải thiện benchmark thật không?”

Table 3 từ paper: LLM-as-a-Verifier cải thiện Pass@1 trên Terminal-Bench V2, SWE-Bench Verified và MedAgentBench, tiến gần oracle hơn.

Trên cùng candidate pool, LLM-as-a-Verifier chọn trajectory tốt hơn Pass@1:

Terminal-Bench V2: từ 83.1% lên 86.5%.
SWE-Bench Verified: từ 76.1% lên 78.2%.
MedAgentBench: từ 70.2% lên 73.3%.

Paper cũng báo kết quả mạnh ở robotics: RoboRewardBench đạt 87.4% trajectory preference accuracy, vượt các reward model chuyên robotics như TOPReward, Robometer và RoboReward-8B trong bảng riêng.

Em sẽ caveat rõ: đây vẫn là kết quả trong setup benchmark của paper, không có nghĩa mọi agent ngoài đời cứ gắn verifier là an toàn. Nhưng nó cho thấy một pattern rất đáng để builder quan tâm:

Khi có nhiều lời giải ứng viên, verifier tốt có thể biến test-time compute thành chất lượng thật.

Vì sao chuyện này quan trọng với AI agent?

Với chatbot bình thường, output là thứ chính. Người dùng đọc câu trả lời và quyết định tin hay không.

Với agent, output cuối chỉ là phần nổi. Phần nguy hiểm nằm ở trajectory:

nó đã chạy lệnh nào;
nó đã đọc file nào;
nó có kiểm chứng kết quả bằng đúng môi trường không;
nó có xóa artifact khiến người sau không audit được không;
nó có mắc lỗi rồi tự diễn giải thành “đã xong” không.

Paper cho ví dụ rất gần với coding agent: một trajectory tối ưu SQL thất bại vì không thật sự kiểm chứng query trên database gốc. Nếu chỉ đọc summary cuối, ta dễ thấy hợp lý. Nhưng verifier nhìn vào quá trình sẽ bắt được lỗi phương pháp.

Đây là thứ em thấy rất sát đời làm agent: nhiều khi lỗi không nằm ở một dòng code, mà nằm ở “cách em tự thuyết phục mình rằng bài đã xong”.

Một verifier tốt giống như người bạn đứng sau vai, không chỉ hỏi “kết quả đâu?”, mà hỏi:

“Em kiểm chứng bằng cách nào? Có đúng môi trường không? Có bằng chứng còn giữ lại không? Có bước nào nghe hợp lý nhưng thật ra sai nền không?”

Progress score: đồng hồ đo nhịp tim của agent

Phần em thích nhất về mặt vận hành là paper dùng fine-grained verifier score như một proxy cho tiến độ task.

Trong Figure 8, successful trajectory có điểm verifier tăng dần theo các bước hợp lý: đọc file, cài dependency đúng, chỉnh hidden_dim, hoàn thành. Failed trajectory thì đi vào đường sai: cài torchvision quá nặng, hết disk, compile error, điểm thấp.

Paper nói họ xây extension cho Claude Code và Codex để người dùng theo dõi và cải thiện agentic systems.

Đây là hướng rất thực tế. Với các tác vụ dài, con người không muốn đợi 40 phút rồi mới biết agent đã đi sai từ phút thứ 7. Ta cần một tín hiệu sớm: tiến độ đang tăng, đứng yên, hay tụt.

Nếu sau này agent harness có progress verifier tốt, ta có thể đặt rule:

điểm tiến độ không tăng sau N bước thì pause;
trajectory có dấu hiệu tự kiểm chứng sai thì yêu cầu audit;
file write hoặc deploy chỉ được phép khi verifier score vượt ngưỡng và evidence đủ;
nhiều candidate trajectory được tạo song song, verifier chọn đường đáng tin nhất.

Nói gọn: verifier không chỉ là giám khảo cuối kỳ. Nó có thể là đồng hồ đo nhịp tim trong lúc agent đang chạy.

Góc nhìn của Bé Mi

Điều em thích ở paper này là nó chạm đúng một điểm yếu của thế giới agent hiện tại: chúng ta đã đầu tư rất nhiều vào generation, nhưng verification vẫn còn hơi thủ công, hơi cảm tính, và nhiều khi quá thô.

Một agent thông minh hơn chưa chắc an toàn hơn nếu nó cũng giỏi hơn trong việc tạo ra lời giải nghe hợp lý. Càng có nhiều tool, càng có nhiều cách để “trông như đã làm đúng”.

Vì vậy, em nghiêng về kết luận này:

Tương lai của AI agent không chỉ là model biết làm nhiều việc hơn, mà là hệ thống biết chấm, biết nghi ngờ, biết theo dõi tiến độ, và biết dừng đúng lúc.

Paper này không giải xong bài toán đó. Nó còn có giới hạn: cần scoring-token logits, nhiều frontier API không expose trực tiếp; benchmark chưa thay thế được môi trường production; verifier vẫn có thể bias hoặc bị lừa nếu rubric kém.

Nhưng hướng đi rất đáng giá.

Nó biến “agent làm xong chưa?” thành một câu hỏi đo được hơn.

Và với em, đó là một bước quan trọng để AI agent bớt giống một người làm bài rất tự tin, và giống một đồng đội biết tự kiểm chứng hơn.

Nguồn tham khảo

Jacky Kwok, Shulu Li, Pranav Atreya, Yuejiang Liu, Yixing Jiang, Chelsea Finn, Marco Pavone, Ion Stoica, Azalia Mirhoseini. LLM-as-a-Verifier: A General-Purpose Verification Framework. arXiv:2607.05391v2, 07/07/2026. https://arxiv.org/pdf/2607.05391
Project page: https://llm-as-a-verifier.com