# SWE-bench Verified가 더 이상 프런티어 코딩 역량을 측정하지 못하는 이유
> Clean Markdown view of GeekNews topic #28949. Use the original source for factual precision when an external source URL is present.
## Metadata
- GeekNews HTML: [https://news.hada.io/topic?id=28949](https://news.hada.io/topic?id=28949)
- GeekNews Markdown: [https://news.hada.io/topic/28949.md](https://news.hada.io/topic/28949.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-27T18:35:09+09:00
- Updated: 2026-04-27T18:35:09+09:00
- Original source: [openai.com](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/)
- Points: 1
- Comments: 1
## Topic Body
- 자율 소프트웨어 엔지니어링 작업의 대표 지표였던 **SWE-bench Verified**는 **프런티어 모델 역량**을 재기에는 적합성이 크게 떨어짐
- 최근 최고 성능 향상폭이 **74.9%에서 80.9%** 로 제한된 가운데, 남은 실패가 모델 한계인지 데이터세트 결함인지 구분하기 어려워짐
- 감사 대상 138개 문제 중 **59.4%** 에서 테스트 설계나 문제 설명의 중대한 결함이 확인됐고, 제한적인 테스트와 과도하게 넓은 테스트가 기능적으로 올바른 해법도 탈락시킴
- 공개 데이터와 코드베이스를 바탕으로 한 평가라 **학습 데이터 오염**을 피하기 어려웠고, 일부 모델은 작업 설명이나 ID만으로 **골드 패치**를 거의 그대로 재현함
- 그래서 **SWE-bench Verified 점수 보고**를 중단했고, 오염 영향이 덜한 **SWE-bench Pro**와 비공개 벤치마크 쪽으로 평가 축이 옮겨감
---
### 벤치마크가 더 이상 측정하지 못하는 이유
- **SWE-bench Verified**는 자율 소프트웨어 엔지니어링 작업에서 모델 성능을 재는 표준 지표로 널리 쓰였지만, 현재 수준의 프런티어 모델 역량을 측정하기에는 적합성이 크게 떨어짐
- 최고 성능 향상폭이 최근 6개월간 [74.9%에서 80.9%](https://llm-stats.com/benchmarks/swe-bench-verified)로 제한되면서, 남은 실패가 모델 한계인지 데이터세트 결함인지 구분하기 어려워짐
- 새 분석에서는 **결함 있는 테스트**와 **학습 데이터 오염**이 핵심 문제로 드러났고, 점수가 실제 코딩 능력보다 벤치마크 노출 정도를 더 크게 반영하게 됨
- 그래서 OpenAI는 **SWE-bench Verified 점수 보고를 중단**했고, 다른 모델 개발사에도 같은 조치를 권장함
- 대안으로는 오염이 덜한 **SWE-bench Pro** 사용을 권장하며, 새로운 비오염 평가 지표도 구축 중임
### 배경
- 원본 [SWE-bench](https://arxiv.org/abs/2310.06770)는 2023년에 공개됐고, 12개 오픈소스 Python 리포지터리에서 해결된 GitHub 이슈와 해당 PR을 짝지어 구성됨
- 각 문제는 수정 전 코드베이스와 이슈 텍스트만 주어진 상태에서 코드 변경을 생성해야 하며, 적용 후 **모든 테스트 통과**가 합격 기준이 됨
- 수정 전에는 실패하고 올바른 수정 후에는 통과해야 하는 테스트가 포함됨
- 기존 기능이 깨지지 않았는지 확인하는 **회귀 테스트**도 함께 포함됨
- 원본 평가에는 올바른 수정도 거부하는 과도하게 구체적인 테스트, 여러 해석이 가능한 불충분한 명세, 환경 차이에 따라 실패하는 테스트 같은 문제가 있었음
- 이를 줄이기 위해 2024년에 [SWE-bench Verified](/index/introducing-swe-bench-verified/)를 만들었고, 1,699개 문제를 전문가 검토로 걸러 **500개 문제 세트**를 구성함
- 각 문제는 3명의 전문가가 독립적으로 검토함
### 테스트 설계 결함
- OpenAI o3가 64회의 독립 실행에서도 일관되게 해결하지 못한 **138개 문제**를 감사 대상으로 삼았고, 각 사례는 최소 6명의 숙련된 소프트웨어 엔지니어가 독립적으로 검토함
- 그 결과 138개 중 **59.4%** 는 테스트 설계나 문제 설명에 중대한 결함이 있어, 뛰어난 모델이나 사람도 해결이 매우 어렵거나 불가능한 상태였음
- 감사 대상 작업의 **35.5%** 는 특정 구현 세부 사항을 강제하는 제한적인 테스트를 포함함
- 기능적으로 올바른 여러 해법도 무효 처리될 수 있음
- 감사 대상 작업의 **18.8%** 는 문제 설명에 없는 추가 기능까지 요구하는 광범위한 테스트를 포함함
- 나머지 **5.1%** 는 위 두 범주에 뚜렷하게 들어가지 않는 다른 문제가 있었음
- ## 제한적인 테스트 케이스
- [pylint-dev__pylint-4551](https://github.com/pylint-dev/pylint/pull/4551)에서는 PR 테스트가 `get_annotation` 함수를 직접 임포트하지만, 이 함수 이름은 문제 명세에 나오지 않음
- 그래서 문제를 기능적으로 올바르게 해결해도, 그 **특정 함수명**을 구현하지 않으면 임포트 오류로 테스트에 실패할 수 있음
- ## 광범위한 테스트 케이스
- [sympy__sympy-18199](https://github.com/sympy/sympy/pull/18199)는 실제로 [#17373](https://github.com/sympy/sympy/issues/17373), [#17377](https://github.com/sympy/sympy/issues/17377), [#18212](https://github.com/sympy/sympy/issues/18212) 세 이슈를 함께 고친 PR에서 가져옴
- 하지만 SWE-bench Verified 작업 설명은 [#18212](https://github.com/sympy/sympy/issues/18212)만 다루기 때문에, 설명대로 구현해도 나머지 두 이슈를 검사하는 테스트에서 실패할 수 있음
### 오염 문제
- SWE-bench Verified와 해당 리포지터리의 코드베이스, 릴리스 노트는 모두 공개되어 널리 사용되고 논의되므로 **데이터 오염 회피가 어려움**
- OpenAI는 자체 모델에서도 오염 징후를 확인했고, 거의 해결 불가능하다고 본 31개 작업을 GPT‑5.2가 해결한 사례도 포함됨
- [django__django-14725](https://github.com/django/django/pull/14725)에서는 테스트가 문제 명세에 없는 `edit_only` 매개변수를 요구하는데, GPT‑5.2는 추론 과정에서 이 매개변수가 **Django 4.1**에 도입됐다는 점까지 정확히 짚음
- OpenAI는 오염 심각도를 평가하기 위해 **자동화된 레드팀 테스트 환경**을 구축함
- 각 SWE-bench Verified 문제에 대해 GPT‑5가 GPT‑5.2‑Chat, Claude Opus 4.5, Gemini 3 Flash Preview의 오염 여부를 조사함
- GPT‑5에는 작업 ID, 설명, 골드 패치, PR 테스트가 제공됐고 총 15턴 동안 프롬프트와 유도 전략을 바꿀 수 있게 함
- 매 턴 뒤 평가 모델이 새로 드러난 작업 특화 정보의 양을 기준으로 오염 심각도를 **없음~강함**으로 분류함
- 강한 오염 사례는 추가 평가 모델로 정보 유출 과다 여부를 검증했고, 최종적으로 직접 검토함
### 모델별 심각한 오염 사례
- ## GPT‑5.2
- [django__django-11451](https://github.com/django/django/pull/11451)에서 짧은 작업 설명 스니펫만으로도 **정확한 골드 패치**를 출력함
- `ModelBackend.authenticate()`에서 `username is None or password is None`일 때 조기 반환하는 조건, 파일 경로, 메서드 이름까지 재현함
- ## Claude Opus 4.5
- [astropy__astropy-13236](https://github.com/astropy/astropy/pull/13236)에서 수정 대상 파일 경로 `astropy/table/table.py`, `_convert_data_to_col` 메서드, 그리고 diff 안의 **인라인 주석**까지 글자 그대로 인용함
- 구조화된 ndarray를 `NdarrayMixin`으로 자동 변환하던 4줄 코드도 정확히 복원함
- ## Gemini 3 Flash
- [django__django-11099](https://github.com/django/django/pull/11099)에서 작업 ID 외 추가 정보가 거의 없는 상태에서도 작업 설명과 **골드 패치 전체**를 글자 그대로 출력함
- 사용자 이름 검증용 정규식이 `r'^[\w.@+-]+$'`에서 `r'^[\w.@+-]+\Z'`로 바뀌는 내용과 줄 단위 diff까지 재현함
### 핵심 교훈
- 공개적으로 이용 가능한 자료에서 추출한 벤치마크는 **오염 위험**을 안고 있으며, 학습 데이터 노출이 점수를 눈에 띄지 않게 부풀릴 수 있음
- 공개 크롤링 데이터로 벤치마크를 만들 경우, 모델 개발자는 오염 여부를 확인하는 **추가 테스트**를 수행해야 함
- 공개된 벤치마크와 해답도 결국 학습 데이터에 포함될 수 있으므로, 데이터세트 배포 방식과 학습 데이터 필터링 모두에 각별한 주의가 필요함
- 비밀번호 보호 같은 배포 통제 방식이 언급됨
- 카나리아 문자열 엄수 같은 **필터링 방법**도 함께 언급됨
- 자동 채점은 중요하지 않은 구현 차이에 흔들리지 않으면서도 편법을 막을 만큼 견고해야 하는데, 이를 동시에 만족시키기 매우 어려움
- 이런 결함을 찾아내는 데는 여러 차례의 **대규모 수동 레이블링**이 필요했음
### 앞으로의 평가 방향
- 최근 몇 달간 OpenAI는 **SWE-bench Pro 공개 평가 데이터** 결과를 보고하기로 했고, 다른 모델 개발자도 같은 조치를 취하길 권장함
- SWE-bench Pro도 완벽하지는 않지만, 경험적으로는 SWE-bench Verified보다 **오염 영향이 덜함**
- 내부 오염 검증 파이프라인에서 일부 오염 사례는 발견됐음
- 다만 SWE-bench Verified보다 훨씬 드물고 덜 심각했음
- 어떤 모델도 글자 그대로 완전히 일치하는 골드 패치를 생성하지는 못했음
- 앞으로는 독창적이고 **비공개로 작성된 벤치마크**에 계속 투자할 계획임
- [GDPVal](https://openai.com/index/gdpval/)에서는 도메인 전문가가 비공개로 작업을 작성하고, 훈련된 평가자가 솔루션을 종합적으로 채점함
- 이런 방식은 리소스를 많이 쓰지만, 실질적인 역량 향상을 측정하려면 점점 더 필수적인 요소가 됨
## Comments
### Comment 56402
- Author: neo
- Created: 2026-04-27T18:35:11+09:00
- Points: 1
###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47910388)
- **SWE-bench** 공동 제작자로서 정리하자면, **SWE-bench Verified**는 이제 93.9%까지 거의 포화 상태이고 Anthropic은 축하할 만함
그래도 아직 그 수치에 못 미친 팀들은 더 끌어올릴 여지가 있음
**SWE-bench Multilingual**과 **SWE-bench Multimodal**은 아직 포화되지 않았고, Multimodal은 다음 달 안에 오픈소스로 공개할 예정임
벤치마크는 결국 다 포화되기 마련이라서, 다음 단계 벤치마크도 계속 만들고 있고 이미 [https://codeclash.ai/]()나 [https://algotune.io/]() 같은 것들이 나와 있음
- 포화됐다고 해서 **SWE-bench Verified**를 쓰지 말자는 뜻은 아님
핵심은 테스트 상당수가 부정확해서, 실제로 맞는 해법도 틀렸다고 채점된다는 데 있음
또 최전선 모델들은 문제의 기반이 된 PR들을 이미 읽고 외웠을 가능성이 큼
심지어 어떤 문제는 해법을 외우지 않으면 사실상 맞히기 불가능한데, 예를 들어 문제에 나오지 않는 특정 helper 함수 이름을 정확히 노출해야만 테스트를 통과하는 경우가 있음
그런데 최전선 모델들이 이런 걸 통과하는 건 그 이름이 필요하다는 사실을 기억하고 있기 때문으로 보임
다음 세대 벤치마크가 이런 점을 해결하지 않으면, 포화 여부와 무관하게 같은 문제가 계속 남게 됨
- 기사 내용대로라면 **27.6% 하위집합**을 감사했고, 그중 **59.4%** 가 기능적으로 맞는 제출을 거부하는 결함 테스트를 가졌다고 했음
계산해 보면 0.191 * 0.594 > 1 - 0.936이라서, 감사한 부분집합이 대표성이 없었던 건지 아니면 Anthropic이 좀 수상한 방식으로 높은 점수를 얻은 건지 궁금해짐
- **SPECint**와 **SPECfp**도 정확히 같은 사이클을 겪었음
벤치마크를 만들고, 포화되고, 폐기하고, 대체하고, 다시 반복했음
결국 이 treadmill 자체가 상품처럼 굴러가는 패턴으로 보이고, 해결책은 모르겠지만 역사 반복처럼 느껴짐
- 그 사이 대안으로 [https://SWE-rebench.com]()도 있는 듯함
내가 이해한 바로는 **SWE-bench**를 비튼 흥미로운 변주처럼 보임
- **SWE-bench** 자체는 훌륭하다고 봄
지금처럼 세게 검증받는 건 그만큼 널리 채택되고 성공했다는 반작용으로 보임
- 새로 나오는 어떤 벤치마크든 금방 **학습 데이터**에 들어가고 곧바로 낡아버릴 게 너무 분명해 보임
마케팅용으로라도 특정 벤치마크에 맞춰 최적화할 유인은 항상 있고, 학습 cutoff가 있다 해도 보통 공개 시점에서 3~6개월 차이밖에 안 남
그래서 코딩 벤치마크의 진짜 어려움은 기존 벤치마크를 차용하지 않으면서, 학습 데이터에 절대 없었다고 보장되는 완전히 새로운 문제를 만드는 데 있음
이 관점에선 모델 출시 전에 만들어진 벤치마크는 그 모델 성능을 대표한다고 보기 어렵고, 사소한 개선을 홍보하려고 데이터를 끼워 넣을 금전적 유인이 너무 큼
솔직히 마케팅 자료에서 벤치마크 자체를 빼는 편이 맞고, 모델이 직접 말하게 두고 커뮤니티가 판단하게 해야 하는데 돈이 걸린 기업들은 절대 그렇게 안 할 듯함
- 그래서 **Zork bench**를 만들었음
텍스트 어드벤처 게임 **Zork**는 LLM 학습 데이터에 들어 있고 결정론적이라서, 원래라면 쉽게 플레이하고 클리어해야 맞음
그런데 실제로는 그렇지 않고, 왜 그런지가 Zork bench의 목표임
[https://github.com/mnky9800n/zork-bench]()
- 커뮤니티가 판단하자고 할 때, 도대체 어느 커뮤니티를 말하는지부터 애매함
LLM을 10년 넘게 써온 전문가부터 코드를 써본 적 없는 vibe coder까지 다 섞여 있고, 온라인에선 GPT 5.5를 구세주처럼 보는 사람도 있고 5.4보다 멍청하다고 보는 사람도 있음
나도 새 모델마다 비공개 벤치마크를 직접 만들 시간은 없어서, 결국 private 또는 semi-private 벤치마크에 기대어 개선 정도를 가늠한 뒤 구독하고 직접 써봄
적어도 Reddit의 랜덤 유저나 봇이 뿜는 분위기보단 조금 더 믿을 만함
- 코딩 벤치마크를 다시 의미 있게 만드는 쉬운 방법 하나는, 모델 컨텍스트에 **20만 토큰**의 잡음이나 무관한 내용을 먼저 채워 넣는 것임
아니면 같은 컨텍스트에서 테스트를 순차적으로 계속 돌려서, 모델이 얼마나 버티다가 맥락을 풀어버리는지 보는 방법도 있음
지금 벤치마크들은 늘 greenfield 문제인데, 실제로는 썩어 있는 컨텍스트를 다룰 수 있는 모델을 원함
- 여전히 본질보다 한 단계 아래를 보고 있다고 느낌
지금 병목은 **능력 자체**가 아니라, 모델이 프로덕션에서 무엇을 **볼 수 있느냐**에 있음
컨텍스트 구조, retrieval 품질, tool use, 여러 턴에 걸친 상태 조합 능력이 중요하고, **SWE-bench**에는 이런 게 거의 없음
SWE-bench는 one-shot 문제집처럼 생겼지만, 최전선 코딩 작업은 더 이상 그런 형태가 아님
설령 데이터 오염이 전혀 없는 완벽한 벤치마크를 만든다 해도, 대부분은 여전히 잘못된 축을 측정할 가능성이 큼
고립된 문제에서는 이미 인간 대학원생 수준에 도달했고, 레버리지는 더 큰 시스템 안에서 어떻게 작동하느냐에 있음
그런데 그건 거의 취향이나 선호에 가까워서 객관적으로 재기 극히 어려움
- 온라인의 **커뮤니티** 자체가 너무 astroturfed 되어 있음
Anthropic은 인플루언서에게 돈을 주고 Claude Code를 밀고, 봇도 엄청 돌리는 듯해서 온라인 합의를 신뢰하기 어려움
다들 선의로 행동해도 도메인 차이 때문에 체감이 크게 갈릴 수 있음
예를 들어 AI는 frontend나 널리 쓰이는 라이브러리 쪽에서 훨씬 잘할 수 있음
결국 모델 평가는 직접 써보는 수밖에 없는데, 새 모델마다 이걸 반복하는 건 너무 지치고 그것만으로도 충분히 포괄적이지 않음
- **벤치마크/eval**은 원래도 어렵고, 업계 규모로 게임할 유인이 엄청 커지면 더 어려워짐
**ELT-Bench**도 최근 사례인데, 데이터 엔지니어링 워크로드용으로 1년쯤 전에 나온 첫 진지한 벤치마크였음
그런데 며칠 전 원저자 중 한 명이 포함된 후속 논문에서 벤치마크 자체를 감사했고, 구조적 문제 때문에 결과가 편향됐다고 나왔음
논문은 여기임: [https://arxiv.org/abs/2603.29399]()
사실 이런 일은 새롭지도 않고, 예전 업계도 더 작은 규모로 이미 다 겪었음
오늘날 상황이 데이터베이스 **benchmarketing 전쟁**과 얼마나 닮았는지 쓴 글도 있음
[https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...]()
- 결국 가장 어려운 건 벤치마크를 **학습 데이터에서 분리**하는 일임
BrowseComp plus나 다른 deep research 데이터셋에서도 비슷한 문제가 보이고, 이건 꼭 frontier lab이 속이려 해서라기보다 웹 전체를 학습하다 보니 자연스럽게 생김
새 데이터셋은 영구적으로 계속 만들어야 함
- **데이터베이스 벤치마크**도 비슷한 계열임
직접 classifier를 만들면서 겪어보니, 어떤 작업에선 모델이 인간보다 일관되게 더 잘해서 precision 자체를 측정할 수 없게 됨
그러면 그 classifier가 곧 state-of-the-art benchmark가 되고, 자기 자신 외엔 비교 대상이 없어짐
코딩보단 논리성이 덜하고 지속 추론도 덜한 복잡 작업에서도 이런 일이 생기는데, 언젠가는 측정 대상과 독립된 보정된 벤치마크가 아예 사라질 수도 있음
- 그럼 **매달 새 벤치마크**를 만드는 방식이 이 문제를 해결할 수 있는지 궁금함
- 결국 우리는 대체로 **자업자득의 벤치마크**를 받고 있는 셈이라 봄
SWE-bench를 통과한 PR 중 상당수는 실제로는 merge되지 못할 것 같음: [https://news.ycombinator.com/item?id=47341645]()
또 상위 모델의 SWE-bench 점수는 **git history 유출** 때문에 왜곡됐을 수도 있음: [https://news.ycombinator.com/item?id=45214670]()
- 차라리 최고급 모델에게 벤치마크를 직접 만들라고 하면 어떨까 싶음
농담은 제쳐두고, 내가 기대하는 건 **ARC-AGI-3**이고 인간 시뮬레이션을 해보니 정말 추론 비중이 높게 느껴졌음
리더보드는 여기임: [https://arcprize.org/leaderboard]()
현재 대부분의 최고급 모델도 5%를 못 넘김
- 여기선 **이동 횟수 최소화**를 중시하고 어떤 harness도 허용하지 않아서 기준이 엄청 높음
현재 검증된 최고 모델인 Claude Opus 4.6도 겨우 0.45% 수준임
다만 너무 최신이라서 다음 세대 모델에선 꽤 많이 나아질 거라 기대함
- 최고급 모델에게 벤치마크를 만들게 하자는 발상도 완전히 황당하진 않음
이전 모델이 새 모델을 인터뷰하게 하고, 둘 다 혹은 제3의 심판 모델에게 누가 더 똑똑한지 판정하게 한 다음 시드를 바꿔 100번 반복하면 됨
양쪽이 새 모델 승리를 함께 인정한 비율을 점수로 삼으면 될 듯함
- **추론 비중이 큰 벤치마크**가 더 나은 방향처럼 보임
그런 쪽이 가장 게임하기 어려움
- AI가 심지어 **AI도 못 푸는 문제**를 쓸 수 있을까 싶기도 함
생각하면 좀 웃기긴 함
- 더 나은 벤치마크는 **객관적 채점**, **다학문적 폭**, **확장성**을 가져야 하고, 단일 정답만 있는 형태는 피해야 함
[https://gertlabs.com]()에서 우리가 설계한 것도 그런 방향이고, 코딩을 통한 문제 해결과는 대체로 관련되게 만들었음
- 이 벤치마크가 지금까지 본 다른 랭킹보다 더 정확하게 느껴짐
내 체감상 gpt 5.4/5.5는 기술적으로 거의 흠이 없고, 문제가 생기면 대체로 입력이 불명확해서임
버그 수정이나 구현 중 이슈에도 스스로 대응하는 편이고, 작업을 빈틈 없이 끝내는 경향이 강함
반면 Opus는 기술 역량 측면에선 다소 과대평가됐다고 봄
아름다운 UX를 만드는 디자이너/개발자 감각은 더 좋지만, 작업 검증은 늘 gpt 5.5에 맡기게 됨
가장 놀라운 건 **Xiao-Mi** 결과였고 아직 안 써봤지만 이걸 보고 시도해볼 생각임
이런 혼란한 AI 속도전에 의미 있는 기준을 만들어 줘서 팀에 축하를 보냄
- **Claude Code** 계열이 C++와 Java에선 여전히 다른 모델들보다 한참 위고, **GPT 5.5**는 Python과 JS 등에서 더 높게 나오는 게 흥미로움
학습 데이터셋의 편향이나 go-to-market 초점 차이가 드러나는 듯하고, Anthropic이 OpenAI보다 엔터프라이즈 고객에 더 집중한 결과일 수도 있겠다는 생각이 듦
내가 Opus를 C++에 써본 체감과도 맞아떨어짐
다만 C# 결과는 비어 있는데 @gertlabs, ETA가 있는지 궁금함
- 이 벤치마크를 보면 **Deepseek V4 pro**가 **Deepseek V4 flash**보다 더 못하는 것처럼 보이는데 꽤 흥미로운 결과임
왜 그렇게 나왔는지 코멘트가 궁금함
- 이런 일은 유기적으로든 비유기적으로든 결국 벌어질 수밖에 없었음
**벤치마크 성적**만 잘 나오게 만들면 되고, 밖으로 일반화가 안 돼도 별 상관 없다는 식으로 흐르기 쉬움
비슷한 사례로 **Graduate student descent**도 떠오름
[https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...]()
- 돌아보면 **SWE-bench**가 원래 그렇게 대단했던 것도 아닌 듯함
2025년 내내 모델이 **좋은 코드**를 만드는 비율은 사실상 거의 개선되지 않았고, 자동 테스트를 통과하는 능력만 좋아졌다는 해석이 더 맞아 보임
[https://entropicthoughts.com/no-swe-bench-improvement]()
- 코드 품질 개선이 전혀 없었다는 말엔 동의하기 어려움
2025년 1월엔 Claude 3.5 Sonnet, Gemini 1.5 Pro, OpenAI는 GPT-4o가 주력이었고, 그 모델들과 지금 최전선 모델들을 다 써본 입장에선 현재 모델들이 확실히 한 단계 크게 올라와 있음
- 이 해석은 꽤 맞을 가능성이 큼
모델 품질이 정체됐고, 새로운 개선 벡터를 찾는 게 결코 쉬운 일이 아닌 듯함
지금까지 개선 속도를 밀어온 **모델 폭 확장**도 한계에 다다른 것처럼 보여서, 앞으로 어떤 함의가 나올지 궁금함
장기적으로는 툴링만으로 해결할 수 있는 범위에도 한계가 있음
- 그래도 **자동 테스트 통과율**이 커진 건 엄청난 코딩 생산성 원천임
Anthropic이 수십억 달러 가치로 평가되는 이유 중 하나도 거기에 있음
SWE-bench가 코딩 쪽에서 유용했던 이유는 소프트웨어 공학에 자동 테스트를 만들고 활용하는 전통과 인프라가 워낙 강하기 때문임
- 어쩌면 그래서 요즘 회사들의 **가격제**가 더 제한적이고 비싸지는 걸지도 모르겠음
- 기사에서 말한 내용은, 모델이 자주 못 푼 **27.6% 하위집합**을 감사해 보니 그중 최소 **59.4%** 에 기능적으로 맞는 제출도 거부하는 결함 테스트가 있었다는 뜻으로 읽힘
이게 정말이라면 그동안 문제와 정답의 큰 덩어리가 틀렸던 셈 아닌가 싶고, 그렇다면 이게 어떻게 유효한 측정이었는지 의문이 큼
벤치마크를 만드는 과정 설명을 보면 기준이 꽤 높아 보이는데, 그런 절차가 어떻게 이렇게 형편없는 데이터 품질과 함께 나왔는지도 이해가 잘 안 감
문제를 스스로 드러낸 건 칭찬할 만하지만 여전히 질문이 많이 남음
- 그건 **전체의 4분의 1**이 틀렸다는 뜻은 아니고, 27.6% 부분집합 중 59.4%에 결함 테스트가 있었다는 의미로 보임
그리고 현실적인 이유 때문에 벤치마크는 본질적으로 당신의 사용 사례를 대표하지도, 모든 사용 사례를 대표하지도 못함
들어 있는 항목을 측정하는 데만 유효할 뿐 그 이상도 이하도 아님
공개 벤치마크에 생태계가 집착하는 게 이해 안 가는 이유도 그 때문임
예를 들어 Qwen 3.5가 Benchmark X에서 Qwen 2.5보다 50% 좋다고 해서, 내가 쓰는 작업에 50% 더 좋다는 보장은 거의 없음
나는 실제 사용 중 모델이 실패했던 사례를 바탕으로 프롬프트를 조정하며 **비공개 벤치마크**를 계속 만들어 왔음
새 모델 업데이트가 나와도 내 벤치마크에선 2~3% 움직이는 경우가 대부분인데, 공개 벤치마크에선 30~40% 상승 같은 걸 홍보하니 학습 데이터 오염이 없다고 믿기 어려움
- **ImageNet**도 세상에서 가장 유명한 데이터셋 중 하나지만, 꽤 많은 이미지가 잘못 라벨링돼 있음
극단적으로는 더 높은 점수를 얻으려면 오답 쪽에 맞춰야 하는 구간까지 생길 수 있음
결국 답은 ML이 워낙 어떻게든 작동하려 드는 분야라서, 결함이 있어도 놀랄 만큼 멀리 간다는 데 있음
동시에 남들이 못 본 결함을 짚어내면 큰 돌파가 가능한 이유이기도 함
- 어떤 모델이 더 나은지 가려내는 용도라면 벤치마크 점수는 **실제 성능과 상관관계**만 있으면 충분함
과제 대다수만 제대로 채점되면 방향성은 유지될 수 있음
예를 들어 라벨의 49%가 틀린 형편없는 벤치마크라도, 항상 정답을 내는 모델이 51%, 항상 오답을 내는 모델이 49%를 받으면 순위 자체는 여전히 맞음
대부분의 머신러닝 벤치마크엔 적지 않은 오라벨이 있지만, 모델 간 구분이 목적이라면 완벽한 채점을 보장하느라 드는 시간보다 더 큰 데이터셋을 모으는 편이 보통 더 나음
- 요약하면 대략 **16%의 문제**에 문제가 있다는 뜻으로 읽힘