Design Vocabulary设计词汇 · 样本集 01

VOCABULARY / 词条

可解释性

Explainability

加入比较 +

系统在给出结果的同时,用使用者能核对的具体依据说明「为什么是这个结果」,并同等清楚地说明该结果在什么情况下不可靠;这里只讨论使用者层面能看到、能理解的说明与限制披露,不涉及模型内部机制作为一门工程学科的可解释性方法。

示意图 · 编辑插画,尚无可操作示例
虚构的 FIELDNOTES 结果卡片旁展开一个「为什么」面板,面板里三条较短的理由横条与一条颜色明显不同的局限横条并排,背景为暖色调、无法辨认的文字。
虚构的 FIELDNOTES 结果卡片旁展开一个「为什么」面板,面板里三条较短的理由横条与一条颜色明显不同的局限横条并排,背景为暖色调、无法辨认的文字。

识别特征

  • 用输入中实际出现的条件、匹配到的规则或引用的依据说明结果由来,使用者可以逐条对照,而不是一句笼统的「系统判断」
  • 在展示理由的同一处,同样清楚地说明系统在什么情况下不适用或容易出错,而不是只讲道理、不讲局限
  • 解释的呈现方式不暗示或宣称「说明了原因,所以结果是对的」,核查渠道与解释本身分开呈现

概念边界

可解释性关注的是「系统依据什么、可能在哪里出错」这两件事本身有没有被讲清楚;这不同于「识别优于回忆」——后者关注选项和操作是否可见、是否需要记忆,而不是结果背后的依据。它也不同于「信任校准」——信任校准关注置信信号与真实准确率是否匹配,是一个测量、调校信任程度的过程;可解释性提供的是校准所需的原材料之一,但一段解释本身,无论写得多有道理,都不能证明结果是对的:解释可以提升使用者的信心,却不必然提升结果的准确率,二者需要分别对待。

什么时候考虑它

  • 结果会被直接采纳用于有后果的决策,使用者需要判断是否要进一步核查
  • 使用者对系统依据感到意外或怀疑,需要具体理由而不是重新运行一遍就了事
  • 同一系统在不同输入或场景下表现差异较大,笼统的「原理介绍」无法覆盖当前这次结果的实际依据

什么时候慎用

  • 把生成的解释文字当作结果正确的证明,用来替代实际核查或省去错误处理路径
  • 只展示系统推理过程中好看、显得合理的部分,回避说明已知会出错的场景或输入类型
  • 对每一次低风险、易撤销的结果都要求展开完整解释,增加不必要的界面负担

取舍

把依据和局限一起讲清楚,能帮助使用者做出更有依据的采纳或核查决定,但会占用界面空间、增加生成与维护解释内容的成本;如果只做「听起来合理」的解释而不接受局限说明,反而可能让使用者更快接受错误结果。

条件规则 · 编辑建议

当系统展示一个结果或建议必须必须用使用者能够对照原始输入自行核实的具体依据说明该结果的由来,而不是仅给出一句无法核对的笼统判断。
当呈现结果依据的同一处必须必须同样清楚地说明系统在这类结果上已知会失效或不可靠的情况,不能只讲理由、回避局限。
当解释内容本身写得连贯、听起来合理必须不能把生成的解释当作结果正确性的证明,仍需提供独立于解释之外的核查方式。

相关词条

信任校准 ↗可以配合 · 系统需要同时传达置信信号与决策依据

可解释性提供了信任校准所需的原材料之一——讲清依据与局限;但解释本身不能替代对置信信号与真实准确率是否匹配的核查。

对话式界面 ↗提供解释 · 使用者可以针对某次结果继续追问「为什么」

对话式交互天然提供了追加提问、逐层展开依据的入口,是呈现可核对解释的常见载体之一。

系统状态可见性 ↗相关但不同 · 系统状态与结果依据都需要被展示出来

两者都关注「系统内部发生了什么应当被使用者看到」,但状态可见性关注的是当前在做什么、进展如何,可解释性关注的是已产出结果的依据与局限。

来源与支持范围

Microsoft Research · Guidelines for Human-AI Interaction ↗

第 11 条准则要求让使用者能够获取「系统为何如此行动」的解释;第 1、2 条准则分别要求讲清楚系统能做什么、以及系统完成这些任务时大约会犯多少错误,三条准则合起来构成了「依据 + 局限」的最小披露范围。

检索日期:2026-09-15 · 存档于 2026-09-16
NIST · NIST Asks A.I. to Explain Itself (Four Principles of Explainable AI) ↗

「解释准确性」原则要求解释如实反映系统生成该输出的实际过程,而不是随便讲一个听起来合理的理由;「知识局限」原则要求系统只在其设计适用的条件下、或达到足够置信度时才给出结论,二者合起来说明「解释是否真实对应系统的运作」与「结果是否正确」是两件需要分别核实的事。

检索日期:2026-09-15 · 快照待确认
Bansal et al. · Does the Whole Exceed its Parts? The Effect of AI Explanations on Complementary Team Performance (CHI 2021) ↗

