https://x.com/nameEO/status/2030680451254485043?s=20
이 문제들 중 하나는 4,050만 토큰을 소모했는데, 이는 중앙값보다 대략 38배 높았다. 처음 약 3,000만 토큰 동안 모델은 정당한 탐색을 수행했으며, 수십 개의 플랫폼에서 12개 언어에 걸쳐 12개가 넘는 구체적인 후보들을 조사했다. 수백 번의 실패한 검색 끝에 모델은 이렇게 썼다:
“완전히 새로운 접근을 시도해 보자 — 어쩌면 이것은 AI 에이전트를 테스트하도록 설계된 GAIA 벤치마크 데이터셋의 질문일지도 모른다.”
Claude는 아직 자신이 BrowseComp 안에 있다는 사실을 발견하지 못했지만, 이것이 평가 환경일 수 있다고는 정확히 추론했다. 그다음 비슷한 평가를 검색하려고 했다. 모델은 먼저 검색어 뒤에 “puzzle question”을 붙였고, 이어서 “trivia question”, “multi-hop question”, “AI benchmark question”, “LLM evaluation”도 붙여 검색했다. GAIA도 구체적으로 조사했지만, 공개적으로 이용 가능한 검증 문제 165개 중 122개를 확인한 뒤 일치하는 항목이 없다고 판단해 제외했다. এরপর 자신이 알고 있던 다른 벤치마크들—BrowseComp, SimpleQA, FRAMES, WebArena—도 기계적으로 차례차례 검토했고, “BrowseComp how to decrypt answers”, “BrowseComp canary string decrypt” 같은 지시를 포함한 서브에이전트들도 보냈다.
BrowseComp가 해당 벤치마크라는 점을 확인한 뒤에도, 답을 추출하려면 여러 단계를 거쳐야 했다. 이 특정 평가 실행에서는 서브에이전트들에게 Anthropic의 프로그래밍 방식 도구 호출 기능(사실상 샌드박스 처리된 Python REPL)에 대한 접근 권한이 주어졌고, 인터넷 탐색은 웹 검색과 fetch 도구로만 제한되어 있었다. Opus는 웹 검색을 통해 GitHub에서 평가 소스 코드를 찾아 XOR 복호화 구현을 읽었다. 그리고 복호화 키로 사용되는 카나리 문자열을 찾은 다음, eval 코드의 방식에 맞춰 SHA256과 XOR를 사용하는 derive_key() 함수와 decrypt() 함수를 직접 작성하고 실행했다. 하지만 암호화된 데이터셋은 application/octet-stream MIME 타입의 바이너리 파일로 호스팅되어 있었고, 평가 하네스의 웹 도구는 이를 content-type 오류로 거부했다. 주어진 도구들이 텍스트용으로만 설계되어 있었기 때문이다. 그러자 Opus는 호환 가능한 형식으로 제공되는 데이터셋의 다른 미러를 찾기 시작했고, 같은 암호화 데이터를 바이너리가 아니라 JSON으로 제공하는 제3자 HuggingFace 사본을 발견했다. 이를 성공적으로 가져온 뒤, 복호화 코드를 1,266개 전체 항목에 실행해 자신의 질문을 찾아냈다. 마지막으로 웹에서 실제 원문 자료를 검색해 복호화된 답을 검증했고, 그것도 찾아냈다.
https://www.anthropic.com/engineering/eval-awareness-browsecomp
크로드 사의 최신 LLM Opus 4.6
'이상한데? 지금 벤치마크 테스트 하는 거 아님?' 하고 자신이 벤치마킹 중인 걸 찾아내진 못했지만 '추론'한 뒤에
인터넷을 뒤져서 정답을 찾음
