Process Supervision / Step-by-Step Verification 解读

本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。

Source Anchors

---

核心导读

Process supervision 的核心不是把模型的思考过程展示给用户，而是把复杂任务拆成可验证步骤，并判断每一步是否使用了正确证据、遵守了业务规则、触发了合适边界。Let's Verify Step by Step 说明，复杂推理只看最终答案会掩盖错误路径；过程监督可以提供更密集的训练和评估信号。

系统价值在于把流程模型、证据链、政策应用和人工复核转成可审计的 step-level gate。架构取舍集中在步骤粒度、verifier 组合、标注成本、风险分层、延迟开销和 trace 可读性之间。

---

1. 核心问题：结果正确不代表过程可接受

复杂业务任务经常出现一种危险情况：最终结论看起来对，但推理和操作过程不可接受。

例如信贷助手给出“需要人工复核”。最终建议可能正确，但中间过程可能使用了不允许的敏感属性、引用过期政策、漏掉政策例外、混淆客户材料，或把没有证据的推断写成事实。

如果只评估最终答案，系统会把这些问题隐藏起来。金融零售任务需要回答：

Task recognized correctly?
Evidence gathered correctly?
Policy applied correctly?
Exceptions checked?
Boundary decision made?
Final output grounded and compliant?

Process supervision 的目标就是评价通向答案的过程，而不只是评价答案本身。

---

2. 技术贡献：Outcome 与 Process

Let's Verify Step by Step 区分了 outcome supervision 和 process supervision。

在研究中，process supervision 可以训练 process reward model 来判断每一步是否合理。迁移到企业 AI，它也可以是工程上的 step verification：每一步有输入输出、允许行为、禁止行为、证据要求、verifier 和风险门槛。

这让复杂任务从黑箱回答变成可检查的流程执行。

这个差异对金融零售尤其重要。很多业务流程本来就已经存在步骤、权限、证据和复核要求，只是传统系统把它们写在 SOP、BPMN、政策手册和人工培训里。引入 AI 后，不应让这些边界消失在一个大 prompt 中，而应把它们转成模型执行时必须经过的 step gate。

换句话说，过程监督不是额外发明一套 AI 治理语言，而是把已有业务控制翻译成 AI 系统可以记录、验证和回归测试的形式。

---

3. 机制原理：把任务拆成可验证步骤

过程监督首先需要 step decomposition。一个通用结构是：

Step 1: classify task and risk
Step 2: identify required evidence
Step 3: retrieve or inspect evidence
Step 4: apply relevant policy
Step 5: check exceptions and conflicts
Step 6: decide automation / escalation boundary
Step 7: generate final output
Step 8: verify citations and trace

每一步都要定义 verification question。例如任务分类是否正确，证据是否来自授权和当前来源，政策是否为 active policy，例外是否覆盖，是否正确触发拒答或人工复核，最终输出是否有引用。

Step schema 可以包含 step_id、purpose、required_input、expected_output、forbidden_behavior、evidence_required、risk_tier 和 verifier。这样业务流程、AI trace 和 eval 可以对齐。

Verifier 不应全部交给 LLM judge：

过程监督的成熟度在于 verifier 组合，而不是把所有步骤都交给一个更强模型。

---

4. 为什么过程监督有效

第一，它提供更密集的反馈。最终答案只告诉你对错，步骤结果能告诉你错在任务分类、检索、政策应用、例外检查、边界判断还是最终表达。

第二，它能发现“结果对、路径错”。金融系统不能接受通过错误路径得到正确结论，例如没有检查 SLA 却碰巧升级，或没有引用政策却给出正确话术。

第三，它支持审计和事故复盘。团队能追溯使用了哪些数据、哪个政策版本、哪个工具返回了什么、哪个 gate 触发了人工复核。

第四，它适合 agent 发布门禁。Agent 会检索、调用工具、更新状态和生成输出，过程监督可以把这些动作拆成 gate，防止某一步错误直接扩散到业务动作。

---

5. 局限和误用

过程监督不等于展示完整 chain-of-thought。更适合给用户或 reviewer 展示证据摘要、适用政策、缺失信息、人工复核原因和批准状态；不应暴露未验证推理、敏感风控规则或可被攻击者利用的安全策略。

也不是所有任务都需要高强度过程监督。低风险 FAQ 改写可以轻量检查；支付争议、AML narrative、信贷文件总结、合规报告和自动工具动作则需要更强 step-level gate。

---

6. 架构和产品价值：流程模型转 Eval

过程监督最适合把 BPMN、操作流程和政策步骤转成 eval 与 release gate。

Workflow / BPMN
  -> step schema
  -> golden traces
  -> model / agent trace
  -> step verifier
      -> rules
      -> retrieval checks
      -> tool checks
      -> LLM judge
      -> SME review
  -> error localization
  -> release gate
  -> monitoring

Trace 需要记录 task_id、risk_tier、input_sources、retrieved_sources、tool_calls、policy_gates、step_outputs、verifier_results、human_decision、final_output 和 model_config。

上线门槛不应只看 overall accuracy。更关键的是 critical step pass rate、evidence grounding、policy freshness、escalation accuracy、error localization 和 process-final consistency。

---

7. 金融零售系统案例

