改完 Prompt 后，找几个熟悉的问题试一遍，新答案似乎更好，于是发布。即使多试几道题，这种测试仍然站不住脚，因为每次测试的条件都在变化。输入换了，知识库更新了，评价的人也可能换了。两个版本没有面对同一场考试，“新版更好”便无从证明。
可靠的版本比较需要一条连续的数据链：把值得反复验证的情境整理成 Dataset，让基线和候选方案在相同条件下运行 Experiment，再把不可接受的退化写进发布门禁。三者服务于同一件事，即让改动接受可复查的比较。
Dataset 固定比较条件
Dataset 常被理解为一份问题清单。真正能用于评估的 Dataset 更像测试契约，它说明系统将面对什么输入，当时有哪些上下文，我们期待什么，以及这个样本最需要检查哪项风险。
业务问答 Agent 的一个样本可以包含用户问题、会话历史、可用数据快照和预期口径。如果任务要求调用工具，还可以保存期望工具、关键参数或允许范围。开放式回答未必有唯一标准答案，此时保存评价量表、参考事实或证据要求更合适。固定的是比较条件，不是把自然语言任务改成背标准答案。
样本主要来自产品需求和真实运行。需求中的核心流程保证基本覆盖；生产中的失败更有价值，因为它们保留了用户真实说法和系统真实状态。一次已修复的口径错误如果没有进入回归集，几个月后换模型时很可能再次出现。合成样本可以补边界和稀有风险，但不应替代真实流量。
把 Trace 加入 Dataset 前需要整理。删除不该长期保存的敏感信息，确认外部依赖可以重放或固定，补充预期结果和评价要求，并记录样本为何进入集合。直接导入一批日志，只是更换存放位置。没有预期和上下文，运行失败时仍然不知道错在哪里。
Dataset 本身也会过期。业务口径、工具和知识源发生变化后，旧的 expected output 可能已经错误。样本应保存来源、场景标签和更新时间，修改或删除时留下原因。否则两次实验使用了同名 Dataset，实际题目却不同，结果看似可比，基础已经变了。
Experiment 控制变化
有了 Dataset，还需要让基线与候选方案在尽量相同的条件下运行。基线通常是当前生产版本或已经确认的版本；候选方案包含本次改动；两边使用相同样本和评价标准。知识快照、工具环境、模型参数也应固定或明确记录。
一次实验最好只引入一个主要变化。验证 Prompt 时，模型和检索策略先保持不动。真实工程有时无法做到严格单变量，例如新模型要求调整 Prompt，但仍要记录所有版本差异。实验需要的是可解释的结果，没必要追求实验室式纯净。
继续看“华中区消耗下降”的案例。团队希望新 Prompt 减少指标口径错误。旧版和新版应处理同一批 Dataset Item，读取相同数据快照，再由同一套规则和 Judge 评价。每次运行保留输出、执行 Trace、分数、延迟与成本。结果需要回答具体问题：哪些场景进步，哪些样本退化，质量提升是否带来无法接受的耗时。
平均分只能提供概览。正确率从 0.80 升到 0.86，可能伴随一个财务高风险样本由正确变为错误。查看按场景切片的结果和成对差异更有解释力。关键退化样本还要回到 Trace，确认变化来自产品逻辑、评估器还是外部环境。
生成模型会波动，工具数据也可能变化。对发布影响较大的实验，可以固定可控参数，并让关键样本重复运行。遇到偶发差异时，不急着宣布进步或回归；先检查结果是否稳定，评价基础设施是否正常。实验结论应写清适用条件：“在 Dataset v7、知识快照 2026-08-15 和 Judge v3 下，候选版本降低了口径错误，但复杂追问延迟上升。”这比“新版提升 8%”更经得起追问。
在 Langfuse 中，Dataset Item、任务函数和 Evaluator 可以组成 Experiment，Dataset Run 保存各样本的运行和评分，便于比较不同版本。其他评估平台也有 Run、Benchmark 等对应概念。平台负责执行与保存，实验是否公平仍取决于样本、版本和环境控制。
门禁把实验结论接入发布
实验告诉团队发生了什么，门禁决定这些变化能不能上线。门禁不是统一的总分线，它是一组事先约定的发布条件。
条件可以分成硬底线和相对变化。敏感信息泄露、禁止工具调用、关键财务口径错误属于硬底线，出现一次就需要阻断或人工批准。任务完成率、成本和延迟更适合与基线比较，并按场景设置容忍范围。简单样本数量多时，平均值会稀释少数严重问题，所以高风险样本应单独检查。
发布判断可以组合确定性规则、经过校准的语义 Evaluator 和人工复核。规则处理格式、权限等明确约束；Judge 承担较大规模的语义比较；接近阈值、评价分歧和高风险案例进入人工队列。具体组合取决于错误后果，不必追求自动化比例。
门禁还要区分产品失败和评估失败。Judge 超时、结果无法解析、测试数据不可用时，不能把它记成产品低分，也不能默认放行。合理做法是把评估状态单独记录，按风险选择重试、转人工或暂停发布。否则质量流水线本身的故障会污染产品结论。
适合频繁运行的回归集不必很大，但要守住已经确认的重要能力。探索性长尾样本可以放在定期评估里。每次修复线上问题时，团队都应判断它是否值得成为长期回归样本；每次调整阈值、评价器或样本时，也要记录原因。门禁是一份会演进的发布契约。
Langfuse 的 Experiment 可以通过 SDK 接入 CI/CD，运行结果和 Score 用于生成发布报告。是否阻断部署通常仍由团队自己的持续集成逻辑控制。实现时还要核对 SDK 与服务端版本：当前 v4 的实验能力要求使用对应的新 SDK，旧版仅能访问部分 Dataset 能力。版本兼容矩阵比零散示例更可靠。
Dataset、评价规则、版本信息和实验结果都应能够导出并复建。平台更换后仍能重跑同一批样本、解释原有分数，这套质量资产才算由团队掌握。
参考资料
系列目录：AI 应用可观测性与评估