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

在很多 AI 实验室或初创团队的交付流程中，最令人头疼的不是模型能力不足，而是“不可预测性”。

一个典型的场景是：工程师在本地 Notebook 里通过几个精心挑选的 Case 证明了 Prompt 的有效性，信心满满地推向生产环境。结果上线一小时后，用户反馈大量奇怪的输出——模型开始胡言乱语，或者在某些边缘场景下完全失效。

这种现象我们称之为“交付幻觉”：误以为局部验证的成功等同于系统级的鲁棒。要打破这个循环，我们需要将 AI 的交付从“文学创作”转向“工程验证”。

从 Case-by-Case 到 Eval-Driven

大多数团队的迭代路径是：修改 Prompt $\rightarrow$ 手动测试 3 个 Case $\rightarrow$ 觉得 OK $\rightarrow$ 部署。

这种路径最大的问题在于缺乏回归测试。当你为了修复 Case A 而修改 Prompt 时，你可能在无意中破坏了原本正常的 Case B。

工程化方案：构建最小可行评估集 (Golden Dataset)
不要试图覆盖所有场景，但必须建立一个包含 50-100 个核心场景的 Golden Set。每个 Case 包含：
1. Input: 标准输入。
2. Expected Output/Constraint: 不是要求字对字一致（这在 LLM 中不可能），而是定义“通过”的标准（例如：必须包含某个关键词、JSON 格式必须正确、不能出现特定禁词）。
3. Failure Reason: 当该 Case 失败时，预期的失败模式是什么。

每次 Prompt 修改后，必须运行全量 Eval。只有当 New_Pass_Rate >= Old_Pass_Rate 且 Critical_Cases 全部通过时，才允许合并代码。

处理“非确定性”的三个技巧

LLM 的随机性是工程化的天敌。在交付过程中，我建议采取以下三种策略来降低不确定性：

1. 结构化输出的强约束

不要依赖模型“尽量输出 JSON”。使用 Pydantic 或 JSON Schema 进行强制校验。如果模型输出格式错误，直接触发一次自动重试（Retry Loop），并在日志中记录重试次数。如果连续三次失败，则判定为系统级故障而非随机波动。

2. 少样本 (Few-Shot) 的动态注入

静态的 Few-Shot 往往覆盖面不足。更高效的做法是建立一个向量数据库（Vector DB），存储高质量的 $\text{Input} \rightarrow \text{Output}$ 对。根据当前用户的输入，动态检索最相似的 3 个例子注入到 Prompt 中。这能显著提升模型在特定领域任务中的稳定性。

3. 分解复杂链路 (Chain of Thought $\rightarrow$ Pipeline)

不要试图用一个巨大的 Prompt 完成所有事情。将任务分解为：意图识别 $\rightarrow$ 参数提取 $\rightarrow$ 知识检索 $\rightarrow$ 最终生成。
每一个环节都可以独立进行单元测试和评估。当结果出错时，你可以迅速定位是哪个环节出了问题，而不是对着一个 2000 字的 Prompt 发呆猜测哪里写错了。

给交付团队的 Checklist

如果你正处于 AI 项目的交付阶段，请检查你的流程是否包含以下项：
- [ ] 是否有一个版本化的 Golden Dataset？
- [ ] 是否实现了自动化 Eval 脚本（而非手动抽检）？
- [ ] 是否对所有 LLM 调用设置了超时和重试机制？
- [ ] 是否有针对结构化输出的 Schema 校验？
- [ ] 是否记录了生产环境中的 Bad Cases 并将其反哺到评估集中？

AI 工程化的本质就是用确定性的流程去管理不确定性的模型。当你不再依赖“感觉”，而是依赖“指标”时，交付才真正开始变得可控。