「Agentic Design Patterns」と呼ばれるLLMベースのAIエージェント（以下、LLMエージェント）の4つのデザインパターンについて紹介します。
まず、「Agenticワークフロー」について説明し、続いて4つのデザインパターンを説明します
(Part5の前に公開してしまったので、後追いで更新予定です)
Agentic Design Patterns Part 1
Agentic Design Patterns Part 2, Reflection
Agentic Design Patterns Part 3, Tool Use
Agentic Design Patterns Part 4, Planning
Agentic Design Patterns Part 5, Multi-Agent Collaboration
動画もあります。
LLMエージェントについての説明は省略しているため、エージェントについて初見の方は以下記事をお勧めさせて頂きます。
ポイント
- 一度で出力の生成を完結させるのではなく、LLMが反復的にタスクをこなし、出力を改善させるAgenticワークフローの有用性
- LLMエージェントの4つのデザインパターン
- Reflection: LLMの自己改善プロセス
- Tool Use: LLMの能力拡張のためのツール活用
- Planning: 目標達成のための多段階計画の立案・実行
- Multi-agent collaboration: 複数のAIエージェントの協調によるタスク解決
- これらのパターンを採用・組み合わせることで、LLMエージェントの能力を拡張できる
Agenticワークフロー
LLMが反復的にタスクをこなす、出力を改善していくイテレーティブなフローをAgenticワークフローと呼んでいます。
対称的に、プロンプトを与えて一度で出力を生成することをゼロショットモード、Non Agentic Workflowと呼んでいます。
(Zero-shot Learning, Few-shot Learninと混同しそうですが、異なるワードです)
引用: What's next for AI agentic workflows ft. Andrew Ng of AI Fund
雑な理解ですが、プロンプトを一回実行するだけで得られる出力より、後から「〇〇を修正して」というフィードバックを与えたり、タスクを分解して順次実行する方が、求めた出力に近づく可能性は高くなる。
それを自動化して自律的に行えるようにしよう！がAgenticワークフロー(== LLMエージェント、実質)だと捉えています。
そんなAgenticワークフローですが、ゼロショットモードと比べて、LLMがより高度なタスクをこなすことが可能だと主張しています。
実際にAgenticワークフローによる効果として紹介されているのが、OpenAIが提供するプログラム合成の能力を評価するためのベンチマークであるHumanEvalのコーディングベンチマークでの検証です。
コーディングベンチマークにおいて、GPT-3.5のゼロショットが48.1%、GPT-4のゼロショットが67.0%の正解率だったのに対し、GPT-3.5にAgentループを組み込むと最大95.1%まで正解率が向上したという結果が示されています。
引用: What's next for AI agentic workflows ft. Andrew Ng of AI Fund
4つのデザインパターン
Agenticワークフローのインパクトを主張した上で、LLMエージェント開発の参考になる4つのデザインパターン（Reflection、Tool Use、Planning、Multi-agent collaboration）が提案されています。
-
Reflection
- LLMが自身の出力を検査し、改善点を見つける
- 実装が比較的容易でありながら、性能向上が期待できる
-
Tool use
- Web検索やコード実行など、情報収集やデータ処理に役立つツールをLLMに提供
- 外部ツールとのインタラクションにより、LLMの能力の幅・深さ共に拡張
-
Planning
- 目標達成のための多段階の計画を立て、実行する能力をLLMに付与
-
Multi-agent collaboration
- 複数のLLMエージェントが協力してタスクを分担、アイデアを検討することで、単一エージェントよりも優れた解決策を導き出す
デザインパターンの中でも、ReflectionとTool Useは比較的信頼性の高いデザインパターンとされ、PlanningとMulti-agent collaborationはエージェントの能力を大きく拡張する可能性を持つものの、まだ発展途上の段階にあると考えられています。
Reflection: LLMの自己改善プロセス
Reflectionは、LLMが自身の出力を批評的に検証・評価し、改善点を見出すプロセスで、比較的シンプルなパターンでありながら、出力を大幅に改善できる可能性があります。
ChatGPTから理想とは異なる出力を受け取り、出力を改善するために批判的なフィードバックを送ったことは一度はあるのではないでしょうか。
このようなフィードバック、出力の改善のステップを自動化・自律的に行えるようにしよう！が、Reflectionのアイディアです。
具体例としては、コード生成タスクにおいて、まずLLMにコードを生成させた後、LLM自身にそのコードを批評させ、フィードバックを行わせます。さらにそのフィードバックを元に、LLMがコードを書き直す。このプロセスを反復的に行ないます。
Example
-
Self-Refine
- 単一のLLMが自身の出力に対するフィードバック(feedback)を生成し、そのフィードバックに基づいて出力を改善(refine)していく反復的なプロセスを提案
- 対話応答、コード最適化、数学的推論などの7つのタスクで有効性を実証
-
Reflexion
- メモリーと自己反省機能を元に、次の試行でフィードバックを元に出力を改善する
- エージェントが言語的フィードバックを生成し、それを長期記憶に保存することで、より適切な出力をできるように
-
CRITIC
- LLMが外部ツールと対話して出力を批評、修正のサイクルを反復させる手法を提案
- LLMだけでは出力を検証する能力が不十分であり、有害性の検出や数学的推論の正しさの判断が難しいことを指摘
- 出力検証の外部ツールには検索エンジン、コード実行環境などを活用
Tool Use: LLMの能力拡張のためのツール活用
Tool Useは、情報収集、アクション実行、データ操作などのために、LLMに外部ツールを呼び出す機能を与えることで、LLMのケイパビリティを拡張し、タスクを解くために適切なツールを選択可能にするデザインパターンです。
最もわかりやすい例は、Web検索ツールの活用です。「最高のコーヒーメーカーは何ですか？」というプロンプトに対し、LLMがWeb検索ツール・関数を呼び出すことで、Web検索を実行し、回答に必要なコンテキストを獲得します。
引用: What's next for AI agentic workflows ft. Andrew Ng of AI Fund
Example
-
Toolformer
- LLMにどのAPIを呼び出すべきか、いつ呼び出すべきか、どのような引数を渡すべきかを自己学習させる方法
- ツールの呼び出し例のfew shotを示すだけで、LLMがAPIコールを生成し、有用なコールを選別できる
-
Gorilla
- LLMがAPIを適切に選択・コールするためのフレームワークを提案
- ユーザーリクエストに応じて適切なAPI選択、APIコールのためのコードを生成
- API呼び出しに特化し、精度、ハルシネーションの面でGPT-4上回る性能を実現
- 検索システムと組み合わせることで、APIドキュメントの更新に対応可能
ツールを与えることで能力の拡張を図るアプローチは多く採用されていて、聞き覚えのある方もいるのではないでしょうか。
自身の記事で手前味噌ですが、以下のようなWebスクレイピング、Web検索のツールを与えるというTool Useパターンは初歩的ではありますが、よく見かける例です。
またReflectionのセクションで紹介したCRITICは、Reflectionを行う際にTool Useパターンも採用しており、他パターンとの組み合わせも効果的だと考えられます。
LLMがツールを計画、検索、呼び出す能力を評価するためのベンチマークであるAPI-Bank論文では、LLMの外部ツール活用でまだ課題もあることを指摘していますが、
Tool UseはLLMエージェントの能力を拡張させるデザインパターンであり、タスクを実行するために適切なツールを自律的に選択するLLMエージェントの実現は非常に夢のある領域です。
Planning: 目標達成のための多段階計画の立案・実行
Planningは、与えられたタスクをこなすための計画やサブタスクへの分割など、実行すべき一連のステップを自律的に決定することで、複雑なタスクを効率的に処理できるようにします。
こなすべきタスクやその順序が確定している場合は、Planningの必要性は高くないです。
一方で、計画やステップが確定しないタスクの場合は、前もって分解することができないので、Planningによってエージェントは動的に取るべきステップを決めることができるようになります。
ReflectionとTool useのデザインパターンは確実に動作すると述べている一方で、Planningは事前に予測するのは難しく、まだ成熟していない技術であるとも記事では主張しています。
Example
-
Plan-and-Solve Prompting
- 複雑なタスクを解決する際に、タスクを分割し、段階的に解決することでLLMエージェントの性能を向上させるアプローチ
- PlanとSolveの2段階で構成されるプロンプティング手法を提案
- Plan: 全体のタスクをさらに小さなサブタスクに分割する計画を立てる
- Solve: 計画に沿ってサブタスクを実行し、最終的な解を導く
-
HuggingGPT
- LLMと複数の専門モデルを組み合わせて複雑なタスクを解く
- ユーザーリクエストを解析し、タスク計画を実施。一連のサブタスクに分割
- タスクの依存関係や実行順序を特定する
- モデル説明を参照し、各サブタスクに最適なモデルを選択
- タスク計画とモデル選択を通して、複数の専門モデルを適切に組み合わせ、複雑なタスクを自動的に遂行できる
- 複雑なタスクにおいてプランニングが効果的であることを示唆
BabyAGIのTask Creation AgentやTask Prioritization Agentによるタスク計画を立案するプロセスも、Planningに関連します。
(複数のエージェントが協調する点で、マルチエージェントパターンにも)
ユーザから与えられたゴールに対して、BabyAGIは以下のステップを踏んで4つのエージェントを使いながらタスクを処理していきます。
- Task Creation Agentがゴールからタスクを生成する
- Task Prioritization Agentがタスクリストに優先順位をつける
- タスクリストの中から最初のタスクを取得し、Execution Agentに渡してタスク実行する
- 実行結果と元々のゴールをTask Creation Agentに与えて新たなタスクを生成する
- 以降、全タスク終了するまでステップ3～5をループする
引用: 自律型AIエージェントのご紹介
Task Creation Agentがユーザーからのゴールをもとにタスクを生成し、Task Prioritization Agentがそれらのタスクに優先順位を付けます。
これらのエージェントによるPlanning機能により、BabyAGIは与えられたゴールを効率的かつ効果的に達成するための計画を自動的に立案し、実行することができます。
Multi-agent collaboration: 複数のAIエージェントの協調によるタスク解決
Multi-agent collaborationは、複数のLLMエージェントが共に動くことで、単一エージェントより複雑なタスクの遂行能力を高めるデザインパターンです。
Role Promptingのように、複数のエージェントがそれぞれの専門性を活かしてタスクを分担することで、単一のエージェントでは得られない多様な視点と問題解決能力が期待できます。
Example
-
ChatDev
- ソフトウェア開発の工程をCEO、CTO、プログラマー、テスターなど、異なる役割を持つエージェントが介在
- 各フェーズ(設計、コーディング、テスト、ドキュメント作成など)のタスクを細かいサブタスクに分解し、対話を重ねながらタスクをこなすchat chainという仕組みを提案
- 複数のエージェントが、各サブタスクを分担してチャットベースの対話を重ねながらタスクを分担
-
AutoGen
- MicroSoftが開発したマルチエージェントを実装するためのフレームワーク
-
MetaGPT
- 専門的な役割を持つエージェントで構成。各エージェントは役割に応じたタスクを実行
- 標準作業手順書(Standardized Operating Procedures, SOPs)を用いてエージェント間で協調
- 役割に応じたスキーマとフォーマットを確立し、各エージェントがそれぞれの役割とコンテキストに基づいて必要なアウトプットを生成
- Publish-Subscribeメカニズム
- 役割に基づいて関連メッセージをサブスクライブ
- コード生成後、エラー発生時は過去のメッセージとPRD、設計、コードを比較するフィードバックメカニズム
前述のAPI-Bankでも、LLMによる大規模データ生成の手法として、5つのエキスパートエージェントが協調して段階的にデータを生成するMulti-agentな仕組みが提案されています。
- ドメインエージェント: 様々なドメインを生成
- APIエージェント: そのドメインに基づきAPIを生成(実在するAPIの例を参照)
- クエリエージェント: 生成されたAPIとデータ設計原則に基づき、適切なクエリを作成
- 実行エージェント: クエリに対応するAPI呼び出しと応答を生成
- テストエージェント: 生成されたデータが設計原則を満たすかをチェック
引用: https://arxiv.org/pdf/2304.08244.pdf
タスクを分割し、かつエキスパートエージェントが段階的に生成することで、複雑な要件を満たすデータを効率的に作れるようになり、人手による作成コストに比べて98%安価、データの品質も人手によるものと同等で、従来手法に比べ89%の品質向上が見られたとのことです。
LLMマルチエージェントに関しては、LLMマルチエージェントを俯瞰するも参照ください。
デザインパターンの組み合わせ
Agentic Design Patternsの1つ1つは、LLMエージェントの機能拡張や性能向上に寄与するものの、複数のパターンを組み合わせる方が大きな効果が期待できます。
CRITICの事例
CRITICは、ReflectionとTool Useの2つのパターンを組み合わせた例です。
LLMが自身の出力を検証・批評するReflectionに加えて、検索エンジンやコード実行環境などの外部ツールを活用して、さらに出力の品質向上を図っています。
ReflectionとTool Useの2つのパターンに加えて、例えば、出力生成エージェントと建設的な批評を与えるエージェントの2種類を用意し、両者が対話を重ね、批評に基づいて出力を改善していく Multi-agent collaborationを組み合わせることも考えられます。
ChatDevの事例
ChatDevでは、Multi-agent CollaborationとPlanningだけでなく、Reflection、Tool Useの要素も確認でき、4つのデザインパターンが組み合わさったLLMエージェントシステムになっていると考えられます。
Multi-agent CollaborationとPlanningに関しては、既にCEO、CTO、プログラマー、テスターなど、異なる役割を持つエージェントが各開発フェーズのタスクを分担しながらこなすこと、chat chainで各フェーズの作業を細かなサブタスクに分解し、計画的に実行している点に触れました
Reflection
ChatDevでは、ソフトウェア開発の各フェーズを担当する複数のLLMエージェントが協調しながら作業を分担します。
時折、両者がコンセンサスに達したにもかかわらず、あらかじめ定義されたコミュニケーション・プロトコルを終了条件として発動しない対話が観察される。... このような場合、我々は自己反省のメカニズムを導入する。このメカニズムを実現するために、新たな質問者として「擬似自分」を登録し、新たなチャットを開始する。擬似質問者は、図3(c)に示すように、現在のアシスタントに過去の対話の履歴をすべて通知し、対話から得られた決定的な情報の要約を要求する。このメカニズムは、対話中に提案され議論された決定について、アシスタントに反省を促す。
引用: Communicative Agents for Software Development - Self-Reflection - ページ5
エージェント同士の対話の中で、終了条件が満たされずに停滞した場合に、"pseudo self"と呼ばれる新しいエージェントを投入し、これまでの対話履歴を伝えることで、Self Reflectionを促すメカニズムも導入されていることがわかります。[1]
レビュアーとプログラマーの対話分析 このセクションでは、レビュアーとプログラマー間の主なやりとり、特にコーディング段階におけるコード関連の事柄について掘り下げていく。
コードレビュー中のレビュアーとプログラマーのコミュニケーションで最も頻繁に議論される問題は、「メソッドが実装されていない」（34.85%）である。引用: Communicative Agents for Software Development - Reviewer-Programmer Dialogue Analysis - ページ10
Testing pahseでは、プログラマー・レビュアー・テスターの3つの役割のエージェントが、プログラマーが書いたコードを元にテスト・レビューを実施し、レビューアーからプログラマーへのフィードバックとして、"methods not implemented"、"modules not imported"などの指摘が行われます。[2]
Tool Use
設計者は、テキストベースのコマンドの代わりにグラフィカルアイコンを使用してユーザーと対話する、ユーザーフレンドリーなグラフィカルユーザーインターフェース（GUI）を提案する。次に、設計者は、外部のtext-to-imageツール[35]を使用して視覚的に魅力的なグラフィックを作成し、プログラマは、標準的なツールキットを使用してGUI設計に組み込む。
引用: Communicative Agents for Software Development - 2.3 Coding - ページ6
Tool Useに関しても、全てのエージェントが外部ツールの選択が可能なわけではなさそうですが、少なくとも設計者ロールを持つエージェントはGUIデザインにおいて外部のtext-to-imageツールを利用することが明記されています。[3]
論文中では記載がない(認識、誤っていたらご指摘ください)ですが、さらにコーディングエージェントがドキュメントや既存のコードを参照することが出来ると、より高品質なコードを生成できるかもしれません。
まとめ
これらの例を見ると、上手くパターンを組み合わせることが出来れば、LLMエージェントの能力を格段に向上させ、より高度なタスクを遂行できる可能性があることがわかります。
the first AI software engineerとして話題になったDevinも、デモや説明だけでの判断になりますが、少なくともTool UseとPlanningパターンは近しいものがありそうです。
長期的な推論とプランニングの進歩により、Devinは何千もの決定を必要とする複雑なエンジニアリングタスクを計画し、実行することができます。Devinは、すべて
のステップで関連するコンテキストを呼び出し、時間をかけて学習し、ミスを修正することができます。
Devinはまた、サンドボックス化された計算環境内で、シェル、コードエディタ、ブラウザを含む一般的な開発者ツールを備えています。
想像に過ぎませんが、Devinがコーディングを行い、エラーやバグを修正するプロセスでは、ReflectionやMulti-agent collaborationに近い仕組みも採用されている可能性はありそうですね。
これらの例から想像するに、Agentic Design Patternsを実践する際には、
- 作業工程が複雑で情報収集が重要な場合、Tool Useに加えて、Reflection、Planningの組み合わせ
- 専門性の異なるタスクを組み合わせる必要がある場合は、Multi-agent collaboration
など、タスクの性質に応じて適切なデザインパターンを選択・組み合わせることが求められそうです。
また高度なLLMエージェントを構築しようとすると、タスクやロール毎に組み合わせを変える必要もあるかもしれません。
おわりに
LLMエージェント開発のデザインパターン、Agentic Design Patternsを紹介しました。
Agentic Design Patternsは、単独で適用するのではなく、複数組み合わせることで相乗効果が期待できます。
LLMモデルの進化により、ゼロショットモードでもクオリティがどんどん上がっていることは喜ばしいですが、長期的にはこのAIエージェントのワークフローも大きな進歩を期待できるため、引き続きこの領域は試行錯誤していきたいですね！
今回はLLMエージェント自体の概要や課題等には触れていませんが、以下のリソースを読んで頂けると、LLMエージェントの理解に役立つと思います。
- LLMマルチエージェントを俯瞰する
- いまこそ学ぶLLMベースのAIエージェント入門
- LLM-Agent-Survey
- AIエージェントとLangChain
- エージェント型AIシステム構築の7つの原則： OpenAI『Practices for Governing Agentic AI』を読み解く
- Devin を含むAIソフトウェアエンジニアと周辺技術のざっくり紹介
- LLMベースの自律型エージェントシステムのサーベイ
- Large Language Model based Multi-Agents: A Survey of Progress and Challenges
- LLM Powered Autonomous Agents
自身の理解のためにひたすら書いていたら、思ってたよりも長くなってしまったので、もっと要点に絞ったり、パターン毎に実装例を紹介する記事もそのうち書ければと思います。
LLMエージェントを構築する際の参考になれば幸いです！以上です！
参照
Agentic Design Patterns Part 1
Agentic Design Patterns Part 2, Reflection
Agentic Design Patterns Part 3, Tool Use
株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。
Discussion