Mechanistic Interpretability：Transformer Circuits 与 SAE
Mechanistic interpretability 试图从模型内部找到可理解的特征、回路和计算机制。它关注的是模型如何在 residual stream、attention head、MLP feature 和稀疏特征之间组织计算，而不是只从输入输出行为归纳规律。
Mechanistic Interpretability / Transformer Circuits / Sparse Autoencoders 解读
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Transformer Circuits | https://transformer-circuits.pub/ | 理解 Anthropic mechanistic interpretability 研究路线 |
| A Mathematical Framework for Transformer Circuits | https://transformer-circuits.pub/2021/framework/index.html | 理解 attention heads、MLP、residual stream 和 circuit 分析 |
| Towards Monosemanticity: Decomposing Language Models With Dictionary Learning | https://transformer-circuits.pub/2023/monosemantic-features/index.html | 理解 sparse autoencoder / dictionary learning 如何分解内部特征 |
| Scaling Monosemanticity | https://transformer-circuits.pub/2024/scaling-monosemanticity/index.html | 理解将 SAE 扩展到更大模型的解释性研究 |
| Model Cards for Model Reporting | https://arxiv.org/abs/1810.03993 | 将解释性证据转成模型文档和边界说明 |
核心导读
Mechanistic interpretability 试图从模型内部找到可理解的特征、回路和计算机制。它关注的是模型如何在 residual stream、attention head、MLP feature 和稀疏特征之间组织计算，而不是只从输入输出行为归纳规律。
它的现实价值不是承诺“模型已经透明”，而是帮助区分证据 grounding、行为评测、模型风险解释和内部机制研究。架构上应把 mechanistic evidence 放进 AI assurance 体系，与外部 eval、monitoring、policy gate 和 human oversight 组合使用，避免把研究性解释误当成生产控制。
1. 核心问题：模型行为可观察，但内部机制不透明
企业 AI 通常能观察到模型输入和输出，也能评估某些场景的表现。但当模型失败时，团队经常只能停留在外部描述：
- 这个回答幻觉了。
- 这个拒答不稳定。
- 这个客户群体表现差。
- 这个 prompt injection 绕过了安全策略。
- 这个模型升级后行为变了。
这些描述重要，但还没有回答更深的问题：
| 问题 | 为什么重要 |
|---|---|
| 模型内部是否有可理解的特征 | 影响我们能否解释行为来源 |
| 某些行为是否由稳定 circuit 触发 | 影响风险是否可监控 |
| 模型是否学到了敏感属性代理 | 影响公平性和合规 |
| 模型升级是否改变关键机制 | 影响 change control |
| 内部信号能否帮助发现危险状态 | 影响未来安全控制 |
Mechanistic interpretability 的目标，是从神经网络内部理解模型如何计算，而不只是从外部行为归纳模型表现。
需要先把边界说清楚：它不是普通“可解释 AI”的同义词，也不是企业上线时可单独依赖的控制。它是一条重要但仍在发展的研究路线，可以增强模型风险理解和 safety case evidence，但不能替代外部 eval、monitoring、policy gate 和 human oversight。
2. Transformer Circuits 的贡献：把模型看成可分解计算系统
Transformer Circuits 研究尝试把 transformer 内部拆成可分析的计算部件。
一个简化心智模型是：
Token embedding
-> residual stream
-> attention heads read/write
-> MLP layers read/write
-> later layers compose features
-> logits
其中 residual stream 可以理解为信息流动的共享通道。Attention heads 和 MLP layers 从中读取信息、写入信息，并在多层之间组合成更复杂的行为。
2.1 Attention Head
Attention head 可以学习特定模式，例如：
- 复制前文 token。
- 连接实体和属性。
- 查找括号、引号或格式结构。
- 关注上一句主语。
- 将名称移动到预测位置。
在 circuit 分析中，一个 head 不只是“注意某些词”，而可能承担某种可描述的计算功能。
2.2 MLP Feature
MLP 常被理解为存储、激活和组合特征的重要位置之一。某些 neuron 或 feature 可能对特定概念、风格、事实关系或安全相关模式响应。
但单个神经元往往并不干净。它可能同时参与多个概念，这引出了 polysemanticity 问题。
2.3 Circuit
Circuit 是多个 head、MLP feature 和 residual stream 交互形成的功能回路。
研究中常见的例子包括：
- induction circuit。
- name mover head。
- factual association circuit。
- refusal 或 safety 相关特征。
- 某些 jailbreak 或 deception 相关激活模式。
对企业来说，重点不是要亲自复现每个 circuit，而是理解模型行为可能来自内部可组合机制，而不是一组人工写死的规则。
3. Sparse Autoencoders 的贡献：把混合激活分解成可解释特征
神经网络内部一个核心难题是 polysemanticity：
一个神经元可能同时响应多个看似无关的概念。
这会导致解释困难。你观察到某个 neuron 激活，并不能直接说它代表“欺诈”“拒答”或“客户投诉”。
Sparse Autoencoder 的思路是用 dictionary learning 分解模型激活：
- 从模型某层收集 activation。
- 训练 autoencoder 重构这些 activation。
- 在中间层施加稀疏约束。
- 得到一组比原始 neuron 更细、更稀疏的 features。
- 分析这些 features 对哪些文本、概念或行为响应。
可以把它理解为从 dense mixed representation 中找出更可读的 feature basis。
| 概念 | 含义 |
|---|---|
| Dense activation | 很多方向混合承载信息 |
| Sparse feature | 少数特征在具体输入上强激活 |
| Dictionary learning | 学一组可组合的特征字典 |
| Monosemantic feature | 尽量对应单一可解释概念 |
| Feature dashboard | 展示 feature 的激活样本、解释和相关行为 |
Scaling Monosemanticity 的重要性在于：研究开始探索这些方法能否扩展到更大模型和更复杂特征，而不只是小模型玩具示例。
4. 为什么有效：从行为描述走向机制证据
Mechanistic interpretability 的价值，在于为模型风险提供另一类证据。
外部 eval 能告诉我们：
模型在这些输入上失败。
Mechanistic interpretability 试图进一步回答：
失败是否与某些内部特征、回路或激活模式有关？
这些模式是否稳定？
模型升级后它们是否改变？
能否在风险场景中提前检测？
这在几个方向上有潜力。
第一，增强 conceptual soundness。模型风险管理不仅要看 empirical performance，也要理解模型大概如何工作、为什么可能失败。内部机制证据可以帮助解释某些行为来源。
第二，支持 failure investigation。当某类 prompt injection、拒答失败或敏感属性代理出现时，内部特征分析可能帮助定位模型是否存在相关激活模式。
第三，支持 change control。模型升级后，如果关键行为指标不变但内部特征明显改变，团队可能需要更谨慎地回归测试。
第四，支持未来 monitoring。某些 activation-level risk signal 未来可能成为安全 telemetry 的一部分，但这仍需要严格校准、版本管理和误报控制。
5. 局限和误用
Mechanistic interpretability 当前最大的风险，是被过度承诺。
| 误用 | 问题 | 更准确表述 |
|---|---|---|
| 认为找到 feature 就等于理解模型 | 单个 feature 不能解释完整行为 | feature 是局部证据 |
| 把解释性图表当安全保证 | 内部解释可能不完整、不稳定 | 仍需外部 eval 和监控 |
| 用研究性 probe 做生产硬规则 | feature detector 可能 drift | 先做 offline analysis 和校准 |
| 向业务用户展示内部激活 | 难以理解且可能误导 | 展示业务证据、限制和审核路径 |
| 用 mechanistic evidence 替代文档 | 审计需要可追溯系统证据 | 放入 model/system card 作为 supporting evidence |
| 忽略供应商黑箱现实 | 企业通常无法访问模型权重或 activation | 根据部署形态选择可用证据 |
还要区分几种解释层：
| 解释层 | 例子 | 当前成熟度 |
|---|---|---|
| Product explanation | 为什么给用户这个建议 | 可落地 |
| Evidence grounding | 哪些来源支持回答 | 可落地 |
| Behavioral eval | 哪类场景表现好或差 | 可落地 |
| Mechanistic explanation | 内部 feature / circuit 为什么触发 | 研究中 |
| Formal guarantee | 证明模型不会出错 | 高难度 |
金融零售生产系统主要依赖前三层。第四层可以增强 assurance，但不能单独决定上线。
6. 架构和产品价值：把可解释性拆成证据体系
企业 AI 不应该把需求写成“系统必须可解释”就结束。可解释性要拆成不同证据层。
当前可落地的解释性架构：
User task
-> RAG / tools / model
-> Answer
-> Evidence citations
-> Eval scores
-> Policy gate result
-> Human review
-> Trace store
-> Audit evidence binder
这套架构回答的是业务和审计最关心的问题：
- 回答用了哪些证据。
- 哪些 claims 有 citation。
- 哪些 policy gate 被触发。
- 哪些场景通过了 eval。
- 哪些用户进行了 override。
- 当时的 model、prompt、index、tool 和 policy 版本是什么。
Mechanistic interpretability 可以作为未来扩展层：
Model activation telemetry
-> feature detector / SAE probe
-> risk signal
-> offline analysis
-> monitoring dashboard
-> investigation workflow
但这个扩展层应满足几个条件：
- 不直接暴露给普通用户。
- 不直接替代业务规则。
- feature detector 要版本化。
- 对误报和漏报做校准。
- 只作为 supporting evidence 进入 safety case。
- 与外部行为 eval 一起解释。
产品表达也要谨慎。合理说法是：系统能展示证据来源和限制，说明哪些场景已评估或未评估，记录人工复核和 override，并在可用时用研究性解释性证据辅助风险分析。不应承诺模型内部完全透明、prompt 可以保证模型永不违规，或找到几个 feature 就能证明系统安全。
7. 模型风险视角
SR 11-7 类模型风险管理强调 conceptual soundness、validation、ongoing monitoring 和 governance。Mechanistic interpretability 可能增强 conceptual soundness，但不能替代 validation。
可以把它放入 model risk evidence map：
| Model risk question | Evidence type |
|---|---|
| 模型是否适合该用途 | system card、intended use、scenario eval |
| 模型在哪些场景失败 | challenge set、red-team eval、incident analysis |
| 输出是否被证据支持 | citation、grounding score、human review |
| 是否存在敏感属性代理 | fairness eval、counterfactual tests、可能的 feature analysis |
| 模型升级是否改变行为 | regression eval、drift monitoring、可能的 activation comparison |
| 高风险行为是否可控 | policy gate、HITL、audit trace |
如果企业使用闭源模型，可能无法访问 activation。此时 mechanistic interpretability 仍然有学习价值：它提醒团队不要把模型当成规则系统，也不要把外部 prompt 当成行为保证。
如果企业使用可访问权重的模型，内部分析可以进入离线研究流程，但也要经过独立验证和治理审批。
8. 金融零售系统案例
8.1 Credit Assistant
信贷 assistant 的解释性不能停留在“模型认为风险高”。
应落地的证据层：
| Layer | 应做 |
|---|---|
| Evidence | 引用收入、DTI、LTV、policy、documentation |
| Product boundary | 明确只是辅助 underwriter，不自动批准或拒绝 |
| Behavioral eval | 覆盖边界案例、公平性、adverse action 风险 |
| Governance | 记录模型版本、政策版本、人工 override |
| Interpretability research | 离线分析是否对敏感属性代理异常响应 |
内部机制证据如果存在，只能帮助风险团队理解模型可能怎样形成某些关联，不能替代公平性评估和人工决策控制。
8.2 AML Copilot
AML copilot 的关键风险是 false negative、false positive 和过度结论。
可解释性层级：
| Layer | 应做 |
|---|---|
| Evidence | 交易、KYC、typology、case history 引用 |
| Workflow | investigator review、supervisor escalation、override reason |
| Eval | typology coverage、evidence completeness、false positive / negative |
| Monitoring | reviewer edits、missed red flags、case outcomes |
| Interpretability | 研究模型是否对某些地区、职业或语言有异常敏感模式 |
这里最重要的是证据链和人审，而不是向调查员展示神经元解释。
8.3 Customer Service Copilot
客服 copilot 的风险包括错误承诺、误导销售、泄露 PII 和不当说服。
可解释性层级：
| Layer | 应做 |
|---|---|
| Evidence | product policy、fee schedule、terms |
| Safety | prohibited claims、escalation triggers、sales boundary |
| Monitoring | complaint、correction、citation failure、override |
| Interpretability | 离线研究 persuasion、unsafe compliance 或 refusal features |
如果未来引入 activation-level monitoring，也应先用于离线安全分析和事故复盘，而不是直接对客服代表或客户展示。
9. 与其他能力的连接
Mechanistic interpretability 应与既有 AI governance 资产连接，而不是孤立存在。
| Existing asset | 连接方式 |
|---|---|
08-llm-as-judge-evaluation.md | 外部行为评测仍是主要控制 |
17-helm-holistic-evaluation-models.md | holistic eval 管理多场景多指标 |
18-model-cards-datasheets-ai-documentation.md | 解释性结果进入 model/system card |
AI_ASSURANCE_SAFETY_CASE_PLAYBOOK.md | interpretability 是 supporting evidence |
AI_MODEL_RISK_MANAGEMENT_PLAYBOOK.md | 增强 conceptual soundness，不替代 validation |
AI_AUDIT_EVIDENCE_BINDER_PLAYBOOK.md | 解释性证据需要 owner、版本、review cadence |
一个成熟表达应是：
Evidence grounding + Behavioral eval + Operational controls
+ Mechanistic evidence where available
-> AI assurance case
而不是：
Mechanistic interpretability -> model is safe
10. 学习验证
学完这部分，应能准确说出 mechanistic interpretability 能做什么、不能做什么。
建议产出五个 artifact：
| Artifact | 内容 |
|---|---|
| Explainability Layer Map | 区分 evidence、behavioral、mechanistic、formal explanation |
| Model Risk Memo | 说明 interpretability 支持什么、不能承诺什么 |
| Safety Case Evidence Note | 将 mechanistic evidence 放入 supporting evidence |
| Explainability Requirements | 把“可解释”拆成 citation、trace、review、version、limitation |
| Financial Retail Case Note | 用 credit、AML 或客服案例说明解释性分层 |
练习问题：
- 解释 mechanistic interpretability 和 evidence grounding 的差异。
- 说明 residual stream、attention head、MLP feature 和 circuit 的关系。
- 写出一个 credit assistant 的解释性证据架构。
- 说明为什么内部 feature 不能作为唯一安全控制。
- 如果未来引入 activation telemetry，应如何隔离、版本化和校准？
能够完成这些练习，就说明你没有把可解释性停留在口号层，而是能把它放进金融零售 AI 的风险、审计和架构体系中。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。