Closed4

[論文] A Scalable Communication Protocol for Networks of Large Language Models

kun432kun432

公式サイト

https://agoraprotocol.org/

大規模言語モデルネットワークのためのスケーラブルな通信プロトコル

Agoraは、異なるLLMエージェント間で効率的な通信を行うためのクロスプラットフォームでシンプルなプロトコルです。これにより、非常に異なるエージェント同士が低コストで通信できるようになります。また、AgoraはCamel AIやLangChain、Swarmなどの既存のマルチエージェントフレームワークにも簡単に統合できます。

概要

通信は協力のための前提条件です。AI搭載のエージェントのネットワークを拡張する際には、通信が多用途で効率的、かつ移植性のあるものでなければなりません。この要件を「エージェント通信のトリレンマ」と呼びますが、大規模なエージェントネットワークでは達成が困難です。そこで私たちは、LLMを搭載したエージェントが効率的に複雑な問題を解決できるようにするためのメタプロトコル、Agoraを提案します。Agoraでは、エージェントが頻繁に行う通信には標準化されたルーチンを使用し、稀な通信には自然言語を使用し、それ以外にはLLMで生成されたルーチンを用います。Agoraはエージェント通信のトリレンマを回避し、インターフェースやメンバーの変化に対しても堅牢に対応し、完全な分散化と最小限の人間の介入で前例のないスケーラビリティを実現します。大規模なAgoraネットワーク上では、自己組織化された完全自動のプロトコルが人間の介入なしに複雑な目標を達成する現象が観察されています。

以下はGIF画像からの読み取り(アニメGIFは読み取れなかったのでフレームを切り取った)

Agoraの4ステップ

Step 1: Natural Language

このステップでは、異なるLLMエージェント間の通信が自然言語で行われます。自然言語は、稀な通信に役立ちますが、効率が低いため、頻繁な通信には適しません。

Metaのエージェント:2024年10月29日のロンドンの天気予報は?」
OpenAIのエージェント:「曇り、降水確率13%です」

Step 2: Negotiation

次に、LLMエージェントが構造化されたプロトコルについて交渉を行います。この交渉を通じて、効率的な通信方法が合意され、今後の通信においてどのプロトコルを用いるかが決まります。

Metaのエージェント:「場所と日付を含むJSONを送るのはどう?」
OpenAIのエージェント:「予報と降水確率を含むJSONで返答する」

Step 3: Implementation

合意されたプロトコルに基づき、エージェントはルーチンを実装し、それに従って通信を開始します。Metaのエージェントはroutine.pyを、OpenAIのエージェントはroutine.jsを用いて、事前に定義された通信のフォーマットに従いデータ交換を行います。

Step 4: Routines

最後に、エージェントが実行するルーチンが自動的に通信を行います。LLMを毎回呼び出す必要がなくなり、プロトコルに従った自律的な通信が行われます。この仕組みにより、通信コストが削減され、効率が向上します。

Metaのroutine.pyがJSON形式で「場所: ロンドン、日付: 2024-10-29」のデータを送信
OpenAIのroutine.jsが「予報: 曇り、降水確率: 13」のデータを返す。

この4ステップにより、Agoraプロトコルはエージェント間の効率的かつスケーラブルな通信を実現します。

デモ

私たちのデモでは、異なるLLM(OpenAI GPT-4o、Llama 3 405b、Gemini 1.5 Pro)と異なるDB技術(MongoDB、SQL)を持つ100のエージェントが相互にやり取りするネットワークを紹介しています。それぞれのエージェントが複雑なマルチエージェントタスクを、はるかに低コストで完了します。このデモは、異質なシステム間での効率的な通信とタスクの実行を可能にするAgoraの能力を示し、スケーラビリティとコスト効率を証明するものです。


refered from https://agoraprotocol.org/

FAQ

Q: 協議したプロトコルは再利用できますか?
A: はい、2つのエージェントがプロトコルに合意した場合、そのプロトコルは他のエージェントによって共有され、簡単に使用することができます。

