리뷰어 성능은 '무엇을 반려할지'를 좌우한다: Execute-Review-Revise 파이프라인 실험

TL;DR Highlight

다른 계열 중간급 리뷰어를 붙였더니 정답률 52%→64%, 같은 모델 자기검토는 효과 없었다

Who Should Read

저렴한 모델과 비싼 모델을 섞어 실행-검토-수정 에이전트 파이프라인을 만들며 리뷰어 모델 선택에 고민인 개발자

Core Mechanics

다른 계열 리뷰어가 정답률을 올렸다
- 실행 모델 Gemini 3.1 Flash-Lite 혼자 풀면 52%였다.
- gpt-oss-20b를 리뷰어로 붙이니 64%였고 망가진 답은 0개였다.
자기검토는 많이 잡아내도 이득이 없다
- 같은 모델 자기검토는 틀린 답을 85% 잡아냈지만(recall) 정답률 향상은 +6%p로 유의하지 않았다.
- 반려를 2.1배 더 많이 하면서 고친 비율은 15%로 교차 계열의 43%보다 낮았다.
자기검토는 멀쩡한 답을 자주 반려한다
- 맞은 답 52개 중 35%인 18개를 자기검토가 반려했다.
- 다른 계열 리뷰어는 2%(1개)만 반려했다.
낮은 피해율은 실행자가 무시한 덕분이다
- 잘못 반려된 18개 중 실행자가 따른 3개는 모두 오답이 됐다.
- 무시한 15개는 정답 그대로 남아서 안전해 보였을 뿐이다.
능력이 너무 낮은 리뷰어는 비용만 먹는다
- Llama-3.1-8B 리뷰어는 100문제 중 최종 답을 하나도 바꾸지 못했다.
- 토큰 비용은 기준 대비 약 2배였다.

Evidence

정답률 비교 (100문제, Omni-MATH)
- 리뷰 없음 52%, 자기검토 58%(p=0.146), 교차 계열 64%(p=0.0005), 약한 리뷰어 52%.
- 교차 계열은 새로 맞은 문제 12개, 새로 틀린 문제 0개였다.
반려 결과 분해 (자기검토 vs 교차 계열)
- 반려 수 59 대 28, 고침 비율 15% 대 43%(Fisher p=0.0074).
- 정답 반려 후 변화 없음 비율은 41% 대 14%(p=0.0151).
효율과 비용
- 유용한 수정 1건당 반려가 6.6회 대 2.3회 필요했다.
- 추가 정답 1개당 토큰은 약 25,600(자기검토) 대 23,700(교차 계열)으로 비슷했다.
약한 리뷰어의 낭비
- 반려는 2건뿐이고 recall은 0.04였다.
- 작업당 토큰은 668에서 1,353으로 늘었다.

How to Apply

리뷰어를 실행 모델과 다른 계열로 바꿔 보기
- 지금 자기검토 단계가 있다면 리뷰어만 다른 회사의 중간급 모델로 교체한다.
- 같은 100개 샘플에 같은 실행 결과를 두 리뷰어에 돌려 정답률을 비교한다.
반려 결과를 4가지로 로깅하기
- 반려마다 수정으로 고침, 정답을 망침, 변화 없음, 다른 오답으로 바뀜을 기록한다.
- 정답 라벨이 있는 평가셋에서 잘못 반려율을 따로 집계한다.
리뷰어를 recall이 아니라 정밀도로 고르기
- 후보 리뷰어의 반려 수 대비 고친 수를 비교한다.
- 반려가 많고 잘못 반려율이 높은 모델은 제외한다.
약한 리뷰어 투입 전에 변화량 측정하기
- 리뷰 단계를 켠 뒤 최종 답이 실제로 바뀐 비율과 토큰 증가량을 확인한다.
- 답이 거의 안 바뀌면서 비용만 늘면 그 단계를 뺀다.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 다른 모델을 리뷰어로 쓰는 프롬프트)

너는 리뷰어다. 아래 문제와 풀이를 보고 풀이가 틀렸을 때만 reject 하라. 확신이 없으면 accept 하라. 정답은 알려주지 않는다.

문제: {{문제}}
풀이: {{풀이}}

출력 형식:
VERDICT: accept 또는 reject
CRITIQUE: reject라면 틀린 단계와 이유를 구체적으로, accept라면 한 줄

이어서 해 볼 것: reject가 나오면 풀이와 CRITIQUE를 원래 실행 모델에 주고 한 번만 수정시킨 뒤, 정답과 비교해 고침/망침/변화 없음으로 세어 보라.

Terminology

Execute-Review-Revise한 모델이 풀고, 다른 모델이 검토해 반려하면 처음 모델이 한 번 고쳐 쓰는 코드 리뷰 같은 흐름이다.

recall틀린 답 중 리뷰어가 반려한 비율이다. 불량품 중 검수에서 잡힌 비율과 같다.

revision inertia실행 모델이 비판을 받아도 답을 안 바꾸고 버티는 성향이다. 잘못된 지적도 무시해서 피해가 가려진다.

McNemar test같은 문제를 두 조건으로 풀었을 때 결과가 달라진 문제만 비교하는 통계 검정이다.

capability floor리뷰어 능력이 이 선 아래면 검토 단계가 아무 변화도 못 만드는 최저 능력선이다.

Related Resources

https://github.com/faizan-tnvr004/llm-reviewer-capability

Original Abstract (Expand)

Multi-agent LLM pipelines increasingly assign roles, including execution and verification, to models of different capability tiers. This is done because running a flagship model at every stage is expensive. Previous literature has established that verification stages are not always beneficial, but holds reviewer capability roughly fixed relative to the executor. We vary it. We replace the reviewer with models spanning a capability range down to one that cannot solve the problems at all, and measure the outcome of every individual rejection. This is done across a constant set of 100 olympiad mathematics problems. A cross-family mid-tier reviewer improves final accuracy by 12 percentage points, from 52 to 64 percent (p = 0.0005), with zero damaged answers. Same-model self-review attains the highest error-detection rate of any condition (0.85 recall) yet yields no significant gain: it rejects 2.1 times as often for a third the repair rate (15 against 43 percent, p = 0.0074) and falsely rejects 35 percent of its own correct answers against 2 percent for the cross-family reviewer (paired p = 0.000015). The low damage rate of self-review proves to be an artifact of revision inertia rather than reviewer quality: of 18 falsely rejected correct answers, the three where the executor complied all became wrong, while the fifteen it ignored survived unchanged. Below a capability floor the role becomes inert: our weakest reviewer changed zero of 100 final answers while doubling token cost. These findings describe a single executor-reviewer configuration on 100 problems and should be read as a controlled pilot rather than a general claim about verification stages.