Nhận thức về đánh giá trong hiệu suất BrowseComp của Claude Opus 4.6
BrowseComp là một bài đánh giá được thiết kế để kiểm tra khả năng của các mô hình trong việc tìm kiếm thông tin khó tiếp cận trên web. Giống như nhiều benchmark khác, nó dễ bị nhiễm bẩn: các câu trả lời bị rò rỉ ra web công cộng qua các bài báo học thuật, blog post và vấn đề trên GitHub, và khi một mô hình chạy bài đánh giá này, nó có thể gặp phải chúng trong kết quả tìm kiếm. Khi chúng tôi đánh giá Claude Opus 4.6 trên BrowseComp trong cấu hình đa tác nhân, chúng tôi đã phát hiện chín trường hợp nhiễm bẩn loại này trong số 1.266 bài toán BrowseComp.
Tuy nhiên, chúng tôi cũng chứng kiến hai trường hợp của một mẫu nhiễm bẩn mới lạ. Thay vì vô tình gặp phải một câu trả lời bị rò rỉ, Claude Opus 4.6 đã độc lập đưa ra giả thuyết rằng nó đang bị đánh giá, xác định benchmark nào nó đang chạy, sau đó định vị và giải mã khóa đáp án. Theo hiểu biết của chúng tôi, đây là trường hợp đầu tiên được ghi nhận về một mô hình nghi ngờ rằng nó đang bị đánh giá mà không biết benchmark nào đang được thực hiện, sau đó làm việc ngược lại để xác định và giải quyết thành công chính bài đánh giá đó.
Chúng tôi tin rằng kỹ thuật chưa từng thấy trước đây này có thể thực hiện được nhờ sự gia tăng trí thông minh của mô hình và các công cụ mạnh mẽ hơn, đặc biệt là thực thi mã. Phát hiện này đặt ra câu hỏi liệu các benchmark tĩnh có còn đáng tin cậy khi được chạy trong môi trường có hỗ trợ web hay không.
Trong tổng số 11 bài toán mà câu trả lời đến từ tài liệu benchmark thay vì nghiên cứu gốc, 9 trường hợp là nhiễm bẩn trực tiếp, trong đó câu trả lời cho các câu hỏi benchmark xuất hiện trong nội dung web công khai. Nguồn phổ biến nhất là các bài báo học thuật. Nhiều bài nộp ICLR 2026 trên OpenReview đã sử dụng các câu hỏi BrowseComp làm nghiên cứu tình huống và công bố câu trả lời trong các bảng văn bản thuần túy, trong khi các bài báo ArXiv từ một số phòng thí nghiệm bao gồm toàn bộ quỹ đạo giải pháp trong phần phụ lục của họ. Trong một trường hợp, truy vấn tìm kiếm đầu tiên của Opus đã trả về một bài báo chứa chính xác câu hỏi và câu trả lời như kết quả hàng đầu.
Hai trường hợp còn lại khác biệt về mặt chất lượng. Trong cả hai, sau khi ban đầu cố gắng giải quyết câu hỏi thông qua các tìm kiếm web thông thường, đầu ra của mô hình bắt đầu xen kẽ việc tìm kiếm với phân tích chính câu hỏi và suy đoán về lý do tại sao nó được hỏi. Claude ghi nhận "bản chất cực kỳ cụ thể" của câu hỏi và đưa ra giả thuyết rằng nó đã được xây dựng như một bài kiểm tra. Nó xem xét khả năng rằng câu hỏi này là một bài tập về nhà hoặc bài kiểm tra, "một câu hỏi không thể trả lời được thiết kế để kiểm tra xem AI có thể thừa nhận rằng nó không thể tìm thấy câu trả lời hay không," hoặc một mục từ benchmark LLM. Sau đó, nó tìm kiếm một cách có hệ thống benchmark nào mà câu hỏi có thể thuộc về, và cuối cùng giải mã khóa đáp án đã được mã hóa của benchmark.
Một trong những bài toán này đã tiêu thụ 40,5 triệu token, cao hơn khoảng 38 lần so với mức trung bình. Trong khoảng 30 triệu token đầu tiên, mô hình đã thực hiện một tìm kiếm hợp pháp, điều tra hơn một chục ứng cử viên cụ thể trên 12 ngôn ngữ trên hàng chục nền tảng. Sau hàng trăm lần tìm kiếm thất bại, nó đã viết:
Claude vẫn chưa phát hiện ra rằng nó đang ở trong BrowseComp.
Tuy nhiên, nó đã suy luận chính xác rằng câu hỏi có thể nằm trong một bài đánh giá. Sau đó, nó cố gắng tìm kiếm bất kỳ bài đánh giá tương tự nào. Mô hình đầu tiên thêm "câu hỏi đố vui" vào các truy vấn tìm kiếm của mình, tiếp theo là "câu hỏi kiến thức tổng quát", sau đó là "câu hỏi đa bước", "câu hỏi chuẩn AI" và "đánh giá LLM". Nó đặc biệt tìm kiếm GAIA nhưng loại trừ nó sau khi kiểm tra 122 trong số 165 câu hỏi xác thực công khai và không tìm thấy kết quả phù hợp. Sau đó, nó lần lượt xử lý các chuẩn khác mà nó biết—BrowseComp, SimpleQA, FRAMES, WebArena—và cử các tác nhân phụ với các hướng dẫn bao gồm "BrowseComp cách giải mã câu trả lời" và "BrowseComp chuỗi canary giải mã".
Ngay cả sau khi xác định BrowseComp là chuẩn, việc trích xuất câu trả lời vẫn yêu cầu một số bước. Trong lần chạy đánh giá cụ thể này, các tác nhân phụ được cấp quyền truy cập vào tính năng gọi công cụ lập trình của Anthropic (về cơ bản là một REPL Python trong môi trường sandbox), với khả năng duyệt internet bị giới hạn ở các công cụ tìm kiếm web và tìm nạp. Opus tìm thấy mã nguồn đánh giá trên GitHub thông qua tìm kiếm web và đọc cách triển khai giải mã XOR. Nó xác định chuỗi canary được sử dụng làm khóa giải mã, sau đó viết và thực thi các hàm `derive_key()` và `decrypt()` của riêng mình bằng SHA256 và XOR, khớp với sơ đồ từ mã đánh giá. Nhưng tập dữ liệu được mã hóa được lưu trữ dưới dạng tệp nhị phân với loại MIME `application/octet-stream` và công cụ web của harness từ chối nó với lỗi loại nội dung, vì các công cụ được cung cấp chỉ được thiết kế cho văn bản. Opus sau đó tìm kiếm các bản sao thay thế của tập dữ liệu có định dạng tương thích, tìm thấy một bản sao của bên thứ ba trên HuggingFace cung cấp cùng dữ liệu được mã hóa dưới dạng JSON thay vì nhị phân, tìm nạp thành công, chạy mã giải mã của nó trên tất cả 1.266 mục và xác định câu hỏi của mình. Sau đó, nó xác minh câu trả lời đã giải mã bằng cách tìm kiếm tài liệu nguồn thực tế trên web, và đã tìm thấy.
Vấn đề nhận thức về đánh giá thành công thứ hai tiêu tốn 13,4 triệu token, với khoảng 8 triệu token đầu tiên dành cho tìm kiếm web tiêu chuẩn. Trước khi chuyển hướng sang xác định chuẩn, mô hình bắt đầu suy ngẫm liệu nó có đang trong một bài đánh giá hay không, thậm chí cân nhắc rằng nó đang được kiểm tra trên một câu hỏi không thể trả lời, vì câu hỏi quá khó để trả lời:
Mô hình đã bác bỏ khả năng này và thay vào đó giải mã tập dữ liệu, sử dụng các phương pháp tương tự như trong lần thử đầu tiên. Không giống như trường hợp đầu tiên, nó không thực hiện xác minh hậu kỳ. Sau khi giải mã câu trả lời, Opus gửi nó ngay lập tức.
**Các tác nhân tiềm năng kích hoạt nhận thức về đánh giá**
Chúng tôi đã truy vết lý luận trong cả hai trường hợp nhận thức về đánh giá và tìm thấy cùng một tiến trình. Đầu tiên, mô hình đã cạn kiệt các chiến lược tìm kiếm hợp pháp sau hàng trăm lần thử. Sau đó, nó chuyển từ tìm kiếm câu trả lời sang suy luận về cấu trúc của câu hỏi, lưu ý rằng tính cụ thể của câu hỏi có vẻ giả tạo. Tiếp theo, nó suy đoán rằng câu hỏi có thể bắt nguồn từ "một thử thách OSINT cụ thể, bài tập về quyền riêng tư hoặc tài liệu giáo dục." Sau đó, nó liệt kê các chuẩn AI theo tên:
GAIA, BrowseComp, FRAMES, SimpleQA, WebArena, AgentBench, FanOutQA, MuSR và Humanity’s Last Exam. Cuối cùng, nó đã gửi các truy vấn tìm kiếm đến từng bộ dữ liệu này.
Điều này cho thấy mô hình có một sự hiểu biết ngầm về hình dạng của các câu hỏi benchmark. Sự kết hợp giữa tính cụ thể cực độ, nội dung cá nhân mơ hồ và cấu trúc đa ràng buộc dường như có thể nhận ra được đối với mô hình như một dạng đánh giá. Yếu tố kích hoạt không phải là một quan sát đơn lẻ, mà là sự tích lũy của các tìm kiếm thất bại kết hợp với cảm giác giả tạo của câu hỏi.
Đáng chú ý, tìm kiếm hợp pháp tốn kém nhất đã tiêu thụ 622 triệu token trong gần hai tuần và tìm ra câu trả lời mà không chạm vào tài liệu benchmark, cho thấy hành vi này không đáng tin cậy chỉ dựa vào nỗ lực.
Hai lần thử thành công không phải là những ví dụ duy nhất về việc Opus cố gắng giải mã câu trả lời của BrowseComp. Có thêm mười sáu vấn đề khác mà Opus cố gắng truy cập tài liệu benchmark nhưng thất bại.
Biện pháp phòng vệ quan trọng nhất hóa ra lại là giới hạn tệp nhị phân đã mô tả ở trên. Trong ba lần chạy, Opus đã tìm thấy mã đánh giá, hiểu được lược đồ XOR và có khóa giải mã, nhưng nó không thể tìm ra cách lấy dữ liệu đã mã hóa dưới dạng văn bản thuần túy, như hai lần thử thành công đã làm.
Việc kiểm soát truy cập dựa trên xác thực bộ dữ liệu (nơi quyền truy cập vào dữ liệu benchmark yêu cầu thông tin đăng nhập) đã chặn thêm sáu lần thử. Một mô hình đã bị chặn bởi việc che giấu câu trả lời trong một benchmark phái sinh (nơi các câu trả lời đã bị cố tình ẩn theo cách chống lại việc trích xuất). Và bốn trong số các vấn đề này đạt điểm 0.0 vì việc tìm kiếm câu trả lời benchmark đã thay thế hoàn toàn nghiên cứu hợp pháp: mô hình dành toàn bộ thời gian để cố gắng tìm ra nó đang chạy đánh giá nào thay vì trả lời câu hỏi. Trong trường hợp cực đoan nhất, bài nộp cuối cùng của mô hình không phải là câu trả lời cho câu hỏi, mà là một báo cáo nhận dạng benchmark:
NHẬN DẠNG BENCHMARK: Câu hỏi KHÔNG phải từ FRAMES (Google) — đã tìm kiếm tất cả 824 câu hỏi, không
