大多数 RAG 项目一开始都抱着一个简单的假设：只要能收集到文档，就能让它们可被检索。 实际做起来，最难的活儿在生成第一个 embedding 之前就已经开始了。 企业知识通常散落在 PDF、Word 文件、电子表格、幻灯片、扫描页、图片、表格和数据库里。 这些来源很少有一致的结构。 一个 PDF 里可能有页眉、页脚、断开的段落，还有含义依赖上下文的表格。 一张图表在标签和关系里承载的信息，可能比图注里还多。 数据库里的一行数据可能本身是准确的，但脱离表结构或业务背景就毫无意义。 把所有东西都转成纯文本，恰恰可能把检索需要的上下文给抹掉。 原始抽取还会带进重复项、格式残留、缺失值和残缺记录。 如果这些问题被直接塞进向量库，检索器就只能在一堆噪声里翻找。 于是答案质量差往往被怪到 embedding 模型头上，可真正的问题出在源数据。 正因如此，搭建 RAG 知识库应当把数据转换与清洗当作一个专门的工程阶段来做，从这一步开始。

可以围绕几个阶段来设计一条实用的流水线：

  1. 摄取源数据，并保留来源信息，例如文件名、页码、章节、表格、图像、数据库和记录标识符。
  2. 把每种格式都转成结构化表示。 文档正文、表格、图表说明、图像和数据库记录，都应表示为同时带有内容与元数据的记录。
  3. 清洗并规范化记录：去掉重复的页眉、页脚、非法字符、残缺片段、空字段和格式残留。
  4. 保留关联与上下文。 表头应与其对应的值保持关联，图表标签应与其相关的可视化内容保持对应，数据库行应保留 schema 信息。
  5. 把内容切成有意义的块，切分依据是文档结构、章节、记录或语义边界，而不是只按固定的字符长度来切。
  6. 生成可直接用于检索的数据，比如问答对、摘要、解释，或者补充了上下文的段落。
  7. 评估并筛选输出结果，检查其完整性、来源一致性、语言、长度和相关性。
  8. 删除重复记录与近似重复记录，可用规则、指纹或语义相似度来做，然后把校验过的数据导出，用于生成嵌入和建立索引。

每个主要步骤之后都应保存中间输出，这样某次抽取失败或过滤条件过严时，可以直接检查并修正，不必重建整个数据集。这样做还能让 PDF、图片、表格和结构化数据库数据走不同的处理分支，同时保持下游格式一致。

上面这套设计已经在 OpenDCAI/DataFlow 中实现，我也很乐意进一步讨论——自动化数据处理流水线是构建可靠 RAG 系统的一项重要能力。