过去一年里我至少听了十几次RAG 已死的论调。“RAG 过时了。现在上下文窗口context window那么大直接把所有东西塞进提示词prompt不就完了”每次听到这种话我心里想的都是行那咱们来稍微推敲一下这套逻辑。假设你公司有十年的内部文档法律合同、运维手册、客户支持记录、改了四十版的产品规格书。你打算每次查询都把这些全部塞进去成本得多高延迟得多大等模型被海量无关信息淹没、开始胡说八道的时候这几乎是必然的你打算怎么办RAG 没死从来就没死过。真实情况是那些 2023 年试过它的人随便搭了个粗糙的检索流程效果平平然后就弃了。他们把一套不成熟的实现当成了这个思路本身有缺陷。但这两者根本不是一回事。思路本身是站得住脚的只是实现方案终于慢慢跟上来了。上下文窗口我先替直接上超大上下文窗口派把话说全因为这个立场确实值得认真回应。如今顶尖模型单次上下文能塞进数百万 token。如果你能把整个知识库丢进去检索这一步就全省了。不用切块、不用嵌入、不用向量数据库就一次性把所有东西放进去更简单不是吗但这在生产环境中站不住脚原因有三其一成本叠加得飞快。推理成本和处理掉的 token 数成正比。如果每次查询都扔两百万 token而绝大多数查询真正需要的只有两千 token那你等于每请求一次就多花了一千倍的钱。在规模化场景下这可不是什么舍入误差这是决定产品能活得下去还是悄悄失血而死的分水岭。其二太慢了。处理几百万 token 是需要时间的。那些指望两秒内出结果的用户等上六秒八秒体验就会急转直下。这不光是工程问题更是产品问题。其三它其实会让模型变笨而不是变聪明。上下文里塞满无关信息时模型表现会变差。有效信号被稀释注意力被摊薄。有一个真实存在的现象叫迷失在中间lost in the middle意思是模型会系统性低估出现在长上下文中间那部分信息的权重。你不是给了模型更多素材而是给了它更多需要费力筛查的噪音。精准检索恰好找到对的那部分上下文而不是把所有可能的东西都丢过去是一种优势不是权宜之计。切块与嵌入在聊 RAG 演化出的那十种模式之前得先弄清楚两个决定任何 RAG 系统能不能跑起来的基础组件。切块策略Chunking每份进入检索系统的文档都必须被切成可检索的小块chunk。策略很关键而绝大多数早期的 RAG 实现都做错了。最简单的切块方式是按固定字符数或 token 数截断文本。简单、快。但它也经常把完整的句子分割开把结论和支撑它的论据断开切出来的块在语义上失去了原本的完整性。推荐的做法是语义切块semantic chunking不用固定的边界去切而是在主题转换、文档从一个想法自然过渡到另一个想法的地方下刀。这样切出来的块内部是连贯的、语义完整的检索出来的内容才能真正告诉模型一些有用的东西。层级式切块hierarchical chunking也叫从小到大切块则更精细一步。先用小而精的块来存储小块够具体嵌入模型embedding model能把它们和查询精确匹配。但每个小块都带一个指针指向它来自哪个章节、哪份文档、哪个更宽泛的段落。当小块被检索到之后系统会往外扩展到父级上下文再一并交给模型。这样一来你既拿到了小块检索的精确又拥有大块上下文的连贯。嵌入模型与向量数据库Embedding Model Vector Database文档切好块后得把它们转成向量vector一种稠密的、数字化的语义表征这样才能用数学方法与进来的查询做比对。嵌入模型的好坏决定了检索质量的天花板 OpenAI 的text-embedding-3-large和开源的BGE-large它们捕捉语义细节的能力都足够强能应付那些用词和目标文档不完全一致的查询。这些向量存在像 Pinecone、Weaviate、pgvector、Qdrant 这样的向量数据库里通过近似最近邻搜索ANNApproximate Nearest Neighbor在毫秒级别就能找到和任意查询语义最相似的那些块。10 种 RAG 模式1. 简单 RAGNaive RAG查询进来做嵌入召回最匹配的块把块拼到提示词里模型给答案。对于不少场景比如一个整理得很好的内部 wiki或者文档清晰的客服机器人这真的就够用了。理解简单 RAG 的真正价值未必是要一直用它而是要清清楚楚知道它没干什么而这基本也就是推动后面所有模式出现的动力。2. 带记忆的 RAGRAG with Memory简单 RAG 基本上是个健忘症患者。每个查询都落在完全的真空里。你问它能展开说说第二点吗系统压根不知道第二点是什么在它看来根本就没有过第一点。加上记忆memory意味着维护一条持续跟进对话的线索可能是一份摘要可能是历史记录也可能是对已聊内容的提炼并把它揉进每一次的检索查询里。这时候追问才真的有用代词才有了指代对象整个体验才开始像真正的对话而不是一串互不搭界的查询。3. 分支式 RAGBranched RAG有些问题表面上是一个问题实际上是好几个问题套了件大衣。我们上个季度亚太区的客户获取成本跟北美比怎么样这对我们 Q3 的预算分配意味着什么这可不是一个检索任务这至少是三到四个需要不同的文档集、不同类型的推理然后还得把结果揉成一个连贯的答案。分支式 RAG 会先把问题拆开。子查询并行走在不同检索通道里结果回来后先整合到一块儿再拿去生成。当然比简单检索更耗时这点没得说。但对于真正复杂的多段式问题质量上的提升通常太明显。4. HyDEHypothetical Document Embeddings假设性文档嵌入用户的提问和能回答它的那份文档措辞常常差了十万八千里。用户问得口语化文档写得正式。在嵌入空间里一比对结果就不准因为两段文本表面上看起来根本不像哪怕语义是相通的。在检索任何东西之前你先让模型生成一份假设答案不是真答案只是一份看着挺像那么回事、措辞风格跟你的文档库差不多的答案。然后拿这份假设答案当检索查询而不是原始提问。你现在干的是去搜和一份假想答案相似的真实文档而不是搜和问题相似的文档。对齐效果好得出奇召回的块切题得多。对那些用词高度专业化的技术类或垂直领域文档库HyDE 的效果有时出乎意料地好。5. 自适应 RAGAdaptive RAG不是所有情况都需要检索。埃菲尔铁塔哪年建的这类问题真用不上向量数据库法国首都是哪就更不用说了。对所有查询无差别检索浪费算力不说有时还会引入无关上下文把答案质量反而拉低了。自适应 RAG 在检索层前面加了个路由routing步骤。在任何搜索发生之前先做个轻量判断这个查询到底需不需要外部文档还是说模型靠自己脑子里的知识就能答得不错然后系统据此走不同路由。对那些要处理五花八门查询的高吞吐企业系统这个路由层能实实在在地降成本、降延迟。而且这也意味着你的检索管线只有在真正值得跑的时候才跑。6. 纠错式 RAGCRAGCorrective RAG检索偶尔是会失手的这没法完全避免。索引有死角查询有些歧义排最前面的几条结果可能也就在正确答案边上蹭了蹭但并不真的是。标准 RAG 基本察觉不到这些它只会把自己召回来的东西原样喂给模型然后仿佛一切都很好地往下走。CRAG 在检索和生成之间塞了一道质量检查。召回来的文档会被打一个相关性分分高万事大吉正常往下走分低系统会介入干预要么重新措辞查一遍要么退而求其次通过网络搜索补充来源。你就把它理解成带自我纠错机制的 RAG。模型基于垃圾输入一本正经地胡说的概率大大降低了因为那些垃圾输入在送到模型嘴边之前就被截住了。7. 自审式 RAGSelf-RAG这个在理念上其实很有意思。它不加外部检查而是靠训练让模型学会审视自身。生成的过程中会织入一些特殊的 token有点像内置的自我追问让模型时不时停下来琢磨我在这儿真的需要去查吗我刚刚查到的东西真的有关吗我给出的这个答案跟我找到的证据对得上吗模型某种程度上成了自己的审计师。当它不该那么确定的时候就更可能主动说出我对这个其实不太有把握自己的推理链出了错也更可能在把答案吐出来之前先自己抓到。这肯定有代价因为这种方法需要更精细的训练推理也多了些复杂性。但凡是风险高的场景这种校准能力的提升通常都是值得的。8. Agent RAGAgentic RAG到了这里RAG 就不太像一条管道pipeline了而更像一个过程。在 Agent RAG 里模型不再只是检索完就生成。它会一步一步决定下一步做什么可能先查一下向量库发现结果有点稀薄就调一个外部 API 补点数据再对着找到的东西琢磨一下意识到自己需要另一份不同的文档于是再去查最后才把所有东西综合出一个答案——全都在同一次查询里完成。模型本质上是个调度中心orchestrator它行动、观察、然后根据沿途的发现调整自己。对于真正开放式的任务这就是正确的架构复杂的研究类查询、多步骤流程、任何需要动态决策而非固定先检后答序列的场景。它搭建起来更复杂调试起来更头疼本质上可预测性也差一些。但用在恰当的场景上说实话其他方案跟它比差得不是一星半点。9. 多模态 RAGMultimodal RAG你公司的知识可不只是存在纯文本文件里。它还在那些幻灯片里里面的图表讲着项目符号没讲出的故事它在架构图里它在那些数字之间的关系比数字本身还重要的财务报表里它还在那些靠标签指向某个组件才说得清的技术原理图里。标准 RAG 碰到这些要不就当成一堆乱码要不就当数据不存在。多模态 RAG 把这些当成值得认真检索的信息。借助视觉语言模型VLMVision-Language Model图表、表格、图片可以和文本一起被嵌入进去。检索可以把一张图就当成一张图返回来。模型直接解读视觉内容而不是通过某种严重降级的文字近似物去猜。企业知识正越来越多地以视觉形态存在这件事就不再是锦上添花而正在变成你真正需要的东西。10. 图谱 RAGGraph RAG对任何检索系统来说最难啃的一类问题就是问关系。“现在正在被审计的那份供应商合同当初是谁批的”“上个月造成故障的那个服务到底归哪个团队”跟这个客户投诉有关的那条政策v2 到 v3 期间到底改了什么这类问题绝无可能靠找相似文本来回答。它们需要去顺着实体之间的联系走——人、项目、文档、事件而这些联系散落在几十上百个独立来源里。图谱 RAG 在向量索引vector index旁边建了一个知识图谱knowledge graph实体被映射出来关系被追踪下来。当一个查询需要沿着一条关系链去走时检索就去遍历图谱而不是仅仅找那些嵌入向量相近的东西。对于任何涉及组织复杂度、合规、法务或者系统间有大量相互依赖的场景图谱 RAG 打开了一整类其他模式根本摸不着边的问题。架构选择没人会只单用其中一种模式。一个真实的企业 AI 系统往往是组合体前面用自适应 RAG 做路由大部分查询走简单 RAG碰上复杂分析问题就切到分支式 RAGCRAG 再作为质量关卡贯穿始终。要是一个系统重度依赖文档可能还得把多模态 RAG 叠上去处理视觉内容把图谱 RAG 拉进来处理关系型问题。语义切块、足够强的嵌入模型、靠谱的向量存储必须扎扎实实地打牢上面那些花活才可能真正跑起来。糟糕的数据准备没法靠精巧的架构来弥补。那些用惨痛教训才学到这点的团队往往花好几个月去调检索最后发现从头到尾都是切块的问题。而那些把 RAG 当成 2023 年过气潮流的人常常在用另一套工具干着本质上一样的事只不过少了这套方法论和严谨性然后纳闷为什么自己的 AI 产品一过了演示环节就老感觉不那么靠谱。未来RAG 变得成熟是因为底层的那个问题从来就没有消失过。你需要你的 AI 系统处理最新的、私有的、特定领域的信息。你需要它们说的话有根有据而不是仅凭模型训练时咽下去的那点东西胡诌。你需要它们在真正有意义的规模下还能把成本和响应速度都控制住。这些需求不会因为上下文窗口变大就消失。甚至恰恰相反当企业开始把更关键的业务流程押在 AI 上大家对可靠性的要求只会越来越高对那种自信满满的幻觉的容忍度只会越来越低。对能追责、能审计的事实依归的需求正变得越来越紧迫而不是相反。RAG 就是对这个问题给出的回答。只不过它早已不是两年前的那个 RAG 了。现在它有十种模式再过两年可能就是二十种。但它的核心思想让模型在开动脑筋之前先踩在召回来的、有关的、最新的信息上。这十种模式从入门必须搞定的基础款到真正精巧复杂的架构全都在这里了。如果你正用其中任何一种做开发你能做的最好投资还是那件看起来最不性感的事把切块策略弄对选好一个强大的嵌入模型让一切从一个扎实的地基上长出来。说真的只要这步踏实了后面所有事情都会容易得多。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】