Field Log · Entry

Verifier와 Process Supervision: ORM·PRM·Value Model (3/10)

오늘의 결론

Verifier는 “답이 그럴듯한가?”를 묻는 범용 judge가 아니라, 주어진 state·solution·evidence가 task의 성공 조건을 만족하는지 score나 critique로 판정하는 구성요소입니다.

ORM은 완성된 solution의 outcome을, PRM은 중간 step의 타당성을, value model은 partial state에서 앞으로 성공할 기대값을 추정합니다. 이름이 비슷해도 label과 사용 시점이 다릅니다.

Process supervision은 오류 위치와 search pruning에 유용하지만 step 경계, 여러 정답 경로, 미래 회복 가능성 때문에 label을 만들기 어렵습니다. “이 step이 맞다”와 “이 state에서 최종 성공할 수 있다”를 섞지 않습니다.

Best-of-N과 search는 verifier가 선호하는 허점을 적극적으로 찾습니다. 후보 수가 커질수록 reward hacking과 distribution shift를 더 강하게 시험해야 합니다.

RAG Agent에서는 learned verifier보다 schema·calculator·citation entailment·authorization·실제 environment state 같은 실행 가능한 신호를 먼저 사용하고, learned score는 불확실한 부분을 보완합니다.

앞 글에서는 여러 후보를 만드는 generator와 그중 하나를 고르는 selector를 분리했습니다. 이번 글은 selector와 search의 눈 역할을 하는 verifier가 무엇을 학습해야 하는지 다룹니다.

complete solution y
  → outcome verifier: "final result succeeded?"

partial steps s₀ → s₁ → s₂ → ...
  → process verifier: "this transition is valid?"
  → value model: "how likely is future success from here?"

verifier output
  → rank · prune · retry · abstain · escalate

완성 답의 결과를 평가하는 ORM과 각 중간 전이를 평가하는 PRM 및 partial state의 미래 성공 가능성을 추정하는 value model을 후보 선택과 search에 연결하고 executable checks와 calibration gate로 검증하는 구조

그림 1. 결과가 맞는지, 한 단계가 유효한지, 현재 상태에서 앞으로 성공할 수 있는지는 서로 다른 label이다. Production에서는 이 구분을 유지해야 score가 왜 틀렸는지 진단할 수 있다.

Verifier의 입력과 출력을 먼저 정의한다

Verifier를 다음 함수로 추상화할 수 있습니다.

V(input x, candidate y, optional evidence e, optional state s)
  → scalar score
  or class label
  or structured critique

하지만 score=0.83만으로는 의미가 없습니다.

무엇의 확률인가?
어느 population에서 calibration됐는가?
Candidate의 최종 정답만 봤는가, reasoning도 봤는가?
Evidence를 함께 받았는가?
Safety와 helpfulness를 한 점수에 섞었는가?
Threshold를 넘으면 select하는가, execute하는가?

먼저 verifier contract를 씁니다.

verifier:
  target: grounded_answer_correctness
  input:
    question: string
    answer: string
    evidence_spans: Evidence[]
  output:
    supported_claims: string[]
    unsupported_claims: string[]
    score: float  # calibrated on eval-v6 only
  must_not_decide:
    - user_authorization
    - tool_side_effect_permission

Score가 다루지 않는 결정을 명시하는 것이 중요합니다. 높은 factuality score가 결제 승인을 뜻하지 않습니다.

Deterministic Checker와 Learned Verifier

Verifier라는 말에는 두 계열이 섞여 있습니다.

실행 가능한 Checker

Unit test
Compiler와 type checker
JSON Schema validator
Calculator와 symbolic solver
Database constraint
Policy engine
Environment의 terminal state

정확한 specification이 있을 때 강합니다. 대신 specification 밖의 유용성이나 의미적 품질은 판단하지 못합니다.

Learned Verifier

Reward model
Classification model
Pairwise ranker
LLM-as-a-judge
Generative critic

