8.3 评测框架与结果分析

8.3 评测框架与结果分析

本节摘要：评估要跑成体系才有价值。本节讲评测框架的标准化作用（OpenCompass、lm-evaluation-harness 等）、自建场景评测集的方法、人工评估的三种设计与 LLM 裁判管线，最后落到评估的真正产出——错误归类与改进映射，把"评估—改进"闭环转起来。

学习目标

阅读完本节，你应当能够：

1. 说明评测框架解决的三个标准化问题
2. 动手构建一套场景评测集（选题、定标准、防泄漏）
3. 设计人工评估（排序、量表、盲测）并用 LLM 裁判提效
4. 用错误归类法把评估结果翻译成改进动作
5. 在团队里运转"评估—改进"闭环的节奏

一、评测框架：标准化的基础设施

手动跑基准（准备数据、调模型、对答案、算分、出报告）每一步都可能引入不一致，评测框架把整条链路固化下来：

• lm-evaluation-harness：社区使用最广的开源评测框架，覆盖数十个基准，支持本地模型与 API 模型。
• OpenCompass：功能全面的国产开源框架，中英文基准覆盖好，支持多种推理后端与评测模式（基线、对比、裁判）。
• 各类竞技场与榜单平台：把"持续评测"做成服务，提供横向参照系。

框架解决三个问题：口径统一（同一判分逻辑跨模型可比）、过程可复现（配置文件即评测定义，别人能重跑）、成本摊薄（新模型接入只需改配置）。团队内部也建议自建一层"评测配置即代码"——每次发版的评测集版本、提示词模板、判分参数全部入库，半年后还能回答"当时为什么这个分数"。

二、自建评测集：最重要的评估资产

8.1 与 8.2 节反复强调"榜单初筛、自建决断"，这里给出自建方法。一套场景评测集的四步构建法：

第一步：选题。 来源按优先级——真实用户问题日志（脱敏抽样，最有价值）、业务专家列出的典型场景、边界与对抗样例（长输入、歧义指令、诱导性问题、应当拒答的请求）。规模上一两百条起步即可，覆盖度比数量重要。

第二步：定标准。 每题附"判分依据"，三种形态按任务选：标准答案（事实类）、检查清单（质量类，如"包含三个要点、无编造引用、格式合法"）、参考要点（开放类，判覆盖不判措辞）。标准要可执行——另一个评估者拿同一标准能得出一致结论。

第三步：防泄漏。 评测集不入公开仓库、不进训练与微调数据（做数据同步时要显式排除）、定期换新题。这条纪律失败，评测集就从"裁判"退化成"陪练"。

第四步：版本化。 加新题、淘汰过时题都记版本号，跨版本比较时声明口径。线上问题持续脱敏入库（8.1 节的滚动更新），让评测集跟着业务漂移。

这套资产在三个场景直接产出决策：选型（候选模型同集对比）、验收（第 6.3 节微调闭环的测试集）、升级回归（第 7.3 节发版前的质量闸门）——同一份投资，三处复用。

三、人工评估设计与裁判管线

人工评估的三种设计，按信息量递增：

• 打分量表：按维度（有用、准确、安全）打 1–5 分。简单但主观漂移大，量表锚点必须配样例（"3 分长这样"）。
• 两两排序：同一问题下比较两个模型的输出谁更好。相对判断一致性好（RLHF 标注的同一原理），信息量高于打分。
• 盲测：不告知输出来自哪个模型，消除品牌偏见。竞技场模式把它做成了持续运行的大规模实验。

人力贵的现实下，成熟管线是三层漏斗：

全量候选输出
  → 自动指标过滤（格式错误、超长、明显跑题 —— 机器秒筛）
  → LLM 裁判批量评分（按检查清单逐项判，输出分数与理由）
  → 人工复核（只看裁判低分、边界、与上版分歧的样本）
​

裁判提示词的工程要点：给出角色与检查清单、明确"长度与风格不计分"（对抗长度偏差）、要求先给理由再给分（理由可审计）、对比较任务交换顺序跑两次。裁判自身的质量也要校准——抽一批人工判过的样本对照裁判结果，一致性不够就改清单或换裁判模型。

四、错误归类：评估的真正产出

分数只是体检报告的数字，错误分析才是诊断。标准做法是把评测中的失败样本逐条归因，建立"错误类型 → 改进动作"的映射：

归类的价值在于改进动作完全不重叠：知识问题微调解决不了，格式问题 RAG 也帮不上忙——不做归类就改进，等于乱吃药。实际操作中每类错误统计占比，按"占比 × 业务影响"排优先级，形成下一迭代的改进清单。

另一个分析习惯是看长尾不看均值：平均分持平的两个版本，最差 5% 样本的表现可能天差地别，而用户恰恰对最差体验记忆最深。把 P90/P95 表现纳入验收标准，是质量意识的分水岭。

