在本文以及配套的圆桌讨论视频中，我们的研究人员回顾了科学进展与工程进展之间非常紧密的关系，并讨论了将可解释性研究扩展到更大规模 AI 模型时遇到的技术挑战。

去年 10 月，Anthropic 可解释性团队发表了《Towards Monosemanticity》，将 Dictionary Learning 应用于一个较小的 Transformer 模型。

今年 5 月，我们又发表了《Scaling Monosemanticity》，把同一种方法扩展到了规模大几个数量级的模型。

在 Claude 3 Sonnet 中，我们发现了数千万个“特征”。

这里的特征，可以理解为一组与某些语义概念相关联的神经元组合。

这项工作是理解 AI 模型内部工作机制的重要一步。

但如果想继续沿着这个方向推进，我们需要更多工程师。

如果你只读过我们较早期的论文，比如《A Mathematical Framework for Transformer Circuits》和《Toy Models of Superposition》，这件事可能有些反直觉。

因为那些工作所需要的工程投入相对有限。

但只要看看更新一些的研究，就会很明显：

我们现在面对的工程挑战规模已经完全不同。

下面我们会介绍最近研究中涉及的两个具体工程问题。

它们可以很好地说明：

• 可解释性研究中的工程师现在到底在解决什么问题；
• 为什么我们认为工程能力将成为 AI 可解释性研究，乃至 AI 安全研究的重要瓶颈之一。

---

工程问题一：分布式 Shuffle

我们使用 Sparse Autoencoder 来研究模型中的“特征”。

Sparse Autoencoder 的训练数据，来自 Transformer 的内部 Activation。

这些 Activation 必须被充分打乱，否则模型可能会学到与数据顺序相关的伪模式。

最开始训练 Sparse Autoencoder 时，全部训练数据都可以放进单块 GPU 内存。

因此：

Shuffle 非常简单。

只要把数据加载进内存，再随机打乱即可。

但随着规模扩大，数据量已经远远超过单机内存容量。

可以把这想象成：

最开始只是洗一副扑克牌。

后来却变成了：

要把整间仓库里堆满的扑克牌全部打乱。

这已经完全是另一类问题。

---

第一版方案：简单，但无法很好扩展

当时我们当然可以直接实现一个真正可扩展到 PB 级数据的分布式 Shuffle。

但我们没有马上这么做。

我们先选择了一种：

可以很快实现，但扩展性不够好的方案。

假设我们把整个 Shuffle 拆成：

K

个 Job。

每个 Job 负责最终输出数据中的：

1 / K

我们首先生成一个全局 Permutation。

然后每个 Job 都：

1. 流式读取整份训练数据；
2. 只写出属于自己那一部分的输出。

这样确实可以处理更大的数据集。

但缺点也非常明显：

每个 Job 都必须读取全部训练数据。

最开始，这一步需要几个小时。

后来需要几天。

到了《Towards Monosemanticity》时期，我们已经拥有：

100TB 训练数据。

也就是：

• 1000 亿个数据点；
• 每个数据点约 1KB。

此时 Shuffle 已经变成了一个非常严重的工程问题。

---

这是经典工程问题，但依然必须解决

可扩展的 Distributed Shuffle 并不是一个新问题。

它既不是前沿算法问题，也不是什么神秘技术。

但它正是那种：

为了继续推进科学研究，我们必须快速解决的实际工程问题。

而且这类问题并不是一个。

是很多个。

---

多轮 Shuffle

后来我们参考了一种已有方法，并把它扩展成多轮处理。

假设：

N

个 Job 同时运行。

每个 Job：

1. 读取数据集中的：

1 / N

1. 对这部分数据做局部 Shuffle；
2. 写出：

K

个文件。

每个文件大小约为：

1 / (N × K)

整个数据集。

来自所有 Job 的第一个输出文件组合起来，就构成：

最终 Shuffle 数据的前 1/K。

但这部分内部还没有完全打乱。

第二组文件、第三组文件依此类推。

于是，一轮处理后：

原本需要对整份数据做的一次超大 Shuffle，

被拆成了：

N

个更小的 Shuffle。

每个小 Shuffle 的规模缩小了：

K

倍。

---

如果还放不进内存，就再来一轮

如果这些子 Shuffle 已经可以放进单机内存：

直接在单机完成最终 Shuffle 即可。

如果仍然太大：

继续再做一轮相同过程。

假设每个 Job 最多可以在内存中保存：

100GB

数据。

每次写出：

100 个 1GB 文件。

那么每增加一轮，最终需要一次性处理的数据规模就缩小：

100 倍。

于是：

