数据清洗实战：Embedding前的关键准备工作

被低估的数据清洗环节

在一篇来自 Reddit 的开发者分享中，一位构建搜索功能的工程师道出了许多 AI 应用开发者的共同痛点：搜索 API 本身是简单的部分，真正吃掉时间的是数据清洗。

这位开发者提到，他手上有三个「破损」的数据集——价格字段被存成了文本、分类标签毫无逻辑可言。最终，清洗这些脏数据所花的时间，比编写 API 本身还要多。他抛出了一个所有做 RAG（检索增强生成）和语义搜索的人都会遇到的问题：在数据进入 embedding 模型之前，究竟该如何正确地清洗它？

这个看似基础的问题，实际上触及了 AI 工程实践中一个长期被忽视的真相：模型的效果上限，往往由数据质量决定，而非算法本身。

为什么 Embedding 前的数据清洗如此重要

Embedding 模型的作用是把文本转化为高维向量，让语义相近的内容在向量空间中彼此靠近。但这个过程对输入质量极其敏感。

脏数据会污染语义空间

当价格「$1,299.00」被当作普通文本嵌入时，模型可能会将它与其他无关的数字文本聚在一起，而不是理解它作为「价格」的业务含义。同样，混乱的分类标签会让检索结果偏离预期——用户搜索「运动鞋」，却因为分类字段的噪声召回了「运动饮料」。

结构化字段与非结构化字段应区别对待

这是讨论中最容易被忽略的关键点。价格、日期、分类 ID 这类结构化数据，通常不应该直接扔进 embedding 模型。它们更适合作为元数据（metadata）存储，用于向量检索后的过滤与排序。真正需要嵌入的，是产品标题、描述这类富含语义的自然语言文本。

Embedding 模型（嵌入模型）是将文本映射到连续向量空间的神经网络，常见的有 OpenAI 的 text-embedding-ada-002、开源的 BGE、E5 等系列模型。其核心假设是「语义相似的文本，其向量距离也应相近」。模型在训练时学习了大量自然语言的语义规律，但对结构化符号（如货币格式、编码字符串、ID 序列）缺乏特殊理解——它只是把这些内容当作普通 token 序列处理。这也是为什么把价格或分类 ID 直接嵌入会导致语义空间「污染」：模型无法区分「$1,299」是一个价格，还是碰巧由这几个字符组成的任意文本。

一套可落地的数据清洗流程

针对常见的数据质量问题，这里提供一个系统化的清洗思路。

第一步：字段类型归一化

对于「价格卡成文本」的问题，核心是类型转换与规范化：

• 用正则表达式剥离货币符号、千分位逗号，统一转为浮点数或整数（以分为单位存储可避免精度问题）
• 处理缺失值：明确区分「价格为 0」和「价格未知」，不要用同一个默认值糊弄过去
• 异常值检测：用简单的分位数方法（如 IQR）标记明显不合理的价格

第二步：分类标签的语义对齐

「毫无意义的分类」通常源于多个数据源的标签体系不一致。解决方案包括：

• 建立一个受控词表（controlled vocabulary），将各种变体映射到标准分类
• 对于无法自动映射的标签，可以借助 LLM 做一次批量分类，让模型根据产品描述推断合理的类目
• 保留原始标签作为备份字段，便于后续追溯

第三步：文本内容的净化

对于真正要送入 embedding 的文本字段：

• 去除 HTML 标签、多余空白、乱码字符
• 统一大小写与全角半角（尤其中文场景）
• 处理过短或过长的文本——空描述应被过滤，超长文本需要合理分块（chunking）
• 去重：完全相同或高度相似的记录会稀释检索质量

分块（Chunking）是 RAG 工程中的关键决策之一。Embedding 模型通常有 token 长度限制（如 8192 tokens），超长文本必须切割后分别嵌入。常见的分块策略包括：按固定字符数切割（简单但可能截断语义）、按句子或段落边界切割（更符合语义完整性）、以及滑动窗口切割（相邻块有重叠，减少边界信息丢失）。块的大小直接影响检索粒度——太长会引入噪声，太短会丢失上下文。通常推荐在 256–512 tokens 之间，并保留 10–15% 的重叠区域。对于过短的文本（如只有几个词的残缺描述），其 embedding 向量方向往往不稳定，过滤掉是更稳妥的选择。

元数据分离：提升检索精度的最佳实践

很多开发者在踩坑后才意识到的一个架构原则是：embedding 负责语义匹配，元数据负责结构化过滤。

现代向量数据库（如 Pinecone、Weaviate、Qdrant）都支持在向量之上附加元数据字段，并在查询时进行结构化过滤。这意味着：

• 把清洗后的价格、分类、库存状态存为元数据
• 只对标题、描述做 embedding
• 查询时先用元数据过滤（如「价格 < 500 且 分类=鞋类」），再在结果内做语义相似度排序

这种分层设计不仅让检索更精准，也大幅降低了对 embedding 质量的依赖——你不需要指望模型去「理解」价格逻辑。

RAG（Retrieval-Augmented Generation，检索增强生成）是目前主流的 AI 应用架构模式：先从外部知识库中检索与用户问题相关的文档片段，再将这些片段连同问题一起送入大语言模型生成回答。向量检索是 RAG 中最常用的检索方式——将文档预先 embedding 后存入向量数据库，查询时对问题做同样的 embedding，然后通过余弦相似度或近似最近邻算法（ANN）找出最相关的片段。元数据过滤在这个流程中充当「前置筛选器」，能在进入语义排序之前大幅缩小候选集，既提升精度也降低延迟。Pinecone、Qdrant、Weaviate 等向量数据库均原生支持在 ANN 搜索的同时附加结构化字段过滤（即 pre-filtering 或 post-filtering 策略）。

自动化清洗流水线的搭建

开发者花费大量时间的另一个隐性原因，往往是清洗过程缺乏可复现的流水线。建议采用以下策略：

• 将每一步清洗逻辑写成独立、可测试的函数，而非一次性脚本
• 用 Pandas、Polars 或专门的数据校验工具（如 Pandera、Great Expectations）建立数据质量断言
• 记录清洗前后的数据统计（记录数、缺失率、异常值数量），便于验证清洗效果

当数据源更新时，一套自动化流水线能把「又要熬夜清洗」变成「跑一遍脚本」。

Pandera 和 Great Expectations 是两款专注于数据质量验证的 Python 库。Pandera 以声明式的 Schema 方式定义 DataFrame 的字段类型、取值范围、非空约束等规则，适合在数据处理函数中做轻量级断言；Great Expectations 则更面向团队协作，支持将数据期望（Expectation）保存为配置文件，并生成可视化的验证报告，适合作为数据流水线的质量门禁。在 AI 应用场景中，建议至少对「送入 embedding 前的最终数据集」添加断言，例如：文本字段无空值、价格字段均为正数、分类字段取值在受控词表内。这类检查能在数据上游变化时及早发现问题，避免悄无声息地用脏数据污染向量索引。

结语：数据工程才是 AI 应用的地基

这个朴素的开发者求助，其实揭示了一个行业共识：在 AI 应用开发中，写模型调用代码往往只占工作量的一小部分，数据准备才是真正的重头戏。

对于任何要接入 embedding 与语义搜索的项目，与其花时间纠结用哪个模型，不如先把数据清洗和元数据架构做扎实。因为再强大的 embedding 模型，也无法从一堆卡成文本的价格和混乱的分类中，凭空提炼出干净的语义。