6.2 機械学習エンジニアリング(MLOps)

概要と動機

機械学習エンジニアリングは、通常MLOpsと呼ばれ、機械学習をノートブックと実験から取り出して、信頼でき、観察可能で、保守可能な本番システムへ持ち込む規律です。従来のソフトウェアは、コードが言うとおりに振る舞います。MLシステムは、そのコード、データ、学習されたモデルのパラメータが合わせて言うとおりに振る舞います。それがMLシステムを、テストしにくく、再現しにくく、世界が訓練されたデータから離れていくにつれて静かに失敗しやすくします。MLOpsは、ソフトウェアエンジニアリングの厳密さ(バージョン管理、テスト、継続的デリバリー、監視)を、このコード、データ、モデルという三つの現実にもたらします。

大きなチームにとって、MLOpsは、デモで目を見張らせる一回限りのモデルと、多くのチームが安全に築き、デプロイし、運用できるモデルの群れを分けるものです。共有のプラットフォームと実践がなければ、すべてのチームがデータパイプライン、訓練のループ、デプロイを再発明し、六か月後に誰も再現できない脆いシステムになります。企業は、数十のモデルにわたってスケールし、サービスレベル目標を満たし、ある予測がどう生成されたかを尋ねる監査人を満足させるために、MLOpsに頼ります。

政府と規制対象の業界では、MLOpsはしばしば、変装したコンプライアンスの要件です。再現性、系統、バージョニングは、機関が法的に重大な問いに答えられるようにするものです。市民に影響した決定を、正確にどのモデルが、どのデータで、どのコードで訓練され、生成したのか。成熟したMLOpsの実践は、その問いを何年も後に答えられる状態に保ち、それは良いエンジニアリングであり、法的な安全策でもあります。

関連項目: 8.1章(CI/CDとデリバリー)、9.2章(オブザーバビリティと監視)、6.6章(AIのインフラストラクチャと運用)。

主要原則

データ、コード、モデルを、一緒にバージョン管理される成果物として扱います。どれか一つを変えると、システムの振る舞いが変わります。
データから訓練されたモデル、デプロイまでの経路を自動化し、繰り返し可能で監査可能にします。
すべてのモデルを、それを生んだ正確なデータ、コード、設定に追跡可能にします。
デプロイ前に、代表的な保持されたデータに対してモデルを評価し、その後も評価し続けます。
モデルは劣化すると想定します。初日から、ドリフト(ライブデータや入出力の関係が、モデルが訓練されたものから徐々に乖離すること)、データ品質の問題、性能の衰えを監視します。
巧妙で再現できない実験より、退屈で再現可能なパイプラインを好みます。
実験の速度と本番の信頼性という関心事を分け、意図してそれらを橋渡しします。

推奨事項

MLのライフサイクル全体を明示的に管理する

各段階を定義して計装します。データの取り込みと検証、特徴量エンジニアリング、訓練、評価、デプロイ、監視。各段階がテストされ、再試行され、監査されるよう、段階の間の境界を明示的にします。モデルがその場しのぎのノートブックで訓練され、壁越しに運用に投げられるという、よくある失敗を避けます。代わりに、ライフサイクルをオーケストレーションされたパイプラインで包み、認可されたエンジニアなら誰でもクリーンなチェックアウトから実行できるようにします。

特徴量ストア、実験追跡、モデルレジストリを使う

特徴量ストアは、同じ変換が訓練とサービングの両方で動くよう、特徴量の定義を集中させます。これは、訓練とサービングのずれ(訓練のための特徴量の計算と、ライブの予測のための計算の不整合)を排除し、チームが特徴量を再計算するのではなく再利用できるようにします。実験追跡は、すべての訓練の実行のパラメータ、コードのバージョン、データのバージョン、指標を記録し、結果が比較可能で再現可能になります。モデルレジストリは、訓練されたモデルの記録のシステムで、バージョン、系統、評価結果、承認状態、デプロイの段階を保持します。合わせて、これらにより、振る舞いが変わったとき「何が変わったか」に答え、統治された段階を通じてモデルを昇格あるいはロールバックできます。

データとモデルを、系統を伴って再現可能にバージョン管理する

