次の方法で共有

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

エージェント システムを構築するには、LLM 呼び出し、データ取得、および外部アクションの連携方法を調整する必要があります。 複雑さと自律性の のコンティニュアム上のエージェント システムの設計パターンを考えることができます。決定論的チェーンから、動的な決定を行うことができる (内部で複数の LLM 呼び出しを伴う可能性がある) 単一エージェント システムから、複数の特殊なエージェントを調整 するマルチエージェント アーキテクチャまで。

ツールの呼び出し

設計パターンに進む前に、ツールの呼び出しを、単純なものから複雑なものまで、あらゆるエージェント システムで使用できる基本的な機能として理解しておくことが重要です。 ツール呼び出しは、エージェント システムが外部の関数、データ ソース、またはサービスと対話できるようにするメカニズムです。 これにより、次のことができます。

  • SQL クエリ、CRM フェッチ、ベクター インデックス取得などのライブ データ参照。
  • 電子メールの送信やレコードの更新などのアクション。
  • Python 関数または API を使用した任意のロジックまたは変換。

そのため、ツール呼び出しは、選択した設計パターンに関係なく、LLM に外部データまたは API を "認識" させる強力なメカニズムを提供します。

エージェント ツールの詳細については、「AI エージェント ツールの」を参照してください。

以下のセクションでは、3 つのエージェント システム設計パターンについて説明します。各パターンでは、さまざまな角度でツール呼び出しを利用できます。

Gen AI アプリの設計パターンを比較する

Gen AI アプリ (エージェント) の設計パターンは、複雑さの順に表示されます。

デザイン パターン 使用するタイミング 長所 短所
決定論的チェーン
  • 明確に定義されたタスク
  • 基本的な RAG などの静的パイプライン
  • オンザフライの決定は必要ありません
  • 非常にシンプル
  • 監査が簡単
  • 柔軟性がない
  • コードを変更して適応させる必要があります
単一エージェント システム
  • 同じドメイン内の複雑なクエリにモデレートする
  • 複数の特殊なエージェントのオーバーヘッドを伴わない動的な決定。
  • フレキシブル
  • マルチエージェントよりシンプル
  • “既定” に適している
  • 予測が少ない
  • ツール呼び出しの繰り返しまたは間違った呼び出しを防ぐ必要がある
マルチエージェント システム 大きなドメインまたは機能間ドメイン。複数の "エキスパート" エージェント。個別のロジックまたは会話コンテキスト。高度なリフレクション パターン。
  • 高度なモジュール式
  • 大きなドメインにスケーリングする
  • オーケストレーションが複雑
  • トレースとデバッグが困難

単一エージェント システム

単一エージェント システムは、受信要求を処理するために、1 つの調整されたロジック フロー (多くの場合、複数の LLM 呼び出しを調整する) を備えています。 エージェントは次のことができます。

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

多くのユース ケースでは、1 回の LLM 推論 (多くの場合、ツール呼び出し) で十分です。 ただし、より高度なエージェントは、目的の結果が得られるまで、複数のステップをループ処理できます。

"1 つの" エージェントしかない場合でも、内部で複数の LLM とツールの呼び出し (計画、生成、検証など) を行うことができ、すべてこの単一の統一されたフローによって管理されます。

例: ヘルプ デスク アシスタント

  • ユーザーが簡単な質問 ("What is our returns policy?") を尋ねた場合、エージェントは LLM の知識から直接応答する可能性があります。
  • ユーザーが注文の状態を希望する場合、エージェントは lookup_order(customer_id, order_id)関数を呼び出します。 そのツールが "無効な注文番号" で応答した場合、エージェントは再試行するか、ユーザーに正しい ID の入力を求め、最終的な回答が得られるまで続行できます。

