RAG管道架构：将索引与检索作为独立关注点

典型的RAG教程在同一个脚本中开始和结束：加载文档，分块，嵌入，存储到向量数据库，然后在推理时查询该数据库。整个过程在一个进程中运行。这对演示来说可以。但对生产环境不行。

生产RAG系统面向真实用户，处理不断变化的真实数据。文档被添加、更新和删除。嵌入模型被升级。分块策略被优化。与此同时，检索路径需要保持快速、稳定和可观测——即使在重建索引的过程中。当索引和检索纠缠在一起时，改变一个就会破坏另一个。

最佳的生产RAG架构将索引和检索视为两条独立的管道，它们只共享一样东西：向量存储。

为什么单体RAG脚本会崩溃

在单脚本RAG实现中，同一个代码库处理文档摄取、分块、嵌入、存储、查询处理、向量搜索、上下文组装和响应生成。这创建了几种只在规模化时才显现的故障模式。

重新索引会阻塞检索。 当您需要重新处理文档语料库——因为您更改了分块策略、升级了嵌入模型或收到了一批新文档——检索路径要么被阻塞，要么在部分更新的索引上运行。用户体验到降级的结果或完全的停机。

无法独立扩展。 索引是批处理工作负载。在解析和清理期间是CPU密集型的，在嵌入期间是GPU密集型的，在向量写入期间是I/O密集型的。检索是延迟敏感的在线工作负载。它需要快速嵌入短查询和快速的近似最近邻搜索。这些工作负载具有根本不同的资源配置。在同一进程中运行它们意味着两者都没有被优化。

调试变成考古学。 当检索质量下降时，您需要确定问题是出在文档的解析方式、分块方式、嵌入方式还是检索查询的构建方式上。在单体管道中，这些关注点交织在同一个代码库中。将质量问题追溯到其根本原因需要阅读整个系统。

版本管理几乎不可能。 您想对新的分块策略与当前策略进行A/B测试。或者您想回滚一个导致结果降级的嵌入模型更改。在单体系统中，这些操作需要重新处理整个语料库并重新部署整个应用程序。

双管道架构

将RAG分离为索引管道和检索管道，在它们之间创建了清晰的边界和定义明确的契约。

索引管道（批处理）

索引管道将文档处理为向量表示。它按计划运行或响应触发器——新文档到达、模型升级或手动重新索引请求。其阶段为：

1. 文件导入 — 从源系统（文件系统、S3、SharePoint、数据库导出）摄取文档。处理格式检测和去重。
2. 解析器 — 从结构化和非结构化格式（PDF、DOCX、HTML、Markdown、CSV）中提取文本。保留文档元数据和结构信息。
3. 清理 — 规范化文本，移除重复的页眉和页脚，处理编码问题，去除无关标记。此阶段对检索质量有着巨大的影响，但往往投入不足。
4. RAG分块器 — 将清理后的文本分割为检索单元。这是分块策略所在——固定大小加重叠、语义分块或文档结构感知分块。分块器是成熟RAG系统中迭代最频繁的组件。
5. 嵌入 — 使用嵌入模型将块转换为向量表示。这是计算最密集的阶段，受益于批处理和GPU加速。
6. 向量存储写入器 — 将嵌入及其关联的元数据写入向量数据库。处理更新插入、删除和索引管理。

每个阶段都可以独立测试。您可以验证解析器输出而无需运行嵌入器。您可以交换分块策略并在提交完整重新索引之前比较其输出。您可以升级嵌入模型并写入新集合而不触及现有集合。

检索管道（实时）

检索管道处理实时查询。它是延迟敏感的在线服务。其阶段为：

