最后一公里可靠性问题：为何 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 轮时，它正在回答被告知不应回答的问题。在单轮评估中很难捕捉。

加载中…