オープンソースの小規模モデルに基づく、GPT-4 を上回る 3 つのエージェント

本当の「三人の靴屋は一人の諸葛亮より優れている」 -

オープンソースの小規模モデルに基づく 3 つのエージェントの連携は、GPT-4 のツール呼び出し効果に匹敵します。

では早速、2つのシステムの実行記録を見てみましょう。

ユーザーは、さまざまな音楽ジャンルやミュージシャンを探求したい音楽愛好家であると述べました。したがって、指定されたモデルは、Deezer および Shazam API を使用して、いくつかの音楽トラックと対応するアーティスト情報を検索します。

その後、3つの異なる役割を「演じる」エージェントが作業を分担し、協力して2ステップ以内にタスクを完了しました。

より難しいオプションは、ツールを指定せずに、最も人気のある風景画のチュートリアルビデオと、ビデオがアップロードされたチャンネルの詳細をモデルに見つけてもらうことです。

この場合、モデルでは通常、ツールが棚から削除されたり、ツールに必要なパラメータの定義が変更されたりするなど、ツールのステータスの変更が発生します。

ただし、上記の方法を使用すると、モデルはステップ 0 で video_for_simple_youtube_search を使用してビデオの詳細を取得しようとしましたが、この API が壊れていて呼び出すことができないことがわかりました。

そこで、プランナー役のエージェントは考え方を変えて、発信者役のエージェントに別の API を試す必要があることを伝えます。最終的に、新しい API を試すことで詳細な情報を発見し、ユーザーのタスクを解決します。

これは、中山大学とアリババ同義研究所が共同で提案したオープンソースの小規模モデルに基づくマルチモデル協調エージェントフレームワークであるα-UMiです。

α-UMiは、複数のオープンソースの小さなモデルを微調整することで協調操作を実現し、ツール呼び出しなどのデータセットにおけるパフォーマンスはGPT-4に匹敵します。

一般的に、他のクローズドソース API フレームワークと比較して、α-UMi には次のような利点があります。

• α-UMi マルチモデル共同フレームワークに基づいて、プランナー、呼び出し元、サマライザーの 3 つの小さなモデルが使用されます。これらはそれぞれ、パス計画、ツール呼び出し、サマリー応答を担当し、小さなモデルの作業負荷を軽減します。
• 単一モデルのエージェントと比較して、より柔軟なプロンプト設計をサポートします。 ToolBench や ToolAlpaca コーパスなどの複数のベンチマークで単一モデルのエージェント フレームワークを上回り、GPT-4 に匹敵するパフォーマンスを実現します。
• 「グローバル - ローカル」マルチステージ微調整パラダイム(GLPFT)が提案され、オープンソースの小さなモデルでマルチモデル共同フレームワークを正常にトレーニングしました。実験結果から、この 2 段階パラダイムが、現在検討されているマルチモデル共同エージェントのトレーニング パラダイムの中で最善であり、幅広く使用できることが示されました。

マルチモデルコラボレーションフレームワークα-UMiとはどのようなものですか?

現在、OpenAI コードインタープリター、AutoGPT などのプロジェクトなど、API、関数、コードインタープリターを呼び出す大規模モデルに基づくツール学習エージェントが、産業界と学界の両方で広く注目を集めています。

外部ツールのサポートにより、ビッグモデルはWebブラウジング、データ分析、アドレスナビゲーションなどのより複雑なタスクを独立して完了できます。そのため、AIエージェントはビッグモデルの実装の重要な方向性としても歓迎されています。

ただし、上記の主流プロジェクトの一部は、主にクローズドソースの ChatGPT および GPT-4 大規模モデルに基づいており、これらのモデルは推論、ステップ計画、通話要求の生成、要約返信機能においてすでに十分に強力です。

対照的に、モデル容量と事前トレーニング機能の制限により、単一のオープンソースの小さなモデルでは、推論と計画、ツールの呼び出し、応答の生成などのタスクにおいて、大規模なモデルに匹敵するパフォーマンスを同時に達成することはできません。

この問題を解決するために、研究者らはα-UMiを提案した。

α-UMi には、プランナー、呼び出し元、要約者の 3 つの小さなモデルが含まれています。

プランナー モデルはシステムの中核となる頭脳であり、特定のエージェント実行ステップ内で発信者または要約者をアクティブ化し、対応する推論ガイダンスを提供する役割を担います。

呼び出し側と要約側は、プランナーからの指示を受けて、このステップの後続の作業を完了する責任があります。呼び出し側はツールの対話に関する指示を生成する責任があり、要約側は最終的な応答を要約してユーザーにフィードバックする責任があります。

これら 3 つのモデルは、オープンソースの小さなモデルに基づいてさまざまな種類のデータを微調整することによって実装されます。

さらに、研究者らは、グローバル・ローカル多段階微調整パラダイムである GLPFT を提案しました。

オープンソースの小さなモデルに基づくマルチモデルコラボレーションフレームワークを実装するのは簡単ではありません。相反する効果をもたらす 2 つの要因があります。

