RAG映射：流程阶段、核心组件及版本格局
了解检索增强生成从端到端的运作原理，RAG系统需要哪些组件，以及各种不同的RAG变体是如何归类到同一框架中的。
来源: The Complete Guide to RAG — Part 1: What It Is, Why It Exists & How It Works
语言模型虽然具备出色的推理能力，但却可能对您的内部文档、上周的政策变更或一小时前提交的工单一无所知。检索增强生成（RAG）通过在模型回答问题之前让其从外部知识源中查找信息，从而弥补了这一缺陷。本指南将介绍RAG能够解决的问题与无法解决的问题、RAG系统的三个阶段、构建该系统所需的组件，以及如何理解众多不同类型的RAG变体。
一句话概括RAG
RAG结合了两个流程：
- 检索：在外部知识源中定位相关信息。
- 生成：让语言模型根据检索到的信息生成答案。
简单来说，RAG会在模型给出回应之前提供参考库供其查阅。最初提出这一方法的研究将其描述为将模型在训练过程中存储在其权重中的参数化记忆与可以独立检索和更新的非参数化记忆相结合。
用开卷考试作类比会很直观：
- 大语言模型就是学生。
- 知识库则是教科书。
- 检索系统就是翻到对应页面的学生。
- 最终答案则是学生参考那些页面后写出的回答。
模型负责提供推理能力和流畅的语言表达；而检索系统则负责提供与特定问题相关的事实信息。
RAG旨在解决的问题
仅依赖模型内置的知识会遇到若干实际限制，而RAG为每一项限制都提供了部分解决方案。
知识仅限于训练阶段
模型无法知晓在其训练数据收集之后新增或更改的任何内容。借助RAG，最新信息存储在外部数据库中，你可以随时对其进行更新，而无需改动模型本身。
无依据或编造的答案
模型有时会生成错误或缺乏根据的表述。通过检索到的证据，模型可以有具体的依据作为支撑，从而减少无依据的输出。但这不能完全消除此类问题：检索可能会返回错误的段落，信息来源本身也可能不准确，而且模型仍可能做出证据无法支持的断言。
模型从未见过的私有数据
通用型模型无法访问您组织的内部文档、专有代码或私有知识。RAG允许应用程序在查询时调用经过授权的私有数据源，而无需针对这些数据进行重新训练。不过访问控制依然重要：检索系统应仅返回当前用户有权查看的内容。
频繁变化的信息
政策、产品和技术文档以及内部记录都在不断变动。每当有内容变更时，为语言模型重新训练的成本和耗时都远高于在检索索引中添加或更新条目。
过大而无法完整发送的文档
在每次请求中都粘贴整个文档会浪费资源且增加成本。RAG仅发送知识库中的相关部分，这样既能保持提示信息的针对性，又能减少数据量。
无关上下文带来的干扰
过多的松散相关内容会使得模型更难找到关键证据。过滤、重排序和上下文压缩等功能都是为了提升最终传递给模型的内容质量。
RAG能够增强内容的依据性并降低幻觉产生的概率，但并不能保证答案的准确性或无幻觉。应将其视为可靠性工具，而非正确性证明。
RAG系统的三个阶段
最简单的来说，每个RAG系统都会执行三件事：准备知识、从中检索信息，以及利用这些信息生成内容。
第一阶段：索引
索引工作在用户提出问题之前进行。诸如PDF、网页、文档或数据库记录等源材料会被：
- 加载到系统中，
- 分割成更小的片段，
这样就能得到可搜索的知识表示形式。从概念上讲，你实际上是在自己的数据上构建一个搜索索引。
第二阶段：检索
当有查询出现时：
- 使用与索引时相同的模型将查询转换为嵌入，
- 在知识库中搜索相近的向量，
- 选出最相关的片段，
- 通过可选的过滤或重排序进一步优化选择结果。
从查询到候选片段的流程如下：
User Query
│
▼
[Embedding Model]
│
▼
[Query Vector]
│
▼
[Vector Database]
│
▼
[Relevant Chunks]
关键在于查询与文档存在于同一个向量空间中。正因如此，查询时使用的嵌入模型必须与构建索引时使用的模型一致；若使用不同的模型，生成的向量将无法进行有意义的比较。
第三阶段：生成
选定的文本片段会与用户的问题结合形成提示语，随后模型会根据该提示语生成响应：
User Query
+
Retrieved Context
│
▼
[Prompt / Context]
│
▼
[LLM]
│
▼
Final Answer
最终生成的答案既依赖于模型的一般能力，也依赖于从知识源中提取的具体信息。例如，提示语如何呈现这些信息——是否标注了模型可引用的来源标签——会极大影响答案与原始信息的契合度。
索引流程内部
RAG系统的大部分质量取决于索引环节，其基本结构如下：
Raw Data
│
▼
Document Loader
│
▼
Text Chunking
│
▼
Embedding Model
│
▼
Vector Database
原始数据
知识几乎可以来自任何地方：
- PDF文件
- 网站
- 文档资料
- 文字处理文档
- 数据库
- API接口
- 公司内部文件
文档加载器
文档加载器负责读取源数据并将其转换为统一的结构，以便后续处理流程使用。例如在LangChain中，各类加载器都遵循相同的接口规范，能够生成Document对象，并且同时提供load()和lazy_load()方法。延迟加载版本会逐个生成文档，而不会将所有内容都加载到内存中，这对于处理大量数据集尤为重要。LangChain和LlamaIndex是大多数人最初会使用的两个生态系统。
分块处理
大型文档会被拆分成较小的部分，称为块，因为通常提取文档中的相关段落比将整个文档交给模型更为有用。一个很好的类比是将一本书拆成若干张索引卡，每张卡片对应一个观点。
块的大小和重叠度并没有通用的标准值。它们取决于文档的结构、预期的问题类型、所使用的嵌入模型以及后续处理所能承受的上下文量。过小的块会丢失周围的含义；过大的块则会稀释关键句子的信息强度。如需更深入地了解这种权衡关系，请参阅保留证据的分块方法。
嵌入模型
每个数据块都会被转换为一个嵌入向量，即一组代表其含义的数字：
"RAG retrieves relevant information"
↓
[0.24, 0.87, 0.11, 0.62, ...]
嵌入向量使系统能够衡量两段内容之间的相似度，而这正是语义搜索和检索的实现基础：即使词汇重合度很低，含义相似的文本在向量空间中也会彼此靠近。
在 OpenAI 的 text-embedding-3 系列模型中，小型模型默认生成 1536 维的向量，而大型模型则生成 3072 维的向量。
这两种模型都支持 dimensions 参数，用于生成维度更低的向量，从而以稍低的精度换取更少的存储空间和更快的搜索速度。模型系列会不断更新，因此请在提供商的文档中确认当前可选配置。
向量数据库
这些嵌入向量会被存储在专为快速相似度搜索设计的向量数据库或向量索引中。常见的选择包括：
- Qdrant
- Pinecone
- Chroma
- Weaviate
- FAISS
存储的记录通常不仅包含向量数据，还保存原始文本片段以及来源、页码、文档ID或时间戳等元数据。这些元数据使得后续能够按日期或文档类型进行筛选，并明确答案的来源。
RAG应用程序的构成要素
综合来看，一个典型的RAG应用程序由六类组件构成：
- 知识源：提供信息，例如PDF文件、网站、SQL数据库或API。
- 文本分割器：利用LangChain的文本分割工具或自定义逻辑将文档拆分成可处理的片段。
RAG系列架构概览
一旦了解了基本流程，各类变体的生态系统可能会显得十分复杂。目前并不存在统一的RAG类型标准列表；学术论文和工程博客中对于架构、检索策略、上下文处理技术、知识来源以及专用系统等概念使用了大量重叠的名称。按照其功能差异进行分类有助于理清这些架构的关系。
基本架构
- 简单RAG：采用嵌入、检索和生成的三步直连流程。
- 高级RAG：在检索前后增加步骤，如查询重写和重新排序。
- 模块化RAG：将每个阶段视为可互换的模块，便于重新组合。
检索策略
- 单次检索RAG：每个问题仅进行一次检索。
- 多查询RAG：为同一问题生成多种表述并分别进行检索。
- 迭代式RAG：先检索，再分析，最后再次检索。
- 多跳RAG：当答案需要关联多个事实时，通过多次检索实现。
- 混合式RAG：结合语义向量搜索与关键词搜索。
上下文与分块方法
- 父子RAG：匹配小型分块，但返回其所属的较大父级部分。
- 句子窗口RAG：检索某句话及其相邻内容。
- 分层RAG：从文档到段落，逐层进行搜索。
- 上下文增强RAG：在嵌入分块之前先为其添加文档级别的上下文信息。
- RAPTOR：构建递归摘要树，并在各级之间进行检索。
自我修正与自适应方法
- 自我RAG：模型会判断是否需要检索以及其输出是否有依据。
- 校正型RAG（CRAG）：会对检索到的结果进行评估，若结果质量不佳则触发重新检索。
- 自适应RAG：会根据问题的复杂程度选择合适的处理策略。
- 基于反馈的RAG：利用用户或评估者的反馈逐步优化检索效果。
智能体方法
- 智能体RAG
- 多跳智能体RAG
- 多智能体RAG
在这些方法中，智能体会自行决定何时何地进行检索，可能借助多种工具或协作智能体，而非遵循固定的流程。
按知识来源划分的变体
有些名称仅用于说明证据的来源。Vector RAG会搜索嵌入索引，而SQL RAG和Table RAG则查询关系型或表格数据，通常由模型来编写查询语句。GraphRAG从实体与关系的知识图中获取信息，Web或Search RAG则从搜索引擎中获取实时结果，Knowledge-Base RAG则利用经过整理的语料库，如帮助中心或维基页面。
多模态变体
其他标签指的是所检索内容的类型。Text RAG是默认形式；Image、Video和Audio RAG则从相应的媒体中获取信息，通常通过嵌入向量或文字转录实现，而Multimodal RAG则是涵盖多种此类技术的统称。
专业化变体
最后一类是为特定需求设计的群组名称系统：单一领域如法律或医学（领域专用型）、需要考虑时间因素的查询（时间相关型）、针对个体用户定制的答案（个性化）、多种语言的查询与来源（多语言型）、必须得到保护的敏感数据（隐私保护型），以及分布在多个站点或组织中的索引（分布式或联合型）。
这些类别可以相互重叠。一个实际的生产系统可能同时具备混合型、智能代理型和领域专用型的特点；这些标签描述的是设计选择，而非互斥的产品类型。
从简单到复杂的处理流程
最基本的处理流程是一条直线：
Query
↓
Embedding
↓
Vector Search
↓
Top-K Chunks
↓
LLM
↓
Answer
这正是人们通常所说的简单型或基础RAG：将问题嵌入后，选取距离最近的top-k个片段，再将它们传递给模型。这是一种合理的初始版本，对于规模较小且结构清晰的语料库而言往往已经足够。
更成熟的系统会在检索过程之外增加更多环节：
User Query
↓
Query Rewriting
↓
Query Routing
↓
Hybrid Retrieval
↓
Metadata Filtering
↓
Reranking
↓
Context Compression
↓
LLM
↓
Answer
每个环节都针对特定的缺陷。查询重写功能用于修正模糊或口语化的提问，路由机制负责将问题发送到正确的索引或工具，混合检索方式能捕捉到纯向量搜索会遗漏的精确术语，元数据过滤可剔除超出范围的文档，重新排序功能则利用更精准的模型对候选结果进行重新排列，而压缩技术则用于削减剩余内容以符合资源限制。只有当能够证明这些环节确实能解决相应问题时才应添加它们；复杂性本身并非目标。
为何RAG不仅仅是向量数据库与LLM的结合
初学者普遍存在一种误解，认为RAG就是“存储嵌入向量、查询这些向量、再调用模型”。但实际上，生产环境中的流程往往更复杂：
Document Processing
↓
Chunking
↓
Metadata
↓
Embedding
↓
Vector / Keyword Retrieval
↓
Filtering
↓
Reranking
↓
Context Compression
↓
Prompt Construction
↓
LLM
↓
Validation
↓
Final Answer
这一流程中的每一步都可能影响最终答案的质量：错误的解析、草率的分块处理、缺失的元数据、不匹配的嵌入模型、过弱的过滤机制，或是设计不当的提示词。正因如此，将向量存储与模型连接起来仅仅只是开始而已。无论模型多么强大，如果输入的信息有误，它也无法完全弥补这一缺陷。
如何评估RAG系统
仅仅生成答案并不足以作为评判标准。一个优秀的RAG系统应当能够检索到真正有用的信息，并基于这些信息生成合理的回复。值得关注的评估维度包括：
- 检索质量：是否真的能够获取到相关的文档或信息片段？
分别对各个阶段进行测量是诊断问题的关键；按故障阶段评估RAG的方法展示了如何实现这一目标。
下一步该做什么
更深一层的细节在于索引路径本身：PDF如何转化为文本，加载、解析与清洗之间的区别，字符级、标记级、递归级、语义级和结构感知型分块方法的优缺点，分块重叠实际上起什么作用，元数据应如何设计，文本如何转化为向量，余弦相似度、点积和欧几里得距离之间的差异，以及向量数据库如何大规模地进行相似性搜索。
核心要点
- RAG将模型训练所得的知识与可搜索的外部存储相结合，从而使答案能够反映私有信息和最新动态，而无需重新训练模型。
- 它虽能减少无依据的答案，但无法保证答案的正确性；检索、信息来源和内容生成环节仍可能出错。