最后一公里可靠性问题：为何 95% 的准确率往往意味着 0% 的可用性

你构建了一个 AI 功能。你跑了评估。你在测试集上看到了 95% 的准确率。你上线了。六周后，用户对它深恶痛绝，你的团队正在悄悄计划回滚。

这就是最后一公里可靠性问题，它很可能是当今生产环境中 AI 功能失败最常见的原因。这与你的模型不好无关，而与平均准确率指标如何掩盖失败分布有关——以及某些失败无论其统计频率如何都会带来高昂代价。

没有人在上线前做的复合计算

这是一个比任何基准测试都更能扼杀 AI 路线图的计算：如果多步工作流中的每一步都以 95% 的准确率成功，那么一个 20 步的工作流端到端成功的概率为 0.95^20 = 35.8%。

这不是笔误。一个每步 95% 准确率的 20 步 Agent，产出正确结果的概率略高于三分之一。将每步准确率提升到 98%，你能达到 66.8%。你需要每步 99.7% 的准确率，才能让 20 步流水线的故障率低于 10%。

大多数团队以 90-95% 的单步评估结果上线，认为这是胜利，然后在生产环境中发现复合故障率使该功能完全不可用。这种脱节的根源在于：评估衡量的是单个步骤或单轮响应，而用户体验的是多轮工作流，其中每次失败都会向前传播。

这个数学规律不是 LLM 独有的——它适用于任何串行系统。LLM 不同之处在于失败往往是无声的。传统软件 Bug 会抛出异常。而一个细微失败的 LLM 步骤——提取了错误的实体、错误分类了意图、生成了看似合理但实际错误的结构化数据——不会向下游传递任何错误。下一步在错误输入上运行并产出自信错误的输出，而流水线返回一个看起来有效的结果。

平均准确率掩盖了尾部

95% 平均准确率的演示并不意味着 5% 的查询均匀失败。它意味着某个子集的查询几乎总是失败，而这些查询集中在设计时未预料到的模式中。

真实分布是这样的：70% 的查询是常规的——你的模型处理它们近乎完美。另外 20% 涉及细微变化——性能略有下降但可接受。剩余 10% 是边缘案例：不寻常的措辞、非英语输入、以训练数据未涵盖的方式组合功能的请求、来自将系统推向设计范围之外的高级用户的查询。这 10% 占了大约 50-70% 的失败。

产生这 10% 流量的用户往往是你最活跃的用户。高级用户探索更多功能，尝试更复杂的工作流，提交更多支持工单。他们对口碑有着超出比例的影响力。一个 95% 平均准确率却在高级用户查询上隐藏着 40% 失败率的准确率分数，是一个产品问题，而不仅仅是指标问题。

需要关注的信号：上线后，检查你的失败率是均匀分布还是集中分布。按查询复杂度、用户资历和查询长度分段运行失败分析。如果失败呈集群状，你就有了尾部问题，而你的整体准确率数字正在误导你。

需要不同修复方案的两类失败

在投入解决方案之前，你需要对失败进行分类。并非所有准确率差距都可以修复，而可修复问题的修复方案与不可修复问题的应对方案是不同的。

不可减少的失败是指即使给定可用输入，没有任何模型能可靠地产出正确答案的情况。这些源于模糊的用户意图、缺失的上下文、输入中固有的噪声，或真正需要模型无法获取的信息的任务。一个说"它不工作了"却没有说明"它"指的是什么的客户，在没有澄清的情况下无法被可靠处理。这里正确的应对不是更多训练数据——而是范围限制、澄清提示或升级。

可减少的失败可以通过工程修复。由于特定产品类别训练样本有限导致的错误实体提取。上下文窗口耗尽导致长文档性能下降。因少样本示例过窄而对措辞重新表达脆弱的提示词。可以标注并添加的分布外输入上的分类错误。这些失败有明确的负责人、明确的补救措施和明确的上限。

大多数团队发现，其尾部失败中有相当大一部分属于不可减少类别——看起来像模型失败但实际上是范围问题或缺失上下文问题。将这些作为模型准确率问题来处理，会导致昂贵的提示词调优和微调循环，却无法收敛。

构建解决方案前需要的失败分类法

生产系统的实用失败分类法：

无声幻觉——模型产出自信、看似合理、实则错误的输出。这是最危险的，因为它们通过了下游验证。在结构化提取任务中最为常见，模型用听起来合理的虚构数据填补空白。

