この記事では、モデルの評価とシステム全体のテストという 2 つの異なる側面に焦点を当てています。 評価とテストは同じ意味で使用されることが多いですが、個別のデータセットを使用する個別のプロセスと見なす必要があります。
評価 は、開発フェーズ中に行う反復的なアクティビティです。 適切なレベルのチューニングで最適なモデルを見つけるための実験に焦点を当てています。 次に、さまざまなメトリックに基づいてモデルを評価します。
テスト には、チューニングされたモデルや AI 以外のコンポーネントなど、変更が導入されたときにシステム全体を検証することが含まれます。 目標は、ワークロードが特定されたターゲットを満たし、ユーザーの期待を満たしているかどうかを検証することです。 また、品質回帰を防ぐ、交渉不可能な変更管理戦略でもあります。
どちらのプラクティスも、実際の実装で結合されます。 プロセス全体には、モデルへの要求の送信、応答の評価、テスト データに基づく決定の実行または no-go が含まれます。 このプロセスは生産前に交渉できませんが、実際のデータと合成データを組み合わせて運用環境でプロセスを実行することをお勧めします。
ここでの主な焦点は、ジェネレーティブ AI を使用して構築されたソリューション、特に基礎モデルを使用するシナリオです。 モデルのトレーニングと微調整に適用できるガイダンスについては、モデルの トレーニングと微調整をテストするためのガイダンスに進んでください。
モデル評価に品質メトリックを使用する
ビジネス目標に合ったメトリックを使用して、ベースラインを確立し、モデルの品質を測定します。
一連のメトリックに対してユーザー エクスペリエンスの結果を評価および定量化するプロセスを作成します。 たとえば、 Groundedness は、生成モデルの応答が、製造ではなく、提供されたコンテキストでサポートされているかどうかを評価します。 ある法律事務所が、法令を引用する AI アシスタントを開発しているとします。 適切な検証がないと、古いドキュメントや誤って分類されたドキュメントから引き出され、重大な結果が生じる可能性があります。 接地度スコアが高い場合は、モデルの出力が信頼できるソース マテリアルに合わせて維持されます。
特定のユース ケースに基づいてメトリックを選択して優先順位を付け、継続的に監視し、モデルのチューニングとデプロイの意思決定ゲートとして使用します。 単一のメトリックに依存しないようにし、組み合わせを使用して品質のさまざまなディメンションをキャプチャします。 たとえば、モデルが強い接地性を示している場合でも、バイアス出力が生成される可能性があります。 公平性の評価を組み込んで、よりバランスのとれた責任ある結果を得る。
メトリックの詳細については、 監視評価メトリックの説明とユース ケースに関するページを参照してください。
適切なデータを評価に使用する
評価データを使用して反復的なプロセスを通じてモデルを調整します。 ゴールデン データセットと呼ばれるこの データセット は、信頼された入力と出力のペアで構成され、通常は人間によって作成または検証されます。 これは、定義された品質メトリックに対してモデルのパフォーマンスを評価するための客観的なベンチマークとして機能します。
データセットがドメインまたはタスクを代表し、多様で高品質な例と最小限のノイズがあることを確認します。 サンプル サイズが限られていると、評価品質が低下する可能性があるため、サンプル データに十分な多様性やカバレッジがないため、バランスと完全性を向上させるために合成データを生成することを検討してください。
エージェント ワークフローを検証する
アーキテクチャが AI を使用するように進化するにつれて、決定論的コードによってかつて処理されていた機能が AI エージェントにオフロードされるようになりました。 これらのエージェントは、多くの場合、動的な動作で意思決定を行います。
オーケストレーター自体がエージェントとして実装されているエージェント アプリケーションを考えてみましょう。 従来のオーケストレーションとは異なり、エージェントはツールを呼び出し、プロンプトを解釈し、他のエージェントと共同作業を行い、リアルタイムで適応できるため、柔軟性が高くなりますが、検証が困難になります。
この種類のアーキテクチャでは、テストと評価に関する新しい課題が導入されています。 エージェントは非決定的に動作するため、従来の静的テストでは不十分です。 テスト戦略では、ユーザー入力から最終的な応答までの完全なフローを検証する必要があります。 これには、グラウンド データの 取得、ツールの呼び出し、応答の生成が含まれます。 たとえば、
エージェントが外部ツール、API、およびその他のエージェントを正しく呼び出していることを確認します。 モック依存関係を使用して、データが正しく渡されていることを検証します。 ツールまたはエージェントの障害をシミュレートして、動作の信頼性をテストします。
定義済みのプロンプトと予想される出力を使用して、シナリオベースのテストを設計します。 出力は異なる場合があるため、別のモデルで自動スコアリングを使用して結果を評価します。 また、特に機密性の高いタスクや主観的なタスクには、人間ベースのレビューを使用します。
コンテンツの安全性ツールを統合して、有害な出力、偏った出力、または不適切な出力を検出します。 赤いチーミングの演習を含め、予期しない動作や脱獄の脆弱性を特定します。 公平性、透明性、倫理基準への準拠を監視します。
ツールの観点から、次のようなチェックをサポートする Azure AI Evaluation SDK を検討してください。
- 意図の解決: エージェント/オーケストレーターはユーザーの要求を正しく理解していますか?
- ツール呼び出しの精度: 適切なパラメーターを使用して、正しいツールが呼び出されていますか?
- タスクの準拠: 最終的な出力は、割り当てられたタスクと以前の推論手順と一致していますか?
さらに、定期的なパフォーマンスとロード テストを実施します。 同時要求の下でスケーリングし、長い実行パスを処理し、複数のエージェント間の対話を管理するエージェントの能力を評価します。 システムが反復的なリリースを通じて進化するにつれて、ロジックとパフォーマンスの両方で回帰を継続的に監視します。
セキュリティの側面をテストする
アクセスの制御、すべての入力の検証、エージェントの動作の監視によってエージェントワークフローをセキュリティで保護し、誤用や意図しないアクションを防ぎます。
脱獄テスト。 常に脱獄の試行をテストします。 攻撃者は通常、最初にオーケストレーション レイヤーをターゲットにし、要求を解析してモデルに転送します。 悪意のある入力がフィルター処理されないと、モデルの動作が損なわれる可能性があります。
コンテンツの安全性。 チャット ベースのアプリケーションでは、ユーザー プロンプトとグラウンド コンテキストの両方をコンテンツ セーフティ サービスを通じて実行します。
エンドポイントのセキュリティ。 RESTful インターフェイスの場合は、強力な認証を適用し、承認されていないアクセスを防ぐためにセキュリティ制御を十分にテストします。
Scikit-learn、PyTorch の torch.testing モジュール、バイアスと公平性テスト用の FairML、モデル評価用の TensorFlow モデル分析など、他にもオープン ソース ライブラリがあります。
トレードオフ。 このコードをテストすると、コストに影響があります。 たとえば、Azure OpenAI を使用して推論エンドポイントをホストする場合、ストレス テストはシステムの制限を判断するのに役立つ一般的な方法です。 ただし、Azure OpenAI は呼び出しごとに課金されるため、大規模なストレス テストが高価になる可能性があります。 料金を最適化する 1 つの方法は、テスト環境で Azure OpenAI の未使用の PTU を使用することです。 または、 Dev Proxy などのツールを使用して推論エンドポイントをシミュレートすることもできます。
決定論的な動作をテストする
一部のアーキテクチャでは、決定論的ロジックを使用してオーケストレーションを有効にすることができます。 たとえば、非決定論的エージェント オーケストレーターの代わりに、静的コードを使用して実行フローを管理するオーケストレーターを選択できます。たとえば、ユーザーの意図の解釈、インデックスに対するデータの接地のクエリ、モデル 推論エンドポイントの呼び出しなどです。
テストの観点から、このコードは、パフォーマンス、信頼性、機能テスト (特にそのルーティング ロジック) を実行するという重要なシステム コンポーネントと同様に扱います。 特に Microsoft のセマンティック カーネル や LangChain などのエージェント フレームワークを使用している場合は、決定論的コンポーネントに単体テストを適用します。 これらのテストでは、実行時の変動から分離されたプロンプト テンプレート、ツール選択ロジック、データ書式設定、デシジョン ツリーが検証されます。
推論エンドポイントをテストする
推論エンドポイントは、REST API を介して生成モデルを公開し、モデルの正確さを超えてテストする必要があります。 PaaS プラットフォームまたはセルフホステッド サーバーのどちらを使用している場合でも、他のエンドポイントと同様にエンドポイントをテストして、信頼性、スケーラビリティ、およびセキュリティを確保します。
機能と統合のテスト。 要求処理、応答構造、および他のコンポーネントとの統合を検証します。
パフォーマンスとロード テスト。 現実的な条件をシミュレートして、スループット、待機時間、およびリソースの使用状況を評価します。 PaaS 推論エンドポイントの場合は、トークン レベルのメトリック (トークン/秒またはトークン/分) に重点を置きます。これは、REST API の従来の要求サイズよりも意味があります。
スケーリングと GPU の最適化。 さまざまな負荷でテストして、適切な GPU SKU または自動スケール構成を決定します。 実際の GPU 使用率を監視することで、オーバープロビジョニングを回避します。
Trade-off. GPU SKU は高価です。 GPU リソースが過小使用されているかどうかを継続的に確認し、可能な場合は適切なサイズにすることが重要です。 調整を行った後、リソースの使用状況をテストして、コスト効率とパフォーマンスの最適化のバランスを維持します。エラー処理。 HTTP 429 エラー、バックエンド タイムアウト、サービス利用不可などの調整をシミュレートします。 クライアントが再試行、バックオフ、および回線切断を適切に処理することを検証します。
セキュリティとコンテンツの安全性。 パブリックまたはセルフホステッド エンドポイントの場合は、侵入テストを実行し、アクセス制御を検証します。 Azure AI Content Safety などのコンテンツ モデレーション ツールを使用して、安全でない入力/出力をテストおよびフィルター処理します。
グラウンド データ ワークフローをテストする
生成型 AI モデルの関連性は、 その接地データの品質と整合性に依存します。 接地データは、データ処理パイプラインを使用してモデルにシード処理できます。 このデータは、モデルに到達する前に前処理、チャンク、およびインデックスが作成されます。 このモデルは、ユーザー操作中にインデックスにリアルタイムでクエリを実行し、インデックス作成のパフォーマンスと精度をユーザー エクスペリエンスに不可欠なものにします。 テストを早期に統合し、システム ライフサイクル全体にわたって維持します。
テストが不十分なデータ パイプラインは、一貫性のない結果や、セキュリティ侵害などの横断的な懸念につながる可能性があります。 高品質のエクスペリエンスを確保するには、ソース ドキュメント、前処理、オーケストレーション ロジック、インデックス自体など、データ フロー全体をテストします。 主なテストに関する考慮事項は次のとおりです。
機能と統合のテスト。 すべてのデータが正しく完全に読み込まれることを検証します。 パイプラインで、不足しているデータ、空のデータ、または合成データが想定どおりに処理されていることを確認します。
インデックス スキーマの互換性。 下位互換性を確保するためにスキーマの変更をテストします。 フィールドまたはドキュメントの変更は、以前のデータ形式のサポートを保持する必要があります。
前処理とオーケストレーションのテスト。 グラウンド データの準備には、前処理、チャンク、埋め込みの計算が含まれます。多くの場合、Azure AI Search スキル セットなどのツールによって調整されます。 オーケストレーション パイプラインをテストして、すべてのステップが正しく実行され、結果のデータが正確で関連性があることを確認します。
データの鮮度と品質チェック。 古いデータ、バージョン管理の不一致、合成成果物、空または部分的なテーブルのテストを含めます。 必要に応じてクエリまたはインデックス設定を更新して、最新のクリーン なデータを反映します。
インデックスのロード テスト。 インデックスは、さまざまな負荷の下で動作が異なる場合があります。 現実的な使用シナリオに対してクエリのパフォーマンスをテストし、スケーリング、コンピューティング SKU、ストレージ要件に関する決定を通知します。
セキュリティ テスト。 ドキュメントがアクセス制御でパーティション分割されている場合は、それらの制御を厳密にテストします。 各ユーザーまたはロールが、機密性とコンプライアンスを維持するために許可されたコンテンツにのみアクセスすることを確認します。
モデルのトレーニングと微調整をテストするためのガイダンス
生成 AI モデルと同様に、開発ライフサイクルのさまざまな段階で、さまざまなシステム コンポーネントとフローにわたって、さまざまな種類のテストを使用します。 実用的なのと同じくらい、テストを念頭に置いてワークロード資産を開発します。 たとえば、データ操作を実行し、特徴エンジニアリング用のソース データを整形する場合は、適切なコーディングプラクティスに従い、テストをサポートするようにコードを構成します。
モデルを評価する
モデルのトレーニング中に基本計画戦略を適用して、モデルの品質を測定および比較します。 適切に定義されたメトリックを使用して、モデル、パラメーター、および特徴のさまざまな組み合わせのパフォーマンスを評価します。 これらのメトリックは、パフォーマンスの高いモデルを特定するために、バージョンと構成間で繰り返し比較できる、客観的なデータドリブン スコアを提供します。
詳細については、「 回帰/予測メトリック」を参照してください。
評価およびテストするデータ
ソース データを 3 つの異なるデータセット (トレーニング、評価、テスト) に分割します。 トレーニング データセットを使用してモデルを構築し、評価データセットを調整し、テスト データセットを使用して最終的なパフォーマンスを検証します。
ノイズを減らすために、各データセットに高品質のデータが含まれていることを確認します。 データ パイプラインのテスト ケースを使用して品質を適用し、実際のサンプルが限られている場合は合成データを補完します。不正検出などのドメインでは、実際の不正行為のインスタンスがまれで、信頼性の高いモデルをトレーニングするための限られたデータが提供されます。
すべてのデータセットを分離し、重複しないようにして、客観性を維持し、予測の偏りを防ぎます。 テスト用の評価データまたは評価データにトレーニング データを再利用しないでください。
トレーニングと微調整のワークフローのテスト
データ パイプライン テクノロジ。 合成データを使用して機能テスト、負荷テスト、パフォーマンス テストを組み合わせてスケーラビリティを評価し、サイズや製品の適合性、必要な SKU、システム統合に関する情報に基づいた意思決定を行います。
インジェスト ワークフロー。 ETL/ELT パイプラインをエンドツーエンドでテストして、データが確実に取り込まれていることと、データが高品質であることを確認します。 また、接続されているすべてのシステムとの統合をテストし、外部の依存関係を監視します。 合成データを使用して、特に複雑または大量のワークロードに対して、エンドツーエンドの処理を検証します。
スケジュールされたジョブをテストして、インジェスト タスクが時間通りに完了し、予想されるボリュームが返されることを検証します。
インジェストのデータ品質。 データのクレンジングと処理に、データ操作が意図したとおりに機能することを確認するテストが含まれているかどうかを確認します。 完全性、鮮度、スキーマの一貫性、一意性、関連性のチェックを含めます。 また、重複、欠損値、または無効なエントリなしで構造化データが取り込まれることも確認します。
機能とラベルの整合性。 フィーチャが正しく計算され、ラベルが正確に割り当てられていることを検証します (特に複雑なルールを使用する場合)。 将来またはラベルから派生した情報がトレーニング データを汚染しないように、データ漏えいがないか確認します。 また、微妙な漏れでもモデルのパフォーマンスが損なわれる可能性があるため、データ分割が、偏ったサンプルや重複するサンプルを避けるために適切であることを確認します。
ハイパーパラメーター テスト。 ハイパーパラメーター テストは、ワークロードのユース ケースに基づいて精度の目標を満たすようにモデル パラメーターを調整する反復的なプロセスです。 これには、選択したデータに対するトレーニングと、パフォーマンスを検証するためのテスト データの評価が繰り返し含まれます。 より小さいデータセットから始めて、モデルの動作をすばやく評価し、テストを完全なセットにスケーリングします。 モデルの精度と、繰り返しのトレーニングと評価に必要な計算コストと時間のトレードオフに注意してください。
コードの品質。 PyTorch スクリプトなどのカスタム コードを使用してモデルをトレーニングする場合は、設計フェーズ中にロード テストを実行してコンピューティング要件を評価し、適切な SKU を選択します。 単体テストを使用して開発中に回帰をキャッチし、自動化が不可能な場合は手動テストに依存します。 これらのスクリプトはワークフロー内で実行されるため、統合テストを追加して、パイプライン内でスクリプトが確実に実行されることを確認します。
推論エンドポイント。 この REST API は、予測を行うためにトレーニング済みの機械学習モデルへのアクセスを提供します。 モデルは、リアルタイムまたはバッチ入力データを受信し、処理し、予測を返すことができるエンドポイントを持つ環境にデプロイされます。 他の API と同様に、推論エンドポイントが機能、パフォーマンス、およびセキュリティ テストを受け、正確な結果を返し、予想される負荷を処理し、誤用から安全なままであることを確認します。
ライブ サイト テスト。 機能テストをライブ システムに拡張します。 スケジュールされたテストを実行して、データ ボリュームを検証し、レコードの欠落または重複を検出し、データの鮮度を確認します。 合成データを使用して、運用環境でのエンドツーエンドの変換とロジックを安全に検証します。 A/B テストを組み込んで新しいエクスペリエンスを評価し、完全なデプロイの前に品質の回帰を防ぎます。 テストが失敗したときにすぐに調査をトリガーするようにアラートを構成します。
特にコードの変更やパイプラインの更新中に単体テストと機能テストを自動化することで、データ テストを CI/CD パイプラインに統合します。 再トレーニングの前に品質チェックを追加し、サイド バイ サイドデプロイを使用して運用環境で安全にテストします。 テストエラーまたはインジェストの異常に対するアラートを設定します。
Note
テストと監視は、さまざまな目的に役立ちます。 通常、変更を実装する前に、システムに対する潜在的な変更を評価するテストを実施します。 継続的に監視を実施して、システムの全体的な正常性を評価します。
モデルの減衰のテスト
ワークロードの内部および外部の変更により、すべてのモデルが時間の経過と同時に低下します。 モデルの減衰と呼ばれるモデル品質の低下は、次の 2 つの方法で発生する可能性があります。
データ ドリフト は、入力データが変更され、モデルが古くなった場合に発生します。 たとえば、投票パターンを予測するモデルは、再入後の人口統計の変化により無関係になります。
概念ドリフト は、外部条件が変化したときに発生し、モデルの予測が現実を反映しなくなります。 たとえば、売上傾向を予測するモデルは、競合他社が新製品を発売した後に消費者の行動に変化があるため、無関係になります。
減衰を検出するには、自動テストを使用して実際の結果と予測を比較し、統計メトリックを使用して誤差を監視します。 たとえば、サムを上下に使用するユーザー フィードバックは、問題を特定するための重要なシグナルでもあります。 潜在的な減衰が検出されると、運用チームはデータ サイエンティストに警告して、根本原因と次の手順を調査して特定する必要があります。
テスト ツール
次の Azure リソースを検討してください。
マネージド または Kubernetes オンライン エンドポイントにデプロイされたモデルの入力/出力データをリアルタイムでログ記録するための Azure Machine Learning データ コレクター。
リアルタイムの推論データと参照データセットを比較してドリフトやその他のパフォーマンス メトリックを追跡することで、自動化された監視のための Azure Machine Learning モデル監視。 その他の推奨事項については、 ベスト プラクティス を参照してください。