VOCABULARY / 词条
可解释性
Explainability
系统在给出结果的同时，用使用者能核对的具体依据说明「为什么是这个结果」，并同等清楚地说明该结果在什么情况下不可靠；这里只讨论使用者层面能看到、能理解的说明与限制披露，不涉及模型内部机制作为一门工程学科的可解释性方法。
识别特征
- 用输入中实际出现的条件、匹配到的规则或引用的依据说明结果由来，使用者可以逐条对照，而不是一句笼统的「系统判断」
- 在展示理由的同一处，同样清楚地说明系统在什么情况下不适用或容易出错，而不是只讲道理、不讲局限
- 解释的呈现方式不暗示或宣称「说明了原因，所以结果是对的」，核查渠道与解释本身分开呈现
概念边界
可解释性关注的是「系统依据什么、可能在哪里出错」这两件事本身有没有被讲清楚；这不同于「识别优于回忆」——后者关注选项和操作是否可见、是否需要记忆，而不是结果背后的依据。它也不同于「信任校准」——信任校准关注置信信号与真实准确率是否匹配，是一个测量、调校信任程度的过程；可解释性提供的是校准所需的原材料之一，但一段解释本身，无论写得多有道理，都不能证明结果是对的：解释可以提升使用者的信心，却不必然提升结果的准确率，二者需要分别对待。
什么时候考虑它
- 结果会被直接采纳用于有后果的决策，使用者需要判断是否要进一步核查
- 使用者对系统依据感到意外或怀疑，需要具体理由而不是重新运行一遍就了事
- 同一系统在不同输入或场景下表现差异较大，笼统的「原理介绍」无法覆盖当前这次结果的实际依据
什么时候慎用
- 把生成的解释文字当作结果正确的证明，用来替代实际核查或省去错误处理路径
- 只展示系统推理过程中好看、显得合理的部分，回避说明已知会出错的场景或输入类型
- 对每一次低风险、易撤销的结果都要求展开完整解释，增加不必要的界面负担
取舍
把依据和局限一起讲清楚，能帮助使用者做出更有依据的采纳或核查决定，但会占用界面空间、增加生成与维护解释内容的成本；如果只做「听起来合理」的解释而不接受局限说明，反而可能让使用者更快接受错误结果。
条件规则 · 编辑建议
相关词条
可解释性提供了信任校准所需的原材料之一——讲清依据与局限；但解释本身不能替代对置信信号与真实准确率是否匹配的核查。
对话式交互天然提供了追加提问、逐层展开依据的入口，是呈现可核对解释的常见载体之一。
两者都关注「系统内部发生了什么应当被使用者看到」，但状态可见性关注的是当前在做什么、进展如何，可解释性关注的是已产出结果的依据与局限。
来源与支持范围
第 11 条准则要求让使用者能够获取「系统为何如此行动」的解释；第 1、2 条准则分别要求讲清楚系统能做什么、以及系统完成这些任务时大约会犯多少错误，三条准则合起来构成了「依据 + 局限」的最小披露范围。
检索日期：2026-09-15 · 存档于 2026-09-16「解释准确性」原则要求解释如实反映系统生成该输出的实际过程，而不是随便讲一个听起来合理的理由；「知识局限」原则要求系统只在其设计适用的条件下、或达到足够置信度时才给出结论，二者合起来说明「解释是否真实对应系统的运作」与「结果是否正确」是两件需要分别核实的事。
检索日期：2026-09-15 · 存档于 2026-09-16该研究发现，为 AI 建议附加解释会提高使用者接受该建议的比例，且这种提升「无论建议本身是否正确」都会发生；也就是说，解释增加了使用者的采信意愿，却没有同步提高人机协作团队的实际准确率，二者出现了脱节。
检索日期：2026-09-15 · 存档于 2026-09-16定义参考以上来源；数字界面示例、选择建议、条件关系及配方由本样例编辑，尚未经用户研究验证。
类型扩展与实现说明
本词条尚无可操作示例；插画为编辑示意。应用到产品时仍须验证：展示的依据是否真的对应系统实际使用的输入与规则、局限说明是否覆盖了已知的失效场景、以及界面是否在任何措辞上暗示解释等同于结果正确。
{
"evidenceType": "人机交互设计准则与可解释人工智能原则的编辑解释",
"limit": "本词条不测量某种解释呈现方式能把接受率或核查率改变多少，也不假设「解释准确性」（如实反映系统过程）与「结果正确」是同一件事；已读到的研究表明，附加解释会提高使用者的采信意愿，且这种提升不区分建议对错，因此本词条不复述未读过的其他效应量，也不为「该解释多少内容才够」给出通用数值。"
}打开本词条的 Agent JSON 文件这个文件原样收录本词条的全部字段，并附上来源、存档与编辑声明。