Back to Index
检索增强 (RAG) /

RAG 是什么

从知识截止、幻觉和私有数据三大痛点出发，理解 Retrieval-Augmented Generation 的本质与价值

10 min read Part of RAG · Ch. 1
← 上一层级：学习路径 · Part 02 · RAG 体系化进阶

RAG 是什么

大模型很强，但它的强，首先是“会生成高质量文本”，不是“天然知道你现在需要的所有事实”。当你问它“贵司 2025 年 Q3 的销售数据是多少”时，它答不上来，往往不是因为模型笨，而是因为这些数据既不在它的训练参数里，也不在当前上下文里。RAG 要解决的，正是这个“模型能力很强，但知识边界很硬”的问题。Lewis 等人在 2020 年提出的原始 RAG 论文，就把它概括为把参数化记忆和外部非参数化记忆结合起来做生成。(arXiv)

这篇文章会讲什么

flowchart LR
  A[用户问题] --> B[检索相关资料]
  B --> C[组装上下文]
  C --> D[LLM 生成回答]
  D --> E[带证据的答案]
  K[外部知识库] --> B

很多人第一次接触 RAG，会把它理解成“给大模型接一个知识库”。这个理解不算错，但太轻了。RAG 真正重要的地方，不是多了一个数据库，而是它改变了 LLM 回答问题的方式：从“闭卷作答”变成“先查资料，再回答”。这意味着模型不再只能依赖训练时学到的知识，而可以在回答前动态读取外部信息。这个模式今天已经成为企业知识问答、内部 Copilot、文档助手、客服问答等场景的标准做法。LangChain 的官方 RAG 教程，本质上也是围绕这条链路来组织：用户问题进入系统后，先检索，再把检索结果与问题一起送给模型生成回答。(arXiv)

大模型的三大痛点

在谈 RAG 之前，先把“为什么需要它”讲清楚。对企业落地来说，LLM 至少有三类非常现实的痛点：

痛点表现典型场景
知识截止模型训练数据有时间边界，不知道之后发生的事问最新政策、最新产品、最新市场数据
幻觉模型会生成流畅但不真实的细节问具体参数、具体制度条款、具体数字
私有数据不可及模型默认看不到企业内部资料和数据库问公司制度、内部 SOP、客户数据

这三类问题分别对应了三种常见失败方式：不知道、乱猜、看不到。RAG 的价值就在于，它不是试图“让模型记住一切”，而是让模型在需要时能够访问外部知识。(arXiv)

RAG 的定义

RAG 全称 Retrieval-Augmented Generation，中文通常叫“检索增强生成”。它的核心思想非常朴素：

  1. 用户先提出问题
  2. 系统先去外部知识库里找相关材料
  3. 把找到的材料和用户问题一起送给 LLM
  4. 让 LLM 基于这些材料生成回答

这意味着，RAG 不是替代 LLM，而是在 LLM 前面加了一层“查资料”的过程。原始论文中的做法是把外部知识库作为非参数化记忆接入生成模型；今天工程实践里更常见的是把检索和生成解耦：检索用 embedding + 向量数据库，生成用通用 LLM。(arXiv)

用户问题 → 检索相关文档 → 将文档 + 问题送入 LLM → 生成答案

这里的“知识库”不一定非得是向量数据库。它可以是：

  • 向量数据库
  • 传统关键词搜索系统
  • 混合检索系统
  • 企业文档平台
  • 数据库查询层
  • 任何能返回相关内容的外部知识源

所以从系统设计上看，RAG 不是某个产品，而是一种系统设计模式。(arXiv)

三个核心组件

组件英文职责
检索Retrieval根据用户问题，从知识库中找出最相关的文档片段
增强Augmentation把检索到的内容组织成上下文，注入到 prompt 中
生成GenerationLLM 基于增强后的 prompt 生成最终答案

这三个词看起来简单，但它们分别代表三类完全不同的工程问题。Retrieval 解决“找什么”；Augmentation 解决“怎么把找到的内容塞给模型”；Generation 解决“模型如何基于这些内容组织出一个可读答案”。RAG 的效果不好，可能是检索错了，也可能是上下文组织得差，还可能是模型没有正确利用检索结果。所以别把 RAG 想成单一步骤，它天生就是一条流水线。(arXiv)

