10 种 RAG 模式
过去一年里，我至少听了十几次"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 这样的向量数据库里，通过近似最近邻搜索（ANN，Approximate Nearest Neighbor），在毫秒级别就能找到和任意查询语义最相似的那些块。
10 种 RAG 模式
1. 简单 RAG（Naive RAG）
查询进来，做嵌入，召回最匹配的块，把块拼到提示词里，模型给答案。
对于不少场景，比如一个整理得很好的内部 wiki，或者文档清晰的客服机器人，这真的就够用了。
理解简单 RAG 的真正价值，未必是要一直用它，而是要清清楚楚知道它没干什么，而这，基本也就是推动后面所有模式出现的动力。
2. 带记忆的 RAG（RAG with Memory）
简单 RAG 基本上是个健忘症患者。每个查询都落在完全的真空里。
你问它"能展开说说第二点吗？"，系统压根不知道第二点是什么，在它看来，根本就没有过第一点。
加上记忆（memory），意味着维护一条持续跟进对话的线索，可能是一份摘要，可能是历史记录，也可能是对已聊内容的提炼，并把它揉进每一次的检索查询里。这时候，追问才真的有用，代词才有了指代对象，整个体验才开始像真正的对话，而不是一串互不搭界的查询。
3. 分支式 RAG（Branched RAG）
有些问题，表面上是一个问题，实际上是好几个问题套了件大衣。
"我们上个季度亚太区的客户获取成本跟北美比怎么样，这对我们 Q3 的预算分配意味着什么？"这可不是一个检索任务，这至少是三到四个，需要不同的文档集、不同类型的推理，然后还得把结果揉成一个连贯的答案。
分支式 RAG 会先把问题拆开。子查询并行走在不同检索通道里，结果回来后先整合到一块儿，再拿去生成。
当然比简单检索更耗时，这点没得说。但对于真正复杂的多段式问题，质量上的提升通常太明显。
4. HyDE（Hypothetical Document Embeddings，假设性文档嵌入）
用户的提问，和能回答它的那份文档，措辞常常差了十万八千里。
用户问得口语化，文档写得正式。在嵌入空间里一比对，结果就不准，因为两段文本表面上看起来根本不像，哪怕语义是相通的。
在检索任何东西之前，你先让模型生成一份"假设答案"，不是真答案，只是一份看着挺像那么回事、措辞风格跟你的文档库差不多的答案。然后拿这份假设答案当检索查询，而不是原始提问。
你现在干的，是去搜和一份假想答案相似的真实文档，而不是搜和问题相似的文档。对齐效果好得出奇，召回的块切题得多。对那些用词高度专业化的技术类或垂直领域文档库，HyDE 的效果有时出乎意料地好。
5. 自适应 RAG（Adaptive RAG）
不是所有情况都需要检索。"埃菲尔铁塔哪年建的"这类问题真用不上向量数据库，"法国首都是哪"就更不用说了。对所有查询无差别检索，浪费算力不说，有时还会引入无关上下文，把答案质量反而拉低了。
自适应 RAG 在检索层前面加了个路由（routing）步骤。在任何搜索发生之前，先做个轻量判断：这个查询到底需不需要外部文档？还是说模型靠自己脑子里的知识就能答得不错？然后系统据此走不同路由。
对那些要处理五花八门查询的高吞吐企业系统，这个路由层能实实在在地降成本、降延迟。而且这也意味着你的检索管线只有在真正值得跑的时候才跑。
6. 纠错式 RAG（CRAG，Corrective RAG）
检索偶尔是会失手的，这没法完全避免。索引有死角，查询有些歧义，排最前面的几条结果可能也就在正确答案边上蹭了蹭，但并不真的是。标准 RAG 基本察觉不到这些，它只会把自己召回来的东西原样喂给模型，然后仿佛一切都很好地往下走。
CRAG 在检索和生成之间塞了一道质量检查。召回来的文档会被打一个相关性分：分高，万事大吉，正常往下走；分低，系统会介入干预，要么重新措辞查一遍，要么退而求其次，通过网络搜索补充来源。
你就把它理解成带自我纠错机制的 RAG。模型基于垃圾输入一本正经地胡说的概率大大降低了，因为那些垃圾输入在送到模型嘴边之前就被截住了。
7. 自审式 RAG（Self-RAG）
这个在理念上其实很有意思。它不加外部检查，而是靠训练让模型学会审视自身。
生成的过程中会织入一些特殊的 token，有点像内置的自我追问，让模型时不时停下来琢磨：我在这儿真的需要去查吗？我刚刚查到的东西真的有关吗？我给出的这个答案，跟我找到的证据对得上吗？
模型某种程度上成了自己的审计师。当它不该那么确定的时候，就更可能主动说出"我对这个其实不太有把握"；自己的推理链出了错，也更可能在把答案吐出来之前先自己抓到。这肯定有代价，因为这种方法需要更精细的训练，推理也多了些复杂性。但凡是风险高的场景，这种校准能力的提升通常都是值得的。
8. Agent RAG（Agentic RAG）
到了这里，RAG 就不太像一条管道（pipeline）了，而更像一个过程。
在 Agent RAG 里，模型不再只是检索完就生成。它会一步一步决定下一步做什么：可能先查一下向量库，发现结果有点稀薄，就调一个外部 API 补点数据，再对着找到的东西琢磨一下，意识到自己需要另一份不同的文档，于是再去查，最后才把所有东西综合出一个答案——全都在同一次查询里完成。
模型本质上是个调度中心（orchestrator）：它行动、观察、然后根据沿途的发现调整自己。
对于真正开放式的任务，这就是正确的架构：复杂的研究类查询、多步骤流程、任何需要动态决策而非固定"先检后答"序列的场景。它搭建起来更复杂，调试起来更头疼，本质上可预测性也差一些。但用在恰当的场景上，说实话，其他方案跟它比，差得不是一星半点。
9. 多模态 RAG（Multimodal RAG）
你公司的知识可不只是存在纯文本文件里。它还在那些幻灯片里，里面的图表讲着项目符号没讲出的故事；它在架构图里；它在那些数字之间的关系比数字本身还重要的财务报表里；它还在那些靠标签指向某个组件才说得清的技术原理图里。
标准 RAG 碰到这些，要不就当成一堆乱码，要不就当数据不存在。多模态 RAG 把这些当成值得认真检索的信息。
借助视觉语言模型（VLM，Vision-Language Model），图表、表格、图片可以和文本一起被嵌入进去。检索可以把一张图就当成一张图返回来。模型直接解读视觉内容，而不是通过某种严重降级的文字近似物去猜。企业知识正越来越多地以视觉形态存在，这件事就不再是锦上添花，而正在变成你真正需要的东西。
10. 图谱 RAG（Graph RAG）
对任何检索系统来说，最难啃的一类问题就是：问关系。
“现在正在被审计的那份供应商合同，当初是谁批的？”“上个月造成故障的那个服务，到底归哪个团队？”"跟这个客户投诉有关的那条政策，v2 到 v3 期间到底改了什么？"这类问题，绝无可能靠找相似文本来回答。它们需要去顺着实体之间的联系走——人、项目、文档、事件，而这些联系散落在几十上百个独立来源里。
图谱 RAG 在向量索引（vector index）旁边建了一个知识图谱（knowledge graph）：实体被映射出来，关系被追踪下来。当一个查询需要沿着一条关系链去走时，检索就去遍历图谱，而不是仅仅找那些嵌入向量相近的东西。
对于任何涉及组织复杂度、合规、法务，或者系统间有大量相互依赖的场景，图谱 RAG 打开了一整类其他模式根本摸不着边的问题。
架构选择
没人会只单用其中一种模式。
一个真实的企业 AI 系统，往往是组合体：前面用自适应 RAG 做路由，大部分查询走简单 RAG，碰上复杂分析问题就切到分支式 RAG，CRAG 再作为质量关卡贯穿始终。要是一个系统重度依赖文档，可能还得把多模态 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时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～