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 Rate）：Top 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 先变成“答案的样子”

HyDE（Hypothetical 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_k=10) return candidates

HyDE 不是万能的。它依赖大模型的生成质量，如果模型生成的假设文档偏离真实答案，检索效果反而会下降。实际项目中可以做 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_size=500, overlap=50): 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：简单高效的融合算法

RRF（Reciprocal 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, k=60): """ 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(), key=lambda x: x[1], reverse=True) # 使用示例 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(key=lambda x: x[1], reverse=True) 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 项目时，你会遇到不少现象诡异的问题。下面整理一个高频问题排查表。

排查时我的建议是先定位问题出在“召回前、召回中、召回后”哪个阶段。方法很简单：把某一轮的具体 Query、检索结果、重排结果、最终生成结果全部打印出来，人工看一遍。只要能把链路里的中间产物可视化，问题基本能肉眼定位。

8. 最佳实践与工程建议

RAG 检索策略的落地，不只是算法问题，更是工程问题。下面这些实践建议，来自多个项目的共性经验。

8.1 建立评估集是第一步

很多团队一上来就调参，但连“什么叫检索成功”都没定义清楚。建议先构建一个评估集，至少包含 200 到 500 条问题，每条问题标注对应的标准答案片段和理想答案。有了评估集，才能量化每一次策略调整是变好还是变差。

评估指标可以分两层。

检索层：Hit@K、MRR（Mean 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 系统跑通，然后用这套三层框架做一次完整复盘。亲手调过一轮召回和重排，你才会真正理解策略这两个字的重量。