AIマルチエージェントの設計・構築(入門編)

2024年11月25日 20:04

はじめに

日本企業の多くが、これまで生成AIの検証としてRAG（検索拡張生成）を試してきた状況にあると思います。
その次のトレンドとして、AIエージェントやマルチエージェントシステムなどが来ると感じています。それに備えて、多くの企業・組織から色々なフレームワークやサービスが展開されてきています。

しかし、ReActを使うようなAIエージェントや、マルチエージェントの構築に関して業界全体でまだまだ経験が乏しく、ベストプラクティスが固まっていない状況なのではないかと思います。
私自身の経験や論文の内容などを元に、現時点での

マルチエージェントシステムのイメージ
設計・構築のポイント

などをわかりやすくまとめようというのがこの記事の目的となります。

1. マルチエージェントシステムとは

1-1. これまで

これまで検証・構築されてきた多くのLLMアプリケーションは、RAGのようなユースケースで主に生成AIを１タスクに１回だけ使用しているケースが多いかと思います。
（もちろんHydeやAdvanced RAGのようなより複雑なアプリケーションを構築している際にはその限りではありません。）

1-2. 課題

しかしそのような利用方法では、特に複雑なタスクでは下記のようなLLMの制約により活用できない場面が出てきます。

1-3. マルチエージェント構成の採用

そのようなシングルエージェントの課題を解決すべく、

１つの大きく複雑なタスクを複数の小さく単純なタスクに分割
複数回のLLM呼び出し

によって、精度を向上させる構成を取ることが多くなってきています。
このような複数の小タスク・複数のLLM呼び出しを行う構成をマルチエージェントと呼びます。
(明確な定義は現状ないと思うので、少なくともこの記事中はそう呼びます。)

設計は色々あるも、総じて役割・タスクを細かく分ける構成とします。これによって、タスク全体での精度の向上や入出力トークン数の制約を回避します。

1-4. マルチエージェントシステムの実例

最も有名で、設計が公開されている実例はSakana AIさんの"The AI Scientist"だと思います。

これは、LLMを使って研究開発プロセスそのものを自動化しようとする試みです。
「論文を書く」という複雑で高難易度なタスクを、上記のようないくつものタスク・プロセスに分解し個々にLLMに実行させることで実現しています。

参考：AIエージェントとは何か？

そもそもLLMの文脈におけるAIエージェントとは何でしょうか。現状、明確で共通した定義はありませんが、AWSでは以下のように定義をされています。

人工知能 (AI) エージェントは、環境と対話し、データを収集し、そのデータを使用して自己決定タスクを実行して、事前に決められた目標を達成するためのソフトウェアプログラム

AI エージェントとは?

狭義にReAct(*)によって計画策定・ツール利用して与えられたタスクをこなすものをエージェントと呼んだりはしますが、この記事ではLLMを用いて１つのタスク・役割を担うプログラムを広義の意味でのエージェントと呼ぼうと思います。

2. マルチエージェントの設計・検証

2-1. 設計の流れ

経験的に、マルチエージェントシステムにおけるエージェント構成の設計には以下の手順を踏むのがよさそうです。

ただし、デザインパターンの採用のみで解決できそうな場合は、タスク・役割の分割（上記の手順２）はスキップして、よりシンプルな設計を採用べきだと思います。
業務での分割は、業務やそのタスクへのある程度の理解を必要とするため運用のコストが高くなります。

2-2. デザインパターンの採用

LLMによるタスク精度の向上のためによく採用されるエージェントのデザインパターンというものが存在します。
これを取りまとめてくれている論文がありましてそこでは18種類紹介されています。ここでは代表的な３つを紹介します。

Reflection（self-reflection）が最も単純で効果的な手法です。
The AI Scientistでも多用されていますし、私もLangGraphを使った実装方法を以下で紹介しているので試していただけるとイメージがつきやすくなると思います。

Role-based Cooperationは先ほどのタスクの分割にも通じるデザインパターンとなります。

2-3. 設計のポイント

前述のようにマルチエージェントの設計をしていく上で、意識していく必要がある点がいくつかあります。

1 精度と必要リソースはトレードオフ
基本的にマルチエージェントはタスク・役割を細分化すればするほど（つまりコストをかければかけるとほど）精度が向上すると言われています。そのタスクにかけることができるレスポンス時間と利用料は制約としてあらかじめ意識する必要があります。

2 評価対象
LLMを使ったタスクの評価は、機械的な評価ができないケースが多いです。
プロジェクトにおける評価コストが高くなるため、最終出力だけを評価するのか、個別エージェントの出力もきちんと評価するのか評価対象を決めておく必要があります。

3 評価方法
LLMを使ったタスクの評価方法も考えておく必要があります。
そうしたケースで採用される手法は2通り。後者が今後多用されていくと思います。
① 人手による評価
② LLM-as-a-Judge (評価役LLMの検証は必要)

