MLOps

ML パイプラインは、データの取得 → 前処理・特徴量 → 学習 → 評価 → モデルの登録 → デプロイまでを、手作業ではなく決まった手順として自動で流す仕組みです。ノートブックで手で動かしていると、誰がいつどのデータで作ったモデルなのか分からなくなり、再学習のたびにミスが起きます。各段階を独立した処理（コンテナなど）にし、入力と出力を記録しておくと、途中からやり直したり、同じ結果を再現したりできます。

どれを選ぶかは、すでに使っているクラウドやデータ基盤に合わせるのが基本です。小さく始めるなら、定期実行のジョブと実験管理の道具の組み合わせでも十分です。

再学習のきっかけ：

• 定期：毎週・毎月など。一番簡単で、多くの場合はこれで足ります。データの変化の速さに合わせて間隔を決めます。
• 精度の低下：正解が分かって精度を測れる場合に、しきい値を下回ったら。
• ドリフトの検知：入力の分布が大きく変わったら（ドリフトを参照）。
• データやコードの変更：新しい特徴量を足した、ラベルの定義を変えたなど。

自動で再学習しても、自動で本番に出してよいとは限りません。今のモデルと同じ評価データで比べ、下回ったら止める関門（ゲート）を必ずパイプラインに入れます。

モデルレジストリは、学習したモデルをバージョン付きで保存し、「どのデータとコードで作ったか」「評価の結果」「今どの段階か（検証中・本番・引退）」を一緒に管理する場所です。MLflow のモデルレジストリや、各クラウドのサービスがあります。本番で動いているモデルがどれか、1つ前はどれかがすぐ分かることが、安全なデプロイとロールバックの前提になります。

段階的に本番へ出す：オフラインの評価を通っても、本番のデータで初めて分かる問題があるので、いきなり全員に出しません。

ロールバック：問題が起きたら、すぐ前のモデルに戻せるようにしておきます。

• 前のバージョンのモデルをレジストリに残し、設定の切り替えだけで戻せるようにする（作り直さない）。
• 戻す条件を事前に決める（例：エラー率が 1% を超えた、予測の陽性の割合が 2倍になった）。自動で戻す仕組みにできればなお良いです。
• モデルと特徴量・前処理の版を一緒に管理する。モデルだけ戻して、特徴量の作り方が新しいままだと合わなくなります。

普通のソフトウェアの CI/CD はコードが変わったときに動きますが、ML ではデータが変わるだけでもモデルが変わります。そのため、コードのテストにデータのテストとモデルのテストを足します。

学習は時間がかかるので、CI では小さなデータで「最後まで動くか」だけを確かめ、本番用の学習はパイプラインで行う、のように分けるのが現実的です。

モデルの事故の多くは、モデルではなく上流のデータの変化から起きます。列の単位が変わった、ある日だけ件数が半分になった、全部 NULL になった、などです。学習の前と推論の入力の両方で、データを自動で確かめます。

Great Expectations や TensorFlow Data Validation のような道具もありますが、まずは SQL で件数と欠損の割合を数えて、前回と比べるだけでも多くの事故を防げます。「止める」と「警告だけ」の基準を分けておくと、誤報で学習が止まり続けることを避けられます。

ノートブックで良い結果が出たモデルを本番に載せるには、次のような作業が要ります。面接でも「試作から本番まで何をしますか」はよく聞かれます。

全部を最初からそろえる必要はありません。まず「再現できる・前処理が共通・戻せる」の3つを満たしてから出し、残りは使われ方を見ながら足していきます。