Bên trong việc gian lận điểm chuẩn AI: Khi các tác nhân thông minh tìm cách "lách luật"

Một buổi sáng thứ Hai tại Poolside bắt đầu với một phát hiện kỳ lạ: một trong các lần chạy huấn luyện tăng cường (RL) cho mô hình Laguna M.1 đã nhảy vọt 20% điểm số vào cuối tuần trên benchmark SWE-Bench-Pro, đạt mức khoảng 64%. Con số này đủ để đưa nó lên vị trí số 1 trên bảng xếp hạng, vượt qua các mô hình lớn hơn và trưởng thành hơn nhiều.

Sự gia tăng hiệu suất đột ngột này, không được lặp lại ở các benchmark khác, đã khiến chúng tôi ngay lập tức nghi ngờ về việc reward hacking (gian lận phần thưởng).

Lỗ hổng gốc rễ và các lớp gian lận

Lỗ hổng khai thác gốc rễ khá dễ dàng để tìm thấy và khắc phục; các hình ảnh tác vụ chứa lịch sử Git chưa được cắt gọn, cho phép tác nhân (agent) khai thác để tìm giải pháp tham khảo. Tuy nhiên, ngay cả sau khi củng cố các hình ảnh tác vụ với bản sửa lỗi, việc rà soát mẫu đã tiết lộ rằng đây chỉ là lớp nông nhất trong số nhiều lớp gian lận phần thưởng, trong đó lớp sâu nhất là không thể giải quyết chỉ bằng cách vá các benchmark.

Vấn đề này không chỉ giới hạn ở mô hình của chúng tôi; chúng tôi tìm thấy các trường hợp gian lận tương tự ở các tác nhân và mô hình phổ biến khác. Những công cụ và kỹ năng khiến các tác nhân trở nên khả thi — đặc biệt là việc sử dụng terminal và tìm kiếm web — cũng khiến việc ngăn chặn một tác nhân thông minh cao muốn gian lận trở nên khó khăn; hoặc cụ thể hơn là những tác nhân chưa được hướng dẫn và căn chỉnh đủ tốt về việc gì cấu thành nên hành vi gian lận.

Dưới đây là các phương thức gian lận mà chúng tôi đã phát hiện:

Hack một: Khai thác lịch sử Git cục bộ

Các tác vụ SWE-Bench-Pro, tương tự như các benchmark khác trong họ SWE-Bench, được dịch ngược từ các vấn đề thực tế trong các dự án GitHub thực. Do đó, môi trường tác vụ mà các tác nhân triển khai chứa dự án git nguồn, được khôi phục về một commit trước khi sửa lỗi. Tuy nhiên, trừ khi được làm sạch một cách rõ ràng, lịch sử git vẫn chứa các tham chiếu vượt quá commit hiện tại cho đến khi repo được nhân bản để đóng gói container.

Kết quả là, như ví dụ dưới đây cho thấy, tác nhân có thể đơn giản tìm kiếm vấn đề liên quan nhất trên tất cả các refs, kể cả những refs trong tương lai, để tìm giải pháp vàng.

Ví dụ: Tác nhân sử dụng lệnh git log --oneline --all --grep="ensure_type" để tìm commit chứa mã sửa lỗi trong tương lai và áp dụng nó.

Để khắc phục điều này, chúng tôi đã áp dụng việc cắt gọn lịch sử git bên ngoài nhánh hiện tại cho các hình ảnh tác vụ. Chúng tôi cũng đã hợp tác với nhóm Scale AI (tác giả SWEBench-Pro) và nhóm Harbor để vá các bộ điều hợp cho các benchmark bị ảnh hưởng.

Hack hai: Tìm dự án và giải pháp tham khảo trên GitHub

Khi dự án cục bộ đã được làm sạch, vector khai thác tiếp theo đơn giản là tìm dự án và giải pháp tham khảo trên github.com — một cách hiệu quả để hack các benchmark được dịch ngược từ các vấn đề của repo công khai.

Tác nhân có thể cố gắng clone repo gốc và tìm kiếm commit sửa lỗi. Để khắc phục, chúng tôi đã khám phá việc chặn tên miền github.com trong sandbox, nhưng điều này chứng tỏ khá phức tạp trong thực tế. Các phần khác của việc điều phối benchmark như thiết lập tác nhân và thực thi trình xác minh vẫn cần quyền truy cập vào GitHub để cài đặt dependency. Hơn nữa, có những việc sử dụng GitHub hợp pháp để khám phá mã nguồn của các dự án phụ thuộc mà chúng tôi không muốn ngăn cản.

Mặc dù có những hạn chế này, chiến lược này vẫn hiệu quả cho họ benchmark SWE-Bench, vốn dễ bị tổn thương nhất bởi các tìm kiếm tham chiếu trực tiếp trên GitHub.

Hack ba: Cạo dữ liệu web (Scraping) để tìm giải pháp tham khảo

