说到RAG（检索增强生成）和它的七层架构，很多团队上手的第一个AI应用就是搭一套知识库问答。但真正做过生产级RAG的人都会承认一件事：这玩意儿远不是"文档切块、向量化、检索、丢给大模型回答"四步那么简单。我这两年帮人排查过不少RAG线上事故，最后发现几乎所有问题都能落到某一条具体的流水线环节上，而一张清晰的分层图，就是定位问题最快的工具。
什么是RAG的七层架构？简单说，就是把从"用户提问"到"最终答案"的完整链路拆成七个可独立优化、独立排查的环节：查询优化、混合检索、结果融合、重排序、上下文压缩、生成与溯源、评估与闭环。这篇文章不打算讲学院派的概念，我想直接用实战视角把这七层一层层剥开，告诉你每一层在解决什么痛点、常见方案有什么坑、哪些层能砍、哪些层绝对不能省。不管你是刚入门想搭一个本地RAG知识库，还是已经在线上被各种bad case折磨，这张图都能帮你把问题从"感觉哪里都不对"变成"就是第三层融合权重没调好"。
1. 从一次翻车现场说起：为什么需要一张七层架构图
上个月有个团队找我排查一个特别典型的案例。他们的企业知识库问答，用户明明问的是A产品，回答却总是混进B产品的参数。团队第一反应是改prompt，连着调了两天，效果忽好忽坏。后来把链路一层层拆开才找到真凶：检索层同时召回了A和B两个产品的文档，重排序层又没把B的相关内容压下去，大模型拿到混合上下文，自然就"串味"了。这个案例给我的感受很深：RAG系统不是一个整体，而是一条流水线。每个环节都有自己的故障模式，如果没有分层意识，排查起来就像在黑屋子里找一只没叫的猫。
1.1 先看这张图长什么样
这张图在我电脑桌面上存了很久，也分享了无数次。它不复杂，从左到右就是一条链：
- 用户问题进来，先过查询优化层（改写、补全、拆解问题）
- 带着优化后的查询走混合检索层（向量召回、关键词召回、必要时还有知识图谱召回）
- 多路召回的结果进结果融合层（用RRF这类算法合并排序）
- 融合后的候选集再进重排序层（用精排模型把真正相关的排到最前面）
- 排序后的文档做上下文压缩层（去噪声、压缩冗余、截取关键片段）
- 干净且精简的上下文才交给大模型走生成与溯源层（生成答案、附引用、按格式输出）
- 最后的答案和检索过程一起进评估与闭环层（离线指标、在线反馈、bad case回流）
底下还垫着一层"离线数据准备"，负责文档解析、清洗、切分、向量化，它不属于在线七层，但七层里每一层的表现都依赖这层干不干净。
你可能注意到了，这张图其实没有高深的内容，它把很多团队已经在单点做的事串成了一个可管理的框架。我见过太多团队在第五层（上下文压缩）上出问题，却拼命调第二层（检索）的embedding模型，方向完全反了。
1.2 谁需要这张图、怎么用
不同角色用这张图的方式不一样。
刚入门的人，把它当流程地图，对照着理解一个RAG项目从启动到上线的全貌，至少不会再问出"为什么我直接搜关键词也能找到文档，还要用向量检索"这种问题。
已经上线的团队，把它当故障排查手册。出bad case的时候先判断属于哪一层：查不到是检索引擎的事，查到了排不对是重排序的事，排对了答不对是生成或上下文压缩的事。定位到具体层，再动手优化，效率完全不一样。
做技术选型的人，可以拿这张图当checklist去审视框架：你选的框架覆盖了哪几层，哪几层需要自己写，哪些层的成熟度不够。这个后面我会详细讲。
2. 七层架构逐层拆解：每层解决什么问题、有什么坑
这一节是全文的核心，我尽量用"问题-方案-坑-实操建议"的结构来讲，不堆概念。
2.1 第一层 查询优化：把用户的话翻译成文档的语言
先说一个最常见的现象：用户的问题和文档里的表达方式经常不在一个频道上。用户问"上个月退货率为什么涨了"，但文档里写的是"六月退货率上升"；用户问"接口超时怎么办"，文档里写的是"Gateway Timeout错误处理"。向量检索虽然能理解语义，但对这种措辞差异比较大的情况，召回效果会明显打折扣。查询优化层就是专门解决这个问题的。
做法一般是三选一或者组合用：
- Query改写：用一个轻量LLM把用户问题改写成更适合检索的形式，比如补全指代词、补上文提及的实体名、把口语转成书面表达。
- 多查询扩展（Multi-Query）：让LLM生成用户问题的多个变体，比如从"怎么排查内存泄漏"扩展出"内存占用过高如何定位""OOM问题排查步骤"，用多个查询分别去检索再合并结果，相当于扩大召回面。
- HyDE（假设性文档嵌入）：让LLM先基于问题写一段"假设答案"，然后用这段假设答案的embedding去检索。这个思路很巧妙，适合文档风格和用户提问差异大的场景，因为假设答案的用词更接近文档。
不过我必须提醒一点：查询优化并不是免费的。每多一次LLM调用，就多一层延迟、多一层失败概率、多一层成本。我见过一个项目给所有查询都套上改写，结果简单问题反而被改写跑了偏，最后不得不用关键词命中率给查询做分层：命中率高就直接走检索，命中率低才进改写。
实操上的建议是先去查你线上的bad case，统计一下有多少比例的问题是"用户问题与文档表达不一致"造成的。如果这个比例很低，第一层可以只做最简单的问题补全，不用上HyDE这么重的方案。如果很高，优先考虑多查询扩展，因为它比HyDE更容易控制质量和解释。
2.2 第二层 混合检索：向量不是万能的
检索层是整个RAG的地基，也是最容易让人产生"我已经搞定了"错觉的一层。很多初学者的第一反应是：把所有文档切成block，用embedding模型转成向量，存进向量库，然后按相似度召回。这个流程demo没问题，但一上真实数据就露馅。
原因在于纯向量检索有天然短板：它对精确匹配不敏感。你在知识库里搜一个设备型号"TS-6280"，向量检索很可能把"TS-6820"也当成高相似度返回，因为它们的语义和字形都很接近，但业务上这就是两个完全不同的东西。代码、型号、人名、日期、金额这类强精确性的检索需求，向量距离根本表达不了"完全相等"这个概念。
所以生产级RAG基本都会做混合检索，典型组合是：
- 向量检索：负责语义相似，处理"意思相近但措辞不同"的查询。
- 稀疏检索（BM25/全文检索）：负责精确匹配，处理型号、专有名词、数字、代码片段。
- 可选的知识图谱检索：负责实体关系和多跳推理，这个后面聊KG-RAG时再展开。
工具选型上，向量库可以用FAISS、Milvus、Qdrant、Chroma，也可以用pgvector塞进PostgreSQL里和业务数据放一起。BM25可以用Elasticsearch，也可以直接用SQLite的FTS5，轻量场景完全够用。我见过有团队为了"架构先进"同时上了四五个检索组件，最后数据同步和运维成本高得离谱。早期最合理的做法是一路向量加一路BM25，先把效果基线打出来，再决定要不要加第三路。
2.3 第三层 结果融合：让多路召回乖乖合并
混合检索之后紧接着的问题就是：向量返回的100条和BM25返回的50条，怎么合并成一个排名列表？很多人第一次做融合时想当然：把分数标准化一下，然后加权求和。但向量相似度的分数分布和BM25的分数分布完全不是一个量级，而且不同检索器对"相关"的定义不同，直接加权常常把其中一路的结果整体淹没。
业界最常用的方案是RRF，全称Reciprocal Rank Fusion。它的核心思路特别朴素：不看分数，只看排名。对每一条文档，在所有检索结果里都有一个排名位置rank，那么它的融合得分就是：
score(d) = Σ 1 / (k + rank_i(d))
其中i遍历所有检索路，k是一个平滑常数，论文里推荐取60。这个公式的含义是：在某一路里排名越靠前，贡献的分数越高；但即使某一路没召回这条文档，也不会把它的总分归零。用排名而不是用原始分数，就天然回避了不同检索器分数量纲不一致的问题。
实操中需要注意两点。一是k值不是死的，倒序排列里排名靠前的影响很大，如果希望融合结果更照顾各路的前几名，可以把k调小一点；但k过小会让排名靠后的文档几乎得不到分，导致各路召回的重合区域被过度放大。二是如果有业务倾向，比如你确定关键词精确匹配的可靠性更高，可以对不同路的结果做加权RRF，而不是用纯RRF一刀切。
调试融合层有一个笨但有效的方法：先分别看每一路检索单独的效果，记下每一路的recall和top-k命中情况，再开始调融合。没有各路的baseline就直接调权重，你永远不知道是融合的锅还是某一路检索本身就拉胯。
2.4 第四层 重排序：粗排之后的精排逻辑
很多人不理解：向量检索已经按相似度排好序了，为什么还要单独做一层重排序？答案是：embedding模型计算出来的相似度，和"用户真正想要的相关性"之间存在一条不小的鸿沟。
embedding模型大多是双塔结构（Bi-Encoder），query和doc分别编码成向量，然后用余弦距离衡量相似度。这种方式快，但代价是query和doc之间的深层交互信息丢失了。它理解"这两个文本大概在同一个话题上"还可以，但判断"这句解释是否真正回答了这个问题"就很吃力。重排序层用的是Cross-Encoder结构，把query和doc拼成一句话一次性喂给模型，模型能看到两者之间每个token的交叉注意力关系，相关性判断要精准得多。
实际操作时，一般流程是：
- 前几层的混合检索和融合先粗召回50到100条候选文档。
- 把每个候选文档和query组成"query + 文档"的句子对。
- 用重排序模型（比如bge-reranker-v2-m3）给每个句子对打分。
- 按分数重新排序，只取前5到10条进入下一步。
这里有个成本问题：Cross-Encoder要真实计算query和doc的交互，比双塔模型慢得多。100条候选全量精排可能要花几秒到十几秒，这跟检索本身不在一个数量级。所以要控制粗排候选量，一般来说粗排召回50到100条再精排，是一个效果和延迟都比较平衡的窗口。
重排序模型的选型也很关键。常见的有bge-reranker系列、Cohere的Rerank API、monoT5等，选的时候注意三点：一是中文场景优先选训练语料覆盖中文的模型；二是如果业务数据很垂直，比如法律、医疗、代码，建议用业务数据做一点微调，精排效果提升非常明显；三是排行榜上分数最高的模型不一定最适合你的场景，拿一批真实bad case去测比信benchmark更靠谱。
2.5 第五层 上下文压缩：塞进Prompt之前先做减法
这一层是七层里最容易被忽略、却最容易让效果"差一口气"的环节。问题出在很多切分工具产出的chunk并不干净：一个大chunk里可能包含相关段落、不相关的背景介绍、重复的操作步骤。这些内容一并塞进prompt，会在两个方面造成伤害。
第一是token浪费。大模型按token计费，塞1000个token的垃圾进上下文，成本白白翻倍。第二，也是更隐蔽的，冗余信息会稀释相关性注意力。我用7B模型做实验时发现，同一个相关段落夹杂在两倍长度的无关内容里，模型引用它的概率会明显下降，甚至会被无关信息带偏。
常见的上下文压缩手段有这么几类：
- 句子级重要性过滤：把文档按句子拆开，用一个小模型或规则对每个句子和query的相关性打分，保留高分句子，去掉低分部分。
- 摘要式压缩：LLM对检索回来的长文档做摘要，把最核心的信息提炼出来。适合文档长、但核心观点集中的场景，缺点是有可能丢失细节证据。
- 专用压缩模型或算法：比如LLMLingua这类方案，能在保持语义的前提下对prompt做token级别的压缩，压缩率可以达到数倍，但引入额外模型组件，需要看延迟是否可接受。
我在实际项目里的建议是：先看你的chunk长度分布。如果80%的chunk在300个token以内且内容结构完整，那上下文压缩层可以先只做去重和截断，不必上重型方案。如果chunk动不动就是1000token以上的长文，那一定要做压缩，不然生成质量会和召回质量出现明显倒挂——明明检索对了，答案却答得稀烂。
2.6 第六层 生成与溯源：答案要能用、要敢用
前五层干的所有工作，都是为了给第六层的大模型提供一份最高质量的"参考资料"。但生成层本身也有技术含量，不只是"把检索结果拼进prompt再问一句"这么简单。
第一个问题是幻觉。即使检索完全正确，LLM仍然可能自由发挥，编造文档里没有的细节。缓解方法是在prompt里做硬约束，明确告诉模型：只能基于提供的资料回答；资料里找不到的，直接说"根据现有资料无法确认"。我给一个生产项目的prompt加完这句话之后，无中生有的bad case大概下降了40%，成本几乎为零。
第二个问题是引用和溯源。企业场景里，答案没有出处等于不可用。做法是在prompt里强制要求答案格式：先给出结论，再列出证据来源，例如写成"根据[来源A-文件名-页码]……"这种结构，如果用的是JSON输出模式，还可以定义明确的schema：
{ "answer": "最终回答文本", "citations": ["来源1", "来源2"], "confidence": "high|medium|low" }这样生成的结果可以被程序直接解析、校验，后面接自动化质检也方便。
第三个问题是引用真实性校验。这一步很多人会漏掉，但其实特别重要：模型可能引用了检索结果里的一个不相关片段，造成"看似有出处、实际出处对不上"。我建议在生成之后加一道轻量校验，把答案里的核心实体和检索块做一次匹配检查，发现关键断言在证据里找不到支撑时，要么拒答，要么降级为低置信度输出。
2.7 第七层 评估与闭环：知道好不好，才知道怎么改
第七层也是在实际项目里被砍得最频繁的一层，因为它不像前面几层那样"上线即有收益"。但我的经验是，没有评估层的RAG系统，优化等于盲人摸象。你改了检索、调了prompt，不知道是好是坏，改完心里完全没底，线上出问题也不知道该怪谁。
评估层一般分两条线。
离线评估：构建一批固定的测试集，通常50到200条典型问题，每条标注期望检索到的文档和期望答案。跑完RAG流程后，用一组指标衡量表现：检索质量看Recall@K、MRT、NDCG；答案质量看Faithfulness（回答是否忠于召回文档）、Answer Relevancy（回答是否切题）、Context Relevance（召回的上下文是否相关）。这些指标就算不想自己实现，也有RAGAS这样的开源库可以直接用。
在线反馈：在对话界面放"赞成/反对"按钮，把用户点踩的问题标记成bad case，定期拉出来归因。归因的方法正好用上七层图：先判断是检索层没召回到关键文档，还是重排序把关键文档压下去了，还是召回内容相关但模型没用上。连续几个bad case落在同一层，基本就能确定下一步优化方向在哪。
闭环是第七层的精华：把bad case回流成新的评测用例，让系统越用越准。很多团队不重视这个，导致评估集永远停在第一版，优化方向全靠拍脑袋，效果上不去也就不奇怪了。
3. 架构落地：哪些层能砍、哪些层别省
如果每次做RAG都必须上全七层，那对于小团队和轻场景来说成本太高了。这一节聊点实在的，在不同约束条件下该怎么取舍。
3.1 简单场景为什么四层也够
先给一个决策参考：如果你的场景是FAQ问答或小规模文档检索，文档总量在几百篇以内，问题类型单一，那最少四层也能跑通：混合检索、结果融合、生成与溯源、最简评估。查询优化可以不做，因为FAQ问题高度标准化；重排序可以先用粗排凑合，因为文档量少、分组清晰，向量召回精度已经可以接受；上下文压缩可以先靠切分质量保证，chunk小而且干净就行。
但如果你的场景是要上线给用户用、知识库超过几千篇文档、问题类型开放多变，那重排序和评估层绝对不能省，上下文压缩也值得投入。我见过一个团队为了省事把重排序层砍了，上线后用户反复反馈"搜到了相关文档但回答完全跑偏"，最后花了一周补重排序逻辑，期间流失了不少用户，得不偿失。
判断标准很简单：你的bad case分布在哪里，就把资源往哪层倾斜，而不是看哪层"流行"就上哪层。
3.2 用Ollama搭一个零基础本地RAG，七层里实际用了几层
很多人会搜"Ollama搭建简易本地RAG知识库怎么做"，这里我直接分享一下轻量落地路径。我自己在Mac上跑过一套，数据量不大，纯本地推理，零成本复现。
硬件环境是Apple Silicon的MacBook，跑Ollama加载两个模型：一个生成模型，比如qwen2.5:7b，负责回答；一个embedding模型，比如nomic-embed-text或者更偏中文的bge-m3，负责向量化。向量库可以用Chroma，零配置，一个Python进程直接跑，配合sqlite-vec也行。文本拆解我推荐markitdown或PyMuPDF把PDF、Word转成Markdown或纯文本，然后用RecursiveCharacterTextSplitter按块切分，块大小500到800字符，重叠100字符左右。
这个方案实际用到的RAG环节是：检索（向量一路）、生成与溯源（prompt里写清楚来源）、以及最简陋的人肉评估（自己问几条问题看结果）。查询优化、融合、重排序、上下文压缩都没有做。这就意味着它只能当个人知识库或个人实验环境，不能直接作为生产服务对外。
在Mac上跑的时候有三个经常遇到的坑：
- 内存：7B模型和embedding模型同时常驻内存，16GB内存的机器会明显吃力，建议用支持内存卸载的Ollama配置，或者换量化程度更高的模型。
- 中文embedding效果：无脑装英文embedding模型会导致中文检索效果惨不忍睹，至少在CPU量化场景里先跑一轮"油手好闲"测试。
- 切分质量：直接用默认分隔符切分，很容易把表格、代码块拦腰截断，建议先用markitdown把文档结构还原成Markdown标题层级，再按标题层级做结构感知切分。
3.3 用七层视角审视开源框架
现在开源RAG框架很多，LangChain、LlamaIndex、Dify、RAGFlow、FastGPT，Java生态还有LangChain4j。好多团队一上来就问"该用哪个框架"，我的建议是反过来：用七层图当checklist，看框架已经帮你做了哪几层，缺哪几层。
拿我常用的几个来说：
- LlamaIndex的检索和索引体系成熟，数据连接器多，重排序和查询优化也有内置组件，但融合和评估更多是"留了接口"，需要自己搭。
- LangChain生态组件全，七层都有对应模块，但抽象层次多、封装深，出了问题不好排查。适合团队里有人熟悉它内部结构的情况。
- Dify和FastGPT这类偏产品化的平台，把很多层做成了可视化配置，查询优化、检索、重排序都有界面开关，适合快速POC，但深度定制空间有限。
- LangChain4j是Java系的RAG框架，模型、向量库、知识库的Java接入完善，适合团队技术栈是Java且有现成基础设施的情况。它也在不断补齐Easy RAG这类面向中文场景的便捷工具。
框架只能帮你解决三成问题，剩下七成在数据治理、切分策略和评估闭环上，这些是任何框架都替你做了不的。选框架的第一原则是：团队能hold住、出了问题能自己排查，而不是谁的Star最多。
4. 聊点真话：RAG瓶颈到底卡在哪
围绕RAG的评价向来两极分化：有人说它是大模型落地最实用的方案，有人说它是"高级玩具"。两边我都能理解，但说RAG不行的人，绝大多数是没想明白瓶颈到底在哪。
4.1 召回的上限决定了回答的下限
这是RAG最核心的一条规律：生成层再怎么优化，也补不齐检索层丢失的信息。如果相关文档压根没被召回来，大模型就只能靠幻觉硬撑。很多团队在生成层疯狂下功夫，却不愿意回头审视切分策略和embedding效果，方向全拧了。
想让召回上限足够高，一要保证文档解析干净，二要在切分颗粒度上做实验，三要根据业务特点决定是否要上混合检索和知识图谱。这个排列是固定的，顺序错了，越优化越乱。
4.2 语义被切碎，是数据预处理的原罪
切分是RAG所有环节里最"不起眼"但影响最深远的。默认的按字符数量切分，会把一个完整的操作步骤或者一个表格拦腰砍成两半，导致语义残缺。检索的时候，"步骤A为什么卡住"和"步骤B的注意事项"明明是同一个主题，却因为被切进了两个chunk，只能召回一半。
比较靠谱的做法是先做结构还原：用文档解析工具把PDF、Word还原成带标题层级的Markdown，再按标题语义分块。表格和代码块要尽量整体保留，宁可块大一点，也别切成碎片。这一步没有银弹，只能针对自己的文档类型反复调。
4.3 评测缺位，优化等于没有方向盘
前面讲评估层的时候我已经强调过，这里再补一个观点：RAG优化的核心循环是"定义问题-定位层-改-再评估"。很多人不做这个循环，上线之后全靠看用户反馈猜问题，结果每一次改动都是赌运气。
哪怕先人工标注20条测试集，也比没有强。有了这20条，你改完anything都能知道是变好了还是变差了。评测不用一步到位，可以随bad case积累慢慢扩充，关键是让系统进入可度量的闭环。
4.4 从平铺文本到知识图谱：RAG的进阶方向
最后说一个热度很高、但也容易被滥用的方向：KG-RAG和Ontology RAG。很多人把普通RAG和知识图谱RAG搞混，简单说，普通RAG处理的是非结构化文本，擅长语义搜索和开放回答；知识图谱RAG处理的是实体和关系，擅长多跳推理和结构化查询。比如"哪些客户的合同会在本季度到期且金额超过100万"，这类需要跨文档关联、聚合统计的问题，纯向量检索基本束手无策，知识图谱反而得心应手。
但知识图谱的构建成本很高，要设计本体、抽实体、建关系、做数据清洗，没有明确的业务价值就不建议为了"技术先进"而上。现实中更多见的是折中方案：关键实体建立映射表，检索时先做实体对齐，再从知识图谱里取关联信息一起拼进上下文。
结构化和非结构化工具的组合才是企业落地的常态。别指望一种方案打天下，先搞清楚自己的问题类型，再决定要不要碰图谱RAG。
5. 常见问题速查表与避坑提醒
“RAG能不能存图片”“本地文本拆解工具用哪个”“Mac上搭RAG有什么坑”“Wiki类知识库怎么办”这类问题我经常在社区里碰到，单独拿出来集中回答一下。这几个问题看着琐碎，但会直接影响你落地RAG时的体验。
5.1 RAG知识库能存储图片吗
可以存，但最关键的认知是：传统RAG流水线本质上是一个文本处理系统，embedding模型并不吃图片。图片必须经过一道"翻译"才能进入知识库。
推荐的流程是：用OCR提取图片里的文字，用视觉大模型生成图片的内容描述，最后把"OCR文字+内容描述"作为该图片的文本块入库。用户检索到这块文本再返回给多模态大模型，才能把原图呈现出来。如果直接把图片本身塞进去，检索和生成都会失效。如果文档里有大量图表型内容，建议先试OCR效果，再用视觉模型补描述，否则图表里的关键信息会全部蒸发。
5.2 本地RAG文本拆解工具怎么选
文本解析的质量直接影响RAG的上限，单纯的"读PDF提取文字"远远不够。本地环境没有在线API的情况下，我的建议是按文档类型分：通用办公文档用markitdown转Markdown，效果不错；复杂PDF包括扫描件和复杂表格，用unstructured或PyMuPDF；批量处理文档时先统一转MD，再用结构感知切分。
常见的切分逻辑是结合分隔符和标题层级，不要一见到字符数就切。业界用得多的RecursiveCharacterTextSplitter就是基于一组分隔符递归切块，放在LangChain和LlamaIndex里都能直接用。配合结构感知切分，可以把完整表格和代码块变成独立块，避免语义被打断。
5.3 Mac上搭建本地RAG的注意事项
Mac本地实验的体验比Windows顺畅很多，内存是首要瓶颈。建议模型选量化版本，embedding模型常驻内存，生成模型按需加载，16GB内存加4核也能跑得起来。RAG的可行路径可以选择：Ollama负责模型加载，Chroma做向量存储，Python脚本组装RAG流程。这套组合的优点是部署不复杂、能跑起来；缺点是生产环境没有并发能力。
另外要特别注意Apple Silicon的Ollama对某些量化方式支持不稳定，选型前先跑一个简单的矩阵评测，把常见query的结果和首token延迟记下来。很多用户抱怨本地RAG"慢得出奇"，大概率是模型没走GPU推理或量化选错了。
5.4 Wiki类知识库做RAG，和普通文档有什么不同
Wiki类知识库的结构比一堆PDF复杂得多：页面之间有链接关系、有模板标签、有历史版本、有导航分类。做一个Wiki问答，最怕的就是把整页HTML直接切块，切出来的内容全都带着导航菜单和版权尾巴，检索时全是噪声。
我的做法是先按wiki页面为单位做页面级别的清洗，去除导航、页脚、模板噪音，再根据页面的目录结构分块。还有一点注意：Wiki里经常出现同义词和缩写，比如"API"和"应用程序接口"可能分布在不同页面，这种场景最好在查询优化层做一次术语扩展，召回率会明显提升。如果Wiki自身有搜索接口，也可以把它作为BM25之外的一路召回通道接进混合检索。
最后说点实操里的心里话
我电脑上一直放着一张RAG七层架构图，每出现一个bad case，就先在图上打一个点，连续几个bad case落在同一层，我就去改那一层。这个习惯帮我少走了很多弯路。很多人把RAG效果不好归咎于"大模型太笨"或者"纯天然噪声数据背后有什么玄学"，其实绝大多数问题都能落到具体某一层，有明确解法。
如果你打算从零搭一套自己的RAG，建议也别急着往架构里堆东西。先跑最小闭环，再按七层图逐层体检。哪一层出问题就补哪一层，这样搭建的知识库，效果和可维护性都会比一次性堆满所有组件好得多。
