企业级RAG落地之难：不在检索，而在整条信息链的可靠性工程

检索增强生成（RAG）演示很容易令人兴奋。

取几份公司文档，将其置于一个搜索系统之后，将相关段落发送给 大语言模型 （LLM），然后提出一个问题。答案通常在几秒钟内返回，并常附带引用出处。

接着，你将其连接到真实的公司数据。

此时事情才变得有趣起来。

这些文档彼此不一致。部分文档已过时。有用的信息埋藏在电子表格和扫描版PDF文件中。不同员工拥有不同的访问权限。一个在10,000份文档知识库上运行完美的搜索查询，当知识库规模扩大后，其行为可能变得截然不同。

这正是大多数真正工程工作开始的地方。

RAG 仍是将大语言模型与企业信息相连接的一种实用方式。但生产环境中的 RAG 并非仅是在提示词（prompt）后简单部署一个向量数据库。它涉及数据质量、搜索、安全、评估、时效性、成本及运维等多个方面。

模型只是整个系统的一部分。

检索必须被视作基础设施

人们很容易将检索视为应用程序中的另一项功能：用户提出一个问题，系统检索若干文本块，模型在提示词中接收这些文本块，然后返回答案。

当数据量较小且相对干净时，这种做法可能奏效。

企业数据 通常并非如此。

一家公司的知识可能分散于数据库、内部维基、支持工单、合同、电子表格及文件共享系统之中。同一款产品在不同系统中可能有不同名称。某些文档具有正式效力；另一些则撰写于数年前且从未更新。

更优的嵌入模型无法修复糟糕的数据

当检索质量下降时，更换嵌入模型是一个显而易见的起点。

有时这确实有效。

但请考虑一个更简单的问题：一份文档将某产品称为“Enterprise Security Gateway”；另一份称其为“ESG”；第三份则称之为“the gateway”。与此同时，实际的配置限制却位于一份从未被正确解析过的电子表格中。

应采取的行动：

• 确定哪份文档具有权威性。

• 明确旧政策何时已被取代。

• 修复因提取错误而损坏的表格或其他内容。

这些都是数据管理问题。在调优 检索之前，团队需清楚信息来源、最后更新时间、责任人以及对其可信度的判断依据。

否则，你可能构建出一个以惊人语义准确性检索出错误文档的系统——它依然错误。

分块（chunking）是一项架构决策

分块常被当作一项配置设置来处理。

它不应如此。

若分块过大，检索会带回大量无关内容；若分块过小，则有用的关系将消失。

设想一份技术文档，其中包含一个标题、一张配置表，以及一段解释该表例外情况的段落。若将这些部分拆开，检索可能找到该表，却遗漏了解释该表适用条件的段落。

不存在某种“魔法般”的理想分块大小。源内容的结构应影响其索引方式。

• 产品手册可能受益于保留标题与章节结构。

• 政策类文档可能需要附加诸如部门、地区及生效日期等元数据。

• 数据库模式作为结构化关系进行索引，可能比普通文本更合理。

一项 2024年关于企业级RAG的研究 发现，对知识库内容实施相对简单的变更即可影响系统性能，同时亦强调了监控与人工评估的重要性。

这一教训很直接：应根据信息本身特性进行分块，而非依据任意设定的token数量。

向量搜索很有用，但仅靠它并不足够。

语义搜索擅长查找与查询含义相近的信息。

企业搜索往往需要更高精度。

假设有人搜索某个精确的产品ID、合同编号、错误代码或政策名称。语义搜索系统可能返回若干概念上相关但并未命中员工实际所需的确切文档。

此时混合式检索（hybrid retrieval）便派上用场。混合式系统不单依赖向量相似度，还可结合语义信号与基于关键词的搜索，并在适当时机引入重排序（reranking）。

近期有关企业级检索的报道也凸显了向 混合式方法演进的趋势 因为组织在仅使用向量搜索时遇到了其能力极限。

关键点不在于每家公司都应立即用其他方法取代向量搜索，而在于不同问题需要不同的检索信号。

• 概念性问题 → 语义检索可能效果良好。

• 精确标识符 → 关键词匹配至关重要。

• 混合型工作负载 → 结合两种方法可能更合理。

工作负载应决定架构。

将检索过程与最终答案分开测试。

RAG 最容易犯的错误之一，是仅凭最终响应来评判系统。

即使检索到的信息错误，响应仍可能听起来令人信服。

相反情况也可能发生：正确段落被成功检出，却因混杂了过多无关上下文，导致模型未能加以利用。

当答案错误时，存在多个可能的故障点。

• 原始数据本身是否错误？

• 文档解析是否出错？

• 分块（chunking）是否移除了重要上下文？

• 检索是否遗漏了相关段落？

• 正确段落是否排名过低？

• 检出的文档之间是否存在相互矛盾？

• 抑或模型即便拥有必要证据，仍单纯失败？

这些问题需要不同的修复方式。例如， Amazon Bedrock 的 RAG 评估文档 将仅检索（retrieve-only）评估与检索并生成（retrieve-and-generate）评估分开，所用指标涵盖上下文相关性、覆盖率、正确性、完整性及忠实度等领域。

具体工具本身不如其背后的方法论重要。如果正确文档从未送达模型，那么更改提示词（prompt）很可能无法解决该问题。

Ring 展示了当 RAG 遇上真实数据时会发生什么。