자연어와 open-ended task를 다룰 수 있지만 training label, prompt, model bias와 distribution shift에 의존합니다.

가능하면 deterministic signal을 anchor로 두고 learned verifier가 그 사이를 채우게 합니다.

schema valid?                → deterministic
tool actually succeeded?     → environment
claim follows from evidence? → learned + audited labels
answer is useful?            → human preference / calibrated judge

Outcome Reward Model: 완성 결과를 평가한다

Outcome Reward Model(ORM)은 완성된 solution y가 최종 성공했는지 score합니다.

r_outcome = ORM(x, y)

label example:
  1 if final answer is correct
  0 otherwise

Binary label이면 흔히 cross-entropy로 학습합니다.

L_ORM
  = −[r log pθ(success | x,y)
      + (1−r) log(1−pθ(success | x,y))]

Pairwise preference가 있다면 올바르거나 더 좋은 후보의 score가 높도록 ranking loss를 쓸 수 있습니다.

L_pair
  = −log σ(score(y_good) − score(y_bad))

ORM의 장점

Final answer label만 있으면 비교적 쉽게 만들 수 있습니다.
Best-of-N 완성 후보를 ranking하기 쉽습니다.
Code test나 math exact answer처럼 outcome을 자동 판정할 수 있는 task에 잘 맞습니다.
중간 풀이 형식이 달라도 최종 성공을 인정할 수 있습니다.

ORM의 한계

어디서 처음 틀렸는지 알려 주지 않습니다.
우연히 정답을 맞춘 잘못된 reasoning을 reward할 수 있습니다.
Partial solution을 초기에 pruning하기 어렵습니다.
정답만 보고 evidence나 unsafe action을 놓칠 수 있습니다.
Sparse outcome에서는 긴 trajectory의 어느 action이 기여했는지 알기 어렵습니다.

RAG Agent에서 “최종 답 text가 reference와 비슷함”만 ORM label로 쓰면 retrieval provenance나 authorization 실패를 reward할 수 있습니다. Outcome을 episode state로 넓혀야 합니다.

episode outcome:
  grounded answer
  AND correct tool state
  AND no unauthorized side effect
  AND user goal completed

Process Reward Model: 중간 Step을 평가한다

Process Reward Model(PRM)은 solution을 step으로 나누고 각 step의 타당성을 score합니다.

s₀ --a₁--> s₁ --a₂--> s₂ ... --a_T--> s_T

r_t = PRM(x, s₀:t, a_t)

Math reasoning이라면 한 식이나 논리 이동, agent라면 retrieval·tool call·state transition이 step이 될 수 있습니다.

PRM800K의 핵심 맥락

“Let’s Verify Step by Step” 연구는 수학 solution의 중간 step에 human feedback을 모은 PRM800K를 공개하고, outcome supervision과 process supervision을 비교했습니다. 여기서 얻은 결과를 모든 domain의 보편 법칙으로 일반화하지 않습니다. 수학은 step validity와 final answer를 비교적 명확히 판정할 수 있지만, 상담·요약·planning은 step 경계와 여러 유효 경로가 훨씬 모호합니다.

PRM Score를 Solution Score로 합치는 법

각 step score p_t가 있을 때 여러 aggregation이 가능합니다.

minimum:  score(y) = min_t p_t
product:  score(y) = ∏_t p_t
sum-log:  score(y) = Σ_t log p_t
last:     score(y) = p_T
average:  score(y) = mean_t p_t

각각 bias가 있습니다.

Minimum은 단 한 step의 낮은 score에 민감합니다.
Product와 sum-log는 긴 solution을 자동으로 벌점 줄 수 있습니다.
Average는 치명적 오류 하나를 많은 쉬운 step이 희석할 수 있습니다.
Last는 앞 단계의 오류 위치 정보를 버립니다.

Aggregation rule도 training과 별도로 validation set에서 선택하고 길이별 calibration을 봅니다.

PRM의 장점

