ジェネレーティブAIアプリ開発者のワークフロー

2025-04-23

堅牢なジェネレーティブ AI アプリケーション (Gen AI アプリ) を開発するには、意図的な計画、迅速な開発-フィードバック評価ループ、スケーラブルな運用インフラストラクチャが必要です。このワークフローでは、最初の概念実証 (POC) から運用環境のデプロイに移行するための推奨される一連の手順の概要を示します。

0. 前提条件

Gen AI の適合を検証し、制約を特定するための要件を収集します。
ソリューションアーキテクチャを設計します。エージェントシステムの設計パターンを参照してください

1. ビルド

データソースを準備し、必要なツールを作成します。
初期プロトタイプ (POC) をビルドして検証します。
実稼働前環境にデプロイします。

2. 評価と反復

ユーザーフィードバックを収集し、品質を測定する
評価に基づいてエージェントのロジックとツールを絞り込むことで、品質の問題を修正します。
エージェントシステムの品質を継続的に向上させるために、主題エキスパート (SME) の入力を組み込みます。

3. 生産

Gen AI アプリを運用環境にデプロイします。
パフォーマンスと品質を監視します。
実際の使用状況に基づいて保守と改善を行います。

このワークフローは反復的である必要があります。各デプロイまたは評価サイクルの後、前の手順に戻ってデータパイプラインを調整するか、エージェントロジックを更新します。たとえば、運用環境の監視によって新しい要件が明らかにされ、エージェントの設計と評価の別のラウンドの更新がトリガーされる場合があります。これらの手順を体系的に実行し、Databricks MLflow トレース、Agent Framework、およびエージェント評価機能を活用することで、ユーザーのニーズを確実に満たし、セキュリティとコンプライアンスの要件を尊重し、時間の経過と同時に改善を続ける高品質の Gen AI アプリを構築できます。

0. 前提条件

Gen AI アプリケーションの開発を開始する前に、要件の収集とソリューション設計という適切な作業に時間を要することがいかに重要であるかを過大に評価することはできません。

要件の収集には、次の手順が含まれます。

Gen AI がユースケースに適合するかどうかを検証します。
ユーザーエクスペリエンスを定義します。
データソースを調査します。
パフォーマンスの制約を設定します。
セキュリティ制約をキャプチャします。

ソリューションの設計には、次のものが含まれます。

データパイプラインをマップします。
必要なツールを特定します。
システムアーキテクチャ全体の概要を説明します。

この基礎を築くことで、後続のビルド、評価、運用の各ステージの明確な方向を設定します。

要件を収集する

明確で包括的なユースケース要件を定義することは、Gen AI アプリを成功させるために不可欠な最初のステップです。これらの要件は、次の目的に役立ちます。

これらは、Gen AI アプローチがユースケースに適しているかどうかを判断するのに役立ちます。
ソリューションの設計、実装、評価の決定をガイドします。

最初に時間を費やして詳細な要件を収集することで、開発プロセスの後半で大きな課題を回避し、結果として得られるソリューションがエンドユーザーと利害関係者のニーズを確実に満たすことができます。明確に定義された要件により、アプリケーションのライフサイクルの後続のステージの基礎が提供されます。

ユースケースは Gen AI に適していますか?

Gen AI ソリューションにコミットする前に、その固有の長所が要件と一致するかどうかを検討してください。生成型 AI ソリューションが適している例を次に示します。

コンテンツの生成: このタスクでは、静的テンプレートや単純なルールベースのロジックでは実現できない、新しいコンテンツやクリエイティブなコンテンツを生成する必要があります。
動的クエリ処理: ユーザークエリは、オープンエンドまたは複雑で、柔軟でコンテキストに対応した応答を要求します。
情報合成: ユースケースでは、さまざまな情報源を組み合わせたり要約したりすることで、一貫性のある出力が得られます。
エージェントシステム: アプリケーションでは、プロンプトに応答してテキストを生成するだけではありません。次の機能が必要になる場合があります。
- 計画と意思決定: 特定の目標を達成するためのマルチステップ戦略を策定する。
- アクションの実行: 外部プロセスをトリガーするか、さまざまなツールを呼び出してタスクを実行する (データの取得、API 呼び出しの実行、SQL クエリの実行、コードの実行など)。
- 状態の維持: 連続性を実現するために、複数の対話間で会話履歴またはタスクコンテキストを追跡します。
- アダプティブ出力の生成: 以前のアクション、更新された情報、または変化する条件に基づいて進化する応答を生成する。

逆に、次の状況では、Gen AI アプローチが理想的でない場合があります。

このタスクは非常に確定的であり、定義済みのテンプレートまたはルールベースのシステムを使用して効果的に解決できます。
必要な情報のセット全体は、既に静的であるか、単純な閉じたフレームワーク内に収まります。
非常に短い待機時間 (ミリ秒) の応答が必要であり、生成処理のオーバーヘッドに対応できません。
単純なテンプレート化された応答は、目的のユースケースに対して十分です。

重要

以下のセクションでは、ラベル P0、 P1、 および P2 ラベルを使用して、相対的な優先度を示します。

 [P0] 項目は重要または必須です。これらは直ちに対処する必要があります。
 [P1] 項目は重要ですが、 P0 要件の後に従うことができます。
⚪ [P2] 項目は、時間とリソースが許可する限り対処できる優先順位の低い考慮事項または拡張機能です。

これらのラベルを使用すると、チームは、すぐに注意が必要な要件と延期できる要件をすばやく確認できます。

ユーザーエクスペリエンス

ユーザーが Gen AI アプリと対話する方法と、期待される応答の種類を定義します。

 [P0] 一般的な要求: 一般的なユーザー要求の外観利害関係者から例を収集します。
 [P0] 予想される回答: システムが生成する必要がある応答の種類 (短い回答、長い形式の説明、創造的な物語など)。
 [P1] 相互作用のモダリティ: ユーザーがアプリケーションとどのように対話するか (チャットインターフェイス、検索バー、音声アシスタントなど)
 [P1] トーン、スタイル、構造: 生成された出力に採用する必要があるトーン、スタイル、構造 (正式、会話的、技術的、箇条書き、または連続散文)
 [P1]エラー処理: アプリケーションであいまいなクエリ、不完全なクエリ、またはターゲット外のクエリを処理する方法フィードバックを提供するか、説明を要求する必要がありますか?
⚪ [P2] 書式設定の要件: 出力 (メタデータや補足情報を含む) に関する特定の書式設定やプレゼンテーションのガイドラインはありますか?

データ

Gen AI アプリで使用されるデータの性質、ソース、品質を決定します。

[P0] データソース: 使用できるデータソースは何ですか?
- ソースごとに、以下を決定します。
  - データは構造化されているか、非構造化ですか?
  - ソース形式 (PDF、HTML、JSON、XML など) は何ですか?
  - データはどこにありますか?
  - 使用できるデータの量はどのくらいですか?
  - データにアクセスする方法
[P1] データの更新: データはどのくらいの頻度で更新されますか? 更新プログラムを処理するためのメカニズムは何ですか?
[P1] データ品質: 品質に関する既知の問題や不整合はありますか?
- データソースの品質監視が必要かどうかを検討します。

