产品评审结束后，业务同事指着一条模型结果问：它为什么这么判？你打开后台，看到几个关键词被标成高权重，于是说“模型主要看这些”。对方沉默片刻，又问：那它为什么把这条归到这一类？这时你会发现，屏幕上展示的并不一定是完整理由，更像是一组线索。把线索当成理由，是可解释性讨论里常见的误会。
一段理由，三种听众
开发者想要的解释，往往是为了定位问题：输入变了，输出为什么跟着变；换一种预处理，结论是否稳定；某个特征被拿掉，预测会偏向哪边。这类需求更接近调试，而不是写说明书。
业务方关心的是责任边界：模型依据了什么，哪些因素在起作用，出错时能不能复核。用户则未必想看特征权重，他们更想知道，这个结果和自己提供的信息有没有关系，下一次该怎么调整。同一个“为什么”，落在不同角色耳朵里，答案并不一样。
所以，可解释性不是给模型写一篇自述，而是把模型的内部行为翻译成不同听众能接住的句子。翻译得准不准，取决于你有没有说清适用边界。
它更像地图，而不是判决书
常见的做法包括特征归因、局部近似、反事实示例和注意力可视化。它们各有用处，也各有前提。特征归因能指出哪些输入对当前输出影响较大，但不自动说明因果；局部近似是在某个样本附近拟合一个简单模型，换到别处未必成立；反事实示例回答“改什么可能让结果变化”，但只能提示方向，不能保证现实可操作；注意力图看起来直观，却不一定等于模型决策路径。
我在看这类结果时，会先问三个问题：解释的是哪一次输出，换一个样本还成立吗，换一种解释方法结论会不会变。如果答案摇摆，那它更适合当排查入口，而不是对外承诺。把归因图直接说成“模型就是这么想的”，省事，但容易把不确定性藏起来。
解释到哪一步该停
有些场景需要更强的解释能力，比如涉及审核、资源分配或自动化决策流程时，至少要让复核者看到依据、看到不确定区间、看到申诉入口。另一些场景里，模型只做辅助提示，过度解释反而增加认知负担。判断标准不在解释技术本身，而在决策后果由谁承担、错误能否被及时发现。
这也是我对可解释性的基本看法：它不是让模型变得透明，而是让围绕模型的协作变得可追问。透明是状态，可追问是过程。前者很难完全达到，后者可以通过日志、版本记录、对照实验和人工复核慢慢建立。
回到开头那个问题，较稳妥的回答不是“模型主要看这些”，而是“从当前这次输出看，这些输入影响较大；但它是否稳定、是否构成原因，还需要进一步验证”。这句话不够干脆，却更接近事实。可解释性真正要解决的，或许不是让模型说出一句漂亮理由，而是让人知道该在什么时候相信它，什么时候继续追问。