MLflow完全ガイド：実験追跡からModel Registry、プロダクションデプロイまで

MLflowとは？
インストールとサーバー設定
- 基本インストール
- Docker Composeでデプロイ
最初の5分: サーバーを起動して最初の Run を残す
実験追跡（Tracking）
Run 一つが実際に残すもの
Model Registry
モデルサービング
実験の比較と分析
- MLflow UIでの比較
- Python APIでの分析
検索構文: ここでほぼ必ず一度はつまずく
プロダクションチェックリスト
失敗事例と落とし穴
MLflow を使わないほうがよいとき
参考資料
クイズ

MLflowとは？

MLflowはMLライフサイクルを管理するオープンソースプラットフォームです。4つの主要コンポーネントで構成されています：

MLflow Tracking: 実験のパラメータ、メトリクス、アーティファクトを記録
MLflow Projects: 再現可能なMLコードのパッケージング
MLflow Models: 様々なフレームワークのモデルを統一形式でパッケージング
MLflow Model Registry: モデルのバージョン管理とデプロイワークフロー

インストールとサーバー設定

基本インストール

# pipインストール
pip install mlflow

# 追加フレームワークサポート
pip install mlflow[extras]  # sklearn, tensorflow, pytorchなど

# サーバー起動（ローカル）
mlflow server --host 0.0.0.0 --port 5000

# PostgreSQL + S3バックエンドでプロダクションサーバー
mlflow server \
  --backend-store-uri postgresql://mlflow:password@localhost:5432/mlflow \
  --default-artifact-root s3://mlflow-artifacts/ \
  --host 0.0.0.0 --port 5000

Docker Composeでデプロイ

# docker-compose.yml
services:
  mlflow:
    image: ghcr.io/mlflow/mlflow:v3.15.1
    ports:
      - '5000:5000'
    environment:
      - MLFLOW_BACKEND_STORE_URI=postgresql://mlflow:password@postgres:5432/mlflow
      - MLFLOW_DEFAULT_ARTIFACT_ROOT=s3://mlflow-artifacts/
      - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
      - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
    command: >
      mlflow server
      --backend-store-uri postgresql://mlflow:password@postgres:5432/mlflow
      --default-artifact-root s3://mlflow-artifacts/
      --host 0.0.0.0 --port 5000
    depends_on:
      - postgres

  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: mlflow
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mlflow
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

最初の5分: サーバーを起動して最初の Run を残す

この記事のコードは MLflow 3.15.1 を基準に確認しました。2.x から 3.x に移る際に名前が変わった引数があるので、先にバージョンを合わせておくほうが早いです。

ターミナルで mlflow server と打つだけでサーバーは起動します。MLflow 3.7.0 から SQLite がデフォルトのバックエンドストアになり、引数を一つも渡さなければ実行したディレクトリに sqlite:///mlflow.db が自動的に作られます。--backend-store-uri を必ず付ける必要はないということです。ただし公式ドキュメントは、同時実行の多いプロダクション環境では PostgreSQL か MySQL を検討するよう案内しています。バックエンドストアがサポートする方言は sqlite、postgresql、mysql、mssql の四つです。

現在の CLI ドキュメントには mlflow server しかありません。古い記事によく出てくる mlflow ui はコマンド一覧に見当たりません。削除されたバージョンは明記されていないので断定はしませんが、手に馴染んだコマンドがあるなら mlflow server に寄せておくほうが安全です。

# 引数なし — MLflow 3.7.0 以上なら ./mlflow.db が自動生成される
mlflow server

# 保存先を明示したいとき
mlflow server \
  --backend-store-uri sqlite:///mlflow.db \
  --artifacts-destination ./mlartifacts \
  --host 127.0.0.1 --port 5000

# クライアント側（スクリプトを実行するシェル）
export MLFLOW_TRACKING_URI=http://127.0.0.1:5000
export MLFLOW_EXPERIMENT_NAME=iris-classification

