ml-pipeline-creation

ML パイプラインの作成

入力、出力、リネージ、昇格基準が明確な、再現可能な ML ワークフローを構築します。プロジェクトで既に採用されているオーケストレーターや規約を優先し、実例を示すためだけにプラットフォームを導入しないでください。

必須入力

• ビジネス目標と、測定可能なモデル受け入れ基準
• データソース、所有者、機密性、想定される更新頻度
• 既存の前処理、トレーニング、評価、サービングのコード
• 対象環境と、利用可能なオーケストレーションまたは CI システム
• コンピューティング、コスト、レイテンシ、再現性、コンプライアンスに関する制約

重要な詳細が不足している場合は、前提を明示し、実装を選定する前にプラットフォームに依存しないパイプラインを設計してください。

出力要件

以下を作成します。

1. パイプラインの各ステージと成果物の依存関係グラフ
2. バージョン管理されたパイプライン定義または実装
3. 各ステージの入力と出力の明確なスキーマ
4. データ、モデル、環境のバージョン管理ルール
5. 失敗時の動作を含む、評価と昇格のゲート
6. オブザーバビリティ、再試行、バックフィル、ロールバックの手順
7. パイプラインのテスト方法を示す検証記録

ワークフロー

1. 環境を調査します。 リポジトリの言語、依存関係マネージャー、既存のオーケストレーションシステム、モデルフレームワーク、成果物ストア、デプロイ経路を特定します。可能な限り、確立済みのツールを再利用してください。
2. 契約を定義します。 目標、データスナップショットのルール、目標メトリクス、ベースライン、受け入れしきい値、リソース予算、デプロイ制約を記録します。オフライン評価と本番環境の健全性メトリクスを分けてください。
3. DAG をモデル化します。 取り込み、検証、分割、変換、トレーニング、評価、登録、デプロイを、冪等なステージとして表現します。未宣言のファイルや変更可能なグローバル状態に依存せず、すべての成果物を宣言してください。
4. 再現性を確保します。 依存関係を固定し、適切な場合は確率的処理のシードを設定し、コードとデータをバージョン管理して、来歴情報とともに変更不可能な成果物を保存します。変換のフィッティングはトレーニングデータのみに行い、トレーニングと検証データのリークを防いでください。
5. 品質ゲートを追加します。 トレーニング前にスキーマを検証し、メトリクスをベースラインと比較します。成果物が欠落または無効な場合はフェイルクローズし、重大な影響がある場合は本番への昇格前に明示的な承認を必須にします。
6. 運用を設計します。 一時的な障害に限って再試行し、再実行を冪等にします。バックフィルの範囲を定め、構造化ログとメトリクスを出力し、最後に正常動作したモデルへのロールバック方法を文書化してください。
7. 段階的にテストします。 コンポーネントのユニットテスト、小規模で決定論的なエンドツーエンドのフィクスチャ、ステージング環境での実行またはドライランを行います。ステージの失敗によってモデルが暗黙のうちに公開されないことを確認してください。

例

バッチ分類器の場合、成果物のフローを明示的に定義します。

pipeline: customer-churn-training
inputs:
  raw_snapshot: data/raw/churn-2026-08-01.parquet
stages:
  - name: prepare-data
    inputs: [raw_snapshot]
    outputs: [train_set, validation_set, test_set, feature_schema]
  - name: train-model
    inputs: [train_set, feature_schema, training_config]
    outputs: [model, training_metrics]
  - name: evaluate-model
    inputs: [model, validation_set, test_set, baseline_metrics]
    outputs: [evaluation_report, promotion_decision]
  - name: register-model
    condition: promotion_decision == "pass"
    inputs: [model, evaluation_report]
    outputs: [registered_model_version]

prepare-data が宣言されたすべての分割データを出力するようにします。test_set が存在しない場合は、宣言されていないパスを評価で使用させず、実行を拒否してください。

安全上の境界

• データセット、認証情報、モデル成果物、ログは、機密情報である可能性があるものとして扱ってください。
• 許可と必要な匿名化なしに、本番データを開発環境へコピーしないでください。
• 明示的な承認なしに、デプロイ、登録済みモデルの置き換え、本番インフラストラクチャの変更を行わないでください。
• 破壊的な移行やクリーンアップの計画は実行前に提示し、ロールバック経路を維持してください。
• パイプラインを実行しただけでコンプライアンスを満たしたと主張せず、公平性、プライバシー、セキュリティ、規制に関するレビュー要件を明示してください。

検証

• フィクスチャを 2 回実行し、ステージ契約と期待される決定的な出力が同一であることを確認します。
• いずれかのステージを強制的に失敗させ、後続のステージが実行されないことを確認します。
• アーティファクトのハッシュ、コードのリビジョン、パラメーター、データのバージョン、評価結果を、登録済みモデルから追跡できることを確認します。
• レコードの重複や不変アーティファクトの上書きを起こさずに、再試行とバックフィルの動作をテストします。
• デプロイゲートがしきい値未満のモデルを拒否し、既知の正常なフィクスチャを受け入れることを確認します。

ベストプラクティス

• コンポーネントは小さく、冪等で、個別にテストできる状態に保ちます。
• パイプラインのオーケストレーションとモデルのビジネスロジックを分離します。
• 設定はバージョン管理されたデータとして保存し、しきい値をコードに埋め込まないようにします。
• 変更可能な「latest」パスよりも、不変のアーティファクトと明示的な系統情報を優先します。
• トレーニング中だけでなく、デプロイ後もデータ品質とモデルの動作を監視します。

エッジケース

• ストリーミングデータ： イベント時刻セマンティクス、チェックポイント、再生に安全なシンクを使用します。
• 非決定的なトレーニング： シードと環境の詳細を記録し、合意した許容誤差の範囲内で検証します。
• 大規模なバックフィル： 日付範囲に上限を設け、コストを見積もり、規模を拡大する前に 1 つのパーティションでテストします。
• スキーマのドリフト： 互換性のないデータを隔離し、レビュー済みのスキーマ移行を必須にします。
• 部分的な昇格： レジストリ、サービング設定、監視の変更をトランザクションとして扱うか、明示的に元に戻せるようにします。