ゲートウェイを介して Azure OpenAI の高度な監視を実装する
Azure OpenAI Service を含むワークロードの監視は、Azure OpenAI の診断を有効にし、事前に構成されたダッシュボードを使用するのと同じくらい簡単です。 ただし、この戦略では、次のようなジェネレーティブ AI ワークロードに関する、より複雑で一般的な組織の監視要件は満たしていません。
注
Azure OpenAI を直接監視する方法の詳細については、「 Azure OpenAI の監視」を参照してください。
次の図は、ゲートウェイを使用しない Azure OpenAI インスタンスの監視を示しています。 このトポロジにはゲートウェイは必要ありません。 ゲートウェイを含めるかどうかは、概説されている監視シナリオが要件の一部であるかどうかによって異なります。 この記事では、各監視シナリオが対処する課題と、各シナリオにゲートウェイを組み込む利点とコストについて説明します。
モデルの使用状況の追跡
多くのワークロードや組織では、すべての Azure OpenAI インスタンスのクライアントとモデルの両方による Azure OpenAI モデルの使用状況を追跡する必要があります。 これらの情報は、次の目的で使用されます。
チャージバックシステムを実装して、適切な組織またはアプリケーションの所有者に使用コストを割り当てます。
将来の使用量の予算と予測。
モーダルのコストと使用量をモデルのパフォーマンスに結び付けます。
ネイティブの Azure OpenAI 監視機能を使用してサービスのテレメトリを追跡できますが、課題があります。
チャージバック モデルの場合は、Azure OpenAI トークンの使用状況メトリックをアプリケーションまたはビジネス ユニットに関連付ける必要があります。 Azure OpenAI テレメトリには、最後のオクテットがマスクされた呼び出し元の IP アドレスが含まれています。 このマスキングにより、アプリケーションまたはビジネスユニットへのこの関連付けの確立が困難になる場合があります。
さまざまなリージョンの Azure OpenAI インスタンスは、それぞれのローカル リージョン内の Azure Monitor インスタンスにログを記録する可能性があります。 このプロセスでは、すべての Azure OpenAI インスタンスの使用状況を追跡するために、さまざまな Azure Monitor インスタンスからログを集計する必要があります。
モデルの使用状況を追跡するためのゲートウェイを導入する
このトポロジにゲートウェイを導入して、完全なクライアント IP アドレス、クライアントの Microsoft Entra ID (または代替 ID)、または部署、テナント、またはアプリケーションのカスタム識別子を 1 か所にキャプチャします。 その後、このデータを使用して、予算作成と予測のためのチャージバックソリューションを実装し、モデルの費用便益分析を実行できます。
次の例は、Azure API Management をゲートウェイとして使用する場合に実行できる使用状況クエリを示しています。
使用状況の監視のクエリ例
ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend modelkey = substring(parse_json(BackendResponseBody)['model'], 0, indexof(parse_json(BackendResponseBody)['model'], '-', 0, -1, 2))
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend completiontokens = parse_json(parse_json(BackendResponseBody)['usage'])['completion_tokens']
| extend totaltokens = parse_json(parse_json(BackendResponseBody)['usage'])['total_tokens']
| extend ip = CallerIpAddress
| summarize
sum(todecimal(prompttokens)),
sum(todecimal(completiontokens)),
sum(todecimal(totaltokens)),
avg(todecimal(totaltokens))
by ip, model
アウトプット：
プロンプトの使用状況監視のクエリ例
ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend prompttext = substring(parse_json(parse_json(BackendResponseBody)['choices'])[0], 0, 100)
アウトプット：
監査モデルの入力と出力
生成型 AI ワークロードの多くの監査要件の中心となるのは、モデルの入力と出力を監視することです。 レスポンスがモデルからのものか、キャッシュからのものかを知る必要がある場合があります。 モデルの入力と出力の両方を監視するには、複数のユースケースがあります。 ほとんどのシナリオでは、監査ルールは、入力と出力の両方について、すべてのモデルに均一に適用する必要があります。
次のユース ケースは、モデルへの入力を監視するためのものです。
脅威の検出: 入力を分析して、潜在的なセキュリティリスクを特定して軽減します。
使用ガイドライン違反の検出: 不快な言葉やその他の使用基準の入力を分析して、システムがプロフェッショナルで、安全で、偏りがないことを確認します。
モデルのパフォーマンス: モデル出力と組み合わせて、接地性や関連性などの指標でパフォーマンスを評価します。 この情報を使用して、モデルまたはプロンプトのパフォーマンスの問題に対処できます。
以下は、モデルへの出力を監視するためのユースケースの一部です。
データ流出検出: 出力を分析して、機密情報の不正な転送から保護します。
ステートフル コンプライアンス: 同じ会話内の複数のインタラクションの出力を監視して、機密情報の密かなリークを検出します。
コンプライアンス： アウトプットが企業のガイドラインと規制要件に準拠していることを確認します。 2つの例は、モデルが法的なアドバイスを提供したり、金銭的な約束をしたりしないことです。
モデルのパフォーマンス: モデル入力と組み合わせて、接地性や関連性などの指標でパフォーマンスを評価します。 この情報を使用して、モデルまたはプロンプトのパフォーマンスの問題に対処できます。
モデルの入力と出力をモデルから直接監査する場合の課題
モデルロギングの制約: Azure OpenAI などの一部のサービスでは、モデルの入力と出力はログに記録されません。
キャッシュ： より複雑なアーキテクチャでは、キャッシュからの応答を提供する場合があります。 これらのシナリオでは、モデルは呼び出されず、入力または出力をログに記録しません。
ステートフルな会話: 複数の対話式メッセージ交換の状態は、モデルの外部に格納される場合があります。 モデルでは、どの相互作用を会話として関連付ける必要があるかわからない。
マルチモデルアーキテクチャ: オーケストレーション レイヤーは、最終的な応答を生成するために複数のモデルを動的に呼び出す場合があります。
モデルの入力と出力を監査するためのゲートウェイを導入する
このトポロジにゲートウェイを導入して、クライアントから直接元の入力とクライアントに返される最終出力の両方をキャプチャします。 ゲートウェイはクライアントとモデルの間の抽象化であり、クライアントから直接要求を受信するため、ゲートウェイは未処理の生の要求をログに記録する位置にあります。 同様に、ゲートウェイは最終的な応答をクライアントに返すリソースであるため、その応答をログに記録することもできます。
ゲートウェイには、クライアントの要求と受信した最終的な応答の両方をログに記録する独自の機能があります。 この機能は、レスポンスがモデルから直接取得されたか、複数のモデルから集約されたか、キャッシュから取得されたかに関係なく適用されます。 さらに、クライアントが会話識別子を渡す場合、ゲートウェイはその識別子を入力と出力でログに記録できます。 この実装を使用して、会話の複数のインタラクションを関連付けることができます。
ゲートウェイでの入力と出力を監視することで、すべてのモデルに監査規則を均一に適用できます。
ほぼリアルタイムの監視
Azure Monitor は、 ログ データ インジェストに固有の待機時間のため、ほぼリアルタイムの処理には最適化されていません。 ソリューションでほぼリアルタイムのトラフィック処理が必要な場合は、メッセージ バスにログを直接発行し、Azure Stream Analytics などのストリーム処理テクノロジを使用してウィンドウ化された操作を実行する設計を検討できます。
監視用のゲートウェイを導入する際の考慮事項
潜在： アーキテクチャにゲートウェイを導入すると、レスポンスにレイテンシーが増加します。 可観測性の利点がパフォーマンスへの影響を上回るようにする必要があります。
セキュリティとプライバシー: ゲートウェイを使用して収集される監視データが、引き続きお客様のプライバシーの期待に準拠していることを確認します。 可観測性データは、ワークロードの確立されたセキュリティとプライバシーの期待に準拠し、顧客のプライバシー基準に違反してはなりません。 監視を通じてキャプチャされた機密データは、引き続き機密データとして扱います。
確実： 監視機能がワークロードの機能にとって重要であるかどうかを判断します。 その場合は、監視システムが使用できないときにアプリケーション全体がダウンしているはずです。 重要でない場合、監視システムがダウンしている場合、アプリケーションは監視されていない状態で引き続き動作する必要があります。 ゲートウェイのサービス障害または人為的な構成問題のいずれかによって、新しい単一障害点を追加するリスクを理解します。
実装： 実装では、必要なすべての構成を含め、API Management などのすぐに使用できるゲートウェイを利用できます。 別の一般的なアプローチは、コードを使用してオーケストレーション レイヤーを実装することです。
監視用ゲートウェイの導入を回避する理由
1 つのアプリケーションが 1 つのモデルにアクセスする場合、ゲートウェイの導入による複雑さの増加は、監視の利点を上回る可能性があります。 クライアントは、入力と出力のログ記録の責任を処理できます。 また、使用するモデルまたはサービスのネイティブ ログ記録機能を利用できます。 ゲートウェイは、監視する必要がある複数のクライアントまたは複数のモデルがある場合に役立ちます。
次のステップ
ワークロードのゲートウェイ実装には、この記事で説明する戦術的な複数のバックエンド ルーティングの利点を超える利点があります。 詳細については、「 ゲートウェイ経由で Azure OpenAI やその他の言語モデルにアクセスする」を参照してください。