ブラウザで 5000 番ポートを開くと UI が表示されます。最初は Default 実験が一つあるだけで Run 一覧は空です。スクリプトを走らせたのに一覧が空のままなら、たいていはクライアントがサーバーを見ていません。クライアントは mlflow.set_tracking_uri() の呼び出しか MLFLOW_TRACKING_URI 環境変数からサーバーアドレスを知りますが、この環境変数のデフォルト値は None です。何も設定しなければ記録はサーバーに届きません。実験名は MLFLOW_EXPERIMENT_NAME、レジストリのアドレスは MLFLOW_REGISTRY_URI で別々に指定します。

アーティファクトのパスも初日に混乱する箇所です。--serve-artifacts はデフォルトで有効です。クライアントがストレージに直接つなぐ代わりにトラッキングサーバーを経由するという意味で、だから UI に出るアーティファクト URI が mlflow-artifacts:/ で始まります。実際の保存先は --artifacts-destination で決めます。クライアントからストレージに直接アクセスさせたいなら --no-serve-artifacts を、逆にアーティファクト専用のプロキシサーバーを別に立てるなら --artifacts-only を使います。この三つを区別しておくと、学習ログは残るのにモデルファイルだけ上がらないという状況でどこを見るかがすぐ絞れます。

実験追跡（Tracking）

基本的な使い方

import mlflow
import mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris
from sklearn.model_selection import train_test_split
from sklearn.metrics import accuracy_score, f1_score, precision_score

# トラッキングサーバーの設定
mlflow.set_tracking_uri("http://localhost:5000")

# 実験の作成/設定
mlflow.set_experiment("iris-classification")

# データの準備
X, y = load_iris(return_X_y=True)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

# 実験の実行
with mlflow.start_run(run_name="rf-baseline"):
    # パラメータの記録
    params = {
        "n_estimators": 100,
        "max_depth": 5,
        "min_samples_split": 2,
        "random_state": 42
    }
    mlflow.log_params(params)

    # モデル学習
    model = RandomForestClassifier(**params)
    model.fit(X_train, y_train)

    # 予測とメトリクス
    y_pred = model.predict(X_test)
    metrics = {
        "accuracy": accuracy_score(y_test, y_pred),
        "f1_macro": f1_score(y_test, y_pred, average="macro"),
        "precision_macro": precision_score(y_test, y_pred, average="macro")
    }
    mlflow.log_metrics(metrics)

    # タグ
    mlflow.set_tag("model_type", "random_forest")
    mlflow.set_tag("dataset", "iris")

    # モデルの保存（MLflow 3 から artifact_path= ではなく name=）
    mlflow.sklearn.log_model(
        model,
        name="model",
        registered_model_name="iris-classifier"
    )

    # カスタムアーティファクト（グラフ、レポートなど）
    import matplotlib.pyplot as plt
    from sklearn.metrics import confusion_matrix, ConfusionMatrixDisplay

    cm = confusion_matrix(y_test, y_pred)
    fig, ax = plt.subplots()
    ConfusionMatrixDisplay(cm).plot(ax=ax)
    fig.savefig("confusion_matrix.png")
    mlflow.log_artifact("confusion_matrix.png")

    print(f"Run ID: {mlflow.active_run().info.run_id}")
    print(f"Metrics: {metrics}")

ハイパーパラメータチューニングの追跡

import optuna
import mlflow

def objective(trial):
    params = {
        "n_estimators": trial.suggest_int("n_estimators", 50, 500),
        "max_depth": trial.suggest_int("max_depth", 2, 20),
        "min_samples_split": trial.suggest_int("min_samples_split", 2, 10),
        "min_samples_leaf": trial.suggest_int("min_samples_leaf", 1, 5),
    }

    with mlflow.start_run(nested=True, run_name=f"trial-{trial.number}"):
        mlflow.log_params(params)

        model = RandomForestClassifier(**params, random_state=42)
        model.fit(X_train, y_train)
        y_pred = model.predict(X_test)

        accuracy = accuracy_score(y_test, y_pred)
        mlflow.log_metric("accuracy", accuracy)

        return accuracy

