企业官网建设流程全解析

最近一年我接触了不少做知识库问答、企业私有大模型应用的团队，听最多的一句话就是“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更彻底，把整个流程拆成可插拔的模块，检索器、生成器、记忆模块、路由模块都能独立替换，衍生出很多新的组合结构。

1.3 25种架构全览：一张表看懂全局

我先给一张总览表，把25种架构按职责位置分成六个大类。后面每个章节按这个表逐类展开，每一条都会讲清楚它解决什么问题、适用什么场景、有哪些坑。这张表本身建议收藏，做方案评审时对照着看非常有用。

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这类校验机制是刚需。

我总结了一张常用场景和推荐组合的参考表：

7.2 三个最容易踩的坑

第一个坑是“集邮式选型”。把25种架构当勋章，哪个新上哪个，结果链路膨胀到无法维护，定位一个问题要排查十几个环节。我接过的项目里，最夸张的一个服务一次问答要调六次LLM，延迟奔着二十秒过，准确率也没比精简版好多少。

第二个坑是TopK越大越好。有人为了“不漏”，把每个查询的召回块数设成20甚至50，全部进Prompt。实测下来，超过一定阈值后，噪声增多导致准确率不升反降。我的经验值：召回阶段TopK取20到50，重排后最终进入Prompt的前5到8，这是大多数场景的甜点区。

第三个坑是只看准确率不看成本分布。Rerank和Graph RAG都是重成本环节，图增强RAG的构建成本更是高昂。小规模知识库硬上图谱，收益抵不过投入，最后变成一堆没人维护的三元组。

7.3 我的精简实用组合与调参经验

最后分享一套我目前最常用的生产级组合，适合大多数企业内部知识库问答：索引端用父子分块加Multi-Vector入口；检索端用BM25和向量混合召回；融合用RRF，k取60；精排用交叉编码器，候选集取前20，最终取前5；上线前加一个轻量的Adaptive路由，简单问题直接回答；如果上下文敏感，再加一个Contextual Compression做最后压缩。

这一套搭配下来，足以解决相当一部分的常见痛点。排序的稳定性和准确性都比裸向量检索高出不少。

调参层面有几个细节值得留意。RRF的平滑常数k通常取60，对这个参数不要过于纠结，只要别取成个位数或几千，影响有限。分块大小从500到800字符起调，要看具体语料的段落逻辑，技术文档可以用段落天然边界，合同条款建议子块控制在300字以内。Rerank环节最容易被忽视的是候选集大小：太小了，双塔阶段漏召回的直接被永久错过；太大了，交叉编码器的延迟扛不住。经验上20到50是一个合理的区间。

另外分享一组失败案例：之前某客服知识库，最初就是裸向量检索加TopK=20，所有结果直接进Prompt，线上幻觉率非常高，用户问“多久发货”模型都能答出订单号。后来改成混合检索加RRF，再加重排把TopK压到5，幻觉率显著下降。最后又加了Adaptive路由和查询改写，把四成简单问题分流到直接回答通道，平均响应时间缩短了一半。这一路下来，每步都不复杂，但叠加效果很可观。

如果后续要继续深入，可以考虑把检索链路的状态做成可观测的埋点，记录每个环节的耗时和召回质量，用线上数据反哺阈值调整。RAG系统的迭代不会一次到位，但随着每个环节逐步打磨，回答的精准度是能实实在在拉起来的。