Skip to content
←

Split View: AI 코딩 모델 평가에서 신호와 잡음 가려내기 — SWE-bench가 흔들리는 이유

|

AI 코딩 모델 평가에서 신호와 잡음 가려내기 — SWE-bench가 흔들리는 이유

들어가며 — 리더보드는 왜 믿기 어려워졌나

코딩 모델의 SWE-bench 점수는 매주 갱신되는데, 정작 자기 코드베이스에 붙여 보면 순위와 체감이 어긋나는 경험은 흔합니다. 지금 GeekNews에서 도는 OpenAI 평가팀(Frontier Evals)의 글 "Separating signal from noise in coding evaluations" 는 이 괴리를 정면으로 다룹니다. 결론은 꽤 셉니다 — 가장 널리 쓰이는 코딩 벤치마크인 SWE-bench Verified 가 오염과 설계 결함으로 더 이상 의미 있는 신호를 주지 못한다 는 것입니다.

이건 "벤치마크는 원래 완벽하지 않다"는 흔한 면피가 아닙니다. 핵심은 신호(signal)와 잡음(noise)을 분리해서 보라 는 방법론입니다. 이 글은 그 프레임으로 코딩 평가를 다시 정리하고, 팀이 실제로 무엇을 해야 하는지까지 내려갑니다.

타이밍도 한몫합니다. 코딩 모델은 거의 매주 새로 나오고, 팀은 리더보드의 소수점 차이 하나로 실제 도입 결정을 내리는 일이 잦아졌습니다. 그 차이가 잡음이라면, 그 결정은 실험복을 입은 동전 던지기일 뿐입니다.

신호와 잡음이라는 두 축

Allen Institute for AI(Ai2)의 프레임이 정의를 가장 깔끔하게 잡아 줍니다.

  • 신호 는 벤치마크의 변별력 입니다 — 더 나은 모델과 더 못한 모델의 점수를 얼마나 벌려 놓는가. Ai2는 이를 "특정 규모에서 모델들이 흩어진 정도"로 측정합니다.
  • 잡음 은 같은 모델을 다시 돌렸을 때(또는 학습 체크포인트마다) 점수가 흔들리는 변동성 입니다.

좋은 벤치마크는 이 둘의 비율, 즉 신호 대 잡음 비(SNR) 가 높습니다. 흥미로운 건 크기가 답이 아니라는 점입니다. Ai2 실험에서 SNR이 높은 16개 MMLU 서브태스크만 쓴 쪽이 전체 57개를 쓴 쪽보다 나았고, 오류가 32% 줄었습니다. 채점 지표를 정답/오답 대신 bits-per-byte로 바꾸자 MBPP의 SNR이 2.0에서 41.8로 뛰기도 했습니다.

Ai2는 이 비율이 벤치마크의 크기보다 유용성을 더 잘 예측한다고 보고합니다 — SNR이 높은 지표로 바꾸자 두 모델 중 더 나은 쪽을 옳게 고르는 "결정 정확도"가 68%에서 93%로 올랐습니다. 작고 깨끗한 평가가 크고 시끄러운 평가보다 믿을 만할 수 있다는 것 — 대부분의 리더보드가 전제하지 않는 직관입니다.

실무로 옮기면 규칙은 하나입니다 — 두 점수를 비교할 때, 그 차이가 잡음보다 큰지부터 물어라. 순위표의 1위와 3위가 잡음 범위 안에 있다면, 그 순위는 정보가 아니라 착시입니다.

코딩 벤치마크의 잡음은 어디서 오는가

코딩 평가의 잡음은 크게 네 갈래에서 옵니다.

1) 오염(contamination). OpenAI 평가팀은 모델이 task_id 만으로 원본 gold patch나 문제 설명을 거의 그대로 재생산할 수 있음을 보였습니다. 이건 소프트웨어를 짜는 능력 이 아니라 학습 데이터를 암기 한 결과입니다. 점수는 오르지만 신호는 오르지 않습니다.

