70% 可靠性恐怖谷：AI 功能丧失用户信任的深渊

一个故障率高达 70% 的功能是无害的。用户在一周内就会发现他们必须验证每一条输出，将系统视为一个不可靠的助手，并做出相应调整。而一个成功率达到 70% 的功能则更糟糕。它正确的频率足以让用户停止验证，而错误的频率又足以让失败变得集中、显眼且具有针对性。用户的心理模型会崩塌为“我不知道什么时候该信任它” —— 这种产品体验从根本上比“我知道不要信任它”更糟糕。

这就是 70% 的恐怖谷，也是过去两年中构建的大多数 AI 功能所处的位置。团队衡量综合准确率，看着数值超过某个“足够好”的阈值，然后发布。实际的用户体验并不随着这个数字单调提升。在大约 60% 到 85% 的准确率之间，产品随着准确率的提高反而变得更差，因为用户因疏于检查而导致的错误成本，超过了他们无需验证正确答案所带来的价值。

那些在不考虑可预测性问题的情况下发布 70% 准确率产品的团队，发布的并不是一个 95% 产品的拙劣版本。他们发布的是一个完全不同的产品：一个主要的失效模式是隐形的产品。

可靠性不是一个单一的数字

AI 功能质量的标准模型将准确率视为单调递增的好事。越高越好。发布门槛是“我们达到了 N%，发布吧。”仪表盘报告一个单一的数字，团队针对它进行优化，决策基于这样一个假设：从“差”到“好”的曲线在不改变形状的情况下穿过中间地带。

事实并非如此。至少存在三种状态，每种状态下的用户体验都有本质的不同。

在低准确率状态下（低于 ~50%），用户模式是“验证一切，将 AI 作为草稿生成器”。输出是建议，而非答案。每一个结果都带着怀疑去阅读。用户保留自己的判断作为承重组件，而 AI 只是在那些他们本来也要从白纸开始的部分节省劳动力。这里的失败成本很低，因为用户本来就打算检查。

在高准确率状态下（高于 ~95%，且在用户的实际工作负载中持续保持），用户模式是“默认信任，定期抽检”。输出被视为答案，而非建议。罕见的失败作为已知的边缘情况是可以原谅的，用户通过经验了解边界，信任是可以恢复的。失败是可见的，但不会导致崩溃，因为失败率足够低，用户的“这可能不对”的直觉仍然能在正确的地方触发。

在恐怖地带（大约 60–85%，取决于领域和失败的可见性），两种模式都不稳定。当答案通常正确时，每次都验证的成本太高。而默认信任会产生太多集中的失败，且这些失败并非随机分布 —— 它们聚集在模型认为困难的细分领域，用户只有在被坑了几次之后才会发现。用户在不同模式之间摇摆，最终既不信任 AI，也不信任自己判断何时该信任 AI 的能力。这就是“我不知道什么时候该信任它”的失败，也是综合准确率数字最无法揭示的失效模式。

曲线的形状比任何单点的数值都重要。如果一个团队不知道其功能处于哪种状态，他们就不知道发布下一个 5 节点的准确率提升会使用户体验上升、下降还是停滞不前。

为什么综合准确率数字会欺骗你

即使撇开非单调的形状不谈，标题中的准确率数字也会在两个具体方面说谎，从而加剧了恐怖谷问题。

第一个谎言是平均值掩盖了细分领域。一个平均准确率为 70% 的模型很少在所有地方都是 70% 的准确率。它通常在简单领域有 90% 的准确率，而在困难领域只有 40% —— 而那个困难领域极有可能是团队最苛刻客户所在的领域。一个整体准确率为 90% 的信用决策模型仍然可能系统性地调低某一人口统计群体的评分；一个在每个属性上看起来都公平的综合指标，在交叉领域可能会表现得非常糟糕。在 LLM 功能中，这表现为“助手在英语短查询中表现出色，而在西班牙语长查询中则一落千丈”，但排行榜显示为 78%，所以团队就发布了。

