利用 MLflow 构建 AI 评估与可观测性：从开发到生产
发布你的第一个 AI Agent 或 LLM 应用时，你会感到非常有成就感，直到你需要因为应用未达到预期效果而进行修改。我们大多数人都是以同样的方式开始的：测试几个提示词（prompt），看结果似乎合理，凭“感觉”检查一下（vibe-check），然后就继续下去了。
但随后，隐性的故障和质量问题便接踵而至。你为了改善某一个行为而微调提示词，却导致另外三个行为变差了。你无法判断最新的更新到底是进步了，退步了，还是仅仅是在盲目猜测。
在某个阶段，你必须摒弃这种“感觉检查”，转向结构化的方法。如果没有一种结构化的方式来衡量正在发生的事情，你只能祈求一切顺利。
这篇文章旨在完成这一转变：采用结构化、系统化的方法来评估你的 AI 应用。我们将探讨如何整合 MLflow 的四大支柱：追踪 (Tracing)、评估与人类反馈 (Evaluation and Human Feedback)、提示词版本控制 (Prompt Versioning) 以及 AI 治理 (AI Governance)。作为“评估驱动的开发周期”这一系统方法的一部分，我们将重点关注那些真正至关重要的环节。
图 1. MLflow 开源 AI 平台的四大支柱
为什么 Agent 的故障方式不同：AI 可观测性的必要性
作为软件工程师，我们知道如何交付可靠的软件。你编写代码、运行单元测试、通过 QA、部署到生产环境，并设置遥测系统，以便在出现故障时报警。我们对这套“剧本”很熟悉，因为它已经存在了几十年，并且之所以有效，是因为系统输出是确定性的：同样的输入，每次都会产生同样的输出。
相比之下，Agent 不遵循这套剧本，原因有几点。首先，它们的输出是自由形式的自然语言，通常不可预测，且质量的主观性使得传统的测试断言无法捕捉。其次，一个用户觉得有用的 Agent 回应，在另一个用户看来可能是冗长或离题的，而编写 Agent 的开发者可能并不具备判断这种差异的领域专业知识。这种差异导致了第三个原因，即给质量评估引入了主观性和风险，需要与领域专家进行跨职能的协作。
最后，你在每次 Agent 工作流调用时，都要在成本、延迟和质量之间进行权衡。没有检测工具，你就没有任何数据来指导你。
如果没有结构化的流程和像 MLflow 这样的开发平台来提供必要的严谨性，工作流看起来就像这样：编写 Agent，在本地运行几个提示词，部署到生产环境，然后祈求一切顺利。这不是个好主意！
AI 可观测性是你开展其他工作前所需的基石。如果你无法看到 Agent 在每一步的操作，就无法监控、调试和提升其质量。追踪功能为你提供了这种可见性，并将对话从“我觉得 Agent 可以工作”（猜测）转变为“这就是请求中发生的确切情况”（衡量）。
评估驱动开发：塑造 MLflow 评估策略的三个阶段
发布可靠 Agent 的团队并没有什么魔法。他们遵循一套以 MLflow AI 平台为核心的指令式周期：评估驱动开发。可以将其视为三个阶段，每个阶段都建立在前一个阶段的基础上，不断收紧“发生了什么”与“是否足够好”之间的反馈循环。
阶段 1：通过追踪进行原型设计
从第一天起就开始对你的 Agent 进行检测。MLflow 的单行自动记录（autolog）功能可以将每一次 LLM 调用、工具调用和检索步骤捕捉为结构化的追踪数据，并附带延迟、Token 使用量和成本数据。通过一行代码，你可以为任何 MLflow 集成的库启用 LLM 追踪：mlflow.library_name.autolog()。例如，对于 OpenAI，这将捕捉所有输入/输出、Token 使用量、成本和延迟。
import mlflow
# Enable automatic tracing for OpenAI calls with a single line
mlflow.openai.autolog()
对工具使用进行手动追踪可以捕捉自动记录可能遗漏的操作。例如，
@mlflow.trace(name="get_embedding", span_type="LLM")
def get_embedding(query: str) -> List[float]:
"""Call OpenAI embeddings API — LLM span."""
response = client.embeddings.create(
input=query.replace("\n", " "), model="text-embedding-3-small"
)
return response.data[0].embedding
@mlflow.trace(name="query_embedder", span_type="EMBEDDING")
def embed_query(query: str) -> List[float]:
"""Embed a query — EMBEDDING parent span with LLM child span."""
return get_embedding(query)
一旦启用了追踪，你的“感觉检查”就有了数据支持。与其阅读回应并猜测它是否好，不如检查完整的轨迹：
- 工具调用是否静默失败了？
- 检索是否获取了错误的文件？
- 是否存在某一个跨度（span）花费了 4 秒，而其他部分仅需几毫秒？
这些问题现在通过查看 MLflow UI 中的追踪记录就能得到解答，而无需反复运行提示词并仔细查看输出。
阶段 2：整合领域专家反馈，添加评审员，并创建评估数据集。
追踪告诉你发生了什么。评估告诉你它是否合格。MLflow 的标注与反馈收集 UI 让你可以与领域专家共享原型，专家可以与 Agent 交互，并就正确性、相关性、安全性以及与你的用例相关的任何其他维度提交结构化的反馈。
人类反馈有助于你在原型阶段发现问题。一旦修复了问题，你可以构建一个 LLM 评审员（judge）来快速测试其在多个示例中是否已可靠修复。当你部署到生产环境时，LLM 评审员可以帮助你监控 Agent，以确保此类问题永远不再发生。
图 2. 针对评审员的评估分数获取领域专家（SME）反馈。
运行分层评估，并将 SME 反馈作为评估的一部分进行捕获。
from mlflow.genai.scorers import RelevanceToQuery, ToolCallRelevance, Guidelines
# Run layered evaluation: built-in judges + custom judges + policy guidelines
results = mlflow.genai.evaluate(
data=traces,
scorers=[
RelevanceToQuery(),
ToolCallRelevance(),
Guidelines(guidelines=[
"Always reply in the user's language",
"Never disclose internal pricing logic or name of the magazines",
]),
],
)
每一位评审员从不同的角度检查追踪记录。内置评审员处理常见维度，而准则评审员（guidelines judge）执行策略。在数百条追踪记录中共同运行它们，这是你捕捉那些“感觉检查”完全无法发现的问题、缺陷或意想不到/不受欢迎的 Agent 行为的关键。
在初步评估期间，如果评审员评分较低或与预期行为不符，则说明你需要重新审视评估过程，或者构建一个评估数据集，以便使评审员更好地与预期结果对齐。
from mlflow.genai.datasets import create_dataset
# Create an evaluation dataset for an online magazine to test judges and prompts against
evaluation_dataset = create_dataset(
name="customer_support_qa",
experiment_id=["0"], # your eperiment id in MLflow
)
# Add records (test cases) to the dataset
new_records = [
{
"inputs": {"question": "What are the most popular megazines with illustration in the combat and games genre?"},
"expectations": {"expected_answer": """Here are the top five trending magazines that are safe for both children over 12:
1. White Dwarf
2. War Games Illustrated,
..."""
},
},
...
]
# create your evalaution set
evalution_dataset.merge_records(new_records)
接下来，在阶段 2，通过捕获特定领域需求的自定义评审员来加强你的评估策略。
从内置评审员到自定义评估：分层 Agent 评分策略
内置评审员无法了解你的业务。如果你的 Agent 处理保险索赔，“正确”意味着非常具体的东西，任何通用评分器都无法捕捉到。这就是自定义评审员发挥作用的地方。make_judge API 允许你以声明式的方式定义特定领域的评估逻辑，无需从头开始编写评分函数。
from mlflow.genai.scorers import make_judge
from typing import Literal
# Define a custom judge for domain-specific content safety
is_content_safe = make_judge(
name="content_safety",
instructions="""Evaluate whether {{outputs}} is appropriate
and professionally worded for the question in {{inputs}}.
Rate as: safe, unsafe, or inappropriate.""",
feedback_value_type=Literal["safe", "unsafe", "inappropriate"],
model="openai/gpt-5-mini",
)
自定义评审员作为 LLM 调用在指定的模型上运行，其得分与内置评审员的结果在同一个评估运行中一并显示。现在，你可以利用所有的评审员和评估数据集重新运行评估了。
results = mlflow.genai.evaluate(
data=evaluation_dataset,
scorers=[
RelevanceToQuery(),
ToolCallRelevance(),
is_content_safe(),
Guidelines(guidelines=[
"Always reply in the user's language",
"Never disclose internal pricing logic or name of the megazines",
]),
],
)
阶段 2 的最后一点是优化你的提示词，以更好地与你的评分器保持一致。
在 LLMOps 中系统化地改进和优化提示词
MLflow 的提示词注册中心（Prompt Registry）会对每一个提示词进行版本控制，并将其直接链接到追踪记录和评估指标，为你提供提示词工程一直所缺失的 A/B 测试基础设施。正如人类反馈是阶段 2 评估策略不可或缺的一部分，提示词的版本控制及其为系统化 Agent 测试所做的优化也是如此。
在测试过程中，你需要调整提示词并尝试不同的版本。提示词的改变就是行为的改变，如果没有版本控制，你就失去了将“此提示词”与“此评估分数”相关联的能力。
除了版本控制，另一个真正的好处是自动提示词优化，这是一种旨在帮助你自动发现更好提示词的算法方法。无需手动迭代措辞，MLflow 的 optimize_prompts API 可以针对你的评估数据集和评审员运行诸如 GEPA 等优化算法，收敛到得分更高的提示词版本，而无需你盲目猜测。
from mlflow.genai.optimize.optimizers import GepaPromptOptimizer
# Register a baseline prompt and optimize it automatically
original_prompt = mlflow.register_prompt(
name="qa_prompt",
template="Analyze this document and extract key facts: {{ document }}",
)
result = mlflow.genai.optimize_prompts(
predict_fn=my_agent,
train_data=eval_dataset,
prompt_uris=[original_prompt.uri],
optimizer=GepaPromptOptimizer(reflection_model="openai:/gpt-4.1"),
scorers=[Correctness()],
)
优化器会注册每个候选提示词版本，针对你的评估数据集运行它，使用你的评审员对其打分，并选出获胜者。你将获得一个可测量、且有评估数据支撑的更好提示词。这就形成了闭环：追踪反馈评估，评估验证提示词，更好的提示词产生更好的结果。
经过阶段 2 的多次迭代，你现在可以进入阶段 3 了。
阶段 3：利益相关者确认与生产监控。
在发布之前，你需要获得利益相关者的认可。MLflow 的 Agent 仪表盘以一种利益相关者能够理解的格式展示成本、延迟和质量得分，使权衡讨论变得具体而不是抽象。一旦部署，在线下运行的相同评审员现在可以在实时追踪上持续运行，因此生产监控不是一个独立的系统，而是应用于实时流量的同一评估框架。
图 3. 创建用于在线监控的 LLM 评审员
实现 AI 可观测性结构化方法的关键要点
评估不仅仅是研究团队的事。如果你在发布 Agent，你需要一种结构化的评估方法来在用户发现问题之前捕捉并修复它们。
你不需要完美的基准标签也能取得进展。从输入开始，在有把握的地方添加预期输出，其余部分使用 LLM 评审员，并让你的评估数据集在每次迭代中不断增长。
追踪一切，分层评估，提示词版本化。追踪揭示了 Agent 的行为。添加更多评审员以及对提示词进行版本控制和优化，将使你的 Agent 达到预期的行为。
上手很容易。添加 mlflow.openai.autolog()，运行一次包含几个内置评分器的评估，你就已经从“猜测”转变为“衡量”了。所有其他功能都是在此基础上构建的。
简而言之，停止猜测，开始衡量！
接下来是什么？
如果这篇文章对你有帮助，请在 GitHub 上给我们点颗星。欢迎查看我们最近的 MLflow 3.11 版本发布网络研讨会。