LLM-as-a-Verifier: 점수를 하나 뽑지 말고 logprob 분포의 기댓값을 쓰기¶

레포: llm-as-a-verifier/llm-as-a-verifier · 문서
논문: LLM-as-a-Verifier: A General-Purpose Verification Framework (arXiv:2607.05391, 2026-07-06)
저자: Jacky Kwok, Shulu Li, Pranav Atreya, Yuejiang Liu, Yixing Jiang, Chelsea Finn, Marco Pavone, Ion Stoica, Azalia Mirhoseini
공개: 2026-04-09 (Python, MIT, pip install llm-verifier, 별 3,207개 · 2026-09-11 기준)
읽은 날짜: 2026-09-11 (마지막 푸시 2026-08-20, 버전 0.2.0)
태그: #Verifier #LogProbs #TestTimeScaling #BestOfN #AgentEvaluation #PrefixCache #Confidence

한 줄 요약¶

LLM-as-a-Judge가 점수를 토큰 하나로 떨어뜨리는 대신, 점수 토큰 전체의 logprob 분포에 기댓값을 취해 미세한 보상 신호를 만든다. 추가 학습 없이 Best-of-N 선택, 진행 추적, RL 보상에 쓴다.

핵심 아이디어 셋¶

README가 스스로 요약한 세 가지다.

채점 단위를 잘게 쪼갠다 (fine-grained scoring granularity)
점수 토큰의 logprob 분포 전체에 기댓값을 취한다
반복 평가와 기준 분해를 확장한다

두 번째가 이 프로젝트의 정체성이다. LLM에게 "1에서 10 중 몇 점"을 묻고 나온 토큰 하나를 쓰면 정보 대부분이 버려진다. 모델이 7과 8 사이에서 갈등했다는 사실이 사라진다. 여기서는 각 점수 토큰의 확률을 그대로 가중치로 쓴다.

Fine-grained Reward Estimation¶

궤적 τ의 과제 x에 대한 보상을 이렇게 근사한다.

R(x, τ) = (1 / CK) · Σ_c Σ_k Σ_g  p_θ(v_g | x, c, τ) · φ(v_g)

기호	의미
`C`	평가 기준(criteria) 수
`K`	반복 검증 횟수
`G`	점수 토큰 수, 곧 채점 세분화 수준
`p_θ(v_g \\| x, c, τ)`	모델이 점수 토큰 `v_g`에 부여한 확률
`φ(v_g)`	점수 토큰을 스칼라로 매핑

세 겹의 합이다. 기준별로 나누고, 여러 번 반복하고, 점수 토큰 분포 전체를 더한다. 구현은 llm_verifier/fine_grained_reward.py에 있다.

Probabilistic Pivot Tournament (PPT)¶

N개 후보 중 최선을 고르는 문제다. 라운드로빈이면 C(N,2) 쌍을 모두 채점해 O(N²)이다. PPT는 모든 후보를 소수의 pivot하고만 비교해 O(Nk)로 줄인다.

절차가 다섯 단계다.

Candidates: 순위를 매길 후보 풀
Ring pass: 무작위 해밀턴 순환으로 인접 N개 쌍을 채점한다. 모든 후보가 A 슬롯과 B 슬롯에 한 번씩 들어가므로 모델의 위치 편향이 상쇄된다
Pivot selection: ring pass 점수로 정렬해 상위 k개를 pivot으로 삼는다
Pivot tournament: 비pivot 대 pivot, pivot 대 pivot 쌍을 p(a ≻ b) = σ(R_a - R_b)로 채점한다. 예산을 불확실한 상위 후보에 집중시킨다. 같은 쌍을 반복 평가할 때도 A/B 슬롯을 번갈아 써 편향을 상쇄한다
Selection: 승리 질량 w_i와 횟수 c_i로 집계해 정규화 값 w_i/c_i가 가장 높은 후보를 반환한다

위치 편향을 두 지점에서 구조적으로 없앤 설계가 눈에 띈다. 프롬프트로 "공정하게 보라"고 부탁하는 대신 슬롯 배치로 푼다.

Self-Verification (Terminal-Bench 2.1)¶

이 레포에서 가장 흥미로운 실험이다. 모델이 자기 자신의 결과물을 채점할 수 있는가.

과제마다 deepseek-v4-flash로 mini-swe-agent 궤적 5개를 만들고, 같은 모델을 검증자로 쓴다.

구성	Pass@1	LLM-as-a-Verifier	Oracle
Best-of-3	79.4%	86.5% ± 1.1%	92.1%
Best-of-5	78.7%	88.0% ± 0.6%	96.6%