次のような情報を統合するために、インベントリテーブルを作成することを検討してください。

データソース	情報源	ファイルの種類	サイズ	更新頻度
データソース 1	Unity カタログボリューム	JSON（ジェイソン）	10 GB	毎日
データソース 2	パブリック API	XML	NA (API)	リアルタイム
データソース 3	SharePoint	PDF、.docx	500 MB	月間

パフォーマンスの制約

Gen AI アプリケーションのパフォーマンスとリソースの要件をキャプチャします。

待機時間

[P0] 最初のトークンまでの時間: 出力の最初のトークンを配信するまでに許容可能な最大遅延はどれくらいですか?
- 手記： 待機時間は通常、p50 (中央値) と p95 (95 パーセンタイル) を使用して、平均と最悪の場合の両方のパフォーマンスをキャプチャするために測定されます。
[P0] 完了までの時間: ユーザーにとって許容される (完了までの) 応答時間は何ですか?
[P0] ストリーミング待機時間: 応答がストリーミングされる場合、全体的な待機時間は長くなりますか?

スケーラビリティ

[P1]同時ユーザーと要求: システムでサポートする必要がある同時ユーザーまたは要求の数。
- 注: スケーラビリティは、多くの場合、QPS (1 秒あたりのクエリ数) または QPM (1 分あたりのクエリ数) で測定されます。
[P1] 使用パターン: 予想されるトラフィックパターン、ピーク時の負荷、または時間ベースの使用量の急増は何ですか?

コストの制約

[P0] 推論コストの制限事項: 推論コンピューティングリソースのコスト制約または予算の制限は何ですか?

評価

Gen AI アプリを時間の経過と共に評価および改善する方法を確立します。

[P0] ビジネス KPI: アプリケーションがどのビジネス目標または KPI に影響を与える必要がありますか? ベースライン値とターゲットを定義します。
[P0] 利害関係者からのフィードバック: アプリケーションのパフォーマンスと出力に関する初期および継続的なフィードバックを提供するユーザー特定のユーザーグループまたはドメインエキスパートを特定します。
[P0] 品質の測定: 生成された出力の品質を評価するために使用されるメトリック (精度、関連性、安全性、人間のスコアなど)
- これらのメトリックは開発中にどのように計算されますか (たとえば、合成データに対して、手動でキュレーションされたデータセットに対して)。
- 運用環境で品質を測定する方法 (たとえば、実際のユーザークエリに対する応答のログ記録と分析など)。
- エラーに対する全体的な許容度は何ですか? (たとえば、重大なユースケースでは、一定の割合の軽微な事実の不正確さを受け入れるか、100% に近い正確性が必要です)。
- 目的は、実際のユーザークエリ、合成データ、またはその両方の組み合わせから評価セットを構築することです。このセットは、システムの進化に伴ってパフォーマンスを評価する一貫した方法を提供します。
[P1] フィードバックループ: ユーザーフィードバックを収集し (たとえば、親指の上下、アンケートフォームなど)、反復的な改善を促進するために使用する方法
- フィードバックをレビューして組み込む頻度を計画します。

安全

セキュリティとプライバシーに関する考慮事項を特定します。

 [P0] データの機密性: 特別な処理を必要とする機密データ要素または機密データ要素はありますか?
 [P1] アクセス制御: 特定のデータや機能を制限するためにアクセス制御を実装する必要がありますか?
[P1] 脅威の評価と軽減策: アプリケーションは、プロンプトインジェクションや悪意のあるユーザー入力など、一般的な GEN AI の脅威から保護する必要がありますか?

デプロイメント

Gen AI ソリューションの統合、デプロイ、監視、保守の方法について説明します。

[P1] 統合: Gen AI ソリューションは、既存のシステムやワークフローとどのように統合する必要がありますか?
- 統合ポイント (Slack、CRM、BI ツールなど) と必要なデータコネクタを特定します。
- Gen AI アプリとダウンストリームシステム (REST API、Webhook など) の間で要求と応答がどのように流れるかを決定します。
[P1] デプロイ: アプリケーションをデプロイ、スケーリング、およびバージョン管理するための要件は何ですか? この記事では、MLflow、Unity カタログ、エージェントフレームワーク、エージェント評価、およびモデルサービスを使用して、Databricks でエンドツーエンドのライフサイクルを処理する方法について説明します。
[P1] 運用環境の監視と可観測性: 運用環境でアプリケーションをどのように監視しますか？
- ログとトレース: 完全な実行トレースをキャプチャします。
- 品質メトリック: ライブトラフィックの主要なメトリック (正確性、待機時間、関連性など) を継続的に評価します。
- アラートとダッシュボード: 重大な問題のアラートを設定します。
- フィードバックループ: 問題を早期にキャッチし、反復的な改善を推進するため、運用環境にユーザーフィードバック (賛成と不賛成) を組み込みます。

例

たとえば、Databricks カスタマーサポートチームが使用する架空のエージェント RAG アプリケーションに、これらの考慮事項と要件がどのように適用されるかを考えてみましょう。

面積	考慮事項	要求事項
ユーザーエクスペリエンス	相互作用のモダリティ。一般的なユーザークエリの例。予想される応答の形式とスタイル。あいまいなクエリまたは無関係なクエリの処理。	Slack と統合されたチャットインターフェイス。クエリの例: "クラスターの起動時間を短縮するにはどうすればよいですか?「どのようなサポートプランがありますか? 必要に応じて、コードスニペットと関連ドキュメントへのリンクを含む技術的な回答を明確にします。状況に応じた提案を提供し、必要に応じてサポートエンジニアにエスカレートします。
エージェントロジック	クエリの理解と分類。マルチステップの計画と意思決定。自律的なツールの選択と実行。相互作用全体の状態とコンテキストの管理。エラー処理とフォールバックメカニズム。	決定論的フォールバックを使用した LLM を利用した計画。一連の定義済みツール (ドキュメント取得や Salesforce 取得ツールなど) と統合します。会話の状態を保持することで、複数ターンにわたるやり取りを一貫性のあるものにし、堅牢なエラー回復を実現します。
データ	データソースの数と種類。データの形式と場所。データサイズと更新頻度。データの品質と一貫性。	4 つのデータソース。会社のドキュメント (HTML、PDF)。解決されたサポートチケット (JSON)。コミュニティフォーラムの投稿 (デルタテーブル)。 Salesforce コネクタ。 Unity カタログに格納され、毎週更新されるデータ。合計データサイズ: 5 GB。専用のドキュメントとサポートチームによって維持される一貫したデータ構造と品質。
[パフォーマンス]	許容される最大待機時間。コストの制約。予想される使用量とコンカレンシー。	最大待機時間の要件。コストの制約。ピーク時の負荷が予想されます。
評価	評価データセットの可用性。品質メトリック。ユーザーフィードバックの収集。	各製品領域の主題の専門家は、出力を確認し、正しくない回答を調整して評価データセットを作成するのに役立ちます。ビジネス KPI。サポートチケット解決率の増加。サポートチケットあたりのユーザー時間の短縮。品質メトリック。 LLM が判断した回答の正確性と関連性。 LLM ジャッジの取得精度。ユーザーの賛成または反対投票。フィードバックの収集。 Slack には賛成と不賛成を示す機能を実装します。
安全	機密データの処理。アクセス制御の要件。	顧客の機密データを取得ソースに含める必要はありません。 Databricks Community SSO によるユーザー認証。
デプロイメント	既存のシステムとの統合。デプロイとバージョン管理。	サポートチケットシステムとの統合。 Databricks Model Serving エンドポイントとしてデプロイされたエージェント。