첫 오류 위치를 찾는 데 도움이 됩니다.
Search 중간 branch를 score할 수 있습니다.
Final answer가 우연히 맞아도 잘못된 step을 식별할 수 있습니다.
사람이나 generator에 구체적 feedback을 줄 수 있습니다.

PRM의 한계

Step segmentation 자체가 임의적일 수 있습니다.
지역적으로 이상해 보여도 뒤에서 회복 가능한 step이 있습니다.
여러 유효한 풀이를 단일 reference path로 벌점 줄 수 있습니다.
Label 비용이 큽니다.
Evaluator가 미래 step을 보고 label했는지에 따라 leakage가 생깁니다.
Fine-grained score가 정확해 보이지만 잘못 calibration될 수 있습니다.

Value Model: Partial State의 미래 성공을 예측한다

Value model은 현재 partial state s_t에서 policy를 계속 실행했을 때 기대되는 미래 return을 추정합니다.

Vπ(s_t)
  = Eπ[Σ_{k=t}^T γ^(k−t) r_k | s_t]

Terminal success가 0/1이라면 직관적으로 “여기서부터 계속했을 때 성공할 확률”에 가깝게 학습할 수 있습니다.

PRM과 Value가 다른 이유

PRM asks:
  "방금 한 step이 타당한가?"

Value asks:
  "현재 state에서 앞으로 성공할 가능성은 얼마인가?"

예를 들어 agent가 처음 검색 query를 약간 비효율적으로 썼지만 결과에서 필요한 문서를 찾았다면:

Step quality는 낮게 평가될 수 있습니다.
현재 state의 미래 성공 가능성은 높을 수 있습니다.

반대로 논리적으로 맞는 작은 step을 밟았지만 deadline과 tool budget이 거의 끝났다면:

Step validity는 높습니다.
State value는 낮을 수 있습니다.

이 둘을 같은 label로 학습하면 search가 “과거 잘못”과 “미래 가능성”을 혼동합니다.

Value Target 만들기

Partial state에서 여러 rollout을 실행해 성공 비율을 target으로 삼을 수 있습니다.

target V(s)
  ≈ successful rollouts from s / total rollouts from s

하지만 이 target은 rollout policy에 의존합니다.

약한 policy가 실패했다고 state 자체가 불가능한 것은 아닙니다.
Sample 수가 적으면 variance가 큽니다.
Tool·web 환경이 변하면 같은 state의 outcome이 달라집니다.
Search로 수집한 state는 production policy 분포와 다릅니다.

Policy version, environment snapshot, rollout budget을 label provenance에 포함합니다.

Generative Verifier: Score와 함께 이유를 생성한다

Discriminative verifier는 scalar나 class를 냅니다. Generative verifier는 candidate를 분석해 오류 위치와 critique를 text 또는 schema로 생성합니다.

{
  "verdict": "incorrect",
  "first_error_step": 3,
  "error_type": "unsupported_assumption",
  "evidence": "policy-v7#exception",
  "repair": "지역 예외 조건을 먼저 확인"
}

장점:

Debugging과 revision prompt에 직접 쓸 수 있습니다.
오류 taxonomy를 풍부하게 만들 수 있습니다.
한 점수에 숨은 이유를 관찰할 수 있습니다.

위험:

Critique 자체가 hallucination일 수 있습니다.
그럴듯한 오류 설명이 verdict를 정당화할 수 있습니다.
Output token과 latency가 큽니다.
Structured schema가 유효해도 내용이 맞다는 보장은 없습니다.

Generative critique도 별도의 candidate로 보고 reference·evidence·human label로 평가합니다.

Process Label을 어떻게 만든다

사람 Annotation

Annotator가 각 step을 correct, incorrect, ambiguous 등으로 표시합니다.

필요한 지침:

Step 경계 정의
앞 step의 오류를 그대로 이어 간 후속 step 처리
다른 유효 풀이 허용
표현 오류와 논리 오류 구분
외부 지식 사용 범위
첫 오류 이후 label 정책
불확실/판정 불가 label

