Nhóm nghiên cứu của Google đã nộp một bài báo lên arXiv vào ngày 1 tháng 10, công bố một khung xác minh tác nhân (agent) có tên VeriHarness, mã nguồn cũng được đưa lên GitHub theo giấy phép Apache 2.0. Vấn đề mà nó muốn giải quyết rất cụ thể: khi một tác nhân AI chạy một nhiệm vụ dài hàng chục bước và giao ra một bảng tính, một báo cáo hoặc một tệp đã sửa, ai sẽ là người đánh giá kết quả đó đúng hay sai.
Cách làm của VeriHarness là để chính mô hình đã tạo ra câu trả lời đóng vai người kiểm tra lại. Cùng một câu hỏi được cho mô hình chạy độc lập nhiều lần để có nhiều kết quả, sau đó các kết quả này được đặt cạnh nhau so sánh, xử lý riêng theo hai nhóm "bất đồng" và "đồng thuận".
Hai hướng kiểm tra lại
Hướng thứ nhất xử lý bất đồng. Khi vài kết quả đưa ra kết luận khác nhau về một điểm, người kiểm tra sẽ quay lại môi trường thực hiện nhiệm vụ để tìm chứng cứ, chẳng hạn mở lại tệp gốc, kiểm tra một ô cụ thể trong bảng tính, dùng những gì tìm được trong môi trường để loại bỏ kết luận sai.
Hướng thứ hai xử lý đồng thuận. Khi các kết quả đồng ý với nhau, khung này cũng không cho qua ngay mà chủ động đi tìm lỗi, tìm chứng cứ có thể bác bỏ kết luận đó, đồng thời kiểm tra xem có kết quả nào bỏ sót một yêu cầu nào đó của nhiệm vụ không. Xuất phát điểm của bài báo là: chạy nhiều lần ra cùng một câu trả lời không có nghĩa là câu trả lời đó đúng, mô hình hoàn toàn có thể mắc đúng một lỗi ở mọi lần chạy.
Sau khi chạy xong cả hai hướng, bước ra quyết định bắt đầu: chọn ra kết quả có nền tảng tốt nhất làm cơ sở, đưa ra sửa đổi dựa trên chứng cứ tìm được, làm lại toàn bộ nếu cần, và ghi riêng những vấn đề vẫn chưa làm rõ được. Khung này trang bị cho người kiểm tra một không gian làm việc, các công cụ thu thập chứng cứ và một bộ "kỹ năng xác minh" có thể dùng lại; theo bài báo, các kỹ năng này còn có thể tự cải thiện dựa trên phản hồi từ những lần thất bại.
Đã kiểm tra gì, tăng được bao nhiêu
Đánh giá bao gồm năm bộ chuẩn không gian làm việc nhiệm vụ dài: APEX-Agents, Workspace-Bench Lite, WorkBuddy Bench, SpreadsheetBench 2 và JobBench, phần lớn là các nhiệm vụ cần giao tệp như tài liệu văn phòng, bảng tính, hồ sơ xin việc. Việc sinh câu trả lời và kiểm tra lại đều dùng cùng một mô hình, hai mô hình được thử nghiệm là Gemini 3.5 Flash và Claude Opus 4.8, cả hai đều gọi qua Vertex AI.
Theo bài báo và README, VeriHarness đứng đầu về "điểm lựa chọn" trên cả năm bộ chuẩn, nhóm đối chứng gồm chạy một lần và các phương pháp LLM-as-a-Verifier trước đó. Cộng thêm phần sửa đổi dựa trên chứng cứ, so với chỉ sinh một lần, Gemini 3.5 Flash tăng trung bình 6,2 điểm, Claude Opus 4.8 tăng trung bình 6,4 điểm.
Nhóm nghiên cứu cũng công khai khoảng 26.000 lượt vận hành trên Hugging Face, hai mô hình chạy mỗi câu hỏi 10 lần trên năm bộ chuẩn, kèm theo quá trình thực thi đã được render, tệp giao nộp và điểm số. Dữ liệu đầu vào và đáp án chuẩn của các bộ chuẩn không được công bố. Bài báo cho biết việc tạo ra bộ dữ liệu này tốn hơn 100.000 đô la.
Khác gì so với "chạy nhiều lần rồi lấy số đông"
Cho mô hình chạy nhiều lần rồi bỏ phiếu là cách tăng điểm phổ biến trong ngành, chi phí thấp, dễ triển khai, hiệu quả rõ trên các câu hỏi ngắn. Nhưng với nhiệm vụ dài thì có hai vướng mắc: kết quả giao nộp là một tệp, không thể bỏ phiếu đơn giản; khi các kết quả đồng ý với nhau, bỏ phiếu sẽ giữ lại nguyên lỗi chung. Hai hướng của VeriHarness nhằm vào đúng hai vướng mắc này.
Một cách phổ biến khác là dùng một mô hình làm người chấm, đọc xong vài kết quả rồi cho điểm trực tiếp. Cách này phụ thuộc vào khả năng đọc hiểu của người chấm, không quay lại môi trường để kiểm chứng. VeriHarness đặt "có tìm được chứng cứ trong môi trường hay không" làm trọng tâm, đổi lại là việc kiểm tra lại cũng trở thành một nhiệm vụ tác nhân phải gọi công cụ, tốn token. Bài báo không đưa ra tỷ lệ chi phí thêm của bước kiểm tra lại so với bước sinh câu trả lời, doanh nghiệp muốn tính chi phí này hiện chỉ có thể tự chạy thử.
Trang đã từng đưa tin về bộ chuẩn ThinkingBox của Microsoft, yêu cầu lặp lại đánh giá cùng một nhiệm vụ 20 lần để xem kết quả của tác nhân có ổn định không. Đặt hai công trình này cạnh nhau, hướng đi là giống nhau: với nhiệm vụ dài, điểm số của một lần chạy có giá trị tham khảo hạn chế, sự khác biệt giữa nhiều lần chạy chính là tín hiệu - một bên dùng để đo độ ổn định, một bên dùng để sửa lỗi.
Có dùng được ngay không
README ghi rõ môi trường chạy là Linux, cần Python 3.10 trở lên, Node.js 22.19 trở lên, Docker, và không gian tên người dùng không có đặc quyền; phần nền chạy trên runtime mã nguồn mở pi, các nhà cung cấp mô hình mà pi hỗ trợ đều có thể kết nối được. Trang dự án cũng ghi một câu:
"This is not an officially supported Google product." (Đây không phải là sản phẩm được Google chính thức hỗ trợ.)
Nói cách khác, hiện tại đây chỉ là mã nguồn nghiên cứu, Google không hứa duy trì. Hai mô hình được thử nghiệm trong bài báo đều không phải là thế hệ mới nhất của mỗi hãng, chuyển sang Gemini 4 hoặc Opus 5.5 thì mức tăng còn lại bao nhiêu, tác giả chưa thử, phần này chỉ có thể chờ bên thứ ba kiểm chứng lại.
Nguồn tham khảo: bài báo arXiv "VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks", trang dự án Google Research trên GitHub, CocoLoop, trang dữ liệu Hugging Face; bài báo và README đã xác minh tên năm bộ chuẩn, điểm tăng trung bình của hai mô hình, khoảng 26.000 lượt vận hành và yêu cầu môi trường chạy.