直接答案：透明度回答“系统里发生了什么、由谁负责”，可解释性回答“为什么得到这个输出、理由是否忠实且可理解”。一个系统可以披露版本和数据来源，却仍无法解释单次决定；也可能给出局部解释，却没有说明数据、人工复核和申诉路径。验收时应把两者分开记录。
三个概念不要混用
- 透明度
- 让人知道系统目的、版本、数据和模型来源、人工参与、限制、监控与责任边界。它偏向系统和过程记录。
- 可解释性
- 为输出或过程提供伴随证据或理由，并让目标受众能理解。它既可能解释过程，也可能解释某次结果。
- 可解释给谁
- 开发者需要调试线索，业务审核者需要规则与证据，受影响的人需要简单理由、可纠正信息和申诉路径。同一张特征重要性图不能自动满足所有角色。
NIST 四原则如何变成验收项
| 原则 | 要问的问题 | 可保存的证据 |
|---|---|---|
| Explanation | 输出是否伴随理由或证据？ | 输入版本、规则/模型版本、证据引用、输出 ID |
| Meaningful | 目标用户能否理解并采取行动？ | 角色、阅读测试、可操作下一步、申诉入口 |
| Explanation Accuracy | 解释是否忠实反映实际生成过程？ | 对照实验、反事实检查、日志与解释的一致性 |
| Knowledge Limits | 超出设计范围时能否拒绝或升级？ | 适用范围、置信门槛、拒答样本、人工升级记录 |
NIST 将透明、可解释、可解释性、有效可靠、公平、安全等列为相互关联但不同的可信特性。解释得通不代表模型准确、公平或合法；反过来，整体指标合格也不能省略对受影响个体的适当说明。
用一条决策记录检查是否够用
为每个高影响输出保存：用途与受众、输入字段及来源、模型/规则版本、输出与置信信息、主要理由、不可使用的推断、人工复核者、纠正和申诉入口、保留期限。敏感特征不应为了“透明”而无边界公开，解释也不能泄露他人隐私或安全控制。
四种常见失败
只给技术图，不给可操作理由
SHAP、LIME 或注意力图可能帮助开发者，但终端用户仍不知道哪些输入可纠正、谁能复核或如何申诉。
解释听起来合理，却不忠实
生成式说明可能只是事后编故事。需要用扰动、反事实、规则日志或可重复运行检查解释是否随真实决策因素变化。
公开太多，反而造成隐私和安全风险
透明度要按角色和目的分层。公开必要的限制与责任，同时控制训练数据细节、个人信息、风控规则和攻击面。
把合规标签当技术验收
法规义务取决于辖区、角色和场景。欧盟 Article 50 的透明义务不等同于对所有系统提供同一种解释；高风险自动化决策还需单独核对适用法规与专业意见。
最小验收结论
合格的解释至少要与输出相伴、对目标受众有意义、忠实反映生成过程，并在知识边界外停止。合格的透明度记录还要能定位数据、版本、责任人、人工复核和纠正路径。若只能证明“页面上有一段解释文字”，就不能宣称系统已经可解释。
一手资料
- NIST：可解释 AI 四原则（核验于 2026-09-12）
- NISTIR 8312 原文（核验于 2026-09-12）
- NIST AIRC：可信特性（核验于 2026-09-12）
- NIST AI RMF 1.0（核验于 2026-09-12）
- 欧盟委员会：AI Act 透明义务（核验于 2026-09-12）
