RAG实战：用检索增强生成给大模型配上知识库，告别幻觉

你有没有遇到过这种场面：前一天刚把一份关键报告喂给大模型，第二天问它报告里的某个数字，它居然面不改色地给你编了一个。你反复强调“答案就在那份文档里”，它却依然坚持自己的一套。这不是错觉，也不是它讨厌你，而是因为大模型本质上是一个“闭卷考试”的选手。所谓“记性差”，其实是它压根没有“记忆仓库”。RAG就是专治这个毛病的方案，全称Retrieval-Augmented Generation，检索增强生成。核心思路很简单：别让模型硬记，而是给它配一个外部资料库，在它开口回答之前，先去资料库里把相关片段捞出来，再让它基于这些片段作答。这篇文章会从原理讲到实操，哪怕你只会写Python的Hello World，也能跟着做出一个能跑的RAG小系统。

1. 大模型的“记忆”到底差在哪里？

1.1 三个典型痛点：知识截止、幻觉、私有数据

先得把“记性差”这件事拆开看。第一个痛点是知识截止。一个模型在训练完成后，它的参数里保存的信息就固定了。你问它最近一个星期发生的事情，它大概率只会基于训练时见过的旧信息去推测，而不是真的知道答案。这不是笨，是物理限制。训练是极度昂贵的，不可能每天把互联网全部重新喂一遍。

第二个痛点是幻觉。模型在遇到不知道的问题时，不会像一个诚实的人那样说“我不懂”，而是会按照语言规律“编一个看起来合理的答案”。这在聊天时可能无伤大雅，但用在正经场景，比如回答合同条款、产品参数、内部流程时，就是灾难。你拿着它编出来的假信息去汇报，咔嚓一下就是事故。

第三个痛点是私有数据。你的企业文档、个人笔记、项目日志，这些内容根本不在模型的训练语料里，它无论如何都不可能知道。有人试着把这些资料直接写进Prompt里，但Prompt长度有限，塞不下几百份文档。就算勉强塞进去，模型也会被海量无关信息干扰，反而记不住关键内容。

这三个痛点其实指向同一个本质：大模型擅长的是“把已有的知识表达出来”，而不是“按需查找特定信息”。我们需要的不是让模型把每件事都背下来，而是让它像真人一样，遇到记不清的事情，知道去哪儿查资料。

1.2 RAG为什么能救场：让AI学会“查资料”

RAG的思路特别直白：既然你记不住，那我就在你回答之前，先把相关资料送到你眼前。这就好比考试从闭卷变成了开卷。你不需要背下整本百科全书，只需要知道题目来了之后，该翻哪一章、找哪一段，然后照着原文组织答案。

传统做法是让大模型直接生成答案，它靠的是参数里的记忆。RAG则是在“生成”前面加了一个“检索”步骤。用户提出问题时，系统先到外部知识库里做一次相似度搜索，找出最相关的文本片段。然后再把这些片段连同用户问题一起，拼成一个上下文丰富的Prompt交给大模型。模型最终输出的内容，就是基于这些真实片段“总结”出来的，而不是凭空捏造的。

这个机制解决了我前面提到的三个痛点：外部知识库可以随时更新，所以知识截止问题不存在；模型输出受限于检索到的片段，幻觉大幅减少；你自己的文档只要进了知识库，它就拥有这部分“临时记忆”，私有数据也能被回答。这也是为什么目前几乎所有知识库问答、企业文档助手背后都在用RAG——它不是花架子，而是真正把大模型从“记忆力差的优等生”改造成“会查资料的执行者”。

2. RAG系统的四个核心环节

2.1 知识库预处理：切分、向量化、建索引

一个可用的RAG系统，第一步是把文档变成可检索的结构化数据。原始文档是随便的一段文字，长短不一，语义密集度也参差不齐。如果整篇文档作为一个单位去检索，用户问一个小问题，检索出来的却是一整篇万字长文，真正有用的信息反而淹没在大段内容里。所以我们要切分。

切分的技术名词叫“文本分块”，英文叫Chunking。切多大合适？没有绝对标准，但有一个经验原则：切出来的每一块，语义要相对完整，同时大小要适合模型读取。比如一份产品手册，按章节或小标题切分就比较自然。若用固定大小切分，通常是200到500个字符一块，块之间可以重叠20到50个字符，避免把一句话拦腰截断导致语义丢失。

切块之后要做“向量化”。电脑不懂文字，只懂数字。向量化就是把一段文本计算成一个高维数值列表，这个列表可以理解成文本在“语义空间里的坐标”。语义接近的两段话，坐标距离就接近；语义无关的两段话，坐标距离就远。向量化的效果取决于Embedding模型，也就是“文本转向量”的那个模型。选一个高质量的中文Embedding模型，是RAG效果好坏的重要分水岭。

