Skip to content
←

Split View: 평가자 병목 — 약한 채점자가 시스템 전체의 상한이 됩니다

✨ Learn with Quiz
|

평가자 병목 — 약한 채점자가 시스템 전체의 상한이 됩니다

하네스를 아무리 고쳐도 점수가 안 오릅니다

도구 표면을 다듬고, 실패 반환을 구조화하고, 컨텍스트를 플레이북으로 바꿨는데 성공률 그래프가 평평하다고 해 보겠습니다. 구성한 예시지만, 이 평평함에는 흔한 원인이 하나 있습니다. 개선이 없어서가 아니라, 지금의 평가자가 그 개선을 볼 수 없어서입니다. 실행이 죽지만 않으면 통과로 치는 채점기 아래에서는, 결과의 품질을 끌어올리는 모든 변경이 점수에 나타나지 않습니다.

이 상황이 위험한 이유는 결론이 거꾸로 나기 때문입니다. "하네스를 고쳐도 소용없다"가 아니라 "고쳐진 것을 잴 수 없다"가 진짜 상태인데, 그래프만 보면 전자로 읽힙니다.

측정할 수 없는 품질은 선택할 수 없습니다

이 시리즈가 반복해서 돌아오는 원칙입니다. 하네스 개선은 결국 선택의 루프입니다. 변경을 만들고, 평가하고, 나은 쪽을 채택합니다. 이 루프가 고를 수 있는 품질은 평가자가 구별할 수 있는 품질뿐입니다. 평가자가 구별하지 못하는 축에서는 아무리 좋은 변경도 우연과 같은 확률로 채택됩니다. 그래서 약한 채점자는 단순히 아쉬운 요소가 아니라 시스템 전체의 상한입니다.

Lilian Weng의 하네스 글도 하네스 엔지니어링의 난제 목록에서 약한 평가자를 첫손에 꼽습니다. 빠르고 정밀한 검증기가 없는 과제가 많고, 연구적 안목이나 장기적 가치처럼 검증기를 만들기조차 어려운 품질도 있다는 것입니다. 병목이 하네스 바깥이 아니라 평가에 있다는 진단은, 이 분야를 실제로 밀고 있는 사람들의 공통 결론에 가깝습니다.

평가자의 사다리: 스모크에서 패널까지

평가자는 있다 없다의 문제가 아니라 강도의 문제입니다. 이 시리즈는 다섯 단계의 사다리로 정리합니다.

  • 스모크 — 실행이 끝났는지만 봅니다. 무엇을 했는지는 못 봅니다. 결과 품질, 변경 범위, 회귀가 전부 사각지대입니다.
  • 단위 테스트 통과율 — 숫자가 하나 나옵니다. 그 숫자는 테스트 파일이 정직할 때만 의미가 있고, 테스트가 다루지 않는 품질은 여전히 사각지대입니다.
  • 루브릭 채점 — 무엇을 잘한 것으로 칠지 미리 적고 그 기준으로 채점합니다. 잡음이 크게 줄어듭니다.
  • 루브릭 + 채점 자료 격리 — 채점 기준과 정답 자료를 에이전트가 읽지도 쓰지도 못하게 둡니다.
  • 루브릭 + 견제 지표 패널 — 성공률만 보지 않고 도구 호출 수, 수정 범위, 삭제된 테스트 수를 함께 봅니다.

위로 갈수록 비쌉니다. 요점은 항상 꼭대기를 쓰라는 것이 아니라, 지금 어느 단에 서 있는지 알고 그 단의 사각지대를 아는 것입니다. 스모크 단에서 하네스를 정성껏 고치는 일은, 눈금 없는 저울로 재료를 계량하는 요리와 같습니다.

루브릭: 무엇을 잘한 것으로 칠지 미리 적습니다

사다리의 가운데 단이 실무에서 가장 성능 대비 효율이 좋습니다. Anthropic의 멀티 에이전트 시스템 회고는 자사 평가에서 LLM 심사자에게 루브릭을 주고 0.0에서 1.0 사이 점수와 합격 여부를 내게 했다고 적습니다. 기준은 사실 정확성, 인용 정확성, 완결성, 출처 품질, 도구 효율이었습니다. 그리고 자동 채점이 놓치는 미묘한 실패는 사람 테스트가 잡았다는 회고가 따라붙습니다.

# 코드 리뷰 요약 에이전트의 루브릭 (구성한 발췌)
- id: grounded
  weight: 3
  pass: '모든 지적에 파일 경로와 줄 근거가 붙어 있다'
- id: scope
  weight: 2
  pass: '요청된 변경 범위 밖의 파일을 언급하지 않는다'
- id: actionable
  weight: 2
  pass: '리뷰어가 바로 실행할 수 있는 다음 단계가 있다'

루브릭의 가치는 채점 자동화 이전에 합의의 문서화에 있습니다. 무엇이 좋은 결과인지 팀이 합의하지 못했다면, 어떤 채점기를 붙여도 그 불일치가 잡음으로 나타납니다.

격리와 견제: 채점을 만질 수 없게

넷째 단부터는 평가의 무결성이 주제가 됩니다. 채점 기준과 정답 자료가 에이전트가 쓸 수 있는 경로 안에 있으면, 지표를 올리는 가장 싼 방법은 과제를 잘하는 것이 아니라 채점을 고치는 것이 됩니다. 다섯째 단의 견제 지표는 성공률이 오르는 동안 다른 신호가 이상해지지 않는지를 봅니다. 이 두 단은 6편 리워드 해킹의 주제와 직결되므로 거기서 자세히 다룹니다.

