值班的同事发来一张截图：一条用户投诉被自动分派到了“物流”组，而投诉内容其实在说退款。系统旁边有个“解释”面板，写着“迟迟未到”“三天”等词的权重较高。他盯着那行字看了半分钟，问题反而更多了：权重高是多少算高？如果把“三天”换成“两天”，结论会变吗？
这类面板如今很常见。模型给出判断，再附一段理由，看起来就“可信”了。但那段理由到底是什么，值得掰开看。
解释这个词，被用得太宽
工程语境里，“解释”至少混着三件不同的事：一是归因，指出这次输出对哪些输入更敏感；二是因果，说明现实里什么因素真正导致了结果；三是交代流程，让人知道数据从哪来、经过哪些步骤、在什么条件下会失效。三者难度差着量级，但在产品界面里常常被压缩成同一句话。
常见的显著性热力图、特征贡献分值，大多属于第一类。它们回答的是“模型此刻在看哪里”，而不是“世界为什么是这样”。一张质检图上的热力图落在边缘，只能说明模型依据边缘像素做了判断；那块边缘究竟是划痕还是反光，模型并不知道，也不负责。
于是就有了第一个容易踩空的地方：把归因当成因果。归因是模型内部的一次“注意力快照”，因果需要干预和对照。二者混用，解释就会退化成一种让人安心的修辞。
内在可解释与事后解释，是两种取舍
有些模型本身就便于阅读，比如层数很浅的决策树、系数不多的线性模型，规则写在明面上，改动一处能一路推演到结果。代价是表达力有限，面对图像、长文本这类高维输入往往力不从心。
另一条路是先训练复杂模型，再事后生成解释。这种做法灵活，却有个绕不开的麻烦：解释器本身也是被拟合出来的，它未必忠实于模型，更未必稳定。输入改动一两个字，判断没变，解释却可能换了一套说辞。所以“可解释性”在这里不是一次性交付的文档，而是一项需要持续校验的能力——解释也要被检验，比如看它在扰动下是否收敛，看它是否跟模型的实际敏感方向一致。
我倾向于一个偏保守的判断：如果一项解释无法被反驳，它就没什么用。能让人指着说“这里不对”的解释，才算有价值。
谁在读这段解释
同一段说明，不同人需要的形态完全不同。
- 工程师要的是梯度流向、失败样本的分布；
- 业务方要的是一句反事实——把这批工单的关键词规则往前挪，会分到哪去；
- 流程管理者要的是可复现：同样的输入，换个人操作，能否得到同样的输出和同样的说明。
一份解释很难同时满足这三种需求，硬凑的结果通常是三段都不够用。可解释性的难点往往不在算法，而在受众的错位。比较务实的做法是分层：给人看的短说明，给工程用的诊断接口，给流程用的日志与版本记录。它们各自不完美，但至少各自诚实。
边界在哪里
有些场景里，与其解释，不如直接做实验。改一个输入、看输出怎么变，比读十行权重更接近真相。这不是否定解释，而是提醒：解释是提问的起点，不是结论的终点。
还有一种情况值得承认：某些判断过程，我们确实说不清楚，只能给出“模型在这类样本上表现稳定”这样的经验描述。这时候诚实地说“这层面暂时解释不了”，比编一段流畅的理由要好。
回到那张截图。后来那位同事做的事很简单：把关键词换掉，重跑一遍，记录分派结果，再拿几条类似工单对照。他没得到漂亮的理由，但拿到了能反驳的东西。可解释性真正稀缺的部分，大概就在这里——不是让人点头，而是让人有地方下手。