LLM 系列（八）：RAG 篇

引言

在过去几年里，大型语言模型（LLM）以其惊人的语言理解和生成能力，彻底改变了我们与技术互动的方式。从写代码、作诗到进行多轮对话，LLM 仿佛无所不能，给我们造成了一种它们 无所不知 的印象。然而，当我们尝试将这些强大的模型真正应用到严肃的企业场景时，其固有的 阿喀琉斯之踵 便暴露无遗。

“阿喀琉斯之踵”（Achilles' heel）是一个源自古希腊神话的比喻，指的是一个人或事物表面看似强大无敌，但却存在致命弱点，这个弱点一旦被击中，就会导致失败或灭亡。

首先是 知识截止（Knowledge Cutoff） 问题。LLM 的知识来源于其训练数据，而训练是一个极其昂贵且耗时的过程。因此，任何一个模型的知识都被冻结在了某个特定的时间点。它不知道最近发生的新闻，不了解最新的市场动态，更无法访问实时的信息。

其次是 模型幻觉（Hallucination）。LLM 的 本质是基于概率生成文本，它会尽力产出听起来最连贯、最 plausible 的内容，但这并不等同于事实。当模型被问及它知识范围之外或模糊不清的问题时，它可能会一本正经地胡说八道，编造出看似合理但完全错误的答案。这种幻觉从无意义的输出到与事实的矛盾，形式多样，极大地侵蚀了用户对模型的信任，是企业级应用落地的致命障碍。

最后，也是最关键的一点，是 私域知识的缺失（Lack of Domain-Specific & Private Data）。任何一家企业都有其独特的产品文档、内部知识库、客户数据和业务流程。这些私有的、领域特定的知识，通用的 LLM 从未学习过，自然也无法回答与之相关的问题。让模型重新训练或进行大规模微调来学习这些知识，高昂的成本往往会让大多数公司望而却步。

为了解决这些根本性问题，一种优雅而高效的架构应运而生——检索增强生成（Retrieval-Augmented Generation, RAG）。你可以把它想象成给 LLM 配备了一个可随时查阅的“外脑”或“随身小百科”。RAG 架构将 LLM 强大的推理能力与外部的、私有的知识库连接起来，让模型在回答问题前，先去“查找资料”，然后依据可靠的资料来组织答案。

这种模式代表了一种应用 AI 的范式转变：我们不再强求模型本身成为一个无所不知的“知识库”，而是将其定位为一个强大的“推理引擎”。模型的任务从“记忆事实”转变为“理解和处理实时提供的事实”。这种解耦使得 AI 应用更加可靠、可扩展且易于维护，是推动 LLM 从“玩具”走向“工具”的关键一步。

RAG 的核心原理

要理解 RAG 的工作原理，最贴切的比喻莫过于一场 开卷考试。

• • 一个 标准的 LLM，就像一个参加 “闭卷考试” 的学生。他只能依赖自己脑中已经背诵的知识来回答问题。如果遇到没复习到的知识点，就只能凭感觉猜测，甚至编造答案。
• • 一个 搭载了 RAG 的 LLM，则像一个参加 “开卷考试” 的学生。他不需要记住所有细节。当遇到问题时，他会先翻阅桌上的教科书和参考资料（外部知识库），找到最相关的章节和段落，然后基于这些准确的信息，整理出逻辑清晰、内容详实的答案。

这个 “开卷考试” 的过程，在技术上被分解为两个核心阶段：检索（Retrieval）和 增强生成（Augmented Generation） 。

• • 检索（Retrieval）：当系统收到用户的提问后，它不会立刻把问题丢给 LLM。相反，它首先将用户的问题作为一个查询指令，在外部知识库（如公司的产品文档、数据库、知识图谱等）中进行搜索，找出与问题最相关的信息片段。
• • 增强生成（Augmented Generation）：系统将上一步检索到的相关信息，连同用户的原始问题，一起打包成一个内容更丰富、上下文更明确的“增强提示词”（Augmented Prompt）。这个增强后的提示词被发送给 LLM，并明确指示 LLM：“请根据我提供的这些背景资料来回答这个问题”。LLM 此时的角色不再是凭空创作，而是在限定的、可靠的资料范围内进行归纳、总结和生成。

RAG 的巧妙之处在于，它不仅提升了答案的准确性和时效性，还天然地解决了 LLM 的“黑箱”问题，增强了系统的透明度和可信度。因为 RAG 的回答是基于具体的、被检索出的文本，系统可以轻易地将这些“参考文献”展示给用户，比如通过脚注或链接的形式。用户可以追根溯源，自行验证信息的准确性。这种“有据可查”的能力，是获得用户信任、实现业务落地的基本前提

拆解 RAG 系统