ソリューション設計

設計に関するその他の考慮事項については、「エージェントシステムの設計パターン」を参照してください。

データソースとツール

Gen AI アプリを設計するときは、ソリューションを推進するために必要なさまざまなデータソースとツールを特定してマップすることが重要です。これには、構造化データセット、非構造化データ処理パイプライン、または外部 API のクエリが含まれる場合があります。 Gen AI アプリにさまざまなデータソースまたはツールを組み込む場合に推奨される方法を次に示します。

構造化データ

構造化データは通常、明確に定義された表形式 (Delta テーブルや CSV ファイルなど) に存在し、クエリが事前に定義されているか、ユーザー入力に基づいて動的に生成する必要があるタスクに最適です。構造化データを Gen AI アプリに追加するための推奨事項については、構造化情報検索AIエージェントツールを参照してください。

非構造化データ

非構造化データには、未加工のドキュメント、PDF、電子メール、画像、固定スキーマに準拠していないその他の形式が含まれます。このようなデータは、通常、解析、チャンク、埋め込みの組み合わせを使用して追加の処理を行い、Gen AI アプリで効果的にクエリを実行して使用する必要があります。 Gen AI アプリへの構造化データの追加に関する推奨事項については、非構造化データのビルドおよびトレース取得ツールを参照してください。

外部 API とアクション

一部のシナリオでは、Gen AI アプリが外部システムと対話してデータを取得したり、アクションを実行したりする必要がある場合があります。アプリケーションでツールの呼び出しや外部 API の操作が必要な場合は、次のことをお勧めします。

Unity カタログ接続を使用して API 資格情報を管理する:Unity カタログ接続を使用して、API 資格情報を安全に管理します。このメソッドにより、トークンとシークレットが一元的に管理され、アクセスが制御されます。
Databricks SDK を使用して呼び出します。
http_request ライブラリのdatabricks-sdk関数を使用して、外部サービスに HTTP 要求を送信します。この関数は、認証に Unity カタログ接続を利用し、標準の HTTP メソッドをサポートします。
Unity カタログ関数を活用する:
Unity カタログ関数で外部接続をラップして、カスタムの前処理ロジックまたは後処理ロジックを追加します。
Python Executor ツール:
Python 関数を使用してデータ変換または API 操作のコードを動的に実行するには、組み込みの Python Executor ツールを使用します。

例:

内部分析アプリケーションは、外部の金融 API からライブマーケットデータを取得します。アプリケーションでは次のものが使用されます。

API 資格情報を安全に格納するための Unity カタログ外部接続。
カスタム Unity カタログ関数は、API 呼び出しをラップして、前処理 (データ正規化など) と後処理 (エラー処理など) を追加します。
さらに、アプリケーションは Databricks SDK を介して API を直接呼び出すことができます。

実装手法

Gen AI アプリを開発するときは、エージェントのロジックを実装するための 2 つの主なオプションがあります。オープンソースフレームワークを利用するか、Python コードを使用してカスタムソリューションを構築します。各アプローチの長所と短所の内訳を次に示します。

フレームワーク (LangChain、LlamaIndex、CrewAI、AutoGen など) の使用

長所:

すぐに使用するコンポーネント: フレームワークには、迅速な管理、呼び出しのチェーン、さまざまなデータソースとの統合のための既製のツールが付属しているため、開発を高速化できます。
コミュニティとドキュメント: コミュニティのサポート、チュートリアル、定期的な更新プログラムを利用できます。
一般的な設計パターン: フレームワークは通常、一般的なタスクを調整するための明確なモジュール構造を提供し、エージェントの全体的な設計を簡略化できます。

短所：

抽象化を追加しました。 オープンソースフレームワークでは、多くの場合、特定のユースケースでは不要な抽象化レイヤーが導入されます。
更新プログラムへの依存関係: バグ修正と機能更新プログラムのフレームワーク保守担当者に依存している可能性があります。この場合、新しい要件に迅速に適応する能力が低下する可能性があります。
潜在的なオーバーヘッド: アプリケーションできめ細かい制御が必要な場合は、追加の抽象化によってカスタマイズの課題が発生する可能性があります。

純粋な Python の使用

長所:

柔軟性： 純粋な Python で開発すると、フレームワークの設計上の決定に制約されることなく、ニーズに合わせて実装を正確に調整できます。
クイック適応: 外部フレームワークからの更新を待たずに、コードをすばやく調整し、必要に応じて変更を組み込むことができます。
簡略： 不要な抽象化レイヤーを避けてください。不要な抽象化は、より無駄のない、よりパフォーマンスの高いソリューションにつながる可能性があります。

短所：

開発作業の増加: ゼロから構築するには、専用フレームワークが提供する可能性のある機能を実装するために、より多くの時間と専門知識が必要になる場合があります。
ホイールの再発明: 一般的な機能 (ツールチェーンやプロンプト管理など) を独自に開発する必要がある場合があります。
メンテナンスの責任: すべての更新プログラムとバグ修正はユーザーの責任となり、複雑なシステムでは困難な場合があります。

最終的には、プロジェクトの複雑さ、パフォーマンスのニーズ、必要な制御レベルに基づく決定を行う必要があります。どちらのアプローチも本質的に優れたアプローチではありません。開発の好みや戦略的な優先順位に応じて、それぞれ異なる利点が提供されます。

1. ビルド

このステージでは、ソリューション設計を、実際の Gen AI アプリケーションに変換します。すべてを事前に完成させるのではなく、簡単にテストできる最小限の概念実証 (POC) で小規模から始めます。これにより、できるだけ早く実稼働前環境にデプロイし、実際のユーザーまたは中小企業から代表的なクエリを収集し、実際のフィードバックに基づいて調整することができます。

準備、ビルド、デプロイの手順を示すフローチャート。

ビルドプロセスは、次の主要な手順に従います。

a． データとツールを準備する: 必要なデータにアクセスでき、解析され、取得の準備ができていることを確認します。エージェントが必要とする Unity カタログの関数と接続 (取得 API や外部 API 呼び出しなど) を実装または登録します。 b。 ビルドエージェント: 単純な POC アプローチから始めて、コアロジックを調整します。 c. 品質チェック: より多くのユーザーにアプリを公開する前に、重要な機能を検証します。 d. 実稼働前エージェントをデプロイします。 POC を使用して、最初のフィードバックのためにユーザーと主題の専門家をテストできるようにします。 e. ユーザーフィードバックを収集する: 実際の使用状況を使用して、改善領域、必要な追加のデータまたはツール、および次のイテレーションの潜在的な絞り込みを特定します。

a．データの準備とツール

ソリューションの設計フェーズから、アプリに必要なデータソースとツールの最初のアイデアが得られます。この段階では、最小限に抑え、POC を検証するのに十分なデータだけに焦点を当てます。これにより、複雑なパイプラインに大量の先行投資を行うことなく、迅速な反復が可能になります。

