客服中心的同事给我看了一块屏：一张工单被系统自动分到了「退换货」队列，旁边浮着几个高亮词，是模型认为起作用的片段。他问，这算不算解释。我说，算一个提示，但你最好别把它当成模型的思路。
这两者之间的缝隙，比大多数人以为的宽。
高亮的那几个词，未必是它想的
常见的归因方法，无论是看梯度、看注意力权重，还是做遮挡实验，回答的其实是同一个问题：把输入的这一部分拿掉或改掉，输出会变化多少。这是一个关于敏感度的答案，不是一个关于推理路径的答案。模型内部并没有一条用自然语言写着「因为A所以B」的链路等着被读出来，它做的是一连串数值变换。我们看到的「原因」，是事后在这个变换上做的一次局部近似。
近似有它的用处，也有它的失真。局部线性近似只在输入附近成立，稍微走远一点就可能翻向；两个高度相关的特征，权重会在它们之间分摊，看上去像是模型只盯着其中一个；注意力权重高，也不等于该片段对最终决策的贡献大。这些都是方法本身的已知局限，不是实现得不够好。
更要紧的是，解释器往往自己就是一个模型，有自己的训练目标、自己的误差。预测的误差和解释的误差叠在一起，结果仍然整齐、仍然有说服力，但它的可信度已经不是原来那个量级了。
人比想象中更容易被说服
我见过一种很典型的使用方式：把解释贴在结果旁边，作为「透明度」的证明。问题在于，一段解释只要看起来合理，就会抬高人对结果的接受度——哪怕它与被解释的那个判断并无因果关系。这在日常经验里也不难理解，一个给出理由的人，总比一个沉默的人显得更有把握。
所以可解释性在这里的实际作用，可能和我们期待的方向相反：它降低的是质疑，而不是不确定性。如果团队没有独立验证解释的习惯，这块界面带来的安心感，反而会掩盖掉本该被追问的东西。
它真正稳的用处，在别处
解释最常见的误用，是把它当成交付物；它更适合当调试工具。归因图能帮你发现的，往往是模型走了捷径：训练数据里某个无关字段恰好和标签相关，模型就学会了用它；图像里有一道水印、一段边框，被当成了判别依据。这类问题从指标上看不出来，摊开一张归因图反而容易看出来。前提是有人真的去看，并且有权限改数据、改特征。
另一处用处是责任链。当系统参与了会影响人的判断，事后总需要有人说清楚「当时依据了什么」。这时重要的不是解释多漂亮，而是解释的生成过程本身可追溯：用了哪种方法、哪个版本、在什么输入上得出的。缺了这层记录，解释只是一段无法复核的文字。
还有一层常被忽略：解释是给谁看的。给工程师看的归因图，和给业务方看的几句话，需要的信息密度完全不同。把两者混用，通常两头都不满意。
有些地方，解释要不到
也需要承认边界。系统复杂到一定程度，未必存在一个既准确又简短、还能被人类顺畅读懂的描述。这时候硬要一个解释，得到的常常是一个听起来顺耳的叙事，而叙事和机制之间的关系没人验证过。要求解释是合理的，但把「给出了解释」等同于「已经解释清楚」，是一种偷换。
我自己的做法偏保守：把每一条解释都当成假设，而不是结论。具体一点，可以问三个问题。
- 改动输入里被指出的那部分，输出真的按预期变了吗？
- 换一种归因方法，指向的是不是同一批特征？
- 如果这个解释是错的，我们会在什么时候、通过什么信号发现？
三个问题都答不上来，就先别把它写进对外说明里。
说回那块屏。高亮词有用，但它更像一句「我猜你可能是因为这个」，而不是一份自白。对可解释性保持一点不信任，不是否定它，而是把它放回工具的位置。解释的价值不在于让人安心，而在于让人有东西可以反驳——一句能被反驳的解释，才算真正开始工作。