AI 演示跳过的五个关卡：LLM 功能发布就绪清单

AI 功能发布中存在一个重复出现的模式：演示（demo）惊艳全场，功能正式上线，两周内发生了一些灾难性的事情。不是宕机——那些很容易捕捉。而是一些更微妙的事情：模型自信地生成错误信息，成本飙升到预期三倍，或者在真实负载下延迟激增导致功能无法使用。团队手忙脚乱，功能被悄悄禁用，大家一致同意“下次做得更好”。

问题不在于演示做得不好。问题在于演示成了唯一被重视的测试。

LLM 功能在生产环境中的失败方式与传统软件不同。它们是非确定性的，所以行为会在代码未更改的情况下发生变化。它们具有肥尾延迟分布（fat-tailed latency distributions），因此平均性能看起来不错，而最差的 5% 的用户会遇到超时。它们消耗的资源与用户行为成正比，因此一个话唠用户可能会让你的 API 账单激增，而负载测试永远无法揭示这一点。而且它们可能会静默失败——返回 HTTP 200 却带有自信幻觉的内容——而每一个基础设施指标都显示正常。

这些失败模式都不会出现在演示中。演示是理想情况：受控的输入、精心准备的提示词、宽容的评估者。生产环境则恰恰相反。

这就是你的演示跳过的清单。

---

关卡 1：评估覆盖率

AI 功能发布中最常见的失败是在不知道失败率到底有多严重的情况下就上线。团队针对一组理想路径场景（happy-path scenarios）运行精心挑选的测试集，达到 95% 的准确率，然后发布。接着他们发现生产环境的用户以他们从未预料到的方式与系统交互，准确率下降到 70%。

这不是运气不好。这是 AI 功能发布前评估方式的结构性问题。

准备好进入生产环境的评估需要三样东西，而演示用的评估通常会跳过它们：

统计覆盖，而非挑选的例子。 你需要一个接近真实用户行为的测试集，包括边缘案例、对抗性输入以及你的产品将收到的长尾查询。对于 RAG 系统，这意味着使用像 RAGAS 这样的框架在完整的“检索-回答-相关性”管道中进行评估，RAGAS 可以在不需要地面真值标注的情况下衡量上下文精度（context precision）、忠实度（faithfulness）和回答相关性。对于聊天机器人，这意味着包含多轮对话，其中模型必须跨多次交流跟踪上下文。

带有人工校验的自动评估。 AI 评测员（使用更强或同等的模型来评估输出）可以将评估规模扩大到人工审核无法达到的程度，但前提是它经过了适当的校准。在信任 AI 评测员来把关部署之前，它需要与人工审核者达成至少 85-90% 的一致性。低于这个阈值，你就是在自动化你的盲点。

已知的失败率，而不仅仅是准确率。 在发布之前，你应该能够陈述在生产真实输入下的幻觉率。行业数据显示，典型的 LLM 部署中幻觉率为 15-38%。这是否可以接受取决于你的领域——对于医疗或法律应用来说是不可接受的，而对于创意工具来说可能是可以接受的——但这个数字应该是已知的、刻意的，而不是在发布后才发现的。

---

关卡 2：延迟预算

LLM 功能中的延迟不是一个数字。它是一个分布，而长尾部分才是关键。

如果一个功能的延迟中位数是 800 毫秒，而 P95 延迟是 4 秒，那么在 20 个用户中就会有一个人觉得功能坏了。在典型负载下，这可能是每小时数百名用户。而且 LLM 系统中的尾部延迟比传统服务要糟糕得多，因为每个变量——提示词长度、检索复杂度、输出长度、API 提供商负载——都会独立叠加。检索慢的一天、长上下文请求和 API 拥堵可能会同时发生。

在发布之前，你需要在整个技术栈中定义一个明确的延迟预算。对于面向用户的 AI 功能，在用户放弃交互之前，人类的耐受阈值大约是 3 秒。对于聊天机器人，首个 token 的时间（time-to-first-token）最为重要：低于 500 毫秒感觉响应迅速，超过 1 秒就开始感觉体验受损。对于代码助手和自动补全，该阈值降至 100-200 毫秒，因为用户期望在输入完成之前就看到建议。

