跳转到内容

什么是 RAG,为什么 AI 需要先搜索再回答

建议学习 25 分钟更新于 2026/6/1

在学习大语言模型时,经常会看到一个词:

RAG

它的全称是 Retrieval-Augmented Generation,中文通常翻译为检索增强生成

如果只用一句话解释:

RAG 是一种让 AI 在回答问题前,先从外部知识库中检索相关资料,再结合这些资料生成答案的方法。

这篇笔记整理一下 RAG 到底是什么,以及为什么 AI 需要“先搜索再回答”。

RAG 与 LLM 配合使用的概念流程

大语言模型很强,但它不是万能的。

它有几个天然限制。

大模型训练完成后,它掌握的知识通常停留在某个时间点。

如果你问它最近发生的事情、最新文档、公司内部资料、产品库存、实时日志,它可能不知道。

这不是模型不聪明,而是它没有这些新数据。

通用大模型通常不知道企业内部文档。

例如:

  • 公司内部制度。
  • 项目接口文档。
  • 私有代码仓库。
  • 运维手册。
  • 客服知识库。
  • 产品业务规则。

这些内容不会天然存在于模型参数里。

如果直接问模型,它只能根据通用知识猜测。

大语言模型的目标是生成看起来合理的文本。

当它缺少足够信息时,仍然可能生成一个很流畅、但并不准确的答案。这种现象常被称为幻觉。

例如:

用户问:我们公司退款规则是什么?
模型答:根据一般电商惯例,用户可以在 7 天内无理由退款。

这个回答看起来合理,但如果公司的真实规则不是这样,就会出问题。

RAG 要解决的正是这个问题:

不要让模型凭空回答,而是先找到依据,再基于依据回答。

RAG 可以拆成两个动作:

Retrieval 检索
Generation 生成

也就是:

先检索相关信息,再生成最终回答。

普通大模型问答大概是:

用户问题 -> 大模型 -> 回答

RAG 问答则多了一步检索:

用户问题
-> 检索系统查找相关资料
-> 把资料和问题一起交给大模型
-> 大模型根据资料生成回答

这一步看起来简单,但非常关键。

因为它让模型回答问题时,不只依赖训练时学到的通用知识,还能结合外部知识库中的最新、私有、可信资料。

一个典型 RAG 系统通常可以分成两个阶段:

  • 知识准备阶段。
  • 问答生成阶段。

第一步是把外部资料整理成模型可以检索的形式。

资料来源可能包括:

  • Markdown 文档。
  • PDF 文件。
  • 网页内容。
  • 数据库记录。
  • API 文档。
  • 工单记录。
  • 日志和告警说明。

这些资料通常会经过几个处理步骤:

  1. 文档清洗。
  2. 文档切分。
  3. 向量化。
  4. 存入向量数据库或搜索引擎。

文档切分是因为一整篇文档通常太长,不能直接塞进模型上下文。系统会把文档切成一个个小片段。

向量化则是把文本转换成向量,也就是一组数字。这样系统就可以根据语义相似度找到和用户问题最相关的内容。

当用户提出问题时,RAG 系统会执行下面的流程:

  1. 接收用户问题。
  2. 将问题转换成向量。
  3. 在知识库中检索相似片段。
  4. 取出最相关的文档内容。
  5. 把用户问题和检索结果一起放入 Prompt。
  6. 交给大语言模型生成答案。

可以简化成:

问题 -> 检索 -> 拼接上下文 -> 大模型生成 -> 答案

一个 Prompt 可能会变成这样:

请根据以下资料回答用户问题。
资料:
1. ...
2. ...
3. ...
用户问题:
如何申请退款?
要求:
只根据资料回答,不要编造。

这就是 RAG 的核心思路。

一个完整的 RAG 应用通常包括几个关键组件。

知识库保存外部资料。

它可以是企业文档、产品手册、代码说明、客服 FAQ,也可以是日志、工单、数据库内容。

知识库质量直接决定 RAG 效果。

如果知识库内容混乱、过期、重复严重,即使模型再强,回答也容易不稳定。

Embedding 模型负责把文本转换成向量。

例如:

"如何重置密码?" -> [0.12, -0.04, 0.77, ...]

向量的作用是表达文本的语义。

两个句子字面上不一样,但意思接近,它们的向量距离可能也会比较近。

例如:

如何修改密码?
忘记密码怎么办?
怎么重置账号密码?

这些问题在语义上接近,检索系统应该能找到相似资料。

向量数据库用于存储和检索向量。

它可以根据用户问题,找到语义上最接近的文档片段。

除了纯向量检索,很多系统也会结合关键词检索。

例如:

语义检索 + 关键词检索 + 重排序

这样可以兼顾语义理解和精确匹配。

Retriever 负责从知识库里取回相关资料。

它决定了“找什么资料给模型看”。

如果检索结果不准,后面的大模型也很难生成好答案。

这就是 RAG 里常说的一句话:

检索质量决定回答上限。

Generator 通常就是大语言模型。

它负责根据用户问题和检索结果生成自然语言答案。

在 RAG 中,大模型不再是凭空回答,而是被要求基于上下文资料回答。

RAG 的价值主要体现在几个方面。

模型参数更新成本很高。

如果每次知识变化都重新训练模型,成本会非常大。

