告别“幻觉”：在 AI Lab 交付中建立可验证的工程闭环

在很多 AI 实验室或初创团队的交付流程中，最令人头疼的不是模型能力不足，而是“不可预测性”。当你向老板或客户演示一个 Agent 流程时，它可能在 9 次中表现完美，但在第 10 次时突然陷入死循环，或者一本正经地胡说八道。

这种现象在工程上被称为“随机性漂移”。如果你的交付物仅仅是“一个 Prompt + 一个 LLM”，那么你交付的不是产品，而是一个概率分布。

从“调优 Prompt”到“构建闭环”

很多开发者习惯于通过不断修改 Prompt 来修复 Bug。例如：发现模型在处理日期时出错 $\rightarrow$ 在 Prompt 中加入“请注意日期格式必须为 YYYY-MM-DD” $\rightarrow$ 测试通过 $\rightarrow$ 发布。

这种“打补丁”模式在复杂系统中会迅速崩溃，因为每一个新补丁都可能在另一个边缘场景触发新的幻觉。真正的工程化交付需要从“调优”转向“闭环”。

1. 定义可量化的“黄金数据集”（Golden Dataset）

不要依赖于随机的对话测试。你需要为每个核心功能构建一个包含 50-100 个典型用例的黄金数据集。
- 输入：具体的用户请求。
- 预期输出：不仅是文本，而是关键字段（如 JSON key）或状态转移（如：调用了哪个 Tool）。
- 判定标准：定义什么是“正确”。是语义一致？还是正则匹配？还是通过了下游代码的校验？

2. 实现“影子测试”与回归流水线

在每次修改 Prompt 或升级模型版本后，必须强制运行全量回归测试。
- 自动化比对：使用 LLM-as-a-Judge（用更强的模型如 GPT-4o 或 Claude 3.5）来对比新旧版本的输出差异。
- 差异分析：重点关注那些从“正确”变为“错误”的案例，而不是关注整体得分的微小提升。

3. 将约束下沉到代码层（Guardrails）

不要试图用自然语言命令模型“绝对不要做某事”。要把约束写在代码里：
- Schema 强制校验：使用 Pydantic 或 JSON Schema 对模型输出进行强类型校验。如果校验失败，直接触发重试机制或回退到安全模式，而不是将错误传递给用户。
- 状态机控制：Agent 的跳转逻辑应由确定性的状态机驱动，LLM 只负责决定当前状态下的动作（Action），而不负责决定整个流程的拓扑结构。

实战教训：一次关于 API 调用失败的处理

我们在一个自动化报告生成项目中曾遇到过这样的问题：模型在调用外部 API 失败时，会尝试伪造一个看起来很真实的 API 返回结果来维持对话流畅度。这导致最终生成的报告中出现了大量虚假数据。

解决方案：
我们引入了一个简单的中间件层。所有 Tool 的返回结果在交给 LLM 之前会被打上 [SYSTEM_VERIFIED] 标签；同时，我们在 System Prompt 中明确规定：“如果你看到的上下文没有 [SYSTEM_VERIFIED] 标签且 API 返回错误，你必须直接告知用户‘数据获取失败’，严禁基于常识推测结果。”

通过将“真实性”的判定权从 LLM 的自觉性转移到系统标签上，我们将该场景的幻觉率从 15% 降低到了接近 0%。

总结

AI 工程化的本质是用确定性的工程手段去包裹不确定性的概率模型。当你不再追求一个“完美的 Prompt”，而是开始构建一套能够快速发现错误、量化质量并强制执行约束的流水线时，你的 AI 应用才真正具备了生产环境的可交付性。