複雑性を乗り越える：マルチエージェント LLM による統合的問題解決(Navigating Complexity: Orchestrated Problem Solving with Multi-Agent LLMs という論文の和訳)

Navigating Complexity: Orchestrated Problem Solving with Multi-Agent LLMs
という論文を和訳しました。

https://arxiv.org/html/2402.16713v2

## tl;dr

1. 複雑なタスクは分割しよう
1. 分割したタスクはそれぞれの専門エージェントに解かせよう
1. 精度上がったよ
1. 専門エージェントの能力がかぶることがありえるのは課題だよ

## 概要
要旨
大規模言語モデル（LLM）は様々なタスクを解決する上で驚くべき能力を示してきましたが、複雑で曖昧な問題を包括的に扱うことには依然として苦戦しています。マルチエージェントLLMシステムを含む既存のアプローチは、特定の課題に対する解決策を提供していますが、手動のセットアップが必要であり、スケーラビリティに欠けています。この課題に対処するため、我々は分解を活用してLLMが曖昧な問題を効果的に扱えるようにする新しいアプローチを提案します。

我々のアプローチでは、オーケストレーティングLLMがユーザーとやり取りして問題を理解し、それを具体的なサブ問題に分解します。LLMが一度に問題全体を解決するのではなく、ユーザーの要求をより深く理解するためのフォローアップ質問をするよう訓練します。問題が十分に理解されると、オーケストレーティングLLMはそれをより小さく管理しやすいサブ問題に分割します。各サブ問題は、専門のLLM エージェントまたは非 LLM 機能に割り当てられて解決されます。これらのエージェントは並行して各サブ問題を解決し、オーケストレーティングLLMがプロセスを監督し、解決策をユーザーのための包括的な回答にまとめます。

この分解アプローチを採用することで、LLM 出力のトークン制限による制約を緩和し、複雑で曖昧な問題に対してニュアンスのある解決策を提供する能力を強化します。我々のアプローチを通じて、LLM がより人間のように考え、操作できるようにすることを目指します。複雑な問題を管理可能な部分に分解し、協力して解決することで、LLM の問題解決能力を向上させるだけでなく、幅広い現実世界の課題に対処するためのスケーラブルで効率的な方法を提供します。

## 1. 導入