一个简单的 RAG 概念看似清晰，但要构建一个真正稳定、高效、精准的生产级 RAG 系统，则如同组装一台精密的机器，需要对每个“零件”进行精心设计和调优。一个高质量的 RAG 系统并非单一模型，而是一个复杂的多阶段处理流水线，每个环节都充满了工程上的权衡与挑战。接下来，我们将深入其内部，一探究竟。

数据准备与分块 (Data Preparation & Chunking)：知识的“切、磋、琢、磨”

知识库是 RAG 的基石，但我们不能直接将一篇长达数万字的 PDF 文档整个扔给模型。原因有三：首先，Embedding 模型和 LLM 都有上下文窗口长度的限制；其次，将整篇文档作为检索单元，会大大稀释信息的密度，导致检索不够精准；最后，从计算效率和成本考虑，处理更小的文本单元也更为经济。

因此，在将知识“入库”之前，我们必须先对其进行分块（Chunking）。目标是把长文档切分成一个个语义完整、大小适中的信息片段（Chunk） 。选择合适的分块策略至关重要。

• • 固定长度分块（Fixed-Size Chunking）：这是最简单粗暴的方法，按固定字符数（例如 500 个字符）切分文本。优点是实现简单、速度快，但缺点是极易在句子或段落中间“一刀切断”，破坏了原文的语义完整性，导致上下文丢失。
• • 递归字符分块（Recursive Character Splitting）：这是一种更智能的策略。它会尝试按照一系列预设的分隔符（如 \n\n 段落、\n 换行、. 句号等）进行分层切分，优先保证段落和句子的完整性。这是目前业界最常用且效果不错的默认选项。
• • 语义分块（Semantic Chunking）：这是最先进也最复杂的策略。它不再依赖固定的规则或分隔符，而是利用 Embedding 模型来理解文本的语义。它会将语义上相近、讨论同一主题的连续句子聚合在一起，形成一个 Chunk。这种方式能最大程度地保留上下文的连贯性，但计算成本也最高。

此外，块重叠（Chunk Overlap）是一个重要的辅助参数。通过让相邻的两个 Chunk 之间有部分内容重叠（例如重叠 50 个字符），可以有效防止在切分边界丢失关键信息，保证上下文的连续性。

表 1: 主流分块 (Chunking) 策略对比

向量化 (Vectorization)：将知识翻译成机器的语言

分块之后，我们需要将这些文本 Chunk 转换成机器能够理解和比较的格式。这个过程就是向量化（Vectorization），通过一个称为 Embedding 模型的神经网络来完成。

Embedding 模型可以将任意一段文本映射到一个高维的数学向量（Vector）中。这个向量就像是文本在“语义空间”中的坐标，其神奇之处在于：语义上相似的文本，其对应的向量在空间中的距离也更近。这就为我们后续的“按义搜索”而非“按词搜索”奠定了基础。

选择一个合适的 Embedding 模型对 RAG 系统的最终效果影响巨大。主要考虑以下几点：

• • 性能/准确度：模型的检索性能是首要指标。Hugging Face 的 MTEB (Massive Text Embedding Benchmark) 排行榜是业界公认的权威参考，它全面评估了各大模型在不同任务上的表现 。
• • 延迟与成本：商业 API 模型（如 OpenAI 的 text-embedding-ada-002、Cohere 的 embed-v3）使用方便，但每次调用都涉及网络延迟和费用。而开源模型（如 E5、GTE、BGE 系列）可以私有化部署，在本地 GPU 上运行时速度更快、成本更低，但需要投入一定的运维精力。
• • 向量维度：Embedding 向量的维度（如 768、1024、1536）也需要权衡。更高的维度通常能编码更丰富的信息，但也会带来更大的存储开销和计算负担。

向量检索 (Vector Retrieval)：在知识的“瀚海”中“捞针”

当所有知识 Chunk 都被转换成向量后，我们需要一个地方来存储并高效地检索它们。这就是 向量数据库（Vector Database）的用武之地。它就像我们 “开卷考试” 中那座分门别类、索引清晰的图书馆。

vector-space-model

当用户提问时，RAG 系统会将问题同样用 Embedding 模型转换成一个查询向量（Query Vector），然后在向量数据库中执行相似性搜索，快速找出与查询向量“距离”最近的 Top-K 个文档向量，从而找到最相关的知识 Chunk 。市面上有多种向量数据库可供选择，选型时需考虑：

