RAG是什么？为什么检索增强生成是大模型落地的首选方案

RAG是什么，为什么它是大模型落地的首选方案

工具篇讲完了，从这一篇开始，我们进入RAG篇。

RAG是Retrieval-Augmented Generation的缩写，中文叫检索增强生成。名字听起来有点学术，做的事情其实很朴素。就是让大模型在回答问题之前，先去知识库搜相关资料，再根据搜到的内容生成答案。

为什么要费这个劲。因为大模型有两个老大难问题，知识截止和幻觉。RAG就是冲着解决这两个问题来的。

这一篇我们从零讲起。RAG到底是什么，它解决了什么问题，基本原理是什么，为什么说它是大模型落地最成熟的方案。

大模型的两个痛点

先说背景。大模型很厉害，但它不是万能的。用在实际业务里，有两个问题绕不开。

第一个问题，知识有截止日期。

大模型的知识来自训练数据，训练数据是有截止日期的。比如GPT-4的训练数据截止到2024年中，那之后发生的事它就不知道了。你问它2025年的新产品、新政策、新数据，它要么说不知道，要么瞎编。

企业内部的知识它更不知道。公司的产品文档、内部规章、历史案例，这些东西不可能出现在公开训练数据里。

第二个问题，幻觉。

大模型有时候会一本正经地胡说八道。它说的话听起来很有道理，事实却是错的。引用不存在的论文，编造不存在的API参数，给出错误的数字。普通用户很难分辨真假。

做聊天应用，幻觉是个体验问题。做企业应用，幻觉就是个事故问题。客服给用户说错了产品参数，法律助手给了错误的建议，知识库问答引用了不存在的规定，这些都是要出大事的。

怎么解决这两个问题。有两条路。

一条路是微调。把领域知识喂给模型，继续训练，让模型学会这些知识。这条路效果有，但成本高、周期长、更新慢。知识变了还得重新微调，跟不上业务变化的速度。

另一条路就是RAG。不教模型新知识，而是把知识存在外部的知识库里。回答问题的时候，先去库里搜相关内容，再基于搜到的内容回答。模型不用改，知识随时可以更新。

两条路各有适用场景。大部分企业级应用，RAG是更务实的选择。

RAG的基本原理

RAG的流程说起来很简单，就三步。

第一步，用户提问。

第二步，去知识库检索跟问题相关的内容。

第三步，把搜到的内容和问题一起发给大模型，让它根据搜到的内容生成答案。

就这么三步。

为什么这样就能解决知识截止和幻觉的问题。

知识截止的问题好理解。答案的来源是知识库，不是模型的训练数据。知识库是最新的，答案就是最新的。你更新知识库就行，不用动模型。

幻觉的问题怎么解决。因为大模型回答的时候有参考依据了。它不再凭记忆瞎说，会先看搜到的原文，再根据原文来回答。有据可查，准确率就高多了。

而且你还能溯源。用户问为什么这么回答，你可以把引用的原文片段找出来给他看。答案是从哪来的，清清楚楚。这个在企业场景里特别重要。

一个最简单的RAG例子

光说原理不够直观，我们写一个最简单的RAG。

不用向量数据库，也不用复杂的框架。就用Python写十几行代码，感受一下RAG是怎么回事。

fromdotenvimportload_dotenvfromlangchain_openaiimportChatOpenAI load_dotenv()model=ChatOpenAI(model="gpt-3.5-turbo",temperature=0)# 模拟知识库knowledge_base=["公司A产品的价格是2999元，发布于2025年3月。","公司A产品的保修期是一年，非人为损坏免费维修。","公司B产品的价格是4999元，发布于2025年6月。","公司B产品支持7天无理由退换货，15天质量问题包换。",]defsimple_search(query):"""最简单的关键词搜索"""results=[]foriteminknowledge_base:# 简单的关键词匹配forwordinquery:ifwordinitem:results.append(item)breakreturn"\n".join(results)defrag_answer(question):# 第一步，检索相关内容context=simple_search(question)# 第二步，带着上下文提问prompt=f"""请根据下面的参考资料回答用户的问题。 如果参考资料里没有答案，就说我不知道。 不要编造资料里没有的内容。 参考资料：{context}用户问题：{question}"""response=model.invoke(prompt)returnresponse.content# 测试print(rag_answer("A产品多少钱"))print(rag_answer("B产品保修期多长"))print(rag_answer("C产品价格是多少"))