# Optunaスタディの実行
with mlflow.start_run(run_name="hyperparameter-tuning"):
    study = optuna.create_study(direction="maximize")
    study.optimize(objective, n_trials=50)

    # 最適結果の記録
    mlflow.log_params(study.best_params)
    mlflow.log_metric("best_accuracy", study.best_value)
    mlflow.set_tag("best_trial", study.best_trial.number)

PyTorchモデルの追跡

import torch
import torch.nn as nn
import mlflow.pytorch

class SimpleNet(nn.Module):
    def __init__(self, input_dim, hidden_dim, output_dim):
        super().__init__()
        self.fc1 = nn.Linear(input_dim, hidden_dim)
        self.relu = nn.ReLU()
        self.fc2 = nn.Linear(hidden_dim, output_dim)

    def forward(self, x):
        return self.fc2(self.relu(self.fc1(x)))

with mlflow.start_run(run_name="pytorch-model"):
    model = SimpleNet(4, 32, 3)
    optimizer = torch.optim.Adam(model.parameters(), lr=0.001)
    criterion = nn.CrossEntropyLoss()

    mlflow.log_params({
        "hidden_dim": 32,
        "learning_rate": 0.001,
        "optimizer": "Adam",
        "epochs": 100
    })

    for epoch in range(100):
        # 学習ロジック...
        loss = criterion(model(X_tensor), y_tensor)
        optimizer.zero_grad()
        loss.backward()
        optimizer.step()

        # エポックごとのメトリクス記録
        mlflow.log_metric("train_loss", loss.item(), step=epoch)

    # PyTorchモデルの保存
    mlflow.pytorch.log_model(model, "model")

Run 一つが実際に残すもの

mlflow.start_run() で開く Run は四種類の記録を持ちます。パラメータ、メトリクス、タグ、そしてアーティファクトです。パラメータは文字列として保存され、メトリクスは数値で、step を一緒に渡すと時間軸を持つ曲線になります。

start_run() が受け取る引数は run_id、experiment_id、run_name、nested、parent_run_id、tags、description、log_system_metrics です。チューニングのコードで使った nested=True は親 Run の中に子 Run を作るスイッチで、子には mlflow.parentRunId システムタグが自動的に付きます。UI でツリーに畳まれるのもこのタグのおかげです。

MLflow 3 で目立って変わったのはモデルのロギングです。まず、mlflow.sklearn.log_model() と mlflow.pyfunc.log_model() の引数が name= になりました。ドキュメントには artifact_path= は非推奨で name を使うようにと明記されており、この変更は MLflow 3.0 からです。次に、mlflow.start_run() のコンテキストなしでも log_model() を呼べます。返ってくる ModelInfo には model_id が入っており、この値から models:/ 形式の URI を作って読み直せます。三つ目に、mlflow.sklearn.log_model() の serialization_format のデフォルトが skops になりました。cloudpickle を前提にロード環境を揃えているなら確認が必要です。

import mlflow
from mlflow.models import infer_signature

signature = infer_signature(model_input=X_train, model_output=model.predict(X_train))

# MLflow 3: start_run() なしでも記録され、ModelInfo が返ってくる
info = mlflow.sklearn.log_model(
    model,
    name="model",                 # artifact_path= は非推奨
    signature=signature,
    input_example=X_train[:2],
    registered_model_name="iris-classifier",
)

print(info.model_id)
loaded = mlflow.pyfunc.load_model(f"models:/{info.model_id}")

infer_signature(model_input=None, model_output=None, params=None) は入出力スキーマを推論してモデルと一緒に保存します。シグネチャが付いていれば、サービング時に列数や型が食い違ったときに予測が静かにおかしくなる代わりに、リクエストの段階で弾かれます。

