エージェント数を増やすだけでもLLMの性能はスケールする
(arxiv.org)- LLMは複雑なタスクで精度が不安定になりやすいが、本研究は追加構造ではなくサンプリング＋投票だけで性能を引き上げられるかを検証した
- Agent Forestは、同じクエリを複数回実行して回答を集めた後、多数決で最終回答を選ぶシンプルなアンサンブル手法
- GSM8Kでは、アンサンブルサイズ15でLlama2-13BがLlama2-70Bに近い精度に到達し、Llama2-70BとGPT-3.5-Turboもより強力な対応モデルに近づいた
- この手法はCoTベースの方法やマルチエージェント協調フレームワークと独立して組み合わせることができ、既存手法の上にさらなる性能向上をもたらせる
- 改善幅は特に難しいタスクや弱いモデルで大きく、複雑なプロンプト設計なしでも費用対効果を高められる余地がある
複雑なタスクで不安定になるLLMの精度
- LLMは言語生成、理解、推論などさまざまな応用で強力な能力を示す一方、複雑なタスクでは正確な答えを出すのが難しい
- 既存の性能改善研究では、主にアンサンブル手法と複数のLLMエージェントによる協調フレームワークが活用されてきた
- LLM-Debateは、複数のLLMエージェントが算術タスクの最終回答を議論するよう構成し、単一エージェントより推論性能を高める
- CoT-SCは、複数の思考チェーン（thought chain）を生成し、最も自己一貫性のある答えを選ぶ方式で、単一の思考チェーンを使うCoTより推論性能を改善する
- 先行結果でも、エージェント数や思考チェーン数が増えると性能が上がる現象は観察されていたが、基本的なLLMエージェント数そのもののスケーリング特性は、独立した研究対象として十分には扱われていなかった
Agent Forestの動作方式
- Agent Forestは、LLMエージェント数の増加が性能に与える影響を見るため、シンプルなサンプリング＋投票手順を用いる
- 動作は2段階に分かれる
- タスクのクエリを単一のLLM、または複数LLMエージェントの協調フレームワークに繰り返し入力し、複数の出力を生成する
- 生成された出力に多数決投票を適用し、最終結果を決定する
- 手順はCoT-SCに着想を得ているが、複雑なCoT経路設計には依存しない
- 名前は古典的なRandom Forestへのオマージュ
GSM8Kと複数タスクでの結果
- 実験は、サイズの異なるさまざまなLLMと、推論・生成タスクを含む複数のデータセットで実施された
- 全体として、アンサンブルサイズ、つまりエージェント数が大きくなるほどLLMの性能が向上し得る
- Figure 1のGSM8K結果では、Llama2-13B、Llama2-70B、GPT-3.5-Turboのいずれも、アンサンブルサイズが大きくなるほど精度が向上した
- アンサンブルサイズ15でLlama2-13BはLlama2-70Bと比較可能な精度に到達した
- アンサンブルサイズ15と20で、Llama2-70BとGPT-3.5-Turboは、それぞれより強力な対応モデルと比較可能な精度を示した
- 図のエラーバーは標準誤差を表す
- 小さなLLMでも、シンプルなアンサンブルを適用すれば、より大きなLLMと比較可能、またはそれ以上の性能を出せる
既存手法の上に載せられる性能改善
- Agent Forestは、既存の複雑なLLM性能改善手法と独立して組み合わせられるアプローチ
- CoTベースの方法にはプラグインのように追加でき、さらなる性能向上をもたらせる
- 複雑な方法と比較しても、Agent Forestだけで多くの場合、比較可能な性能を達成できる
- 追加の手作業によるプロンプト設計や複雑な協調フレームワークなしでも、競争力のある結果を得られる
難易度による効果と最適化
- 性能向上は難しいタスクや弱いモデルでより大きく現れる
- 問題の難易度がAgent Forestの効果に与える影響は、3つの次元に分けて分析された
- 問題の内在的難易度
- 推論ステップの長さ
- 正解の事前確率
- 各次元を調整した実験を通じて、Agent Forestの効果に影響する属性を確認した
- 確認された属性に基づき、「More Agents」の効果がよりよく現れるようにする最適化戦略も追加で開発した
- 公開コードは
https://github.com/MoreAgentsIsAllYouNeed/AgentForestで提供されている
1件のコメント
Hacker Newsのコメント
この論文をきちんと読んでいない人がいるように思う
この論文は、Chain-of-thought や LLM-Debate のようなマルチエージェント構成という発想を、ほぼ反証しているように見える
論文が提案している代替案は、同じ LLM に同じクエリを何度も投げるが、クエリ同士でコンテキストは共有せず、回答間の類似度を計算して最も多い答えを選ぶ、という方式
LLM が幻覚と正答を混ぜて出すなら、正答同士は互いに似ていて、幻覚は混乱してばらけるはずなので筋は通る
ところが、この単純なアルゴリズムが他のマルチエージェント・アルゴリズムと同じくらい、時にはそれ以上にうまく機能する
つまり、巧妙なプロンプトを使う他のマルチエージェント手法が特別なことをしているのではなく、改善の大半は LLM を複数回実行し、「最良の答えを選べ」とさせるところから来ているように見える
昔から天気シミュレーションでは、入力パラメータを少しずつ変えてモデルを繰り返し実行し、外れ値を捨てて平均を取ってきたが、かなりうまく機能している
LLM もおおむねランダムシード、つまり温度値を持っているので、同じ入力を入れて出力を平均すれば、より良い推定値を得られる
Lorenz system は、幻覚問題がおそらく解決不可能である理由についても手がかり、もしかすると説明を与えてくれる
この見方を受け入れると、LLM が汎用人工知能へ向かう道としてはほぼ行き止まりだという点もすぐに明らかになる
シミュレーションはエミュレーションではなく、LLM が知能を持つようになる可能性は、天気予報が天気を制御するようになる可能性と同じくらいだ
たいてい、特定のライブラリが非常に異常で文書化されていない形で動作しているのに、例を尋ねると、そのライブラリがそんなふうに動作していたならそもそも必要なかったはずの、見栄えがよく理解しやすい偽の関数コードが出てくる
その種のクエリを何度実行しても役に立つとは思えない
複数の予測器の結果を平均したり投票させたりして最も多い予測値を選べば、複数の予測の共通分母を取りつつ、予測のノイズを減らせる
だが、それが正解を保証しないことはすでに分かっているのに、だとすれば何度も実行することがどうしてより良くなり得るのか？
それ自体は良いが、都市伝説や文化的な伝説も上位に来そうだ
とても人間的なミスではあるが、それでもミスだ
これを超えるには、世界モデルを作り、矛盾を見つけ、その矛盾を解消する新しい証拠を探す必要があると思う
ついに出た
単一エージェントにすべてを正解させることに集中するのではなく、エージェントを階層化すべきだと 16か月ほど言ってきたので、これで参照できる論文ができてうれしい
タスクごとの収穫逓減が、理想的な人間の会議規模に近い人数で急速に頭打ちになる点も興味深い: https://www.researchgate.net/figure/18-Optimal-Meeting-Sizes...
エージェント数をもっと細かい段階で実験していたら、あの数字とどれくらい近く一致するのか気になる
将来的に各エージェントを少しずつ異なる目標に合わせてファインチューニングしたとき、性能がどれほどさらに上がるのかも見てみたい
各エージェントの温度値を変えるだけでも性能向上がありそうだ
研究コミュニティがこの方向に動き始めていて、とても喜ばしい
LLMWare の SLIM agents も見る価値がある: https://github.com/llmware-ai/llmware/tree/main/examples/SLI...
ほぼまさにこのテーマに集中しながら、複数のローカル LLM をつないでいる
これに隣接する良いテーマとして、モデルの用途に応じて 決定論的サンプリング が必要だという点もある
用語が少し違っているかもしれないが、LLMWare チームがこれに関連して良い 2 部構成の動画を作っている: https://www.youtube.com/watch?v=7oMTGhSKuNY
専用の小型 LLM が今後の道だと思う
ちなみに彼らとは何の関係もなく、単に本当にすばらしいプロジェクトだと思っているだけ
頭蓋骨の中に自分自身のバージョンが 5 個か 8 個くらい走り回っていて、そのうち 1 つがある程度監督者の役割をしている、という感じ
crewAI がその一例
最近の ACM ByteCast の Edward Chang 回と関連しているように見える
Stanford University のコンピューターサイエンス学科の非常勤教授である Edward Chang が出演した回: https://learning.acm.org/bytecast/ep50-edward-y-chang
聴きたくなければ文字起こしもある
彼が使っているアプローチは、最近の LLM の一般的な質問/回答形式ではなく、複数の LLM に討論テーマについて互いに会話させ、人間は司会者の役割を担うというもの
同じリソースで、複数の LLM が会話を通じて到達した最終回答は、精密度と正確度の両方で大きく向上するという
単に LLM たちに問題を独立に解かせたうえで、最も人気のある答えを選べばよい
ベンチマークはしていないが、かなり説得力があるように感じた
たとえば各エージェントを、数学のサブ分野ごとに異なる「専門家」として定義した: 証明論者、抽象代数の専門家など
役には立ったが、信号対雑音比は高く、多くのエージェントが同じ論点を繰り返していた
この手の専門家混合研究全般で、もどかしく感じていた点がある
乱択アルゴリズム入門や基本的な確率的推論を見れば、温度パラメータが 0 より大きい場合、LLM に N 回問い合わせて多数決の結果を選ぶ方式は、1 回だけ尋ねてその結果を選ぶより、たいてい良い性能を出すはず
異なる LLM を特化させて混ぜれば追加の改善が可能そうで、その場合は温度 0 で回せるかもしれない
あるいは、この論文が提案しているように、タスクをサブタスクへよりうまく分割する方法もあり得る
しかし自分には、こうした仮説上の利得を単純なランダム反復方式と比較して、実際に定量化した人がいないように見える
特に、ある投票戦略や混合方式、さらには特定のモデルでは、MoE のような方式が素朴な反復より厳密に悪くなることすらあり得る
LLM 研究者ではなく、どちらかというと心配している市民なので、何か見落としているのかもしれない
それでも、LLM 研究者たちが Motwani/Raghavan の最初の章を忘れてしまったように見えて奇妙だ
グラフをざっと見ると、利得の大半は10 エージェントで出ていて、20 で少し伸びた後は収穫逓減がある
エージェントをさらに大量に付けるだけでは解決しなさそう
公開リポジトリがある: https://anonymous.4open.science/r/more_agent_is_all_you_need...
ベンチマークに使ったプロンプトはここにある: https://anonymous.4open.science/r/more_agent_is_all_you_need...
とても興味深い
こういう方式だが、ツールセットを使う LLM ベースのエージェントをベンチマークするものも見てみたい
これはものすごく高価で持続不可能な方法ではないのか？
最新モデルではおそらく収穫逓減が生じるだろうから、MoE が進むべき道だという雰囲気には同意する
しかし単一プロンプトの計算量が突然7〜15倍に増えるのでは？
現在の上位コメントをいくつか読むだけでも、LLM サービスを提供する会社のビジネスモデルは奇妙に感じる
A から B へ連れていくには n 回呼び出す必要がある配車サービス、服が「たぶん」きれいになるまで洗剤を n 回塗らなければならない洗剤のようなもの
会社が対価を受け取って「人工知能」を提供するなら、正解に対してだけ料金を払うのが合理的ではないか？
配車サービスを提供するなら、目的地まで連れていったときだけ支払うべきではないか？
十分な頻度で失敗するなら、人間や汎用的な従来型自動化のほうが良くなる基準点はかなり低くなるのではないか？
このバブルはこういう形ではじける気がする
LLM が画期的なツールであることは疑っていないが、非常に細分化された用途を除いては本気で懐疑的だ
もしかすると教訓は、LLM エージェントの責任を分散するやり方が、既存の人間組織の失敗モデルと同じだということかもしれない
合意したものを提供できなければ、顧客は是正を求めることができる
タクシー運転手が不必要に複雑な経路を通ったり、過剰に料金を請求したり、目的地に連れていかなかったりすれば、タクシー会社に苦情を言える
洗濯がきちんとできていなければ、やり直しを求める
しかし多くの活動は本質的にリスクがあるか、結果が不確実である
誰にも制御できない要素が常にあるからだ
弁護士は訴訟に勝つと約束することはできないが、最善を尽くして事件を代理しなければならない
医師は再び健康になると保証しない
どんなタクシー運転手も、時間通りに目的地に到着すると保証はしないが、目的地までは連れていく
Atlassian は管理型 JIRA インスタンスを使えばリリース締切を守れるとは保証しないが、データ損失を防ぐために最善を尽くす
基本的にチャットボットへのアクセス権を売る会社も、正しい結果を返すとは保証しないだろう
おそらく可用性の保証程度は可能だ
GPT-3.5 エージェントをいくらアンサンブルしても、GPT-4 の 1 回の呼び出しより正確度は低い
うまく構成しさえすればよい