1. API端点 — 接受带有身份验证、速率限制和请求验证的传入查询。
2. 查询嵌入器 — 使用与索引期间相同的嵌入模型将用户查询转换为向量。这必须使用相同的模型和配置——此处的不匹配会静默地降低结果质量。
3. 向量搜索 — 对向量存储执行近似最近邻搜索。应用元数据过滤器，如果运行多个索引版本则处理多集合查询。
4. 上下文组装器 — 获取检索到的块，如有需要进行重新排序，将它们组装成连贯的上下文窗口，并为下游LLM格式化。此阶段管理token预算和去重。
5. API响应 — 返回组装好的上下文（或如果集成了LLM则返回生成的响应）以及来源归属元数据。

检索管道与索引管道具有完全不同的运行特性。它需要始终可用、在毫秒内响应并处理并发请求。它不需要解析文档、管理分块策略或处理批量嵌入作业。

管道之间的契约

向量存储是两条管道之间的接口。契约很简单：索引管道以已知的维度、已知的元数据模式和已知的集合命名约定写入向量。检索管道使用相同的嵌入模型从这些集合中读取。

此契约支持独立部署。您可以部署索引管道的新版本——使用不同的分块策略或新的嵌入模型——而无需重新部署检索管道。写入新集合，验证结果，然后将检索管道指向新集合。回滚就是将其指回旧集合。

在实践中是什么样子

在Ertas Data Suite中，两条管道都作为可视化节点图构建在同一画布上。索引管道是一系列节点：文件导入、解析器、清理、RAG分块器、嵌入、向量存储写入器。检索管道是另一条独立的链：API端点、查询嵌入器、向量搜索、上下文组装器、API响应。它们并排放置在画布上，视觉上不同但共享向量存储连接。

这种视觉分离使架构变得具体。您可以看到两条管道是独立的。您可以修改索引管道中的分块节点而不触及检索管道。您可以向检索管道添加重新排序节点而不触发重新索引。每条管道按自己的时间表运行——索引管道作为批处理作业，检索管道作为持久化服务。

由于Ertas作为桌面应用程序在本地运行，整个架构都保留在您的基础设施内。向量存储是本地的。嵌入模型在本地运行。没有文档内容或查询数据离开机器。对于有数据主权要求的企业，这消除了评估云RAG服务的合规开销。

分离的运营优势

独立的可观测性。 每条管道获得自己的指标。索引：每小时处理的文档数、块分布统计、嵌入吞吐量、写入延迟。检索：p50/p95/p99查询延迟、相关性评分、缓存命中率、并发查询数。当检索质量下降时，首先检查检索指标。如果检索正常，问题在索引中——检查索引指标以找到根本原因。

独立的迭代。 分块策略是生产RAG系统中最常更改的组件。使用分离的管道，您可以通过索引管道运行新的分块配置，将结果写入测试集合，并针对该集合评估检索质量——所有这些都不影响生产检索路径。

独立的故障域。 如果索引管道在批处理作业期间崩溃，检索继续从现有索引提供服务。如果检索管道出现延迟峰值，索引继续处理文档。两者的故障不会相互传播。

清晰的团队边界。 在较大的组织中，负责数据摄取和质量的团队（通常是数据工程团队）可以拥有索引管道，而负责面向用户应用程序的团队可以拥有检索管道。向量存储契约是两个团队之间的API。

何时开始分离

如果您的RAG系统是一个具有小型静态语料库和单一用户的原型或内部工具，单体方法就可以了。分离增加了在该规模下不合理的架构开销。

当出现以下任何条件时进行分离：您的语料库定期更新，您需要在不停机的情况下迭代分块或嵌入，多人或多个团队在系统上工作，或者检索可靠性是业务需求而非便利。

对于大多数企业RAG部署，这些条件从第一天起就存在。从分离的管道开始可以避免以后从单体系统进行痛苦的迁移——这种迁移通常需要在生产压力下重新处理整个语料库并重新设计应用程序架构。

最佳的RAG管道架构不是拥有最复杂检索算法的架构。而是您可以更改任何组件——解析器、分块器、嵌入器、检索策略——而不破坏其他一切的架构。