生产环境 LLM 故障的排查顺序应是:实际发送的 prompt → 检索上下文 → 温度为 0 的复现 → 变更时间点;模型内部机制是最后才查的地方。
几乎所有生产环境的 LLM bug 都是通过输入、输出和日志来诊断的。可解释性只在少数场景下才能发挥作用,知道哪些场景值得用比掌握哪些技术更重要。这一页就是那个清单,同时也会先指出哪些场景下它不是正确的工具。
如果你的模型输出了糟糕的结果,按顺序要做的事情是:阅读实际发送的提示词,包括框架追加的所有内容;检查失败case的检索上下文;检查在 temperature 0 下是否能复现;以及检查是否从某个特定部署开始出现的。
这四个步骤能解决绝大多数真实的事故。模型的内部结构是最后才要看的,而不是最先看的,因为那部分是没有变化过的——这个检查清单的系统性版本比本页任何技术都更值得花一个下午去实践。
接下来要说的是残留问题:经历了上述步骤仍然存在的问题,以及在这种时候来自模型内部的信号确实是代价最低的解决路径。
这个类别里几乎所有技术都需要本地权重。托管 API 返回 token,有时候返回对数概率(log-probabilities),但不返回激活值,而且永远不会。
所以实际问题不是"这个技术好吗",而是"这个问题值得为了调查而自托管一个开源模型吗"。通常不值得。偶尔——产品核心的分类器、安全相关行为的特征描述、你微调过却无法解释的模型——是值得的,当内部访问是你购买的一部分时,自托管的权衡就变了。
有一种技术跨越了这个门槛:日志概率分析通过任何暴露它的 API 都能工作,而且它是对模型内部状态存在的最便宜的有用信号。
token 分布告诉你模型是自信的还是在近似平局之间选择。概率 0.95 的错误答案和概率 0.31 的错误答案是不同的 bug:第一个是表示问题,第二个通常是提示词或检索问题——正确答案本在竞争之中,最终落败。
对于任何约束输出——分类、路由、从固定集合中提取——读取允许 token 上的分布给你一个可用的置信度信号和一个弃权阈值。这是一个生产功能,不是分析:在阈值以下弃权把一类静默的错误答案转化为一个可处理的情况。详见对数概率了解机制。
当检索系统返回错误的文档时,所涉及的内部结构是嵌入,而且它们对你完全可用。检查查询嵌入与本应获胜的文档嵌入之间的相似度,然后检查实际获胜的文档。这区分了三种从外部看起来一模一样的失败:文档根本不在索引中、它在索引中但得分低于截断线、或者它得分很高但被近似重复项取代了。每种都有不同的修复方法,再多的提示词迭代都无法区分它们。
如果你自托管,在中间层隐藏状态上做线性探针是一个真正实用的组件。它的代价是你已经计算过的张量上的一个点积,在生成之前对提示词运行,可以标记类别——这个请求看起来像是我们路由到别处的那个类别——比第二次模型调用更便宜。
探针页面的评估义务在这里完整适用:一个对照任务、在文档级别留出的测试集、以及在真实流量上测量的误报率。仅凭训练准确率就部署的探针是一个隐患。
范围窄但真实存在。如果模型忽略了放在长文档中间的指令,注意力模式会直接显示位置结构。这是一个合法的用例,因为所声称的是关于路由的——这正是注意力所报告的——而不是关于因果关系的。修复通常是移动指令,而看到模式后这就成了一个决策而不是猜测。
在求助任何这些技术之前,请求路径通常有答案。Multigrid 记录每个请求的模型、token 数量和延迟,这能告诉你回归是否从特定部署开始、是否与提示词长度相关、以及是一个模型还是所有模型。周二出现的异常行为是一个部署问题,没有任何激活值能告诉你这一点。
生产模型的电路分析。针对小模型中窄粒度行为的数月工作。没有哪个版本能塞进一个事故响应中。
作为行为控制的 steering 向量。真实存在,但几乎总是被系统提示词加输出检查所击败——后者可审计、可跨模型版本移植、不需要系数扫描。参见 steering 页面了解它确实能赢的场景。
作为监控的稀疏自编码器特征。研究前景看好。但在操作上,这意味着训练和维护第二个模型来解释第一个,然后验证它的特征确实如其标签所述。看着它就好,现在还不要基于它构建。
作为用户面向解释的归因图。在显著图页面已经覆盖过:最令人信服的图恰恰是那些通过理智检查的。向用户展示你无法验证的解释比不展示更糟糕。
先写评估集。二十到五十个失败的 case,包含预期输出。没有它你无法判断你学到的任何东西是否有帮助,而构建评估集经常能直接解决问题。
在开源模型上复现。如果 bug 无法在你有权重的模型上复现,内部结构就不可用,调查到此为止。
一次性廉价地插桩。为你的失败和通过 case 捕获隐藏状态,一次完成并保存。之后的一切都是对存储张量的分析,而不是重复推理。
做探针,带对照任务。问模型是否表示了它正在犯错的区别。否定答案是有信息的:它说修复是数据或检索方面的,而不是提示词方面的。
只通过干预来确认。修补或消融来测试你形成的假设。如果你无法陈述什么结果会证伪它,你还没准备好运行它。