コードだけでなく、データセットにバージョンを付けます。訓練の実行が不変のスナップショットを参照するよう、コンテンツアドレス可能なストレージやデータのバージョニングツールを使います。コードはgitのコミットで、環境はロックされた依存関係とコンテナイメージで固定します。系統を端から端まで捉えます。どの生データがどの特徴量を供給し、どの特徴量とコードがどのモデルを生み、そのモデルがどこにデプロイされているか。インシデントや監査が来たとき、系統は、法医学的な悪夢を単純なクエリに変えます。結果が依存する所では、ランダム性(シード)とハードウェアを記録します。

ワークロードに合うデプロイのパターンを選ぶ

バッチのスコアリングは、スケジュールに沿って大きなデータセットに対して走ります。運用が最も単純で、レイテンシに寛容で、レポートや定期的な決定に理想的です。
オンライン(リアルタイム) のサービングは、厳しいレイテンシの予算内で個々のリクエストに応答します。低レイテンシの特徴量の取得と、慎重なキャパシティ計画が必要です。
ストリーミングは、到着するイベントを継続的にスコアリングします。鮮度が決定的な不正検知や監視に合います。
エッジは、レイテンシ、プライバシー、接続性、データ主権の理由から、デバイスやオンプレミスのハードウェアでモデルを動かします。政府や現場の設定で一般的です。

要件を満たす最も単純なパターンを選び、シャドウデプロイ、カナリア、即時のロールバックでロールアウトを設計します。

ドリフト、劣化、データ品質を監視する

本番で入力と出力を計装します。データドリフト(入力の分布のずれ)、コンセプトドリフト(入力と目標の間の関係の変化)、データ品質の失敗(ヌル、スキーマの変更、壊れた上流のソース)、そして持っている所では、遅れて届く正解に対して測定される性能の劣化に注意します。アラートの閾値を設定し、ランブックを書き、監視を再訓練のトリガーに配線します。静かな劣化はMLの古典的な失敗モードで、監視はそれに対する唯一の防御です。

トレードオフ: 長所と短所

決定	選択肢A	選択肢B	トレードオフ
サービングのパターン	バッチ	オンライン	単純さとコスト対、鮮度とレイテンシ
特徴量の計算	特徴量ストア	モデルごとのパイプライン	一貫性と再利用対、セットアップのオーバーヘッド
プラットフォーム	マネージドなMLOpsプラットフォームを買う	オープンソースのツールを組み立てる	速度とサポート対、柔軟性とロックイン
再訓練	予定どおり	ドリフトで起動	予測可能性対、応答性と複雑さ
再現性の厳密さ	完全なデータのバージョニング	軽量な追跡	監査の強さ対、ストレージと労力

包括的なトレードオフは、今の投資対、後の脆さです。重い再現性と監視のインフラストラクチャは前もって労力がかかりますが、説明のつかない失敗、再現できないモデル、侵食された信頼という、はるかに大きなコストを防ぎます。マネージドなプラットフォームはチームを速くしますがロックインを生みえ、オープンソースのスタックは統合の作業を代償に制御を与えます。大きな組織は通常、舗装された道の既定の背後にこの複雑さを隠す、共有のプラットフォームチームから恩恵を受けます。

チームで議論すべき問い