⚠️ 最常见的分析错误：只报总分不拆维度、只看平均不看长尾、只列失败样本不归类原因。三者占其一，评估就从"指南针"退化成"发奖状"。

五、闭环的运转节奏

把前面的组件组装成团队的常态化机制：

• 发版闸门（每次模型/提示词/检索变更）：自建评测集全量跑，安全项一票否决，质量项对比上版不允许回退。
• 持续监控（线上，第 7.3 节）：负反馈率、抽样审查，异常触发评测集回归。
• 季度深检：错误归类全景分析，重排改进路线图，评测集滚动更新。

节奏感来自一个认知：模型、数据、用户分布都在变，评估不是项目期的一次性考试，而是随产品运行的持续仪表盘。

常见问题

问题：评测集和验证集是一回事吗？

不是。验证集服务于训练过程（调超参、判收敛，第 6.3 节），评测集服务于产品决策（选型、发版、回归），后者按真实用户分布构建、永不参与任何训练。混用会导致"为评测集优化"的隐性污染。

问题：LLM 裁判用哪个模型合适？

原则：裁判能力应显著高于被评对象（强模型判弱模型更可靠），且尽量与被评模型不同家族（缓解自我偏好）。关键决策场景用两个不同家族裁判交叉，分歧样本人工裁决。

问题：没有历史日志的冷启动怎么办？

先人工构造：业务专家列典型场景各写几条，加边界样例，几十条也能支撑第一轮选型；上线后立刻开始收集真实问题滚动扩充，一个季度后评测集自然成熟。

五、一个错误归类的实战示范

错误归类听着简单，做到位需要方法。以一次真实感的 RAG 系统回归为例，评测集两百条，失败三十一条，归类过程如下：

第一遍粗分：知识缺失八条（库里有答案但检索没找到的有五条、库里真没有的有三条）、指令不遵六条（要求列点却写成段落）、幻觉编造五条（引用了不存在的条款号）、安全越界两条（把内部折扣规则透露给了普通用户）、其他十类各一二条。

第二遍细查第一大类：五条"检索没找到"里，三条的分块把答案切断了（条款被切在两个块中间），两条是用户用了口语化问法（"过期能退吗"匹配不到"退换货时效条款"）。改进动作随之明确：分块策略改按条款边界、查询侧加同义改写——如果只看总分，这两个修复点根本浮不出来。

第三遍看联动：安全越界的两条都发生在"检索命中内部文档但权限过滤失效"的场景——这不是模型问题，是检索管线的权限漏洞。单独看是安全问题，归到系统层是权限问题，修法完全不同。

示范的要点：归类要两遍起（粗分类、细查因），并允许跨层归属（模型错、检索错、系统错分开统计）。三十一条错误最终指向四个修复点，其中只有半个需要动模型——这就是错误分析的价值：它把钱花在真正的问题上。

补充：让评估结论"可争议"

好的评估文化允许质疑结论。三个实操做法：评估报告必须附"本次评测的局限"段落（覆盖了什么、没覆盖什么、样本量多少）；关键决策（如选型）要求两个独立评测来源相互印证；建立"评估异议"通道，允许任何人用具体样本挑战评测结论，被采纳的异议进入评测集修订。这些做法的出发点是承认评估本身会出错——一个可以被挑战的评估体系，远比一个看似精确的分数体系更值得信任。

常见追问：评估多久跑一次合适？

按变更节奏分层：每次发版（模型、提示词、检索配置任一变更）必跑全量回归；线上监控每日滚动看负反馈与抽样；深度错误归类分析按季度或大版本。另外两个触发点别忘：上游依赖更新时（供应商模型静默升级）立即回归；业务高峰前（大促、开学季等流量形态变化）预防性回归。评估频率跟着"变化"走，而不是跟着日历走。

再追问：评估报告应该给谁看、写成什么样？

给决策者看的版本要短：结论先行（升级还是不升级）、关键指标对比表、风险与遗留问题三段，一页为限。给工程团队的版本要厚：失败样本明细、错误归类统计、复现配置。两份报告同源不同层——从同一份评测数据里切出。常见的失败是把工程版直接甩给决策者，信息过载导致"看不懂所以不决策"，评估的价值就此流失。

本节要点回顾

• 评测框架（lm-eval、OpenCompass）解决口径、复现、成本三问题；团队要做到评测配置即代码。
• 自建评测集四步：真实问题选题、可执行判分标准、防泄漏纪律、版本化——一份投资，选型/验收/回归三处复用。
• 人工评估三法（量表、排序、盲测）+ 三层漏斗管线（自动筛 → 裁判评 → 人工复核），裁判提示词要对抗偏差并做一致性校准。
• 错误归类是评估的真正产出：六类错误对应六种不重叠的改进动作；看长尾不看均值。
• 闭环三节奏：发版闸门、线上监控、季度深检——评估是持续仪表盘，不是一次性考试。

评估体系完工，第 9 章进入应用现场：生成、理解、代码、多模态与行业落地的架构与打法。