평가 보정을 먼저 하십시오

순서에 관한 결론입니다. 하네스 개선을 자동화하고 싶다면, 평가자 보정이 먼저입니다. 평가가 잡음이면 루프는 잡음을 따라 움직이고, 자동화는 그 움직임을 빠르게 만들 뿐입니다. 지표는 오르는데 실사용 품질은 그대로인 시스템은 대체로 이 순서를 뒤집은 결과입니다.

보정의 실무는 이 블로그의 다른 글에서 다뤘습니다. 사람 라벨과 심사자 판정의 일치율을 재고, 불일치 사례로 루브릭을 고치는 순환입니다. 평가 주도 개발에서 가장 먼저 보정해야 하는 것은 심사자입니다를 함께 읽으면 좋습니다.

직접 연습하기

하네스 엔지니어링 RPG의 5티어가 정확히 이 글의 제목인 "평가자 병목"입니다. 게임 안에서 평가자는 과제 점수의 상한을 정하는 규칙으로 구현되어 있어서, 같은 하네스를 스모크 아래에서 돌릴 때와 루브릭 아래에서 돌릴 때 결과가 어떻게 갈리는지 직접 확인할 수 있습니다.

참고 자료

The Evaluator Bottleneck — A Weak Grader Caps the Whole System

You fix the harness and the score does not move

Say you refine the tool surface, structure the failure returns, and turn the context into a playbook — and the success-rate graph stays flat. A constructed example, but this flatness has one common cause: not that there was no improvement, but that the current evaluator cannot see it. Under a grader that counts anything that does not crash as a pass, every change that raises the quality of the result is invisible to the score.

What makes this dangerous is that the conclusion comes out backwards. The true state is "we cannot measure what improved", but the graph reads as "fixing the harness does not help".

You cannot select for a quality you cannot measure

This is the principle the series keeps returning to. Harness improvement is ultimately a selection loop: make a change, evaluate it, adopt the better side. The only qualities this loop can select for are the ones the evaluator can distinguish. On any axis the evaluator cannot tell apart, even excellent changes get adopted at chance. A weak grader is therefore not a minor shortfall; it is the ceiling of the entire system.

Lilian Weng's harness post also puts weak evaluators first in its list of hard problems for harness engineering: many tasks lack a fast and precise verifier, and some qualities — research taste, long-term value — are hard to build a verifier for at all. The diagnosis that the bottleneck sits in evaluation rather than elsewhere is close to a shared conclusion among the people actually pushing this field.

The evaluator ladder: from smoke to panel

An evaluator is not a yes/no matter but a matter of strength. This series organizes it as a five-rung ladder.

  • Smoke — checks only that the run finished. Not what it did. Result quality, scope of change, and regressions are all blind spots.
  • Unit-test pass rate — you get one number. It means something only while the test files are honest, and quality no test covers stays a blind spot.
  • Rubric grading — write down in advance what counts as good and grade against it. Noise drops a lot.
  • Rubric plus sealed grading data — the rubric and answer set are neither readable nor writable by the agent.
  • Rubric plus a counter-metric panel — not just the success rate: tool calls, modification scope, and deleted tests are watched together.

It gets more expensive as you climb. The point is not to always use the top rung, but to know which rung you stand on and what its blind spots are. Carefully fixing a harness under a smoke evaluator is cooking with a scale that has no markings.

The rubric: write down in advance what counts as good

The middle rung is where practice gets the best return. Anthropic's multi-agent system retrospective describes giving an LLM judge a rubric and having it output a 0.0–1.0 score and a pass-fail grade. The criteria: factual accuracy, citation accuracy, completeness, source quality, tool efficiency. And the retrospective adds that human testing caught the subtle failures automated grading missed.

# Rubric for a code-review summary agent (constructed excerpt)
- id: grounded
  weight: 3
  pass: 'Every finding carries a file path and line-level evidence'
- id: scope
  weight: 2
  pass: 'No files outside the requested change scope are mentioned'
- id: actionable
  weight: 2
  pass: 'There is a next step the reviewer can execute immediately'

The value of a rubric comes before grading automation: it documents an agreement. If the team has not agreed on what a good result is, any grader you attach will surface that disagreement as noise.

Sealing and counters: putting the grading out of reach

From the fourth rung upward, the subject becomes the integrity of evaluation. If the grading criteria and answer data sit inside paths the agent can write, the cheapest way to raise the metric is no longer doing the task well — it is editing the grading. The fifth rung's counter-metrics watch whether other signals go strange while the success rate climbs. Both rungs connect directly to part 6 on reward hacking, which covers them in detail.

Calibrate the evaluator first

The conclusion is about order. If you want to automate harness improvement, evaluator calibration comes first. If the evaluation is noise, the loop follows the noise, and automation only makes that movement faster. A system whose metrics rise while real-use quality stays flat is usually the result of reversing this order.

The practice of calibration is covered elsewhere on this blog: measure agreement between human labels and judge verdicts, then revise the rubric using the disagreement cases, and repeat. In evaluation-driven development, the first thing to calibrate is the judge pairs well with this post.

Practice it yourself

Tier 5 of the harness engineering RPG is literally the title of this post: "The evaluator bottleneck". In the game, the evaluator is implemented as the rule that caps the task score, so you can watch how the same harness splits between a run under smoke and a run under a rubric.

References