デプロイされたモデルが静かに劣化したことを、顧客や市民が害される前にどうやって知り、そのアラートを誰が所有しますか。 静かな衰えはMLの古典的な失敗モードです。コードはまだ動き、モデルはまだ自信に満ちたスコアを返し、世界が訓練データから離れるにつれて品質が滑り落ちます。多くのモデルを動かす大きなチームでは、これを、フリート全体で一度ではなく、モデルごとに答える必要があります。それぞれが独自のドリフトの特性と正解の遅れを持つからです。データドリフト、コンセプトドリフト、データ品質の破綻の現在のモニター、アラートの閾値、誰が対応するかを述べるランブックを持ち込んでください。ラベルが数週間遅れて届く規制対象の設定では、その間に観察できる代理のシグナルを議論してください。遅れた正解を待つことは、害を発見するのを待つことを意味するからです。モデルのドリフトのアラートに単一の所有者が名指しされていなければ、そのモデルは事実上、監視されていません。
監査人に18か月前の特定の予測の再現を求められたら、実際に端から端までできますか。 再現性は、良いエンジニアリングの中に隠れたコンプライアンスの要件です。機関が、誰かに影響した決定を、正確にどのモデルが、どのデータで、どのコードで生成したかに答えられるようにします。本物の例を持ち込んでたどってみてください。不変のデータのスナップショット、gitのコミット、ロックされた依存関係とコンテナイメージ、記録されたシード、生データから特徴量を経てデプロイされたモデルまでの系統。シグナルは、その連鎖のどの環かが欠けているか手作業かです。政府と規制対象の業界では、法が実際に要求する保持期間を決め、ストレージがその窓全体にわたって系統を答えられる状態に保つことを確認してください。ギャップは、日常のクエリを法医学的な緊急事態に変えるからです。
モデルを本番に昇格させ、ロールバックするルールは何で、それはレジストリによって徹底されていますか。それとも信頼だけですか。 統治されない昇格は、ノートブックの実験が本番に漏れ、誰もきれいに元に戻せないために悪いモデルが居座る原因です。多くのチームにとって、成熟と脆さの違いは、モデルレジストリが必須の承認と評価で昇格をゲートするか、エンジニアが手で重みを押し込めるかです。現在の昇格の経路、ロールバックの仕組み、全トラフィックの前にシャドウデプロイやカナリアが実際に走る証拠を持ち込んでください。再訓練が予定されているのかドリフトで起動するのか、再訓練されたモデルがデプロイ前に検証のゲートを通るのかを議論してください。検証なしにライブデータで再訓練することは、ドリフトや汚染を増幅するからです。答えは、人々が従うと信頼されるwikiのページではなく、プラットフォームで徹底されるべきです。
MLOpsプラットフォームをオープンソースのツールで築くか、マネージドなものを買うか、両者を混ぜるか。そしてロックインを量ったのは誰ですか。 この選択は、将来のすべてのモデルがどれだけ速く出荷されるか、データとパイプラインへの制御をどれだけ保つかの天井を決めます。マネージドなプラットフォームはチームを素早く本番に届けてサポートを担いますが、特徴量の定義、系統の記録、モデルの成果物を、簡単には離れられない独自の形式に閉じ込めえます。組み立てられたオープンソースのスタックは、本物の統合と保守の労力を代償に可搬性を保ちます。各道のTCO(ライセンスあるいは構築、ストレージ、再訓練の計算、運用するプラットフォームの人員)、インフラを動かすチームの能力についての誠実な見立て、具体的な出口のテストを持ち込んでください。レジストリ、特徴量ストア、系統をエクスポートして、別の場所で再構築できるか。企業と政府の設定では、調達の制約とデータ主権のルールを加えてください。規制当局が禁じるリージョンや形式で訓練データを保存するプラットフォームは、どれほど便利でも失格だからです。
特徴量ストアとモデルレジストリは、一つの集中したプラットフォームか、チームごとの連合か。そして訓練とサービングのずれは、今日いくらかかっていますか。特徴量の定義を集中させることは、訓練では一つの方法で、サービングでは別の方法で計算される特徴量のずれを排除します。それは精度を失う静かで高価な源ですが、単一のプラットフォームはすべてのチームを遅くするボトルネックになりえます。連合は、チームに自律を与える一方で、配管と、二つのチームが同じ特徴量を一貫せず定義する可能性を増やします。ずれがすでにあなたを噛んだ所の証拠、特徴量を再利用するチームと再構築するチームの数、共有のプラットフォームチームが提供できる舗装された道の既定を持ち込んでください。大きな組織では、一つの監査可能な記録のシステムのガバナンス上の利益と、中央の待ち行列のデリバリーのコストを量り、規制対象の設定では、監査人が任意の予測を、それを生んだ正確な特徴量コードまで追跡できる、集中した系統を好んでください。
各モデルのデプロイのパターンを、本当のレイテンシ、鮮度、主権のニーズに合わせましたか。それとも、すべてを一つの形に既定にしましたか。 バッチ、オンライン、ストリーミング、エッジは、運用のコストと複雑さが大きく異なり、間違ったものを選ぶと、夜間のレポートが決して必要としなかったリアルタイムのインフラに使いすぎるか、不正スコアラーが頼る鮮度に飢えさせるかのどちらかです。ワークロードごとに、要件が実際に正当化するパターンを決め、現代的に感じるからという理由で、最も複雑な選択肢に標準化するのに抵抗してください。各モデルのレイテンシの予算、量、古い答えのコスト、正解の遅れを持ち込んでください。政府と現場の設定では、エッジとオンプレミスのデプロイを意図して量ってください。データ主権のルールや断続的な接続が、モデルをローカルのハードウェアに強いることがあり、その選択が、そこに押し出すすべてのモデルをどうバージョン管理し、監視し、ロールバックするかを作り変えるからです。

セクター別の視点

