评测集不是"一堆问题"，是"测试资产"------30 条结构化评测集（E02）
系列《AI 应用生产化手册》第 2 篇（共 30 篇）｜配套开源项目：github.com/ChenYingbo/...
一、先看三个问题
E01 我们手工问了 10 个问题，很快发现三个问题：
- 这 10 个问题是"随手想"的------凭什么代表真实用户会问的东西？改天线上用户问的，评测集里根本没有。
- 没法回答"覆盖了哪些能力"------领导问"评测覆盖全面吗"，你只能答"还行吧"。
- 评分是即兴的------同一个答案，昨天打 4 分今天打 3 分，标准漂移。
解法只有一个：把"随手问"升级为"结构化评测集"------有字段、有分类、有难度分层、有边界 case、有标注规范。
核心认知：评测集不是"一堆问题"，而是"一份经过设计的测试资产"。它决定了你的评测体系能测出什么、漏掉什么。
二、原理：四个设计维度
评测集设计四原则
| 原则 | 含义 | 反面教材 |
|---|---|---|
| 多样性 | 覆盖不同问题类型（定义/对比/代码/流程...） | 全是"什么是 X" |
| 难度分层 | 简单/中等/困难按比例分布 | 全是简单题，测不出退化 |
| 边界 case | 刻意放"会翻车"的问题 | 全是"标准答案题" |
| 可标注 | 每题有预期/评分依据 | 只有问题没有标准 |
四大来源（按真实度排序）
真实日志采样（最真实，最贵）
↓ 脱敏 + 挑选
人工标注（专业标注员/领域专家）
↓ 标注规范
LLM 辅助扩写（快速量产，需人工校验）
↓ 防重复
合成数据（覆盖边角，质量最低，需严格校验）原则：能采真实就采真实，合成数据只用来补边角，且必须人工过一遍。
黄金集 vs 演进集
| 黄金集（Golden Set） | 演进集（Evolving Set） | |
|---|---|---|
| 用途 | 回归门禁的稳定基线（E04） | 随线上反馈持续扩充（P30 数据飞轮） |
| 特点 | 数量少、质量高、几乎不变 | 持续追加、标注随业务演进 |
| 变更 | 只在重大里程碑评审后更新 | 每轮迭代都可增删 |
常见误解：评测集是"建一次用永远"。错------黄金集保底防退化，演进集跟进业务，两者缺一不可。
结构化字段（为什么评测集要带字段）
不带字段的评测集 = 问题列表；带字段的评测集 = 可分析的资产：
| 字段 | 作用 |
|---|---|
id |
追踪、关联评测报告 |
category |
按能力域统计覆盖（factual/procedural/coding/...） |
difficulty |
难度分布、回归时分层看退化 |
boundary |
标记边界 case，单独统计"翻车率" |
expectation |
标注/判分依据，保证评分一致性 |
notes |
设计意图，防后人（自己）看不懂 |
有了字段，评测报告才能回答"哪类问题在退化"------这是评测驱动改进的前提。
三、动手：30 条结构化评测集
配套项目已交付 30 条评测集初稿（可直接用，也可按你的业务调整）：
bash
git clone https://github.com/ChenYingbo/ai-prod-demo.git && cd ai-prod-demo
# 查看评测集
cat eval/e02_eval_set.json | python3 -m json.tool | head -20
# 统计覆盖情况（类别/难度/边界）
python3 - <<'EOF'
import json, collections
data = json.load(open('eval/e02_eval_set.json', encoding='utf-8'))
print('总数:', len(data))
print('类别:', dict(collections.Counter(d['category'] for d in data)))
print('难度:', dict(collections.Counter(d['difficulty'] for d in data)))
print('边界:', sum(1 for d in data if d['boundary']))
EOF本评测集的设计（30 条构成）
| 类别 | 数量 | 说明 |
|---|---|---|
| factual（事实/概念） | 8 | 定义类、对比类、流程类、安全概念 |
| procedural（流程步骤） | 4 | 构建 RAG、上线检查、评测方法、重试机制 |
| coding（代码） | 4 | 调用接口、sqlite、日期、HTTP 客户端 |
| comparative（对比判断） | 4 | RAG vs 微调、缓存对比、离线 vs 在线、单体 vs 多 Agent |
| boundary（边界 case） | 8 | 全系列安全底线：拒绝编造/拒答/防注入/缺上下文澄清/无记忆说明 |
| hard（深度长尾） | 2 | 技术深问、架构理解 |
难度分布：简单 6 / 中等 15 / 困难 9------故意让"困难 + 边界"占 57%，因为评测的使命是抓退化，不是晒正确率。
基于 E01 结果的自检（关键一步）
拿 E01 的 10 问打分结果对照本评测集，回答：
- E01 里答得差的问题，在本评测集的哪一类？------如果集中在 boundary，说明系统缺"拒答/澄清"能力（这是评测集设计要暴露的）
- 哪几类完全没有覆盖到？------比如 E01 没有代码题、没有注入题，本评测集补上了
- 有没有重复/无效问题？------删掉，评测集宁缺毋滥
四、真实踩坑（含配套项目实测）
- 幸存者偏差：只收集"模型答得好"的问题当评测集------评测集是找问题的，不是证明它能干的
- 边界 case 太少：90% 是标准题，翻车场景一个没测------边界 case 占比建议 ≥20%
- 评测集泄漏：评测问题出现在系统提示词/知识库里 = 开卷考试（合成数据环节最易发生）
- 标注规范缺失：没有 expectation/rubric，两个评分的人标准不一样，报告没法比较
- 数量崇拜：追求 1000 条而每条粗制滥造------30 条高质量 > 1000 条噪音
- 黄金集随便改：每次心情好就加几题，回归基线漂移------黄金集要"锁死"
- （实测）边界 case 的判分要单独设计：本套评测集真实跑分时发现，naive 判分器会把"安全拒答"判成"没回答问题"------注入题明明被正确拦截了却判 FAIL，需要给边界 case 加规则判分
- （实测）评测集要能暴露定位缺口 ：无知识库时模型会编造报销流程（幻觉）------评测集把它暴露出来，正是 RAG 要解决的方向
这套 30 条评测集在配套项目上用真实模型（DeepSeek）跑出了 29/30（97%），门禁 0.8 通过------评测集本身也经过了两轮校准（详见 E03）。
五、小结
- 四原则：多样性 / 难度分层 / 边界 case / 可标注
- 黄金集锁死防退化，演进集持续扩------标尺不能动
- 带字段的评测集才是资产：能回答"哪类问题在退化"
明天（E03）：《评测执行框架》------用 DeepEval 跑评测集，对比 LLM-as-judge 与规则判分（含真实的"安全拒答被判错"校准实录）。 收藏 + 关注，每天一篇，30 天把 AI 应用送上生产。