构建信任修复流程:当你的 AI 犯下显而易见的错误后该怎么办
当 Google 的 AI Overview 建议用户在披萨酱中加胶水,并为了消化健康而吃石头时,这不仅仅是让产品团队蒙羞——它暴露了我们在思考 AI 可靠性方面的系统性鸿沟。失败的原因不仅在于模型错了。失败的原因在于模型在高度受关注的情境下“自信地”犯错,而且没有为被误导的用户提供任何补救路径。
对 AI 系统的信任并非逐渐流失。研究表明,它遵循一种“悬崖式”崩塌模式:一个明显的错误就能导致信任度大幅下降,并产生可衡量的影响。只有 29% 的开发者表示他们信任 AI 工具——尽管采用率攀升至 84%,但这一比例比前一年下降了 11 个百分点。我们正在构建人们虽然在使用但并不信任的系统。当你的产品发布了代表用户行动的智能体 (agentic) 功能时,这种差距就显得至关重要。
本篇文章讨论的是工程师和产品构建者在错误发生“之后”应该做什么——而不仅仅是如何预防错误。
硬性失败与软性失败之间的不对称性
AI 系统中有两种失败模式,它们对信任的破坏方式不同。
硬性失败 (Hard failures) 是显而易见的:系统崩溃、返回错误或拒绝完成任务。用户能意识到出问题了。他们虽然感到沮丧,但不会根据错误信息采取行动。系统的无能是可见的,这反而在逻辑上维护了认知安全 (epistemic safety)。
软性失败 (Soft failures) 则是自信的错误答案。模型以极高的确定性生成听起来合理的输出,用户信以为真并付诸行动,而错误往往在很久之后才会浮出水面——如果能被发现的话。比如律师在真实的法庭陈述中引用虚假的案例;消费者遵循了违反税法的 AI 生成财务建议;或者一位教授两年的研究成果被没有撤销选项的 AI 助手删除了。
软性失败更为糟糕,因为在错误被发现之前,损害已经扩散。关于临床 AI 的研究发现,高置信度得分增加了用户的依赖性,但反而在逻辑上降低了诊断准确率——用户在最应该质疑系统的时候停止了二次检查。同样的模式出现在各个领域:自信的错误答案比承认不确定性更损害信任,但这种损害只有在用户已经采取行动后才会显现。
实际的启示是:你系统的置信度呈现方式是一种信任机制,而不仅仅是一个 UX 选择。 为了显得更有能力而隐藏不确定性,在错误暴露时会产生适得其反的效果。
