一个客服工单被自动判为高优先级，被推到了值班队列的前面。工程师点开系统附带的“解释”，看到几个被高亮的词，觉得说得通，于是调整了一条规则。一周后，相似的工单又被判错，高亮的词却换成了另外几个。他没有改模型，但那份解释已经不能支撑他再做一次判断。
这类时刻，是可解释性从概念落到日常的地方。它很少以“能不能解释”的形式出现，更多是以“这次的理由我能不能拿去用”的形式出现。
解释是输出的近似，不是模型的思路
常见做法是显著性图、注意力权重、以及基于扰动的特征归因。它们大多在输入或中间表示上做局部探测，得到的是“哪些输入影响了这一次输出”的一张图。这有用，但它回答的问题比我们想问的要小。模型内部并没有一条用自然语言写成的推理链等着被读取，我们拿到的更接近一次测量结果。
注意力权重尤其容易被误读。权重高只说明模型在这一步分配了较多关注，并不等于该词对最终判定起了决定作用。把权重直接当作理由讲给用户听，短期省事，长期会积累误判的账。
读起来合理的解释，未必稳定
一段解释只要语句通顺、指向具体，人很容易就此停下追问。我的习惯是先看另一件事：把输入换一个同义词、加一个标点、调整语序，解释会不会大幅变动。如果会，那这份理由的价值就要打折扣，因为它描述的可能是一次偶然，而不是模型的倾向。
评估解释时，一致性检查往往比“像不像人话”更容易做，也更少争议。它不需要标注数据，只需要几组相近输入，就能看出归因是否漂移。
不同的人要的解释，并不是同一样东西
- 开发者要的是定位：哪个特征、哪一层出了问题，能否复现，改哪里。
- 使用者要的是可核对的说法：如果不认同这个结果，我能改什么、找谁。
- 审计方要的是留痕：当时的输入、模型版本、给出的说明，事后能否还原。
把这三类需求压缩成界面上的一段说明，通常谁都不满意。开发者嫌它太浅，用户嫌它太技术，审计方则发现缺了版本信息。分开做，各自简单。
可解释的模型不是退路
在结构化数据、规则边界比较清楚的场景里，梯度提升树配合特征贡献，甚至一张决策表，往往已经够用，维护成本也低。上线前先问一句“这个问题是否真的需要那么复杂的模型”，常常能省掉事后补解释的功夫。可解释性在这里不是妥协，而是设计时的默认选项之一。
反过来，有些任务本身就难以逐条说明，比如高维感知类模型。此时更现实的目标不是让每次判断都有理由，而是让系统在不确定时有办法表达不确定，并把人接进来。
解释不等于因果，也不等于可信
一份解释能告诉我们模型依赖了什么，却不能告诉我们这种依赖在现实里是否成立。相关性被模型学到，解释只是把它如实呈现。更麻烦的是，解释得漂亮也可能只是把一个错误决定包装得像样。所以它需要被放进流程里：上线前的一致性检查，解释与人工复核结论的比对，模型版本变化后解释的重新验证。
我不太喜欢把可解释性说成一个有或没有的开关。它更像一组可以逐项确认的问题：这次的理由稳不稳，是给谁看的，看完能做什么。答不上来的时候，模型给出的那句“因为”，就先别急着信。