评测方法论：离线评测与在线评测、A/B测试框架、评测数据集构建、评测自动化流水线
聊到Agent评测，很多人第一反应就是「跑个分」。但说实话，我见过太多团队在评测上栽跟头——要么离线跑得飞起，上线就崩；要么在线数据攒了一大堆，却不知道怎么归因。评测这件事，本质上是在回答一个问题：我的Agent到底变好了没有？
今天我们就来拆解评测的方法论。我会从离线到在线，从数据集到自动化流水线，把我在实际项目中踩过的坑和总结的经验，一次性讲清楚。
一、离线评测：先让Agent在「考场」里跑一遍
离线评测，说白了就是拿一批标注好的数据，让Agent跑一遍，然后算指标。它的好处是快、可控、可复现。我习惯把离线评测比作「单元测试」——你不可能每次改完代码都直接上线，对吧？
核心原则：离线评测的指标必须与线上业务目标对齐。否则你就是在「刷分」，而不是「优化」。
常用的离线指标包括：
- 任务完成率：Agent是否成功完成了用户指定的任务？比如订票、查询天气、生成报告。
- 平均交互轮数：完成任务需要多少轮对话？轮数越少，通常效率越高。
- 工具调用准确率：Agent调用API或工具时，参数是否正确？返回结果是否被正确解析？
- 响应延迟：从用户输入到Agent输出，花了多少毫秒？
嗯，这里要注意一点：离线评测的数据集如果构建得不好，评测结果就是「垃圾进，垃圾出」。我见过一个团队，用100条人工构造的简单问题做评测，结果Agent表现「完美」，上线后用户一问复杂场景就崩了。所以，离线数据集的质量，直接决定了评测的可信度。
二、在线评测：让真实用户来「投票」
离线评测再漂亮，也替代不了真实用户的使用体验。在线评测，就是把Agent部署到生产环境，收集真实用户的交互数据，然后分析表现。
我个人习惯把在线评测分为两类：
- 被动式：不干预用户行为，只记录日志。比如用户点了什么、Agent回复了什么、用户有没有再次追问。
- 主动式：在用户交互后，弹出反馈问卷，让用户打分。比如「这个回答对你有帮助吗？」
在线评测的难点在于「归因」。举个例子：用户问了一个问题，Agent回答得不好，用户就流失了。但你怎么知道是Agent的问题，还是用户本身需求就不明确？我曾经在项目中遇到过这种情况——我们花了三周优化Agent的回答质量，结果在线指标纹丝不动。后来一查日志，发现是前端加载太慢，用户根本没等到Agent回复就走了。
避坑指南：在线评测一定要同时监控「系统层指标」（延迟、错误率）和「业务层指标」（留存、转化）。两者缺一不可。
三、A/B测试框架：科学地「比一比」
说到在线评测，就绕不开A/B测试。说白了，A/B测试就是让一部分用户用旧版本（对照组），另一部分用户用新版本（实验组），然后看哪个版本表现更好。
搭建一个靠谱的A/B测试框架，我建议至少考虑以下几点：
- 流量分割：用户必须被随机分配到A组或B组，不能有偏差。我习惯用用户ID的哈希值来做分流，简单可靠。
- 样本量计算：别急着看结果。先算一下需要多少样本量才能达到统计显著性。我记得有一次，我们只跑了200个用户就宣布「新版本胜出」，结果第二天数据一反转，脸都打肿了。
- 指标选择：选一个「北极星指标」作为主要评判标准，其他指标作为辅助。比如做客服Agent，北极星指标可以是「问题解决率」。
- 实验时长：至少跑满一个完整的业务周期。比如电商场景，至少要覆盖一个周末+一个工作日。
小技巧：如果实验组和对照组的指标差异很小，别急着下结论。试试「反向A/B测试」——把两个版本互换一下，看看结果是否一致。如果一致，说明你的实验设计是可靠的。
四、评测数据集构建：好数据是「养」出来的
评测数据集，说白了就是Agent的「考卷」。考卷出得好不好，直接决定了你能测出Agent的真实水平。
我总结了一套构建数据集的方法论，分为三步：
4.1 数据来源
- 历史日志：从生产环境中抽取真实用户的问题。这是最宝贵的资源。
- 人工构造：针对边界场景、异常场景，由领域专家手动编写。比如「用户输入了乱码怎么办？」
- 合成数据：用大模型生成一批模拟数据。但要注意，合成数据容易有「模式化」的问题，需要人工审核。
4.2 标注规范
数据集的标注质量，决定了评测的「天花板」。我建议制定详细的标注规范，包括：
- 什么是「正确回答」？是语义等价，还是字面匹配？
- 什么是「部分正确」？比如Agent回答了80%的信息，但漏了一个关键点。
- 什么是「错误回答」？比如Agent给出了完全无关的信息，或者产生了幻觉。
我的经验：标注规范一定要先做「试标」。找3-5个人，每人标50条数据，然后对比一致性。如果一致性低于80%，说明规范还不够清晰，需要迭代。
4.3 数据集维护
数据集不是一次性的。随着业务变化，Agent的能力也在变。我习惯每两周做一次「数据集刷新」——加入新的真实用户问题，剔除过时的场景。
五、评测自动化流水线：让机器替你「跑分」
手动评测？不存在的。一个成熟的Agent项目，评测必须是自动化的。我画了一张流程图，帮你理解整个流水线的结构：
这张图展示了我常用的评测流水线。核心逻辑是：代码提交后，自动触发离线评测；离线通过后，自动部署到预发环境；预发验证通过后，再自动开启在线A/B测试。每一步都有明确的「通过/不通过」标准，不通过就自动回退。
实现这套流水线，我推荐用以下工具组合：
- CI/CD：GitHub Actions 或 GitLab CI，负责触发和编排。
- 评测引擎：自己写一个Python脚本，读取数据集、调用Agent、计算指标。
- 结果存储：用InfluxDB或Prometheus存储时序指标，方便后续分析。
- 可视化：Grafana做Dashboard，一眼就能看出Agent的表现趋势。
避坑指南：我曾经把离线评测和在线A/B测试放在同一个流水线里，结果离线评测跑了一个小时，A/B测试又跑了两天，整个流水线卡死了。后来我把它们拆成两个阶段——离线评测是「门禁」，必须快速通过；在线A/B测试是「长期观察」，异步进行。
六、总结：评测不是终点，是起点
说了这么多，其实我想表达的核心观点就一个：评测方法论不是一套固定的流程，而是一套持续迭代的思维框架。离线评测帮你快速验证想法，在线评测帮你发现真实问题，A/B测试帮你科学决策，数据集和自动化流水线则让这一切变得可持续。
你想想看，如果每次改完Agent，你都能在10分钟内拿到离线指标，在1天内看到在线趋势，在1周内完成A/B测试——那你的迭代速度会有多快？
嗯，这就是评测方法论的价值所在。它不是「做完一次就完事」的，而是伴随Agent整个生命周期的「体检系统」。希望今天的分享，能帮你把这个系统搭建起来。