このドキュメントでは、機械学習（ML）ソリューションの品質の評価、保証、管理に役立つガイドラインをいくつか説明します。ML モデルの開発から、トレーニング システムとサービング システムの本番環境へのデプロイまで、プロセスのすべてのステップについての提案を提供します。このドキュメントでは、MLOps の実践的な運用ガイドで説明されている情報を拡張し、MLOps ライフサイクルの各プロセスにおける品質面に焦点を当てて明確にします。
このドキュメントは、ML ソリューションの構築、デプロイ、運用に関与するすべての方を対象としています。このドキュメントは、MLOps 全般に精通されていることを前提としています。特定の ML プラットフォームに関する知識をお持ちであることは前提としていません。
ML ソリューションの品質の概要
ソフトウェア エンジニアリングでは、ソフトウェアの品質を確保するために多くの標準、プロセス、ツール、プラクティスが開発されています。その目的は、ソフトウェアが本番環境で想定どおりに動作し、機能面の要件と機能面以外の要件の両方を確実に満たしているようにすることです。これらのプラクティスでは、ソフトウェアのテスト、ソフトウェアの検証と検証、ソフトウェアのロギングとモニタリングなどのトピックを扱います。DevOps では通常、これらのプラクティスが CI / CD プロセスに統合され、自動化されています。
MLOps は、ML システムを迅速かつ確実にビルド、デプロイ、運用化するための、標準化されたプロセスおよび機能のセットです。他のソフトウェア ソリューションと同様に、ML ソフトウェア ソリューションでもこれらのソフトウェア品質プラクティスを統合し、MLOps のライフサイクル全体に適用する必要があります。これらのプラクティスを適用することで、モデルの信頼性と予測可能性を確保でき、モデルが確実に要件を満たします。
ただし、ML システムの構築、デプロイ、運用のタスクには、他のソフトウェア システムとは関係のない特定の品質手法を必要とする追加の課題が伴います。他のほとんどのソフトウェア システムの特性に加えて、ML システムには次の特性があります。
データに依存するシステム。トレーニング済みモデルの品質とその予測の品質は、トレーニングに使用されるデータと、予測リクエストのために送信されるデータの有効性に左右されます。ソフトウェア システムは有効なデータに依存していますが、ML システムはデータから意思決定のロジックを自動的に推測するため、データの品質に特に依存します。
デュアル トレーニング サービング システム。ML ワークロードは通常、トレーニング システムとサービング システムという 2 つの異なるが関連性のある本番環境システムで構成されます。継続的なトレーニング パイプラインでは、新しくトレーニングされたモデルが生成されます。生成されたモデルは予測サービングのためにデプロイされます。本番環境で性能の高いモデルを生成して維持するには、有効性と効率性のバランスを取るためのさまざまな品質手法が各システムに必要です。さらに、この 2 つのシステムの間に不整合があると、エラーが発生して予測性能が低下します。
陳腐化しやすい。モデルは、本番環境にデプロイされた後に劣化することがよくあります。これは、モデルがその環境の変化（購入行動の季節的な変更など）に適応できないためです。また、新しい製品や新しい場所などのデータの変化にモデルが適応できない場合もあります。したがって、本番環境でモデルの有効性を追跡することが ML システムのもう 1 つの課題です。
自動化された意思決定システム。他のソフトウェア システムでは一連の要件やビジネスルールに対するアクションが手動で慎重にコーディングされていますが、ML モデルは意思決定のためのルールをデータから学習します。データに暗黙のバイアスがあると、モデルが不当な結果をもたらす可能性があります。
デプロイされた ML モデルで不適切な予測が生成される場合、さまざまな問題が原因で ML の品質が低下する可能性があります。一部の問題は、あらゆるプログラムにある典型的なバグが原因で発生する可能性があります。ただし、ML 固有の問題には、トレーニング プロセスの一部としての適切なモデル評価および検証手順の欠如に加えて、データの偏りや異常も含まれる可能性があります。また、モデルの組み込みインターフェースとサービス提供 API の間でデータ形式に不整合が生じることもあります。さらに、このような問題がない場合でも、モデルの性能は時間の経過とともに低下します。モデルが適切にモニタリングされていない場合は、障害が発生しても何も通知されないことがあります。したがって、開発段階、デプロイ段階、本番環境のそれぞれの段階で、ML モデルとシステムに対して異なる種類のテストおよびモニタリングが必要となります。
モデル開発の品質に関するガイドライン
テストフェーズで ML モデルを開発する場合、次の 2 組のターゲット指標を使用してモデルのパフォーマンスを評価できます。
- モデルの最適化指標。この指標にはモデルの予測有効性が反映されます。この指標には、分類タスクの精度および F 尺度、回帰および予測タスクの平均絶対パーセント誤差、ランキング タスクの減価累積利得、言語モデルの perplexity および BLEU スコアが含まれます。この指標の値が大きいほど、特定のタスクに適したモデルとなります。一部のユースケースでは、公正性を確保するために、さまざまなデータスライス（さまざまな顧客属性など）で類似する予測の有効性を得ることが重要です。
- モデルの充足指標。この指標には、予測レイテンシなど、モデルが満たす必要がある運用上の制約が反映されます。レイテンシのしきい値を特定の値（たとえば、200 ミリ秒）に設定するとします。この場合、しきい値を満たさないモデルは受け入れられません。充足指標の別の例として、モデルのサイズがあります。これは、モデルを低電力のハードウェア（モバイル デバイスや組み込みデバイスなど）にデプロイする場合に必要です。
テスト中に、モデルの開発、トレーニング、評価、デバッグを行うことで、充足指標のしきい値を超過することなく、最適化指標に関する有効性を改善できます。
テストのガイドライン
- 最適化指標と充足指標に対して事前定義済みの固定しきい値を設定します。
- モデルとデータを受け取り、一連の評価指標を生成する効率的な評価ルーティンを実装します。モデルのタイプ（ディシジョン ツリーやニューラル ネットワークなど）やモデルのフレームワーク（TensorFlow や Scikit-learn など）に関係なく機能するようにルーティンを実装します。
- 比較するベースライン モデルがあることを確認します。このベースラインは、ハードコードされたヒューリスティックで構成することも、平均またはモードのターゲット値を予測する単純なモデルにすることもできます。ベースライン モデルを使用して ML モデルの性能を確認します。ML モデルがベースライン モデルよりも良好ではない場合、ML モデルに根本的な問題があります。
- 再現性の向上と段階的な改善につながるよう、すべての実施済みテストを追跡します。各テストで、ハイパーパラメータ値、特徴量選択、ランダムシードを保存します。
データ品質のガイドライン
- 適切な評価指標を選択して、テストの早い段階で不均衡なクラスに対処します。さらに、少数派クラスのインスタンスの重み付けの引き上げや、多数派クラスのインスタンスのダウンサンプリングなどの手法を適用します。
- 現在のデータソースを理解し、関連するデータ前処理と特徴量エンジニアリングを実行してトレーニング データセットを準備します。この種のプロセスは、反復可能で自動化できる必要があります。
- モデルの最終評価のために個別のテストデータ分割（ホールドアウト）があることを確認します。テスト分割はトレーニング中には確認せず、ハイパーパラメータ チューニングには使用しないでください。
- トレーニング、検証、テスト分割が入力データを均等に表していることを確認します。このようなテスト分割のサンプリングは、データの性質と現在の ML タスクの性質によって異なります。たとえば、層化分割は分類タスクに関連し、時系列分割は時系列タスクに関連しています。
- 検証用の分割とテスト分割は、トレーニング データ分割とは別に前処理されるようにしてください。これらの分割が混在した状態で前処理されると、データ漏洩が発生します。たとえば、統計を使用して正規化または数値特徴量のバケット化のためにデータを変換する場合は、トレーニング データからの統計を計算して適用することで、検証用の分割とテスト分割を正規化できます。
- 特徴量のデータ型と統計プロパティを含むデータセット スキーマを生成します。このスキーマを使用して、テストとトレーニング中に異常または無効なデータを見つけることができます。
- トレーニング データが適切に一括でシャッフルされ、引き続きモデル トレーニング要件を満たすようにします。たとえば、このタスクは正のインスタンス分布と負のインスタンス分布に適用できます。
- ハイパーパラメータの調整とモデルの選択のために別個の検証データセットを用意します。検証データセットを使用して早期停止を行うこともできます。それ以外の場合は、指定された最大数のイテレーション セット全体でモデルをトレーニングできます。ただし、モデルの新しいスナップショットを保存するのは、検証データセットでの性能が以前のスナップショットと比較して向上している場合に限ります。
モデル品質のガイドライン
- 入力と出力の関係を学習することを妨げる基本的な問題がモデルに存在しない状態にしてください。ごく少数のサンプルを使用してモデルをトレーニングすることで、この目標を達成できます。これらの例でモデルが高精度を達成できない場合は、モデルの実装またはトレーニング ルーチンにバグが存在する可能性があります。
- ニューラル ネットワークをトレーニングする場合は、損失の
NaN値と、モデルのトレーニング全体を通して値がゼロの重みの割合をモニタリングします。これらのNaNまたはゼロ値は、誤った算術計算、勾配消失または勾配爆発を示している可能性があります。時系列で重み値の分布の変化を可視化すると、トレーニングの速度を低下させる内部共変量シフトを検出できます。バッチ正規化を適用することで、この速度の低下を緩和できます。 - トレーニング データとテストデータでモデルのパフォーマンスを比較し、モデルが過学習または学習不足かどうかを確認します。いずれかの問題が確認される場合は、関連する改善策を取ります。たとえば学習不足の場合は、モデルの学習容量を増やすことができます。過学習の場合は正則化を適用できます。
- 誤って分類されたインスタンス、特に予測の信頼度が高いインスタンスと、マルチクラスの混同行列内で最も混同されているクラスを分析します。これらのエラーは、トレーニング サンプルが正しくラベル付けされていないことを示している可能性があります。エラーによって、外れ値を削除するなど、データの前処理を行う機会を特定することもできます。または、このようなクラスを区別するための新しい機能を作成することもできます。
- 特徴量の重要度スコアを分析し、モデルの品質を大幅に改善しない特徴量をクリーンアップします。複雑なモデルよりも倹約モデルが優先されます。
トレーニング パイプラインのデプロイに関する品質ガイドライン
モデルとモデルのトレーニング パイプラインを実装するときに、CI / CD ルーティンで一連のテストを作成する必要があります。これらのテストは、新しいコードの変更を push するときに自動的に実行され、またトレーニング パイプラインをターゲット環境にデプロイする前に実行されます。
ガイドライン
- 特徴量エンジニアリング機能の単体テストを行います。
- モデル入力のエンコードの単体テストを行います。
- ユーザー実装の（カスタム）モデルの単体テストを個別に行います（例: カスタムグラフの畳み込み層とプーリング層、またはカスタム アテンション レイヤの単体テスト実施）。
- カスタムの損失関数または評価関数の単体テストを行います。
- 想定される入力に対するモデルの出力タイプと形状の単体テストを行います。
- モデルの
fit関数が、いくつかの小さなデータバッチでエラーなく動作することを確認する単体テストを行います。このテストでは、損失が減少し、トレーニング ステップの実行時間が想定どおりであることを確認する必要があります。これらのチェックを行うのは、モデルコードの変更が原因でトレーニング プロセスを遅らせるバグが発生する可能性があるためです。 - モデルの保存および読み込み機能の単体テストを行います。
- エクスポートされたモデル サービング インターフェースを、未加工の入力と想定される出力に対して単体テストします。
- モック入力と出力アーティファクトを使用して、パイプライン ステップのコンポーネントをテストします。
- パイプラインをテスト環境にデプロイし、エンドツーエンドのパイプラインの統合テストを行います。このプロセスではいくつかのテストデータを使用して、ワークフロー全体が適切に実行され、想定されるアーティファクトが生成されることを確認します。
- 新しいバージョンのトレーニング パイプラインを本番環境にデプロイする場合には、シャドー デプロイを使用します。シャドー デプロイにより、新しくデプロイされたパイプライン バージョンが、以前のパイプライン バージョンと並行してライブデータに対して実行されるようになります。
継続的なトレーニングに関する品質ガイドライン
継続的なトレーニング プロセスは、トレーニング パイプラインの実行のオーケストレーションと自動化に関係します。一般的なトレーニング ワークフローには、データの取り込みと分割、データ変換、モデル トレーニング、モデル評価、モデル登録などのステップがあります。一部のトレーニング パイプラインはより複雑なワークフローで構成されます。追加のタスクには、ラベル付けされていないデータを使用する自己教師ありモデル トレーニングの実行、または埋め込み用のおおよその最近傍インデックスの構築が含まれます。トレーニング パイプラインの主な入力は新しいトレーニング データです。主な出力は、本番環境にデプロイする新しい候補モデルです。
トレーニング パイプラインは、スケジュール（毎日、毎週など）またはトリガー（新しいラベル付きデータが利用可能になったときなど）に基づいて本番環境で自動的に実行されます。したがって、トレーニング ワークフローに品質管理ステップ（特にデータ検証ステップとモデル検証ステップ）を追加する必要があります。これらのステップは、パイプラインの入力と出力を検証します。
トレーニング ワークフローのデータ取り込みステップの後にデータ検証ステップを追加します。データ検証ステップでは、パイプラインに取り込まれた新しい入力トレーニング データをプロファイリングします。プロファイリング中、パイプラインは ML 開発プロセスで作成された事前定義済みデータスキーマを使用して、異常を検出します。ユースケースによっては、無効なレコードを無視することも、データセットから削除することもできます。ただし、新しく取り込まれたデータの他の問題によってトレーニング パイプラインの実行が停止する可能性があるため、それらの問題を特定して対処する必要があります。
データ検証のガイドライン
- 抽出されたトレーニング データの特徴量が完全であり、予想されるスキーマと一致すること（つまり特徴量の不足や追加された特徴量がないこと）を確認します。また、特徴量が予想ボリュームと一致していることも確認します。
- トレーニング パイプラインに取り込まれるデータセット内の特徴量のデータ型と形状を検証します。
- 特定の特徴量（日付、時刻、URL、郵便番号、IP アドレスなど）の形式が、想定される正規表現と一致していることを確認します。また、特徴量が有効な範囲内にあることも確認します。
- 各特徴量の欠損値の最大割合を検証します。特定の特徴量の欠損値の割合が大きいと、モデルのトレーニングに影響する可能性があります。欠損値は通常、信頼できない特徴量ソースであることを示します。
- 入力特徴量のドメインを検証します。たとえば、カテゴリ特徴量の語彙や数値特徴量の範囲に変化があるかどうかを確認し、それに応じてデータの前処理を調整します。別の例として、特徴量を入力するアップストリーム システムの更新で異なる測定単位が使用される場合、数値特徴量の範囲が変わる可能性があります。たとえば、アップストリーム システムで通貨がドルから円に変更されることや、距離がキロメートルからメートルに変更されることがあります。
- 各特徴量の分布が予想どおりであることを確認します。たとえば、支払いタイプの特徴量の最も一般的な値が
cashであり、この支払いタイプがすべての値の 50% を占めることをテストで確認できます。ただし、最も一般的な支払いタイプがcredit_cardに変更された場合、このテストは失敗する可能性があります。このような外部の変更には、モデルの変更が必要になる場合があります。
モデル登録ステップの前にモデル検証ステップを追加して、検証基準を満たすモデルのみが本番環境のデプロイに登録されるようにします。
モデル検証のガイドライン
- 最終的なモデル評価には、モデルのトレーニングやハイパーパラメータの調整に使用されていない別のテスト分割を使用します。
- テストデータ分割に照らし合わせて候補モデルをスコアリングし、関連する評価指標を計算して、候補モデルが事前定義の品質しきい値を超えていることを確認します。
- さまざまなデータパターンを考慮するために、テストデータ分割がデータ全体を表していることを確認します。時系列データの場合は、トレーニング分割よりも新しいデータがテスト分割に含まれていることを確認します。
- 重要なデータスライス（国別のユーザー数やジャンル別の映画の数など）でモデルの品質をテストします。スライス化されたデータでテストすることで、細かな性能の問題がグローバル サマリー指標では明らかにならない問題を回避できます。
- テストデータ分割に照らし合わせて現在の（チャンピオン）モデルを評価し、トレーニング パイプラインによって生成された候補（チャレンジャー）モデルと比較します。
- モデルを公正性インジケーターと照らし合わせて検証し、暗黙的なバイアスを検出します。たとえば、トレーニング データの多様性が不十分な場合、暗黙的なバイアスが引き起こされることがあります。公平性インジケーターにより、モデルを本番環境にデプロイする前に対処する必要がある根本原因の問題を特定できます。
継続的なトレーニング中に、最適化指標と充足指標の両方に照らし合わせてモデルを検証できます。または、最適化指標のみに照らし合わせてモデルを検証し、充足指標に照らし合わせた検証をモデルのデプロイ フェーズまで延期することもできます。同じモデルのバリエーションを異なるサービス環境やワークロードにデプロイする場合は、充足指標に照らし合わせた検証を延期する方が適切な場合があります。サービス環境またはワークロード（クラウド環境とオンデバイス環境、リアルタイム環境とバッチ サービング環境など）に応じて、必要となる充足指標のしきい値が異なる可能性があります。複数の環境にデプロイする場合、継続的なトレーニング パイプラインで 2 つ以上のモデルをトレーニングすることがあります。この場合、各モデルはターゲット デプロイ環境に合わせて最適化されます。詳細と例については、Vertex AI でのデュアル デプロイをご覧ください。
複雑なワークフローを含む継続的トレーニング パイプラインをさらに本番環境に導入する場合は、パイプライン実行により生成されるアーティファクトとメタデータを追跡する必要があります。この情報を追跡することで、本番環境で発生する可能性のある問題を追跡してデバッグできます。また、この情報を追跡することでパイプラインの出力を再現できるため、後続の ML 開発のイテレーションでパイプラインの実装を改善できます。
ML メタデータとアーティファクトの追跡に関するガイドライン
- ソースコード、デプロイされたパイプライン、パイプラインのコンポーネント、パイプライン実行、使用中のデータセット、生成されたアーティファクトのリネージを追跡します。
- ハイパーパラメータとパイプライン実行の構成を追跡します。
- パイプライン ステップの主な入力と出力アーティファクトを追跡します。これには、データセットの統計情報、データセットの異常（存在する場合）、変換されたデータとスキーマ、モデルのチェックポイント、モデルの評価結果などがあります。
- 条件に対応して条件付きパイプライン ステップが実行されることを追跡し、主要なステップが実行されない場合や失敗した場合の変更メカニズムを追加してオブザーバビリティを確保します。
モデルのデプロイに関する品質ガイドライン
トレーニング済みのモデルが、最適化指標の観点から検証済みであり、モデル ガバナンスの観点から承認されていることを前提としています（後述のモデル ガバナンスセクションを参照）。モデルはモデル レジストリに格納され、本番環境にデプロイできる状態です。この時点で、モデルが移行先の環境で動作するのに適していることを確認するための一連のテストを実装する必要があります。また、モデルの CI / CD ルーティンでこれらのテストを自動化する必要があります。
ガイドライン
- モデル アーティファクトがそのランタイム依存関係とともに読み込まれ、正常に呼び出されることを確認します。この検証を行うには、サービス環境のサンドボックス化バージョンでモデルをステージングします。この検証により、モデルで使用されるオペレーションとバイナリが環境に存在することを確認できます。
- ステージング環境で、モデルのサイズやレイテンシなどモデルの充足指標（存在する場合）を検証します。
- ステージング環境で、未加工の入力および想定される出力に照らし合わせて、モデル、アーティファクト、サービス インターフェースの単体テストを行います。
- 予測リクエストの一般的なケースとエッジケースについて、ステージング環境でモデル アーティファクトの単体テストを行います。たとえば、すべての機能が
Noneに設定されたリクエスト インスタンスの単体テストなどです。 - ターゲット環境にデプロイされたモデルサービス API のスモークテストを行います。このテストを実行するには、1 つのインスタンスまたはインスタンスのバッチをモデルサービスに送信し、サービスのレスポンスを検証します。
- ライブ サービング データの小規模なストリームで、新しくデプロイされたモデル バージョンのカナリアテストを行います。このテストでは、モデルが多数のユーザーに公開される前に、新しいモデルサービスでエラーが発生しないことを確認します。
- 以前のサービング モデル バージョンに迅速かつ安全にロールバックできるステージング環境でテストします。
- 提供対象群の小さなサブセットを使用して新しくトレーニングされたモデルをテストするため、オンライン テストを実行します。このテストでは、新しいモデルのパフォーマンスを測定して現在のモデルと比較します。新しいモデルのパフォーマンスと現在のモデルのパフォーマンスを比較した後で、すべてのライブ予測リクエストを処理するために新しいモデルを完全にリリースすることを決定する場合があります。オンライン テストの手法には、A/B テストや多腕バンディット（MAB）などがあります。
モデル サービングに関する品質ガイドライン
本番環境にデプロイされ、サービス提供している ML モデルの予測性能は、時間の経過とともに低下します。この低下は、サービング特徴量と、モデルで期待される特徴量との間に不整合が生じたことが原因で発生する可能性があります。この不整合をトレーニング サービング スキューといいます。たとえば、レコメンデーション モデルで、最後に閲覧された商品コードなどの特徴量に対して英数字の入力値が予期されているとします。ただし、モデルサービスを消費するアプリケーションの更新が原因で、サービング中に商品コードではなく商品名が渡されます。
また、サービング データの統計的特性が時間の経過とともに変動し、モデルが古くなり、現在デプロイされているモデルで学習されたパターンが正確でなくなることがあります。どちらの場合も、モデルは正確な予測を提供できなくなります。
このようなモデルの予測性能の低下を回避するには、モデルの有効性を継続的にモニタリングする必要があります。モニタリングにより、モデルの性能が低下しないことを事前に定期的に確認できます。
ガイドライン
- 定期的な分析のために、サービング リクエスト / レスポンス ペイロードのサンプルをデータストアに記録します。リクエストは入力インスタンスであり、レスポンスはそのデータ インスタンスのモデルによって生成された予測です。
- 記述統計の計算に基づいて、保存されているリクエスト / レスポンス データをプロファイリングする自動プロセスを実装します。これらのサービング統計情報を定期的に計算して保存します。
- サービング データの統計情報をトレーニング データのベースライン統計情報と比較して、データのシフトとドリフトに起因するトレーニング サービング スキューを特定します。さらに、サービング データ統計情報の経時的な変化を分析します。
- 予測の特徴アトリビューションの経時的な変化を分析して、コンセプト ドリフトを特定します。
- トレーニング データに関して、外れ値とみなされるサービング データ インスタンスを特定します。このような外れ値を検知するには、特異点検知手法を使用して、サービング データの外れ値の割合の経時的な変化を追跡します。
- データセット内の主要な予測特徴量でモデルがスキュースコアのしきい値に達したときのアラートを設定します。
- ラベル（実際のデータ）が利用可能な場合は、真のラベルをサービス インスタンスの予測ラベルと結合して、継続評価を行います。このアプローチは、オンライン テストで A/B テストとして実装する評価システムに似ています。継続評価では、本番環境でのモデルの予測能力を特定でき、さらにはモデルが性能を発揮できるリクエストの種類と性能をそれほど発揮できないリクエストの種類を特定できます。
- 重要なシステム指標の目標を設定し、その目標に沿ってモデルの性能を測定します。
- サービスの効率性をモニタリングし、本番環境でモデルが大規模にサービス提供できるようにします。このモニタリングは、キャパシティ プランニングの予測と管理、さらにはサービス インフラストラクチャの費用の見積もりにも役立ちます。CPU 使用率、GPU 使用率、メモリ使用率、サービス レイテンシ、スループット、エラー率などの効率性指標をモニタリングします。
モデル ガバナンス
モデル ガバナンスは、従業員が企業の AI の原則を実施するためのガイドラインとプロセスを提供する企業の中核的な機能です。これらの原則には、バイアスを発生させるモデルやバイアスを強制するモデルの回避や、AI による決定を正当化できることなどがあります。モデル ガバナンス機能により、人間参加型であることが確実になります。人間によるレビューの導入は、機密性が高く影響の大きいワークロード（多くの場合、ユーザー向けのワークロード）において特に重要です。このようなワークロードには、信用リスクのスコア付け、採用候補者のランク付け、保険ポリシーの承認、ソーシャル メディアでの情報の拡散などがあります。
ガイドライン
- タスクごとに各モデルの責任分担表を用意します。この表では、組織階層全体にわたる部門横断チーム（事業部門、データ エンジニアリング、データ サイエンス、ML エンジニアリング、リスクとコンプライアンスなど）を考慮する必要があります。
- モデルカードなどを使用して、モデルのバージョンにリンクされているモデル レジストリでモデルのドキュメントとレポートを管理します。このようなメタデータには、モデルのトレーニングに使用されたデータ、モデルの性能、既知の制限事項に関する情報などが含まれます。
- 本番環境へのモデルのデプロイを承認する前に、モデルのレビュー プロセスを導入します。このタイプのプロセスでは、モデルのチェックリストのバージョン、補足ドキュメント、関係者が要求する可能性のある追加情報を維持します。
- ベンチマーク データセット（ゴールデン データセットとも呼ばれます）でモデルを評価します。このデータセットは、標準ケースとエッジケースの両方に対応しています。また、公平性インジケーターに照らし合わせてモデルを検証することで、暗黙的なバイアスを検出できます。
- モデルのユーザーに対し、モデルの全体としての予測動作と、特定のサンプル入力インスタンスに対する予測動作を説明します。この情報を提供することで、モデルの重要な特徴量と望ましくない動作を理解できます。
- What-If 分析ツールを使用してモデルの予測動作を分析し、さまざまなデータ特徴量の重要性を理解します。この分析は、複数のモデルと入力データのサブセットにおけるモデルの動作を可視化するうえでも役立ちます。
- 敵対的攻撃に対してモデルをテストして、本番環境での悪用に対してモデルが堅牢であることを確認します。
- 本番環境、データセット シフト時、ドリフト時のモデルの予測性能に関するアラートを追跡します。モデルの関係者に通知するアラートを構成します。
- モデルのオンライン テスト、ロールアウト、ロールバックを管理します。
次のステップ
- Google Research の The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction を読む。
- O'Reilly の A Brief Guide to Running ML Systems in Production を読む。
- ML のルールを読む。
- ML のテストとデバッグのトレーニングを試す。
- ML におけるデータ検証に関する論文を読む。
- Google Cloud の E2E MLOps コード リポジトリを確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。