repair/retry 二次推理如何分类错误并避免无限重试或语义漂移？

题型：深入 · 区分基础设施重试、格式修复和业务语义再生成。

建议回答

我会先把错误分为四类：限流、网络和临时超时等基础设施错误适合带退避重试；缺括号、代码围栏等明确且无歧义的格式错误可本地 repair；字段缺失、枚举错误和跨字段冲突适合把原始输入、原始输出和最小校验错误反馈给修复模型；输入非法、Schema 不兼容或安全规则命中则不可重试，应直接失败或转人工。

二次推理不能只说“请修好 JSON”，而要冻结原任务目标和不可变约束，让模型输出完整新对象或受控 Patch，并在修复后重新执行全部 Schema 与业务校验。每次尝试保存 promptVersion、modelVersion、validationErrors、输出摘要和 attempt，设置最大次数、总时长与 Token 预算；连续错误相同或质量无提升时提前终止。有效结果提交前不触发下游，因此重试不会重复下游副作用；如果上一步已经创建外部产物，则必须先查询或对账，不能把结果未知当普通失败。

Pydantic 只能证明对象符合已编码规则。人物设定是否忠于原剧本、分镜是否可拍等语义问题，仍要由确定性规则、独立校验模型或人工抽检覆盖。

关键权衡

• 本地 repair 延迟低，但只适合不会改变语义的机械修复。
• 重新生成可能纠正根本错误，也可能丢失原输出中正确字段并增加成本。
• 更严格 Schema 减少脏数据，却可能提高首轮失败率，需要与任务拆分共同设计。

易错点

• 不要把 temperature 调低当成完整的结构化输出保障。
• 不要无限追加错误信息和历史输出，Context 会膨胀并诱发新的语义漂移。