什么是检索增强生成 (RAG)？

自从大语言模型 (LLM) 成为技术焦点以来，其处理通用知识的能力令人惊叹。然而，当问题转向企业内部文档、专有知识库或实时数据时，LLM 的局限性变得显而易见：它们无法访问训练数据之外的私有信息。检索增强生成 (RAG) 的诞生正是为了解决这一核心需求。在 LLM 生成答案之前，它首先从外部知识库中检索最相关的上下文，并将其作为“参考资料”输入给 LLM，从而引导其生成准确的答案。简而言之，RAG 将 LLM 从“依赖记忆”提升到“有据可依”，显著提高了它们在专业领域和实时信息查询中的准确性和可信度。

为什么 RAG 很重要？

尽管 LLM 在语言理解和生成方面表现出色，但它们仍存在固有的局限性

静态知识：模型的知识基于训练时的数据快照，无法自动更新，难以感知最新信息。
外部数据盲区：它们无法直接访问企业私有文档、实时信息流或特定行业的内容。
幻觉风险：在缺乏准确证据时，它们为了保持对话流畅，仍可能编造听起来合理但错误的内容。

RAG 的引入为 LLM 提供了实时、可靠的“事实依据”。其核心机制分为两个阶段：

检索阶段：根据用户的问题，快速从外部知识库中检索出最相关的文档或数据片段。
生成阶段：LLM 将检索到的信息作为上下文，结合自身的语言能力，组织并生成最终答案。

这将 LLM 从“凭记忆说话”升级为“看文档说话”，显著增强了在专业及企业级应用中的可靠性。

RAG 如何工作？

检索增强生成通过引入信息检索机制，利用实时、外部或私有数据源，使 LLM 能够生成更高质量的回复。其工作流程可分为以下关键步骤：

数据处理与向量化

RAG 所需的知识来自各种格式的非结构化数据，如文档、数据库记录或 API 返回内容。这些数据通常需要先进行分块（Chunking），然后通过嵌入模型（Embedding Model）转化为向量，并存储在向量数据库中。

为什么需要分块？直接索引整个文档会面临以下问题：

检索精度下降：长文档向量化会导致语义“平均化”，丢失细节。
上下文长度限制：LLM 的上下文窗口有限，需要筛选最相关的部分进行输入。
成本与效率：长文本的嵌入计算和检索成本更高。

因此，智能分块策略是平衡信息完整性、检索粒度和计算效率的关键。

检索相关信息

用户的查询也会被转化为向量，在向量数据库中进行语义相关性搜索（例如计算余弦相似度），匹配并召回最相关的文本片段。

上下文构建与答案生成

检索到的相关内容作为事实依据添加到 LLM 的上下文中，由 LLM 最终生成答案。因此，RAG 可以被视为用于自动构建上下文的“上下文工程 1.0”。

深入探索现有 RAG 架构：超越向量检索

工业级的 RAG 系统远非“向量搜索 + LLM”那么简单；其复杂性和挑战主要体现在检索过程中。

数据复杂度：多模态文档处理

核心挑战：企业知识多以包含文本、图表、表格和公式的多模态文档形式存在。简单的 OCR 提取会丢失大量语义信息。

先进实践：领先的解决方案（如 RAGFlow）倾向于使用视觉语言模型 (VLM) 或专门的解析模型（如 DeepDoc）将多模态文档“翻译”为富含结构和语义信息的单模态文本。将多模态信息转化为高质量单模态文本已成为先进 RAG 的标准做法。

分块的复杂性：精度与上下文的权衡

简单的“分块-嵌入-检索”流水线存在内在矛盾：

语义匹配：需要较小的文本块以确保语义焦点清晰。
上下文理解：需要较大的文本块以确保信息的完整性和连贯性。

这迫使系统设计在“精准但碎片化”与“完整但模糊”之间做出艰难的权衡。

