评测样例治理专题

版本：v1.1
最后更新：2026-07-06
适用对象：负责 AI 评测、模型回归、Prompt 迭代、线上失败样例回流、数据标注和评测平台建设的算法、平台、产品、运营与质量团队。

1. 为什么需要评测样例治理

很多团队开始做 eval 后，很快会遇到新的问题：

样例越来越多，却越来越乱
新旧样例混在一起，没人知道哪些还有效
每次评测结果变动，都说不清是模型变了、Prompt 变了，还是样例集变了
线上失败样例没有沉淀，下一次版本升级又踩同样的坑
一批样例反复被开发人员看见，逐渐变成“训练答案”，失去真实评测价值
指标看起来稳定，但样例覆盖不到真正高风险场景

评测样例治理的目标不是追求样例数量，而是让样例集长期保持：

代表真实业务
覆盖关键风险
期望结果清晰
版本可追溯
质量可审核
生命周期可管理

OpenAI 的 eval 文档强调，评测要围绕真实任务定义输入、期望输出和评分方式；MLflow/Databricks 的 GenAI evaluation dataset 实践也强调把 request、response、expectations、source、tags 等字段结构化管理。评测样例治理就是把这些原则落到日常工程流程里。

2. 什么是评测样例治理

评测样例治理可以理解为：

不只收集评测样例，还要管理样例的来源、标签、期望结果、风险等级、版本、质量、使用范围和生命周期

它回答的问题包括：

这个样例从哪里来
它代表什么业务场景
它验证哪类能力或风险
期望输出是什么
谁审核过这个期望
它适用于哪些模型、Prompt 或策略版本
它是否仍然有效
它是否被污染或过度曝光

没有治理的 eval 很容易变成“样例堆积”；有治理的 eval 才能成为可靠的质量资产。

3. 评测样例的核心价值

样例不是为了让评测报告看起来更完整，而是服务 5 件事。

3.1 定义质量标准

样例让“什么叫好”变得具体。

例如：

RAG 问答必须基于证据
信息抽取不能补全不存在字段
高风险请求必须升级人工
JSON 输出必须符合 schema

没有样例，质量标准容易停留在口号。

3.2 防止回归

历史失败样例进入回归集后，可以防止同类问题再次出现。

例如：

某次版本曾经误放高风险请求
某次 Prompt 修改导致 JSON 缺字段
某次模型升级后引用错位

这些都应该沉淀成回归样例。

3.3 支撑模型和 Prompt 对比

同一批样例可以对比：

不同模型
不同 Prompt
不同检索策略
不同工具 schema
不同安全规则

前提是样例集稳定且版本清楚。

3.4 支撑上线门禁

样例集可以变成发布门禁：

高风险样例必须全部通过
JSON schema 通过率必须达标
误放率不能上升
关键业务场景不能退化

3.5 支撑故障复盘

线上事故复盘后，如果失败样例没有进入评测集，复盘就只完成了一半。

4. 哪些样例最值得优先治理

不是所有样例价值一样高。优先治理高风险、高频、高影响样例。

4.1 真实线上失败样例

优先级最高。

包括：

用户投诉样例
人工纠错样例
事故复盘样例
申诉成功样例
业务指标异常对应样例

这些样例直接代表系统真实短板。

4.2 高风险边界样例

例如：

越权请求
敏感数据外发
高风险工具调用
资金操作
法务或合规风险
提示注入

这些样例数量可能不多，但治理价值很高。

4.3 高频业务场景样例

例如：

客服意图分类
知识库问答
工单路由
摘要生成
信息抽取

高频场景决定整体体验和成本。

4.4 版本切换样例

模型、Prompt、检索策略或工具协议升级后新增的问题，应进入版本切换样例池。

4.5 人工分歧样例

如果审核人之间经常分歧，说明规则边界不清。

这些样例适合用来：

修订标注指南
细化业务规则
训练审核人一致性
补充 few-shot 示例

5. 样例分层：不要所有样例挤在一起

建议把样例分成 4 层。

5.1 基线样例

作用：

稳定代表核心能力
用于日常 smoke test
每次改动都要跑

特点：

数量不需要太大
质量必须高
期望结果非常明确
不应频繁变化

5.2 回归样例

作用：

防止历史问题再次发生

来源：

线上失败
事故复盘
版本升级回归
用户投诉

特点：

价值高
需要保留失败背景
应绑定修复版本

5.3 边界样例

作用：

测试规则边界和极端输入

包括：

信息不足
证据冲突
多意图
低质量输入
提示注入
越权请求

特点：

不一定代表日常流量
但能暴露系统韧性

5.4 探索样例

作用：

验证新场景、新模型、新能力

特点：

允许频繁变化
不一定进入正式门禁
需要评审后才能转入基线或回归集

6. 每条评测样例应该记录什么

