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で作成し、ユーザーの承認を得ます。
- デカップリングインターフェース（API/サービス） をフェーズ3で記述し、その後 トレーニングループを記述します。
- 再現可能なスクリプト をフェーズ4で提供し、モデルをトレーニングしてアーティファクトを保存します。