RAG 的意思是「检索增强生成」，英文全称 Retrieval-Augmented Generation。用大白话讲：让模型先去翻资料，再照着翻到的内容回答，而不是关起门来凭记性答。你问它公司的报销标准，它不会硬猜，而是先去翻你放进来的那份制度文件，找到对应段落，再照着写答案。

这个思路听着朴素，解决的问题却不小。模型答错的时候，多数不是它笨，是它手里根本没有那页纸。

全称里的三个词，对应三件事

把 RAG 拆开看，名字本身就把做法说完了。

检索：先去库里找东西

检索就是搜索。你问一句话，系统拿这句话去一个资料库里比对，挑出几段最贴近的文字。这个过程和你在搜索框里打字很像，只不过它不是在公开网络上搜，而是在你指定的那堆文档里搜。

增强：把找到的东西塞进问题里

找到的几段文字不会单独摆着，它们会被拼到你的问题前面，一起送给模型。模型这一次看到的不只是「报销标准是多少」，还有「以下是公司差旅制度第 4 章……」。它的作答范围被这几段话框住了。

生成：模型照着手里的材料写答案

最后一步才是我们熟悉的那个环节：模型组织语言，写出一段通顺的回答。区别在于它这次是对着材料写，像开卷考试，而不是闭卷默写。

整套流程其实就三步

把资料切块，存成能搜索的形态

一份 80 页的产品手册，没法整本塞给模型。系统会先把它切成一段一段，每段几百字，切的时候尽量不打断一个完整意思。切好的每一块会被转成一串数字，业内叫向量，存进一个专门的库。你可以把这步理解成给每页资料贴标签、编索引，方便以后翻。

切块的大小有讲究。切得太碎，一句话里没有上下文，搜出来也读不懂；切得太长，一块里混了好几个话题，搜到的那段里可能只有一句是你要的。我见过一个团队把整章存成一块，结果每次检索都命中同一段，答什么都往那上面扯。

拿你的问题，去库里找最像的几段

你提问之后，系统把你的问题也用同样的方式转成数字，再去库里找距离最近的几块。找几块是可以调的，常见是三到五块。找少了会漏掉信息，找多了会把不相干的内容一起塞进去，反而干扰模型判断。

把问题和找到的内容一起交给模型

这一步的提示词大概长这样：先给几段资料，再写一句「只根据以上内容回答，资料里没有就说没有」，最后才是你的问题。模型拿着这份临时材料作答，答完这一轮，材料就丢了。下次再问，它重新去库里找一遍。

它和直接问模型，到底差在哪？

直接问模型，等于问一个读了很多书但没看过你公司文件的人。它知道一般的报销流程长什么样，却不知道你们单位住宿费上限是几百块。这类问题它答得越流利，你越容易当真。

RAG 相当于临时给它外挂一份参考资料。同一个模型，接口没变，参数没变，只是每次提问时多塞几页纸进去。它的知识范围从「训练时见过的」扩到了「你现在给它的」。

打个比方，会计做账时手边摊着凭证，翻一张记一笔。凭证不在他脑子里，但他算出来的数对得上账。RAG 让模型也这么干活，手边有据可查，笔下就不容易飘。

还有一层时间上的差别。模型的知识停在训练数据截止的那一天，之后改的规章、换的价格、新出的型号，它一概不知道。RAG 每次都是现查，你的资料今天更新，今天问就能查到新的。模型本身没变聪明，是它手边的东西变新了。

为什么它能减少胡编

答案有出处，能回头核对

做得细的 RAG 系统会把引用标出来：这句话来自哪份文件的第几段。你看到一段结论，可以点开原文对一遍。核对这个动作本身就筛掉了不少错误，因为编造的内容常常找不到对应的原文。

模型被要求「照材料说」的时候，也少了自由发挥的空间。它不再需要从记忆里拼凑细节，只需要把眼前的几段话读懂、归纳、换个说法讲出来。这个任务比默写容易得多。

