GitHub ML パイプラインのアクション

GitHub アクション ワークフローは、トリガー、ジョブ、ランナー、ステップを指定する YAML 定義です。これらは、プッシュ、プル リクエスト、スケジュール、または手動ディスパッチで実行できます。ジョブはランナー上で実行され、以前のジョブに依存することができるため、コード チェック、データ検証、トレーニング、評価、ゲート制御パブリケーションなどのパイプラインが可能になります。 ML チームは、毎日のコード レビューの応答性を維持できるように、高速な決定論的チェックを高価なステージやハードウェア固有のステージから分離する必要があります。一般的なプルリクエスト ジョブでは、依存関係をインストールし、単体テストを実行し、小規模なフィクスチャの機能スキーマを検証できます。後のジョブは、制御されたデータセットでトレーニングし、モデル アーティファクトを生成し、評価レポートを生成する場合があります。プロモーションは明示的な基準に依存し、評価された正確なアーティファクト ダイジェストを保存する必要があります。 GPU トレーニングには自己ホスト型または専用のランナーが必要になる場合があり、これにより容量、パッチ適用、および分離の責任が発生します。コンテナーはソフトウェアの依存関係を一貫させることができますが、ハードウェアまたはデータへのアクセスを自動的に提供するわけではありません。ワークフローでは、依存関係のインストールやアーティファクトを削減するためにキャッシュを使用してジョブ間で出力を渡したり、レポートを保持したりすることがよくあります。キャッシュは信頼できる成果物として扱われるべきではなく、キャッシュのキーには関連する依存関係の入力が含まれている必要があります。秘密の範囲は狭くする必要があります。フォークからのプル リクエストには、シークレット アクセスが制限されている場合があります。サポートされている場合、OIDC はワークフロー ID を有効期間の短いクラウド認証情報と交換し、有効期間の長いキーへの依存を軽減できます。組織のポリシーに従って、トークンのアクセス許可を制限し、サードパーティのアクションをレビュー済みのバージョンまたは不変の参照に固定します。信頼性の高い ML ワークフローは、コードのコミット、環境、データ バージョン、トレーニング構成、モデル ダイジェストを記録します。ジョブがデータセットをダウンロードしたり、データセット上でトレーニングしたりする場合、データのライセンス、プライバシー、コスト管理も重要になります。すべてのトレーニング済みモデルを自動的に公開することは避けてください。リスクが正当な場合には検証と承認が必要です。ワークフローのログとアーティファクトには、監査可能性、コスト、機密データの露出のバランスをとる保持設定が必要です。アクションはオーケストレーションを提供するものであり、トレーニングの再現性、検証が適切であること、リリースが安全であることを保証するものではありません。これらのプロパティは、パイプラインの入力とゲートによって異なります。