7.1 Credit Underwriting Assistant

任务是帮助 underwriter 整理申请材料、政策依据、例外和复核点。过程步骤包括识别申请类型、提取收入/负债/抵押物、应用 active policy、检查 exception、识别 adverse action boundary、生成 memo。

关键 gate 是不使用 prohibited basis，不把模型建议作为审批结果，所有 material claims 有证据，高风险样本必须人工确认。

7.2 AML Alert Investigation

AML 助手需要识别 typology、聚合 KYC、覆盖交易证据、检查历史 alert、区分事实和推断、避免自动 SAR decision。

关键 gate 是无证据不得写成事实，高风险 typology 不能被低估，关闭 alert 的建议必须有明确依据并人工复核。

7.3 Payment Dispute Workflow

支付争议流程包括确认交易、分类 claim、查找网络规则、检查 SLA、列出证据缺口、生成客户消息。

关键 gate 是 SLA 风险必须显示，客户和商户证据冲突必须标记，自动发送消息必须通过 approved language。

7.4 Regulatory Reporting Assistant

监管报告助手要确认报告周期、实体和产品范围，拉取带 lineage 的数据，映射监管模板，标注缺失和估算，生成草稿并路由到合规复核。

关键 gate 是数据 lineage 必须保留，异常不能被摘要隐藏，任何估算必须明确标注。

---

8. Eval 数据设计

过程监督需要 golden trace，而不是只有最终答案。数据集应包括 full correct trace、early wrong trace、retrieval wrong trace、policy wrong trace、exception missing trace、boundary wrong trace、final answer wrong 和 deceptive trace。

指标包括：

unsafe pass rate 很重要，因为它衡量 verifier 是否放过了不该放过的错误。

---

9. 可交付资产

---

10. 学习验证

读完后应能回答：

1. Outcome supervision 和 process supervision 的差异是什么？
2. 为什么最终答案正确仍可能不可接受？
3. Process reward model 与工程 step verifier 有什么关系？
4. 为什么过程监督不等于展示完整 chain-of-thought？
5. 如何把 payment dispute 流程转成 step-level eval？
6. 如果模型给出正确结论但引用旧政策，应如何计分？
7. 如果 LLM judge 与 SME 不一致，如何校准？

真正掌握 process supervision 的标志，是能把复杂 AI 任务拆成可验证的业务步骤，并用 step-level gate 支撑上线、审计和持续改进。

---

SOTA 检查 (2026-07-01)

• 训练侧主线已变：主流开源推理 RL（DeepSeek-R1 的 GRPO 及后续 RLVR 谱系，2025-01 起）用的是可验证的 outcome/rule-based reward，而非训练出的 PRM——R1 报告明确因 reward hacking 和标注成本放弃 PRM 路线。本篇"process supervision 提供更密集训练信号"的原始训练结论在开源实践中已被部分替代，但 2026 年出现回摆：Verifiable Process Reward Models（VPRM，arXiv 2601.17223，2026-01）用确定性规则 verifier 检查中间步骤，VeriGate（arXiv 2605.30451，2026-05）把 verifier-gated step-level 监督接回 GRPO，"Internalizing Outcome Supervision into Process Supervision"（arXiv 2605.05226，2026-05）则提出在保持 outcome 主导的前提下融入过程信号。
• PRM 作为 test-time verifier/reranker 仍是现役方案：当前公开基准上的主流 PRM 是 Qwen2.5-Math-PRM、Skywork-PRM、Math-Shepherd 一系；Qwen 团队《The Lessons of Developing Process Reward Models in Mathematical Reasoning》（arXiv 2501.07301，2025-01，ACL Findings 2025）系统总结了 MC 自动标注偏差与 BoN 评估偏差，是 Let's Verify Step by Step（2023-05）之后该方向最重要的方法论修正。
• PRM 正从数学/代码扩展到 agent 与领域任务：AgentPRM（WWW 2026）对 agent 轨迹做 step-wise promise/progress 打分；Fin-PRM（arXiv 2508.15202，2025-08）是金融推理领域专用 PRM——与本篇第 7 节金融零售案例（信贷/AML/争议/监管报告的 step gate）方向一致，印证"领域化过程监督"是活跃前沿而非过时叙事。
• 不随版本过时的框架性结论：本篇的核心迁移——step decomposition、verifier 矩阵（规则/检索/工具/LLM judge/SME 分层而非全交给 LLM judge）、golden trace、critical step pass rate 与 unsafe pass rate、"结果对但路径错不可接受"——是工程与治理层的方法论，不依赖任何一代 PRM 训练技术；即使训练侧转向 RLVR，生产系统的 step-level gate 与审计轨迹需求只增不减。
• 库内配套（带日期，路径已验证）：训练侧对比见 docs/llm/day62-process-reward-model.md、docs/llm/day63-orm-vs-prm.md、docs/llm/day67-rlvr-verifiable-rewards.md、docs/llm/day65-grpo-deepseek.md（LLM-150，2026-10 完结）；工程落地见 docs/aipa/day16-llm-as-judge-rubric.md、docs/aipa/day17-judge-calibration.md、docs/aipa/day19-blocking-ci-eval-gate.md（AIPA-120，2026-06 完结）。