Inter-annotator agreement와 adjudication을 기록합니다. 합의가 낮은 category를 억지 binary로 만들지 않습니다.

자동 Outcome으로 Step Label 추정

Partial solution에서 여러 continuation을 sample하고 최종 정답률로 step quality를 추정할 수 있습니다. Math-Shepherd 같은 접근은 자동 process supervision의 가능성을 보여 줍니다.

장점은 규모이고, 단점은 proxy noise입니다.

좋은 state도 continuation model이 약해 실패할 수 있습니다.
잘못된 state도 우연히 정답으로 회복할 수 있습니다.
동일 generator가 만든 오류 bias를 verifier가 학습합니다.
Final answer leakage가 step label에 들어갈 수 있습니다.

Executable Step Label

Code, SQL, tool use에서는 일부 step을 실행해 확인할 수 있습니다.

code patch → compile/test
SQL plan   → parser + read-only sandbox
tool call  → schema + dry-run result
citation   → source span + entailment label

실행 가능하다고 모든 semantic goal을 판정하는 것은 아닙니다. Test coverage와 environment fidelity를 함께 평가합니다.

Label Provenance

{
  "trajectory_id": "tr_...",
  "step_index": 4,
  "label": "incorrect",
  "label_source": "human_adjudicated",
  "annotator_policy": "prm-guide-v3",
  "visible_context": "prefix_only",
  "generator": "model-snapshot-x",
  "environment": "sandbox-v8"
}

Verifier training data도 model training data와 같은 version·lineage 관리가 필요합니다.

Search에 Verifier를 연결한다

Best-of-N

완성 후보를 모두 만든 뒤 ORM이나 generative verifier로 ranking합니다.

y* = argmax_i ORM(x, y_i)

Parallelize하기 쉽지만 잘못된 branch에도 끝까지 compute를 씁니다.

Beam Search with PRM

각 step에서 후보를 확장하고 PRM score가 높은 b개 prefix만 남깁니다.

frontier₀ = {root}
repeat:
  expanded = generate_next_steps(frontier)
  scored = PRM(expanded)
  frontier = top_b(scored)

초기 pruning 오류가 되돌릴 수 없다는 문제가 있습니다. Diversity constraint나 exploration slot을 남깁니다.

Value-guided Search

현재 partial state의 미래 성공 가능성을 사용해 expansion priority를 정합니다.

priority(s) = V(s) + exploration_bonus(s) − cost_so_far(s)

Value가 overconfident하면 익숙한 branch만 반복합니다. Search policy가 만든 state에서 verifier를 재평가해야 합니다.

Process + Outcome 결합

candidate score
  = α · process_score
  + β · outcome_score
  − λ · cost

이 식의 weight는 보편값이 아닙니다. Hard constraint는 weighted score에 섞지 않습니다.

if unauthorized or schema_invalid:
  reject
else:
  rank by calibrated quality and cost

Reward Hacking은 왜 N과 함께 커지는가

Verifier가 진짜 utility가 아니라 proxy를 측정하면 generator와 search는 proxy의 허점을 찾습니다.

true quality U(y)
proxy reward R(y)

optimization chooses argmax R(y)
not necessarily argmax U(y)

흔한 Proxy Exploit

길고 자세한 답에 높은 점수
특정 phrase나 answer format을 정답 신호로 사용
Citation 개수는 많지만 source가 claim을 지지하지 않음
“불확실하다”는 표현만 넣어 calibration이 좋아 보임
Tool call schema는 맞지만 semantic argument가 틀림
Benchmark-specific shortcut이나 answer leakage
Judge가 선호하는 문체를 복제

후보 수가 커지면 우연히 높은 proxy score를 얻는 극단 후보를 만날 가능성이 커집니다. Training 분포에서의 verifier accuracy가 search 분포에서 유지된다고 가정하지 않습니다.

Search-induced Distribution Shift

training candidates:
  ordinary model samples

deployment candidates:
  samples explicitly optimized to maximize verifier score

