解釈可能性(Interpretability)の技術的課題

Anthropicの解釈可能性(Interpretability)チームは2024年6月13日、「The engineering challenges of scaling interpretability」という記事を公開しました。解釈可能性研究の規模は、アルゴリズムの工夫よりもデータ量とインフラを扱うエンジニアリング力に律速され始めています(データ重複とスケーリング則で性能はどう壊れるかも参照)。2023年10月に公開された「Towards Monosemanticity」は、比較的小さなトランスフォーマーモデルに辞書学習(dictionary learning)を適用した研究でしたが、2024年5月公開の「Scaling Monosemanticity」では、桁違いに大きなモデルへ同じ手法を適用し、Claude 3 Sonnetの中に数千万個の「特徴」を発見しています。この規模の飛躍を陰で支えたのが、以下の2つのエンジニアリング上の壁です。

分散シャッフル — カード1組から倉庫全体のシャッフルへ

Sparse autoencoderの学習には、トランスフォーマーの活性化データを事前にシャッフルしておく必要があります。順序に依存した見せかけのパターンをモデルに学習させないためです。研究チームが小規模だった当初は、学習データを1台のGPUに収められたため、シャッフルは些細な作業でした。しかしデータ量がメモリに収まらない規模に増えると、事情が一変します。難易度は、トランプ1組のシャッフルから倉庫いっぱいのカードのシャッフルへと跳ね上がります。

最初に採用したのは、実装は速いがスケールしない方式でした。K個のジョブに分割し、各ジョブが出力データの1/Kを担当します。ジョブごとに全学習データをストリーミングで読み込み、自分の担当分だけを書き出す方式です。この方式には明確な欠点があり、各ジョブが全学習データを読み切る必要がありました。「Towards Monosemanticity」の頃には学習データが100TB(1,000億件のデータポイント、1件あたり1KB)に達しており、シャッフル処理は数時間から数日かかる大きな悩みの種になっていました。

この問題を、研究チームはあるブログ記事を参考にした多段シャッフルへの拡張で解決しました。1パスあたりN個のジョブが動き、各ジョブはデータセットの1/Nを読み込んでシャッフルし、K個のファイルに1/NKずつ書き出します。各ジョブが書き出した最初のファイルを集めると、最終的にシャッフルされたデータの1/Kに相当する部分集合が得られますが、それ自体はまだシャッフルされていません。これを1パスで100分の1に圧縮できるよう設計すると、パス数を重ねるごとに扱えるデータ規模は次のように増えます。

この方式の導入以降、シャッフルは検討事項から外れました。

特徴可視化パイプライン — 数百万特徴を100Mトークンから可視化する

もう1つの技術的課題は、特徴可視化(feature visualization)のためのデータ生成です。特徴可視化とは、個々の特徴がどのトークンで強く活性化するかをユーザーが確認できるようにする仕組みで、「Towards Monosemanticity」論文のFeature Browserで公開されているものです。

課題は、数百万個の特徴それぞれについて、活性化レベルの異なる多様なデータセット例を見つけ出す必要がある点です。100Mトークンのデータセットに対して数百万特徴を扱うには、次のような複数段階の分散処理が必要でした。

1. データセットと特徴の両方を分割(シャード)し、各ジョブが担当するデータのスライスを走査。担当する特徴ごとに、最も強く活性化するK個のトークンと、ランダムに選んだ10×K個のトークンを記録する
2. 特徴側でシャードし直して前段の結果を集約。これでデータセット全体を通じた「特徴ごとの最強活性化トークン」と「ランダムサンプル」が確定する
3. 各トークン例について、周辺トークンでの特徴の発火具合を計算する必要がある。最初は特徴ごとにシャードして必要な活性化データを読み込む方式を試したが、対象トークンがデータセット全体にランダムに散らばっているため、必要なデータだけを効率よく読み出す方法がなかった
4. そこで、データセット側でシャードし直すパスを追加。各ジョブが担当する活性化データを読み、特徴グループごとに個別ファイルへ保存する。その後、特徴側でパスを回せば、必要なデータだけに簡単にアクセスできるようになる