• 1 轮可以处理约 100GB；
• 2 轮可以处理约 10TB；
• 3 轮可以处理约 1PB；
• 4 轮可以处理约 100PB；
• 以此类推。

---

一个好的工程方案，最终应该“消失”

自从我们实现这一方案之后：

我们基本不再思考 Shuffle。

现在它只是：

• 自动发生；
• 很快完成；
• 很少出问题。

当然，世界上肯定存在：

• 更高效的算法；
• 更快的实现。

但这并不重要。

这个方案已经解决了我们的瓶颈。

于是我们就可以把注意力投入：

下一个真正阻碍研究的问题。

这是研究工程中的一个重要模式。

很多时候，最佳方案并不是：

“设计一个理论上最完美的系统”。

而是：

足够快地构建一个能消除当前瓶颈的系统。

---

工程问题二：Feature Visualization Pipeline

另一个重要工程问题，是生成：

Feature Visualization 所需要的底层数据。

Feature Visualization 的目标是：

让研究者能够看到：

• 哪些 Token 最强烈地激活某个 Feature；
• 这些 Activation 在数据集中的分布情况；
• 某个 Feature 在上下文周围 Token 上如何响应；
• 以及其他帮助理解 Feature 的信息。

当 Feature 数量只有少量时，这些计算很容易。

但我们现在需要处理：

数百万 Feature。

这就变成了一个很有意思的分布式系统问题。

---

目标：为每个 Feature 找到有代表性的样本

对于每一个 Feature，我们都希望收集多种不同样本。

不仅要找：

Activation 最大的例子。

还要覆盖：

整个 Activation Distribution。

这样研究者才能判断：

一个 Feature 是否真的是自己以为的那个概念。

最早，这整套流程运行在：

单个 Job。

但很快，我们就超出了单机能够处理的规模。

现在的方案则分成多轮 Distributed Pass。

---

当前规模

用于 Visualization 的数据集约为：

1 亿 Token。

需要处理：

数百万 Feature。

第一步，是同时对：

• Dataset；
• Feature；

进行 Shard。

把两边都切成很多小块。

---

第一轮：Dataset × Feature 双向分片

每个 Job 负责：

• Dataset 的一部分；
• Feature 的一部分。

对于自己负责的 Feature，每个 Job 会记录：

Top-K 激活样本

也就是：

这个 Feature 在当前 Dataset Slice 中最强的 K 个 Token。

10 × K 个随机激活样本

这些 Token 不一定是最强激活，但只要激活了该 Feature，就有机会被随机采样。

这样可以帮助我们看到：

Feature 的整个分布，而不只是极端值。

Transformer Activation 之前已经被缓存到了对象存储中。

因此，这一阶段不需要重新运行 Transformer。

---

第二轮：按 Feature 聚合

下一轮，我们改成：

按 Feature 分片。

然后聚合第一轮中所有 Job 的结果。

这一步之后，对于每个 Feature，我们可以获得：

• 整个数据集上最强的激活 Token；
• 一批随机的激活 Token。

这些就是最终 Feature Visualization 中要展示的示例。

---

接下来的问题：上下文 Token 怎么办？

只知道某一个 Token 激活了 Feature 还不够。

我们还想知道：

这个 Token 周围其他 Token 上，

Feature 是如何响应的。

因此，对每个示例：

都需要重新获取其邻近位置的 Transformer Activation。

最开始，我们的做法依然是：

按 Feature 分片。

每个 Job 负责一组 Feature。

然后它去加载：

这些 Feature 对应样本周围的 Activation。

问题是：

这些样本在整个 Dataset 中是随机分布的。

因此：

没有办法只顺序读取这个 Job 真正需要的数据。

你可能为了取几个零散位置，

被迫到整个大数据集中随机访问。

效率非常差。

---

重新换一个 Sharding 方向

为了改善这个问题，我们增加了一轮：

按 Dataset 分片的 Pass。

这时，每个 Job 负责一段连续 Transformer Activation。

然后：

把不同 Feature Group 后续所需要的 Activation，

分别写入独立文件。

这样就等于提前把随机访问：

重排成了顺序读取。

之后再运行：

按 Feature 分片的 Pass。

此时每个 Feature Job 都可以很方便地只读取：

自己真正需要的数据。

最终我们会：

1. 计算 Feature 在周围 Token 上的 Activation；
2. 把所有相关结果整理成统一格式；
3. 写出前端网页能够直接读取的数据。

---

为什么这些问题重要

Distributed Shuffle 和 Visualization Pipeline 都不是什么：

• 神秘的新算法；
• 惊人的理论突破。

但如果没有它们：

