2023年，一个内部知识库项目上线。团队把文档切成块，扔进向量数据库，用户问什么就搜什么。前两周一切正常，第三周开始崩：有人问"远程办公政策"，系统返回了2021年的旧版；有人问"报销流程"，拿到的却是财务系统的登录指南。
这不是模型的问题。OpenAI的工程师后来复盘：90%的RAG故障，根因都在检索管道，而非大模型本身。
检索失败只有四种死法：太浅（搜到了但不对）、太窄（只搜了一个数据源）、太脆（换个问法就崩）、太散（答案需要拼两个事实，但系统只能拿一个）。过去两年，整个行业都在围着这四个问题打补丁，攒出了21种设计模式。
这篇文章按时间线还原RAG的完整进化。从能用的60分，到靠谱的90分，每一层解决什么问题、引入什么代价，都会摊开讲。
第一层：基础模式，60-70分的及格线
Pattern 01 — 朴素RAG（Naive RAG）。所有人都是从这里开始的：文档分块、嵌入向量库、相似度搜索、塞进提示词。内部知识库或快速原型，这个方案够用。它的天花板也很明显：词汇不匹配直接漏检，多步推理完全不会，跨文档关联想都别想。
Pattern 02 — 多查询扩展（Multi-Query）。针对"太浅"问题的第一个补丁。系统不再只搜用户原话，而是自动生成多个查询变体。用户问"远程办公政策"，系统同时搜"居家办公规定""WFH规则""弹性工作安排"。召回率上去了，延迟也上去了——每次查询变成N次向量搜索。
Pattern 03 — 查询重写（Query Rewriting）。比多查询更精细。用大模型把用户问题改写成更适合检索的形式。口语化的"咋报销"变成正式的"差旅费用报销流程"，指代消解把"这个政策"还原成具体名称。代价：多一次LLM调用，百毫秒级延迟。
Pattern 04 — 假设文档嵌入（HyDE, Hypothetical Document Embeddings）。解决"用户问题太短，文档太长"的匹配困境。系统先让LLM生成一个假想的理想答案，用这个答案去搜，而不是用原始问题。学术文献检索场景效果显著，但生成假设答案本身需要算力，且假设可能跑偏。
Pattern 05 — 重排序（Reranking）。向量搜索拿回的Top-K只是"大概相关"，重排序用更精细的模型（通常是交叉编码器）重新打分，把真正相关的往前排。延迟增加30-100毫秒，准确率提升15-25%，大多数生产系统会在这里停一下，权衡投入产出。
第二层：高级模式，解决"太窄"和"太脆"
Pattern 06 — 多路检索（Multi-Retriever）。不再只搜向量库，同时查关键词索引、图数据库、结构化表格。企业场景里，答案可能藏在CRM记录、PDF扫描件、Slack消息三个地方。挑战在于：不同来源的结果怎么融合打分？简单归一化往往失效，需要训练专门的融合模型。
Pattern 07 — 递归检索（Recursive Retrieval）。先搜大纲，再钻细节。法律文档场景：先定位到"第三章 违约责任"，再检索该章节下的具体条款。实现需要文档有清晰的层级结构，且每次递归都增加延迟。
Pattern 08 — 上下文压缩（Contextual Compression）。检索回来的块太长，塞进提示词容易超窗口、费token。用小型模型把每个块压缩成摘要，只保留和问题相关的部分。LangChain和LlamaIndex都内置了这个功能，但压缩本身可能丢失关键细节。
Pattern 09 — 父文档检索（Parent Document Retrieval）。解决"块太小丢上下文，块太大检索不准"的矛盾。检索时用小粒度块（比如256 token），但返回时带上完整的父文档（比如整页或整节）。向量库需要维护父子关系索引，存储成本上升。
Pattern 10 — 句子窗口检索（Sentence Window Retrieval）。和父文档类似，但粒度更细。检索到具体句子，返回时带上前后N句的上下文。适合精确引用场景，比如医疗指南或法规条文。
Pattern 11 — 自动合并检索（Auto-Merging Retrieval）。更智能的上下文组装。系统检索多个相关块后，自动判断哪些块在原文中是相邻的，合并成连续段落。避免"第3页后半句+第5页前半句"这种割裂的上下文。
Pattern 12 — 多模态检索（Multimodal RAG）。处理PDF里的图表、产品手册里的截图、视频字幕。需要把图像也嵌入到向量空间，CLIP和类似模型成为基础设施。2024年后，这个模式从"高级功能"变成"基础能力"。
第三层：Agentic模式，系统开始自己做决定
Pattern 13 — Self-RAG。系统不再盲目检索，而是先判断：这个问题需要查资料吗？检索回来的内容有用吗？生成答案后还要再检查：这个答案有依据吗？每个决策点都是一个二元分类，用小模型快速完成。延迟增加，幻觉率下降。
Pattern 14 — Corrective RAG。检索结果质量不达标时，自动触发修正流程：改写查询、换数据源、或者坦诚告知用户"找不到相关信息"。关键设计：怎么定义"质量不达标"？通常用检索结果与问题的相关性分数阈值，但阈值调不好会误伤。
Pattern 15 — 工具使用RAG（Tool Use RAG）。系统不只会检索文档，还能调用计算器、查天气、跑数据库查询。从"问答系统"进化成"能行动的助手"。需要定义工具描述、参数模式、错误处理，工程复杂度陡增。
Pattern 16 — 规划RAG（Plan-and-Execute RAG）。复杂问题拆解成子任务。用户问"对比A和B两款产品的售后政策"，系统先规划：1）查A的售后政策 2）查B的售后政策 3）对比差异 4）生成回答。每一步都可能触发不同的检索策略。
Pattern 17 — ReAct（Reasoning + Acting）。把推理过程显式化。系统输出"想法→行动→观察→下一步想法"的链条，用户能看到系统为什么检索这个、为什么那样回答。可解释性提升，但输出长度增加，成本上升。
第四层：图与结构，解决"太散"
Pattern 18 — 图RAG（Graph RAG）。把文档解析成知识图谱：实体、关系、属性。检索时不仅找文本相似，还能沿着关系游走。"张三的直属领导是谁"→找到"张三"节点→找"汇报给"关系→得到答案。微软2024年开源的GraphRAG实现让这个模式大规模可用，但图谱构建成本高昂。
Pattern 19 — 层次化索引RAG（Hierarchical Index RAG）。文档摘要→章节摘要→段落→句子，多层索引。检索时自顶向下，先定位到相关章节，再深入细节。适合超大规模文档库，比如百万页的技术规范。
Pattern 20 — 社区检测RAG（Community Detection RAG）。图RAG的进阶。先用算法识别文档中的"社区"——紧密相关的主题簇。检索时先定位社区，再在社区内细搜。降低大图上的搜索复杂度，提升跨文档关联的召回。
第五层：自适应与进化
Pattern 21 — 自适应RAG（Adaptive RAG）。系统根据问题类型，动态选择检索策略。简单事实性问题→朴素RAG快速回答；复杂分析性问题→启动Plan-and-Execute；需要实时数据→调用工具。路由决策本身可以用小模型训练，也可以手写规则。
这21种模式不是"21个可选功能"，而是"5个进化阶段"。每个阶段都在修补前一阶段的缺陷，同时引入新的权衡。多查询提升召回但增加延迟，图RAG解决关联但构建昂贵，Agentic增强能力但调试困难。
2024年下半年，一个趋势变得清晰：没有团队在用单一模式。生产级系统通常是3-5种模式的组合，用路由层动态调度。LangChain的"智能体执行器"、LlamaIndex的"路由器"、以及各家的自定义编排层，本质上都是在做同一件事——根据问题特征，选择检索策略的组合。
另一个趋势是评估体系的成熟。RAGAS、ARES、TruLens等框架提供了检索准确率、答案相关性、上下文召回率等指标。没有评估，优化就是盲人摸象。2023年大家还在争论"哪种嵌入模型更好"，2024年的共识是：嵌入模型差异<5%，检索架构差异>30%。
回到开头的那个内部知识库项目。团队最终采用了多查询+重排序+父文档检索的组合，把准确率从62%拉到87%。没有用到任何Agentic或图模式——不是不想，是问题复杂度还没到那一步。
你的RAG系统现在卡在哪一层？是还在用朴素RAG硬撑，还是已经在调Self-RAG的决策阈值，又或者正在评估Graph RAG的构建成本？
热门跟贴