设想一个很常见的场面：用户收到系统的拒绝通知，理由栏写着“综合评分不足”。他打来电话，客服答不上来，转给算法团队；团队导出一张特征权重图，附几句说明发了过去。解释交付了，疑问还在。这类落差，是讨论可解释性时最容易被跳过的一段——把“能输出一段理由”当成“解释清楚”，中间隔着的东西不少。
同一个词，三种诉求
三种人问的其实是三个问题。开发者想知道哪里出了错，比如某个字段在预处理阶段被错误缩放，这类信息在梯度、残差和日志里比在任何解释面板里都直接。当事人想知道的更接近因果：如果我换个填法，结果会不会不同。审核方关心的是规则是否被一致执行、有没有用到不该用的依据。三种诉求被压缩进同一个词，做出来的东西往往谁都不满意。
技术手段各有前提。特征重要性说的是模型在这个样本上依赖了哪些输入，依赖不等于原因；注意力权重看起来像“关注点”，但要把它读成理由，还需要额外论证；反事实解释最贴近人的问法——改动什么能让结论翻转——可在高维、带硬约束的输入上，未必找得到合理解；用简化模型去拟合黑箱，得到的解释忠实于简化模型，与原来的模型之间隔了一层。这些方法都有用，但它们是工具，不是结论。
解释是一次有损压缩
还有一个不太好听的权衡：忠实度与可读性通常此消彼长。把真实计算路径完整摊开，没人看得懂；压缩成人能读的三五条，必然丢细节。所以多数解释本质上是一次有损压缩，重要的是丢在哪里、丢的是不是对方在乎的那部分。这一点不事先讲明，解释就容易滑向修辞。
我的判断是，可解释性更该被当成设计约束，而不是交付物。如果某个决定必须能被当事人理解并质疑，那在选型阶段就该把这条写进去，而不是上线之后在外面套一层说明。有些场景里，换用结构更简单的模型、接受一点效果上的让步，换来可对话性，这笔账是划得来的；也有些场景，解释只能停在“统计上如此”，那就把边界说在前面，别让人以为能拿到一个因果答复。
落到工程上，可以试着把可解释性写成可测试的需求，先问四个问题：
- 谁有权看到这段解释，是当事人、审核者，还是只给内部工程团队；
- 什么条件下必须给出，是每次拒绝、只在被质疑时，还是抽样；
- 解释需要满足哪些条件，比如必须指向可操作的输入，而不是“模型认为”；
- 怎么验证它与模型的实际行为一致，而不是一段事后编写的话术。
这几条写不清楚，加一个解释页面，只是把不确定性从系统转移给了用户。