機械学習モデルのデプロイのテスト

デプロイの準備が整いました。大きな赤いボタンを押すだけでモデルをデプロイするだけなら、デプロイ時に、パイプラインをヒックなしで実行、更新、提供します。これらのニーズにより、このページで説明する要件とソリューションにつながります。

再現可能なトレーニングでモデルの更新をテストする

今後も、ユニコーンの外観の予測力を向上させていきたいと考えています。たとえば、「時間帯」特徴のために特徴量エンジニアリング コードをリファクタリングするとします。コードが正しいことをテストする方法は?モデルを再度トレーニングして、同じ結果が得られるかどうかを確認するとします。あれ、モデル トレーニングが再現できないことがわかりました。ユニコーンの外観を予測し続けると判断した場合は、さらに調査します。次の手順を行うことで、再現性が得られることがわかります。

  • 乱数ジェネレータ(RNG)に決定的にシードする。詳細については、「ML におけるデータの準備と特徴量エンジニアリング」コースのデータ生成におけるランダム化をご覧ください。

  • モデル コンポーネントを一定の順序で初期化し、実行するたびにコンポーネントが RNG から同じ乱数を取得するようにします。ML ライブラリは通常、この要件を自動的に処理します。

  • モデルの複数の平均実行。

  • 予備的なイテレーションであっても、バージョン管理を使用して、モデルやパイプラインを調査するときにコードとパラメータを正確に特定できるようにします。

これらの手順を行った後も、他の非決定性の原因となる可能性があります。

仕様と API 呼び出しに対するモデルの更新をテストする

モデルを Unicorn Predictor 2.0 に更新したら、新しいモデルでアルゴリズムの正確性と API 呼び出しの変更をテストする必要があります。その方法を見てみましょう。

API 呼び出しのテスト

API 呼び出しのアップデートをどのようにテストしていますか?もちろん、モデルを再トレーニングすることは可能ですが、時間がかかります。その代わりに、ランダムな入力データを生成し、勾配降下法の 1 ステップを実行する単体テストを作成します。ランタイム エラーなしでステップを完了する必要がある。

アルゴリズムの正確性のテスト

モデルは正しく予測できるだけでなく、アルゴリズムによって正しく、運が良くないので予測する必要があります。たとえば、99% のメールが迷惑メールではないとした場合、すべてのメールを迷惑メールではないと分類すると、確率は 99% になります。そのため、モデルのアルゴリズムの正しさを確認する必要があります。手順は次のとおりです。

  • 数回のイテレーションでモデルをトレーニングし、損失が減少することを確認します。
  • 正則化なしでアルゴリズムをトレーニングします。モデルが十分に複雑な場合、トレーニング データは記憶され、トレーニングの損失は 0 に近くなります。
  • アルゴリズムの特定のサブ計算をテストします。たとえば、RNN の一部が入力データの要素ごとに 1 回実行されることをテストできます。

パイプライン コンポーネントの統合テストを作成する

ML パイプラインでは、1 つのコンポーネントが変更されると、他のコンポーネントでもエラーが発生することがあります。パイプライン全体をエンドツーエンドで実行するテストを作成して、コンポーネントが連携して動作することを確認します。このようなテストを統合テストと呼びます。

統合モデルを継続的にテストするだけでなく、新しいモデルや新しいソフトウェア バージョンを push するときに統合テストを実行する必要があります。パイプライン全体を実行する速度が遅いため、継続的インテグレーションのテストが難しくなります。統合テストを高速化するには、データのサブセットのトレーニングまたはよりシンプルなモデルを使用します。詳細はモデルとデータによって異なります。継続的なカバレッジを取得するには、モデルまたはソフトウェアの新しいバージョンごとにテストを行うように、より高速なテストを調整します。その間、低速なテストはバックグラウンドで継続的に実行されます。

提供前にモデルの品質を検証

新しいモデル バージョンを本番環境にプッシュする前に、次の 2 種類の品質低下をテストします。

  • 急激な低下: 新しいバージョンのバグによって品質が大幅に低下する可能性があります。新しいバージョンと以前のバージョンの品質を照合して検証します。

  • 速度の低下: 急激な低下のテストでは、複数のバージョンにわたるモデルの品質の低下が検出されないことがあります。代わりに、検証用データセットに対するモデルの予測が一定のしきい値を満たすようにします。検証用データセットがライブデータから逸脱している場合は、検証用データセットを更新して、モデルが同じ品質しきい値を満たしていることを確認してください。

提供前にモデルインフラストラクチャの互換性を検証

サーバーよりもモデルの更新が早いと、モデルにサーバーとは異なるソフトウェアの依存関係が組み込まれ、互換性が失われる可能性があります。モデルをサンドボックス バージョンでサーバーに配置し、モデルで使用されるオペレーションがサーバーに存在することを確認します。