90% 可靠性之墙：为什么 AI 功能会陷入瓶颈以及该如何应对

你的 AI 功能发布时准确率为 92%。团队举杯欢庆。三个月后，进展陷入停滞 —— 尽管投入了更多数据、更多算力和两次模型升级，错误率却不再下降。听起来很熟悉吗？

这就是 “90% 可靠性之墙”，这并非巧合。它源于三种力量的交汇：边际准确率提升的指数级成本、可消除误差与结构上不可避免误差之间的区别，以及生产环境中故障的复合放大效应 —— 而这些是基准测试永远无法捕捉到的。不了解自己正在与哪种力量对抗的团队，将会浪费数个季度的时间去试图解决那些根本无法解决的问题。

为什么 90% 是自然的停滞点

准确率的提升并不随投入线性增长。关于深度学习算力成本的研究发现，将准确率从 90% 提高到 95% 所需的资源，大约是最初达到 90% 所需资源的 20 倍。达到 99% 的准确率往往在经济上是不理智的。改进曲线遵循一种接近对数斜率的规律，每提升一个百分点所需的成本都比前一个百分点呈指数级增长。

这在 90% 关口产生了一种引力。在这个阶段，你的模型已经消耗了训练分布中大部分容易获取的信号。这也是基准测试得分与生产环境行为开始出现最剧烈分歧的地方。在清晰的音频书录音上声称拥有 95% 准确率的语音识别系统，在面对真实说话者、背景噪音和特定领域词汇的生产环境中，准确率通常会下降到 75-80%。这种差距不是模型的失败 —— 而是测量的失败。

Princeton Reliability Project 对 AI 智能体（Agents）的研究精确地捕捉到了这种动态：在通用智能体基准测试中，可靠性的提升速度只有准确率提升速度的一半。在专门的客户服务基准测试中，可靠性的提升速度仅为准确率提升速度的七分之一。你的模型在基准测试衡量的维度上变得更聪明，但在生产环境中至关重要的维度上却变得更脆弱。

两种误差，两个截然不同的问题

当你陷入瓶颈时，最有价值的诊断性问题是：你面对的是可减少误差（reducible error）还是不可减少误差（irreducible error）？

可减少误差是指在给定任务和数据的情况下，你的模型与最佳可能模型之间的差距。它有你可以采取行动的原因：训练数据不足、特征表示不佳、架构错误、训练分布与生产分布不匹配。如果你属于这一类，投资更好的数据或模型将会提升指标。

不可减少误差 —— 有时被称为贝叶斯误差（Bayes error） —— 是任何分类器在给定任务上都无法逾越的理论底线。它不是你模型的属性，而是任务本身的属性。它源于真实的歧义：即使是人类也无法在正确标签上达成一致的图像、设计上就存在重叠的意图、或者正确答案取决于未说明语境的查询。一旦触及这个底线，你挣扎的就不再是模型问题，而是范围问题。

实际测试方法：绘制错误率与训练集规模的关系图。如果错误率下降缓慢 —— 呈亚对数增长 —— 且尽管有新数据加入，曲线在数月内一直趋于平缓，那么你可能正在接近贝叶斯误差。如果错误率突然停止提升，且正好伴随着数据耗尽或基准测试饱和，你可能遇到了架构限制。如果错误率早期下降迅速，然后停滞在 10-20% 左右，那么训练与生产环境之间的领域偏移（Domain shift）更有可能是元凶。

欺诈检测陷阱清晰地说明了其中的利害关系：在一个欺诈交易占 0.5% 的数据集上，一个达到 99.5% 准确率的模型可能会学会对所有交易都预测为 “合法”。得分完美，价值为零。如果你优化的目标错了，可减少误差和不可减少误差就毫无意义。

生产环境如何放大这道 “墙”

90% 之墙不仅是模型现象，它是一个系统现象。孤立来看，准确率为 90% 的模型看起来是可控的 —— 十次中出错一次。但在一个由三个组件构成的流水线中，如果每个组件的准确率都是 90%，复合准确率就变成了 72.9%。四个 90% 的组件产生的准确率仅为 65.6%。一个真实的医疗诊断流水线，结合了 90% 准确率的乳腺摄影模型、85% 的转录模型和 97% 的诊断模型，其整体可靠性并不是 91%，而是 74%。

这就是为什么团队反复被生产环境中的表现所震惊。基准测试衡量的是单个组件，而用户体验到的是所有组件的乘积。

医疗领域让这一点变得更加真切。2026 年的一项研究发现，虽然大型语言模型在给定完整临床信息时能达到合理的诊断准确率，但在信息稀缺的开放式场景（而这恰恰是临床推理最关键的时候）中，它们在生成适当鉴别诊断方面的失败率超过 80%。流水线不仅表现不佳，而且是在工作流中最糟糕的时刻表现不佳。

