RAG检索增强生成和大模型之间的关系最近被问到的频率高得惊人尤其是我已经接了大模型的API为什么还要做RAG上了RAG之后微调是不是就废了这类问题。说句实话这两者从来就不是同一层的东西大模型是大脑RAG是给它配的外接资料库。但很多人把它们当成并列的技术路线来选结果要么白折腾要么走了弯路。这半年我在几个知识库项目里把向量化、分块、本地部署、混合检索这些环节挨个踩了一遍今天这篇文章就围绕一个核心问题展开RAG和大模型到底是怎么咬合的每一步在替大模型解决什么结合实际落地时的选型、切分、评估经验一次说透。1. 大模型的两个死穴知识过期与幻觉RAG正是为它们而生1.1 参数里存的是概率不是事实先说清楚大模型内部的知识长什么样。训练时模型看到的是海量文本把token之间的统计关系压缩进几十亿甚至上千亿个参数里。你问它一个问题它做的其实是一次次概率预测——下一个最有可能出现的词是什么。所以它的知识边界非常明确训练数据里见过的东西它大概率能答得漂亮训练数据里没有的东西它只能靠邻近知识的迁移来猜。这个猜就是问题的根源。很多朋友拿企业内部的合同、售后记录、设备手册去问通用大模型发现答案全是正确的废话原因就在这里——这些私有数据根本没出现在训练语料里。再比如热词里经常有人查大模型如何理解文档答案是大模型理解文档的前提是文档内容能进入它的上下文窗口而私有文档恰恰进不去。知识截止日期是一堵硬墙大模型再强也翻不过去。1.2 幻觉不是想骗你是生成机制的必然产物幻觉这个词大家都熟但它的成因经常被误解。大模型并不是故意编造而是它根本没有我不知道这个选项。当某个问题超出它的知识范围时它仍然会按照概率把词一个一个推出来只要生成的句子连贯、符合语言习惯它自己觉得没问题就会自信地输出。哪怕你把温度调到最低也只是让输出更稳定并不会让不知道变成知道。我见过最典型的场景是科研场景有人拿大模型辅助写论文问它某篇参考文献的出处它给出了一个格式很规范、作者名字也像模像样的条目但文献压根不存在。这就是幻觉的可怕之处——它比直接说错更危险因为它太像真的了。RAG在这里的价值是直接的把可信资料检索出来后塞进上下文让大模型只能基于这些资料作答从机制上压缩幻觉空间。1.3 落到业务场景这三点最致命抛开理论从实际项目看大模型短板集中在这三处私有数据不可见企业内部知识、专家经验、历史报表大模型一概不知。这决定了它没法直接在企业场景里当懂行人。知识无法快速更新训练一次模型动辄消耗大量算力和数据集而业务数据每周都在变用重训练去追最新动态根本不现实。回答无法溯源即便答对了你也没法向它要一句这句话出自哪份文档。在合规要求高的行业没有来源支撑的答案等于没有答案。这三个短板正好对应RAG的核心作用外挂知识、按需检索、原文溯源。这就是为什么RAG不是大模型的锦上添花而是大模型真正走向业务场景的必经之路。2. RAG到底怎么工作文档切成块、问题变向量、答案带着证据出2.1 离线建索引切分、向量化、进库RAG的第一步是把知识库里的原始文档变成可检索的索引。这里包括三个动作切分chunking、向量化embedding、入库indexing。切分听起来简单做起来最容易翻车。以中文文档为例如果按固定300到500字符切块很容易把一句话的上下文从中间割断导致语义碎片化。靠谱的做法是按段落、标题、列表项等自然边界切同时让相邻块保持一定重叠比如50到100字符的重叠区保证跨块的语义连续性。后面我会专门讲切分策略这里先记住一个结论切分质量决定了检索质量的底限。切完之后每一块文本要交给嵌入模型转成向量。嵌入模型和大模型是两回事它的任务是把一段文本映射到一个几百维甚至上千维的向量空间语义相近的文本在空间里的距离也近。这个向量随后存入向量数据库比如Chroma、Milvus、FAISS同时把原文和元数据、文档ID一起存好方便后面溯源。2.2 在线检索把问题也变成向量用相似度找候选用户提问时系统用同一个嵌入模型把问题转成向量然后在向量数据库里做近似最近邻搜索。最常用的度量是余弦相似度取值范围从-1到1越接近1表示和问题越相关。通常会取Top-K条最相似的块K一般设在3到8具体取决于上下文窗口和答案复杂度。这一步有个很好的生活化类比把向量数据库当成一个图书管理员你给管理员一句话他脑子里想的不是这句话出现在哪本书第几页而是哪几段内容说的意思跟这句话最接近。这意味着RAG的检索是语义层面的不是关键词层面的——用户问这批货什么时候能到知识库里写的是预计交付周期为三个工作日这两句没有任何重合词但语义高度相关向量检索能把它们匹配上。2.3 生成阶段大模型不是凭空答而是带着资料答检索到相关块之后系统把它们和用户问题一起组装进一个提示词模板再交给大模型生成答案。这里有一个关键认知RAG全程没有修改大模型的一个参数它只是改变了模型看什么来作答。你可以把这一步理解为让考生带着资料进考场模型本身的知识储备没有变但答题时的依据变扎实了。一个标准的生产级提示词模板长这样你是一名知识库助手。请只基于以下资料回答用户问题。 如果资料中没有相关信息请直接回答知识库中未找到相关内容不要自行编造。 资料 {检索到的文本块们} /资料 用户问题{用户问题}注意模板里的两个细节都是经验之谈一是明确要求没有资料就承认不知道这能显著降低幻觉二是把资料放在问题之前让模型先读资料再作答输出会更稳定。实测下来这两个细节对答案质量的影响往往比换一个更强的模型还明显。3. RAG和微调的分工什么时候补知识什么时候调行为3.1 一个比喻把两者的关系说清楚很多人纠结到底该做RAG还是做微调我的回答是先想清楚你要解决的是知道什么还是怎么说话。微调是在大模型的基础上用一批带标注的数据继续训练改变的是模型参数和权重。它能改变模型的行为习惯、输出格式、领域措辞甚至学会调用特定工具。这有点像调整一个人的说话风格和办事方式而RAG不碰参数只在每次提问时动态地给模型补充参考资料。这更像是在考试时递给考生一份可靠的书单。所以两者的定位完全不同微调管行为RAG管知识。知识类问题用RAG解决行为类问题用微调解决大部分场景根本用不着非此即彼。3.2 什么信号出现才值得做微调我总结下来确实需要微调的场景通常是这四类固定输出格式比如必须输出严格JSON、固定字段、特定语气提示词怎么写都压不住模型自由发挥。专业术语和行文风格比如法律文书、医疗报告、客服话术要求用特定的行业表达习惯这种一致性很难靠临时提示词保证。工具调用能力让模型学会按特定格式调用内部API或函数这是行为层面的训练RAG替代不了。特定对话角色的性格设定长时间的扮演类场景微调后的人设更稳定。注意微调解决不了知识缺失。用微调去教模型记住一批事实性内容不但浪费数据还可能造成参数冲突学完新知识旧能力却退化了。3.3 什么信号出现优先上RAG反过来下面这些场景基本不用犹豫直接走RAG知识更新频繁业务数据天天变每次重训模型不现实改文档重新建索引就行。依赖私有数据合同、手册、聊天记录、会议纪要这些内容大模型永远学不到必须靠检索注入。回答需要溯源客户或合规部门要这句话的依据是什么RAG能把答案和原始文档ID绑定微调做不到。数据量小但要求高只有几百份文档的领域知识用RAG完全够用微调反而容易过拟合。3.4 落地项目里我常用的组合路线实际项目里RAG和微调常常是先后关系而不是二选一。我的习惯是先上RAG把知识检索链路跑通观察一段时间回答质量如果发现格式、语气、结构化输出确实有硬伤再针对性地做一次轻量微调比如用LoRA这类参数高效微调方案成本可控。最后再把微调后的大模型接回RAG框架里让资料供给和表达能力各司其职。对比维度RAG微调知识更新成本低重新入库即可高需重新训练事实准确性高基于检索证据低依赖参数记忆输出行为控制弱靠提示词约束强直接改参数数据需求量少几十篇即可起步多通常要上千条可解释性好能溯源差黑盒算力成本低高这个表格建议收藏。每次项目讨论会上有人争论技术路线把这张表拍出来问题基本当场结束。4. 知识库能不能存图片多模态RAG的现实边界与落地策略4.1 为什么普通RAG存不了图片热词里有不少人在搜rag知识库能存储图片嘛这个问题确实容易踩坑。从原理上讲常规RAG的整个链路是围绕文本设计的文档被切块、文本被向量化、向量被检索、文本被拼进提示词。图片本身不是文本你没法直接拿一张照片去做普通文本切分更没法把图片像素送给文本嵌入模型转向量——嵌入模型只接受文本序列。所以严格答案是纯文本RAG存不了图片。如果你只是把图片文件硬塞进知识库目录检索时它根本不会参与打分等于没存。4.2 多模态时代图片进RAG的三种主流做法虽然原生图片进不了传统RAG但多模态模型发展之后业界已经有几套成熟思路图文描述转文本先用视觉语言模型VLM对图片生成详细描述文本再把它和图片路径、标题、OCR识别出的文字一起入库。检索时命中描述文本再通过路径把原始图片调出来。这是目前性价比最高、也最好实现的方案。多模态向量化用CLIP这类图文对齐的嵌入模型把图片和文本映射到同一个向量空间。用户用文字问去年年会合影系统能在图片向量里直接检索到相关照片。适合真正的以图搜图、相册检索场景但需要额外部署多模态嵌入模型。文档结构解析针对PDF里的图表、流程图、表格用解析工具把表格转成Markdown、把图表转成结构化文字描述然后再走普通文本RAG。很多号称支持多模态知识库的工具底层用的其实是这套化图為文的降维思路。4.3 我给初学者的落地建议如果你不是做相册检索、商品图像搜索这类强视觉场景我建议别一上来就上多模态RAG。先用文本方案跑通把图片的标题、说明文字、OCR结果提取出来作为图片的文本替身入库。这已经能满足绝大多数企业内部知识库诉求比如设备说明书里的电路图、合同里的签字盖章页。等到你确实遇到用户必须直接检索图片内容的需求再去上CLIP这类的多模态嵌入。记住一个原则能让文本承载的信息就不要让图像直接参与检索。多模态RAG不是不能用而是它的成本、延迟、部署复杂度都比纯文本高一截得拿实际需求说话。5. 从零搭一套本地RAG知识库选型、分块与翻车点5.1 模型选型生成模型和嵌入模型分开选本地RAG至少要两个模型一个是生成回答的大模型一个是负责向量化的嵌入模型。很多人以为一个模型全包了这是最常见的起步误区。大模型这边我用Ollama做本地部署比较多它把模型下载、量化、启动都封装成了简单命令对单机实验特别友好。模型体积和效果要平衡通常7B到14B参数量的量化版本在消费级显卡甚至纯CPU上就能跑。需要说明的是本地模型的能力上限确实比云端商用API低但数据不出内网这在很多企业场景里是不可妥协的硬条件。嵌入模型这边中文场景BGE-M3和M3E是绕不开的两个选择在中文语义匹配上的表现明显优于通用英文模型。这里有个必须记住的规则建索引和查询必须使用同一个嵌入模型。如果你建库时用A模型查询时换成了B模型向量空间的坐标系都不一样检索结果会直接报废。这个错误隐蔽且致命我见过不止一个团队在这个坑里折腾了整整一周。5.2 框架选型LangChain4j、Dify还是自研框架选择没有标准答案关键看你的技术栈和场景。这里按我接触过的三类情况给出选型建议框架擅长场景适合人群LangChain4jJava技术栈的RAG集成把文档加载、切分、向量检索、提示词组装串成一条链Spring生态的Java团队Dify低代码/可视化编排内置知识库管理和模型接入一条提示词即可发布应用非深技术背景想快速出DemoLlamaIndexPython生态的文档索引与检索对复杂文档结构支持好Python工程师、数据团队自研链路对检索逻辑有高度定制需求比如多路召回、复杂权限控制已有稳定技术栈的长期项目我个人做企业项目时倾向于先用Dify验证效果原型跑通后再根据性能瓶颈决定是否自研检索链。这能节省很多早期时间——你真正需要操心的是检索质量而不是框架API怎么调用。5.3 切分策略与本地文本拆解工具切分是RAG里最容易被低估的一步。对于中文常见的切分参数是每块300到500字、重叠50到100字但更重要的是按语义边界切。先用标题识别Markdown的#、PDF的书签层级划分章节再在章节内按段落切最后兜底按固定长度切。这样切出来的块每一块都是相对完整的语义单元检索命中时提供的上下文才不残缺。关于热词里问到的本地RAG文本拆解工具实际上并不需要专门的大工具PDF类文档用PyMuPDF或pdfplumber提取正文和结构表格类用Camelot或表格识别模型转成Markdown扫描件先过OCR再按文本处理。一套Python脚本就能完成整个拆解流水线。关键不是工具多酷而是你要清楚自己的文档里有多少种格式每种格式用什么策略拆拆出来的块是否保留了足够的结构信息。5.4 检索不出结果时先排查这三个地方本地RAG跑起来之后最常见的故障就是查不到东西。我自己的排查顺序固定如下基本能覆盖八成问题嵌入模型是否一致建库和查询用的是不是同一个模型向量维度是否对得上。切分是否合理块太大导致语义混杂块太小导致上下文不全。先用一条明确的问题去向量库里人工看Top5返回的块一眼就能看出问题出在切分还是检索。是否走了混合检索纯向量检索对精确术语不友好比如型号、编号这类关键词BM25关键词检索往往更准。两条路都走再做融合召回率会有质变。这套排查顺序看起来朴素但效率极高。不要一上来就怀疑模型能力不够大部分RAG效果差根源都在检索链路而不是生成链路。6. 检索质量决定回答质量RAG瓶颈的识别与优化清单6.1 瓶颈一召回不准答案必然跑偏RAG的上限不是大模型决定的是检索决定的。检索召回的内容不对再强的模型也只能基于错误资料作答这比不检索还危险。我实测过的项目里第一次跑通的RAG答案相关率通常只有六成上下剩下四成问题都出在该找到的没找到或者找到的是干扰项。优化手段里见效最大的两项是混合检索和重排序。混合检索就是同时跑向量检索和BM25关键词检索各自取Top结果后合并去重。重排序则是用专门的rerank模型对初选结果按相关性重新打分把最相关的几条顶到前面。这两步加上之后检索质量一般会有肉眼可见的提升。6.2 瓶颈二上下文塞爆与噪音干扰检索到的块并不是越多越好。上下文窗口就那么大塞进去的无关信息越多大模型被带偏的概率越大。Top-K设成5往往比设成10回答更精准。额外的优化手法是上下文压缩把检索到的长块先用大模型提取关键句再把压缩后的内容拼进提示词既能控制Token成本也能减少干扰。另外要强调一个容易被忽略的点给知识块打元数据是改善生成质量最快的作弊手段。比如每块带上来源文档、章节标题、更新时间检索后把这些元数据一并拼进提示词。大模型知道了这段资料来自2025版操作手册第三章它的回答自然会更精确、更谨慎。6.3 瓶颈三没有评估就不知道坏在哪里很多团队做完RAG就扔上线回答质量全靠感觉。这是最大的瓶颈。RAG不是装完就结束的东西它是需要迭代的链路而迭代的前提是你知道哪一环出了问题。我的做法是准备一个固定的评测集50到100条真实用户问题标注好标准答案和应该命中的文档。每次改动后跑一遍统计检索命中率和答案正确率。工具层面可以用开源的RAGAS框架它能自动评估生成答案的事实正确性、忠实度和上下文相关性。但再好的自动指标也要配合人工抽查——把检索返回的结果拉出来看一看往往能发现指标反映不出来的问题。6.4 优化到位的参考状态经过两三轮迭代一个健康的RAG系统应该有这些表现九成以上测试问句能召回正确文档答案里每条关键事实都能对应到知识库原文知识库中未找到相关内容这个拒绝回答被触发时基本准确无误。达到这个状态后再去做模型侧优化才有意义。我在实际项目里最大的体会是RAG和大模型的关系更像是数据管道和发动机的关系。发动机再好管道里流的全是脏水输出也好不到哪去。所以别把精力全花在挑模型上多花时间打磨文档切分、检索策略和评测闭环投资回报率高得多。最后分享一个屡试不爽的小习惯每改一次检索逻辑都把调整前后的Top5返回结果截图对比放进项目的复盘文档里。这比任何指标都直观也是你在团队里说服同事这次改动有效时最有力的证据。