エージェント システムの設計パターン

GenAI エージェントは、GenAI モデルのインテリジェンスと、データ取得、外部アクション、その他の機能のためのツールを組み合わせます。このページではエージェントの設計について説明します。

• エージェント システムを構築する具体的な例は、モデルとツールの呼び出しがどのように連携するかを調整する方法を示しています。
• エージェント システムの設計パターンは、決定論的なチェーンから、動的な決定を下せるシングル エージェント システム、複数の特化エージェントを調整するマルチ エージェント アーキテクチャに至るまで、複雑性と自律性の連続体を形成します。
• 実践的なアドバイスのセクションでは、適切な設計の選択、エージェントの開発、テスト、本番運用への移行に関するアドバイスが提供されます。

エージェントは、情報の収集や外部アクションの実行にツールに大きく依存しています。ツールの背景の詳細については、 「ツール」を参照してください。

エージェントシステムの例

エージェント システムの具体的な例として、顧客と対話するコール センターの GenAI エージェントを考えてみましょう。

顧客は「前回の注文の返品を手伝ってもらえますか？」とリクエストします。

1. 理由と計画 : クエリの意図を考慮して、エージェントは次のように「計画」します。「ユーザーの最近の注文を検索し、返品ポリシーを確認します。」

2. 情報の検索 (データ インテリジェンス): エージェントは注文データベースを照会して関連する注文を取得し、ポリシー ドキュメントを参照します。

3. 理由 : エージェントは、その注文が返品期間内に収まるかどうかを確認します。

   • オプションの人間参加: エージェントは追加のルールをチェックします: アイテムが特定のカテゴリに該当する場合、または通常の返品期間外の場合は、人間にエスカレーションします。

4. アクション : エージェントが返品プロセスをトリガーし、配送ラベルを生成します。

5. 理由 : エージェントが顧客への応答を生成します。

AI エージェントは顧客に応答します。「完了しました!「こちらが発送ラベルです…」

これらのステップは、 人間の コールセンターの文脈では自然なものです。 エージェント システムの コンテキストでは、 LLM 「推論」し、システムは詳細を入力するために専用のツールまたはデータ ソースを呼び出します。

複雑さのレベル: LLMからエージェントシステムまで

GenAI アプリは、単純な LLM 呼び出しから複雑なマルチエージェント システムまで、さまざまなシステムで動作できます。AI を活用したアプリケーションを構築するときは、まずシンプルに始めましょう。柔軟性の向上やモデル駆動型の意思決定のために本当に必要な場合、より複雑なエージェント動作を導入します。決定論的チェーンは、明確に定義されたタスクに対して予測可能なルールベースのフローを提供します。エージェント的なアプローチを多くすると、柔軟性と可能性が高まりますが、複雑さが増し、遅延が発生する可能性が高くなります。

デザインパターン	いつ使用するか	長所	短所
LLM + プロンプト	一般的な質問と回答 短期使用のためのクイックプロトタイプ	とてもシンプル 簡単に作成できます	最小限のカスタマイズ
決定論的チェーン	明確に定義されたタスク 基本的なRAGなどの静的パイプライン 即座の決断は不要	シンプル 監査が容易	柔軟性がない 適応するにはコードの変更が必要
シングルエージェントシステム	同じドメイン内の中程度から複雑なクエリ 複数の専門エージェントのオーバーヘッドなしで動的な決定を行う	フレキシブル マルチエージェントよりもシンプル 良い「デフォルト」	予測しにくい 繰り返しのツール呼び出しや誤ったツール呼び出しを防ぐ必要があります
マルチエージェントシステム	大規模または多機能ドメイン 異なるロジックや会話コンテキストを持つ複数の「専門家」エージェント	高度にモジュール化された 大規模なドメインに拡張可能	オーケストレーションが複雑 追跡とデバッグが困難

Mosaic AI エージェント フレームワークはこれらのパターンに依存しないため、シンプルに開始して、アプリケーション要件の拡大に合わせて、より高いレベルの自動化と自律性へと進化させることが容易になります。