运行一下你会看到。

第一个问题，A产品的价格，它能从知识库找到正确答案。
第二个问题，B产品的保修期，知识库没写B产品的保修，它可能会说不知道或者答错。这就是检索不准的问题。
第三个问题，C产品，知识库没有，它应该说我不知道。

这个例子很简陋，搜索是关键词匹配，知识库只有四条。但麻雀虽小五脏俱全，RAG的基本流程就是这样的。后面所有复杂的RAG系统，都是在这个基础上一步步优化出来的。

为什么需要向量检索

刚才的例子用的是关键词搜索。关键词搜索有个问题。用户问的话和知识库的文字不一定对得上。

比如知识库写的是"产品享有一年质保服务"，用户问的是"保修期有多久"。关键词匹配可能就搜不到，因为句子里没有"保修"这两个字。

人能理解"质保"和"保修"是一个意思，关键词匹配理解不了。

怎么解决这个问题。用向量检索，也叫语义检索。

向量检索的思路是，把文字转换成向量，然后用向量之间的相似度来判断语义的接近程度。意思相近的句子，向量距离就近。意思不相关的，向量距离就远。

“产品享有一年质保服务"和"保修期有多久”，字面上不一样，语义上很接近。转换成向量以后，它们的相似度很高，就能被检索到。

这就是为什么现在的RAG系统基本都用向量数据库。向量检索比关键词检索更懂语义，搜得更准。

当然向量检索也不是完美的。它也有搜不准的时候，有时候会漏掉相关内容，有时候会搜到不相关的。所以实际的RAG系统，往往是关键词检索和向量检索一起用，各取所长。

RAG的优势和局限

说清楚了原理，我们来客观地看看RAG的优缺点。

优势

第一，知识可以随时更新。今天加了新文档，明天就能搜到。不用重新训练模型。

第二，答案有据可查。每个回答都能找到对应的原文片段，可溯源，可验证。出了问题也能定位是哪里的问题。

第三，成本低。相比微调，RAG的成本低很多。不需要GPU，不需要大量训练数据，一个向量数据库就够了。

第四，数据安全。企业的敏感数据不用喂给模型训练，存在自己的向量库里就行。

局限

第一，检索质量决定回答质量。搜不到相关内容，再强的模型也答不好。搜到的内容不对，答案也会错。

第二，不擅长深度推理。RAG擅长找事实性的答案，比如价格、参数、规定。需要深度推理、综合分析的问题，光靠检索不够。

第三，上下文长度有限。能塞进上下文的内容是有限的，太多了模型处理不了，还会稀释有效信息。

第四，不能学习新知识。RAG只是检索和引用，它不会把知识内化到模型里。每次回答都要重新搜。

了解了这些，你就知道RAG适合做什么、不适合做什么。知识库问答、客服咨询、文档检索这类场景，RAG是首选。需要深度思考和创造的场景，RAG就不够用了。

为什么说RAG是大模型落地的首选

现在行业里有个共识，大模型落地，RAG是首选方案。为什么。

第一个原因，效果可预期。RAG的效果好不好，你大概能估计出来。知识库质量高，检索做得好，回答质量就不会太差。不像端到端的模型，效果很难预估。

第二个原因，成本可控。不需要大量标注数据，不需要昂贵的训练资源。几台服务器，一个向量数据库，就能搭起来。

第三个原因，风险可控。答案有来源，可以溯源，可以审核。出了问题能定位，也能修正。企业用着放心。

第四个原因，见效快。从0到1搭一个能用的RAG系统，快的话一两周就能搞定。然后可以持续优化，一步步提升效果。

这些特点加起来，让RAG成了企业引入大模型最稳妥的路径。先从知识库问答切入，跑通了再扩展到其他场景。风险小，见效快，ROI清晰。

这也是为什么这个专栏用了整整一个模块来讲RAG。做Agent落地，RAG是绕不开的。

下一篇我们讲文档处理流水线。知识库的质量直接决定RAG的效果。文档怎么解析、怎么切块、怎么处理不同格式，里面学问很多。