Mímisbrunnr知恵の泉

← MLOps 一覧

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：データドリフトとコンセプトドリフトの検知　|　関連：MLパイプラインのオーケストレーションとCI/CD/CT

要点（BLUF）

1. いつ再学習するか

flowchart TB
  T1["スケジュール：毎週/毎月など定期"] --> R["再学習を起動"]
  T2["性能トリガー：精度がしきい値を割った"] --> R
  T3["ドリフトトリガー：PSIがしきい値超過"] --> R
  T4["データ量トリガー：新データが一定量たまった"] --> R
  R --> G["評価ゲート＋前モデル比較"]
  G -->|"改善"| P["昇格（Staging->Production）"]
  G -->|"改善せず"| H["据え置き（現行を維持）"]
方針長所短所
スケジュール型単純・予測可能劣化に出遅れ／無駄な再学習も
トリガー型必要なときだけ・即応トリガー設計が難しい・誤発火

実務では併用が多い：定期再学習を土台にしつつ、ドリフト・性能トリガーで臨時再学習する。

2. CT（継続的トレーニング）が CI/CD に加わる意味

通常のソフトウェアは CI（継続的インテグレーション）/CD（継続的デリバリー）で回ります。ML はそこに **CT（継続的トレーニング）**が加わります——コードが変わらなくても、新しいデータで自動的に再学習・再デプロイする仕組みです。CI/CD/CT の三位一体が、MLOps 成熟度（MLOps成熟度モデルと自動化レベル）の L1–L2 を構成します。具体的なパイプライン自動化はMLパイプラインのオーケストレーションとCI/CD/CTで扱います。

3. 動く最小例：再学習トリガーの判定ロジック

監視指標（性能・ドリフト・新データ量・前回からの経過）から、再学習すべきかを判定する最小ロジックです。

def should_retrain(signals, policy):
    """signals: 現在の監視値。policy: 起動条件。
    戻り値: (再学習するか, 理由のリスト)"""
    reasons = []
    if signals["accuracy"] < policy["min_accuracy"]:
        reasons.append(f"性能低下 acc={signals['accuracy']:.3f} "
                        f"< {policy['min_accuracy']}")
    if signals["max_psi"] > policy["max_psi"]:
        reasons.append(f"ドリフト psi={signals['max_psi']:.2f} "
                        f"> {policy['max_psi']}")
    if signals["new_samples"] >= policy["new_samples"]:
        reasons.append(f"新データ蓄積 {signals['new_samples']} "
                        f">= {policy['new_samples']}")
    if signals["days_since"] >= policy["max_days"]:
        reasons.append(f"定期再学習 経過{signals['days_since']}日 "
                        f">= {policy['max_days']}")
    return (len(reasons) > 0), reasons

policy = {"min_accuracy": 0.85, "max_psi": 0.25,
          "new_samples": 10000, "max_days": 30}

# ケース1：ドリフトで起動
s1 = {"accuracy": 0.88, "max_psi": 0.53, "new_samples": 3000, "days_since": 7}
print("ケース1:", should_retrain(s1, policy))

# ケース2：すべて正常 -> 再学習しない
s2 = {"accuracy": 0.90, "max_psi": 0.08, "new_samples": 2000, "days_since": 10}
print("ケース2:", should_retrain(s2, policy))

出力：

ケース1: (True, ['ドリフト psi=0.53 > 0.25'])
ケース2: (False, [])

出力の意味：ケース1は性能（0.88）は基準内ですが、PSI=0.53 がしきい値0.25を超えたのでドリフトを理由に再学習を起動します（データドリフトとコンセプトドリフトの検知の検知結果がそのままトリガーになる）。ケース2は性能・ドリフト・データ量・経過日数すべてが条件を満たさないので再学習しません。「いつ再学習するか」を勘でなく明文化した条件で自動判定する——これが CT の入口です。起動した再学習は、この後で必ず評価ゲートを通します。

4. 運用の勘所

なぜそうするのか

再学習をトリガー型で自動化するのは、劣化のタイミングは予測できないからです。ドリフトはいつ起きるか分からないので、定期再学習だけでは出遅れます。一方で、再学習を「無条件に本番投入」しないのは、新しいデータが必ずしも良いモデルを生むとは限らないからです。汚染データやドリフトを学習して悪化することもある。だから「劣化を検知したら再学習を起動するが、改善を確認するまで昇格しない」という、起動は積極的・昇格は慎重な非対称な設計にします。これがループを安全に閉じる鍵です。

⚠️ よくある落とし穴

対応 lab

関連ノート