Azure で AI ワークロードをテストおよび評価する
AI ワークロードでのテストの目的は、システムに変更が導入されたときに品質を 向上させるために役立ちます。 テストでは、ワークロードが特定されたターゲットを満たし、ユーザーの期待を満たしているかどうかを検証できます。 また、品質の低下を防ぎます。 このプロセスには、さまざまな機能領域にわたってテストを実施し、ワークロードの要件に基づいて機能の品質、負荷処理、予測可能性、およびその他の基準を評価する作業が含まれます。
テスト結果は、AI コンポーネントがリリースの準備ができているかどうかどの SKU または機能が適切であるかなど決定のための重要なデータ ポイントを提供します。 さらに、テストは、障害の 認識システムとして機能し ルーチンまたは合成テストを通じて運用環境の問題を検出するのに役立ちます。
Azure Well-Architected Framework は、包括的なテスト手法の概要を示しています。 開発ライフサイクルのさまざまな段階、およびさまざまなシステム コンポーネントとフローで、さまざまな種類のテストを に使用する必要があります。 これらのテストがないと、ロールアウトされた変更によってシステムの品質が低下する可能性があります。 たとえば、小さなコード エラーが大きなシステム 障害になる可能性があります。 AI システムの非決定的な性質により、システムの動作が予測不能になったり、偏った結果が生じたりする可能性があります。 また、リソースの割り当ては非効率的であり、これらのシステムは悪用に対して脆弱であるため、実際のユーザー データまたはシステム リソースが悪用される可能性があります。
テスト 念頭に置いてワークロード資産を設計し、開発する必要があります。 たとえば、データ操作を実行し、特徴エンジニアリング用のソース データを整形する場合は、適切なコーディングプラクティスに従い、テストをサポートするようにコードを構成します。 この戦略には、効果的な単体テストを容易にするコードの設計と、コードの機能とその依存関係からのテストの分離が含まれます。 この例では、ボリュームと同一性の点で十分に代表的なテスト データを使用してテスト環境で実行できるシステムを設計する必要があります。
ワークロード コンポーネントを運用環境に安全にデプロイする必要があります。 ワークロードの安全なデプロイプラクティスの一部は、ユーザーまたはデータがシステムを使用する前に正しい動作を保証するための戦略的テストです。 戦略テストは、初期デプロイ中に、システムが進化し、コードまたはインフラストラクチャの変更が行われるにつれて不可欠です。 運用環境に変更をデプロイする前に、AI 関連のコードとインフラストラクチャに対して提案されたすべての変更をテストします。
この記事では、その手法をアーキテクチャの AI 側面に適用することに重点を置いています。 これらのテストを実行する方法は、スコープ内にありません。
推奨事項
この記事で提供される推奨事項の概要を次に示します。
| 推奨 | 説明 |
|---|---|
| テスト戦略の成功メトリックを定義します。 | 他の種類のワークロード テストと同様に、特定のテストに適したメトリックをキャプチャして分析し、テストによって AI ワークロードに関する有用な分析情報が得られるようにする必要があります。 ▪ 成功メトリックの定義 |
| 開発ライフサイクル全体を通じて、データ インジェストと処理パイプラインのエンド ツー エンドのテストを実施します。 | テストはデータを検証し、データ操作プロセスが意図したとおりに動作することを確認するのに役立ちます。 設計フェーズの早い段階でテストを組み込み、データ品質と適切なテクノロジとサイズ設定の選択肢を確保します。 開発中にカスタム コードの単体テストを開発し、リアルタイムの運用テストを実施して問題をキャッチし、機能を検証します。 ▪ データ インジェストのテスト |
| トレーニング ジョブのテストを実行して、スクリプトが呼び出され、期待どおりに機能することを確認します。 | 負荷とパフォーマンスのテストでは、ジョブの実行に適したコンピューティングの選択とサイズ設定に関する分析情報を提供できます。 単体テストでは、コードのユーティリティを検証し、依存関係が更新されたときに回帰をキャッチできます。 ▪ トレーニング ワークフローをテストする |
| トレーニング、評価、テストデータの重複を避けるために、モデルを評価してテストします。 | ソース データがトレーニングに完全に使用されないようにするには、モデルの評価と最終テスト用に一意のデータを予約する必要があります。 これらのサブセットは、実際のトレーニング プロセスには含まれません。 ▪ モデルの評価とテスト |
| 推論エンドポイントをテストします。 | 推論サーバーがホストするエンドポイントでロード テストを実施し、それらのテスト結果に基づいて GPU SKU を選択します。 サービスとしてのプラットフォーム (PaaS) でホストされるエンドポイントの場合は、スループットと潜在的なエラーをテストします。 これらのエンドポイントには到達可能であるため、脱獄の状況を防ぐために適切なセキュリティ テストを実施します。 ▪ 推論エンドポイントのテスト |
| クエリで関連する結果が得られるように、インデックス設計の正確性をテストします。 | 機能テストと統合テストは、データが正確であることを確認し、下位互換性をチェックするインデックス スキーマ テストに役立ちます。 品質の前処理手順をテストする必要があります。 ロード テストでは、リソースに適した SKU が決定され、セキュリティ制御によってデータの機密性が保護されます。 ▪ グラウンド データのテスト |
| オーケストレーターをテストして、その機能とセキュリティを検証します。 | パフォーマンスと信頼性を確保するために、負荷モードと障害モードのテストを含む単体テスト、機能テスト、統合テスト、ランタイム テストを実施します。 セキュリティとコンテンツの安全性テストは、システムとデータを保護するためにも重要です。 ▪ オーケストレーターのテスト |
| モデルの減衰をテストします。 | モデルの減衰は、ほとんどの AI ワークロードに影響を与える避けられない問題です。 データと概念の誤差のテストは、モデルの減衰を早期にキャッチし、ワークロードに悪影響を与える前に問題を軽減するのに役立ちます。 ▪ Prevent モデルの減衰 |
成功メトリックを定義する
ベースラインを用意し、明確に定義されたメトリックを使用してモデルの予測力を測定することをお勧めします。 一般的なメトリックを次に示します。
精度 は、テスト データセット内の合計インスタンスに対する正しく予測されたインスタンスの比率を表します。 これは、モデル全体のパフォーマンスの一般的な尺度です。
精度 は、真陽性と偽陽性の合計に対する真陽性予測の比率です。 たとえば、医療診断のように、誤検知を最小限に抑えることが重要な場合に便利です。
感度 真陽性と偽陰性の合計に対する真陽性の比率を測定します。 これは、偽陰性を回避する場合や、関連するケースが見つからない場合に重要です。
特定性 は、真陰性と偽陽性の合計に対する真陰性の比率を計算します。 これは、正確な負の予測のために最適化する場合に関連します。
Note
回帰モデルの成功メトリックを定義する場合は、次のメトリックを追加することを検討してください。
平均絶対誤差 (MAE) は、予測値と実際の値の平均絶対差を測定します。 各実際の値とそれに対応する予測値の間の絶対差の平均を取って計算します。 MAE は、MSE や RMSE と比較して外れ値の影響を受けにくいです。
平均二乗誤差 (MSE) は、実際の値と予測値の平均二乗差を測定します。 各実際の値とそれに対応する予測値の間の二乗差の平均を取って計算します。 MSE では、エラーが 2 乗されるため、MAE よりも大きなエラーが大きくなります。
2 乗平均平方根誤差 (RMSE) は、MSE の平方根です。 元のデータと同じ単位で、実際の値と予測値の間の平均絶対誤差の測定値が提供されます。 RMSE は平均化する前にエラーを 2 乗するため、MAE と比較して外れ値に対してより敏感です。
データ インジェストのテスト
抽出、変換、読み込み (ETL) プロセス、データの移動、操作などのデータ パイプライン。 ワークロードの ETL 部分をテストして、データが確実に取り込まれていること、およびデータが高品質で、分析と特徴エンジニアリングに許容できることを確認します。 データのクレンジングと処理に、データ操作が意図したとおりに機能することを確認するテストが含まれていることを確認します。
テストは、設計、開発、生産の各段階を含め、ライフサイクル全体を通して統合する必要があります。
設計の選択を容易にするテスト
ワークロードの要件を収集する場合、重要な意思決定手順は、設計に実行可能な特定のテクノロジ オプションを選択することです。
ETL の要件と受け入れ条件に基づいて、探索的機能テストを実施して、目的のタスクを実行する最適な製品、SKU、および機能を選択します。 概念実証、テクノロジの証明、および機能テストの証明は、適切なテクノロジを選択しているかどうか、および適切なサイズに設定されているかどうかを評価するために不可欠です。
既存のアーキテクチャに AI を組み込むシナリオでは、新しいテクノロジが現在のシステムとどの程度統合できるかをテストします。
初期ワークロードの要件は変更される可能性があります。 ビジネスが成長を予測し、システムが通常のユーザー クエリを 2 倍処理する必要があるとします。 この期待には、適切な容量計画が必要です。 システムが追加のデータにどのように応答するかを理解し、既存のサイズ設定に対してデータドリブン調整を行ったり、新しい製品を選択したりするには、事前テストを行うことをお勧めします。 容量テストの場合は、機能テストとロード テストとパフォーマンス テストを組み合わせ、合成を使用して現実的な状態をシミュレートすることをお勧めします。
コードの品質を確認するためのテスト
コードが含まれている場合は、単体テストを通過し、失敗した場合は解放されないようにします。 たとえば、インジェストの一部として実行されるカスタム コードを使用するのが一般的です。 データ クレンジングと処理に使用されるコードもあります。 単体テストを実行して、コードが設計に従って動作し、データ操作が期待どおりに機能することを確認します。
継続的インテグレーションと継続的デリバリー パイプラインの一部としてテストを実行します。
ライブ システムでテストする
機能テストは、ライブ システムまで拡張する必要があります。 これらのテストが失敗した場合は、必要に応じて、アラートをトリガーして直ちに調査を開始することを検討してください。 次に例をいくつか示します。
スケジュールされたテストを実行して、予想される量の設定されたスケジュールでデータが取り込まれた場合に、正しい量のデータが収集されたことを確認します。
欠損値や重複データなどのデータの問題を検出するテストを実行し、基本的なデータ整合性チェックを実行します。 データに鮮度を示す一時的な情報が含まれている場合、これらのテストでその情報を確認し、ダウンストリーム プロセスが古いデータを使用できないようにする可能性があります。
外部依存関係の可用性を確認します。 たとえば、データ クレンジング ジョブでは、テーブルの抽出や前処理のために別のサービスを呼び出す場合があります。 テストを実行して、使用できないことが ETL プロセスに影響を与える可能性があるため、テストが利用可能であることを確認します。
運用環境の ETL システムの正確性をテストするもう 1 つの方法は、合成テストを使用することです。 運用環境で使用可能な既知のテスト データを持つことは、非常に効果的です。 これを使用して、既知の開始状態と、そのデータの予想される終了状態を比較することで、エンドツーエンドの処理を検証できます。 たとえば、ドキュメントはドキュメント インテリジェンスを経由する必要があり、個人データが含まれています。 合成ドキュメントを挿入すると、ワークロードが意図したとおりにデータ操作ジョブを実行することをテストできます。
さらに、完全にコミットする前にユーザーの操作から学習するために、 A/B テストとも呼ばれるさまざまなエクスペリエンスをリリースして実験します。 A/B テストは、品質の低下を防ぐのに役立ちます。
インジェスト中に収集されるテスト データ
さまざまなデータ ソースからのインジェスト プロセスの一環として、トレーニング データが期待値と一致することを検証するテストを含めます。
不完全なデータまたは破損したデータを使用して機械学習モデルをトレーニングすると、逆効果になる可能性があります。 無駄な作業につながる可能性があり、意味のある予測を行うのに失敗するモデルが発生する可能性があります。 データ インジェストと前処理パイプラインには、チェックポイントとして品質テストが含まれます。 これらのテストは、データ分析と特徴エンジニアリング時に設定した期待値に合わせてデータが揃っていることを確認するのに役立ちます。
次の一覧には、いくつかのテスト ケースの例が含まれています。
完全性をテストします。 予想されるトレーニング データの量をテストして、データセットの完全性を確認します。 このテストにより、モデルをトレーニングするのに十分なデータが提供されます。
重要な情報をテストします。 トレーニングが特定のレコードや識別子などの既知のエンティティに基づいている場合は、データセットをテストして、それらのエンティティが存在することを確認します。 この検証により、重要な情報が見つからないことが保証されます。
無関係なデータをテストします。 取り込まれたデータには、無関係なエントリや誤ったエントリを含めることはできません。 データ インジェスト プロセスでは、そのデータを除外する必要があります。
鮮度をテストします。 取り込まれたデータの鮮度は、モデルの予測能力に影響を与えるべきではありません。 データが合理的に最新の情報を反映しており、以前の実行から古くないことを検証します。 たとえば、データに過去 1 週間のレコードが含まれると予想されるが、データをインポートした後にそのようなレコードがない場合は、インポートの失敗やソース システムでのデータの鮮度の問題を示している可能性があります。
定期的なテストを実施する
データ インジェストに関する重大な懸念事項は、データの量とスループットです。 パフォーマンスのボトルネックを防ぐために、操作中の継続的な評価が必要です。 この継続的な評価は、1 回限りのテストではなく、運用プロセスの一部である必要があります。 目標は、ワークロード チームがサービス レベルの目標を見逃さないようにすることです。
監視がパフォーマンスの低下を示す状況を考えてみましょう。 このような状況を軽減するには、ETL プロセスを再評価して最適化します。 変更を行った後、パフォーマンス テストは、変更が必要なスループットを満たしていることを確認するのに役立ちます。
Note
テストと監視は、さまざまな目的に役立ちます。 通常、変更を実装する前に、システムに対する潜在的な変更を評価するテストを実施します。 継続的に監視を実施して、システムの全体的な正常性を評価します。
トレーニング ワークフローをテストする
実際のトレーニング作業を行う PyTorch スクリプトなどのカスタム コードを使用してモデルをトレーニングします。 これらのスクリプトは、ノートブックや Azure Machine Learning ジョブなど、コンピューティング上で実行されます。これには、メモリとネットワーク リソースも必要です。 コンピューティングニーズを評価し、提案された SKU が適切であることを確認するには、設計フェーズ中にロード テストを行うことをお勧めします。 多くの場合、制限時間内にワークロードを効率的に実行するための最適な構成を判断するには、手動テストが必要です。
ほとんどのタスクを処理する特殊化された SDK を使用してスクリプトを記述します。 ただし、スクリプトはまだコードであるため、開発の一環として単体テストを統合する必要があります。 これらのテストは、依存関係を更新するときに回帰が発生しないようにするのに役立ちます。 単体テストが不可能な場合は、品質回帰を防ぐために新しいコードをデプロイする前に手動テストが必要です。
これらのスクリプトは、Azure Machine Learning スタジオなどのワークフローの一部として実行され、スクリプトが実行されたタイミングと実行の有無に関する分析情報を提供できます。 ただし、統合テストを実行して、これらのスクリプトが確実に呼び出されるようにすることをお勧めします。
モデルを評価してテストする
Note
多くの場合、モデルの評価とテストは同じ意味で使用されますが、個別のデータセットを使用する個別のプロセスと見なす必要があります。 評価は、開発フェーズ中に行う反復的なアクティビティです。 適切なレベルのチューニングで最適なモデルを見つけるための実験に焦点を当てています。 これには、ハイパーパラメーター、構成、または機能の調整と、さまざまなメトリックに基づくモデルの評価が含まれます。 最適なモデルを特定したら、デプロイ中にテストを実施します。
テストには、チューニングされたモデルと非 AI コンポーネントを含むシステム全体を検証して、それらが正しく機能することを確認し、適切に統合し、品質基準に従って期待される結果を提供することが含まれます。 ワークロードの他のコンポーネントと共に、モデルを現場で評価します。 このプロセスには、モデルへの要求の送信、応答の評価、テスト データに基づく Go または No-Go の決定が含まれます。 テストは運用環境の前にネゴシエーションできませんが、実データと合成データを使用して運用環境でもテストを実施することをお勧めします。
データを使用して評価とテストを行う
通常、ソース データからパーティション分割された 3 つの主要なデータセットがあります。トレーニング、評価、テストです。
通常は最大のサブセットであるトレーニング データセットを使用して、モデルをトレーニングします。 評価に別のデータセットを使用して、さまざまな順列を評価することで反復的なプロセスを通じてモデルを調整します。 満足できる順列が見つかると、テスト データセットに対してテストします。
ノイズを最小限に抑えるために、すべてのデータセットに高品質のデータを含める必要があります。 データ インジェストと前処理パイプラインに関するテスト ケースは、品質チェックポイントとして機能できます。 サンプルが不足している場合は、低品質のデータに起因する可能性もあります。 合成データを使用して、データセットのバランスを取り、均一性を実現します。 このアプローチは、実際の不正行為のインスタンスがまれな不正検出モデルなどのモデルをトレーニングする場合に役立ちます。そのため、信頼性の高い予測に十分な統計能力を得ることは困難です。
予測の偏りを回避するには、すべてのデータセットを個別に保持します。 評価にはトレーニング データを使用しないでください。また、テストには評価データを使用しないでください。 モデルの評価と最終的なテスト用に一意のデータを予約します。
評価メトリックを使用する
モデルをトレーニングし、運用環境に適したモデルを選択することは、相互に依存するプロセスです。 最初にモデルを選択する必要がありますが、実験と評価後に変更される可能性があります。
モデルの評価は、メトリックを使用してモデル、パラメーター、および特徴の多数の順列を評価する実験ループとして続きます。 これらのメトリックは科学的評価を提供します。最適なモデルを決定するには、さまざまなバージョンと構成間で繰り返し比較する必要があります。 詳細については、「 評価メトリック」を参照してください。
同様のアプローチは、生成型 AI モデルにも適用されます。 モデルのパフォーマンスに基づいてユーザー エクスペリエンスの結果を評価および定量化するプロセスがあります。 たとえば、基本性は、モデルがソース データとどの程度適切に整合しているかを定量化する主要なメトリックの 1 つです。 関連性は、応答がクエリにどの程度関連しているかを示すもう 1 つの重要なメトリックです。 メトリックの例については、「 生成 AI の評価と監視のメトリックを参照してください。
さまざまなメトリックを使用して、さまざまな種類のモデルを評価します。 各メトリックの重要性は、シナリオによって異なる場合があります。 ユース ケースに基づいてメトリックに優先順位を付けます。 たとえば、責任ある AI では公平性が重要です。 適切なテストにもかかわらず、ソース データが偏っているため、モデルで不公平なバイアスが発生する可能性があります。 結果は関連性が高いが、公平性は低い場合があります。 公平性評価をプロセスに統合して、偏りのない結果を確保します。
生成 AI は、オーケストレーション コード、ルーティング ロジック、取得拡張生成 (RAG) のインデックスと統合され、評価が複雑になります。 メトリックを使用してモデルを個別に評価する必要がありますが、他のシステム コンポーネントを評価することも重要です。
モデルをテストする
微調整は基本的にテストです。これは、事前トレーニング済みのモデルを変更してその動作を変更するためです。 モデルの初期パフォーマンスを理解するには、ベースラインから始める必要があります。 微調整後、モデルのパフォーマンスを再評価して、品質基準を満たしていることを確認します。 次の一般的な評価メトリックについて考えてみましょう。
接地 は、モデルとソース データの配置を指します。 地表モデルは、現実と一致する回答を生成します。
関連性 は、特定の質問に対する応答の関連性を示します。 質問に直接対処しない場合、非常に根拠のある回答には関連性がない可能性があります。
類似性 は、ソース データ テキストと生成された応答の間の類似性を測定します。 モデルでは正確な文言を使用しましたか? 編集ガバナンスが不足すると、類似性スコアが低下する可能性があります。
取得 インデックス クエリの有効性を示します。 取得したインデックス データが質問にどの程度合っているかを評価します。 インデックス検索の無関係なデータによって、このスコアが低下します。 取得スコアが高いほど、インデックス クエリのみに依存するため、変動性が低いことを示します。
流暢 語彙の使用法に関連します。 モデルがスタイル ガイドに準拠し、適切な形式でコンテンツを表示する場合は、根拠や関連性がない場合でも、流暢になる可能性があります。
一貫性 モデルの音声が自然かつ一貫して流れるかどうかを評価します。 会話が本物のやり取りのように感じるかどうかを評価します。
ハイパーパラメーターのテスト
モデル パラメーターは、アプリケーション固有の設計上の決定に依存します。 アプリケーション設計の一環として、ワークロードのユース ケースに基づいてモデルとパラメーターを選択します。 テスト プロセスには反復的な内部ループがあり、トレーニング データとテスト データを比較して、モデルが目的のデータセットでトレーニングされていることを検証します。 また、パラメーターは、モデルが許容できる精度で予測を行えるように調整されます。
Trade-off. 内部ループには、モデルをトレーニングするための計算コストと、テストを通じて評価するコストが含まれます。 モデルのトレーニングとテストに必要な時間をこのループに組み込む必要があります。 テスト プロセスにはトレーニング プロセスよりも時間がかかることが予想されます。 トレーニング データのサブセットに対して初期テストを実行して、モデルが妥当な結果を生成するかどうかを評価できます。 そのテスト セットを完全なデータセットに徐々にスケールアップできます。
推論エンドポイントをテストする
推論エンドポイントは、予測を行うためにモデルへのアクセスを許可する REST API です。 これは、要求の一部としてデータを送信し、モデルからの結果を含む応答を取得するインターフェイスです。 エンドポイントはコンピューティングでホストされます。これは、Azure OpenAI Service などの PaaS、または NVIDIA Triton Inference Server、TorchServe、および BentoML などの Microsoft 以外の推論サーバーです。 PaaS シナリオでは、サービス プロバイダーはテストをある程度処理します。 ただし、エンドポイントをホストする場合は、他の API と同様に扱い、徹底的にテストします。
トレーニングと評価中にモデルをテストしますが、推論エンドポイントをテストするには、要求処理、応答の作成、スケーリング、インスタンス間の調整など、そのモデルに関連するメカニズムが正しく機能することを確認する必要があります。 要件に基づいてユース ケースをカバーする包括的なテスト計画を作成します。 このセクションでは、考慮すべきテスト ケースとテストの種類の例について説明します。
推論ホスティング サーバーのテストに関する考慮事項
コンピューティングの負荷特性を理解し、ロード テストを通じてパフォーマンスを検証することが重要です。 これらのアクションは、アーキテクチャを設計または最適化するときにテクノロジを選択するのに役立ちます。 たとえば、推論サーバーが異なると、パフォーマンス特性が異なります。 同時実行接続の数が増えると、コードは CPU サイクルとメモリを消費します。 標準およびピーク時の読み込み条件でコードとコンピューティング リソースがどのように実行されるかを理解します。 Azure Load Testing はロード テストに適したオプションであり、大量の負荷を生成できます。 Apache JMeter などの他のオープン ソース オプションも人気があります。 環境からこれらのテストを直接呼び出すことも検討してください。 たとえば、Machine Learning はロード テストとうまく統合されます。
もう 1 つの重要な決定は、GPU 機能の選択です。 多くのモデルでは、設計上、効果的な推論に GPU が必要です。 ロード テストは、GPU SKU のパフォーマンス制限を理解し、オーバープロビジョニングを防ぐのに役立ちます。これは財務上の重要な考慮事項です。
PaaS 以外のホスティング プラットフォームでは、API がパブリックに公開されるため、セキュリティが重要です。 エンドポイントが悪用または侵害されないようにすることが重要です。これにより、システム全体が危険にさらされる可能性があります。 このエンドポイントを、他のパブリック エンドポイントと共に定期的なセキュリティ テストの一部として含めます。 ライブ システムで侵入テストなどのテストを実施することを検討してください。 セキュリティのもう 1 つの側面は、コンテンツの安全性です。 コードは、要求と応答のペイロード内の有害なコンテンツを検出する特殊な API を呼び出すことができます。 Azure AI Content Safety は、コンテンツの安全性テストを容易にするために、テストから呼び出すことができます。
主要な戦略については、「 セキュリティ テストの推奨事項を参照してください。
PaaS 推論エンドポイントのテストに関する考慮事項
クライアントは、PaaS サービスの推論エンドポイントに要求を送信するときにエラーを予期する必要があります。 エラーは、システム のオーバーロード、応答しないバックエンド、およびその他のエラー状態が原因で発生する可能性があります。 サービスに対して障害モード分析を実施し、それらの潜在的な障害をテストします。 クライアント コードで軽減策を設計および実装するには、エラー モード分析が必要です。 たとえば、Azure OpenAI API は、HTTP 429 エラー応答コードを返すことによって要求を調整します。 クライアントは、再試行メカニズムとサーキット ブレーカーを使用して、そのエラーを処理する必要があります。 詳細については、「エラー モード分析を実行するための推奨事項」を参照してください。
PaaS サービスのテストは、従量課金制や事前プロビジョニング済みのコンピューティングなどの関連コストを理解しているため、サービス SKU を選択するのに役立ちます。 Azure 料金計算ツールを使用して、ワークロード、頻度、トークンの使用状況を評価し、最適な課金とコンピューティングのオプションを決定します。 低コストの SKU を使用してワークロードをシミュレートし、Azure OpenAI のプロビジョニング済みスループット ユニット (PTU) などのハイエンド オプションを正当化します。
ロード テストは従量課金制コンピューティングには関係ありません。これは、無限の容量では問題が発生しないためです。 テストでは、制限とクォータが検証されます。 従量課金制コンピューティングのロード テストはお勧めしません。これは、多大な費用がかかります。 ただし、1 分あたりのトークン数または 1 分あたりの要求数で測定されるスループットを確認するには、ロード テストを行う必要があります。 要求サイズなどのメトリックを考慮する標準 API とは異なり、このアプローチではトークンに基づいてワークロードが評価され、使用状況が決定されます。 重要なのは、アクティブなユーザーの数を理解し、それに応じてスループットを測定することです。 詳細については、「 スループットを設定する」を参照してください。
セキュリティコントロールを使用する
推論サーバーと PaaS オプションのどちらを使用するかに関係なく、セキュリティはお客様の責任です。 API エンドポイントでは、脱獄とコンテンツの安全制御をテストすることが重要です。 これらのコントロールをバイパスできず、期待どおりに機能していることを確認します。 たとえば、既知のブロックされた項目を送信すると、デプロイ前にセキュリティコントロールが設定されていて正常に動作しているかどうかを確認するのに役立ちます。 必要に応じてこれらのテストを実行するか、リリース プロセスに統合することを検討してください。
システムが誤って公開すべきではない情報を公開できるかどうかをテストすることが重要です。 たとえば、システムは応答ペイロード内の個人情報を公開しないでください。 また、クライアントが他の ID 用のエンドポイントにアクセスできないことをテストします。 認証と承認のメカニズムを使用して API が機密情報を漏らさないことを確認し、適切なユーザーセグメント化を維持するためのセキュリティ テストを実施します。
接地データをテストする
データ設計は生成モデルの効率に影響を与え、接地データは重要なコンポーネントです。 グラウンド データは、応答の関連性を高めるためのより多くのコンテキストを提供します。 モデルに到達する前にインデックスが作成されます。 ユーザーが回答を待つと、このインデックスにリアルタイムでアクセスされます。
エンドツーエンドのテストを実施し、そのプロセスをデータ設計の一部として組み込みます。 モデルのパフォーマンス、オーケストレーション、インデックス、前処理、ソース データに基づいて、顧客のエクスペリエンスの結果を評価および定量化するテスト プロセスを実装します。 品質メトリックを反復的に監視および測定します。 次にいくつかの考慮事項を示します。
機能テストと統合テストを使用して、データ処理を徹底的にテストします。 データが想定どおりに読み込まれ、すべてのデータが存在することを確認します。
下位互換性のためにインデックス スキーマをテストします。 ドキュメントまたはフィールドに対する変更をテストして、新しいバージョンが以前のバージョンのデータに対応できることを確認する必要があります。
データのインデックスが作成される前に、ノイズとバイアスを減らし、効率的なクエリを可能にする準備が行われます。 このプロセスには、埋め込みの前処理、チャンク、計算が含まれます。各ステップでは、インデックス内のコンテキストまたはファイルにデータが保存されます。 Azure AI Search によって提供されるスキル セットなどのオーケストレーション パイプラインでは、次の手順が実行されます。 オーケストレーション コードをテストして、ステップが見逃されておらず、処理されたデータが高品質であることを確認する必要があります。
テストでは、古いデータ、合成値、空のテーブル、データの更新、および最新バージョンでの処理を確認する必要があります。 テストエラーが発生した場合は、検索クエリとインデックスの調整が必要になる場合があります。 このプロセスには、前に説明したフィルターとその他の要素の調整が含まれます。 テストは反復的なアクティビティと考える必要があります。
インデックスは複雑であり、クエリのパフォーマンスは、負荷の見積もりが必要なインデックス構造によって異なる場合があります。 適切なロード テストは、ストレージ、コンピューティング、および要件をサポートするために使用できるその他のリソースのさまざまな SKU を特定するのに役立ちます。
すべてのセキュリティコントロールをテストする必要があります。 たとえば、データは別のドキュメントに分割される場合があります。 各パーティションにはアクセス制御があります。 機密性を保護するには、これらのコントロールを適切にテストする必要があります。
オーケストレーターをテストする
RAG アプリケーションの重要なコンポーネントは、中央オーケストレーターです。 このコードは、最初のユーザーの質問に関連するさまざまなタスクを調整します。 オーケストレーター タスクでは、通常、ユーザーの意図、基礎データを検索するためのインデックスへの接続、推論エンドポイントの呼び出しを理解する必要があります。 エージェントが REST API の呼び出しなどのタスクを実行する必要がある場合、このコードはコンテキスト内でそれらのタスクを処理します。
オーケストレーション コードは、任意の言語で開発することも、ゼロから記述することもできます。 ただし、開発プロセスの高速化と簡素化には、Azure AI Studio のプロンプト フローや Apache Flow の有向非循環グラフ (DAG) などのテクノロジを使用することをお勧めします。 プロンプト フローは、デザイン時のエクスペリエンスを提供します。 これを使用して、タスクを単位としてモジュール化し、各ユニットの入力と出力を接続し、最終的にプロセス全体を表すオーケストレーション コードを形成します。
オーケストレーション コードを分離します。 これを個別に開発し オンライン エンドポイントと REST API を使用してマイクロサービスとしてデプロイしてアクセスします。 このアプローチにより、モジュール性とデプロイの容易さが保証されます。
テストの観点から、このコードを他のコードと同様に扱い、単体テストを します。 ただし、より重要な側面は、機能と統合のテストを通じて検証できるルーティング ロジックなどの機能です。 プロンプト エンジニアリングをテストして、コードがユーザーの意図を検出し、呼び出しを適切にルーティングできることを確認します。 Scikit-learn、PyTorch の torch.testing モジュール、バイアスと公平性テスト用の FairML、モデル評価用の TensorFlow モデル分析など、テスト用のフレームワークとライブラリがいくつかあります。
また、エラー モードのテストなどのランタイム テストを実施します。 たとえば、トークンの制限に関連する潜在的なエラーをテストします。
特定のランタイム テストは、決定に役立ちます。 ロード テストを実行し このコードがストレスを受けてどのように動作するかを理解し、その結果を容量計画に使用します。 このコードは、他のサービスに到達する必要があるアーキテクチャの重要なポイントに配置されているため、これらのすべての呼び出しからテレメトリを収集するのに役立ちます。 このデータは、ローカル処理とネットワーク呼び出しに費やされた時間に関する分析情報を提供し、潜在的な待機時間などの他のコンポーネントの動作を決定できます。 プロンプト フローなどのテクノロジには、このプロセスを容易にするテレメトリ機能が組み込まれています。 それ以外の場合は、カスタム コードにテレメトリを組み込みます。
Note
このコードをテストすると、コストに影響があります。 たとえば、Azure OpenAI を使用して推論エンドポイントをホストする場合、ストレス テストはシステムの制限を判断するのに役立つ一般的な方法です。 ただし、Azure OpenAI は呼び出しごとに課金されるため、大規模なストレス テストが高価になる可能性があります。 料金を最適化する 1 つの方法は、テスト環境で Azure OpenAI の未使用の PTU を使用することです。 または、推論エンドポイントをシミュレートすることもできます。
セキュリティ上の問題は、オーケストレーション コードとモデルの両方に適用されます。 脱獄のテストを含めます。このテストでは、モデルのセキュリティを解除することが目標です。 攻撃者はモデルと直接対話しません。 最初にオーケストレーション コードと対話します。 オーケストレーション コードは、ユーザー要求を受信して解析します。 オーケストレーション コードが悪意のある要求を受け取った場合、その要求をモデルに転送し、モデルを侵害する可能性があります。
コンテンツの安全性は、もう 1 つの重要な側面です。 チャットボット アプリケーションでは、オーケストレーション コードはチャット テキストを受け取ります。 このコードでは、 コンテンツ セーフティ サービスの呼び出しを行います。 分析のためにユーザー プロンプトとグラウンド コンテキストの両方を送信し、リスクの評価を受け取ります。 Prompt Shields は、大規模な言語モデルの入力を分析し、ユーザー プロンプト攻撃とドキュメント攻撃を検出する統合 API です。これは、敵対的な入力の 2 つの一般的な種類です。
RESTful エンドポイントでは セキュリティ制御と認証が重要です。 認証を管理し、徹底的なテストを行う必要があります。
モデルの減衰を防ぐ
すべてのモデルの一般的な問題は、時間の経過に伴うある程度の低下です。 ワークロードの内部および外部の変更は、最終的にモデルとその出力の品質の低下を引き起こします。 モデルの減衰は、次の 2 つの方法で発生します。
データ ドリフト は、入力データが変更されたときに発生します。 新しいデータ入力により、トレーニング済みのモデルが古くなります。 たとえば、地区など、特定の地理的地域の投票パターンを予測するモデルがあるとします。 地区が再描画され、その地区の人口の人口統計が変化する場合は、変更を考慮してモデルを更新する必要があります。
概念の誤差 は、ワークロードとモデルの外部にある条件が、モデルの出力が現実と一致しなくなったように変化したときに発生します。 たとえば、テクノロジ製品の売上予測モデルがあるとします。 競合他社が、一般の人々から大きな注目を集めるより高度な競合製品を予期せず導入した場合は、消費者の傾向がどのように変化するかに基づいてモデルを更新する必要があります。
可能であれば、自動テストを使用して、モデルのライフ サイクルにわたってモデルの減衰を検出して評価します。 モデルで不連続値を予測する場合は、時間の経過と同時にそれらの値に対する予測を評価し、予想される結果と実際の結果の間の偏差を測定するテストを作成できます。 概要統計と距離メトリックを比較することで、時間の経過に伴うドリフトを検出する監視を使用して、このテストを補完します。
モデルの減衰を特定するもう 1 つの一般的なアプローチは、ユーザーフィードバックです。 ユーザーフィードバックの例として、サムアップまたはサムダウン応答メカニズムがあります。 時間の経過と共に肯定的なフィードバックと否定的なフィードバックを追跡し、否定的なフィードバックのしきい値を満たしたときにアラートを作成すると、モデルの品質を調査するタイミングを把握するのに役立ちます。
モデルの減衰を識別するために使用するシグナルに関係なく、潜在的な減衰について警告される運用チームは、データ サイエンティストに信号を調査し、減衰が発生しているかどうかと根本原因を判断する必要があります。
ツールを実装する
Azure Machine Learning データ コレクターを使用して、マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイントにデプロイされたモデルから入力データと出力データのリアルタイム ログを取得します。 Machine Learning は、ログに記録された推論データを Azure Blob Storage に格納します。 その後、このデータをモデルの監視、デバッグ、または監査に使用できます。これにより、デプロイされたモデルのパフォーマンスを監視できます。 Machine Learning の外部または Machine Learning バッチ エンドポイントにモデルをデプロイする場合、データ コレクターを利用できないため、別のデータ収集プロセスを運用化する必要があります。
Machine Learning モデルの監視を使用して監視を実装します。 Machine Learning は、ストリーミングされた運用環境の推論データと参照データに対して統計計算を実行することで、監視シグナルを取得します。 参照データには、履歴トレーニング データ、検証データ、またはグラウンド トゥルース データが含まれる場合があります。 一方、運用推論データは、運用環境で収集されたモデルの入出力データを指します。
- Machine Learning の監視機能とメトリックをキャプチャして分析する方法についてはMachine Learning モデルの監視に関するページを参照してください。
- 監視に関するその他の推奨事項についてはベスト プラクティスを参照してください。