はじめに
お客様のような独立系ソフトウェア ベンダー (ISV) を含む Microsoft パートナーは、さまざまなプロコードとローコードのアプローチを通じて、生成型 AI ソリューションを作成できます。 このプロセスをサポートするために、Microsoft では、ISV がこれらのソリューションをより適切に構築できるようにするためのガイダンスをしています。
ISV が特殊なクエリとタスクの管理を目指すにつれて、生成 AI ソリューションの複雑さが増します。 これらの複雑な生成 AI ソリューションには、開発中に固有の予防措置と、運用環境全体で一貫した監視と観察が必要です。 製品の動作と出力を観察することで、成長の領域をすばやく特定し、リスクや問題に迅速に対処し、アプリケーションのパフォーマンスをさらに向上させることができます。
副操縦アプリケーションの構築と運用
監視性がソリューション ライフサイクルの最初からアプリケーションに与える影響を理解するには、ユース ケースの作成、ソリューションの構築、デプロイ後の使用のための運用化という 3 つの主要な段階でライフサイクルを考える必要があります。
実際の LLM ライフサイクルというタイトルの画像。 これは 3 つの円で構成され、矢印で接続され、"管理" というラベルの付いた大きな矢印で囲まれています。 最初の円には "Ideating/Exploring" というラベルが付き、"try prompts"、"Hypothesis"、"Find LLMs" が含まれています。 ビジネス ニーズの矢印に由来し、"advance project" というラベルの付いた矢印で 2 つ目の円に接続されます。 2 つ目の円は "Building/augmenting" というラベルが付き、"取得拡張生成"、"例外処理"、"プロンプト エンジニアリングまたは微調整"、および "評価" で構成されます。 2 つ目の円は、"アプリのデプロイの準備" で最後の円に接続します。 最後の円は最大で、"運用化" というラベルが付き、"DEPLOY LLM app/UI"、"quota and cost management"、"content filtering"、"safe rollout/staging"、および "monitoring" で構成されます。 最後の円は "フィードバックの送信" を使用して 2 番目の円に接続され、2 番目の円は 1 つ目の円に接続されます。 
最初のフェーズは、ユース ケースを特定し、それを構築するための技術的なアプローチを使用して構成されます。 アプリケーションをビルドするためのパスを特定したら、アプリケーションの開発と評価で構成される 2 番目のフェーズに入ります。 アプリケーションが運用環境にデプロイされると、最後のフェーズに入り、そこで観察および更新できます。
2 番目と 3 番目のフェーズから収集された可観測性の分析情報は、以前のフェーズに戻って更新とデプロイを実行するときに重要になります。 継続的なテストを実行し、メトリックを取得して以前のプロセスに通知することで、アプリケーションを微調整し続けることができます。
プロセスのさまざまなポイントで可観測性を練習するために実行できるアクションを理解することが重要です。 大まかに言うと、アプリケーションのライフサイクル中に次の可観測性アクションが発生します。
第 1 フェーズ
- 製品マネージャーなどの技術的でないペルソナは、アプリケーションの重要な特性を特定することによって、可観測性を実践します。
- 利害関係者は、リスクと安全性のメトリック、品質メトリック、実行メトリックなど、アプリケーションのパフォーマンスを測定するために最も重要なメトリックを定義できます。
- Teams では、ユーザー エンゲージメントやコスト管理などのメトリックの目標を定義できます。
- 技術的なペルソナは、アプリケーションの構築を最も成功に収めることができるプラットフォーム、ツール、メソッドを特定することに重点を置きます。
- この手順には、使用するパターンの選択、大規模な言語モデル (LLM) の選択、描画元の主要なデータ ソースの識別などが含まれます。
第 2 フェーズ
- この段階では、開発者とデータ サイエンティストは、ソリューションを簡単に監視および反復処理できるように設定できます。 後で可観測性を高めるために、ISV は次の場合があります。
- ゴールデン データセットと自動マルチターン会話データセットを作成して、副次的な評価を行います。
- データのサブセットを使用してフローをデバッグ、実行、評価します。
- さまざまなプロンプトを使用してモデル評価用のバリエーションを作成します。
- LLM のコスト削減に合わせて価格とリソースの最適化を実行して、反復と構築を行います。
- 開発者は、運用環境にデプロイする前に、開発全体で実験を実行し、アプリケーションの品質を評価することに重点を置いています。 この段階では、次の操作を行う必要があります。
- モデルやプロンプトの有効性など、定義済みのメトリックを使用してテスト データセットを使用して、アプリケーションの全体的なパフォーマンスを評価します。
- これらのテストの結果を比較し、ベースラインを確立してから、コードを運用環境にデプロイします。
第 3 フェーズ
- アプリケーションが運用環境で積極的に使用されている間、多くの実験が実行されます。 ソリューションが適切に動作していることを確認するには、ソリューションを監視することが重要です。 このフェーズでは、次の操作を行います。
- アプリ内に埋め込まれたテレメトリ インストルメンテーションは、関連するトレース、メトリック、ログを出力します。
- クラウド サービスは、Azure OpenAI の正常性とその他の関連メトリックを出力します。
- 調整されたテレメトリ ストレージは、トレース、メトリック、ログ、使用状況、同意、およびその他の関連メトリックに関するデータを保持します。
- 事前に設定されたダッシュボード エクスペリエンスにより、開発者、データ サイエンティスト、管理者は、運用環境で LLM API のパフォーマンスとシステムの正常性を監視できます。
- エンド ユーザーからのフィードバックは、ソリューションの改善に役立つ評価のために開発者やデータ サイエンティストに送信されます。
データとテレメトリを収集すると、将来対処して改善する領域に関する分析情報が得られます。 適切なメトリックの識別や、アプリケーションのビルド中にソリューションの厳格な評価を実行するなど、イデーション フェーズ中に先入的な手順を実行することで、後で成功するためにソリューションを準備できます。
生成 AI における可観測性の課題
一般に、可観測性では ISV が多くの障害をナビゲートする必要がある場合があります。生成型 AI ソリューションでは、特定の考慮事項と課題が導入されています。
定性評価
生成型 AI プロンプト応答は自然言語形式で提供されるため、一意に評価する必要があります。 たとえば、接地性や関連性などの品質をチェックできます。
ISV は、これらの品質を測定するための最適なルートを検討する必要があります。最終的な検証のために、手動評価または AI 支援メトリックを人間と共に選択するかどうか。
評価方法に関係なく、プロンプトの応答を比較するために既存のデータセットも必要になる可能性があります。 これらの準備は、一般的なプロンプト トピックに対する理想的な応答を特定するため、アプリケーションの開発中により多くの作業を意味する可能性があります。
責任ある AI
倫理的 AI に対する新しい考慮事項と期待により、プライバシー、セキュリティ、インクルーシビティなどを監視する必要性が生まれます。 ISV は、エンド ユーザーの安全性を高め、リスクを軽減し、否定的なユーザー エクスペリエンスを最小限に抑えるために、これらの属性を監視する必要があります。
Microsoft の責任ある AI の 6 つの原則は、安全、倫理的、信頼できる AI システムを促進するのに役立ちます。 ソリューション内でこれらの値を昇格させるためには、これらの標準に照らしてアプリケーションを評価することが重要です。
使用状況とコストの監視メトリック
トークンは生成型 AI アプリケーションの主要な測定単位であり、すべてのプロンプトと応答は、測定できるようにトークン化されます。 使用されるトークンの数の追跡は、アプリケーションの実行コストに影響するため、不可欠です。
ユーティリティ メトリック
アプリケーションのユーザー満足度とビジネスへの影響の監視は、パフォーマンスまたは品質メトリックと同じくらい重要です。 AI はさまざまな方法で顧客と対話するため、顧客のエンゲージメントとリテンション期間を監視するための新しい考慮事項があります。
AI の応答の有用性の測定は、さまざまな方法で実現できます。 たとえば、プロンプトファネルと応答ファネルは、操作が使用可能または役に立つ応答を得るまでにかかる時間を追跡します。 また、ユーザーが AI に関与する時間、会話の長さ、ユーザーが提供された応答を受け入れる回数を追跡することも重要です。 ユーザーが応答を編集できるシナリオでは、編集距離または応答を編集する範囲を測定することが不可欠です。
パフォーマンス メトリック
AI では、ソリューションがプロンプトとデータを迅速かつ効率的に処理できるようにするために適切に維持する必要がある、ますます複雑で高パフォーマンスのシステムが必要になります。 生成型 AI はさまざまな種類の定性的コンテンツを作成するため、さまざまなシナリオで AI を評価およびテストするためのシステムを用意することが重要です。
LLM の対話は一般的なアプリケーションよりも複雑であるため、待機時間の問題を特定するには、複数のレイヤーで測定する必要があります。 たとえば、ユーザーのプロンプトをトークン化し、応答を生成し、ユーザーに応答を返す時間は、個別に、または全体として測定できます。 潜在的な問題の領域を特定するには、ワークフローの各コンポーネントを評価する必要があります。
ソリューションを監視する機能は、デプロイ方法によっても異なります。 ISV は通常、副操縦アプリケーションに 2 つのデプロイ パターンのいずれかを採用します。 自分が所有する環境にアプリケーションをデプロイして管理するか、顧客に属する環境にアプリケーションをデプロイすることができます。
デプロイがソリューションの種類全体の可観測性に与える影響の詳細については、 pro-code 可観測性ガイドを参照してください。
監視および評価するメトリック
生成型 AI アプリケーションと機械学習モデルの ISV 領域では、ソリューションを継続的に評価し、望ましくない動作を抑制するために迅速に介入することが重要です。 ユーザー エクスペリエンスまたはフィードバック、ガードレールと責任ある AI、出力の一貫性、待機時間、コストに関連するメトリックの監視は、副操縦アプリケーションのパフォーマンスを最適化するために不可欠です。
AI 支援メトリックを使用した定性的評価
定性的な情報を測定するために、ISV は AI 支援メトリックを使用してソリューションを監視できます。 AI 支援メトリックは、GPT-4 などの LLM を利用して、人間の判断と同様にメトリックを評価します。これによって、ソリューションの機能に関するより微妙な入力が提供されます。
通常、これらのメトリックには、質問、回答、会話の周囲のコンテキストなどのパラメーターが必要です。 大きく分けて次の 2 つのカテゴリに分類されます。
- リスクと安全性のメトリック 暴力、自傷行為、性的コンテンツ、ヘイトフル コンテンツなどのリスクの高いコンテンツを監視します
- 生成品質メトリック 次のような定性測定を追跡します。
- 接地性モデルの応答がプロンプトまたは入力ソースからの情報とどの程度一致しているか。
- 関連性モデルの応答が元のプロンプトとどの程度関係しているか。
- 一貫性モデルの応答が理解可能で人間のような程度。
- 流暢モデルの応答の言語、文法、構文。
このようなメトリックにより、ISV はアプリケーションの応答の品質をより簡単に評価できます。 これらは、解釈が困難なさまざまな値を迅速かつ測定可能な評価を提供します。
責任ある AI 標準
Microsoft は、責任ある AI の基準を維持することに取り組んでいます。 これをサポートするために、生成型 AI に関連するリスクを軽減するのに役立つ一連の Responsible AI 標準 を確立しました。
- アカウンタビリティ
- Transparency
- 公平性
- 包摂性
- 信頼性と安全性
- プライバシーとセキュリティ
ISV は、問題が発生したときに通知するメトリックを監視できます。 これらの通知には、有害なコンテンツの応答またはプロンプトを表示する定性的 AI 支援メトリックや、特定のエラーまたはフラグ付きメッセージに対して ISV にアラートを送信する、定性的な AI 支援メトリックが含まれる場合があります。
たとえば、Azure OpenAI には、コンテンツ のフィルター処理によってコンテンツが返されなかったフィルター処理されたプロンプトと応答の割合を測定できるソリューションが用意されています。 ISV は、これらのエラーを返すプロンプトを監視し、発生する量を減らすことを目指す必要があります。
お客様の利用状況と満足度
AI の一部の機能は、顧客の保有期間やアプリケーションの使用に費やされた時間の監視など、他の種類のアプリケーションと同様に監視できます。 ただし、AI に特に適用される顧客満足度の監視には多くの違いがあります。
- 応答に対するユーザーの反応。 これは、ユーザーが親指を上または下にして応答に反応するかどうかと同じくらい単純なメトリックを使用して測定できます。
- 応答に対するユーザーの変更。 ユーザーがニーズに合わせて AI の応答を変更できるシナリオでは、ユーザーが応答を変更した量を監視することで分析情報を得ることができます。 たとえば、ユーザーが大幅に変更した下書きメールは、ユーザーがそのまま送信した下書きメールほど役に立たない可能性があります。
- ユーザーによる応答の使用率。 ユーザーが AI に応答してアプリケーションを通じてアクションを実行するかどうかを監視することを検討してください。 AI がアプリケーションを通じてアクションを実行するよう提案する場合は、提案を受け入れるユーザーの割合を測定します。
多くの AI アプリケーションの目標は、ユーザーが役に立つと感じる応答を作成することです。 プロンプトと応答ファネルを使用すると、ソリューションが役立つ応答を生成する速度を測定する一般的な方法です。 このじょうごは、ユーザーが会話を保持または終了する応答をソリューションが作成するのにかかる時間と対話の量を測定します。
この概念では、ユーザーがプロンプトを送信したときにファネルが開始されます。 AI がユーザーが操作できる応答を生成すると、応答がユーザーの望むものに近づくにつれてファネルが絞り込まれます。 たとえば、ユーザーは AI 応答を編集したり、少し異なる回答を求めたりすることができます。 ユーザーが操作に満足すると、ユーザーは探していた特定の情報を取得し、じょうごが終了します。 プロンプトが広範なものから便利なもの、具体的なものまでにかかる相互作用の数を測定することは、アプリケーションが顧客に対してどの程度有効であるかを判断するのに役立ちます。
ユーザーがソリューションにどのように関与しているかを観察することで、アプリケーションがどれほど役立つのかについて推論を行うことができます。 ユーザーが、より多くのアクションを実行せずに LLM の出力を一貫して利用している場合は、応答が役に立った可能性があります。
コストの監視
生成型 AI アプリケーションを実行するために必要なリソースはすぐに追加できるため、それらを一貫して観察することが不可欠です。
アプリケーションのコスト最適化に影響を与える可能性のある領域には、次のようなものがあります。
- GPU 使用率
- ストレージのコストと考慮事項
- スケーリングに関する考慮事項
これらのメトリックの可視性を確保すると、コストを管理しながら、アラート システムまたはこれらのメトリックに関連する自動プロセスを設定すると、迅速なアクションを促すのにも役立ちます。
たとえば、アプリケーションが直接使用するプロンプト トークンと完了トークンの数は、GPU 使用率とソリューションの運用コストに直接影響します。 トークンの使用状況を注意深く監視し、特定のしきい値を超えた場合にアラートを設定すると、アプリケーションの動作を把握するのに役立ちます。
ソリューションの可用性とパフォーマンス
すべてのソリューションと同様に、AI アプリケーションの一貫した監視は、高レベルのパフォーマンスを促進するのに役立ちます。 生成型 AI アプリケーションと他のアプリケーションの主な違いの 1 つは、パフォーマンスを測定するときに考慮する必要があるトークン化の概念です。
生成 AI ソリューションを構築する ISV は、次の測定を行うことができます。
- 最初のトークンをレンダリングする時間
- 1 秒あたりにレンダリングされるトークン
- アプリケーションで管理できる 1 秒あたりの要求数
これらのメトリックはすべてグループとして測定できますが、LLM には複数のレイヤーがあることにも注意してください。 たとえば、AI が応答を生成するのにかかる時間は、次の時間で構成されます。
- ユーザーからプロンプトを受信する
- トークン化を使用してプロンプトを処理する
- 関連する不足している情報を推論する
- 応答を生成する
- デトケン化を使用してこの情報を応答にコンパイルする
- この応答をユーザーに返す
これらの各手順を測定すると、遅延とその発生場所を特定し、問題の発生元で対処できます。
その他の生成 AI 評価手法
ゴールデン データセット
Golden Dataset は、副操縦的な品質保証を提供するために使用される現実的なユーザーの質問に対する専門家の回答のコレクションです。 これらの回答はモデルのトレーニングには使用されませんが、モデルが同じユーザーの質問に与える回答と比較できます。
測定できるメトリックではありませんが、高品質の標準化された応答を使用すると、LLM の応答を比較して、ソリューションの出力に役立ちます。 このように、副操縦のパフォーマンスを評価するために、独自のゴールデン データセットをすることで、副操縦評価プロセスを高速化できます。
複数ターンの会話シミュレーション
評価データセットを手動でキュレーションすることは、自然に聞こえるマルチターン チャットの作成が困難なため、主に 1 ターンの会話に限定できます。 ISV では、モデルの回答を比較するためのスクリプト化された対話を記述する代わりに、シミュレートされた会話を開発して、副操縦者の複数ターンの会話能力をテストできます。
このシミュレーションでは、AI が単純な仮想ユーザーと対話できるようにすることでダイアログを生成できます。 その後、このユーザーは、事前に生成されたプロンプトのスクリプトを使用して AI と対話するか、AI を使用して生成されるため、評価する多数のテスト会話を作成できます。 また、人間のエバリュエーターを使用してアプリケーションと対話し、レビューする長い会話を生成することもできます。
長い会話内でアプリケーションの対話を評価することで、ユーザーの意図を識別し、会話全体でコンテキストを使用する方法を評価できます。 多くの生成 AI ソリューションは、複数のユーザー操作に基づいて構築することを目的としているため、アプリケーションが複数ターンの会話をどのように処理するかを評価することが不可欠です。
作業を開始する開発者ツール
ISV 開発者とデータ サイエンティストは、ツールとメトリックを使用して LLM ソリューションを評価する必要があります。 Microsoft には、探索に使用できる多くのオプションがあります。
Azure AI Foundry
Azure AI Foundry
2 種類の自動メトリックをサポートし従来の ML メトリックと AI 支援メトリックという生成的な AI アプリケーションを評価します。 また、 チャットプレイグラウンド 関連機能を使用して、モデルを簡単にテストすることもできます。
プロンプト フロー
プロンプト フロー は、プロトタイプ作成やテストからデプロイと監視まで、LLM ベースの AI アプリケーションのエンド ツー エンドの開発サイクルを合理化するように設計された一連の開発ツールです。 prompt フロー SDKは次の機能を提供します。
- タスク固有の評価ニーズに対応するためにPrompty を介してカスタム コード ベースまたはプロンプト ベースのエバリュエーターをサポートする組み込みのエバリュエーター。
- プロンプト トレース プロンプトの入力、出力、コンテキストを追跡し、開発者がモデルの問題の原因と原因を特定できるようにします
- 監視ダッシュボード。これにはシステム (トークンの使用や待ち時間など) と評価からのカスタム メトリクスが含まれ、Azure AI Foundry と Application Insights でのデプロイ前後の観察をサポートします。
その他のツール
Prompty は、LLM プロンプトを作成および管理するための言語に依存しない資産クラスです。 ソリューションを設計、テスト、強化するためのオプションを提供することで、開発プロセスを高速化できます。
PyRIT (生成 AI 用 Python リスク識別ツール) は、Red Teaming Generative AI システム用の Microsoft のオープン オートメーション フレームワークです。 これにより、さまざまな損害カテゴリに対する副操縦の堅牢性を評価できます。
次のステップ
可観測性と監視を念頭に置いて生成 AI アプリケーションを設計することで、開発から生産までの品質を評価できます。 アプリケーションの開発を開始したり、既に運用環境にあるソリューションを監視するためのオプションを調べるために使用できるツールを使ってみる。
その他のリソース
LLM を評価する方法: 完全なメトリック フレームワーク - Microsoft Research
LLM アプリケーションの評価に関するその他のガイダンス
プロンプト フローの概要 - Azure Machine Learning |Microsoft Learn
プロンプト フローの設定と作業の開始に関する情報