评测数据集构建

摘要：公开基准（MMLU/GSM8K）饱和且易污染，做产品决策最该建的是"自己业务的私有黄金集"。本文给出 JSONL 结构、expected 用 rubric 而非标准答案、200–500 条规模经验、60/20/20 来源配比、标签切片、冻结与版本化，以及 PII 脱敏红线。这是整个评测体系里投入产出比最高的一步。

核心概念

为什么黄金集是最高杠杆动作

公开基准只能告诉你"模型能力基线"，而你的产品问题千差万别。一套反映真实流量的私有集，能让你每次改 prompt / 模型 / 切分策略时，得到"对业务是否变好"的可比信号。内容来自 production 评测实践（见 mangodeveloper.com 指南）。

关键原则：expected 是"量规（rubric）"，不是逐字标准答案。 你测的是行为，不是字符串匹配。

数据结构（JSONL）

每行一条，字段含输入、可选上下文、rubric 级期望、标签与难度：

json

{"id": "support_001", "input": "如何取消订阅？", "context": ["KB: 取消订阅", "KB: 退款政策"], "expected": "引用退款窗口，走取消流程，提供暂停替代方案。", "tags": ["billing", "policy"], "difficulty": "easy"}
{"id": "support_002", "input": "同一订单被扣了两次款。", "context": ["KB: 重复扣款"], "expected": "先确认问题，索要卡号后4位，说明5-7天退款时效。", "tags": ["billing", "escalation"], "difficulty": "medium"}

字段说明

id：唯一，便于追溯与去重。
input：用户真实 input（脱敏后）。
context：RAG 场景的检索上下文（可选）。
expected：rubric 式描述，定义"好答案应做到什么"，而非唯一正确文本。
tags：topic / difficulty / intent，用于切片分析（聚合分数会掩盖回归）。
difficulty：用于分桶与能力/回归评估区分。

规模与来源配比

规模经验（来自实践指南）

200–500 条是甜点：低于 100 条统计噪声主导；高于 1000 条标注成本陡增、边际信号下降。
60% 来自真实生产流量（PII 已剥离）、20% 来自你见过的失败边缘案例、20% 来自对抗/红队。
每条必须带 tags，否则聚合分数会掩盖某类意图的回归。

操作步骤：构建与维护

1. 从生产流量抽样本并脱敏

bash

# 从日志/数据仓库抽近期样本（示意，按你的存储替换）
# 关键：抽取后先过 PII 识别再入库
python scripts/sample_production.py --days 30 --n 300 --out raw/sample.jsonl
python scripts/strip_pii.py --in raw/sample.jsonl --out golden/prod_$(date +%F).jsonl

PII 脱敏是入库前强制步骤

生产流量含姓名、电话、邮箱、订单号等。入库前必须识别并脱敏（见 online-monitor.md 的 PII 掩码）。一旦明文进入评测集，即构成数据泄露事件。

2. 版本化与冻结

bash

# 用 git 管理评测集，每次评测记录数据集 SHA
git add golden/ && git commit -m "golden set 2026-10-09: 320 cases"
git rev-parse HEAD   # 记录本次评测使用的数据集 SHA

冻结后只增不改

集子冻结后只能新增样本，不能修改旧样本来"美化"新模型分数。改旧样本等于作弊，会让回归失去意义。每次评测运行都记录数据集 SHA，保证可复现。

3. 接入 CI 回归

python

# ci_eval.py 伪代码骨架
import json, subprocess, sys

baseline = load_baseline("baseline_scores.json")   # 历史稳定版本分数
result = run_eval("golden/prod_2026-10-09.jsonl")  # 跑 Ragas / LLM-Judge

for dim in baseline:
    drop = baseline[dim] - result[dim]
    if drop > 0.10:   # 相对基线下降 >10% 即红 flag
        print(f"REGRESSION in {dim}: {drop:.2%}")
        sys.exit(1)

验证

切片验证：不只看总分，按 tags 看每个维度。某类意图跌了但总分没跌，是典型"聚合掩盖回归"。
人工抽检：每季度抽 50–100 条复核 expected rubric 是否合理，过时的 rubric 会误导 judge。
漂移检查：若某 tag 长期 100% 通过，说明该部分已"毕业"为回归项，可移入更严格集或降低采样。

回滚 / 清理

评测集是数据资产，不做物理删除，误加的样本用新提交"废弃标记"而非改写历史（保证 SHA 可追）。
旧的评测 JSON 结果按日期归档，便于回溯某次发布对应的数据集版本。

故障排查

现象	原因	处理
总分没变但用户投诉变多	聚合掩盖了某 tag 回归	强制按 tag 切片报告
judge 与人工不符	`expected` rubric 太松/歧义	重写下 rubric，做 Kappa 校准（见 auto-human.md）
分数莫名上升	有人改了旧样本	查 git history，确认是否违反"冻结"
样本量不足噪声大	<100 条	补充至 200+ 再下结论

安全与合规

数据泄露与合规红线

脱敏前置：明文 PII 入库即泄露，必须在抽取后、入库前完成识别与脱敏。
最小保留：仅保留评测必需字段，context 含机密时做脱敏或合成化。
访问控制：评测集按敏感级别设访问权限，避免全员可读生产语义数据。
合规留存：遵循 GDPR/个保法的最短留存原则，过期样本标记废弃。

成本 / 性能

构建成本：主要是人工标注与审核，单次 200–500 条的中等投入；后续维护为增量。
运行成本：黄金集跑 Ragas / LLM-Judge 的成本见 ragas.md、auto-human.md；规模远小于公开基准，可控。
收益：相比反复人工回归，CI 自动回归把"是否变坏"的检测从天级降到分钟级，是最高 ROI 的一步。

评测数据集构建 ​

核心概念 ​

数据结构（JSONL） ​

规模与来源配比 ​

操作步骤：构建与维护 ​

1. 从生产流量抽样本并脱敏 ​

2. 版本化与冻结 ​

3. 接入 CI 回归 ​

验证 ​

回滚 / 清理 ​

故障排查 ​

安全与合规 ​

成本 / 性能 ​

参考资料 ​