数据处理与数据集评估笔记

发表于 分类于 ， ， ， 阅读次数：

数据处理与数据集评估笔记

1. 为什么数据决定模型上限

对句子嵌入、检索召回和 RAG 场景来说，模型当然重要，但很多时候真正决定上限的是数据。

常见原因有：

  • 正样本质量决定模型学到什么叫“相关”
  • 负样本质量决定模型能否真正学会区分
  • 样本分布决定模型上线后是否能泛化
  • 标签噪声决定训练信号是否稳定
  • 评估集质量决定你是否能看清真实问题

先记住一个判断：模型是在数据里学规律。如果数据本身混乱、偏斜或失真，训练出来的结果大概率也会带着同样的问题。

2. 数据处理到底包括什么

很多人一提数据处理，只想到“删乱码、去空值”，但在 embedding 项目里，数据处理通常至少包括下面这些部分：

  • 数据采集
  • 样本构造
  • 数据清洗
  • 去重和归一化
  • 标签治理
  • 样本分布分析
  • 训练 / 验证 / 测试切分
  • 评估集构建
  • 数据版本管理

换个更完整的说法：

数据处理 = 数据工程 + 数据质量控制 + 数据评估设计。

3. 先定义样本单位，再谈处理策略

在做数据处理之前，第一件事不是清洗，而是先明确“一个样本到底是什么”。

不同任务里，样本单位并不一样：

3.1 相似度任务

通常是句子对：

  • sentence_a
  • sentence_b
  • label

3.2 检索任务

通常是：

  • query
  • positive
  • negative 或 hard_negative

3.3 文档向量库构建

通常是：

  • doc_id
  • chunk_id
  • text
  • metadata

如果样本单位没定义清楚，后面很多统计都会失真。
比如你以“句子对”为单位去算分布，和以“query”为单位去算分布，结论会完全不同。

4. 数据处理的主线流程

一个比较稳的流程通常是：

  1. 明确任务目标和样本单位
  2. 采集原始数据
  3. 构造正样本、负样本、hard negative
  4. 做文本清洗和标准化
  5. 做去重、去模板、去噪
  6. 分析样本分布和标签分布
  7. 切分 train / valid / test
  8. 构建标准评估集和 badcase 集
  9. 训练第一版模型
  10. 用 badcase 反推数据问题，再回流修正

这条链路里，最容易被忽视的不是清洗，而是：

  • 分布分析
  • 泄漏排查
  • 评估集设计

5. 数据清洗要做什么

5.1 基础清洗

最基础的一层通常包括：

  • 去空文本
  • 去乱码
  • 去无意义符号
  • 去极短文本
  • 去极长文本
  • 统一空白符
  • 统一全角半角
  • 统一大小写

如果是中文场景，还经常要考虑：

  • 简繁统一
  • 标点统一
  • URL、邮箱、手机号脱敏
  • 时间、数字、金额是否归一化

5.2 噪声清洗

很多业务数据不是“脏”，而是“有大量无效结构”。

例如：

  • 页眉页脚
  • 导航栏
  • 广告词
  • 模板开场白
  • 重复免责声明
  • OCR 识别错误文本

这些内容如果不清掉，会让模型学到大量无关模式。

5.3 去重

去重非常重要，因为重复样本会让训练和评估都失真。

常见去重对象：

  • 完全重复文本
  • 近重复文本
  • 同一 query 的重复点击对
  • 同一文档切块后的重复片段

如果不做去重，常见后果有：

  • 模型过度拟合高频表达
  • 评估结果虚高
  • 数据规模看起来很大，但有效信息量并不高

6. 样本分布为什么必须看

很多训练失败，不是模型没学会，而是数据分布本身有问题。

至少要看下面几类分布。

6.1 文本长度分布

要看：

  • query 长度分布
  • document / passage 长度分布
  • chunk 长度分布

如果训练集里大部分文本很短，但线上是长 query 或长段落，模型上线后就容易掉点。

6.2 标签分布

例如：

  • 正负样本比例
  • 2 / 1 / 0 多档标签比例
  • query 是否只有正样本没有负样本

