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

在 AI 实验室（AI Lab）从 Demo 走向生产交付的过程中，最令工程师头疼的不是模型不够强，而是模型不可控。很多团队在交付初期会陷入一个循环：发现 Bug $\rightarrow$ 修改 Prompt $\rightarrow$ 测试通过 $\rightarrow$ 发现另一个 Bug $\rightarrow$ 修改 Prompt $\rightarrow$ 原本通过的 Case 又挂了。

这种“打地鼠”式的开发模式，本质上是因为缺乏一套可验证的工程闭环。

从“感觉不错”到“量化通过”

大多数 AI 交付的失败始于对质量的模糊定义。当产品经理说“这个回答感觉有点生硬”或者“偶尔会胡说八道”时，这在工程上是不可执行的指令。

要打破这个局面，第一步是将“体感”转化为“数据集”。我们建立了一套名为 Golden Dataset (金标集) 的机制：
1. Case 萃取：将所有线上报错、用户投诉、以及预期中的边界情况，全部转化为 (Input, Expected_Output, Evaluation_Criteria) 的三元组。
2. 评测维度拆解：不再使用单一的“正确/错误”，而是将维度拆解为：
- 事实准确性 (Factuality)：是否包含虚假信息？
- 指令遵循度 (Instruction Following)：是否满足了所有格式要求？
- 安全性 (Safety)：是否触发了敏感词或违规输出？

构建自动化评测流水线 (Eval Pipeline)

手动测试是不可持续的。在实际交付中，我们引入了 LLM-as-a-Judge 的架构，利用更高能力的模型（如 GPT-4o 或 Claude 3.5 Sonnet）作为裁判来审计轻量级模型的输出。

我们的流水线逻辑如下：
Prompt 修改 $\rightarrow$ 全量 Golden Set 推理 $\rightarrow$ Judge 模型打分 $\rightarrow$ 回归报告。

在这个过程中，最关键的是 Judge Prompt 的稳定性。为了防止裁判模型本身产生幻觉，我们采用了“少样本引导 (Few-shot)”和“思维链 (CoT)”要求裁判模型先给出理由，再给出分数。例如：

“请先分析输出内容与参考答案在事实点上的差异，列出具体不一致的地方，最后根据差异程度给出 1-5 分。”

处理“长尾幻觉”的工程手段

即便有了评测集，AI 依然会在某些极端 Case 上翻车。此时，单纯靠调优 Prompt 已经触及天花板，我们需要引入工程化的约束手段：

1. RAG 的强制锚定

为了解决知识性幻觉，我们实施了 Citation Enforcement (引用强制)。要求模型在生成每一段结论时，必须标注来源片段的 ID（如 [Source 1]）。如果模型无法在上下文中找到支撑点，则必须回答“无法从现有资料中得出结论”。这直接将生成问题转化为了检索匹配问题。

2. 输出格式的硬约束

对于需要对接下游系统的 API 调用或结构化数据，我们弃用了纯文本生成，全面转向 JSON Schema 强制校验。通过 Pydantic 等库在运行时拦截不合规的输出并触发自动重试（Self-Correction），确保系统不会因为一个多余的逗号而崩溃。

小结：AI 工程化的本质是回归传统软件工程

AI Lab 的交付过程看似是在与随机性搏斗，但其核心依然是软件工程的基本功：定义输入输出 $\rightarrow$ 构建测试用例 $\rightarrow$ 实现自动化回归 $\rightarrow$ 持续迭代优化。

当你不再依赖于“这次运气好通过了”，而是能够自信地说出“这次修改让 Golden Set 的通过率从 82% 提升到了 91%，且没有引起任何回归错误”时，你的 AI 项目才真正具备了交付能力。