面试被问到“RAG策略”时最怕的不是不知道RAG是什么而是开口就把RAG背成三段流程文档切块、向量化检索、拼进Prompt交给大模型。这种回答不能算错但很难拿分。RAG真正拉开差距的地方是检索这件事本身有没有被拆开设计。query进入知识库之前怎么处理候选文档用什么方式召回召回之后如何精排并组织成上下文这三个阶段共同决定了一个RAG系统到底是“能用”还是“好用”。这里说的三层检索就是回答RAG策略时最值得讲清楚的得分框架。这篇文章不准备只给面试话术我会按实际RAG系统的调试路径把三层检索拆开讲。每一层存在的理由、常见做法、参数取舍、失败现象和排查方向都会写到。如果你正在准备大模型应用岗、算法岗或后端岗面试或者刚接触RAG知识库项目想搞清楚检索链路里到底要控制哪些变量这篇可以直接作为复习主线。1. 面试官问“RAG策略”时到底想听什么1.1 这个问题要看你能不能把RAG拆成可调优的链路很多面试者会把RAG策略理解成“用向量数据库做相似度检索”。这个理解只覆盖了召回环节的一部分而且是最基础的那部分。真正的RAG策略是围绕“如何从知识库中拿到最有利于生成答案的证据”设计的一整套链路包括查询理解、多路召回、精排、上下文压缩、结果引用、失败兜底每一环都有独立策略。面试官问这个问题通常不是想听名词解释而是想判断你有没有真正处理过RAG知识库项目里的实际问题。比如检索结果不相关怎么定位长文档里答案分散在多个片段怎么处理关键词和语义刚好冲突时怎么取舍多路召回结果怎么合并召回得分很高但生成答案跳出了文档范围怎么办。这些问题不拆开链路是说不清楚的。能答出三层检索结构至少证明你不是把RAG当成“一个数据库的API”来用而是意识到检索是一个需要设计和调优的子系统。这也是这个话题最核心的得分点。1.2 三层检索是哪三层为什么是这个顺序我通常会把RAG的检索主链路分成三层查询理解层在拿到用户问题之后先判断这个问题适合直接回答、走RAG还是先改写再检索。多路召回层用不同方式从知识库中拉回候选片段包括稀疏检索、稠密检索、结构化查询、知识图谱查询等。精排与上下文构建层对召回结果重新排序、去重、压缩在受限于上下文窗口的情况下选出最有利于生成答案的片段。这个顺序不是随便排的。它对应的是数据在一套RAG系统里的实际流动方向先处理query再获得候选集最后优化输入给大模型的上下文。面试时按这个顺序讲逻辑是顺的。追问到任何一层时也都能往下展开。反过来如果一上来就讲向量数据库、Embedding模型、FAISS索引这些实现细节面试官会很难判断你的全局观。细节当然要讲但要放在对应的层级里讲。2. 第一层检索查询理解层先让问题变得可匹配2.1 大多数RAG效果差问题其实出在原始query这里先说一个容易踩的坑。很多RAG项目上线后效果不好第一反应是换Embedding模型、调切块大小或者换向量数据库。但真正追下去会发现很多问题出在用户query本身表达太短、专有名词拼写不准确、口语化严重、指代不明确、问题里包含多个需要分开回答的子问题。最典型的情况是用户只输入一个名词比如“合同违约金”。这个query进入向量检索后匹配出来的片段往往很泛可能同时包含采购合同、劳动合同、销售合同里的违约金条款。如果查询理解层不做任何干预召回结果很难稳定。正确做法是先识别用户问题里的核心实体和限制条件再决定要不要加上“合同类型”“适用场景”这类限定。所以第一层检索的实际目标是让query从“用户原话”变成一个“更有可能命中知识库的表达”。这不只是一个可有可无的优化步骤而是RAG链路里被忽略最多的效果瓶颈。2.2 查询改写、HyDE和多跳拆解怎么用查询改写是最常见的做法。典型操作包括把错别字纠正过来把“它”“这个”之类的指代词替换成具体实体把口语化问题改写成书面表达给短query补充业务上下文。改写的实现方式可以用规则也可以让大模型根据历史对话和知识库结构生成改写后的query。复杂场景里一条问题会被改写成多条平行query分别走检索再合并结果。HyDE是另一种思路。它的做法是让大模型根据用户问题先生成一个“伪答案”再用伪答案去做向量检索。原理很好理解用户问题通常很短信息量不够但伪答案是一段相对完整的描述把它转成向量后更容易和知识库里的文档片段在语义空间里靠近。HyDE适合那些query信息量不足、同义表达差异大的场景代价是多了一次大模型生成调用延迟会变高。多跳问题拆解对应的是这类问题“A公司去年发布的新模型相比它上一代有什么改进”。这种问题里包含两个信息点直接拿整句话去检索容易只命中“新模型”或只命中“上一代”的相关文档。更稳妥的处理是拆成“找出A公司去年发布的新模型”和“找到这个模型的上一代”两步每一步单独检索再把结果串起来供大模型综合回答。需要提醒的是查询改写不是越激进越好。改写得过多会把原问题里的限定条件丢掉甚至引入大模型凭空补出来的信息。面试里可以补一句改写应该尽量保留原意如果拿不准就把原始query和改写后的query一起走检索再做结果合并。2.3 什么时候要升级到Agentic RAG如果只有一层固定的“改写检索生成”遇到下面的场景会很僵知识库完全能回答的问题系统非要走一遍RAG成本和延迟白白增加需要多轮检索才能回答好的复杂问题系统只检索一次用户问的是知识库里没有的信息系统仍然硬检索最后生成一堆幻觉。Agentic RAG解决的就是这类问题。它把决策能力交给大模型先判断要不要检索、检索哪类知识源、是否只需要一次检索还是需要迭代多轮检索结果不够再决定下一步是改写query、换一路召回还是直接告诉用户“知识库里没有”。这种模式不是要推翻三层检索而是让每一层都具备“动态决策”能力。面试中讲到Agentic RAG时可以把它理解为查询理解层的进阶版本。关键在于说清楚什么时候走固定RAG什么时候走Agentic RAG。我的经验是固定RAG链路适合高频、意图明确、答案稳定的问题Agentic RAG适合问题复杂、知识源多、结果需要不断确认的场景。两者不是替代关系而是按业务需求选择。3. 第二层检索多路召回层先让候选量够大3.1 为什么只做向量检索不够只靠向量检索的RAG系统在生产环境里通常会遇到三类问题。第一类是专有名词和精确标识符失效。比如产品型号“ABC-3000”、数据库字段名“user_profile”、一段代码里的函数名这些文本本身没有多少语义信息转换成向量后可能落在空间中很普通的位置相似度排序反而不如直接做关键词匹配稳定。第二类是长尾词和缩写问题。公司内部系统的缩写、人名、地名用向量检索找出来经常不准。第三类是结果过于“语义化”。用户问“如何配置Nginx反向代理”向量检索可能召回一堆讲“Nginx负载均衡”的文章因为它们在语义上高度相关但用户要的其实是精确的配置步骤。所以“向量混合检索加BM25多路召回”会成为一个高频优化项。BM25这种稀疏检索方法擅长精确命中关键词对专有名词、型号、编号、代码片段特别友好向量检索擅长处理同义改写和语义相关。两者互补正是多路召回存在的意义。3.2 常见的三路召回稀疏检索、稠密检索、结构化查询召回阶段的核心目标是“宁可多召回也不要漏掉关键证据”。常见做法至少包含三路第一路是稀疏检索。用BM25或基于倒排索引的搜索引擎比如Elasticsearch。它适合处理精确关键词、属性过滤和时间范围筛选。比如“2023年发布的合同模板”可以先通过倒排索引把“合同模板”命中再过滤年份。第二路是稠密检索。用Embedding模型把query和文档片段转成向量用FAISS、Milvus、Qdrant这类向量检索引擎找相似度最高的片段。它适合语义匹配比如用户问“公司请假制度”文档里写的是“休假管理规范”这种同义表达靠关键词很难命中向量检索可以。第三路是结构化查询。如果知识库里有知识图谱、本体或关系型数据可以走实体与属性查询。比如用户问“某部门下有哪些项目负责人”这类问题与其去切片的文档里找不如直接查关系数据。ontology RAG等思路本质上就是让RAG不局限于非结构化文本而是把知识库里的结构化信息也当成一路检索来源。实践里很少同时上三路通常先上“BM25向量检索”两路覆盖绝大多数场景。只有知识库中实体关系类问题占比很高时才值得引入知识图谱查询。3.3 多路召回结果融合与参数判断多路召回的难点不是“能把结果都查出来”而是“多路结果合并后怎么排序”。两路甚至三路检索返回的分数体系完全不同BM25的分数和向量余弦相似度不可直接比较。常见做法有两种。一种是RRFReciprocal Rank Fusion也叫倒数排名融合。它不看具体分数只看每个文档在不同路的排名。排名越靠前融合后的分数越高。这种方法实现简单、对分数尺度不敏感工程里用得很多。另一种是加权分数融合。先对每一路结果做分数归一化再按权重求和。权重的确定依赖实验比如“向量检索分数占比0.6BM25占比0.4”。这种做法更精细但需要针对业务反复调权。还有两个参数要单独说。一个是每路召回多少条常见设置在20到50之间。另一个是融合后最终保留多少条进入精排常见设置在5到15之间。如果融合后候选仍然太少比如单路只有3条结果先不要急着调权重要看是知识库里本来缺内容还是query改写不到位还是索引没有覆盖到目标文档。注意多路召回阶段不要一上来就追求“精确”。这个阶段的目标是召回全哪怕混入少量不相关片段也没关系后续有精排兜底。如果召回阶段就设得很严真正正确的片段很容易被过滤掉。4. 第三层检索精排与上下文构建层决定模型看到什么4.1 交叉编码器rerank把“相关”再过滤一遍向量检索阶段用的Embedding模型大多是双编码器结构query和doc分别编码成向量再算相似度。这种结构检索效率高但精度有限因为query和doc在编码阶段没有交互。它适合做“粗召回”不适合做最终排序。精排阶段通常换成交叉编码器。交叉编码器把query和doc拼在一起送进模型算出一个相关性得分因为两者在模型内部充分交互相关性判断更准确代价是速度慢。实际落地时不可能对候选集所有文档都做交叉编码所以顺序一般是召回阶段用双编码器快速筛出几十条候选精排阶段再用reranker对这些候选重新打分排序。常见做法是在第三层选择5到10条真正相关的结果进入最终上下文。bge-reranker这类开源rerank模型在中文场景里用得比较多具体版本以实测效果为准。如果团队资源有限也可以用大模型自带打分能力做简单精排例如把候选片段逐条让模型判定相关性但要注意token成本和延迟。4.2 上下文压缩和去重避免关键信息被淹没精排之后另一个高频问题是重复。多路召回的结果经常会出来多段几乎相同的内容尤其在知识库存在多个版本文档、相似文档或同一条内容被切进多个相邻块的时候。如果不做去重LLM的上下文会被重复信息占满真正的差异化内容反而挤不进去。去重可以分两层。第一层是文本相似度去重根据embedding向量之间的相似度把重复度较高的片段合并保留一个。第二层是信息量去重如果片段内容明显是另一段的超集保留更完整的那段。上下文压缩做得更细的话还可以从候选片段中抽取出与query最相关的句子或段落而不是把整个chunk塞进上下文。常见做法是按句子切分片段给每个句子算相关性按相关性排序后组装成紧凑上下文。这种做法会牺牲一部分上下文连贯性但能让模型更聚焦。具体要不要压缩取决于知识库文档质量和上下文窗口大小。4.3 上下文窗口分配和引用溯源第三层检索里上下文分配也是一个容易被忽略的策略。假设上下文窗口只有4000 token知识库里单个片段平均800 token那最多放5段。如果只按相关分数从高到低取前5段很可能出现这样一种情况第5段的分数也不低但包含的信息和前面重复或者它单独看相关合起来看和问题无关。更稳的分配方式是先按业务属性把上下文分成几个槽位比如“定义说明”“规则条款”“案例说明”每类最多保留1到2段再按相关分数填充。引用溯源也建议在这个环节做。给每段进入上下文的片段打上文档ID、章节标题、片段起止位置然后要求大模型在生成时标注引用来源。这样一旦答案错误可以快速定位是哪个片段误导了模型。面试中能说出这一步通常会让面试官觉得你不是停留在玩具Demo层面。5. 除了三层检索切块、向量化和索引也会被追问5.1 切块策略直接影响召回质量三层检索讲得再完整底层的数据准备如果糙前面三层的效果都会打折。面试中很可能围绕“RAG切块策略”继续追问。切块没有万能答案但有几个明确判断标准。块太大比如1000 token以上一个块里包含多个主题向量化之后语义被拉平检索出来的片段可能只有一句话有用其他全是噪音。块太小比如100 token以下语义被切碎实体和上下文被拆开召回精度也会下降。常用起点是256到512 token之间同时设置一定比例的overlap比如50 token的重叠保证跨块语义不丢失。更进阶的做法是按文档结构切分Markdown按标题切HTML按标签语义切PDF按段落切代码按函数或类切。这样每个块自带主题边界检索和引用都会更清晰。5.2 Embedding和索引的选择逻辑Embedding模型不是越贵越好关键看知识库语言和业务领域。中文知识库通常优先测中文优化过的Embedding模型英文场景选择更多但最终都要用一批真实业务query做效果对比不能只看榜单分数。向量索引方面常见选择有FAISS、Milvus、Qdrant、Chroma等。如果知识库规模不大比如只有几万条文档片段FAISS或Chroma足够。到了百万级数据、并发访问高、需要水平扩展时再考虑Milvus或Qdrant这类服务化数据库。面试里讲到这个层级重点不是报菜名而是说清楚“根据数据规模、部署环境和并发要求做选择”。有些RAG项目一开始未必需要独立向量数据库。几十MB的文本数据用文件加载、内存索引也跑得起来。稳定运行后再考虑迁移到服务化组件这个顺序是更务实的工程路径。5.3 检索效果怎么量化评估如果没有评估指标上面说的所有优化都可能变成自我感觉良好。RAG检索环节至少要看两类指标。一类是检索质量指标包括召回率、命中率、MRR、NDCG。常用的评估方式是把一批用户问题准备好人工标注出每个问题应该命中的文档片段然后看检索系统能否把这些目标片段排到前面。另一类是端到端指标包括答案准确率、引用准确率和幻觉率。答案准确率关注最终回答是否正确引用准确率关注回答里引用的片段是否真的能支撑对应结论幻觉率关注回答有没有超出给定上下文。实际项目中两类指标缺一不可。检索指标好了端到端不一定好因为生成环节可能没有遵循上下文端到端好了检索指标不一定能看出问题因为模型可能只用了其中一小段正确内容。面试里能把这两类指标分开讲会让回答更有层次。6. 面试追问“遇到的问题”时按链路排查才加分6.1 从“没有召回、召回不准、生成不对”三个现象反推面试官很可能会追加一个问题“你实际做RAG时效果不好会怎么调”这里最怕的回答是“换模型”和“换数据库”。更稳的思路是先判断问题出在哪一层。如果现象是没有召回也就是检索结果为空或极少。优先检查query改写是否正确索引目录是否覆盖知识库文档切块后是否有内容被丢弃以及知识库里是不是真的存在相关材料。这个阶段不要急着调rerank因为结果还没到精排就断了。如果现象是召回了一堆结果但相关性差。优先看多路召回的配置向量检索用的Embedding模型是否适配领域BM25分词器是否支持中文和专有名词多路结果融合权重是否合理topK是否过大导致噪音比例升高。如果现象是召回的相关片段看起来对但生成结果不对。问题可能出在第三层关键证据没有被选进最终上下文上下文被重复信息占满多个候选片段互相矛盾或者生成prompt没有强调“只能基于给定上下文回答”。6.2 我建议的调试顺序和升级路线如果从零开始搭一套RAG知识库我的建议是不要直接上完整版三层检索而是先跑通一个最简基线基线文档切块 - Embedding向量化 - 向量检索Top20 - 直接拼上下文 - LLM生成在基线之上每加一层优化就要做一次评估避免同时改多个变量导致无法定位效果来自哪里。推荐的升级顺序是先加查询改写解决用户query信息量不足的问题。再加BM25与向量检索的多路召回用RRF融合解决精确匹配和语义匹配互补问题。再加rerank精排解决召回结果排序不准的问题。最后加上下文压缩和引用溯源解决上下文浪费和答案不可验证的问题。每一层升级之后跑同一批测试问题记录指标变化。如果能清楚说明每层优化的前后差异面试时讲出来会比背概念更有说服力。6.3 一套可复用的RAG策略表述模板面试现场如果需要在短时间内组织答案可以按下面这个结构组织先给结论“RAG策略的核心是三层检索。第一层是查询理解解决用户query和知识库表达不一致的问题第二层是多路召回用BM25加向量检索保证候选集足够全第三层是精排和上下文构建用reranker选出最相关的片段再通过上下文压缩和引用溯源保证生成质量。”然后挑一层往下讲一个具体案例比如“我在某个项目里发现向量检索对产品型号匹配不准后来加入BM25多路召回用RRF融合产品型号类问题的命中率提升明显。”最后补一个踩坑点“多路召回不是越多越好如果某些召回路效果一直很差融合后反而会把排名拉低需要定期评估保留或下线。”这样回答既有全局又有细节还有工程判断。RAG策略这个话题本身不难难的是能不能把知识点组织成一条可落地的调试链路。把三层检索当成排查路径来记比死记术语有用得多。