有了向量，还得有地方放。向量数据库或索引就是用来存储这些向量的。市面上有很多成熟方案，但小项目也不一定要上重型数据库，直接存在内存里，用列表加上余弦相似度计算也能跑。关键思路是：对每一块文本计算向量后，连同文本原文、来源页数等元信息一起存进去，构建出一个可检索的索引。

2.2 用户查询的路由：检索召回与相关性排序

知识库就绪之后，用户会抛来一个问题。系统拿到这个问题，先做和文档同样的处理——用同一个Embedding模型把问题也转成向量。然后拿着这个向量去向量库里“找人”，计算它与每个文档块向量的相似度，按得分从高到低排序。这一步叫检索召回。

检索阶段通常会限定一个“取回数量”，也就是top_k。比如top_k=3，意思是最多取回3个最相关的文本片段。为什么不是越高越好？因为模型对过长上下文的注意力会稀释，塞太多无关内容反而会干扰判断。一般小知识库取3到5个片段，大知识库取5到8个，再配合相似度得分阈值做过滤，能显著提高回答准确度。

这个打分背后其实是数学上的余弦相似度，范围在-1到1之间，越接近1表示方向越一致。实际使用中，0.7以上通常说明比较相关，0.5到0.7可以纳入候选，低于0.5就要考虑是不是知识库里根本没有对应内容。我习惯把得分也记录到日志里，这样排查问题时会非常直观。

2.3 增强生成：把检索结果塞进Prompt

检回来的片段不会直接丢给大模型，而是要经过一个“组装”步骤。常见做法是构造一个Prompt模板，里面明确告诉模型：以下是从知识库中检索到的资料，请根据这些资料回答问题。如果资料中没有相关内容，请直接说明不知道，不要编造。

Prompt模板会占到系统效果的一部分。好的模板把“用户问题”和“检索资料”分开，避免模型把检索原文和用户问题混为一谈。我常用的模板结构是：先给角色设定，再把多个检索片段按序号列出来，然后放上用户问题，最后追加一句“只基于上面提供的资料，不要使用你的内部知识”。这套模板看起来简单，但实际测试下来，比直接拼接效果稳定得多。

此时，RAG的“G”，也就是Generation，才开始工作。大模型读取这个拼接好的Prompt，把检索片段作为事实依据，生成一段流畅的答案。因为片段里包含了真实出处，模型相当于在做“总结转述”，而不是“凭空创作”。这也是RAG能显著降低幻觉的主要原因。

3. 小白也能上手的RAG实操

3.1 技术选型：只讲原则，不点品牌

很多教程一上来就让你装一堆框架，结果环境依赖冲突，还没看到效果就劝退了。我的建议是：先不依赖重型框架，用Python基础库手写一个最小RAG，把流程跑通，再考虑要不要引入成熟工具。这样你能清楚地看到每一步发生了什么，而不是被框架的黑盒迷惑。

需要提前准备的东西有：一个能提供文本转向量能力的Embedding服务，一个能根据Prompt生成答案的大模型接口。这两个服务你可以用云端API，也可以用本地开源模型。实操中怎么选？初期建议选你手头最容易调通的接口，哪怕速度不快，先把链路跑通。链路通了，后面换高性能组件都是一行函数的事。

代码方面，我会用到Python自带的math库做余弦相似度计算，其他的都用最基础的数据结构。你不需要安装额外的第三方库，只需要Python 3.8以上环境。如果连Python都还没装，直接去官网下载安装，装完打开命令行输入python --version，能输出版本号就说明环境OK。

3.2 最小可用的RAG代码结构

我现在展示一个极简实现。先定义两个抽象函数：get_embedding(text)用来把文本转成向量，call_llm(prompt)用来向大模型发送请求并获取回答。实际使用的时候，你把这两个函数替换成对应服务的SDK调用即可。

import math from typing import List, Dict def get_embedding(text: str) -> List[float]: # 这里换成你的Embedding服务调用 # 返回一个固定长度的数值列表 raise NotImplementedError("替换为实际的Embedding接口") def call_llm(prompt: str) -> str: # 这里换成你的大模型服务调用 # 输入拼接好的Prompt，返回生成的文本 raise NotImplementedError("替换为实际的大模型接口")

下面这段代码负责把文档切分成块。我使用基础的字符切分，实际项目中你可以换成按段落或按Markdown标题切分，效果更好。

def split_text(text: str, chunk_size: int = 200, overlap: int = 20) -> List[str]: chunks = [] start = 0 while start < len(text): end = start + chunk_size chunks.append(text[start:end]) if end >= len(text): break start = end - overlap return chunks

切块的逻辑很简单：每次前进chunk_size - overlap，这样相邻两块之间有20个字符的重复。重复的目的就是防止关键信息恰好落在切缝上。假如一句话刚好被切到上一块结尾和下一块开头，两块各含半句，检索时会因为语义不全而漏掉。有了重叠部分，这句话至少能完整出现在其中一块里。