但它只是降低概率，不是消除错误

这一点要说清楚。RAG 不是保险箱。检索那一步没找对内容，后面全歪。你问「退货多久到账」，库里存的是一份两年前的旧版规则，模型会非常认真地照着旧规则答，语气还很肯定。

翻车的方式有好几种：切块把一句话拦腰截断，搜出来的半句读着像另一个意思；你问「年假」，文档里写的是「带薪年休假」，用词对不上，检索就可能漏掉；几段资料互相矛盾，模型挑了错的那段。

所以我一般会跟人说，RAG 把「凭空编」换成了「照着错的材料答」。后者听起来没那么糟，对使用者来说一样是错答案。

几个容易搞混的地方

上传文件聊天，不等于 RAG

现在很多产品支持拖一个 PDF 进去直接问。这种体验是 RAG 的一种形态，但不全是。有的产品只是把整份文件塞进模型的上下文窗口，文件小的时候能用，文件一大就塞不下，也做不了跨几百份文档的检索。完整的 RAG 有一套独立的索引和检索环节，能管住成千上万份资料。

资料更新了，模型不会自己学会

这是问得最多的一条。你把制度文件改了一版传上去，模型并没有「学到」新内容。它只是在下次回答时，检索到了新文件。如果索引没重建，旧文件的碎片还留在库里，它可能同时看到新旧两个版本。

所以资料改动之后，要记得让索引跟着更新。这一步常被漏掉，表现就是「明明改了，它还按老的答」。

用了 RAG，资料的质量还是得治

垃圾进，垃圾出。

这句话在 RAG 上体现得特别直接。扫描件没做文字识别，检索出来是一堆乱码；同一份制度存了五个版本，谁也不知道哪个有效；表格转成文本时行列错位，数字全串了。这些毛病的根在资料，换什么模型都救不回来。

我见过一些团队，模型换了三轮，效果没起 {MOD}，回头一查，是知识库里躺着一半过期文档。

哪些场景真的用得上

判断标准很简单：答案是不是写在某份你能拿到的文档里，而且这份文档会变。两条都占，基本就适合；一条都不占，硬上也没多大意思。

企业知识库问答是最典型的一类。新员工入职，问社保怎么转、门禁卡在哪办、出差住宿什么标准，这些答案都写在制度里，只是散在十几个文档里不好找。RAG 把这些文档收进去，一句话就能问出来，还带原文链接。

这类系统里还有个绕不开的事：权限。财务制度只该让财务看，人事档案只该让人事看。检索的时候得按人筛一遍，不然一句提问就能把不该看的段落捞出来。这一点比模型选型更容易出事。

客服话术查询也合适。产品有几百个型号，每个的退换政策不一样，坐席不可能全背下来。把政策文档和话术库接进去，边聊边查，答错的比例会降下来。

产品手册检索是另一块。设备装了几年，说明书早丢了，维修师傅在现场想知道某个报警码什么意思。手册做成 RAG，手机上一问就有，比翻 PDF 快得多。

内部规章查询同理。考勤、报销、采购审批、保密要求，这些内容的特点是条目多、改动频繁、答错的代价不低。这类场景对「有出处」的需求，比对「答得快」的需求更强。

反过来看，需要模型自己推理、写方案、做创意的时候，RAG 帮不上太多。它擅长把已有的事实找出来讲清楚，不擅长无中生有。

想自己搭一套，先想清楚三件事

资料够不够干净。先把重复的、过期的、扫描不清的清一遍，比调模型参数有用得多。

问题会长什么样。用户是打三个关键词，还是写一整句话，决定了检索怎么设。拿真实的问题去测，别拿自己编的例句测。

答不出来的时候怎么办。系统要留一个「资料里没有」的出口，而不是硬凑一个答案。这个出口设不好，前面做的核对全白费。

RAG 不神秘，它就是把「查资料」这个动作塞进了回答流程里。理解了这一点，很多产品宣传里的说法，你自己就能判断真假。