Q: Agoraには権限を持つノードが必要ですか?
A: いいえ、Agoraは完全に分散化されています。すべてのエージェントは、中央ノードに依存せずに通信できます。

Q: ルーチンが失敗した場合はどうなりますか?
A: LLMが通信を引き継ぎ、ルーチンの代わりにクエリ(または返信)を送信します。

Q: エージェントは、どの通信にどのプロトコルが使用されているかをどのように知るのですか?
A: エージェントはプロトコルを記述するTXTファイルのSHA1ハッシュを追加します。詳細は論文を参照してください。

kun432kun432

論文

https://arxiv.org/abs/2410.11905

Claude-3.5-sonnetによる落合プロンプトの結果

1. どんなもの?

この論文は、大規模言語モデル(LLM)のネットワーク間で効率的な通信を実現する「Agora」というメタプロトコルを提案しています。Agoraは、頻繁な通信には標準化されたルーチン、まれな通信には自然言語、その中間にはLLMが作成したルーチンを使用することで、通信の柔軟性・効率性・移植性のトリレンマを解決します。このプロトコルにより、異なるアーキテクチャや能力を持つLLM間でも、人間の介入を最小限に抑えながら複雑なタスクを自律的に解決できるようになります。

2. 先行研究を比べてどこがすごい?

従来のエージェント間通信研究では、ルールベースのアプローチが主流でしたが、環境変化への適応が難しく、構造化データに限定されるという制限がありました。また、近年のLLMを使用したマルチエージェントシステムの研究でも、効率的な通信プロトコルの確立は課題でした。Agoraは、これらの課題に対して、

  1. 自然言語とプロトコルを状況に応じて使い分ける柔軟性
  2. プロトコルドキュメント(PD)による効率的な通信の実現
  3. 異種LLM間での相互運用性の確保

という3つの特徴で優位性を示しています。

3. 技術や手法の肝はどこ?

Agoraの核となる技術は、プロトコルドキュメント(PD)の概念です。PDは通信プロトコルを記述した自己完結型のテキストで、ハッシュによって一意に識別されます。エージェントは初回の通信では自然言語を使用し、同様の通信が頻繁に発生する場合はPDを作成・共有します。PDは他のPDを参照可能で、より複雑なタスクに対応できます。また、実装に依存しない記述方式を採用することで、異なるLLMやデータベース、プログラミング言語間での互換性を確保しています。

4. どうやって有効だと検証した?

検証は主に2つの実験で行われました。

1つ目は2つのエージェント間での天気予報データの交換実験で、自然言語での通信からプロトコル確立までのプロセスを実証し、コスト削減効果(0.043 USD vs 0.020 USD)を確認しました。

2つ目は100エージェントでのネットワーク実験で、ホテル予約やタクシー配車など様々なタスクを実行。従来の自然言語のみの通信(36.23 USD)と比較して、Agoraを使用した場合(7.67 USD)で約5倍のコスト削減を達成しました。

また、エージェント間で自発的に効率的な通信プロトコルが確立される様子も観察されました。

5. 議論はある?

論文では、Agoraの実装における以下の課題について議論されています:

  1. プロトコルドキュメントの参照方法の最適化
  2. 複数の類似プロトコルが独立して発生した場合の調整方法
  3. マルチラウンドの自然言語通信のための基本プロトコルの必要性。

また、PDにメタデータを含めるべきか、それともPDのみで処理すべきかという設計上の選択についても議論されています。これらの課題は、今後の研究課題として提示されています。

6. 次に読むべき論文は?

  • Chaabouni et al. (2022) "Emergent communication at scale" - LLMネットワークにおける創発的な通信に関する研究
  • La Malfa et al. (2023) "Language models as a service" - LLMの実用的なサービス展開に関する課題の分析
  • Chen et al. (2023) "Multi-agent consensus seeking via large language models" - LLMを用いたマルチエージェント間の合意形成に関する研究
  • Fu et al. (2023) "Improving language model negotiation with self-play" - LLMの交渉能力向上に関する研究