データ

データの代表的なサブセットを特定する
- 構造化データの場合は、最初のシナリオに最も関連するキーテーブルまたは列を選択します。
- 非構造化データの場合は、代表的なドキュメントのサブセットのみにインデックス作成の優先順位を付けます。必要に応じてエージェントが関連するテキストチャンクを取得できるように、モザイク AI ベクター検索で基本的なチャンク/埋め込みパイプラインを使用します。
データアクセスを設定する
- アプリで外部 API 呼び出しを行う必要がある場合は、 Unity カタログ接続を使用して資格情報を安全に格納します。
基本カバレッジを検証する
- 選択したデータサブセットが、テストする予定のユーザークエリに適切に対応していることを確認します。
- 今後の反復のために、追加のデータソースまたは複雑な変換を保存します。現在の目標は、基本的な実現可能性を証明し、フィードバックを収集することです。

ツール

データソースを設定したら、次の手順は、エージェントが実行時に Unity カタログに呼び出すツールを実装して登録することです。ツールは、SQL クエリや外部 API 呼び出しなどの 単一対話関数であり、エージェントが取得、変換、またはアクションのために呼び出すことができます。

データ取得ツール

制約付き構造化データクエリ: クエリが修正された場合は、それらを Unity カタログ SQL 関数または Python UDF でラップします。これにより、ロジックが一元化され、検出可能な状態が維持されます。
オープンエンドの構造化データクエリ: クエリがよりオープンエンドの場合は、テキストから SQL へのクエリを処理する Genie 領域を設定することを検討してください。
非構造化データヘルパー関数: Mosaic AI Vector Search に格納されている非構造化データの場合は、エージェントが呼び出して関連するテキストチャンクをフェッチできる非構造化データ取得ツールを作成します。

API 呼び出しツール

外部 API 呼び出し:API 呼び出しは、 Databricks SDK の http_request メソッドを使用して直接呼び出すことができます。
省略可能なラッパー: 前処理または後処理ロジック (データ正規化やエラー処理など) を実装する必要がある場合は、 UNITY カタログ関数で API 呼び出しをラップします。

最小限に抑えておく

基本的なツールからのみ開始します。 単一の取得パスまたは限られた API 呼び出しのセットに焦点を当てます。反復処理を行う際に、さらに追加できます。
対話形式で検証する: エージェントシステムに組み込む前に、各ツールを (ノートブック内など) 個別にテストします。

プロトタイプツールの準備ができたら、エージェントのビルドに進みます。エージェントは、これらのツールを調整してクエリに応答し、データをフェッチし、必要に応じてアクションを実行します。

b。ビルドエージェント

データとツールが配置されたら、ユーザークエリなどの受信要求に応答するエージェントを構築できます。初期プロトタイプエージェントを作成するには、 Python または AI プレイグラウンドを使用します。次の手順に従います。

単純な開始
- 基本的な設計パターンを選択します。 POC の場合は、基本チェーン (一連の固定ステップなど) または単一のツール呼び出しエージェント (LLM が 1 つまたは 2 つの重要なツールを動的に呼び出すことができる) から始めます。
  - シナリオが Databricks のドキュメントで提供されているサンプルノートブックの 1 つと一致する場合は、そのコードをスケルトンとして調整します。
- 最小限のプロンプト: 現時点では、プロンプトを複雑にしすぎないよう心がけてください。指示を簡潔にし、最初のタスクに直接関連させます。
ツールの組み込み
- ツールの統合: チェーン設計パターンを使用している場合、各ツールを呼び出す手順はハードコーディングされます。ツール呼び出しエージェントでは、LLM が関数を呼び出す方法を認識できるようにスキーマを指定します。
  - エージェントシステムに組み込んでエンドツーエンドでテストする前に、分離されたツールが期待どおりに実行されていることを検証します。
- ガードレール： エージェントが外部システムを変更したりコードを実行したりできる場合は、基本的な安全性チェックとガードレール (呼び出しの数の制限や特定のアクションの制限など) があることを確認します。これらを Unity カタログ関数内に実装します。
MLflow を使用してエージェントをトレースしてログに記録する
- 各ステップをトレースします。MLflow トレースを使用して、ステップごとの入力、出力、経過時間をキャプチャし、問題をデバッグし、パフォーマンスを測定します。
- エージェントをログに記録します。MLflow Tracking を使用して、エージェントのコードと構成をログに記録します。

この段階では、 完璧は目標ではありません。テストユーザーや SMI からの早期フィードバックのためにデプロイできる、シンプルで機能するエージェントが必要です。次の手順では、実稼働前環境で使用できるようにする前に、迅速な品質チェックを実行します。

c. 品質チェック

より広範な実稼働前の対象ユーザーにエージェントを公開する前に、オフラインの "十分な" 品質チェックを実行して、エンドポイントにデプロイする前に主要な問題をキャッチします。この段階では、通常、大規模で堅牢な評価データセットはありませんが、少数のサンプルクエリでエージェントが意図したとおりに動作するように、引き続きクイックパスを実行できます。

ノートブックで対話形式でテストする
- 手動検査: 代表的な要求を使用してエージェントを手動で呼び出します。適切なデータを取得し、ツールを正しく呼び出し、目的の形式に従うかどうかに注意してください。
- MLflow トレースを検査します。 MLflow トレースを有効にしている場合は、詳細なテレメトリを確認します。エージェントが適切なツールを選択し、エラーを適切に処理し、予期しない中間要求または結果が生成されないことを確認します。
- 待機時間を確認します。 各要求の実行にかかる時間に注意してください。応答時間やトークンの使用量が多すぎる場合は、先に進む前に手順を排除したり、ロジックを簡略化したりする必要があります。
Vibe check
- これは、ノートブックまたは AI Playground で実行できます。
- 一貫性と正確性: エージェントの出力は、テストしたクエリに対して意味がありますか? 剹匿性の間違いや詳細の欠落はありますか?
- エッジケース: 少し変わったクエリをいくつか試した場合でも、エージェントは論理的に応答したか、あるいは少なくとも、意味不明な出力をせず、丁寧に回答を控えるといった適切なエラー処理を行ったか。
- プロンプトの準拠: 必要なトーンや書式設定などの高度な手順を指定した場合、エージェントはこれらに従っていますか?
"十分な" 品質を評価する
- この時点でテストクエリが制限されている場合は、合成データの生成を検討してください。評価セットの作成を参照してください。
- 主な問題に対処する: 大きな欠陥が見つかった場合 (たとえば、エージェントが無効なツールを繰り返し呼び出したり、ナンセンスを出力したりする場合など)、これらの問題を修正してから、より多くのユーザーに公開してください。品質に関する一般的な問題とその解決方法を参照してください。
- 実行可能性を決定します。 エージェントが少数のクエリの使いやすさと正確性の基本的なバーを満たしている場合は、続行できます。そうでない場合は、プロンプトを絞り込み、ツールまたはデータの問題を修正して、再テストします。
次の手順を計画する
- 改善点を追跡する: 延期することに決めた欠点を文書化します。実稼働前に実際のフィードバックを収集したら、これらを見直すことができます。

