给 AI 软件从业者的信任校准

图片由 Annie Ruygt 提供

信任校准（trust calibration）是人机交互设计领域的一个概念，对做 AI 软件的人来说尤其相关。信任校准要做的，是让用户对产品的信任程度与产品的实际能力对齐。

如果我们做出来的东西让用户盲目信任，就可能促成危险甚至破坏性的交互，用户一旦踩坑就再也不会回来。反过来，如果用户对我们的产品信任不足，产品就会显得没用，或者比实际能力更弱。

那么信任校准在实践中是什么样子，又该怎么做到？2023 年有一项研究梳理了 1000 多篇关于人与自动化系统之间信任及信任校准的论文（完整参考文献见文末）。对做 AI 软件的人来说，其中的洞见相当开眼，也有一些不太舒服的真相。下面我只挑最有价值的部分。

给信任设上限

先说一个关键点：我们希望用户信任产品，但这种信任是有上限的。目标是让信任被校准，而不是不计代价地追求更多信任。信任校准做得不好，会带来两种同样糟糕的结果：

• 过度信任：用户在本不该依赖 AI 系统的场景下依赖它（我让代码助手去修生产环境的 bug，然后就去睡了）。
• 信任不足：即便 AI 的协助确实有用，用户也会拒绝，结果是对产品价值的感知下降，用户的工作负担反而增加。

对你的产品来说，校准后的信任是什么样子？要弄清这一点，重点不在于画出一堆抽象的信任参数，而在于帮用户建立对产品能力与边界的准确心智模型。多数情况下，这意味着不能只依赖我们默认会想到的那些信任校准机制，比如置信度分数。

例如，Cursor 最显著的信任校准机制是它对修改建议的高亮显示：模型建议修改的代码用红色标出，随后给出的修改建议用绿色标出。这立刻传达出“这是建议，不是命令”。

相比之下，Tesla 的 Autopilot 是一个委派式系统。它必须通过详细的能力说明、明确的操作边界（仅在高速公路上）、以及在条件超出系统限制时醒目的退出提醒，以不同的方式校准信任。

构建协作式系统

在确定高层信任校准目标时，最根本的考量或许是决定你的项目被设计成协作式工具还是委派式工具。

协作式系统通常要求较低的信任水平，因为用户可以选择接受或拒绝 AI 的建议。但这类系统也面临一个独特的风险：过度信任很容易让用户的满足感逐渐演变为过度依赖，从而把原本设计为协作式的关系变成委派式关系，却又没有任何必要的保障措施。

如果你在构建编程助手、内容生成器或设计工具，请实现可见的“建议边界”，明确表明 AI 是在提供想法还是在做决定。Grammarly 在这方面做得很好：它给建议加下划线而不是自动更正，并在悬停时显示理由。

对于风险更高的交互，可以考虑引入摩擦。在将 AI 建议应用到生产代码或发布 AI 生成的内容之前，要求用户明确确认。

构建委派式系统

相比之下，用户期望委派式系统完全取代人的操作。盲目信任系统是它被视为有价值的前提。

如果你在构建自动化工具、智能调度或决策系统，请在能力沟通和边界设定上大力投入。Calendly 的智能调度之所以有效，是因为它清楚地说明了自己会做什么、不会做什么（我会找到适合我们双方的时间 vs. 我会重新安排你已有的会议）。构建稳健的兜底机制，并在引导流程中突出系统的局限。

时机决定一切

研究表明，我们何时进行信任校准，至少与如何校准同等重要。信任校准有三个关键窗口，每个窗口各有自己的机会与挑战。

• 交互前校准发生在用户接触系统之前。文档和教程属于这一类。提前设定预期可以防止最初的过度信任，而过度信任一旦形成，日后纠正起来会格外困难。

交互前校准可以采取以能力为重点的引导流程，既展示成功也展示失败。不要只演示 AI 的完美输出，还要给用户看 AI 出错的例子，以及如何发现这些错误。

• 交互中校准是通过实时反馈调整信任。动态更新的提示比静态展示更能改善信任校准，而能对用户行为做出响应的自适应校准，效果优于只显示静态信息的系统。

构建基于上下文更新的置信度指示器，而不只是依据模型置信度。比如你在做一款文档 AI，对于系统已经处理过成千上万次的标准文档类型，显示较高的置信度；对于不常见的格式，则显示较低的置信度。

• 交互后校准侧重于学习和调整，帮助用户在交互结束后理解系统中的成功与失败。这类校准并不可靠，因为等用户收到这些信息时，他们的信任模式已经定型，很难改变。

交互后的反馈对教学仍有价值。在重要的交互之后设置“反思时刻”。Midjourney 就是这么做的：让用户对生成的图像打分，帮助用户了解哪些提示词效果最好，同时校准他们对后续生成结果的预期。

信任是前置的，也是习惯驱动的。最有效的校准发生在使用之前和使用之中，此时预期仍在形成，行为仍可改变。再晚一些，你基本上就是在对抗已经根深蒂固的模式。

性能信息与过程信息

引导用户时，可以依靠面向性能的信号（系统能做什么），也可以依靠面向过程的信号（系统如何运作）。真正的挑战在于，把恰当的解释在恰当的时刻给到恰当的用户。

