Wiki Notes

Appearance

数据集构建与标注专题 ​

版本：v1.1

最后更新：2026-07-08

适用对象：正在做 Prompt 应用、RAG、Agent、结构化提取、语音、多模态评测、模型优化，以及需要把“线上问题如何沉淀为可复用数据资产”制度化的产品、算法、平台与评测同学

很多 AI 项目效果不稳定，不是模型不够强，而是数据集建设停留在：

  • 几个 demo 样例
  • 一张 Excel 表
  • 一次性人工标注

真正决定系统上限的往往是：

  • 样本是否覆盖真实业务分布
  • 标注规则是否一致
  • 失败样例是否被长期留存
  • 数据版本是否可追踪
  • 数据集是否真的能服务上线决策

所以这篇专题不把“数据集”理解成一个文件，而是把它当成 AI 平台最重要的长期资产之一。

1. 为什么数据集建设不是附属工作，而是主线工作 ​

无论你做的是：

  • Prompt 应用
  • RAG
  • Agent
  • 结构化抽取
  • 语音助手
  • 多模态识别

最终都会回到同一个问题：

  • 你怎么知道系统现在真的更好了

如果没有稳定数据集，团队就只能靠：

  • 几次演示
  • 主观感受
  • 线上用户反馈

来判断质量。

这种方式在原型期还勉强可用，但到了持续迭代阶段就会非常危险：

  • 一次改 Prompt 可能让旧场景退化
  • 一次换模型可能让边界样例失守
  • 一次改工具策略可能引入新的越权或误调用

所以数据集建设本质上是在回答：

  • “我们用什么证据来做模型、Prompt、工具和策略决策”

2. 先明确：数据集不是只有“训练集” ​

企业 AI 场景最容易犯的错误之一是把所有样本都混成一个大池子。

更实用的分法通常至少包括：

2.1 训练 / 优化数据 ​

用于：

  • SFT
  • RFT
  • Prompt 优化
  • 检索优化
  • 路由阈值调优

2.2 评测数据 ​

用于：

  • 离线回归
  • 模型对比
  • 发布门禁
  • 场景验收

2.3 失败样例数据 ​

用于：

  • 事故复盘
  • 回归补齐
  • 失效模式分析

2.4 红队与安全数据 ​

用于：

  • 越权
  • prompt injection
  • 敏感内容
  • 工具滥用
  • 高风险边界

2.5 人工复核与审查数据 ​

用于：

  • 审批一致性校验
  • 质检抽样
  • 标注冲突仲裁

如果这些数据用途不分开，后面通常会同时出现：

  • 训练污染
  • 评测失真
  • 决策不可复现

3. 一个好数据集真正要满足什么 ​

很多人会先问“数据量大不大”，但在企业项目里更重要的是：

3.1 代表性 ​

  • 是否覆盖真实业务分布
  • 是否包含高频任务

3.2 边界性 ​

  • 是否包含高风险样例
  • 是否包含难例、歧义例、冲突例

3.3 可判定性 ​

  • 是否能定义什么叫通过
  • 是否能写成标注规则或 grader

3.4 可维护性 ​

  • 是否有 owner
  • 是否能持续更新
  • 是否有版本记录

3.5 可追溯性 ​

  • 样例从哪来
  • 为什么被加入
  • 属于哪类失败模式

如果没有这些，即使数据很多，也很难变成真正的工程资产。

4. 样本从哪里来，决定了这套数据到底值不值钱 ​

最推荐优先收集的来源通常有四类：

4.1 线上真实案例 ​

最有价值，因为最接近真实使用分布。

但要处理：

  • 脱敏
  • 权限
  • 数据保留策略

4.2 历史业务记录 ​

例如：

  • 工单
  • FAQ
  • 规则问答
  • 审批记录
  • 文档审查结果

这类数据很适合做初始数据池。

4.3 人工构造难例 ​

用于补：

  • 边界场景
  • 长尾风险
  • 极端输入
  • 故意攻击样例

4.4 合成数据 ​

根据 OpenAI 当前 cookbook 与 evals 文档在 2026-07-08 的说明，合成数据仍然是非常常见的冷启动手段。

它适合：

  • 快速扩展场景覆盖
  • 补齐稀缺样本
  • 构造对抗样例

但要注意：

  • 合成数据不能完全替代真实数据
  • 合成数据要被标记来源
  • 不能让训练集和评测集一起被同一套合成逻辑污染

5. 标注真正难的不是“写答案”，而是“定义判定规则” ​

标注工作最常被低估的部分，是判定标准。

一个成熟的标注规范通常至少要回答：

  • 标注目标是什么
  • 哪些输出算正确
  • 哪些输出算部分正确
  • 多答案是否允许
  • 无法判断时怎么办
  • 引用错误但结论正确算不算通过
  • 工具调用顺序错误但结果正确算不算通过

如果这些问题没有在前面写清楚，后续通常会出现：

  • 同一样本不同人给出不同标签
  • 模型改进与否无法稳定判断
  • 数据越标越多，结论却越来越不可信

