大厂 Evals 经验系列 · EDD 专题
设想一个客服 Agent 答错退款问题。研发改了提示词，再问一次，回答正确。这个问题可以关闭了吗？
如果下次知识库、模型或工具变了，团队还得凭记忆重问，那次修复只留下了一段聊天。本文想追问的，是如何把这段聊天变成可以再次执行、可以比较版本的任务。
MLflow 的材料把追踪、人工反馈和评测组织在一起；这里选择其中一条线索，讨论失败记录如何进入回归，而不介绍安装和 API。本文没有运行示例，下面的客服场景均为假设。
保存执行记录，还没保存验收标准
MLflow 的结构化评测文章将 trace 与质量判断分开，并把领域人员反馈纳入评测。trace 是一次请求的执行记录，可包含模型与工具调用；它说明系统做过什么。MLflow 原文
假设客服面对的规则是：退款需要核验订单和凭证。Agent 最终给出“可以退款”，执行记录显示它查询了订单，却跳过了凭证。结果看着友好，过程已经漏了一项业务条件。
这时可以留下两种不同的意见：“语气太生硬”与“未核验凭证就承诺退款”。前者还需要解释什么表达更合适；后者有明确规则、动作和证据位置。若把两者都记成“不满意”，下一位研发很难知道该修哪里，也无法确认修复是否兑现。
我的建议是让反馈至少回答三件事：当时能获得哪些信息，哪项条件必须满足，哪段记录支持失败判断。缺少信息时保留“无法判断”，不要用一个低分代替证据。领域人员的价值，在这里首先是定义正确行为，而非为模型增加一个投票。
从旧记录中提取一个新的任务
MLflow 的端到端流程文档先添加预期，再将带标注的 trace 转为数据集，并用它评估不同版本。流程文档
精选译句：“把带标注的执行记录转为可复用的评测数据集。”原句为 “Transform your annotated traces into a reusable evaluation dataset.”
原创批注｜可复用需要保留重跑所需的条件。仅有旧回答，无法知道新版本面对的是不是同一个问题。
针对前面的假设，我会把任务写成：用户申请退款；预置一份订单记录和缺失凭证的状态；预期先询问凭证，不承诺已完成退款；评分依据是回复内容与退款状态。原失败记录留作定位依据，新任务则供新版本执行。
两者不能混用。对旧 trace 打分，是在评价旧执行；重新运行任务，是让新版本产生新执行。若报告把这两种结果并列为“新版回归成绩”，即使数据格式一致，比较对象也已经变了。
重跑还要处理状态。旧订单可能已经退款，接口今天可能返回另一种结果。直接重新访问线上对象，会把状态变化带进测试。可以使用经过核验的快照或隔离测试对象，但要注明哪些环节被替代。测试对象能帮助比较版本，不能证明真实接口的可用性。
这也是我理解的数据集管理责任：不仅保存问题与参考答案，还要维护任务的前置条件。无法重建的样本仍可用于人工复盘，暂时不宜承担自动回归的门禁。
给不同判断选择不同的评分依据
Databricks 的电信客户流失 Agent 文章展示了通用、业务规则和代码评分等方法。文中系统是作者为讲解搭建的案例，不能由此推断客户流失率已在生产中下降。案例原文
这个案例给我的启发是：先问判定需要什么证据，再选 scorer。scorer 指评分器，可以执行规则，也可以调用模型作判断。
回到假设的退款任务，“是否生成退款交易”应检查交易状态；“是否把缺失凭证说清楚”可以按细则阅读回答；“是否进行了无用重试”要看调用记录和业务原因。把这三件事都交给同一个文本裁判，会使它判断自己看不到的状态。
反过来，代码断言也会出错。检查回答是否包含“凭证”两个字，无法区分“请补充凭证”与“无需凭证”。检测词出现，只是测到一种文字特征。验收要的是动作条件满足，评分规则需要覆盖否定、例外和合理替代表述。
评分规则也要留下版本。假设第一次把缺少凭证判为失败，第二次只检查是否提到退款，两次分数上升未必说明系统改善。规则修订后，应让两版系统按同一规则重跑；对缺失交易状态的记录，标记无法评估，说明实际参与统计的任务范围。若把这些任务悄悄删掉，剩余样本通过率会变好，却没有解决原来的证据缺口。
同一次评测可以保存多项结果，却不一定需要立即合成总分。一个回复语气很好，但越过退款条件，平均分会淡化问题。我的产品取舍是把关键条件单独呈现，再讨论体验与成本；哪些条件能够阻断上线，需要业务明确决定。
提示词版本怎样进入修复记录
MLflow 文章介绍了提示词版本与 trace、评测结果的关联。提示词章节
从交付管理看，我会给前面的修复留一条变更说明：新版增加凭证核验要求，预计改善哪类任务，可能影响哪些原有回答。随后保留新旧版本在同一任务定义下的执行记录，检查改对的地方，也检查原本正确的行为是否退步。
提示词编号本身不足以标识完整系统。假设两个版本都写着“退款提示词 v2”，一个能查凭证，一个只能查订单，结果差别未必来自提示词。比较记录还要绑定实际使用的模型、工具和知识条件。若这些同时变化，先报告整个配置的变化，别把收益全算给一句新提示。
还有一种容易漏掉的退步：Agent 学会每次都问凭证，即使当前上下文已提供并通过核验。新增一项要求可以修复遗漏，也可能造成重复询问。因此我会补一条对应任务：凭证已经核验时，允许继续处理。这是本文提出的反例设计，避免把修复变成机械地增加步骤。
旧样本与修复反例用于开发，也要留出未参与调参的任务检查泛化。否则反复对同一小组样本改提示词，得到的可能只是对熟悉题目的适配。
上线后，这条任务还要继续维护
MLflow 将上线后的质量监测接入同一评测思路。上线阶段 但复用评分器的意义是延续已定义的检查，不能证明它覆盖了新用户和新业务。
假设退款政策增加一类例外订单。旧任务依然要求询问凭证，却可能已不适用于这类订单。线上再出现不满意反馈时，应先检查任务定义的有效期，而不是直接强化旧规则。监测分数下降，可以触发调查；调查需要确认问题来自系统行为、数据状态还是验收约定。
我会给这条回归任务留下三项维护信息：当前适用的政策版本、能复现它的测试条件、谁负责裁定新例外。政策改变后，旧任务保留历史用途，修订后的任务重新比较版本，不把两套标准的分数接成一条提升曲线。
对产品经理而言，这篇材料最有用的地方，是把“修过这个问题”拆成可交接的证据：有失败记录，有明确预期，有重新执行的任务，也有版本比较。下一次验收这个退款修复时，应能取出新版执行、关键条件结果和原有任务的退步情况；只有一段正确回答，仍不足以结束这项验收。
来源说明：D01 为 MLflow 的方法文章，D02 为 Databricks 的能力讲解案例，D03 为随版本更新的流程文档。本文采用短译与原创解读，不将工具能力、教学输出或流程说明写成已验证的生产收益。
系列相关阅读
本专题阅读顺序：完整理解 EDD → Google 的提示词实验 → OpenAI 的评测位置 → 微软的需求断言 → MLflow 的回归任务 → AWS 的协作验收 → 美团的双环评测。
评测基础可回读再读A社博文：怎样建立可信的 Agent 评测；判断评分可靠性，可继续阅读谁来给 AI 裁判打分与Agent 分数涨了，能力真的变强了吗。