mcpField
M
machine-learning-ops-ml-pipeline

machine-learning-ops-ml-pipeline

github.com/sickn33データ・データベース48.7k491 回インストール今日更新
リポジトリ

machine-learning-ops-ml-pipeline について

データ、ML、MLOpsの担当者向けに、データ準備、学習、デプロイ、監視を段階的に進めるパイプラインの設計・実装を支援するスキルです。検証、再現性、本番環境のリスク管理を重視します。

主な機能

  1. 01段階ごとの専門エージェント連携
  2. 02データ品質と特徴量設計
  3. 03学習と実験追跡の設計
  4. 04モデルのデプロイと監視の計画
  5. 05検証、ロールバック、ガバナンスの重視

活用シーン

  1. 01エンドツーエンドのMLパイプライン設計
  2. 02学習とデプロイの担当範囲の整理
  3. 03ドリフト監視とモデルのロールバック計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill machine-learning-ops-ml-pipeline

インストール後、Claude Code で/machine-learning-ops-ml-pipelineを入力して読み込まれたか確認します。

詳細

機械学習パイプライン - マルチエージェント MLOps オーケストレーション

次の内容について、完全な ML パイプラインを設計し、実装します:$ARGUMENTS

このスキルを使用する場合

  • 機械学習パイプライン - マルチエージェント MLOps オーケストレーションのタスクやワークフローに取り組む場合
  • 機械学習パイプライン - マルチエージェント MLOps オーケストレーションに関するガイダンス、ベストプラクティス、チェックリストが必要な場合

このスキルを使用しない場合

  • タスクが機械学習パイプライン - マルチエージェント MLOps オーケストレーションに関係しない場合
  • この範囲外の別のドメインやツールが必要な場合

手順

  • 目標、制約、必要な入力を明確にします。
  • 関連するベストプラクティスを適用し、成果を検証します。
  • 実行可能な手順と検証方法を提示します。

考え方

このワークフローでは、複数の専門エージェントが連携し、最新の MLOps ベストプラクティスに従って、本番環境に対応した ML パイプラインを構築します。次の点を重視します。

  • フェーズベースの調整:各フェーズは前のフェーズの成果を基盤とし、エージェント間の引き継ぎを明確にします
  • 最新ツールとの統合:実験には MLflow/W&B、特徴量には Feast/Tecton、サービングには KServe/Seldon を使用します
  • 本番環境を第一に考える姿勢:すべてのコンポーネントを、スケーラビリティ、監視、信頼性を考慮して設計します
  • 再現性:データ、モデル、インフラストラクチャをバージョン管理します
  • 継続的な改善:再トレーニング、A/B テスト、ドリフト検出を自動化します

マルチエージェント方式により、各領域をそれぞれの専門家が担当します。

  • データエンジニアは、データの取り込みと品質を担当します
  • データサイエンティストは、特徴量と実験を設計します
  • ML エンジニアは、トレーニングパイプラインを実装します
  • MLOps エンジニアは、本番環境へのデプロイを担当します
  • 可観測性エンジニアは、監視を担保します

実装可能な範囲と証拠

$ARGUMENTS を、範囲を限定した目標、データの利用権、予測単位、対象期間、ベースライン、受け入れ指標で置き換えてください。タスク/サブエージェントのブロックとフェーズの参照はオーケストレーションの擬似コードであり、実行可能なツールではありません。利用が許可された委任手段と明示的な引き継ぎだけを使用してください。データ漏洩を防ぐため、変換処理の適合前に時間またはエンティティ単位で分割し、データの系譜と未使用のホールドアウトを維持してください。データセットやプロバイダーへのデータ送信、GPU の利用料金、アラートの配信、デプロイの前に承認を得てください。ドリフトアラームは診断ではなく、再トレーニング済みモデルを昇格させる自動的な根拠でもありません。固定ベースラインに対して、精度、キャリブレーション、公平性、遅延ラベル、ロールバックを評価してください。以下の数値目標は例示であり、普遍的な保証や実測結果ではありません。実際のテストと成果物、未解決のリスクを記録してください。設定ファイルを生成しただけでは、本番環境への対応や網羅性が確保されたことにはなりません。

フェーズ 1:データと要件の分析

subagent_type: data-engineer prompt: | 次の要件に基づき、ML システムのデータパイプラインを分析して設計してください:$ARGUMENTS

成果物:

  1. データソースの監査と取り込み戦略:

    • ソースシステムと接続パターン
    • Pydantic/Great Expectations を使用したスキーマ検証
    • DVC または lakeFS によるデータのバージョン管理
    • 増分ロードと CDC 戦略
  2. データ品質フレームワーク:

    • プロファイリングと統計情報の生成
    • 異常検知ルール
    • データリネージの追跡
    • 品質ゲートと SLA
  3. ストレージアーキテクチャ:

    • Raw/processed/feature レイヤー
    • パーティショニング戦略
    • 保持ポリシー
    • コスト最適化