开卷 vs 闭卷：一个最有用的类比

理解 RAG，最好的类比仍然是考试。

  • 闭卷考试：模型只能依赖自己参数里“记住”的知识作答
  • 开卷考试：模型可以先翻资料，再根据资料回答

Fine-tuning 更像是把某些知识、风格或任务模式“背进模型里”；RAG 更像是把资料摆在桌上，让模型在回答前先查一遍。这个类比非常重要，因为它直接解释了 RAG 的两个关键优势：第一，知识库可以随时更新，不必重新训练模型；第二，回答可以带来源，便于审计和溯源。Lewis 等人的原始论文也把 RAG 的优势描述为：外部记忆更容易更新，并且能为生成提供可追踪的知识来源。(arXiv)

当然，开卷考试不意味着永远答对。 如果系统查到的资料本身就是错的，或者查到了对的资料但模型解读错了，答案依然会错。所以 RAG 从来不是“消灭幻觉”的银弹，它只是把回答从“纯靠模型猜”推进到“尽量基于证据回答”。这一步已经非常有价值，但仍然需要检索、重排、上下文组织和输出约束共同配合。(arXiv)

为什么 2026 年 RAG 仍然重要

这几年一个常见问题是：既然长上下文越来越强，RAG 还有没有必要？

答案是：有，而且非常有。

原因不难理解。OpenAI 的 GPT-4.1 系列官方支持最高 100 万 token 上下文，Google 的 Gemini 2.5 Pro 官方也支持约 100 万 token 输入；这说明长上下文能力确实在快速进步。(OpenAI)

但长上下文解决的是：

模型这次最多能“看见多少内容”

RAG 解决的是：

这次到底应该把哪几段内容拿给模型看

这是两个完全不同的问题。

把整个知识库直接塞进上下文，往往会遇到三个现实问题：

  1. 成本高，token 消耗大
  2. 噪声多，无关内容会干扰模型
  3. 长上下文里，中间信息未必能被同样稳定利用

所以即使在长上下文时代，RAG 依然重要，因为它让系统只把“最相关的那几段”送进去，而不是让模型在海量上下文里自己翻。换个工程角度看：

长上下文解决“能塞多少”，RAG 解决“该塞什么”。(OpenAI)

RAG vs Fine-tuning vs 长上下文

方案更适合什么问题优点缺点
RAG知识频繁更新、私有数据、需要可溯源回答可更新、可解释、接入私有知识方便依赖检索质量，系统链路更复杂
Fine-tuning风格、术语、固定任务模式响应快、行为更稳定更新知识成本高，不适合高频变化事实
长上下文单次任务需要读大量原文实现直接、适合单文档分析成本高、噪声大，不等于好检索

这三者不是非此即彼。现实里经常是组合使用：

  • 用 Fine-tuning 固化风格和任务格式
  • 用 RAG 注入最新知识和私有资料
  • 用长上下文处理某次会话里必须整段阅读的大文档

所以更好的问题不是“RAG 和微调谁更好”，而是：

哪一部分该靠模型参数，哪一部分该靠外部知识，哪一部分该靠当前上下文。 (arXiv)

简史：从 Lewis 2020 到现代模块化 RAG

RAG 这个名字并不是后来工程圈随便起的，而是来自 2020 年 Lewis 等人的论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。原始论文里的 RAG 更偏研究范式：检索器和生成器一起优化，目标是让模型在知识密集型任务上结合参数记忆和外部记忆。(arXiv)

但今天工程上的 RAG，已经演化成更模块化的形态：

  • Embedding 模型负责把 query 和文档变成向量
  • 向量数据库负责高效检索
  • reranker 负责精排
  • LLM 负责把检索内容组织成最终回答

这种形态虽然比原始论文里的“端到端 RAG”更松耦合，但工程上更灵活，也更容易替换组件。你可以换 embedding、换 vector DB、换模型，而不需要重新训练整套系统。这也是为什么 RAG 会在企业实践里迅速普及：它非常工程化。(arXiv)

一个简单例子：为什么企业场景会偏爱 RAG