6. 数据集要按场景和风险分层，而不是只做“一张大表” ​

建议至少按下面方式分层：

6.1 基础能力集 ​

覆盖：

  • 常规输入
  • 主流程
  • 正常边界

6.2 核心业务集 ​

覆盖：

  • 关键业务链路
  • 最常被领导和客户看到的场景

6.3 高风险集 ​

覆盖：

  • 敏感信息
  • 越权
  • 错误执行高代价任务
  • 合规场景

6.4 故障回归集 ​

覆盖：

  • 曾在线上出过的问题
  • 被用户投诉过的错误
  • 曾触发告警或事故的场景

6.5 红队攻击集 ​

覆盖：

  • 注入攻击
  • jailbreak
  • 输入污染
  • 工具滥用

这样做的价值是上线时不只知道“总分是多少”，还能知道：

  • 到底是哪一类能力在退化

7. 不同系统类型的数据集重点完全不同 ​

7.1 Prompt / 结构化提取系统 ​

重点看：

  • 输出 schema 是否稳定
  • 字段抽取是否完整
  • 边界输入是否破坏格式

7.2 RAG 系统 ​

重点看：

  • 问题是否真实
  • 证据文档是否存在
  • 答案是否真的可从知识库得到
  • 检索失败和生成失败能否区分

7.3 Agent 系统 ​

重点看：

  • 工具选择是否正确
  • 参数是否正确
  • 多步链路是否完整
  • 何时该停、何时该转人工

7.4 语音系统 ​

重点看：

  • 转写质量
  • 打断恢复
  • 多轮连贯
  • 口语噪声和环境变化

7.5 多模态系统 ​

重点看：

  • 图文对齐
  • 局部区域理解
  • 表格、图像、截图场景
  • 复杂输入的歧义处理

所以不要用一套单薄的“问答对”去替代所有任务类型的数据资产。

8. RAG 数据集最容易做错在哪 ​

RAG 数据集如果只保存：

  • 问题
  • 标准答案

通常是不够的。

更推荐至少保存：

  • 问题
  • 参考答案
  • 证据文档 ID
  • 证据片段或引用
  • 所属知识域
  • 风险等级
  • 样例来源
  • 版本号

因为 RAG 里经常要区分三件事：

  • 没有召回到正确证据
  • 召回到了但排序不对
  • 证据对了但生成错了

如果数据结构无法区分这三类问题，排障就会非常痛苦。

9. Agent 数据集比问答数据集更像“过程数据” ​

Agent 评测里，最终答案对不对只是其中一部分。

更常需要记录：

  • 意图
  • 上下文
  • 可用工具
  • 正确工具序列
  • 关键状态变化
  • 是否应该转人工
  • 允许的失败回退路径

很多 Agent 数据集失败，是因为只存了：

  • 用户问题
  • 理想答案

却没有存：

  • 过程是否合规
  • 工具是否误用
  • 路径是否安全

10. 标注规范最少应包含哪些内容 ​

建议每套标注任务至少有一份明确规则文档，包含：

  • 任务目标
  • 标签定义
  • 正例与反例
  • 通过 / 不通过标准
  • 歧义处理规则
  • 冲突仲裁规则
  • 抽样复核策略
  • 升级处理方式

如果是结构化任务，还应写明：

  • 字段级定义
  • 缺失值策略
  • 多值字段规则
  • 非法值示例

如果是 Agent / 流程任务，还应写明：

  • 哪些路径允许
  • 哪些操作严禁
  • 哪些情形必须人工接管

11. 标注质量如何控制 ​

最小可行的质量控制通常包括：

11.1 双人标注或抽样复核 ​

不是所有数据都要双标，但高风险样例非常值得。

11.2 冲突仲裁 ​

对高冲突样本建立：

  • 冲突记录
  • 仲裁结果
  • 规则更新记录

11.3 标注员训练 ​

很多质量问题不是标注员不认真，而是：

  • 规则不清楚
  • 示例不够
  • 工具配置不合理

11.4 规则持续迭代 ​

随着线上问题暴露，要定期更新：

  • 标签定义
  • 边界解释
  • 典型误判案例

12. 数据集版本化为什么比很多人想象中更重要 ​

没有版本化，后面你几乎无法回答：

  • 这次模型变好，是因为模型升级还是数据集换了
  • 这个 regression 是新引入的，还是之前就存在
  • 当前通过的门禁到底基于哪一批样本

建议至少记录：

  • 数据集 ID
  • 版本号
  • 变更说明
  • 样本来源
  • 创建时间
  • 创建人 / owner
  • 适用任务

最好还能区分：

  • 新增样例
  • 修改样例
  • 删除样例
  • 标注规则变更

13. 线上失败样例应该如何回流 ​

很多团队知道“要回流”，但没有真正的流程。

推荐最小闭环：

text
线上异常
 -> 人工复盘
 -> 归类失败模式
 -> 脱敏
 -> 进入候选样例池
 -> 标注 / 复核
 -> 入回归集
 -> 重新跑评测

这里最关键的不是“收集很多”，而是：

  • 每条样例都知道为什么被收进来