限られたロールアウトに対してすべてが実行可能な場合は、エージェントを実稼働前にデプロイする準備が整います。完全な評価プロセスは、特に実際のデータ、SME フィードバック、構造化された評価セットを取得した後に、後のフェーズで行われます。ここでは、エージェントのコア機能を確実に実証することに重点を置きます。

d. プレプロダクションエージェントを展開する

エージェントがベースライン品質しきい値を満たした後、次の手順では、ユーザーがアプリに対してクエリを実行し、フィードバックを収集して開発をガイドする方法を理解できるように、実稼働前環境でホストします。この環境は、POC フェーズ中に開発環境にすることができます。主な要件は、環境にアクセスして内部テスト担当者またはドメインエキスパートを選択できるようにすることです。

エージェントをデプロイする
- エージェントをログに記録して登録します。 まず、エージェントを MLflow モデルとしてログに記録し、Unity カタログに登録します。
- Agent Framework を使用してデプロイする: Agent Framework を使用して登録済みのエージェントを取得し、モデルサービスエンドポイントとしてデプロイします。
推論テーブル
- Agent Framework は、要求、応答、トレースと共にメタデータを Unity カタログの推論テーブルに、サービスエンドポイントごとに自動的に格納します。
セキュリティ保護と構成
- アクセス制御:テストグループ (SMI、パワーユーザー) へのエンドポイントアクセスを制限します。これにより、制御された使用が保証され、予期しないデータの公開が回避されます。
- 認証: 必要なシークレット、API トークン、またはデータベース接続が正しく構成されていることを確認します。

これで、実際のクエリに関するフィードバックを収集するための制御された環境が作成されました。エージェントを迅速に操作する方法の 1 つは、AI Playground で、新しく作成された Model Serving エンドポイントを選択し、エージェントにクエリを実行できます。

e. ユーザーフィードバックを収集する

実稼働前環境にエージェントをデプロイした後、次の手順は、実際のユーザーと中小企業からのフィードバックを収集して、ギャップを明らかにし、不正確さを特定し、エージェントをさらに改良することです。

レビューアプリを使用する
- Agent Framework を使用してエージェントをデプロイすると、単純なチャットスタイルのレビューアプリが作成されます。これは、テスターが質問を投げ、エージェントの応答をすぐに評価できるユーザーフレンドリーなインターフェイスを提供します。
- すべての要求、応答、ユーザーフィードバック (サムアップ/ダウン、コメントの書き込み) は推論テーブルに自動的に記録されるため、後で簡単に分析できます。
監視 UI を使用してログを検査する
- 監視 UI で賛成票/反対票やテキストによるフィードバックを追跡して、テスト担当者が特に役立つ（または役立たない）と見なした応答を確認します。
ドメインの専門家を引き付け
- 一般的で異常なシナリオを実行するよう中小企業に勧めます。ドメインの知識は、ポリシーの解釈ミスやデータの欠落など、微妙なエラーを表面化するのに役立ちます。
- 小さなプロンプト調整から大規模なデータパイプラインのリファクタリングまで、問題のバックログを保持します。次に進む前に、優先順位を付ける修正プログラムを決定します。
新しい評価データをキュレーションする
- 注目すべき操作または問題のある相互作用をテストケースに変換します。時間の経過とともに、これらはより堅牢な評価データセットの基礎となります。
- 可能であれば、これらのケースに正しい回答または予想される回答を追加します。これは、後続の評価サイクルで品質を測定するのに役立ちます。
フィードバックに基づいて反復処理する
- 小さなプロンプトの変更や新しいガードレールなどの迅速な修正を適用して、すぐに問題に対処します。
- 高度なマルチステップロジックや新しいデータソースの要求など、より複雑な問題の場合は、アーキテクチャの大きな変更に投資する前に十分な証拠を収集してください。

この実稼働前フェーズでは、レビューアプリ、推論テーブルログ、SME 分析情報からのフィードバックを活用することで、主要なギャップを解消し、エージェントを繰り返し調整できます。この手順で収集された実際の相互作用により、構造化された評価セットを構築するための基盤が作成され、アドホックな改善から、より体系的なアプローチから品質測定に移行できます。繰り返し発生する問題に対処し、パフォーマンスが安定したら、堅牢な評価を実施した運用環境のデプロイに向けて十分な準備が整います。

2. 評価と反復

Gen AI アプリが実稼働前環境でテストされた後、次の手順は、その品質を体系的に測定、診断、および調整することです。この "評価と反復" フェーズでは、生のフィードバックとログを構造化された評価セットに変換し、改善点を繰り返しテストし、アプリが精度、関連性、安全性に必要な標準を満たしていることを確認できます。

このフェーズには、次の手順が含まれます。

ログから実際のクエリを収集します。 高価値または問題のある相互作用を推論テーブルからテストケースに変換します。
エキスパートラベルを追加する: 可能であれば、これらのケースに基準データやスタイル・ポリシーのガイドラインを添付し、正確性や根拠性、その他の品質面をより客観的に測定できるようにします。
エージェント評価の活用:組み込みの LLM ジャッジまたはカスタムチェックを使用して、アプリの品質を定量化します。
反復処理： エージェントのロジック、データパイプライン、またはプロンプトを調整して、品質を向上させます。評価を再実行して、主要な問題を解決したかどうかを確認します。

これらの機能は、Gen AI アプリが Databricks の外部で実行されている場合でも機能します。 MLflow トレースを使用してコードをインストルメント化することで、任意の環境からトレースをキャプチャし、Databricks Data Intelligence Platform で統合して、一貫した評価と監視を行うことができます。新しいクエリ、フィードバック、SME 分析情報を組み込み続けるにつれて、評価データセットは継続的な改善サイクルを支える生きたリソースになり、Gen AI アプリは堅牢で信頼性が高く、ビジネス目標に沿った状態が維持されます。

準備、ビルド、デプロイ、および修正の手順を示すフローチャート。

a. エージェントを評価する

エージェントが運用前環境で稼働し始めたら、次の手順は、場当たり的な感覚チェックにとどまらず、そのパフォーマンスを体系的に測定することです。 Mosaic AI Agent Evaluation を使用すると、評価セットの作成、組み込みまたはカスタム LLM ジャッジによる品質チェックの実行、問題領域に対する迅速な反復が可能になります。

オフラインとオンライン評価

Gen AI アプリケーションを評価する場合、オフライン評価とオンライン評価の 2 つの主要なアプローチがあります。開発サイクルのこのフェーズでは、オフライン評価に重点を置いています。これは、ライブユーザー操作以外の体系的な評価を指します。オンライン評価は、運用環境でのエージェントの監視について後で説明する際に説明します。

多くの場合、チームは開発者ワークフローで長すぎる "バイブテスト" に大きく依存し、非公式に少数のクエリを試し、応答が妥当と思われるかどうかを主観的に判断します。これは出発点となりますが、運用品質のアプリケーションを構築するために必要な厳しさとカバレッジがありません。

これに対し、適切なオフライン評価プロセスでは、次の処理が行われます。

