一次内部评审里，工程师打开一张注意力热力图，说模型主要看了这几个词。产品经理追问：那它为什么把这条工单分到二线？会议室安静了几秒。热力图能指出模型“看了哪里”，却没有回答“为什么这样决定”，也没有说明“改哪一处会得到不同结果”。
解释给谁看，决定了解释长什么样
讨论可解释性，先要区分听众。客服主管关心的是“这类工单以后怎么处理”，工程师关心的是“哪段特征把分数推高”，运营关心的是“改文案或改规则会不会影响结果”。如果只给所有人同一张热力图，解释很容易变成一种仪式：图很漂亮，决策仍然靠猜。
- 给一线人员，解释要短，能对应到下一步动作。
- 给工程团队，解释要能定位到输入、特征和版本差异。
- 给管理或审核角色，解释要说明限制条件，而不是只给一个肯定结论。
同一个模型，面向不同角色可能需要不同的解释粒度。把“解释”当成一份可交付物，而不是一次演示，团队才会认真考虑它是否真的被使用。
热力图不是因果证明
特征重要性、注意力权重、局部代理模型，能提供线索，但它们描述的多是模型内部的相关性，不等于现实中的因果。某条内容没有出现在推荐位，可能是因为用户兴趣不匹配，也可能是因为存量不足或策略约束。模型解释只能覆盖其中一部分。热力图不是因果证明，可解释性也不能只靠事后补一张图。
更麻烦的是，解释本身也可能不稳定。输入稍微变化，重要特征就换了一批，这种解释很难支撑复盘。团队需要观察解释在不同样本、不同版本间是否一致，而不是只看一个顺眼的例子。
可操作的解释，要能回答“改什么”
一个有用的解释，往往需要给出反事实：在哪些条件变化后，结果会不同。比如工单分流，能说明是关键词、历史处理路径还是紧急度描述触发了分流；比如内容推荐，能说明是兴趣匹配还是供给约束。这样的解释不要求模型把全部机制摊开，而是让解释与下一步动作连起来。
这也意味着，解释不该只在模型输出后出现。数据采集、特征设计、阈值设定、人工复核，每一步都在影响最终结果。事后解释能补课，但不能替代前面的设计。
边界比承诺更重要
不是所有模型都需要同等深度的解释。一个内部草稿分类器和一个直接面向用户的自动分流系统，错误代价不同，解释要求也不该一样。对可解释性的承诺，要跟决策影响匹配：影响越大，越需要可追溯的依据、可复核的流程和明确的人工介入点。
回到开头那个问题，产品经理要的并不是一张更漂亮的热力图，而是一个能拿去做判断的说法：模型看到了什么，依据是否可靠，改哪里会不一样，出了问题谁来复核。可解释性真正的难点，也许不在把模型讲得多复杂，而在把这几件事讲清楚。