• 面向性能的校准重在传达能力，手段包括可靠性统计、置信度分数，以及清晰的能力边界。
• 面向过程的校准则提供决策过程的详细说明、影响决策的因素拆解，以及推理的透明度。

乍看之下，过程透明似乎是理所当然的选择，但过程解释的效果因用户专业水平和领域知识的不同而差异极大。如果我们要面向的用户可能落在这一光谱上的任何位置，就必须避免让新手用户信息过载，同时又要为想要细节的专家用户提供足够的信息。

研究中效果最好的系统把两种方式结合了起来，提供分层信息，让用户按自己的专业水平和当下需求获取相应程度的细节。

静态校准与自适应校准

这部分我本来很想略过，因为它读起来像是研究作者在阴阳怪气地往我的项目里加待办事项。简单说，自适应校准——系统主动监测用户行为并据此调整沟通方式——比静态校准有效好几个数量级，而静态校准对每个用户都一视同仁，不管其专业水平、信任倾向或行为有何差异。

静态校准机制容易搭建、容易维护，所以我们偏爱它。但残酷的现实是，它把恰当校准的负担完全推给了用户。我们等于要求用户自己根据通用信息去调整行为。

这个结论丝毫不顾我们的时间和心理健康，但它也揭示了一个实实在在的机会：聪明的开发者可以借此真正让产品脱颖而出。

实用的自适应校准技巧

• 行为自适应： 统计用户接受与拒绝建议的频率，据此调整置信度阈值。如果用户持续拒绝高置信度建议，就降低显示不确定性的阈值。
• 上下文感知： 根据使用场景调整信任信号。写作类 AI 在语法修正上可以显示更高的置信度，在创意建议上则更低；深夜用户可能疲惫时，置信度也应调低。
• 识别专业程度： 经常对 AI 输出做精细修改的用户，多半比那些直接接受整份文件重写的用户更想要详细的解释。

透明度的悖论

透明和可解释反而可能损害信任校准——这一点对我触动最大。解释能增进用户理解，但也会造成信息过载，削弱用户发现并纠正垃圾输出的能力。更糟的是，解释本身会带来一层全新的信任校准问题：用户会过度信任解释机制，而不是批判性地评估实际输出。

这意味着在透明度上，我们的设计理念应该是质量优先于数量。与其提供全面却令人不堪重负的细节，不如提供精心打磨、切题的信息。目标应当是帮助用户做出更好的决策，而不只是满足他们对系统内部的好奇心。

拟人化与无端的信任

让用户与我们的 AI 项目交互时感觉尽可能像人，这似乎是理所当然的。但事实是，那些通过设计、语言或交互模式显得更像人的系统，恰恰擅长把用户信任推高到超出系统实际能力的程度。

所以，构建更传统的人机交互，完全可能让我们的 AI 项目用起来更安全，也因此更易用。

• 使用工具式的语言： 把输出表述为“分析表明”，而不是“我认为”或“我相信”
• 拥抱机器般的精确： 给出确切的置信度百分比，而不是人类式的模糊措辞（“我挺确定……”）

信任跌得快，涨得慢

这里没什么特别突破性的东西，但结论值得一提，哪怕只是为了印证我们自以为已经知道的事。

早期交互至关重要。用户会很快形成心智模型，此后对系统可靠性的变化反应迟钝。

更关键的是，信任因系统故障下跌的速度，远快于因成功而积累的速度。这种不对称意味着，我们应当在引导和首次使用体验上投入得格外多，哪怕开发成本更高。

测量是创新的机会

这项研究暴露出，无论对研究者还是开发者而言，有效的测量机制与协议都是一片空白。显然，我们需要超越简单的用户满意度指标或采用率，去开发能够主动识别信任校准偏差的测量框架。

理想的测量方式应当综合多项指标。几个可行的指标示例：

• 行为信号： 追踪不同置信度下的采纳率。校准良好的信任应当表现为：高置信度输出的采纳率更高，低置信度输出的采纳率更低。
• 分场景指标： 针对不同用例分别测量信任校准。用户可能在简单任务上校准良好，在复杂任务上却校准很差。
• 用户自述： 定期做脉冲调查，问一句“你有多大把握判断出这个 AI 什么时候会出错？”，就能发现校准上的缺口。

校准后的结论

至少从这项研究来看，显然不存在通用公式，也没有哪个单一功能能有效地校准信任。每个开发者都得自己定义并理解项目的信任目标，并据此在时机、内容、自适应性和透明度之间取得平衡。正因如此，这件事既难，又值得做。信任校准必须成为产品身份的核心部分，而不是一头跑出谷仓才想起来追的猪崽。

论文：

Magdalena Wischnewski、Nicole Krämer 与 Emmanuel Müller。2023。《Measuring and Understanding Trust Calibrations for Automated Systems: A Survey of the State-Of-The-Art and Future Directions》。收录于 Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems (CHI '23)，2023 年 4 月 23–28 日，德国汉堡。ACM，美国纽约州纽约市，16 页。https://doi.org/10.1145/3544548.3581197