記録が溜まったら mlflow.search_runs() で取り出します。この関数は pandas DataFrame を返します。実験結果をそのまま表として受け取り、ソートしたり groupby したりできるということです。カラム名は保存層のプレフィックスをそのまま踏襲します。

run_id  status  start_time  params.n_estimators  params.max_depth  metrics.accuracy  tags.model_type

まずフィルタなしで一度呼んで .columns を出力し、そのあとに必要な列だけ選ぶ順序が楽です。正確なカラム構成は Run に何を記録したかで変わります。

Model Registry

モデルの登録とバージョン管理

from mlflow import MlflowClient

client = MlflowClient()

# モデル登録（log_modelでregistered_model_nameを使用すると自動登録）
# または手動登録：
result = client.create_registered_model(
    name="iris-classifier",
    description="Iris花分類モデル"
)

# 特定の実行のモデルをバージョンとして登録
model_version = client.create_model_version(
    name="iris-classifier",
    source=f"runs:/{run_id}/model",
    run_id=run_id,
    description="RandomForest baseline v1"
)

print(f"Model Version: {model_version.version}")

Aliasを活用したデプロイ管理

# MLflow 2.xではAliasを使用（Stageは非推奨）
client = MlflowClient()

# プロダクションaliasの設定
client.set_registered_model_alias(
    name="iris-classifier",
    alias="champion",
    version=3
)

# チャレンジャーモデルの設定
client.set_registered_model_alias(
    name="iris-classifier",
    alias="challenger",
    version=5
)

# Aliasでモデルをロード
champion_model = mlflow.pyfunc.load_model("models:/iris-classifier@champion")
challenger_model = mlflow.pyfunc.load_model("models:/iris-classifier@challenger")

# A/Bテスト
champion_pred = champion_model.predict(X_test)
challenger_pred = challenger_model.predict(X_test)

print(f"Champion accuracy: {accuracy_score(y_test, champion_pred)}")
print(f"Challenger accuracy: {accuracy_score(y_test, challenger_pred)}")

モデルタグの活用

# モデルバージョンにタグを追加
client.set_model_version_tag(
    name="iris-classifier",
    version=3,
    key="validation_status",
    value="approved"
)

client.set_model_version_tag(
    name="iris-classifier",
    version=3,
    key="approved_by",
    value="data-science-lead"
)

# タグでモデルを検索
from mlflow import search_model_versions

approved_versions = search_model_versions(
    "name='iris-classifier' AND tag.validation_status='approved'"
)

モデルサービング

MLflow内蔵サービング

# ローカルREST APIサービング
mlflow models serve \
  -m "models:/iris-classifier@champion" \
  --port 8080 \
  --env-manager local

# テストリクエスト
curl -X POST http://localhost:8080/invocations \
  -H "Content-Type: application/json" \
  -d '{"inputs": [[5.1, 3.5, 1.4, 0.2]]}'

サービングコマンドのデフォルト値

mlflow models serve はデフォルト値が思いのほか効いてきます。-p/--port は 5000、-h/--host は 127.0.0.1、-w/--workers は 1、-t/--timeout は 60 秒です。ホストのデフォルトがループバックなので、コンテナ内でそのまま起動すると外から繋がりませんし、ワーカーが一つなので負荷テストの数字が期待より低く出ます。

環境マネージャは --env-manager で選びます。有効な値は local、virtualenv、uv、conda で、デフォルトは virtualenv です。デフォルトが virtualenv ということは、サービングを起動するたびに隔離環境を作り直すという意味で、初回起動が思ったより長くかかります。依存関係がすでに揃ったイメージの中なら --env-manager local が最速で、再現性を保ちつつ速度も欲しいなら uv を試す価値があります。

/invocations エンドポイントが受け取るペイロードキーは dataframe_split、dataframe_records、instances、inputs、params の五つです。五つとも現在有効で、非推奨の印が付いたものはありません。

mlflow models serve \
  -m "models:/iris-classifier@champion" \
  --host 0.0.0.0 --port 8080 \
  --workers 4 \
  --env-manager local

FastAPIカスタムサービング

