Skip to content

MLシステム基礎

TL;DR

機械学習システムは、コードだけでなく、データ、特徴量、ラベル、モデル成果物、フィードバックループに依存するソフトウェアシステムです。中心課題は「モデルを学習すること」ではなく、世界が変化しても学習、サービング、監視、再学習を整合させ続けることです。


MLシステムの境界

通常のサービスはコードと設定を出荷します。MLシステムは、パイプラインによって生成された意思決定関数を出荷します。

重要なのはフィードバックループです。推薦モデルはユーザーが見るものを変え、それがクリックを変え、将来の学習データを変えます。不正検知モデルは取引を止め、観測されるラベル分布を変えます。


本番MLの構成要素

構成要素管理するものよくある障害
データ取り込み生イベントと鮮度パーティション欠落、重複、スキーマ変化
特徴量パイプライン学習とサービングで使う変換学習・サービング間のズレ、古い特徴量
学習パイプラインデータセット、アルゴリズム、評価再現できないモデル、リーク
モデルレジストリ成果物のバージョンと昇格状態間違ったモデルのデプロイ
サービング層オンラインまたはバッチ予測レイテンシ悪化、リソース枯渇
監視データ、予測、品質、事業指標静かな品質劣化

MLシステムの制御プレーン

本番MLでは「モデル」だけを見るとブラスト半径を見誤ります。

プレーン管理するもの弱いと起きる事故
データ取り込み、ラベル、JOIN、バックフィル、保持重複や未来ラベルで学習する
特徴量定義、オンライン/オフライン一致、鮮度古い特徴量や意味の変わった特徴量を使う
モデル成果物、レジストリ、ランタイム、ロールバック間違った成果物が本番に出る
意思決定しきい値、ポリシー、フォールバック、人間レビューAUCは良いがユーザーアクションが悪化する
実験割当、表示ログ、指標、ガードレール壊れた実験データで出荷判断する
ガバナンスリスク階層、所有者、監査、廃止高影響モデルが所有者なしで動く

設計レビューで変更がどのプレーンに属するか説明できないなら、本番準備は不足しています。


学習とサービング

学習は大きな履歴データで品質を最適化します。サービングはライブトラフィックの下でレイテンシと信頼性を最適化します。同じ特徴量名が両方の経路で同じ意味を持つことが重要です。


設計判断

判断選ぶ条件注意点
バッチ予測結果を事前計算できる予測が古くなる
オンライン予測今すぐユーザー向け判断が必要レイテンシと依存先障害
ストリーミング予測連続イベントを処理する状態管理と重複処理
ライブラリとして埋め込み最低レイテンシが必要独立更新が難しい
共有モデルサービスロールアウトと監視を集中したいネットワークホップが増える

問題タイプ別の設計

問題典型構成主なリスク
不正/ abuseオンラインモデル + 特徴量ストア + ルール + レビュー偽陽性、遅延ラベル
推薦候補生成 + ランカー + 再ランキング + 探索ログフィードバックループ
検索ランキング検索 + ランキング + 実験位置バイアス
チャーン予測バッチスコア + キャンペーン古いセグメント
異常検知ストリーミング特徴量 + アラートアラート疲れ

アーキテクチャは意思決定ループに合わせます。


代表的な障害モード

学習・サービング間のズレ

学習ではある変換を使い、サービングでは別の変換を使ってしまう状態です。オフライン評価は良くても本番品質が落ちます。

対策:

  • 共有された特徴量定義を使う。
  • 学習とサービングの特徴量パリティテストを行う。
  • サービング時の特徴量をログに残して再生できるようにする。

データリーク

予測時には存在しない情報が学習データに入る問題です。タイムスタンプ、JOIN、ラベルの書き戻しでよく発生します。

対策:

  • 時点整合なデータセットを作る。
  • イベント時刻と処理時刻を分ける。
  • 各特徴量が意思決定時点で利用可能だったかを確認する。

静かなモデル劣化

サービスは稼働し、エラーも少ないのに、世界の変化により予測品質が落ちます。

対策:

  • 入力分布と予測分布を監視する。
  • 遅延ラベルを結合する。
  • ビジネス指標とユーザー影響を追う。
  • ロールバック経路を維持する。

代理目的のミスマッチ

測りやすい指標を最適化して、本当に必要な成果を悪化させる問題です。

  • クリック率最適化が低品質コンテンツを増やす。
  • 不正検知のRecall最適化が正当ユーザーを止める。
  • 視聴時間最適化が長期満足度を下げる。

対策は、主指標、ガードレール、診断指標、スライス指標を分けることです。


運用メトリクス

レイヤーメトリクス
データ鮮度、完全性、NULL率、重複率、スキーマ変更
特徴量オンライン/オフライン差分、鮮度、分布変化
学習パイプライン時間、失敗率、データ版、成果物ハッシュ
評価Precision/Recall、キャリブレーション、スライス別品質
サービングp50/p95/p99、エラー率、タイムアウト、CPU/GPU使用率
ビジネスコンバージョン、不正損失、継続率、苦情、手動レビュー量

アーキテクチャレビュー項目

  • 学習データセットをコードとデータスナップショットから再現できるか。
  • 特徴量は時点整合か。
  • オンライン特徴量とオフライン特徴量は同じ契約から作られるか。
  • アプリケーションコードを戻さずにモデルだけロールバックできるか。
  • 各予測をモデルバージョン、特徴量、リクエスト文脈まで追跡できるか。
  • デプロイ後の品質を監視しているか。

成熟度モデル

レベル状態リスク
0. ノートブック手動データ取得、手動評価、手動デプロイ再現できない
1. 定期学習パイプラインはあるがリネージが弱い悪いデータで静かに学習
2. レジストリ管理成果物、指標、所有者を登録特徴量ズレが残る
3. 制御されたロールアウトシャドー、カナリー、ロールバック遅延ラベル対応が必要
4. ガバナンス付き意思決定リスク階層、監査、人間制御、廃止手続きコストが高い

一気に最高レベルを目指すより、再現性、レジストリ、ロールアウト、ガバナンスの順に強化します。


重要なポイント

  1. モデルはMLシステムの一部にすぎない。
  2. データ、特徴量、ラベル、フィードバックループは本番依存関係である。
  3. 学習とサービングは一緒に設計する。
  4. オフライン評価だけでは不十分。
  5. モデル挙動の監視はサービス稼働監視と同じくらい重要。

参考文献

  1. Hidden Technical Debt in Machine Learning Systems
  2. TFX: A TensorFlow-Based Production-Scale Machine Learning Platform
  3. Data Validation for Machine Learning
  4. TensorFlow Serving: Flexible, High-Performance ML Serving

MITライセンスの下で公開。Babushkaiコミュニティが構築。