别让“幻觉”成为交付的遮羞布：在 AI Lab 中建立基于确定性的验证闭环

在很多 AI Lab 的交付现场，最令人焦虑的时刻不是模型不聪明，而是它“偶尔”会犯错。当客户问起“为什么这次结果错了”时，很多团队习惯于用一个模糊的词来掩盖：幻觉 (Hallucination)。

但从工程交付的角度来看，“幻觉”这个词是危险的。因为它暗示了错误是不可预测、不可避免且随机发生的。如果一个交付物被定义为“偶尔会有幻觉”，那么它在商业逻辑上就是不可用的。

真正的 AI 工程化，应该是将“概率性的生成”包裹在“确定性的验证”之中。

从“提示词优化”到“验证闭环”

大多数团队在面对错误时的路径是：发现错误 $\rightarrow$ 修改 Prompt $\rightarrow$ 测试 $\rightarrow$ 发现新错误 $\rightarrow$ 再次修改 Prompt。这是一个典型的死循环，因为你试图用一个概率性的工具（LLM）去修复另一个概率性的结果。

在实际的 AI Lab 交付中，我们推崇的是验证闭环 (Verification Loop)。其核心逻辑是：不信任 LLM 的自评，只信任可编程的断言。

1. 定义“硬性约束”断言

不要问模型“你刚才生成的答案正确吗？”，而要编写代码去检查：
- 格式断言：输出是否严格符合 JSON Schema？
- 引用断言：答案中的每一个事实点是否都能在检索到的 Context 中找到原文索引？（通过计算 Token 重叠度或使用小型 Cross-Encoder 模型）
- 逻辑断言：如果答案包含数值计算，是否可以通过 Python exec() 或简单的正则提取并重新计算一遍？

2. 构建“负样本”回归集

很多团队只关注 Positive Case（跑通了没），而忽略了 Negative Case（怎么才算错）。
一个成熟的交付项目需要维护一个 $\text{Error-Bank}$：记录所有曾经出现过的幻觉案例，将其转化为测试用例。每次 Prompt 更新后，必须确保这些历史错误不再复现，而不是仅仅看几个新例子跑得顺不顺。

实践案例：知识库 RAG 的确定性增强

在一个金融文档分析的项目中，我们遇到了典型的“细节幻觉”——模型会把 A 公司的营收数据安在 B 公司头上。

我们放弃了通过增加 System Prompt（如“请仔细核对公司名称”）来解决问题，而是引入了一套双路校验机制：
1. 提取路：LLM 生成答案的同时，必须强制输出 {"fact": "...", "source_chunk_id": "..."} 的结构化列表。
2. 校验路：由一个轻量级的 Python 脚本遍历所有 source_chunk_id，检查该 Chunk 中是否真的包含 fact 中的关键实体和数值。如果校验失败，直接触发重试或标记为“无法确认”。

这种做法将准确率从 85% 提升到了 98%，且最重要的是，我们能给客户一个确定的解释：“这里没有关闭是因为校验路未能在原文中找到证据”，而不是“模型产生了幻觉”。

给 AI 工程团队的建议

AI Lab 的交付不是在写诗，而是在构建工业流水线。请记住以下三点：
- 警惕 Prompt 依赖症：当你发现自己连续三天在微调同一个 Prompt 的措辞时，你应该考虑的是增加一层代码层面的验证逻辑。
- 量化错误分布：不要说“感觉好多了”，要说“在 500 个回归集样本中，幻觉率从 12% 下降到了 3%”。
- 接受“不知道”：一个敢于承认“根据现有资料无法得出结论”的 Agent，比一个一本正经胡说八道的 Agent 要值钱得多。

真正的炼金术不是把铅变成金子，而是通过严苛的过滤和纯化，剔除掉所有的杂质。