内部知识库的问答助手给出“按现有流程应退回补充材料”，经办人盯着屏幕，不知道问题出在检索到的旧条款、模型的归纳，还是那句被忽略的例外说明。此时人们常说要提高可解释性。但真把解释摆到桌上，事情未必结束：一段看似合理的理由，可能只是模型在事后编出的顺滑说法。
解释不是把权重摊开
很多人把可解释性理解成可视化：给每个输入打一个分数，画一张特征贡献图。图能帮助排查，但它像仪表盘，不等于驾驶日志。模型为何在这条样本上偏向某个答案，往往牵扯检索结果、上下文拼接、提示词、阈值和版本差异。只盯注意力权重，容易把工程问题缩成一张热力图。
一个实际的做法，是把解释当成系统输出的一部分：结论、依据、置信程度、可复现路径和拒答条件一起交付。谁需要看什么，也得分层。业务人员要的是“依据哪条规则、有没有例外”；工程人员要的是“哪个环节变了、能否复现”；外部使用者关心的是“我能不能申诉、怎样改变输入”。同一套解释很难同时满足所有人。
听起来合理，不等于解释成立
事后解释有一个麻烦：它天然容易自洽。模型先给出答案，再由另一套方法补理由，补出来的理由未必参与过决策。判断解释是否成立，不能只看文字是否通顺，而要看它能否被检验。比如，删掉被指认的关键依据，结论是否真的改变；换一种等价表述，解释是否稳定；同一输入在不同版本下，理由是否漂移。这些检查不花哨，却能看到工程现场的问题。
这里也需要克制。可解释性不是把所有内部状态都公开，也不是承诺“任何结论都能还原成一句话”。有些模型行为来自大规模参数交互，硬要生成单一路径，反而会制造虚假的确定性。稳妥的目标是：在关键场景留下足够证据，让人类能够判断该不该信、该不该继续追问、该不该把决定交回流程。
先写清楚“解释给谁用”
如果团队准备上线一个会给出建议的模型，我会先问三个问题：这个解释给谁看？看完之后要做什么动作？解释错了，谁来发现？回答不了，所谓解释面板很可能只是装饰。相反，如果能在日志里保留输入来源、规则命中、版本号和拒答原因，再配一份面向业务人员的简明说明，解释就开始具备可操作性。
- 结论旁边给出依据来源，而不是只给一句自然语言理由。
- 保留可复现的输入与版本信息，方便回看同一问题为何前后不同。
- 给“不知道”留位置，低置信时允许拒答或转人工。
- 把解释纳入测试，检查删改关键依据后结论是否随之变化。
这些做法不保证模型变得透明，却能让协作保持诚实。可解释性真正要补的，可能不是一段漂亮的说明，而是让结论背后有迹可循、让质疑有地方落脚。模型说“就是这样”时，系统至少应该告诉人：它是依据什么走到这里，又在哪一步可能停下。