评测
定位:没有评测集,所有「我感觉变好了」都是错觉。 评测是把 Agent 从「看着能跑的 Demo」变成「敢交付」的那道关,也是横切所有设计层的质量底座。
📎 来源:实践分享第五章 + 控制价 CLI 化实战的 4 方评测方法论。诊断侧见 评测与改进/失败分析与治理。
理念:LLM as Judge → Agent as Judge
Section titled “理念:LLM as Judge → Agent as Judge”- 以好坏为衡量:不只看「准不准」,更看「好不好」——含业务指标也含技术指标。
- 三件套缺一不可:指标设计 + 评测集设计 + 评测工具设计。
- 双轨并行:程序化评测(确定性、可重复)+ 大模型评测(主观质量)。
- 引入 Sub-Agent:让 Agent 自己跑测试、自己判分——从单次打分升级为自动化流程。
LLM-as-Judge 只看「这一句答得对不对」;Agent-as-Judge 看「整个任务做得好不好」。
指标:红线层 + 质量层
Section titled “指标:红线层 + 质量层”🔴 红线层 · 一票否决(不过线,质量层再高也没意义):数据准确率 100% · 不造数据 · 不靠检索/记忆作答。
🔵 质量层 · 综合回答质量:
| 指标 | 类别 |
|---|---|
| 任务完成度 / 事实准确性 / 业务诉求覆盖 | 业务 |
| 证据可追溯 / 边界与风险 | 技术 |
| 业务表达 | 表达 |
三层金字塔(越往下越确定、越频繁)
Section titled “三层金字塔(越往下越确定、越频繁)” L3 E2E 端到端 · 真实环境(Sub-Agent 大规模提问 / 浏览器校验排版) L2 Skill 测试 单 Skill 独立拆解(Mock CLI 输出,长链路简化为 1–2 步) L1 单测 CLI 层基础验证(子命令、参数、JSON schema 是否稳定)底层覆盖广、跑得勤、最确定;顶层最接近真实但成本高——分层才跑得起、也信得过。
评测集 = 出厂质量 = 核心竞争力
Section titled “评测集 = 出厂质量 = 核心竞争力”- 法律、医疗都靠高质量数据集(医疗有几十国医生临床对话整理的人工集)。
- 最好的评测集本身就是核心竞争力:同一把尺子,我们打 95、友商打 90,高下立判。
- 参考:《评测数据集设计:成本问数》—— 17 种子场景 / 102 案例 / L1–L4 分层。
落地方法:会话 JSONL 当数据源(可复用范式)
Section titled “落地方法:会话 JSONL 当数据源(可复用范式)”Claude Code 每次会话自动把完整对话流水落到本地,是一份现成、客观的评测源:
~/.claude/projects/<project-slug>/<session-id>.jsonl每行一个 JSON,信息完整:用户/模型每条消息(含 thinking)、每次工具调用(name+args+result+时间戳+token)、每条 Bash、每个文件读写、累计 token。一次 E2E 单文件常 1–10MB、几百到几千行。
四步流程:
STEP 01 固化测试剧本 → 02 跑完导 JSONL → 03 写提取脚本 → 04 落客观指标从 JSONL 反推的 8 个客观指标(控制价 4 方评测实测用法):
| 指标 | 提取方式 |
|---|---|
| 实际用时 | 末条 − 首条 timestamp |
| 错误率 | tool result 含 error / 总调用;细分 CLI/Bash/文件 |
| python 临时补丁 | Bash args 含 python -c 内联代码计数(错误兜底手写的) |
| 用户介入 | 用户消息中「纠错/重试/改这里」模式计数 |
| 合计 token | 累加所有 usage(input+output+cache) |
| Bash 调用 | 全部 Bash 计数;CLI 模式细分 report-gen vs 其他 |
读 .py 源码 | Read 对 *.py 的调用计数(模型在猜内部实现) |
| 审核结论 | 末尾回复提取结论,判断多方是否同口径 |
可重复性四固定:剧本固定 + 项目数据固定 + 环境固定 + 唯一变量是「模型 × 架构」。原始 JSONL 留底 → 数据可追溯、指标可复核。
把「我觉得变好了」换成「用时 79m→15m、错误率 11%→0%、token 13M→2.9M」——数字才有说服力。完整 4 方对照见 实践分享/控制价审核CLI化实战。
- 问数场景测评闭环全流程 → 场景指南/问数/08
- 失败如何归因(8 层 + 决策树)→ 评测与改进/失败分析与治理
- 审核/质量类场景 → 场景指南/审核