如果标签极度失衡，模型往往会学到偏置策略，而不是学到真正的语义边界。

6.3 场景分布

要看数据是否覆盖不同业务场景，例如：

  • FAQ
  • 搜索
  • 商品检索
  • 知识库问答
  • 代码检索

如果训练样本只覆盖热门场景，长尾场景通常会明显掉效果。

6.4 热门与长尾分布

要区分：

  • 高频 query
  • 长尾 query
  • 高频文档
  • 稀有文档

如果训练集被热门 query 主导，模型可能对高频表达很强，但对长尾表达泛化很差。

6.5 正样本来源分布

正样本如果同时来自多种来源，例如：

  • 点击日志
  • 人工标注
  • FAQ 映射
  • 改写生成

最好分别统计占比，因为不同来源噪声强度不一样。

6.6 负样本难度分布

不能只看负样本数量，还要看难度结构。

通常可以分成：

  • 随机负样本
  • 同域负样本
  • hard negative

如果全是简单负样本，模型离线 loss 可能很好看，但上线区分能力依然不够。

7. 标签质量怎么检查

数据量大不代表标签质量高。

标签问题通常来自：

  • 点击不等于相关
  • 曝光位置偏置
  • 人工标注标准不一致
  • 自动构造规则太粗糙
  • 历史系统的错误被继承进新数据

可以从下面几方面检查：

7.1 抽样人工复核

最直接也最有效。

重点抽样：

  • 高频 query
  • 长尾 query
  • 高相似但错召回样本
  • 模型和标签明显冲突的样本

7.2 看标签一致性

例如同一个 query 是否出现下面这种情况：

  • 同一文档有时标正样本
  • 有时又标成负样本

这种冲突标签会直接污染训练信号。

7.3 看模型反常样本

如果一个样本长期表现为：

  • 标签是正样本，但模型始终给很低分
  • 标签是负样本，但模型和人工都觉得很相关

那就要怀疑数据或标签本身有问题，而不是先怀疑模型。

8. 正样本和负样本要怎么治理

8.1 正样本治理

正样本要优先保证“真相关”。

对于日志数据，常见过滤规则包括：

  • 去掉极短停留
  • 去掉误点击
  • 去掉曝光高但满意度低的内容
  • 去掉跳出率特别高的点击对

如果是结构化映射数据，还要检查：

  • 映射关系是否过期
  • 标题和正文是否错配
  • 类目标签是否长期维护

8.2 负样本治理

负样本的核心不是“越多越好”，而是“越像线上干扰项越好”。

常见做法：

  • 先用随机负样本保证基础区分
  • 再补同域负样本
  • 最后重点挖 hard negative

8.3 Hard Negative 是最值得花时间的部分

hard negative 常见来源：

  • BM25 高分误召回
  • 旧 embedding 模型的错召回
  • Cross-Encoder 高混淆样本
  • 人工 badcase 回流

很多时候，模型的真实提升不来自更多数据，而来自更强的 hard negative。

9. 训练集、验证集、测试集怎么切

切分数据时，重点不是比例，而是避免数据泄漏。

9.1 常见切分比例

  • 8:1:1
  • 9:0.5:0.5

9.2 更重要的是避免泄漏

例如：

  • 同一问题的改写版本，不要分到不同集合
  • 同一文档的多个 chunk，不要乱落到 train 和 test
  • 同一用户会话，不要一部分在训练、一部分在测试
  • 同一商品不同标题变体，不要跨集合乱分

如果泄漏存在，评估结果通常会明显虚高。

9.3 切分方式最好按业务实体来做

例如按下面这些维度切，通常更稳：

  • 按 query_id
  • 按 doc_id
  • 按会话
  • 按用户

而不是简单随机切行。

10. 评估集应该怎么设计

评估集不是简单从训练数据里抽一点出来，而是要刻意设计。

一个好的评估集通常要满足：

  • 覆盖核心业务场景
  • 覆盖热门 query 和长尾 query
  • 覆盖高混淆样本
  • 尽量有人工校验
  • 分布尽量接近线上真实请求