より広範なデプロイの前に品質ベースラインを確立し、改善を目標とする明確なメトリックを作成します。
注意が必要な特定の弱点を特定し、想定されるユースケースのみをテストする制限を超えて移動します。
バージョン間でパフォーマンスを自動的に比較することで、アプリを絞り込む際に品質の回帰を検出します。
利害関係者の改善を示す定量的メトリックを提供します。
ユーザーが実行する前に、エッジケースと潜在的な障害モードを検出するのに役立ちます。
パフォーマンスの低いエージェントを運用環境にデプロイするリスクを軽減します。

オフライン評価に時間を費やした場合、長期的には大きな配当が得られます。これは、一貫して高品質の応答を提供するためのドライブを支援します。

評価セットを作成する

評価セットは、Gen AI アプリのパフォーマンスを測定するための基礎として機能します。従来のソフトウェア開発のテストスイートと同様に、この代表的なクエリと予想される応答のコレクションが、品質ベンチマークと回帰テストデータセットになります。

評価セットを使用した準備、ビルド、デプロイ、修正の手順を示すフローチャート。

いくつかの補完的なアプローチを使用して、評価セットを構築できます。

推論テーブルのログを評価例に変換する

最も価値のある評価データは、実際の使用状況から直接取得されます。実稼働前デプロイでは、要求、エージェントの応答、ツール呼び出し、および取得されたコンテキストを含む推論テーブルログが生成されています。

これらのログを評価セットに変換すると、いくつかの利点があります。
- 実際の範囲: 予期しなかったユーザーの行動も含まれています。
- 問題に重点を置いた: 具体的には、否定的なフィードバックや遅い応答をフィルター処理できます。
- 代表的な配布: さまざまなクエリの種類の実際の頻度がキャプチャされます。
合成評価データを生成する

キュレーションされたユーザークエリのセットがない場合は、合成評価データセットを自動生成できます。このクエリの "スターターセット" は、エージェントが次の操作を行うかどうかを迅速に評価するのに役立ちます。
- 一貫性のある正確な回答を返します。
- 正しい形式で応答します。
- 構造、調性、およびポリシーガイドラインを尊重します。
- コンテキストを正しく取得します (RAG の場合)。
合成データは通常、完璧ではありません。一時的な足掛かりと考えてください。次のことも検討できます。
- 中小企業やドメインの専門家に、無関係なクエリや反復的なクエリをレビューして排除させます。
- 後で実際の使用状況ログに置き換えるか、拡張します。
クエリを手動でキュレーションする

合成データに依存しない場合、または推論ログがまだない場合は、10 ~ 15 個の実際のクエリまたは代表的なクエリを特定し、そこから評価セットを作成します。代表的なクエリは、ユーザーのインタビューや開発者のブレーンストーミングから発生する可能性があります。短く精選されたリストでも、エージェントの応答に明らかな欠陥が見つかる可能性があります。

これらのアプローチは相互に排他的ではなく、補完的です。 効果的な評価セットは時間の経過とともに進化し、通常は次のような複数のソースの例を組み合わせます。

手動でキュレーションされた例から始めて、コア機能をテストします。
必要に応じて、実際のユーザーデータを取得する前に、合成データを追加して対象範囲を広げることができます。
実際のログが使用可能になったら、徐々に組み込みます。
変化する使用パターンを反映する新しい例で継続的に更新します。

評価クエリのベストプラクティス

評価セットを作成するときは、次のようなさまざまなクエリの種類を意図的に含めます。

予想される使用パターンと予期しない使用パターンの両方 (非常に長い要求や短い要求など)。
誤用の可能性がある攻撃や、インジェクション攻撃を促す攻撃 (システムプロンプトを明らかにしようとする試みなど)。
複数の推論手順またはツール呼び出しを必要とする複雑なクエリ。
最小限またはあいまいな情報を含むエッジケース (スペルミスやあいまいなクエリなど)。
さまざまなユーザースキルレベルと背景を表す例。
応答の潜在的な偏りをテストするクエリ ("会社 A と会社 B の比較" など)。

評価セットは、アプリケーションと共に拡張および進化する必要があります。新しい障害モードやユーザーの動作を明らかにするときは、代表的な例を追加して、エージェントがそれらの領域で改善を続けられるようにします。

評価基準を追加する

各評価例には、品質を評価するための基準が必要です。これらの基準は、エージェントの応答を測定する基準として機能し、複数の品質ディメンションにわたって客観的な評価を可能にします。

実証済みの正確なデータまたは参考程度の回答

事実の正確性を評価する場合、2 つの主なアプローチがあります。予想される事実と参照の回答です。評価戦略では、それぞれ異なる目的を果たします。

予想される事実を使用する (推奨)

expected_factsアプローチには、正しい応答に表示する必要がある重要な事実を一覧表示する必要があります。例については、「request、response、guidelines、およびexpected_factsを使用したサンプル評価セット」を参照してください。

この方法には、次のような大きな利点があります。

応答でのファクトの表現方法を柔軟に設定できます。
領域の専門家が正確なデータを提供しやすくします。
コア情報が存在することを確認しながら、さまざまな応答スタイルに対応します。
モデルのバージョンまたはパラメーター設定全体で、より信頼性の高い評価を可能にします。

組み込みの正確性の判断は、言い回し、順序付け、追加コンテンツに関係なく、エージェントの応答にこれらの重要な事実が組み込まれているかどうかを確認します。

期待される応答を使用する (代替)

または、完全なリファレンス回答を提供することもできます。この方法は、次の状況で最適に機能します。

エキスパートによって作成されたゴールドスタンダードの回答があります。
応答の正確な文言または構造が重要です。
高度に規制されたコンテキストで応答を評価しています。

Databricks では一般に、expected_factsよりもexpected_responseを使用することをお勧めします。これは、精度を確保しながら柔軟性を高めるからです。

スタイル、トーン、またはポリシーコンプライアンスのガイドライン

実際の精度を超えて、応答が特定のスタイル、トーン、またはポリシーの要件に準拠しているかどうかを評価する必要がある場合があります。

ガイドラインのみ

主な懸念事項が、事実の正確さではなく、スタイルまたはポリシーの要件を適用する場合は、予想される事実なしでガイドラインを提供できます。

# Per-query guidelines
eval_row = {
    "request": "How do I delete my account?",
    "guidelines": {
        "tone": ["The response must be supportive and non-judgmental"],
        "structure": ["Present steps chronologically", "Use numbered lists"]
    }
}

# Global guidelines (applied to all examples)
evaluator_config = {
    "databricks-agent": {
        "global_guidelines": {
            "rudeness": ["The response must not be rude."],
            "no_pii": ["The response must not include any PII information (personally identifiable information)."]
        }
    }
}

LLMの判事は、これらの自然言語命令を解釈し、応答がそれらに準拠しているかどうかを評価するガイドライン。これは、トーン、書式設定、組織ポリシーへの準拠などの主観的な品質ディメンションに特に適しています。

スタイルとトーンのジャッジを示す LLM ジャッジ UI。

地上の真理とガイドラインの組み合わせ

包括的な評価のために、ファクト精度チェックとスタイルガイドラインを組み合わせることができます。 request、response、guidelines、およびexpected_factsを使用したサンプル評価セットを参照してください。このアプローチにより、応答が事実に基づいて正確になり、組織の通信標準に準拠することが保証されます。

