メインコンテンツまでスキップ
に最終更新

ガイド: エージェント開発ワークフロー

このガイドは、AI アプリケーションまたは AI エージェントの構築のライフサイクル全体を理解するための出発点を提供します。このガイド全体を通じて、「AI エージェント」は、単純な LLM 呼び出し、AI 関数、エージェントベースの実装など、GenAI を利用したシステムの総称です。

開発ライフサイクルの概要​

  1. ユースケース、範囲、成功を理解する メトリクス
  2. 初期AIエージェントを構築する
  3. AIエージェントの品質を反復する
  4. 本番運用前に関係者と調整する
  5. リリースから本番運用まで、品質を継続的に監視します

1. ユースケース、範囲、成功を理解する メトリクス​

何かを構築する前に、AI エージェントが何を行うのかを明確にします。本番運用への展開を承認する人々を含む関係者と調整します。

  • エージェントはどのような種類の入力を処理しますか (「ドメイン」または「スコープ」)?どのようなユーザーが入力を送信しますか?
  • エージェントは一般的な入力に対して理想的にはどのように応答すべきでしょうか?どのような情報やコンテキストを使用すればよいでしょうか?
  • 良い回答と悪い回答を定義する基準は何ですか? 語調、正確さ、完全性、回答の長さ、安全性、引用、その他の要件など。
  • 本番運用には、コスト、レイテンシー、スケーラビリティなど、どのようなシステム要件と制約がありますか?
  • 潜在的な障害モードとは何ですか? また、エージェントはそれらをどのように処理する必要がありますか? (ユーザー入力の誤り、回答するには情報が不十分、回答が間違っていることを示すユーザー フィードバックなど)。

最もシンプルで実行可能なアプローチを選択してください。多くのユースケースでは、複雑なエージェント システムやマルチエージェント システムは必要ありません。構築する前に、問題が複雑さの連続体のどこに位置するかを評価します。単純な決定論的ロジックまたはバッチ AI 機能で十分でしょうか?動的なツール呼び出し、推論、または調整が必要な場合は、ツール呼び出しエージェントまたはマルチエージェント システムを検討してください。より詳しいガイダンスについては、「エージェント システムの設計パターン」を参照してください。

この基盤により、次のことが可能になります。

  1. エージェントに必要なデータソースとツールを特定する
  2. 意図した行動を反映した最初の指示やプロンプトを書く
  3. 代表的な例や早期のフィードバックを提供できるドメイン専門家またはテスターを特定する
  4. 評価基準をエンコードして反復を加速する自動審査員を作成する

この段階では完璧な明確さは必要ありません。繰り返すうちに理解は深まっていきます。しかし、特に品質の測定方法や「本番運用準備完了」の意味について、早期の調整を強化することで、その後の品質改善と承認が大幅に迅速化されます。

2. 初期AIエージェントを構築する​

ユースケースと目標が明確に定義されたら、AI エージェントのプロトタイプを作成する準備が整います。Databricks は、AI エージェントを構築するためのガイド付きの UI ベースのルートと、完全にカスタマイズされたコードベースのルートの両方を提供します。

2.1.データとツールを準備する​

AI エージェントは通常、コンテキストと機能を提供するためにデータとツールを使用します。Databricks でのデータとツールの操作の概要については、 「AI エージェント ツール」を参照してください。

新しいデータとツールを作成する前に、既存のデータとツールを検索します。

  • Unity Catalogまたはワークスペース検索で利用可能なデータを調べて、どのような管理対象アセットがすでに存在しているかを理解します。 これにより、新しいアセットを作成する前に、利用可能なコンテキストと機能を把握できるようになります。
  • AI Playgroundでは、検索インデックス、MCP サーバー、UC 関数など、エージェントがすでに使用できるツールを表示および選択できます。

必要に応じて新しいアセットを作成および管理します。

これらのデータアセットとツールはすべて Unity Catalog で管理およびバージョン管理されているため、AI エージェントとアプリケーション全体で検出および再利用できます。

2.2.初期エージェントを構築する​