使用するタイミング:

  • さまざまなユーザー クエリが必要ですが、それでも、まとまりのあるドメインまたは製品領域内にあります。
  • 特定のクエリや条件によっては、顧客データを取得するタイミングを決定するためにツールを使用することが必要となる場合があります。
  • 決定論的チェーンよりも柔軟性を高める必要がありますが、異なるタスクに個別の特殊なエージェントを必要としません。

の利点:

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

考慮事項:

  • ハードコーディングされたチェーンと比較して、繰り返しまたは無効なツール呼び出しから保護する必要があります。 (無限ループは任意のツール呼び出しシナリオで発生する可能性があるため、イテレーションの制限またはタイムアウトを設定します)。
  • アプリケーションが大幅に異なるサブドメイン (財務、開発、マーケティングなど) にまたがる場合、1 つのエージェントが扱いにくくなるか、機能要件で過負荷になる可能性があります。
  • エージェントが集中し、関連性を保つためには、慎重に設計されたプロンプトと制約が必要です。

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

このパターンでは、開発者は、呼び出されるコンポーネント、順序、およびパラメーターを定義します。 に関する、どのツール を呼び出すか、またはどの順序で 行うかについての動的な意思決定はありません。 システムは、すべての要求に対して定義済みのワークフローに従い、非常に予測可能になります。

一般的に "チェーン" と呼ばれるフローは、基本的に次のような固定のステップ チェーンです。

  1. 常にユーザーの要求を取得し、関連するコンテキストのベクター インデックスから取得します。
  2. そのコンテキストをユーザーの要求と組み合わせて、最終的な LLM プロンプトにします。
  3. LLM を呼び出し、応答を返します。

例: 基本的な RAG チェーン

基本的な RAG チェーンの図。

決定論的な RAG チェーンは常に次のようになるかもしれません。

  1. 受信ユーザーの要求 (取得) を使用して、ベクター インデックスから top-k の結果を取得します。
  2. 取得したチャンクをプロンプトテンプレートにフォーマットする（拡張）。
  3. その拡張プロンプトを LLM に渡します (生成)。
  4. LLM の応答を返します。

使用するタイミング:

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

の利点:

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

考慮事項:

  • 多様な要求や予期しない要求を処理するための柔軟性が制限されています。
  • ロジック ブランチが拡大するにつれて、複雑になり、保守が困難になる可能性があります。
  • 新機能に対応するために重要なリファクタリングが必要な場合があります。

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

マルチエージェント システムには、メッセージの交換やタスクの共同作業を行う、2 つ以上の特殊なエージェントが含まれます。 各エージェントには、独自のドメインまたはタスクの専門知識、コンテキスト、および異なる可能性のあるツール セットがあります。 別の "コーディネーター" (別の LLM またはルール ベースのルーター) は、要求を適切なエージェントに送信するか、エージェント間でいつ引き渡すかを決定します。

例: 専門エージェントを備えたエンタープライズ アシスタント

  • カスタマー サポート エージェント: CRM の検索、返品、出荷を処理します。
  • Analytics エージェント: SQL クエリとデータの要約に焦点を当てます。
  • Supervisor/router: 特定のユーザー クエリに最適なエージェント、または切り替えるタイミングを選択します。

各サブエージェントは、一意のプロンプトや会話履歴を必要とする独自のドメイン (lookup_customer_account や run_sql_queryなど) 内でツール呼び出しを実行できます。

使用するタイミング:

  • コーディング エージェントや財務エージェントなど、個別の問題領域またはスキル セットがあります。
  • 各エージェントは、会話履歴またはドメイン固有のプロンプトにアクセスする必要があります。
  • 1 つのエージェントのスキーマにすべてを適合させるツールは非常に多く、実用的ではありません。各エージェントはサブセットを所有できます。
  • 特殊なエージェント間でリフレクション、批判、または双方向のコラボレーションを実装したいと考えています。

の利点:

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

考慮事項:

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

実用的なアドバイス