2) 채점 결함(design flaws). 같은 글은 SWE-bench Verified의 남은 미해결 문제 중 60% 이상이 채점 기준상 애초에 풀릴 수 없는 것이라고 지적합니다. 기능적으로 올바른 제출을 49개 테스트가 틀렸다고 판정하고, 26개 테스트는 문서에 없는 동작을 요구합니다. 모델이 맞혀도 0점이 나오는 구조입니다.

3) 하네스·인프라 차이. Anthropic은 모델 가중치를 하나도 바꾸지 않고 실행 환경만 조정해도 점수가 움직인다는 걸 측정했습니다. Terminal-Bench 2.0에서 자원을 가장 넉넉히 준 설정과 가장 빠듯하게 준 설정의 차이가 6%p(p < 0.01) 였고, 인프라 오류율은 5.8%에서 0.5%로 떨어졌습니다. 순위를 가르는 게 모델이 아니라 컨테이너 설정일 수 있다는 뜻입니다.

4) 벤치마크 과적합·마모. 새 벤치마크도 오래 못 갑니다. SWE-bench Verified를 개선하려고 나온 SWE-bench Pro 조차 독립 감사에서 자동 파이프라인 기준 27.4%, 사람 검수 기준 34.1%의 과제가 깨져 있었습니다. 게다가 같은 모델이 벤치마크만 바꿔도 크게 흔들립니다 — 한 보고에서는 동일 모델이 SWE-bench Verified에서 약 81%, 더 어려운 SWE-bench Pro에서는 약 46%를 기록했습니다.

불편한 지점은 이 효과들이 단조롭지 않다는 것입니다. Anthropic은 자원 여유를 적당히 바꾸는 정도로는 차이가 잡음 안에 머물렀지만(통계적으로 무의미, p = 0.40), 양 극단에서는 크게 벌어짐을 확인했습니다 — SWE-bench에서는 한 과제에 RAM을 5배 줘도 점수가 약 1.54%p 움직였을 뿐입니다. 같은 손잡이가 어떤 구간에서는 무시할 만하고 다른 구간에서는 결정적입니다. 하네스 차이가 눈앞에서 숨는 방식이 바로 이것입니다.

팀이 실제로 해야 할 일

리더보드는 모델 개발자에게는 신호일지 몰라도, 어시스턴트를 고르는 팀에게는 대부분 잡음입니다. 실무 지침은 이렇게 정리됩니다.

  • 자기 과제로 평가하라. 팀의 실제 PR·이슈 30~50개로 작은 프라이빗 평가 셋을 만드세요. 리더보드 1위보다 "우리 코드베이스에서의 통과율"이 훨씬 강한 신호입니다.
  • 순위가 아니라 신뢰구간을 봐라. Anthropic의 권고는 명확합니다 — 3%p 미만의 리더보드 차이는, 평가 설정이 문서화되고 서로 맞춰지기 전까지는 회의적으로 대하라.
  • 오염에 강한 설계를 골라라. 시간 컷오프를 굴리는 방식(LiveCodeBench)이나 비공개 테스트셋(GAIA)이 암기 점수를 구조적으로 막아 줍니다.
  • 하네스를 고정하고 문서화하라. 프롬프트·재시도·타임아웃·자원 한도를 명시하지 않은 비교는 사과와 오렌지를 견주는 것입니다.
  • 평가를 공개한다면 보정하라. Anthropic의 제안은 과제마다 자원의 하한과 상한을 함께 명시하고, 양 끝의 점수가 서로 잡음 범위 안에 들도록 맞추라는 것입니다 — 그러지 않으면 설정이 슬그머니 점수의 일부가 됩니다.
  • 여러 유형을 삼각측량하라. 정적 벤치마크, 사람 선호 아레나, 에이전트 스위트를 함께 보면 한 축의 잡음이 서로 상쇄됩니다.
  • 여러 번 돌려라. 단발 통과/실패 실행은 변동을 숨깁니다. 과제마다 3~5회 돌리면 점수의 폭이 보이고, 그 폭이 바로 당신이 꿰뚫어 봐야 할 잡음입니다.
  • 포화를 경계하라. 상위 모델들이 몇 점 안에 몰려 있으면 그 벤치마크는 이미 변별을 멈춘 것입니다 — 신호가 낮고, 그들 사이의 순서는 거의 무작위입니다.

