ML導入プレイブック は何をしますか？
このスキルは、既存のソフトウェアエンジニアリングプロジェクトに機械学習モデルを実装するための適応型方法論を提供します。従来のSWEとMLOpsのギャップを埋め、MLの調査、分離、トレーニング、統合を構造化します。
アクティブ化のタイミング
- ユーザーが既存のコードベースに「MLを追加」または「アルゴリズムを追加」と依頼した場合。
- 非MLアプリケーションに新しいモデル（例：レコメンデーション、分類、予測）の統合を計画している場合。
- エージェントがMLコンポーネントを適応的に構築、トレーニング、デプロイするワークフローを構造化する場合。
フェーズ1: 問題フレーミングと実現可能性
モデルコードを書く前に、「なぜ」と「どのように」を確立します。
- ヒューリスティックチェック: 単純なヒューリスティック（例：正規表現、ルールベースのソート）で問題をより速く解決できるかどうかをユーザーに尋ねます。もし可能なら、そちらから始めます。
- メトリクス定義: MLモデルが改善しようとしているビジネスメトリクス（例：クリック率、レイテンシの低減）を定義します。
- エラー予算: 「悪い」予測がどのようなものか、システムがそれをどのように処理すべきかを定義します。
フェーズ2: データ準備
MLは、クリーンでアクセス可能なデータなしには役に立ちません。
- データソースの監査: トレーニングデータがどこにあるかを特定します。ライブデータベース、静的CSV、またはAPIですか？
- データ契約: 入力データのスキーマを確立します。どの特徴量が必要ですか？特徴量が欠落している場合はどうなりますか？
- リーク防止: ユーザーが提案するデータ分割が、将来の情報をトレーニングセットに誤って漏洩しないようにします（例：時系列データの時系列分割）。
フェーズ3: アーキテクチャの統合と分離
モデル推論をコアビジネスロジックに密結合しないでください。
- API境界: モデルをAPIエンドポイント（例：
fastapi-patternsやdjango-patternsを使用）または専用のサービス層の背後に配置することを提案します。 - フォールバックメカニズム: デフォルト状態を設計します。モデルの応答が遅すぎる場合やエラーが発生した場合、システムはハードコードされたルールにグレースフルにフォールバックする必要があります。
- フィーチャーフラグ: 新しいML推論呼び出しをフィーチャーフラグでラップし、安全にロールアウト（またはロールバック）できるようにします。
フェーズ4: モデルの実装とトレーニング
再現性と反復のためのコードを構造化します。
- シンプルに開始: 最初にベースラインモデル（例：シンプルなscikit-learnのロジスティック回帰や、最小限のPyTorch線形層）を構築します。
- 再現性:
pytorch-patternsや類似のベストプラクティスを適用します：乱数シードを固定し、コードをデバイス非依存にし、テンソル/配列の形状を明示的にドキュメント化します。 - 自動化されたエビデンス: データ変換と推論スキーマのテストを要求します。ベースラインと比較する評価スクリプトなしにモデルを受け入れてはいけません。
フェーズ5: MLOpsへの引き継ぎ
ベースラインモデルが統合されたら、継続的な運用に焦点を移します。
mle-workflowを参照: ユーザーを実験追跡、モデルレジストリ、ドリフト検出の設定へと導きます。- CI/CD: 既存のCIパイプラインにモデル評価ステップを追加し、将来のコミットでモデルパフォーマンスが低下しないようにします。
反復型エージェントワークフロー
このプレイブックを通じてユーザーを支援する際、エージェントは以下のことを行う必要があります：
- アーキテクチャを提案する前に、明確化の質問をして フェーズ1を完了します。
- フェーズ2でユーザーの承認を得るために データ契約のドラフト を作成します。
- トレーニングループを書く 前に フェーズ3で 分離インターフェース（API/サービス）を記述 します。
- モデルをトレーニングしアーティファクトを保存する 再現可能なスクリプト をフェーズ4で提供します。