エージェント システムの背後にある理論の詳細については、 Databricks創設者によるブログ記事を参照してください。

• AIエージェントシステム：信頼性の高いエンタープライズAIアプリケーションのためのモジュールエンジニアリング
• モデルから複合AIシステムへの移行

LLMとプロンプト

最もシンプルな設計では、膨大なトレーニング データセットの知識に基づいてプロンプトに応答するスタンドアロンの LLM またはその他の GenAI モデルが使用されます。この設計は、単純なクエリや一般的なクエリには適していますが、実際のビジネス データとは切り離されていることがよくあります。システム プロンプトにカスタム命令または埋め込みデータを提供することで、動作をカスタマイズできます。

決定論的チェーン (ハードコードされたステップ)

決定論的チェーンはツール呼び出しによって GenAI モデルを拡張しますが、開発者はどのツールまたはモデルが、どのような順序で、どの 引数を使用して呼び出されるかを定義します。 LLM は 、どのツールをどの ような順序 で呼び出すかについては決定しません。システムはすべてのリクエストに対して事前定義されたワークフローまたは「チェーン」に従うため、予測可能性が高くなります。

たとえば、決定論的な検索拡張生成 (RAG) チェーンでは、常に次のようになります。

1. ベクトル インデックスから上位 k 件の結果を取得し、ユーザー要求に関連するコンテキストを見つけます。
2. ユーザーのリクエストと取得したコンテキストを組み合わせてプロンプトを拡張します。
3. 拡張プロンプトを LLM に送信して応答を生成します。

いつ使用するか:

• 予測可能なワークフローを持つ明確に定義されたタスクの場合。
• 一貫性と監査が最優先事項である場合。
• オーケストレーションの決定のための複数の LLM 呼び出しを回避して待機時間を最小限に抑える場合。

利点：

• 最高の予測可能性と監査可能性。
• 通常、待機時間が短くなります (オーケストレーションのための LLM 呼び出しが少なくなります)。
• テストと検証が簡単にできます。

考慮 事項：

• 多様なリクエストや予期しないリクエストを処理するための柔軟性が限られている。
• ロジック分岐が大きくなると、複雑になり、保守が難しくなる可能性があります。
• 新しい機能に対応するには大幅なリファクタリングが必要になる場合があります。

シングルエージェントシステム

シングルエージェント システムには、1 つの調整されたロジック フローを調整する LLM があります。LLM は、どのツールを使用するか、いつさらに LLM 呼び出しを行うか、いつ停止するかを適応的に決定します。このアプローチは、動的でコンテキストに応じた意思決定をサポートします。

単一エージェントシステムでは次のことが可能です。

1. ユーザークエリなどのリクエストや、会話履歴などの関連するコンテキストを受け入れます。
2. 最適な応答方法に関する理由付け (必要に応じて、外部データまたはアクションのツールを呼び出すかどうかを決定します)。
3. 必要に応じて反復し、有効なデータの受信やエラーの解決など、目的が達成されるか特定の条件が満たされるまで、LLM またはツールを繰り返し呼び出します。
4. ツールの出力を会話に統合します。
5. まとまりのある応答を出力として返します。

たとえば、ヘルプデスク アシスタント エージェントは次のように適応する可能性があります。

• ユーザーが簡単な質問（「返品ポリシーは何ですか？」）をした場合、エージェントは LLM の知識から直接応答する可能性があります。
• ユーザーが注文ステータスを知りたい場合、エージェントは関数lookup_order(customer_id, order_id)を呼び出す可能性があります。ツールが「無効な注文番号」と応答した場合、エージェントは再試行するか、ユーザーに正しい ID の入力を促し、最終的な回答が得られるまで続行します。

いつ使用するか:

• さまざまなユーザークエリが予想されますが、それでもまとまりのあるドメインまたは製品領域内にあります。
• 特定のクエリや条件では、顧客データをいつ取得するかを決定するなどのツールの使用が必要になる場合があります。
• 決定論的チェーンよりも柔軟性が必要ですが、タスクごとに個別の専門エージェントは必要ありません。