후자는 더 adversarial합니다. 실제 N, temperature, search algorithm으로 생성한 후보를 validation에 포함합니다.

방어

Executable hard checks
여러 독립 signal의 conjunction
Hidden holdout verifier와 rotating tests
Adversarial candidate mining
N/search-depth별 calibration
Score와 human utility의 정기 audit
Critical false positive에 높은 비용 부여
Low-margin abstention
Generator와 verifier 동시 개선 후 locked re-evaluation

Verifier ensemble도 완전한 해결은 아닙니다. 같은 data와 bias를 공유하면 함께 속습니다.

Calibration과 Threshold

Verifier score 순위가 맞아도 확률로 해석할 수 없는 경우가 많습니다.

Ranking과 Calibration을 구분한다

ranking:
  good candidate tends to score above bad candidate

calibration:
  among candidates scored near 0.8,
  about 80% satisfy the defined event

Best-of-N은 ranking이 중요하고, “0.8 이상이면 자동 실행”에는 calibration이 중요합니다.

Reliability Diagram

Score를 bin으로 나누고 각 bin의 empirical success rate를 비교합니다. 전체 ECE 하나만 보지 말고 length, language, model, domain, N, search depth별 curve를 봅니다.

Threshold는 Decision Cost로 정한다

false positive cost:
  wrong answer selected / unsafe action allowed

false negative cost:
  good answer rejected / unnecessary escalation

고위험 write action은 false positive cost가 매우 큽니다. Factual QA와 같은 threshold를 쓰지 않습니다.

RAG Agent용 Multi-Verifier 설계

RAG Agent trajectory를 한 score로 압축하지 않습니다.

step 1 retrieval:
  query relevance · ACL filter · evidence coverage

step 2 reasoning:
  claim support · contradiction · missing condition

step 3 tool proposal:
  schema · semantic arguments · policy

step 4 execution:
  real result · error · idempotency · final state

step 5 final answer:
  groundedness · completeness · calibrated abstention

Gate와 Rank를 분리한다

hard_gates:
  - acl_passed
  - tool_schema_valid
  - authorization_granted
  - no_unsupported_critical_claim

ranking_signals:
  - evidence_coverage
  - answer_helpfulness
  - process_score
  - latency_cost

Hard gate 실패를 높은 helpfulness score가 상쇄하게 두지 않습니다.

Verifier Failure도 Trace한다

{
  "verifier_id": "citation-prm-v5",
  "input_hash": "sha256:...",
  "score": 0.74,
  "threshold": 0.80,
  "decision": "retrieve_again",
  "calibration_slice": "ko-policy-long-context",
  "model_version": "...",
  "latency_ms": 143
}

나중에 human label이 들어오면 verifier false positive/negative를 replay할 수 있습니다.

Verifier 평가 Suite

Outcome Discrimination

Accuracy, precision, recall
AUROC·AUPRC
Pairwise ranking accuracy
Critical false-positive rate

Class imbalance가 크면 accuracy만 보지 않습니다.

Process Localization

첫 오류 step 정확도
Step-level precision·recall
오류 없는 prefix의 false alarm
Error type classification
Annotation agreement 상한과 비교

Calibration

Reliability diagram
Brier score
ECE와 slice ECE
Threshold별 risk·coverage

Search Utility

Verifier 단독 점수보다 실제 search 결과가 중요합니다.

with same generator and compute:
  random selection
  majority
  ORM selection
  PRM/value-guided search
  oracle selection

Selected success@1, oracle gap, cost, latency를 비교합니다.

Adversarial Robustness

길이와 문체만 바꾼 동일 답
정답 phrase를 포함한 오답
Citation 수만 늘린 unsupported answer
Correct final answer with wrong steps
Wrong final answer with polished steps
Unseen generator/model
Search-optimized candidate
Korean·English 혼합과 domain terminology

Temporal·Environment Shift