まず、根拠、アクション、最終回答を生成する 3 つのタスクは、トレーニング中に相互に促進し、同時にエージェント タスクに対するモデルの全体的な理解を強化できます。したがって、現在のほとんどの研究では、単一のモデルをトレーニングして、根拠、アクション、最終的な回答を同時に生成します。

第二に、モデル容量とさまざまなタスクのデータ比率も制限となり、1 つのモデルをトレーニングして同時に 3 つのタスクで最高のパフォーマンスを達成することが困難になります。

下図では、単一のモデルエージェントが各指標のピークに到達するのに必要なデータ量が異なります。すべての指標のピークに到達するデータ量とモデルチェックポイントを見つけるのは困難です。

この問題は、マルチモデルのコラボレーションによって解決できます。

研究者らは、上記の2点を考慮して、「グローバル-ローカル」多段階トレーニング法を提案しました。これは、トレーニングにおいて、論理的思考、行動、最終回答の利点を​​最大限に活用して相互を促進し、より優れた単一モデルの初期化を実現し、その後、マルチモデルの微調整を実行してサブタスクのパフォーマンスの向上に重点を置くことを目的としています。

上の図は、この多段階の微調整のプロセスを示しています。最初の段階では、事前トレーニング済みの LLM を使用してツール呼び出しエージェント タスクを微調整し、単一モデルのエージェント LLM 初期化を取得します。

次に、第 2 段階では、研究者らはツール呼び出しエージェント タスクのトレーニング データを再構築し、根拠の生成、ツール インタラクション アクションの生成、最終応答の生成という 3 つのサブタスクに分割しました。また、第 1 段階でトレーニングされたシングル LLM エージェント ベースを 3 回コピーし、さまざまなサブタスクでさらに微調整しました。

GPT-4に匹敵するパフォーマンス

静的評価

静的評価では、すべてのベースラインの出力をラベル付き出力と比較すると、次のことがわかります。

• α-UMi システムのパフォーマンスは、ChatGPT やツール呼び出しオープンソースモデル ToolLLaMA を大幅に上回り、GPT-4 と同等のパフォーマンスでした。

注目すべきは、ToolLLaMA では満足のいく結果を得るために出力長 8192 が必要であるのに対し、 α-UMi ではマルチモデル フレームワークによってもたらされるより柔軟なプロンプト設計のおかげで、入力長 4096 しか必要としないことです。

• マルチモデル協調フレームワークモデルの微調整方式を比較すると、3 つのモデルを直接微調整したり、単一のモデルをマルチタスクで微調整したりしても、マルチモデル協調フレームワークを効果的にすることはできません。多段階の微調整 GLPFT を使用することによってのみ、最高のパフォーマンスを達成でき、その後のマルチモデル協調トレーニングのアイデアが生まれます。

実際のAPI呼び出しの評価

著者は、ToolBench データセットでの実際の API 呼び出し評価方法も紹介しました。実験結果は次のとおりです。

実際のAPI呼び出し実験の結果、α-UMiはChatGPTとToolLLaMAに勝ち、GPT-4に匹敵する成功率を達成しました。

モデルオーバーヘッド

これを見ると、マルチモデルのコラボレーションによってコストがさらに増加するのではないか、と疑問に思う人もいるかもしれません。著者は、トレーニング、推論、およびストレージの各段階におけるマルチモデルコラボレーションフレームワークのオーバーヘッドの比較も調査しました。

一般に、マルチモデル コラボレーション フレームワークでは、トレーニングとモデル パラメータの保存に高いオーバーヘッドが発生しますが、推論速度は単一モデル フレームワークと同等です。

もちろん、7B ベースを使用したマルチモデル協調エージェント フレームワークのパフォーマンスが 13B 単一モデル エージェントのパフォーマンスをはるかに上回ることを考慮すると、全体的なオーバーヘッドも少なくなります。つまり、小規模なモデルをベースとするマルチモデル協調エージェント フレームワークを選択してオーバーヘッドを削減し、大規模モデルを持つ単一モデル エージェント フレームワークを上回ることができます。

最後に、研究者らは、マルチエージェントコラボレーションがインテリジェントエージェント開発の将来のトレンドであり、オープンソースの小さなモデルのマルチエージェントコラボレーション機能をどのようにトレーニングして改善するかが、実際の実装における重要なリンクであると結論付けました。この記事は、オープンソースの小さなモデルに基づくマルチエージェントコラボレーションの新しいアイデアを切り開き、単一モデルエージェントのベースラインを超え、複数のツール呼び出しベンチマークでGPT-4に匹敵するツール呼び出し結果を達成しました。

今後は、プランナーの汎用化を強化して、より幅広いエージェントタスクのシナリオで使用できるようにし、呼び出し元モデルをローカルでプライベート化してローカルツール呼び出しタスクに集中できるようにするほか、大規模なクラウドモデルと小規模なローカルモデルを組み合わせた「ビッグスモール」モデル連携フレームワークも構築します。