利点：

• エージェントは、呼び出すツール(存在する場合)を選択することで、新しいクエリや予期しないクエリに適応できます。
• エージェントは、LLMの繰り返し呼び出しやツールの呼び出しをループして、完全なマルチエージェント設定を必要とせずに結果を絞り込むことができます。
• この設計パターンは、多くの場合、エンタープライズのユースケースのスイートスポットであり、マルチエージェントセットアップよりもデバッグが簡単で、動的ロジックと限られた自律性が可能です。

考慮 事項：

• ハードコードされたチェーンと比較すると、ツールの繰り返し呼び出しや無効な呼び出しを防ぐ必要があります。無限ループはあらゆるツール呼び出しシナリオで発生する可能性があるため、反復制限またはタイムアウトを設定します。
• アプリケーションが根本的に異なるサブドメイン（財務、DevOps、マーケティングなど）にまたがる場合、単一のエージェントでは扱いにくくなったり、機能要件で過負荷になったりする可能性があります。
• エージェントの集中力と関連性を維持するために、慎重に設計されたプロンプトと制約は依然として必要です。
• エージェンシーは連続体です。システムの動作を制御するモデルに自由度を与えるほど、アプリケーションのエージェンシー性が高まります。実際には、ほとんどの本番運用システムは、コンプライアンスと予測可能性を確保するために、たとえば危険なアクションに対して人間の承認を必要とするなど、エージェントの自律性を慎重に制限します。

マルチエージェントシステム

マルチエージェント システムには、メッセージを交換したり、タスクで共同作業を行う 2 つ以上の専門エージェントが含まれます。各エージェントには、独自のドメインまたはタスクの専門知識、コンテキスト、および潜在的に異なるツール セットがあります。別の「コーディネーター」または「AI スーパーバイザー」がリクエストを適切なエージェントに送信したり、あるエージェントから別のエージェントにいつ引き継ぐかを決定します。スーパーバイザは別の LLM またはルールベースのルータにすることができます。

たとえば、顧客アシスタントには、専門のエージェントに委任するスーパーバイザーがいる場合があります。

• ショッピング アシスタント: 顧客の製品検索を支援し、レビューから長所と短所についてのアドバイスを提供します。
• 顧客サポートエージェント: フィードバック、返品、配送に対応します

いつ使用するか:

• コーディングエージェントや財務エージェントなど、明確な問題領域やスキルセットがあります。
• 各エージェントは、会話履歴またはドメイン固有のプロンプトにアクセスする必要があります。
• 非常に多くのツールがあるため、それらすべてを 1 つのエージェントのスキーマに適合させるのは現実的ではありません。各エージェントはサブセットを所有できます。
• 専門のエージェント間での反省、批評、またはコラボレーションを実装したいと考えています。

利点：

• このモジュラーアプローチは、各エージェントを、狭いドメインに特化した別々のチームによって開発または保守できることを意味します。
• 1 人のエージェントではまとまりのある管理に苦労する可能性のある大規模で複雑なエンタープライズ ワークフローを処理できます。
• 高度なマルチステップまたはマルチパースペクティブ推論を促進します - たとえば、1つのエージェントが回答を生成し、別のエージェントがそれを検証します。

考慮 事項：

• エージェント間のルーティングの戦略に加えて、複数のエンドポイント間でのログ記録、トレース、デバッグのオーバーヘッドが必要です。
• 多くのサブエージェントとツールがある場合、どのエージェントがどのデータまたは APIにアクセスできるかを決定するのは複雑になる可能性があります。
• エージェントは、慎重に制約しないと、解決せずにタスクを無期限にやりとりすることができます。単一エージェントのツール呼び出しでも無限ループのリスクは存在しますが、マルチエージェントのセットアップではデバッグの複雑さがさらに増します。

実践的なアドバイス

ユースケースがAgent Bricks の提供に適合する場合は、ガイド付きのよりシンプルなオプションから始めてください。