样例治理的基础是结构化字段。

6.1 推荐字段

json

{
  "case_id": "rag-qa-20260706-001",
  "task": "rag_qa",
  "input": {
    "question": "如何申请退款？",
    "context": ["文档片段 1", "文档片段 2"]
  },
  "expected": {
    "answer_type": "insufficient_evidence",
    "must_mention": ["当前资料不足以确认退款期限"],
    "must_not_mention": ["7 天无理由退款"]
  },
  "rubric": "只能基于提供资料回答，证据不足时必须拒答",
  "source": {
    "type": "production_failure",
    "ticket_id": "masked-ticket-id",
    "date": "2026-07-06"
  },
  "tags": ["rag", "insufficient_evidence", "refund"],
  "risk_level": "medium",
  "owner": "ai-platform",
  "status": "active",
  "created_at": "2026-07-06",
  "updated_at": "2026-07-06",
  "valid_from": "prompt_v1.3",
  "valid_until": null
}

6.2 字段解释

字段	作用
case_id	唯一标识，便于追踪
task	任务类型，便于分组统计
input	模型输入或系统输入
expected	期望结果或判定标准
rubric	人工评分或自动评分规则
source	样例来源
tags	场景、风险、失败类型标签
risk_level	风险等级
owner	维护负责人
status	active、candidate、deprecated
valid_from	从哪个版本开始适用
valid_until	失效版本或时间

7. 期望结果怎么写

很多 eval 失效，是因为只有输入，没有清晰期望。

7.1 分类任务

期望结果应包含：

正确类别
允许的等价类别
不允许的类别
判定依据

示例：

json

{
  "expected_label": "finance",
  "allowed_labels": ["finance"],
  "forbidden_labels": ["sales", "support"],
  "reason": "用户明确提到发票和付款"
}

7.2 信息抽取任务

期望结果应包含：

字段值
缺失字段
证据片段
是否允许部分匹配

7.3 RAG 问答任务

期望结果应包含：

必须提到的事实
不允许编造的事实
证据来源
资料不足时的拒答要求

7.4 生成类任务

生成任务很难只有一个标准答案，需要 rubric。

评分维度可以包括：

事实正确
风格匹配
结构完整
不编造
不违反安全规则
可读性

8. 样例版本化

样例也需要版本化，否则无法解释指标变化。

8.1 为什么需要版本

评测结果变化可能来自：

模型变化
Prompt 变化
样例变化
标签变化
rubric 变化
数据预处理变化

如果样例集没有版本，就无法判断到底是哪一项导致指标波动。

8.2 版本命名建议

text

evalset_{task}_{major}.{minor}.{patch}

例如：

text

evalset_rag_qa_2.1.0
evalset_ticket_routing_1.4.2
evalset_tool_calling_3.0.0

8.3 什么时候升版本

变更	版本建议
新增少量样例	patch
修正标签或期望结果	patch 或 minor
大规模新增场景	minor
评分规则变化	minor 或 major
样例结构大改	major
删除大量样例	major

8.4 版本记录要写什么

每次变更至少记录：

变更原因
新增样例数
删除样例数
修改标签数
影响的任务
是否影响历史指标对比
审核人

9. 样例生命周期

样例不应该一旦加入就永远有效。

9.1 候选池

来源：

线上失败
人工反馈
红队测试
产品新增场景

状态：

candidate

要求：

暂不进入正式门禁
需要补齐期望结果和标签
需要评审

9.2 正式集

状态：

active

要求：

期望结果明确
标签完整
通过评审
可以进入 CI 或发布门禁

9.3 观察集

状态：

watch

适合：

新场景
结论尚不稳定
人工分歧较大

这些样例可以跑，但不一定影响发布。

9.4 废弃集

状态：

deprecated

废弃原因：

业务规则变了
产品功能下线
样例重复
期望结果已不适用
输入数据不可再使用

废弃样例不要直接删除，最好保留记录，避免历史指标无法解释。

10. 样例质量门禁

样例进入正式集前要过质量门禁。

10.1 必填检查

是否有唯一 case_id
是否有任务类型
是否有输入
是否有期望结果
是否有来源
是否有标签
是否有风险等级
是否有 owner

10.2 内容检查

输入是否可复现
期望结果是否清楚
标签是否准确
是否包含敏感信息
是否与其他样例重复
是否仍符合当前业务规则

10.3 评审检查

高风险样例建议至少双人评审。

需要特别评审：

安全样例
合规样例
资金操作样例
权限相关样例
对外发送样例

11. 样例污染与泄漏

评测样例可能被污染。

常见污染方式：

开发人员反复查看测试答案
样例被用于 Prompt few-shot
样例进入微调数据
样例被复制到公开文档
模型供应商可能见过公开 benchmark

11.1 污染的风险