然后是构建索引和检索。我直接用列表保存，检索时逐个计算余弦相似度。

def cosine_similarity(vec_a: List[float], vec_b: List[float]) -> float: dot = sum(x * y for x, y in zip(vec_a, vec_b)) norm_a = math.sqrt(sum(x * x for x in vec_a)) norm_b = math.sqrt(sum(x * x for x in vec_b)) if norm_a == 0 or norm_b == 0: return 0.0 return dot / (norm_a * norm_b) class SimpleVectorStore: def __init__(self): self.chunks = [] self.vectors = [] def add(self, chunk: str, vector: List[float]): self.chunks.append(chunk) self.vectors.append(vector) def search(self, query_vector: List[float], top_k: int = 3) -> List[Dict]: scored = [] for i, vec in enumerate(self.vectors): score = cosine_similarity(query_vector, vec) scored.append({"index": i, "score": score, "text": self.chunks[i]}) scored.sort(key=lambda x: x["score"], reverse=True) return scored[:top_k]

这段代码没有任何魔法。cosine_similarity就是高中向量夹角的余弦公式；SimpleVectorStore类似一个带索引的列表。每次添加文本块时，我们把向量存起来，检索时用问题向量和库里每一个向量做点积归一化，得到相似度。数据量小的时候，这个线性扫描完全够用。

接下来是做Prompt组装和完整流程。

def build_prompt(query: str, retrieved_chunks: List[Dict]) -> str: context = "\n\n".join( [f"[资料{i + 1}] {chunk['text']}" for i, chunk in enumerate(retrieved_chunks)] ) prompt = f"""你是一名信息检索助手。请严格根据下面的资料回答问题。 如果资料中没有相关信息，请直接回复“资料中未找到相关内容”，不要自行编造。 资料： {context} 问题： {query} """ return prompt def rag_pipeline(query: str, store: SimpleVectorStore, top_k: int = 3) -> str: query_vector = get_embedding(query) retrieved = store.search(query_vector, top_k=top_k) prompt = build_prompt(query, retrieved) answer = call_llm(prompt) return answer

到这步，一个最小RAG就算成型了。你只需要把文档读完，切块，向量化后存入SimpleVectorStore，再调用rag_pipeline就能得到答案。整个过程没有引入任何第三方框架，每一步的原理都暴露在代码里，出问题也能很快定位。

3.3 完整跑通一套流程的注意事项

上面代码里我留了两个raise NotImplementedError，这是因为不同的服务调用方式差异太大，没必要写死。实际替换时要注意几个细节。

第一，Embedding接口返回的向量长度通常由模型决定，比如几百到几千维。你不需要关心维度多大，只要保证所有文本和查询都使用同一个Embedding模型就行。如果混用不同模型，向量空间不一致，算出来的相似度毫无意义。这是新手最容易犯的错误。

第二，大模型接口调用时，Prompt里的资料长度不要超过模型的上下文窗口。如果你的切块是200字符，取回3块，加上系统提示和问题，一般一千字以内，主流模型都能处理。如果你追求更高召回，取了10块，每块又很大，就可能超过限制，接口会直接报错。

第三，文档来源信息最好跟着存下来。比如在SimpleVectorStore里除了保存文本，还保存文件名、页码或章节标题。这样当答案生成之后，你可以把引用来源附在后面，方便人工验证。这在实际业务场景中几乎是必须的，否则模型答得再对，你也不知道它依据的是哪一段。

4. 实测效果与调试心得

4.1 为什么检索结果不准？最常见的原因

我帮某开发者A同学搭过一个内部知识库问答，用的就是上面这套思路。A同学一开始很兴奋，往知识库里灌了几百页的规范文档，结果问第一个问题答案就偏了。他以为是大模型不够聪明，把模型换来换去，效果毫无起色。我排查后发现问题出在检索环节：文档是PDF转出来的，排版乱，切块时把表格内容拆得七零八落，嵌入向量全部失真。

这是第一个常见原因：文档质量差，切出来的块语义破碎。解决办法是预处理时要清洗文本，去掉多余的换行和空格，把表格转换成自然语言描述。第二个常见原因是Embedding模型和领域不匹配。通用模型在日常对话上表现不错，但对专业术语、特殊缩写不敏感。这时候要么换领域优化的Embedding模型，要么在切片里保留上下文词汇，帮助模型正确编码术语。

第三个原因是top_k取值不当。A同学最初把top_k设成1，认为只找最相关的一段最准确，但有些问题的答案分散在多个段落里，只取一段就会漏掉关键信息。我帮他改成top_k=5，问题立刻解决。检索不是越精确越好，而是要在“相关”和“完整”之间找平衡。