from fastapi import FastAPI
import mlflow.pyfunc
import numpy as np

app = FastAPI()

# モデルのロード（サーバー起動時に1回）
model = mlflow.pyfunc.load_model("models:/iris-classifier@champion")

@app.post("/predict")
async def predict(features: list[list[float]]):
    predictions = model.predict(np.array(features))
    return {
        "predictions": predictions.tolist(),
        "model_version": "champion"
    }

@app.get("/health")
async def health():
    return {"status": "healthy", "model": "iris-classifier@champion"}

実験の比較と分析

MLflow UIでの比較

# 実験検索（CLI）
mlflow runs list --experiment-id 1

# メトリクスベースの検索
mlflow runs list \
  --experiment-id 1 \
  --filter "metrics.accuracy > 0.95" \
  --order-by "metrics.accuracy DESC"

Python APIでの分析

import mlflow
import pandas as pd

# 実験の全実行を照会
runs = mlflow.search_runs(
    experiment_ids=["1"],
    filter_string="metrics.accuracy > 0.9",
    order_by=["metrics.accuracy DESC"],
    max_results=10
)

# DataFrameで分析
print(runs[["run_id", "params.n_estimators", "params.max_depth", "metrics.accuracy"]])

# 最適な実行を見つける
best_run = runs.iloc[0]
print(f"Best run: {best_run.run_id}, Accuracy: {best_run['metrics.accuracy']}")

検索構文: ここでほぼ必ず一度はつまずく

mlflow.search_runs() と UI の検索ボックスは同じフィルタ構文を使います。短い構文ですが、初めて使うとほぼ必ず引っかかるルールがいくつかあります。

プレフィックス	対象	例
`metrics.`	数値メトリクス	`metrics.accuracy > 0.72`
`params.`	ハイパーパラメータ（文字列で保存）	`params.n_estimators = "100"`
`tags.`	ユーザータグとシステムタグ	`tags.environment IS NOT NULL`
`datasets.`	データセット情報	`datasets.name = "iris"`
`attributes.`	Run 自体の属性	`attributes.status = "FINISHED"`

attributes. でアクセスできる項目は status、user_id、run_name、run_id、start_time、end_time です。

つまずく箇所は三つです。第一に、AND はサポートされますが OR はサポートされません。二つの条件を or でまとめたいなら、クエリを二回投げて DataFrame の段階で合わせるしかありません。第二に、パラメータはすべて文字列として保存されるので、数値に見えてもダブルクォートで囲む必要があります。第三に、LIKE は大文字小文字を区別し、ILIKE は区別しません。IS NULL と IS NOT NULL はパラメータとタグにしか使えません。

runs = mlflow.search_runs(
    experiment_ids=["1"],
    filter_string='metrics.accuracy > 0.72 AND metrics.loss <= 0.15',
    order_by=["metrics.accuracy DESC"],
)

# パラメータは文字列 — クォートがないと引っかからない
exact = mlflow.search_runs(filter_string='params.n_estimators = "100"')

# OR がないので二回照会して連結する
import pandas as pd

merged = pd.concat([
    mlflow.search_runs(filter_string='tags.model_type = "random_forest"'),
    mlflow.search_runs(filter_string='tags.model_type = "xgboost"'),
]).drop_duplicates(subset="run_id")

プロダクションチェックリスト

□ バックエンドストアをPostgreSQL/MySQLに設定
□ アーティファクトストアをS3/GCS/MinIOに設定
□ 認証/認可の設定（OIDC、Basic Auth）
□ 自動実験記録（autolog）の設定
□ Model Registryのalias規則を策定
□ CI/CDでモデル検証を自動化
□ モデルサービングのヘルスチェックを設定
□ 実験整理ポリシーの定義（古い実行のアーカイブ）

失敗事例と落とし穴

症状から書きます。実際に出会う順序がそうだからです。

