# MLメタデータ管理 ## 定義 MLメタデータ管理とは、特徴量・ラベル・訓練済みモデル・パイプライン実行といったMLシステムの各サブシステムが「何を行ったか」を追跡するための仕組みである。『信頼性の高い機械学習』第4章は、特徴量システムとラベリングシステムのいずれもがメタデータの効率的な追跡から恩恵を受けるとし、最低限、特徴量の定義と各モデルで使われているバージョンを追跡する必要があるとする。メタデータシステムはモデルの訓練やモデル提供のライブパス(推論のリクエスト経路)に決して入るべきではないが、機能していなければ特徴量エンジニアリングやラベル付けの運用に支障が出るため軽視できない。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] §4.4.1) ### 単一システム 対 複数システム連携 メタデータシステムの構築方針には2つの選択肢があり、トレードオフを伴う。 - **単一システム**: 全てのソースからのメタデータを1つのシステムで追跡する。サブシステム間の関連付けが容易になり分析・レポートが簡素化される一方、データスキーマの観点から正しく設計するのが難しく(列の追加と既存データへの埋め戻しが継続的に発生する)、システム全体を安定させ信頼できるものにするのも難しい。 - **複数システムの連携**: 特徴量・ラベル用、訓練用、運用用、品質監視用のように、タスクごとに別々のメタデータシステムを構築する。各システムを独立に開発でき、1つが停止しても他への影響が限定的という利点がある一方、システムをまたぐ分析・レポーティングには一意な識別子の共有か、メタデータシステム全体の関係を追跡する「メタデータのメタデータシステム」の確立が必要になる。 ニーズがシンプルでよく理解されている場合は単一システムが推奨され、領域が急速に発展し追跡対象が拡張し続けることが予想される場合は複数システムの方が時間の経過とともに開発を簡素化できる。(Source: 同 §4.4.1) ### 追跡すべきメタデータの4類型 第4章は、追跡すべきメタデータを4つのまとまりに分けて具体的な要素を挙げる。 - **データセットのメタデータ**: 出所(どのシステム・外部プロバイダから来たか)、場所(保存先への参照)、責任者またはチーム、作成日またはバージョン、使用制限(ライセンス・ガバナンス上の制約)。 - **特徴量のメタデータ**: 特徴量バージョン定義(コードや記述への参照。バージョン更新のたびに更新)、責任者またはチーム、作成日または現在バージョンの日付、使用制限(司法管轄区域や規制業種によっては特定の特徴量やバケッティング粒度の使用が禁止・制限されることがある。例: 年齢そのものは保険目的で使用禁止だが、規制が許すバケッティングを適用した変換特徴量「保険における年齢区分」は使用を許可する、という制御が現実的な回避策になる)。 - **ラベルのメタデータ**: ラベル定義バージョン(どのラベリング指示で作られたか)、ラベルセットバージョン(誤りの修正や追加によるラベル集合自体の変化を追跡し、古いモデルとの厳密な比較に古いバージョンのラベルを使えるようにする)、ラベルの出所(ライセンスされたソースか、どの人間/アルゴリズムが作成したか)、ラベルの信頼度(自動生成や新人作成者によるラベルは信頼度が低くなりうる。訓練に使うラベルの閾値選定に使われる)。 - **パイプラインのメタデータ**: 中間成果物・どのパイプライン実行から来たか・どのバイナリが生成したかについてのデータ。TensorFlow Extended(TFX)に含まれるML Metadata(MLMD)のように、一部のML訓練システムでは自動的に生成される。 (Source: 同 §4.4.2〜§4.4.5) ### モデルストア:モデルに関するメタデータ追跡の実運用形態 [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]] §10.4.2は、モデルをストレージ(S3等)に保存するだけでは不十分だとし、デバッグ・メンテナンスのために記録すべき8種のアーティファクトを挙げる: (1) モデルの定義(損失関数・隠れ層の数など、この形式のモデルの生成に必要な情報)、(2) モデルのパラメーター(実際に設定された値。定義と組み合わせて予測モデルを再作成できる)、(3) 特徴抽出関数と予測関数(通常エンドポイントにラップされる)、(4) 依存関係(Pythonバージョン・パッケージ等。通常コンテナにパッケージ化)、(5) データ(訓練データの格納場所・バージョン・DVCコミット等へのポインター)、(6) モデル生成に関するコード(フレームワーク・訓練方法・データ分割方法・実験回数・ハイパーパラメーター範囲等)、(7) 実験のアーティファクト(損失曲線・テストパフォーマンスの数値等)、(8) タグ(所有者チーム・解決するビジネス課題)。これらが同一の場所ではなくS3・ECS・Snowflake・Weights & Biases・AWS Lambdaのように点在しがちであることが、担当データサイエンティストが不在(退職・休暇等)の場合のデバッグを困難にする根本原因だとされる。本書執筆時点でMLflowはこの種のモデルストアとして最も有名だが、アーティファクトの記録・アクセスに関する問題は未解決だと評される。(Source: 同 §10.4.2) ## 横断的知見 - **10章のモデルストア8アーティファクトは、4章の「追跡すべきメタデータの4類型」(データセット/特徴量/ラベル/パイプライン)が明示的に立てていない「モデル」というメタデータ対象を補完する**: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] §4.4.2〜§4.4.5の4類型は、モデルそのもの(モデルの定義・パラメーター・生成コード・実験アーティファクト)を独立した追跡対象として列挙しておらず、パイプラインのメタデータ(中間成果物・どの実行から来たか)がその一部を間接的にカバーするにとどまる。これに対し10章のモデルストアは、まさにこの「モデル自体のメタデータ」を主題とし、8種のアーティファクトとして具体化する。両者を重ね合わせると、MLメタデータ管理が扱うべき対象は「データセット」「特徴量」「ラベル」「パイプライン」「モデル」の5類型に拡張できる可能性があり、4章の枠組みは10章のモデルストアで補完して初めて完結すると言える。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] §4.4.2〜§4.4.5, [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]] §10.4.2) - **モデルストアが訓練システムの一部として「モデルの定義」「モデルのパラメーター」を明示的に区別している点は、[[モデルアーキテクチャ・定義・訓練済みモデル]] concept が集約する3層区別(アーキテクチャ/定義/訓練済みモデル)のインフラレベルの実装に相当する**: 10章§10.4.2の「モデルの定義」(損失関数・隠れ層数などモデル生成に必要な情報)は[[モデルアーキテクチャ・定義・訓練済みモデル]]の「モデルの定義(構成されたモデル)」概念とほぼ同義であり、「モデルのパラメーター」(実際に設定された値)は同conceptの「訓練済みモデル」の構成要素(重み等のパラメータ値の集合)に対応する。3層区別が『信頼性の高い機械学習』3章では概念レベルの整理にとどまっていたのに対し、10章のモデルストアはこれを実際に記録・追跡すべきアーティファクトの単位として運用レベルに落とし込んでおり、MLメタデータ管理と3層区別が同じ問題(モデルの何を、どの粒度で、どう追跡するか)への異なる抽象度からのアプローチであることを示す。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]] §10.4.2) - **『信頼性の高い機械学習』第4章が扱う「特徴量・ラベル・パイプラインが何を行ったかを追跡するメタデータシステム」と、『機械学習システムデザイン』6章が扱う「実験の詳細と成果物を追跡する実験管理・バージョン管理」は、どちらも「MLシステムの過去の状態を追跡し再現可能にする」という同じ目的を、対象(データ資産のメタデータ 対 訓練実験そのもの)を変えて達成しようとする隣接領域である**: 4章§4.4.1はメタデータシステムがモデルの訓練・提供のライブパスに決して入るべきではないと述べ、特徴量定義・ラベル定義・パイプライン実行という静的な資産の系譜を追跡対象とする。これに対し6章§6.1.3は、損失曲線・評価指標・ハイパーパラメーターの経時変化・モデルの中間結果(アーティファクト)という、1回の訓練実行(実験)そのものの動的な進捗を追跡対象とし、MLflowやWeights & Biasesのようなツールが実験管理からバージョン管理へ、DVCのようなツールがバージョン管理から実験管理へと機能を広げてきたと述べる。4章の「特徴量バージョン定義」や「ラベルセットバージョン」は、6章が実験ごとに記録すべきとする「使用した特徴量のフルセット」と重なる部分があり、両者は同じ根本問題(「何が」「いつ」「どう変わったか」を追跡する)に異なる粒度(データ資産全体のカタログ 対 個々の実験のスナップショット)からアプローチしていると整理できる。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] §4.4.1, [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 6 モデル開発とオフライン評価]] §6.1.3, §6.1.3.1) - **6章が具体的に列挙するデータバージョン管理の困難さ(diffの定義・大規模ファイルの複製コスト・コンフリクトのマージ不能性・GDPRによる復元不能性)は、4章が抽象的に述べる「メタデータシステムを正しく設計するのは難しい」という主張の具体的な内訳を提供する**: 4章はメタデータシステムを単一システムで構築するか複数システムを連携させるかというトレードオフを論じるが、「難しさ」の中身自体には深入りしない。6章§6.1.3.2は、ソースコードの行単位diffがデータには意味を成さないこと、開発者1と開発者2が異なるデータバージョンで訓練したモデルをマージしても意味がないこと、GDPRのようなユーザーデータ削除義務が過去バージョンへの復元を法的に不可能にすることという3つの具体的な困難を挙げており、これらは4章が触れる「特徴量の使用制限(司法管轄区域の規制)」という論点とも部分的に重なる(GDPR的な制約がデータバージョン管理とメタデータの使用制限の両方に影響する共通の外部要因である)。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] §4.4.3, [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 6 モデル開発とオフライン評価]] §6.1.3.2) ## 未解決の問い - 「メタデータのメタデータシステム」(複数システム構成で分析を横断するための識別子共有基盤)は本章では概念の存在のみが示され、具体的な設計パターンには立ち入らない。この設計は他ソースでの補完が必要。 - MLflow・Weights & Biases・DVCのような実験管理/バージョン管理ツール(6章)は、4章が挙げる特徴量メタデータ・ラベルメタデータ・パイプラインメタデータをどこまでカバーしているか。両者が別々のツール群として運用されている場合、実験の再現に必要な情報が実験管理システムとメタデータシステムに分散し、突き合わせが必要になるのではないか。両ソースともこの統合問題には触れていない。 - 特徴量の使用制限(司法管轄区域による規制)を、変換特徴量の粒度制御で回避するアプローチ(§4.4.3の年齢バケッティング例)は、本章自身が「本稿執筆時点では優れた設計や解決策は存在しない」と留保している。この分野の進展を追う別ソースはあるか。 - パイプラインのメタデータ(MLMD/TFX)は本章では簡単に触れられるのみで詳細は扱われない。継続的トレーニングや訓練システムを扱う章(7章・10章)でこの領域がどう扱われるか。10章のモデルストア(§10.4.2)はモデル単位のメタデータを扱うがパイプライン実行そのものの中間成果物追跡には踏み込まないため、この問いは依然として未解決。 - 10章のモデルストア8アーティファクトと4章の4類型を合わせた「5類型」仮説(データセット/特徴量/ラベル/パイプライン/モデル)は、実際の商用・OSSツール(MLflow・TFX MLMD等)でどこまで1つのシステムに統合されているか、それとも10章§10.4.1の「単一システム対複数システム連携」のトレードオフどおり別々のツールに分散しているか。 ## 関連 - ソース: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] / [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 6 モデル開発とオフライン評価]](実験管理とバージョン管理という隣接領域) / [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]](モデルストアの8アーティファクト) - 概念: [[特徴量ストア]] / [[教師データのためのログ設計]] / [[モデルアーキテクチャ・定義・訓練済みモデル]](訓練済みモデルの再現性という隣接論点、モデルストアのアーティファクト区分と対応) / [[機械学習基盤]] - 実体: [[TensorFlow]] / [[MLflow]] / [[Stitch Fix]](独自モデルストアの構築事例) ## 出典 - Cathy Chen ほか, 『信頼性の高い機械学習 ―SRE 原則を活用した MLOps』, オライリー・ジャパン, 2024, 4 章 §4.4. - Chip Huyen 著, 江川崇・平山順一 訳, 『機械学習システムデザイン』, オライリー・ジャパン, 2023, 6章, §6.1.3, §6.1.3.1, §6.1.3.2. - [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]](§10.4.2 モデルストアが記録する8アーティファクト)