一个做工业质检的团队遇到过这样的事：模型把一批正常件判成缺陷，工程师打开可视化工具，图上几个高亮区域看上去很有说服力——边缘纹理、反光点。大家点头，觉得找到了原因。改完预处理，指标回升。可两周后同类误判在另一条产线上重演，高亮却落在完全不同的位置。
这类经历会让人对“解释”这件事变得谨慎。图是有的，理由也说得通，但它是否真的对应模型内部发生的判断，是另一回事。
先分清它给谁看
可解释性在实际项目里常被两种需求拉扯。一种是内看的：调模型的人想知道哪里出了问题，需要的是忠实——解释能不能反映模型真实依赖的特征，能否在改动输入后预测输出变化。另一种是外看的：业务方、审核方、受影响的用户需要一个说法，需要的是可核验、可反驳，能落到具体动作上。
这两种需求经常被同一张图打发。麻烦在于，对外说得通的东西，对内未必忠实；对内忠实的东西，对外往往没法看——一堆特征交互的数值，没人接得住。
一张热力图能承担多少
注意力权重、显著性图这类方法常被当作解释来展示。它们展示的是模型在某个环节分配关注的方式，和“因为A所以B”的因果链不是一回事。同一输入微扰一下，高亮区域可能大幅移动；换一次随机种子，图也会变。这不代表这些工具没用，它们在排查数据泄漏、发现捷径特征时仍然好用，只是不该被当成结论递给别人。
更实际的做法是把解释做成可检验的东西。比如给一条反事实：如果这个参数从X变成Y，判断会不会翻转。这种问法不依赖模型的自我陈述，能直接验证，也便于业务方提出异议——他们可以指着某个字段说，这个值不对，或者这个值本来就不该参与判断。
有些边界要先承认
不是所有任务都能给出人类能接受的解释。高维输入、强交互的特征，以及那些连标注者自己都说不清依据的判断，硬要产出解释，往往只是把不可解释包装得更体面。这种时候更稳的路子是把可解释性往前移：限制模型能用哪些输入，把明显不该参与判断的字段挡在外面；对关键结论保留规则兜底；定期做敏感性与稳定性测试，看解释本身是否稳定。
这些做法不产生漂亮的图，但它们让系统在出问题时有个可追问的入口。可解释性最终要解决的，不是“能不能说出一句话”，而是这句话被质疑时，团队有没有能力去查、去改、去承认查不出来。
所以看到一份条理清晰的解释时，值得多问一句：它是在描述模型，还是在描述我们希望模型的样子。这两者之间，往往隔着一次微扰的距离。