我们根本无法把可解释性实验扩展到现在这个规模。

这正是研究工程的特点。

很多时候：

科学想法只有在工程系统能承载它之后，才真正存在。

---

科学与工程并不是两个阶段

我们最开始研究 Sparse Autoencoder 时：

并不知道它最终是否真的有效。

所以一开始，我们不会立刻投入大量时间建设：

• PB 级存储系统；
• 复杂可视化平台；
• 超大规模分布式训练基础设施。

先做最小实验。

如果结果不好：

就停止。

如果结果有希望：

再把系统规模扩大一点。

然后继续实验。

随着信心增强：

我们逐渐投入更多工程能力。

这个过程一直持续到：

《Scaling Monosemanticity》。

---

研究和工程是交织进行的

这反映了可解释性团队日常工作的真实方式。

团队成员经常在：

• Research；
• Engineering；

之间来回切换。

比如：

先想办法从现有系统里再挤出一点规模，

好让一个新实验能够跑起来。

然后回到研究中分析结果。

发现新方向之后，

又回到基础设施层做下一轮扩展。

因为：

很多研究想法最终不会成功。

所以在看到有效信号之前，

我们不会立刻为每个想法建设重型基础设施。

---

Research 是团队活动

研究并不只是：

坐着思考。

同样重要的事情还有：

• 实现想法；
• 跑实验；
• 搭系统；
• Debug；
• 分析；
• 迭代；
• 扩展规模。

因此，我们更喜欢把研究理解成：

Team Science。

---

我们需要什么样的工程师

我们尤其需要：

Generalist Engineer。

也就是能够在多个领域之间灵活切换的工程师。

可能今天在做：

• Data Pipeline；

明天在：

• 跑 ML Experiment；

后天又在：

• 优化 GPU 使用；

再之后去：

• Debug Distributed System。

真正重要的不是：

只精通某一个狭窄工具。

而是：

能够快速理解新问题，并把它推进到可用状态。

---

常见问题

你们计划招聘多少人？

可解释性团队目前有：

18 名成员。

团队正在快速扩张。

当前希望招聘至少：

• 5 名 Senior Engineer；
• 2 名 Team Manager。

职位分布在多个地点。

---

可解释性团队会和其他团队合作吗？

会。

我们和其他研究团队合作非常紧密。

尤其是：

Alignment 团队。

Anthropic 的组织方式比较接近：

Team Science。

不同团队之间边界相对开放。

这让很多项目能够快速跨团队推进。

---

如何决定研究方向？

我们的长期 Research Roadmap 会参考 Anthropic 的：

Responsible Scaling Policy。

这项 Policy 要求：

在模型能力跨越某些阈值之前，

Anthropic 必须先达到对应的安全里程碑。

因此，在选择可解释性研究方向时，我们会考虑：

• 当前 Interpretability 研究格局是什么；
• 哪些问题是我们最有能力解决的；
• 我们的研究能否帮助实现对应安全里程碑。

不过在日常层面：

研究依然非常探索性。

只是这种探索会受到上述长期目标引导。

---

团队成员过去都是什么背景？

背景非常多样。

包括：

• Neuroscience；
• Mathematics；
• Biology；
• Physics；
• Data Visualization；
• Software Engineering。

这也是为什么我们尤其看重：

跨领域解决问题的能力。

---

一定要在旧金山吗？

团队成员目前分布在：

• San Francisco；
• Boston；
• New York；
• Seattle；
• London。

人数最多的地点是：

San Francisco。

当地成员通常每周会有几天到办公室工作。

团队也支持 Remote。

但远程成员预计每年大约：

25% 的时间

需要前往 Anthropic Office。

---

总结

可解释性研究看起来经常像：

• 数学；
• 神经网络分析；
• Feature Interpretability。

但随着模型规模增长，

真正决定研究能不能继续推进的因素，越来越多地来自：

工程。

比如：

• 如何 Shuffle 100TB 数据；
• 如何为数百万 Feature 找到有代表性的 Activation；
• 如何避免随机读取造成的巨大 I/O 成本；
• 如何把研究原型快速扩展成分布式 Pipeline。

这些问题中的大多数都不是：

新的计算机科学难题。

但它们必须：

• 被正确实现；
• 在合适的时间实现；
• 足够稳定；
• 足够快。

而且不能为了一个尚未证明有效的研究方向，

过早投入大量基础设施成本。

可解释性研究真正需要的，不只是更好的科学想法。

也需要能够不断把这些想法：

做出来、跑起来、扩大规模。

这也是为什么，对 Anthropic 来说：

Research 和 Engineering 并不是可以分开的两件事。