RAG 数据摄取与索引流水线：别让脏数据进入向量库

RAG 的线上质量，很多时候在用户提问前就已经决定了。文档有没有解析对，表格有没有丢列，旧版本有没有清掉，权限有没有带进索引，Embedding 是否复用缓存，都会直接影响后面的召回和生成。

数据摄取流水线的目标不是“把文档塞进向量库”，而是把原始内容变成可检索、可引用、可授权、可回滚、可评测的知识单元。

调研摘要

主流 RAG 工程方案在数据摄取上有几个共同点：

• LlamaIndex 的 ingestion pipeline 把加载、切分、元数据抽取、Embedding 等步骤看作 transformations，并通过缓存避免重复处理相同节点。
• LangChain 的 indexing 思路强调记录源文档和派生文档的关系，避免重复写入和无效重建。
• Azure AI Search 的 RAG 文档强调多源数据接入、增量索引、chunking、vectorization、hybrid search、semantic ranking 和查询时权限裁剪。
• Elastic 的 RAG 资料强调外部知识更新、引用可验证、document-level access control，以及文本、向量、混合和语义检索组合。

落到工程实践里，可以把摄取流水线拆成八个阶段。

总体流水线

这条链路最好是可重放的。任意一个版本的索引都应该能回答：它来自哪些数据源、用什么解析器、什么分块策略、什么 embedding 模型、什么权限快照生成。

1. 数据源接入

生产 RAG 往往不是单一文档目录，而是 Wiki、PDF、网页、对象存储、数据库、客服工单、代码仓库和内部系统的混合体。

接入层不要急着生成 embedding。先把 source manifest 建好，记录每个源的同步范围、频率、owner 和权限策略。

2. 变更检测

没有增量机制的 RAG 索引，很快会遇到两个问题：全量重建太慢，旧内容无法清理。

建议为每份文档计算稳定指纹：

{
  "source_id": "wiki:rag-playbook",
  "source_url": "https://example.com/wiki/rag-playbook",
  "content_hash": "sha256:...",
  "metadata_hash": "sha256:...",
  "updated_at": "2026-07-07T10:00:00Z",
  "deleted": false
}

增量索引至少要识别四种事件：新增、内容更新、元数据更新、删除。元数据更新也很重要，因为 ACL、owner、业务标签变化可能不改变正文，但会改变检索边界。

3. 解析与抽取

解析阶段的产物不应该只是一段纯文本。生产系统更需要结构化中间表示。

推荐中间结构包含：

不要过早丢掉页码、标题路径和表格结构。后面做 citation、bad case 复现和人工审核时，这些字段很关键。

4. 清洗与规范化

清洗不是把文本“变干净”这么简单，而是减少会污染检索的噪声。

清洗规则要版本化。否则一次规则调整导致召回变化时，很难判断是数据变了还是 pipeline 变了。

5. 元数据和权限

元数据不是附加字段，而是 RAG 的控制面。没有元数据，就做不了权限过滤、时间过滤、业务路由、引用和回滚。

{
  "document_id": "doc_rag_playbook",
  "chunk_id": "doc_rag_playbook_0042",
  "source": "wiki",
  "source_url": "https://example.com/wiki/rag-playbook#release-gate",
  "title_path": ["RAG Playbook", "Release Gate"],
  "owner": "ai-platform",
  "updated_at": "2026-07-07",
  "doc_status": "active",
  "acl_groups": ["team:ai-platform"],
  "pipeline_version": "ingest_2026_07_07",
  "embedding_model": "text-embedding-v3"
}

权限建议在检索前就裁剪，而不是把无权内容放进 prompt 再要求模型不要泄露。缓存 key 也要包含用户权限上下文，避免跨租户或跨团队污染。

6. 分块与父子关系

分块策略在 Chunking 工程指南 里已经展开。摄取流水线里需要额外关注的是：分块结果要能增量更新和回溯。

一个常见错误是：文档某一段更新后，整篇文档所有 chunk_id 都变化。这会破坏引用、评测样本和 bad case trace。chunk_id 应尽量稳定。

7. Embedding 与索引写入

Embedding 是昂贵步骤，也会成为质量漂移来源。生产系统需要把 embedding 模型、维度、归一化方式和生成时间写进 manifest。

索引写入通常至少有两类目标：

如果使用 hybrid retrieval，两个索引的 chunk_id 和过滤字段必须一致。否则线上 trace 很难解释“为什么 BM25 找到了而 vector 没有”，也很难合并排序结果。

8. 索引发布

不要直接把新索引写到线上 collection。更稳的方式是构建新版本索引，评测通过后切 alias。

每个索引版本都应该有 manifest：

上线后如果出现集中 bad case，先看 manifest，而不是直接猜 prompt 有问题。

质量门禁

摄取流水线完成后，至少跑一组数据质量和检索质量检查。

这些检查应该在索引发布前执行，而不是等用户线上报错。

常见反模式

最小实现清单

如果从零开始，先做到这些：

• 为每个数据源建立 source manifest。
• 为每份文档计算 content_hash 和 metadata_hash。
• 解析阶段保留 block、page、heading_path、source_span。
• Chunk schema 包含 document_id、chunk_id、parent_id、source_url、updated_at、acl。
• Embedding 结果按 chunk hash 缓存。
• 全文索引和向量索引共享 chunk_id 和过滤字段。
• 新索引先评测，再通过 alias 发布。
• 旧索引保留至少一个回滚窗口。
• 每次发布生成 index manifest 和 eval report。

相关阅读

• RAG 的真实架构：从文档摄取到可引用答案
• Chunking 工程指南：文档怎么切，RAG 上限就在哪
• 混合检索：BM25、向量召回与 RRF
• RAG 发布门禁：让每次改动都可比较、可回滚
• RAG 上线检查清单：从 Demo 到 Production

参考资料

• LlamaIndex Ingestion Pipeline
• LangChain Indexing
• Azure AI Search RAG Overview
• Elastic: What is Retrieval Augmented Generation

结论

RAG 数据摄取不是离线杂活，而是生产质量的第一道门禁。把解析、清洗、元数据、权限、分块、Embedding、索引发布和回滚做成可观测流水线，后面的检索、生成和评测才有稳定基础。