4.2 必看的几个关键调参点

我把调参过程中的经验整理成一张表，方便你对照：

调参并不是一次到位。我最开始会固定其他参数，只单独调chunk_size和top_k，记录每组参数下两三组测试问题的回答质量，做一个小对比。比如同一篇文档，chunk_size=200和chunk_size=500的检索结果可能完全不同。花半小时做这种对比，比盲猜模型要高效得多。

这里要特别提醒：不要盲目相信“窗口越长越好”。有些模型上下文窗口虽然有几千甚至上万字，但真正能精准聚焦的信息还是有限的。塞入过多片段，模型可能会被无关内容带偏，甚至把它当成事实。我见过有人把top_k设为20，结果回答里混进了好几个矛盾片段的信息。所以宁可少而精，也不要贪多。

4.3 从“能跑”到“好用”的几个进阶技巧

跑通最小RAG之后，你会遇到另一个问题：效果比纯靠大模型强，但离“好用”还有距离。我分享几个投入产出比极高的优化。

第一个是文档清洗。很多人直接把PDF、Word塞给切分器，结果页眉页脚、页码、乱码都混进来了。建议在切分前做一次文本归一化：统一换行符，去掉多余空白，识别的乱码字符能替换就替换。别小看这一步，我的经验是清洗前后检索命中率能提升两成以上。

第二个是元数据过滤。如果知识库覆盖多个主题，可以在向量化过程中给每个块打上标签，比如“产品规格”“常见问题”“售后政策”。检索时先按标签过滤，再做向量相似度搜索，准确率会明显提升。这个功能在简单代码里只需要在SimpleVectorStore里加一个字段，非常值得做。

第三个是自建小测试集。拿二三十个典型问题，预先人工写好标准答案，每次改完参数或更换模型，就自动跑一遍，比较回答是否命中关键词或语义相似。没有这个测试集，你会靠感觉调参，效果很随机。有测试集之后，每次改动是变好还是变坏，一目了然。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

下面的这些问题，是我和身边朋友实际踩过的高频坑，整理成速查表：

排查顺序也是有讲究的。我建议先看检索结果，再看Prompt，最后才怀疑大模型。记住：RAG里大约一半的问题出在“检”上，另一半出在“组装”上，真正属于模型生成能力的问题反而不多。

5.2 一个完整的排查案例

某开发者在做项目文档答疑时遇到一个问题：用户问“去年年末的项目复盘报告里，提到了客户满意度下降的原因是什么？”系统给的答案却是完全不相关的一个关于预算的表述。这个回答一眼就很离谱，但他反复调整模型参数都无效。

我让他先把检索到的片段和时间打分打印出来。一打印发现，检索回来的3个片段里有两个是关于预算的，只有一个提到“客户满意度”，而且那个片段是不完整的一句话：“客户满意度受交付周期影响较大，因此”。后续内容被切到了下一块，而这个下一块因为得分略低没有被取回。

问题就出在切分点正好落在关键句上，同时top_k没有覆盖到那个补充片段。解决方案有两个：一是把chunk_overlap从20加大到50，这样关键句大概率会完整出现在某一小块里；二是把top_k从3提升到5，让语义相关但排序靠后的片段也有机会进入Prompt。

他按我建议把overlap改成50后重新跑，检索到的第一个片段就是完整的那句话。再问一遍，答案变得准确多了。这个案例说明：很多“模型答错”的表象，根源在几行切分参数，而不是模型本身不够强。

还有一次，某同学把同一篇文档分别用两个语言版本的Embedding模型编码，导致向量距离全部失真。我让他统一模型后，一切恢复正常。所以再次强调：一个系统里，全链路的向量化模型必须保持一致，这是原则，不是建议。

6. 最后再分享一个实用小习惯

我在实际项目中养成了一个习惯：每跑一个RAG系统，都会保留一份“检索片段快照”，也就是把每个问题对应的检回片段和相似度得分保存下来。这样即使集成到线上系统之后，别人拿着一个问题来问我为什么答得不好，我不用猜，直接看快照就能定位。这个习惯帮我在处理线上问题时省下大量时间。

另外，如果你准备长期做知识库问答，建议尽早把向量库持久化，不要每次启动都重新切分和向量化。我最初图省事，所有向量都存在内存里，文档一多启动就要等好几分钟。后来改成第一次构建后落盘，启动时直接加载，时间从几分钟降到几秒。改动量很小，但体验提升非常明显。

RAG并不是什么高不可攀的魔法。它就是把“检索”和“生成”两个成熟技术拼起来，中间用向量化解开连接。多动手跑几遍，多打印中间结果看，你会很快理解每个环节的脾气。等你把它调顺了，再回头看“大模型记性差”这个问题，会发现它早就不是问题了——你只是给AI配了一个随时可查的档案柜而已。