什么是 RAG,为什么 AI 需要先搜索再回答
在学习大语言模型时,经常会看到一个词:
RAG它的全称是 Retrieval-Augmented Generation,中文通常翻译为检索增强生成。
如果只用一句话解释:
RAG 是一种让 AI 在回答问题前,先从外部知识库中检索相关资料,再结合这些资料生成答案的方法。
这篇笔记整理一下 RAG 到底是什么,以及为什么 AI 需要“先搜索再回答”。
一、为什么需要 RAG
Section titled “一、为什么需要 RAG”大语言模型很强,但它不是万能的。
它有几个天然限制。
训练知识会过期
Section titled “训练知识会过期”大模型训练完成后,它掌握的知识通常停留在某个时间点。
如果你问它最近发生的事情、最新文档、公司内部资料、产品库存、实时日志,它可能不知道。
这不是模型不聪明,而是它没有这些新数据。
不知道私有知识
Section titled “不知道私有知识”通用大模型通常不知道企业内部文档。
例如:
- 公司内部制度。
- 项目接口文档。
- 私有代码仓库。
- 运维手册。
- 客服知识库。
- 产品业务规则。
这些内容不会天然存在于模型参数里。
如果直接问模型,它只能根据通用知识猜测。
可能产生幻觉
Section titled “可能产生幻觉”大语言模型的目标是生成看起来合理的文本。
当它缺少足够信息时,仍然可能生成一个很流畅、但并不准确的答案。这种现象常被称为幻觉。
例如:
用户问:我们公司退款规则是什么?模型答:根据一般电商惯例,用户可以在 7 天内无理由退款。这个回答看起来合理,但如果公司的真实规则不是这样,就会出问题。
RAG 要解决的正是这个问题:
不要让模型凭空回答,而是先找到依据,再基于依据回答。二、RAG 是什么
Section titled “二、RAG 是什么”RAG 可以拆成两个动作:
Retrieval 检索Generation 生成也就是:
先检索相关信息,再生成最终回答。普通大模型问答大概是:
用户问题 -> 大模型 -> 回答RAG 问答则多了一步检索:
用户问题 -> 检索系统查找相关资料 -> 把资料和问题一起交给大模型 -> 大模型根据资料生成回答这一步看起来简单,但非常关键。
因为它让模型回答问题时,不只依赖训练时学到的通用知识,还能结合外部知识库中的最新、私有、可信资料。
三、RAG 的基本流程
Section titled “三、RAG 的基本流程”一个典型 RAG 系统通常可以分成两个阶段:
- 知识准备阶段。
- 问答生成阶段。
知识准备阶段
Section titled “知识准备阶段”第一步是把外部资料整理成模型可以检索的形式。
资料来源可能包括:
- Markdown 文档。
- PDF 文件。
- 网页内容。
- 数据库记录。
- API 文档。
- 工单记录。
- 日志和告警说明。
这些资料通常会经过几个处理步骤:
- 文档清洗。
- 文档切分。
- 向量化。
- 存入向量数据库或搜索引擎。
文档切分是因为一整篇文档通常太长,不能直接塞进模型上下文。系统会把文档切成一个个小片段。
向量化则是把文本转换成向量,也就是一组数字。这样系统就可以根据语义相似度找到和用户问题最相关的内容。
问答生成阶段
Section titled “问答生成阶段”当用户提出问题时,RAG 系统会执行下面的流程:
- 接收用户问题。
- 将问题转换成向量。
- 在知识库中检索相似片段。
- 取出最相关的文档内容。
- 把用户问题和检索结果一起放入 Prompt。
- 交给大语言模型生成答案。
可以简化成:
问题 -> 检索 -> 拼接上下文 -> 大模型生成 -> 答案一个 Prompt 可能会变成这样:
请根据以下资料回答用户问题。
资料:1. ...2. ...3. ...
用户问题:如何申请退款?
要求:只根据资料回答,不要编造。这就是 RAG 的核心思路。
四、RAG 的核心组件
Section titled “四、RAG 的核心组件”一个完整的 RAG 应用通常包括几个关键组件。
知识库保存外部资料。
它可以是企业文档、产品手册、代码说明、客服 FAQ,也可以是日志、工单、数据库内容。
知识库质量直接决定 RAG 效果。
如果知识库内容混乱、过期、重复严重,即使模型再强,回答也容易不稳定。
Embedding 模型
Section titled “Embedding 模型”Embedding 模型负责把文本转换成向量。
例如:
"如何重置密码?" -> [0.12, -0.04, 0.77, ...]向量的作用是表达文本的语义。
两个句子字面上不一样,但意思接近,它们的向量距离可能也会比较近。
例如:
如何修改密码?忘记密码怎么办?怎么重置账号密码?这些问题在语义上接近,检索系统应该能找到相似资料。
向量数据库或搜索引擎
Section titled “向量数据库或搜索引擎”向量数据库用于存储和检索向量。
它可以根据用户问题,找到语义上最接近的文档片段。
除了纯向量检索,很多系统也会结合关键词检索。
例如:
语义检索 + 关键词检索 + 重排序这样可以兼顾语义理解和精确匹配。
Retriever
Section titled “Retriever”Retriever 负责从知识库里取回相关资料。
它决定了“找什么资料给模型看”。
如果检索结果不准,后面的大模型也很难生成好答案。
这就是 RAG 里常说的一句话:
检索质量决定回答上限。Generator
Section titled “Generator”Generator 通常就是大语言模型。
它负责根据用户问题和检索结果生成自然语言答案。
在 RAG 中,大模型不再是凭空回答,而是被要求基于上下文资料回答。
五、RAG 为什么有用
Section titled “五、RAG 为什么有用”RAG 的价值主要体现在几个方面。
让答案更接近最新信息
Section titled “让答案更接近最新信息”模型参数更新成本很高。
如果每次知识变化都重新训练模型,成本会非常大。
RAG 的做法是:模型不用频繁重训,只需要更新外部知识库。
例如:
产品规则变了 -> 更新知识库 -> RAG 检索新规则 -> 模型按新规则回答这样更适合业务系统。
RAG 会把相关资料提供给模型。
模型有依据可参考,胡编的概率会降低。
当然,RAG 不能完全消除幻觉。如果检索结果错了、Prompt 设计不好、模型没有严格遵守资料,仍然可能出错。
但相比直接让模型裸答,RAG 通常更可靠。
可以接入私有数据
Section titled “可以接入私有数据”企业最关心的往往不是模型知道多少通用知识,而是模型能不能理解自己的业务数据。
RAG 可以把内部知识库接入大模型。
例如:
- 内部制度问答。
- 项目文档问答。
- 运维知识库问答。
- 代码仓库问答。
- 客服知识库问答。
这也是企业级 AI 应用里 RAG 很常见的原因。
更容易追溯来源
Section titled “更容易追溯来源”如果 RAG 系统把检索到的文档来源一起返回,用户就可以看到答案依据。
例如:
答案来自:- 《退款规则.md》第 3 节- 《售后流程.md》第 2 节这会比单纯的一段模型回答更可信。
六、RAG 和微调有什么区别
Section titled “六、RAG 和微调有什么区别”学习 RAG 时,很容易想到另一个词:微调。
微调是把特定数据继续训练进模型里,让模型在某类任务上表现更好。
RAG 则是把外部资料作为上下文提供给模型,让模型临时参考。
可以这样区分:
微调:改变模型本身RAG:不改模型,给模型补充资料适合微调的场景:
- 固定风格输出。
- 特定任务格式。
- 分类、抽取等稳定任务。
- 希望模型习惯某种回答方式。
适合 RAG 的场景:
- 知识经常更新。
- 需要引用私有文档。
- 需要答案可追溯。
- 不想频繁训练模型。
很多实际系统会同时使用二者:
微调负责能力和风格RAG 负责知识和事实七、RAG 的典型应用
Section titled “七、RAG 的典型应用”RAG 很适合知识密集型应用。
企业知识库问答
Section titled “企业知识库问答”把企业文档、制度、流程、FAQ 接入 RAG 后,员工可以直接提问:
年假怎么申请?报销流程是什么?VPN 连接失败怎么办?系统先检索内部文档,再生成答案。
客服系统可以基于产品文档、售后政策、历史工单进行回答。
相比纯规则 FAQ,RAG 更适合处理自然语言问题。
RAG 可以接入代码仓库和项目文档。
开发者可以问:
这个接口在哪里定义?这个服务的启动流程是什么?登录态在哪里校验?系统检索相关代码和文档,再让模型解释。
运维和安全分析
Section titled “运维和安全分析”在运维场景中,RAG 可以连接日志说明、告警手册、历史故障记录。
当出现异常时,系统可以检索相似案例,辅助分析根因。
安全场景也类似,可以结合威胁情报、规则库、历史事件进行解释和建议。
八、RAG 的局限
Section titled “八、RAG 的局限”RAG 很有用,但不是万能的。
检索不准会影响答案
Section titled “检索不准会影响答案”如果检索阶段找错资料,模型就会基于错误上下文回答。
这类问题通常不是模型生成能力的问题,而是检索质量的问题。
文档质量很重要
Section titled “文档质量很重要”RAG 很依赖知识库。
如果文档本身过期、重复、矛盾,模型也很难给出稳定答案。
所以做 RAG 之前,往往要先治理知识库。
上下文长度有限
Section titled “上下文长度有限”检索到的内容不能无限塞给模型。
如果资料太多,可能超过上下文长度,也可能让模型抓不住重点。
这就需要做好切分、召回、重排序和摘要。
成本和延迟会增加
Section titled “成本和延迟会增加”RAG 比普通问答多了检索步骤。
它通常会增加:
- 向量化成本。
- 检索成本。
- 模型上下文长度成本。
- 整体响应延迟。
所以生产系统里要考虑缓存、索引优化、召回数量、模型选择等问题。
九、一个简单例子
Section titled “九、一个简单例子”假设我们要给自己的博客做一个问答助手。
用户问:
我之前写的软考高级架构师考后感里,提到论文题有哪些方向?如果直接问大模型,它大概率不知道。
因为这是我自己博客里的内容,不一定存在于模型训练数据里。即使模型知道“软考高级架构师”是什么,也不知道我那篇文章里具体记录了哪些论文题。
但如果用 RAG,流程会变成:
- 把博客文章切分成片段。
- 把片段向量化并存入向量库。
- 用户提问时,先检索和“软考”“论文题”“架构师”相关的文章片段。
- 系统找到那篇考后感里的相关内容。
- 把检索到的片段和用户问题一起交给模型。
- 模型根据片段生成回答。
最后答案可能是:
你在那篇软考高级架构师考后感里提到,论文题大概有四个方向:
1. 六边形架构设计2. 向量数据库3. 论高并发系统设计4. 论多模态大模型在移动智能测试框架中的应用这个例子更能体现 RAG 的意义。
它不是让模型提前记住我的博客,而是在回答前先检索我的博客内容,再基于检索到的资料组织答案。
RAG 的核心价值是让大模型连接外部知识。
可以用一句话记住:
RAG = 先检索,再生成。大模型负责理解问题和组织答案,检索系统负责找到最新、私有、可信的资料。
如果说普通大模型问答更像“凭记忆回答”,那么 RAG 更像“开卷回答”:
闭卷:用户问题 -> 大模型 -> 答案开卷:用户问题 -> 搜索资料 -> 大模型 -> 有依据的答案这也是为什么企业级 AI 应用很重视 RAG。
因为真正落地时,问题往往不是模型会不会聊天,而是:
模型能不能基于我的数据,给出可靠、可追溯、可更新的答案?