基础原理

RAG（Retrieval-Augmented Generation）中文叫做检索增强生成，它是一种将外部知识库与大语言模型（LLM）相结合的技术。其核心思想是在大模型生成回答之前，先检索文档将检索到内容作为上下文输入给模型，从而提高回答的准确性和时效性。

在一个典型的 RAG 系统中，首先会对外部文档进行预处理并向量化存储形成知识库，当用户提出问题，系统会将问题转化成向量，并且计算出向量相似度，在知识库中找出与用户问题相近的片段，然后将用户问题和相似片段一起丢给大模型（prompt），大模型在此基础上生成答案。

总结上述过程，大致可以分为三个阶段：

  1. 准备阶段：分片、索引
  2. 检索阶段：召回、重排
  3. 生成阶段：生成

使用场景

通过上述的介绍不难发现，RAG 适合用做智能客服或者企业内部知识库等私有化数据的场景。一般来说，传统的 LLM 通常都有上下文的限制（即使 Gemini 有百万的上下文），这就导致大模型在工作时始终有上下文局限，我们不可能把大量的私有数据一下子全部喂给大模型，而 RAG 通过分片、向量化存储和向量相似性等手段解决了 LLM 根本局限性。

总结一下，可以归纳为三大核心优势：

  1. 获取最新信息：RAG通过连接到实时更新的数据源（如新闻网站、社交媒体流或企业内部的动态数据库），克服了LLM的知识时效性问题。这使得RAG系统能够提供反映最新情况的答案，这在金融、新闻和客户服务等快速变化的领域至关重要。
  2. 增加事实性并减少幻觉：RAG通过“事实接地”（Factual Grounding）来提高输出的准确性。它要求LLM的回答必须以检索到的外部文档为依据，而不是仅凭其内部的参数化知识。这种机制显著降低了模型产生“幻觉”的风险，并允许系统在生成答案时提供引文或来源链接，从而让用户可以验证信息的准确性。
  3. 实现专业领域知识：RAG使得通用的LLM能够在不经过昂贵和耗时的重新训练或微调的情况下，应用于高度专业的领域。无论是医疗、法律还是制造业，企业都可以通过构建包含其专有文档、手册和数据的知识库，来创建一个能够理解并回答特定领域问题的“专家系统”。

下面来说一下 RAG 的工作流程。

工作流程

第一阶段：分片与索引

  1. 数据分片（Text Splitting）

    上面说到，LLM 存在上下文的局限，往往无法一次性处理长数据源，因此需要将数据源（文档、链接内容等）切分成多个片段。需要说明的是，分片方式的选择应当是灵活的，它应该是具备“上下文感知”（Context-aware）能力，尽可能沿着段落、章节、标题等自然边界进行分割，以保持每个块内部的语义连贯性，这对于确保检索的精准度和生成答案的质量至关重要。

  2. 嵌入（Embedding）

    然后，每个文本块都被送入一个嵌入模型（Embedding Model）中，转换成一个高维的数值向量，即“嵌入向量”。这个向量是文本块语义的数学表示，在向量空间中，意思相近的文本块，其对应的向量在空间中的距离也更近。嵌入模型的选择是一个关键的架构决策，因为它直接决定了后续语义搜索的质量和效果。

  3. 索引与存储（Indexing & Storage)

    上一步通过 Embedding 将片段文本转换为向量后，将片段文本连同片段向量存入向量数据库中的过程叫做索引。

第二阶段：召回与重排

第二阶段主要包含查询转换、向量化搜索和重新排名等过程，我们一个个概念说。

  1. 召回

    召回就是搜索与用户问题相关的片段过程，大致可以描述如下：
    用户输入问题 -> Embedding（Embedding 下文有专门说到） -> 转换为向量 -> 向量数据库 -> 查询与用户问题相近的片段 -> 召回结果

    需要注意的是，向量数据库查询与用户问题相近的片段这一过程，我们叫做向量相似度计算。向量相似度计算方式有很多种，目前比较常见的有余弦相似度、欧式距离、点积等。

  2. 重排

    重排做的事情就是重新排序，它做的事情跟召回类似，对召回结果中的相似片段进行二次评估，从而找到跟用户问题更为相似和接近的片段作为重排结果，提升回答的准确性。跟召回不同的是，重排阶段使用了一个更小、更专业的重排模型，它在提升准确性的同时也带来了更大的开销和成本，因此重排阶段不能跟召回混在一起。

第三阶段：生成

最后这个阶段比较好理解，生成最终答案。

在第二阶段得到重排结果后，系统将经过重新排名后的、最相关的文档块内容，与用户的原始查询组合在一起，形成一个全新的、内容丰富的“增强提示”（Augmented Prompt）。这是一个关键的提示工程（Prompt Engineering）步骤。提示语会明确地指示LLM，将提供的文档块作为其回答的唯一事实依据。

这个增强提示被发送给LLM。模型被要求在严格遵循所提供上下文的基础上，综合信息，并以流畅、连贯的自然语言生成对用户原始问题的回答。这种“有约束的生成”是RAG的核心机制，它将LLM的创造力引导到基于事实的轨道上，从而确保了答案的准确性和可靠性。

最后，生成的答案会呈现给用户。一个设计良好的RAG系统通常会附上答案所依据的来源信息，例如源文档的名称、链接或具体段落的引用 。这种透明度不仅增强了用户的信任感，也为需要审计和验证的专业场景提供了必要支持。

RAG 系统的核心组件说明

上面说完了 RAG 大致的工作流程，下面来说一下 RAG 系统中常见的核心组件。

文本拆分器

上面说到了 RAG 系统的流程第一阶段就需要对数据源进行分片，分片的方式有多种，例如可以对数据源按字数分片、按段落分片、按章节分片和按页码分片等。这其中需要我们的 RAG 能够具备分片的能力，例如常见的 LangChain 就提供了多种文本拆分器，可以满足对数据源进行不同分片方式的场景。

Embedding

Embedding 说简单点就是将文本转换为向量的过程。

我以一个二维向量为例，假设 “某产品的工作电压是 210V～250V 之间” 这个文本片段对应的向量是 [1,2]，“某产品的最佳工作电压是 220V” 这个文本片段对应的向量是 [1,1]，“某产品保修 3 年” 这个文本片段对应的向量是 [-3,-1]，容易看到，前两个文本片段包含的内容比较接近，转化为向量后，向量也是十分接近的，而第三个文本片段和前两个内容差距比较大，转化为向量后差别也比较大，这正是 Embedding 的意义，含义相近的文本在做 Embedding 之后，向量也是相近的。

现在假设用户的问题是 ”某产品应该在多大的电压下工作“，在对用户问题做 Embedding 之后得到一个向量，我们就可以根据向量相似度找到与之相近的向量文本片段，从而将用户问题和相近的文本片段一起丢给大模型，大模型就可以根据这些信息生成最终的答案。

向量数据库

向量数据库是 RAG 系统的基石头，它负责存储和检索嵌入向量，常见的主流的向量数据库有 Pinecone 和 ChromaDB 等。