模型评测、Benchmark 与 Eval 底层图谱
把“模型分数”拆成任务、样本、标注、评分器、线上反馈和发布闸门：理解 AI 系统如何知道自己有没有真的变好
阅读定位: 这一页只讨论模型评测、Benchmark 和 Eval 的底层结构：评测对象、能力维度、样本与标注、自动评分、人类评审、LLM-as-Judge、离线和线上评测、数据污染与生产闸门。
它不替代 LLMOps 可观测性平台页，也不做具体模型排行榜；这里关心的是“分数从哪里来、分数能说明什么、分数什么时候会骗人”。如果要理解 Eval 怎样作为训练 run 的闸门，连接 dataset、checkpoint、回滚和发布，可以继续看
训练数据到模型能力形成的一生；如果要看评测结果怎样被翻译成质量 / 安全 / 成本 / 延迟闸门、Canary、上线或回滚决策，继续看
模型评测到发布闸门的一生。
目标场景
业务要什么
→
能力维度
拆成可测问题
→
任务与样本
输入 / 期望 / 约束
→
评分机制
规则 / 人 / Judge
→
误差分析
坏例 / 分布
→
上线决策
闸门 / 灰度
→
反馈回流
更新 Eval
| 传统考试直觉 | AI 评测里的真实问题 | 应该怎么理解 |
|---|
| 一个总分代表水平 | 不同任务能力差异很大，平均分会掩盖关键失败 | 看分数分布、任务切片、坏例类型和高风险场景 |
| 题库固定就公平 | 模型可能见过题、被针对优化，或题库已经脱离真实场景 | 固定 Benchmark 适合横向参考，生产 Eval 要持续更新 |
| 答案唯一就好判 | 开放问答、摘要、Agent 和工具调用常常没有唯一标准答案 | 需要 rubrics、偏好比较、人工校准和任务成功率 |
| 分数越高越适合上线 | 高分模型可能更贵、更慢、更容易过度回答或不符合业务语气 | 上线看质量、成本、延迟、安全、稳定性和可控性 |
最小直觉
评测不是给模型贴一个永久成绩单，而是在某个任务分布、某套提示、某个评分口径和某个时间点上，估计系统是否足够可靠。它更像工程里的仪表盘和刹车系统，而不是学校考试。
知识与事实
- 事实问答、引用忠实度、时效性和专业知识覆盖
- 重点不是“会不会背”，而是能否在证据约束下回答
- 常见指标：正确率、引用命中、不可回答识别
推理与规划
- 数学、逻辑、代码推理、多步任务和计划修正
- 要区分最终答案正确、过程合理和步骤可执行
- 常见指标：pass@k、步骤成功率、任务完成率
指令遵循与格式
- 角色边界、输出结构、长度约束、语言风格和拒答策略
- 生产里格式错误常常比“智商不够”更先造成故障
- 常见指标：schema 合法率、约束命中率、解析失败率
工具与行动
- 函数选择、参数生成、权限遵守、失败重试和结果整合
- 不是只看最终文字，而要看中间调用链路是否正确
- 常见指标：工具选择准确率、参数合法率、端到端成功率
鲁棒与一致性
- 同义改写、噪声输入、长上下文、边界条件和多轮状态
- 模型不能只在“干净题面”上表现好
- 常见指标：扰动后保持率、拒答稳定性、上下文敏感度
安全与合规
- 有害请求、隐私泄露、越狱、注入、越权工具调用
- 安全评测要同时看放行风险和误伤正常请求
- 常见指标：攻击成功率、误拒率、审计完整率
| 评测资产 | 它包含什么 | 关键设计问题 | 常见坑 |
|---|
| Task | 任务定义、输入类型、输出要求、适用人群 | 到底要测哪种能力，和业务目标如何对应 | 把“聊天好不好”这种模糊目标直接拿来测 |
| Sample | 用户输入、上下文、工具状态、期望行为、元数据 | 样本是否覆盖真实流量、边界条件和高价值场景 | 只收集简单成功样本，忽略失败和长尾 |
| Reference | 标准答案、可接受答案、证据来源或评分要点 | 开放任务是否允许多种正确答案 | 用单一参考答案惩罚合理表达差异 |
| Rubric | 评分维度、扣分规则、严重程度、示例 | 评审者和 Judge 是否能稳定复现口径 | 标准太抽象，导致评分噪声大 |
| Annotation | 人工标签、偏好对、错误类型、风险等级 | 标注人是否理解业务，是否有一致性检查 | 标注质量低，却把标签当真相 |
| Split | 开发集、回归集、隐藏集、红队集、线上抽样集 | 调参、验收和监控是否分开 | 边调边看同一套题，最后过拟合评测集 |
样本不是只有输入和答案
生产 Eval 的样本最好保留任务来源、用户类型、时间、语言、权限、检索材料、工具状态、期望输出和风险标签。没有这些元数据，分数下降时很难知道是哪个人群、哪类任务或哪条链路坏了。人工标签、偏好对和评分口径怎样形成，继续看 人类反馈与标注口径。
| 评测方式 | 适合测什么 | 强项 | 边界 |
|---|
| 精确匹配 / 规则 | 选择题、JSON schema、正则格式、工具参数 | 便宜、稳定、可放进 CI | 不适合开放表达和语义质量 |
| 程序执行 | 代码题、SQL、数据转换、工作流结果 | 直接验证是否能跑通 | 测试用例覆盖不足会漏掉错误 |
| Embedding / 相似度 | 语义接近、召回质量、聚类筛查 | 适合大规模粗筛 | 相似不等于正确，容易被流畅废话骗过 |
| LLM-as-Judge | 开放问答、摘要、风格、忠实度、偏好比较 | 速度快、可批量、能解释评分理由 | 会有偏见、漂移、位置偏好和自信误判 |
| 人工评审 | 业务可用性、高风险输出、复杂偏好、定标样本 | 更贴近真实责任和业务语境 | 成本高、慢，需要标注规范和一致性管理 |
| 用户反馈 | 满意度、留存、转化、任务完成 | 最接近真实价值 | 噪声大，有选择偏差，不能直接替代诊断评测 |
自动评测像传感器
它适合高频、低成本地发现变化，但传感器本身也会有噪声。越关键的指标，越要和人工抽检或线上指标定期校准。
人工评审像定标器
人工不应该只在最后“看几条”，而要参与 rubric 设计、Judge 校准、坏例归因和高风险样本验收。
好评测通常是混合系统
规则判硬约束，程序判可执行结果，Judge 判语义质量，人工判业务风险，线上数据判真实价值。
离线回放
固定样本
→
候选对比
模型 / Prompt / RAG
→
闸门检查
质量 / 安全 / 成本
→
灰度实验
小流量
→
线上 A/B
真实用户
→
监控回流
坏例 / 指标
| 对比项 | 离线 Eval | 线上 A/B |
|---|
| 核心价值 | 可重复、可控、适合上线前回归 | 能验证真实用户行为和业务指标 |
| 主要输入 | Golden Set、坏例集、红队集、历史请求回放 | 真实流量、实验分桶、用户反馈和业务事件 |
| 适合判断 | 改动有没有明显退化，候选方案是否值得灰度 | 用户是否更满意，转化或效率是否真的提升 |
| 风险 | 样本老化、覆盖不足、和真实分布脱节 | 实验污染、用户风险、统计周期长、归因困难 |
| 工程要求 | 版本化样本、固定随机性、可复现 trace、批量评分 | 分流、护栏、回滚、实时监控、业务指标联动 |
二者不是替代关系
离线 Eval 负责“不要把明显坏的东西放出去”，线上 A/B 负责“这个变化在真实世界是否有价值”。只做离线容易自嗨，只做线上则会把用户当测试集。
| 设计点 | 建议做法 | 为什么 |
|---|
| 评分口径 | 把相关性、正确性、忠实度、安全、格式分开打分 | 一个总分很难解释具体退化在哪里 |
| Judge Prompt | 给清晰 rubric、正反例、输出 schema 和不确定选项 | 减少模型凭感觉打分，提高可复现性 |
| 位置偏差 | 做 A/B 输出顺序随机化，或使用成对比较后再汇总 | Judge 可能偏向第一个或第二个答案 |
| 自评偏差 | 避免让同一模型长期评自己的输出 | 模型可能偏好自身风格，导致分数虚高 |
| 校准 | 抽样和人工标签对齐，定期计算一致率 | Judge 是评分器，不是真理本身 |
| 可追踪 | 保存 Judge 模型、Prompt、温度、输入输出和理由 | 评分漂移时可以复盘和重跑 |
Judge 最适合做相对比较
在很多开放任务中，LLM-as-Judge 更适合回答“版本 B 是否比版本 A 更好”，而不是给出一个像物理测量一样绝对可靠的分数。它的价值在批量筛查、趋势监控和候选方案比较；具体偏差和校准方法继续看 LLM-as-Judge、自动评测偏差与校准。
| 专项 | 要测的问题 | 样本设计 | 常见指标 |
|---|
| 幻觉评测 | 模型是否编造事实、引用、数字或不存在的来源 | 可回答题、不可回答题、证据冲突题、过期知识题 | 事实正确率、忠实度、不可回答识别率、引用错误率 |
| 鲁棒评测 | 轻微扰动、噪声、同义改写或长上下文是否导致退化 | 改写样本、错别字、格式噪声、干扰段落、边界长度 | 保持率、扰动敏感度、长上下文成功率 |
| 因果 / 反事实 Eval | 关键条件变化时，输出是否按因果逻辑变化 | 反事实变体、干预对照、混杂控制、同一对象不同条件 | 反事实一致率、因果变量敏感度、伪相关暴露率；底层机制见 因果推理 / 反事实 / 干预 |
| 安全评测 | 是否拒绝危险请求，是否误伤正常请求 | 越狱、提示注入、隐私、危险操作、合规灰区和正常对照组 | 攻击成功率、误拒率、策略一致率、升级人工比例 |
| 工具调用评测 | 是否选对工具、填对参数、处理失败并整合结果 | 单工具、多工具、缺参、权限不足、工具报错、状态变化 | 工具选择准确率、参数合法率、执行成功率、端到端完成率 |
| RAG 评测 | 是否检到证据，答案是否基于证据 | 有证据、无证据、冲突证据、多跳问题、权限隔离样本 | 召回率、重排命中、答案忠实度、引用覆盖率 |
| 多轮对话评测 | 是否保持状态、遵守先前约束、正确修正错误 | 多轮任务、偏好变更、上下文冲突、记忆污染、用户纠错 | 状态保持率、约束遵循率、修正成功率 |
数据污染
- 评测题或答案进入训练数据、微调数据或提示样例
- 结果是模型像“会做题”，但不一定真正泛化
- 需要隐藏集、近似去重、时间切分和污染检测；训练侧配方可继续看 数据配方 / Token 预算
Benchmark Gaming
- 围绕公开题型、评分器或排行榜规则做针对性优化
- 分数提高，但真实用户任务不一定提高
- 需要私有评测、动态样本和线上指标校验；底层机制见 Goodhart 式指标失真
题库老化
- 产品形态、模型能力和用户输入都在变，旧题库会失真
- 长期固定样本容易变成团队共同背熟的“仪式”
- 需要保留核心回归集，同时定期加入新坏例和新任务
| 防护手段 | 解决什么问题 | 注意点 |
|---|
| 训练集 / 评测集隔离 | 避免用见过的题验证模型能力 | 包括 SFT、偏好数据、Prompt 示例和合成数据 |
| 配方切片对照 | 判断某类数据上采样是否只提高局部题型 | 把 Eval 按语言、领域、长度、来源和风险切开，回看 数据配方 |
| 隐藏集与私有集 | 降低公开题库被针对优化的风险 | 隐藏集也要定期更新，且访问受控 |
| 时间切分 | 验证模型对新知识、新分布的适应 | 适合新闻、法规、价格、产品规格等时效场景 |
| 动态生成变体 | 测试鲁棒性和反模板能力 | 生成样本仍需抽检，避免引入错误标签 |
| 坏例回流 | 让评测集跟着真实问题演进 | 坏例要归类、去重、标注严重程度，不是简单堆数据 |
改动提交
模型 / Prompt / RAG
→
离线回归
固定样本
→
红队闸门
安全 / 权限
→
成本延迟闸门
Token / P95
→
人工抽检
高风险样本
→
灰度发布
可回滚
| 闸门 | 典型检查 | 失败时动作 |
|---|
| 质量闸门 | 关键任务不能退化，坏例集不能复发，核心指标达到阈值 | 阻止发布，回到误差分析和样本切片 |
| 安全闸门 | 越狱、注入、隐私、越权工具调用和误拒率 | 补护栏、调策略、升级人工确认或禁用能力 |
| 格式闸门 | JSON / schema 合法率、工具参数合法率、引用格式 | 修 Prompt、加解析修复、降低采样随机性 |
| 成本闸门 | 输入 token、输出 token、工具次数、模型单价和缓存命中 | 压上下文、改路由、设 max tokens 或重做方案 |
| 延迟闸门 | TTFT、总耗时、P95 / P99、工具超时和重试率 | 优化链路、缩短上下文、灰度扩容或回滚 |
| 业务闸门 | 转化、完成率、人工接管率、用户满意度和投诉 | 继续灰度、局部放量或按人群回滚 |
生产闸门的原则
不要让“平均分提升”自动放行所有改动。模型、Prompt、RAG、工具 schema、检索语料、路由策略和安全规则的任何变化，都可能造成回归。可靠流程应该能回答：改了什么、用什么样本测过、哪些切片变差、上线后怎样回滚。评测结果如何进入发布闸门，可继续看 模型评测到发布闸门的一生；评测结果如何进入坏例回流和持续改进，可继续看 反馈闭环 / 数据飞轮。
| 证据节点 | 必须记录的字段 | 用来回答的问题 |
|---|
| 评测计划 | eval_plan_id、target_capability、risk_tier、pass_threshold、blocker_rules | 这次评测到底要证明什么，哪些失败必须阻断发布？ |
| 样本资产 | dataset_version、sample_slice、label_policy、contamination_check、holdout_flag | 样本是否覆盖真实任务、长尾、高风险和未见分布？ |
| 运行记录 | eval_run_id、candidate_version、baseline_version、prompt_version、runtime_config | 分数变化来自模型、Prompt、RAG、采样还是运行环境？ |
| 评分证据 | metric_values、judge_version、human_review_id、disagreement_cases | 分数是否可复核，自动 Judge 和人工是否一致？ |
| 发布结论 | release_gate_id、known_regressions、waiver_reason、rollback_cases | 为什么允许或拒绝上线，哪些风险被带入灰度监控？ |
误区：排行榜第一就是业务最优
排行榜只代表特定 Benchmark 上的表现。业务还要看任务分布、成本、延迟、合规、工具链路、可部署性和团队可控性。
误区：Eval 做一次就够
模型、用户、产品和攻击方式都在变。评测集需要像代码测试一样维护，也需要像产品数据一样持续观察。
误区：Judge 分数就是客观真相
Judge 也是模型，也会偏见、漂移和误判。它适合提高评测吞吐，但需要人工定标和多指标交叉验证。
误区：只测最终答案
RAG、Agent 和工具调用系统要同时测检索、上下文、工具参数、权限、后处理和用户结果。最终答案对了，也可能中间链路不可控。