别让“模型能力”掩盖了“工程缺陷”：AI 交付中的鲁棒性陷阱

在 AI Lab 的实际交付过程中，最危险的时刻往往不是模型表现不佳的时候，而是模型表现“看起来很完美”的时候。

很多团队在 Demo 阶段会陷入一个典型的认知误区：只要通过精心挑选的几个 Test Case 证明模型能跑通，就认为交付已经完成了 80%。但事实上，在 AI 工程化领域，从 Demo 到 Production 的距离，不是 20% 的代码量，而是 100% 的鲁棒性重构。

“Demo 成功”的幻象

我曾接手过一个企业级知识库项目。在验收演示时，模型对所有预设问题的回答都精准得令人惊叹。但上线第一周，系统就因为大量“非预期输入”而崩溃——用户输入的不是标准问题，而是包含大量口语碎屑、错别字，甚至是完全无关的情绪化表达。

这就是典型的“鲁棒性陷阱”。当开发者在受控环境下测试时，潜意识里会给模型提供“高质量”的输入。而真实世界的用户输入是混沌的。如果你的交付逻辑依赖于模型在特定 Prompt 下的某种“灵光一现”，那么这种成功就是脆弱的。

从“炼金术”转向“工程化”

要打破这个陷阱，AI Lab 需要将关注点从单纯的 Prompt Tuning（炼金术）转向工程化的防御体系：

1. 输入端的“强力过滤”与标准化

不要试图用一个巨大的 Prompt 让模型处理所有异常。在进入 LLM 之前，必须建立一套前置处理流水线：
- 意图识别（Intent Classification）：先判断用户是在提问、在抱怨还是在尝试攻击（Prompt Injection）。
- 输入清洗：利用轻量级模型或正则对噪声进行剔除。
- 格式强制化：通过 Few-shot 或结构化指令，将模糊输入转化为模型易于理解的标准格式。

2. 输出端的“确定性校验”

永远不要信任 LLM 直接输出的结果。对于关键业务逻辑，必须引入校验层：
- Schema 验证：如果要求输出 JSON，必须使用 Pydantic 或类似工具进行强类型校验，失败则触发自动重试或降级方案。
- 幻觉检测：针对 RAG 场景，引入 NLI（自然语言推理）检查答案是否真的由检索到的文档支撑，而非模型自创。
- 边界拦截：建立敏感词和合规性拦截库，确保输出不越界。

3. 构建“负样本”测试集

大多数团队只关注 Positive Cases（正确案例），但决定交付质量的是 Negative Cases（失败案例）。
我们需要刻意构建一个测试集：
- 对抗性输入：故意诱导模型产生幻觉或跳出角色设定。
- 极端边界值：超长文本、空输入、乱码输入。
- 歧义表达：同一个词在不同语境下的多种含义。

写在最后

AI 的能力上限决定了产品的潜力，但工程的下限决定了产品的生死。一个能够稳定处理 95% 普通请求且对 5% 异常请求有优雅降级方案的系统，远比一个能处理 100% 精选案例但偶尔会彻底崩溃的系统更有价值。

真正的 AI 工程化交付，就是承认模型的不可预测性，并用确定性的工程手段将其包裹起来。