AutoGen: 金融AIのためのマルチエージェント対話フレームワーク

Gorillaが、単一のLLMで数千のAPIを正確に呼び出せることを示した後、自然な疑問が浮かびます。複数のLLMに異なる役割を与え、互いに対話させたらどうなるでしょうか？AutoGen (Wu et al., 2023) は、マルチエージェント対話のフレームワークを構築することでその疑問に答えています。今これを読むのは非常にタイムリーです。私が目にしている本番環境の金融AIシステムの多くは、デフォルトで少なくとも3つのエージェントを含むように設計されているからです。

論文の概要

AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (Wu, Bansal, Zhang et al., Microsoft Research, 2023) は、「対話型エージェント（conversable agents）」が互いにメッセージを送信してタスクを完了するフレームワークを提案しています。各エージェントは、LLM、ツール、および人間の入力の組み合わせによって支えられています。このフレームワークには、2つの組み込みエージェントタイプ、AssistantAgent（LLM駆動）と UserProxyAgent（コードの実行と人間の入力の転送が可能）、さらに大規模なアンサンブルでのターンを制御する GroupChatManager が導入されています。

核となる考え方は、著者が「対話プログラミング（conversation programming）」と呼ぶものです。コードでオーケストレーションロジックを手書きする代わりに、自然言語のシステムプロンプトを通じて各エージェントが何をすべきかを指定し、メッセージパッシングに制御フローを任せます。論文では、数学の問題解決、検索拡張生成（RAG）によるQA、ALFWorldの意思決定、およびOptiGuideと呼ばれるオペレーションズ・リサーチへの応用を通じて、このフレームワークを実証しています。

主要なアイデア

• MATHベンチマークでの精度向上: 2つのエージェントによるAutoGen設定（LLMアシスタントとコード実行プロキシ）は、MATHテストセットで69.48%に達しました。これはGPT-4単体での55.18%と比較して、コード実行フィードバックを追加しただけで14ポイントの向上を示しています。
• ヒューマンインザループ（Human-in-the-loop）が第一級市民: UserProxyAgent には、ALWAYS（常に）、NEVER（なし）、TERMINATE（終了時のみ）という設定可能な human_input_mode があります。これにより、エージェントのロジックを変更することなく、監視の強度を調整できます。
• 動的なグループチャット: GroupChatManager は、固定されたラウンドロビン方式ではなく、対話の状態に基づいて次の発言者を選択します。これにより、進行中の結果に応じてワークフローを分岐させることができます。
• OptiGuideによる安全性の向上: サプライチェーン最適化ワークフローに SafeGuard エージェントを追加したところ、安全でないコードの検出 F1スコアが GPT-4 で 8ポイント、GPT-3.5 で 35ポイント改善され、同時にユーザーのコードベースを430行から100行に削減できました。
• インタラクティブな検索: QAタスクにおいて、アシスタントエージェントは UPDATE CONTEXT シグナルを発することで追加のコンテキストを要求できました。これは Natural Questions の質問の約19.4%で発生し、全体の F1スコアは 23.40% でした。
• 設計による構成可能性: AutoGenエージェントはそれ自体が他のエージェントが呼び出せる有効な「ツール」であるため、特別な接着剤（glue code）なしで階層的なパイプラインを構成できます。

評価できる点と不十分な点

MATHやALFWorldの結果は堅実です。実際のベンチマークを使用し、名前の挙がっているベースラインと比較した、制御され再現可能な比較が行われています。69.48%という数字は、構造化された対話ループ内でのコード実行フィードバックの利点を分離して示しているため、意味があります。

弱い点は、コストとレイテンシの分析、というかその欠如です。GroupChatのすべてのターンで、蓄積された対話履歴を含む完全なLLM呼び出しが発生します。4つのエージェントが10ラウンド対話するワークフローでは、コンテキストウィンドウが大きくなる中で最低40回のLLM呼び出しが行われます。論文では、どのアプリケーションについてもトークンコストやレイテンシを報告していません。数千のトランザクションを処理するライブの会計パイプラインでは、この省略は理論上の問題ではなく、その手法が実現可能かどうかを決定する要因となります。

また、対話プログラミングのメタファーは、デモで見えるよりも脆弱です。GroupChatManagerは、LLMにエージェントのリストから選択させることで次の発言者を選びます。その選択自体が確率的なテキスト生成ステップであるため、例外が発生しない微妙な形で制御フローが狂う可能性があります。操作の順序が重要であり、ツールの呼び出しを間違えれば仕訳項目が破損する可能性がある元帳書き戻しエージェントにとって、非決定的な発言者選択は真のリスクとなります。

最後に、評価タスクはすべて単一セッションかつ短期間のものです。エージェントが数日間にわたって状態を蓄積したり、矛盾する指示を処理したり、古いエージェントのメモリと新しい元帳エントリの間の競合を解決したりする必要がある実験はありません。これらはまさに、実際の会計ワークフローで発生するシナリオです。

なぜこれが金融AIにとって重要なのか

金融AIにおけるマルチエージェントシステムの利点は明確です。照合、転記、レポート作成は、本質的に分離された関心事です。Beancountのパイプラインは、元帳を読み取り専用でクエリする LedgerReaderAgent、トランザクションを銀行明細と比較する ReconcilerAgent、新しいエントリを提案する WriterAgent、そして書き込みが行われる前に勘定科目表のルールに照らしてチェックする ReviewerAgent を持つことができます。AutoGenの UserProxyAgent パターンは WriterAgent にとって適切な抽象化です。これは実際の元帳書き込みを実行し、その結果を ReviewerAgent が検査するメッセージとして返すことができます。

OptiGuide SafeGuard の結果は、最も直接的に転用可能な知見です。安全でないアクションをキャッチするための専用の検証エージェントを追加することで、検出能力が大幅に向上しました。しかも、その検出は事後監査としてではなく、対話ループの中で行われました。これは、Beancountの書き戻しの安全性に私が求めているアーキテクチャそのものです。事後にアラートを出すのではなく、コミットをブロックする検証者です。

非決定的な発言者選択の問題は解決可能です。GroupChatManagerをオーバーライドして、メッセージの内容に基づいてルーティングする決定論的なPython関数を使用できます。しかし、そうする必要があることを知っておかなければならず、論文ではそれが懸念事項として前面に出されていません。

次に読むべきもの

• AgentBench: Evaluating LLMs as Agents (Liu et al., arXiv:2308.03688, ICLR 2024) — Webブラウジング、コーディング、データベース操作など、8つの異なるエージェント環境でLLMをベンチマークしています。商用モデルとオープンソースモデルの間のギャップが主要な発見であり、金融エージェントパイプラインに使用するベースモデルの選択に直接影響を与えます。
• TradingAgents: Multi-Agents LLM Financial Trading Framework (arXiv:2412.20138) — 金融市場向けにAutoGenパターンを直接具体化したもので、専門のアナリスト、リサーチャー、トレーダー、リスクマネージャーエージェントを備えています。シャープレシオと最大ドローダウンの結果は、マルチエージェント金融システムの最初の現実的なパフォーマンス数値を提供しています。
• AGENTLESS: Demystifying LLM-based Software Engineering Agents (Xia et al., arXiv:2407.01514) — 単純で「エージェントレス」な2フェーズのアプローチ（特定して修正する）が、SWE-benchにおいて複雑なマルチエージェントフレームワークを上回ると主張しています。エージェントを増やせば常に良くなるという仮定に対する有用な対抗軸となります。