数据准备:数据源选择、清洗与标准化

数据准备这一步,说白了就是给向量测试评估集找「原材料」。我见过不少团队,模型还没跑呢,先花了两周在数据上折腾。嗯,这一步确实绕不开。你想想看,数据质量直接决定了评估结果的可信度。数据脏,结论就虚。

我个人习惯把数据准备拆成三个环节:选源、清洗、标准化。咱们一个一个聊。

数据源选择:开源数据集、业务日志、合成数据

选数据源,没有银弹。三种来源各有各的脾气,我分别说说。

开源数据集

这是最省力的起点。像 SQuAD、MS MARCO、Natural Questions 这些,社区验证过,拿来就能用。我在项目中遇到过直接用 SQuAD 做检索评估的情况,效果还行,但有个坑——开源数据集的分布和真实业务场景往往有偏差。

我的建议:开源数据集适合做基准测试(benchmark),但别指望它能完全代表你的业务场景。用它做「初筛」可以,做「终判」要谨慎。

业务日志

这才是真正贴近实战的数据源。用户真实的查询、点击、反馈,这些日志里藏着最宝贵的信号。我记得有一次帮客户做电商搜索评估,从日志里扒了 10 万条真实查询,跑出来的结果和用公开数据集测的完全两个方向。

但业务日志也有麻烦:

  • 隐私合规问题——用户数据不能直接往外扔
  • 噪声多——误点击、爬虫请求、测试流量混在一起
  • 标注成本高——原始日志没有 ground truth
注意:从业务日志提取数据时,一定要做脱敏处理。我曾经因为漏掉一个用户 ID 字段,差点被合规部门叫停项目。

合成数据

当真实数据不够用、或者某些场景覆盖不到时,合成数据就派上用场了。比如你想测试长尾查询的检索效果,但日志里全是高频词,这时候可以用大模型生成一批模拟查询。

合成数据的优点很明显:可控、可扩展、无隐私风险。但缺点也突出——它可能带有人工痕迹,和真实分布有 gap。我一般把合成数据当作「补充剂」,而不是「主食」。

数据源类型 优点 缺点 推荐场景
开源数据集 标准化、社区验证、即拿即用 与业务场景有偏差、覆盖有限 基准测试、模型选型
业务日志 真实用户行为、高业务相关性 隐私风险、噪声多、标注成本高 业务效果评估、线上监控
合成数据 可控、可扩展、无隐私问题 人工痕迹、分布偏差 长尾场景覆盖、压力测试

数据清洗与预处理

数据源选好了,接下来就是「洗菜」。这一步做不好,后面所有评估都是白搭。

我总结了一套清洗流程,你可以参考:

  1. 去重——重复的 query 或 document 会扭曲评估指标。我习惯用 MinHash 做近似去重,精确去重用哈希就行。
  2. 去噪——HTML 标签、特殊字符、乱码、全角半角混用,这些都得清理。正则表达式是你的好朋友。
  3. 长度过滤——太短的 query(比如只有 1 个字符)通常没有评估意义;太长的 document 可能超出模型输入限制。设个阈值,直接过滤掉。
  4. 语言一致性检查——如果你的评估集是中文的,混入英文或日文文本会污染结果。用 langdetect 或 fastText 做语言识别。
  5. 标注一致性校验——如果数据有人工标注,一定要做 inter-annotator agreement 检查。Kappa 值低于 0.6 的样本,我建议直接丢弃。

核心原则:清洗的目的是「去除明显错误」,而不是「让数据变完美」。过度清洗会丢失真实分布中的多样性。

举个例子,我曾经处理一批电商搜索日志,发现大量 query 包含「包邮」「正品」这类词。一开始我想把它们当噪声去掉,后来发现这些恰恰是用户最关心的维度。嗯,保留它们,反而让评估更贴近真实。

数据格式标准化

数据洗干净了,还得统一格式。向量评估集通常需要三个核心字段:query、document(或 passage)、relevance label。我推荐用 JSON Lines 格式,每行一个独立样本,方便流式处理。

{
  "query_id": "q_0001",
  "query": "深度学习框架对比",
  "doc_id": "d_0042",
  "document": "PyTorch 和 TensorFlow 是目前最主流的深度学习框架...",
  "relevance": 2,
  "source": "业务日志_2024Q1"
}

标准化时要注意几个细节:

  • 字段命名统一——别一会儿用 query_text,一会儿用 q_text。我习惯用 snake_case,全小写。
  • 标签类型明确——相关性分数是 0/1 二值,还是 0-3 分级?在元数据里写清楚。
  • 编码统一——全部用 UTF-8,别问为什么,问就是吃过 GBK 的亏。
  • 版本号——每个数据集文件带上版本号,方便回溯。我见过最惨的案例:团队用了旧版数据跑了一周实验,结果发现数据已经更新了三版。
避坑指南:我曾经在标准化时忽略了 document 的截断问题。有些 document 超过 512 ,模型自动截断后,评估结果和完整文档的结果差异很大。建议在标准化阶段就记录 document 的原始长度和截断策略。

整体流程框架

下面这张图概括了数据准备的完整链路,从数据源到标准化后的评估集:

数据准备流程框架 数据源选择 开源 · 业务日志 · 合成 数据清洗与预处理 去重 · 去噪 · 长度过滤 格式标准化 JSON Lines · UTF-8 评估数据集 质量检查与验证 反馈迭代:质量不达标则返回清洗或重新选源 💡 关键原则 • 数据源选择要匹配评估目标,不要盲目追求数据量 • 清洗和标准化过程要可复现,建议用脚本而非手动操作

这张图里我特意加了一条反馈回路。为什么?因为数据准备很少是一次性完成的。你做完质量检查,发现数据分布有问题,就得回去调整清洗策略,甚至换数据源。我做过最极端的一个项目,光数据准备就迭代了 5 轮。

好了,数据准备这块就聊到这儿。记住一句话:评估集的质量上限,在数据准备阶段就已经决定了。后面模型跑得再花哨,也救不了脏数据。