主题
LLM 结果频繁校验失败、修复后仍错或字段悄悄漂移时怎么排查？
题型：问题排查 · 保留原始输出，按版本和错误层级定位。
排查顺序
- 固定失败样本的 input、promptVersion、schemaVersion、modelVersion 和参数，比较最近变更前后的首轮通过率，先判断是全量回归还是特定剧本结构触发。
- 查看未经清洗的原始输出和完整校验错误，区分截断、非 JSON、字段缺失、类型转换、枚举漂移、引用不存在和业务语义冲突。
- 检查 Pydantic 默认值、别名和宽松类型转换是否把错误“修成”了合法对象，字段悄悄漂移往往比显式失败更难发现。
- 对 repair 轨迹比较每轮改动，确认错误反馈是否过长或互相冲突、修复 Prompt 是否丢失原始约束、模型是否在补一个字段时重写了其他正确字段。
- 基础设施超时要区分请求失败与结果未知；纯文本生成可安全再请求，但已经被下游消费或产生外部产物时必须先冻结传播并对账。
止损与永久修复
先冻结有问题的 Prompt、Schema 或模型版本，把未通过业务校验的结果放入隔离区，不允许静默进入分镜和关键帧阶段。永久修复可能是补充显式约束、收紧类型、拆分超大 Schema、改为受控 Patch repair，或为高风险字段增加确定性校验与人工抽检。
验证与复盘
把故障样本、边界样本和正常样本加入版本化回归集，分别验证首轮输出和 repair 路径；灰度新版本时同时观察通过率、字段准确率、尝试次数和成本。复盘要记录根因属于模型、Prompt、Schema、输入数据还是恢复策略。
易错点
- 不要在预处理阶段删除原始模型响应，否则无法判断模型错误还是解析器错误。
- 不要把所有历史失败样本直接塞回 Prompt，可能增加 Token 和过拟合风险。