選択した設計パターンに関係なく、安定した保守可能なエージェント システムを開発するための次のベスト プラクティスを検討してください。

  1. 単純な開始: 単純なチェーンのみが必要な場合は、決定論的チェーンを構築するのが高速です。
  2. 徐々に複雑さを増します。 動的なクエリや柔軟なデータ ソースが必要な場合は、ツール呼び出しを使用して単一エージェント システムに移行します。
  3. 複数エージェントに移動する: 明確に異なるドメインまたはタスク、複数の会話コンテキスト、または 1 つのエージェントのプロンプトに対して大きすぎる大きなツール セットがある場合のみ。

ユース ケースが単純な RAG チェーンのように小さく始まる場合は、ハードコーディングされたチェーンから始めます。 要件が進化するにつれて、動的な意思決定のためのツール呼び出しロジックを追加したり、タスクを複数の特殊なエージェントにセグメント化したりできます。 実際には、多くの実際のエージェント システムはパターンを組み合わせています。 たとえば、主に決定論的なチェーンを使用しますが、必要に応じて、LLM が 1 つのステップで特定の API を動的に呼び出せるようにします。

Mosaic AI Agent Framework は、選択したパターンに依存しないため、アプリケーションの成長に合わせて設計パターンを簡単に進化させることができます。

開発ガイダンス

  • プロンプト
    • 矛盾した指示や気が散る情報を避け、幻覚を減らすために、プロンプトを明確かつ最小限に抑えます。
    • 無制限の API セットや大規模な無関係なコンテキストではなく、エージェントに必要なツールとコンテキストのみを提供します。
  • ログ記録 & 可観測性
    • ユーザー要求、エージェント プラン、ツール呼び出しごとに詳細なログ記録を実装します。 MLflow トレース は、デバッグのために構造化されたログをキャプチャするのに役立ちます。
    • ログを安全に保存し、会話データ内の個人を特定できる情報 (PII) に注意してください。
  • モデルの更新およびバージョンのピン留め
    • LLM の動作は、プロバイダーがバックグラウンドでモデルを更新するときに変化する可能性があります。 バージョン固定と頻繁な回帰テストを使用して、エージェント ロジックが堅牢で安定していることを確認します。
    • MLflow と Mosaic AI Agent Evaluation を組み合わせることにより、エージェントのバージョン管理と品質とパフォーマンスの定期的な評価を合理化できます。

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

  • フォールバック ロジック & エラー処理
    • ツールやLLMの障害に備えて計画を立てましょう。 タイムアウト、正しくない応答、または空の結果は、ワークフローを中断する可能性があります。 高度な機能が失敗した場合は、再試行戦略、フォールバック ロジック、またはより単純なフォールバック チェーンを含めます。
  • 反復プロンプト エンジニアリング
    • 時間の経過と同時にプロンプトとチェーン ロジックを調整することが期待されます。 (Git と MLflow を使用して) 各変更をバージョン管理し、バージョン間でパフォーマンスをロールバックまたは比較できるようにします。
    • DSPy などのフレームワークを検討して、エージェント システム内のプロンプトやその他のコンポーネントをプログラムで最適化します。

運用ガイダンス

  • レイテンシとコスト最適化
    • 追加の LLM またはツール呼び出しのたびに、トークンの使用と応答時間が増加します。 可能であれば、ステップを組み合わせるか、繰り返しクエリをキャッシュして、パフォーマンスとコストを管理できるようにします。
  • セキュリティとサンドボックス
    • エージェントがレコードを更新したりコードを実行したりできる場合は、それらのアクションをサンドボックス化するか、必要に応じて人による承認を強制します。 これは、意図しない損害を避けるために、企業または規制された環境で重要です。
    • Databricks では、セキュリティで保護された実行のために Unity カタログ ツールが推奨されます。 Unity カタログ関数ツールとエージェント コード ツールのを参照してください。 Unity Catalog を使用すると、任意のコード実行を分離でき、悪意のあるアクターがエージェントをだまして、他の要求に干渉または傍受するコードを生成して実行することを防ぐことができます。

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