“RAG 你肯定知道但你能把 RAG 的策略讲清楚吗”最近面试中被问到这个问题的人不少。很多候选人都能说出“检索增强生成”的全称也能画出“文档切块—向量化—检索—拼接 Prompt—大模型生成”的流程图但一旦面试官追问“你如何在项目里做召回”“多路召回结果怎么融合”“为什么检索到了相关内容大模型还是答偏了”就答不上来了。这篇文章不是为了背八股而是想把 RAG 面试中最容易拿分的一个分析框架完整拆开三层检索策略。无论你是刚开始接触 RAG还是已经在做知识库问答、智能客服、企业文档检索这套思路都能直接用来回答问题、设计系统、排查线上故障。1. 为什么面试官爱问 RAG 策略RAG 的火爆不是偶然。大模型虽然知识面广但存在幻觉、知识陈旧、无法访问私有数据等问题。RAG 通过“先检索、再生成”的方式把外部知识库接入大模型生成流程既提升了回答的准确性又让模型输出有据可查是目前企业落地大模型应用最主流的方案之一。但面试官问“RAG 策略”重点往往不是“RAG 是什么”而是“你会怎么设计一套可用的 RAG 系统”。搜索引擎的检索技术、推荐系统的召回排序、大模型的 Prompt 工程、甚至向量数据库的选型都会在这个问题里被串联起来。所以这个问题表面考 RAG实际上考的是你对“检索—排序—生成”整个链路有没有结构化认知。更关键的是“策略”这个词意味着你要告诉面试官在面对候选文档成千上万、用户 Query 千奇百怪、检索结果良莠不齐的情况下你的系统每一步做了什么决策、为什么做这个决策、如何衡量效果。把 RAG 拆成三层检索策略来回答是一种既清晰又有深度的答题结构。1.1 三层检索策略指什么我推荐你把 RAG 的检索链路拆成三层第一层查询理解层。负责把用户原始输入变成“适合检索的 Query”。比如补全指代、纠错、改写、拆解复杂问题。第二层召回层。负责从大规模文档库中快速找到候选内容。常见手段有 BM25 关键词召回、向量语义召回、混合检索、多路召回。第三层融合重排层。负责对多路召回结果做融合、过滤、精排并最终组装成有利于大模型生成的上下文。这三层合在一起就是一套完整的 RAG 检索策略。面试时从这三层展开既不会漏掉关键点又能体现出你对工程细节的把控。1.2 三层检索背后的核心指标理解三层检索先要理解 RAG 系统最关心的几个指标召回率Recall正确答案有没有被检索出来。精确率Precision检索出来的结果有多少是真正相关的。命中率Hit RateTop K 结果中是否包含可支撑答案的片段。答案准确率 / 幻觉率最终生成结果是否忠于检索证据。你会发现查询理解层和召回层主要影响召回率融合重排层主要影响精确率而最终 Prompt 的组装方式直接影响幻觉率和答案质量。三层不是孤立的而是层层递进、环环相扣。2. RAG 基础检索到底在解决什么问题在展开三层检索之前先统一一下对 RAG 的理解。RAG 的全称是 Retrieval-Augmented Generation中文叫检索增强生成。它的思路很直接不指望大模型记住所有知识而是在生成回答前先从外部知识库中检索出相关文档片段把这些片段作为上下文交给大模型让模型基于证据回答。一个典型 RAG 系统的离线部分包括文档解析、清洗、切块Chunking、向量化Embedding、写入向量数据库。在线部分包括用户 Query 处理、检索召回、融合重排、构建 Prompt、大模型生成。2.1 检索模块为什么是 RAG 的胜负手很多人一开始做 RAG 会把重心放在 Prompt 上但实际项目跑下来会发现80% 的效果问题出在检索链路。检索结果不相关Prompt 写得再好大模型也只能“一本正经地胡说八道”。检索模块要解决的核心矛盾有两个第一Query 与文档之间的语义鸿沟。用户问“这个月工资为啥少了”文档里写的是“薪酬结构、绩效扣款、社保调整”两者字面上完全不重叠单纯靠关键词匹配大概率召回不到。第二候选文档数量与质量之间的平衡。向量检索可以把上百万文档的召回做到毫秒级但召回的 Top K 里往往掺杂大量“语义相似但不相关”的内容需要重排层做二次筛选。三层检索策略本质上就是围绕这两个矛盾设计的解决方案。2.2 从朴素 RAG 到进阶 RAG网上经常有人把 RAG 分为 Naive RAG、Advanced RAG、Modular RAG 几个阶段。朴素 RAG 就是最简单的“切块—向量化—检索—生成”流程。进阶 RAG 会在检索前增加 Query 改写在检索后增加重排。模块化 RAG 则把整个链路拆成更细的模块可以自由组合。如果面试官问你“做过哪些 RAG 优化”你可以顺着三层检索的思路回答查询理解层做了 Query 改写、HyDE、意图路由。召回层做了混合检索、多路召回、切块策略调优。融合重排层做了 RRF 融合、Cross-Encoder 重排、引用溯源。这样回答既系统又显得你有真实落地经验。3. 第一层查询理解与预处理策略很多 RAG 项目把用户输入直接丢进向量检索这样做不是不行但效果往往不稳定。用户的问题通常是口语化的、简短的、有指代的甚至包含错别字。直接拿这样的 Query 去做向量召回召回质量很难保证。查询理解层要做的就是解决“用户问题不是好的检索式”这个问题。3.1 Query 改写把口语变成适合检索的表述Query 改写是最常用、也是性价比最高的一层策略。常见做法包括指代消解用户先问“张三的项目延期了”接着问“他后续有什么计划”这里的“他”需要补全为“张三”。问题补全用户问“Java 内存模型”可以补全为“Java 内存模型是什么有哪些组成部分”同义扩展把“工资少了”扩展成“薪资减少、薪酬变动、扣款原因”。纠错把“RAG 怎么优化”里的错别字修正。最简单的 Query 改写可以用规则实现比如关键词替换更灵活的方式是用大模型改写 Query。下面是一个基于大模型改写的伪代码示例你需要把它替换成项目实际使用的模型 SDK# 伪代码Query 改写流程 # 实际使用时请替换为你的大模型调用 SDK def rewrite_query(original_query, chat_model): prompt f 你是一个专业的检索查询改写助手。 请把用户的问题改写成适合搜索引擎和向量检索的查询语句。 要求 1. 补全指代和缺失成分 2. 保留原始意图 3. 输出不要啰嗦直接给出改写结果 用户问题{original_query} 改写结果 rewritten chat_model.complete(prompt) return rewritten.strip()这种改写虽然简单但在实际业务里能明显提升检索命中率。比如用户问“它怎么配置”如果你不把“它”还原成具体产品名向量检索时“它”这个 token 几乎不携带语义信息还会干扰向量分布。3.2 意图识别与检索路由企业级 RAG 通常不只有一个知识库。可能有产品文档库、技术工单库、制度规范库、代码仓库文档库。用户问“接口报错 401”应该去技术文档和工单里检索用户问“请假流程”应该去制度规范里检索。这时候可以在查询理解层增加意图识别与路由模块。路由方式有两种规则路由通过关键词、正则判断 Query 属于哪个领域然后路由到对应索引。比如包含“报错、异常、接口、代码”就走技术库包含“请假、报销、考勤”就走制度库。模型路由用一个大模型分类器判断 Query 的意图返回对应的知识库名称和检索参数。# 伪代码意图路由 def route_query(original_query, chat_model): prompt f 请判断用户问题属于哪个知识库 A. 技术文档库 B. 制度规范库 C. 产品使用手册 用户问题{original_query} 请只输出 A/B/C route chat_model.complete(prompt).strip() return route面试时提到意图路由最好再补一句“路由决策本身也需要兜底比如模型分类置信度低时默认走全库召回”这会让面试官觉得你考虑过边界情况。3.3 HyDE让 Query 先变成“答案的样子”HyDEHypothetical Document Embeddings是查询理解层另一个有价值的策略。它的核心思想是先用大模型根据用户问题生成一个“假设性答案”或“假设性文档”再用这个假设文档去做向量检索。为什么这样做因为用户问题往往很短而知识库里的文档片段很长。在向量空间里短 Query 的向量和长文档的向量分布不完全一致。如果先让大模型生成一段“如果这个问题有答案答案大概会长什么样”的文本再用这段文本去做检索Query 与文档的语义空间会更接近。# 伪代码HyDE 流程 def hyde_retrieve(original_query, chat_model, vector_search): # 1. 生成假设性文档 hypothetical_doc chat_model.complete( f请简要回答以下问题假设你拥有相关知识{original_query} ) # 2. 用假设文档向量去检索 candidates vector_search(hypothetical_doc, top_k10) return candidatesHyDE 不是万能的。它依赖大模型的生成质量如果模型生成的假设文档偏离真实答案检索效果反而会下降。实际项目中可以做 A/B 测试对比开启和关闭 HyDE 的命中率再决定是否上线。3.4 子问题分解处理多跳问题有些用户问题不是单轮检索能解决的。比如“张三负责的项目里哪个延期了对应的负责人是谁”这需要先找到张三的项目再找到项目延期信息再关联负责人。这就是所谓多跳问题。子问题分解的策略是把复杂问题拆成多个简单子问题逐个检索最后汇总。可以用大模型生成子问题列表再对每个子问题走一遍“改写—召回—重排”流程最后把多轮检索结果合并交给生成模型。# 伪代码子问题分解 def decompose_question(question, chat_model): prompt f 请把以下复杂问题拆解为多个简单的子问题每个子问题单独一行输出。 要求子问题可以在知识库中独立检索到答案。 问题{question} sub_questions chat_model.complete(prompt).strip().split(\n) return sub_questions不过子问题分解在面试中属于加分项实际落地时要注意控制检索次数否则延迟会明显上升成本也会翻倍。4. 第二层召回策略召回层是 RAG 检索链路的核心它的目标是在海量文档中快速圈定一小批候选片段。召回讲究“准中带全”宁可多召回一些不相关的内容也不能让正确答案漏掉。如果正确答案根本没进入候选集后面的重排再厉害也无力回天。4.1 稀疏检索BM25 关键词召回BM25 是传统搜索引擎中最经典的排序函数也是 Lucene、Elasticsearch 默认的相似度算法之一。它的核心思路是一个词在文档中出现的频率越高同时这个词在语料库中越罕见那么文档与 Query 的相关性就越高。BM25 的优势在于精确匹配能力强适合专用名词、型号、编号、代码片段。可解释性好能直接告诉用户命中了哪些关键词。不需要训练模型开箱即用。缺点是它对语义理解无能为力。用户说“车跑不动”文档里写的是“发动机动力不足”字面完全不匹配BM25 就召回不到。在 Python 中可以使用 rank_bm25 这类库实现但理解它的原理比调库更重要。核心公式可以简化为对 Query 中每个词计算 IDF逆文档频率与词频的加权和。IDF 越高说明这个词越有区分度。4.2 稠密检索向量语义召回向量检索是 RAG 区别于传统搜索引擎的核心。它的思路是用 Embedding 模型把文本映射成高维向量语义相近的文本在向量空间中的距离也更近。Query 向量化后在向量数据库中查询最近邻。向量检索的优点非常明显能处理同义词、 paraphrase、口语化表达。能理解浅层语义关系。配合 FAISS、Milvus、Elasticsearch 等引擎可以支撑大规模数据。但在实际项目中向量检索也经常出问题模型与文档领域不匹配Embedding 效果差。相似度阈值设置不当召回一堆无关内容。长文档切块不合理语义被切断。所以现代 RAG 系统很少只用向量检索而是用 BM25 向量检索的混合模式。4.3 混合检索BM25 与向量的组合混合检索的逻辑不复杂同时用 BM25 和向量检索各召回一批结果然后合并。这样既保留了关键词的精确匹配能力又引入了语义泛化能力。举个例子用户问“如何解决 Redis 缓存穿透”BM25 能精确命中“Redis 缓存穿透”相关的技术文章向量检索能召回“缓存失效、热点 Key 打爆数据库”这类语义相近但字面不同的内容。两者结合召回率会明显提升。当然混合检索的关键不是“同时查两个索引”而是“怎么合并结果”。这就是第三层融合重排要做的事情。4.4 切块策略召回效果的隐形决定因素很多 RAG 项目调了很久的模型却发现效果没有提升最后定位到问题出在切块上。切块Chunking决定了知识库中以什么粒度组织文档片段直接影响检索效果。切块太小信息不完整。比如一段产品介绍被切成 100 个字的小块单块可能只包含“产品名称”不包含“功能、参数、使用场景”检索到了也撑不起完整答案。切块太大噪声太多。一个 2000 字的块里可能只有 200 字与问题相关向量化后相关信号被稀释精度下降。常见的切块策略包括固定大小切块、递归字符切块、按结构切块标题、段落、Markdown 层级以及基于语义的切块。下面是一个递归字符切块的简化实现思路是设置一个目标块大小和重叠窗口# 简易递归切块示例实际项目可参考 langchain 等框架的实现 def simple_recursive_chunk(text, chunk_size500, overlap50): chunks [] start 0 text_len len(text) while start text_len: end start chunk_size chunk text[start:end] chunks.append(chunk) if end text_len: break start end - overlap return chunks切块策略没有标准答案需要根据文档类型、Embedding 模型、下游任务来调。工程上建议把不同切块参数放到评估集上做实验而不是靠感觉拍脑袋。4.5 多路召回与知识图谱除了 BM25 和向量检索企业级 RAG 还会引入更多召回通道。常见的多路召回包括关键词召回适合代码、型号、专有名词检索。向量召回适合语义相似检索。知识图谱召回适合实体关系查询比如“A 公司的创始人是谁”。规则召回基于业务规则精确匹配比如“查询 2024 年 3 月的财报”。多路召回的核心价值是“多路互补”。没有一条召回通道是万能的但多个通道的并集往往能覆盖更多用户问题。代价是检索结果更多、噪声更大因此对第三层的融合重排要求更高。5. 第三层融合与重排策略很多 RAG 项目做到“混合检索”就停了直接把多路结果拼接进 Prompt。但你会发现五路召回、每路 Top 10加起来几十个片段如果一股脑全塞给大模型不仅 Token 成本爆炸大模型还会被不相关内容干扰反而答错。第三层融合重排就是解决“结果太多、噪声太大、顺序不合理”的问题。5.1 RRF简单高效的融合算法RRFReciprocal Rank Fusion倒数排名融合是混合检索中最常用的融合算法。它的思路是如果一个文档在多个召回结果列表中的排名都比较靠前那么它融合后的分数就高。RRF 公式很简洁score(d) Σ 1 / (k rank_i(d))其中 rank_i(d) 是文档 d 在第 i 路召回中的排名k 是一个常数一般取 60。这样排名第 1 的文档贡献 1/61排名第 60 的文档贡献 1/120排名越靠前贡献越大。def reciprocal_rank_fusion(ranked_lists, k60): RRF 融合 ranked_lists: 多路召回的排名列表每个列表是 doc_id 的有序数组 返回按融合分数降序排列的 (doc_id, score) 列表 scores {} for docs in ranked_lists: for rank, doc_id in enumerate(docs): # rank 从 0 开始所以实际排名是 rank 1 scores[doc_id] scores.get(doc_id, 0) 1.0 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue) # 使用示例 bm25_results [doc_a, doc_c, doc_b] vector_results [doc_b, doc_d, doc_a] fused reciprocal_rank_fusion([bm25_results, vector_results]) print(fused)RRF 最大的优点是简单、稳定、无需训练、对分数尺度不敏感。它不关心每路召回用的什么分数模型只看排名。这在实际工程中非常实用因为向量检索的相似度分数和 BM25 的分数根本不在一个量纲上直接加和没有意义RRF 规避了这个问题。5.2 Rerank用 Cross-Encoder 做精排RRF 只是一次粗糙融合它能解决“多路合并”的问题但解决不了“召回结果与 Query 相关度参差不齐”的问题。更精细的做法是引入重排模型。主流方案是 Cross-Encoder 重排。与 Bi-Encoder把 Query 和文档分别编码成向量再算相似度不同Cross-Encoder 会把 Query 和候选文档拼接成一个长文本一起送入编码器输出一个相关性分数。因为模型能看到 Query 与 Document 的完整交互相关度判断往往更准。# 伪代码Cross-Encoder 重排流程 def rerank(query, candidates, rerank_model): scored [] for doc in candidates: score rerank_model.score(query, doc) # 替换为实际重排模型 API scored.append((doc, score)) scored.sort(keylambda x: x[1], reverseTrue) return scored[:5]重排层的价值在混合检索后特别明显。向量检索召回的 Top K 里经常有“语义很接近但不包含答案”的片段Cross-Encoder 能把这些噪声排到后面从而提升最终上下文的质量。5.3 阈值过滤与去重融合重排之后还需要做几件“琐碎但必要”的事相似度阈值过滤向量检索分数低于阈值的片段直接丢弃。去重同一份内容可能以不同切块方式命中多次需要按文档来源去重。上下文窗口裁剪LLM 上下文有限需要按权重截取 Top N 个片段。时效性加权HR 政策、新闻类问题越新越重要。这些规则看起来不起眼但能避免不少线上问题。比如有些知识库重复内容多去重前上下文里塞进三份几乎一样的段落既浪费 Token 又容易让模型重复回答。5.4 引用溯源与 Groundedness引用溯源是 RAG 面试中一个越来越重要的考点。它的核心思想是生成结果必须能对应到检索证据否则就算答案看起来正确也没有可信度。具体做法有两种第一种在 Prompt 中强制要求模型“只基于上下文回答并在每个论点后标注来源片段”。例如请基于以下检索片段回答问题。如果问题不在片段中请回答“知识库中未找到相关信息”。 每个回答点后标注来源例如 [1]、[2]。第二种在生成结果后做 Groundedness 校验用另一个模型检查答案中的每个关键句是否被检索片段支持。如果发现“无证据断言”就标记为幻觉内容。面试时提到这一层能明显体现你对 RAG 生产落地的理解深度而不是只会调接口。5.5 组装 Prompt检索结果如何进入上下文检索质量再高最终都要通过 Prompt 才能影响生成结果。组装上下文时要注意控制长度一般取 Top 3 到 Top 5 个片段即可不是越多越好。保留来源信息给每个片段编号Prompt 中要求模型引用编号。提示模型“不知道就不知道”减少强行编造。你是一个企业知识库问答助手。 请仅根据以下检索片段回答问题。 如果片段中没有相关信息请明确回答“知识库中未找到相关信息”。 检索片段 [1] 内容Redis 缓存穿透是指查询一个不存在的数据... [2] 内容解决方案包括布隆过滤器、缓存空值... 用户问题如何解决缓存穿透 请回答并在关键句后标注来源编号。如果你在面试中能把 Prompt 组装也讲清楚说明你不是只会跑通 Demo而是有完整的认知链路。6. 面试怎么答三层检索答题模板如果你正在准备面试建议把下面的表达框架背熟然后结合你自己的项目案例展开。6.1 开场回答参考“我理解 RAG 的检索策略可以分成三层。第一层是查询理解我会根据用户 Query 做改写、意图识别和路由必要时用 HyDE 生成假设文档提升召回的语义匹配度。第二层是召回我会做混合检索同时用 BM25 做关键词召回、用向量检索做语义召回还可以根据业务场景加知识图谱或规则召回。第三层是融合重排先用 RRF 这类算法做多路结果融合再用 Cross-Encoder 做精排最后做阈值过滤、去重、裁剪把高质量的候选片段组装成 Prompt 上下文。”6.2 常见的追问方向面试官大概率会追问“你如何在 Query 改写和原 Query 之间做权衡”可以答改写有漂移风险所以我会保留原 Query对改写结果和原 Query 分别召回再融合结果。“向量检索的 Top K 怎么定”可以答先根据延迟和 Token 预算定上限再在评估集上测不同 K 值。“重排模型选型要注意什么”可以答Cross-Encoder 效果更好但延迟更高可以考虑用小模型粗排、大模型精排的两级策略。“怎么评估 RAG 效果”可以答从命中率、相关性、答案准确率、幻觉率、端到端延迟五个维度建立评估集。6.3 避坑不要只背术语面试最忌背概念但讲不出设计取舍。比如说到向量检索最好能补充“我遇到过相似度阈值设得太高导致召回率低的情况后来根据评估集把阈值调到 0.72命中率提升了 8 个百分点”。即使这是你基于项目经验的真实总结也要用具体数据支撑。没有数据时可以这样回答“这个数值与 Embedding 模型和应用场景强相关我一般会根据历史日志画分数分布再选取分位数作为阈值。”7. 常见问题与排查思路做 RAG 项目时你会遇到不少现象诡异的问题。下面整理一个高频问题排查表。问题现象常见原因解决思路检索结果完全无关知识库切块不合理或 Embedding 模型与领域不匹配检查切块大小、重叠窗口替换领域 Embedding 模型关键词能查到但向量查不到向量模型对专有名词不敏感增加 BM25 召回或做 Query 改写扩展专有名词向量能查到但关键词查不到口语表达与文档用词不一致增加 query 同义扩展、HyDE、向量检索权重调高多路召回结果互相冲突没有统一融合策略引入 RRF 或重排模型做统一打分大模型回答与检索片段不符Prompt 没有约束模型“只基于片段回答”在 Prompt 中增加 Groundedness 约束输出后做引用校验命中片段有内容但答案不完整相关片段被切碎了信息分散调整切块策略增加上下文窗口或做父子块检索检索延迟太高召回路数太多或向量索引没有做压缩限制召回路数用 IVF/PQ 等索引或增加缓存同一问题结果不稳定混合检索融合策略不稳定或重排模型抖动固定随机种子增加阈值过滤做结果快照对比排查时我的建议是先定位问题出在“召回前、召回中、召回后”哪个阶段。方法很简单把某一轮的具体 Query、检索结果、重排结果、最终生成结果全部打印出来人工看一遍。只要能把链路里的中间产物可视化问题基本能肉眼定位。8. 最佳实践与工程建议RAG 检索策略的落地不只是算法问题更是工程问题。下面这些实践建议来自多个项目的共性经验。8.1 建立评估集是第一步很多团队一上来就调参但连“什么叫检索成功”都没定义清楚。建议先构建一个评估集至少包含 200 到 500 条问题每条问题标注对应的标准答案片段和理想答案。有了评估集才能量化每一次策略调整是变好还是变差。评估指标可以分两层。检索层HitK、MRRMean Reciprocal Rank、NDCG。生成层答案正确率、忠实度Faithfulness、引用准确率。8.2 日志与追踪比模型调参更重要线上 RAG 系统一定要记录完整的追踪日志原始 Query改写后的 Query每路召回的 Top K 结果及分数融合重排后的结果最终 Prompt 内容和生成结果端到端耗时有了这些日志你才能复现线上问题、分析失败案例、持续迭代。没有日志的 RAG 系统就像一个没有监控的数据库出了问题只能靠猜。8.3 缓存策略RAG 的检索耗时和 LLM 生成耗时都存在重复计算问题。高频问题、热门实体查询完全可以使用缓存。常见做法Query 级缓存相同或相似 Query 直接返回历史结果。检索级缓存相同 Query 的召回结果缓存一段时间。生成级缓存对命中缓存的内容直接复用答案不再调用大模型。缓存时要特别注意数据更新问题知识库变化后要及时失效对应缓存。8.4 权限与安全边界企业级 RAG 必然涉及敏感数据。检索层必须做权限过滤不能让普通员工检索到 HR 薪酬数据。常见做法是在文档入库时打权限标签检索时用当前用户的权限列表做过滤。这个过程要在检索阶段完成而不是检索后才过滤否则敏感内容已经被向量化召回存在泄露风险。另外Prompt 注入也是一个需要关注的攻击面。恶意用户可能通过 Query 让 RAG 系统忽略上下文、输出知识库之外的内容。对抗方式包括Prompt 中明确系统边界、对用户输入做敏感词过滤、对生成内容做合规校验。8.5 版本管理与灰度发布RAG 系统的每个环节都可能变化Embedding 模型换版本、重排模型升级、知识库更新、切块策略调整。任何一个变化都可能导致线上效果波动。建议建立配置化流程将“切块参数、Embedding 模型、检索策略、融合权重、Prompt 模板”都做成可配置项。发布新策略时先在小流量灰度对比评估集指标和线上用户反馈再逐步放量。9. 最后说几句RAG 面试的答案不在于你背了多少概念而在于你能不能把“查询理解—召回—融合重排”三层检索策略讲成一套有逻辑、有取舍、有落地细节的方案。把这套三层框架吃透你不仅能应对面试更能直接帮你设计出更可靠的知识库问答系统。下一步可以继续学习的方向包括Sparse-Dense 混合检索的进阶实现、Rerank 模型训练、多智能体 RAG 路由、RAG 与知识图谱结合以及基于 Llama.cpp 等工具构建本地化 RAG 服务。如果你正在准备面试建议找一个公开数据集把你目前的 RAG 系统跑通然后用这套三层框架做一次完整复盘。亲手调过一轮召回和重排你才会真正理解策略这两个字的重量。 RAG三层检索策略全解析：从查询理解到融合重排
“RAG 你肯定知道但你能把 RAG 的策略讲清楚吗”最近面试中被问到这个问题的人不少。很多候选人都能说出“检索增强生成”的全称也能画出“文档切块—向量化—检索—拼接 Prompt—大模型生成”的流程图但一旦面试官追问“你如何在项目里做召回”“多路召回结果怎么融合”“为什么检索到了相关内容大模型还是答偏了”就答不上来了。这篇文章不是为了背八股而是想把 RAG 面试中最容易拿分的一个分析框架完整拆开三层检索策略。无论你是刚开始接触 RAG还是已经在做知识库问答、智能客服、企业文档检索这套思路都能直接用来回答问题、设计系统、排查线上故障。1. 为什么面试官爱问 RAG 策略RAG 的火爆不是偶然。大模型虽然知识面广但存在幻觉、知识陈旧、无法访问私有数据等问题。RAG 通过“先检索、再生成”的方式把外部知识库接入大模型生成流程既提升了回答的准确性又让模型输出有据可查是目前企业落地大模型应用最主流的方案之一。但面试官问“RAG 策略”重点往往不是“RAG 是什么”而是“你会怎么设计一套可用的 RAG 系统”。搜索引擎的检索技术、推荐系统的召回排序、大模型的 Prompt 工程、甚至向量数据库的选型都会在这个问题里被串联起来。所以这个问题表面考 RAG实际上考的是你对“检索—排序—生成”整个链路有没有结构化认知。更关键的是“策略”这个词意味着你要告诉面试官在面对候选文档成千上万、用户 Query 千奇百怪、检索结果良莠不齐的情况下你的系统每一步做了什么决策、为什么做这个决策、如何衡量效果。把 RAG 拆成三层检索策略来回答是一种既清晰又有深度的答题结构。1.1 三层检索策略指什么我推荐你把 RAG 的检索链路拆成三层第一层查询理解层。负责把用户原始输入变成“适合检索的 Query”。比如补全指代、纠错、改写、拆解复杂问题。第二层召回层。负责从大规模文档库中快速找到候选内容。常见手段有 BM25 关键词召回、向量语义召回、混合检索、多路召回。第三层融合重排层。负责对多路召回结果做融合、过滤、精排并最终组装成有利于大模型生成的上下文。这三层合在一起就是一套完整的 RAG 检索策略。面试时从这三层展开既不会漏掉关键点又能体现出你对工程细节的把控。1.2 三层检索背后的核心指标理解三层检索先要理解 RAG 系统最关心的几个指标召回率Recall正确答案有没有被检索出来。精确率Precision检索出来的结果有多少是真正相关的。命中率Hit RateTop K 结果中是否包含可支撑答案的片段。答案准确率 / 幻觉率最终生成结果是否忠于检索证据。你会发现查询理解层和召回层主要影响召回率融合重排层主要影响精确率而最终 Prompt 的组装方式直接影响幻觉率和答案质量。三层不是孤立的而是层层递进、环环相扣。2. RAG 基础检索到底在解决什么问题在展开三层检索之前先统一一下对 RAG 的理解。RAG 的全称是 Retrieval-Augmented Generation中文叫检索增强生成。它的思路很直接不指望大模型记住所有知识而是在生成回答前先从外部知识库中检索出相关文档片段把这些片段作为上下文交给大模型让模型基于证据回答。一个典型 RAG 系统的离线部分包括文档解析、清洗、切块Chunking、向量化Embedding、写入向量数据库。在线部分包括用户 Query 处理、检索召回、融合重排、构建 Prompt、大模型生成。2.1 检索模块为什么是 RAG 的胜负手很多人一开始做 RAG 会把重心放在 Prompt 上但实际项目跑下来会发现80% 的效果问题出在检索链路。检索结果不相关Prompt 写得再好大模型也只能“一本正经地胡说八道”。检索模块要解决的核心矛盾有两个第一Query 与文档之间的语义鸿沟。用户问“这个月工资为啥少了”文档里写的是“薪酬结构、绩效扣款、社保调整”两者字面上完全不重叠单纯靠关键词匹配大概率召回不到。第二候选文档数量与质量之间的平衡。向量检索可以把上百万文档的召回做到毫秒级但召回的 Top K 里往往掺杂大量“语义相似但不相关”的内容需要重排层做二次筛选。三层检索策略本质上就是围绕这两个矛盾设计的解决方案。2.2 从朴素 RAG 到进阶 RAG网上经常有人把 RAG 分为 Naive RAG、Advanced RAG、Modular RAG 几个阶段。朴素 RAG 就是最简单的“切块—向量化—检索—生成”流程。进阶 RAG 会在检索前增加 Query 改写在检索后增加重排。模块化 RAG 则把整个链路拆成更细的模块可以自由组合。如果面试官问你“做过哪些 RAG 优化”你可以顺着三层检索的思路回答查询理解层做了 Query 改写、HyDE、意图路由。召回层做了混合检索、多路召回、切块策略调优。融合重排层做了 RRF 融合、Cross-Encoder 重排、引用溯源。这样回答既系统又显得你有真实落地经验。3. 第一层查询理解与预处理策略很多 RAG 项目把用户输入直接丢进向量检索这样做不是不行但效果往往不稳定。用户的问题通常是口语化的、简短的、有指代的甚至包含错别字。直接拿这样的 Query 去做向量召回召回质量很难保证。查询理解层要做的就是解决“用户问题不是好的检索式”这个问题。3.1 Query 改写把口语变成适合检索的表述Query 改写是最常用、也是性价比最高的一层策略。常见做法包括指代消解用户先问“张三的项目延期了”接着问“他后续有什么计划”这里的“他”需要补全为“张三”。问题补全用户问“Java 内存模型”可以补全为“Java 内存模型是什么有哪些组成部分”同义扩展把“工资少了”扩展成“薪资减少、薪酬变动、扣款原因”。纠错把“RAG 怎么优化”里的错别字修正。最简单的 Query 改写可以用规则实现比如关键词替换更灵活的方式是用大模型改写 Query。下面是一个基于大模型改写的伪代码示例你需要把它替换成项目实际使用的模型 SDK# 伪代码Query 改写流程 # 实际使用时请替换为你的大模型调用 SDK def rewrite_query(original_query, chat_model): prompt f 你是一个专业的检索查询改写助手。 请把用户的问题改写成适合搜索引擎和向量检索的查询语句。 要求 1. 补全指代和缺失成分 2. 保留原始意图 3. 输出不要啰嗦直接给出改写结果 用户问题{original_query} 改写结果 rewritten chat_model.complete(prompt) return rewritten.strip()这种改写虽然简单但在实际业务里能明显提升检索命中率。比如用户问“它怎么配置”如果你不把“它”还原成具体产品名向量检索时“它”这个 token 几乎不携带语义信息还会干扰向量分布。3.2 意图识别与检索路由企业级 RAG 通常不只有一个知识库。可能有产品文档库、技术工单库、制度规范库、代码仓库文档库。用户问“接口报错 401”应该去技术文档和工单里检索用户问“请假流程”应该去制度规范里检索。这时候可以在查询理解层增加意图识别与路由模块。路由方式有两种规则路由通过关键词、正则判断 Query 属于哪个领域然后路由到对应索引。比如包含“报错、异常、接口、代码”就走技术库包含“请假、报销、考勤”就走制度库。模型路由用一个大模型分类器判断 Query 的意图返回对应的知识库名称和检索参数。# 伪代码意图路由 def route_query(original_query, chat_model): prompt f 请判断用户问题属于哪个知识库 A. 技术文档库 B. 制度规范库 C. 产品使用手册 用户问题{original_query} 请只输出 A/B/C route chat_model.complete(prompt).strip() return route面试时提到意图路由最好再补一句“路由决策本身也需要兜底比如模型分类置信度低时默认走全库召回”这会让面试官觉得你考虑过边界情况。3.3 HyDE让 Query 先变成“答案的样子”HyDEHypothetical Document Embeddings是查询理解层另一个有价值的策略。它的核心思想是先用大模型根据用户问题生成一个“假设性答案”或“假设性文档”再用这个假设文档去做向量检索。为什么这样做因为用户问题往往很短而知识库里的文档片段很长。在向量空间里短 Query 的向量和长文档的向量分布不完全一致。如果先让大模型生成一段“如果这个问题有答案答案大概会长什么样”的文本再用这段文本去做检索Query 与文档的语义空间会更接近。# 伪代码HyDE 流程 def hyde_retrieve(original_query, chat_model, vector_search): # 1. 生成假设性文档 hypothetical_doc chat_model.complete( f请简要回答以下问题假设你拥有相关知识{original_query} ) # 2. 用假设文档向量去检索 candidates vector_search(hypothetical_doc, top_k10) return candidatesHyDE 不是万能的。它依赖大模型的生成质量如果模型生成的假设文档偏离真实答案检索效果反而会下降。实际项目中可以做 A/B 测试对比开启和关闭 HyDE 的命中率再决定是否上线。3.4 子问题分解处理多跳问题有些用户问题不是单轮检索能解决的。比如“张三负责的项目里哪个延期了对应的负责人是谁”这需要先找到张三的项目再找到项目延期信息再关联负责人。这就是所谓多跳问题。子问题分解的策略是把复杂问题拆成多个简单子问题逐个检索最后汇总。可以用大模型生成子问题列表再对每个子问题走一遍“改写—召回—重排”流程最后把多轮检索结果合并交给生成模型。# 伪代码子问题分解 def decompose_question(question, chat_model): prompt f 请把以下复杂问题拆解为多个简单的子问题每个子问题单独一行输出。 要求子问题可以在知识库中独立检索到答案。 问题{question} sub_questions chat_model.complete(prompt).strip().split(\n) return sub_questions不过子问题分解在面试中属于加分项实际落地时要注意控制检索次数否则延迟会明显上升成本也会翻倍。4. 第二层召回策略召回层是 RAG 检索链路的核心它的目标是在海量文档中快速圈定一小批候选片段。召回讲究“准中带全”宁可多召回一些不相关的内容也不能让正确答案漏掉。如果正确答案根本没进入候选集后面的重排再厉害也无力回天。4.1 稀疏检索BM25 关键词召回BM25 是传统搜索引擎中最经典的排序函数也是 Lucene、Elasticsearch 默认的相似度算法之一。它的核心思路是一个词在文档中出现的频率越高同时这个词在语料库中越罕见那么文档与 Query 的相关性就越高。BM25 的优势在于精确匹配能力强适合专用名词、型号、编号、代码片段。可解释性好能直接告诉用户命中了哪些关键词。不需要训练模型开箱即用。缺点是它对语义理解无能为力。用户说“车跑不动”文档里写的是“发动机动力不足”字面完全不匹配BM25 就召回不到。在 Python 中可以使用 rank_bm25 这类库实现但理解它的原理比调库更重要。核心公式可以简化为对 Query 中每个词计算 IDF逆文档频率与词频的加权和。IDF 越高说明这个词越有区分度。4.2 稠密检索向量语义召回向量检索是 RAG 区别于传统搜索引擎的核心。它的思路是用 Embedding 模型把文本映射成高维向量语义相近的文本在向量空间中的距离也更近。Query 向量化后在向量数据库中查询最近邻。向量检索的优点非常明显能处理同义词、 paraphrase、口语化表达。能理解浅层语义关系。配合 FAISS、Milvus、Elasticsearch 等引擎可以支撑大规模数据。但在实际项目中向量检索也经常出问题模型与文档领域不匹配Embedding 效果差。相似度阈值设置不当召回一堆无关内容。长文档切块不合理语义被切断。所以现代 RAG 系统很少只用向量检索而是用 BM25 向量检索的混合模式。4.3 混合检索BM25 与向量的组合混合检索的逻辑不复杂同时用 BM25 和向量检索各召回一批结果然后合并。这样既保留了关键词的精确匹配能力又引入了语义泛化能力。举个例子用户问“如何解决 Redis 缓存穿透”BM25 能精确命中“Redis 缓存穿透”相关的技术文章向量检索能召回“缓存失效、热点 Key 打爆数据库”这类语义相近但字面不同的内容。两者结合召回率会明显提升。当然混合检索的关键不是“同时查两个索引”而是“怎么合并结果”。这就是第三层融合重排要做的事情。4.4 切块策略召回效果的隐形决定因素很多 RAG 项目调了很久的模型却发现效果没有提升最后定位到问题出在切块上。切块Chunking决定了知识库中以什么粒度组织文档片段直接影响检索效果。切块太小信息不完整。比如一段产品介绍被切成 100 个字的小块单块可能只包含“产品名称”不包含“功能、参数、使用场景”检索到了也撑不起完整答案。切块太大噪声太多。一个 2000 字的块里可能只有 200 字与问题相关向量化后相关信号被稀释精度下降。常见的切块策略包括固定大小切块、递归字符切块、按结构切块标题、段落、Markdown 层级以及基于语义的切块。下面是一个递归字符切块的简化实现思路是设置一个目标块大小和重叠窗口# 简易递归切块示例实际项目可参考 langchain 等框架的实现 def simple_recursive_chunk(text, chunk_size500, overlap50): chunks [] start 0 text_len len(text) while start text_len: end start chunk_size chunk text[start:end] chunks.append(chunk) if end text_len: break start end - overlap return chunks切块策略没有标准答案需要根据文档类型、Embedding 模型、下游任务来调。工程上建议把不同切块参数放到评估集上做实验而不是靠感觉拍脑袋。4.5 多路召回与知识图谱除了 BM25 和向量检索企业级 RAG 还会引入更多召回通道。常见的多路召回包括关键词召回适合代码、型号、专有名词检索。向量召回适合语义相似检索。知识图谱召回适合实体关系查询比如“A 公司的创始人是谁”。规则召回基于业务规则精确匹配比如“查询 2024 年 3 月的财报”。多路召回的核心价值是“多路互补”。没有一条召回通道是万能的但多个通道的并集往往能覆盖更多用户问题。代价是检索结果更多、噪声更大因此对第三层的融合重排要求更高。5. 第三层融合与重排策略很多 RAG 项目做到“混合检索”就停了直接把多路结果拼接进 Prompt。但你会发现五路召回、每路 Top 10加起来几十个片段如果一股脑全塞给大模型不仅 Token 成本爆炸大模型还会被不相关内容干扰反而答错。第三层融合重排就是解决“结果太多、噪声太大、顺序不合理”的问题。5.1 RRF简单高效的融合算法RRFReciprocal Rank Fusion倒数排名融合是混合检索中最常用的融合算法。它的思路是如果一个文档在多个召回结果列表中的排名都比较靠前那么它融合后的分数就高。RRF 公式很简洁score(d) Σ 1 / (k rank_i(d))其中 rank_i(d) 是文档 d 在第 i 路召回中的排名k 是一个常数一般取 60。这样排名第 1 的文档贡献 1/61排名第 60 的文档贡献 1/120排名越靠前贡献越大。def reciprocal_rank_fusion(ranked_lists, k60): RRF 融合 ranked_lists: 多路召回的排名列表每个列表是 doc_id 的有序数组 返回按融合分数降序排列的 (doc_id, score) 列表 scores {} for docs in ranked_lists: for rank, doc_id in enumerate(docs): # rank 从 0 开始所以实际排名是 rank 1 scores[doc_id] scores.get(doc_id, 0) 1.0 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue) # 使用示例 bm25_results [doc_a, doc_c, doc_b] vector_results [doc_b, doc_d, doc_a] fused reciprocal_rank_fusion([bm25_results, vector_results]) print(fused)RRF 最大的优点是简单、稳定、无需训练、对分数尺度不敏感。它不关心每路召回用的什么分数模型只看排名。这在实际工程中非常实用因为向量检索的相似度分数和 BM25 的分数根本不在一个量纲上直接加和没有意义RRF 规避了这个问题。5.2 Rerank用 Cross-Encoder 做精排RRF 只是一次粗糙融合它能解决“多路合并”的问题但解决不了“召回结果与 Query 相关度参差不齐”的问题。更精细的做法是引入重排模型。主流方案是 Cross-Encoder 重排。与 Bi-Encoder把 Query 和文档分别编码成向量再算相似度不同Cross-Encoder 会把 Query 和候选文档拼接成一个长文本一起送入编码器输出一个相关性分数。因为模型能看到 Query 与 Document 的完整交互相关度判断往往更准。# 伪代码Cross-Encoder 重排流程 def rerank(query, candidates, rerank_model): scored [] for doc in candidates: score rerank_model.score(query, doc) # 替换为实际重排模型 API scored.append((doc, score)) scored.sort(keylambda x: x[1], reverseTrue) return scored[:5]重排层的价值在混合检索后特别明显。向量检索召回的 Top K 里经常有“语义很接近但不包含答案”的片段Cross-Encoder 能把这些噪声排到后面从而提升最终上下文的质量。5.3 阈值过滤与去重融合重排之后还需要做几件“琐碎但必要”的事相似度阈值过滤向量检索分数低于阈值的片段直接丢弃。去重同一份内容可能以不同切块方式命中多次需要按文档来源去重。上下文窗口裁剪LLM 上下文有限需要按权重截取 Top N 个片段。时效性加权HR 政策、新闻类问题越新越重要。这些规则看起来不起眼但能避免不少线上问题。比如有些知识库重复内容多去重前上下文里塞进三份几乎一样的段落既浪费 Token 又容易让模型重复回答。5.4 引用溯源与 Groundedness引用溯源是 RAG 面试中一个越来越重要的考点。它的核心思想是生成结果必须能对应到检索证据否则就算答案看起来正确也没有可信度。具体做法有两种第一种在 Prompt 中强制要求模型“只基于上下文回答并在每个论点后标注来源片段”。例如请基于以下检索片段回答问题。如果问题不在片段中请回答“知识库中未找到相关信息”。 每个回答点后标注来源例如 [1]、[2]。第二种在生成结果后做 Groundedness 校验用另一个模型检查答案中的每个关键句是否被检索片段支持。如果发现“无证据断言”就标记为幻觉内容。面试时提到这一层能明显体现你对 RAG 生产落地的理解深度而不是只会调接口。5.5 组装 Prompt检索结果如何进入上下文检索质量再高最终都要通过 Prompt 才能影响生成结果。组装上下文时要注意控制长度一般取 Top 3 到 Top 5 个片段即可不是越多越好。保留来源信息给每个片段编号Prompt 中要求模型引用编号。提示模型“不知道就不知道”减少强行编造。你是一个企业知识库问答助手。 请仅根据以下检索片段回答问题。 如果片段中没有相关信息请明确回答“知识库中未找到相关信息”。 检索片段 [1] 内容Redis 缓存穿透是指查询一个不存在的数据... [2] 内容解决方案包括布隆过滤器、缓存空值... 用户问题如何解决缓存穿透 请回答并在关键句后标注来源编号。如果你在面试中能把 Prompt 组装也讲清楚说明你不是只会跑通 Demo而是有完整的认知链路。6. 面试怎么答三层检索答题模板如果你正在准备面试建议把下面的表达框架背熟然后结合你自己的项目案例展开。6.1 开场回答参考“我理解 RAG 的检索策略可以分成三层。第一层是查询理解我会根据用户 Query 做改写、意图识别和路由必要时用 HyDE 生成假设文档提升召回的语义匹配度。第二层是召回我会做混合检索同时用 BM25 做关键词召回、用向量检索做语义召回还可以根据业务场景加知识图谱或规则召回。第三层是融合重排先用 RRF 这类算法做多路结果融合再用 Cross-Encoder 做精排最后做阈值过滤、去重、裁剪把高质量的候选片段组装成 Prompt 上下文。”6.2 常见的追问方向面试官大概率会追问“你如何在 Query 改写和原 Query 之间做权衡”可以答改写有漂移风险所以我会保留原 Query对改写结果和原 Query 分别召回再融合结果。“向量检索的 Top K 怎么定”可以答先根据延迟和 Token 预算定上限再在评估集上测不同 K 值。“重排模型选型要注意什么”可以答Cross-Encoder 效果更好但延迟更高可以考虑用小模型粗排、大模型精排的两级策略。“怎么评估 RAG 效果”可以答从命中率、相关性、答案准确率、幻觉率、端到端延迟五个维度建立评估集。6.3 避坑不要只背术语面试最忌背概念但讲不出设计取舍。比如说到向量检索最好能补充“我遇到过相似度阈值设得太高导致召回率低的情况后来根据评估集把阈值调到 0.72命中率提升了 8 个百分点”。即使这是你基于项目经验的真实总结也要用具体数据支撑。没有数据时可以这样回答“这个数值与 Embedding 模型和应用场景强相关我一般会根据历史日志画分数分布再选取分位数作为阈值。”7. 常见问题与排查思路做 RAG 项目时你会遇到不少现象诡异的问题。下面整理一个高频问题排查表。问题现象常见原因解决思路检索结果完全无关知识库切块不合理或 Embedding 模型与领域不匹配检查切块大小、重叠窗口替换领域 Embedding 模型关键词能查到但向量查不到向量模型对专有名词不敏感增加 BM25 召回或做 Query 改写扩展专有名词向量能查到但关键词查不到口语表达与文档用词不一致增加 query 同义扩展、HyDE、向量检索权重调高多路召回结果互相冲突没有统一融合策略引入 RRF 或重排模型做统一打分大模型回答与检索片段不符Prompt 没有约束模型“只基于片段回答”在 Prompt 中增加 Groundedness 约束输出后做引用校验命中片段有内容但答案不完整相关片段被切碎了信息分散调整切块策略增加上下文窗口或做父子块检索检索延迟太高召回路数太多或向量索引没有做压缩限制召回路数用 IVF/PQ 等索引或增加缓存同一问题结果不稳定混合检索融合策略不稳定或重排模型抖动固定随机种子增加阈值过滤做结果快照对比排查时我的建议是先定位问题出在“召回前、召回中、召回后”哪个阶段。方法很简单把某一轮的具体 Query、检索结果、重排结果、最终生成结果全部打印出来人工看一遍。只要能把链路里的中间产物可视化问题基本能肉眼定位。8. 最佳实践与工程建议RAG 检索策略的落地不只是算法问题更是工程问题。下面这些实践建议来自多个项目的共性经验。8.1 建立评估集是第一步很多团队一上来就调参但连“什么叫检索成功”都没定义清楚。建议先构建一个评估集至少包含 200 到 500 条问题每条问题标注对应的标准答案片段和理想答案。有了评估集才能量化每一次策略调整是变好还是变差。评估指标可以分两层。检索层HitK、MRRMean Reciprocal Rank、NDCG。生成层答案正确率、忠实度Faithfulness、引用准确率。8.2 日志与追踪比模型调参更重要线上 RAG 系统一定要记录完整的追踪日志原始 Query改写后的 Query每路召回的 Top K 结果及分数融合重排后的结果最终 Prompt 内容和生成结果端到端耗时有了这些日志你才能复现线上问题、分析失败案例、持续迭代。没有日志的 RAG 系统就像一个没有监控的数据库出了问题只能靠猜。8.3 缓存策略RAG 的检索耗时和 LLM 生成耗时都存在重复计算问题。高频问题、热门实体查询完全可以使用缓存。常见做法Query 级缓存相同或相似 Query 直接返回历史结果。检索级缓存相同 Query 的召回结果缓存一段时间。生成级缓存对命中缓存的内容直接复用答案不再调用大模型。缓存时要特别注意数据更新问题知识库变化后要及时失效对应缓存。8.4 权限与安全边界企业级 RAG 必然涉及敏感数据。检索层必须做权限过滤不能让普通员工检索到 HR 薪酬数据。常见做法是在文档入库时打权限标签检索时用当前用户的权限列表做过滤。这个过程要在检索阶段完成而不是检索后才过滤否则敏感内容已经被向量化召回存在泄露风险。另外Prompt 注入也是一个需要关注的攻击面。恶意用户可能通过 Query 让 RAG 系统忽略上下文、输出知识库之外的内容。对抗方式包括Prompt 中明确系统边界、对用户输入做敏感词过滤、对生成内容做合规校验。8.5 版本管理与灰度发布RAG 系统的每个环节都可能变化Embedding 模型换版本、重排模型升级、知识库更新、切块策略调整。任何一个变化都可能导致线上效果波动。建议建立配置化流程将“切块参数、Embedding 模型、检索策略、融合权重、Prompt 模板”都做成可配置项。发布新策略时先在小流量灰度对比评估集指标和线上用户反馈再逐步放量。9. 最后说几句RAG 面试的答案不在于你背了多少概念而在于你能不能把“查询理解—召回—融合重排”三层检索策略讲成一套有逻辑、有取舍、有落地细节的方案。把这套三层框架吃透你不仅能应对面试更能直接帮你设计出更可靠的知识库问答系统。下一步可以继续学习的方向包括Sparse-Dense 混合检索的进阶实现、Rerank 模型训练、多智能体 RAG 路由、RAG 与知识图谱结合以及基于 Llama.cpp 等工具构建本地化 RAG 服务。如果你正在准备面试建议找一个公开数据集把你目前的 RAG 系统跑通然后用这套三层框架做一次完整复盘。亲手调过一轮召回和重排你才会真正理解策略这两个字的重量。