Policy document와 tool schema가 바뀐 뒤 calibration을 재검증합니다. Stale verifier가 이전 규칙에 맞는 답을 높은 점수로 줄 수 있습니다.

흔한 실패와 처방

1. ORM·PRM·Value를 모두 “Reward Model”이라 부른다

Label과 사용 시점이 달라 debugging이 불가능해집니다.

처방: Target event, input prefix, horizon, aggregation을 contract에 씁니다.

2. Step Score 평균을 그대로 Solution Score로 쓴다

치명적 오류 하나가 희석됩니다.

처방: Minimum, sum-log, outcome 결합을 validation하고 길이 bias를 측정합니다.

3. Final Answer를 본 Annotator가 앞 Step을 Label한다

미래 정보가 prefix-only verifier에 leakage됩니다.

처방: Annotation visibility를 기록하고 deployment input과 맞춥니다.

4. 한 Reference Path만 정답으로 인정한다

새롭지만 유효한 풀이를 false negative 처리합니다.

처방: Constraint와 local validity를 평가하고 multiple-path adjudication을 둡니다.

5. Verifier Accuracy만 높으면 Search도 좋아진다고 본다

Search는 score 극단과 새로운 candidate 분포를 만듭니다.

처방: 실제 N·depth·generator에서 end-to-end utility를 평가합니다.

6. High Score로 Authorization을 대체한다

Learned model은 권한 주체가 아닙니다.

처방: Policy engine과 user approval을 hard gate로 둡니다.

7. Generative Critique를 사실로 기록한다

Critique도 hallucinate할 수 있습니다.

처방: Structured claim을 evidence와 human label로 검증합니다.

8. Verifier가 Generator와 같은 Shortcut을 공유한다

서로 동의해도 같은 오답일 수 있습니다.

처방: Executable checks, counterfactual, unseen generator split을 사용합니다.

Production 체크리스트

스스로 확인하기

ORM과 PRM은 각각 어떤 label을 예측하는가?
Step validity와 state value가 반대 방향일 수 있는 예시는 무엇인가?
PRM step score의 평균이 치명적 오류를 숨길 수 있는 이유는 무엇인가?
Partial-state rollout으로 만든 value label은 왜 policy-dependent한가?
Final answer를 본 annotator의 label이 leakage가 될 수 있는 이유는 무엇인가?
Generative verifier의 critique를 다시 검증해야 하는 이유는 무엇인가?
Best-of-N이 커질수록 verifier proxy exploit이 증가할 수 있는가?
Training sample과 search-optimized sample의 분포는 어떻게 다른가?
Ranking이 좋아도 자동 실행 threshold에 calibration이 필요한 이유는 무엇인가?
RAG Agent에서 한 개 reward score로 합치면 안 되는 hard gate는 무엇인가?
Oracle success@N과 selected success@1 사이 gap이 verifier에 대해 무엇을 말하는가?
Tool schema 변경 후 verifier를 재평가해야 하는 이유는 무엇인가?

작은 실습

최종 정답과 step annotation이 있는 문제 100개를 준비합니다.

ORM으로 완성 후보 8개를 ranking합니다.
PRM으로 첫 오류 step과 solution score를 계산합니다.
Minimum, average, sum-log aggregation을 비교합니다.
Oracle success@8과 각 selector의 success@1을 기록합니다.
답은 맞지만 step이 틀린 후보, 답은 틀리지만 문체가 좋은 후보를 추가합니다.
Candidate 길이와 generator를 바꿔 reliability diagram을 그립니다.
Verifier가 놓친 false positive를 다음 adversarial set으로 환원합니다.

RAG Agent라면 step을 retrieval, evidence selection, tool proposal, execution, final claim으로 바꾸고 각 단계에 deterministic check와 learned score를 하나씩 연결해 봅니다.

다음 글은 LLM 불확실성과 Calibration: 모르면 멈추게 만들기입니다. Verifier score와 model confidence를 확률처럼 해석할 수 있는 조건, abstention과 risk-coverage를 다룹니다.