구체적으로는 이렇게 합니다 — 스캐폴드를 하나로 고정하고(같은 프롬프트·같은 재시도 정책·같은 타임아웃), 각 모델을 프라이빗 과제 셋에서 여러 번 돌린 뒤 평균과 폭을 함께 보고하세요. 두 모델의 폭이 겹치면 승자는 없습니다 — 무승부이고, 그럴 땐 가격·지연·라이선스로 결정하는 편이 낫습니다.

이 모든 게 eval-first 원칙 으로 수렴합니다. 모델(또는 어시스턴트)보다 평가 셋이 먼저라는 것 — AI 모델 개발 생애주기 글에서 다룬 그 순서 그대로입니다. 평가가 먼저 있으면, 어떤 모델을 쓸지의 결정이 취향이 아니라 실험이 됩니다.

마치며

신호와 잡음을 가르는 일은 결국 겸손의 문제입니다. 리더보드 최상단의 소수점 몇 자리는 대체로 마케팅이고, 진짜 신호는 당신의 과제에서 재현되는 차이 입니다. OpenAI는 오염과 채점 결함에서, Anthropic은 인프라 변동에서, Ai2는 통계적 변별력에서 각자 출발했지만 도착점은 같습니다 — 숫자 하나를 믿지 말고, 그 숫자가 잡음보다 큰지를 물어라. 코딩 어시스턴트를 고르는 팀에게 이보다 실용적인 조언은 드뭅니다.

그렇다고 벤치마크가 쓸모없다는 뜻은 아닙니다 — 모델을 훈련하는 사람에게는 없어서는 안 될 도구입니다. 다만 리더보드는 질문의 출발점이지 답이 아니라는 것입니다.

참고 자료

Separating Signal from Noise When You Evaluate AI Coding Models — Why SWE-bench Got Shaky

Introduction — Why the Leaderboard Got Hard to Trust

A coding model's SWE-bench score updates every week, yet the moment you wire it into your own codebase the ranking and the felt experience often diverge. The OpenAI evals team (Frontier Evals) post trending on GeekNews right now, "Separating signal from noise in coding evaluations," takes that gap head on. The conclusion is blunt: SWE-bench Verified, the most widely used coding benchmark, no longer gives meaningful signal, thanks to contamination and design flaws.

This isn't the usual "no benchmark is perfect" shrug. The point is a method — separate signal from noise and look at each. This post reframes coding evaluation through that lens, then gets down to what teams should actually do.

The timing makes it matter. Coding models ship almost weekly, and teams increasingly make real procurement calls off a single leaderboard delta. If that delta is noise, the decision is a coin flip wearing a lab coat.

The Two Axes — Signal and Noise

The framework from the Allen Institute for AI (Ai2) gives the cleanest definitions.

  • Signal is a benchmark's discriminatory power — how far apart it pushes the scores of a better model and a worse one. Ai2 measures it as the spread of models at a given scale.
  • Noise is the variability you get when you run the same model again, or across training checkpoints.

A good benchmark has a high ratio of the two — a high signal-to-noise ratio (SNR). The interesting part is that bigger is not better. In Ai2's experiments, using only the 16 highest-SNR MMLU subtasks beat using all 57, cutting error by 32%. Swapping the scoring metric from pass/fail to bits-per-byte pushed MBPP's SNR from 2.0 to 41.8.

Ai2 reports that this ratio predicts a benchmark's usefulness better than its raw size does — swapping to a higher-SNR metric lifted its "decision accuracy," the odds of correctly picking the better of two models, from 68% to 93%. A small, clean eval can be more trustworthy than a large, noisy one, which is not the intuition most leaderboards are built on.

Translated to practice, there is one rule — when you compare two scores, first ask whether the gap is larger than the noise. If rank 1 and rank 3 sit inside the noise band, that ranking is an illusion, not information.

