こちらのもくもく会の資料です。
スライドはこちら。
使用するノートブック。
MLflowとは何か？
機械学習ライフサイクル管理プラットフォーム
実験から本番運用までをシームレスに管理するオープンソースツール
提供する価値
- 実験の完全な追跡と比較
- ワンクリックでのモデル再現
- 統一的なモデル管理とバージョン管理
- プラットフォーム非依存のデプロイ
- チーム全体での知見の共有
MLflowが解決する課題
誕生から現在に至る変遷
-
2018年 誕生期
Databricksによるオープンソース化。従来型ML向けの実験管理 -
2018-2023 成長期
多様なMLフレームワーク統合、モデルレジストリ充実、数百万ユーザー獲得 -
2023-2024 生成AI対応
MLflow 2.x系でLLM対応機能追加、プロンプト管理、LLM評価 -
2025年〜 MLflow 3.0の革新
LoggedModel導入、2つのユーザージャーニー、最新版は3.5.0 (2025年10月)
MLflow 3.0の2つのユーザージャーニー
モデルトレーニング
従来型機械学習・深層学習ワークフロー
- 実験トラッキング
- モデルパッケージング
- レジストリ管理
- デプロイメント
生成AIアプリ & エージェント
生成AI特化の開発ワークフロー
- 生成AI トレーシング
- プロンプト管理
- 評価フレームワーク
- エージェント最適化
主要提供機能：モデルのトレーニング
📊 実験トラッキング
- パラメータ、メトリクス、成果物の自動記録
- 実験の比較と可視化
- LoggedModelによる統合管理
📦 モデルレジストリ
- モデルのバージョン管理とステージ管理
- Unity Catalogとの統合
- Model Registry Webhooks (3.3.0以降)
🚀 モデルデプロイメント
- 複数形式でのエクスポート、REST APIサービス化
主要提供機能：生成AIアプリ & エージェント
🔍 トレーシング
- 生成AIアプリケーションの完全な可観測性
- Auto-tracing対応（OpenAI、Claude、Langchain等）
- OpenTelemetryメトリクスエクスポート (3.4.0以降)
- PII マスキング、TypeScript SDK対応
📈 評価
- 生成AI評価 in OSS (3.3.0以降)
- カスタムジャッジAPI (3.4.0以降)
- フィードバック追跡、評価データセット管理
💬 プロンプト管理
- プロンプトレジストリ、プロンプト最適化API (3.5.0以降)
🔌 インテグレーション & ツール連携
- MCP Server (3.4.0以降)、Databricks Agent Framework連携
⚡ 共通基盤機能
- ジョブ実行バックエンド、FastAPI + Uvicorn Server
- エクスペリメントタイプ (ML/GenAI自動判別)
LoggedModel：新しい第一級オブジェクト
Run中心 → Model中心へのパラダイムシフト
MLflow 3.0で導入された新しいアーキテクチャの核心概念
主な特徴
- 生成AIエージェント、DLチェックポイント、モデルバリアントを統合管理
- 複数の評価ラウンドに対応
- トレースとメトリクスを一元的にグループ化
- バージョン間の包括的な比較が可能
もくもく会
📚 Notebook 1：MLflow基礎編
- LoggedModelを使った実験管理
- パラメータ、メトリクス、モデルのログ
- Unity Catalogへの登録
🤖 Notebook 2：生成AIのトレーシング & 評価
- Tracingの基本とAuto-tracing
- 生成AI評価の実践
Notebook1_ MLflowチュートリアル
このノートブックでは、MLflowを使わない場合の課題を体験した後、MLflowを使った解決方法を学びます。
本日の流れ
- データの準備とEDA: データを理解する
- Part 1: MLflowなしで実験（課題を体験）
- Part 2: MLflowで同じ実験（課題解決を実感）
- Part 3: 複数モデルの比較（MLflowの真価を発揮）
- Part 4: モデルの再利用（実務での活用）
- Part 5: Unity Catalogへのモデル登録（組織での共有）
※ Databricks Free Edition (Serverless Compute) で動作確認済みです
📖 参考リンク：Databricks 機械学習ガイド（日本語）
環境セットアップ
必要なライブラリをインストールします。
- MLflow: 機械学習の実験管理ツール
- Plotly: インタラクティブなグラフ作成ライブラリ
- すでにインストール済みの場合は「Requirement already satisfied」と表示されます
📖 参考リンク：
# MLflowとplotlyのインストール（最新版）と、Pythonカーネルの再起動
%pip install mlflow plotly
dbutils.library.restartPython()
事前準備：データの読み込み
今回使用するのは Diabetes データセット です。
- 糖尿病患者のデータ（年齢、BMI、血圧など10個の特徴量）
- 1年後の病状進行度を予測する回帰問題
- 442サンプル
注意: このデータセットの特徴量は標準化済みです
- 各特徴量は平均0、標準偏差1に変換されています
- そのため年齢（age）も小数点の値になっています
- 機械学習では、異なるスケールの特徴量を比較しやすくするため、このような前処理が一般的です
📖 参考リンク：scikit-learn Diabetes データセット（英語）
import pandas as pd
import numpy as np
from sklearn import datasets
from sklearn.model_selection import train_test_split
# データの読み込み
X, y = datasets.load_diabetes(return_X_y=True)
# データの分割（全実験で共通使用）
X_train, X_test, y_train, y_test = train_test_split(
X, y, test_size=0.2, random_state=42
)
# データの確認
print(f"訓練データ: {X_train.shape[0]}サンプル")
print(f"テストデータ: {X_test.shape[0]}サンプル")
print(f"特徴量の数: {X_train.shape[1]}個")
# データフレームとして表示（最初の5行）
feature_names = datasets.load_diabetes().feature_names
df_sample = pd.DataFrame(X_train[:5], columns=feature_names)
df_sample['target'] = y_train[:5]
print("サンプルデータ（標準化済み）:")
display(df_sample)
print("\n特徴量の説明:")
print("age: 年齢, sex: 性別, bmi: BMI, bp: 血圧")
print("s1-s6: 血清測定値（コレステロール、血糖値など）")
訓練データ: 353サンプル
テストデータ: 89サンプル
特徴量の数: 10個
サンプルデータ（標準化済み）:
| age | sex | bmi | bp | s1 | s2 | s3 | s4 | s5 | s6 | target |
|---|---|---|---|---|---|---|---|---|---|---|
| 0.0707687524925978 | 0.05068011873981862 | 0.012116851120166501 | 0.056300895272529315 | 0.0342058144930179 | 0.04941617338368593 | -0.03971920784793797 | 0.03430885887772673 | 0.02736404910541198 | -0.0010776975004659671 | 144 |
| -0.009147093429829445 | 0.05068011873981862 | -0.018061886948495892 | -0.03321323009955148 | -0.02083229983502694 | 0.012151506430731283 | -0.07285394808472044 | 0.07120997975363674 | 0.00027247814860377354 | 0.019632837073706312 | 150 |
| 0.005383060374248237 | -0.044641636506989144 | 0.04984027370599448 | 0.09761510698272045 | -0.015328488402222454 | -0.016345003592116398 | -0.006584467611155497 | -0.002592261998183278 | 0.017036071348324546 | -0.013504018244969336 | 280 |
| -0.027309785684926546 | -0.044641636506989144 | -0.035306880130588664 | -0.029770379123702218 | -0.05660707414825608 | -0.0586200459337036 | 0.030231910429713918 | -0.03949338287409329 | -0.049872451808799324 | -0.1294830118603341 | 125 |
| -0.02367724723390713 | -0.044641636506989144 | -0.06548561819925106 | -0.08141314376144114 | -0.038719686991641515 | -0.05360967054507104 | 0.059685012862409445 | -0.0763945037500033 | -0.0371288393600719 | -0.042498766648810526 | 59 |
簡単なデータ探索（EDA）
モデルを作る前に、データの特徴を理解しましょう
📖 参考リンク：探索的データ解析（日本語）
# 基本統計量の確認
print("=== 基本統計量 ===")
df_all = pd.DataFrame(X, columns=feature_names)
df_all['target'] = y
display(df_all.describe())
| age | sex | bmi | bp | s1 | s2 | s3 | s4 | s5 | s6 | target |
|---|---|---|---|---|---|---|---|---|---|---|
| 442 | 442 | 442 | 442 | 442 | 442 | 442 | 442 | 442 | 442 | 442 |
| -2.511816797794472e-19 | 1.2307902309192911e-17 | -2.2455642172282577e-16 | -4.7975700837874414e-17 | -1.3814992387869595e-17 | 3.918434204559376e-17 | -5.7771786349272854e-18 | -9.042540472060099e-18 | 9.293722151839546e-17 | 1.1303175590075123e-17 | 152.13348416289594 |
| 0.047619047619047644 | 0.047619047619047665 | 0.047619047619047616 | 0.047619047619047596 | 0.04761904761904759 | 0.047619047619047644 | 0.047619047619047596 | 0.047619047619047616 | 0.047619047619047616 | 0.047619047619047644 | 77.09300453299109 |
| -0.1072256316073538 | -0.044641636506989144 | -0.09027529589850945 | -0.11239880254408448 | -0.12678066991651324 | -0.11561306597939897 | -0.10230705051741597 | -0.0763945037500033 | -0.12609712083330468 | -0.13776722569000302 | 25 |
| -0.03729926642522996 | -0.044641636506989144 | -0.03422906805670789 | -0.03665608107540074 | -0.03424784020248786 | -0.03035839725719808 | -0.035117160592829294 | -0.03949338287409329 | -0.03324559264822791 | -0.033179026090433 | 87 |
| 0.005383060374248237 | -0.044641636506989144 | -0.007283766209687899 | -0.00567042229275739 | -0.004320865536613489 | -0.0038190651205350003 | -0.006584467611155497 | -0.002592261998183278 | -0.0019471710869220743 | -0.0010776975004659671 | 140.5 |
| 0.038075906433423026 | 0.05068011873981862 | 0.031248015431550695 | 0.03564378941743375 | 0.028358014845663134 | 0.02984439452183999 | 0.02931150097869218 | 0.03430885887772673 | 0.03243232415655107 | 0.027917050903375224 | 211.5 |
| 0.11072667545381144 | 0.05068011873981862 | 0.17055522598064407 | 0.13204361674121307 | 0.15391371315651542 | 0.19878798965729408 | 0.18117906039727852 | 0.18523444326019867 | 0.13359728192191356 | 0.13561183068907107 | 346 |
# ターゲット変数（病状進行度）の分布を確認
import plotly.express as px
fig = px.histogram(
df_all,
x='target',
nbins=30,
title='ターゲット変数（病状進行度）の分布',
labels={'target': '病状進行度', 'count': '患者数'},
color_discrete_sequence=['skyblue']
)
fig.update_layout(showlegend=False)
fig.show()
print(f"最小値: {df_all['target'].min():.1f}")
print(f"最大値: {df_all['target'].max():.1f}")
print(f"平均値: {df_all['target'].mean():.1f}")
print(f"中央値: {df_all['target'].median():.1f}")
最小値: 25.0
最大値: 346.0
平均値: 152.1
中央値: 140.5
# 特徴量とターゲットの相関関係を確認
import plotly.graph_objects as go
# 相関係数を計算
correlations = df_all.corr()['target'].drop('target').sort_values(ascending=False)
# 棒グラフで表示
fig = go.Figure(data=[
go.Bar(
x=correlations.index,
y=correlations.values,
marker_color=['red' if v > 0 else 'blue' for v in correlations.values]
)
])
fig.update_layout(
title='各特徴量とターゲット変数の相関係数',
xaxis_title='特徴量',
yaxis_title='相関係数',
height=400
)
fig.show()
print("\n=== 相関が強い特徴量トップ3 ===")
for i, (feature, corr) in enumerate(correlations.head(3).items(), 1):
print(f"{i}. {feature}: {corr:.3f}")
=== 相関が強い特徴量トップ3 ===
1. bmi: 0.586
2. s5: 0.566
3. bp: 0.441
EDAから分かったこと
- ターゲット変数（病状進行度）は約25〜346の範囲に分布
- 特徴量の中で、bmi（BMI）やs5が病状進行度と比較的強い相関がある
- これらの特徴量が予測に重要な役割を果たす可能性が高い
それでは、これらのデータを使ってモデルを作っていきましょう！
Part 1: MLflowを使わない実験 😰
まず、MLflowを使わずに機械学習モデルを作ってみましょう。
やりたいこと
- 線形回帰モデルで予測
- 性能を評価
課題を体験してみましょう！
from sklearn.linear_model import LinearRegression
from sklearn.metrics import mean_squared_error, r2_score
import time
# 実験開始（時刻を記録）
experiment_time = time.strftime("%Y-%m-%d %H:%M:%S")
print(f"実験開始時刻: {experiment_time}")
# モデルの作成と学習
model = LinearRegression()
model.fit(X_train, y_train)
# 予測と評価
predictions = model.predict(X_test)
mse = mean_squared_error(y_test, predictions)
r2 = r2_score(y_test, predictions)
print(f"\n=== 実験結果 ===")
print(f"MSE (平均二乗誤差): {mse:.2f}")
print(f"R² スコア: {r2:.3f}")
実験開始時刻: 2025-11-05 11:57:32
=== 実験結果 ===
MSE (平均二乗誤差): 2900.19
R² スコア: 0.453
😰 MLflowなしの課題
上の実験で、以下の課題があります：
1. 実験結果が残らない
- セルを再実行したら、前の結果が消えてしまう
- 「さっきの実験、MSEいくつだったっけ？」→ わからない...
2. 複数実験の比較が大変
- 3つのモデルを試したとき、どれが良かった？
- コピペでメモ？エクセルに手入力？
3. 再現できない
- 「あの良い結果、どの設定でやったんだっけ？」
- モデルファイルはどこに保存した？
次のPart 2では、MLflowでこれらの課題を解決します！
Part 2: MLflowで同じ実験 😊
全く同じ実験を、今度はMLflowを使ってやってみましょう。
MLflowの基本用語（5つだけ覚えましょう！）
| 用語 | 意味 | 例 |
|---|---|---|
| Run（ラン） | 1回の実験 | 「今日の1回目の実験」 |
| Parameter（パラメータ） | モデルの設定値 | test_size=0.2 |
| Metric（メトリクス） | 評価指標（数値） | MSE=2800.5 |
| Model（モデル） | 学習済みモデル | 保存されたファイル |
| Experiment（エクスペリメント） | 複数Runをまとめる箱 | 「糖尿病予測プロジェクト」 |
📖 参考リンク：MLflow Tracking（日本語）
エクスペリメントの種類
MLflowには2種類のエクスペリメントがあります：
1. ノートブックエクスペリメント（今回使用）
- ノートブックに自動的に添付される
- ノートブックを開くと、右上のフラスコアイコンから確認できる
- 手軽で初心者におすすめ
-
mlflow.start_run()を実行すると、自動的にノートブックエクスペリメントに記録される
2. ワークスペースエクスペリメント
- ワークスペース内の独立したファイルとして作成
- 複数のノートブックから同じエクスペリメントを参照できる
- チームでの共有に便利
-
mlflow.set_experiment()で明示的に指定が必要
今回はノートブックエクスペリメントを使用します！
特に設定しなくても、mlflow.start_run() を実行するだけで自動的に記録されるので簡単です。
📖 参考リンク：エクスペリメントとラン（日本語）
import mlflow
import mlflow.sklearn
from sklearn.linear_model import LinearRegression
from sklearn.metrics import mean_squared_error, r2_score
# MLflowのランを開始（これだけ！）
# ノートブックエクスペリメントに自動的に記録されます
with mlflow.start_run(run_name="Linear Regression - with MLflow"):
# --- ここから同じコード ---
model = LinearRegression()
model.fit(X_train, y_train)
predictions = model.predict(X_test)
mse = mean_squared_error(y_test, predictions)
r2 = r2_score(y_test, predictions)
# --- ここまで同じ ---
# MLflowに記録（追加部分）
mlflow.log_param("model_type", "LinearRegression")
mlflow.log_param("test_size", 0.2)
mlflow.log_metric("mse", mse)
mlflow.log_metric("r2_score", r2)
# モデルも保存
mlflow.sklearn.log_model(
sk_model=model,
name="model",
input_example=X_train[:1] # モデルの入力例
)
print(f"MSE: {mse:.2f}")
print(f"R² Score: {r2:.3f}")
print("\n✅ MLflowに記録されました！")
🔗 View Logged Model at: https://dbc-4676632f-7fbb.cloud.databricks.com/ml/experiments/1696904fb2634a5bb84f0de6d5d835c1/models/m-782f8cfc4f8e4c1598f7ddaa670114ba?o=3224001485664229
MSE: 2900.19
R² Score: 0.453
✅ MLflowに記録されました！
😊 MLflowで解決されたこと
1. 実験結果が自動保存される
- 右上のフラスコアイコン 🧪 をクリック → 実験履歴が見える！
- MSE、R²、パラメータ、実行時刻、全て記録されている
2. コードで実験結果を取得できる
- 次のセルで実験履歴を確認してみましょう
📖 参考リンク：MLflowでのモデルの記録（日本語）
# 実験履歴の取得
runs_df = mlflow.search_runs()
# run_nameカラムを作成（バージョン互換性のため）
if 'run_name' not in runs_df.columns:
runs_df['run_name'] = runs_df['tags.mlflow.runName']
# 主要な情報だけ表示
display(runs_df[[
'run_name',
'start_time',
'metrics.mse',
'metrics.r2_score',
'params.model_type'
]].sort_values('start_time', ascending=False))
| run_name | start_time | metrics.mse | metrics.r2_score | params.model_type |
|---|---|---|---|---|
| Linear Regression - with MLflow | 2025-11-05T11:57:35.468+00:00 | 2900.193628493483 | 0.45260276297191915 | LinearRegression |
Part 3: 複数モデルの比較（MLflowの真価！）
ここからがMLflowの本領発揮！
3つの異なるモデルを試して、どれが一番良いか比較してみましょう：
- 線形回帰（Linear Regression）
- ランダムフォレスト（Random Forest）
- Gradient Boosting
📖 参考リンク：実験の比較（日本語）
from sklearn.ensemble import RandomForestRegressor, GradientBoostingRegressor
# 実験するモデルのリスト
models = [
("Linear Regression", LinearRegression()),
("Random Forest", RandomForestRegressor(n_estimators=100, random_state=42)),
("Gradient Boosting", GradientBoostingRegressor(n_estimators=100, random_state=42))
]
# 各モデルで実験を実行
for model_name, model in models:
with mlflow.start_run(run_name=model_name):
# 学習
model.fit(X_train, y_train)
# 予測
predictions = model.predict(X_test)
# 評価
mse = mean_squared_error(y_test, predictions)
r2 = r2_score(y_test, predictions)
rmse = np.sqrt(mse)
# MLflowに記録
mlflow.log_param("model_type", model_name)
mlflow.log_metric("mse", mse)
mlflow.log_metric("rmse", rmse)
mlflow.log_metric("r2_score", r2)
# モデル保存
mlflow.sklearn.log_model(
sk_model=model,
name="model",
input_example=X_train[:1]
)
print(f"✅ {model_name}: MSE={mse:.2f}, R²={r2:.3f}")
print("\n🎉 全モデルの実験完了！")
🔗 View Logged Model at: https://dbc-4676632f-7fbb.cloud.databricks.com/ml/experiments/1696904fb2634a5bb84f0de6d5d835c1/models/m-b37d5225c4ca4f639f3dbd86ad9a3975?o=3224001485664229
✅ Linear Regression: MSE=2900.19, R²=0.453
🔗 View Logged Model at: https://dbc-4676632f-7fbb.cloud.databricks.com/ml/experiments/1696904fb2634a5bb84f0de6d5d835c1/models/m-8e0135c7aebb47fd95e3450eb85ce1a4?o=3224001485664229
✅ Random Forest: MSE=2952.01, R²=0.443
🔗 View Logged Model at: https://dbc-4676632f-7fbb.cloud.databricks.com/ml/experiments/1696904fb2634a5bb84f0de6d5d835c1/models/m-2ba6e0f6bff0445888dff171233d227e?o=3224001485664229
✅ Gradient Boosting: MSE=2898.44, R²=0.453
🎉 全モデルの実験完了！
結果を比較してみましょう！
MLflowなら、複数実験を簡単に比較できます
# 全実験の取得
all_runs = mlflow.search_runs()
# run_nameカラムを作成（バージョン互換性のため）
if 'run_name' not in all_runs.columns:
all_runs['run_name'] = all_runs['tags.mlflow.runName']
# 比較表を作成
comparison_df = all_runs[[
'run_name',
'metrics.mse',
'metrics.rmse',
'metrics.r2_score'
]].sort_values('metrics.mse')
print("=== モデル性能比較（MSEが小さいほど良い）===")
display(comparison_df)
# ベストモデルを表示
best_run = comparison_df.iloc[0]
print(f"\n🏆 ベストモデル: {best_run['run_name']}")
print(f" MSE: {best_run['metrics.mse']:.2f}")
print(f" R² Score: {best_run['metrics.r2_score']:.3f}")
| run_name | metrics.mse | metrics.rmse | metrics.r2_score |
|---|---|---|---|
| Gradient Boosting | 2898.4366729135236 | 53.83713098701976 | 0.4529343796683363 |
| Linear Regression | 2900.193628493483 | 53.85344583676594 | 0.45260276297191915 |
| Linear Regression - with MLflow | 2900.193628493483 | null | 0.45260276297191915 |
| Random Forest | 2952.0105887640448 | 54.332408273184846 | 0.4428225673999313 |
📊 視覚化してみましょう
import plotly.graph_objects as go
from plotly.subplots import make_subplots
# データの準備
comparison_df_sorted = comparison_df.sort_values('metrics.mse', ascending=True)
comparison_df_r2 = comparison_df.sort_values('metrics.r2_score', ascending=True)
# サブプロットの作成
fig = make_subplots(
rows=1, cols=2,
subplot_titles=('モデル性能比較 - MSE', 'モデル性能比較 - R² Score')
)
# グラフ1: MSE比較
fig.add_trace(
go.Bar(
x=comparison_df_sorted['metrics.mse'],
y=comparison_df_sorted['run_name'],
orientation='h',
marker_color='skyblue',
name='MSE'
),
row=1, col=1
)
# グラフ2: R²スコア比較
fig.add_trace(
go.Bar(
x=comparison_df_r2['metrics.r2_score'],
y=comparison_df_r2['run_name'],
orientation='h',
marker_color='lightgreen',
name='R² Score'
),
row=1, col=2
)
# レイアウトの設定
fig.update_xaxes(title_text='MSE (小さいほど良い)', row=1, col=1)
fig.update_xaxes(title_text='R² Score (大きいほど良い)', row=1, col=2)
fig.update_layout(
height=400,
showlegend=False,
title_text='モデル性能の比較'
)
fig.show()
Part 4: モデルの再利用（実務での活用）
MLflowに保存したモデルは、いつでもロードして使えます！
想定シーン：
- 「先週の実験で作った良いモデル、本番で使いたい」
- 「新しいデータで予測したい」
📖 参考リンク：モデルのロードと推論（日本語）
最も性能の良いモデルをロードする
# ログされたモデルを検索（MSEの昇順でソート）
logged_models = mlflow.search_logged_models(
order_by=[{"field_name": "metrics.mse", "ascending": True}],
max_results=50,
output_format="list"
)
if len(logged_models) == 0:
print("❌ ログされたモデルが見つかりません")
print("Part 2またはPart 3を実行してモデルをログしてください")
else:
# ベストモデル（MSEが最小）を取得
best_model = logged_models[0]
print(f"ロードするモデル名: {best_model.name}")
print(f"モデルURI: {best_model.model_uri}")
# モデルのロード
loaded_model = mlflow.pyfunc.load_model(best_model.model_uri)
print("\n✅ モデルのロード完了！")
ロードするモデル名: model
モデルURI: models:/m-2ba6e0f6bff0445888dff171233d227e
✅ モデルのロード完了！
ロードしたモデルで予測してみる
if len(logged_models) > 0:
# テストデータの一部で予測
sample_data = X_test[:5]
predictions = loaded_model.predict(sample_data)
# 結果を表示
results_df = pd.DataFrame({
'予測値': predictions,
'実際の値': y_test[:5],
'誤差': np.abs(predictions - y_test[:5])
})
print("=== 予測結果 ===")
display(results_df)
print(f"\n平均誤差: {results_df['誤差'].mean():.2f}")
else:
print("⚠️ モデルがロードされていないため、予測をスキップします")
| 予測値 | 実際の値 | 誤差 |
|---|---|---|
| 161.28890402348782 | 219 | 57.71109597651218 |
| 190.52483685489605 | 70 | 120.52483685489605 |
| 170.53102229767367 | 202 | 31.468977702326328 |
| 285.06072731740306 | 230 | 55.060727317403064 |
| 126.49996592033699 | 111 | 15.49996592033699 |
Part 5: Unity Catalogへのモデル登録
ベストモデルをUnity Catalogに登録して、組織全体で管理・共有できるようにします。
Unity Catalogとは？
- Databricksのデータとモデルのガバナンス機能
- モデルのバージョン管理、アクセス制御、系譜追跡が可能
- Databricks Free Editionでは
workspace.defaultスキーマが最初から利用可能
📖 参考リンク：Unity Catalogモデルレジストリ（日本語）
ベストモデルをUnity Catalogに登録
# ベストモデルの情報を再取得（ログされたモデルから）
logged_models_uc = mlflow.search_logged_models(
order_by=[{"field_name": "metrics.mse", "ascending": True}],
max_results=50,
output_format="list"
)
if len(logged_models_uc) == 0:
print("❌ ログされたモデルが見つかりません")
print("Part 2またはPart 3を実行してモデルをログしてください")
else:
# ベストモデル（MSEが最小）を取得
best_model_uc = logged_models_uc[0]
print(f"登録するモデル名: {best_model_uc.name}")
print(f"モデルURI: {best_model_uc.model_uri}")
# Unity Catalogのモデル名を設定
# フォーマット: カタログ名.スキーマ名.モデル名
uc_model_name = "workspace.default.diabetes_prediction_model"
print(f"\nUnity Catalogモデル名: {uc_model_name}")
登録するモデル名: model
モデルURI: models:/m-2ba6e0f6bff0445888dff171233d227e
Unity Catalogモデル名: workspace.default.diabetes_prediction_model
# ベストモデルをUnity Catalogに登録
if len(logged_models_uc) > 0:
model_version = mlflow.register_model(
model_uri=best_model_uc.model_uri,
name=uc_model_name
)
print(f"✅ モデルをUnity Catalogに登録しました！")
print(f"モデル名: {uc_model_name}")
print(f"バージョン: {model_version.version}")
else:
print("⚠️ モデルがないため、Unity Catalogへの登録をスキップします")
Registered model 'workspace.default.diabetes_prediction_model' already exists. Creating a new version of this model...
✅ モデルをUnity Catalogに登録しました！
モデル名: workspace.default.diabetes_prediction_model
バージョン: 4
🔗 Created version '4' of model 'workspace.default.diabetes_prediction_model': https://dbc-4676632f-7fbb.cloud.databricks.com/explore/data/models/workspace/default/diabetes_prediction_model/version/4?o=3224001485664229
登録されたモデルの確認
Unity Catalogに登録したモデルは、以下の方法で確認できます：
-
カタログエクスプローラー: 左サイドバーの「Catalog」から
workspace→default→ モデル名 - コード: MLflow APIを使用
# 登録されたモデルの情報を取得
from mlflow import MlflowClient
if len(logged_models_uc) > 0:
client = MlflowClient()
# モデルの最新情報を取得
model_info = client.get_registered_model(uc_model_name)
print(f"=== モデル情報 ===")
print(f"モデル名: {model_info.name}")
print(f"作成日時: {model_info.creation_timestamp}")
print(f"最終更新: {model_info.last_updated_timestamp}")
# すべてのバージョンを表示
model_versions = client.search_model_versions(f"name='{uc_model_name}'")
print(f"\n登録されているバージョン数: {len(model_versions)}")
for mv in model_versions:
print(f" - バージョン {mv.version}: ステータス={mv.status}")
else:
print("⚠️ 登録されたモデルがありません")
=== モデル情報 ===
モデル名: workspace.default.diabetes_prediction_model
作成日時: 1762328669817
最終更新: 1762343881233
登録されているバージョン数: 4
- バージョン 4: ステータス=READY
- バージョン 3: ステータス=READY
- バージョン 2: ステータス=READY
- バージョン 1: ステータス=READY
Unity Catalogからモデルをロードして使用
# Unity Catalogからモデルをロード
if len(logged_models_uc) > 0:
# バージョンを指定しない場合、最新バージョンが使用されます
uc_loaded_model = mlflow.pyfunc.load_model(f"models:/{uc_model_name}/{model_version.version}")
# 予測を実行
sample_predictions = uc_loaded_model.predict(X_test[:3])
# 結果を表示
uc_results_df = pd.DataFrame({
'予測値': sample_predictions,
'実際の値': y_test[:3],
'誤差': np.abs(sample_predictions - y_test[:3])
})
print("=== Unity Catalogモデルでの予測結果 ===")
display(uc_results_df)
print("\n✅ Unity Catalogに登録したモデルで予測できました！")
else:
print("⚠️ 登録されたモデルがないため、予測をスキップします")
| 予測値 | 実際の値 | 誤差 |
|---|---|---|
| 161.28890402348782 | 219 | 57.71109597651218 |
| 190.52483685489605 | 70 | 120.52483685489605 |
| 170.53102229767367 | 202 | 31.468977702326328 |
Unity Catalogのメリット
✅ 一元管理
- すべてのモデルが1箇所で管理される
- カタログエクスプローラーから簡単にアクセス
✅ バージョン管理
- モデルの全バージョンが保存される
- いつでも過去のバージョンに戻せる
✅ アクセス制御
- 誰がモデルを使用できるかを制御
- 本番環境での誤使用を防止
✅ 系譜追跡（リネージ）
- モデルがどのデータから作られたかを追跡
- ガバナンスとコンプライアンスに対応
まとめ：MLflowのメリット
✅ 実験管理が楽に
- 実験結果が自動保存される
- いつでも過去の実験を確認できる
- 「あれ、どの設定だっけ？」が無くなる
✅ 比較が簡単
- 複数モデルの性能を一目で比較
- ベストモデルがすぐわかる
- グラフ化も簡単
✅ 再現性の確保
- モデルを保存・ロード
- パラメータも全て記録
- 「同じ結果が出ない」が無くなる
✅ チームでの共有
- 実験結果をチームで共有
- 「私のマシンでは動く」問題の解消
✅ Unity Catalogで組織全体での管理
- モデルを一元管理
- バージョン管理とアクセス制御
- ガバナンスとコンプライアンスに対応
次のステップ
- ハイパーパラメータチューニング: Hyperoptの活用（日本語）
- より複雑なモデルの管理: MLflow Projects（英語）
- モデルのデプロイ: モデルサービング（日本語）
- MLflow Models Registry の活用: モデルレジストリ（日本語）
補足：よくある質問
Q1: MLflowはDatabricksでしか使えない？
A: いいえ、ローカル環境でも使えます！pip install mlflow でインストールできます。
Q2: MLflowのデータはどこに保存される？
A: Databricksでは自動的にワークスペースに保存されます。ローカルでは mlruns フォルダに保存されます。
Q3: 実験が増えすぎたら重くならない？
A: MLflowは効率的に管理するので大丈夫です。不要な実験は削除することもできます。
Q4: もっと詳しく学ぶには？
A:
Notebook2_生成AIトレーシング評価
このノートブックでは、MLflowを使った生成AIアプリケーションのトレーシングと評価を学びます。
本日の流れ
- 環境セットアップ: 必要なライブラリのインストール
- Part 1: Tracingの基本とAuto-tracing
- Part 2: GenAI Evaluationの実践（事前構築されたJudge）
- Part 3: モデルのロギングとデプロイ
- Part 4: 本番環境モニタリング
※ Databricks Free Edition (Serverless Compute) で動作確認済みです
📖 参考リンク：
環境セットアップ
必要なライブラリをインストールします。
- MLflow: 実験管理とトレーシング
- Databricks SDK: Foundation Model APIアクセス
- Databricks Agents: GenAI評価用
- OpenAI: MLflow OpenAIトレーシング用
- Pandas: データ処理
# MLflowとDatabricks SDKのインストール
%pip install mlflow databricks-sdk databricks-agents openai pandas plotly
dbutils.library.restartPython()
Part 1: Tracingの基本とAuto-tracing
**トレーシング（Tracing）**とは、LLMアプリケーションの実行過程を記録・可視化する機能です。
なぜトレーシングが必要？
😰 トレーシングなしの課題
- LLMへのプロンプトと応答が見えない
- エラーの原因が分からない
- レイテンシ（遅延）のボトルネックが不明
- コストが把握できない
😊 トレーシングのメリット
- すべてのLLM呼び出しが記録される
- プロンプトと応答が可視化される
- 実行時間とコストが追跡できる
- デバッグが簡単になる
📖 参考リンク：MLflow Tracing入門（英語）
Databricks Foundation Model APIの設定
Databricks Foundation Model API (FMAPI) を使用してLLMを呼び出します。
from databricks.sdk import WorkspaceClient
from databricks.sdk.service.serving import ChatMessage, ChatMessageRole
# WorkspaceClientの初期化
w = WorkspaceClient()
def call_fmapi(prompt: str, endpoint: str = "databricks-gpt-oss-20b") -> str:
"""
Databricks Foundation Model APIを呼び出す
Args:
prompt: LLMへの入力プロンプト
endpoint: Foundation Modelのエンドポイント名
Returns:
LLMからの応答テキスト
"""
response = w.serving_endpoints.query(
name=endpoint,
messages=[
ChatMessage(role=ChatMessageRole.USER, content=prompt)
]
)
return response.choices[0].message.content
print("✅ Foundation Model API設定完了")
シンプルなLLM関数（トレーシングなし）
def simple_llm_call(question: str) -> str:
"""
シンプルなLLM呼び出し（トレーシングなし）
"""
# Databricks Foundation Model APIを使用
return call_fmapi(question)
# トレーシングなしで実行
print("=== トレーシングなしの実行 ===")
result = simple_llm_call("MLflowとは何ですか？")
print(f"質問: MLflowとは何ですか？")
print(f"回答: {result}")
print("\n⚠️ 実行履歴が残りません！")
=== トレーシングなしの実行 ===
質問: MLflowとは何ですか？
回答: [{'type': 'reasoning', 'summary': [{'type': 'summary_text', 'text': "The user asks about MLflow. We should explain. It's an open-source platform to manage ML lifecycle: experiments, reproducibility, deployments. Features: tracking experiments, packaging code in reproducible runs, model registry, deployment ops. Provide overview and some deep details: Tracking API, Projects, Models, Model registry. Provide version, use cases, popular libs. Also mention integration with Python, R, Java, Go. Provide example. Let's answer in Japanese (since user used Japanese). Provide thorough answer."}]}, {'type': 'text', 'text': '## MLflowとは？\n\nMLflow（エムエルフロー）は、機械学習（ML）モデルの **実験管理・再現性・デプロイ** を統一されたワークフローで扱うためのオープンソースプラットフォームです。 \n2020年にDatabricks社がリリースし、Apache 2.0ライセンスで公開されています。Python・R・Java・Go で動作し、ほぼすべての機械学習フレームワーク（scikit‑learn、TensorFlow、PyTorch、XGBoost など）と統合が可能です。\n\n---\n\n### 主なコンポーネント（モジュール）\n\n| # | コンポーネント | 主な役割 | 主なAPI |\n|---|----------------|---------|--------|\n| 1 | **Tracking** | 実験 (run) のロギング（パラメータ・メトリクス・アーティファクト）を保存し、可視化・比較 | `mlflow.log_param`, `mlflow.log_metric`, `mlflow.log_artifact` |\n| 2 | **Projects** | 実験コードを再現可能な“プロジェクト”単位でパッケージング | `mlflow.projects.run` |\n| 3 | **Models** | 様々なフレームワークのモデルを「モデルパッケージ化」し、ローカル・クラウド環境で一貫性のある推論を行う | `mlflow.pyfunc`, `mlflow.sklearn`, `mlflow.tensorflow`, etc. |\n| 4 | **Model Registry** | 複数のモデルバージョンを登録・バージョン管理・ステージング（staging→production）を行う | `mlflow.register_model`, `mlflow.transition_transition` |\n\n> **注:** 「MLflow Tracking」だけで十分機能するケースも多いです。後述のポイントで「Trackingを使うだけで何ができるか」を説明します。\n\n---\n\n## 1. 何を解決するか？\n\n| 課題 | 典型的な流れ | MLflowでの解決策 |\n|------|--------------|-----------------|\n| 実験結果の追跡が散在 | 研究メモ、ローカルファイル、複数のプロジェクトで分散 | **Tracking**：パラメータ・メトリクス・アーティファクトを一元管理・検索・可視化 |\n| 再現性が難しい | コード実行環境変更、パラメータの手入力ミス | **Projects**：環境定義（`conda.yaml`, `requirements.txt`, Docker）、再現可能な実行 |\n| モデルの配布が煩雑 | Kerasモデルをtf-servingへ手動デプロイ | **Models**：モデルを 플랫폼非依存の形式（`Python function`, `JAR`, `ONNX`）で保存し、簡易デプロイ |\n| バージョン管理とデプロイフロー | 本番と開発で隙間が生じる | **Model Registry**：モデルのバージョン管理、ステージング、アクセス制御、メタ情報管理 |\n\n---\n\n## 2. 特徴・利点\n\n| 項目 | 説明 |\n|------|------|\n| **オープンソース** | GitHubで誰でも自由にカスタマイズ・拡張可能 |\n| **Python以外でも使える** | R、Java、Go 向けクライアントが用意 |\n| **プラグイン性** | 任意のログ・デプロイ先（S3, GCS, Azure Blob, MLflow OSS, Databricks等）へ簡単に接続 |\n| **ローカル・クラウド・オンプレ** | 自前で起動したMLflow Server（Flask＋Redis）を社内に設置したり、Databricks Notebookに統合 |\n| **標準化されたAPI** | 3つのコンポーネント（Tracking, Projects, Models）を統一的に呼び出せるので、既存ワークフローへの導入障壁が低い |\n| **実験比較が直感的** | UI上でrunをハイライト, 曲線プロット, エージェント, 上位runsの抜き出しが可能 |\n\n---\n\n## 3. 典型的な実装フロー\n\n```python\n# 1. インポート\nimport mlflow\nimport mlflow.sklearn\nfrom sklearn.datasets import load_iris\nfrom sklearn.model_selection import train_test_split\nfrom sklearn.ensemble import RandomForestClassifier\n\n# 2. 実験開始\nwith mlflow.start_run():\n # 3. パラメータログ\n n_estimators = 200\n mlflow.log_param("n_estimators", n_estimators)\n\n # 4. データ準備\n X, y = load_iris(return_X_y=True)\n X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3)\n\n # 5. モデル学習\n model = RandomForestClassifier(n_estimators=n_estimators)\n model.fit(X_train, y_train)\n\n # 6. 評価\n acc = model.score(X_test, y_test)\n mlflow.log_metric("accuracy", acc)\n\n # 7. モデル保存\n mlflow.sklearn.log_model(model, "model")\n\n# 8. UIで確認: http://127.0.0.1:5000 （デフォルト）\n```\n\nこのシンプルなスクリプトで、**パラメータ・メトリクス・モデルファイル**がMLflow Tracking UIに記録され、数回のクリックで異なる `n_estimators` を比較できるようになります。 \n\nそして、`mlflow.sklearn.log_model` により `model.pkl` を MLflow ログに保存したほか、同時に `MLmodel` というメタ情報ファイルも出力されるので、あとから以下のように *Python関数として再利用* したり、`mlflow models serve` で、簡単に REST API サーバーを起動できます。\n\n```bash\nmlflow models serve -m runs:/<run_id>/model -p 1234\n```\n\n---\n\n## 4. 代表的なユースケース\n\n| シナリオ | MLflowのゴール | 具体的な設定例 |\n|--------|---------------|---------------|\n| **データサイエンティストの実験ノート** | 実験メトリクスを可視化し、共同作業 | Tracking + UI, バージョン管理 |\n| **MLOpsパイプライン構築** | 1〜10回/月のGridSearchを定期実行、best model を自動デプロイ | MLflow Projects + Pipelines + Model Registry |\n| **クラウド/社内ホスト** | 専用のMLflow ServerをDatabricks on AWSで構築 | Databricks Workspace + MLflow Tracking |\n| **CI/CD Pipeline** | 変更があったモデルを自動でテスト・スタッジングにデプロイ | GitHub Actions + Docker + MLflow CLI |\n\n---\n\n## 5. 競合／補完ツールとの違い\n\n| 競合／補完 | 主な違い | 何に適しているか |\n|-------------|----------|-----------------|\n| **Weights & Biases** | 企業向け SaaS（Analyticsに特化） | 大規模データ＆チーム向け |\n| **Neptune.ai** | GA4のようにダッシュボードに特化 | 視覚的にクイックフィードバックが必要 |\n| **TensorBoard** | TensorFlowに特化 | グラフ・トレーシング中心 |\n| **Azure ML/ SageMaker** | Cloud MVC & Model Deploy の統合 | クラウドベンダーリングに特化 |\n| **DVC (Data Version Control)** | データ・モデルのバージョン管理 | データのバージョン管理とMLflow の組み合わせ |\n| **MLflow (X)** | シンプルな“ホスト”＋“SDK”ので、組み込みが容易 | シンプルなプロトタイピングからSTAGING→PRODまで |\n\nMLflowは「**ベースプレイヤー／ブリッジ**」であることが多く、他ツールと併用して使われるケースがほとんどです。 \n例えば、**DVC** でデータをバージョン管理しつつ **MLflow** で experiment/tracking を行うと、データとモデル両方の再現性を確保できます。\n\n---\n\n## 6. デプロイ時に使えるMLflowの機能\n\n| 機能 | 用途 |\n|------|------|\n| **mlflow.serving** | `mlflow_model` を Flask/Spark Rest Server でホスト |\n| ** Docker / OCI Image** | `mlflow build-docker` で自動で Dockerfile を生成し、k8s へのデプロイ |\n| **MLflow with Kubernetes** | `mlflow k8s deploy` コマンドで実験・モデルを K8s に自動デプロイ |\n| **ONNX & TorchScript** | `mlflow.pyfunc` で任意の PyTorch/TensorFlow モデルを (ONNX/TorchScript) 形式に変換・保存 |\n| **Model Registry API** | REST API を介してモデルバージョンを更新、ダウンロード、ステージング切替 |\n\n---\n\n## 7. まとめ\n\n- **MLflowは実験管理からデプロイまでを一貫して扱える** オールインワンのオープンソースープレートフォーム。\n- 主要コンポーネント（Tracking, Projects, Models, Model Registry）があるだけで、**ML開発フローのほぼ全て**に対応。\n- Python/Java/R/Go で使える SDK と統合済みのウェブ UI が提供され、**ガイド付きパイプライン**を短時間で構築可能。\n- **クラウド/社内公開**も自前ホスト+S3/GCS のように柔軟に構成できるため、**エンタープライズレベルのMLOps**に向いている。\n\nもし、“どのコンポーネントをどのように取り入れればいいか”や、“既存のCI/CDにどう組み込むか”で具体的にご相談されたい場合は、お気軽にお知らせください！ 🚀'}]
⚠️ 実行履歴が残りません！
Auto-tracingの有効化
MLflowのAuto-tracingを使うと、LLM呼び出しを自動的にトレースできます。
**span_type（スパンタイプ）**を設定することで、トレース画面に適切なアイコンが表示されます：
-
LLM: LLM呼び出し（💬アイコン） -
RETRIEVER: ドキュメント検索（🔍アイコン） -
CHAIN: 複数ステップの処理（🔗アイコン） -
TOOL: ツール呼び出し（🔧アイコン）
import mlflow
import mlflow.openai
# Auto-tracingを有効化（OpenAI互換API用）
mlflow.openai.autolog()
# トレースされる関数
@mlflow.trace(span_type="LLM")
def traced_llm_call(question: str) -> str:
"""
トレースされるLLM呼び出し
"""
# Databricks Foundation Model APIを使用
return call_fmapi(question)
# トレーシングありで実行
print("=== トレーシングありの実行 ===")
result = traced_llm_call("トレーシングはどのように機能しますか？")
print(f"質問: トレーシングはどのように機能しますか？")
print(f"回答: {result}")
print("\n✅ トレースが記録されました！")
print("右側の「Traces」タブから確認できます")
=== トレーシングありの実行 ===
質問: トレーシングはどのように機能しますか？
回答: [{'type': 'reasoning', 'summary': [{'type': 'summary_text', 'text': 'The user asks in Japanese: "トレーシングはどのように機能しますか？" meaning "How does tracing work?" This is likely referring to tracing in the context of terminal or command tracing? Possibly they refer to software tracing (like OpenTracing, distributed tracing). We need context: maybe they\'re referring to Docker or serverless? The assistant previously has no context. Provided instructions: answer in Japanese. Should explain general concept of tracing, e.g., distributed tracing, application instrumentation, trace IDs, sampling etc. Provide example, maybe with OpenTelemetry. The user likely asking about tracing in some system. We need to respond with an explanation that covers mechanism, how traces propagate, instrumentation, storage, visualization. Provide step-by-step. Provide how to enable tracing (configuration).\n\nOk respond in Japanese with clarity.'}]}, {'type': 'text', 'text': '## トレーシング（分散トレーシング）は何か \nトレーシングとは、**1 つのリクエストがシステム全体をどのように流れたのか**を可視化・解析する仕組みです。 \n「マイクロサービス」や「クラウドネイティブなアプリケーション」では、1 つの処理が複数のサービスやコンポーネントを跨いで行われます。 \nトレーシングを使うと \n\n1. **どこで遅延が発生しているか** \n2. **どのサービスがボトルネックになっているか** \n3. **依存関係（A→B→C）の把握** \n4. **障害発生時の再現性の向上** \n\nが可能になります。\n\n---\n\n## 架空のバックエンドサービス（例：User Service → Order Service → Payment Service）での流れを追う手順 \n\n| ステップ | 何が起きるか | 重要な情報 |\n|----------|--------------|-----------|\n| **1. リクエスト到着** | 例：API Gateway が `/orders` へのリクエストを受け取る | **Trace ID**（同じリクエストを識別する一意な ID）と **Span ID**（個々の処理単位）を生成 |\n| **2. Trace/Span 議論** | **Sampler**：そのリクエストをトレースするかどうか判定（例：10% で取る） | Trace は「親・子」の関係があるので、各 Span には **Parent ID** がある |\n| **3. Service 内での Span** | User Service はユーザー情報を取得し、Order Service へ転送 → Order Service が注文を作成 → Payment Service へ転送 | サービスごとに **span** を作成し、**Name**、**Start Time**、**End Time**、**Tags/Logs**（重心）を記録 |\n| **4. Span の送信** | 生成した Span を Collector（例：Jaeger Agent）へ送信 | バックエンドへ送るプロトコルは gRPC / HTTP (JSON, Protobuf) |\n| **5. 集計・保存** | Collector が受け取った Span を Storage（例：Elasticsearch, Tempo, backend database）へ保存 | ここで Trace ID ごとに全 Span がまとまる |\n| **6. 可視化** | UI（例：Jaeger UI, Grafana Tempo, OpenTelemetry Collector）で Trace を表示 | ツリー構造やタイムラインで "重い" スパンを色分け |\n\n---\n\n## トレーシングの根幹となるコンセプト \n\n| 用語 | 意味 | 例 |\n|------|------|--------------------------|\n| **Trace** | 1 つの外部からのリクエストを通して、関連する全スパンの集合 | e.g. `GET /orders` |\n| **Span** | 単一の処理単位（DB クエリ、HTTP 呼び出し、計算処理） | e.g. “Execute SQL user.query” |\n| **Context（Trace Context）** | Trace ID, Span ID, Parent ID, Sampling Flag 等を保持した状態 | 送信先へ `X‑B3‑TraceId` ヘッダーで渡す |\n| **Sampler** | どのリクエストをトレースするかを決定 | 固定率サンプリング、サービスレベル指標に合わせたサンプリング |\n| **Exporter** | Span を外部に送る手段 | Jaeger Agent (UDP), OTel Collector (gRPC) |\n\n---\n\n## トレーシングを導入する手順（OpenTelemetry を例に）\n\n1. **Instrumentation の追加** \n ```python\n from opentelemetry import trace\n from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor\n from opentelemetry.instrumentation.requests import RequestsInstrumentor\n\n app = FastAPI()\n FastAPIInstrumentor.instrument_app(app)\n RequestsInstrumentor().instrument()\n ```\n\n2. **TracerProvider の設定** \n ```python\n from opentelemetry.sdk.trace import TracerProvider\n from opentelemetry.sdk.resources import Resource\n\n trace.set_tracer_provider(\n TracerProvider(\n resource=Resource.create({"service.name": "order-service"})\n )\n )\n tracer = trace.get_tracer(__name__)\n ```\n\n3. **Exporter とレイジング設定** \n ```python\n from opentelemetry.exporter.jaeger.thrift import JaegerExporter\n from opentelemetry.sdk.trace.export import BatchSpanProcessor\n\n jaeger_exporter = JaegerExporter(\n agent_host_name="jaeger-agent",\n agent_port=6831,\n )\n span_processor = BatchSpanProcessor(jaeger_exporter)\n trace.get_tracer_provider().add_span_processor(span_processor)\n ```\n\n4. **サンプリング設定**（例：10% だけ取り寄せ） \n ```python\n from opentelemetry.sdk.trace.sampling import TraceIdRatioBased, RandomSampler\n\n sampler = TraceIdRatioBased(0.1) # 10% のリクエストをトレース保存\n trace.set_tracer_provider(\n TracerProvider(sampler=sampler, resource=Resource.create({"service.name":"order-service"}))\n )\n ```\n\n5. **Span でのタグ・ログ** \n ```python\n with tracer.start_as_current_span("order.create"):\n span.set_attribute("order.id", order_id)\n span.set_attribute("customer.id", customer_id)\n # 註: エラーが起きたら set_status で状態を記録\n ```\n\n6. **可視化** \n * Jaeger UI (`http://localhost:16686`) \n * Grafana + Tempo \n * OpenTelemetry\'s own web UI\n\n---\n\n## デバッグ・運用で気を付けるポイント\n\n| 項目 | チェックポイント |\n|------|-------------------|\n| **Propagation** | すべての HTTP/ gRPC 呼び出しでトレースコンテキストを正しく挿入/抽出する。 |\n| **Latency** | 重要なスパンにタイムスタンプを正確に： `start_time`, `end_time` |\n| **Sampling** | サンプリング率が低すぎるとボトルネックが見えにくくなる。 |\n| **Tag 規格** | `db.system`, `http.status_code`, `error` などの標準タグを使うと分析が楽。 |\n| **セキュリティ** | トレース ID だけではサービス内部の機密を漏らさない（CSRF 等）。|\n| **コスト** | スパンの数と保存期間に応じたストレージコスト; 必要な粒度を見極める。 |\n\n---\n\n## まとめ\n\n1. **トレーシングはリクエストを「Trace」「Span」に分解し、サービス間で情報を継承しながら記録** \n2. **Sampler が取捨選択し、Exporter で外部保存** \n3. **可視化ツールで階層・タイムラインを確認し、問題箇所を特定** \n\nこれにより、マイクロサービス環境で「何がどこで遅れたか」「どのサービスが原因か」を即座に確認できるので、運用・デバッグ効率が飛躍的に向上します。ぜひ、上記の手順を参考に実装してみてください。'}]
✅ トレースが記録されました！
右側の「Traces」タブから確認できます
複数ステップのトレーシング
RAG（Retrieval-Augmented Generation）のような複数ステップの処理もトレースできます。
@mlflow.trace(name="retrieve_documents", span_type="RETRIEVER")
def retrieve_documents(query: str) -> list:
"""
ドキュメント検索（モック）
"""
# モックドキュメント
docs = [
"MLflowは機械学習ワークフローを管理するためのオープンソースプラットフォームです。",
"MLflowはトラッキング、プロジェクト、モデル、レジストリのコンポーネントを提供します。",
"トレーシングはLLMアプリケーションのデバッグと最適化に役立ちます。"
]
return docs
@mlflow.trace(name="generate_answer", span_type="LLM")
def generate_answer(query: str, context: list) -> str:
"""
コンテキストを使って回答生成
"""
# コンテキストを使ったプロンプトを作成
context_text = "\n".join(context)
prompt = f"""以下のコンテキストを参考に、質問に答えてください。
コンテキスト:
{context_text}
質問: {query}
回答:"""
# Databricks Foundation Model APIを使用
return call_fmapi(prompt)
@mlflow.trace(name="rag_pipeline", span_type="CHAIN")
def rag_pipeline(query: str) -> dict:
"""
RAGパイプライン全体
"""
# ステップ1: ドキュメント検索
documents = retrieve_documents(query)
# ステップ2: 回答生成
answer = generate_answer(query, documents)
return {
"query": query,
"documents": documents,
"answer": answer
}
# RAGパイプラインを実行
print("=== RAGパイプラインの実行 ===")
result = rag_pipeline("MLflowとは何ですか？")
print(f"質問: {result['query']}")
print(f"回答: {result['answer']}")
print("\n✅ 全ステップがトレースされました！")
print("📊 右側の「Traces」タブから詳細を確認できます")
Part 2: GenAI Evaluationの実践
LLMアプリケーションの品質を評価します。
評価の重要性
LLMの出力は確率的なので、以下を評価する必要があります：
- 正確性（Correctness）: 回答が正しいか
- 関連性（Relevance）: 質問に関連しているか
- 安全性（Safety）: 有害なコンテンツを含まないか
- 幻覚（Groundedness）: 事実と異なる情報を生成していないか
事前構築されたJudge
MLflowは以下の事前構築されたJudgeを提供しています：
-
RelevanceToQuery: 質問への関連性 -
Correctness: 正確性（グラウンドトゥルースとの比較） -
Safety: 安全性（有害コンテンツの検出） -
RetrievalGroundedness: 幻覚の検出 -
Guidelines: ガイドライン準拠
📖 参考リンク：
評価用のデータセットを準備
import pandas as pd
# 評価用のQAデータセット
# mlflow.genai.evaluate()では 'inputs' と 'expectations' カラムが必要
# inputs と expectations はどちらも辞書形式である必要がある
eval_data = pd.DataFrame({
"inputs": [
{"question": "MLflowとは何ですか？"},
{"question": "MLflowのトラッキング機能はどのように動作しますか？"},
{"question": "モデルレジストリとは何ですか？"},
{"question": "MLflowを使ってモデルをデプロイする方法は？"},
{"question": "MLflow Projectsとは何ですか？"}
],
"expectations": [
{"expected_response": "MLflowは機械学習ライフサイクル全体を管理するためのオープンソースプラットフォームです。"},
{"expected_response": "MLflow Trackingを使用すると、MLコードを実行する際にパラメータ、メトリクス、アーティファクトをログできます。"},
{"expected_response": "モデルレジストリは、モデルのバージョンとライフサイクルを管理するための集中型モデルストアです。"},
{"expected_response": "MLflow Modelsは標準フォーマットを使用して、さまざまなプラットフォームにデプロイできます。"},
{"expected_response": "MLflow Projectsは、再利用可能で再現可能な形式でMLコードをパッケージ化します。"}
]
})
print("=== 評価データセット ===")
display(eval_data)
| inputs | expectations |
|---|---|
| {"question":"MLflowとは何ですか？"} | {"expected_response":"MLflowは機械学習ライフサイクル全体を管理するためのオープンソースプラットフォームです。"} |
| {"question":"MLflowのトラッキング機能はどのように動作しますか？"} | {"expected_response":"MLflow Trackingを使用すると、MLコードを実行する際にパラメータ、メトリクス、アーティファクトをログできます。"} |
| {"question":"モデルレジストリとは何ですか？"} | {"expected_response":"モデルレジストリは、モデルのバージョンとライフサイクルを管理するための集中型モデルストアです。"} |
| {"question":"MLflowを使ってモデルをデプロイする方法は？"} | {"expected_response":"MLflow Modelsは標準フォーマットを使用して、さまざまなプラットフォームにデプロイできます。"} |
| {"question":"MLflow Projectsとは何ですか？"} | {"expected_response":"MLflow Projectsは、再利用可能で再現可能な形式でMLコードをパッケージ化します。"} |
モデルの予測を取得
def qa_model(question: str) -> str:
"""
質問応答モデル
"""
# Databricks Foundation Model APIを使用
return call_fmapi(question)
# 予測を生成（テスト用）
eval_data["prediction"] = eval_data["inputs"].apply(lambda x: qa_model(x["question"]))
print("=== 予測結果 ===")
display(eval_data[["inputs", "prediction"]])
| inputs | prediction |
|---|---|
| {"question":"MLflowとは何ですか？"} | [{"summary":[{"text":"The user asks: "MLflowとは何ですか？" which is Japanese: "What is MLflow?" They want explanation of MLflow. Provide concise explanation. Should explain purpose, components (tracking, projects, models, registry). Include use cases. Provide in Japanese. Probably no code needed. Just a description. Ok.","type":"summary_text"}],"text":null,"type":"reasoning"},{"summary":null,"text":"MLflowとは何か？\n\nMLflowは、機械学習（ML）プロジェクトを統一的に管理・再現できるオープンソースのプラットフォームです。※2018年にDatabricksによって公開されて以来、研究や商用環境で広く採用されています。\n\n---\n\n## 主な機能（四つのモジュール）\n\n| モジュール | 役割 | 主な機能 |\n|---|---|---|\n| Tracking | 実験結果の記録 | ハイパーパラメータ、ログ、評価指標、モデルファイルなどを UI で可視化・比較 |\n| Projects | 再現性のある実行環境 | 依存パッケージ、実行コマンドを MLproject ファイルで宣言し、Docker/conda などで実行 |\n| Models | モデルのパッケージ化 | 変数・フォーマット統一（MLflow Models）で、Python、Java、R、Spark など多様なランタイムにデプロイ |\n| Model Registry | モデルバージョニング | モデルの登録、承認、ステージング（staging/production など）、バージョン管理・メタデータ管理 |\n\n---\n\n## 何が解決できるか？\n\n1. 実験の再現性 \n - どのコード、データ、パラメータでどのモデルが生成されたかを完全に追跡。\n\n2. チーム協働 \n - 開発者・データサイエンティスト・運用担当者が同じ UI でプロジェクトを共有。 \n - 実験結果の可視化や比較が瞬時に行える。\n\n3. モデルデプロイの標準化 \n - 1箇所でモデルをパッケージ化し、様々なクラスター・クラウド環境へ簡単にデプロイ。\n\n4. バージョン管理 \n - モデルの異なるバージョンをステージング環境でテストし、問題ないことを確認後に本番にリリース。\n\n---\n\n## 実際の利用イメージ\n\n| フロー | 具体的な操作 | ツール・コマンド |\n|---|---|---|\n| 実験 | モデルをトレーニングし、パラメータと評価指標を記録 | mlflow.log_param(...), mlflow.log_metric(...) |\n| パッケージ化 | 完成したモデルをモデルフォーマットで保存 | mlflow.sklearn.log_model（Python 用） |\n| デプロイ | 足取りしたモデルを推論サービスへ配置 | mlflow models serve（ローカル） / mlflow models build-docker |\n| 管理 | モデルの承認フローを作業 | MLflow UI でステージ変更 / コメント追加 |\n\n---\n\n## まとめ\n\n- MLflow は「実験、パッケージ化、デプロイ、管理」を一つのプラットフォームで実現するフレームワークです。 \n- 主要な機能として Tracking, Projects, Models, Model Registry があり、これらを組み合わせて ML パイプラインを構築・運用します。 \n- オープンソースでありつつ、商用での拡張（MLflow Enterprise）もあり、組織規模を問わず活用できます。 \n\nMLflow を使うことで、モデル開発のスピードと品質を両立させ、機械学習の「実験→デプロイ→運用」までを統一的に管理できるようになります。","type":"text"}] |
| {"question":"MLflowのトラッキング機能はどのように動作しますか？"} | [{"summary":[{"text":"The user: "MLflowのトラッキング機能はどのように動作しますか？" Means: "How does the MLflow tracking functionality work?" They want explanation in Japanese, presumably about MLflow's tracking. Provide technical details: Experiment, Run, Logging metrics, parameters, artifacts, server, client SDK, API, local and remote backend stores, logging via boto3 for AWS, etc.\n\nWe can also mention how mlflow.client, mlflow.tracking, mlflow.set_tracking_uri, server side runs, logging, logging API etc. Provide code examples maybe. Also library functions.\n\nExplain that MLflow uses the concept of Experiment and Run. Tracking is onto a backend store (SQL, file). Artifacts stored in artifact location (file system, S3, GCS). Example of mlflow.start_run().\n\nAlso as of MLflow 2.0, can use mlflow.start_run() from mlflow import log_metric, log_param etc. MLflow supports remote tracking URI via HTTP. The tracking API uses REST.\n\nExplain what the client does, that calls to a tracking server.\n\nList typical workflow: set tracking URI, create experiment, start run, log parameters, metrics, artifacts. When run ends, you can query; call mlflow.search_runs etc.\n\nExplain typical drop-in replacement for other experiment trackers.\n\nAlso detail that mlflow.tracking.MlflowClient can query param futures, etc.\n\nAlso can store runs in local file system.\n\nAlso the default tracking URI uses local file system under .mlruns.\n\nExplain that the mlflow.tracking.client can trigger UI.\n\nAlso that runs can be logged to a remote server and artifacts to cloud.\n\nLet's produce in Japanese.\n\nAlso mention that after logging, you can view via UI.\n\nLet's answer accordingly.","type":"summary_text"}],"text":null,"type":"reasoning"},{"summary":null,"text":"## MLflow Tracking 機能 ― 基本的な仕組みと使い方\n\n### 1. ざっくりとした構成\n\n| 要素 | 説明 |\n|------|------|\n| Experiment | 実験単位。名前で 一連の Run をまとめる。 |\n| Run | 実際に実験を走らせたもの。パラメータ・メトリクス・アーティファクトのスナップショット。 |\n| Tracking Store (backend) | Run のメタ情報 (experiment、run、params、metrics、tags、アーティファクトへの参照) を保存する。ファイルシステム、MySQL、PostgreSQL、ClickHouse 等が選べる。 |\n| Artifact Store (file/remote) | mlflow.log_artifact で保存したファイル・モデルを置く場所。ローカルディスク、S3、GCS、Azure Blob 等。 |\n\n\n[client <- UI] <> [Tracking server] <> [artifact store]\n\n\n- client : mlflow Python API など (Python SDK、CLI、REST API)\n- Tracking Server : MLflow Tracking Server が http でリクエストを受け、バックエンドにデータを保存\n- Artifact Store : バックエンドに記録されたパスを使って blob ストレージから取得\n\n---\n\n### 2. ライフサイクル（典型的なPythonスクリプト）\n\npython\nimport mlflow\nimport mlflow.sklearn\nfrom sklearn.ensemble import RandomForestRegressor\nfrom sklearn.datasets import load_boston\nfrom sklearn.model_selection import train_test_split\n\n# ① トラッキング URI と Experiment を設定\nmlflow.set_tracking_uri(\"http://mlflow-server:5000\") # 任意の Tracking サーバ\nexperiment_name = \"boston_regression\"\nmlflow.set_experiment(experiment_name)\n\n# ② データを用意\nX, y = load_boston(return_X_y=True)\nX_train, X_valid, y_train, y_valid = train_test_split(X, y, test_size=0.2, random_state=42)\n\n# ③ Run を開始\nwith mlflow.start_run() as run:\n # ③-1 モデルを訓練\n model = RandomForestRegressor(n_estimators=200, random_state=0)\n model.fit(X_train, y_train)\n\n # ③-2 パラメータをログ\n mlflow.log_param(\"n_estimators\", 200)\n mlflow.log_param(\"random_state\", 0)\n\n # ③-3 予測ありメトリクスをログ\n preds = model.predict(X_valid)\n mae = mean_absolute_error(y_valid, preds)\n mlflow.log_metric(\"mae\", mae)\n\n # ③-4 モデルを保存（MLflow 形式でアーティファクト）\n mlflow.sklearn.log_model(model, \"model\")\n\n # ③-5 任意のファイルをアーティファクトとして保存\n with open(\"my_log.txt\", \"w\") as f:\n f.write(\"Some log\")\n mlflow.log_artifact(\"my_log.txt\")\n\n# run.id は mlflow UI で確認可能\nprint(\"Run ID:\", run.info.run_id)\n\n\n#### ポイント\n\n- set_tracking_uri \n - デフォルトはローカルディスク (./mlruns)。 \n - HTTP URL を指定すると、Remote Tracking Server に接続。 \n- set_experiment \n - 指定した名前の Experiment が無ければ自動作成。 \n- start_run \n - Run を開始し、current_run がスレッドローカルに保存。 \n - with のブロックが終了すると、mlflow.end_run() が呼ばれる。 \n- log_param, log_metric \n - キー・バリューを直列化して DB に保存。 \n - メトリクスはタイムスタンプ付きなので、同じキーで複数の値をログ可。 \n- log_artifact \n - ファイルを Artifact Store にコピー。 \n - 大量データ・モデルサイズはこれが主な役割。 \n\n---\n\n### 3. 軽い実装詳細\n\n1. クライアント → サーバ (REST) \n txt\n POST /runs/log\n GET /experiments/list\n POST /mlflow/artifacts/upload\n \n - mlflow.tracking.MlflowClient などで実装されている。 \n - mlflow.set_tracking_uri でベース URL を設定し、client が自動で HTTP リクエストを送る。 \n\n2. バックエンドストアへの書き込み \n - デフォルトでは SQLite（mlruns.db）。 \n - --backend-store-uri で postgresql://… 等を渡すと RDBMS が使われる。 \n - checkpointer で高速に書き込みを行う（行単位で insert/update）。 \n\n3. アーティファクトストア \n - --default-artifact-root で指定。 \n - 例えば s3://bucket/mlruns なら、boto3 を介して PUT される。 \n - ローカルファイルなら file:// で、ディレクトリをコピー。 \n\n4. UI \n - mlflow ui (localhost:5000) でブラウザ上で Experiment と Run を確認。 \n - UI は Tracking Server が持つ HTTP API をフロントエンドで呼び、データを描画。 \n\n---\n\n### 4. よくある質問\n\n| 質問 | 回答 |\n|------|------|\n| Run の最大数を制限できますか？ | mlflow.tracking.MlflowClient().set_tag_to_run と mlflow.tracking.MlflowClient().delete_run で古い Run を整理可能。 |\n| 複数プログラミング言語からログできますか？ | はい。Python, Java, R, REST API がサポート。 mlflow.pyfunc で Python‑to‑Java/Beam も可能。 |\n| メトリクスを可視化したい | UI で折れ線グラフ。 mlflow.plots.line や mlflow.visualization でも統計可視化可能。 |\n| 軽量な環境（e.g. Docker）での実行 | mlflow server をコンテナ内で docker run -p 5000:5000 mlflow-server で起動し、--backend-store-uri と --default-artifact-root を指定。 |\n| Run の再トレースや再実行 | mlflow.notebook.autolog() で自動ログ。編成した mlflow.run() から同じ Experiment/Run で再実行可。 |\n\n---\n\n### 5. まとめ\n\n- Tracking は「何をしたか」を追跡・保存する \n - Experiment → Run → Param / Metric / Artifact \n- プログラム側は mlflow.start_run で開始して log_* でデータを送る \n- データは「Backend Store」でメタ情報、Artifact Store にデータが格納 \n- REST API / Python SDK で統一されたインターフェース \n- UI による可視化、検索・統計処理が容易 \n\nこの仕組みにより、チューニングの再現性とチーム間での経験共有が実現できます。ぜひ実際のプロジェクトで「Run」をライブラリのインストールから実行、ログまで追跡してみてください。","type":"text"}] |
| {"question":"モデルレジストリとは何ですか？"} | [{"summary":[{"text":"We need to answer "モデルレジストリとは何ですか？". Likely Japanese question: "What is a model registry?" They want a definition. Should be in Japanese. Provide explanation: a centralized storage for ML models, versioning, metadata, approvals, sharing, etc. Mention MLflow, Azure ML model registry, AWS SageMaker model registry. Ok. Provide details.","type":"summary_text"}],"text":null,"type":"reasoning"},{"summary":null,"text":"## モデルレジストリ（Model Registry）とは？\n\nモデルレジストリは、機械学習（ML）や人工知能（AI）プロジェクトにおいて、作成したモデルを一元管理・追跡するための仕組み・サービスです。 \n以下のような機能や目的が主な特徴です。\n\n| 目的 / 機能 | 説明 |\n|------------|------|\n| バージョン管理 | モデルの推奨バージョンや古いバージョンを追跡し、変更履歴を明確化。Git のように 1.0, 1.1 などで管理できる。 |\n| メタデータの蓄積 | トレーニングデータセット、ハイパーパラメータ、実験スコア、評価指標、作成日時、作者情報などをタグ付け。検索やフィルタリングが容易になる。 |\n| ラベル付け (ステージング) | Candidate → Staging → Production のように、モデルの飛び道具を管理。公開前にレビューやテストが実施しやすい。 |\n| デプロイメント連携 | モデルのデプロイ先（オンプレミス、クラウド、エッジ）を指定し、CI/CD パイプラインと統合。 |\n| アクセス制御 | ユーザーやチームに対して権限を付与し、誰がモデルを閲覧・更新・デプロイできるかを管理。 |\n| 再現性 | 同じバージョンのモデルを再実行できるため、再現実験が保証される。 |\n| 統合 | 既存のデータ料管理, CI/CD, モニタリングツールと連携。 |\n\n### 主な利用ケース\n\n1. 実験の管理 – 同じアイデアを複数回試し、最良のモデルを選定。 \n2. 運用/デプロイ – 本番環境に投入する前にステージングで検証。 \n3. 監査 – バージョン履歴とメタデータから監査ログを生成。 \n4. 協同 – チーム間でモデルを共有し、再利用を促進。\n\n### 代表的なプラットフォーム（日本語ドキュメント例もあります）\n\n| プラットフォーム | 主な特徴 | 日本語公式サイト |\n|------------------|----------|-----------------|\n| MLflow Model Registry | オープンソース。MLflow Trackingと連携し、Gitのような作業フローを実現。 | https://mlflow.org/docs/latest/model-registry.html |\n| Azure Machine Learning Model Registry | Azureに統合。サービスとして提供され、Azure Pipelinesと組み合わせてCI/CDを実現。 | https://learn.microsoft.com/ja-jp/azure/machine-learning/model-registry |\n| AWS SageMaker Model Registry | SageMaker Notebooks, Training と連携。バージョン管理とデプロイメントが可能。 | https://docs.aws.amazon.com/sagemaker/latest/dg/model-registry.html |\n| Databricks Model Registry | Databricks Unified Analytics Platform 上で提供。 | https://docs.databricks.com/applications/mlflow/index.html |\n| Kubeflow Model Registry (KFServing, KF Pipelines) | Kubernetesをベースにしたオープンソース。 | https://www.kubeflow.org/docs/components/model-registry/ |\n\n### 具体的な使用例（MLflowの場合）\n\n1. Experiment Tracking \n python\n import mlflow\n mlflow.start_run()\n mlflow.log_param(\"lr\", 0.01)\n mlflow.log_metric(\"accuracy\", 0.92)\n mlflow.sklearn.log_model(model, \"model\")\n mlflow.end_run()\n \n\n2. Register the Model \n bash\n mlflow models register --model-uri runs:/<run_id>/model --name \"my-model\"\n \n\n3. Transition to Staging/Production \n bash\n mlflow models transition-version --name my-model --version <ver_num> --stage Staging\n \n\n### まとめ\n\n- モデルレジストリは、MLモデルを「作成 → 評価 → 公開 → メンテナンス」の一連のライフサイクルでシステマティックに管理する仕組みです。 \n- バージョン管理、メタデータ管理、ステージング機能、アクセス制御などを提供し、チーム間の協働や運用効率、再現性・監査性を大幅に向上させます。 \n- 上記のように、クラウドプロバイダーやオープンソースソフトウェアがさまざまな実装を提供しているため、プロジェクトの要件に合わせて選択すると良いでしょう。","type":"text"}] |
| {"question":"MLflowを使ってモデルをデプロイする方法は？"} | [{"summary":[{"text":"The user asks: "MLflowを使ってモデルをデプロイする方法は？" – Japanese: "How to deploy a model using MLflow?" We need to answer them. Provide steps in Japanese, include installation, training, logging, artifacts, registration, deployment options: MLflow Models, serving via REST API, Docker, Flask, Kubernetes, cloud, using MLflow's "mlflow models serve" command, using model registry, etc. Provide overview of MLflow's tools: notebooks, tracking, projects, models, registry. Provide sample code. Provide guidance on serving locally and production.\n\nAlso mention prerequisites: Python, MLflow, possibly Docker, Kubernetes, etc. Provide example steps: 1) train and log model, 2) create model package (MLflow Models), 3) register model in Model Registry, 4) serve locally with simple command, 5) Deploy on Docker container, 6) Deploy to cloud, e.g., AWS SageMaker, Azure ML, GCP AI Platform, or use MLflow's integration. The answer can be quite extensive but should be succinct.\n\nWe also might talk about "MLflow Tracking server (like Jupyter Notebook) integrated with a database". Also mention "mlflow run" for deploying a project. Also mention "mlflow model build-package".\n\nWe can include code snippets: training script with mlflow.log_metric, mlflow.log_params, mlflow.sklearn.log_model, then packaging with mlflow models serve etc.\n\nAdditionally, user may ask specifically "how to deploy a model with MLflow" – we can give a step-by-step guide: (1) Install mlflow, (2) Train model, (3) Log using mlflow.log_model, (4) Register into Model Registry, (5) Serve locally via mlflow models serve -m mlruns/..., (6) Deploy to cloud (Docker/K8s). Provide word about authentication, scaling.\n\nMake sure not to use "Japanese" more than needed.\n\nWe should answer in Japanese. So produce in Japanese. Also use bullet points.\n\nWrap up with resources: MLflow official docs.","type":"summary_text"}],"text":null,"type":"reasoning"},{"summary":null,"text":"MLflow を使ったモデルのデプロイ手順（日本語） \n以下では、MLflow の主要コンポーネント（Tracking / Projects / Models / Model Registry）を利用して、モデルを学習・保存・デプロイまで一連の流れを説明します。 \n\n---\n\n### 1. 開発環境を準備する \nbash\n# ① 仮想環境作成（任意）\npython -m venv ml-env\nsource ml-env/bin/activate # Windows は ml-env\\Scripts\\activate\n\n# ② MLflow のインストール\npip install mlflow\n\n\n> Tip \n> ‑ ローカルで試す際は mlflow ui がトラッキングサーバとして起動します。 \n> ‑ 大規模環境では PostgreSQL 等の外部 DB を使うとログが永続化します。 \n\nbash\n# Tracking 用 UI を起動\nmlflow ui\n# ポート 5000 でアクセス: http://127.0.0.1:5000\n\n\n---\n\n### 2. モデルを学習し、MLflow にログする \npython\n# train.py\nimport mlflow\nimport mlflow.sklearn\nfrom sklearn.ensemble import RandomForestRegressor\nfrom sklearn.datasets import load_boston\nfrom sklearn.model_selection import train_test_split\n\ndef main():\n mlflow.set_experiment(\"BostonHousing\")\n\n X, y = load_boston(return_X_y=True)\n X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)\n\n with mlflow.start_run():\n # ==== ハイパーパラメータ\n n_estimators = 100\n mlflow.log_param(\"n_estimators\", n_estimators)\n\n # ==== 学習\n model = RandomForestRegressor(n_estimators=n_estimators, random_state=42)\n model.fit(X_train, y_train)\n\n # ==== 評価\n predictions = model.predict(X_test)\n rmse = ((predictions - y_test) ** 2).mean() ** 0.5\n mlflow.log_metric(\"rmse\", rmse)\n\n # ==== モデルの保存\n mlflow.sklearn.log_model(model, \"model\")\n\nif __name__ == \"__main__\":\n main()\n\n\nbash\n# TRAIN\npython train.py\n\n\n> これで mlruns ディレクトリに実行結果と model フォルダが保存されます。 \n> mlflow UI でパラメータ／メトリクス・モデルを確認できます。 \n\n---\n\n### 3. モデルを保存・登録（Model Registry） \n#### 3‑1. モデルアーティファクトをエクスポート \nbash\n# ローカルに保存したファイルを使ってモデルを登録\nmlflow models list-registered-models\n\n\n> Note \n> Registry を使うと複数バージョンを管理でき、ステージング／プロダクションを切り替えられます。 \n\n#### 3‑2. Registry に登録 \nbash\nmlflow models register \\\n -m runs:/<run_id>/model \\\n -n BostonHousingRegressor\n\n\n> 登録後、model を参照すると BostonHousingRegressor になるので、バージョン管理が可能です。 \n\n---\n\n### 4. モデルをローカルで「Serve」 \nbash\n# 1. モデルの場所を指定して REST API を立ち上げる\n# <run_id> を取得済みか、または Registry 名を指定\nmlflow models serve \\\n -m runs:/<run_id>/model \\\n -p 1234\n\n\n> http://127.0.0.1:1234/invocations へ JSON で入力を POST すれば推論できる。 \n> 例 \n> bash\n> curl -X POST -H \"Content-Type: application/json\" \\\n> -d '{\"columns\": [\"crim\",\"zn\",...], \"data\": [[0.1, 0.2, ...]]}' \\\n> http://127.0.0.1:1234/invocations\n> \n\n#### 4‑1. 参照モデル名で Serve（Model Registry から取得） \nbash\nmlflow models serve \\\n -m models:/BostonHousingRegressor/Production \\\n -p 1234\n\n\n> ModelRegistry で Production ステージに設定したバージョンが使われます。 \n\n---\n\n### 5. Docker でパッケージ化してデプロイ \n#### 5‑1. Dockerfile 作成 \ndockerfile\n# ベースイメージは python:3.9\nFROM python:3.9-slim\n\n# 作業ディレクトリ\nWORKDIR /app\n\n# 必要なパッケージをインストール\nRUN pip install mlflow scikit-learn\n\n# ワークロードをコピー\nCOPY ./train.py .\n\n# エントリポイントとして mlflow serve を使う\nENTRYPOINT [\"mlflow\", \"models\", \"serve\",\n \"-m\", \"mlruns/0/<run_id>/model\",\n \"-p\", \"1234\",\n \"--host\", \"0.0.0.0\"]\n\n\n#### 5‑2. Docker イメージビルド・実行 \nbash\ndocker build -t mlflow-regressor .\ndocker run -p 1234:1234 mlflow-regressor\n\n\n> クラウド（ECR, GCR, Docker Hub など）へ Push し、ECS/EKS、Kubernetes の Pod としてデプロイ。 \n\n---\n\n### 6. クラウドノード/マネージドサービスへデプロイ \n| プラットフォーム | 方法 | コマンド / 重要ポイント | \n|------------------|------|---------------------------|\n| AWS SageMaker | mlflow.sagemaker API でデプロイ | mlflow.sagemaker.deploy( model_uri=\"models:/BostonHousingRegressor/Production\" ) |\n| Azure ML | mlflow.azureml API | mlflow.azureml.deploy() |\n| Google Cloud AI Platform | mlflow gcpmlengine | mlflow gcpmlengine deploy() |\n| Kubeflow | kubeflow-argo + mlflow-model-serve コンテナ | Kubernetes 用 Helm Chart |\n\n> それぞれ、サービスの認証情報を事前に取得し、mlflow を設定します。 \n\n---\n\n### 7. モデルの管理・更新フローまとめ \n\n| ステップ | 内容 | コマンド例 |\n|-----------|------|------------|\n| ① 学習 & ログ | mlflow.sklearn.log_model() で runs に保存 | python train.py |\n| ② モデル登録 | mlflow models register で Model Registry に登録 | mlflow models register -m runs:/<run_id>/model -n MyModel |\n| ③ ステージ変更 | UI / CLI (mlflow models transition-stage) で Staging/Production | mlflow models transition-stage -m models:/MyModel/1 -s Production |\n| ④ デプロイ | mlflow models serve でローカル／Docker／K8s へ | mlflow models serve -m models:/MyModel/Production -p 1234 |\n| ⑤ モニタリング | mlflow ui または外部ログ / APM (Prometheus, Datadog) を連携 | mlflow ui |\n\n---\n\n## 重要なポイント & ベストプラクティス\n\n1. Model Registry を必ず使う \n * バージョン管理とステージングを統一的に管理できます \n * ステージが Production のバージョンだけをサーブするように IAM で制御できる \n\n2. モデルを「実行ファイル」化する \n * mlflow models build-package で MLflow Models パッケージを作成し、 \n --conda-env で依存環境を生成。 \n * これを Docker イメージにインストールすると再現性が向上 \n\n3. ワークフローを CI/CD に組み込む \n * GitHub Actions / GitLab CI で \n - MLflow の mlflow run で再学習・再デプロイ \n - docker buildx でビルド \n - kubectl でデプロイ \n\n4. 監視とロギング \n * mlflow ui でメトリクスを可視化 \n * model_prediction_latency などのカスタムメトリクスを自動ログ \n * Prometheus + Grafana で external metrics として取り込むと、Auto‑Scaling が容易 \n\n5. セキュリティ \n * MLflow server を HTTPS + Basic / OAuth で保護 \n * API Gateway（API Manager）で認可/レートリミット \n\n---\n\n## 参照リンク\n\n* MLflow Docs – Model Registry \n* MLflow Docs – Deploying With Docker \n* MLflow Docs – Cloud Deployment \n* MLflow Docs – MLflow Projects \n* 公式 GitHub サンプルリポジトリ: https://github.com/mlflow/mlflow \n\n---\n\nまとめ \n1. 学習 → mlflow.log_* でログ \n2. mlflow models register で Model Registry に登録 \n3. mlflow models serve（ローカルまたは Docker）で REST API を起動 \n4. 必要に応じて Kubernetes / Cloud にデプロイ \n5. ステージングで検証→Production へ Promotion でデプロイ \n\nこうすることで、学習から運用までを MLflow を中心に統一的に管理できます。ぜひ取り入れてみてください！","type":"text"}] |
| {"question":"MLflow Projectsとは何ですか？"} | [{"summary":[{"text":"The user asks: "MLflow Projectsとは何ですか？" This is Japanese: "What is MLflow Projects?". The user likely expects an explanation of MLflow Projects, perhaps in Japanese. So I should provide a concise explanation of MLflow Projects - what they're, how they help reproducible workflows, the MLproject file, environment, dependencies, command line interface, integration with main MLflow components. Also likely mention that it's for packaging code and dependencies, the specification of the project, environment file, how to execute with mlflow run. The user didn't specify a specific language; the question is in Japanese. Let's answer in Japanese.\n\nWe should explain:\n\n- MLflow Projects: a way to package code with reproducibility\n- .mlproject file\n- Environment specification via conda, pip, docker, etc\n- The mlflow run command\n- Arguments, parameters\n- Target callable\n- Integration with experiments and runs\n- Example usage, simple example of MLproject file\n- Additional features like support for specifying base image, dependencies, arguments.\n\nAlso mention differences between Projects and Experiments / Models, to clarify.\n\nPossible to go into details:\n\n- YAML syntax\n- Local, Git, conda/pip envs\n- How to call\n- Example workflow\n- Why use it\n\nThus we respond in Japanese. We'll keep it concise but thorough.","type":"summary_text"}],"text":null,"type":"reasoning"},{"summary":null,"text":"## MLflow Projects とは？\n\nMLflow Projects は 再現性の高い機械学習ワークフローを「パッケージ化」 するための仕様・ツールです。 \n「モデルを学習させるコード」「依存関係」「入力パラメータ」の全てをひとまとめにして、 \n異なる環境やチーム間で簡単に実行・共有できるようにします。\n\n---\n\n### 1. 何をパッケージ化するか\n\n| 内容 | 具体例 |\n|------|--------|\n| 実行可能なコード | Pythonスクリプト、Jupyter Notebook、Makefileなど |\n| 実行環境 | Conda/virtualenv、Dockerイメージ、Pipenv など |\n| パラメータ | 学習率、ハイパーパラメータ、データパスなど |\n| 実行結果 | MNISTの精度、ROC曲線の図、学習済みモデル等 |\n\n---\n\n### 2. MLproject ファイル（YAML）\n\nMLflow Projects の根幹は MLproject という YAML ファイルです。 \nファイル名は MLproject（大文字のM〜）で、プロジェクトのメタ情報を書きます。\n\nyaml\nname: sample_mnist\n\nconda_env: conda.yaml # Conda 環境ファイル\ndocker_env: environment.yml # もしくは Dockerfile も可\n\nentry_points:\n main:\n parameters:\n epochs: {type: int, default: 10}\n lr: {type: float, default: 0.01}\n command: \"python train.py --epochs {epochs} --lr {lr}\"\n\n\n- name : プロジェクト名\n- conda_env / docker_env : 依存関係を解決するための環境定義\n- entry_points : 実行可能なエントリ。main はデフォルトのエントリ\n - parameters : コマンドライン引数（型・デフォルト値を指定）\n - command : 実際に呼び出すシェルコマンド\n\n---\n\n### 3. 依存環境の定義\n\n| 方法 | 内容 |\n|-----|------|\n| Conda | conda.yaml (dependencies: - python=3.8 ...) |\n| Pip | requirements.txt（pip: セクション） |\n| Docker | Dockerfile を docker_env に指定 |\n\nMLflow は mlflow run を実行すると、自動で環境を作成してくれます。\n\n---\n\n### 4. 実行\n\nbash\n# ローカルディレクトリ（ランダムレポジトリ名）\nmlflow run .\n\n# Git リポジトリ\nmlflow run https://github.com/your-org/your-project\n\n# Git タグ／ブランチ\nmlflow run -e v1.0 https://github.com/your-org/your-project\n\n# パラメータ指定\nmlflow run . -P epochs=20 -P lr=0.001\n\n\n実行すると：\n\n1. 環境構築（Conda／Docker）\n2. パラメータ挿入 ({epochs}, {lr})\n3. コマンド実行（python train.py ...）\n4. メタデータ（パラメータ、ログ、出力）が自動で MLflow UI に保存\n\n---\n\n### 5. MLflow Ecosystem との連携\n\n| 機能 | 役割 |\n|------|------|\n| MLflow Tracking | すべての実行ログ・パラメータ・メトリクスを記録 |\n| MLflow Models | 学習済みモデルを Project 化して再利用 |\n| MLflow Registry | バージョン管理、ステータス（Staging, Production）管理 |\n\n- mlflow run で実行した情報はすべて Tracking に保存されるので、セルフドキュメント な形で再現できます。\n- Project は mlflow run だけでなく mlflow artifacts や mlflow models と連携して、モデルのデプロイ時にも利用されます。\n\n---\n\n### 6. 実際のユースケース\n\n| ケース | 使い方 |\n|--------|--------|\n| チームで同じ実験を再現 | 同じ MLproject を共有 → mlflow run で全員同じ環境・パラメータで走らせる |\n| CI/CD での自動実行 | GitHub Actions から mlflow run → 失敗するとスクリプトが失敗。 |\n| プロダクションデプロイ前の検証 | 本番前に mlflow run で同じ環境を再現 → 結果を比較 |\n\n---\n\n### 7. まとめ\n\n- MLflow Projects は「コード + 依存関係 + パラメータ」をひとつにまとめ、 \n mlflow run コマンドでどこでも再現性高く実行できる仕組み。\n- YAML の MLproject ファイルにエントリポイントと環境を宣言し、 \n Conda・Docker・Pip の選択肢から自動で環境を構築。\n- 実行情報は MLflow Tracking に保存され、メトリクス、ログ、実行結果を簡単に管理・共有できる。\n\nこれにより、機械学習パイプラインの再現性と可搬性が格段に向上します。","type":"text"}] |
事前構築されたJudgeを使った評価
MLflowの事前構築されたJudge（評価者）を使います。
from mlflow.genai.scorers import RelevanceToQuery, Correctness, Safety, RetrievalGroundedness, Guidelines
# 評価用のpredict関数を作成
# predict_fnの引数名は、inputsカラムの辞書のキーと一致する必要がある
def predict_fn(question):
"""
評価用のpredict関数
question: 質問文（文字列）
returns: 予測結果（文字列）
"""
return qa_model(question)
# Guidelines Judge（ガイドライン準拠）の作成
guidelines = Guidelines(
guidelines="""
良い回答の基準:
1. 簡潔で分かりやすい（50-300文字）
2. 専門用語を適切に使用
3. 具体的な説明を含む
"""
)
# 評価の実行
with mlflow.start_run(run_name="QA Model Evaluation with All Judges"):
# すべての事前構築されたJudge（評価者）を定義
judges = [
RelevanceToQuery(), # 質問への関連性
Correctness(), # 正確性（グラウンドトゥルースと比較）
Safety(), # 安全性（有害コンテンツの検出）
RetrievalGroundedness(), # 幻覚の検出
guidelines # ガイドライン準拠
]
print("=== 使用するJudges ===")
print("1. RelevanceToQuery: 質問への関連性")
print("2. Correctness: 正確性（グラウンドトゥルースとの比較）")
print("3. Safety: 安全性（有害コンテンツの検出）")
print("4. RetrievalGroundedness: 幻覚の検出")
print("5. Guidelines: カスタムガイドライン準拠")
print()
# mlflow.genai.evaluateで評価
eval_results = mlflow.genai.evaluate(
data=eval_data,
predict_fn=predict_fn,
scorers=judges
)
print("=== 評価結果 ===")
print(f"\n評価スコア:")
for metric_name, metric_value in eval_results.metrics.items():
print(f" {metric_name}: {metric_value:.3f}")
print("\n✅ すべてのJudgeによる評価が完了しました！")
print("📊 詳細な評価結果は右側の「Experiments」タブから確認できます")
2025/11/05 11:43:53 INFO mlflow.models.evaluation.utils.trace: Auto tracing is temporarily enabled during the model evaluation for computing some metrics and debugging. To disable tracing, call `mlflow.autolog(disable=True)`.
2025/11/05 11:43:53 INFO mlflow.genai.utils.data_validation: Testing model prediction with the first sample in the dataset.
=== 使用するJudges ===
1. RelevanceToQuery: 質問への関連性
2. Correctness: 正確性（グラウンドトゥルースとの比較）
3. Safety: 安全性（有害コンテンツの検出）
4. RetrievalGroundedness: 幻覚の検出
5. Guidelines: カスタムガイドライン準拠
Part 3: モデルのロギングとデプロイ
評価が完了したら、次はモデルをデプロイして本番環境で利用します。
デプロイの流れ
-
LoggedModelとしてロギング: RAGパイプラインを
mlflow.pyfunc.PythonModelとしてラップ -
Unity Catalogに登録:
mlflow.register_model()でUnity Catalogに登録 -
サービングエンドポイントにデプロイ:
databricks.agents.deploy()でデプロイ - エンドポイントのテスト: デプロイされたエンドポイントを呼び出してテスト
実装の詳細
Part 3とPart 4の詳細な実装については、以下の記事を参照してください：
📖 MLflow3とDatabricksで実現するLLMops
この記事では、以下の内容を詳しく解説しています：
- LoggedModelの実装方法
- Unity Catalogへの登録
- agents.deployを使ったデプロイ
- 本番環境でのモニタリング設定
- Scorerの登録とアクティブ化
- サンプリング設定とバックフィル
その他の参考リンク：
Part 4: 本番環境モニタリング
評価したモデルをデプロイした後は、本番環境で継続的にモニタリングします。
本番環境モニタリングとは
サービングエンドポイントが受け取るリクエストは自動的にトレースされます。これらのトレースに対して、登録されたScorerがバックグラウンドで自動評価を実行します。
主要な機能
-
Scorerの登録とアクティブ化
-
.register(): Scorerを登録 -
.start(): サンプリング設定でアクティブ化
-
-
サンプリング設定
-
sample_rate=1.0: 全トレースを評価（重要な指標） -
sample_rate=0.1: 10%のみ評価（コスト削減）
-
-
バックフィル
- 過去のトレースに遡及的に評価を適用
-
Scorerのライフサイクル
- 未登録 → 登録済み → アクティブ ↔ 停止 → 削除済み
ベストプラクティス
-
適切なサンプリングレート
- 安全性・セキュリティチェック:
sample_rate=1.0（全トレース） - コストの高い評価:
sample_rate=0.05～0.2（5-20%） - 一般的な品質指標:
sample_rate=0.5（50%）
- 安全性・セキュリティチェック:
-
Scorer数の管理
- エクスペリメントあたり最大20個のScorerまで
- 本当に必要な評価に絞る
-
処理時間の考慮
- 初回スコアリング: 15-20分程度かかる
- その後は新しいトレースに自動適用される
実装の詳細
本番環境モニタリングの詳細な実装については、以下の記事を参照してください：
📖 MLflow3とDatabricksで実現するLLMops
その他の参考リンク：
まとめ：生成AIトレーシング & 評価
✅ Part 1: トレーシング
-
@mlflow.traceデコレータで自動トレーシング -
span_typeパラメータで適切なアイコン表示 - RAGパイプラインなど複数ステップの可視化
- デバッグとパフォーマンス最適化が容易
✅ Part 2: 評価（Evaluation）
- 5つの事前構築されたJudgeで品質測定
- RelevanceToQuery（関連性）
- Correctness（正確性）
- Safety（安全性）
- RetrievalGroundedness（幻覚の検出）
- Guidelines（ガイドライン準拠）
-
mlflow.genai.evaluate()で一括評価
📚 Part 3 & 4: 全体のライフサイクル
Part 3（モデルのロギングとデプロイ）とPart 4（本番環境モニタリング）の詳細な実装については、以下の記事を参照してください：
📖 MLflow3とDatabricksで実現するLLMops
この記事では以下の内容を実装付きで詳しく解説しています：
- LoggedModelの実装方法
- Unity Catalogへの登録
- agents.deployを使ったデプロイ
- Scorerの登録とアクティブ化
- サンプリング設定とバックフィル
- 本番環境での継続的モニタリング
次のステップ
- Qiita記事で全体のライフサイクルを学ぶ
- 実際のデプロイを試す: agents.deployで本番環境にデプロイ
- より高度な評価: カスタムScorerの作成
- A/Bテスト: 複数のモデルバージョンを比較
📖 参考リンク：
補足：よくある質問
Q1: トレーシングはコストがかかる？
A: トレーシング自体のオーバーヘッドは最小限です。LLM呼び出しのコストが主な部分です。
Q2: 本番環境でトレーシングを無効化すべき？
A: サンプリング（一部のリクエストのみトレース）を使えば、本番でも有効にできます。
Q3: 複数のLLMプロバイダーに対応している？
A: はい！OpenAI、Anthropic、HuggingFace、Azure OpenAIなど多数対応しています。
Q4: デプロイやモニタリングの実装方法は？
A: 以下のQiita記事で実装付きで詳しく解説しています：
Q5: もっと詳しく学ぶには？
A: 以下の公式ドキュメントを参照してください：