这里正确的做法是关注每个细分领域的准确率。这不是作为一个关于公平性的事后补救，而是作为主要视图，将全局平均值降级为总结行。跨属性对的错误率热图揭示了综合指标所掩盖的模式。如果一个 50% 的细分领域躲在 90% 的细分领域后面，团队需要在该领域的 50% 用户发现之前察觉到。

第二个谎言是准确率是在评估集（eval set）上测量的，而不是在实际工作负载（workload）上。评估套件是经过策划、过滤的，并且偏向于团队能想到的查询。实际的工作负载包含了评估套件漏掉的长尾情况：粘贴了 8K 上下文的用户、以合成示例从未涵盖的方式提问的客户、检索器返回了错误文档的情况。长尾情况下的实际准确率几乎总是比评估集数字差，而用户体验是由长尾情况决定的，而不是由中位数决定的。将“评估套件上的 78%”与“生产环境中的 78%”混为一谈的团队是在犯范畴错误。

为什么用户无法自行察觉模型失调

此时往往会产生一个诱人的念头：如果问题在于用户无法判断何时该信任输出结果，那就把信任校准的责任推给用户。在新手引导流程中告诉他们模型“有时会犯错”，在每条回答下方添加免责声明，让他们自己去琢磨。

这种做法并不可行，关于自动化偏见 (automation bias) 的研究清晰地解释了原因。在人机协作中，用户始终无法察觉校准失效；他们会过度依赖过度自信的 AI，而对不自信的 AI 信任不足，即使系统显示了置信度分数也是如此。这种被称为“自动化懈怠” (automation complacency) 的模式——即在 AI 连续几次正确后就停止检查的倾向——是人类与部分可靠系统交互时的稳定性特征，而非训练或注意力缺陷。这种现象直接从自动驾驶文献推广到了 LLM 功能中。

对产品而言，这意味着用户不能作为信任校准机制。如果团队发布了一个准确率为 70% 且输出语气自信的功能，并指望用户去核实正确性，那么用户几乎不会核实任何内容，会在特定子集上出错，并以一种极难恢复的方式丧失对该功能的信任。信任校准机制必须存在于产品中，而不是在用户的大脑里。

该机制大致由四个部分组成，且必须在发布前就设计进去，而不是在出现第一波流失后才匆忙补救。

针对“诡异地带”进行设计

第一部分是用户可以据此行动的置信度呈现。不是埋在提示框里的数字分数（这种分数几乎普遍被忽略），而是一种 UX 模式，使“我对此不确定”在结构上与“我对此有信心”截然不同。比如草稿模式横幅。对模型标记为低置信度的输出进行不同的视觉处理。明确指出“此回答使用的来源可能不可靠”。信号必须足够强烈，以打破自动化懈怠循环，这意味着它必须干扰用户的默认阅读流，而不是礼貌地待在角落。

第二部分是针对“诡异频段”内任何功能的“默认辅助”UX。如果该功能在实际工作负载上的实测准确率在 60% 到 85% 之间，默认模式应是“供人工审核的草稿”，而非“直接回答”。你应当让用户必须点击按钮才能将 AI 输出提交到工作流，而不是必须点击按钮去审核它。这反转了认知负荷：不行动的成本落在 AI 的输出上（它只是个草稿），而不是你的警觉性上（你必须记得检查）。自动化程度文献将此称为“AI 作为第二意见的人机回环” (human-in-the-loop with AI as second opinion) ——由人类做出主要决策，而 AI 对潜在问题发出提醒，而非相反。