污染后，评测结果会虚高。

模型可能不是学会了任务，而是见过答案。

11.2 防控方式

区分训练集、示例集、评测集
高价值评测集限制访问
不把正式评测样例放进 Prompt
维护隐藏测试集
定期新增新鲜线上样例
对公开样例和私有样例分开统计

12. 样例标签体系

标签是治理的核心。

12.1 基础标签

建议包含：

task：任务类型
scenario：业务场景
risk_level：风险等级
source：来源
language：语言
modality：文本、图片、音频、视频
status：生命周期状态

12.2 失败类型标签

常见标签：

hallucination
format_error
missing_field
wrong_tool
unsafe_allow
over_refusal
citation_error
insufficient_evidence
prompt_injection
permission_violation

12.3 标签治理原则

标签不要无限膨胀
标签含义要有说明
标签变更要记录版本
指标报表要能按标签聚合
每个标签最好有典型样例

13. 样例回流流程

线上失败样例要进入闭环。

推荐流程：

text

线上失败 / 人工纠错 / 用户投诉
 -> 进入候选池
 -> 脱敏
 -> 标注期望结果
 -> 打标签和风险等级
 -> 评审
 -> 进入回归集或观察集
 -> 后续版本持续回归

13.1 脱敏

需要处理：

姓名
手机号
邮箱
身份证
地址
订单号
合同编号
企业内部链接
密钥或 token

13.2 标注

标注时要记录：

正确答案
判定依据
不允许出现的内容
风险等级
是否需要人工复核

13.3 评审

评审重点：

样例是否真实有效
期望结果是否明确
是否值得进入长期回归
是否需要归入高风险门禁

14. 样例目录结构建议

小团队可以用文件管理，大团队建议进入评测平台或数据集管理系统。

文件结构示例：

text

evals/
  rag_qa/
    evalset_rag_qa_2.1.0/
      cases.jsonl
      rubric.md
      changelog.md
      README.md
  ticket_routing/
    evalset_ticket_routing_1.4.2/
      cases.jsonl
      labels.yaml
      review-notes.md

每个数据集至少包含：

cases.jsonl
rubric.md
changelog.md
README.md

15. 样例治理与工程流程

15.1 CI 门禁

适合进入 CI 的样例：

基线样例
高风险回归样例
schema 稳定性样例
工具调用关键样例

不一定适合 CI 的样例：

探索样例
人工评分样例
成本很高的长上下文样例

15.2 发布门禁

发布前应跑：

基线集
回归集
高风险集
本次变更相关场景集

15.3 周期性评审

建议每月或每季度评审：

是否有过期样例
是否有重复样例
是否有标签混乱
是否有新场景缺口
是否有线上失败未回流

16. 常见反模式

16.1 所有样例堆在一个文件里

问题：

无法分层、分场景、分风险统计

修正：

按任务、场景、风险、生命周期拆分

16.2 只有输入没有期望结果

问题：

无法自动评测，也无法人工一致评分

修正：

为每条样例补 expected 和 rubric

16.3 线上失败没有回流

问题：

同类问题会反复出现

修正：

建立失败样例候选池和评审流程

16.4 样例不版本化

问题：

指标波动无法归因

修正：

样例集版本和变更日志必须记录

16.5 样例被 Prompt 或训练污染

问题：

评测结果虚高

修正：

区分训练、示例和评测样例，维护隐藏集

17. 落地检查清单

17.1 样例结构

是否有 case_id
是否有 task
是否有 input
是否有 expected
是否有 rubric
是否有 source
是否有 tags
是否有 risk_level
是否有 status

17.2 样例分层

是否区分基线样例
是否区分回归样例
是否区分边界样例
是否区分探索样例
是否有高风险样例集

17.3 版本与变更

是否为样例集打版本
是否记录样例变更原因
是否记录新增、删除、修改数量
是否能解释历史指标变化

17.4 质量与安全

是否做重复检测
是否做敏感信息脱敏
是否限制高价值评测集访问
是否避免评测样例进入训练或 Prompt
是否定期清理过期样例

18. 推荐搭配阅读

19. 推荐资料

以下资料在 2026-07-06 检查时可访问。

官方文档

OpenAI Evals：https://developers.openai.com/api/docs/guides/evals
OpenAI Evaluation best practices：https://developers.openai.com/api/docs/guides/evaluation-best-practices
OpenAI Evals GitHub：https://github.com/openai/evals
MLflow GenAI Evaluation：https://mlflow.org/docs/latest/genai/eval-monitor/
Databricks Evaluation datasets：https://docs.databricks.com/en/generative-ai/agent-evaluation/evaluation-datasets.html
DVC Data Versioning：https://dvc.org/doc/use-cases/versioning-data-and-model-files

20. 一句话总结