症状: 学習は終わったのに Run がずっと RUNNING のまま。診断: autolog と手動の Run が重なっています。アクティブな Run がないとき mlflow.autolog() は Run を自分で作り、学習が終われば自分で閉じます。ところがすでに開いている Run があると、ドキュメントの説明どおり、その Run に記録はするものの学習終了後に自動では閉じません。with ブロックなしで start_run() を呼んだなら mlflow.end_run() を自分で呼ぶ必要があります。

症状: パラメータサーチを 50 回回したのに子 Run が 5 つしかない。診断: sklearn の autolog はパラメータサーチ estimator に対して親 Run 一つと複数の子 Run を作りますが、子の数は max_tuning_runs で制限されます。デフォルト値は 5 です。残りの試行は個別の Run としてそもそも記録されません。全部見たいならこの値を上げてください。autolog がサポートするフレーバーは Keras/TensorFlow、LightGBM、Paddle、PySpark、PyTorch、scikit-learn、Spark、statsmodels、XGBoost です。

症状: log_model() で非推奨の警告が出る。診断: artifact_path= を使っています。MLflow 3.0 から name= に変わり、ドキュメントにも artifact_path= は非推奨で name を使うようにと書かれています。警告の段階なのですぐ壊れはしませんが、新しく書くコードは name= に統一するほうがよいです。

症状: mlflow.register_model() の呼び出しが数分戻ってこない。診断: この関数は await_registration_for 引数を持ち、デフォルト値は 300 秒です。モデルバージョンが準備できるまで最大 5 分待ちます。CI パイプラインが理由もなく 5 分伸びたなら、たいていここです。

症状: 昔のチュートリアルの Stage コードが警告を出すか動かない。診断: ドキュメントは Model Stage が非推奨であり、将来のメジャーリリースで削除される予定だと案内しています。対象の API は transition_model_version_stage() です。削除バージョンはまだ発表されていませんが、いま新しく書くコードなら alias とタグに移すのが正解です。旧 Production ステージに対応する名前としてドキュメントが例に挙げるのが champion です。alias を付けるときは client.set_registered_model_alias()、読むときは client.get_model_version_by_alias()、外すときは client.delete_registered_model_alias() を使います。モデルを呼ぶときに models:/iris-classifier@champion 形式の URI を使えば、バージョン番号をコードに埋め込まずに済みます。

症状: 複数人が同時に学習を回すと記録が断続的に失敗する。診断: バックエンドストアが SQLite かどうかをまず確認してください。SQLite はファイルロックベースなので、同時書き込みが集中すると待たされるか失敗します。公式ドキュメントの案内は明確です。同時実行の多いプロダクション環境なら PostgreSQL か MySQL を検討せよ、ということです。一人で使うノートパソコンなら SQLite で十分で、チームが加わったら移す時期です。

# autolog が Run を閉じてくれる場合とそうでない場合
mlflow.autolog()

model.fit(X_train, y_train)          # アクティブな Run なし -> 作って閉じてくれる

with mlflow.start_run(run_name="manual"):
    model.fit(X_train, y_train)      # ここに記録され、ブロックを出るときに閉じる

run = mlflow.start_run(run_name="leaky")
model.fit(X_train, y_train)          # 記録はされるが閉じられない
mlflow.end_run()                     # 自分で閉じる必要がある

MLflow を使わないほうがよいとき

入門記事があまり書かない部分なので、別に立てておきます。

ノートブック一つで終わる使い捨ての分析なら MLflow は過剰です。基準を一つ挙げるとこうです。同じコードをパラメータだけ変えて三回以上回すつもりがないなら、まだ早いです。逆に、先週回したあの設定は何だったかという質問が一度でも出たなら、そのときが導入時期です。

MLflow がやらないことも、はっきりさせておくほうがよいです。

オーケストレーションはしません。スケジューリング、リトライ、依存グラフは Airflow や Argo のようなツールの担当です。
フィーチャストアではありません。特徴量を計算してくれることも、学習とサービングの整合性を保証してくれることもありません。
データのバージョン管理ツールではありません。Run にデータセット情報を付けることはできますが、データ自体のスナップショットは取りません。
プロダクション監視ツールではありません。デプロイしたモデルのドリフトやレイテンシには別の観測スタックが必要です。

