只有在线模型才能教会我们的 6 个 Bug
离线测试是必要的，但仅有它们是不够的。
我构建了 AgentOps Debugger 来追踪秘鲁的环境合规情况。它使用 Qwen Cloud 上的 Qwen-plus 来查找记录并编写报告。
我将系统设计为离线优先。我的 315 项测试在没有任何网络调用的情况下运行，全部通过。但当我切换到阿里云上的在线模型时，系统崩溃了。
代码没问题，问题在于模型的输出。
以下是从真实模型故障中总结出的六条教训：
• 标签不匹配 (Label Mismatch) Schema 预期的是 "completed" 或 "failed"，但模型发送的是 "success" 或 "done"。解析器因为一个单词就拒绝了有用的答案。 修复方案：使用具有容错能力的预处理器来规范化同义词。
• 退化计划 (Degenerate Plans) 规划器有时会返回空结果。应用程序试图将这种“沉默”转化为正常的响应，从而产生了虚假答案。 修复方案：添加一个计划解释器。如果计划为空，请告知用户系统规划失败，而不是撒谎。
• Schema 漂移 (Schema Drift) 模型将字段名从 "documentTitle" 改成了 "title"，还混用了英文和西班牙文标签。 修复方案：使用别名映射并挽救有效部分。如果其中一个引用失效，保留其他四个。
• 任务不匹配 (Unpaired Tasks) 模型在起草报告之前就要求保存报告。逻辑上是安全的，但用户体验很糟糕。 修复方案：代码必须能够检测缺失的步骤并自动插入它们。
• 循环错误 (Loop Errors) 即使在用户回答后，模型仍会不断询问相同的澄清问题。 修复方案：将实体解析 (entity resolution) 从模型转移到代码中。一旦用户提供了数据，系统应以确定性的方式处理剩余工作。
• 虚假歧义 (False Ambiguity) 模型声称某个公司名称存在歧义，但实际上并没有。这导致工作流中断。 修复方案：允许模型提出歧义的可能性，但由数据来决定这种歧义是否真实存在。
核心原则： 让 LLM 负责叙述，但不要让它掌控结构化结果。
模型应该处理意图、规划和语言。代码必须处理实体解析、图表数据和报告组装。
当你能将每一个结论追溯到一条记录时，系统才会变得值得信赖。用模型来讲述故事，用代码来还原真相。
Source: https://dev.to/ginollerena/six-bugs-only-a-live-model-could-teach-us-57k5
Optional learning community: https://t.me/GyaanSetuAi