事前にキャプチャされた応答を使用する

開発またはテストから要求と応答のペアを既にキャプチャしている場合は、エージェントを再び取り込まずに、それらを直接評価できます。これは次の場合に役立ちます。

エージェントの動作における既存のパターンの分析。
以前のバージョンに対するパフォーマンスのベンチマーク。
応答を再生成しないことで、時間とコストを節約します。
Databricks の外部で提供されるエージェントの評価。

評価データフレームに関連する列を指定する方法の詳細については、「例: 以前に生成された出力をエージェント評価に渡す方法」を参照してください。モザイク AI エージェント評価では、エージェントを再度呼び出す代わりに、これらの事前にキャプチャされた値を使用しますが、同じ品質チェックとメトリックを適用します。

評価基準のベストプラクティス

評価基準を定義する場合:

具体的で目的を持つ: 異なるエバリュエーターが同様に解釈する明確で測定可能な条件を定義します。
- カスタムメトリックを追加して、気になる品質基準を測定することを検討してください。
ユーザー値に重点を置く: ユーザーにとって最も重要な条件に合わせて優先順位を付けます。
単純なスタート: 主要な基準セットから始め、品質ニーズの理解が深まるにつれて拡大します。
バランスカバレッジ: 品質のさまざまな側面 (事実の正確性、スタイル、安全性など) に対応する基準を含めます。
フィードバックに基づいて反復処理します。 ユーザーのフィードバックと進化する要件に基づいて条件を調整します。

高品質の評価データセットの構築の詳細については、評価セットを開発するためのベストプラクティスを参照してください。

評価を実行する

クエリと条件を使用して評価セットを準備したので、 mlflow.evaluate()を使用して評価を実行できます。この関数は、エージェントの呼び出しから結果の分析まで、評価プロセス全体を処理します。

基本的な評価ワークフロー

基本的な評価を実行するには、わずか数行のコードが必要です。詳細については、「評価の実行」を参照してください。

評価がトリガーされる場合:

評価セットの各行に対して、 mlflow.evaluate() は次の処理を行います。
- クエリを使用してエージェントを呼び出します (まだ応答を提供していない場合)。
- 組み込みの LLM ジャッジを適用して、品質ディメンションを評価します。
- トークンの使用状況や待機時間などの運用メトリックを計算します。
- 各評価の詳細な根拠を記録します。
結果は MLflow に自動的に記録され、以下が作成されます。
- 行ごとの品質評価。
- すべての例で集計されたメトリック。
- デバッグと分析の詳細なログ。

ジャッジ評価を示す LLM ジャッジ UI。

評価のカスタマイズ

追加のパラメーターを使用して、特定のニーズに合わせて評価を調整できます。 evaluator_config パラメーターを使用すると、次の操作を実行できます。

実行する組み込みのジャッジを選択します。
すべての例に適用されるグローバルガイドラインを設定します。
ジャッジのしきい値を構成します。
ジャッジの評価を導くいくつかのショットの例を提供します。

詳細と例については、「例」を参照してください。

Databricks の外部でエージェントを評価する

エージェント評価の強力な機能の 1 つは、Databricks だけでなく、どこからでもデプロイされた Gen AI アプリを評価できることです。

どのジャッジが適用されるか

既定では、エージェント評価では、評価セットで使用可能なデータに基づいて適切な LLM ジャッジが自動的に選択されます。品質の評価方法の詳細については、 LLM 審査官による品質の評価方法に関するページを参照してください。

評価結果の分析

評価を実行した後、MLflow UI は、アプリのパフォーマンスを理解するための視覚化と分析情報を提供します。この分析は、パターンの特定、問題の診断、改善の優先順位付けに役立ちます。

評価結果を確認する

mlflow.evaluate(),実行した後で MLflow UI を開くと、相互接続されたビューがいくつか見つかります。 MLflow UI でこれらの結果を移動する方法については、「 MLflow UI を使用して出力を確認する」を参照してください。

障害パターンを解釈する方法のガイダンスについては、 b. エージェントとツールの改善を参照してください。

カスタム AI のジャッジとメトリック

組み込みのジャッジは多くの一般的なチェック (正確性、スタイル、ポリシー、安全性など) をカバーしていますが、アプリのパフォーマンスのドメイン固有の側面を評価することが必要な場合があります。カスタムのジャッジとメトリックを使用すると、独自の品質要件に対応するために評価機能を拡張できます。

カスタム LLM ジャッジ

プロンプトからカスタム LLM ジャッジを作成する方法の詳細については、「プロンプトから AI ジャッジを作成する」を参照してください。

カスタムジャッジは、次のような人間のような判断の恩恵を受ける主観的または微妙な品質ディメンションを評価することに優れています。

ドメイン固有のコンプライアンス (法的、医療、財務)。
ブランドの音声とコミュニケーションのスタイル。
文化的な感受性と適切さ。
複雑な推論品質。
特殊な記述規則。

ジャッジの出力は、MLflow UI に組み込みのジャッジと共に表示され、評価を説明するのと同じ詳細な根拠があります。

カスタムメトリック

プログラムによる決定論的な評価を行う場合は、 @metric デコレーターを使用してカスタムメトリックを作成できます。 @metric デコレーター参照してください。

カスタムメトリックは、次の場合に最適です。

形式の検証やスキーマのコンプライアンスなどの技術的な要件の検証。
特定のコンテンツの有無を確認する。
応答の長さや複雑さのスコアなどの定量的な測定を実行します。
ビジネス固有の検証規則の実装。
外部検証システムとの統合。

b. エージェントとツールを改善する

評価を実行し、品質の問題を特定した後、次の手順は、パフォーマンスを向上させるためにこれらの問題に体系的に対処することです。評価結果は、エージェントが失敗した場所と方法に関する貴重な分析情報を提供し、ランダムな調整ではなく、ターゲットを絞った改善を行うことができます。

品質に関する一般的な問題とその修正方法

評価結果に含まれる LLM ジャッジの評価は、エージェントシステムにおける特定の種類の不具合を示しています。このセクションでは、これらの一般的な障害パターンとその解決策について説明します。 LLM ジャッジの出力を解釈する方法については、 AI ジャッジの出力を参照してください。

品質改善のための反復に関するベストプラクティス

改善を繰り返し行う際は、厳格なドキュメントを維持してください。例えば次が挙げられます。

変更をバージョン管理する
- MLflow Tracking を使用して、重要なイテレーションごとにログを記録します。
- 中央の構成ファイル内にプロンプト、構成、およびキーパラメーターを保存します。これがエージェントでログに記録されていることを確認します。
- デプロイされた新しいエージェントごとに、変更内容とその理由を詳しく説明した変更ログをリポジトリに保持します。
機能した内容と機能しなかった内容の両方を文書化する
- 成功した方法と失敗した方法の両方を文書化します。
- 各変更がメトリックに与える影響に注意してください。エージェント評価の MLflow 実行へのリンクを残します。
利害関係者と連携する
- レビューアプリを使用して、中小企業の機能強化を検証します。
  - レビュー担当者の指示を使用して、校閲者に変更を伝えます。
