一个客服机器人把对话转给了人工，界面上只留下一行提示：置信度低。工程师想知道是哪一句触发的，产品经理想知道这行字能不能给用户看，用户只想知道自己哪句话说错了。三个问题，一个界面都答不了。
解释是拟合出来的，不是取出来的
很多常见做法并不打开模型内部去看，而是在某个输入附近反复采样，再用一个简单模型去逼近黑箱在这一小片区域里的行为。得到的是一条近似边界，不是决策的因果链条。它会随采样范围变化，也会随随机种子变化。同一张图跑两次，高亮区域换个位置，并不罕见。
这不必然是缺陷。局部近似在调试时很好用：它能告诉你模型此刻在看哪几个词、哪一块像素，便于对照输入做排查。问题出在下一步——把这条近似当成“原因”对外发布，就跨过了一道界线。
流畅的解释更容易被放过
人读解释时，判断的常常不是它对不对，而是它顺不顺。一句“文本中包含疑似催促语气”听起来合理，就很难再被追问。可解释性在这里的风险不是技术不够，而是它太容易让人安心，安心之后就不再提问。
一个可操作的办法是把解释当成假设来检验：改动一个词，看高亮是否跟着移动；把解释指出的关键片段删掉，看输出是否真的翻转。如果删掉之后结论没变，这条理由就该被标为可疑，而不是被写进文档。
对内和对外，是两件事
- 对内，解释是调试工具，要的是可复现、可比较，能落到具体片段或具体环节上。
- 对外，解释是沟通与责任界面，要的是适用范围、前提条件和不确定性，宁短勿满。
把两者混在一起，常见的结果是：给工程师看的信息太笼统，帮不上定位；给用户看的信息太肯定，经不起反问。
它也有做不到的地方
有些决策本身难以压缩成一句话，硬要概括，会丢掉真正起作用的那些条件。也有些场景，解释即使准确，接收方也没有能力判断它是否正确——这时候更该提供的是可申诉的路径和可复查的记录，而不是一句理由。
所以我不太赞成把可解释性当成一个可以打勾的交付项。它更像一个持续的动作：每次给出理由，都留下被推翻的余地，并且记得这份解释是针对哪一版模型、在什么输入分布下成立的。
回到那个客服界面。比起“置信度低”，更有用的可能是“这句话里的时间表达与订单状态相互冲突”。前者是一个分数，后者是一个能被人接着追问的句子。可解释性能走多远，大概取决于我们能接住多少个这样的追问。