RAG：让 AI 不再瞎编的检索增强生成

意图

RAG(Retrieval Augmented Generation,检索增强生成)是一种让大模型在回答前先去你的知识库检索相关资料、再基于检索到的真实内容作答的方式。它让 AI 的回答有据可依,而不是凭记忆瞎编。

问题

一天,你想用 ChatGPT 帮客户回答咨询。你问它:

我们产品的退款政策是什么?

它一本正经地答了一段—看着很专业,但根本不是你们公司的政策,是它根据「一般退款政策长什么样」编出来的。

你又问:

我们 API 的限流是多少?

它说不知道(它没见过你们的内部文档),或者又编一个数字。

你换了个问题:

上季度的用户增长是多少?

它答的是去年的数据—因为模型训练有截止日期,最新的数字它没学过。

三个问题,三种翻车:编造(幻觉)、不懂私有知识、知识过期。直接拿大模型答你的业务问题,几乎必然踩这三个坑。

解决方案

RAG 的思路很简单:与其让 AI 凭记忆答,不如让它先查资料再答。

具体做法:把你的文档(退款政策、API 文档、财报、手册…)变成一个可按语义搜索的库。用户问问题时,先去这个库里捞最相关的几段,把它们和问题一起塞给 AI,让 AI 基于这几段作答。

这样一来:

• 编造没了—它答的是你给的真实文档
• 私有知识能答了—你的文档它从没见过,但现在查得到
• 时效性解决了—文档随时更新,它答的就是最新的

真实世界类比

开卷考试。

闭卷考试:学生靠死记硬背,记不清的就编(像幻觉)。 开卷考试:学生带一本参考书,答题前先翻到相关页,照着书答。

RAG 就是给 AI 配一本「开卷用的参考书」—而且是能按意思秒速翻到相关页的那种。律师出庭带案卷、医生问诊翻病历,都是同一个道理:重要的回答,不靠记忆,靠可查的依据。

结构 / 原理

一个 RAG 系统拆成四个角色:

1. 文档库(知识源) — 你的原始材料:PDF、Markdown、网页、Notion…

2. 索引器(建库) — 把文档切成小块(chunk),每块用 embedding 模型转成向量,存进向量数据库。这一步离线做一次,能用很久。

3. 检索器(查询时) — 用户问题来了,也转成向量,在向量库里找「语义最接近」的 K 个片段。

4. 生成器(回答) — 把检索到的片段拼进 prompt(「根据以下资料回答:…」),交给大模型生成答案。

关键点:检索器和生成器之间的「接口」就是那几段被捞出来的文本。检索质量好,答案就准;检索没捞到,模型也只能瞎答—垃圾进,垃圾出。

最小示例

用 LangChain 跑一个最小 RAG,核心就两步:

# 1. 建库:文档 -> 切分 -> 向量化 -> 存库
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma

docs = TextLoader("refund_policy.md").load()
chunks = RecursiveCharacterTextSplitter().split_documents(docs)
vectorstore = Chroma.from_documents(chunks, embedding)  # embedding = 你的向量化模型

# 2. 查询:问题 -> 检索 -> 拼进 prompt -> 生成
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})
relevant = retriever.invoke("退款政策是什么?")
# relevant = 最相关的 3 段文档,塞给 LLM 生成答案

注意第二步:检索回来的是原始文档片段,不是答案。答案是大模型基于这些片段生成的。这个分工是 RAG 的本质—检索负责「找依据」,模型负责「组织答案」。

适合场景

该用 RAG:

• 私有知识:公司文档、产品手册、内部 wiki,模型从没见过
• 时效性强:数据频繁更新(财报、政策、价格),靠训练跟不上
• 需要溯源:答案要能指出「这段来自哪份文档」
• 长尾事实:大量具体、细碎的事实,塞不进 prompt

不该用 RAG:

• 公开通识(「什么是 Transformer」)—模型本来就会,不用查
• 需要推理/计算而非事实检索的任务
• 文档量很小(几页)—直接全塞进 prompt(长上下文)更简单,RAG 是多余的

优缺点

优点:

• 不幻觉(基于真实文档答)
• 能答私有知识
• 文档可随时更新,无需重训模型
• 答案可溯源(指出处)
• 比微调便宜得多、快得多

缺点:

• 检索质量决定上限—切分不好、embedding 不好,捞不到就答错
• 有延迟(先检索再生成,比直接答慢)
• 上下文长度限制—捞太多塞不下
• 它是「让 AI 有据可依」,不是「让 AI 更聪明」—复杂推理它还是不会

与相关概念的关系

RAG vs 微调:RAG 给 AI 配「外挂记忆」,微调改 AI 的「内在能力」。知识更新/私有事实用 RAG;改变风格、行为或特定领域能力用微调。两者不互斥,常组合使用。

RAG vs 长上下文:长上下文是把所有文档一次性塞进 prompt;RAG 是按需只检索相关的几段。文档量小(几十页内)用长上下文更简单;文档量大(成千上万篇)必须用 RAG—既塞不下也贵。

RAG vs Agentic RAG:普通 RAG 是「检索一次就答」;Agentic RAG 让 Agent 自主决定:要不要检索、检索几次、要不要换关键词重搜、要不要调工具。它是 RAG + Agent 判断力。

RAG 依赖 Embedding:检索能「按意思」而不是「按字面」找,靠的是 embedding 把文本变成语义向量。这是 RAG 的地基—想理解它为什么能搜到相关内容,先看 Embedding 小课。

练习

1. 找一份你公司的真实文档(退款政策/FAQ/手册),用 LangChain 或 LlamaIndex 跑一个最小 RAG,问它 3 个文档里的具体问题。观察:答对了吗?答错的是不是因为检索没捞到相关片段?
2. 反思一个你「直接拿 ChatGPT 答业务问题翻车」的场景:是幻觉、私有知识、还是时效?用 RAG 能不能解决?

---

-> 想亲手搭一个生产级 RAG?走 RAG 系统实战路径,3 周从向量库到评估体系。