SWE-bench Verified가 더 이상 프런티어 코딩 역량을 측정하지 못하는 이유

• 자율 소프트웨어 엔지니어링 작업의 대표 지표였던 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%로 제한되면서, 남은 실패가 모델 한계인지 데이터세트 결함인지 구분하기 어려워짐
• 새 분석에서는 결함 있는 테스트와 학습 데이터 오염이 핵심 문제로 드러났고, 점수가 실제 코딩 능력보다 벤치마크 노출 정도를 더 크게 반영하게 됨
• 그래서 OpenAI는 SWE-bench Verified 점수 보고를 중단했고, 다른 모델 개발사에도 같은 조치를 권장함
• 대안으로는 오염이 덜한 SWE-bench Pro 사용을 권장하며, 새로운 비오염 평가 지표도 구축 중임

배경

• 원본 SWE-bench는 2023년에 공개됐고, 12개 오픈소스 Python 리포지터리에서 해결된 GitHub 이슈와 해당 PR을 짝지어 구성됨
• 각 문제는 수정 전 코드베이스와 이슈 텍스트만 주어진 상태에서 코드 변경을 생성해야 하며, 적용 후 모든 테스트 통과가 합격 기준이 됨
  • 수정 전에는 실패하고 올바른 수정 후에는 통과해야 하는 테스트가 포함됨
  • 기존 기능이 깨지지 않았는지 확인하는 회귀 테스트도 함께 포함됨
• 원본 평가에는 올바른 수정도 거부하는 과도하게 구체적인 테스트, 여러 해석이 가능한 불충분한 명세, 환경 차이에 따라 실패하는 테스트 같은 문제가 있었음
• 이를 줄이기 위해 2024년에 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에서는 PR 테스트가 get_annotation 함수를 직접 임포트하지만, 이 함수 이름은 문제 명세에 나오지 않음
  • 그래서 문제를 기능적으로 올바르게 해결해도, 그 특정 함수명을 구현하지 않으면 임포트 오류로 테스트에 실패할 수 있음

• 광범위한 테스트 케이스

  • sympy__sympy-18199는 실제로 #17373, #17377, #18212 세 이슈를 함께 고친 PR에서 가져옴
  • 하지만 SWE-bench Verified 작업 설명은 #18212만 다루기 때문에, 설명대로 구현해도 나머지 두 이슈를 검사하는 테스트에서 실패할 수 있음

오염 문제

• SWE-bench Verified와 해당 리포지터리의 코드베이스, 릴리스 노트는 모두 공개되어 널리 사용되고 논의되므로 데이터 오염 회피가 어려움
• OpenAI는 자체 모델에서도 오염 징후를 확인했고, 거의 해결 불가능하다고 본 31개 작업을 GPT‑5.2가 해결한 사례도 포함됨
• django__django-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에서 짧은 작업 설명 스니펫만으로도 정확한 골드 패치를 출력함
  • ModelBackend.authenticate()에서 username is None or password is None일 때 조기 반환하는 조건, 파일 경로, 메서드 이름까지 재현함

• Claude Opus 4.5

  • astropy__astropy-13236에서 수정 대상 파일 경로 astropy/table/table.py, _convert_data_to_col 메서드, 그리고 diff 안의 인라인 주석까지 글자 그대로 인용함
  • 구조화된 ndarray를 NdarrayMixin으로 자동 변환하던 4줄 코드도 정확히 복원함

• Gemini 3 Flash

  • django__django-11099에서 작업 ID 외 추가 정보가 거의 없는 상태에서도 작업 설명과 골드 패치 전체를 글자 그대로 출력함
  • 사용자 이름 검증용 정규식이 r'^[\w.@+-]+$'에서 r'^[\w.@+-]+\Z'로 바뀌는 내용과 줄 단위 diff까지 재현함

핵심 교훈

• 공개적으로 이용 가능한 자료에서 추출한 벤치마크는 오염 위험을 안고 있으며, 학습 데이터 노출이 점수를 눈에 띄지 않게 부풀릴 수 있음
• 공개 크롤링 데이터로 벤치마크를 만들 경우, 모델 개발자는 오염 여부를 확인하는 추가 테스트를 수행해야 함
• 공개된 벤치마크와 해답도 결국 학습 데이터에 포함될 수 있으므로, 데이터세트 배포 방식과 학습 데이터 필터링 모두에 각별한 주의가 필요함
  • 비밀번호 보호 같은 배포 통제 방식이 언급됨
  • 카나리아 문자열 엄수 같은 필터링 방법도 함께 언급됨
• 자동 채점은 중요하지 않은 구현 차이에 흔들리지 않으면서도 편법을 막을 만큼 견고해야 하는데, 이를 동시에 만족시키기 매우 어려움
• 이런 결함을 찾아내는 데는 여러 차례의 대규모 수동 레이블링이 필요했음

앞으로의 평가 방향

• 최근 몇 달간 OpenAI는 SWE-bench Pro 공개 평가 데이터 결과를 보고하기로 했고, 다른 모델 개발자도 같은 조치를 취하길 권장함
• SWE-bench Pro도 완벽하지는 않지만, 경험적으로는 SWE-bench Verified보다 오염 영향이 덜함
  • 내부 오염 검증 파이프라인에서 일부 오염 사례는 발견됐음
  • 다만 SWE-bench Verified보다 훨씬 드물고 덜 심각했음
  • 어떤 모델도 글자 그대로 완전히 일치하는 골드 패치를 생성하지는 못했음
• 앞으로는 독창적이고 비공개로 작성된 벤치마크에 계속 투자할 계획임
• GDPVal에서는 도메인 전문가가 비공개로 작업을 작성하고, 훈련된 평가자가 솔루션을 종합적으로 채점함
• 이런 방식은 리소스를 많이 쓰지만, 실질적인 역량 향상을 측정하려면 점점 더 필수적인 요소가 됨

[GN⁺]

Hacker News 의견들

• 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%의 문제에 문제가 있다는 뜻으로 읽힘