最近一年我接触了不少做知识库问答、企业私有大模型应用的团队听最多的一句话就是“RAG根本没想象中好用”。最典型的场景员工查内部运维手册问“某某服务为什么启动失败”AI一本正经给了一段跟问题毫无关系的答案让AI读一份几十页的行业报告结果它只盯着某一页的碎片信息完全答不出全局概况。这些问题的根源往往不在大模型本身而在RAG的链路设计。RAG也就是检索增强生成确实是把最新知识、私有数据注入大模型的主流方案。但很多人把它想得太简单切文档、灌向量库、拼Prompt三步走完就上线。结果做出来的系统不仅幻觉没压住连基础的检索命中率都很差。这篇文章我会把RAG从基础三段式讲到25种具体架构按“检索前、索引端、召回后、结构化、迭代反思”五个层面逐层拆解最后给出我自己实际搭建知识库时的选型组合和调参经验。内容偏实操适合正在做RAG系统、或者准备把RAG落地的工程师和架构师收藏。1. 为什么RAG会翻车先理解三段式基础再谈25种变体1.1 朴素RAG的三段式以及大多数人翻车的地方先对齐最基础的认知。常规RAG系统也就是很多论文里说的Naive RAG本质上只有三个阶段索引、检索、生成。索引阶段负责把文档变成机器能查的东西先做文档加载和清洗去掉页眉页脚、水印、重复内容然后按固定规则切分成块转成向量写入向量数据库。检索阶段接收用户问题把问题也转成向量在库里做相似度搜索找出TopK个最相关的文本块。生成阶段把用户问题、检索到的文本块、系统提示词一起拼进Prompt交给大模型生成回答。听起来很顺但实际跑起来问题集中在三处。第一是切块太粗暴常用的做法是固定字符数切分比如512个字符一刀切经常把一句话从中间切断一个完整概念被拆到两个块里检索时只命中半个概念。第二是用户提问方式和文档写法对不上用户习惯口语化表达文档是严谨书面语词面不匹配导致语义检索也匹配不到。第三是检索出来的内容本身有噪声硬塞进Prompt之后大模型被噪声带偏反而比以前更容易胡编。1.2 三种基础形态Naive、Advanced、Modular为了补上述这些洞业界逐渐分化出三种基础形态后面的25种架构基本都是从这三种形态演化出来的组合拳。Naive RAG就是上面的三段式适合快速跑通Demo不适合生产。Advanced RAG做的是在检索前和检索后增加优化动作检索前先对用户问题做改写、扩展、路由检索后对召回的文本块做重排、压缩、去重。Modular RAG更彻底把整个流程拆成可插拔的模块检索器、生成器、记忆模块、路由模块都能独立替换衍生出很多新的组合结构。形态核心特征典型适用主要短板Naive RAG索引-检索-生成固定三段式技术验证、小型知识库召回不准、上下文碎片化Advanced RAG检索前重构 检索后处理生产级知识库问答链路变长、维护成本上升Modular RAG模块化、可组合、可替换复杂业务场景、多源数据工程复杂度高、需要精细调度1.3 25种架构全览一张表看懂全局我先给一张总览表把25种架构按职责位置分成六个大类。后面每个章节按这个表逐类展开每一条都会讲清楚它解决什么问题、适用什么场景、有哪些坑。这张表本身建议收藏做方案评审时对照着看非常有用。分类架构名称一句话定位基础形态Naive RAG原始三段式一切变体的起点基础形态Advanced RAG检索前重构和检索后处理基础形态Modular RAG模块化自由组合的框架查询端Query Rewriting改写用户问题提升检索命中查询端Multi-Query一个问句扩展成多个子查询并行召回查询端HyDE用假设答案文档替代原问题做向量匹配查询端Step-Back Prompting先问抽象问题再回到具体问题查询端Query Routing判断问题应该走哪种检索通道索引端Semantic Chunking按语义边界切块杜绝碎片化索引端Parent-Child Chunking小块负责召回大块负责提供上下文索引端Hierarchical Index文档-章节-块的树状分层索引索引端Multi-Vector Retrieval一个文档挂多个向量入口召回融合Hybrid Search关键词检索与向量检索并行召回融合RRF多路召回结果按排名融合召回融合Rerank用交叉编码器对召回结果精排召回融合Contextual Compression按问题压缩上下文滤除噪声结构化增强图增强RAG抽取实体关系图结构检索结构化增强知识图谱增强RAG实体链接 三元组事实约束结构化增强RAPTOR递归摘要树兼顾粗细粒度结构化增强记忆图RAG图谱上的多跳联想式检索迭代反思Adaptive RAG按问题复杂度动态决定检索动作迭代反思Iterative RAG生成后自我评估缺信息再检索迭代反思Self-RAG模型自己输出反思标记调控生成迭代反思CRAG先评估检索质量低质则纠错重构迭代反思Agentic RAG智能体自主规划工具调用2. 检索前先改造问题5种查询端架构很多人链路一跑不通就急着换向量库、调Embedding模型其实有一个更便宜、见效更快的思路在检索之前先把用户的问题改造得更适合检索。查询端架构做的就是这件事。2.1 Query Rewriting把用户口语翻译成文档黑话Query Rewriting是最直观的做法。用户的问题往往是口语化的、上下文不完整的但文档里的写法是正式的。比如用户问“这个系统为什么老是卡”而运维文档里的相关描述是“性能瓶颈排查”“延迟过高原因分析”直接拿原问题去做向量检索匹配度一定很难看。解决思路是先用大模型把问题改写一遍再拿改写后的文本去检索。具体做法可以简单粗暴在Prompt里让模型扮演检索助手把原始问题改写成适合搜索的关键词组合或规范化问句。我见过更稳的写法是让模型输出多个改写版本全部送去检索再合并结果。这里有个细节需要注意改写需要额外调用一次大模型成本和延迟都会增加。所以我的建议是不要做成必选步骤而是设置一个触发条件比如先做一轮轻量检索如果相似度分数普遍偏低再触发改写重检。这样能把大多数简单问题挡在快速通道里。2.2 Multi-Query一个问题多路出击Multi-Query解决的是“一个问题可能有多种问法”的问题。同一个需求A用户会说“怎么退款”B用户会说“我怎么把钱要回来”C用户会说“订单取消后多久到账”。文档里的相关章节只匹配其中一种表述单路检索就容易漏。Multi-Query的做法是让大模型基于原始问题生成多个角度不同的子问题比如3到5个然后并行去做检索最后把结果合并、去重。这相当于把一次提问变成一次小组会议大家从不同视角翻资料再汇总。但这个架构的副作用也很明显查询数量放大之后召回结果数量也会成倍上升如果直接全部塞进上下文Prompt会被无关内容撑爆。所以Multi-Query必须跟去重和重排配合使用。我在一个客服项目里就是用Multi-Query加Rerank组合覆盖度提升明显但一定要在重排阶段把无关片段压下去。2.3 HyDE用“假答案”去找真内容HyDE的全称是Hypothetical Document Embeddings思路有点反直觉不让用户问题去做检索匹配而是先让大模型凭空生成一个“假设性答案文档”再用这个假文档的向量去向量库里检索真实文档。为什么这样能成立关键在向量空间的对齐方式。文本转成向量之后文档与文档之间的语义距离通常比查询与文档之间的语义距离更稳定。举个实际感受查询“苹果公司最近为什么股价波动大”和文档“AAPL股价受财报影响下调”之间向量距离可能很远但一篇假设文档“苹果公司股价近期波动主要受财报和供应链影响”跟真实文档的距离就近得多。所以用假设文档去捞真实文档成功率更高。HyDE的坑在于假设文档是模型编的很可能包含幻觉内容尤其涉及具体数字、日期、法规条文时。用它做开放型知识问答没问题做医疗、法务这类强事实核查场景要非常谨慎必须配合后置的严格校验或者直接避开这个方案。2.4 Step-Back Prompting先拉远再看全局Step-Back Prompting的思路来自一个常见困境用户问的是一个具体问题但需要的答案依赖一组背景知识。比如“为什么某款产品最近提价了”直接检索可能只找到产品公告找不到背后的行业原材料涨价背景。做法是先让大模型把具体问题抽象一步生成更上位的通用问题拿上位问题去检索背景资料再结合原始问题去生成最终回答。以提价为例上位问题可能是“该产品所在行业近期有哪些成本上涨因素”检索出来的是一段行业背景综述覆盖面广再回到具体产品时就有关联依据了。这个方案适合综述类、原因类、趋势类问题。它跟Query Rewriting的区别在于Query Rewriting是改变提问的表达方式Step-Back是改变提问的抽象层级。实际系统里两者可以串联使用先抽象再改写效果叠加。2.5 Query Routing让问题走对路企业知识库往往不是只有一种数据源。有些内容适合关键词精确匹配比如产品型号、订单编号有些适合向量语义检索比如概念解释、方案建议有些存放在关系数据库里比如用户余额、订单状态还有些问题根本不需要检索大模型自己就能回答。Query Routing做的事情就是判断当前问题应该走哪条通道是走向量检索还是走关键词搜索还是直接查SQL或者干脆不检索直接让模型答。这像一个路由器把不同的请求分发到不同的后端。我见过的实现方式有两种。轻量的是用大模型分类Prompt里描述每条通道适合的问题类型让模型输出通道编号重型的是训练一个专门的意图分类器适合QPS很高、对延迟敏感的场景。路由架构本身不直接提升单路检索的精度但能避免“所有问题都往一个向量库里塞”带来的系统性低效。3. 入库之前决定上限4种索引端架构索引端架构经常被忽视因为它在跑线上之前就定好了。但说句实话索引端的设计直接决定检索上限后面再强的重排也救不回一个信息切碎、结构混乱的库。3.1 Semantic Chunking按语义边界切分固定字符数切块是RAG翻车的第一大来源。一篇文档连续切下来常常出现一个段落被劈成两半、一个列表项被截断的情况。检索时命中的块里只有半个概念模型自然只能给出片面的回答。语义分块的做法是让切分边界落在语义完整的位置。最简单可靠的实现是先用LLM做章节边界识别或者利用文档自带的段落和标题结构常用的做法是先用规则识别句子边界然后计算相邻句子向量之间的相似度变化相似度明显下降的位置就是主题切换点在那里切块。也可以借助现有结构比如HTML的标题标签、PDF的书签结构。分块大小也需要调。块太小单块信息量不足检索时经常需要拼凑好几块才能凑齐答案块太大块内混入的无关内容多向量表示被稀释。我的经验值是在500到800个字符起步再根据具体文档内容验证调整。注意语义分块本身也有成本别为了“语义完美”分得太碎否则检索出的块数量暴增后处理压力也变大。3.2 Parent-Child Chunking小块召回大块给答案这是我在生产项目里最常用也最推荐的基础架构之一。它把切块分成两层小块用于检索大块用于生成。简单来说把文档先按比较大的单位切出“父块”再把父块内部切出若干“子块”。检索时用子块匹配问题命中后把子块对应的父块整体提取出来作为上下文喂给模型。为什么这样设计小块粒度细召回更精准不太容易被无关内容干扰但小块独立拿出来信息量不足。父块上下文完整能提供充分的背景和前后逻辑但直接拿父块去检索匹配精度往往下降。父子结构相当于把“精确定位”和“完整理解”分开处理。用一个图来理解子块是书里的具体段落索引父块是该段落所在章节的完整内容。注意点父块不宜设得太大一般1500到2000字足够提供上下文再大会导致Prompt膨胀且引入噪声。子块和父块的比例需要根据文档类型实验调整技术文档和规章制度的最优值差异很大。3.3 Hierarchical Index像图书馆一样分层面对一份几百页的大型手册如果全部摊平成块检索时没有层级概念容易迷失。Hierarchical Index的做法是构建一个树形索引顶层是章节、目录级别的摘要中间是小节级别的概述底层是原始块。检索时先在上层定位到相关章节缩小范围后再进入下层做精细匹配。这样设计的好处是双重的一是显著提升检索效率避免每次都在全库范围内比对二是回答问题时可以带着章节上下文模型能理解当前内容在整个文档中的位置回答更结构化。图书馆查书就是一个很贴切的类比先确定书架区域再逐层缩小到具体书页。实现上这类方案需要文档有清晰的结构信息。如果输入是排版混乱的扫描PDF结构信息缺失分层索引很难自动构建必须先做OCR和版面分析。这也是一个常常被忽略的环节很多人直接把扫描件丢给切块脚本结果索引质量很差还以为是向量库不行。3.4 Multi-Vector Retrieval给文档开多个入口传统的做法是一个文档块对应一个向量。但实际内容里一个块往往包含多个子主题比如一个产品介绍段落里既有技术参数又有适用场景还有售后说明。一个向量要把这些信息全部压缩表达检索时任何单一主题的查询都只能匹配到这个块的一部分。Multi-Vector Retrieval的思路是让一个文档块生成多个向量比如分别对应标题、摘要、正文、关键实体。检索时用户的查询可能命中标题向量也可能命中关键实体向量只要命中任一个入口就能把整块内容带出来。这相当于给一个文档块开了多个“门”查询从哪个方向都能进来。这种架构跟父子分块可以叠加使用。子块负责多向量精确定位父块负责完整上下文。多向量方案需要好的向量化策略通常会用LLM辅助生成每个块的摘要或关键词向量。4. 召回不是越多越好4种融合与精排架构很多人天真地以为召回数量越多越好实际上TopK拉到20以上时上下文里充满噪声大模型的注意力被稀释幻觉反而加重。召回之后怎么融合、怎么排序、怎么压缩往往才是拉开系统精度的分水岭。4.1 Hybrid Search关键词和语义一起上向量检索擅长处理语义相关问题但对精确匹配不敏感。比如用户问“服务器型号R740报错”如果文档里写的是“PowerEdge R740”向量检索可能会因为词序、上下文干扰而给出不稳定的结果而传统的关键词检索BM25能精确命中“R740”这个型号。Hybrid Search把两条路并行一条走BM25关键词打分一条走向量相似度打分然后把两者结果合并。大多数知识库类场景关键词和语义各有侧重叠加后效果显著优于任一单路。一个容易犯的错是直接把两路分数相加。BM25的分数范围和余弦相似度完全不可比直接相加等于默认两条路的权重等同且线性这在大多数情况下并不合理。至少要先把两路分数各自归一化到相同区间再融合或者用后面要讲的RRF这类排名融合方法。4.2 RRF让多个召回结果排队说话RRF的全称是Reciprocal Rank Fusion是一种经典的融合算法。它不关心不同检索器的原始分数只看每个检索器结果里的排名。对每个文档把它在所有召回列表中的排名倒数累加公式是score sum(1 / (k rank))其中k是一个平滑常数常见取60。最后按总分排序。这个方法的友好之处在于直接省去了归一化不同检索器分数的麻烦即使一个检索器的分数分布跟另一个差异极大也能公平地按位置说话。延迟也低不需要额外调模型。RRF在实践中的搭配一般是BM25召回一路向量召回一路偶尔再加一路查询改写召回用RRF合并。合并之后通常还要再过一道重排因为RRF只解决了“多路怎么合”的问题没有解决“合完之后什么最该排前面”的问题。4.3 Rerank双塔粗筛交叉精排检索阶段的向量匹配通常用的是双塔模型就是查询和文档各自编码成向量再算相似度。双塔模型的好处是可以把文档向量离线算好在线检索非常快但代价是查询和文档在编码阶段没有交互精度有限。Rerank阶段换成交叉编码器查询和文档拼接在一起送入模型直接输出相关性分数。因为做了完整交互精度显著高于双塔缺点是无法离线预处理在线计算量远大于向量比对所以不能对所有文档都跑交叉编码器只能对检索阶段筛出的TopK个候选做精排。实际配置建议是检索阶段召回20到50个候选重排阶段只对这20到50个做交叉编码打分最终取前5到8个进Prompt。重排是效果提升性价比最高的一个环节强烈不建议省。4.4 Contextual Compression把噪音赶出上下文即使经过重排召回的文档块里仍可能有大段跟问题无关的内容。比如一个产品文档块有1200字用户只关心其中的退货条款其他介绍性内容全部无关。原样塞进Prompt既浪费Token又可能干扰答案准确性。Contextual Compression的思路是在召回结果进入Prompt之前根据当前查询对每个文档块做压缩也就是用一个轻量级LLM把块中与查询相关的句子抽出来无关内容丢弃。这样进入Prompt的信息密度大幅提高。代价也很直接每个召回的块都要过一次LLM压缩成本和时间都上升。所以这个环节适合用在问题比较复杂、上下文预算比较紧张的场景。我更推荐的折中方案是只对重排后真正被选入Prompt的前几个块做压缩而不是对全部候选压缩。5. 用图谱和树对抗碎片化4种结构化RAG知识库问答经常遇到一个问题答案分散在多个文档段落里需要把几处信息拼起来才能回答。普通切块型RAG对这类多跳问题很吃力因为它看到的永远是碎片。结构化RAG就是把数据间的关联显式建出来再基于这种关联做检索。5.1 图增强RAG实体关系织成网图增强RAG通常也被泛称为Graph RAG的核心思路是从文档中抽取实体和关系构建一张知识图谱。检索时不再是孤立地匹配文本块而是先从查询中提取实体定位到图的节点上再沿着实体之间的关系边扩展把相连的信息都带出来。这种架构特别擅长回答“A和B之间是什么关系”“有哪些因素影响了C”这类需要关联推理的问题。它还能聚合出全局性结论比如统计某个社区内实体出现的频次和共现关系直接回答“整个知识库中讨论最多的技术方向是什么”。普通向量RAG几乎不具备这种能力。代价是图谱构建非常昂贵。实体抽取、关系抽取、消歧每一步都要消耗大量算力对语料质量和领域一致性要求很高。如果语料杂、术语乱抽出的图会充满噪声。所以这个方案适合对全局关联有强烈需求的场景而不是所有知识库的默认选择。5.2 知识图谱增强RAG事实约束兜底跟完全依靠文本检索的RAG不同知识图谱增强RAG在链路里显式加入结构化三元组比如“(某产品, 属于, 某产品线)”“(某接口, 依赖, 某服务)”。查询时先做实体识别把用户问题中的实体链接到图谱节点然后查图谱拿到相关三元组再把三元组和文本检索结果一起送进Prompt。这个方案的价值在于给生成过程加了一组“事实约束”。大模型容易自由发挥但如果Prompt里明确给出一条事实三元组模型被约束的概率显著提升。对于医疗、法务、金融这类事实错误代价极高的场景知识图谱增强是一个值得投入的方向。落地时的坑在于实体识别和实体链接的准确率。如果实体识别失败后续图谱查询全部白做。需要针对语料训练或者精调命名实体识别模型并且要维护一套领域词典。5.3 RAPTOR递归摘要树从叶子看到树冠RAPTOR的完整名字是Recursive Abstractive Processing for Tree-Organized Retrieval核心是把文档构建成一层递归摘要树。做法是把文档块按语义相似度聚类每一簇生成一个摘要然后对摘要再做聚类、再生成更高层的摘要重复若干次形成从叶子块到高层摘要的多层树结构。检索时可以根据问题特点路由到不同的层具体细节类问题去叶子层找全局综述类问题去高层摘要找。也可以同时检索多层把细粒度信息和全局信息一起给模型。这个方案的优点是对“具体和全局兼顾”的问答需求特别有效。一个很实用的场景是处理长篇研究报告问“第三章的数据来源是什么”去叶子层问“整份报告的核心结论是什么”去高层摘要。实现成本主要在于递归摘要的构建阶段文档更新频繁的话维护成本偏高。5.4 记忆图RAG海马体式联想记忆图RAG的思路借鉴了人脑的记忆机制海马体会把新信息跟已有的相关知识连接起来回忆时不是线性搜索而是从一个记忆点顺着联想路径跳转。实现上先用LLM从文档中抽取实体和关系构建成开放知识图谱类似于给长期记忆建索引检索时对查询实体做图谱上的个性化PageRank从相关实体出发往外扩散若干步把关联实体对应的原始文本全部取回。这个方案对长文档的多跳问答表现很好。比如一篇技术方案文档里A组件影响了B服务B服务又依赖C数据库用户问“A组件挂了会影响什么”普通RAG可能只在A组件附近找到片段而记忆图RAG能顺着A到B到C的路径把连锁影响全部找出来。坑在于扩散步数需要控制。步数太少多跳信息取不全步数太多无关实体和噪声大量进入上下文。通常两步到三步比较合理具体要按知识库的图谱密度调试。6. 生成之前先想想要不要检索5种迭代与反思架构传统RAG的流程是单向的检索完、拼好、生成、结束。但实际很多问题一次检索根本不够也有的问题压根不需要检索。迭代与反思类架构解决的就是“让系统自己判断怎么查、查几次、查完怎么用”。6.1 Adaptive RAG按问题复杂度动态调度Adaptive RAG的思路是给RAG系统加一个“复杂度判断器”。简单问题直接让模型回答不检索省时省钱中等难度问题走一次标准检索复杂问题走多轮检索或多步推理。判断器可以是一个轻量分类器也可以用大模型做给一个Prompt让它判断问题是“直接回答型”“单轮检索型”还是“多跳推理型”。实际项目中这类调度显著降低整体延迟和成本因为客服场景里大概有四成问题是高频重复的简单问法不需要每次都掏全链路。实现时最难的是判断阈值怎么定。判断太保守简单问题也去检索成本优势没了判断太激进复杂问题被当作简单问题直接回答准确率崩盘。我的做法是先收集线上问题做标注标出每个问题的真实复杂度再校准分类器的阈值或Prompt示例。6.2 Iterative RAG一轮不够就再来一轮Iterative RAG让系统进入循环生成答案之后让模型自评是否缺少关键信息如果缺就基于当前已生成内容生成新一轮检索词检索补充信息再继续生成直到模型认为信息充足或达到最大轮数。这种架构适合答案需要多段拼接的问题。比如“某设备配置步骤和故障恢复方法是什么”第一轮检索可能只找到配置步骤模型发现恢复方法的描述缺失就发起第二轮检索针对恢复方法单独搜索。最终答案融合两轮信息。这个方案最大的问题是可能陷入循环每轮检索到的内容会互相干扰甚至出现两轮信息矛盾。必须设置最大迭代轮数一般2到3轮就够了。还要在每轮检索后做信息去重和冲突消解否则上下文越滚越大答案越滚越乱。6.3 Self-RAG让模型自我反思检索质量Self-RAG的做法比较特别它把“反思”写进生成过程本身。模型在生成时会额外输出一些特殊标记比如“是否需要检索”“检索结果是否相关”“答案是否被支持”“答案是否完整”这些反思标记会被用于指导下一步动作。举个例子模型生成一句话之前先判断当前知识够不够不够就触发检索检索完成之后判断结果是否与问题相关不相关就换一种方式再查生成答案时判断每个句子有没有被检索结果支持没支持的句子要降低置信度或重写。这种架构需要专门的模型训练或者很强的Prompt设计。它的价值在于把质量检查从外部链路搬到了生成过程中能更细粒度地控制“哪一句该信”“哪一句该改”。如果你觉得普通RAG是“生成完才知道错”Self-RAG更像是“边写边检查”。6.4 CRAG先检查再纠错不让坏内容进门CRAG的全称是Corrective RAG很直白在检索结果出来之后、进Prompt之前先做一个质量评估。评估器和Rerank不太一样它不只打分排序而是输出一个分级判断当前检索结果是可靠的、可能有点用的、还是完全不可靠的。如果是“完全不可靠”系统不会硬着头皮把坏内容塞给模型而是触发纠错动作换一个检索策略重试或者把链路切换成其他信息来源甚至直接放弃检索让模型用自身知识生成并明确标注不确定性。这个方案的价值在于给RAG系统增加了一条“否决通道”。我遇到的很多生产事故都是向量库返回了一堆相似但错误的内容模型照单全收一本正经地错。CRAG在入口处挡住了这类情况。实现时质量评估器可以用交叉编码器打分的阈值来判断也可以再叠加一个LLM对检索结果与问题相关度做判断。6.5 Agentic RAG把检索权交给智能体Agentic RAG是把检索决策权交给智能体。智能体拥有规划能力可以自行决定先查哪个工具、要不要调用代码解释器、要不要查数据库、检索结果不够时是否换一种检索方式还能维护多轮对话中的临时记忆。这种架构是当前最灵活的RAG形态。它能解决传统RAG做不了的任务比如用户问“帮我统计各地区的销量并排序”智能体会先检索销量数据表然后决定调用代码解释器做聚合计算而不是简单地把表内容塞进Prompt让模型硬算。但要清醒认识到灵活性的代价是失控风险。智能体可能调错工具、循环调用、偏离原本问题。生产环境中必须给智能体设置严格的动作空间和最大步数工具描述写清楚每个工具的输入输出做校验。Agentic RAG是25种架构里最“上限高但下限低”的入门可以先在小范围业务上验证。7. 怎么组合怎么选一个决策框架和我的实际搭配把25种架构都摆出来之后很多人问我的第一个问题往往是那我是不是都上不是。全部上等于每个环节都在叠加延迟和故障点成本翻几倍效果未必更好。选型的关键是回到业务本身的约束条件。7.1 从四个维度做选型决策我的决策框架是四个维度数据形态、问题类型、时延预算、准确性要求。数据形态看结构文档结构清晰的优先分层索引加父子分块结构混乱、口语化严重的语义分块和查询改写更重要。问题类型看需求高频问题的类型都是事实查询那关键词召回和重排是重点经常被要求做全局归纳图谱或摘要树更合适。时延预算很现实每加一次LLM调用就增加一次以秒计的网络耗时Rerank用GPU加速还能忍但检索前改写加检索后压缩全上一个问答可能奔着十秒去。准确性要求决定了能不能省步骤高准确场景如医疗法务HyDE这类带幻觉风险的直接不碰CRAG和Self-RAG这类校验机制是刚需。我总结了一张常用场景和推荐组合的参考表业务场景推荐架构组合选择理由企业内部文档问答父子分块 混合检索 RRF Rerank结构可靠精度优先成本可控客服高频问答Query Routing Adaptive RAG 上下文压缩四成简单问题不检索压延迟压成本长报告全局分析RAPTOR 图增强RAG需要跨章节聚合、关联推理医疗/法务强事实场景知识图谱增强 CRAG 可选Self-RAG用事实三元组约束生成入口拦截坏内容多源异构数据平台Query Routing Agentic RAG数据通道多需要动态调度和工具编排7.2 三个最容易踩的坑第一个坑是“集邮式选型”。把25种架构当勋章哪个新上哪个结果链路膨胀到无法维护定位一个问题要排查十几个环节。我接过的项目里最夸张的一个服务一次问答要调六次LLM延迟奔着二十秒过准确率也没比精简版好多少。第二个坑是TopK越大越好。有人为了“不漏”把每个查询的召回块数设成20甚至50全部进Prompt。实测下来超过一定阈值后噪声增多导致准确率不升反降。我的经验值召回阶段TopK取20到50重排后最终进入Prompt的前5到8这是大多数场景的甜点区。第三个坑是只看准确率不看成本分布。Rerank和Graph RAG都是重成本环节图增强RAG的构建成本更是高昂。小规模知识库硬上图谱收益抵不过投入最后变成一堆没人维护的三元组。7.3 我的精简实用组合与调参经验最后分享一套我目前最常用的生产级组合适合大多数企业内部知识库问答索引端用父子分块加Multi-Vector入口检索端用BM25和向量混合召回融合用RRFk取60精排用交叉编码器候选集取前20最终取前5上线前加一个轻量的Adaptive路由简单问题直接回答如果上下文敏感再加一个Contextual Compression做最后压缩。这一套搭配下来足以解决相当一部分的常见痛点。排序的稳定性和准确性都比裸向量检索高出不少。调参层面有几个细节值得留意。RRF的平滑常数k通常取60对这个参数不要过于纠结只要别取成个位数或几千影响有限。分块大小从500到800字符起调要看具体语料的段落逻辑技术文档可以用段落天然边界合同条款建议子块控制在300字以内。Rerank环节最容易被忽视的是候选集大小太小了双塔阶段漏召回的直接被永久错过太大了交叉编码器的延迟扛不住。经验上20到50是一个合理的区间。另外分享一组失败案例之前某客服知识库最初就是裸向量检索加TopK20所有结果直接进Prompt线上幻觉率非常高用户问“多久发货”模型都能答出订单号。后来改成混合检索加RRF再加重排把TopK压到5幻觉率显著下降。最后又加了Adaptive路由和查询改写把四成简单问题分流到直接回答通道平均响应时间缩短了一半。这一路下来每步都不复杂但叠加效果很可观。如果后续要继续深入可以考虑把检索链路的状态做成可观测的埋点记录每个环节的耗时和召回质量用线上数据反哺阈值调整。RAG系统的迭代不会一次到位但随着每个环节逐步打磨回答的精准度是能实实在在拉起来的。