この4段階の分散処理を経て生成されたデータが、「Towards Monosemanticity」論文で公開されたFeature Browserを裏側から支えています。数百万個という特徴の数に対してデータセットが100Mトークンという規模である以上、素朴な全数探索ではなく、シャードの切り方をデータセット軸と特徴軸で切り替える設計が必須になった、という点がこの課題の核心です。

研究とエンジニアリングは不可分

Sparse Autoencoderの研究を始めた当初は、そのアプローチがうまくいくかどうか分かっていませんでした。実験を重ねて手応えを得るたびにインフラへの投資を増やし、それが「Scaling Monosemanticity」まで積み重なってきたという経緯です。多くの研究アイデアは実を結ばないため、うまくいく兆しが見えるまではインフラに過剰投資しないという判断基準がありました。チームメンバーは研究とエンジニアリングを頻繁に行き来し、現行システムから性能を絞り出して新しい実験を走らせては、また研究に戻るというサイクルを繰り返しています。

なぜ「特定分野の専門家」より「ジェネラリスト」を求めるのか

FAQでは採用方針についても具体的に触れられています。日々の研究の進め方は非常に探索的である一方、その探索はResponsible Scaling Policyが定める安全マイルストーンとの関係で方向づけられます。解釈可能性研究の全体像のどこにギャップがあり、チームがどの問題に取り組める立場にあるかを見極めながら、次に何を研究するかが決まります。

拠点についても具体的に記載があります。チームメンバーはサンフランシスコ・ボストン・ニューヨーク・シアトル・ロンドンに在籍し、最も人数が多いのはサンフランシスコで、そこに所属するメンバーは週に数日出社しています。リモート勤務も受け入れており、その場合は年間のおよそ25%をAnthropicのオフィス訪問に充てることが条件になります。

こうした背景から、採用ではパイプライン構築・機械学習実験の実行・GPU利用の最適化といった異なる領域を柔軟に横断できる「ジェネラリストのエンジニア」が特に重視されます。分散シャッフルや特徴可視化パイプラインの実例が示す通り、この研究領域で成果を出すには、特定のアルゴリズムに詳しいだけでなく、大規模な分散システムを自分の手で組み立てられる能力が欠かせません。

採用広報として書かれたことが示すボトルネックの所在

記事の締めくくりでは、この内容を書いた動機がエンジニア採用にあることが明記されています。分散シャッフルや特徴可視化パイプラインで紹介した2つの実例は、Research Engineerというポジションで実際に取り組むことになる問題の縮図として提示されたものです。記事は「もしこうした問題に興味を持ったなら、ぜひ応募してほしい」と読者に直接呼びかけて締めくくられています。研究成果の発表と採用広報が一体になっている点は、解釈可能性研究のボトルネックがエンジニアリング人材の不足にあるという冒頭の主張を裏付けています。

まとめ

解釈可能性研究の進展は、「良いアルゴリズムを思いつくこと」だけでは決まらず、ペタバイト級のデータをどう分散処理するかという泥臭いエンジニアリングに強く律速されます。分散シャッフルと特徴可視化パイプラインという2つの具体的な実例は、Claude 3 Sonnetで数千万個もの特徴を見つけた「Scaling Monosemanticity」の裏側を支えたインフラそのものでもあります。モデルの内部を透明にする研究の速度は、こうしたエンジニアリング投資の量に直接左右されるという点は、Anthropicの安全性研究がどのように製品へつながっているかを理解するうえでも押さえておきたい背景です。華やかな研究成果の裏には、地味なデータ処理の作業が積み重なっているという事実は、研究発表だけを追っていると見えにくい部分です。関連する研究チームの取り組みは「J-space」を探った解釈可能性研究でも扱っています。研究から製品への具体的な経路はAnthropicの安全性研究がClaude製品のどこに入っているかにまとめていますので、あわせて参照してください。