近年、大規模言語モデル（LLM）の普及により、様々な分野での問題解決が革新されました[[Devlin et al., 2018]](https://arxiv.org/abs/1810.04805) [[Patil et al., 2023]](https://arxiv.org/abs/2305.15334) [[Touvron et al., 2023]](https://arxiv.org/abs/2302.13971)。これらのモデルはユーザーのクエリを理解し、応答を生成する能力を持ち、しばしば新しい洞察や解決策を提供します[[Wei et al., 2022a]](https://arxiv.org/abs/2201.11903)。特に、LLMはゼロショットやフューショット学習技術で対処できるタスクで優れた性能を発揮し[[Brown et al., 2020]](https://arxiv.org/abs/2005.14165)、質問を馴染みのある形式に変換したり、類似の例に基づいてコーディング問題を解決したりします[[Chen et al., 2021]](https://arxiv.org/abs/2107.03374) [[Sanh et al., 2021]](https://arxiv.org/abs/2110.08207)。そのため、多様な専門分野で多くのタスクを自動化し、ワークフローを効率化する大きな可能性を秘めています[[Liu et al., 2023b]](https://arxiv.org/abs/2303.16634)[[Chiang and Lee, 2023]](https://arxiv.org/abs/2305.01937) [[Gao et al., 2023]](https://arxiv.org/abs/2304.02554) [Shen et al., 2023](https://arxiv.org/abs/2305.13091) [Zheng et al., 2023](https://arxiv.org/abs/2306.05685)。

しかし、その優れた能力にもかかわらず、LLMには限界があります。幻覚、矛盾する応答、ユーザークエリの誤解などの事例は、問題解決にこれらのモデルのみに頼ることの課題を浮き彫りにしています[[Azamfirei et al., 2023]](https://ccforum.biomedcentral.com/articles/10.1186/s13054-023-04393-x)。新しい問題を体系的に解決するためにユーザーを支援する既存のフレームワークは、LLMモデルが課されるトークン制限によって制約されています[[Gur et al., 2023]](https://arxiv.org/abs/2307.12856)。これらの制限は、LLMが1つのメッセージやクエリで処理できる単語やトークンの数を制限し、しばしば応答の包括性を妨げ、会話の連続性を阻害します。以前の会話をチェーンで繋げたり、意味検索技術を採用したりするアプローチは、これらの課題の一部を軽減しますが、検索された情報の冗長性や無関連性などのエラーの影響を受けやすいです[[Ouyang et al., 2022]](https://arxiv.org/abs/2203.02155) [[Saunders et al., 2022]](https://arxiv.org/abs/2206.05802) [[Liu et al., 2023a]](https://arxiv.org/abs/2305.01210)。

これらの限界に対処するため、長文や複雑な問題に取り組むマルチエージェントフレームワークを活用することが有望な方向性です[[Du et al., 2023]](https://arxiv.org/abs/2305.14325) [[Cohen et al., 2023]](https://arxiv.org/abs/2305.13281) [[Dafoe et al., 2021]](https://www.nature.com/articles/d41586-021-01170-0) [[Dafoe et al., 2020]](https://arxiv.org/abs/2012.08630) [[Kramár et al., 2022]](https://www.nature.com/articles/s41467-022-34473-5) [[Yao et al., 2022]](https://arxiv.org/abs/2210.03629)。このようなフレームワークは、問題解決タスクを複数の LLM エージェントに分散させ、ヒューリスティックな方法と比較してより堅牢なアプローチを提供します[Li et al., 2023](https://arxiv.org/abs/2303.17760) [[Liang et al., 2023]](https://arxiv.org/abs/2305.19118) [[Qian et al., 2023]](https://arxiv.org/abs/2307.07924) [[Lazaridou et al., 2020]](https://arxiv.org/abs/2005.07064) [[Graesser et al., 2020]](https://arxiv.org/abs/1901.08706) [[Lee et al., 2018]](https://arxiv.org/abs/1710.06922) [[Wu et al., 2023]](https://arxiv.org/abs/2303.15078)。しかし、各 LLM エージェントにペルソナや役割を手動で割り当てることは、特に事前定義された役割のない新しい問題を対処する際にボトルネックとなります[Rasal, 2024]。

本論文では、既存のアプローチの長所を統合しつつ、その限界に対処する新しい解決策を提案します。我々のアプローチは、長文や複雑な問題のシームレスな解決を促進するために問題分解を採用するオーケストレーション戦略を中心としています。人間の問題解決アプローチにヒントを得て、我々のフレームワークは、問題の要件を確認するためにユーザーと反復的な会話を行うオーケストレーションLLMを含みます。要件が明らかになると、オーケストレーションLLMは問題を管理可能なサブ問題に分解し、それらを問題の特定の側面に対処するように調整された専門エージェントに割り当てます。特筆すべきは、我々のアプローチが必要に応じて非LLM機能を組み込み、実世界のタスクへの堅牢性と適応性を向上させていることです[[Qin et al., 2023]](https://arxiv.org/abs/2307.16789)。問題分解と分散タスク割り当てを活用することで、我々のフレームワークはLLMを用いた問題解決のための包括的でスケーラブルなソリューションを提供します。

これが我々の提案です：

• 我々の提案するソリューションは、人間の問題解決アプローチにヒントを得た問題分解とマルチエージェントオーケストレーションを統合し、既存のフレームワークの限界に対処します。
• 問題分解と分散タスク割り当てを活用することで、我々のフレームワークはLLMを用いた問題解決のための包括的でスケーラブルなソリューションを提供し、実世界のタスクへの適応性を向上させます。

## 2. 方法論

これらの課題に対応するため、我々の方法論は、単にメモリ拡張に頼るのではなく、アルゴリズムの改良によってトークン制限の問題に対処する新しいアプローチを採用しています。我々の方法論の中核には、オーケストレーションLLMの開発があります。これは、ユーザーの問題文を理解し、それを管理可能なサブ問題に分解し、専門化されたLLMエージェント間の相互作用を調整する責任を担っています。

人間の問題解決戦略にヒントを得て、我々の方法論は複雑なタスクをより小さく、消化しやすい要素に分解するプロセスを模倣しています。高度な自然言語処理（NLP）技術を用いて複雑なクエリを分析・解剖し、様々な領域にまたがる個別のサブ問題を特定します。これらのサブ問題は、データ分析、クリエイティブライティング、技術的問題解決などの特定のタスクに事前訓練された専門の LLM エージェントにマッピングされ、その応答の精度と関連性を確保します。

実生活のシナリオで専門知識を求めることに類似して、我々の方法論は問題解決の結果を最適化するために領域専門家との協力を活用します。例えば、個人が効率的な税務申告のために税務専門家を求めるのと同様に、我々のアプローチは領域特有の課題に効果的に取り組むために専門化されたエージェントを統合します。

さらに、我々は問題領域、必要な専門知識、タスクの複雑さなどの事前定義された基準に基づいて、オーケストレーション LLM が複雑な問題を分解できるアルゴリズムフレームワークを開発します。最後に、問題解決プロセスを効率化し、リソース利用を最適化するために、可用性、専門知識、ワークロードなどの要因を考慮して、選択された専門エージェント間でサブ問題を割り当てるタスク割り当てシステムを実装します。

私たちのフレームワークの高レベルアルゴリズムは `LABEL:tab:problem_solving` にあります

| ステップ | LLMsを用いた問題解決のオーケストレーション |
| --- | --- |
| 1 | 複雑な問題文を要求する |
| 2 | 問題に対する包括的な解決策を確保する |
| 3 | 開始 |
| 4 | 複雑な問題文を入力する |
| 5 | 問題をサブ問題に分解する |
| 6 | 各サブ問題に対して以下を実行する |
| 7 | - サブ問題の領域と要件に基づいて、専門のLLMエージェントを選択する |
| 8 | - 選択されたエージェントにサブ問題を割り当てる |
| 9 | - エージェントがサブ問題を解決し、解決策を保存する |
| 10 | 終了（各サブ問題に対するループの終了） |
| 11 | - サブ問題の解決策を一貫性のある全体的な解決策に集約する |
| 12 | - 包括的な解決策を出力する |
| 13 | 終了 |

### 2.1 分解アプローチ
我々のフレームワークの実装は、ユーザーが複雑な問題文を提出することから始まり、LangChain フレームワーク内の会話インターフェースを通じて行われます[[Chase, 2022]](https://github.com/langchain-ai/langchain)。オーケストレーション LLM 内で、この入力は綿密に処理され、重要な情報と要件が正確に抽出・分析されます。その後、オーケストレーションLLMは洗練された分解アルゴリズムをシームレスに適用し、問題を管理可能なサブ問題に体系的に分解し、プロセス全体を通じて明確さと精度を確保します。

分解アプローチは、GPT4 モデル[[OpenAI, 2023]](https://arxiv.org/abs/2303.08774) [[Bubeck et al., 2023]](https://arxiv.org/abs/2303.12712) を用いた一連の few-shot を反復して作成されました。当初、LLM モデルは主要な問題を曖昧なサブ問題に分解しましたが、期待される分解形式に合わせるため、さらなる改良が必要でした。few-shot を活用し、モデルに思考連鎖型の推論を提供して、効果的に分解プロセスを導きました。

分解が成功すると、オーケストレーション LLM は、これらのサブ問題を最適な専門 LLM エージェントに割り当てる重要な役割を担います。この割り当てプロセスは、各サブ問題が効果的に対処するために必要な専門知識と能力を持つエージェントに委ねられるよう、綿密に調整されています。

フレームワークの有効性の中心となるのは、その礎石となる分解フェーズです。初期設計は意図的に、多様な問題領域に適応可能で一般化できるように作られ、専門的なユースケースシステムの開発よりも分解能力の実証を優先しました。

## 3. 実験

私たちの実験は、オーケストレーション LLM エージェントの活用を中心に展開しています。このエージェントは OpenAI の gpt-4 モデル [[OpenAI, 2023]](https://arxiv.org/abs/2303.08774) を使用し、ユーザーと巧みに対話して要件を明確にし、その後問題を管理可能なサブ問題に分解します。このオーケストレーション LLM は、各サブ問題に対処するのに最も適した専門 LLM エージェントも決定します。実験で使用される各専門 LLM エージェントは、OpenAI の gpt3.5-turbo モデルをベースとし、temperature を `0.0` に設定して、応答の一貫性と創造性のバランスを反映しています。LLMエ ージェント間のコミュニケーションを促進するのは LangChain フレームワークであり、これによりシームレスなマルチエージェント間の相互作用が可能となり、問題解決に焦点を当てることができます。

### 3.1 実験1 : LLM エージェントを用いた旅行計画

この実験では、ユーザーが自身の旅行計画をフレームワークに提示し、オーケストレーションLLMとの対話を開始して要件を洗練させ、その後問題をサブ問題に分解します。オーケストレーションLLMは専門エージェントにタスクを割り当て、完了後、エージェントは最終的な行動方針にまとめられる結果を提供します。実行前に、オーケストレーションLLMはユーザーと詳細を確認し、正確性を確保します。

以下はフレームワークの会話出力です。

```text
初期対話：要件の収集

ユーザー：シカゴ空港からニューアーク空港への往復便を2024年3月22日から3月26日まで予約する必要があります。贅沢に飛行したいので、午前10時から午後4時の間に移動したいです。

オーケストレーションLLMエージェント：承知しました。最適なオプションを見つけるために、座席クラスの希望や、フライト中に必要な追加サービスについて具体的に教えていただけますか？

ユーザー：ビジネスクラスを希望し、機内Wi-Fiへのアクセスと窓側の座席が欲しいです。

オーケストレーションLLMエージェントが問題を分解

オーケストレーションLLMエージェントはユーザーの要求を処理し、専門エージェントが処理するサブ問題に分解します：

フライト検索エージェント：2024年3月22日の午前10時から午後4時の間にシカゴからニューアークへ出発し、3月26日に帰国するビジネスクラスの便を探す。

アメニティ設定エージェント：ビジネスクラスで機内Wi-Fiと窓側座席を提供している航空会社を特定する。

予約エージェント：フライトオプションが選択された後、予約プロセスを処理する。

専門エージェントとの対話

オーケストレーションLLMエージェントからフライト検索エージェントへ：2024年3月22日の午前10時から午後4時の間にシカゴからニューアークへ出発し、3月26日に帰国するビジネスクラスの便を探してください。

フライト検索エージェント：いくつかのオプションが見つかりました。

オーケストレーションLLMエージェントからアメニティ設定エージェントへ：これらのオプションのうち、ビジネスクラスで機内Wi-Fiと窓側座席を提供しているのはどれですか？

アメニティ設定エージェント：[条件を満たす航空会社をリストアップ]

オプションの最終決定

オーケストレーションLLMエージェントからユーザーへ：ご希望に基づき、ビジネスクラス、機内Wi-Fi、窓側座席を提供する最適なフライトオプションをご紹介します。[オプションを提示]

ユーザー：3月22日の午後2時発のエアラインXのオプションを選びます。

オーケストレーションLLMエージェントから予約エージェントへ：3月22日午後2時発のエアラインXの便を、ビジネスクラス、窓側座席、機内Wi-Fi付きで予約してください。

予約エージェント：フライトが予約されました。こちらが予約確認の詳細です。
```

### 3.2 実験 2 : 探索的研究と要約

ユーザーは探索的な研究クエリをフレームワークに投げかけ、オーケストレーションLLMに問題をサブ問題に分割し、専門エージェントにタスクを割り当てるよう促します。タスクの完了後、専門エージェントは出力を提供し、それらはオーケストレーションLLMによって包括的な要約に統合されます。必要に応じて最終出力を洗練させるため、ユーザーからのフィードバックが求められます。

以下はフレームワークの会話出力です。

```text
初期対話：要件の収集

ユーザー：LLM における長期記憶管理に関するトピックについて、現在可能なことと不可能なことに焦点を当てて研究する必要があります。そして、これらの調査結果をまとめ、将来の研究方向を提案する 5 ページの記事を作成したいです。

オーケストレーション LLM エージェントが問題を分解

オーケストレーション LLM エージェントは要求を分析し、いくつかの主要なタスクを特定します：

文献レビューエージェント：LLM における長期記憶管理に関する既存の研究の包括的なレビューを実施。

分析エージェント：収集した研究を分析し、解決済みの問題、進行中の課題、未探索の領域を区別。

執筆エージェント：調査結果を一貫性のある5ページの記事にまとめ、現在の能力と限界を強調し、将来の研究方向を提案。

専門エージェントとの対話

タスク1：文献レビューの実施

オーケストレーションLLMエージェントから文献レビューエージェントへ：LLMにおける長期記憶管理に関する主要な研究論文を特定し要約し、方法論、発見、制限に焦点を当てる。

文献レビューエージェント：[長期記憶管理に関連する主要な方法論、発見、課題、制限を含む論文の要約を返す。]

タスク2：研究の分析

オーケストレーションLLMエージェントから分析エージェントへ：文献レビューに基づき、LLMにおける長期記憶管理の現状を分析し、可能なこと、依然として課題となっていること、将来の研究の潜在的な領域を特定する。

分析エージェント：[LLMにおける長期記憶管理の現在の能力と制限を区別し、将来の研究方向の提案を含む分析を提供する。]

タスク3：記事の執筆

オーケストレーションLLMエージェントから執筆エージェントへ：収集・分析された情報を使用して、LLMにおける長期記憶管理に関する調査結果をまとめた5ページの記事を執筆する。現在可能なこと、制限、将来の研究のためのアイデアを強調する。

執筆エージェント：[既存の研究の概要、現在の制限、提案された将来の方向性を含む、LLMにおける長期記憶管理の現状をまとめた5ページの記事を草稿する。]

記事の最終化

オーケストレーションLLMエージェントからユーザーへ：専門エージェントによって実施された包括的な研究と分析に基づき、LLMにおける長期記憶管理の現状をまとめた5ページの記事を作成しました。この記事では、現在可能なこと、主な課題と制限、将来の研究の潜在的な領域について議論しています。

ユーザー：記事をレビューし、必要に応じてフィードバックを提供するか修正を要求する。
```

## 4. 結果

研究で一般的に使用される従来のデータセットのみに依存するのではなく、我々のアプローチの能力を具体的に示すために GSM8K データセットを選択し、フレームワークの有効性を評価することにしました。実験では 4 種類の異なるエージェントを使用しました：GPT3.5-turbo モデルを使用した単一の LLM エージェント、GPT3.5-turbo モデルを使用した 2 つの LLM エージェント、GPT3.5-turbo モデルに思考連鎖とペルソナアプローチを組み合わせた 2 つのLLMエージェント[[Wei et al., 2022b]](https://arxiv.org/abs/2201.11903) [[Rasal, 2024]](https://arxiv.org/abs/2401.01312)、そして最後に、オーケストレーションと分解方法論にGPT4モデル[[OpenAI, 2023]](https://arxiv.org/abs/2303.08774)を使用し、専門化されたLLMエージェントにGPT3.5-turboモデルを使用した2つのLLMエージェントで、これは主要な問題をサブ問題に分解することを含みます。我々のオーケストレーションフレームワークは既存の方法論に対して顕著な進歩を示しており、詳細な結果は表 1 に示されています。

>「GSM8K は、人間の問題作成者によって作られた 8,500 個の高品質な小学校レベルの数学問題で構成されています。これらは 7,500 個のトレーニング問題と 1,000 個のテスト問題に分けられています。これらの問題は解くのに 2 から 8 ステップを要し、解法は主に基本的な算術演算（+ - / *）を使用して一連の初歩的な計算を行い、最終的な答えに到達することを含みます。優秀な中学生であれば、すべての問題を解くことができるはずです。」[[Cobbe et al., 2021]](https://arxiv.org/abs/2110.14168)

さらに、我々の観察によると、数学に特化した LLM エージェントを使用するよりも、電卓機能を使用した場合に精度が大幅に向上することが示されました。この改善は、LLM が様々な分野で多様性を持っているにもかかわらず、数学的演算を実行する際の固有の限界に起因しています。我々は、LLM を数学的演算のために訓練するのではなく、我々のフレームワークが、サブ問題が LLM エージェントを必要とするのか、それとも非 LLM のアプローチを必要とするのかを見分ける LLM の調整を促進すると主張します。

| Agent | Solve Rate |
| --- | --- |
| Single GPT3.5-turbo | 50% |
| Multi-Agent GPT3.5-turbo | 55% |
| Multi-Agent GPT3.5-turbo (LLM-Harmony) | 65% |
| Multi-Agent GPT4 (Our Approach)  | 73% |

## 5. 制限事項
我々の分解フレームワークは重要な進歩を表していますが、考慮すべき固有の制限があります。これらの制限の中で最も重要なのは、新規または既存のあらゆる問題シナリオに対応するための一般化が不足していることです。多様な問題解決アプローチを包括的に理解するために、基盤となる大規模言語モデル（LLM）として機能するオーケストレーションモデルをさらにトレーニングする必要性を認識しています。現在、モデルは様々な問題を分解する能力を示していますが、その範囲は将来の課題の複雑さに対応できない可能性があります。

例えば、ユーザーが交通手段を要求した場合を考えてみましょう。現在のモデルは問題を巧みに分解し、乗車予約が可能な専門エージェントを生成します。しかし複数の専門エージェントがこの能力を持つシナリオがありえます。そのような場合、オーケストレーションLLMは最適な行動方針を決定する課題に直面します。さらに、このフレームワークには新しい専門エージェントに関する情報を取り込む仕組みがなく、オーケストレーション LLM の知識ベースを継続的に更新するための再トレーニングメカニズムの必要性が浮き彫りになっています。

また、現在のモデルは問題を効果的に分解しますが、分解ステップの結果に基づいて問題解決戦略を反復的に学習し改善する能力が欠如しています。この制限に対処することが、我々の今後の研究の重要な焦点となります。しかしながら、本論文の主な目的は、読者に我々の分解アプローチを周知し、問題解決の文脈におけるその応用についての洞察を提供することです。

## 6.結論

結論として、本論文では大規模言語モデル（LLM）によって調整される分解フレームワークを用いた問題解決への新しいアプローチを紹介しています。複雑な問題文を管理可能な部分問題に慎重に分解することで、我々のフレームワークは問題解決プロセスを効率化し、現在の LLM ベースのソリューションに内在する制限を緩和する可能性を示しています。ユーザーのクエリを理解し問題を分解する LLM の固有の能力を活用することで、我々のアプローチは様々な分野にわたる幅広い課題に対処するための有望な道筋を提供します。

フレームワークの実装は、複雑な問題文を分解し、専門化された LLM エージェントにタスクを割り当てる効果を強調し、一貫性のある包括的な解決策をもたらします。さらに、我々の実験は旅行計画や研究要約生成などのタスクを容易にするフレームワークの多様性を強調し、実世界のシナリオにおける適用可能性を示しています。

しかし、我々の研究はさらなる研究開発が必要ないくつかの制限も明らかにしています。分解フレームワークは大きな進歩を表していますが、新しい問題シナリオへの一般化は継続的な課題です。加えて、フレームワークは適応学習や新しい専門エージェントの統合のためのメカニズムが欠如しており、将来の改善の余地を示しています。

これらの制限にもかかわらず、本論文は体系的でスケーラブルなフレームワークを導入することで、LLMベースの問題解決アプローチに関する成長する文献に貢献しています。我々のアプローチと洞察を共有することで、この分野でのさらなる研究と革新を刺激し、問題解決能力の向上と人工一般知能の実現への道を開くことを目指しています。