重要なコンポーネントと統合パターンの実装コードを提示してください。

subagent_type: data-scientist prompt: | 次の内容について、特徴量エンジニアリングとモデル要件を設計してください:$ARGUMENTS 次のデータアーキテクチャを使用してください:{phase1.data-engineer.output}

成果物:

  1. 特徴量エンジニアリングパイプライン:

    • 変換仕様
    • 特徴量ストアのスキーマ(Feast/Tecton)
    • 統計的検証ルール
    • 欠損データ/外れ値への対処戦略
  2. モデル要件:

    • アルゴリズム選定の根拠
    • パフォーマンス指標とベースライン
    • トレーニングデータ要件
    • 評価基準としきい値
  3. 実験設計:

    • 仮説と成功指標
    • A/B テストの方法論
    • サンプルサイズの計算
    • バイアス検出のアプローチ

特徴量変換コードと統計的検証ロジックを含めてください。

フェーズ 2:モデル開発とトレーニング

subagent_type: ml-engineer prompt: | 次の要件に基づき、トレーニングパイプラインを実装してください:{phase1.data-scientist.output} 次のデータパイプラインを使用してください:{phase1.data-engineer.output}

包括的なトレーニングシステムを構築してください:

  1. トレーニングパイプラインの実装:

    • 明確なインターフェースを備えたモジュール式のトレーニングコード
    • ハイパーパラメーター最適化(Optuna/Ray Tune)
    • 分散トレーニングのサポート(Horovod/PyTorch DDP)
    • クロスバリデーションとアンサンブル戦略
  2. 実験追跡のセットアップ:

    • MLflow/Weights & Biases の統合
    • 指標の記録と可視化
    • アーティファクト管理(モデル、プロット、データサンプル)
    • 実験の比較と分析ツール
  3. モデルレジストリの統合:

    • バージョン管理とタグ付け戦略
    • モデルのメタデータとリネージ
    • 昇格ワークフロー(dev -> staging -> prod)
    • ロールバック手順

設定管理を含む完全なトレーニングコードを提示してください。

subagent_type: python-pro prompt: | 次の ML コードを最適化し、本番環境に対応させてください:{phase2.ml-engineer.output}

注力分野:

  1. コードの品質と構成:

    • 本番環境の標準に合わせてリファクタリング
    • 包括的なエラー処理を追加
    • 構造化形式による適切なロギングを実装
    • 再利用可能なコンポーネントとユーティリティを作成
  2. パフォーマンスの最適化:

    • ボトルネックをプロファイリングして最適化
    • キャッシュ戦略を実装
    • データの読み込みと前処理を最適化
    • 大規模トレーニング向けのメモリ管理
  3. テストフレームワーク:

    • データ変換のユニットテスト
    • パイプラインコンポーネントの統合テスト
    • モデル品質テスト(不変性、方向性)
    • パフォーマンスのリグレッションテスト

テストカバレッジを完全に備えた、本番環境ですぐに使える保守性の高いコードを提供してください。

フェーズ 3:本番環境へのデプロイとサービング

subagent_type: mlops-engineer prompt: | 次のモデルの本番環境へのデプロイを設計してください:{phase2.ml-engineer.output} 次の最適化済みコードを使用してください:{phase2.python-pro.output}

実装要件:

  1. モデルサービングインフラストラクチャ:

    • FastAPI/TorchServe を使用した REST/gRPC API
    • バッチ予測パイプライン(Airflow/Kubeflow)
    • ストリーム処理(Kafka/Kinesis との連携)
    • モデルサービングプラットフォーム(KServe/Seldon Core)
  2. デプロイ戦略:

    • ダウンタイムゼロを実現するブルーグリーンデプロイ
    • トラフィックを分割するカナリアリリース
    • 検証用のシャドーデプロイ
    • A/B テストインフラストラクチャ
  3. CI/CD パイプライン:

    • GitHub Actions/GitLab CI ワークフロー
    • 自動テストのゲート
    • デプロイ前のモデル検証
    • GitOps デプロイ用の ArgoCD
  4. Infrastructure as Code:

    • クラウドリソース用の Terraform モジュール
    • Kubernetes デプロイ用の Helm チャート
    • 最適化のための Docker マルチステージビルド
    • Vault/Secrets Manager によるシークレット管理

デプロイ設定と自動化スクリプトを完全な形で提供してください。

subagent_type: kubernetes-architect prompt: | 次の ML ワークロード向け Kubernetes インフラストラクチャを設計してください:{phase3.mlops-engineer.output}

