前言：LLM 應用開發的現實困境

當你第一次看到 LLM 應用的程式碼時，可能會覺得「就這麼簡單？」——呼叫 API、傳入 prompt、拿到回應。但當這段程式碼進入生產環境後，噩夢才真正開始：

• 使用者回報「AI 回答怪怪的」，但你完全不知道當時的 prompt 長什麼樣
• 上週運作正常的功能，這週突然品質下降，卻無從追查原因
• 團隊成員各自修改 prompt，沒人知道哪個版本效果最好
• 想評估 AI 回答品質，只能靠人工一筆一筆檢查

這些就是 LLM 應用的「黑盒問題」——你無法觀測、無法追溯、無法系統性評估。

MLflow GenAI 正是為了解決這些問題而生。

MLflow GenAI 是什麼？

MLflow GenAI 是 MLflow 針對生成式 AI 應用推出的專用模組，提供從開發到生產的完整生命週期管理。與傳統的 ML 實驗追蹤不同，它專注於解決 LLM 應用特有的挑戰：

MLflow GenAI 建構在三大核心功能之上：Tracing（可觀測性）、Logging（版本管理）、Evaluation（品質評估）。

核心功能一：Tracing（可觀測性）

問題情境

假設你的 LLM 應用串接了 RAG（檢索增強生成），流程是：

使用者問題 -> 向量檢索 -> 組合 prompt -> LLM 呼叫 -> 回應

當回答品質不佳時，問題可能出在任何一個環節：

• 檢索到的文件不相關？
• prompt 組合方式有問題？
• LLM 本身幻覺？

沒有 tracing，你只能盲目猜測。

Tracing 如何解決

MLflow Tracing 會捕捉完整的執行鏈路，記錄每個步驟的：

• 輸入與輸出：每個函式接收什麼、回傳什麼
• 執行時間：哪個步驟最耗時
• Token 使用量：成本分佈在哪裡
• 中繼資料：模型版本、溫度參數等配置

程式碼範例

import mlflow

# 啟用自動追蹤（支援 OpenAI、LangChain 等 30+ 框架）
mlflow.openai.autolog()

# 你的程式碼完全不需要修改
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "什麼是 MLflow？"}]
)

# MLflow 自動記錄：
# - 完整的 prompt 內容
# - 回應內容
# - token 數量（input/output）
# - 延遲時間
Code language: PHP (php)

這就是 MLflow 強調的「一行程式碼啟用追蹤」——透過 autolog() 自動攔截框架的 API 呼叫。

在 UI 中看到什麼

在 MLflow UI 中，你可以看到類似這樣的追蹤結果：

[Trace] user_query_handler (總耗時: 2.3s)
  |
  +-- [Span] vector_search (0.3s)
  |     inputs: {"query": "什麼是 MLflow？"}
  |     outputs: {"documents": [...], "scores": [0.92, 0.87]}
  |
  +-- [Span] prompt_assembly (0.01s)
  |     inputs: {"template": "...", "context": "..."}
  |     outputs: {"final_prompt": "..."}
  |
  +-- [Span] llm_call (2.0s)
        inputs: {"model": "gpt-4", "messages": [...]}
        outputs: {"response": "MLflow 是一個..."}
        metadata: {"tokens": {"input": 150, "output": 200}}
Code language: JavaScript (javascript)

一眼就能看出：LLM 呼叫佔了 87% 的時間，而檢索結果的相關性分數都很高，所以問題可能出在 prompt 組合或 LLM 本身。

OpenTelemetry 相容性

MLflow Tracing 完全相容 OpenTelemetry 標準，這意味著：

• 可以匯出到 Jaeger、Zipkin、Datadog 等現有監控系統
• 可以與後端服務的 traces 串接，形成端對端追蹤
• 沒有供應商鎖定，隨時可以遷移

# 匯出到 OpenTelemetry Collector
import os
os.environ["OTEL_EXPORTER_OTLP_ENDPOINT"] = "http://collector:4317"
Code language: PHP (php)

核心功能二：Logging（版本管理）

問題情境

你的團隊有三個人同時在調整 prompt：

• Alice 覺得加上「請用繁體中文回答」效果更好
• Bob 認為應該在 system prompt 強調「簡潔回答」
• Carol 想嘗試新的 few-shot 範例

一週後，生產環境的 prompt 已經面目全非，沒人記得原本長什麼樣，也不知道哪次修改造成了品質下降。

Prompt Registry 如何解決

MLflow Prompt Registry 提供類似 Git 的版本控制：

import mlflow

# 註冊一個 prompt 模板
mlflow.genai.register_prompt(
    name="customer-support",
    template="""你是一個客服助理。

使用者問題：{{question}}
相關文件：{{context}}

請根據文件內容回答問題。如果文件中沒有相關資訊，請誠實說明。""",
    commit_message="初始版本：基本客服模板"
)
Code language: PHP (php)

每次修改都會產生新版本，且舊版本永遠不會被覆蓋（immutable）：