2-4. LLM-as-a-Judgeの必要性と検証

LLM-as-a-Judgeに対する不信感を持っている人は一定数いると思います。ただ、高速なエージェント構築・評価・修正のサイクル（LLMOps）のために今後採用が加速していくはずだと考えられます。
一方で、完全に信じ切るのではなく採点能力の検証は必須です。

あらかじめ、人間による採点と評価役のLLMによる採点の結果が平仄の取れたものであることを確認しておきます。

マルチエージェントの構築は想像よりも検証点が多くなり、機能の評価コストが大変大きくなることが予想されます。
重要な評価ポイントをできるだけクイックに評価を繰り返すことができる仕組み作りが必要となります。

2-5. AgentOps

単一のLLM機能を対象とするLLMOpsを拡張したAgentOpsという概念も生まれてきています。
信頼性の高いエージェントシステムを構築するためには、開発初期段階からのobservability（観測可能性）が重要と定められています。

先ほどの評価の話と近い話ですが、LLMによる判断が多くなるマルチエージェントシステムでは何か変な挙動を起こした時に、どこでどう間違ったか？を素早く確認できるようにしておく必要があるということです。

参考：マルチエージェント構築の自動化

機械的な評価(LLM-as-a-Judge含む)が可能な場合に、マルチエージェントシステムの設計をエージェントシステムに実施させるという手法も研究されてきています。

ADASという手法では、設計→評価→結果の保存を繰り返すことでより高い精度でタスクをこなすマルチエージェントシステムを作っていきます。

試しに "ソフトウェア開発のためのマルチエージェント" を設計させてみると以下のようにな設計となりました。

最終的にはTech Expert、Design Expert、Business Expert、UX Expertという役割を与えられたエージェントが、お互いにReflectionを繰り返し、Voting-based Cooperationで最終的なコードが出力されるという設計です。
詳細は以下の記事をご確認いただければ幸いです。

3. マルチエージェントシステムの構築

私自身未だマルチエージェントシステムの本番構築をやり切った経験がないので、ここは簡単な考えの共有とさせてください。

個人的にはマルチエージェントシステムとKubernetesは相性が良さそうだと考えています。
個別エージェントを１コンテナとして、KubernetesやOpenShift、ECSなどのコンテナ基盤上で動かすという構成です。

特にReActを使い出すと、どのエージェントがどの程度呼び出されるか予測しづらい状態となるので、自分でLLM推論サーバーをホストする場合自動でスケーリングや死活管理ができると嬉しいです。
また、エージェントの設計をyamlなどで管理できる点も魅力的だと思います。

実際、NvidiaやRedHatなどの企業はそのような将来を見据えて動いているように見えます。
NvidiaはNIMというサービスで、高速にLLMを動かせる推論サーバーのコンテナイメージを提供しています。また、それらを組み合わせて作ったマルチエージェントシステムをHelmチャート化し、 AWS, Azureなどの主要クラウドのKubernetesにデプロイできるNIM Agent Blueprintを発表しています。

4. 主要なサービス・フレームワーク

4-1. 主要なクラウドサービス

2024/11/20時点で簡単に調べた限りでは、AWS, Azure, GCPはそれぞれ以下のようなエージェント系のサービスを展開しています。

詳しく触ってはいませんが、Azure AI Agent Serviceはマルチエージェントではなくシングルエージェント用のサービスに見えました。マルチエージェント構成は別途Microsoftが展開しているAutoGenなどのOSSフレームワークに任せる方針のようです。
（違ったらどなたかご指摘ください。）

4-2. 主要なフレームワーク

どちらかというと上記のクラウドベンダーによるサービスよりも、OSSのコミュニティの方が育っている感じがします。

2024/11/18時点では、Githubのstarで比較するとDify（⭐️51.9k）が最も多かったです。
AutoGenはMicrosoft、SwarmはOpenAIが開発しています。
また、Dify, CrewAI, LangGraphはそれぞれ開発元がホストしたSaaSも提供しています。

5. まとめ

長くなったのでまとめます。

状況：

日本企業ではRAGやChatBotをメインとしてシングルエージェントでの検証が進んできた。
今後は、難易度が高いタスクをLLMに任せる場合、今後はマルチエージェントの採用が必要となる場面も増えてくる。

マルチエージェントの設計：

マルチエージェントの設計は、業務理解が重要。
精度をサポートするために、ある程度デザインパターンも頭に入れておくと良い。

マルチエージェントの構築：

マルチエージェントシステムの構築では、検証コストが高くなっていくことが想定される。
LLM-as-a-Judgeを中心としたLLMOpsが採用されていくはず。

以上となります。日本におけるマルチエージェントシステムの設計や検証、構築の流れの一助になれば嬉しいです。何か議論や感想があればNoteやX(Twitter)でコメント・ご教示いただけると助かります。

X: https://twitter.com/CurveWeb

目を通していただきありがとうございました。