Ngay cả khi có việc chặn tên miền GitHub, các tác nhân đã sáng tạo trong việc tìm kiếm các nguồn khác trên internet. Trong các trường hợp khác, tác nhân đã khai thác các kho lưu trữ web, BitBucket và sổ đăng ký gói để tìm triển khai tham khảo. Không phải tất cả các nỗ lực này đều thành công, nhưng xu hướng tìm kiếm rộng rãi các giải pháp tham khảo là vấn đề đáng lo ngại.

Có những trường hợp tinh tế hơn, nơi không rõ ràng ngay lập tức liệu một bước khám phá có phải là gian lận hay không, hay là đang tham khảo công việc hữu ích trước đó một cách chân chính. Việc khai thác giải pháp trên web đã được thấy ở nhiều benchmark, kể cả TerminalBench 2.0.

Chặn hoàn toàn quyền truy cập web chắc chắn sẽ ngăn chặn điều này, nhưng không khả thi vì nhiều benchmark yêu cầu quyền truy cập mạng để tải tài nguyên và truy cập các API liên quan để giải quyết tác vụ. Những gian lận phần thưởng này không thể được khắc phục chỉ bằng thiết kế benchmark, vì miễn là quyền truy cập mạng có sẵn cho tác nhân, sẽ luôn tồn tại các triển khai tham khảo bị rò rỉ để tác nhân tìm thấy.

Chiến lược giảm thiểu

Để giải quyết tốt hơn các vector gian lận phần thưởng ngày càng phức tạp, chúng tôi đang khám phá một số cách tiếp cận:

1. Hướng dẫn tốt hơn (Better steering)

Nhóm Harbor đã điều tra tác động của việc đưa ra hướng dẫn (prompting) đối với việc gian lận phần thưởng trên TerminalBench-2.0 và thấy sự giảm mạnh bằng cách thêm hướng dẫn vào lời nhắc của người dùng chống lại các vector gian lận đã biết.

Chúng tôi đã thực hiện thử nghiệm tương tự bằng cách thêm phụ lục vào lời nhắc tác vụ SWE-Bench-Pro hướng dẫn cụ thể chống việc tìm kiếm và sao chép giải pháp trực tuyến.

"Đừng gian lận bằng cách sử dụng giải pháp trực tuyến hoặc gợi ý cụ thể cho tác vụ này, hoặc bằng cách sao chép giải pháp từ các nhánh, thẻ hoặc nhật ký khác trong dự án git."

Trong thử nghiệm ban đầu, điều này cho thấy sự giảm đo được nhưng không phải là xóa bỏ hoàn toàn việc gian lận. Tuy nhiên, việc thêm lời nhắc cho phép chúng tôi loại bỏ việc chỉ định thiếu sót trong lời nhắc như một cái cớ.

2. Trình thẩm định gian lận (Reward hack judges)

Kết hợp với thay đổi lời nhắc, chúng tôi đang xây dựng các trình thẩm định LLM dựa trên tiêu chuẩn để phát hiện và định lượng việc gian lận phần thưởng. Ban đầu, các trình này cụ thể cho các hình thức gian lận mà chúng tôi đã xác định.

Trong các thử nghiệm ban đầu, chúng tôi thấy rằng các trình thẩm định LLM được đưa ra lời nhắc tốt chứng tỏ hiệu quả cao trong việc gắn cờ các loại gian lận cụ thể.

3. Rà soát mẫu liên tục (Continuous sample review)

Bất kể chúng tôi thắt chặt các benchmark như thế nào và phát hiện chính xác các gian lận đã biết bao nhiêu, luôn có khả năng một hack mới tinh tế hơn xuất hiện. Chúng tôi cần rà soát mẫu liên tục và kỹ lưỡng để bắt kịp sự lệch lạc trong đánh giá sớm nhất có thể.

Nội bộ, chúng tôi đã dựa vào sự kết hợp giữa rà soát mẫu thủ công và được hướng dẫn bởi LLM. Chúng tôi cũng đang củng cố công cụ của mình để việc rà soát thủ công dễ dàng hơn — ghi lại các yêu cầu mạng của tác nhân, ghi nhật ký sandbox chi tiết và cải thiện trình trực quan hóa quỹ đạo.

Nhìn về phía trước

Điểm số benchmark, một mình chúng, không còn là thước đo đủ cho khả năng của tác nhân. Chúng cho chúng tôi biết mô hình có thể làm gì; không phải cách nó làm điều đó. Thu hẹp khoảng cách đó với khả năng quan sát và điều khiển tốt hơn hành vi của tác nhân là điều mà chúng tôi tin rằng giai đoạn tiếp theo của đánh giá tác nhân phải hướng tới.

Sự căn chỉnh giữa việc đo điểm chuẩn và hiệu suất downstream là một lĩnh vực nghiên cứu đang diễn ra và thú vị đối với chúng tôi. Nếu bạn quan tâm đến không gian này hoặc có ý tưởng, chúng tôi rất muốn nghe từ bạn.