先进实践：领先的解决方案（如 RAGFlow）采用了语义增强技术，例如构建语义目录和知识图谱。这些技术不仅解决了物理分块带来的语义碎片化问题，还能够基于实体关系网络发现跨文档的相关内容。

为什么向量数据库不足以支撑 RAG？

向量数据库擅长语义相似度搜索，但 RAG 需要精确可靠的答案，这对检索系统提出了更高要求：

混合搜索：仅依靠向量检索可能会漏掉精确的关键词匹配（如产品代码、法规编号）。混合搜索结合了向量检索与关键词检索 (BM25)，兼顾了语义广度和关键词精度。
张量或多向量表示：为了支持跨模态数据，采用张量或多向量表示已成为重要趋势。
元数据过滤：基于日期、部门和类型等属性进行过滤是业务场景中的刚需。

因此，RAG 的检索层是一个以向量搜索为基础，但必须整合全文搜索、重排序和元数据过滤等能力的复合系统。

RAG 与记忆：同源异流的检索

在 Agent 框架内，记忆机制的本质与 RAG 相同：都是根据当前需求从存储中检索相关信息。核心区别在于数据源：

RAG：针对的是用户预先提供的现有静态或动态私有数据（如文档、数据库）。
记忆：针对的是 Agent 在交互过程中实时生成或感知到的动态数据（如对话历史、环境状态、工具执行结果）。它们在技术底层（如向量检索、关键词匹配）高度一致，可以看作是应用在不同场景下的同一种检索能力（“现有知识” vs “交互记忆”）。一个完整的 Agent 系统通常既包含用于固有知识的 RAG 模块，也包含用于交互历史的 Memory 模块。

RAG 应用

RAG 在几个典型场景中展示了明确的价值：

企业知识问答与内部搜索
通过将企业私有数据向量化并结合 LLM，RAG 可以直接根据权威来源返回自然语言答案，而非文档列表。在满足智能问答需求的同时，它天然符合企业对数据安全、访问控制和合规性的要求。
复杂文档理解与专业问答
对于合同、法规等结构复杂的文档，RAG 的价值在于其能够在保持上下文完整性的同时，生成准确、可验证的答案。其系统准确性很大程度上取决于文本分块和语义理解策略。
动态知识融合与决策支持
在需要综合多源信息的业务场景中，RAG 演变为业务决策的知识编排和推理支持系统。通过多路召回机制，它融合了不同系统和格式的知识，在生成阶段保持事实一致性和逻辑可控性。

RAG 的未来

RAG 的演进正沿着几条清晰的路径展开：

RAG 作为 Agent 的数据基础
RAG 与 Agent 是架构与场景的关系。Agent 要实现自主、可靠的决策与执行，必须依赖准确及时的知识。RAG 为其提供了访问私域知识的标准能力，是构建知识感知型 Agent 的必然选择。
高级 RAG：利用 LLM 优化检索本身
下一代 RAG 的核心特征是充分利用 LLM 的推理能力来优化检索过程，例如重写查询、总结或融合结果，或实现智能路由。用 LLM 赋能检索的每个环节是突破当前性能瓶颈的关键。
迈向上下文工程 2.0
当前的 RAG 可以看作是上下文工程 1.0，其核心是为单个问答任务组装静态知识上下文。即将到来的上下文工程 2.0 将以 RAG 技术为核心进行扩展，成为一个能为 Agent 自动动态组装全面上下文的系统。该系统融合的上下文将不仅来自文档，还包括交互记忆、可用工具/技能以及实时环境信息。这标志着 Agent 开发从“手工坊”模式向自动化上下文工程的工业起点转变。

RAG 的本质是为大语言模型构建一个专用、高效、可信的外部数据接口；其核心是检索（Retrieval），而非生成（Generation）。从解决私有数据访问的实际需求出发，其技术深度体现在对复杂非结构化数据检索的优化上。随着与 Agent 架构的深度融合以及向自动化上下文工程的发展，RAG 正在从一种提高问答质量的技术，演变为构建下一代可信、可控、可扩展智能应用的核心基础设施。