🔖
チャットボットの先にある世界：現場で使いたいAIエージェント設計パターン
はじめに
プロンプトエンジニアリングから時代は、AIエージェント開発フェーズに移ってきましたが、「どうやってエージェントって設計すればいいの？」という課題感あるかと思います。
そこで今回は、2024年6月に公開された研究論文で提案された、AIエージェント設計における18の設計パターンを紹介します。この記事では、それぞれの概要と、ピックアップした7つのパターンを詳しく解説します。
取り上げる論文
18の設計パターン概要
| パターン名 | 概要 |
|---|---|
| Passive Goal Creator | ユーザーの入力を対話インターフェースから分析し、目標を特定 |
| Proactive Goal Creator | 関連ツールを使用して状況を把握し、ユーザーの目標を予測 |
| Prompt/Response Optimiser | 目的の入力/出力に合わせてプロンプト/レスポンスを最適化 |
| Retrieval Augmented Generation (RAG) | 外部ソースから情報を取得し、エージェントの知識を強化 |
| One-shot Model Querying | 1回のモデルクエリで計画の全ステップを生成 |
| Incremental Model Querying | 計画生成の各ステップでモデルをクエリ |
| Single-path Plan Generator | ユーザーの目標達成に向けた中間ステップを生成 |
| Multi-path Plan Generator | 各中間ステップで複数の選択肢を生成 |
| Self-reflection | エージェント自身が計画と推論過程を評価し、改善 |
| Cross-reflection | 他のエージェントやモデルを使用して計画と推論過程を評価 |
| Human Reflection | 人間のフィードバックを収集して計画を改善 |
| Voting-based Cooperation | 投票によってエージェント間の合意形成 |
| Role-based Cooperation | エージェントに役割を割り当て、役割に応じて意思決定 |
| Debate-based Cooperation | エージェント間の議論を通じて合意形成 |
| Multimodal Guardrails | 基盤モデルの入力と出力を制御 |
| Tool/Agent Registry | エージェントとツールを選択するための統一されたソースを維持 |
| Agent Adapter | エージェントとツールを接続するためのインターフェースを提供 |
| Agent Evaluator | エージェントの性能を評価 |
1. Passive goal creator
| 1. Passive goal creator | |
|---|---|
| 概要 | ユーザーの入力を対話インターフェースから分析し、目標を特定するパターン |
| 利用シーン | • 対話からのユーザの意図理解 |
| メリット | • ユーザーの自然な入力から目標を抽出可能 • 対話的な目標設定が可能 |
| デメリット | • 曖昧な入力への対応が困難 • 複雑な目標の解釈に課題 |
2. Prompt/Response Optimiser
| 2. Prompt/Response Optimiser | |
|---|---|
| 概要 | 目的の入力/出力に合わせてプロンプトやレスポンスを最適化するパターン |
| 利用シーン | • チャットボットの応答改善 • 検索クエリの最適化 • 文章生成の品質向上 |
| メリット | • より正確な応答が得られる • 出力の品質が向上する |
| デメリット | • 通常チャットbotよりもコストがおおよそ2~3倍程度 |
Dify例
上から
- 通常チャットbot
- プロンプトのみ最適化
- プロンプト・レスポンス最適化
気になる方は試してみてください。
プロンプト最適化用のプロンプト例
あなたはプロンプト最適化のプロフェッショナルです。
入力プロンプトを最適化してください。
{input}
レスポンス最適化用のプロンプト例
あなたはレスポンス最適化のプロフェッショナルです。
出力を最適化してください
{output}
3. Single-path Plan Generator
| 3. Single-path Plan Generator | |
|---|---|
| 概要 | ユーザーの目標達成に向けた中間ステップを一つずつ生成するパターン |
| 利用シーン | • 単純なタスク自動化 • 直線的なプロセス設計 • 明確な目標を持つプロジェクト |
| メリット | • シンプルで理解しやすい • 実装が容易 |
| デメリット | • 柔軟性に欠ける • 複雑なタスクには不向き |
*以下の画像はエンジニア向け
4. Multi-path Plan Generator
| 4. Multi-path Plan Generator | |
|---|---|
| 概要 | 各中間ステップで複数の選択肢を生成するパターン |
| 利用シーン | • 戦略的意思決定支援 • 複数の解決策が必要なシナリオ • リスク分散が必要な計画立案 |
| メリット | • 柔軟な選択肢を提供 • リスク分散が可能 |
| デメリット | • 計算コスト(最近tokenあたりのコストはだいぶ安いので気にならない方もいらっしゃるかも) • 選択肢が多すぎる場合の判断が困難 |
5. Self-reflection
| 5. Self-reflection | |
|---|---|
| 概要 | エージェント自身が計画と推論過程を評価し、改善するパターン |
| 利用シーン | • 自己学習システム • 品質管理プロセス • エラー検出と修正 |
| メリット | • 継続的な改善が可能 • エラーの早期発見 |
| デメリット | • 処理時間の増加 • 計算リソースの追加消費 |
6. Cross-reflection
あれ、Self-reflectionと何が違うの?
| 6. Cross-reflection | |
|---|---|
| 概要 | 他のエージェントやモデルを使用して計画と推論過程を評価するパターン |
| 利用シーン | • ピアレビューシステム • 協調的な問題解決 • 多角的な評価が必要なケース |
| メリット | • 多様な視点からの評価 • バイアスの軽減 |
| デメリット | • 外部依存のリスク • 調整コストの増加 |
7. Role-based Cooperation
| 7. Role-based Cooperation | |
|---|---|
| 概要 | エージェントに役割を割り当て、役割に応じて意思決定を行うパターン |
| 利用シーン | • チーム型AIシステム • 複数エージェントの協調作業 • 専門性の分担が必要なケース |
| メリット | • 明確な責任分担 • 専門性の活用 |
| デメリット | • コミュニケーションコスト • 役割の適切な配分が必要 |
段階的な導入ステップ
選び方は、個人の自由だと思います。まずは簡単に試せるもからやってみて、便利だと思うものを選んでいくという方法でいいでしょう。
例えば、以下のステップなど
1. まずは品質向上から
- Prompt/Response Optimiserで既存システムの改善
- 実装例を参考に、低コストで効果検証
2. タスク処理の高度化
- Single-pathからMulti-pathへの段階的移行
- 処理の複雑さに応じて選択
3. 品質管理の自動化
- Self-reflectionによる自己改善
- Cross-reflectionでの多角的評価
最後に
今回紹介した内容を実装ベースで深く知りたい方がいらっしゃいましたら、以下の本おすすめです。
Discussion