カスタム エージェントを構築する前に、宣言型のAgent Bricksオファリングまたは既存のDatabricks ソリューション アクセラレータが既にユース ケースに適合しているかどうかを評価します。一般的なパターンでは、これらのガイド付きアプローチにより、セットアップが大幅に削減され、ある程度の品質が向上し、本番運用までの時間を短縮できます。

カスタムエージェントがまだ必要な場合は、新しいビルダーはエクスペリメントへの最速の方法から始める必要があります。 AI Playground を使用すると、コードを書かずにエージェントのプロトタイプを作成できます。AI Playground を使用すると、さまざまなモデルを試したり、迅速なエンジニアリングを行ったり、ツールをテストしたりして、データの品質、エージェントの動作、アプローチの可能性を迅速に理解することができます。その後、エージェントをコードとしてエクスポートし、さらにカスタマイズや反復を行うことができます。

すでにエージェント コードがある場合は、既存のコードを Databricks に持ち込み、Databricks アプリとしてデプロイできます。

エージェントを構築するときは、事前に評価と本番運用の計画を立ててください。

  • MLflow Tracingを使用してエージェントをインストルメント化し、エージェントの動作を記録および分析します。

    • この段階では、機能の正確性に重点を置きます。エージェントがエンドツーエンドで実行され、必要なデータとツールにアクセスできることを確認します。
    • 間違ったツールの選択、コンテキストの欠落、幻覚などの初期の問題がないか確認します。
    • 後で、これらのトレースはエージェントの品質を評価するために使用されます。

  • 実装中に、本番運用アプリケーションに適切な認証方法を検討してください。

3. AIエージェントの品質を反復する​

実用的なプロトタイプが完成したら、次のフェーズでは、品質の測定、理解、改善を緊密に繰り返します。Databricks は、MLflow Tracing、評価データセット、LLM 審査員によってサポートされるMLflow Evaluation をこのループの中心に置きます。

自動採点者と LLM 審査員はスケールと一貫性を提供しますが、現実世界での有用性を検証し、微妙な失敗を理解するには人間によるフィードバックが不可欠です。人間からのフィードバックは、LLM 審査員の育成と調整にも役立ちます。エージェントが成熟するにつれて、人間からのフィードバックは通常 3 つの段階で発生します。

  1. 開発者と利害関係者による早期検証
  2. より広範な分野の専門家によるレビュー
  3. エンドユーザーからのフィードバック

3.1.初期行動を検証する​

開発者と、利害関係者またはドメイン専門家の小さなグループが、迅速かつ早期のフィードバックを提供できます。 テストと評価を拡大する前に、最も明白な状況でエージェントが適切な動作を行っていることを確認します。

プロトタイプ作成中、開発者はエージェントを手動でクエリして、エンドツーエンドで実行され、期待どおりに動作することを確認することで、非公式の「雰囲気チェック」を実行することがよくあります。MLflow Tracing UI を使用すると、開発者はトレースにフィードバックや期待を直接添付して、品質の問題にフラグを付けたり、成功した例をマークしたり、将来の評価と反復のためにメモを記録したりできます。

内部プロトタイプを展開すると、 Review App Chat UI によってフィードバックを収集するためのシンプルな UI が提供されます。プロトタイプのチャット UI を、妥当なクエリと問題のあるクエリの両方を尋ねることができる少数の開発者またはドメイン エキスパートと共有します。

MLflow Tracing は、インタラクションとフィードバックを記録して、結果の初期データセットを構築します。MLflow UI またはコードを使用してトレースを分析し、エージェントのパフォーマンスと動作を理解します。結果が悪かったり予期しなかったりする場合は、トレースを使用してデバッグします。

  • ツールの誤用、幻覚、コンテキストの欠落など、エージェントの品質問題を分析します。プロンプトの調整、ツールの使用、データなどの修正を適用します。3.4 問題を修正し、改善点を再検証するを参照してください。
  • 反復処理を実行すると、トレース データセットを代表的なユーザー入力として使用して、新しいプロトタイプのトレースを生成できます。
  • エージェントが代表的な入力のすべてまたはほとんどを期待どおりに処理するまで、実行、検査、修正、再実行というループを繰り返します。
  • 今後の反復でさらに多くの問題が明らかになり、対処される可能性があります。品質改善は反復的であり、この初期段階に限定されません。

