私は、数学、機械学習、またはエージェント的コーディングに関心のある人たちと協力して、最先端の数学研究を行うためのマルチエージェント・フレームワークを作りたいと考えています。私の核となるアイデアは、Claudeの力を使ってトランスフォーマーのアーキテクチャを構築することです。
アーキテクチャ（Q/K/V アテンション）
具体的には、claude 1体が「agent teams」機能を通じて複数のclaudeチームを制御する構成です。チームリーダーは「attention head（注意ヘッド）」のclaudeで、チームメンバーは「mlp（多層パーセプトロン）」のclaudeです。
ClaudeFormerはトランスフォーマーに正確に対応しています。各コンポーネントには直接の対応物があります。
Workers = MLPs（ワーカー＝MLP）。各ワーカーのClaudeは単一のファイルを維持します。そのファイルは `residual.md` で、そこには彼らの完全な知識状態が含まれています。すべての計算、すべてのパターン、すべての推論（conjecture）、すべての証明の試み。ワーカーはこのファイルを読み、考え、Macaulay2の計算を行い、ファイルを更新します。ファイルそれ自体が状態です。ワーカーの会話コンテキストが圧縮されたり、あるいは最初から作り直されたりしても、その残差ファイルを読み直せば、完全に回復できます。ワーカーは実質的に、残差ストリームに適用される無状態の関数です。
The Router = Attention Mechanism（ルーター＝アテンション機構）。Claudeが1体、注意ヘッドとして振る舞います。しかし重要なのは、全員の残差ファイルを（各ファイルが1つのClaudeが実際に扱えるコンテキスト量と同程度の最大35万トークン、つまり最大350Kトークンずつになり得ます）読むのではないことです。その代わりに、各ワーカーは短い要約（2〜5Kトークン）を公開します。そこにはKeys（「自分が見つけたこと」）とQueries（「自分が必要としていること」）が含まれます。ルーターはすべての要約を読み、アテンションを計算します。「ワーカー1の発見Xは、ワーカー7の質問Yに答えている」。そしてそれをディスパッチします。
Values = Written by the Source（Values＝ソースが書く）。ルーターが、いくつかの情報をワーカー間で共有すると決めたら、ワーカー1に「あなたのHasse不変量データをワーカー7へ送って—彼らはそれが必要だ」と伝えます。するとワーカー1は、ワーカー7が必要としている内容に合わせて、Valueを直接ワーカー7のインボックス用ファイルへ書き込みます。ソースがValueを書き込むのは、自分の仕事を最もよく理解しているからです。
Verification = A Routing Decision（検証＝ルーティングの判断）。ルーターが、ワーカーの要約内に証明の主張（proof claim）を見つけたら、それを敵対者（adversary）へルーティングします。「ワーカー1、あなたの証明をワーカー5に送って。ワーカー5、これを反証しようとしてください。」これは特別な検証フェーズで起こるのではなく、ディスパッチ中に自然に起こります。
なぜうまくいくと期待しているのか、その理論
ClaudeFormerは、はるかに大きなコンテキストウィンドウで問題に取り組む「単一のClaude」をエミュレートすることを意図しています。その発想は、30,000,000トークンのコンテキストを持つClaudeを、各々が1,000,000トークンのコンテキストを持つ30個のClaudeでシミュレートできる、というものです。
30,000,000トークンのコンテキストを持つClaudeの利点は、その30,000,000トークンの中で、問題に関する非常に多くの異なる質問やアプローチを探索できることです。そして、探索中の現在のアイデアと過去のどこかのアイデアが結びつきそうなら、そのつながりはコンテキスト内にあり、結びつきが実際に作られます。つまり、コンテキストウィンドウを大幅に増やすことが与える本当の利点は、その巨大なコンテキストをまたいでつながりを作れることです。
ただし、コンテキストウィンドウ内の過去情報のうち、実際に現在の問題に関連しているのはだいたい10%程度である、というヒューリスティックがあります。そこで、30,000,000トークンのコンテキストウィンドウを持つClaudeはそのすべての情報をコンテキストに含めますが、関連する情報だけを選択的にルーティングするルーターを用意すれば、無関係な情報でコンテキストを埋めてしまわずに、それをエミュレートできます。
二層の情報階層によって、このスケールが可能になります。ワーカーは巨大な私有ファイル（350Kトークン）を保持しますが、短い要約（2〜5Kトークン）を通じて通信します。ルーターはN個の要約を読みます。N個のフルファイルを読むのではありません。ワーカーが30人いて、それぞれが5Kトークンなら、ルーターは150Kトークンを読むことになります。これは単一のコンテキストウィンドウの範囲内に十分収まります。
スケーリングの次元
アーキテクチャは3つの方法でスケールします。
コンテキストウィンドウ：並行して働くClaudeの数。各ワーカーの残差ファイルは最大350Kトークンまで保持できます。これは膨大な量の研究コンテキストです。ワーカーが増えるほど、同時に探索できる方向性が増えます。
深さ：どれだけ多くのディスパッチサイクルを回すか。各サイクルでは、ワーカーが考える → 要約を公開する → ルーターがディスパッチする → ワーカーが値を交換する → ワーカーが統合して続行する。深さを増やすほど、アイデアの相互混入が増えます。ここでの制約は、単一のclaudeが実際に使える残差ストリームのドキュメントがどれくらいの長さまでか、という点です。
アテンションヘッド：もし90人のワーカclaudeがいるなら、単一の注意ヘッドでは90個すべての要約を効果的に読み取ることはできません。その代わりに、複数の注意ヘッドを用意し、それぞれがワーカのサブグループを見ます。すべてのワーカのペアが少なくとも1つの注意ヘッドにカバーされるように配置します。
私が持ち込めるもの／協力依頼
この問題に取り組むために私が用意しているインフラは次のとおりです。私はエージェント的エンジニアで、Claude Codeを使った幅広い経験があります。さらに、計算機科学の修士課程をほぼ修了しています。また、現在数学のPhDを取っている友人がいて、このプロジェクトに興味を持っており、私たちの結果を検証してくれます。さらに、このシステムが本当に進展しているかどうかについて、良いヒューリスティックを提供してくれるでしょう。加えて、文献検索をしてみた限りでは、この種のアーキテクチャは検討されていないようです。
興味があればコメントするかDMしてください！一緒に取り組めそうです。
[link] [comments]