カスタム エージェント システムを構築する必要がある場合、Databricks とMosaic AI エージェント フレームワークは選択したパターンに依存しないため、アプリケーションの拡大に合わせて設計パターンを簡単に進化させることができます。安定した保守可能なエージェント システムを開発するには、次のベスト プラクティスを検討してください。

1. 簡単に始めましょう: 単純なチェーンのみが必要な場合は、決定論的チェーンをすばやく構築できます。
2. 徐々に複雑さを増す: より動的なクエリや柔軟なデータソースが必要になったら、ツール呼び出しを備えた単一エージェント システムに移行します。 明確に区別できるドメインやタスク、複数の会話コンテキスト、または大規模なツール セットがある場合は、マルチエージェント システムを検討してください。
3. パターンを組み合わせる: 実際には、現実世界の多くのエージェント システムはパターンを組み合わせます。たとえば、ほぼ決定論的なチェーンには、必要に応じてLLM特定のAPIsを動的に呼び出すことができる 1 つのステップを含めることができます。

開発ガイダンス

• プロンプトとツール

  • プロンプトは明確で最小限に抑えて、矛盾する指示を避け、情報を散らし、幻覚を減らします。
  • 無制限のAPIsセットや無関係な大規模なコンテキストではなく、エージェントに必要なツールとコンテキストのみを提供します。 設計時にツールアプローチを選択します。

• ログ記録と可観測性

  • MLflow Tracingを使用して、各ユーザー要求、エージェント プラン、およびツール呼び出しの詳細なログ記録を実装します。
  • ログを安全に保存し、会話データ内の個人を特定できる情報 (PII) に注意してください。自動化のためにデータ分類を検討してください。

テストとイテレーションのガイダンス

• 評価

  • MLflow評価と本番運用モニタリングを使用して、開発と本番運用の評価メトリクスを定義します。
  • 専門家やユーザーから人間によるフィードバックを収集して、自動評価メトリクスが適切に調整されていることを確認します。

• エラー処理とフォールバックロジック

  • ツールまたは LLM の障害を計画します。タイムアウト、形式が正しくない応答、または空の結果があると、ワークフローが中断される可能性があります。再試行戦略、フォールバック ロジック、または高度な機能が失敗した場合のより単純なフォールバック チェーンを含めます。

• 反復的な改善

  • 時間の経過とともにプロンプトとエージェント ロジックが改良されることが予想されます。プロンプトのMLflow プロンプト レジストリとアプリのMLflow アプリ バージョン追跡を使用したバージョンの変更。バージョン管理により操作が簡素化され、ロールバックや比較が可能になります。
  • 評価データを収集し、メトリックを定義する際には、 MLflow Prompt Optimizationなどのより自動化された最適化方法を検討してください。

本番運用 ガイダンス

• モデルの更新とバージョンの固定

  • LLM の動作は、プロバイダーがバックグラウンドでモデルを更新すると変化する可能性があります。バージョンの固定と頻繁な回帰テストを使用して、エージェントロジックの堅牢性と安定性を維持します。

• レイテンシとコストの最適化

  • LLM またはツール呼び出しが追加されるたびに、トークンの使用量と応答時間が増加します。可能な場合は、ステップを組み合わせるか、繰り返しクエリをキャッシュして、パフォーマンスとコストを管理しやすくします。

• セキュリティとサンドボックス化

  • エージェントがレコードを更新したりコードを実行したりできる場合は、それらのアクションをサンドボックス化するか、必要に応じて人間による承認を強制します。これは、企業環境や規制された環境では、意図しない損害を回避するために重要です。Unity Catalog機能は、本番運用のためのサンドボックス実行を提供します。
  • ツール オプションの詳細なガイダンスについては、 「ツール アプローチの選択」を参照してください。

これらのガイドラインに従うことで、ツールの誤呼び出し、LLM パフォーマンスのドリフト、予期しないコストの急増など、最も一般的な障害モードの多くを軽減し、より信頼性が高くスケーラブルなエージェント システムを構築できます。