该研究发现,为 AI 建议附加解释会提高使用者接受该建议的比例,且这种提升「无论建议本身是否正确」都会发生;也就是说,解释增加了使用者的采信意愿,却没有同步提高人机协作团队的实际准确率,二者出现了脱节。

检索日期:2026-09-15 · 存档于 2026-09-16

定义参考以上来源;数字界面示例、选择建议、条件关系及配方由本样例编辑,尚未经用户研究验证。

类型扩展与实现说明

本词条尚无可操作示例;插画为编辑示意。应用到产品时仍须验证:展示的依据是否真的对应系统实际使用的输入与规则、局限说明是否覆盖了已知的失效场景、以及界面是否在任何措辞上暗示解释等同于结果正确。

{
  "evidenceType": "人机交互设计准则与可解释人工智能原则的编辑解释",
  "limit": "本词条不测量某种解释呈现方式能把接受率或核查率改变多少,也不假设「解释准确性」(如实反映系统过程)与「结果正确」是同一件事;已读到的研究表明,附加解释会提高使用者的采信意愿,且这种提升不区分建议对错,因此本词条不复述未读过的其他效应量,也不为「该解释多少内容才够」给出通用数值。"
}
完整 Agent 条目 JSON
{
  "id": "explainability",
  "type": "principle",
  "name": {
    "zh": "可解释性",
    "en": "Explainability"
  },
  "aliases": [
    "Explainable Results",
    "结果说明",
    "为何如此"
  ],
  "granularity": "experience",
  "intents": [
    "calibrate-trust",
    "explain-result"
  ],
  "tags": [
    "可解释性",
    "结果说明",
    "局限说明",
    "可核对依据",
    "非正确性证明"
  ],
  "definition": "系统在给出结果的同时,用使用者能核对的具体依据说明「为什么是这个结果」,并同等清楚地说明该结果在什么情况下不可靠;这里只讨论使用者层面能看到、能理解的说明与限制披露,不涉及模型内部机制作为一门工程学科的可解释性方法。",
  "boundary": "可解释性关注的是「系统依据什么、可能在哪里出错」这两件事本身有没有被讲清楚;这不同于「识别优于回忆」——后者关注选项和操作是否可见、是否需要记忆,而不是结果背后的依据。它也不同于「信任校准」——信任校准关注置信信号与真实准确率是否匹配,是一个测量、调校信任程度的过程;可解释性提供的是校准所需的原材料之一,但一段解释本身,无论写得多有道理,都不能证明结果是对的:解释可以提升使用者的信心,却不必然提升结果的准确率,二者需要分别对待。",
  "signature": [
    "用输入中实际出现的条件、匹配到的规则或引用的依据说明结果由来,使用者可以逐条对照,而不是一句笼统的「系统判断」",
    "在展示理由的同一处,同样清楚地说明系统在什么情况下不适用或容易出错,而不是只讲道理、不讲局限",
    "解释的呈现方式不暗示或宣称「说明了原因,所以结果是对的」,核查渠道与解释本身分开呈现"
  ],
  "when": [
    "结果会被直接采纳用于有后果的决策,使用者需要判断是否要进一步核查",
    "使用者对系统依据感到意外或怀疑,需要具体理由而不是重新运行一遍就了事",
    "同一系统在不同输入或场景下表现差异较大,笼统的「原理介绍」无法覆盖当前这次结果的实际依据"
  ],
  "when_not": [
    "把生成的解释文字当作结果正确的证明,用来替代实际核查或省去错误处理路径",
    "只展示系统推理过程中好看、显得合理的部分,回避说明已知会出错的场景或输入类型",
    "对每一次低风险、易撤销的结果都要求展开完整解释,增加不必要的界面负担"
  ],
  "tradeoff": "把依据和局限一起讲清楚,能帮助使用者做出更有依据的采纳或核查决定,但会占用界面空间、增加生成与维护解释内容的成本;如果只做「听起来合理」的解释而不接受局限说明,反而可能让使用者更快接受错误结果。",
  "comparison": {
    "focus": "系统依据什么给出这个结果、这个结果在哪些情况下不可靠,而不是整体上是否「显得可信」",
    "mechanism": "把可核对的具体依据和已知局限并排呈现,供使用者对照原始输入自行判断",
    "cost": "生成和维护解释、局限说明的成本,以及必须克制把解释包装成正确性证明的诱惑"
  },
  "sources": [
    {
      "id": "msr-hax-guidelines-g11",
      "title": "Microsoft Research · Guidelines for Human-AI Interaction",
      "url": "https://www.microsoft.com/en-us/haxtoolkit/library/",
      "claim": "第 11 条准则要求让使用者能够获取「系统为何如此行动」的解释;第 1、2 条准则分别要求讲清楚系统能做什么、以及系统完成这些任务时大约会犯多少错误,三条准则合起来构成了「依据 + 局限」的最小披露范围。",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://www.microsoft.com/en-us/haxtoolkit/library/",
        "status": "available",
        "checkedAt": "2026-09-16T05:43:24.829Z",
        "jobId": "spn2-7cb34684fb905780ab4c35f6e41f0ec7680b9b7e",
        "url": "https://web.archive.org/web/20260916054347/https://www.microsoft.com/en-us/haxtoolkit/library/",
        "timestamp": "20260916054347"
      }
    },
    {
      "id": "nist-four-principles-explainable-ai",
      "title": "NIST · NIST Asks A.I. to Explain Itself (Four Principles of Explainable AI)",
      "url": "https://www.nist.gov/news-events/news/2020/08/nist-asks-ai-explain-itself",
      "claim": "「解释准确性」原则要求解释如实反映系统生成该输出的实际过程,而不是随便讲一个听起来合理的理由;「知识局限」原则要求系统只在其设计适用的条件下、或达到足够置信度时才给出结论,二者合起来说明「解释是否真实对应系统的运作」与「结果是否正确」是两件需要分别核实的事。",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://www.nist.gov/news-events/news/2020/08/nist-asks-ai-explain-itself",
        "status": "pending",
        "checkedAt": "2026-09-16T05:52:07.543Z",
        "error": "status-request-failed",
        "jobId": "spn2-3b30129de8757a6f84c79f718b0f7aebf58e4aa2"
      }
    },
    {
      "id": "bansal-2021-explanations-overreliance",
      "title": "Bansal et al. · Does the Whole Exceed its Parts? The Effect of AI Explanations on Complementary Team Performance (CHI 2021)",
      "url": "https://arxiv.org/abs/2006.14779",
      "claim": "该研究发现,为 AI 建议附加解释会提高使用者接受该建议的比例,且这种提升「无论建议本身是否正确」都会发生;也就是说,解释增加了使用者的采信意愿,却没有同步提高人机协作团队的实际准确率,二者出现了脱节。",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://arxiv.org/abs/2006.14779",
        "status": "available",
        "checkedAt": "2026-09-16T05:52:08.058Z",
        "jobId": "spn2-ca81f214340e0a259c2bab721d3c6d122126dea2",
        "url": "https://web.archive.org/web/20260916055231/https://arxiv.org/abs/2006.14779",
        "timestamp": "20260916055231"
      }
    }
  ],
  "relations": [
    {
      "target": "trust-calibration",
      "kind": "composes_with",
      "condition": "系统需要同时传达置信信号与决策依据",
      "reason": "可解释性提供了信任校准所需的原材料之一——讲清依据与局限;但解释本身不能替代对置信信号与真实准确率是否匹配的核查。",
      "basis": "editorial"
    },
    {
      "target": "conversational-interface",
      "kind": "informs",
      "condition": "使用者可以针对某次结果继续追问「为什么」",
      "reason": "对话式交互天然提供了追加提问、逐层展开依据的入口,是呈现可核对解释的常见载体之一。",
      "basis": "editorial"
    },
    {
      "target": "visibility-of-system-status",
      "kind": "related",
      "condition": "系统状态与结果依据都需要被展示出来",
      "reason": "两者都关注「系统内部发生了什么应当被使用者看到」,但状态可见性关注的是当前在做什么、进展如何,可解释性关注的是已产出结果的依据与局限。",
      "basis": "editorial"
    }
  ],
  "rules": [
    {
      "when": "系统展示一个结果或建议",
      "instruction": "必须用使用者能够对照原始输入自行核实的具体依据说明该结果的由来,而不是仅给出一句无法核对的笼统判断。",
      "strength": "must",
      "basis": "editorial"
    },
    {
      "when": "呈现结果依据的同一处",
      "instruction": "必须同样清楚地说明系统在这类结果上已知会失效或不可靠的情况,不能只讲理由、回避局限。",
      "strength": "must",
      "basis": "editorial"
    },
    {
      "when": "解释内容本身写得连贯、听起来合理",
      "instruction": "不能把生成的解释当作结果正确性的证明,仍需提供独立于解释之外的核查方式。",
      "strength": "must",
      "basis": "editorial"
    }
  ],
  "principle": {
    "evidenceType": "人机交互设计准则与可解释人工智能原则的编辑解释",
    "limit": "本词条不测量某种解释呈现方式能把接受率或核查率改变多少,也不假设「解释准确性」(如实反映系统过程)与「结果正确」是同一件事;已读到的研究表明,附加解释会提高使用者的采信意愿,且这种提升不区分建议对错,因此本词条不复述未读过的其他效应量,也不为「该解释多少内容才够」给出通用数值。"
  },
  "demo": null,
  "version": "0.1.0",
  "editorialStatus": "drafted",
  "requirements": [],
  "demoCapabilities": [],
  "implementationNote": "本词条尚无可操作示例;插画为编辑示意。应用到产品时仍须验证:展示的依据是否真的对应系统实际使用的输入与规则、局限说明是否覆盖了已知的失效场景、以及界面是否在任何措辞上暗示解释等同于结果正确。",
  "image": {
    "src": "/images/explainability.webp",
    "alt": "虚构的 FIELDNOTES 结果卡片旁展开一个「为什么」面板,面板里三条较短的理由横条与一条颜色明显不同的局限横条并排,背景为暖色调、无法辨认的文字。"
  },
  "searchTerms": [
    "explainability",
    "result rationale",
    "limits disclosure",
    "checkable evidence",
    "not proof of correctness"
  ]
}