MLシステム設計 — モデルの外側の9割

ノートブックで出た精度は、本番では約束になりません。特徴量の定義、学習と推論のズレ（スキュー）、劣化に気づく監視、そして再学習の輪。モデルの外側にある「9割」を、前提知識ゼロから設計の順番に並べ直します。

比喩: 名店の味を、支店で再現する

本店のシェフが、誰もが唸るソースを完成させたとします。ではレシピを配れば、支店10店で同じ味が出るでしょうか。出ません。店ごとに仕入れ先が違えば素材が変わり、下ごしらえの手順書が曖昧なら工程が人によってずれ、冷蔵庫が半日止まっていても誰も気づかない。味が再現できるかどうかを決めているのは、シェフの腕ではなく厨房の設計のほうです。

機械学習の本番システムも、まったく同じ構造をしています。ノートブックの中で高い精度を出したモデルは、レシピにすぎません。そのレシピが毎日同じ結果を出し続けるかどうかは、素材（データ）の入手経路が安定しているか、下ごしらえ（特徴量の計算）が学習時と本番で一致しているか、味が落ちたときに気づく仕組みがあるか、で決まります。Sculley らの "Hidden Technical Debt in Machine Learning Systems"（NeurIPS 2015）が広めたのは、まさにこの構図でした。システム全体を箱で描くと、「MLのコード」は真ん中にある小さな箱ひとつにしかならない、という指摘です。

この記事が扱うのは、その小さな箱の外側です。

全体像: MLシステムは直線ではなく輪

入門書に出てくる流れは、たいてい一本の直線で描かれます。データを集め、特徴量を作り、学習し、評価し、デプロイする。しかし本番に置いた瞬間、この線の端と端がつながって輪になります。

デプロイされたモデルは予測を出し、その予測がユーザーの行動を変え、変わった行動がログに残り、そのログが明日の学習データになる。推薦システムなら露骨で、「表示したから押された」商品ばかりが正例として溜まっていきます。モデルが自分の作った世界を学び直す、という自己参照がここで生まれます。普通のWebシステムには無い、MLだけの厄介さです。

この輪の上には、事故が集中する境界が4つあります。

1. 学習と推論の境界 — 同じ入力から同じ特徴量が出ているか（学習・推論スキュー）
2. 過去と現在の境界 — 予測時点では知り得ない情報を、学習時に混ぜていないか
3. オフラインとオンラインの境界 — 検証データでの数字が、本番の成果と結びついているか
4. モデルと世界の境界 — 世界のほうが動いたことに気づけるか（ドリフト）

MLシステムの設計とは、要するにこの4つの境界に検問を置く作業です。順に見ていきます。

オフラインの数字が保証してくれる範囲

まず境界③から始めるのが健全です。手元の検証データで測れるのは、「過去のある期間のデータ」という1つの世界の中での汎化だけだからです。それ以上のことは何も言っていません。

モデルを複雑にしていくと訓練誤差は下がり続ける一方、未知データでの誤差はどこかで反転して悪化します。この乖離は下の図で直接いじって確かめられます。ここで大事なのは、この図に描かれている「テスト誤差」ですら、本番の誤差ではないという点です。テストデータは過去から切り出したものなので、世界が動けばその数字ごと古くなります。

だからオフライン評価は「デプロイしてよいかの足切り」であって、「うまくいく保証」ではありません。評価設計そのものの作法は過学習と評価設計にまとめてあります。本番で効くかどうかは、最終的にオンラインで測るしかない — その測り方が統計的検定とABテストです。

特徴量: 定義が二重化した瞬間に負ける

いちばん多い事故は、モデルではなく特徴量の計算で起きます。学習用の特徴量は分析基盤の上でSQLで書かれ、本番の推論サーバではPythonで書き直される。書いた人も時期も違うので、片方は「金額の欠損は0」、もう片方は「欠損は平均で埋める」。モデルは何も悪くないのに、本番の予測だけが静かにずれます。