この投稿は、Intuit Machine Learning Platform のソフトウェア エンジニアリング マネージャーである Tobias Wenzel と共同執筆しました。
たとえば、自動運転を使用したり、Alexa と対話したりする場合、高品質で信頼性の高い機械学習 (ML) モデルの重要性を誰もが認識しています。 ML モデルは、ビジネス アプリケーション、ヘルスケア、金融機関、amazon.com、TurboTax などでも使用されています。
ML 対応アプリケーションが多くのビジネスの中核になるにつれて、モデルはソフトウェア アプリケーションと同じ活力と規則に従う必要があります。 MLOps の重要な側面は、テスト、バージョン管理、継続的デリバリー、モニタリングなどの確立された DevOps プラクティスを使用して、以前に開発された ML モデルの新しいバージョンを本番環境に提供することです。
いくつかある 規範的 MLOps に関するガイドラインを参照してください。この投稿では、従うことができるプロセスの概要と、テストに使用するツールについて説明します。 これは、間のコラボレーションに基づいています。 インテュイット そしてAWS。 私たちは、この投稿で説明した推奨事項を実際に大規模に実装するために協力してきました。 になるという Intuit の目標 AI 駆動のエキスパート プラットフォーム は、初期モデル開発と新しいバージョンのテストの速度を上げるという戦略に大きく依存しています。
要件
新しいモデル バージョンを展開する際の主な考慮事項は次のとおりです。
- モデル精度性能 – することが重要です 追跡する 精度、精度、再現率などのモデル評価指標を分析し、目的の指標が比較的同じままであるか、モデルの新しいバージョンで改善されていることを確認します。 ほとんどの場合、モデルの新しいバージョンをデプロイしても、エンド ユーザーのエクスペリエンスが改善されなければ意味がありません。
- テストデータの品質 – シミュレートされたものかポイント イン タイム コピーかに関係なく、非実稼働環境のデータは、ボリュームまたは分布に関して、モデルが完全に展開されたときに受け取るデータを代表するものである必要があります。 そうでない場合、テスト プロセスは代表的なものではなく、モデルは本番環境で異なる動作をする可能性があります。
- 機能の重要性とパリティ – モデルの新しいバージョンの機能の重要性は、古いモデルと相対的に比較する必要がありますが、新しい機能が導入されている可能性があります。 これは、モデルが偏らないようにするためです。
- ビジネス プロセスのテスト – 新しいバージョンのモデルが、必要なビジネス目標を許容範囲内で満たすことができることが重要です。 たとえば、ビジネス メトリクスの 100 つは、サービスのエンドツーエンドのレイテンシが 10,000 ミリ秒を超えてはならない、または特定のモデルをホストして再トレーニングするためのコストが年間 XNUMX ドルを超えてはならないというものです。
- 費用 – テストへの簡単なアプローチは、実稼働環境全体をテスト環境として複製することです。 これは、ソフトウェア開発の一般的な方法です。 ただし、ML モデルの場合、このようなアプローチでは、データのサイズによっては適切な ROI が得られない可能性があり、対処するビジネス上の問題に関してモデルに影響を与える可能性があります。
- セキュリティ – 多くの場合、テスト環境には、実際の顧客データではなくサンプル データが想定されます。その結果、データ処理とコンプライアンス ルールの厳格さが緩和される可能性があります。 ただし、コストと同様に、運用環境をテスト環境に単純に複製すると、セキュリティとコンプライアンスのリスクが生じる可能性があります。
- フィーチャ ストアのスケーラビリティ – 組織が、コストまたはセキュリティ上の理由から、別のテスト機能ストアを作成しないことにした場合、モデル テストを運用機能ストアで行う必要があります。これにより、テスト期間中にトラフィックが XNUMX 倍になるため、スケーラビリティの問題が発生する可能性があります。
- オンライン モデルのパフォーマンス – オンライン評価はオフライン評価とは異なり、知覚される満足度ではなくリアルタイムでユーザー満足度を測定するため、推奨モデルなどの場合に重要になる場合があります。 季節性やその他のユーザーの行動により、本番環境以外で実際のトラフィック パターンをシミュレートすることは難しいため、オンライン モデルのパフォーマンスは本番環境でのみ行うことができます。
- 運用パフォーマンス – モデルが大きくなり、さまざまなハードウェアに分散化された方法でデプロイされることが増えるにつれて、レイテンシー、エラー率などの目的の運用パフォーマンスについてモデルをテストすることが重要です。
ほとんどの ML チームは、モデル テストに対して多面的なアプローチを採用しています。 次のセクションでは、さまざまなテスト段階でこれらの課題に対処する方法を示します。
オフライン モデル テスト
このテスト フェーズの目標は、精度の観点から既存のモデルの新しいバージョンを検証することです。 これは、リアルタイム予測を提供している本番システムの予測に影響を与えないように、オフラインで行う必要があります。 このテストでは、該当する評価指標に対して新しいモデルのパフォーマンスが向上することを確認することで、課題 1 (モデルの精度のパフォーマンス) に対処します。 また、適切なデータセットを使用することで、このテストは課題 2 と 3 (テスト データの品質、機能の重要性、パリティ) に対処でき、課題 5 (コスト) に取り組むという追加の利点もあります。
このフェーズは、ステージング環境で行われます。
オフラインのバックテストで再生するために使用できる本番トラフィックをキャプチャする必要があります。 合成データではなく、過去の実動トラフィックを使用することをお勧めします。 の Amazon SageMakerモデルモニター キャプチャデータ機能 でホストされているモデルの本番トラフィックをキャプチャできます アマゾンセージメーカー. これにより、モデル開発者は、ピーク営業日やその他の重要なイベントのデータを使用してモデルをテストできます。 キャプチャされたデータは、次を使用してバッチ方式で新しいモデル バージョンに対して再生されます。 Sagemaker バッチ変換. これは、数週間または数か月にわたって収集されたデータを使用して、バッチ変換の実行をわずか数時間でテストできることを意味します。 これにより、リアルタイム モデルの XNUMX つ以上のバージョンを並べて実行し、各エンドポイントに重複した予測リクエストを送信する場合と比較して、モデル評価プロセスを大幅に高速化できます。 このアプローチでは、パフォーマンスの高いバージョンをより迅速に見つけることができるだけでなく、コンピューティング リソースを使用する時間も短縮され、全体的なコストが削減されます。
このテスト アプローチの課題は、機能セットがモデル バージョンごとに変わることです。 このシナリオでは、両方のバージョンの機能のスーパーセットを含む機能セットを作成して、すべての機能を一度にクエリし、データ キャプチャを通じて記録できるようにすることをお勧めします。 その後、各予測呼び出しは、モデルの現在のバージョンに必要な機能のみで機能します。
追加のボーナスとして、統合することにより Amazon SageMaker の明確化 オフライン モデル テストでは、新しいバージョンのモデルのバイアスをチェックし、機能の属性を以前のバージョンのモデルと比較することもできます。 パイプラインを使用すると、トレーニング後に品質チェック手順を実行してモデルのメトリックと機能の重要性を分析できるように、ワークフロー全体を調整できます。 これらの指標は SageMakerモデルレジストリ トレーニングの次の実行での比較のために。
統合とパフォーマンスのテスト
統合テストは、機能面とランタイム パフォーマンスの観点からエンド ツー エンドのビジネス プロセスを検証するために必要です。 このプロセス内で、フィーチャ ストア内のフィーチャのフェッチ、計算、ML アプリケーションの実行など、パイプライン全体をテストする必要があります。 これは、さまざまなシナリオと要求をカバーし、考えられるすべてのコード実行に対して高いカバレッジを実現するために、さまざまなペイロードで実行する必要があります。 これにより、課題 4 と 9 (ビジネス プロセスのテストと運用パフォーマンス) に対処し、新しいバージョンのモデルでビジネス プロセスが壊れないようにします。
このテストは、ステージング環境で行う必要があります。
統合テストとパフォーマンス テストはどちらも、MLOps パイプラインを使用して個々のチームが実装する必要があります。 統合テストについては、機能的に同等の運用前環境を維持し、いくつかの異なるペイロードでテストする、実証済みの方法をお勧めします。 に示すように、テスト ワークフローを自動化できます。 このワークショップ. パフォーマンス テストでは、次を使用できます。 AmazonSageMaker推論レコメンダーこれは、どのインスタンス タイプと、それらのインスタンスをいくつ使用するかを決定するための優れた出発点となります。 このためには、オープンソース プロジェクトなどのロード ジェネレーター ツールを使用する必要があります。 perfsizesagemaker & パーフサイズ Intuit が開発したものです。 Perfsizesagemaker を使用すると、さまざまなペイロード、応答時間、および XNUMX 秒あたりのピーク トランザクションの要件を使用して、モデルのエンドポイント構成を自動的にテストできます。 異なるモデル バージョンを比較する詳細なテスト結果を生成します。 Perfsize は、XNUMX 秒あたりのピーク トランザクション数と予想される応答時間のみを考慮して、さまざまな構成を試すコンパニオン ツールです。
A / Bテスト
e コマース アプリケーションなど、モデルの即時出力に対するユーザーの反応が必要な多くの場合、オフライン モデル機能評価では十分ではありません。 これらのシナリオでは、モデルの更新を決定する前に、本番環境でモデルを A/B テストする必要があります。 実際の顧客への影響がある可能性があるため、A/B テストにはリスクもあります。 このテスト方法は、軽量のエンジニアリング サニティ チェックである最終的な ML パフォーマンス検証として機能します。 この方法は、課題 8 と 9 (オンライン モデルのパフォーマンスと運用の卓越性) にも対処します。
A/B テストは本番環境で実行する必要があります。
SageMaker を使用すると、ML モデルで A/B テストを簡単に実行できます。 複数の生産バリアント エンドポイントで。 トラフィックを新しいバージョンに段階的にルーティングして、動作の悪いモデルが本番環境に及ぼすリスクを軽減できます。 A/B テストの結果が良さそうであれば、トラフィックは新しいバージョンにルーティングされ、最終的にトラフィックの 100% が引き継がれます。 モデル A から B に移行するには、デプロイ ガードレールを使用することをお勧めします。 Amazonパーソナライズ 例としてモデルを参照してください。 A / Bテストを使用して、Amazon Personalizeによって生成された推奨の効果を測定する.
オンライン モデル テスト
このシナリオでは、モデルの新しいバージョンは、本番環境でライブ トラフィックを処理しているモデルとは大きく異なるため、オフライン テストのアプローチは、新しいモデル バージョンの有効性を判断するのに適していません。 これの最も顕著な理由は、予測を生成するために必要な機能が変更されたため、以前に記録されたトランザクションをモデルのテストに使用できなくなったことです。 このシナリオでは、シャドウ デプロイを使用することをお勧めします。 シャドウ デプロイメントは、シャドウ (または 挑戦者) プロダクション (または チャンピオン) 現在予測を提供しているモデル。 これにより、本番トラフィックでシャドウ モデルがどのように機能するかを評価できます。 シャドウ モデルの予測は、要求元のアプリケーションには提供されません。 オフライン評価のためにログに記録されます。 テストのためのシャドウ アプローチにより、課題 4、5、6、および 7 (ビジネス プロセスのテスト、コスト、セキュリティ、フィーチャ ストアのスケーラビリティ) に対処します。
オンライン モデル テストは、ステージング環境または運用環境で行う必要があります。
新しいモデル バージョンをテストするこの方法は、他のすべての方法を使用できない場合の最後の手段として使用する必要があります。 複数のモデルへの呼び出しを二重化すると、本番環境のすべてのダウンストリーム サービスに追加の負荷が発生し、パフォーマンスのボトルネックや本番環境のコストの増加につながる可能性があるため、最後の手段としてこれをお勧めします。 これがもたらす最も明白な影響は、フィーチャ サービス レイヤーにあります。 物理データの共通プールから機能を共有するユース ケースの場合、同じデータ テーブルに同時にアクセスする複数のユース ケースをシミュレートして、本番環境に移行する前にリソースの競合が存在しないことを確認できる必要があります。 可能な限り、機能ストアへのクエリの重複を避ける必要があり、モデルの両方のバージョンに必要な機能を XNUMX 番目の推論に再利用する必要があります。 に基づいたフィーチャー ストア Amazon DynamoDB、Intuitが構築したものとして、実装できます Amazon DynamoDB アクセラレータ(DAX) を使用してキャッシュし、データベースへの I/O が 7 倍になるのを回避します。 これらおよびその他のキャッシング オプションは、課題 XNUMX (フィーチャ ストアのスケーラビリティ) を軽減できます。
課題 5 (コスト) と課題 7 に対処するために、シャドウ デプロイを使用して着信トラフィックをサンプリングすることを提案します。 これにより、モデルの所有者は、生産システムへの影響を最小限に抑えるための別の制御層を得ることができます。
シャドウ デプロイメントは、 モデルモニター チャレンジャー バージョンの改善を観察するために、通常の本番環境の展開と同様にオファリングを行います。
まとめ
この投稿では、モデルのテストに関するさまざまな課題に対処するための包括的な一連のプロセスとツールを作成するためのビルディング ブロックについて説明します。 すべての組織は独自のものですが、これは、独自のテスト戦略を実装する際に開始し、考慮事項を絞り込むのに役立ちます。
著者について
トバイアス・ウェンゼル カリフォルニア州マウンテン ビューにある Intuit 機械学習プラットフォームのソフトウェア エンジニアリング マネージャーです。 彼は 2016 年の開始以来、プラットフォームに取り組んでおり、ゼロからの設計と構築を支援してきました。 彼の仕事では、プラットフォームの運用上の卓越性に焦点を当て、Intuit の季節的なビジネスを通じて成功を収めてきました。 さらに、彼は最新のテクノロジーを使用してプラットフォームを継続的に拡張することに情熱を注いでいます。
シヴァンシュ・ウパディヤイ AWS ビジネス開発および戦略的産業グループのプリンシパル ソリューション アーキテクトです。 この役割では、AWS の最も高度な採用者がデータと AI を効果的に使用して業界を変革するのを支援しています。
アランタン SageMaker のシニア プロダクト マネージャーであり、大規模なモデルの推論に取り組んでいます。 彼は機械学習を分析の分野に適用することに情熱を注いでいます。 仕事以外では、アウトドアを楽しんでいます。
