翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
5. 継続的インテグレーション
ML システムはテストを実行して、システムがエンドツーエンドで動作することを検証し、潜在的な障害点をチェックします。テストはコミット時に自動的に実行され、長時間のテストは固定スケジュールで実行されます。テストでは、ユニットレベルやシステムレベルなど、従来のソフトウェアエンジニアリング領域がチェックされます。さらに、データ、機能、モデルをチェックすることで、ML の詳細がキャプチャされます。
5.1 ローカルコードチェック |
コードを一元化されたコードリポジトリにコミットする前に、開発者は基本的なユニットテストや静的分析などのチェックをローカルで実行します。コミットの前にこれらのチェックを実行すると、全体的なコード品質が向上し、バージョン管理に入る前に問題を検出できます。 |
5.2 静的コード分析 |
中央コードリポジトリには静的コード分析ツールがあり、コミット時に短時間で実行されます。このツールは、コードのスタイルとフォーマットを改善します。また、ソースコードとインフラストラクチャコード内の一般的なセキュリティの脆弱性、一般的なバグ、およびコード内のその他の弱点もチェックします。 |
5.3 データ品質テスト |
データ品質テストでは、最低限、データが固定スキーマに違反していないことを確認します。より包括的なアプローチでは、取り込み時にデータ統計を計算し、データに制約を設定し、それらに対してテストを実行します。 データ品質テストは、個別に設定することも、パイプラインの一部として設定することもできます。統計と制約はモニタリング時に再利用されます。 |
5.4 特徴量テスト |
完全なパイプラインの一部として、特徴量重要度が生成されます。特徴量テストでは、特徴量の重要性やモデルの特徴量値の帰属方法は変わらないと考えます。特徴量テストをモニタリングにフィードして、モデルの入力の違反をアラートおよび追跡することができます。 |
5.5 ユニットテスト |
モデル、アプリケーション、インフラストラクチャなど、すべてのコードのユニットテストは、コミット前とコミット時に実行されます。各ユニットテストでは、重要なコードをチェックして、期待どおりに機能することを確認します。ML コードの場合、アルゴリズムの正確性についてテストを実行できます。 |
5.6 統合テスト |
統合テストでは、パイプラインの関連インフラストラクチャの立ち上げを含め、パイプラインが正常にエンドツーエンドで実行されることを確認します。このテストでは、システムが期待どおりに動作し、ログ記録されていることを検証します。個別のデプロイの場合は、デプロイが機能していることを確認するために、これについてもエンドツーエンドのテストを行う必要があります。 |
5.7 スモークテスト |
システムには、各機能を少しずつすばやく回帰的にテストするスモークテストが設定されています。スモークテストは継続的な統合の一部であり、クラウド機能を模倣するためにコンテナ化された環境で実行できます。 |
5.8 負荷テスト |
オンデマンドの負荷テストが設定されています。負荷テストでは、ML システムが高負荷と低負荷でどのように動作するかをキャプチャすることに加えて、システム全体のスループットまたはレイテンシーに関する統計を提供します。負荷テストで収集されたデータは、リソースサイズとスケーリングポリシーに関する情報を提供します。 |
5.9 モデル機能テスト |
モデルの出力と入力は、自動機能テストによって実行されます。動作が機能の範囲内かチェックするために、モデルの出力と入力の両方が、実際のデータまたはフェイクデータを使用して基本的な例でテストされます。 |
5.10 極端なケースでのモデル推論テスト |
最小機能テストの一環として、モデルテストでは、モデルを昇格させる前に特定の入力を指定して極端な動作を確認する必要があります。これにより、予期しない動作を防ぐための追加のガードレールが設けられます。 |