Ring 的生产级支持系统提供了一个有用范例。

在 2026 年 3 月的技术报告中，AWS 描述了 Ring 如何为覆盖 10 个国际区域的客户支持构建一个多地区（multi-locale）RAG 系统。挑战不仅在于翻译支持内容；不同地区具有不同的产品配置、要求和支持信息。

Ring 利用元数据驱动的过滤机制，从集中式知识系统中提供面向特定地区的支持内容；同时将内容摄取、评估和上线推广划分为彼此独立的工作流。据 AWS 称，该方法使扩展至每个新增地区所需的成本降低了 21%。

有趣之处并非 AWS 的产品列表。

而是其架构。

地区（locale）成为元数据；内容更新成为受控流程；评估成为工作流的一部分，而非仅在部署后才进行。

安全性绝不能被视为事后补救。

当 RAG 系统连接至公司内部信息时，权限管理尤其重要。

设想一名员工询问某份客户合同。检索系统找到了正确文档，并将其提供给模型。

从检索角度看，这看似成功。

但从 安全视角来看，这可能构成一次严重失败。

访问控制必须在受限信息成为模型上下文之前即已实施。在模型已接收到敏感信息之后再对答案进行过滤，为时已晚。

• 必须在受限信息进入上下文之前完成身份验证（identity check）。

• 授权规则（authorization rules）应随检索请求一同传递。

• 当系统可执行多次检索或工具调用时，可审计性（auditability）至关重要。

安全性必须内嵌于检索过程本身，而非生成后的清理步骤。

时效性（Freshness）是一项运维问题。

企业知识持续变化。

价格变动；政策更新；产品规格替换；访问权限变更；支持工单关闭。

若索引未能同步更新，大语言模型（LLM）可能自信地返回上周正确、今日却已错误的信息。

一个生产系统需明确回答以下问题：哪些数据源需近乎实时更新；变更以多快的速度抵达索引；当权威文档被删除时会发生什么；旧版本如何处理；以及工程师能否追溯影响某次回答的具体文档版本。

• 哪些数据源需要近实时更新？

• 变更多久能到达索引中？

• 当一份权威文档被删除时会发生什么？

• 旧版本如何处理？

• 工程师能否追溯是哪个文档版本影响了某个回答？

这些问题大多属于数据与运维范畴，但它们直接影响AI系统的质量。

成本与延迟会改变系统设计

在原型开发阶段容易忽略另一项权衡。

检索更多文档可提升召回率，但也会增大上下文尺寸；增加检索或重排序环节可在提升相关性的同时引入延迟；更大的提示（prompt）可能提高推理成本。

更多的上下文并不自动等同于更优的上下文。

如果五个相关段落即可回答一个问题，那么检索二十个段落可能只会让模型面对更多无关材料去筛选，还可能引入相互矛盾的信息。

目标是以足够快、足够低成本的方式，检索出足够多且正确的信息，使企业能够规模化地使用该系统。

一个实际投产的RAG系统真正需要什么

一套成熟的 RAG架构 更容易被理解为若干相互连接的层级。

• 数据源层—— 连接企业系统并追踪来源出处（provenance）。

• 处理层—— 解析、清洗并结构化输入内容。

• 索引层—— 构建搜索所需的数据表征。

• 检索层—— 融合语义、关键词或领域特定信号。

• 策略层—— 在受限信息送达模型前应用身份与访问控制规则 。

• 评估层—— 分别度量检索效果与生成效果。

• 可观测性层—— 记录足够信息，以便安全诊断故障。

• 生成层—— 将选定的上下文转化为答案或智能体（agent）操作。

团队未必需要自行构建每一层；托管服务与开源组件可分别承担技术栈的不同部分。

关键问题其实更简单：每一部分由谁负责？团队如何知晓其发生故障？

真正的问题并非RAG是否已死

随着上下文窗口扩大、大语言模型处理长输入的能力增强，人们自然会质疑RAG是否仍有必要。

对企业团队而言，这或许并非最有价值的问题。

更优的问题是：该系统能否持续地、在正确的时间，将正确的信息提供给正确的模型、交付给正确的用户？

有时答案将是传统RAG。

有时则会涉及混合检索、结构化数据、基于图的检索或长上下文方法。在许多系统中，这些方法中的若干种将协同工作。

架构应遵循信息问题本身，而非相反。

大语言模型（LLM）无法弥补系统向其提供错误信息所导致的缺陷。

最强的企业级AI系统未必采用最新模型或最大上下文窗口；它们必然是那些能管控抵达模型的信息、强制执行访问权限、追溯信息来源，并衡量最终答案是否真正有用者。

RAG从来就不只是关于检索。

它关乎在AI系统与其完成有用工作所需的信息之间，构建一条可靠路径。在生产环境中，围绕该路径的工程实践，其重要性丝毫不亚于检索算法本身。

阿卜杜拉·赛亚德（Abdullah Sayyad）是一名科技作家与研究员

欢迎加入 VentureBeat 社区！

我们的客座投稿计划旨在邀请技术专家分享洞见，并就人工智能（AI）、数据基础设施、网络安全及其他塑造企业未来前沿技术，提供中立、无利益关联的深度剖析。

阅读更多 来自我们的客座投稿计划——并查看我们的 投稿指南 ，若您有意撰写并投稿自己的文章！