代码助手（Coding Assistant）的例子在结构上非常相似。GitHub Copilot 能够让代码生成速度提升 55%，这听起来像是可靠的收益。但代码变动率（Code churn）—— 即在编写后两周内被回滚的代码行数 —— 正在翻倍。大约 40% 的生成代码中出现了安全漏洞。模型的准确率并没有陷入瓶颈，但生产价值却陷入了瓶颈，因为下游校验和修复的成本抵消了速度上的提升。

如何诊断你面临的是哪种问题

在决定如何行动之前，你需要了解你正在对抗的是什么。有四项诊断值得进行：

基准测试与生产环境的差距分析。如果你的受控基准测试显示为 95%，而生产环境显示为 78%，那么这个差值主要不是模型质量问题——而是分布偏移 (distribution shift) 问题。投入模型改进并不能像改进处理生产环境差异的方法那样有效地缩小这一差距。

失败模式分类。抽样 100 个生产环境错误并进行分类。它们是随机分布在输入分布中的吗？还是系统性的，聚集在特定的输入类型、边缘案例或代表性不足的主题周围？随机失败表明存在数据覆盖问题。系统性失败表明存在任务范畴问题——你的模型在超出其训练分布或确实存在歧义的一类输入上可靠地犯错。

人类基准衡量。让人们在你的模型难以处理的相同输入上执行相同的任务。如果人类在这些输入上也存在分歧或失败，那么你处于贝叶斯误差 (Bayes error) 状态。如果人类能轻松成功，说明你面临的是可避免的误差。

一致性测试。使用相同的输入运行 100 次相同的任务。如果输出结果差异显著，你的可靠性问题不在于准确率——而在于一致性。一个准确率为 90% 但一致性为 100% 的模型，与一个准确率为 90% 但在 30% 的输入上存在波动的模型，是两种完全不同的产品。后者造成的用户信任问题会比准确率数字所暗示的更加严重。

有效的架构决策

一旦你诊断出了问题，解决方案就会大相径庭。

如果你遇到了可减少的误差：标准疗法适用——更多的高质量训练数据、针对失败簇的定向数据增强、针对生产环境分布的微调，以及针对知识差距的检索增强 (RAG)。这可以通过投入来解决，尽管随着你接近贝叶斯误差，回报会递减。

如果你遇到了不可减少的误差或任务范畴限制：正确的答案几乎永远不是在模型上投入更多，而是改变问题的形态。

范畴缩小 (Scope narrowing) 是最被低估的工具。与其构建一个处理所有法律文件但准确率为 90% 的 AI，不如构建一个处理特定合同格式中特定条款类型且准确率为 99% 的 AI。与其构建一个回答任何医学问题的 AI，不如构建一个在特定影像模态中标记特定病症的 AI。窄域系统交付的是可靠的价值。广义系统交付的是不可靠的价值，这会侵蚀用户信任。

置信度门控 (Confidence gating) 是针对混合可靠性系统最直接的架构响应。将高置信度的输出直接推送给用户。将低置信度的输出路由给人工审核。阈值是一个产品决策，而不是模型决策——它在吞吐量和质量之间进行权衡，其设定完全取决于你的用户能容忍什么。大多数企业级部署将其设定在 85-90%，但关键是将其视为一个可调的旋钮，而不是一个固定参数。

优雅降级 (Graceful fallback) 意味着你的系统知道自己不知道什么。如果一个语音识别模型无法自信地转录某个法律术语，它不应该给出最接近的猜测——它应该表现出不确定性、请求重复或升级处理。给出自信但错误输出的系统对用户信任的损害，比承认不确定性的系统要快得多。需要构建的功能需求是范畴感知：即能够识别输入何时超出了系统可靠的领域。

分阶段自动化 (Staged automation) 承认并非工作流中的所有任务都有相同的可靠性天花板。分解工作流。在系统达到 99% 的子任务上实现自动化。仅在准确率降至 85% 的子任务上应用人工审核。精心实施这种架构的组织报告称，与尝试全自动化相比，输出错误减少了 96%，同时保留了 30-35% 的生产力提升。

你实际上在做的决策

当你的 AI 功能停滞在 90% 时，你面临的选择最终是一个产品决策，而非工程决策。

你可以追逐接下来的 5 个准确率百分点。这需要了解你面对的是可减少误差还是不可减少误差。如果是可减少的，投入可能是有意义的。如果是不可减少的，你是在以指数级的成本购买边际收益——而且你最终会发现，用户行为（或竞争对手的产品）已经发生了变化。

你可以重新设计边界。将范畴缩小到你可以达到 99% 的子任务。在部署更广泛的系统时，配合置信度门控和明确的不确定性提示。接受并非每个 AI 功能都应该是完全自主的，将人工审核构建到产品架构中，而不是将其视为迟早要拆除的临时脚手架。

你不应该做的是继续将基准测试准确率作为用户价值的代名词，而两者其实正在持续偏离。90% 的瓶颈在告诉你，你的优化目标和用户的实际需求已经不再一致。这是一个值得倾听的信号。

那些能够交付并维持用户信任的 AI 产品的团队，并不是那些达到了 99% 准确率的团队。他们是那些将边界划定在 99% 并围绕这一边界构建一切的团队。