RAG 的做法是:模型不用频繁重训,只需要更新外部知识库。

例如:

产品规则变了 -> 更新知识库 -> RAG 检索新规则 -> 模型按新规则回答

这样更适合业务系统。

RAG 会把相关资料提供给模型。

模型有依据可参考,胡编的概率会降低。

当然,RAG 不能完全消除幻觉。如果检索结果错了、Prompt 设计不好、模型没有严格遵守资料,仍然可能出错。

但相比直接让模型裸答,RAG 通常更可靠。

企业最关心的往往不是模型知道多少通用知识,而是模型能不能理解自己的业务数据。

RAG 可以把内部知识库接入大模型。

例如:

  • 内部制度问答。
  • 项目文档问答。
  • 运维知识库问答。
  • 代码仓库问答。
  • 客服知识库问答。

这也是企业级 AI 应用里 RAG 很常见的原因。

如果 RAG 系统把检索到的文档来源一起返回,用户就可以看到答案依据。

例如:

答案来自:
- 《退款规则.md》第 3 节
- 《售后流程.md》第 2 节

这会比单纯的一段模型回答更可信。

学习 RAG 时,很容易想到另一个词:微调。

微调是把特定数据继续训练进模型里,让模型在某类任务上表现更好。

RAG 则是把外部资料作为上下文提供给模型,让模型临时参考。

可以这样区分:

微调:改变模型本身
RAG:不改模型,给模型补充资料

适合微调的场景:

  • 固定风格输出。
  • 特定任务格式。
  • 分类、抽取等稳定任务。
  • 希望模型习惯某种回答方式。

适合 RAG 的场景:

  • 知识经常更新。
  • 需要引用私有文档。
  • 需要答案可追溯。
  • 不想频繁训练模型。

很多实际系统会同时使用二者:

微调负责能力和风格
RAG 负责知识和事实

RAG 很适合知识密集型应用。

把企业文档、制度、流程、FAQ 接入 RAG 后,员工可以直接提问:

年假怎么申请?
报销流程是什么?
VPN 连接失败怎么办?

系统先检索内部文档,再生成答案。

客服系统可以基于产品文档、售后政策、历史工单进行回答。

相比纯规则 FAQ,RAG 更适合处理自然语言问题。

RAG 可以接入代码仓库和项目文档。

开发者可以问:

这个接口在哪里定义?
这个服务的启动流程是什么?
登录态在哪里校验?

系统检索相关代码和文档,再让模型解释。

在运维场景中,RAG 可以连接日志说明、告警手册、历史故障记录。

当出现异常时,系统可以检索相似案例,辅助分析根因。

安全场景也类似,可以结合威胁情报、规则库、历史事件进行解释和建议。

RAG 很有用,但不是万能的。

如果检索阶段找错资料,模型就会基于错误上下文回答。

这类问题通常不是模型生成能力的问题,而是检索质量的问题。

RAG 很依赖知识库。

如果文档本身过期、重复、矛盾,模型也很难给出稳定答案。

所以做 RAG 之前,往往要先治理知识库。

检索到的内容不能无限塞给模型。

如果资料太多,可能超过上下文长度,也可能让模型抓不住重点。

这就需要做好切分、召回、重排序和摘要。

RAG 比普通问答多了检索步骤。

它通常会增加:

  • 向量化成本。
  • 检索成本。
  • 模型上下文长度成本。
  • 整体响应延迟。

所以生产系统里要考虑缓存、索引优化、召回数量、模型选择等问题。

假设我们要给自己的博客做一个问答助手。

用户问:

我之前写的软考高级架构师考后感里,提到论文题有哪些方向?

如果直接问大模型,它大概率不知道。

因为这是我自己博客里的内容,不一定存在于模型训练数据里。即使模型知道“软考高级架构师”是什么,也不知道我那篇文章里具体记录了哪些论文题。

但如果用 RAG,流程会变成:

  1. 把博客文章切分成片段。
  2. 把片段向量化并存入向量库。
  3. 用户提问时,先检索和“软考”“论文题”“架构师”相关的文章片段。
  4. 系统找到那篇考后感里的相关内容。
  5. 把检索到的片段和用户问题一起交给模型。
  6. 模型根据片段生成回答。

最后答案可能是:

你在那篇软考高级架构师考后感里提到,论文题大概有四个方向:
1. 六边形架构设计
2. 向量数据库
3. 论高并发系统设计
4. 论多模态大模型在移动智能测试框架中的应用

这个例子更能体现 RAG 的意义。

它不是让模型提前记住我的博客,而是在回答前先检索我的博客内容,再基于检索到的资料组织答案。

RAG 的核心价值是让大模型连接外部知识。

可以用一句话记住:

RAG = 先检索,再生成。

大模型负责理解问题和组织答案,检索系统负责找到最新、私有、可信的资料。

如果说普通大模型问答更像“凭记忆回答”,那么 RAG 更像“开卷回答”:

闭卷:用户问题 -> 大模型 -> 答案
开卷:用户问题 -> 搜索资料 -> 大模型 -> 有依据的答案

这也是为什么企业级 AI 应用很重视 RAG。

因为真正落地时,问题往往不是模型会不会聊天,而是:

模型能不能基于我的数据,给出可靠、可追溯、可更新的答案?