解释的对象是决策而非模型
别名: 解释决策 · 模型说明书 · decision-level explanation
概念解释
理赔被拒，申请人问「为什么」。他要的不是神经网络有几层、用了何种注意力，而是这一次决定凭什么落到拒绝。把模型卡片、架构图或训练语料说明贴过去，答的是另一件东西。解释的对象是决策，不是模型（explain the decision not the model）：用户要能对这个具体裁定采取下一步，而不是通过一次科普课。
模型当然可以另有说明书，给审计和研发。那份说明书解答的不是当事人面前的这一次。
机制
「可解释的人工智能」常被做成模型属性：可线性化、可可视化、可画决策树。属性在实验室里对研究者有用，因为它回答「这个装置大体怎么工作」。当事人的问题是个案级的：凭哪些本案事实，得到了哪个可申诉的结论。两种问题的合格答案结构不同。前者是装置说明书，后者是裁定书。
Miller 强调解释是对特定事件的社会交流。事件在这里就是这次决策。把模型当作解释对象，交流的主题被换成了工程，用户无法把话用在提交补充材料、选择申诉或接受上。于是「已经解释过了」在产品日志里为真，在用户任务里为假。
怎么研究
同一拒件分别配「模型说明书」（架构、训练数据、总体准确率）和「决策说明」（本案用到的事实、结论、可采取的动作），看人下一步选什么。自变量：说明对象（模型 / 本次决策）、是否允许申诉。因变量：能否指出可改的事实、申诉材料的相关度、误把模型限制当成个案原因的比例。
总体准确率会抬高「系统靠谱」的感觉，却不提高个案行动的质量，必须分开报。
边界
采购、监管、事故调查需要模型级说明，这条不否定那一类读者。终端用户在高风险裁定上要的是决策级。低风险的创作建议几乎没有「一次决策」可解释，硬给裁定书体会显得荒谬。这条也不处理该说明该有多长——对象错了，长短都救不回来。
怎么落地
- 面向当事人的说明以本案事实开头，以可采取的动作结尾。架构、参数量、训练数据放到「关于本系统」而不是结果旁边。
- 若必须提模型限制，写成对这次结论的限定（「影像质量不足，本次未给出恶性判断」），不要写成产品介绍。
- 提供「针对这次决定」和「关于系统如何工作」两个入口，默认打开前一个。
- 验证：把说明交给没看过系统的人，只问「申请人下一步该做什么」。答不上来，对象就还在模型上，不在决策上。