継続的トレーニング - yuuk1's Digital Garden

# 継続的トレーニング Navigation: [[index]] | [[concepts/_index]] ## 定義継続的トレーニング(Continuous Training, CT)とは、学習済みモデルを使い続けることが「入力データの分布は学習時と予測時とで大きく変わらない」「入力データの使える特徴量も学習時と予測時とで一致し十分にある」という暗黙の仮定に依存しており、長期的に運用する機械学習システムではこの仮定が満たされなくなることが珍しくないため、定期的に新しいデータを用いて予測モデルを自動的に再学習し提供する取り組みを指す。ブラックフライデーのような新しい商習慣の登場やCOVID-19による行動様式の変化のように、モデル学習時に存在しなかったパターンが後から生じることが、継続的トレーニングを必要とする典型的な理由として挙げられる。(Source: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 6 継続的トレーニングをするための機械学習基盤]] §6.1.3) 継続的トレーニングは、DevOpsが担う継続的インテグレーション(CI)・継続的デリバリー(CD)に、モデルの継続的トレーニング(CT)を加えたML Opsの3本目の柱として位置づけられる。CTの実現には、分散学習用GPUクラスターのような計算基盤だけでは不十分で、データサイエンティストが本番環境へ容易にモデルをデプロイできる仕組みを用意し、実験サイクルと本番リリースサイクルを近づける[[機械学習基盤]]が必要になる。(Source: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 6 継続的トレーニングをするための機械学習基盤]] §6.2) 継続的トレーニングを行うシステム(継続的なMLシステム)の内部構造は、固定の不変データセットではなく絶えず流れ込む訓練事例のストリームと、購入行動のように正解判明までの遅延を伴う訓練用ラベルの別ストリームという2つの流れの管理から始まる。これに、モデルが学習すべきでない行動(スパム発注・攻撃的な入力等)を取り除く悪いデータの除去、生データを効率的に保存・共有する特徴量ストア、SGDのような漸進的学習手法によるモデル更新、そして検証を経てチェックポイントを運用へプッシュする一連の工程が続く。チェックポイントの本番プッシュは、頻度の高い小さな自動化ローンチとみなせる(1時間に4回プッシュすれば1日約100回のローンチに相当)。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 10 継続的なML]] §10.1) `継続的トレーニング(Continuous Training)`と訳される概念は、『機械学習システムデザイン』9章では`継続学習(continual learning)`という訳語で扱われる。同書は継続学習を「実運用にサンプルが入力されるたびにモデルを自動更新するパラダイム」という誤解と切り分け、実際には512個・1,024個単位のマイクロバッチでモデルを更新できるインフラを構築し、必要に応じていつでも(ゼロからでもファインチューニングでも)迅速に更新・デプロイできるようにする取り組みだと定義する。ここで強調されるのは、継続学習が**再訓練の頻度の問題ではなく再訓練の作法(モデルを毎回ゼロから訓練するステートレス再学習か、前回のチェックポイントから訓練を続けるステートフル学習か)の問題である**という点である。ステートレス再学習とステートフル学習の双方を実現するインフラを一度構築すれば、訓練頻度の調節は設定を変えるだけで済むようになる。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 9 実現場での継続学習とテスト]] §9.1, §9.1.1) ## 横断的知見 - **12章(オンライン広告)は、6章が一般論として述べる「分布シフトによる劣化」を、広告配信という具体ドメインの因果的な理由づけ(未知の広告枠・新たな広告主が絶えず登場する)で裏づけ、6章自身のダッシュボード例(図6-4)の出所も明らかにする**: 6章§6.1.3は継続的トレーニングが必要な理由を、ブラックフライデーやCOVID-19のような「学習時に存在しなかったパターンが後から生じる」という一般的な事例で説明する。12章§12.5.2はこれを広告配信ドメインに固有の理由——未知の広告枠・新たな広告主が次々と登場し続けるため訓練データの性質が変化し続ける——として言い換え、対策を6章に委譲する形で明示的に接続する。さらに12章は、6章§6.4のコラム「広告配信サービスにおけるメトリクス監視の例」(2時間ごとに配信ログを追加して再学習する運用、図6-4のダッシュボード)が、12章の著者(西林孝)自身が広告配信システムで運用している実例であることを明かしており、6章の一般化された4ステップの機械学習基盤論と、12章の広告配信という具体ドメインが、同一著者の同一システムを介して直接つながっていることがわかる。この接続は書籍の構成そのもの(6章の抽象論を12章の具体例が締めくくる)を裏づける稀有な例である。(Source: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 6 継続的トレーニングをするための機械学習基盤]] §6.1.3, §6.4, [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 12 オンライン広告における機械学習]] §12.5.2) - **『信頼性の高い機械学習』は同一書籍内の第7章と第10章で、「全てのモデルは再訓練される」という同じ前提を異なる強度で提示する**: 7章§7.3.2はこの前提を訓練システム設計の11原則の1つ(「モデルは再訓練される」)として述べ、対応策として設定・スナップショット・データ/メタデータのバージョン管理という一般的な設計指針にとどめる。これに対し10章§10.4は同じ前提を章全体の結論に格上げし、「全ての運用MLシステムは継続的なMLシステムとして扱うべきである」という明示的な推薦にまで踏み込む。7章では訓練システム設計上の一原則だったものが、10章では標準・ベストプラクティスの全面適用という運用方針そのものに発展している。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 7 MLモデル訓練システム]] §7.3.2, [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 10 継続的なML]] §10.4) - **『仕事ではじめる機械学習』6章と『信頼性の高い機械学習』10章は、著者も出版時期も異なるのに「継続的な再学習を前提にシステムを設計すべきである」という同じ結論に別々の論法で到達する**: 6章はCI/CDにCT(継続的トレーニング)を加えたMLOpsの3本柱という一般的な設計フレームワークとして継続的トレーニングの必要性を提示するのに対し、10章はフィードバックループ・外界の出来事による分布シフト・危機対応という信頼性工学の観点から議論を積み上げ、§10.4で「全ての運用MLシステムは継続的なMLシステムとして扱うべきである」という推薦に到達する。異なる書籍・異なる出発点の議論が同じ実務上の結論へ収束している。(Source: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 6 継続的トレーニングをするための機械学習基盤]] §6.2, [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 10 継続的なML]] §10.4) - **9章のドリフト分類・監視戦略と10章の危機対応ステップは、診断と対応という補完関係にある**: 9章§9.3.4.2は特徴量ドリフト/データドリフト・モデルドリフト/予測ドリフト・コンセプトドリフトという3分類と、PSI・KLダイバージェンス・ワッサースタイン距離による定量化手法を提供する。10章§10.2.1は外界の出来事による分布シフトを傾向スコアリング・逆傾向重み付けで完全に解消するのは理論上可能でも実際には非常に困難であるとし、「管理する対象として扱う」姿勢を取ったうえで、§10.2.4で訓練停止・フォールバック・ロールバック・不良データ削除・ロールスルーという5つの即時対応を提示する。9章が異常の検知・定量化(診断)を担い、10章がその後の意思決定と実行(対応)を担うという役割分担が読み取れる。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 9 モデルの監視と可観測性]] §9.3.4.2, [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 10 継続的なML]] §10.2.1, §10.2.4) - **15章§15.2のGoogle連続的MLモデル障害は、10章§10.2.4が抽象的に提示する5つの即時対応(訓練停止・フォールバック・ロールバック・不良データ削除・ロールスルー)のうち「訓練停止」と「ロールスルー」を、実際の障害対応として裏づける一次記録である**: 10章§10.2.4はこの5つの対応を一般論として列挙するにとどまるが、[[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 15 ケーススタディ：MLOpsの実践]] §15.2は、Google の連続的なクリック予測モデルが重複クエリによるフィードバックループで汚染された際、運用担当者がまず訓練を停止し(「穴の中にいると気づいたら掘るのをやめる」という10章の比喩そのままの判断)、その後試みたロールバックや再更新はいずれもさらなる重複クエリを生んで症状を悪化させ、最終的には緩和策を重ねることをやめてシステムが新しい世界の状態に自然に追いつくのを待つ(ロールスルー)という判断が最も効果的だったと結論づける。これは10章が列挙する5対応が「等価な選択肢」ではなく、フィードバックループが自己の緩和策自体を汚染源にしうる状況では、ロールバックのような能動的介入がむしろ不利になりうることを実例で示している。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 15 ケーススタディ：MLOpsの実践]] §15.2, [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 10 継続的なML]] §10.2.4) - **15章§15.2は、10章§10.2.2が抽象的に説明するフィードバックループの実例そのものであり、「モデルバージョンを特徴量として記録する」という10章の緩和策が実装されていなかったことが原因究明の遅れにつながったことを示唆する**: 10章§10.2.2はフィードバックループの緩和策として、モデルのバージョン情報を訓練データの特徴量として記録し、観測データの変化が現実世界の変化かモデル自身の学習状態の変化かを区別できるようにすることを提案する。15章§15.2の事例では、アプリの重複クエリが生んだクリックなしデータをモデルが学習し予測値が過小化する過程で、アプリ担当とモデル担当が互いのシステムへの可視性を持たなかったため、根本原因(アプリの再クエリ発行)の特定に長い時間を要した。10章の緩和策(モデルバージョンの特徴量化)は入力データの出所の追跡には有効だが、15章の事例が示す「アプリ側の挙動変化が下流モデルの訓練データに影響する」という、モデル自身のバージョンとは無関係な外部要因の追跡までは直接カバーしない——両者を突き合わせると、10章の緩和策だけでは15章のような組織横断的なフィードバックループの原因特定を完全には防げないことが見える。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 15 ケーススタディ：MLOpsの実践]] §15.2, [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 10 継続的なML]] §10.2.2) - **15章§15.5のGoogle広告クリック予測モデルは、継続的トレーニングを回すシステムにおいて「ラベルが現実そのものではなく記録系の産物である」ことが再訓練の安全性検証をも欺きうることを示す**: 10章・9章はいずれも継続的な再訓練とその監視・危機対応を論じるが、ラベル自体の信頼性が訓練データ全体にわたって体系的に損なわれるケースは明示的に扱っていない。15章§15.5は、クリックログ処理インフラの障害により数日分の広告表示が誤って「クリックされなかった」と記録され、この汚染されたデータでの再訓練後の検証システムまでもが(汚染されたテストセットを参照したため)誤った合格判定を下したことを報告する。継続的トレーニングの自動化された検証パイプライン(古いモデルより新しいモデルが優れているかのテスト)は、ラベル生成プロセス自体が一時的に壊れている場合には機能しないことを、この事例は具体的に示す。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 15 ケーススタディ：MLOpsの実践]] §15.5, [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 10 継続的なML]] §10.1) - **『機械学習システムデザイン』9章の継続学習4段階ステージは、『信頼性の高い機械学習』10章が結論として掲げる「全ての運用MLシステムは継続的なMLシステムとして扱うべきである」という到達点への、具体的な移行経路を与える**: 10章§10.4は既出のとおりこの推薦を章の結論として提示するが、そこへ至る具体的な組織的・技術的な移行手順までは詳述しない。9章§9.1.4は、(1) 手作業・ステートレス再学習、(2) 再訓練の自動化(スケジューラー・データ可用性・モデルストアが要件)、(3) 自動化・ステートフル学習(データとモデルのリネージ追跡が要件)、(4) 時間・パフォーマンス・ボリューム・ドリフトの各トリガーに基づく継続学習、という4段階を要件つきで示す。10章が「あるべき姿」を宣言するのに対し、9章は「そこへどう辿り着くか」という段階的な現実解を与えており、両者を合わせて初めて目標と経路が揃う。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 9 実現場での継続学習とテスト]] §9.1.4, [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 10 継続的なML]] §10.4) - **9章が「継続学習は再訓練の頻度ではなく作法の問題である」と理論的に切り分ける一方、6章・12章の実例は頻度そのものを具体的な運用パラメータとして提示しており、両者は抽象度の異なるレイヤーで補完し合う**: 6章§6.4.1・12章§12.5.2は「2時間ごとに配信ログを追加して再学習する」という広告配信ドメインの具体的な頻度を実例として示すが(既出)、その頻度をステートレス再学習とステートフル学習のどちらで実現しているかには触れていない。9章§9.1.1が導入する「頻度(いつ更新するか)」と「作法(どう更新するか)」という2軸の区別を適用すると、6章・12章の実例は前者(頻度)を具体化した記述であり、後者(作法)の情報を欠いていることが分かる——9章の理論枠組みがなければ、6章・12章の「2時間ごと」という数字がステートレスかステートフルかを判別する軸自体が存在しなかった。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 9 実現場での継続学習とテスト]] §9.1.1, [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 6 継続的トレーニングをするための機械学習基盤]] §6.4.1, [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 12 オンライン広告における機械学習]] §12.5.2) - **[[MLモデル監視]]が集約する「監視は受動的、継続学習は能動的な適応」という8章由来の役割分担を、9章自身の冒頭が独立に補強し、さらに実環境でのテストという第3の項を加える**: [[MLモデル監視]]は『機械学習システムデザイン』8章§8.3.3の「監視はシフトの発生を待つことしかできない受動的な取り組みであり、修正はできない」という記述から、監視(受動)対継続学習(能動)という対比を蓄積している。9章の冒頭はこれと独立に(章の導入部という位置づけで)、モデルの出力を受動的に追跡することが監視、出力を生成するモデルを能動的に選択して評価することが実環境でのテストであると述べたうえで、監視と実環境でのテストの目的が「更新すべき時を明らかにすること」、継続学習のゴールが「安全かつ効率的に更新を自動化すること」であると整理する。これにより、8章の監視/継続学習という二項対立に、9章は実環境でのテストという診断と実行の中間項を挿入しており、「検知(監視)→検証(実環境でのテスト)→実行(継続学習)」という3段階のパイプラインとして再構成できる。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 9 実現場での継続学習とテスト]] 冒頭, [[MLモデル監視]]) - **9章が挙げる継続学習の3ユースケース(突発的シフト・レアな出来事・継続的コールドスタート問題)は、[[データ分布のシフト]]が抽象的に述べる「(3) ターゲット分布のラベル付きデータでモデルを再訓練する」という対処法を、具体的な発生シナリオへ翻訳する**: [[データ分布のシフト]]は8章由来の対処法として再訓練を挙げるが、いつ・なぜ再訓練が必要になるかの具体例までは踏み込んでいない。9章§9.1.2は、Lyftの動的価格設定のような突発的な需要急増(共変量シフトの一種)、Alibabaの独身の日のような年1回のレアイベント、TikTokが数分で新規ユーザーに適応する継続的コールドスタート問題という3つの具体シナリオを与えており、[[データ分布のシフト]]の抽象的な対処法(3)に「どのようなシフトが継続学習を正当化するか」という判断材料を追加する。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 9 実現場での継続学習とテスト]] §9.1.2, [[データ分布のシフト]]) ## 未解決の問い - 15章§15.2の事例では、フィードバックループの緩和策(ロールバック・再更新)自体が症状を悪化させたが、10章§10.2.5が提案する安定したベースラインモデルC(フォールバック/訓練停止/訓練遅延/パラレルユニバースモデル)のいずれかを平時から用意していれば、この障害はより早く収束したか。15章はモデルCに相当する仕組みの有無に触れていない。 - 15章§15.5が示す「ラベル生成プロセス自体の一時的な汚染」に対し、継続的トレーニングの自動検証パイプラインはどのような整合性チェック(例: テストセットの陽性割合の異常検知)を組み込むべきか。10章・15章のいずれも具体的な検証設計までは踏み込んでいない。 - 12章が明かす「6章の図6-4ダッシュボードは広告配信システムの実例である」という事実を踏まえると、6章の4ステップの機械学習基盤論のうちどの部分が広告配信ドメイン固有の設計で、どの部分がドメインに依存しない一般的な設計なのかの切り分けは、両章を合わせても明示的には示されていない。 - 継続的トレーニングの再学習頻度(日次・時間次等)は、モデルの鮮度によるビジネス影響とスクラッチ学習のコストのどちらを優先して決めるべきか。ch.6は「計算時間を低減する取り組みが必要」と述べるのみで、頻度決定の具体的な方法論は示していない。12章は「2時間ごとに再学習」という広告配信の実例を示すが、この頻度をどう決定したかの根拠までは明示していない。 - 継続的トレーニングを回すパイプラインが生成する多数のモデルアーティファクトのうち、どれを本番へ昇格させるかの判定(精度しきい値以外の基準)はどう設計すべきか。 - ch.1が示す機械学習プロジェクトの10ステップにおける「9. システムに組み込む」は一度きりのデプロイなのか、継続的トレーニングのサイクルに組み込まれた反復的な工程として描かれているのか。両章を橋渡しする記述はch.6に明示されていない。 - 10章§10.2.1が提案する傾向スコアリング・逆傾向重み付けによる分布シフト補正(予防)と、9章§9.3.4.2のPSI・KLダイバージェンス等によるドリフト定量化(監視)は、同じ「分布の変化」を扱いながらアプローチが異なる。両者を組み合わせて運用する具体的な設計(検知した特定のドリフトの種類にどう重み付けで対応するか)は、9章・10章のいずれにも明示されていない。 - 10章§10.2.5が挙げる安定したベースラインモデルC(フォールバック/訓練停止/訓練遅延/パラレルユニバースモデルの4戦略)は、[[A-Bテスト|A/Bテスト]]の標準的な設計にフィードバックループ対策を組み込んだ拡張と位置づけられるが、この拡張が[[A-Bテスト|A/Bテスト]]や[[探索と活用のトレードオフ]]といった既存の実験設計の議論とどう接続するかは、10章の範囲では扱われていない。 - 7章§7.3.11の「機能停止には検知時間+再訓練時間の合算が必要」という復旧時間の考え方と、10章§10.2.3が示す6〜12時間に及ぶラベル遅延・パイプライン遅延は、どちらも継続的MLシステムの遅延を扱うが、両者を統合した「継続的MLシステム全体の実効的な復旧時間」をどう見積もるべきかは、いずれの章にも明示されていない。 - 9章§9.1.3.3が挙げる「行列ベース・木ベースのモデルは頻繁な部分更新に不向き」というアルゴリズム上の制約は、10章・6章・12章のいずれの実例(広告配信の2時間ごと再学習、Google連続的MLモデル等)でも具体的なモデルアーキテクチャーが明示されていないため、実際にこの制約に抵触した実例があるかどうかは未確認である。 - 9章§9.2.5.1末尾が指摘する「モデルの開発者本人が評価も担うとバイアスやばらつきが生じる」という評価体制上の課題は、[[MLモデル監視]]・本ページのいずれもまだ明示的に扱っていない組織設計の軸であり、継続学習の自動評価パイプライン(10章・9章の双方が前提とする)の「誰が承認するか」というガバナンス設計と接続する余地がある。 ## 関連 - 概念: [[機械学習基盤]] / [[MLモデル監視]] / [[技術的負債]] / [[機械学習プロジェクトの進め方]] / [[CTR予測]](12章の再学習対象モデル) / [[フィードバックループ]] / [[A-Bテスト|A/Bテスト]] / [[障害緩和]] / [[データ分布のシフト]](継続学習が対処するシフトの数学的分類) / [[シャドウデプロイ]] / [[カナリアテスト]] / [[多腕バンディット]](更新したモデルを安全に評価する実環境でのテスト手法) - ソース: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 6 継続的トレーニングをするための機械学習基盤]] / [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 12 オンライン広告における機械学習]](広告配信ドメインでの具体的な理由づけと実例) / [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 10 継続的なML]](継続的MLシステムの内部構造・6つの観察・危機対応) / [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 15 ケーススタディ：MLOpsの実践]](§15.2 Google連続的MLモデルのフィードバックループ実例、§15.5 ラベル生成プロセス汚染による検証システムの欺瞞) / [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 9 実現場での継続学習とテスト]](継続学習の4段階ステージ、頻度対作法の区別、データの鮮度の価値の測定、実環境でのテスト手法群) - 実体: [[仕事ではじめる機械学習]] / [[信頼性の高い機械学習]] / [[Google]] ## 出典 - [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 6 継続的トレーニングをするための機械学習基盤]] — 有賀康顕, 『仕事ではじめる機械学習第2版』第6章, オライリー・ジャパン, 2021, §6.1.3, §6.2. - [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 12 オンライン広告における機械学習]] — 西林孝, 同書第12章, §12.5.2. - [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 10 継続的なML]] — Cathy Chen ほか, 『信頼性の高い機械学習 ―SRE 原則を活用した MLOps』, オライリー・ジャパン, 2024, 10章, §10.1, §10.2.1, §10.2.5, §10.4. - [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 15 ケーススタディ：MLOpsの実践]] — Cathy Chen ほか, 同書, 15章, §15.2(執筆: Todd Phillips, Google), §15.5(執筆: Daniel Papasian, Google). - [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 9 実現場での継続学習とテスト]] — Chip Huyen 著, 江川崇・平山順一訳, 『機械学習システムデザイン』, オライリー・ジャパン, 2023, 9章, §9.1, §9.1.1, §9.1.2, §9.1.3.3, §9.1.4, §9.1.6, §9.2, §9.2.5.1.