具体的阈值并不如明确定义并针对 P95 水平（而非中位数）进行测试的过程重要。在任何发布清单被签署之前，工程问题“我们的延迟预算通过了吗？”必须有一个具体的、可证伪的答案。

如果你的 P95 延迟超出了预算，有一些切实可行的杠杆：缓存频繁的检索结果、流式输出以减少感知延迟、使用更快的模型进行初始响应而使用较慢的模型进行后续跟进，以及通过削减系统提示词的冗余来减小提示词大小。但这些杠杆需要在发布前拉动，而不是作为事故后的行动项。

---

Gate 3: 优雅降级路径

每一个 LLM 功能都会失败。问题在于你是否已经决定了失败时会发生什么。

传统的软件降级很直接：数据库宕机，显示错误页面。LLM 的降级更复杂，因为失败是一个光谱：主模型很慢但可用，主模型错误率高，API 完全宕机，输出可用但质量已降至可接受的阈值以下。每种情况都需要不同的应对措施。

一个生产级的回退链（fallback chain）通常看起来像：主模型 → 来自同一供应商的更便宜/更快的模型 → 来自不同供应商的同等模型 → 基于规则或模板的响应 → 不丢失用户上下文的优雅错误消息。关键词是“通常”——你特定的链条取决于你的质量/成本权衡，以及对你的用户而言哪些失败模式最重要。

熔断器模式（Circuit breaker pattern）直接适用于 LLM 功能。定义一个阈值（例如连续 5 次失败，或在滚动窗口内错误率超过 5%），实现一个在达到该阈值时路由到回退路径的状态机，并构建一个定期测试恢复情况的探测机制。关键的运营决策是：什么是“失败”？对于 LLM 功能，这应该包括质量失败（输出低于你的评估阈值），而不仅仅是基础设施失败（API 超时）。即使 API 返回了 200 OK，如果 LLM 以高频率自信地产生幻觉，那也是一种失败。

回退路径必须在发布前进行测试。仅仅实现它们是不够的——你需要故意在预发环境中触发它们，以验证它们是否正确启动、用户上下文是否得以保留，以及回退的质量是否真的可以接受（而不只是“聊胜于无”）。

---

Gate 4: 监控基准

只有 15% 的 LLM 部署具备足够的可观测性。这是杠杆率最高的问题，因为如果没有它，你在处理其他门控（gate）时就像在盲飞——你无法验证你的评估覆盖范围在生产环境中是否有效，无法捕捉延迟退化，也无法在回退链启动时察觉。

LLM 监控需要一种与传统应用监控不同的方法，因为有趣的失败对基础设施指标是不可见的。当 LLM 返回一个幻觉答案时，你的基础设施日志看到的是：HTTP 200，延迟在预算内，消耗了 token，返回了响应。一切看起来都很正常。失败仅存在于响应的内容中，而基础设施监控并不会读取内容。

LLM 功能的最小化生产监控栈需要：

带内容捕获的追踪（Tracing）。 每一个请求都应该产生一个追踪，包括 prompt、响应、每个阶段的延迟（检索、模型推理、后处理）以及 token 数量。没有这些，你无法诊断质量退化。

输出质量抽样。 对一定比例的实时流量进行评估——无论是使用 LLM 即评委（LLM-as-judge）打分，还是针对性的人工审核。这是在用户开始抱怨之前，捕捉幻觉率变化或质量退化的唯一方法。

针对用户或功能的成本归属。 为每一个 API 调用标记用户或功能标识符。设置针对每个用户支出阈值的告警。LLM 成本的激增在事后看来是可预测的，但如果没有归属分析，它们就是不可见的：比如一个拥有超长对话历史的单个用户，一个意外走红的功能，或者一个导致 token 消耗膨胀的上下文膨胀（context bloat）Bug。

发布前建立基准，而非发布后。 在发布前（而不是在发布的第一个迭代周期之后）建立监控的原因是，你需要一个基准来进行对比。如果你的基准是 5%，那么 20% 的幻觉率就令人担忧。如果那一直是你的生产环境水平，那就是预料之中的。如果没有发布前的基准，你无法区分退化和常态。

---

Gate 5: 回滚程序

加载中…