- エージェントのさまざまなバージョンを並べて比較する場合は、複数のエージェントエンドポイントを作成し、 AI Playground でモデルを使用することを検討してください。これにより、ユーザーは同じ要求を個別のエンドポイントに送信し、応答とトレースを並べて調べることができます。

3. 生産

アプリを繰り返し評価して改善した後、要件を満たし、幅広く使用できる品質レベルに達しました。運用フェーズでは、洗練されたエージェントを運用環境にデプロイし、継続的な監視を実装して時間の経過と同時に品質を維持します。

運用フェーズには次のものが含まれます。

エージェントを運用環境にデプロイする: 適切なセキュリティ、スケーリング、および認証設定を使用して、運用対応のエンドポイントを設定します。
運用環境のエージェントを監視する: 継続的な品質評価、パフォーマンスの追跡、アラートを確立して、エージェントが実際の使用で高品質と信頼性を維持できるようにします。

これにより、継続的なフィードバックループが作成され、監視分析情報によってさらなる改善が促進されます。これにより、テスト、デプロイ、監視を続行できます。このアプローチにより、アプリは高品質で準拠し、ライフサイクル全体を通じて進化するビジネスニーズに合わせて維持されます。

監視とログを含む完全な Gen AI 開発ワークフローを示すフローチャート。

a．エージェントを運用環境にデプロイする

徹底的な評価と反復的な改善が完了したら、運用環境にエージェントをデプロイする準備が整います。 [Mosaic AI Agent Framework](/generative-ai/agent-framework/build-gen AI-apps.md#agent-framework) は、多くのデプロイの問題を自動的に処理することで、このプロセスを簡略化します。

デプロイプロセス

エージェントを運用環境にデプロイするには、次の手順が必要です。

Unity カタログでエージェントを MLflow モデルとしてログに記録して登録します。
Agent Framework を使用してエージェントをデプロイします。
エージェントがアクセスする必要がある依存リソースの認証を構成します。
デプロイをテストして、運用環境の機能を確認します。
- モデルサービスエンドポイントの準備ができたら、AI Playground でエージェントと対話し、そこで機能をテストおよび検証できます。

実装手順の詳細については、生成 AI アプリケーション用のエージェントのデプロイに関する記事を参照してください。

運用環境のデプロイに関する考慮事項

運用環境に移行するときは、次の重要な考慮事項に注意してください。

パフォーマンスとスケーリング

予想される使用パターンに基づいて、コストとパフォーマンスのバランスを取ります。
コストを削減するために、断続的に使用されるエージェントに対して、ゼロへのスケーリングを有効にすることを検討してください。
アプリケーションのユーザーエクスペリエンスのニーズに基づいて待機時間の要件を理解します。

セキュリティとガバナンスの

すべてのエージェントコンポーネントに対して Unity カタログレベルで適切なアクセス制御を行います。
可能な場合は、Databricks リソースの組み込みの認証パススルーを使用します。
外部 API またはデータソースに対して適切な資格情報管理を構成します。

統合アプローチ

アプリケーションがエージェントと対話する方法を決定します (たとえば、API や埋め込みインターフェイスを使用)。
アプリケーションでエージェントの応答を処理して表示する方法を検討します。
- クライアントアプリケーションで追加のコンテキスト (ソースドキュメント参照や信頼度スコアなど) が必要な場合は、( カスタム出力を使用するなどして) 応答にこのメタデータを含むようにエージェントを設計します。
エージェントが使用できない場合のエラー処理とフォールバックメカニズムを計画します。

フィードバックの収集

最初のロールアウト中に、レビューアプリを利用して利害関係者のフィードバックを得る。
アプリケーションインターフェイスでユーザーフィードバックを直接収集するメカニズムを設計します。
- レビューアプリからのフィードバックを収集するために作成されたフィードバックエンドポイントは、外部アプリケーションがエージェントに関するフィードバックを提供するために使用することもできます。デプロイされたエージェントに関するフィードバックを提供するを参照してください。
フィードバックデータを評価と改善プロセスに確実に組み込みましょう。

b。運用環境でエージェントを監視する

エージェントを運用環境にデプロイした後は、パフォーマンス、品質、および使用パターンを継続的に監視することが不可欠です。機能が決定論的である従来のソフトウェアとは異なり、Gen AI アプリは、実際の入力に遭遇する際に品質の誤差や予期しない動作を示す可能性があります。効果的な監視を使用すると、問題を早期に検出し、使用パターンを理解し、アプリケーションの品質を継続的に向上させることができます。

エージェントの監視を設定する

Mosaic AI には、カスタム監視インフラストラクチャを構築せずにエージェントのパフォーマンスを追跡できる組み込みの監視機能が用意されています。

デプロイされたエージェントのモニターを作成します。
トラフィックの量と監視のニーズに基づいてサンプリングレートと頻度を構成します。
サンプリングされた要求で自動的に評価する品質メトリックを選択します。

主要な監視ディメンション

一般に、効果的な監視は、次の 3 つの重要なディメンションに対応する必要があります。

運用メトリック
- 要求のボリュームとパターン。
- 応答の待機時間。
- エラー率と種類。
- トークンの使用状況とコスト。
品質メトリック
- ユーザークエリとの関連性。
- 取得されたコンテキストに基づいた根拠のある応答。
- 安全性とガイドラインの遵守。
- 全体的な品質合格率。
ユーザーフィードバック
- 明示的なフィードバック (高評価/低評価)。
- 暗黙のシグナル（フォローアップ質問、放棄された会話）。
- サポートチャネルに報告された問題。

監視 UI を使用する

監視 UI は、2 つのタブを使用して、これらのディメンション全体で視覚化された分析情報を提供します。

[グラフ] タブ: 要求量、品質メトリック、待機時間、および時間経過に伴うエラーの傾向を表示します。
[ログ] タブ: 個々の要求と応答 (評価結果を含む) を調べます。

フィルター機能を使用すると、ユーザーは特定のクエリを検索したり、評価結果でフィルター処理したりできます。詳細については、「生成 AI のための Lakehouse Monitoring とは」を参照してください。(MLflow 2)。

ダッシュボードとアラートを作成する

包括的な監視の場合:

評価されたトレーステーブルに格納されている監視データを使用して、カスタムダッシュボードを構築します。
重要な品質または運用のしきい値に対するアラートを設定します。
主要な利害関係者との定期的な品質レビューをスケジュールします。

継続的改善サイクル

監視は、改善プロセスに戻るときに最も重要です。

メトリックとユーザーフィードバックを監視して問題を特定します。
問題のある例を 評価セットにエクスポートします。
MLflow トレース分析と LLM ジャッジ結果を使用して根本原因を診断します (一般的な品質の問題とその修正方法で説明されています)。
拡張された評価セットに対する機能強化を開発してテストします。
更新プログラムをデプロイし、 影響を監視します。

この 反復的な閉ループアプローチは、 変化する要件やユーザーの動作に適応しながら、エージェントが実際の使用パターンに基づいて継続的に改善し続け、高品質を維持するのに役立ちます。エージェント監視を使用すると、運用環境でのエージェントのパフォーマンスを把握できるため、問題に事前に対処し、品質とパフォーマンスを最適化できます。