M61：机制可解释性、推理与 Verifier：一页小结

内容类型：预习教材（不代表已完成）
日期：2026-10-23
阶段：P1 · AI Model Engineering 90
周次：W9
节奏：周五一页小结
状态：教材已备；学习未完成
标签：mechanistic-interpretability activation intervention verifier test-time-compute

一句话定义

机制可解释性试图用可干预、可复现的内部证据解释模型行为，而 verifier 与 test-time compute 则从输出侧增加检查和搜索；三者共同回答“模型为什么这样答，以及怎样更可靠地得到答案”。

学习目标

1. 串起 activation、feature、intervention、verifier 与 test-time compute 的关系。
2. 区分观察性证据、相关性证据和因果性证据能支持的结论强度。
3. 理解内部解释与外部验证互补，但都不能自动等同于真实业务正确性。
4. 能为一个高风险模型结论设计最低限度的证据链。

核心知识

1. Activation 不是“概念本身”

activation 是模型在特定输入与特定层、位置、通道上的数值状态。它像一次运行留下的内部轨迹：可以被记录、比较和干预，但某个神经元数值较大，并不能直接证明它“代表欺诈”“代表否定”或“理解了客户”。同一概念可能分布在多个维度，一个维度也可能承载多个上下文相关特征。

feature 是研究者根据跨样本模式提出的可解释结构。它可能来自线性探针、稀疏自编码器、聚类或人工对照，但名称仍是外部赋义。可信度来自稳定复现、对照样本和干预效果，而不是一张好看的热力图。

2. 从相关到因果的证据阶梯

可以把证据由弱到强排列为：输出案例 → attention/activation 可视化 → 探针可预测 → 定向消融或替换 → 在多个样本和反事实上稳定复现。可视化说明“某处发生了活动”，探针说明“信息可被读出”，干预才更接近说明“这部分信息参与导致了结果”。即便干预成功，也应限制结论范围：它证明的是特定模型、层位、输入分布和干预方式下的因果影响，并非完整的人类可读推理过程。

3. Verifier 检查候选，不读取模型内心

verifier 接收答案、步骤、证据或结构化字段，输出通过/拒绝、分数或排序。规则校验器适合格式、范围、余额守恒等确定约束；执行校验器适合代码、SQL、数学表达式；学习型 judge 能处理开放文本，但会继承偏差、提示敏感性与模型共谋风险。Verifier 的目标应尽量接近“可验证条件”，不要让模糊的“看起来不错”分数替代事实。

4. Test-time compute 是推理时资源分配

single pass 只生成一次；self-consistency 生成多个候选再投票；best-of-N 用 verifier 排序；cascade 先运行便宜模型，低置信度时升级；搜索式方法在步骤空间扩展与剪枝。增加计算量可能提升覆盖率，却也带来延迟、成本和相关错误重复。关键不是“思考越久越好”，而是新增样本或检查是否提供独立信息。

机制与推导

一条可用的可靠性链可以写成：输入分布与任务边界 → 模型生成候选 → verifier 检查可验证约束 → 必要时追加候选或升级模型 → 聚合结果 → 保留证据与不确定性 → 人或下游规则作最终决定。

内部机制研究位于“模型生成候选”内部，帮助定位特征和失败原因；verifier 位于候选之后，负责检查；test-time compute 是调度策略。三者不能互相替代：解释出某个 feature 不保证答案正确，答案通过格式检查不证明内部推理可靠，多采样达成一致也可能只是同源偏差。

可以用一个简单决策式选择额外计算：当“错误损失 × 额外验证带来的错误下降”大于“额外延迟与成本”时，才值得升级。这里的错误下降必须由留出样本估计，而不是凭直觉设置。

最小练习

选择一个“从文档中提取金额并判断是否超限”的小场景，画三栏表：

1. 内部观察：记录某层 activation 或 attention，仅写“观察到什么”。
2. 外部验证：用正则/解析器检查金额格式，用规则检查阈值，用原文定位检查证据。
3. 升级策略：首次失败时重试还是升级模型；第二次失败是否拒答并转人工。

然后为每项标记它能支持的结论，例如“金额字段可从输出解析”，而不是越级写成“模型理解了账单”。不需要真实运行模型，也不要填写虚构结果。

常见误区

• 把 attention 权重直接称为模型解释。
• 看到 probe 准确率高，就断言该特征被模型实际用于决策。
• 用另一个语言模型 judge 所有问题，却没有 judge 自身的校准与失败集。
• 认为多数投票天然正确；多个候选可能共享同一错误模式。
• 把客户可理解的业务理由与模型内部因果机制混为一谈。
• 只计算 token 成本，不考虑延迟、人工复核和错误损失。

金融、Web3 与文档场景连接

在反洗钱告警中，客户可见理由应来自规则、交易证据和政策条款，而不是未经验证的神经元解释；机制可解释性更适合研发阶段定位捷径特征。链上风险判断可使用交易哈希、金额守恒、地址标签来源等可执行 verifier。合同或账单抽取可用坐标、原文片段和字段约束形成证据链。高风险结论若无法验证，应允许 abstention，而不是靠增加采样次数强行给答案。

自检问题

1. activation、feature 与 mechanism 分别是什么，证据强度有何不同？
2. 为什么 probe 能读出信息，不等于模型用该信息作决策？
3. verifier 检查的对象是什么，它最容易出现哪三类偏差？
4. self-consistency 与 verifier cascade 的目标和成本有何区别？
5. 面向客户的业务理由为什么不能直接由内部 activation 推导？

专业课程对齐

• ARENA Mechanistic Interpretability：对应 Transformer 内部表征、activation inspection、ablation 与因果干预入门；重点不是记术语，而是区分“读得到”“改动后会影响输出”和“已经解释完整机制”。
• TransformerLens 官方文档：对应 hook、activation cache、组件级定位与 patching 工具；观察 residual stream、attention output、MLP output 在层和 token 位置上的张量形状与干预边界。
• ARENA 主课程：对应推理、训练与模型行为的整体背景，用来把内部机制证据放回模型工程全链路，而不是把单个 neuron 或 probe 当成业务解释。

深入学习提示

先精读 ARENA 机制可解释性导论，画出“相关性观察 → probe → ablation/patching → 可重复因果效应”的证据阶梯；再按需查 TransformerLens 的 hook 与 cache API，核对一次干预实际替换的是哪个 batch、token、layer 和 component。若做实验，预先写下效应量，例如 $\Delta = s(x; a\leftarrow a')-s(x)$，同时设置干预位置、负对照位置和未干预基线。最后选读 ARENA 主课程中与推理或 verifier 相邻的内容，检查 verifier 是外部候选检查器，不是“读取模型想法”。本日结论只能落到指定输入、指标与干预范围，不能从一次 activation 变化外推稳定概念、完整 circuit 或面向客户的理由。

建议在小结图上为每条证据注明观察对象、对照、效应量与可重复范围，让以后回看时能迅速识别“已测到什么”和“尚未证明什么”。

学后填写区

• 我现在能清楚区分的三类证据：
• 我仍然会混淆的概念：
• 我为一个场景设计的 verifier：
• 我认为值得追加 test-time compute 的条件：
• 后续要回看的资料或问题：