第三部分是用于卡控发布的细分仪表盘。发布门槛不能是一个单一数字。它必须包括最差细分市场的准确率以及该细分市场的用户规模。一个全局准确率为 78% 但在占比 8% 的用户群中仅为 45% 的功能尚未准备就绪，即使全局数字达标也是如此。团队需要要么将该细分市场提升至基准水平，要么缩小发布范围以排除该细分市场，而不是发布一个失败模式为“底层 8% 的用户体验极差，且支持团队将通过投诉发现这一点”的产品。Apple Card 的故事是 LLM 之外这类失败的典型案例；而在 LLM 内部，这类问题往往出现在语言区域、查询长度或专业领域。

第四部分是一种明确按可靠性等级对功能进行分类的发布纪律。针对高准确率等级的功能，需在实际工作负载下超过 95% 且最差细分市场高于 ~85% 时方可发布。针对辅助等级的功能，则在其 UX 被设计为“草稿与审核”且准确率足以让草稿发挥作用（通常 50–70% 就足够了）时发布。处于中间地带的功能——例如准确率为 70% 但 UX 设计为“直接回答”——是应当拒绝发布的配置。要么提高准确率，要么降级 UX，两者的错位是导致信任崩塌的原因。

实践中的具体表现

在“诡异地带”表现出色的团队通常具有以下几个习惯：

他们运行按租户或按细分的准确率仪表盘，突出显示最差的部分，而不是将其掩盖在全局平均值之下。评估套件（eval suite）是从实际工作负载（采样生产流量）中筛选的，而不是使用合成用例，因此评估数值能够反映用户的真实体验。模型给出的置信度分数在边界处（由渲染层而非模型本身）转换为 UX 信号，从而让产品界面反映模型的确定性，而不是要求用户去读取概率并自行转化。

他们以书面形式按目标可靠性等级对每个 AI 功能进行分类，且发布门槛会参考该分类。标注为“辅助型”的功能可以以较低的准确率发布，因为其 UX 是为审核设计的；而标注为“自主型”的功能在最差细分市场达标前不得发布。产品经理负责的是等级声明的准确性，而不是为了达到某个随意的准确率目标——因为发布一个准确率声明与 UX 声明不匹配的功能，正是他们试图防止的失败。

他们关注体验指标，而不仅仅是输出指标。告诉你功能陷入信任崩塌的数字不是准确率，而是诸如“在前十次交互中，从接受 AI 输出转为忽略输出的用户比例”，或者是“评估流水线评分正确、但用户明确点踩的比例”。用户试图告诉团队评估流水线无法察觉的信息，如果团队不针对这些信号建立监测机制，那么他们将首先从用户流失中听到这些声音。

幻灯片无法察觉的失效模式

70% 的“恐怖谷”之所以让团队措手不及，是因为从组织架构赋予的视角来看，它是不可见的。准确率数字在上升，评估套件通过了，模型卡看起来比上季度更好，领导层审阅的仪表板幻灯片是一片绿色。

与此同时，用户正悄然形成一种持久的信念，认为该功能在某种他们无法再预测的方面是不可靠的。可预测的不可靠性是可以补救的，而不可预测的不可靠性则不然。学到“这个 AI 在处理西班牙语长查询时会出错”的用户，仍会将其用于英语短查询；而发现“这个 AI 有时会在我无法预先识别的情况下出错”的用户，会停止将其用于任何重要事务。前者是下一版本的潜在客户，后者则是团队在两个季度内都无法察觉、且即便察觉也会归因错误的流失用户。

核心结论是：可靠性不是幻灯片上的一个数字——它是用户预测何时可以信任输出的能力。内化了这一点的团队不再用单一的准确率数字来衡量功能，而是开始使用两个指标：准确率本身，以及用户验证出的、对其信心的预测能力。未内化这一点的团队则将一个又一个功能推向“恐怖谷”，看着仪表板变绿，并疑惑为什么参与度曲线在第三周左右开始趋于平缓。

你无法通过将模型准确率再提高 5 个百分点来赢得这场信任战争。你只能通过设计产品，让“我不知道什么时候该信任它”永远不再是用户需要面对的问题，从而赢得这场战争。