Process Supervision：Step-by-Step Verification
Process supervision 的核心:
Process Supervision / Step-by-Step Verification 解读
面向对象: AI PM / AI BA / AI Architect / EvalOps / Model Risk。 核心问题: 对复杂推理任务，只看最终答案是否正确够不够？什么时候需要评估中间步骤？ 学习目标: 理解 process supervision、outcome supervision、step-level verification 和 reasoning eval 对企业 AI 的意义。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Let's Verify Step by Step | https://arxiv.org/abs/2305.20050 | 理解 process supervision 相比 outcome supervision 的价值 |
| Chain-of-Thought Prompting | https://arxiv.org/abs/2201.11903 | 理解中间推理步骤对复杂任务的影响 |
| Self-Consistency | https://arxiv.org/abs/2203.11171 | 理解多路径推理和选择 |
| Tree of Thoughts | https://arxiv.org/abs/2305.10601 | 理解搜索式推理和中间状态评估 |
Process supervision 的核心:
不只评价最终答案，还评价通向答案的每一步是否合理、被证据支持、符合规则。
1. Outcome Supervision vs Process Supervision
| 维度 | Outcome Supervision | Process Supervision |
|---|---|---|
| 评估对象 | 最终答案 | 中间步骤和最终答案 |
| 优点 | 标注更简单 | 能定位错误路径 |
| 缺点 | 不知道哪里错 | 标注成本高 |
| 适合 | 简单分类、明确答案 | 多步推理、合规判断、复杂流程 |
| 企业价值 | 快速质量指标 | 可解释、可审计、可调试 |
金融零售里，很多任务不能只看最终输出:
- 信贷建议。
- AML narrative。
- 投诉处理。
- 支付争议。
- 合规报告。
因为错误可能隐藏在推理中间。
2. 为什么最终答案正确仍然可能不安全
例子:
信贷助手给出“需要人工复核”的最终建议。
最终建议可能正确，但中间理由可能错误:
- 使用了不允许的敏感属性。
- 忽略了政策例外。
- 引用了过期政策。
- 混淆客户身份。
- 编造证据。
这意味着:
结果对，不代表过程可接受。
3. Step-Level Verification
将推理拆成步骤:
Step 1: identify task
Step 2: gather relevant evidence
Step 3: apply policy
Step 4: check exceptions
Step 5: decide output boundary
Step 6: generate final answer
每一步都可以评估:
| Step | Verification question |
|---|---|
| task identification | 是否识别正确任务和风险等级 |
| evidence gathering | 是否使用正确来源 |
| policy application | 是否引用 active policy |
| exception check | 是否覆盖例外 |
| boundary decision | 是否触发 HITL/refusal/escalation |
| final output | 是否清晰、完整、合规 |
4. PM 视角: 什么时候值得做过程监督
过程监督成本高，不是所有任务都需要。
| Task | Need process supervision? | Reason |
|---|---|---|
| FAQ 改写 | 低 | 结果易判定 |
| 客服政策问答 | 中 | 需要引用和话术边界 |
| 信贷文件总结 | 高 | 影响客户和合规 |
| AML 调查摘要 | 高 | 证据链和监管风险 |
| 支付争议处理 | 高 | SLA、规则、客户影响 |
| 代码生成 | 中高 | 过程可用测试覆盖部分替代 |
PM 要用 risk tier 决定评测深度。
5. BA 视角: 流程步骤就是评测步骤
BA 的流程建模可以直接变成 process eval。
Payment Dispute Example
| Business process step | Eval question |
|---|---|
| 确认交易 | 是否提取金额、时间、商户、渠道 |
| 确认客户 claim | 是否区分 fraud / non-fraud dispute |
| 查网络规则 | 是否引用正确 rule |
| 检查 SLA | 是否识别 deadline |
| 判断证据缺口 | 是否列出 missing evidence |
| 生成草稿 | 是否避免承诺退款 |
AML Example
| Business process step | Eval question |
|---|---|
| 识别 alert typology | 是否匹配交易模式 |
| 聚合 KYC | 是否使用 current profile |
| 查看历史 alert | 是否检查 previous disposition |
| 证据分析 | 是否区分事实和推断 |
| 结论边界 | 是否避免过早关闭 |
| 草稿生成 | 是否有 evidence citation |
6. 架构师视角: Process Eval Pipeline
Workflow Spec
-> Step Schema
-> Golden Cases
-> Step Labeling
-> Model Output Trace
-> Step Verifier
-> rules
-> retrieval checks
-> LLM judge
-> SME review
-> Error Localization
-> Release Gate
Step Schema
| Field | Example |
|---|---|
| step_id | apply_policy |
| required_input | policy_source, customer_segment |
| expected_behavior | apply active policy, cite source |
| forbidden_behavior | use expired policy |
| evidence_required | source id + section |
| risk_tier | high |
| verifier | rule + SME sample |
7. Process Reward Model vs Rule Verifier
Research 中的 process reward model 用模型学习判断步骤好坏。
企业落地可以混合:
| Verifier | 适合 |
|---|---|
| rule verifier | 硬规则、权限、字段、格式 |
| retrieval verifier | citation、source、freshness |
| LLM judge | 语义完整性、rationale quality |
| SME review | 高风险样本和 calibration |
| system tests | 工具调用、状态、API 行为 |
不要把所有 step verification 都交给 LLM judge。
8. 与 Chain-of-Thought 展示的边界
过程监督不等于向最终用户展示完整 chain-of-thought。
更适合展示:
- evidence summary。
- decision checklist。
- policy applied。
- missing information。
- confidence factors。
- human approval status。
不建议展示:
- 原始长推理。
- 未校验 speculation。
- 敏感内部策略。
- 可以被攻击者利用的安全规则细节。
9. 金融零售案例
9.1 Credit Underwriting
过程监督步骤:
- 识别申请类型。
- 提取收入/负债/抵押物。
- 应用 policy。
- 检查 exception。
- 识别 adverse action risk。
- 生成 underwriter memo。
关键 gate:
- 不使用 prohibited basis。
- 所有 policy claim 有来源。
- 高风险输出人工审批。
9.2 Compliance Report Assistant
过程监督步骤:
- 明确报告周期。
- 拉取正确数据。
- 应用监管模板。
- 标注缺失数据。
- 生成草稿。
- 合规复核。
关键 gate:
- 不把估算当事实。
- 不漏报异常。
- 保留数据 lineage。
10. Eval 数据设计
| Dataset type | 内容 |
|---|---|
| full correct trace | 每一步都正确 |
| early wrong trace | 第一步识别错任务 |
| evidence wrong trace | 用错来源 |
| policy wrong trace | 应用旧政策 |
| exception missing trace | 漏例外 |
| boundary wrong trace | 未触发 HITL |
| final answer wrong | 过程对但输出错 |
Metrics
| Metric | Definition |
|---|---|
| step accuracy | 每步正确率 |
| critical step pass rate | 高风险步骤通过率 |
| error localization rate | 能否定位错误步骤 |
| final correctness | 最终答案正确 |
| process-final consistency | 过程和结论一致 |
| human review agreement | 与 SME 一致 |
11. 作品集输出
| Artifact | 内容 |
|---|---|
| Process Eval Map | 把 BPMN/流程步骤转成 eval steps |
| Step Schema Library | 每步输入、行为、证据、风险、verifier |
| Golden Trace Set | 正确和错误过程样本 |
| Release Gate | critical step threshold |
| Audit Evidence Note | 为什么过程可接受 |
12. 面试表达
30 秒版本
Process supervision 不只看最终答案，而是评估中间步骤是否正确、被证据支持、符合业务规则。金融高风险任务里，结果对但过程用了错误政策或敏感属性也不能接受。
2 分钟版本
Outcome supervision 只评价最终答案，标注简单但难定位错误。Process supervision 会把任务拆成步骤，比如识别任务、收集证据、应用政策、检查例外、决定是否升级、生成最终输出。每一步都有 verifier，可以是规则、检索检查、LLM judge 或 SME review。对 AML、信贷、支付争议和合规报告，这能把 BA 的流程模型直接变成 eval 和 audit evidence。上线门禁不只看最终 accuracy，还看 critical step pass rate、error localization、policy compliance 和 human review agreement。
CTO 深挖
我会把 process eval 绑定 trace schema。系统需要记录任务分类、检索来源、工具调用、policy gate、HITL decision 和最终输出。这样才能定位错误在 retrieval、reasoning、policy、tool 还是 UX。
13. 复习问题
- outcome supervision 和 process supervision 的区别是什么？
- 为什么最终答案正确仍然可能不可接受？
- BA 流程模型如何转成 step-level eval？
- 哪些 verifier 适合硬规则，哪些适合语义质量？
- 为什么不应该把完整 chain-of-thought 展示给最终用户？
- Process supervision 如何支持审计和模型风险管理？
- 在金融零售中，哪些任务必须做 critical step gate？