本文全面解析RAG（检索增强生成）系统，通过为LLM引入外部知识库，先检索相关信息再生成回答，有效减少"幻觉"并提高准确性。详细拆解五大核心组件：数据分块技术、数据转换方法（嵌入与关键词结合）、数据库选择、查询转换策略及检索后处理流程。这些技术共同构建完整RAG系统，使模型能回答近期话题或小众领域问题，无需大规模微调，是LLM应用的重要技术方向。
本文较长，建议点赞收藏。更多AI大模型应用开发学习视频及资料，在智泊AI。
一、简单理解
这篇文档核心是把“检索增强生成（RAG）系统”拆解开，用直白的方式讲清它的工作逻辑、关键部分和实用价值。
1、RAG系统到底是什么？
简单说，RAG是给大语言模型（LLM）加了个“外部知识库”：你提问时，它不会只靠模型自己的“旧知识”，先去知识库搜相关信息，再把信息和问题一起交给模型，最后生成更准、更及时、不瞎编（少“幻觉”）的回答。
2、RAG的核心流程：两步走
整个系统跑起来分两大环节，缺一不可：
（1）预处理（搭知识库）：先把要用到的资料（比如书籍、手册）整理好，建成能快速搜索的数据库。
（2）推理（响应用户）：用户提问后，先处理问题，再去数据库搜相关内容，最后让模型结合搜到的信息出答案。
3、关键组件：每个环节的“核心操作”
（1）数据分块：把长文档拆成“合适的小块”
- 就是把一本厚书、一篇长文，拆成电脑好处理的片段。
- 块太大，模型看了会乱；块太小，含有的信息太少，搜不到重点，得找平衡。
- 还能按文档结构拆（比如代码按函数、网页按标题），或给片段加“背景备注”（比如标注来自哪本书、哪一章），方便精准搜索。
（2）数据转换：把文字变“能搜索的格式”
- 目的是让电脑看懂文字、能对比相似度，主要有两种方式：
- 嵌入法：把文字变成高维数字，能捕捉语义（比如“开心”和“积极”是相近的），但对“精确关键词”不敏感。
- 关键词法（比如TF-IDF、BM-25）：盯准具体词语，比如“某型号冰箱”，能精准找到含这个词的文档，是嵌入法的补充。
- 现在主流是两种方法一起用，既搜语义相似的，也搜关键词匹配的。
（3）数据库：存“处理好的信息”
- 主要用“向量数据库”（比如Pinecone、Milvus），擅长快速对比数字相似度，搜得快。
- 也能用“图数据库”，记录文档间的关系（比如A文章引用B文章），适合复杂关联查询。
- 还能加“过滤功能”，比如先限定只搜《哈利·波特》第5部的内容，再精准检索，效率更高。
（4）查询转换：优化用户的“原始问题”
- 用户提问常很随意，直接搜效果差，得先“加工”：
- 改写问题：比如把“画《蒙娜丽莎》的艺术家后来怎么样了”，改成“列奥纳多·达·芬奇 《蒙娜丽莎》 艺术家”，搜得更准。
- 多问几个角度：比如“怎么养多肉”，拆成“多肉浇水频率”“光照需求”等，多搜几组结果。
- 先猜答案再搜：比如问“地球自转周期”，先让模型猜“约24小时”，再按这个猜测搜相关文档，适合模糊查询。
（5）检索后处理：整理搜到的“杂乱信息”
- 搜完可能有重复文档、无关内容，得先处理：
- 去重：删掉重复的文档。
- 排序融合：把不同方法搜到的结果整合，优先展示相关性最高的。
- 筛选重点：用小模型从文档里挑关键信息，避免大模型因信息太多而混乱。
4、为什么要用RAG？
- 不用花大价钱微调模型，就能让LLM回答近期话题（比如新政策）或小众领域（比如某款冷门产品）的问题。
- 减少LLM“瞎编”的情况，回答有外部知识库做依据，更可信。
要不要我帮你整理一份RAG系统核心组件简化对照表，把专业术语和通俗解释对应起来，方便快速查阅？
二、原文部分
如果你接触过大语言模型（LLM），大概率至少听过 RAG 这个术语 —— 即检索增强生成（Retrieval Augmented Generation）。RAG 的核心思路非常简单：假设你想向大语言模型提问，它不会只依赖模型自身的预训练知识，而是先从外部知识库中检索相关信息；随后将这些检索到的信息与问题一同提供给大语言模型，使其能够生成更具依据、时效性更强的回答。
那么，为什么要使用检索增强生成（RAG）呢？
当提供准确且时效性强的信息至关重要时，你无法仅依赖大语言模型（LLM）的内置知识。而 RAG 则提供了一种经济实用的解决方案：无需自行微调模型（更不会因此耗尽毕生积蓄），就能借助大语言模型生成关于近期话题或小众领域的内容。即便大语言模型的内置知识足以回答问题，使用 RAG 往往也是个不错的选择 —— 近期研究表明，它有助于减少大语言模型的 “幻觉” 问题。
https://arxiv.org/html/2404.08189v1
最基础的 RAG 系统包含哪些核心组件？
在深入探讨本文的进阶内容前，我们先梳理基础概念。通常来说，RAG 系统由两大核心流程构成 ——预处理流程与推理流程。
- 推理流程的核心是利用现有数据库中的数据，响应用户查询并解答问题；
- 预处理流程则是指以正确方式搭建数据库，为后续的精准检索做好准备。
以下是最基础的 RAG 完整流程示意图：
索引构建（或预处理）步骤
这是离线预处理阶段，核心目标是搭建可用的数据库：
-
确定数据源（Identify Data Source）
根据应用场景选择相关数据源，例如维基百科、书籍、产品手册等。由于这一步依赖具体业务领域，本文暂不展开 —— 你可以根据需求任意选择数据，尽管放手去选！
-
数据分块（Chunking the Data）
将数据集拆分为更小、更易处理的文档或数据块；
-
转换为可搜索格式（Convert to Searchable Format）
将每个数据块转换为数值向量或类似的可搜索表示形式；
-
存入数据库（Insert into Database）
将这些可搜索的数据块存储到自定义数据库中，也可使用外部数据库或搜索引擎。
推理步骤
在查询推理阶段，核心包含以下关键环节：
-
查询处理（Query Processing）
将用户查询转换为适合检索的格式；
-
检索 / 搜索策略（Retrieval/Search Strategy）
通过相似性搜索机制，检索出最相关的文档；
-
检索后答案生成（Post-Retrieval Answer Generation）
以检索到的文档为上下文，借助大语言模型生成最终答案。
很好 —— 到这里我们已经明确了搭建 RAG 系统所需的核心模块。信不信由你，要让这个简易 RAG 升级为功能强大的 “CHAD-rag”，每个组件背后都有大量深入研究支撑。接下来，我们就从 “数据分块” 开始，逐一解析这些核心组件。
1. 数据分块（Chunking）
数据分块是将长文档拆分为更小、更易处理的片段的过程。这听起来简单，但实际上，数据分块的方式直接决定 RAG 流程的成败。预处理阶段创建的所有数据块，最终都会在推理阶段被检索使用：
- 如果数据块尺寸过小（比如每句一个块），由于包含的信息量极少，可能难以通过检索找到目标；
- 如果数据块尺寸过大（比如直接存入整篇维基百科文章），一次性向大语言模型（LLM）输入大量文本，可能会让模型感到困惑，影响回答效果。
数据分块的粒度不同，最终结果也会大相径庭！数据分块的粒度不同，最终结果也会大相径庭！
部分框架会借助 LLM 进行数据分块，例如从文本语料中提取简单事实或命题，并将其作为独立数据块。但这种方式成本较高 —— 数据集规模越大，需要调用 LLM 的次数就越多。
图 2：我们发现，在命题级别对检索语料库进行分段和索引，可作为一种简单且有效的策略，提升密集检索模型在推理阶段的泛化性能（A、B）。我们通过实证比较，分析了密集检索模型在处理以100 词段落、句子或命题级别索引的维基百科时，在检索任务及下游开放域问答（QA）任务中的性能表现（C、D）。
结构化分块（Structural Chunking）
如果你的数据本身存在固有边界（比如 HTML 代码或编程语言代码），有时直接利用这些边界进行分块是最佳选择。（作者自制示意图）如果你的数据本身存在固有边界（比如 HTML 代码或编程语言代码），有时直接利用这些边界进行分块是最佳选择。（作者自制示意图）
我们经常会处理具有已知结构或格式的数据集：
- 例如，若要将代码存入数据库，可直接按 “函数名” 或 “类定义” 拆分每个脚本；
- 对于维基百科文章这类 HTML 页面，可按标题标签（如 H2 标签）拆分，从而分离出每个子章节。
上下文分块（Contextual Chunking）
但我们前文讨论的分块方式存在明显缺陷。假设你的数据集包含数万段从《福尔摩斯探案集》全书中提取的段落，而用户的查询是 “《血字的研究》中第一个案件是什么？”—— 你觉得会发生什么？
问题在于，每个数据块都是孤立的信息片段，我们无法通过数据块本身判断它是否来自《血字的研究》。因此，在后续检索阶段，我们可能会检索到大量与 “案件” 相关的段落，却无法确认它们是否与目标书籍相关。要解决这个问题，就可以使用 “上下文分块” 技术。
什么是上下文分块？
Anthropic 近期的一篇博客将其定义为：在嵌入前，为每个数据块添加专属的解释性上下文前缀。简单来说，在索引构建阶段，我们会为每个数据块补充额外相关信息 —— 比如书籍名称、章节号、甚至书籍内容摘要。这些上下文信息能帮助检索器在搜索时，精准定位到与 “《血字的研究》” 和 “案件” 相关的内容，从而从数据库中找到正确的文档！
上下文分块会在数据块的文本内容之外，额外补充相关信息上下文分块会在数据块的文本内容之外，额外补充相关信息
当然，还有其他方法可以解决 “精准检索” 问题 —— 比如元数据过滤（metadata filtering），我们会在后续 “数据库相关内容” 中详细讨论。
2. 数据转换（Data Conversion）
需要注意的是，预处理阶段采用的文档转换策略，后续进行相似性搜索时也需沿用 —— 这两个组件紧密关联。
目前该领域主流的两种转换方法为：基于嵌入的方法（embedding-based methods）与基于关键词频率的方法（如 TF-IDF、BM-25）。
基于嵌入的方法（Embedding Based Methods）
我们先从基于嵌入的方法说起。这种方法会利用预训练 Transformer 模型，将文本转换为高维向量表示，从而捕捉文本的语义信息。嵌入方法的优势在于：能有效捕捉语义关联、处理同义词，还能理解上下文依赖的语义（如多义词在不同语境中的含义）。但它也存在不足：计算成本较高，且有时会忽略 “精确匹配”—— 而这类匹配用更简单的方法反而容易捕捉。
嵌入方法示意图
语义检索（Semantic Search）何时会失效？
举个例子：假设你有一个包含特定冰箱信息的手册数据库，当你查询中提到 “某款特定小众型号” 或 “序列号” 时，嵌入方法可能只会检索到 “与查询大致相似” 的文档，却无法实现 “精确匹配”。这就需要引入另一种检索方式 —— 基于关键词的检索。
基于关键词的方法（Keyword Based Methods）
基于关键词的方法中，最常用的两种是TF-IDF与BM-25。这类算法的核心是关注 “文档与查询中术语（terms）的统计关联”。
TF-IDF
TF-IDF（词频 - 逆文档频率）的核心逻辑是：根据词语在单篇文档中的频率与其在整个语料库中的频率之比，衡量词语的重要性。数据集中的每篇文档，都会被表示为一个 “词汇表中所有词语的 TF-IDF 分数数组”。这个文档向量中分数较高的索引，对应着 “最能体现该文档内容特征” 的词语 —— 因为这些词语在该文档中出现频率高，而在其他文档中出现频率低。例如，与 “Godrej A241gX（某冰箱型号）” 相关的文档，“Godrej” 和 “A241gX” 这两个短语的 TF-IDF 分数会很高，因此通过 TF-IDF 能更精准地检索到这类文档。
TF-IDF 的核心是 “词语在单篇文档中的出现频率” 与 “在整个语料库中的出现频率” 之比，TF-IDF 的核心是 “词语在单篇文档中的出现频率” 与 “在整个语料库中的出现频率” 之比。
BM-25
BM-25 是 TF-IDF 的优化版本，新增了文档长度归一化与术语饱和度两个关键机制：
- 文档长度归一化：根据 “该文档长度与语料库平均文档长度的差异”，调整 TF-IDF 分数（避免长文档因词语总数多而导致分数失真）；
- 术语饱和度：当某个词语在数据库中出现过于频繁时，其重要性会随之降低（避免 “通用词” 过度影响检索结果）。
两种方法的核心差异与结合趋势
- TF-IDF 与 BM-25 的优势：能精准找到 “包含特定关键词且精确匹配” 的文档；
- 嵌入方法的优势：能找到 “语义相似” 的文档，即便关键词不完全一致。
如今的主流做法是同时使用两种方法进行检索，再融合结果—— 这样既能兼顾 “精确匹配”，又能覆盖 “语义相似”，实现两种方法的优势互补。后续讨论 “reciprocal rank 融合（RRF）与去重” 时，我们会详细介绍如何整合这些不同的检索方法。
3. 数据库（Databases）
接下来，我们来聊聊数据库。RAG 系统中最常用的数据库类型是向量数据库（Vector Databases）。向量数据库通过为文档建立 “向量表示” 索引来存储文档，这种向量表示既可以来自嵌入（embedding），也可以来自 TF-IDF。向量数据库擅长与查询向量进行快速相似性比对，因此非常适合 RAG 场景。你可能需要了解的主流向量数据库包括 Pinecone、Milvus、ChromaDB、MongoDB，它们各有优缺点，定价模式也不同。
向量数据库的替代方案是图数据库（Graph Databases）。图数据库将信息存储为 “文档网络”，每个文档通过 “关系” 与其他文档相连 —— 比如 “某篇文章引用了另一篇文章”“某个人物出现在某本书的某章节” 这类关联，都能通过图结构清晰呈现。
现代向量数据库支持 “语义检索 + 属性过滤” 结合使用。
如今许多现代向量数据库与图数据库，还融合了关系型数据库的特性，其中最典型的就是元数据过滤（metadata filtering） 或属性过滤。比如，若你已知查询与《哈利・波特》第 5 部相关，那么可以先将整个数据库过滤为 “仅包含《哈利・波特》第 5 部相关文档”，无需对全部数据集进行嵌入检索 —— 这样效率会高得多。向量数据库中的 “最优元数据过滤” 是计算机科学研究中一个极具价值的领域，若要深入探讨，单独写一篇文章会更为合适。
4. 查询转换（Query Transformation）
进入推理阶段后，我们首先从 “查询转换” 讲起 —— 这指的是在进行任何相似性搜索前，对用户的原始查询进行的所有预处理步骤。简单理解就是：通过优化用户的问题，来获取更优的检索结果与回答。
通常我们不建议直接用用户的原始查询进行检索。用户输入往往比较杂乱，可能包含随意内容；因此需要一个额外的转换层，先解读用户查询的真实意图，再将其转化为 “适合检索的查询语句”（即检索友好型查询）。
为何 “查询重写” 至关重要？举个简单例子
实现查询转换最常用的技术是查询重写（Query Rewriting）。假设有人问：“画《蒙娜丽莎》的艺术家后来怎么样了？” 若直接用这句话做语义检索或关键词检索，获取的信息大概率都围绕 “《蒙娜丽莎》” 本身，而非 “画这幅画的艺术家”。而查询重写系统会调用大语言模型（LLM）对原查询进行改写，比如将其转化为 “Leonardo da Vinci Mona Lisa artist（列奥纳多・达・芬奇 《蒙娜丽莎》 艺术家）”—— 这样检索效率会高得多。
直接检索 vs 查询重写
其他常见的查询转换技术
1. 上下文感知查询生成（Contextual Query Writing）
即借助额外上下文优化查询，常见场景包括：
- 利用用户之前的对话记录（比如历史提问中提到 “19 世纪印象派”，可将该信息融入当前查询）；
- 若已知应用涵盖 10 本书的文档，可通过 “分类器大语言模型（classifier LLM）” 判断用户查询涉及 10 本书中的哪一本，缩小检索范围；
- 若数据库使用其他语言（如英文文档库），还可先将中文查询翻译为对应语言，再执行检索。
2. 假设性文档嵌入（HYDE）
HYDE 是 “Hypothetical Document Embedding” 的缩写，是一种更复杂的转换技术：
- 先用大语言模型对用户查询生成一个 “假设性答案”（比如查询 “地球自转周期”，模型先假设答案 “约 24 小时”）；
- 以这个 “假设性答案” 为依据进行相似性搜索，检索与该答案相关的文档。这种方式能更精准地定位 “包含目标答案” 的文档，尤其适合模糊查询场景。
假设性文档嵌入（HYDE）示意图
3. 多查询扩展（Multi-Query Expansion）
从单个用户查询生成多个 “衍生查询语句”，通过并行检索获取多组文档。例如用户查询 “如何养护多肉植物”，可衍生出 “多肉植物浇水频率”“多肉植物光照需求”“多肉植物土壤选择” 等多个子查询；后续再通过 “去重（de-duplication）” 或 “排序融合（rank fusion）” 步骤，剔除冗余文档并整合优质结果。
4. 其他进阶技术
-
Astute RAG
近期提出的一种方法，在生成回答前，先将 “外部输入的知识” 与 “大语言模型自身的内置知识” 进行整合，再基于整合后的信息优化查询；
-
多跳检索技术（Multi-Hop Techniques）
以 Baleen 程序为例，其逻辑是：先执行初始检索，分析 top 结果中 “频繁共现的术语”（比如检索 “光合作用” 时，发现 “叶绿素”“光照” 高频出现），再将这些术语补充到原始查询中，重新检索。这种自适应方式能弥合 “用户查询与文档内容之间的词汇差异”，进一步提升检索精准度。
5. 检索后处理（Post Retrieval Processing）
在检索到潜在相关的文档后，我们可以在将信息输入大语言模型（LLM）生成回答前，增加一个检索后处理步骤。
例如，我们可以进行信息选择与强调：通过 LLM 从检索到的文档中筛选出对回答有用的部分，比如高亮关键语句、进行语义过滤（移除无关段落），或通过上下文总结将多份文档融合为一份。这一步的目标是避免大语言模型因信息过载而生成不够聚焦或准确的回答。
你可以先用小型 LLM 标记检索文档中的相关信息，再整合上下文提示，最终调用大语言模型生成回答。
通常我们会通过 “查询扩展” 执行多轮查询，或同时使用 “嵌入 + BM-25” 等多种检索算法分别获取多组文档。为了去重，我们常采用重排序方法（如 Reciprocal Rank Fusion，RRF）。RRF 会融合不同检索方法的排名结果，对在多种方法中持续排名靠前的文档赋予更高权重。最终，排名前 K 的高相关文档会被传递给 LLM。
Reciprocal Rank Fusion 是一种经典的搜索引擎算法，用于融合多种排名算法得到的条目排名。
FLARE（前瞻性主动检索增强生成）
是一种迭代式检索后策略：从用户输入和初始检索结果开始，LLM 会迭代生成 “猜测性语句”；随后检查生成的猜测中是否包含低概率 token（如下划线标注部分）—— 如果有，则调用检索器从数据集中检索有用文档并进行必要修正。
更多AI大模型应用开发学习视频及资料，在智泊AI。