자기 모델의 작업을 판정하는데도 Pass@1보다 한참 위로 올라간다. Best-of-5에서 78.7%에서 88.0%로 9.3%p다.

생성과 검증이 같은 모델인데 개선이 나온다는 것은, 만드는 능력과 고르는 능력이 분리된다는 뜻이다. 궤적을 만들 때는 못 보던 오류를 다 만들어놓고 비교할 때는 본다.

궤적은 data/terminal_bench_2.1_trajs/에 들어 있고 DEEPSEEK_API_KEY만 있으면 재현된다.

Test-Time Scaling 결과¶

벤치마크	Base Model	Harness	Pass@1	Verifier	Oracle
Terminal-Bench V2	GPT-5.5 (Best-of-5)	Capy	83.1%	86.5%	92.1%
SWE-Bench Verified	Opus 4.5 / 4.6 / Gemini 3 Flash (Best-of-3)	mini-swe-agent	76.1%	78.2%	84.4%
MedAgentBench	Claude Opus 4.8 (Best-of-5)	AgentBench	70.2%	73.3%	75.0%

이 표들은 검증자로 Gemini 2.5 Flash를 쓴다.

Progress Tracking¶

같은 보상 함수로 궤적을 매 스텝마다 채점할 수 있다. Terminal-Bench의 pytorch-model-cli 과제에서 Terminus-2 실행 두 건을 추적한 결과를 보이는데, 성공한 궤적은 점수가 꾸준히 오르고 실패한 궤적은 처음부터 낮게 깔린다.

track은 끝난 궤적을 채점하고, ProgressTracker는 실행 중인 에이전트를 감시한다. 스텝마다 먹이면 실시간 진행 점수가 나온다. README가 밝힌 용도가 "가망 없는 롤아웃을 일찍 중단하는 것" 이다.

Prefix-Cache 최적화¶

0.2.0의 핵심 개선이고 실무에 바로 쓸 만한 발상이다.

검증 프롬프트 하나에 궤적 두 개가 통째로 들어간다. Terminal-Bench 2.1 기준 약 80k 토큰이다. 게다가 기준별로, 반복별로 다시 채점하므로 같은 입력이 계속 재전송된다.

두 가지로 해결했다.

프롬프트에서 criterion을 꼬리에 둔다. 과제, 두 궤적, 평가 척도가 전부 앞에 오므로 공유 prefix가 된다
채점 시 동일 prefix마다 요청 하나를 먼저 완료시킨 뒤 나머지를 펼친다. 캐시를 먼저 데운다

결과가 캐시 히트율 5.2%에서 78.4%, 미캐시 입력 토큰 약 3.4배 감소다.

프롬프트 안에서 변하는 부분을 뒤로 미는 것만으로 이만큼 나온다. 같은 컨텍스트를 여러 기준으로 반복 평가하는 구조라면 어디서나 쓸 수 있다.

Token Accounting¶

캐시 히트율을 가정이 아니라 측정으로 낸다는 점을 README가 강조한다. 모든 검증자 호출이 과금 대상을 기록한다.

Verifier tokens (4,320 verifier calls)
  input                          272,551,552
    cached input                 214,712,320  (78.8% hit rate)
    uncached input                57,839,232
  output                          32,441,600
    reasoning                     26,102,144

llm_verifier.token_usage()로 라이브러리 사용자도 같은 숫자를 받는다. 점수 캐시에서 나온 비교는 계산에 넣지 않고, 백엔드가 보고한 usage 블록을 그대로 쓴다.

코드 규모¶

항목	값
전체 엔트리	1,139개
파이썬 파일	12개, 약 111KB
테스트 파일	0개
`data/`	908개 (궤적 데이터)
기여자	3명 (상위 1명이 커밋 16건)
저장소 크기	약 68MB

핵심 모듈은 fine_grained_reward.py(38.7KB), progress.py(16.7KB), loaders.py(11.2KB), pivot_tournament.py(3.0KB), prompts.py(7.7KB)다.

별 3,207개는 코드 분량이 아니라 논문 저자진과 벤치마크 주장에서 온 것으로 보는 편이 정확하다. 실제 구현은 작고, 저장소 용량 대부분이 재현용 궤적 데이터다.

한계와 리스크¶

