判断公式自纠正价值 = 修复的真实错误 − 引入的新错误 − 额外延迟与成本 − 过度拒答。只看“第二版更顺眼”会系统性高估收益。

先明确要纠正哪类错误

“质量不好”不是可执行的错误类型。格式错误可以用 Schema 校验;代码错误可用编译和测试;事实错误要对齐权威来源;计划遗漏要检查目标覆盖;业务与安全违规应由策略引擎判定。表达偏好才适合 rubric 或模型 Critic。

错误类型决定验证器与修复动作
错误优先验证信号修复动作
结构与字段解析、Schema、领域约束局部重生成或明确报错
事实与引用权威源、引用蕴含、时效重新取证,不是改写语气
Tool 参数/步骤Dry-run、契约、环境回执修参数、换动作或重规划
业务/安全策略确定性 Policy Decision阻断、审批或降权,不让模型覆盖
主观表达校准 rubric、成对比较在保留事实的前提下重写

纠正对象还应精确到 claim、字段、代码位置或任务节点。整篇重写会扩大变化面,可能修好一处同时破坏三处;局部修复更容易验证,但当核心假设错误时必须允许从取证或计划层重来。

优先使用独立、确定性的验证信号

Schema、编译、测试、查询和业务规则

能用确定性验证就不要先调用 Judge。确定性并不意味着完美:测试可能覆盖不足,Schema 只保证形状;但它们的失败语义稳定、可复现,适合作为第一道门。

权威数据源、引用对齐和多源核对

事实型输出要检查每个关键主张是否由可访问来源支持、来源是否权威且在时间范围内、引用是否真的蕴含该主张。多源一致不等于真相,但能暴露来源冲突;冲突应进入不确定或人工判断,而不是让模型投票制造确定性。

只有难以规则化时才用模型 Critic

Self-Refine展示了同一模型生成反馈并迭代改写的可能性;Reflexion则把任务反馈转成语言反思并放入情景记忆。二者是研究结果,不是“同模型自评必然可靠”的保证。生产系统仍要验证 Critic 与真实任务成功的相关性。

高影响或证据冲突进入人工

人工不是失败兜底箱,而是显式决策主体。升级请求应包含原目标、候选输出、失败证据、已尝试修复、影响范围和可选动作;只丢一句“模型不确定”会把排障成本转嫁给审批者。

验证层级:越向后越昂贵、主观,前层失败不应被后层“说服”覆盖
确定性检查解析、规则、编译、测试、后置条件。
外部事实来源、回执、对账和多源冲突。
模型 Critic难规则化的语义、覆盖和表达判断。
人工决定高影响、模糊或证据冲突。

自检应由风险和信号触发

对所有输出固定增加一轮 Critic,通常会让简单任务无谓增加延迟,也可能让正确答案被改坏。触发器应组合后果、失败信号与不确定性:高价值产物、不可逆动作前;规则验证失败;来源冲突;异常步骤数或重复动作;模型输出明确缺少证据。

所谓“置信度”必须校准。模型自报 0.9 不等于真实 90% 正确;若要用它路由,应在代表性数据上检验分桶后的实际错误率。没有校准时,优先依赖可观察异常和业务风险。

Critic 输出必须可行动

下面的 TypeScript 契约把 verdict、错误定位和允许修复动作分开。它是简化示例;生产实现还要使用运行时 Schema、版本字段和输入哈希。

type RepairAction =
  | 'patch_output'
  | 'regenerate'
  | 'retrieve_again'
  | 'replan'
  | 'escalate';

interface Finding {
  code: string;                    // 稳定原因码
  target: { kind: 'claim' | 'field' | 'step'; id: string };
  evidenceRefs: string[];
  message: string;
  action: RepairAction;
}

interface CriticResult {
  verdict: 'pass' | 'fail' | 'uncertain';
  findings: Finding[];
  checkedCriteria: string[];
  evaluatorVersion: string;
}

“可以更完善”“建议补充细节”不合格,因为修复器不知道改哪里、用什么证据、何时通过。Critic 还必须声明检查过哪些条件,避免一个只检查风格的 Judge 给整个任务签发“通过”。

修复循环要有边界

每轮只回注必要的 finding、原目标、相关证据与不可改变约束。Runtime 根据原因码选择动作,而不是默认全量重新生成:解析错误局部修补;证据不足重新检索;核心假设错误重规划;政策违规直接阻断;高风险不确定进入人工。

  1. 运行独立验证器并固化 finding;
  2. 计算本轮剩余预算与修复价值;
  3. 选择最小变化面的修复动作;
  4. 重新运行受影响检查,并回归未受影响的不变量;
  5. 通过、预算耗尽、同类失败重复或风险升级时终止。

连续同类失败说明当前证据、能力或策略没有改变,再循环只会产生措辞漂移。用错误指纹检测停滞,并转为换模型、换工具、请求新信息或人工,而不是把最大轮数当唯一退出机制。

防止评估器与生成器共享盲点

独立性可以来自不同信号,而不必机械使用不同模型。编译器、数据库约束和外部回执比“另一个 LLM”更独立。必须用模型 Judge 时,可分离 Prompt 和证据视图、隐藏候选身份或顺序、使用人工校准集,并监控位置偏差、冗长偏好和同族模型共享误差。

还要测“修复后变差”:原输出正确却被 Critic 判错,或局部修改破坏了其他约束。评测数据应保留 pass-through 样本、故意错误样本和难以判断样本,不要只统计被成功修好的案例。

证明自纠正不是昂贵装饰

至少设置三组:无纠正基线、当前纠正策略、简单重试或更强模型替代。按错误类型统计初始错误数、真实修复数、新增错误数和最终失败,结合额外 Token、P50/P95 延迟、人工介入与过度拒答。

推荐指标净修复率 =(修复且未引入回归的样本 − 原本正确却被改坏的样本)/ 触发纠正的样本。它不能替代端到端成功率,但能阻止团队用“修改次数”冒充价值。

上线策略应按风险分层:低价值简单任务禁用;可确定性检查的任务按失败触发;高影响输出可强制多层验证;高风险动作即使 Critic 通过也不绕过策略与审批。把策略写入 RFC,并用线上抽样和漂移检测持续复审。

主动提取:为什么换一个同系列模型做 Judge 仍不等于独立验证?
模型可能共享训练分布、提示诱导和事实盲点;独立性应优先来自不同机制与权威证据。不同模型只能降低部分相关性,仍需校准集证明。
故障判断:同一事实错误连续两轮都被改写但未重新检索,应该继续吗?
不应。证据没有变化,循环只改变措辞。应触发 retrieve_again、明确不确定或人工升级,并用错误指纹阻止重复修补。

资料与事实边界

以下以官方文档、标准、论文和原始工程资料为主。厂商 API、价格、限额与模型能力会变化,落地时仍需按目标版本做能力探测和回归。

  1. Shinn et al.:Reflexion — 将任务反馈转成语言反思与情景记忆的原始研究
  2. Madaan et al.:Self-Refine — 生成、反馈、迭代改写范式的原始研究
  3. Anthropic:Building Effective AI Agents — Evaluator-optimizer 的适用条件与可测量价值边界
  4. OpenAI:Evaluation best practices — 评测设计、自动评分与人工校准的官方实践