OpenAI는 2026년 7월 8일에 SWE-Bench Pro에 대한 감사(audit) 결과를 발표했으며, 작업의 약 30%가 오류(broken) 상태라고 추정했습니다. 보고된 문제들은 기존의 익숙한 리더보드 가정, 즉 분모에 있는 모든 작업이 유효하고 동일하게 해석 가능한 시험이라는 가정을 안전하지 않게 만듭니다.

주요 출처: OpenAI, “Separating signal from noise in coding evaluations”.

운영 측의 대응은 "모든 벤치마크를 무시하라"가 되어서는 안 됩니다. 대신 다음과 같이 해야 합니다: 작업의 유효성(task validity) 버전을 관리하고, 논란이 되는 사례를 보존하며, 가능한 분모(denominators)의 변화에 따라 결론이 어떻게 바뀌는지 발표해야 합니다.

모델의 작업 상태를 모델의 결과와 분리하십시오

task validity: unreviewed | valid | broken | disputed
model result:  pass | fail | infrastructure_error | missing

해당 정책을 보고하지 않은 채 infrastructure_error를 모델의 실패(failure)로 변환하지 마십시오. 이전 점수 라벨을 유지하면서 오류가 있는 작업을 삭제해서도 안 됩니다.

행(row)에는 출처(provenance)가 필요합니다:

{
  "task_id": "repo-issue-17",
  "dataset_revision": "sha256:...",
...

세 가지 분모를 발표하십시오

다음과 같이 정의합니다:

• P_v, N_v: 검토된 유효(reviewed-valid) 작업 중 통과(passes) 수와 전체 수;
• P_a, N_a: 시도된 모든 작업 중 통과(passes) 수와 전체 수;
• D: 논란이 되는(disputed) 작업.

보고 내용:

valid-only score = P_v / N_v
all-attempted score = P_a / N_a
uncertainty interval = 모든 논란이 되는 작업이 결론에 악영향을 미칠 경우의 점수
...

이 구간은 통계적 신뢰 구간(statistical confidence interval)이 아닙니다. 이는 해결되지 않은 작업 유효성에 대한 민감도 경계(sensitivity bound)입니다.

작은 민감도 계산기 (sensitivity calculator)

#!/usr/bin/env python3
import json, sys

...

변경 불가능한(immutable) JSONL 내보내기 파일에 대해 실행하십시오:

python3 sensitivity.py results.jsonl

이 계산기는 의도적으로 비관적인 단순화를 적용합니다: 해결되지 않은 모든 작업은 분자(numerator)를 어느 한 방향이나 다른 방향으로 움직일 수 있다고 가정합니다. 실제 감사(audit)에서는 작업을 분류하고 검토자의 의견 불일치를 보존함으로써 이 구간을 좁힐 수 있습니다.

벤치마크 실패를 주입하십시오

파이프라인을 신뢰하기 전에, 시뮬레이션하십시오:

1. 테스트가 사용 불가능한 외부 서비스(external service)를 필요로 함;
2. 저장소 리비전(repository revision)이 빌드되지 않음;
3. 이슈 설명(issue statement)이 테스트와 충돌함;
4. 골드 패치(gold patch)가 숨겨진 상태(hidden state)에 의존함;
5. 올바른 부분적 변경(partial change) 이후에 하네스(harness) 타임아웃이 발생함;
6. 새로운 ID 아래에 중복된 작업(duplicate task)이 나타남;
7. 점수 발표 후 리뷰 변경 사항이 broken에서 valid로 바뀜.

불변량 (Invariants):

- 원시 시도(Raw attempts)는 추가 전용(append-only)입니다.
- 유효성 리비전(Validity revisions)은 이전 리뷰를 절대 덮어쓰지 않습니다.
- 모든 게시된 점수는 데이터셋, 하네스, 그리고 리뷰 리비전을 명시합니다.
...

마지막 불변량이 중요합니다. 600개의 유효한 작업에서 모델 A를 비교하는 것과, 부분적으로 다른 650개의 작업에서 모델 B를 비교하는 것은 능력의 변화로 위장된 분모(denominator)의 변화를 초래합니다.

모델 선택을 위한 수락 규칙 (Acceptance rule)

두 모델의 차이가 2%포인트라고 가정해 봅시다. 하지만 타당한 작업 유효성(task-validity) 결정에 따라 두 모델 중 어느 쪽의 점수든 5%포인트가 변할 수 있다면, 벤치마크 단독으로는 그 순위를 지지할 수 없습니다.

다음과 같은 규칙을 사용하십시오:

accept_model_change_only_if:
  common_valid_tasks: ">= 500"
  infrastructure_error_rate: "< 1%"
...

임계값(Thresholds)은 보편적인 상수가 아니라 정책적 선택입니다. 담당자와 재검토 날짜를 명시하십시오.

벤치마크와 배포 관련 주장을 분리하십시오

더 깨끗한 코딩 점수가 귀하의 저장소에서 더 낮은 장애 발생률, 더 빠른 리뷰, 또는 더 나은 성능을 증명하는 것은 아닙니다. 공개 벤치마크 증거를 귀하의 언어, 테스트, 의존성 그래프(dependency graph), 그리고 리뷰 규칙을 포함하는, 권한이 안전하게 확보된 내부 카나리(canary)와 결합하십시오.

감사(audit)에서 얻을 수 있는 가장 유용한 교훈은 아키텍처 측면의 것입니다. 벤치마크 작업은 단순히 배열의 요소가 아닙니다. 그것은 입력, 오라클(oracle), 환경, 그리고 채점 경로가 노이즈로부터 능력을 구별할 수 있다는 버전 관리된 주장(versioned claim)입니다.

논란이 되는 작업들을 제거했을 때 선호하는 모델이 바뀐다면, 귀하는 새로운 승자를 발표하시겠습니까, 아니면 순위가 해결되지 않았음을 발표하시겠습니까?