LLM EvalA/B Testing指标体系工程化质量
LLM 评测入门：从主观好坏到可量化指标（离线评测 + 在线 A/B）
“感觉变好”不是评测。LLM 系统的质量来自一条可重复的闭环：定义任务与输出合同、构建真实评测集、选择可解释指标、做离线回归与在线 A/B，并把失败样本回写。本文给出一套从 0 到 1 的 LLM 评测框架，覆盖离线/在线、正确性/可靠性/成本/延迟四维指标，以及如何避免 LLM-as-judge 的常见坑。
2026年3月4日
Synthly 团队
预计阅读 16 分钟
📷 Photo by Markus Winkler via Pexels
先对齐一句话：评测的目标是“可重复的决策依据”
很多团队改 prompt、换模型、加 RAG，最后只有一句话：
- “感觉更好了。”
这句话最大的问题是：不可复现、不可解释、不可回滚。
评测体系的目标是让你能回答：
- 这次改动提升了什么？
- 代价是什么？
- 在哪些场景变差了？
- 需要灰度还是可以全量？
一、从任务出发：先定义“输出合同”，再谈指标
如果你不知道什么算成功，任何指标都是噪声。
建议先写输出合同（Output Contract）：
- 输出格式（JSON/Markdown/表格）
- 必填字段
- 枚举约束
- 失败与追问规则
结构化输出的合同与校验思路可参考：
二、离线评测：用最小成本挡住 80% 的回归
1）构建评测集：真实样本 > 自己编的样例
最小建议：
- 100–300 条真实问题（按任务类型分桶）
- 每条包含：输入、期望输出要点、通过/失败判定
- 覆盖边界：缺信息、冲突约束、工具失败、长文本
2）离线指标：不只看“对不对”
建议至少有：
- 任务通过率（pass@1）
- 结构化解析成功率（parse success）
- 工具调用失败率（timeout/429/empty）
- token 成本、工具次数
- 端到端时延（模拟或记录）
3）失败归因：把失败变成可修复条目
不要只记录“失败”。记录：
- 失败类型（解析错/字段漂移/证据不足/工具错）
- 触发条件（某类输入/某工具/某版本）
- 修复建议（改 schema、改检索、加追问、加预算）
失败样本是最值钱的数据资产。
三、在线评测：A/B 不是锦上添花，是“验证真实价值”
1）在线指标要贴业务
除了模型指标，更要有业务指标：
- 用户纠正次数/返工率
- 任务完成率（用户视角）
- 次日留存、转化
- 人工介入率
2）灰度与回滚：评测必须可止损
上线策略建议：
- 小流量灰度
- 关键指标护栏（guardrail metrics）
- 一键回滚（prompt/model/tool 版本）
如果没有回滚，A/B 就是在赌。
四、LLM-as-judge：能用，但要“校准 + 约束 + 记录不确定性”
LLM 当裁判常见三个坑：
- rubric 不清晰 → 裁判随心所欲
- 裁判偏好某种风格 → 把“更像裁判”当成更好
- 与被评模型同源 → 偏差加剧
工程建议：
- 用少量人工标注样本校准裁判
- rubric 写成可执行条款（例如字段是否齐全、证据是否引用）
- 记录裁判置信度与分歧（必要时多裁判投票）
这类“多采样/多裁判”的稳定性思路也可以参考：
五、把评测做成闭环：评测集会“越用越强”
最小闭环流程：
- 收集线上失败案例
- 归因分类（解析/工具/知识/策略）
- 回写到离线评测集
- 每次改动跑回归
- 灰度上线验证
当评测集越积越厚，你的迭代速度会越来越快。
六、最小落地清单（可直接复制到项目里）
- 输出合同（字段/枚举/失败与追问）
- 离线评测集（真实样本 + 分桶 + 边界）
- 指标面板（正确性/可靠性/成本/延迟）
- 失败归因模板（可落库）
- 灰度开关与回滚
- 线上数据回写评测集
做到这 6 件事，你就从“调 prompt”升级为“做系统”。
常见问题
没有人工标注怎么办？
可以先用弱监督：规则校验 + 结构化合同校验 + 关键事实一致性检查，先把明显错误筛掉。然后逐步引入少量人工标注做校准，比一开始就追求全量标注更现实。
评测集会不会过拟合？
会，所以要持续更新：加入新分布、新失败样本，并保留一部分“保密集”（holdout set）只用于最终验证，避免把系统调成“只会做题”。