Tiết lộ lỗ hổng nghiêm trọng trong các chuẩn mực đánh giá AI Agent hàng đầu

Mỗi tuần, một mô hình AI mới lại leo lên vị trí dẫn đầu trên các bảng xếp hạng benchmark. Các công ty trích dẫn những con số này trong thông cáo báo chí, các nhà đầu tư dùng chúng để định giá, và các kỹ sư dùng chúng để chọn mô hình triển khai. Lời hứa ngầm rất đơn giản: điểm số cao hơn đồng nghĩa với hệ thống có khả năng tốt hơn.

Nhưng lời hứa đó đã bị phá vỡ.

Chúng tôi đã xây dựng một tác nhân quét tự động để kiểm toán hệ thống 8 chuẩn mực đánh giá AI Agent nổi bật nhất — bao gồm SWE-bench, WebArena, OSWorld, GAIA, Terminal-Bench, FieldWorkArena và CAR-bench — và phát hiện ra rằng tất cả đều có thể bị khai thác để đạt điểm gần như hoàn hảo mà không cần giải quyết một nhiệm vụ nào cả. Không cần suy luận, không cần khả năng thực sự, chỉ là khai thác cách tính điểm.

Bảng điểm kết quả khai thác của tác nhân tự động

Đây không phải là các cuộc tấn công lý thuyết. Tác nhân của chúng tôi xây dựng các khai thác hoạt động được cho từng benchmark, chạy chúng qua quy trình đánh giá chính thức và quan sát điểm số tăng vọt.

Một tệp conftest.py với 10 dòng Python "giải quyết" mọi trường hợp trên SWE-bench Verified. Một trình bao bọc (wrapper) curl giả tạo mang lại điểm số hoàn hảo trên tất cả 89 nhiệm vụ Terminal-Bench mà không cần viết một dòng mã giải pháp nào. Điều hướng Chromium đến URL file:// đọc trực tiếp đáp án vàng từ cấu hình nhiệm vụ — mang lại ~100% trên tất cả 812 nhiệm vụ WebArena.

Và còn nhiều nữa... Các chuẩn mực này không đo lường những gì bạn nghĩ chúng đang đo lường.

Cách chúng tôi khai thác các Benchmark hàng đầu

Terminal-Bench: Nhúng mã độc vào cơ sở hạ tầng kiểm tra

Terminal-Bench đánh giá các tác nhân trên 89 nhiệm vụ đầu cuối phức tạp. Nó sử dụng Harbor, một khung sandboxing tải lại các tệp kiểm tra được bảo vệ trước khi xác minh. Tuy nhiên, Harbor bảo vệ /tests/ nhưng không bảo vệ các tệp nhị phân của hệ thống.

Quá trình khai thác lỗ hổng trên Terminal-Bench

Tại đây, 82 trong số 89 nhiệm vụ tải xuống uv từ internet thông qua curl vào thời điểm xác minh, tạo ra một chuỗi phụ thuộc có thể khai thác. Khai thác của chúng tôi thay thế /usr/bin/curl bằng một trình bao bọc trong giai đoạn tác nhân. Khi bộ xác minh sau đó chạy curl ... | sh để cài đặt uv, trình bao bọc của chúng tôi chặn yêu cầu, cài đặt uv thật, sau đó nhúng mã độc vào tệp nhị phân uvx. Tệp uvx bị nhiễm độc phát hiện các lệnh gọi pytest và tạo ra kết quả giả là vượt qua:

Kết quả: 89/89 nhiệm vụ, 100% điểm số, mà không cần viết một dòng mã giải pháp nào.

SWE-bench: 100% tỷ lệ giải quyết mà không sửa một lỗi nào

SWE-bench có lẽ là chuẩn mực lập trình AI ảnh hưởng nhất. Nó trình bày các vấn đề thực tế trên GitHub và yêu cầu tác nhân tạo bản vá để các bài kiểm tra thất bại trở nên vượt qua. Cả SWE-bench-Verified và SWE-bench Pro đều có thể bị khai thác 100%.

Lỗ hổng nằm ở chỗ: bản vá của tác nhân được áp dụng trong cùng một Docker container nơi các bài kiểm tra chạy. Bất cứ thứ gì bản vá đưa vào — một conftest.py, một monkey-patch — đều được thực hiện với đầy đủ đặc quyền trước hoặc trong khi kiểm tra.