このステップを踏むと、より広範なテストに投資する前に、プロトタイプが一般的なケースで適切に動作し、妥当なレベルの品質を達成していることに自信を持てるようになります。

3.2.テストとフィードバックを拡大する​

プロトタイプが単純なケースで動作した後、ベータ テスターの範囲を拡大し、よりカスタマイズされたフィードバックを収集することで、品質評価を拡大します。このフェーズでは、予期しないトピック、誤解されたクエリ、ツールと検索のギャップ、新たな使用パターンなどの盲点が明らかになります。評価データセットも拡張されます。

  • アプリケーションをより広範な関係者やドメイン エキスパート、またはベータ版のエンド ユーザーに展開します。エージェントがより幅広い使用パターンに触れるにつれて、そのフィードバックを取り入れます。
  • 専門家からのフィードバックを得るためにカスタム スキーマを使用したレビュー アプリのラベル付けセッションを使用して、より詳細なフィードバックと期待を取得します。
  • 人間のフィードバックとラベル付きトレースを同期して評価データセットを構築し、次のステップでの体系的な評価とモニタリングの準備をします。
  • 評価データセットをさらに充実させるには、合成評価セットの生成を検討してください。

3.3.品質を評価し、体系的にデバッグする​

評価データセットがより大きく多様化するにつれて、問題を検出し、最も重要な障害を明らかにし、根本原因を理解するための構造化され、より自動化された方法が必要になります。

実際には、データを次の 2 種類の評価データセットに分割することになります。

  • 回帰テスト : 高品質の AI 応答を含むデータは、予想される動作を定義するのに役立ちます。これらのデータセットを使用して、エージェントの新しいバージョンが、予想されるさまざまなシナリオにわたって引き続き良好なパフォーマンスを発揮することを検証します。
  • 問題に焦点を当てたデバッグ : 品質の低い AI 応答を含むデータには、さまざまな望ましくない動作が含まれている可能性があります。同じ種類の低品質の動作を示すトレースのグループを分離して、根本原因を理解し、対象を絞った修正を繰り返すことができます。

以下のツールは、両方のタイプの評価データセットの構築と分析に役立ちます。

回帰テストを実行する​

  • 高品質の AI 応答または人間の期待値があるデータの代表的なサブセットを選択して、回帰テストを構築します。
  • 組み込みまたはカスタムの LLM 審査員と採点者を使用して評価基準を定義します。自動評価では、LLM のみを使用して応答の品質を評価することも、応答を実際の応答や期待値と比較することもできます。
  • エージェントの新しいバージョンで評価を実行し、更新によって以前の良好な動作が低下しないことを確認します。

低品質な回答の種類を特定する​

自動検出の精度を向上させる​

主に人間によるフィードバックを使用して評価データセットの構築を開始できますが、自動検出を使用して評価を拡張できます。反復するにつれて、アプリケーションとドメインに合わせて調整された LLM 審査員またはコードベースのスコアラーに投資します。

根本原因を効果的に解決​

障害が特定されたら、その障害が発生した理由を特定する必要があります。

  • MLflow Tracingを使用して、エージェントの推論の各ステップを手動で検査します。

    • 選択されたツール
    • ツールの入力と出力の使用方法
    • 検索によって関連するコンテキストが返されたかどうか
    • モデルの応答が下流の意思決定にどのように影響したか

  • MLflowAIまたはエージェント判定 を適用してトレースを分析し、接地不良、プロンプト構造の誤り、ツール引数の誤りなど、考えられる原因を指摘します。

  • MLflow の評価 UI でバージョンを比較して、問題が反復間で再発するか持続するかを確認します。

このステップの理想的な結果は、何が失敗しているのか、なぜ失敗しているのか、そしてそれをどのように修正するのかを体系的に理解することです。自動化とアプリケーション固有の判定により、エージェントの能力が向上し、テスト セットがより複雑になっても、自信を持って反復できます。

3.4.問題を修正し、改善点を再検証する​

