一次内部制度问答里，员工问系统：为什么我的出差申请被退回？系统答：根据相关规定。再追问“哪一条”，它给出一段看似完整的摘要，却找不到原文对应位置。这样的回答不算沉默，但也没有把理由交到人手里。
这类场景让可解释性变得具体。用户要的不是模型结构图，而是“你凭什么这样判断”。很多产品把解释做成一个附加面板：显示几个关键词、几段引用、一个置信度。它们有时有用，却容易变成事后装饰。真正要紧的是，解释能不能被检查，能不能改变下一步行动。
解释不是把结果翻译一遍
事后说明有一个常见陷阱：先有结论，再找理由。语言模型尤其擅长生成听起来顺滑的因果句，但顺滑不等于忠实。要判断一段解释是否可靠，可以看几个简单动作：删掉它引用的那段材料，结论会不会变；换一种问法，答案是否稳定；把输入里的无关信息改掉，解释是否还指向同一处依据。若这些动作都改变不了结果，解释很可能只是陪衬。
工程师需要的解释与普通用户不同。前者想定位是哪段检索、哪个特征或哪条规则影响了输出，后者只想知道自己该如何补材料、找谁复核。把两者混在一个界面里，信息会显得很多，却未必可用。
把“为什么”拆成可检查的几件事
- 证据：回答引用了什么原文、记录或规则，能否一键回到出处，而不是只给摘要。
- 路径：系统经过了哪些可描述的步骤，哪些步骤是检索，哪些是生成，哪些由人工规则兜底。
- 边界：哪些问题它没有把握，哪些输入超出适用范围，要明确说出来。
- 可申诉：用户能否标记错误、补充材料，并让人看到后续处理，而不是对着一个分数猜。
可解释性因此更像一种产品契约，而不是模型附赠的说明书。它要求界面愿意暴露不确定性，也要求后台留下可复核的日志。日志不必对所有人开放，但至少要让负责运营和工程的人能追到同一条线索。否则，解释只在演示时成立，一到真实纠纷就失效。
解释的边界也需要解释
有些复杂模型很难给出逐层透明的说明，这不必被说成失败。更诚实的做法是承认边界：告诉用户哪些部分可以核验，哪些只能给出统计意义上的依据，哪些场景不应交给自动系统单独决定。把“不知道”留在界面里，往往比补一段自信的说明更有用。
回到那个出差申请的问题。一个可用的回答未必很长，它至少要指出具体条款、说明匹配过程、标出不确定处，并给出复核入口。可解释性不是让系统显得更聪明，而是让使用它的人保留判断的余地。