スタートアップ。 最も乏しい資源はエンジニアリングの注意なので、MLOpsを軽量に保ち、買ってください。シンプルなホスト型のツールで実験を追跡し、デプロイされた各モデルを、gitの訓練データのスナップショットとコードのコミットに固定し、プラットフォームではなく安価なドリフトのチェックを一つ加えます。二、三個目のモデルが再利用を価値あるものにするまで、特徴量ストアとオーダーメイドのパイプラインは飛ばします。保守できない脆いスタックは、欠けている能力よりも速くあなたを沈めるからです。

小規模事業者。 おそらくMLプラットフォームの専門家はおらず予算も厳しいので、MLOpsを、人員を置くシステムではなく、すでに動かしているツールに埋め込まれたものとして扱ってください。バージョニング、デプロイ、監視を代わりに扱ってくれるマネージドなサービスを好み、規律をデータの衛生と再現性の問題として枠づけます。どのモデルとデータが特定の結果を生んだかを知り、ロールバックする能力を保つ。後の切り替えが可能であり続けるよう、データとモデルをエクスポートできるベンダーを好んでください。

大企業。 問題は、数十のモデルと多くのチームにわたる規模です。グループがパイプラインを再発明するのをやめるよう、共有の特徴量ストア、実験追跡、統治された昇格を備えたモデルレジストリ。舗装された道の既定を提供するプラットフォームチームに予算を付け、すべてのモデルが監査可能で、すべてのインシデントが説明可能になるよう、系統と監視を標準化し、基盤のツールが入れ替え可能に保たれるインターフェースの背後で、作るか買うかとロックインを意図して管理します。検証のゲートとロールバックを、慣習ではなくプラットフォームで徹底します。

政府。 再現性、系統、バージョニングは、変装したコンプライアンスの要件なので、初日から第一級として扱ってください。デプロイされたすべてのモデルの背後にある正確なデータセットとコードにバージョンを付け、その系統を法的に求められる期間保持し、市民に影響した過去の任意の予測を再現できるようにします。重大な決定には人間によるレビューを保ち、データ主権のルールが求める所ではエッジとオンプレミスのデプロイを量り、どのベンダーのプラットフォームにも、データ、特徴量、系統の完全な可搬性を認めるよう求めてください。

事例

スタートアップ。 小さな分析のスタートアップは、一人のデータサイエンティストと軽量なセットアップで、最初の解約予測モデルを出荷しました。シンプルなホスト型のツールで実験を追跡し、デプロイされた各モデルをgitの訓練データのスナップショットとコードのコミットに固定し、最近の入力を訓練時の分布と比較する基本的な週次のジョブを加えました。データソースが日付の形式を変え、予測がずれ始めたとき、その単純なチェックは、怒った顧客からの電話の後ではなく、数日で捉え、チームは最後の良いモデルを再現してロールバックできました。

大企業。 小売銀行は数十の与信と不正のモデルを運用しています。チームにわたって共有される特徴量ストア、実験追跡サービス、必須の承認ゲートを備えたモデルレジストリに標準化しました。本番のすべてのモデルは、訓練データのスナップショットとコードのコミットにさかのぼれます。不正のモデルはストリーミングのスコアラーとしてデプロイされ、与信のモデルはバッチで動きます。監視の層が入力のドリフトを観察し、データソースのスキーマが変わったときにアラートを出し、それはかつて、壊れた上流のフィードが決定を壊す前に捉えました。

政府。 公的な給付機関は、MLモデルを使って案件のレビューに優先順位をつけています。それらの決定が市民のサービスへのアクセスに影響するので、機関はデプロイされたすべてのモデルの背後にある正確なデータセットとコードにバージョンを付け、この系統を法的に求められる期間保持し、過去の任意の予測を求めに応じて再現できます。モデルはバッチでデプロイされ、旗が立ったケースを人間がレビューし、ドリフトのモニターは、入ってくる母集団がずれるたびに必須の再評価を強いるので、モデルが検証された条件の外で静かに適用されることは決してありません。

ビジネスケース: 動機、ROI、TCO

MLOpsは、脆い実験を頼れる資産に変えることで元を取ります。ROIは、新しいモデルの本番までの時間の短縮、高価なインシデントの減少、重複したインフラストラクチャの減少、少人数のプラットフォームチームで多くのモデルを運用できることから来ます。共有の特徴量ストアとレジストリは、チームが同じ配管を再構築するのをやめるので、モデルあたりのデリバリー時間を劇的に削れます。