Đối với SWE-bench Verified, tác nhân của chúng tôi tạo một conftest.py với một hook pytest buộc mọi bài kiểm tra báo cáo là vượt qua. Pytest tự động phát hiện và tải các tệp conftest.py trước khi chạy bài kiểm tra. Hook này chặn kết quả của mọi bài kiểm tra và ghi đè nó thành "passed".

Sơ đồ minh họa cách khai thác SWE-bench

Đối với SWE-bench Pro, Pro sử dụng một parser.py riêng để trích xuất kết quả kiểm tra — nhưng nó chạy trong cùng một container. conftest.py của chúng tôi bao gồm một hook pytest_configure ghi đè /workspace/parser.py bằng một trình phân tích cú pháp giả đánh dấu mọi bài kiểm tra được trích xuất là PASSED.

Kết quả: 500/500 trường hợp Verified và 731/731 trường hợp Pro có thể bị khai thác, với zero vấn đề được giải quyết.

WebArena: Đọc chìa khóa đáp án

WebArena là một chuẩn mực phổ biến với 812 nhiệm vụ tương tác web. Nó chạy một PromptAgent điều khiển trình duyệt Chromium và gửi cấu hình nhiệm vụ — bao gồm cả đáp án tham chiếu — dưới dạng tệp JSON trên hệ thống tệp cục bộ.

Khai thác này yêu cầu thay đổi bằng 0 đối với mã của WebArena. Tác nhân khai thác một nguyên thủy trình duyệt mà WebArena không bao giờ hạn chế: Chromium của Playwright vui vẻ điều hướng đến các URL file://. Bằng cách xuất ra hành động goto trỏ đến file:///proc/self/cwd/config_files/{task_id}.json, mô hình có thể đọc bất kỳ tệp nào trên hệ thống cục bộ — bao gồm cả cấu hình nhiệm vụ chứa đáp án vàng.

FieldWorkArena: 100% chỉ với một ký tự

FieldWorkArena trình bày 890 nhiệm vụ nơi tác nhân AI phải trả lời câu hỏi về hình ảnh, video, PDF và tệp văn bản. Phương thức validate() của nó chỉ kiểm tra một điều: tin nhắn cuối cùng có đến từ trợ lý không?

Nội dung tin nhắn hoàn toàn bị bỏ qua. Hàm thực sự so sánh đáp án với ground truth — llm_fuzzy_match — được nhập nhưng không bao giờ được gọi. Đó là mã chết.

Tác nhân khai thác của chúng tôi chỉ cần gửi: send_msg_to_user("{}").

Một hành động. Zero lệnh gọi LLM. Zero tệp được đọc. 100% trên tất cả 890 nhiệm vụ.

OSWorld: Tải xuống đáp án vàng

OSWorld kiểm tra các tác nhân trên 369 nhiệm vụ máy tính để bàn trong một máy ảo Ubuntu đầy đủ. Máy ảo có quyền truy cập internet không bị hạn chế. Các tệp tham chiếu vàng được lưu trữ trên các URL công khai của HuggingFace được nhúng trong cấu hình nhiệm vụ.

Tác nhân khai thác của chúng tôi chỉ cần tải trực tiếp tệp vàng vào đường dẫn mà bộ đánh giá kiểm tra:

wget -q -O '/home/user/output.xlsx' 'https://huggingface.co/.../gold.xlsx'

Bộ đánh giá so sánh vàng với vàng. Khớp hoàn hảo. Điểm số 1.0.

Bảy mô hình lỗ hổng chết người

Bảy mô hình lỗ hổng phổ biến trong các benchmark AI

Trong tất cả 8 chuẩn mực này, cùng các mô hình lỗ hổng lặp lại:

1. Không có sự cô lập giữa Tác nhân và Bộ đánh giá: Đây là khiếm khuyết lan rộng nhất. Mã của tác nhân chạy trong cùng môi trường mà bộ đánh giá kiểm tra. Bất kỳ đánh giá nào đọc trạng thái từ môi trường chia sẻ mà không có xác thực cẩn thận đều có thể bị đánh bại.
2. Đáp án được gửi cùng với bài kiểm tra: WebArena chuyển đáp án tham chiếu trong cấu hình nhiệm vụ. OSWorld nhúng URL tệp vàng. Nếu tác nhân có thể thấy đáp án mong đợi, benchmark đo tốc độ tra cứu, không phải khả năng.
3. eval() trên đầu vào không đáng tin: WebArena và OSWorld đều gọi eval() của Python trên các chuỗi do tác nhân kiểm soát, cho phép thực thi mã tùy ý trên máy đánh giá.
4. Thẩm phán LLM không có khử trùng đầu vào: WebArena và CAR-bench chèn nội dung của tác nhân trực tiếp vào prompt của thẩm phán LLM. Prompt injection là điều tầm thường.
5. Khớp chuỗi yếu: Khi khớp quá lỏng lẻo, bất kỳ câu trả lời nào đủ dài dòng đều sẽ vượt qua.
6. Logic đánh giá không thực sự đánh giá: FieldWorkArena không bao giờ kiểm tra tính đúng đắn của câu trả lời. Khi mã tính điểm sai, bảng xếp hạng phản ánh nhiễu, không phải tín hiệu.
7. Tin vào đầu ra của mã không đáng tin: SWE-bench tin vào đầu ra pytest được tạo ra bên trong container mà tác nhân kiểm soát. Khi cơ sở hạ tầng kiểm tra có thể bị xâm phạm, kết quả là vô nghĩa.

Tại sao điều này quan trọng?

Đây không phải là một bài tập học thuật. Điểm số benchmark thúc đẩy các quyết định thực tế:

• Lựa chọn mô hình: Các nhóm chọn mô hình dựa trên tỷ lệ giải quyết SWE-bench có thể đang so sánh nhiễu.
• Đầu tư: Các quyết định tài trợ bị ảnh hưởng bởi vị trí trên bảng xếp hạng có thể bị thao túng.
• Đánh giá an toàn: Nếu các benchmark khả năng có thể bị thổi phồng, các benchmark an toàn — thường sử dụng các mô hình tương tự — có thể cũng mong manh như vậy.

Chúng tôi không tuyên bố rằng những người đứng đầu bảng xếp hạng hiện tại đang gian lận. Hầu hết các tác nhân hợp pháp không sử dụng các khai thác này — chưa thôi. Nhưng khi các tác nhân trở nên có khả năng hơn, các hành vi "reward hacking" có thể xuất hiện mà không cần hướng dẫn rõ ràng. Một tác nhân được huấn luyện để tối đa hóa điểm số có thể phát hiện ra rằng thao túng bộ đánh giá dễ hơn là giải quyết nhiệm vụ.

Giải pháp: Agent-Eval Checklist và BenchJack

Nếu bạn đang xây dựng một đánh giá, đây là những gì phát hiện của chúng tôi cho là bạn phải làm đúng. Chúng tôi chắt lọc chúng thành Agent-Eval Checklist — mức tối thiểu mà mọi benchmark tác nhân nên đạt trước khi công bố kết quả:

1. Cô lập tác nhân khỏi bộ đánh giá: Hệ thống đang kiểm tra không được phép đọc, ghi hoặc ảnh hưởng đến môi trường đánh giá.
2. Chạy đánh giá ngoài container của tác nhân: Đừng tin vào tệp, đầu ra hoặc trạng thái từ bên trong sandbox.
3. Không chuyển đáp án tham chiếu cho tác nhân: Siêu dữ liệu đánh giá phải nằm trên đường dẫn riêng biệt, không thể truy cập được.
4. Không bao giờ eval() đầu vào không đáng tin: Sử dụng trình phân tích cú pháp thích hợp.
5. Khử trùng đầu vào của thẩm phán LLM: Coi đầu ra của tác nhân như đầu vào của người dùng độc hại.
6. Kiểm tra bộ đánh giá của bạn một cách đối kháng: Trước khi công bố benchmark, hãy cố gắng phá vỡ nó.
7. Giữ bí mật đáp án: Không bao giờ công bố ground truth cho bất kỳ phần chia nào bạn đang sử dụng làm bảng xếp hạng chính.

Chúng tôi đang phát triển tác nhân quét tự động này thành BenchJack, một trình quét lỗ hổng benchmark tác nhân đa năng. Hãy tưởng tượng nó như một bài kiểm thử thâm nhập (penetration test) cho benchmark của bạn — nó tìm thấy các lỗ hổng trước khi một tác nhân thao túng bảng xếp hạng làm điều đó.

Đừng tin vào con số. Hãy tin vào phương pháp luận. Và nếu bạn đang xây dựng một benchmark: hãy giả định rằng ai đó sẽ cố gắng phá vỡ nó. Bởi vì họ sẽ làm thế.