MLflow 的评测流程:怎样把一次失败变成可重跑的任务

原文把开发分成三个阶段：原型阶段先记录系统实际做了什么；评测阶段让业务专家给出反馈，把预期变成可以重复运行的检查；上线前由相关方确认质量、成本和响应时间之间的取舍；上线后继续观察真实请求，把新问题送回开发。执行记录、人工反馈与评测、提示词版本和治理，是文中相互连接的四部分。这里的“可观测性”，就是能够查看一次请求经过哪些步骤、用了什么信息，以及时间、成本和输出表现，而不只看最后一句回答。〔2〕

这篇博文给出了全局流程，但理解“反馈怎样变成下一版的测试”还需要具体任务。因此，下文同时使用 MLflow 官方《端到端工作流：评测驱动开发》里的退款政策问答，走一遍记录、标注预期、整理题目、重新执行的过程；再结合 Databricks 作者搭建的电信留客案例，看为什么不同评分会发现不同问题。这是三份互补材料，不是同一个系统的一份连续实验报告。〔1〕〔3〕

阅读重点是把一次“不满意”变成别人也能复查的依据：用户问了什么，当时怎样回答，应该做到什么，改完后又怎样比较。先把这条线看清楚，后面的工具名和评分规则才有具体含义。

MLflow 的端到端评测文档从一个客服问答机器人开始。它的知识库保存退款、运输和保修政策；收到问题后，先按关键词找到相关知识，再交给语言模型组织回答。〔1〕

退款政策的示例内容很具体：30 天内，凭收据可全额退款。用户询问退款政策时，机器人应把这两项条件说明白。

这个例子演示的是政策问答。它没有查询订单、核验真实收据或执行退款交易。先弄清这一点，后面才能知道评分到底在检查什么。

如果员工人工验收时只说“回答得不完整”，这条反馈还不够用于下一版检查。遗漏了期限、遗漏了收据条件，或者答了另一种政策，需要有具体记录。

MLflow 要串起的流程，就是从一次实际回答中留下记录，补上预期，再让新版本面对同样的问题重新回答。

MLflow 把一次执行留下的记录称为 trace。这个例子会保存问答执行，之后可以查询这些记录，查看输入、调用和输出。〔1〕

另一篇 MLflow 流程博文进一步把 tracing、专家反馈、评测和版本管理连接起来：先看到系统怎样运行，再让领域人员说明预期表现，随后比较改动。〔2〕

对于退款问答，用户问了什么、机器人当时答了什么，是定位问题的起点。但旧回答本身并没有告诉后来的人应该怎样判定。

文档因此给相关记录补上预期：回答必须提及 30 天和收据，表达应有帮助。预期是评测时的参照，不是把旧回答直接当成正确答案。〔1〕

这样，一次反馈就有了明确对象。以后再说“期限漏了”，可以回到同一个问题和相应预期，而不用依靠某位同事记得当时的讨论。

文档接着把带预期的记录合入评测数据集，并允许补入手工设计的问题。其中一道问题询问：购买已经过了 45 天，还能不能退货？〔1〕

数据集可以理解成一批等待重新检查的任务。这里保存的核心内容是输入问题和预期表现。45 天的问题与普通退款政策问句不同，能帮助检查机器人怎样处理期限边界。

随后，评测程序把机器人的回答函数传进去。运行评测时，是让当前版本重新回答数据集中的问题，再检查新输出。文档示范补充退款知识、说明超过 30 天可提供店内余额后，再用相同数据集比较版本。它是教学修改，没有报告这一步已经带来生产收益。〔1〕

这一步还需要分清政策依据。文档是在演示修改知识内容，实际业务中新增退款方式必须先有经过确认的政策，不能为了让分数更好而自行增加承诺。政策变更时，也要核对原题的预期是否仍然适用。

批注：给旧回答重新打分，与让新版重新作答，是两件事。前者仍在评价旧执行；后者才产生能够用于检查新版的输出。把旧记录保存得再完整，也不能替代一次新的执行。