Where the Noise in Coding Benchmarks Comes From

Noise in coding evals arrives from four directions.

1) Contamination. The OpenAI team showed that a model can reproduce the original gold patch or problem statement nearly verbatim from just the task_id. That is memorization of training data, not the capability to write software. The score rises; the signal does not.

2) Design flaws. The same post finds that more than 60% of the remaining unsolved SWE-bench Verified problems are not actually solvable as scored. Forty-nine tests reject functionally correct submissions, and twenty-six demand behavior that is nowhere in the spec. The model can be right and still score zero.

3) Harness and infrastructure differences. Anthropic measured that scores move without changing a single model weight — just by adjusting the run environment. On Terminal-Bench 2.0 the gap between the most- and least-resourced setups was 6 percentage points (p < 0.01), and the infrastructure error rate fell from 5.8% to 0.5%. What separates the ranks can be the container config, not the model.

4) Overfitting and wear-out. New benchmarks don't last long either. SWE-bench Pro, built to improve on Verified, was found in an independent audit to have broken tasks in 27.4% of cases by automated pipeline and 34.1% by human review. And the same model swings hard when only the benchmark changes — one reported comparison had a single model at roughly 81% on SWE-bench Verified and roughly 46% on the harder SWE-bench Pro.

The uncomfortable part is that these effects aren't monotonic. Anthropic found that modest changes in resource headroom stayed within the noise (statistically insignificant, p = 0.40), while the extremes diverged sharply — and on SWE-bench, giving a task 5x the RAM moved the score only about 1.54 points. The same knob is negligible in one range and decisive in another, which is exactly how a harness gap hides in plain sight.

What Teams Should Actually Do

A leaderboard may be signal to the people training models, but to a team choosing an assistant it is mostly noise. The practical guidance:

  • Evaluate on your own tasks. Build a small private eval set from 30–50 of your team's real PRs and issues. "Pass rate on our codebase" is a far stronger signal than rank 1 on a public board.
  • Read confidence intervals, not ranks. Anthropic's advice is explicit — treat leaderboard gaps below 3 percentage points with skepticism until the eval config is documented and matched.
  • Prefer contamination-resistant designs. A rolling time cutoff (LiveCodeBench) or a private held-out test set (GAIA) structurally blocks memorization scores.
  • Pin and document the harness. A comparison that doesn't state prompts, retries, timeouts, and resource limits is comparing apples to oranges.
  • If you publish an eval, calibrate it. Anthropic's suggestion is to specify both a resource floor and ceiling per task and tune them so the scores at each end fall within noise of one another — otherwise the config silently becomes part of the score.
  • Triangulate across types. Read a static benchmark, a human-preference arena, and an agentic suite together, so the noise on any one axis cancels out.
  • Run each candidate more than once. A single pass/fail run hides the variance; three to five runs per task show you the spread — the very noise you're trying to see through.
  • Watch for saturation. When the top models cluster within a couple of points, the benchmark has stopped discriminating — low signal, and the order among them is close to random.

Concretely: freeze one scaffold — same prompt, same retry policy, same timeouts — run each model on your private task set several times, and report the mean with its spread. If two models' spreads overlap, you don't have a winner; you have a tie, and you should decide on price, latency, or licensing instead.

All of this converges on the eval-first principle — the eval set comes before the model (or the assistant), the same order laid out in the AI model development lifecycle post. Once the eval exists, choosing a model stops being taste and becomes an experiment.

Closing

Separating signal from noise is, in the end, a matter of humility. The last couple of decimal places at the top of a leaderboard are mostly marketing; the real signal is the difference that reproduces on your own tasks. OpenAI started from contamination and scoring flaws, Anthropic from infrastructure variance, Ai2 from statistical discrimination — and they arrive at the same place: don't trust a single number, ask whether that number is bigger than the noise. For a team choosing a coding assistant, there is little advice more practical than that.

None of this means benchmarks are useless — they are indispensable to the people training the models. It means a leaderboard is the start of a question, not the answer to it.

References