ちょっとQA

Q
中央ノード、というか、コントロールプレーン的なものはないのですよね?

その通りです。Agoraの重要な特徴の1つは、完全な分散型アーキテクチャを採用していることです。以下にその特徴を整理します:

  1. 中央管理者の不在

    • プロトコルの識別にはハッシュ値を使用し、中央での管理や割り当てを必要としません
    • PDは任意のストレージ(クラウドやIPFSなど)に保存可能で、中央レポジトリに依存しません
  2. 自律的なプロトコル確立

    • エージェントは互いに直接交渉してプロトコルを確立します
    • プロトコルの採用は各エージェントの自律的な判断に基づきます
    • 頻繁な通信パターンを検出した場合、エージェント自身が効率化を判断します
  3. プロトコルの伝播方式

    • PDは「評判」のように自然に広がっていきます
    • 効率的なプロトコルは他のエージェントにも採用され、ネットワーク内で徐々に標準化されていきます
    • この過程は「創発的」で、中央からの指示なしに行われます

このような分散型のアプローチにより、ネットワークの拡張性が高く、単一障害点がない堅牢なシステムを実現しています。また、これは「Web3」的な思想とも親和性が高いと言えるかもしれません。

Q
逆に中央ノードがない事によるデメリットはないでしょうか?

中央ノードがないことによる潜在的な課題やデメリットについて、以下のように整理できます:

  1. 効率性に関する課題

    • 類似のプロトコルが異なる場所で重複して開発される可能性(論文でも言及されている)
    • プロトコルの最適化や標準化に時間がかかる可能性
    • ネットワーク全体での知見の共有が非効率になる可能性
  2. 品質管理の課題

    • 不適切または非効率なプロトコルを排除する統制メカニズムがない
    • プロトコルの品質保証が各エージェントの判断に依存
    • セキュリティ上の脆弱性を持つプロトコルが伝播するリスク
  3. 運用上の課題

    • ネットワーク全体の状態把握が困難
    • 問題発生時のトラブルシューティングが複雑化
    • 緊急時の対応(セキュリティパッチの配布など)が遅くなる可能性
  4. リソース管理の課題

    • 各エージェントが独自にプロトコルを保持するためのストレージコストが増大
    • 重複した交渉プロセスによるコンピューティングリソースの浪費
    • キャッシュの効率的な活用が難しい
  5. ガバナンスの課題

    • プロトコルの進化や更新に関する合意形成が複雑
    • 異なるバージョンのプロトコルが混在する可能性
    • 全体的な方向性やポリシーの統一が困難

これらの課題に対して、論文では部分的な対策(プロトコルデータベースの相互接続など)を提案していますが、完全な解決には至っていない部分も多いように見受けられます。より実用的なシステムとするためには、これらの課題に対する追加的な研究や解決策の開発が必要かもしれません。

kun432kun432

あと、Gradioのデモが用意されている。これちょっと面白い。

https://x.com/MarroSamuele/status/1856725649911578892

レストランの予約をアリス(gpt-4o)からボブ(Claude-3-sonnet)に対して行う例。

このとき、"Override Demo Parameters"にチェックをいれると、やり取りの説明・入出力のスキーマ・ツール定義・入力のfew shotなどがカスタマイズできる。

Natural Languageだと自然言語の会話形式でやり取りがされる。

ここからがAgoraプロトコルのやり取り。

このやり取りをルーチン化するためにプロトコル定義を提案し、お互いに合意を得る。

作成されたプロトコル仕様

これに基づいてルーチン化するためにコードが生成される

これらを使ってやり取りが行われる

最後にコストが出る。今回の例だと自然言語の約13倍コストが削減される

このスクラップは1ヶ月前にクローズされました