• • 可扩展性（Scalability）：系统是否需要支持数十亿甚至更多的向量？对于大规模企业应用，需要选择像 Milvus、Pinecone 这样专为海量数据设计的数据库。
• • 易用性与开发体验：对于快速原型开发或中小型项目，Chroma 这样 API 简洁、易于上手的数据库可能更合适。
• • 部署模式：是选择 Pinecone 这样的全托管云服务（SaaS），省去运维烦恼，还是选择 Milvus、Weaviate、Chroma 这样的开源方案，进行私有化部署以获得更大的灵活性和数据控制权？。
• • 高级功能：是否支持元数据过滤（例如，只在“2023 年的财报”中搜索）或混合搜索（Hybrid Search，即结合传统的关键词搜索和向量语义搜索）？这些功能可以显著提升复杂查询的准确率。

表 2: 主流向量数据库选型参考

召回与重排 (Recall & Reranking)：从“相关”到“最相关”的精炼

通过向量检索，我们从海量知识库中快速“召回”（Recall）了，比如说，50 个可能相关的文档片段。但这一步的检索算法（通常是基于 Bi-Encoder 的近似最近邻搜索）为了速度，在精度上有所妥协。这 50 个片段的相关性良莠不齐，甚至可能出现“大海捞针，针在中间”（Lost in the Middle）的问题——即最重要的信息被淹没在一堆次要信息中，而 LLM 在处理长上下文时，往往会忽略中间部分的内容 。

为了解决这个问题，生产级的 RAG 系统通常会引入一个关键的优化步骤：重排序（Reranking） 。重排序是在召回之后、生成之前的一个精炼阶段。它使用一个更强大但计算更密集的重排序模型（Reranker），通常是跨编码器（Cross-Encoder），来对初步召回的 50 个 Chunk 进行二次打分。与 Bi-Encoder 分别计算问题和文档的向量不同，Cross-Encoder 会将问题和每个候选 Chunk 配对后一起输入模型，从而能更精细地捕捉二者之间的相关性。这个过程就像一个初选和复试：

• • 初选（召回）：用速度快的 Bi-Encoder 从 100 万份简历中快速筛选出 50 份。
• • 复试（重排）：用更资深的 Cross-Encoder 逐一面试这 50 位候选人，最终选出最优秀的 3-5 位。

通过重排序，我们能确保喂给 LLM 的是“优中选优”的、最核心的知识，这不仅能显著提升答案的质量，还能在不牺牲召回广度的前提下，有效缩减最终输入 LLM 的上下文长度，节省成本。

完整流程示例：一次提问的“奇幻漂流”

现在，让我们把所有零件组装起来，跟随一个具体的提问，走完一次完整的 RAG 旅程。

场景：一位产品经理向公司内部的 AI 助手提问：“我们最新发布的‘星尘’AI 芯片相比上一代‘光子’芯片，在能效和推理速度上具体有哪些提升？请给出数据。”

1. 提问（Query）：用户在聊天框输入问题。

2. 向量化（Embedding）：系统调用 Embedding 模型，将这个问题转换成一个 768 维的查询向量。

3. 召回（Recall）：系统拿着这个查询向量，到存储着公司内部文档（产品白皮书、性能测试报告、发布会 PPT 等）的 Milvus 向量数据库中进行相似性搜索，召回 Top 50 的相关文本 Chunk。

4. 重排（Reranking）：Reranker 模型（一个 Cross-Encoder）对这 50 个 Chunk 进行精细打分，发现其中 3 个 Chunk 的相关性得分最高：一块来自《“星尘”芯片性能基准测试报告.pdf》的表格数据，一块来自《Q3 产品发布会.pptx》中对比两代芯片的关键幻灯片文字，还有一块来自《“星尘”芯片技术规格书.docx》的能效章节。

5. 提示词构建（Prompt Augmentation）：系统构造一个增强提示词，结构如下：

“请基于以下上下文信息，回答用户的问题。请确保答案只依赖于提供的上下文，并引用数据来源。

上下文 1 (源自：性能基准测试报告.pdf):

‘...在 ResNet-50 模型上，星尘芯片的推理速度达到 2500 FPS，比光子芯片的 1800 FPS 提升了 38%。’

上下文 2 (源自：技术规格书.docx):

‘...星尘芯片采用 5nm 工艺，典型功耗为 15W，而上一代光子芯片为 25W，能效比提升了 67%。’

上下文 3 (源自：Q3 产品发布会.pptx):

‘...总结来说，星尘芯片实现了速度与效率的双重突破...’

用户问题:

我们最新发布的‘星尘’AI 芯片相比上一代‘光子’芯片，在能效和推理速度上具体有哪些提升？请给出数据。”

6. 生成（Generation）：LLM（如 Deepseek R1/Qwen）接收到这个结构清晰、信息充分的提示词，轻松地从中提取关键数据并组织成答案。

7. 回答（Answer）：AI 助手最终输出一个精准、有据可查的回答：

