1. 为什么普通RAG扛不住复杂问题先认清瓶颈在哪过去半年我一直在和检索增强生成RAG系统打交道最有感触的一点是普通RAG上线容易做好很难。很多人以为把文档切块丢进向量库检索之后拼到Prompt里就完事了结果一问到“去年Q3各区域销售漏洞对比”这类需要多文档综合的问题答案就开始东拼西凑甚至直接幻觉。本文要拆解的正是业界在朴素RAG基础上沉淀出来的7种高级RAG架构每种架构对应哪一类问题、原理是什么、实现时要注意什么我会尽量按实际使用的经验来讲而不是给一堆名词解释。这篇内容适合正在做RAG项目、已经跑通Demo但效果不理想的AI开发者从头搭管线的人也能当索引清单来用。1.1 朴素RAG的四个典型失败场景先想一个最简单的RAG流程把文档切成几百个Token的块做Embedding存进向量库用户提问时把问题Embedding后召回Top-5块最后把这些块塞进Prompt让大模型生成答案。这套流程跑Demo很好一旦放到真实业务里问题就暴露得很快。我做过一个某公司内部文档问答项目场景是让员工直接查制度、报销、IT流程。朴素RAG上线后统计下来主要有四类失败召回不全。用户问“如果出差回来发票弄丢了怎么报销”Embedding检索只匹配到“报销流程”相关的片段但真正讲“发票丢失处理”的那一段因为关键词和问题差异太大排在了第12位根本没进Top-5于是模型只能照着别的流程硬编答案。噪声过多。查询命中了一个包含“报销”但主要内容是别的流程的大段落前缀部分与问题无关大模型被带偏回答里混入了别部门的流程细节。你会发现Top-5里真正有用的可能只有一两个其余全是干扰项。粒度失衡。整页文档切块后有的块太小缺上下文比如只切到一句“请参照附件”没有附件描述有的块太大涵盖多个主题检索出来的块既不聚焦也不完整。粒度一旦失衡召回准了也没用因为拿到的内容本身就残缺。多跳问题。有些问题需要把两三份文档的信息串起来比如“某项目的合同期和付款条件是否匹配”单次检索根本找不到同时包含合同期和付款条件的片段模型只能猜。这四类问题就是后面七种架构要逐一处理的对象。1.2 高级RAG的分层拆解法既然瓶颈分散在查询、索引、检索、生成四个环节那解法也应该分层对应。我把这套思路总结成一个简单框架后面讲每种架构时都会往这个框架里放查询侧想办法改进用户的原始查询生成多个变体、把查询转成假答案让检索器更容易命中目标多查询检索、HyDE、RAG-Fusion的查询改写部分都属这一类。索引侧调整切块策略和索引结构同时兼顾召回粒度和上下文完整性父子文档切块是这里最典型的手段。检索后处理检索完不直接送生成器先做重排序和上下文压缩把Top-20里的东西筛成Top-5、压缩成精华片段这一步直接决定最终答案质量的上限。生成侧让模型或一个额外评估器检查检索质量判断“该不该用这些文档”必要时触发纠错或知识精炼这就是自省式与纠正式RAG做的事。系统侧把单个检索动作升级成多步决策过程让模型自己决定查什么、换什么查询、要不要再查一轮这就是Agentic RAG的范畴。这样拆解之后你再看网上一堆RAG名词就不会觉得零散了。它们本质上都是针对上述某几个环节的定向补丁彼此之间不是竞争关系而是可以叠加的关系。下一章我把七种架构按这个分层逻辑一个个拆开。2. 七种高级RAG架构逐一拆解原理、位置与实现要点这七种架构并不互斥实际项目里经常两三种叠着用。为了理解方便我按“查询侧 → 索引侧 → 检索后处理 → 生成侧 → 系统侧”的顺序来拆这样最符合问题出现的先后逻辑。2.1 多查询检索用多个问题视角弥补单个查询的盲区多查询检索Multi-Query Retrieval的原理一句话就能说清让大模型把用户问题改写成多个不同的查询分别检索后再合并去重。它解决的是用户提问和文档语言表达之间的语义鸿沟。用户不一定知道知识库里的关键词比如他问“报销单据弄丢了”文档里写的是“原始凭证遗失处理”两种说法在向量空间里未必足够接近但大模型知道它们是同一件事。让大模型基于原问题生成3到5个变体查询比如“原始凭证遗失怎么办”“发票丢失报销流程”“报销票据遗失说明”就等于用不同词面把同一意图打了一遍召回率自然上来了。实现时我建议变体数量控制在3到5条。太多会让成本翻倍而且会出现大量重复结果太少又起不到扩充召回的作用。我常用的一种做法是让大模型输出JSON列表逐条解析过滤掉与原问题语义完全重复的变体再做一次简单的去重最后合并各路召回结果。多查询检索最直接的效果是召回率明显上涨副作用是后续重排序的压力变大因为它会把更多相关结果捞上来也会把更多无关结果带上来所以它几乎一定要和重排配合使用。2.2 HyDE先写一个“假设答案”再拿它去检索Hypothetical Document EmbeddingsHyDE假设文档嵌入的核心动作是先用大模型生成一个基于问题的假设性回答文档再用这个假答案的Embedding代替问题去检索。为什么这样能有效Embedding模型把问题和文档映射到向量空间时问题通常很短、很口语化而文档很长、很正式两者在向量空间里天然有一段距离。HyDE相当于把问题先翻译成“文档语言”生成一个150到200词的假设回答用假回答去和文档做相似度匹配匹配到的通常就是真正包含相关内容的事实证据。这个思路在短查询场景里经常比直接Embedding问题效果更好因为假回答里包含了文档里可能出现的实词和句式。这里有个常见误区HyDE不是让模型“猜答案”而是让它“列出答案里可能包含的主题、实体和上下文”。我实际跑下来的体会是Prompt里明确写“不要给出具体事实结论只描述一份包含该问题答案的文档可能长什么样”比直接要它给答案稳定得多。HyDE的缺点是成本高每次检索前都要多一次大模型调用而且生成结果不稳定所以我会把它当作多查询检索之外的补充方案而不是完全替代。2.3 RAG-Fusion把多路结果用排名融合变成一路RAG-Fusion解决的是“单一检索器信号不可靠”的问题。向量检索擅长语义相近但可能漏掉精确关键词关键词检索命中准确却对同义词、改写毫无办法。两边都有道理那就融合。具体做法是多路并行检索一路向量检索一路关键词检索甚至把多查询检索的每一个变体都算一路。每路各自返回一个排序列表然后用RRFReciprocal Rank Fusion倒数排名融合把多个列表合并成一个最终序列。RRF公式很简单一个文档的融合得分是它在每个列表中排名的倒数再求和通常写作 score(d) Σ 1/(k rank_i(d))其中k取经验值60。这个公式最大的优点在于它只关心排名不关心不同检索器给出的原始相似度分数。向量检索打出的0.82和关键词检索打出的15.4根本没有可比性但排名是可以比的。我在某个知识库项目里用“向量关键词”双路融合后召回质量明显比单路好尤其是在专有名词、编号、型号这类场景里关键词那一路经常能给出意外惊喜。RAG-Fusion的代价是维护多路检索器每次查询的延迟也会上升但这个代价通常值得。2.4 父子文档切块检索要小的、喂给模型要大的父子文档切块Parent-Child Chunking是我强烈建议做的一步它解决的是切块粒度的矛盾。父块里面放整篇文档或一个较长的章节直接作为生成阶段的内容子块则是从父块继续拆分出的小片段用于Embedding和向量检索。原理很简单小片段语义更聚焦容易命中大片段上下文更完整送进Prompt不容易断章取义。实操上我常用子块128到200个Token、父块512到1024个Token并在父块开头保留原有标题。检索命中的是子块但返回给模型的是子块对应的父块。注意这里要求索引阶段就建立子块ID到父块ID的映射关系检索之后要把父块内容取出来替换而不是把子块直接丢给模型。这么做的代价是索引里的块数量变多了因为同一个父块会被拆成多个子块并各自生成Embedding存储和写入成本上升。另外如果父块跨了多个主题比如一整节“费用报销”包含差旅费、招待费、交通费父块照样会混入杂质所以父块也不能无脑大要尽量跟原文档的章节标题对齐。2.5 重排序与上下文压缩把召回来的噪声干掉把重排序Re-ranking和上下文压缩Contextual Compression放在一起讲是因为它们在管线里常常连续出现目标都是清理召回结果的质量。重排解决的是“Top-5不等于最相关的5个”的问题。向量检索粗召回一批候选通常是Top-20或Top-50然后把(query, doc)对交给一个交叉编码器重新打分最后按新分数取Top-5。交叉编码器能同时看到问题和文档的完整关系比双塔式的Embedding判断更准但计算量也更大所以不能替代第一轮粗召回。上下文压缩则是对进入Prompt的文档做一次“瘦身”。常见做法是把候选文档切句子只保留与问题最相关的那几句或者让大模型抽取关键段落。原因很现实向量检索返回的片段里经常混着大段无关上下文直接把整段送进Prompt大模型会“有样学样”地引用这些无关信息产生幻觉和跑题。压缩之后Prompt更短、更聚焦答案质量通常会提升一截。成本方面要注意重排序器的输入长度通常有限制一次只能处理不超过几百个Token的文本所以它更适合做第二轮精排。正确顺序是粗召回 → 上下文压缩 → 重排 → 送生成器。2.6 自省式RAG与纠正式RAG给检索结果加一层质检自省式RAGSelf-RAG和纠正式RAGCorrective RAGCRAG出场时机一样在“检索结果已经准备好”和“生成答案之前”之间插入一个质量检查环节。它们的目标很明确就是减少“模型拿错误文档硬答”的情况。Self-RAG的思路是让大模型在推理时生成反思标记判断检索文档是否相关、是否足以回答、是否被引用支持从而决定是用检索结果还是直接用内部知识。实现难度稍高因为它通常需要对模型输出格式做改造在工程上也可以退化成Prompt里显式要求模型“先检查文档相关性再回答”。CRAG则更工程化单独训练一个轻量评估器先给检索结果打一个“质量分”分数高走正常生成分数低说明这一轮检索大概率不靠谱就触发纠错——重写查询、换一个检索源、查外部权威来源实在不行就明确告诉用户“没有找到相关信息”。之后还会有一个“知识精炼”步骤从原始检索结果里提取只与问题相关的内容拼接到生成Prompt中。我测试过CRAG风格的方法最直接的变化是“无引用幻觉”明显下降。以前模型会把我给它的文档里的细节和它自己编的细节混在一起加了这个质检环节之后它要么回答有出处要么直接承认没找到不会强行编造。2.7 Agentic RAG从检索增强到智能体决策最后这个是我认为最接近未来方向的架构。Agentic RAG的核心变化是检索不再是一个固定管线里的步骤而是由大模型主导的一个决策循环。典型实现有三种形态。Router型智能体先判断问题类型决定走向量检索、关键词检索还是调用外部工具再决定要不要用检索结果。多步检索型第一轮结果不够智能体改写查询再检索一轮直到它认为自己拿到足够信息。多智能体型拆成检索Agent、审查Agent、写作Agent各司其职协作完成。第三种已经不只是“检索增强生成”更接近一个完整的Agent系统。代价是复杂度和成本都会明显上升所以必须有严格的控制限制最大轮数、记录已经查过的查询、对低分结果强制改写查询否则很容易出现同一个查询反复检索的空转。但如果你要做跨多个来源、需要多轮推理的复杂问答Agentic RAG带来的效果提升是固定管线给不了的。3. 七种架构怎么选先看痛点再看成本没有一种架构能解决所有问题选型应该先明确“当前最主要的失败场景是什么”。我把七种架构的核心信息放在表格里方便对照。架构主要解决的问题典型适用场景主要代价多查询检索查询表述与文档语言不匹配用户提问口语化、关键词变化多检索次数与Token成本增加HyDE短查询与长文档的语义鸿沟问题短、文档正式、术语多多一次LLM生成结果不稳定RAG-Fusion单一检索器信号不可靠含编号、型号、专有名词的混合场景需要维护多路检索器融合参数要调父子文档切块切块粒度不平衡长文、章节结构清晰的资料库索引量和存储开销上升重排序上下文压缩粗召回噪声过多所有候选多、Prompt长度受限的场景增加推理时延与额外模型调用自省/纠正式RAG检索结果不可信对准确性有强要求的客服、合规场景需要额外评估器阈值要调Agentic RAG固定流程无法多步推理跨文档、多轮检索的复杂问题延迟高、易循环、维护复杂表格只能覆盖一部分实际上选型还有两个很实际的角度。第一个角度是成本预算。如果你的系统对延迟和Token消耗非常敏感那就优先做索引侧和查询侧的低成本组合也就是多查询检索、RAG-Fusion、父子文档切块这些不会增加太多生成阶段的开销。重排序和CRAG会显著增加每次查询的成本Agentic RAG的Token消耗更是成倍增长所以预算有限时不要一上来就全都上。第二个角度是问题复杂度。大部分内部知识库问答停留在“单次检索能回答”的层面用前面六种架构的组合就已经能解决绝大多数问题。只有当你明确看到“需要跨文档综合、需要多轮判断”的需求时再往Agentic方向走。我个人的建议路线是先做便宜的组合多查询、父子切块、融合、重排如果仍然出现幻觉再加纠错如果问题复杂度进一步上升再加Agentic。4. 一个能跑的参考管线把多查询、融合、重排、纠错拼起来理论讲再多不如给一条可落地的参考管线。下面这段伪代码表达的是我常用的一条组合管线它把多查询、RAG-Fusion、重排序和CRAG式纠错串在了一起。# 伪代码示意组合管线方便你迁移到自己的工程里 def generate_answer(question: str): # 1. 查询侧让大模型生成查询变体 variants llm.generate_variants(question, n3) # 2. 检索侧向量检索 关键词检索多路并行 results [] for q in variants [question]: results.append(vector_store.search(q, top_k20)) results.append(keyword_store.search(q, top_k20)) # 3. 融合对多路结果做RRF fused reciprocal_rank_fusion(results, k60) # 4. 重排粗召回候选降到精排5个 candidates fused[:20] reranked reranker.rerank(question, candidates)[:5] # 5. 纠错对精排结果做质量评估 quality evaluator.score(question, reranked) if quality low_threshold: # 重写查询后再检一次仍然没有就诚实回答 reranked retrieve_with_rewritten_query(question) if not reranked: return no_support_answer(question) # 6. 压缩与生成 compressed compress_for_prompt(question, reranked) return llm.generate(question, compressed)这个管线里的每一步都可以单独摘出来用。如果你今天的场景只是“召回率不够”那从第2、3步开始就够了如果问题是“Top-5里有噪声”那就加第4步重排如果问题变成“模型总在没根据的时候硬答”第5步纠错才是关键。我把第5步放在重排之后是因为重排质量高的时候评估器对相关性的判断会更准确。如果先评估一个Top-20的粗糙结果很多相关文档会被无关文档稀释质量分反而不可信。另外第6步的压缩放在重排之后可以减少送入生成器的Token量也避免重排器处理超长文本。这个管线的吞吐量并不适合在每轮对话里都全量跑。我实际使用时会加两个开关简单问题只走第1、2、3、4、6步跳过纠错只有高价值或高风险的查询才全量走到第5步。工程上要允许自己“按需取舍”而不是把每一条查询都压到最重配置。5. 把这几种架构跑进生产后我踩过的七个坑每一章配方都很美好但真正落地时坑几乎全在细节里。我把踩过的坑按环节整理出来希望你不用再走一遍我的弯路。5.1 查询侧与索引侧的坑第一个坑出现在多查询检索的Token消耗上。我最早让大模型生成5个查询变体结果其中3个几乎一样检索出的片段也高度重复最后Prompt里全是重复内容有效信息反而少了。后来加了“语义去重”先对查询变体做相似度比较重复的只保留一个再限制变体数量为3个成本降下来召回质量没有降。这个操作看着简单省掉的Token量却非常可观。第二个坑是HyDE生成的假答案和文档风马牛不相及。我遇过一次很典型的案例问题问的是离职交接流程HyDE生成的假设文档却把入职、转岗、社保全写进去了结果检索回来一堆完全不相关的块。原因是我给了模型太多发挥空间。修正办法是把Prompt从“生成一段假设答案”改成“列出该问题答案文档可能包含的标题与要点”并限制输出在100词以内。这个改动之后召回稳定性好了很多。第三个坑是父子切块的父块设到了2048个Token。父块大确实意味着上下文完整但一个父块经常覆盖四五个子主题检索命中的子块对应父块后无关内容依旧很多整块塞进Prompt反而是灾难。我最终把父块调到512到1024个Token切块时尽量让父块跟原有章节标题对齐效果比单纯调大小好很多。5.2 融合与重排的坑第四个坑是RRF的k值不能随便拍。一开始我用k10结果排名靠前的文档把分数垄断了融合结果跟直接取某一路几乎没区别。改成k60之后各路由结果才有合理竞争局部排名靠后的文档才可能挤进前面。建议在业务数据集上跑一遍小网格搜索k通常在50到80之间取不要默认一个值就不动了。第五个坑是重排序截断把关键信息截丢了。我用的重排器最长只能处理512个Token而很多文档块超过这个长度。结果文档结尾的关键细节根本没进入重排器自然排不上去。后来我先把候选文档切成句子抽出与问题相关的句子再做压缩压缩后的短文本再进重排器情况明显改善。这个坑很容易被忽视因为重排器本身不会告诉你它截断了什么。5.3 纠错与智能体的坑第六个坑是CRAG的阈值调太高等于没装。我最初把评估分数阈值设为0.7跑了一周几乎没触发过一次纠错因为大多数召回的片段都有一些相关性分数在0.5到0.7之间晃。后来抽了200条人工标注的问题结果画出分数分布把阈值卡在分布低谷0.55附近纠错才开始正常工作。这个分布必须先画否则阈值就是个玄学。第七个坑是Agentic RAG死循环同一个查询反复查。智能体在拿不到可回答内容时很容易重新生成一个和原来几乎相同的查询继续检索。我加了两个防御全局最多5步维护一个“已检索查询集合”如果新查询和集合里的某个查询相似度超过0.9直接判定为重复强制智能体改写查询。没有这两道防御Agent在复杂场景里真的会空转到超时。6. 落地前最后补一句评测、成本与迭代顺序这一节我要讲的是容易被技术分享冷落、但真正决定成败的事情。6.1 没有评测就不该上高级RAG如果不做评测你根本分不清多查询检索到底有没有带来收益。我现在的习惯是建一个业务评估集至少100个问题按难度和类型分桶分单跳简单问题、多跳问题、含专有名词问题、明确该回答“未找到”的问题。每个问题记两件事答案正确度、是否有引用支撑。上线前跑一遍这个评估集记下基线每加一种架构再跑一遍看哪个分桶涨、哪个分桶跌、哪个分桶被牺牲。这一步能帮你挡掉大量“感觉变聪明了实际变差了”的改动。6.2 成本与延迟能省则省高级RAG的代价首先是Token和时间。多查询一次查询要多次向量检索重排要做交叉计算纠错又多一次大模型调用Agentic甚至可能要跑好几轮。省成本有几个方向对高频重复问题做缓存相同的业务问题直接命中缓存不要重复检索对简单问题直接跳过重排和纠错对查询变体数量做动态控制问题很简单就只用一个查询。延迟方面重排和压缩是最明显的瓶颈可以考虑用更轻量的模型做初筛把真正的重排留给关键场景。6.3 按这个顺序一步步往上加我建议的迭代顺序是这样的第一版只做最基础的优化换更好的Embedding模型、语义化切块、建立父子文档结构。第二版加多查询检索和RRF融合这一步对召回率的提升最明显成本也可控。第三版加重排和上下文压缩把精排质量提上来。第四版再加纠正式RAG处理幻觉最后看业务是否需要多跳推理再上Agentic RAG。每一步都回到评估集上验证再决定要不要继续往下走。最后再说一点我自己的体会七种架构不是集邮不要为了“高级”而高级。每种架构都应该对应一个具体的失败场景加上之前先问自己一句“它治的是哪个病”。我用这套方法把一个客服问答项目从严重跑题推进到了能挡住绝大多数幻觉的程度真正的体会就是把评测和迭代节奏踩稳比任何单一架构都重要。所以当你准备对现有RAG系统动手时不要一次性上七个先找一瓶药对症下药。 1. 为什么普通RAG扛不住复杂问题先认清瓶颈在哪过去半年我一直在和检索增强生成RAG系统打交道最有感触的一点是普通RAG上线容易做好很难。很多人以为把文档切块丢进向量库检索之后拼到Prompt里就完事了结果一问到“去年Q3各区域销售漏洞对比”这类需要多文档综合的问题答案就开始东拼西凑甚至直接幻觉。本文要拆解的正是业界在朴素RAG基础上沉淀出来的7种高级RAG架构每种架构对应哪一类问题、原理是什么、实现时要注意什么我会尽量按实际使用的经验来讲而不是给一堆名词解释。这篇内容适合正在做RAG项目、已经跑通Demo但效果不理想的AI开发者从头搭管线的人也能当索引清单来用。1.1 朴素RAG的四个典型失败场景先想一个最简单的RAG流程把文档切成几百个Token的块做Embedding存进向量库用户提问时把问题Embedding后召回Top-5块最后把这些块塞进Prompt让大模型生成答案。这套流程跑Demo很好一旦放到真实业务里问题就暴露得很快。我做过一个某公司内部文档问答项目场景是让员工直接查制度、报销、IT流程。朴素RAG上线后统计下来主要有四类失败召回不全。用户问“如果出差回来发票弄丢了怎么报销”Embedding检索只匹配到“报销流程”相关的片段但真正讲“发票丢失处理”的那一段因为关键词和问题差异太大排在了第12位根本没进Top-5于是模型只能照着别的流程硬编答案。噪声过多。查询命中了一个包含“报销”但主要内容是别的流程的大段落前缀部分与问题无关大模型被带偏回答里混入了别部门的流程细节。你会发现Top-5里真正有用的可能只有一两个其余全是干扰项。粒度失衡。整页文档切块后有的块太小缺上下文比如只切到一句“请参照附件”没有附件描述有的块太大涵盖多个主题检索出来的块既不聚焦也不完整。粒度一旦失衡召回准了也没用因为拿到的内容本身就残缺。多跳问题。有些问题需要把两三份文档的信息串起来比如“某项目的合同期和付款条件是否匹配”单次检索根本找不到同时包含合同期和付款条件的片段模型只能猜。这四类问题就是后面七种架构要逐一处理的对象。1.2 高级RAG的分层拆解法既然瓶颈分散在查询、索引、检索、生成四个环节那解法也应该分层对应。我把这套思路总结成一个简单框架后面讲每种架构时都会往这个框架里放查询侧想办法改进用户的原始查询生成多个变体、把查询转成假答案让检索器更容易命中目标多查询检索、HyDE、RAG-Fusion的查询改写部分都属这一类。索引侧调整切块策略和索引结构同时兼顾召回粒度和上下文完整性父子文档切块是这里最典型的手段。检索后处理检索完不直接送生成器先做重排序和上下文压缩把Top-20里的东西筛成Top-5、压缩成精华片段这一步直接决定最终答案质量的上限。生成侧让模型或一个额外评估器检查检索质量判断“该不该用这些文档”必要时触发纠错或知识精炼这就是自省式与纠正式RAG做的事。系统侧把单个检索动作升级成多步决策过程让模型自己决定查什么、换什么查询、要不要再查一轮这就是Agentic RAG的范畴。这样拆解之后你再看网上一堆RAG名词就不会觉得零散了。它们本质上都是针对上述某几个环节的定向补丁彼此之间不是竞争关系而是可以叠加的关系。下一章我把七种架构按这个分层逻辑一个个拆开。2. 七种高级RAG架构逐一拆解原理、位置与实现要点这七种架构并不互斥实际项目里经常两三种叠着用。为了理解方便我按“查询侧 → 索引侧 → 检索后处理 → 生成侧 → 系统侧”的顺序来拆这样最符合问题出现的先后逻辑。2.1 多查询检索用多个问题视角弥补单个查询的盲区多查询检索Multi-Query Retrieval的原理一句话就能说清让大模型把用户问题改写成多个不同的查询分别检索后再合并去重。它解决的是用户提问和文档语言表达之间的语义鸿沟。用户不一定知道知识库里的关键词比如他问“报销单据弄丢了”文档里写的是“原始凭证遗失处理”两种说法在向量空间里未必足够接近但大模型知道它们是同一件事。让大模型基于原问题生成3到5个变体查询比如“原始凭证遗失怎么办”“发票丢失报销流程”“报销票据遗失说明”就等于用不同词面把同一意图打了一遍召回率自然上来了。实现时我建议变体数量控制在3到5条。太多会让成本翻倍而且会出现大量重复结果太少又起不到扩充召回的作用。我常用的一种做法是让大模型输出JSON列表逐条解析过滤掉与原问题语义完全重复的变体再做一次简单的去重最后合并各路召回结果。多查询检索最直接的效果是召回率明显上涨副作用是后续重排序的压力变大因为它会把更多相关结果捞上来也会把更多无关结果带上来所以它几乎一定要和重排配合使用。2.2 HyDE先写一个“假设答案”再拿它去检索Hypothetical Document EmbeddingsHyDE假设文档嵌入的核心动作是先用大模型生成一个基于问题的假设性回答文档再用这个假答案的Embedding代替问题去检索。为什么这样能有效Embedding模型把问题和文档映射到向量空间时问题通常很短、很口语化而文档很长、很正式两者在向量空间里天然有一段距离。HyDE相当于把问题先翻译成“文档语言”生成一个150到200词的假设回答用假回答去和文档做相似度匹配匹配到的通常就是真正包含相关内容的事实证据。这个思路在短查询场景里经常比直接Embedding问题效果更好因为假回答里包含了文档里可能出现的实词和句式。这里有个常见误区HyDE不是让模型“猜答案”而是让它“列出答案里可能包含的主题、实体和上下文”。我实际跑下来的体会是Prompt里明确写“不要给出具体事实结论只描述一份包含该问题答案的文档可能长什么样”比直接要它给答案稳定得多。HyDE的缺点是成本高每次检索前都要多一次大模型调用而且生成结果不稳定所以我会把它当作多查询检索之外的补充方案而不是完全替代。2.3 RAG-Fusion把多路结果用排名融合变成一路RAG-Fusion解决的是“单一检索器信号不可靠”的问题。向量检索擅长语义相近但可能漏掉精确关键词关键词检索命中准确却对同义词、改写毫无办法。两边都有道理那就融合。具体做法是多路并行检索一路向量检索一路关键词检索甚至把多查询检索的每一个变体都算一路。每路各自返回一个排序列表然后用RRFReciprocal Rank Fusion倒数排名融合把多个列表合并成一个最终序列。RRF公式很简单一个文档的融合得分是它在每个列表中排名的倒数再求和通常写作 score(d) Σ 1/(k rank_i(d))其中k取经验值60。这个公式最大的优点在于它只关心排名不关心不同检索器给出的原始相似度分数。向量检索打出的0.82和关键词检索打出的15.4根本没有可比性但排名是可以比的。我在某个知识库项目里用“向量关键词”双路融合后召回质量明显比单路好尤其是在专有名词、编号、型号这类场景里关键词那一路经常能给出意外惊喜。RAG-Fusion的代价是维护多路检索器每次查询的延迟也会上升但这个代价通常值得。2.4 父子文档切块检索要小的、喂给模型要大的父子文档切块Parent-Child Chunking是我强烈建议做的一步它解决的是切块粒度的矛盾。父块里面放整篇文档或一个较长的章节直接作为生成阶段的内容子块则是从父块继续拆分出的小片段用于Embedding和向量检索。原理很简单小片段语义更聚焦容易命中大片段上下文更完整送进Prompt不容易断章取义。实操上我常用子块128到200个Token、父块512到1024个Token并在父块开头保留原有标题。检索命中的是子块但返回给模型的是子块对应的父块。注意这里要求索引阶段就建立子块ID到父块ID的映射关系检索之后要把父块内容取出来替换而不是把子块直接丢给模型。这么做的代价是索引里的块数量变多了因为同一个父块会被拆成多个子块并各自生成Embedding存储和写入成本上升。另外如果父块跨了多个主题比如一整节“费用报销”包含差旅费、招待费、交通费父块照样会混入杂质所以父块也不能无脑大要尽量跟原文档的章节标题对齐。2.5 重排序与上下文压缩把召回来的噪声干掉把重排序Re-ranking和上下文压缩Contextual Compression放在一起讲是因为它们在管线里常常连续出现目标都是清理召回结果的质量。重排解决的是“Top-5不等于最相关的5个”的问题。向量检索粗召回一批候选通常是Top-20或Top-50然后把(query, doc)对交给一个交叉编码器重新打分最后按新分数取Top-5。交叉编码器能同时看到问题和文档的完整关系比双塔式的Embedding判断更准但计算量也更大所以不能替代第一轮粗召回。上下文压缩则是对进入Prompt的文档做一次“瘦身”。常见做法是把候选文档切句子只保留与问题最相关的那几句或者让大模型抽取关键段落。原因很现实向量检索返回的片段里经常混着大段无关上下文直接把整段送进Prompt大模型会“有样学样”地引用这些无关信息产生幻觉和跑题。压缩之后Prompt更短、更聚焦答案质量通常会提升一截。成本方面要注意重排序器的输入长度通常有限制一次只能处理不超过几百个Token的文本所以它更适合做第二轮精排。正确顺序是粗召回 → 上下文压缩 → 重排 → 送生成器。2.6 自省式RAG与纠正式RAG给检索结果加一层质检自省式RAGSelf-RAG和纠正式RAGCorrective RAGCRAG出场时机一样在“检索结果已经准备好”和“生成答案之前”之间插入一个质量检查环节。它们的目标很明确就是减少“模型拿错误文档硬答”的情况。Self-RAG的思路是让大模型在推理时生成反思标记判断检索文档是否相关、是否足以回答、是否被引用支持从而决定是用检索结果还是直接用内部知识。实现难度稍高因为它通常需要对模型输出格式做改造在工程上也可以退化成Prompt里显式要求模型“先检查文档相关性再回答”。CRAG则更工程化单独训练一个轻量评估器先给检索结果打一个“质量分”分数高走正常生成分数低说明这一轮检索大概率不靠谱就触发纠错——重写查询、换一个检索源、查外部权威来源实在不行就明确告诉用户“没有找到相关信息”。之后还会有一个“知识精炼”步骤从原始检索结果里提取只与问题相关的内容拼接到生成Prompt中。我测试过CRAG风格的方法最直接的变化是“无引用幻觉”明显下降。以前模型会把我给它的文档里的细节和它自己编的细节混在一起加了这个质检环节之后它要么回答有出处要么直接承认没找到不会强行编造。2.7 Agentic RAG从检索增强到智能体决策最后这个是我认为最接近未来方向的架构。Agentic RAG的核心变化是检索不再是一个固定管线里的步骤而是由大模型主导的一个决策循环。典型实现有三种形态。Router型智能体先判断问题类型决定走向量检索、关键词检索还是调用外部工具再决定要不要用检索结果。多步检索型第一轮结果不够智能体改写查询再检索一轮直到它认为自己拿到足够信息。多智能体型拆成检索Agent、审查Agent、写作Agent各司其职协作完成。第三种已经不只是“检索增强生成”更接近一个完整的Agent系统。代价是复杂度和成本都会明显上升所以必须有严格的控制限制最大轮数、记录已经查过的查询、对低分结果强制改写查询否则很容易出现同一个查询反复检索的空转。但如果你要做跨多个来源、需要多轮推理的复杂问答Agentic RAG带来的效果提升是固定管线给不了的。3. 七种架构怎么选先看痛点再看成本没有一种架构能解决所有问题选型应该先明确“当前最主要的失败场景是什么”。我把七种架构的核心信息放在表格里方便对照。架构主要解决的问题典型适用场景主要代价多查询检索查询表述与文档语言不匹配用户提问口语化、关键词变化多检索次数与Token成本增加HyDE短查询与长文档的语义鸿沟问题短、文档正式、术语多多一次LLM生成结果不稳定RAG-Fusion单一检索器信号不可靠含编号、型号、专有名词的混合场景需要维护多路检索器融合参数要调父子文档切块切块粒度不平衡长文、章节结构清晰的资料库索引量和存储开销上升重排序上下文压缩粗召回噪声过多所有候选多、Prompt长度受限的场景增加推理时延与额外模型调用自省/纠正式RAG检索结果不可信对准确性有强要求的客服、合规场景需要额外评估器阈值要调Agentic RAG固定流程无法多步推理跨文档、多轮检索的复杂问题延迟高、易循环、维护复杂表格只能覆盖一部分实际上选型还有两个很实际的角度。第一个角度是成本预算。如果你的系统对延迟和Token消耗非常敏感那就优先做索引侧和查询侧的低成本组合也就是多查询检索、RAG-Fusion、父子文档切块这些不会增加太多生成阶段的开销。重排序和CRAG会显著增加每次查询的成本Agentic RAG的Token消耗更是成倍增长所以预算有限时不要一上来就全都上。第二个角度是问题复杂度。大部分内部知识库问答停留在“单次检索能回答”的层面用前面六种架构的组合就已经能解决绝大多数问题。只有当你明确看到“需要跨文档综合、需要多轮判断”的需求时再往Agentic方向走。我个人的建议路线是先做便宜的组合多查询、父子切块、融合、重排如果仍然出现幻觉再加纠错如果问题复杂度进一步上升再加Agentic。4. 一个能跑的参考管线把多查询、融合、重排、纠错拼起来理论讲再多不如给一条可落地的参考管线。下面这段伪代码表达的是我常用的一条组合管线它把多查询、RAG-Fusion、重排序和CRAG式纠错串在了一起。# 伪代码示意组合管线方便你迁移到自己的工程里 def generate_answer(question: str): # 1. 查询侧让大模型生成查询变体 variants llm.generate_variants(question, n3) # 2. 检索侧向量检索 关键词检索多路并行 results [] for q in variants [question]: results.append(vector_store.search(q, top_k20)) results.append(keyword_store.search(q, top_k20)) # 3. 融合对多路结果做RRF fused reciprocal_rank_fusion(results, k60) # 4. 重排粗召回候选降到精排5个 candidates fused[:20] reranked reranker.rerank(question, candidates)[:5] # 5. 纠错对精排结果做质量评估 quality evaluator.score(question, reranked) if quality low_threshold: # 重写查询后再检一次仍然没有就诚实回答 reranked retrieve_with_rewritten_query(question) if not reranked: return no_support_answer(question) # 6. 压缩与生成 compressed compress_for_prompt(question, reranked) return llm.generate(question, compressed)这个管线里的每一步都可以单独摘出来用。如果你今天的场景只是“召回率不够”那从第2、3步开始就够了如果问题是“Top-5里有噪声”那就加第4步重排如果问题变成“模型总在没根据的时候硬答”第5步纠错才是关键。我把第5步放在重排之后是因为重排质量高的时候评估器对相关性的判断会更准确。如果先评估一个Top-20的粗糙结果很多相关文档会被无关文档稀释质量分反而不可信。另外第6步的压缩放在重排之后可以减少送入生成器的Token量也避免重排器处理超长文本。这个管线的吞吐量并不适合在每轮对话里都全量跑。我实际使用时会加两个开关简单问题只走第1、2、3、4、6步跳过纠错只有高价值或高风险的查询才全量走到第5步。工程上要允许自己“按需取舍”而不是把每一条查询都压到最重配置。5. 把这几种架构跑进生产后我踩过的七个坑每一章配方都很美好但真正落地时坑几乎全在细节里。我把踩过的坑按环节整理出来希望你不用再走一遍我的弯路。5.1 查询侧与索引侧的坑第一个坑出现在多查询检索的Token消耗上。我最早让大模型生成5个查询变体结果其中3个几乎一样检索出的片段也高度重复最后Prompt里全是重复内容有效信息反而少了。后来加了“语义去重”先对查询变体做相似度比较重复的只保留一个再限制变体数量为3个成本降下来召回质量没有降。这个操作看着简单省掉的Token量却非常可观。第二个坑是HyDE生成的假答案和文档风马牛不相及。我遇过一次很典型的案例问题问的是离职交接流程HyDE生成的假设文档却把入职、转岗、社保全写进去了结果检索回来一堆完全不相关的块。原因是我给了模型太多发挥空间。修正办法是把Prompt从“生成一段假设答案”改成“列出该问题答案文档可能包含的标题与要点”并限制输出在100词以内。这个改动之后召回稳定性好了很多。第三个坑是父子切块的父块设到了2048个Token。父块大确实意味着上下文完整但一个父块经常覆盖四五个子主题检索命中的子块对应父块后无关内容依旧很多整块塞进Prompt反而是灾难。我最终把父块调到512到1024个Token切块时尽量让父块跟原有章节标题对齐效果比单纯调大小好很多。5.2 融合与重排的坑第四个坑是RRF的k值不能随便拍。一开始我用k10结果排名靠前的文档把分数垄断了融合结果跟直接取某一路几乎没区别。改成k60之后各路由结果才有合理竞争局部排名靠后的文档才可能挤进前面。建议在业务数据集上跑一遍小网格搜索k通常在50到80之间取不要默认一个值就不动了。第五个坑是重排序截断把关键信息截丢了。我用的重排器最长只能处理512个Token而很多文档块超过这个长度。结果文档结尾的关键细节根本没进入重排器自然排不上去。后来我先把候选文档切成句子抽出与问题相关的句子再做压缩压缩后的短文本再进重排器情况明显改善。这个坑很容易被忽视因为重排器本身不会告诉你它截断了什么。5.3 纠错与智能体的坑第六个坑是CRAG的阈值调太高等于没装。我最初把评估分数阈值设为0.7跑了一周几乎没触发过一次纠错因为大多数召回的片段都有一些相关性分数在0.5到0.7之间晃。后来抽了200条人工标注的问题结果画出分数分布把阈值卡在分布低谷0.55附近纠错才开始正常工作。这个分布必须先画否则阈值就是个玄学。第七个坑是Agentic RAG死循环同一个查询反复查。智能体在拿不到可回答内容时很容易重新生成一个和原来几乎相同的查询继续检索。我加了两个防御全局最多5步维护一个“已检索查询集合”如果新查询和集合里的某个查询相似度超过0.9直接判定为重复强制智能体改写查询。没有这两道防御Agent在复杂场景里真的会空转到超时。6. 落地前最后补一句评测、成本与迭代顺序这一节我要讲的是容易被技术分享冷落、但真正决定成败的事情。6.1 没有评测就不该上高级RAG如果不做评测你根本分不清多查询检索到底有没有带来收益。我现在的习惯是建一个业务评估集至少100个问题按难度和类型分桶分单跳简单问题、多跳问题、含专有名词问题、明确该回答“未找到”的问题。每个问题记两件事答案正确度、是否有引用支撑。上线前跑一遍这个评估集记下基线每加一种架构再跑一遍看哪个分桶涨、哪个分桶跌、哪个分桶被牺牲。这一步能帮你挡掉大量“感觉变聪明了实际变差了”的改动。6.2 成本与延迟能省则省高级RAG的代价首先是Token和时间。多查询一次查询要多次向量检索重排要做交叉计算纠错又多一次大模型调用Agentic甚至可能要跑好几轮。省成本有几个方向对高频重复问题做缓存相同的业务问题直接命中缓存不要重复检索对简单问题直接跳过重排和纠错对查询变体数量做动态控制问题很简单就只用一个查询。延迟方面重排和压缩是最明显的瓶颈可以考虑用更轻量的模型做初筛把真正的重排留给关键场景。6.3 按这个顺序一步步往上加我建议的迭代顺序是这样的第一版只做最基础的优化换更好的Embedding模型、语义化切块、建立父子文档结构。第二版加多查询检索和RRF融合这一步对召回率的提升最明显成本也可控。第三版加重排和上下文压缩把精排质量提上来。第四版再加纠正式RAG处理幻觉最后看业务是否需要多跳推理再上Agentic RAG。每一步都回到评估集上验证再决定要不要继续往下走。最后再说一点我自己的体会七种架构不是集邮不要为了“高级”而高级。每种架构都应该对应一个具体的失败场景加上之前先问自己一句“它治的是哪个病”。我用这套方法把一个客服问答项目从严重跑题推进到了能挡住绝大多数幻觉的程度真正的体会就是把评测和迭代节奏踩稳比任何单一架构都重要。所以当你准备对现有RAG系统动手时不要一次性上七个先找一瓶药对症下药。