mle-workflow

機械学習エンジニアリングワークフロー

このスキルを使用して、モデル作業を、明確なデータ契約、再現可能なトレーニング、測定可能な品質ゲート、デプロイ可能なアーティファクト、および運用監視を備えた本番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です。これにより、チームが誰も信頼しないメトリクスを最適化したり、実際のエラーモードに対処しない特徴量を追加したり、ロールバックなしで複雑さを出荷したりするのを防ぎます。

決定脳

タスクがあいまいで、影響が大きく、メトリクスが多い場合は、このループを使用してください。

1. モデルではなく、決定から始めてください。下流の動作を変更するアクションに名前を付けます。
2. 誰が気にするか、そしてその理由を名前を付けます。異なるステークホルダーは、偽陽性、偽陰性、レイテンシ、計算コスト、不透明性、機会損失に対して異なるコストを支払います。
3. あいまいさを仮説に変換します。どの信号が結果を分離するか、どの証拠がそれを反証するか、どの単純なベースラインが打ち負かしにくいかを尋ねます。
4. 独自のシステムを発明する前に、先行技術または近くの既知の問題を調査します。
5. 選択肢を (確率、信頼度) x (コスト、深刻度、重要度、影響) でスコアリングします。
6. 敵対的行動、インセンティブ、選択的開示、分布シフト、フィードバックループを考慮します。
7. 最も重要なミスを減らす最も単純な変更を優先します。単純さは怠惰ではありません。それは、反復速度を維持しながら、大失敗を最小限に抑える方法です。
8. 決定、証拠、反論、次の可逆的なステップをキャプチャします。

メトリクスとミスの経済学

習慣ではなく、失敗コストからメトリクスを選択してください。

• 早期に混同行列を使用して、チームが抽象的な精度ではなく、具体的な偽陽性と偽陰性について議論できるようにします。
• 誤った陽性決定のコストが支配的な場合は、精度を優先します。
• 見逃した陽性のコストが支配的な場合は、再現率を優先します。
• 精度/再現率のトレードオフが真にバランスが取れており、説明可能な場合にのみF1を使用します。
• 単一のしきい値よりも順序の品質が重要な場合は、AUCまたはランキングメトリクスを使用します。
• レイテンシ、スループット、メモリ、コストを第一級のメトリクスとして追跡します。これらは実現可能なモデルの複雑さを形成するためです。
• オフラインのゲインを祝う前に、ベースラインおよび現在の本番モデルと比較します。
• 実際のフィードバック信号を、バイアス、ラグ、カバレッジギャップを伴う遅延ラベルとして扱います。分析なしでそれらをグラウンドトゥルースとして扱わないでください。

すべてのメトリクスの選択は、どのミスを安くし、どのミスをより起こりやすくし、誰がそのコストを吸収するかを述べる必要があります。

データと特徴量の仮説

特徴量は分離の理論に基づくべきです。

• テキスト、カテゴリカルフィールド、数値履歴、グラフ関係、新しさ、頻度、集計は、自動的な特徴量ではなく、候補となる信号ファミリーです。
• すべての特徴量ファミリーについて、なぜそれが結果を分離するはずか、そしてそれがどのように将来の情報をリークする可能性があるかを述べてください。
• ノイズの多いラベルの場合は、判定、ラベル信頼度、ソフトターゲット、または信頼度重み付けを検討してください。
• クラスの不均衡の場合は、重み付き損失、リサンプリング、しきい値移動、キャリブレーションされた決定ルールを比較してください。
• 欠損値の場合は、不在が有益か、代入可能か、棄権する理由かを判断してください。
• 外れ値の場合は、クリップ、バケット化、調査、またはまれではあるが重要な信号として保存するかを判断してください。
• 相関する特徴量の場合は、それらが冗長、不安定、または利用できない将来の状態のプロキシであるかどうかを確認してください。

エラー分析で、ベースラインが追加の信号や容量で合理的に修正できる理由で失敗していることが示されるまで、モデルの複雑さを追加しないでください。

エラー分析ループ

各ベースライン、トレーニング実行、しきい値変更、または設定変更の後:

1. ミスを偽陽性、偽陰性、棄権、低信頼度ケース、システム障害に分割します。
2. エラーを共通の特性でクラスタリングします: 言語、エンティティタイプ、ソース、時間、地理、デバイス、スパース性、新しさ、特徴量の鮮度、ラベルソース、モデルバージョン。
3. モデルのミスをデータのバグ、ラベルの品質の問題、特徴量の欠落、サービングの不一致、または運用上の障害から分離します。
4. 各エラークラスタについて、修正の優先順位をリスクと影響で評価します。
5. 各修正を反復コンパクトの次の実験スロットに追加します。
6. 適切な場合は、回帰テストスイートにエラーケースを追加します。

トレーニングとサービングの同等性

トレーニング時の特徴量計算は、サービング時と同一でなければなりません。そうでなければ、オフラインのゲインは幻想であり、モデルは本番環境で予期せぬ動作をします。

• 同一のコードパスをトレーニングとサービングで使用するか、特徴量変換を共有ライブラリに抽出します。
• ポイントインタイムの正確性を保証して、ラベルがトレーニング時に将来の情報をリークしないようにします。
• 特徴量の鮮度と可用性の期待値を文書化します。トレーニング時に利用可能な特徴量がサービング時には利用できない場合があります。
• スキーマ変更を特徴量バージョンまたはデータ契約で明示的にします。

アーティファクト管理

モデルアーティファクトは、再現性のある方法でバージョン管理し、保存し、ロードする必要があります。

• モデルアーティファクトとともに、前処理コード、設定、依存関係をバンドルします。
• 安全なロードメカニズムを使用して、信頼できないソースからの悪意のあるアーティファクトを防ぎます。
• アーティファクトがPIIやその他の機密データをリークしないことを確認します。
• アーティファクトの保存と取得のための明確なロールバック戦略を用意します。

デプロイとロールアウト

デプロイはリスク管理の練習です。

• カナリアデプロイ、シャドウトラフィック、A/Bテストなどの戦略を使用して、リスクを軽減します。
• ロールアウト中の健全性を監視するための明確なメトリクスとダッシュボードを定義します。
• 問題が発生した場合に迅速にロールバックするための計画を用意します。
• ロールバックが行われた後に、根本原因を調査して修正する計画を立てます。

まとめ

このスキルは、機械学習モデルを堅牢な本番システムに変えるための実用的なガイドを提供します。重要なのは、すべてのMLシステムに同じ重厚なプロセスを強制するのではなく、各プロジェクトのニーズに合わせてスコープを調整することです。データ契約、明確なメトリクス、再現可能なトレーニング、徹底的な評価、慎重なデプロイ、継続的な監視に焦点を当てることで、信頼性が高く、保守可能で、ビジネス価値を提供するMLシステムを構築できます。