“根据公司的内部文档，‘星尘’AI 芯片相比‘光子’芯片在能效和推理速度上有显著提升： 1、推理速度：在 ResNet-50 模型上，‘星尘’芯片的推理速度为 2500 FPS，相比‘光子’芯片的 1800 FPS 提升了 38%（来源：性能基准测试报告.pdf）。 2、能效：‘星尘’芯片的典型功耗为 15W，相比‘光子’芯片的 25W，能效比提升了约 67%（来源：技术规格书.docx）。”

至此，一次高质量的 RAG 问答流程圆满完成。

RAG 的“进化”与“变体”：不止于简单的问答

基础的 RAG 框架已经非常强大，但它仅仅是一个起点。整个领域正在飞速发展，涌现出许多更智能、更强大的 RAG 变体。了解这些前沿方向，有助于我们思考 AI 应用的未来形态。这种演进轨迹，也正反映了 AI 系统从固定的、基于规则的流水线，向着动态的、具备推理能力的、能够使用多种工具的智能体方向发展的宏大趋势。

image-20250720000052967

• • 自纠正 RAG (Self-Correcting RAG)：这类 RAG 引入了“反思”和“修正”机制。例如，CRAG (Corrective-RAG) 在检索后增加了一个评估器（Evaluator）来判断检索到的文档质量。如果文档不相关，它会自动触发 Web 搜索来补充信息，或者改写查询词重新检索。而 Self-RAG 更进一步，它训练 LLM 自身学会生成特殊的“反思令牌”，让模型自己判断是否需要检索、检索回来的内容是否有用、自己生成的答案是否基于了证据，从而实现全流程的自我优化和批判。
• • 图 RAG (Graph-RAG)：当知识本身具有很强的关联性时（比如组织架构、产品依赖关系、知识图谱），传统的文本块检索就显得力不从心。Graph-RAG 将知识库构建成一个知识图谱，检索时不再是返回孤立的文本块，而是返回相互连接的实体及其关系。这为 LLM 提供了更深层次的结构化上下文，使其能够进行更复杂的推理。
• • 智能体 RAG (Agentic RAG)：这是 RAG 演进中最具颠覆性的一步。它不再是一个固定的“检索-生成”流水线，而是由一个 LLM 驱动的 智能体（Agent） 来主导整个过程。这个智能体具备规划和使用工具的能力。当收到一个复杂问题时，它会先进行“思考”（Thought），然后规划出解决问题的步骤（Plan），并决定调用哪个“工具”（Tool）来执行。这些工具可能包括：Agentic RAG 将 RAG 从一个信息检索框架，提升为了一个动态的、多才多艺的问题解决框架。RAG 本身，也从整个系统，降级成了智能体可以选用的一种工具。
  • • 进行向量检索（标准的 RAG 步骤）
  • • 执行 SQL 查询从结构化数据库中获取数据
  • • 调用外部 API 获取实时信息（如天气、股价）
  • • 使用计算器进行数学运算
• • 缓存增强生成 (Cache-Augmented Generation, CAG)：随着 LLM 的上下文窗口越来越大（动辄百万 Token），一种 RAG 的替代方案 CAG 开始受到关注。对于那些相对静态、大小可控的知识库，CAG 会在系统启动时就将所有知识预加载到模型的 KV 缓存中。这样，在响应用户查询时，就完全省去了实时检索的延迟，响应速度极快。但它的缺点是灵活性较差，不适用于频繁更新的动态知识库。
• 结语

回顾全文，我们可以清晰地看到，RAG 并非一个高深莫测的算法，而是一种极其务实且强大的工程思想。它直面了通用大模型在落地应用时最核心的三个痛点：知识局限、事实幻觉和私域无知。

通过将 LLM 的通用推理能力与企业外部或内部的特定知识源相结合，RAG 成功地为模型装上了“事实的锚”，使其回答既能保持语言的流畅自然，又能做到内容的准确可靠。

对于任何希望利用大模型技术创造价值的企业而言，RAG 都是那把不可或缺的“金钥匙”。它是一座至关重要的桥梁，连接了公域的通用语言智能与私域的、构成企业核心竞争力的专有数据。掌握 RAG，不仅仅是学会一项技术，更是理解并采纳一种全新的、可持续的 AI 应用构建范式。对于每一位致力于用 AI 打造可靠、可信、可扩展产品的产品经理、开发者和架构师来说，这条路，才刚刚开始。

系列文章

大模型发展历程：技术演进与趋势洞察

LLM 系列（二）：基础概念篇

LLM系列（三)：核心技术之架构模式

LLM 系列(四)：神奇的魔法数 27

LLM 系列（五）：模型训练篇

LLM 系列（六）：模型推理篇

LLM 系列（七）：数学概念篇