最近几次模拟面试里我常问候选人同一个问题“你的 RAG 项目里检索策略是怎么设计的”有人会熟练地报出“向量检索、FAISS、top_k、embedding”也有人会把“混合检索 重排”说成套话。但真正能拿高分的候选人都不会急着堆工具名而是先画出一张完整的决策地图索引怎么准备查询怎么处理结果怎么排序复杂问题怎么拆解。这恰好是“RAG 策略”这个词最容易让人误解的地方——它不是某一个检索函数而是从业务文档到最终答案之间一整条需要做取舍的链路。这篇文章我就把这条链路拆成三层来讲希望能在你准备面试或做 RAG 项目规划时提供一个更清晰、更有边界感的思考框架。1. 面试官问的“RAG 策略”到底在等什么答案1.1 “策略”不是“名词清单”很多人准备 RAG 相关问题时会背下一批术语向量检索、BM25、倒排索引、Rerank、Hybrid Search、GraphRAG、Agentic RAG。这些词本身没有错但当你把它们一个接一个地倒给面试官时对方获取不到你的“策略”。我们可以换个角度理解面试官的提问动机。他问“RAG 策略”通常不是在考定义而是在判断三件事你有没有完整链路意识从文档进来到答案出去中间经历了哪些环节。你有没有做出方案取舍的能力为什么在这个场景用向量检索而不是只用 BM25。你有没有处理复杂问题的预案多跳问题怎么拆检索不到怎么办答案质量差怎么办。只报名词回答停在了“我认识什么工具”的层面。会做取舍的人回答停在了“我理解我的业务应该用什么方案”的层面。面试官想听到的正是后者。1.2 三层检索框架从能查到能答我在复盘很多 RAG 项目时习惯把检索策略拆成三层。这个拆法不是为了应付面试而是因为它能对应到实际开发链路里的不同痛点。层级核心关注点典型问题主要手段第一层数据准备与索引层决定系统里能存什么、以什么结构被检索切块太碎导致上下文断裂切块太大导致噪声过多切块策略、索引结构、元数据设计第二层查询执行与排序层决定用户问题能否被准确地检索到user query 口语化、多路召回结果不一致、召回结果不相关Query 改写、多路召回、融合、重排、上下文组装第三层复杂问题决策层决定复杂 query 能否被拆解、验证和修正多跳问题答不对、检索结果不相关、单次检索不够用Agentic RAG、多跳拆解、GraphRAG、检索质量评估面试时如果你能先把这张表讲明白再落到某个具体项目的细节里对方会比较容易理解你的思路。因为你不是在背诵技术名词而是在用一个结构把“检索策略”这件事组织起来。1.3 一个关键判断检索不是一次 API 调用而是一条控制流我见过很多早期 RAG Demo 的做法是把用户问题 embedding 化去向量库里检索 top_k 个片段拼到 prompt 里给大模型。这个流程能跑通但它把“检索”简化成了一次 API 调用。真实业务里检索策略更像是一个控制流。你需要决定什么问题要检索什么问题可以直接回答。一次检索不够时要不要再查一次。多个结果之间内容重复要不要去重。查回来的片段和问题不相关是继续换关键词还是直接告诉用户“知识库没有答案”。所以后面的三层框架本质上是在回答一个问题你怎么在每一步决策里减少信息损失和错误传递。这才是“策略”二字的真正含义。2. 第一层索引侧的检索准备策略2.1 切块策略到底在解决什么不管是文档、PDF 还是 Markdown进入 RAG 系统的第一件事几乎都是切块。很多人以为切块只是把长文本切成小段其实它决定了后面所有检索质量的上限。为什么必须切块常见原因有三点embedding 模型有 token 长度上限向量检索的召回粒度需要尽量匹配用户问题的粒度整篇文档直接塞进 prompt成本高且噪声大。但切块不是“越小越好”。块太小语义不完整检索回来一段话可能看不出上下文块太大噪声多embedding 向量的语义被稀释检索回来的内容可能只有一小部分是真正相关的。更合理的理解是切块的目的是让每个块内部语义尽量完整同时让块与块之间边界清晰。2.2 从固定窗口到父子块不同切法的取舍实际工程里切块策略有几种常见路线各有适用边界。固定窗口切分比如按 512 个字符切一块再保留适量重叠。优点是实现简单能很快跑通链路。缺点是容易在段落中间切断语义尤其在表格、代码片段、引用关系较多的文档里。递归字符切分按文档结构层级切分先按段落切再按句子切最后按字符切。这种方式比固定窗口更灵活是很多框架里默认的做法但它依赖分隔符顺序和文档结构纯文本里效果并不总是理想。语义切分利用 embedding 相似度判断语义边界语义不连续的地方就是切分点。它的切分粒度更符合人类理解但计算成本更高还要调整相似度阈值初期不建议一上来就搞。父子块是一种很实用的折中方案。小块负责召回精度更高大块负责给大模型做上下文保证信息完整。比如召回到一个句子块再把它所属的段落或章节一起送进 prompt。这种方式能同时兼顾“检索准确”和“上下文完整”。结构化文档切分针对 Markdown、HTML、表格、代码块做专门处理。表格如果被切成碎片相关性判断会非常难代码如果被硬切语义基本就丢了。实际做知识库时不同文档类型往往要配不同的切分器。这里有一个经验判断如果刚开始学习用固定窗口加一点重叠字符就可以。先把整体流程跑通再用真实文档做效果评估如果发现“相关片段被切断了”或“整体语义太散”再换父子块或结构化切分。不要一开始就追求复杂的切分策略因为切分效果很难脱离具体文档集来评估。2.3 索引侧不是只有向量库一提到 RAG很多人默认检索就是用向量库。但真实业务里索引结构通常不止一种。向量索引擅长语义相似度检索。用户换一种说法也能找到含义相近的内容。但它在精确词匹配上偏弱比如产品型号、报错码、人名、合同编号这类内容embedding 可能表现得并不稳定。BM25 或倒排索引擅长关键词精确匹配。它不依赖语义理解只要用户 query 里的词命中文档里的词就有机会召回。对于术语密集、固定短语多的行业文档BM25 往往能补上向量检索的短板。所以行业里越来越多方案把两者做混合检索向量索引管语义相似稀疏索引管精确匹配再把多路结果融合起来。比如用户问“数据库连接超时怎么排查”向量检索能找到语义相关的排查文档而 BM25 能精确命中包含“连接超时”关键字的 FAQ。除此之外知识图谱索引现在也经常被提及。它通过实体和关系来表示知识结构适合回答“A 和 B 之间有什么关系”“哪些公司投资了某个领域”这类关系型问题。它解决的不是关键词匹配而是把分散在多个文档里的实体关系串联起来。2.4 最容易被忽略的元数据与权限过滤很多团队在索引层花了大量时间调切块策略却忽略了元数据设计。结果出现一个很常见的问题系统同时索引了多份不同来源的文档用户提问时其他业务线的资料也被检索进来了答案自然显得混乱。解决这个问题靠的不是换更好的 embedding而是元数据过滤。在索引阶段给每个块打上来源、时间、业务线、文档类型、权限等级等标签。检索阶段先根据用户身份和问题上下文做过滤再在过滤后的子集里做相似度检索。这个步骤在面试里经常被忽略但它在生产中却非常关键。权限控制不到位不仅影响答案准确性还可能引发数据泄露风险。面试官如果追问“你的检索结果如何防止跨权限泄漏”你能够回答“在索引层设计 metadata 过滤先过滤权限再检索”通常会加分。3. 第二层查询执行与排序策略3.1 Query 改写别把原始问题直接丢进检索用户提问通常是口语化的可能带指代、带语气词、缺上下文。比如用户先问“A 服务器的故障率是多少”接着问“那相比 B 呢”这时候如果不做改写直接检索“那相比 B 呢”大概率什么都查不到。所以查询阶段的第一个动作是 query 预处理。常见做法包括补全指代把“它”“这个”“那”替换成完整实体。补全缺失条件加上时间、业务域、产品名等限定词。转换问题句式把口语化成更适合检索的关键词组合。扩展同义词把用户问题里的专业术语扩展到别名和英文缩写。这里不一定要用大模型来做改写简单规则也能处理一部分。比如用命名实体识别把“A 服务器”识别出来再结合上下文补全。实际工程中用 LLM 改写 query 会更灵活但也会带来额外延迟和成本。所以在我的项目里通常先判断“哪些 query 需要改写”再决定是否调用模型。3.2 多路召回与结果融合单一检索方式有固有盲区。向量检索容易漏掉精确关键词BM25 容易漏掉语义相近但词面不同的内容。于是很多方案会做多路召回同一问题向量检索引擎查一路BM25 查一路知识图谱或 SQL 再查一路最后合并结果。多路召回之后要解决融合问题。最简单的做法是把各路结果拼在一起去重后按名次重新排序。常见方法之一是 RRFReciprocal Rank Fusion它的核心思路是一个文档在不同结果列表里排名越靠前融合后的分数越高。RRF 的细节可以后面再补关键是它的思想不要只信某一路的排名而是综合多路排名来降低单一策略的偏差。融合阶段尤其要注意不同召回路返回的 top_k 数量不必一样。向量召回可以多一些比如 top50精确检索可能只需要 top20再交给后面的重排模型统一精排。如果一开始就把 top5 的结果送进 prompt很多高价值片段在召回阶段就被截掉了。3.3 Rerank 才是效果提升的关键杠杆很多做 RAG 的人把精力放在调 embedding 模型上却低估了重排的作用。实际体感是在已经有多路召回的基础上接入一个 rerank 模型效果提升往往比换 embedding 明显得多。原因很简单embedding 检索的目标是“找一批可能相关的内容”它的排序不是最终答案排序而 rerank 模型的任务更接近“给定问题和候选片段判断哪段最匹配”。后者更精准。简单说先用低成本的粗召回方式拿到一个较大的候选集合比如 top50再用 rerank 模型做精排取 top5 送进 prompt。这比直接“一个向量模型 top5”效果稳定得多。Rerank 的主要代价是额外延迟和部署成本。跨编码器类的重排模型通常比双塔式 embedding 慢因为它要考虑问题与每个候选片段的交叉交互。在实时问答系统里需要评估能否接受这部分延迟。如果延迟敏感可以缩小候选集数量或者在离线阶段先做一次粗排。3.4 上下文组装不是召回越多越好前面几层都在解决“能不能召回相关内容”但最后决定答案质量的还有“怎么把这些内容组装给大模型”。常见误区是把召回的 top10 甚至 top20 个片段全部塞进 prompt。这样做的结果通常是答案被无关片段污染、上下文超长导致成本上升、模型注意力被分散。更合理的组装策略是按相关度排序最相关的放前面。对内容做冗余去重避免多个片段说同一件事。给每个片段标注来源或序号让模型可以引用。控制总 tokens按任务复杂性给一个预算。如果某个片段相关性很低宁可丢弃也不要硬塞进去。这段是检索策略的“最后一公里”却经常被归到 prompt 工程里。但实际排查问题时会发现很多答案不准不是生成模型不好而是给生成模型的候选上下文既乱又长。注意召回是查出来重排是排好序上下文组装是准备给模型看的证据。三件事不能混在一起。真正稳定的 RAG 流程通常会把“候选召回”和“最终精排”拆成两个阶段而不是一次检索直接送到生成层。4. 第三层复杂查询下的高级策略4.1 Agentic RAG让模型决定要不要检索最早的 RAG 是强制性的不管用户问什么统一走检索再生成。但实际场景里有一些问题不需要检索也能回答比如常识问题也有一些问题只检索一次根本不够比如“先找出最近发布的产品再总结它的核心功能”。Agentic RAG 的思路是把检索从单次调用变成模型可以决策的工具调用。模型先判断这个问题是否需要检索再决定检索哪类知识源甚至决定“这次检索结果不够我再换一个关键词查一次”。这其实就是把大语言模型的工具调用能力和 RAG 结合起来。检索不再是被动执行而是成为模型自主规划的一部分。面试时提到 Agentic RAG关键不是背概念而是能说清楚它解决了什么问题它让系统有了“先判断再行动”的能力而不是对每个问题都做同样的事。4.2 多跳拆分把大问题拆成小问题用户的问题不一定都是单点问题。比如“某公司在某地区的市场份额变化主要原因是什么”这个问题需要先定位公司再找到某地区的销售数据再找原因分析。单次检索很难一次拿到全部答案。多跳检索的常见实现有两种一种是先生成子问题列表逐个检索后拼接结果另一种是让 Agent 在一个循环里不断检索、总结、再检索。后者更灵活但对模型能力要求更高也更容易出现错误传播——前面一步判断错了后面全部跟着错。在实际项目里我一般建议先评估问题复杂度。如果 80% 的问题是单跳问题就别为了剩下 20% 把系统做得过度复杂。你可以先做规则判断识别出明显需要多跳的问题再走 Agent 分支简单问题就走普通 RAG 分支。这样既控制延迟又能覆盖复杂场景。4.3 GraphRAG 与检索修正GraphRAG 是在向量索引和关键词索引之外增加一层图结构的信息组织方式。它把文档里的实体、关系、事件抽出来构建成知识图谱再基于图结构做检索和推理。对于那些实体关系密集、很多答案分散在不同文档里的场景GraphRAG 会比纯向量检索更有优势因为它能提供跨文档的关系链。但 GraphRAG 的落地成本不低。你需要做实体抽取、关系抽取、图存储、查询设计还要维护图谱更新。如果场景只是简单的文档问答没必要为了追概念而引入图。另一类值得关注的技术是“检索结果修正”比如 Self-RAG、CRAG 这类思路。它们的核心不再是怎么检索更多而是怎么判断检索结果是否可靠。模型在生成答案前先判断检索到的片段和问题相关吗如果不相关要么重新检索要么明确告诉用户“知识库没有足够信息”。这类策略对生产环境的意义很大因为它减少了“瞎编答案”的概率。面试时如果能提到“我会对检索结果做置信度判断不确定时就拒绝回答”会显得你真正考虑过质量兜底。4.4 高级策略的适用边界高级策略听起来更有技术含量但并不是所有系统都该上。Agentic RAG 会带来额外的模型调用次数、更长的响应时间和更高的成本。多跳拆解要求底层模型有较强的推理能力否则拆解本身就会出错。GraphRAG 需要维护图谱数据更新频繁时维护成本很高。我的建议是如果系统刚起步先把第一层和第二层做到稳定再逐步叠加第三层。先解决“查得到、查得准”再考虑“复杂问题能不能自动拆”。否则复杂框架带来的不确定性会掩盖掉最初的问题。判断依据很简单你的用户问题里有多少是“多条信息拼在一起才能回答”如果比例不高先不要上重型方案。把基础 RAG 做扎实可能在业务上就够用了。5. 面试实战怎么把三层讲成一个完整故事5.1 回答骨架先给框架再给细节面试官问“你的 RAG 策略是什么”时可以按下面的顺序组织回答先给框架我把 RAG 检索分成三层——索引准备、查询重排、复杂问题决策。再挑一层展开以我的项目为例第一层我们主要处理切块和元数据过滤因为文档来源很杂。讲一个具体问题比如我们发现原始 query 直接检索命中率低后来加了 query 改写和多路召回效果明显提升。最后说边界如果是更复杂的问题我们会尝试拆解成子问题但我们不会一开始就全量上 Agent因为延迟和成本要先评估。这个回答结构好在哪它明显区别于“名词背诵”先让面试官看到你有全局结构再用项目细节证明你踩过坑、做过取舍。5.2 常见追问与高分话术面试官大概率会顺着你的回答继续追问。提前准备几个常见追问比临场发挥更稳。追问方向常见的低分回答更完整的回答思路为什么用混合检索“因为大家都说好。”向量擅长语义相似BM25擅长精确匹配单路召回会漏多路召回后需要用 RRF 或重排融合。切块大小怎么定“默认 512。”取决于文档结构和 embedding 上限先固定窗口跑通再根据召回效果换成父子块或结构化切分。Rerank 有用吗“有用但我们也还没加。”在候选召回后做精排是最直接的优化点代价是延迟需要评估是否可接受。检索不到答案怎么办“那就没办法。”先看是召回问题还是文档缺失召回问题可以加 query 改写、多路召回、换切块文档缺失就做“无法回答”兜底。如何保证 RAG 的稳定性“模型很强应该没问题。”建离线评测集记录召回率、无答案比例、答案准确率上线后监控延迟、返工率和用户反馈。5.3 从 Demo 到生产你还缺什么面试里很多人能讲 Demo但一问生产落地就卡壳。真正完整的 RAG 项目至少还缺以下这些能力离线评测集一批有标准答案或可人工标注的问题用来对比不同检索策略。可观测性每次检索的召回来源、重排得分、无答案比例、覆盖日志。失败重试与降级检索超时时是否降级为关键词检索大模型调用失败时是否返回缓存结果。权限与安全元数据过滤、数据脱敏、用户级权限隔离。内容更新机制知识库新增、过期、删除时索引如何增量更新。这些内容即使你没有全部做过只要能在面试中表现出“我知道生产系统需要这些”就比只讲模型和向量库的人更有竞争力。5.4 真正的 RAG 策略是什么把这三层框架再收束一下RAG 策略不是一个检索函数的一次调用而是一套“把用户问题变成高可信上下文”的决策系统。第一层决定你能召回什么第二层决定你召回得准不准第三层决定复杂问题能不能被拆解、验证和修正。三层不是互斥的而是按复杂度逐步叠加的。真正有价值的不是用最新的概念而是你知道每个方案要解决什么问题、付出什么代价、什么时候该停。下次再被问到“你的 RAG 策略是什么”可以试着从三层开始讲先讲索引怎么准备再讲查询怎么执行和多路结果怎么排序最后讲复杂问题怎么处理。框架是通用的细节可以由你自己的项目经验来填充。面试官看重的往往不是你背了多少种高级解法而是你能不能把自己的方案讲成一条有原因、有取舍、有边界的决策链路。