评测样例治理的核心不是攒更多测试数据，而是把样例变成有来源、有标签、有期望、有版本、有生命周期的质量资产，让每次模型、Prompt、检索或策略变更都能被稳定、可追溯地验证。

评测样例治理专题 ​

1. 为什么需要评测样例治理 ​

2. 什么是评测样例治理 ​

3. 评测样例的核心价值 ​

3.1 定义质量标准 ​

3.2 防止回归 ​

3.3 支撑模型和 Prompt 对比 ​

3.4 支撑上线门禁 ​

3.5 支撑故障复盘 ​

4. 哪些样例最值得优先治理 ​

4.1 真实线上失败样例 ​

4.2 高风险边界样例 ​

4.3 高频业务场景样例 ​

4.4 版本切换样例 ​

4.5 人工分歧样例 ​

5. 样例分层：不要所有样例挤在一起 ​

5.1 基线样例 ​

5.2 回归样例 ​

5.3 边界样例 ​

5.4 探索样例 ​

6. 每条评测样例应该记录什么 ​

6.1 推荐字段 ​

6.2 字段解释 ​

7. 期望结果怎么写 ​

7.1 分类任务 ​

7.2 信息抽取任务 ​

7.3 RAG 问答任务 ​

7.4 生成类任务 ​

8. 样例版本化 ​

8.1 为什么需要版本 ​

8.2 版本命名建议 ​

8.3 什么时候升版本 ​

8.4 版本记录要写什么 ​

9. 样例生命周期 ​

9.1 候选池 ​

9.2 正式集 ​

9.3 观察集 ​

9.4 废弃集 ​

10. 样例质量门禁 ​

10.1 必填检查 ​

10.2 内容检查 ​

10.3 评审检查 ​

11. 样例污染与泄漏 ​

11.1 污染的风险 ​

11.2 防控方式 ​

12. 样例标签体系 ​

12.1 基础标签 ​

12.2 失败类型标签 ​

12.3 标签治理原则 ​

13. 样例回流流程 ​

13.1 脱敏 ​

13.2 标注 ​

13.3 评审 ​

14. 样例目录结构建议 ​

15. 样例治理与工程流程 ​

15.1 CI 门禁 ​

15.2 发布门禁 ​

15.3 周期性评审 ​

16. 常见反模式 ​

16.1 所有样例堆在一个文件里 ​

16.2 只有输入没有期望结果 ​

16.3 线上失败没有回流 ​

16.4 样例不版本化 ​

16.5 样例被 Prompt 或训练污染 ​

17. 落地检查清单 ​

17.1 样例结构 ​

17.2 样例分层 ​

17.3 版本与变更 ​

17.4 质量与安全 ​

18. 推荐搭配阅读 ​

19. 推荐资料 ​

官方文档 ​

20. 一句话总结 ​

评测样例治理专题

1. 为什么需要评测样例治理

2. 什么是评测样例治理

3. 评测样例的核心价值

3.1 定义质量标准

3.2 防止回归

3.3 支撑模型和 Prompt 对比

3.4 支撑上线门禁

3.5 支撑故障复盘

4. 哪些样例最值得优先治理

4.1 真实线上失败样例

4.2 高风险边界样例

4.3 高频业务场景样例

4.4 版本切换样例

4.5 人工分歧样例

5. 样例分层：不要所有样例挤在一起

5.1 基线样例

5.2 回归样例

5.3 边界样例

5.4 探索样例

6. 每条评测样例应该记录什么

6.1 推荐字段

6.2 字段解释

7. 期望结果怎么写

7.1 分类任务

7.2 信息抽取任务

7.3 RAG 问答任务

7.4 生成类任务

8. 样例版本化

8.1 为什么需要版本

8.2 版本命名建议

8.3 什么时候升版本

8.4 版本记录要写什么

9. 样例生命周期

9.1 候选池

9.2 正式集

9.3 观察集

9.4 废弃集

10. 样例质量门禁

10.1 必填检查

10.2 内容检查

10.3 评审检查

11. 样例污染与泄漏

11.1 污染的风险

11.2 防控方式

12. 样例标签体系

12.1 基础标签

12.2 失败类型标签

12.3 标签治理原则

13. 样例回流流程

13.1 脱敏

13.2 标注

13.3 评审

14. 样例目录结构建议

15. 样例治理与工程流程

15.1 CI 门禁

15.2 发布门禁

15.3 周期性评审

16. 常见反模式

16.1 所有样例堆在一个文件里

16.2 只有输入没有期望结果

16.3 线上失败没有回流

16.4 样例不版本化

16.5 样例被 Prompt 或训练污染

17. 落地检查清单

17.1 样例结构

17.2 样例分层

17.3 版本与变更

17.4 质量与安全

18. 推荐搭配阅读

19. 推荐资料

官方文档

20. 一句话总结