機械学習エンジニアリングワークフロー
このスキルを使用して、モデル作業を、明確なデータ契約、再現可能なトレーニング、測定可能な品質ゲート、デプロイ可能なアーティファクト、および運用モニタリングを備えた本番MLシステムに変換します。
有効化するタイミング
- 本番ML機能、モデルリフレッシュ、ランキングシステム、レコメンダー、分類器、埋め込みワークフロー、または予測パイプラインの計画やレビューを行う場合
- ノートブックコードを、再利用可能なトレーニング、評価、バッチ推論、またはオンライン推論パイプラインに変換する場合
- モデルプロモーション基準、オフライン/オンライン評価、実験トラッキング、またはロールバックパスを設計する場合
- データドリフト、ラベルリーク、古い特徴量、アーティファクトの不一致、または不整合なトレーニングとサービングロジックによって引き起こされる障害をデバッグする場合
- モデルモニタリング、カナリアロールアウト、シャドウトラフィック、またはデプロイ後の品質チェックを追加する場合
スコープの調整
目前のシステムに適合するレーンだけを使用してください。このスキルは、ランキング、検索、レコメンデーション、分類器、予測、埋め込み、LLMワークフロー、異常検知、バッチ分析に役立ちますが、1つのアーキテクチャを全てに強制するものではありません。
- すべてのモデルが教師ありラベル、オンラインサービング、フィーチャーストア、PyTorch、GPU、人間によるレビュー、A/Bテスト、またはリアルタイムフィードバックを持つと仮定しないでください。
- データ契約、ベースライン、評価スクリプト、ロールバックのメモがあれば変更をレビュー可能にできる場合に、重厚なMLOps機構を追加しないでください。
- プロジェクトにラベル、遅延結果、スライス定義、本番トラフィック、またはモニタリングの所有権がない場合、その仮定を明示的にしてください。
- 例は交換可能な足場として扱ってください。メトリクス、サービングモード、データストア、ロールアウトメカニクスは、プロジェクトネイティブの同等物に置き換えてください。
関連スキル
python-patternsおよびpython-testing：Python実装とpytestカバレッジ用pytorch-patterns：深層学習モデル、データローダー、デバイスハンドリング、トレーニングループ用eval-harnessおよびai-regression-testing：プロモーションゲートとエージェント支援回帰チェック用database-migrations、postgres-patterns、およびclickhouse-io：データストレージと分析面用deployment-patterns、docker-patterns、およびsecurity-review：サービング、シークレット、コンテナ、本番環境の堅牢化用
SWEサーフェスの再利用
MLEをソフトウェアエンジニアリングから分離しないでください。ECC SWEワークフローのほとんどは、多くの場合、より厳格な障害モードでMLシステムに直接適用できます。
推奨される minimal --with capability:machine-learning インストールでは、このスキルとともにコアエージェントサーフェスを利用可能にします。スキル専用またはエージェント制限のあるハーネスの場合は、ターゲットがエージェントをサポートしている場合、skill:mle-workflow を agent:mle-reviewer とペアリングしてください。
| SWEサーフェス | MLEでの使用法 |
|---|---|
product-capability / architecture-decision-records | モデル作業を明示的なプロダクト契約に変換し、データ、モデル、ロールアウトの不可逆的な選択を記録する |
repo-scan / codebase-onboarding / code-tour | 並列MLスタックを導入する前に、既存のトレーニング、特徴量、サービング、評価、モニタリングパスを見つける |
plan / feature-dev | モデル変更を、データ、評価、サービング、ロールバックフェーズを持つプロダクト機能としてスコープする |
tdd-workflow / python-testing | 実装前に、特徴量変換、分割ロジック、メトリクス計算、アーティファクト読み込み、推論スキーマをテストする |
code-reviewer / mle-reviewer | コード品質に加えて、ML固有のリーク、再現性、プロモーション、およびモニタリングリスクをレビューする |
build-fix / pr-test-analyzer | 壊れたCI、不安定な評価、欠落したフィクスチャ、環境固有のモデルまたは依存関係障害を診断する |
quality-gate / test-coverage | 変換、メトリクス、推論契約、プロモーションゲート、ロールバック動作に対する自動化されたエビデンスを要求する |
eval-harness / verification-loop | オフラインメトリクス、スライスチェック、レイテンシ予算、ロールバック訓練を反復可能なゲートに変える |
ai-regression-testing | すべての本番バグを回帰として保存する：欠落した特徴量、古いラベル、不適切なアーティファクト、スキーマドリフト、サービングの不一致 |
api-design / backend-patterns | 予測API、バッチジョブ、べき等な再トレーニングエンドポイント、応答エンベロープを設計する |
database-migrations / postgres-patterns / clickhouse-io | ラベル、特徴量スナップショット、予測ログ、実験メトリクス、ドリフト分析をバージョン管理する |
deployment-patterns / docker-patterns | ヘルスチェック、リソース制限、ロールバックを備えた再現可能なトレーニングおよびサービングイメージをパッケージ化する |
canary-watch / dashboard-builder | モデルバージョン、スライス、ドリフト、レイテンシ、コスト、遅延ラベルのダッシュボードでロールアウトの健全性を可視化する |
security-review / security-scan | モデルアーティファクト、ノートブック、プロンプト、データセット、ログにシークレット、PII、安全でないデシリアライゼーション、サプライチェーンリスクがないか確認する |
e2e-testing / browser-qa / accessibility | 説明可能性やフォールバックUI状態を含む、予測を消費する重要なプロダクトフローをテストする |
benchmark / performance-optimizer | スループット、p95レイテンシ、メモリ、GPU使用率、予測または再トレーニングあたりのコストを測定する |
cost-aware-llm-pipeline / token-budget-advisor | 最大のモデルをデフォルトにする代わりに、品質、レイテンシ、予算に基づいてLLM/埋め込みワークロードをルーティングする |
documentation-lookup / search-first | コーディング前に、モデルサービング、フィーチャーストア、ベクトルDB、評価ツールの現在のライブラリ動作を確認する |
git-workflow / github-ops / opensource-pipeline | MLE変更を、明確なスコープ、生成アーティファクトの除外、再現可能なテストエビデンスとともにレビュー用にパッケージ化する |
strategic-compact / dmux-workflows | 長期間のML作業を並列トラックに分割する：データ契約、評価ハーネス、サービングパス、モニタリング、ドキュメント |
10のMLEタスクシミュレーション
MLE作業を計画またはレビューする際に、カバレッジチェックとしてこれらのシミュレーションを使用してください。強力なMLEワークフローは、各タスクを明示的な契約、再利用可能なSWEサーフェス、自動化されたエビデンス、レビュー可能なアーティファクトに削減する必要があります。
| ID | 一般的なMLEタスク | 効率的なECCパス | 必要な出力 | 対象となるパイプラインレーン |
|---|---|---|---|---|
| MLE-01 | 曖昧な予測、ランキング、レコメンダー、分類器、埋め込み、または予測機能をフレーム化する | product-capability、plan、architecture-decision-records、mle-workflow | 誰が気にするか、意思決定者、成功指標、許容できない過ち、前提、制約、最初の実験を命名するイテレーションコンパクト | プロダクト契約、ステークホルダーの損失、リスク、ロールアウト |
| MLE-02 | メトリクス目標、ラベル、データソース、過ちの許容範囲を定義する | repo-scan、database-reviewer、database-migrations、postgres-patterns、clickhouse-io | エンティティ粒度、ラベルタイミング、ラベル信頼度、特徴量タイミング、ポイントインタイム結合、分割ポリシー、データセットスナップショットを含むデータとメトリクス契約 | データ契約、メトリクス設計、リーク、再現性 |
| MLE-03 | 複雑性を追加する前に、ベースラインモデルとスコアリングパスを構築する | tdd-workflow、python-testing、python-patterns、code-reviewer | 混同行列、キャリブレーションノート、レイテンシ/コスト見積もり、既知の弱点、スコア形状と決定性のテストを含むベースラインスコアラー | ベースライン、スコアリング、テスト、サービングパリティ |
| MLE-04 | 結果を分ける仮説から特徴量を生成する | python-patterns、pytorch-patterns、docker-patterns、deployment-patterns | 信号ソース、欠損値、外れ値、相関、リークチェック、トレーニング/サービング等価性をカバーする特徴量計画と変換モジュール | 特徴量パイプライン、リーク、トレーニング、アーティファクト |
| MLE-05 | トレードオフの下でしきい値、設定、モデル複雑性を調整する | eval-harness、ai-regression-testing、quality-gate、test-coverage | 精度、再現率、F1、AUC、キャリブレーション、グループスライス、レイテンシ、コスト、複雑性、許容可能なエラークラスを比較するしきい値/設定レポート | 評価、しきい値、プロモーション、回帰 |
| MLE-06 | エラー分析を実行し、過ちを次の実験に変える | eval-harness、ai-regression-testing、mle-reviewer、silent-failure-hunter | 偽陽性、偽陰性、曖昧なラベル、古い特徴量、欠落した信号、学んだ教訓を含むバグトレースのエラークラスタレポート | エラー分析、バグトレース、イテレーション、回帰 |
| MLE-07 | バッチまたはオンライン推論用にモデルアーティファクトをパッケージ化する | api-design、backend-patterns、security-review、security-scan | 前処理、設定、依存関係制約、スキーマ検証、安全な読み込み、PIIセーフなログを含むバージョン管理されたアーティファクトバンドル | アーティファクト、セキュリティ、推論契約 |
| MLE-08 | フィードバックキャプチャを備えたオンラインサービングまたはバッチスコアリングをリリースする | api-design、backend-patterns、e2e-testing、browser-qa、accessibility | 応答エンベロープ、タイムアウト、バッチ処理、フォールバック、モデルバージョン、信頼度、フィードバックログ、プロダクトフローテストを含む予測エンドポイントまたはバッチジョブ | サービング、バッチ推論、フォールバック、ユーザーワークフロー |
| MLE-09 | シャドウトラフィック、カナリア、A/Bテスト、またはロールバックでモデルをロールアウトする | canary-watch、dashboard-builder、verification-loop、performance-optimizer | トラフィック分割、ダッシュボード、p95レイテンシ、コスト、品質ガードレール、ロールバックアーティファクト、ロールバックトリガーを命名するロールアウト計画 | デプロイメント、カナリア、ロールバック |
| MLE-10 | 本番モデルを運用、デバッグ、リフレッシュする | silent-failure-hunter、dashboard-builder、mle-reviewer、doc-updater、github-ops | ドリフトチェック、遅延ラベルの健全性、アラートオーナー、ランブック更新、再トレーニング基準、PRエビデンスを含む観察台帳とリフレッシュ計画 | モニタリング、インシデント対応、再トレーニング |
イテレーションコンパクト
モデルコードに触れる前に、作業を1つのレビュー可能なアーティファクトに圧縮してください。これはPRの説明に収まるほど短く、別のエンジニアがトレードオフに異議を唱えられるほど正確である必要があります。
目標：
誰が気にするか：
意思決定者：
モデルによって変更されるユーザーまたはシステムアクション：
成功指標：
ガードレールメトリクス：
過ちの許容範囲：
許容できない過ち：
許容可能な過ち：
前提：
制約：
ラベルとデータスナップショット：
ベースライン：
候補信号：
しきい値または設定計画：
評価スライス：
既知のリスク：
次の実験：
ロールバックまたはフォールバック：
このコンパクトは、強力なSWE設計ノートに相当するMLEです。これにより、チームが誰も信頼しないメトリクスの最適化、実際のエラーモードに対処しない特徴量の追加、またはロールバックなしで複雑さをリリースすることを防ぎます。
意思決定ブレイン
タスクが曖昧で、影響が大きく、メトリクスに依存している場合は常にこのループを使用してください。
- モデルではなく決定から始めてください。ダウンストリームの動作を変更するアクションに名前を付けてください。
- 誰が気にするか、そしてその理由を述べてください。異なるステークホルダーは、偽陽性、偽陰性、レイテンシ、計算コスト、不透明性、または機会損失に対して異なるコストを支払います。
- 曖昧さを仮説に変換してください。どの信号が結果を分けるか、どの証拠がそれを反証するか、どの単純なベースラインが打ち負かすのが難しいかを尋ねてください。
- 独自のシステムを発明する前に、先行研究または近くの既知の問題を調査してください。
(確率、信頼度) x (コスト、重大度、重要度、影響)で選択肢をスコアリングしてください。- 敵対的行動、インセンティブ、選択的開示、分布シフト、フィードバックループを考慮してください。
- 最も重要な過ちを減らす最も単純な変更を優先してください。単純さは怠惰ではありません。それは、反復速度を維持しながら大失敗を最小限に抑える方法です。
- 決定、証拠、反論、次の可逆的ステップを記録してください。
メトリクスと過ちの経済学
習慣ではなく、障害のコストからメトリクスを選択してください。
- チームが抽象的な精度ではなく、具体的な偽陽性と偽陰性について議論できるように、早期に混同行列を使用してください。
- 誤った肯定的な決定のコストが支配的な場合は、精度を優先してください。
- 見逃された肯定的なもののコストが支配的な場合は、再現率を優先してください。
- 精度/再現率のトレードオフが真にバランスが取れており、説明可能な場合にのみF1を使用してください。
- 順序付けの品質が単一のしきい値よりも重要な場合は、AUCまたはランキングメトリクスを使用してください。
- レイテンシ、スループット、メモリ、コストを第一級のメトリクスとして追跡してください。これらは実現可能なモデル複雑性を形成するからです。
- オフラインの改善を祝福する前に、ベースラインおよび現在の本番モデルと比較してください。
- 実際のフィードバック信号を、バイアス、ラグ、カバレッジギャップのある遅延ラベルとして扱い、分析なしに真実として扱わないでください。
すべてのメトリクス選択は、どの過ちをより安くし、どの過ちをより起こりやすくし、誰がそのコストを吸収するかを述べる必要があります。
データと特徴量の仮説
特徴量は分離の理論に基づくべきです。
- テキスト、カテゴリフィールド、数値履歴、グラフ関係、新しさ、頻度、集計は、自動的な特徴量ではなく、候補信号ファミリーです。
- すべての特徴量ファミリーについて、それがなぜ結果を分けるべきか、どのように将来の情報をリークする可能性があるかを述べてください。
- ノイズの多いラベルの場合は、裁定、ラベル信頼度、ソフトターゲット、または信頼度重み付けを検討してください。
- クラス不均衡の場合は、重み付き損失、リサンプリング、しきい値移動、キャリブレーションされた決定ルールを比較してください。
- 欠損値の場合は、不在が情報的であるか、代入可能であるか、棄権する理由であるかを決定してください。
- 外れ値の場合は、クリップするか、バケットするか、調査するか、まれだが重要な信号として保持するかを決定してください。
- 相関する特徴量の場合は、それらが冗長であるか、不安定であるか、利用できない将来の状態のプロキシであるかを確認してください。
エラー分析が、ベースラインが追加の信号や容量で修正可能な理由で失敗していることを示すまで、モデルの複雑性を追加しないでください。
エラー分析ループ
各ベースライン、トレーニング実行、しきい値変更、または設定変更の後：
- 過ちを、偽陽性、偽陰性、棄権、低信頼度のケース、システム障害に分割してください。
- 共有特性（言語、エンティティタイプ、ソース、時間、地理、デバイス、スパース性、新しさ、特徴量の鮮度、ラベルソース、モデルバージョン）でエラーをクラスタリングしてください。
- モデルの過ちとデータのバグを分離してください（以下略）
[原文が途中で切れていますが、翻訳はここまでとします]