ユニコーンの出現を予測するユニコーン モデルをデプロイする準備が整いました。デプロイ時に、機械学習（ML）パイプラインが問題なく実行、更新、提供されるようにする必要があります。大きな [デプロイ] ボタンを押すだけでモデルをデプロイできたら、残念ながら、完全な ML システムでは、次のテストが必要です。
- 入力データの検証。
- 特徴量エンジニアリングの検証。
- 新しいモデル バージョンの品質を検証する。
- サービング インフラストラクチャの検証。
- パイプライン コンポーネント間の統合のテスト。
多くのソフトウェア エンジニアは、テスト駆動開発（TDD）を好みます。TDD では、ソフトウェア エンジニアは「実際の」ソースコードを記述する前にテストを記述します。ただし、機械学習では TDD が難しい場合があります。たとえば、モデルをトレーニングする前に、損失を検証するテストを作成することはできません。代わりに、まずモデル開発中に達成可能な損失を検出し、次に達成可能な損失に対して新しいモデル バージョンをテストする必要があります。
ユニコーン モデルについて
このセクションでは、ユニコーン モデルについて説明します。必知事項は次のとおりです。
機械学習を使用して、ユニコーンの出現を予測する分類モデルを構築しています。データセットには、ユニコーンの出現 10,000 件とユニコーンの出現なし 10,000 件の詳細が含まれています。このデータセットには、場所、時刻、高度、気温、湿度、樹木被覆、虹の有無など、さまざまな特徴が含まれています。
再現可能なトレーニングでモデルの更新をテストする
ユニコーン モデルの改善を継続したい場合もあります。たとえば、特定の特徴量に追加の特徴量エンジニアリングを行い、より良い（または少なくとも同じ）結果が得られるようにモデルを再トレーニングするとします。残念ながら、モデルのトレーニングを再現できないことがあります。再現性を高めるには、次の推奨事項に従ってください。
乱数ジェネレータを確定的にシードします。詳細については、データ生成のランダム化をご覧ください。
モデル コンポーネントを固定の順序で初期化して、コンポーネントが実行ごとに乱数生成ツールから同じ乱数を取得できるようにします。通常、ML ライブラリは、この要件を自動的に処理します。
モデルの複数の実行の平均値を取得します。
事前反復処理でもバージョン管理を使用すると、モデルやパイプラインを調査するときにコードとパラメータを特定できます。
これらのガイドラインに従ったとしても、非決定性の他の原因が存在する可能性があります。
ML API への呼び出しをテストする
API 呼び出しの更新をテストする方法モデルを再トレーニングすることもできますが、時間がかかります。代わりに、単体テストを作成してランダムな入力データを生成し、勾配降下法の 1 ステップを実行します。このステップがエラーなく完了した場合、API の更新によってモデルが破損していない可能性があります。
パイプライン コンポーネントの統合テストを作成する
ML パイプラインでは、1 つのコンポーネントの変更が他のコンポーネントでエラーを引き起こす可能性があります。パイプライン全体をエンドツーエンドで実行する統合テストを作成して、コンポーネントが連携して動作することを確認します。
インテグレーション テストを継続的に実行するだけでなく、新しいモデルと新しいソフトウェア バージョンをプッシュするときにインテグレーション テストを実行する必要があります。パイプライン全体の実行が遅いため、継続的インテグレーション テストが難しくなります。統合テストをより速く実行するには、データのサブセットまたはよりシンプルなモデルでトレーニングします。詳細はモデルとデータによって異なります。継続的なカバレッジを取得するには、高速テストを調整して、モデルまたはソフトウェアの新しいバージョンごとに実行するようにします。一方、時間のかかるテストはバックグラウンドで継続的に実行されます。
サービング前にモデルの品質を検証する
新しいモデル バージョンを本番環境に push する前に、次の 2 種類の品質低下をテストします。
突然の劣化。新しいバージョンのバグにより、品質が大幅に低下する可能性があります。新しいバージョンの品質を以前のバージョンと比較して検証します。
デグラデーションが遅い。突然の品質低下を検出するテストでは、複数のバージョンにわたるモデル品質の低下が検出されない場合があります。代わりに、検証データセットに対するモデルの予測が固定しきい値を満たしていることを確認します。検証データセットがライブデータから逸脱している場合は、検証データセットを更新し、モデルが引き続き同じ品質しきい値を満たしていることを確認します。
サービング前にモデルとインフラストラクチャの互換性を検証する
モデルがサーバーよりも速く更新されると、モデルとサーバーのソフトウェア依存関係が異なるため、互換性の問題が発生する可能性があります。モデルで使用されるオペレーションがサーバーに存在することを確認するには、サーバーのサンドボックス化バージョンにモデルをステージングします。