为什么没有评测体系的 Agent 只能靠拍脑袋迭代
讲透 Agent 评测维度、测试集构建、输入质量分级路由与模型路由选型四件套。
立靶：不做系统评测，Agent 是怎么死的
先想象一个没有评测体系的 Agent 团队的日常。有人在群里说「今天这个版本感觉变聪明了」，于是合并上线。第二天另一个人说「怎么又变笨了」，没人能说清到底是哪次改动引入的回归——因为根本没有可重复的衡量标准。这就是拍脑袋迭代：每一次「变好」都是体感，每一次「变坏」都查不到根因。
没有评测体系，至少会同时踩中三个坑：
- 拍脑袋迭代：迭代方向靠主观感受，无法回答「这次改动到底是涨了还是跌了」。
- 无法定位回归：今天的 badcase 是上周哪个 prompt 改动引入的？没有固定测试集做基线对比，回归就是黑洞。
- Benchmark 高分但真实场景崩：模型在公开榜单上分数漂亮，一上线就崩。原因不在模型，而在输入。
记住这条贯穿全讲的判断：AI 产品的失败，90% 是输入问题，不是模型问题。 评测体系存在的意义，就是把「我觉得」换成「我测了」。下面四块拼在一起，才是一套完整的评测体系：评测维度、测试集、输入质量分级路由、模型路由选型。
框架：评测维度体系
一个 Agent 至少要在五个维度上有数：
| 维度 | 测什么 | 方法 |
|---|---|---|
| 召回率 | 真实问题中被正确识别出来的比例 | 用专家标注过的正例测试集跑，统计漏报 |
| 精确率 | 被识别出的问题中真正有问题的比例 | 用干净的负例测试集跑，统计误报 |
| 建议有效性 | 修改建议是否直接可用 | 人工评估抽样，看建议落地率 |
| 问题类型覆盖率 | 各类问题是否都覆盖到 | 按问题类型分桶统计命中 |
| P99 延迟 / token 成本 | 响应是否够快、单次调用花多少钱 | 线上埋点统计尾延迟与 token 消耗 |
这里有个关键的取舍：精确率和召回率不可能同时拉满，优先级取决于业务里哪种错误代价更高。
- 代码审查场景：精确率优先。误报多了会造成 Alert Fatigue（告警疲劳），开发者一旦开始忽略告警，整个工具就废了。
- 合同审查场景：召回率优先。漏掉一条风险条款可能带来巨大的法律代价，宁可多报也不能漏报。
同样一套维度，权重要按业务的「错误成本结构」来配。这是 PM 视角，不是算法视角——算法只会告诉你 F1 分数，PM 要决定这个场景该往精确率还是召回率偏。
补充一个公开 Benchmark 的能力分解视角。AgentBench 把 Agent 能力拆成五个核心维度：指令跟随、编码能力、知识获取、逻辑推理、常识理解。它的几个关键发现值得记：主要失败类型是 TLE（超出轮数限制），占比 23%–82%，是最大瓶颈——Agent 不是不会做，而是绕不出来、耗尽轮数；高质量对齐数据配小模型，效果约等于低质量数据配大模型；用代码数据训练是双刃剑，静态流程能力上升但通用推理能力会下降。
数据与 case：Benchmark 速查与一个真实事故
同一个 Benchmark 对不同业务的相关性天差地别，看榜单一定要看「跟我的场景相不相关」：
| Benchmark | 测什么 | 对合同审查的相关性 |
|---|---|---|
| MMLU | 知识广度 | 低 |
| SWE-bench Verified | 代码修复 | 极低 |
| GAIA | 多步骤任务 | 中 |
| LegalBench | 法律任务专项 | 高 |
| LongBench | 长文档理解 | 高 |
| TruthfulQA / HaluEval | 幻觉率 | 高 |
一个做合同审查的 Agent，盯着 MMLU 和 SWE-bench 的分数选模型是缘木求鱼；真正该看的是 LegalBench、LongBench 和幻觉率这三项。Benchmark 不是越多越好，是越相关越好。
再讲一个真实事故（脱敏）。某法律文书审查 Agent，离线测试集上指标漂亮，一上线就翻车。复盘发现根因不在模型，而在输入：用户上传的是扫描件，OCR 出来一堆乱码，模型拿着乱码硬答，结果驴唇不对马嘴。为什么上线前测不出来？三个根因：
- 测试集偏差：测试样本的质量分布偏理想化，全是清晰扫描件，没有乱码件。
- 长尾分布忽视：构造测试集时，边缘场景（模糊件、缺页件）被嫌麻烦跳过了。
- PM 视角缺失：评测维度只盯着精度和召回，根本没人去看「输入质量的分布长什么样」。
这就是开头那句话的来源——失败 90% 出在输入。如果上线前对输入质量做了分级，乱码件本就不该进 LLM，而该被拦下来转人工或反问。
可操作做法
怎么建测试集
- 正例：经过资深专家审查、且确认发现真实问题的案例。
- 负例：被专家标注为「无实质问题」的干净案例——专门用来测误报、压精确率。很多人只攒正例，负例和正例一样重要。
- 规模：200–500 条离线集打底，外加 20–50 条人工评估集。
- 双基线对比：不要只看 Agent 自己的分数，要和基线比——纯 LLM 裸跑 vs Agent、传统静态工具 vs Agent。
- 覆盖长尾：刻意把模糊件、缺页件、乱码件这类边缘场景放进去，别图省事跳过。
上线流程与生产数据回流：离线测试集达标 → Shadow Mode 影子运行（约 2 周）→ 10% 灰度 → 逐步放量。在线核心指标看建议采纳率，参考线 ≥ 40%。上线不是终点，测试集要靠生产数据持续回流校准：T+1d 建立输入质量异常监控，T+1w 抽样真实失败案例补进测试集，T+1m 每月迭代重跑基线，T+3m 测试集分布逐步收敛到真实生产分布。核心思想：让测试集从「理想分布」慢慢长成「生产分布」，否则永远在测一个不存在的世界。
输入质量分级路由：在 LLM 之前加一个 ingest 层，先给输入打质量分，再按分数分级路由。低质量输入不该进 LLM。
| 业务 | 输入质量分级维度 | 路由策略 |
|---|---|---|
| 合同审查 | 扫描件清晰度 / OCR 置信度 | 清晰走默认，模糊转人工 |
| 语音招聘 | 信噪比 / ASR 置信度 / 语速 | 嘈杂换电话或转人工 |
| 代码审查 | 代码完整性 / 编译通过率 | 编译失败直接拒收 |
| 客服 Agent | 问题清晰度 / 历史完整性 | 信息缺失则反问 |
怎么做模型路由选型：这里要分清两种正交的路由——输入质量分级路由（管「这个输入配不配进 LLM」）和模型路由（按任务难度/类型/成本在多个模型间选，管「进哪个 LLM」）。趋势是模型选型正从「上线前一次性决策」变成「运行时动态路由」：按任务难度自动选模型，难任务上 frontier 大模型、简单任务下沉小模型，性能不降的前提下成本省约 25%。设计要点：把「成本-质量」做成一个可调旋钮，而不是无脑固定选最强模型；路由决策本身要可观测、可回放；分档边界靠离线测试集加生产回流来校准。模型升级要不要换，按这个框架决策：看相关 Benchmark → 跑自有离线测试集 → 对比成本和延迟 → Shadow Mode 验证 → 10% 灰度上线，一步都不要省。
收口
失败 90% 是输入问题，不是模型问题——所以在 LLM 前面先建 ingest 层：质量评分 + 分级路由，低质量输入不该进 LLM。模型选型也不是上线前选个最强的就完了，而是运行时分层路由，把「成本-质量」做成可调旋钮，简单任务下沉、难任务才上 frontier。