RAG作为模块化服务：为什么检索应该是基础设施，而非嵌入式代码

没有人会把数据库驱动逻辑嵌入HTTP处理程序中然后称其为架构。数据库在几十年前就成为了基础设施——被抽象在连接字符串、查询接口和托管服务之后。但出于某种原因，大多数使用检索增强生成构建系统的团队正在做等同于将SQL直接硬编码到路由处理程序中的事情，只不过这里的"SQL"是分块逻辑、嵌入调用、向量搜索配置和重排序启发式方法，全部纠缠在不应该了解这些内容的应用程序代码中。

这就是当今大多数RAG实现核心的耦合问题，它正在悄然制造与行业花了多年学会用数据库、缓存和消息队列来避免的同类技术债务。

耦合问题

典型的RAG实现看起来大致如此：应用程序接收用户查询，应用程序代码调用嵌入模型将查询向量化，应用程序代码使用特定搜索参数查询向量数据库，应用程序代码应用重排序或过滤逻辑，应用程序代码用检索到的上下文构建提示词，然后应用程序将该提示词发送给LLM。

每一个步骤都在应用程序内部。分块策略、嵌入模型选择、相似度阈值、检索文档数量、重排序算法——所有这些都嵌入在应用程序代码中，通常分散在多个文件和函数中。

现在考虑当你需要更改这些决策中的任何一个时会发生什么。

你从一个嵌入模型切换到性能更好的新模型。这是一次应用程序部署。你调整分块策略，因为带表格的文档被错误地分割了。应用程序部署。你添加元数据过滤器以限制检索最近90天的文档。应用程序部署。你添加重排序步骤以提高精度。应用程序部署。

每一次检索改进都需要完整的应用程序发布周期。检索管道和应用程序共享相同的部署边界、相同的CI/CD管道、相同的回滚程序。重排序逻辑中的错误可能导致整个应用程序崩溃。分块策略中的退化需要回滚在同一版本中发布的应用程序功能。

这不是理论上的担忧。构建生产RAG系统的团队报告说，检索调优——调整块大小、尝试不同嵌入模型、微调搜索参数——占了持续维护工作的相当大比例。当这些工作与应用程序部署耦合时，它同时拖慢了检索团队和应用程序团队。

数据库类比

考虑你的应用程序如何与PostgreSQL数据库交互。你的应用程序不包含查询计划器。它不管理索引创建。它不处理存储引擎决策。它连接到一个端点，通过定义良好的接口发送查询，并接收结果。数据库团队可以重建索引、升级引擎、更改复制拓扑和优化查询计划——所有这些都不需要应用程序团队部署任何东西。

这种分离存在是因为行业通过痛苦的经验了解到，将存储基础设施与应用程序逻辑耦合会创建脆弱、迭代缓慢且难以理解的系统。

检索属于同一类关注点。它是基础设施。它有自己的性能特征、自己的调优参数、自己的故障模式、自己的版本控制需求。将其视为应用程序代码是一种架构类别错误。

RAG作为服务的样子

RAG检索API端点将检索管道与应用程序清晰地分离。应用程序发送查询。它接收排序的、相关的上下文。它不知道也不关心上下文是如何检索的。

在端点背后，检索服务拥有自己的部署生命周期。检索团队可以：

• 替换嵌入模型而无需触及应用程序。从通用模型转移到领域特定模型，或完全升级到更新的架构。API契约保持不变。
• 按文档类型更改分块策略。 法律合同用一种分块方法，技术文档用另一种，客户支持记录用第三种。应用程序永远不会知道。
• 添加或移除重排序阶段。 从仅使用向量相似性开始，然后加入交叉编码器重排序，再添加元数据提升。每次更改都是独立部署。
• 版本化检索管道。 并行运行v1和v2。将10%的流量路由到新管道。比较检索质量指标。升级或回滚不需要任何应用程序更改。
• 独立检测。 将检索延迟、相关性评分、缓存命中率和嵌入吞吐量作为一等运维指标进行跟踪，与应用程序级别的可观测性分开。

这就是具有工具调用规范集成的RAG管道为AI代理所带来的能力。代理不包含检索逻辑。它通过标准化接口调用检索工具。该工具背后的检索服务可以独立演进。

为什么企业需要这种分离

对于评估本地部署RAG服务的企业团队，检索基础设施与应用程序代码之间的分离不是可选的——它是治理要求。

可审计性。 当检索是一个独立服务时，你可以准确审计任何给定查询检索了什么。你可以记录检索管道版本、考虑的文档、排序评分以及传递给模型的最终上下文。这个审计记录存在于检索服务中，而不是分散在应用程序日志中。

访问控制。 不同的文档集合可能有不同的访问策略。检索服务可以集中执行文档级权限，而不是要求每个应用程序围绕检索内容实现自己的访问控制逻辑。

数据驻留。 当检索管道是可部署的服务时，你精确控制它在哪里运行。本地部署检索层意味着嵌入、向量和文档内容永远不会离开你的基础设施，即使应用程序层使用云托管的LLM进行生成。

独立扩展。 检索工作负载和生成工作负载有不同的资源特征。嵌入和向量搜索是计算密集但速度快的。LLM生成更慢且内存密集。当这些是独立服务时，你可以根据各自的实际资源需求独立扩展。

Ertas如何将检索视为基础设施

Ertas将检索视为一个可部署的管道，在架构上与消费它的应用程序分离。检索管道——文档摄取、分块、嵌入、索引和搜索——是一个托管服务，有自己的配置、版本控制和部署生命周期。

当Ertas驱动的应用程序或代理需要上下文时，它通过定义的接口调用检索管道。应用程序指定它需要什么：一个查询、可选过滤器、期望的结果数量。管道处理如何满足该请求，包括使用哪个嵌入模型、如何搜索、是否重排序以及查询哪些文档集合。

这意味着管理文档摄取和检索质量的团队可以独立于构建面向用户应用程序的团队进行迭代。分块策略可以改进。嵌入模型可以升级。新的文档集合可以被索引。这些更改都不需要重新部署应用程序。

对于本地部署的团队，检索管道完全在其基础设施内运行。文档内容、嵌入和向量索引留在现场。管道可以配置为与组织现有的文档存储协同工作，从文件共享、内容管理系统或内部数据库中提取，无需将数据迁移到外部服务。

架构原则

这里的模式并不新颖。它与推动数据库、缓存、消息队列和认证服务从应用程序代码中分离出来的原则相同。基础设施关注点值得基础设施级别的处理：具有定义接口的专用服务、独立的部署生命周期和专门的运维工具。

检索就是基础设施。它一直伪装成应用程序代码，因为RAG模式相对较新，团队默认选择了通往可工作原型的最快路径。但原型会变成生产系统，生产系统需要架构边界。

那些早早划定这条边界的团队——将其RAG管道视为模块化的、可独立部署的服务，而非嵌入应用程序中的代码——将更快地迭代检索质量，以更低的风险部署应用程序更改，并保持对两个系统更清晰的运维可见性。

那些不划定这条边界的团队最终会得出行业三十年前关于数据库得出的同样结论：基础设施属于基础设施，而非应用程序代码。唯一的问题是在做出改变之前积累了多少耦合。