테스트가 없다. 파이썬 12개 파일에 테스트 파일이 0개다. 채점 로직이 핵심 자산인데 회귀를 잡을 장치가 없다. 포크해서 쓸 때 직접 만들어야 한다.
Oracle과의 격차가 여전히 크다. Best-of-5 self-verification에서 88.0% 대 Oracle 96.6%로 8.6%p가 남는다. 후보 안에 정답이 있는데도 못 고른 경우가 그만큼이다. 선택 자체가 아직 풀린 문제가 아니다.
벤치마크마다 검증자와 베이스 모델이 다르다. 검증자는 Gemini 2.5 Flash와 deepseek-v4-flash가 섞이고, 베이스 모델은 GPT-5.5, Opus 4.5/4.6/Gemini 3 Flash 혼합, Opus 4.8로 제각각이다. 행끼리 비교하면 안 되고, 검증자를 바꿨을 때의 민감도도 알 수 없다.
개선 폭이 벤치마크마다 크게 다르다. SWE-Bench Verified는 2.1%p(76.1 → 78.2)에 그치는데 Oracle은 84.4%다. 어떤 과제에서 잘 먹히고 어떤 과제에서 안 먹히는지가 설명되지 않는다.
비용 대비 효과가 표에 없다. Best-of-N은 롤아웃을 N개 만들고 그 위에 검증 호출을 얹는다. 토큰 회계 기능은 훌륭하지만 "Pass@1 대비 총비용이 몇 배이고 그만한 값을 하는가" 는 README가 답하지 않는다. Prefix 캐시로 검증 비용은 줄였어도 생성 비용 N배는 그대로다.
"추가 학습이 필요 없다"가 공짜라는 뜻은 아니다. 학습은 안 하지만 검증자도 LLM 호출이고, 위 표에서 검증자 호출만 4,320회에 입력 2.7억 토큰이다.
자체 보고 결과다. 재현 스크립트와 궤적을 함께 공개한 점은 좋지만, 궤적 자체가 저자들이 만든 것이라 생성 단계의 편향은 검증할 수 없다.

가져갈 지점¶

logprob을 신뢰도로 쓰는 계보에 정확히 놓인다

Logits as Confidence 노트에서 본 발상을 채점에 적용한 형태다. 점수 토큰 하나를 뽑지 말고 분포 전체를 쓰라는 것이 공통 원리다. RAG 신뢰도 게이팅에도 같은 방식을 적용할 수 있다. "관련 있음/없음"을 토큰 하나로 받지 말고 분포에 기댓값을 취하는 식이다.

결정론적 게이트와 LLM 판정의 역할 분담

AgentCore 노트에서 CI 하드 게이트에는 결정론적 평가기를, 추세 관찰에는 LLM judge를 쓰라고 정리했다. 이 프레임워크는 후자를 정교하게 만든 쪽이다. 분포 기댓값과 반복 평가로 판정 분산을 줄였으므로, 그만큼 게이트에 쓸 여지가 넓어진다. 다만 표준편차가 ±0.6~1.1%p로 여전히 존재한다.

criterion을 프롬프트 꼬리에 두기

prefix 캐시 히트율을 5.2%에서 78.4%로 올린 기법은 우리 평가 파이프라인에 그대로 옮길 수 있다. 같은 긴 컨텍스트를 여러 기준으로 반복 평가하는 구조라면 무조건 이득이다. 변하는 부분을 뒤로 미는 원칙 하나다.

온라인 진행 추적으로 조기 중단

Liner 중단 기능 노트가 사용자가 멈추는 경로를 다뤘다면, 이쪽은 시스템이 스스로 멈추는 판단 근거다. 둘을 합치면 중단 체크포인트에서 진행 점수를 함께 보고 가망 없으면 자동으로 접는 구조가 된다.

자기 검증이 성립한다는 관찰

같은 모델이 생성과 검증을 다 해도 개선이 나온다는 결과는 실무적으로 크다. 검증용으로 더 비싼 모델을 따로 붙이지 않아도 된다는 뜻이기 때문이다. 다만 Oracle 격차가 크므로 상한을 알고 써야 한다.

결론¶

"점수를 토큰 하나로 떨어뜨리지 말라" 는 한 문장이 이 프로젝트의 전부이고, 그 하나로 Best-of-N 선택, 진행 추적, RL 보상을 함께 커버한다. 위치 편향을 슬롯 배치로 없애고 O(N²)를 O(Nk)로 줄인 PPT, criterion을 꼬리에 두어 캐시를 살린 프롬프트 설계도 각각 독립적으로 가져다 쓸 만하다.

다만 테스트가 없고, 벤치마크마다 모델 구성이 달라 행끼리 비교가 안 되며, 비용 대비 효과가 제시되지 않는다. 별 3,207개에 비해 코드는 작다. 아이디어와 프롬프트 설계를 참고하고 채점 로직은 직접 검증하며 쓰는 쪽이 맞다.

Oracle 격차 8.6%p가 남았다는 점도 기억할 만하다. 후보 안에 답이 있어도 못 고르는 경우가 그만큼이라, 선택 문제는 아직 열려 있다.