所以，“把失败变成可重跑的任务”，至少意味着留下了问题、预期和执行入口。旧回答供人追查，新执行供人检查修改。两者有关联，但承担的用途不同。

文档对客服机器人同时使用多种评分：检查事实是否准确、回答是否符合服务要求，以及是否包含指定信息。〔1〕

这几项分别回答不同问题。回复语气友好，可能仍然漏掉收据；关键词齐全，也可能把条件关系说错。

文档中的指定信息检查采用词项是否出现的方式。读这个示例时要理解它的能力范围：出现“30 天”和“收据”，只能证明这些文字出现了。

若评分函数实际拿到的必含词就是这两项，两项都出现得 1，只出现一项得 0.5，都没出现得 0。这个分数首先表示指定词项的覆盖比例，不能直接当作完整政策正确率。

代码还有一个容易漏读的条件：如果预期里没有评分函数要找的 must_mention 字段，函数直接返回 1.0。有些手工题没有这个字段；前面的标注又把词表放在 key_information 项下。使用示例前，需要核对数据集交给评分函数的实际结构。这个默认返回值不能统一解释为词项确实检查通过。本文没有运行示例代码。〔1〕

例如，“30 天内需要收据”与“超过 30 天也不需要收据”，都可能包含相关词。这是对示例规则的解释性对照，不是文档报告过的真实失败。想核查完整政策含义，还需要查看回答是否正确表达条件，不能只停在词项计数。

这种区别，也能帮助读懂 Databricks 的另一篇多 Agent 案例。

Databricks 的作者为讲解搭建了一套电信客户留存 Agent。主管 Agent 协调其他能力，为客户问题生成应对内容。文章分别检查通用质量、业务约束和执行行为。〔3〕

作者展示了两种具体发现：业务规则评分识别出回答推荐了竞争对手产品；执行分析发现一次请求在缺少客户资料时触发了 13 次工具调用。原文据此讨论身份验证检查和提示词调整。〔3〕

前一种问题，要读回答是否违反业务要求；后一种问题，要看执行过程中发生了什么。只给最终文字一个总分，很容易把这两类证据混在一起。

13 次是作者所展示请求的调用数量，不是所有 Agent 的统一上限。判断调用是否无效，还需要结合任务需要、输入是否充分以及工具返回情况。

这个案例给客服问答流程补充了一点认识：评测数据里除了答案，还可以关联执行记录；根据要判断的问题，选择相应证据和评分方式。

MLflow 流程博文还介绍了提示词版本管理，以及版本、执行记录和评测结果的关联；上线后继续使用质量监测来发现问题。〔2〕

对读者来说，可以把前面的退款政策问答连成一条记录：原问题是什么，原先的预期是什么，这次修改了什么，当前版本实际答了什么，各项检查结果怎样。

版本编号帮助找到对应内容，评测结果帮助比较表现。仅仅有一个新编号，并没有证明回答已经改善；仍要回到新输出和相同检查条件。

如果以后退款政策变化，预期也要重新核对。否则，一个遵循新政策的回答，可能继续被旧要求判错。这是使用这套流程时需要维护的业务条件。

现在再看最初那条“退款政策没答完整”的反馈，它不应只留成一次聊天截图。可以留下明确的问题与预期，让下一版重新回答，再把结果与版本关联。这样才能区分“这次看起来答对了”，以及“这一类问题有了可再次执行的检查”。

〔1〕MLflow：End-to-End Workflow: Evaluation-Driven Development。本文使用客服问答、预期标注、数据集和重新执行的教学流程。

https://mlflow.org/docs/latest/genai/datasets/end-to-end-workflow

〔2〕Jules S. Damji：Structuring AI Evaluation and Observability with MLflow: From Development to Production，2026-04-22。

https://mlflow.org/blog/structured-ai-eval

〔3〕Ananya Roy、Layla Yang：Building Responsible and Calibrated AI Agents with Databricks and MLflow: A Real-World Use Case Deep Dive，2026-01-21。本文所述系统为作者搭建的讲解案例。

https://www.databricks.com/blog/building-responsible-and-calibrated-ai-agents-databricks-and-mlflow-real-world-use-case-deep