まとめると MLflow は、何をどの設定で回して結果がどうだったかを残す台帳です。

参考資料

以下のリンクは 2026-08-16 確認時点のものです。本文の引数とデフォルト値は MLflow 3.15.1 のドキュメントに従っており、バージョンが違えば変わる可能性があります。正確な API は使用中のバージョンのドキュメントで確認してください。

MLflow 3 の概要: https://mlflow.org/docs/latest/ml/mlflow-3/
mlflow.sklearn API: https://mlflow.org/docs/latest/api_reference/python_api/mlflow.sklearn.html
Model Registry: https://mlflow.org/docs/latest/ml/model-registry/
Model Registry ワークフロー: https://mlflow.org/docs/latest/ml/model-registry/workflow/
Autologging: https://mlflow.org/docs/latest/ml/tracking/autolog/
Run の検索構文: https://mlflow.org/docs/latest/ml/search/search-runs/
CLI リファレンス: https://mlflow.org/docs/latest/api_reference/cli.html
ローカルへのモデルデプロイ: https://mlflow.org/docs/latest/ml/deployment/deploy-model-locally/
トラッキングサーバーのアーキテクチャ: https://mlflow.org/docs/latest/self-hosting/architecture/tracking-server/
バックエンドストア: https://mlflow.org/docs/latest/self-hosting/backend-store/

確認クイズ（6問）

Q1. MLflowの4つの主要コンポーネントは？

Tracking、Projects、Models、Model Registry

Q2. mlflow.log_paramsとmlflow.log_metricsの違いは？

log_paramsは学習ハイパーパラメータ（文字列）を記録し、log_metricsは性能指標（数値）を記録します。メトリクスはstepパラメータでエポックごとの追跡が可能です。

Q3. MLflow 2.xでモデルデプロイ管理に使用する概念は？

Alias（例：@champion、@challenger）。Stageは非推奨になりました。

Q4. nested=Trueパラメータはいつ使用しますか？

ハイパーパラメータチューニングのように、親の実行の中で複数の子実行を記録する際に使用します。

Q5. アーティファクトストアにS3を使用する理由は？

モデルファイルやグラフなどの大容量アーティファクトをスケーラブルなオブジェクトストレージに保存し、チーム間の共有とバージョン管理を容易にするためです。

Q6. mlflow.autolog()の長所と短所は？

長所：コード変更なしで自動的にパラメータ/メトリクス/モデルを記録。短所：不要な情報が多く記録される場合があり、カスタムメトリクスは別途記録が必要です。

クイズ

Q1: 「MLflow完全ガイド：実験追跡からModel Registry、プロダクションデプロイまで」の主なトピックは何ですか？

MLflowを使ったML実験管理の全ワークフローをハンズオンで実習します。Trackingで実験を記録し、Model Registryでバージョン管理、プロダクションデプロイまで実装します。

Q2: MLflowとは？とは何ですか？

MLflowはMLライフサイクルを管理するオープンソースプラットフォームです。4つの主要コンポーネントで構成されています： MLflow Tracking: 実験のパラメータ、メトリクス、アーティファクトを記録 MLflow Projects: 再現可能なMLコードのパッケージング MLflow Models: 様々なフレームワークのモデルを統一形式でパッケージング MLflow Model Registry: モデルのバージョン管理とデプロイワークフロー

Q3: インストールとサーバー設定の主な手順は何ですか？

基本インストール Docker Composeでデプロイ

Q4: 実験追跡（Tracking）の主な特徴は何ですか？

基本的な使い方ハイパーパラメータチューニングの追跡 PyTorchモデルの追跡

Q5: Model Registryはどのように機能しますか？

モデルの登録とバージョン管理 Aliasを活用したデプロイ管理モデルタグの活用