TCOは、プラットフォームの構築あるいはライセンス、バージョン管理されたデータとモデルのストレージ、再訓練の計算、そのすべてを運用する人員をカバーします。採用しないコストと量ってください。再現も監査もできないモデル、顧客や市民を害する静かな失敗、規制上の指摘。規制対象の設定では、監査での説明のつかないモデルのコストは、MLOpsへの投資全体をはるかに上回りえます。リーダーシップに論拠を示すには、MLOpsを間接費ではなく、リスクの低減とデリバリーの加速として枠づけます。将来のすべてのモデルが通る、舗装された道として。

アンチパターンと落とし穴

ノートブックから本番への飛躍。 統治されないノートブックで訓練され、再現性のないモデルをデプロイすること。
訓練とサービングのずれ。 訓練とサービングで異なる特徴量のコードがあり、静かに精度を失うこと。
データのバージョニングがない。 コードにはバージョンを付けるがデータには付けず、実行が再現できないこと。
デプロイして忘れる。 監視なしにモデルを出荷し、ユーザーが不満を言ったときにだけ劣化を発見すること。
自動操縦の再訓練。 検証なしにライブデータで自動的に再訓練し、ドリフトや汚染を増幅すること。
一回限りのインフラストラクチャ。 すべてのチームが独自のパイプラインを築き、コストと脆さを増やすこと。
遅れたラベルの無視。 正解が数週間後に届くのに、精度を即座に測れると想定すること。

成熟度モデル

開始。 ノートブックでその場しのぎに作られたモデル。手作業のデプロイ。データもモデルもバージョン管理されず、監視なし。過去の予測の再現は当て推量です。
発展。 一部の実験追跡とモデルレジストリが現れますが、実践はチームごとに異なります。デプロイは半自動化され、基本的な監視が少数のモデルをカバーし、データのバージョニングは部分的で系統にはギャップがあります。
標準化。 特徴量ストア、レジストリ、再現可能なパイプライン、端から端までの系統を備えた共有のプラットフォームが、文書化され組織全体で徹底されます。ドリフトとデータ品質の監視がモデルにわたって走り、昇格とロールバックは、すべてのチームが使う統治された経路に従います。
管理。 フリートがベースラインに対して測定されます。ドリフト率、データ品質の破綻、遅れた正解に対するモデルの精度、訓練とサービングのずれ、本番までの時間、モデルごとの運用コストが指標として追跡され、アラートの閾値と検証のゲートが証拠に基づいて徹底され、各モデルの健全性が名前のある所有者とともに決まった周期でレビューされます。
オーケストレーション。 ライフサイクルは完全に自動化され、監査可能で、適応的です。ドリフトで起動する再訓練が検証のゲートの背後で走り、セルフサービスの舗装された道がチームを安全に出荷させ、継続的な評価がモデルの性能をビジネスの指標に結びつけ、プラットフォームがデリバリー、リスク、コンプライアンスと統合されるので、データと条件が変わるにつれて、モデルは日常的に退役し、置き換えられ、再スコープされます。

議論のためのアイデア

実験の自由と本番の再現性を、どうバランスさせますか。
あなたのユースケースにとって、正しい再訓練のトリガー(予定、ドリフト、性能の衰え)は何ですか。
データとモデルの系統をどれだけ保持しなければならず、何がその要件を駆動しますか。
特徴量ストアとレジストリは、集中したプラットフォームか、チームごとの連合であるべきですか。
正解のラベルが長い遅れで届くとき、精度をどう監視しますか。
エッジのデプロイが、追加の運用の複雑さに見合うのはいつですか。

要点

MLの振る舞いはコード、データ、モデルから来ます。三つを一緒にバージョン管理し統治します。
特徴量ストア、実験追跡、レジストリは、再現可能なMLの背骨です。
系統はモデルを監査可能にし、インシデントを説明可能にします。規制対象の設定で不可欠です。
レイテンシ、鮮度、主権のニーズに合わせて、バッチ、オンライン、ストリーミング、エッジを選びます。
モデルは劣化します。ドリフト、データ品質、衰えの監視は任意ではありません。

参考文献とさらなる読み物

Chip Huyen, Designing Machine Learning Systems.
Andriy Burkov, Machine Learning Engineering.
D. Sculley et al., Hidden Technical Debt in Machine Learning Systems.
Mark Treveil et al., Introducing MLOps.
Valliappa Lakshmanan, Sara Robinson, and Michael Munn, Machine Learning Design Patterns.
Emmanuel Ameisen, Building Machine Learning Powered Applications.