别在 AI 交付中迷信“端到端测试”：为什么“中间层断言 + 边界采样”才是质量底线

在 AI Lab 的实际交付过程中，我观察到一个非常普遍的误区：很多工程师习惯于将 LLM 应用视为一个“黑盒”，然后试图通过构建庞大的端到端（E2E）测试集来验证质量。他们会写几百个 Case，输入 Prompt，然后用另一个 LLM 来判断输出是否“看起来正确”。

这种做法在 Demo 阶段能快速跑通，但在生产环境下是极其危险的。因为 LLM 的随机性（Stochastic nature）决定了 E2E 测试的通过率并不代表系统的稳定性，而仅仅是某种“概率上的巧合”。

核心痛点：E2E 的“掩盖效应”

端到端测试最大的问题在于它掩盖了中间环节的失效。

假设你的 pipeline 是：`用户输入` $\rightarrow$ `意图识别` $\rightarrow$ `知识库检索` $\rightarrow$ `答案生成` $\rightarrow$ `最终输出`。

如果 E2E 测试结果是“正确”的，可能发生了两种截然不同的情况：

1. **链路全对**：每个步骤都精准执行。

2. **错误抵消**：意图识别错了，但检索恰好搜到了一个能勉强回答该问题的片段，生成模型又通过强大的泛化能力把答案给“圆”回来了。

在这种情况下，你的系统其实处于一个极不稳定的状态。一旦用户输入稍微偏移，或者知识库更新了一次，整个链路会瞬间崩塌。

解决方案：中间层断言 (Intermediate Assertions)

真正的 AI 工程化交付，必须将“黑盒”拆解为一系列可验证的“白盒”状态迁移。我们需要在每个关键节点引入**强类型断言**或**结构化校验**。

1. 意图识别层的“硬约束”

不要只检查 LLM 是否返回了正确的意图标签，而要检查该标签是否在预定义的枚举值中，并且其携带的参数是否符合 Schema 定义（例如使用 Pydantic 进行校验）。如果意图识别失败，直接触发 Fallback 机制，而不是让它带着错误的意图进入下一步。

2. 检索层的“相关度阈值”

在 RAG 链路中，不要直接把 Top-K 文档喂给模型。必须引入一个相关度分数（Score）的硬阈值断言。如果最高分低于 $0.7$，则判定为“未找到相关信息”，直接告知用户或引导至人工客服。这比让模型在没有参考资料的情况下强行“幻觉”出一个答案要专业得多。

3. 生成层的“事实锚点”校验

利用 LLM 的 Self-Correction 能力进行反向验证：要求模型在生成答案后，列出答案中每一个事实陈述所对应的原文档片段 ID。如果某个结论无法追溯到原文档，则该部分内容被标记为不可信并剔除。

从“全量覆盖”转向“边界采样” (Boundary Sampling)

面对海量的潜在输入空间，试图覆盖所有 Case 是不可能的。我们应该将精力从追求 $100\%$ 的 Case 通过率，转向对**边界条件**的极端采样。

- **负样本压力测试**：专门构造那些极其接近正确意图但实际上是错误请求的样本（Adversarial Examples），验证系统的拒绝能力。

- **长尾分布采样**：针对低频但高风险的业务场景进行深度挖掘，确保这些场景下的中间层断言依然生效。

- **漂移监控**：在生产环境中实时监控中间层断言的触发频率。如果某个节点的断言失败率突然升高，即使 E2E 指标依然好看，也意味着系统出现了潜在的模型漂移或数据污染。

总结

AI 交付不是关于如何写出完美的 Prompt，而是关于如何构建一套能够快速定位失效点的**观测体系**。

当你不再依赖于一个简单的 `is_correct=True` 的 E2E 判断，而是能够清晰地看到 `Intent_Valid -> Retrieval_Score > 0.7 -> Fact_Anchored = True` 这条确定性的链路时，你的 AI 应用才真正具备了工业级的鲁棒性。