問題がアプリケーション固有であるのと同様に、修正もアプリケーションに合わせて調整する必要があります。一般的な修正の例は次のとおりです。

  • プロンプトの最適化: エージェントの指示を手動で調整するか、データドリブン プロンプトの最適化を使用します。 マルチステップ推論やツールの使用の調整など、より広範なエージェントの最適化には、 DSPy チューニングを使用します。
  • ツールとデータ: トレースに事実の欠落や根拠の不足が見られる場合、ツールまたは検索フローを改善します。
  • ルーティング: トレースに間違ったツールまたはサブエージェントが呼び出されたことが示されている場合は、ツールまたはエージェントのメタデータ、プロンプト、またはルーティング モデルを改善します。
  • ガードレール: 応答が安全ルールに違反したり、情報が漏洩したりした場合は、 AI ゲートウェイ ガードレールまたはエージェントでカスタマイズされたガードレールを使用します。
  • フォールバック: 代替 API エンドポイントやフォールバック応答などのフォールバック メカニズムを使用して、極端なケース、データの欠落、または API 呼び出しの失敗を適切に処理します。

修正を繰り返す際には、アプリのバージョン管理とPrompt Registryを使用してバージョンを記録し、比較や回帰テストを簡素化します。

プロンプト、取得、ツール、データ、またはエージェントのその他の部分に対する各修正は、検出されたのと同じ方法で検証する必要があります。同じ評価データセットで新しいエージェント バージョンを再実行して、問題が修正され、回帰が発生していないことを確認します。

4. 本番運用前に関係者と調整する​

エージェントを実際の環境にリリースする前に、チームはエージェントの現在の機能、制限、測定された品質について共通の理解を持つ必要があります。このポイントに到達するには、通常、複数回の反復とステップ 3の品質向上が必要です。この段階では、技術的なシグナル (評価メトリクス、システム メトリクス、サンプル トレースなど) をビジネス コンテキストに変換し、エージェントが本当に「準備ができている」かどうかを最終的に判断します。

  • 評価結果を明確なビジネス シグナルに変換します。関係者が対応できる言語で、正確性、安定性、安全性、既知の制限を要約します。
  • 標準化された品質チェックが満たされていることを確認する: 必要な評価メトリクス、回帰チェック、およびデータセット カバレッジしきい値が候補バージョンに合格していることを確認します。
  • 運用の準備状況を検証し、承認を得る: モニタリングの設定、ガードレール、展開計画を確認します。 本番運用前にリスクと受け入れ基準を文書化します。

5.本番運用までリリースし、品質を継続的に監視する​

本番運用に到達することは大きなマイルストーンです。 これは、エージェントが実際のユーザーと実際の影響に対応できる準備ができていることを意味します。同時に、本番運用は新たなサイクルの始まりでもあります。 エージェントが稼働すると、実際の使用によって新しい動作、エッジ ケース、問題が明らかになるため、継続的なモニタリングと改善が行われます。

  • 本番運用でエンドユーザーからのフィードバックを収集します。 ユーザー フィードバックを特定のトレースにリンクして、モデルの動作と合わせて分析できるようにします。これは、元のトレースに添付された評価としてフィードバックを記録することで実行できます。

  • ガードレール、ルーティング、一貫したログ記録にAI ゲートウェイを活用します。新しいエージェントの各バージョンが、運用上の支障なく実際のトラフィックに対して評価できることを確認します。

  • サンプリングされた本番運用トレースで評価を実行することで、ライブ トラフィックの品質を監視します。 新しいバージョンが少なくとも以前のバージョンと同様に機能することを確認し、ユーザーが新しいタイプのクエリを送信したときに新しい問題がないか確認します。継続的なモニタリングにより、エージェントの信頼性と安全性が維持され、進化するビジネス ニーズに合わせて維持されます。 MLflowモニタリング ダッシュボードを提供しますが、トレースはUnity Catalogに保存できるため、ダッシュボードとアラートをカスタマイズできます。

  • 本番運用の知識に基づいて行動する:

    • リスクの高いユースケースの場合は、モニタリングを自動化またはゲート制御されたロールバック メカニズムにリンクして、重大な問題を修正します。
    • 本番運用の知識を次のイテレーションに活用してください。 実際の障害を新しい評価データに変換し、評価とデバッグのループに戻って、エージェントの次のより良いバージョンを構築します。

次のステップ​