内容审核后台有个常见的瞬间：模型把一张用户上传的图标记为“需人工复核”，审核员点开解释面板，看到的是一张热力图，几块红色落在画面边角。他盯着看了两秒，还是得自己从头判断。那张图确实说明了模型看了哪里，但没有回答他真正想问的：为什么是这张，不是上一张。
这类落差，是可解释性在落地时最常撞上的东西。它很少是因为技术不够好，更多是问题没问对：解释给谁看，看完要做什么决定。
同一份解释，四种读者
模型团队想知道的是模型有没有学到捷径，比如把水印当成类别特征；业务方想知道这次判定要不要推翻；合规与审计想知道流程是否可追溯；而受到判定影响的人，只想知道自己改什么才能通过。这四种需求指向的解释形态完全不同，甚至互相冲突。给工程师看的显著性图，对普通用户近乎天书；而一句“因为图片包含疑似违规元素”，工程师看了会觉得毫无信息量。
很多团队的做法是先做出一种解释，再想办法让它兼任其他角色。结果通常是每种角色都不满意。
几种常见手段，各自解释了什么
可解释性常被当成一个可以后加上去的功能模块，实际上它更像一组问答，问题变了，答案的形式也得跟着变。下面这几类手段，各有明确的适用面。
- 特征重要性：描述模型输出与输入特征之间的统计关联，稳定、易读，但它不是因果。某个特征重要，不等于改动它就能改变结果。
- 显著性图与注意力权重：告诉人模型在这一步把权重放在了哪里。权重高不代表它处在因果链的关键节点上，注意力也常被误当作推理过程本身。
- 代理模型：用一个简单模型去逼近复杂模型的局部行为。它解释的是那个代理，不是原模型；而逼近得越像，代理本身往往越难读。
- 反事实解释：给出“如果输入变成这样，结果就会不同”。这是最贴近人直觉的一种，但它可能给出不现实的建议。
把它们混着用，又不说明各自在解释什么，是误解的主要来源。
解释本身稳不稳定，是个信号
一个容易被忽略的检查：把输入做微小扰动，换一种同义表述、调整几个像素，再看解释是否大幅跳变。如果解释跟着乱跳，而预测结果没变，那说明解释方法在这个输入附近不稳定，据此做的判断要打折。反过来，这种不稳定性也可能是模型确实处在一个敏感边界上的提示。它不提供答案，但提供了值得追查的方向。
有些问题，解释解决不了
规模大到一定程度之后，逐条追溯内部机制在工程上不现实，我们能拿到的多是行为层面的描述：在哪些输入附近会失效、对哪类表述更敏感、错误是否成簇出现。这类描述不够优雅，但对实际决策往往更有用。要承认这个边界，而不是用一套看起来很完备的解释界面去掩盖它。
更实际的做法，是把解释当成一个产品需求来定义：谁在读，读完要做一个什么决定，做错的代价是什么。定义清楚之后，选择哪种方法反而是简单的一步。可解释性真正的难点，多半不在算法里，而在这一步的对话里。
回到开头那个审核员。他需要的可能不是一张热力图，而是一句能让他快速判断的话，加上一个能让他追问下去的入口。前者是工程，后者是设计。