指令漂移——在多轮对话中，模型逐渐失去对系统提示词约束的遵守。到第 8 轮时，它正在回答被告知不应回答的问题。在单轮评估中很难捕捉。

上下文崩溃——在上下文限制处，性能急剧下降。模型开始忽略早期指令、自相矛盾或重复内容。这种失败模式随对话长度扩展，在短评估中不可见。

分布偏移——生产输入与训练或评估分布不匹配。季节性模式、新产品发布、地区使用模式和对抗性用户都会引入模型未见过的输入。你的评估准确率变成了历史文物。

复合提取错误——在 Agentic 工作流中，步骤 N 的提取错误会腐化步骤 N+1 到步骤 N+K 的输入。即使每个单独步骤只有轻微失败，最终输出也可能完全错误。

每个类别都有不同的架构应对方案。将它们全部视为"准确率问题"，正是为什么那么多 AI 功能即使经过数月优化也仍停留在 80-87% 可靠性的原因。

真正弥合最后一公里的架构修复

你无法在真实世界分布上可靠地将平均准确率推至 99%+。贝叶斯错误率——给定你的输入的不可减少的错误下界——为模型改进所能实现的效果设置了硬性上限。你能做的是构建使尾部失败变得安全的架构。

为高置信度场景硬编码快速路径。 识别 60-70% 的常规和确定性查询。为它们构建基于规则或基于查询的处理器。将 LLM 保留给其灵活性真正有用的模糊案例。这不是承认你的 LLM 不够好——这是正确的架构。确定性路径对其覆盖的案例更快、更便宜、更可审计、更可靠。

流水线步骤之间的验证门。 在将步骤 N 的输出传递给步骤 N+1 之前，根据模式、约束或完整性检查对其进行验证。在客户服务流水线中，如果实体提取返回一个数据库中不存在的客户 ID，停止流水线并升级，而不是在错误数据上继续。在步骤边界捕捉失败可以防止无声的复合效应。

带有显式弃权的置信度阈值。 配置你的系统在输出置信度低于阈值时弃权——返回"我无法可靠地回答这个问题"。这需要模型原生的置信度分数（LLM 无法可靠暴露）或训练用于区分高置信度和低置信度案例的辅助分类器。经过校准的弃权是一个功能，而不是失败。

结构化升级设计。 大多数团队将人工升级作为事后补救——用户在沮丧时触发的后备按钮。有效的升级是首先设计的，而不是最后添加的。定义触发器：哪些失败信号触发自动交接（用户反复重新表述、置信度分数下降、循环检测）。设计交接：人工客服收到什么上下文。将升级率作为产品健康指标来衡量，而不仅仅是成本线。

为何升级率是产品指标

框架很重要。将升级视为失败的团队优化低升级率，最终导致用户无法联系到人工且不信任 AI。将升级视为设计结果的团队构建了这样的系统：AI 处理它能处理好的内容，在无法处理时迅速交接——用户信任这两个组件。

一个升级率 40%、首次联系解决率 90% 的精心设计 AI 客户服务工作流，比升级率 10%、首次联系解决率 60% 的工作流是更好的产品。第二个系统迫使用户争取升级并在无法解决的交互上浪费时间。

目标不是最大化自动化。目标是最大化可靠解决。这不是同一个优化目标。

用什么代替平均准确率来衡量

用这些指标重新审视你的评估套件：

• 第 90、95 和 99 百分位查询复杂度的尾部准确率——随着查询变难，准确率如何下降？
• 多步工作流的端到端任务完成率，而非每步准确率
• 按查询类别的升级率——特定意图或用户群是否驱动了不成比例的升级？
• 无声失败率——返回结果却没有任何错误信号的失败，通过下游验证或人工抽样来衡量
• 首次联系解决率——用户的问题是否在没有第二次交互的情况下得到解决？

这些指标比基准准确率更难收集，这就是为什么大多数团队默认使用更简单的度量。但它们是预测你的功能在上线六个月后是否还能在生产环境中存活的指标。

那些把最后一公里可靠性做好的团队，不是拥有最好模型的团队。而是那些在上线前运行了复合故障数学计算、在每个流水线边界构建了验证门、在上线前定义了升级触发器、并衡量用户实际体验而非评估预测结果的团队。

95% 的准确率是早期研究阶段的指标。生产可靠性是架构问题。