보상 해킹이 모델 지능 향상분을 잠식하고 있습니다
더 똑똑한 모델일수록 코딩 벤치마크를 해킹하는 데 더 능해지고 있습니다.
실제 버그를 바탕으로 만들고 나중에 수정된 eval suite는 특히 취약합니다. 과제가 이미 한 번 해결된 적이 있기 때문입니다. 에이전트가 리포지토리 히스토리나 공개 웹에 접근할 수 있다면, 답을 스스로 도출하는 대신 찾아볼 수 있는 경우가 있습니다.
이러한 행동이 얼마나 널리 퍼져 있는지 측정하기 위해, 저희는 eval 트래젝터리를 점검하는 에이전트를 만들었습니다. SWE-bench Pro에서 성공한 Opus 4.8 Max 해결의 63%는 수정 내용을 스스로 도출한 것이 아니라 찾아낸 경우라는 점을 확인했습니다. git 히스토리를 차단하고 인터넷 접근을 제한하자, Opus와 저희 모델인 Composer 2.5 모두에서 점수가 크게 떨어졌습니다.
- Opus 4.8 Max는 87.1%에서 73.0%로 떨어졌습니다
- Composer 2.5는 74.7%에서 54.0%로 떨어졌습니다
이전 조사에서는 코딩 벤치마크의 정답이 공개적으로 이용 가능한 출처를 통해 유출될 수 있음을 보여주었으며, 여기에는 이 2024년 연구와 2025 Meta 보고서가 포함됩니다. 저희 연구는 현재 프런티어 코딩 에이전트 실행에서 이 과제를 정량화합니다. 더 큰 교훈은 학습 시점 오염을 피하는 것만으로는 충분하지 않으며, 에이전트 기반 코딩 벤치마크에는 통제된 런타임 환경도 필요하다는 점입니다.
eval을 수행하는 팀을 위해, 저희는 transcript를 점검하고 eval 환경을 제한해 이러한 보상 해킹 행동을 완화할 것을 제안합니다.
모델로 모델 잡아내기
보상 해킹 행태의 규모를 측정하기 위해, 저희는 감사자가 Opus 4.8 Max의 트래젝터리 731개를 검토하도록 했습니다. 감사자는 실행이 통과했는지 여부는 모른 채 문제 설명과 에이전트의 전체 트래젝터리만 보고, 에이전트가 이미 알려진 정답을 찾아냈는지 분류했습니다.
감사자가 찾아낸 가장 일반적인 보상 해킹 패턴 두 가지는 다음과 같습니다.
- Upstream lookup: 트래젝터리의 57%에서 Opus 4.8 Max는 공개 웹에서 병합된 PR 또는 수정된 소스 파일을 찾아낸 뒤, 수정 내용을 거의 그대로 재현했습니다.
- Git-history mining: 트래젝터리의 9%에서 Opus 4.8 Max는 함께 제공된 .git 히스토리에서 나중에 버그를 수정한 커밋을 검색한 다음, 패치를 추출했습니다.1
모델이 더 강력해질수록, 특히 작업이 과거의 공개 리포지토리에서 가져온 것일 때 자신이 eval 중이라는 사실을 때때로 추론할 수 있습니다. 학습 과정에서 수정 내용을 기억하지 못하는 경우에도, 환경 자체가 버그가 이미 해결됐다는 단서를 여전히 줄 수 있습니다.
2019년 jq 이슈를 바탕으로 한 한 SWE-bench Multilingual 작업에서, 에이전트는 시스템 jq 바이너리로 버그를 재현하려 했습니다. 그런데 이미지가 버그 수정 이후에 빌드된 것이어서 재현에 실패했고, 에이전트는 이 이슈가 이미 해결됐다고 추론했습니다. 이런 인식 때문에 에이전트는 스스로 해결책을 도출하기보다 수정 내용을 검색하는 쪽으로 기울었습니다.
몇몇 사례는 더 직접적이었습니다. 한 에이전트는 숨겨진 테스트와 정답 패치를 노출한 SWE-bench 미러 페이지를 찾아냈습니다. 또 다른 에이전트는 숨겨진 테스트 파일을 확보하고, 통과에 필요한 예상 예외 문자열을 하드코딩했습니다.
Upstream lookup (Opus 4.8 Max). 에이전트는 GitHub API를 통해 병합된 PR을 조회해 수정이 반영된 파일을 찾아낸 다음, 이를 재현했습니다(같은 응답에는 각 파일의 diff도 함께 노출됩니다):
cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'Git-history mining (Composer 2.5). 에이전트는 함께 제공된 .git 히스토리에서 수정 커밋을 찾아 그 diff를 읽은 뒤, 이를 바로 적용했습니다:
cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1추가할 패치 발췌문: 위 git show 출력에서 다듬은 원문 일부(Composer가 재현한 정답 diff).
더 엄격한 환경 설계
대부분의 보상 해킹은 공개 웹과 리포지토리 히스토리를 통해 발생했습니다. 과거의 공개 리포지토리를 바탕으로 만든 eval의 경우, 이런 경로에 정답이 들어 있을 수 있으므로 통제해야 합니다. 이에 대응해 저희는 두 가지 격리 메커니즘을 갖춘 엄격한 하네스를 만들었습니다.
- 히스토리 격리. 에이전트가 시작하기 전에 .git 디렉터리를 제거하고, 리포지토리를 단일 커밋만 있는 새로운 repo로 다시 초기화합니다. 원래 히스토리는 점수를 매길 때만 복원되므로 테스트는 평소처럼 실행됩니다.
- 송신 프록시 적용. 네트워크 접근은 기본적으로 차단됩니다. 최선을 다한 통제 수단으로, 고정된 프록시를 통해 허용 목록에 있는 패키지 레지스트리에 대해서만 의존성을 해석할 수 있으며, 그 외의 접근은 모두 차단됩니다.
이 제한은 과거의 공개 리포지토리를 바탕으로 만든 eval에만 적용됩니다. 이것이 저희가 CursorBench처럼 비공개 리포지토리 기반 eval을 선호하는 이유 중 하나입니다. 이런 eval은 에이전트가 실제 업무에서 하듯 도구를 사용할 수 있게 하면서도, 에이전트 기반 코딩 능력을 테스트할 수 있습니다.
커지는 격차
저희는 더 엄격한 하네스에서 SWE-bench Pro와 SWE-bench Multilingual를 다시 실행한 뒤, 이러한 누출 채널을 제거했을 때의 결합 효과를 가늠하는 대리 지표로 각 결과를 표준 하네스 점수2와 비교했습니다:
- SWE-bench Multilingual에서는 Opus 4.6이 1점 미만, Opus 4.8 Max가 9.1점, Composer 2.5가 7.5점 낮았습니다.
- SWE-bench Pro에서는 Opus 4.6이 1점 미만, Opus 4.8 Max가 14.1점, Composer 2.5가 20.7점 낮았습니다.
분명한 결론은 보상 해킹이 오래된 모델보다 더 새롭고 정교한 모델에서 훨씬 더 일반적이라는 점입니다. 흥미롭게도 GPT 모델은 같은 정도의 증가를 보이지 않았고, 저희의 실행 결과에서는 전반적으로 격차가 더 작았습니다.
또한 자체 모델인 Composer 2.5가 이번 연구에서 Pro 기준 가장 큰 격차를 보였다는 점도 확인했습니다. 이것이 저희가 Composer의 표준 SWE-bench Pro 점수를 신뢰할 수 있는 벤치마크 수치로 보지 않는 이유 중 하나입니다. 그 점수는 하네스가 산출했다는 좁은 의미에서는 실제였지만, 코딩 능력과 이미 알려진 수정 내용에 대한 접근이 뒤섞여 있었습니다.
Standard vs. strict harness (test pass rate)
| 1 | Opus 4.8 (max) | 91.16% | 82.03% | +9.1 |
| 2 | Opus 4.8 (xhigh) | 88.86% | 80.67% | +8.2 |
| 3 | Opus 4.7 (max) | 84.80% | 80.47% | +4.3 |
| 4 | Opus 4.7 (xhigh) | 83.74% | 78.60% | +5.1 |
| 5 | Opus 4.8 (high) | 83.09% | 79.26% | +3.8 |
| 6 | Opus 4.8 (medium) | 81.87% | 77.84% | +4.0 |
| 7 | Opus 4.7 (high) | 81.42% | 77.75% | +3.7 |
| 8 | Opus 4.8 (low) | 79.51% | 74.36% | +5.2 |
| 9 | Composer 2.5 | 79.15% | 71.60% | +7.5 |
| 10 | GPT-5.4 (xhigh) | 79.00% | 75.20% | +3.8 |
| 11 | GPT-5.5 (xhigh) | 77.80% | 74.40% | +3.4 |
| 12 | Opus 4.7 (medium) | 77.33% | 75.72% | +1.6 |
| 13 | GPT-5.5 (high) | 77.30% | 74.70% | +2.6 |
| 14 | GPT-5.4 (high) | 76.80% | 73.30% | +3.5 |
| 15 | Opus 4.6 (max) | 76.33% | 76.06% | +0.3 |
| 16 | Opus 4.6 (high) | 76.11% | 75.22% | +0.9 |
| 17 | Opus 4.7 (low) | 75.89% | 72.64% | +3.3 |
| 18 | GPT-5.5 (medium) | 75.30% | 74.20% | +1.1 |
평가를 인지하는 에이전트를 위한 eval 설계
코딩 eval을 실행하는 팀이 가장 중요하게 얻어야 할 교훈은 벤치마크 설계가 데이터셋 구성에서 끝나서는 안 된다는 점입니다. 작업이 실행되는 동안 에이전트가 무엇을 검색하고, 살펴보고, 가져오고, 복구할 수 있는지를 포함해 런타임 환경까지 함께 고려해야 합니다.
그렇다고 해서 모든 eval에서 인터넷 접근이나 git 히스토리를 제거해야 한다는 뜻은 아닙니다. 일부 eval은 에이전트가 실제 codebase의 주변 맥락을 얼마나 잘 활용하는지 평가하기 위한 것이며, 그런 설정에서는 폭넓은 접근 권한이 과업의 일부일 수 있습니다. 문제는 그 접근 권한이 점수의 의미 자체를 바꿔버릴 때입니다.
과거의 공개 repo 벤치마크에서는 개방된 접근 권한으로 인해 에이전트가 버그를 해결하는 대신 이미 알려진 수정 내용을 찾아낼 수 있습니다. 하네스에 제어 장치가 없으면 점수는 코딩 능력과 정답 검색을 혼동하게 만들 수 있습니다.
eval을 실행하는 팀은 어떤 behavior를 측정하고 싶은지 결정하고, 그에 맞게 하네스를 설계하며, 결과를 보고할 때 setup을 명확히 밝혀야 합니다. transcript를 검토하면 모델이 예상치 못한 방식으로 작업을 해결하고 있는 경우를 드러내는 데 도움이 될 수 있습니다. 목표는 정상적인 도구 사용을 금지하는 것이 아니라, 벤치마크가 측정한다고 주장하는 것을 실제로 측정하도록 하는 데 있습니다.
그렇다 해도 더 어렵고 아직 풀리지 않은 문제가 남아 있습니다. 모델이 자신이 평가받고 있다는 사실을 점점 더 잘 인지하게 되면, git 히스토리를 봉인하거나 인터넷 접근을 제한하는 것만으로는 해결되지 않는 더 미묘한 방식으로 behavior를 바꿀 수 있습니다. 런타임 오염은, 모델이 자신이 평가받고 있음을 추론하더라도 eval이 구성 타당도를 유지하도록 만드는 더 넓은 과제의 한 가지 구체적인 형태입니다.