假设你有一个企业知识库，里面包含：

  • 员工手册
  • 报销制度
  • API 文档
  • 客服 SOP
  • 内部产品说明

用户问：

年假有多少天？

没有 RAG

模型可能会：

  • 根据常识猜一个范围，比如“通常是 5–15 天”
  • 或者说不知道
  • 或者说出一个听起来合理但并非你公司政策的数字

有 RAG

系统先检索到员工手册相关条款，例如：

“员工入职满一年后，享有 10 天年假。”

然后模型再基于这段内容回答：

根据《员工手册》，入职满一年后可享有 10 天年假。

这两个答案的差别，不只是“后者更准”，而是：

  • 后者有依据
  • 后者可审计
  • 后者可以展示来源
  • 后者随着知识库更新而自动更新

这正是企业场景最看重的价值。(arXiv)

实践中的常见误区

误区更准确的说法
RAG 能完全消除幻觉不能，它只能显著降低“纯靠猜”的概率
检索越多越好不是，过多无关内容会稀释重点并增加噪声
RAG 和 Fine-tuning 二选一不是，很多系统会把两者组合使用
长上下文能替代 RAG不能完全替代，长上下文更像“容量”，RAG 更像“选择机制”

最值得强调的一点是：

RAG 是一套工程系统，不是一个理论银弹。

它的效果同时受这些因素影响：

  • 文档清洗质量
  • chunk 切分策略
  • embedding 模型
  • 检索方式
  • rerank 是否存在
  • prompt 组织
  • 回答约束
  • 引用与后处理机制

所以，一个“RAG 效果不好”的系统，不一定是 RAG 这个思路有问题，更可能是其中某一个环节还没做好。(arXiv)

何时考虑 RAG

场景信号建议
问题依赖企业内部文档、制度、产品说明强烈建议使用 RAG
知识更新频率高RAG 通常优于把知识硬塞进模型
需要给出依据或引用来源RAG 很合适
只是通用常识问答可以先不接 RAG
主要是单份长文档深度分析可优先考虑长上下文，不一定先做 RAG

一句话判断法是：

如果答案依赖“模型训练后才出现的知识”或“模型从未见过的私有知识”，那你就应该认真考虑 RAG。 (arXiv)

RAG 的工程挑战

把 RAG 接上，并不等于系统就能稳定工作。落地时最常见的挑战包括：

挑战常见原因常见方向
检索不准chunk 切分差、embedding 不匹配、query 表达弱优化 chunk、embedding、query rewrite
文档更新困难缺乏增量更新和版本管理做 ingest 流程、去重、增量索引
多语言效果不稳embedding 模型语言覆盖不足选多语言模型、按语言分索引
长文档难处理切太碎或切太粗章节切分、parent-child、分层检索
结果看起来有依据但仍不准检索到了不完全相关内容，或模型误解了材料rerank、引用约束、答案校验

所以从工程视角看，RAG 的难点不只是“会不会检索”，而是：

如何把检索、组织、生成这三步做成一条高召回、低噪声、可解释的链路。

这也是为什么 RAG 值得单独开一个系列。(arXiv)

小结

RAG 解决的是大模型的“知识边界”问题。它不是让模型变成另一个模型，而是让模型在回答前有机会访问外部知识。这个能力对于三类场景尤其关键：

  • 知识会变
  • 知识是私有的
  • 回答必须有依据

即使在长上下文和更强模型不断出现的今天，RAG 仍然是企业落地 LLM 的主流方案之一，因为它同时兼顾了更新性、成本、可控性和可解释性。Lewis 等人的原始论文给出了这个方向的研究起点，而今天的工程实践则把它发展成了一条成熟的系统路线。(arXiv)

核心概念速查

概念一句话
RAG在生成答案前先检索外部知识，再基于知识作答
Retrieval从知识库中找出与问题最相关的文档片段
Augmentation把检索结果组织成模型当前可见的上下文
Generation模型基于问题和参考资料生成最终回答
Parametric Memory模型参数里“记住”的知识
Non-parametric Memory外部知识库、索引或检索系统提供的知识
开卷 vs 闭卷RAG 像开卷查资料，Fine-tuning 更像把知识背进参数
长上下文 vs RAG长上下文解决容量，RAG 解决选择什么内容进入上下文