はじめに
複数のLLMを組み合わせるMulti-Agentシステムでは、モデル間の情報伝達に自然言語やJSONを使うことが一般的です。
例えば、
Context
↓
Sender LLM
↓
要約を生成
↓
Receiver LLM
↓
Answer
という構成です。
分かりやすい一方で、SenderはReceiverへ情報を渡すためだけに文章を自己回帰的に生成する必要があります。
そこで面白いと思ったのが、
XBridge: Entity-Grounded Latent Bridge for Heterogeneous LLM Communication
です。
XBridgeは、SenderがReceiver向けの文章を生成する代わりに、トークン情報とLLM内部の隠れ状態を組み合わせて情報を伝えるdecode-freeな通信方式です。
なぜ隠れ状態だけではダメなのか？
単純に、
Sender Hidden States
↓
Receiver
とすればよさそうですが、異なるLLMでは問題があります。
Representation Mismatch
例えばLlamaとQwenでは内部表現の空間が異なります。
単純に次元を射影してReceiverへ注入しても、Receiverから見ると分布外の表現になってしまう可能性があります。
XBridgeではReceiverからSenderの隠れ状態へCross Attentionすることで、この問題に対処します。PDFでは、Receiver自身の隠れ状態をQueryとしてSender側を参照する構造として説明されています。
Rare-token Compression Collapse
もう一つ重要なのが、
Rare-token Compression Collapse
です。
潜在表現では文脈の意味を保持できても、
- 人名
- 地名
- 数値
- レアトークン
などの正確なアイデンティティを失う場合があります。
実際、HotpotQAでは連続ブリッジのみの場合、F1が約30%まで低下しています。
XBridgeはLAM + LEBで解決する
そこでXBridgeでは、通信を2つの経路に分けます。
1. LAM：Lexical Anchor Mapping
LAMはSenderのコンテキストトークンをReceiver側の語彙へ変換します。
共通する表層文字列があれば直接対応させ、それ以外は一度文字列へ戻してReceiverのTokenizerで再トークナイズします。LAM自体は決定論的で、学習を必要としません。
つまり、
正確な名前や数値などをトークンとしてReceiverへ渡す経路
です。
2. LEB：Latent Enrichment Bridge
LEBはSenderの隠れ状態をCross AttentionによってReceiverへ取り込みます。
論文のLlama→Qwen構成では、Receiverの28層のうち、
Layer 6 / 13 / 20 / 27
にLEBを挿入します。
各モジュールは約66M parametersで、合計約264M parametersです。
ざっくり言えば、
LAMが「何について話しているか」を正確に保持し、LEBがSenderの持つ文脈的な表現を追加する
という役割分担です。
Ablationが面白い
HotpotQA（Llama → Qwen）の結果を見ると、LAMとLEBの違いが分かりやすいです。
| Method | F1 |
|---|---|
| NoComm | 24.6 |
| LEB-only | 30.3 |
| LAM-only | 56.5 |
| XBridge | 78.8 |
LEBだけでは30.3ですが、LAMを使うと56.5まで上がり、LAM + LEBでは78.8まで改善しています。
特に興味深いのは、潜在表現だけでは正確なEntityを伝えるのが難しいことです。
PDFに掲載されているEntity摂動実験でも、LAM側のEntityを置き換えるとReceiverの出力も置換Entityへ移る一方、LEBだけを置き換えても出力Entityは変化しませんでした。
この結果から、LAMとLEBには異なる役割があることが分かります。
自然言語通信より高速
もう一つ面白いのが速度です。
HotpotQAでは、
| Method | Latency |
|---|---|
| NLComm | 1.70 sec/sample |
| XBridge | 0.15 sec/sample |
となり、約11倍高速と報告されています。
理由はシンプルで、SenderがReceiver向けの文章を自己回帰的に生成する必要がないからです。Senderは単一のforward passのみを実行します。
ただし、XBridgeでもReceiver側ではコンテキストを処理する必要があります。
そのため、
「長いContextの計算コストそのものがなくなる技術」ではなく、「Senderの通信文生成を省略できる技術」
と理解するのがよさそうです。
小さいSenderでも使える？
個人的に気になったのがこの実験です。
ReceiverをLlama-3.1-8Bとした条件では、
| Sender | F1 |
|---|---|
| Qwen2.5-1.5B | 59.5 |
| Qwen2.5-7B | 61.9 |
| Qwen2.5-14B | 62.1 |
となっています。
Senderを7Bから1.5Bまで小さくしても、性能差は比較的小さくなっています。
ただし、これはSenderの小型化を評価した実験です。
Receiverまで小型化して同じように機能するかは別問題なので、ここは実際に試してみたいところです。
ローカルGPUで再現してみたい
次はXBridgeをローカル環境で再現してみようと思います。
本家と同じ8B/7B構成だけではなく、小型モデルを使ったMini-XBridgeも試して、
- No Communication
- Natural Language Communication
- Full Context
- LAM-only
- LEB-only
- LAM + LEB
を比較したいです。
さらに、
- QA F1
- Entity Accuracy
- Latency
- VRAM使用量
- Bridge学習時間
も測定してみます。
Bridge自体はReceiver全体の約3.8%にあたる264M parametersで、論文では587サンプルを使い単一GPUで10分未満の学習だったとされています。
コンシューマGPUと小型LLMでも同じ傾向が出るのか、かなり気になるところです。
まとめ
XBridgeを最初に見ると、
「LLM同士が言葉を使わず通信する」
技術に見えます。
ただ、実際にはもう少し正確に、
SenderがReceiver向けの文章を生成せず、Lexicalな情報とLatent Representationを組み合わせて通信する
仕組みと捉えるのがよさそうです。
特に面白かったのは、
「潜在表現だけでは意味は伝わっても、正確なEntityが壊れることがある」
という点です。
そこで、
LAM = 正確なLexical情報
LEB = SenderのLatent Representation
という2つの経路を組み合わせるのがXBridgeのポイントです。PDFでも、この二重チャネルによって離散的なEntity identityと連続的な文脈知識を分離して扱う構成として説明されています。
次は実際に公式実装を動かして、ローカルGPUでMini-XBridgeを作れるか試してみようと思います。
参考
- Wooseong Yang et al., XBridge: Entity-Grounded Latent Bridge for Heterogeneous LLM Communication
- XBridge Official Implementation（論文資料にも実装コードの公開先が記載されています）