customer-support
  |- v1: 初始版本（2024-01-15）
  |- v2: 新增繁體中文要求（2024-01-16）
  |- v3: 調整語氣更友善（2024-01-18）

Alias 機制

實務上，你不會想在程式碼中寫死 v3。MLflow 提供 alias（別名）機制：

# 設定 production alias 指向 v2
# 設定 staging alias 指向 v3

# 程式碼中使用 alias
prompt = mlflow.genai.load_prompt("prompts:/customer-support@production")
Code language: PHP (php)

當 v3 測試通過後，只需要把 production alias 指向 v3，不需要改任何程式碼。

LoggedModel：完整應用版本

除了 prompt，MLflow 的 LoggedModel 可以追蹤整個應用的狀態：

• Git commit hash
• 所有 prompt 版本
• 模型配置（temperature、max_tokens 等）
• 相依套件版本

with mlflow.start_run():
    mlflow.set_active_model(name="customer-support-bot")

    # 所有後續的 traces 都會關聯到這個版本
    response = process_user_query(question)
Code language: PHP (php)

當問題發生時，你可以精確知道「2024-01-18 15:30 的那個異常回應，用的是哪個版本的程式碼和 prompt」。

核心功能三：Evaluation（品質評估）

問題情境

你修改了 prompt，覺得效果變好了。但「覺得」不夠客觀——怎麼證明？

傳統做法是人工評估：準備 100 個測試問題，請人逐一判斷回答品質。這不僅耗時，還有主觀偏差。

LLM-as-a-Judge 如何解決

MLflow 採用「用 LLM 評估 LLM」的方法，稱為 LLM-as-a-Judge：

import mlflow

# 定義評估資料集
eval_data = [
    {"question": "如何重設密碼？", "expected": "請至設定頁面..."},
    {"question": "退款需要幾天？", "expected": "一般需要 3-5 個工作天..."},
]

# 執行評估
results = mlflow.genai.evaluate(
    data=eval_data,
    predict_fn=my_chatbot,
    scorers=[
        mlflow.genai.scorers.Correctness(),      # 回答是否正確
        mlflow.genai.scorers.Relevance(),        # 回答是否相關
        mlflow.genai.scorers.Guidelines(         # 自訂評估標準
            guidelines="回答必須使用繁體中文，語氣友善專業"
        ),
    ]
)
Code language: PHP (php)

內建 Scorers

MLflow 提供多種內建評估器：

評估結果解讀

評估結果摘要：
- 正確性：85% (85/100 通過)
- 相關性：92% (92/100 通過)
- 準則符合度：78% (78/100 通過)

失敗案例分析：
- Q: "如何取消訂閱？"
- A: "請聯繫客服處理。"
- 評估：準則不符合 - 回答過於簡短，未提供具體步驟
Code language: JavaScript (javascript)

與 Tracing 整合

評估結果會自動關聯到對應的 traces，讓你可以：

1. 找出所有「幻覺」分數低的回應
2. 檢視這些回應的完整執行鏈路
3. 分析是哪個環節出了問題

MLflow GenAI vs 傳統 MLflow：差異比較

簡單來說：傳統 MLflow 關注「如何訓練出好模型」，MLflow GenAI 關注「如何用好模型建構好應用」。

何時該使用 MLflow GenAI？

適合使用的情境

• 你正在開發 LLM 應用（聊天機器人、RAG 系統、AI Agent）
• 團隊多人協作，需要版本控制 prompt
• 應用已上線，需要監控品質和除錯
• 想要系統性評估 prompt 修改的效果
• 偏好開源方案，避免供應商鎖定

可能不需要的情境

• 只是簡單的一次性 API 呼叫
• 尚在 POC 階段，還沒確定架構
• 已有成熟的內部監控系統

框架整合支援

MLflow GenAI 支援 30+ 框架的自動追蹤：

LLM Provider

• OpenAI
• Anthropic (Claude)
• Google Gemini
• AWS Bedrock

Application Framework

• LangChain / LangGraph
• LlamaIndex
• DSPy
• Pydantic AI
• AutoGen / AG2

TypeScript 生態系

• Vercel AI SDK
• LangChain.js
• Mastra

只需一行 mlflow.xxx.autolog() 即可啟用。

小結

本文介紹了 MLflow GenAI 的三大核心功能：

1. Tracing：捕捉完整執行鏈路，解決「黑盒」問題
2. Logging：版本化管理 prompt 和應用配置
3. Evaluation：LLM-as-a-Judge 自動化品質評估

這三個功能相互配合：Tracing 產生資料，Logging 追蹤版本，Evaluation 評估品質。形成一個完整的 LLM 應用可觀測性解決方案。

下一篇文章，我們將實際動手安裝 MLflow，並使用 Tracing 功能追蹤第一個 LLM 呼叫。

延伸閱讀

• MLflow GenAI 官方文件
• MLflow Tracing 文件
• MLflow Evaluation 文件
• MLflow Prompt Registry