推荐至少给回流样例打这些标签：

  • 失败类型
  • 任务类型
  • 风险等级
  • 来源系统
  • 是否已复现
  • 是否已修复

14. 数据集应该怎样服务模型和 Prompt 决策 ​

根据 OpenAI 当前 Working with evals、Evaluation best practices、Model optimization 文档在 2026-07-08 的说明：

  • 应该尽量用接近真实生产输入的数据集做评测
  • 评测要服务于模型、Prompt 和系统级迭代
  • 可以把 evals 放到 Prompt 设计之前，像行为驱动开发一样先定义通过标准

这对工程的启发很明确：

  • 数据集不是验收结束后才用
  • 数据集应该在设计 Prompt、模型路由、工具策略前就介入

也就是说，数据集是“设计工具”，不是“收尾工具”。

15. OpenAI 当前评测与数据集能力对这件事有哪些启发 ​

根据 OpenAI 当前官方资料在 2026-07-08 的说明：

  • Working with evals 强调用 evals 持续测试输出是否符合预期
  • Getting started with datasets 已支持在平台里创建和管理数据集
  • Trace grading 说明可以围绕真实 traces 进行批量评分和定位问题
  • Evaluation best practices 强调 pairwise、pass/fail、长度偏差控制与高能力模型做 judge

这几件事放在一起意味着：

  • 数据集建设应当和 trace、eval、发布门禁串起来
  • 不要把数据集孤立成“离线 Excel 资产”

16. 如果要做训练 / 微调，数据集还要多看哪几个问题 ​

如果数据集不仅用于评测，还用于 SFT / RFT / 优化，至少还要额外关注：

  • 训练集和测试集严格分离
  • 标签噪声会不会被模型学进去
  • 目标是否真的适合用训练而不是 Prompt / workflow 优化
  • reward / grader 是否可自动判断

OpenAI 当前 Supervised fine-tuning、Reinforcement fine-tuning 和 fine-tuning best practices 资料都在强调：

  • 先明确目标
  • 先准备高质量样本
  • 先分开训练与测试
  • 再决定是否值得进入训练环节

这意味着：

  • 不是所有问题都该先用微调解决

17. Hugging Face 与 Label Studio 在工程上能提供什么价值 ​

根据 Hugging Face 与 Label Studio 当前官方文档在 2026-07-08 的信息：

  • Hugging Face datasets 文档非常适合做数据集的加载、切分、缓存、列式处理与版本化工作流
  • Label Studio 提供了项目配置、任务导入、预测预标注、人工标注、导出与外部存储同步等完整标注流程

这对企业团队的启发通常是：

  • datasets 更像数据工程底座
  • Label Studio 更像标注工作台

一个稳妥的组合方式通常是：

  • 用 datasets 管结构化数据资产
  • 用 Label Studio 管人工标注与复核流程

18. 建议最少沉淀哪些字段 ​

不论你把数据集存在哪里，建议每条样例至少有：

  • sample_id
  • task_type
  • scenario
  • risk_level
  • source
  • input
  • reference_answer
  • label / grade
  • rationale 或审查备注
  • dataset_version
  • created_at
  • owner

如果是 RAG，还建议加：

  • gold_documents
  • gold_chunks
  • knowledge_version

如果是 Agent，还建议加：

  • allowed_tools
  • expected_tool_path
  • must_handoff

19. 最值得跟踪的指标有哪些 ​

19.1 数据覆盖类 ​

  • 高频场景覆盖率
  • 高风险场景覆盖率
  • 线上失败回流率

19.2 标注质量类 ​

  • 标注冲突率
  • 复核通过率
  • 规则更新频率

19.3 数据资产类 ​

  • 无 owner 样例比例
  • 无版本样例比例
  • 无来源样例比例

19.4 评测使用类 ​

  • 每次发布覆盖的数据集比例
  • 回归集命中率
  • 历史故障复发率

20. 最常见的反模式 ​

  • 只收成功案例，不收失败案例
  • 把训练集和评测集混在一起
  • 数据集没有来源、没有 owner、没有版本
  • 标注规则只存在口头上
  • 只看总分，不看场景分层和风险分层
  • 线上失败不回流，永远重复踩同样的坑
  • 把合成数据当成真实世界替代品
  • 所有任务共用同一套标签体系，导致定义越来越模糊

21. 建议的建设顺序 ​

第一阶段：先有最小评测集 ​

至少覆盖：

  • 高频主路径
  • 高风险边界
  • 典型失败样例

第二阶段：再建标注规范和复核流程 ​

把：

  • 标签定义
  • 边界规则
  • 冲突仲裁

固定下来。

第三阶段：再做版本化和自动化评测 ​

把：

  • 数据集版本
  • 发布门禁
  • Trace 回流

串起来。

第四阶段：最后再扩展到训练 / 微调 / 主动学习 ​

这样节奏更稳，也更容易证明价值。

22. 推荐搭配阅读 ​

23. 重点官方资源 ​

以下资源已按 2026-07-08 复核可访问：