5. 継続的な統合

ML システムはテストを実行して、システムがエンドツーエンドで動作することを検証し、潜在的な障害点をチェックします。テストはコミット時に自動的に実行され、長いテストは固定スケジュールで実行されます。テストでは、ユニットレベルやシステムレベルなど、従来のソフトウェアエンジニアリング領域をチェックします。さらに、テストでは、データ、機能、モデルをチェックして ML の詳細をキャプチャします。

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