10.1 标准评估集

这是每次训练都要跑的稳定基线。

要求：

  • 版本稳定
  • 标注质量高
  • 用来做横向对比

10.2 Badcase 集

这是最重要的补充集。

来源通常是：

  • 线上错召回
  • 用户投诉
  • 人工复核发现的高价值错误
  • 新业务新术语

badcase 集的作用不是看平均分，而是防止关键错误反复出现。

10.3 分层评估

如果场景复杂，建议把评估集再分层：

  • 热门 query 集
  • 长尾 query 集
  • 专业术语集
  • 否定表达集
  • 数字、时间、版本号敏感集

这样你才能知道模型到底是“整体提升”，还是只在某一类场景提升。

11. 数据集评估到底评什么

除了看模型指标，还应该单独评估数据集本身。

至少可以看下面几类指标。

11.1 规模指标

  • 样本总量
  • 唯一 query 数
  • 唯一 doc 数
  • 平均每个 query 的正样本数
  • 平均每个 query 的负样本数

11.2 分布指标

  • 文本长度分布
  • 标签分布
  • 场景分布
  • 来源分布
  • 热门 / 长尾分布

11.3 质量指标

  • 重复率
  • 近重复率
  • 空文本比例
  • 模板文本比例
  • 乱码比例
  • 标签冲突率

11.4 难度指标

  • hard negative 占比
  • 高混淆样本占比
  • 多跳或长文本样本占比

如果这些指标长期不看，训练往往会变成“看 loss 猜问题”。

12. 一个很实用的数据诊断思路

如果模型效果不好，可以先按下面顺序排查：

  1. 看训练和测试是否泄漏
  2. 看是否有大量重复样本
  3. 看标签是否冲突
  4. 看负样本是不是太简单
  5. 看热门样本是否占比过高
  6. 看长尾 query 是否覆盖不足
  7. 看评估集是否真的接近线上

这条排查顺序很实用，因为很多问题根本不是模型结构导致的。

13. 数据版本管理为什么重要

如果你每次训练都在用“最新数据”，但没有快照和版本号，后面几乎一定会遇到这类问题：

  • 效果变好了，不知道是哪批数据带来的
  • 效果变差了，不知道是哪次清洗规则改坏了
  • badcase 修好了，但下个版本又回来了

所以至少要给下面这些东西做版本管理：

  • 原始数据快照
  • 清洗规则版本
  • 样本构造规则版本
  • hard negative 生成版本
  • 评估集版本
  • badcase 集版本

14. 一个适合落地的默认做法

如果你现在要从零做一套数据处理和数据集评估流程，可以先按这个 baseline 走：

  1. 先定义样本单位和标签规范
  2. 从业务日志和结构化关系里构造正样本
  3. 补随机负样本、同域负样本和 hard negative
  4. 做基础清洗、去重和归一化
  5. 统计长度分布、标签分布、场景分布和来源分布
  6. 按 query_id 或 doc_id 切 train / valid / test
  7. 建一份小而稳定的标准评估集
  8. 再维护一份持续追加的 badcase 集
  9. 每次训练都固定跑离线评估和分层评估
  10. 把线上 badcase 持续回流

这套流程不花哨，但很稳，也最容易持续迭代。

15. 一份可直接抄的检查清单

  1. 是否明确了样本单位
  2. 是否定义了标注规则
  3. 是否做了基础清洗和噪声清洗
  4. 是否做了完全去重和近重复检查
  5. 是否统计了长度分布和标签分布
  6. 是否区分了热门和长尾样本
  7. 是否统计了正样本和负样本来源
  8. 是否有足够强的 hard negative
  9. 是否避免了 train / test 泄漏
  10. 是否有稳定的评估集和 badcase 集
  11. 是否给数据和规则做了版本管理

16. 一句话总结

数据处理和数据集评估的核心不是“把脏数据洗干净”，而是：

让训练数据更真实、分布更合理、标签更稳定、评估更可信。

对 embedding 项目来说，很多时候真正决定模型上限的，不是你换了多大的模型，而是你把数据治理做到了什么程度。