Kubernetes 固有の要件:

  1. ワークロードのオーケストレーション:

    • Kubeflow によるトレーニングジョブのスケジューリング
    • GPU リソースの割り当てと共有
    • スポット/プリエンプティブルインスタンスとの連携
    • PriorityClass とリソースクォータ
  2. サービングインフラストラクチャ:

    • オートスケーリング用の HPA/VPA
    • イベント駆動型スケーリング用の KEDA
    • トラフィック管理用の Istio サービスメッシュ
    • モデルのキャッシュとウォームアップ戦略
  3. ストレージとデータアクセス:

    • トレーニングデータ用の PVC 戦略
    • CSI ドライバーによるモデルアーティファクトのストレージ
    • フィーチャーストア用の分散ストレージ
    • 推論を最適化するキャッシュレイヤー

ML プラットフォーム全体の Kubernetes マニフェストと Helm チャートを提供してください。

フェーズ 4:モニタリングと継続的改善

subagent_type: observability-engineer prompt: | 次にデプロイされた ML システムの包括的なモニタリングを実装してください:{phase3.mlops-engineer.output} 次の Kubernetes インフラストラクチャを使用してください:{phase3.kubernetes-architect.output}

モニタリングフレームワーク:

  1. モデルパフォーマンスのモニタリング:

    • 予測精度の追跡
    • レイテンシーとスループットのメトリクス
    • 特徴量重要度の変化
    • ビジネス KPI との相関
  2. データとモデルのドリフト検出:

    • 統計的ドリフト検出(KS 検定、PSI)
    • コンセプトドリフトのモニタリング
    • 特徴量分布の追跡
    • ドリフトに関するアラートとレポートの自動生成
  3. システムの可観測性:

    • すべてのコンポーネントの Prometheus メトリクス
    • 可視化用の Grafana ダッシュボード
    • Jaeger/Zipkin による分散トレーシング
    • ELK/Loki によるログ集約
  4. アラートと自動化:

    • PagerDuty/Opsgenie との連携
    • 再トレーニングの自動トリガー
    • パフォーマンス低下時のワークフロー
    • インシデント対応ランブック
  5. コスト追跡:

    • リソース使用率のメトリクス
    • モデル/実験別のコスト配分
    • 最適化の推奨事項
    • 予算アラートと制御

モニタリング設定、ダッシュボード、アラートルールを提供してください。

設定オプション

  • experiment_tracking: mlflow | wandb | neptune | clearml
  • feature_store: feast | tecton | databricks | custom
  • serving_platform: kserve | seldon | torchserve | triton
  • orchestration: kubeflow | airflow | prefect | dagster
  • cloud_provider: aws | azure | gcp | multi-cloud
  • deployment_mode: realtime | batch | streaming | hybrid
  • monitoring_stack: prometheus | datadog | newrelic | custom

成功基準

  1. データパイプラインの成功:

    • 本番環境でのデータ品質問題が 0.1% 未満
    • 自動データ検証が 99.9% の割合で合格
    • 完全なデータリネージの追跡
    • 特徴量の提供レイテンシが 1 秒未満
  2. モデルのパフォーマンス:

    • ベースライン指標を達成、または上回る
    • 再トレーニングまでのパフォーマンス低下が 5% 未満
    • 統計的有意性のある A/B テストの成功
    • 24 時間を超えて検出されないモデルドリフトがない
  3. 運用の卓越性:

    • モデル提供の稼働率 99.9%
    • p99 推論レイテンシが 200ms 未満
    • 5 分以内の自動ロールバック
    • アラート通知まで 1 分未満の、完全なオブザーバビリティ
  4. 開発速度:

    • コミットから本番環境まで 1 時間未満
    • 実験の並列実行
    • 再現可能なトレーニング実行
    • セルフサービスでのモデルデプロイ
  5. コスト効率:

    • インフラストラクチャの無駄が 20% 未満
    • リソース割り当ての最適化
    • 負荷に基づく自動スケーリング
    • スポットインスタンスの利用率が 60% 超

最終成果物

完了すると、オーケストレーションされたパイプラインによって以下が提供されます。

  • 自動化を全面的に備えたエンドツーエンドの ML パイプライン
  • 包括的なドキュメントと運用手順書
  • 本番環境に対応した Infrastructure as Code
  • 完全な監視・アラートシステム
  • 継続的な改善のための CI/CD パイプライン
  • コスト最適化とスケーリング戦略
  • 災害復旧およびロールバック手順

例

ユーザーからのリクエスト:

以下を対象に、完全な ML パイプラインを設計し、実装してください:$ARGUMENTS。

制限事項

  • 上記の説明にある対象範囲に、タスクが明確に合致する場合にのみ、このスキルを使用してください。
  • 環境固有の検証、テスト、専門家によるレビューの代替として、出力を扱わないでください。
  • 必要な入力、権限、安全上の境界、成功基準が不足している場合は、作業を中止して確認を求めてください。

コメント