RAG 面试题到底应该怎么拆
一句话总结
RAG 面试不是考你记不记得住检索增强生成的论文标题，而是考你在信息不完整、系统有噪音、业务目标冲突时，能不能把"用户问了一个问题"到"系统给出答案"这条链路上的每个环节拆开来看。面试官想听的不是"我用 FAISS 做了向量检索"，而是"这个场景下检索的 recall 和 precision 哪个权重更高，为什么，以及如果用户追问你怎么判断上下文是否还足够"。
不是让你背诵 RAG 的架构图，而是让你证明你能把架构图上的每个框都变成一道判断题。
适合谁看
这篇文章写给正在准备 RAG 相关岗位面试的人，特别是那些简历上写了"搭建 RAG 系统"却在面试中被追问到沉默的候选人。你不是不知道 RAG 是什么，你是一道题拿到手里不知道从哪里下嘴。你可能是从大模型应用团队出来的后端工程师，简历上写着"负责知识库问答系统"，面试时被问"如果检索召回的文档和用户问题语义相关但 factual 错误，你怎么设计链路"，你开始讲 embedding 模型的选型，面试官打断你问"所以你的判断标准是什么"，你意识到自己一直在描述流程而不是做判断。你也可能是从传统搜索团队转过来的算法工程师，对倒排索引了如指掌，但面对面试官问"向量检索和关键词检索的融合策略"时，把两种检索方式各讲了一遍，没敢说哪种场景下应该放弃其中一种。
你还可能是应届生，刷了一百道八股文，面试时发现面试官根本不问你 RAG 有几个模块，而是给你一个具体 case："用户上传了一份 200 页的 PDF，前 50 页是目录，问了一个问题，系统召回的全是目录页，你怎么拆这个问题？"你准备了 RAG 的五种范式，却不知道这个 case 该用哪个范式来答。这篇文章就是替你判断：遇到 RAG 面试题，第一步该拆什么，第二步该验证什么，第三步该放弃什么。
不是背架构图，而是把每个框变成判断题
大多数候选人准备 RAG 面试的方式，是把 LangChain 的文档或者某篇综述论文的架构图背下来。面试时一被问到"讲讲你的 RAG 系统"，就开始从左到右念：用户查询进来，先做 query rewriting，然后做 retrieval，然后做 reranking，然后做 generation，最后输出答案。
面试官听完点头，然后问："如果 retrieval 这一步什么都没召回，你的系统怎么办？"你愣住了，因为架构图上没有画这条分支。
不是 RAG 没有这条分支，而是你把"描述系统"当成了"设计系统"。描述系统时，每个模块都是必选项；设计系统时，每个模块都是一道判断题。query rewriting 要不要做？取决于用户问题的歧义程度和业务对延迟的容忍度。一个做企业内部知识库的 RAG 系统，用户问题往往是结构化的"这个项目的 deadline 是什么"，这时候做 query expansion 反而可能引入噪音；但一个面向 C 端的开放域问答系统，用户问"那个东西怎么样"，不做 query disambiguation 根本不知道怎么检索。
retrieval 用 dense 还是 sparse？不是 dense 更先进所以选 dense，而是要看你的知识库更新频率和实体类型。医疗领域的新药名称，dense retrieval 可能因为训练数据里没有而完全无法召回，这时候必须保留 sparse retrieval 作为兜底。reranking 要不要上交叉编码器？不是效果一定更好，而是你的 QPS 和延迟预算允不允许。一个内部工具，答案生成等 5 秒可以接受，上 cross-encoder 精细排序没问题；但一个实时客服场景，用户问题进来 3 秒内必须给出第一个字，reranking 的 latency 可能直接杀死这个方案。
面试时一个典型的 dead air 时刻是这样的：面试官问"你的检索模块是怎么设计的"，候选人回答"我们用了向量检索，基于 cosine similarity"，然后停下来等面试官反馈。面试官追问"cosine similarity 的阈值设多少"，候选人开始犹豫"嗯...我们设了 0.7 左右"，面试官问"0.7 是怎么来的"，候选人答不上来。这个对话的断裂点在于，候选人把"用了什么"当成了答案，但面试官想问的是"为什么这个值，以及什么情况下会变"。
正确的打开方式是：我们初始阈值设在 0.75，基于前 1000 条查询的离线评估，这个值在 precision 和 recall 上达到我们业务可接受的平衡点；但上线后发现对于长尾实体查询，这个阈值会过滤掉正确文档，所以我们增加了基于 query 复杂度的动态阈值策略，简单查询收紧、复杂查询放宽。不是你在背参数，而是你在解释参数背后的判断逻辑。
> 📖 延伸阅读：Riot Games软件工程师面试真题与系统设计2026
拆解 RAG 面试题的四个锚点
拿到任何 RAG 相关的面试题，不要急着给方案，先找四个锚点：数据特征、用户意图、失败模式、业务约束。这四个锚点不是让你背诵的框架，而是让你快速定位面试官真正想问什么。
数据特征锚点解决的是"你的知识库是什么样的"。同样叫"文档"，PDF 扫描件、结构化的数据库记录、实时更新的网页、多模态的图文混排，每一种的拆解方式完全不同。面试里一个经典的陷阱题："如果你的知识库是 10 万份产品说明书，每份 50-200 页，用户问题是'这个型号的保修期多久'，你怎么设计检索？"很多人开始讲 chunking strategy，讲 overlap size，但漏掉了最关键的一点：产品说明书是高度结构化的文档，有明确的章节层级和表格结构。
这时候你的 chunking 不是按固定 token 切分，而是要保留文档结构信息，让 chunk 的 metadata 里带上"这是保修条款章节"。更进一步，这类查询的答案是确定的、简短的，甚至不需要走完整的 generation，可以直接用检索到的结构化字段回答。面试官在这里想听的判断是：你知道什么时候该用 RAG，什么时候其实只是一个结构化搜索问题。
用户意图锚点解决的是"用户到底在问什么"。RAG 系统的一个常见失败模式，是把用户的问题当成最终问题来检索，但用户的问题可能是多轮对话中的 follow-up，可能包含指代消解，可能是条件反射式的模糊表达。面试中一个高区分度的问题："用户先问'你们公司的退款政策是什么'，系统回答了；用户接着问'那如果我是 VIP 呢'，这时候检索该怎么处理？
"平庸的回答是"把上一轮的上下文加进去一起做检索"；好的回答是判断"这个 follow-up 的语义重心在于 VIP 身份的限定条件，检索时应该强化 VIP 相关的文档权重，同时过滤掉普通用户的政策条款"。不是简单地加上下文，而是判断上下文中的哪些信息应该被提取、哪些应该被抑制。
失败模式锚点是面试官最常挖坑的地方。任何系统设计中，面试官想听的不是"这样设计会成功"，而是"这样设计会在哪里失败"。RAG 的典型失败模式包括：检索召回正确但生成幻觉、检索召回错误但生成正确（运气好）、检索召回为空但生成强行回答（最危险）、检索召回大量冗余信息导致生成冗长且偏离重点。面试时主动分析这些失败模式，比被动等面试官追问要加分得多。
一个具体的对话场景：面试官问"怎么评估你的 RAG 系统好坏"，候选人答"我们用 answer relevance 和 context precision 两个指标"，面试官问"如果这两个指标都高，但用户反馈还是说答案不好，可能是什么原因"。候选人如果回答"可能是用户问题本身不清晰"，就掉入了把责任推给用户的陷阱；更好的判断是：这两个指标都是基于 reference answer 的，但 reference answer 本身可能是错的，或者用户的好不是"答案相关"那么好，而是"答案帮我节省了操作步骤"那么好。不是指标越高越好，而是指标和业务目标是否对齐。
业务约束锚点决定了你的方案是纸面漂亮还是真能落地。延迟约束、成本约束、合规约束，每一个都可能推翻你精心设计的算法方案。一个真实的 debrief 场景：某候选人面试时讲了一个基于多轮交互式检索的方案，技术细节非常丰富，hiring manager 在 debrief 时问了一个问题"这个方案一次查询要调几次模型"，候选人答"平均 4-5 次"，hiring manager 摇头"我们的 unit economics 不允许这么玩"。
不是方案不好，是方案和业务模型不匹配。硅谷 RAG 相关岗位的薪资参考：base $130K-$220K，RSU $50K-$300K/年（依公司阶段和级别），bonus 10%-20% of base。能拿到这个 package 的人，必须竣必须能在技术理想和业务现实之间快速找到平衡点。
面试流程拆解：每一轮在考察什么
RAG 岗位的面试通常 4-6 轮，总时长 3-5 小时，分两天或集中一天完成。不是每一轮都问 RAG，但每一轮都在考察你做 RAG 需要的某种能力。
第一轮通常是 hiring manager 面，30-45 分钟。这一轮的重点不是技术深度，而是你的问题定义能力和沟通效率。HM 会用 5 分钟讲他们团队在做的事情，然后抛出一个开放问题："我们现在的 RAG 系统在某某场景下效果不太好，如果是你，会怎么入手分析？"注意，这不是让你给方案，而是看你问问题的质量。平庸的候选人直接开始给建议；好的候选人会先问："不太好具体是什么表现？
是检索不准、生成幻觉、还是延迟太高？"再问："这个场景下用户的典型 query 是什么格式的？是长尾查询还是头部查询？"HM 心里在记：这个人能不能在信息不完整时先做合理假设、再快速验证。这一轮常见的失败模式是候选人讲得太多、听得太少，HM 已经暗示了某些约束条件，候选人还在推自己的预设方案。
第二轮到第四轮通常是技术深度面，系统设计 + 算法 + 代码，各 45-60 分钟。系统设计面会给一个具体场景让你设计完整链路，比如"设计一个面向医生的药物相互作用查询 RAG 系统"。这里的关键锚点是 safety 和 explainability：药物信息人命关天，你的检索必须有溯源，生成必须有置信度标注，不能直接丢一个答案出去。
算法面可能深入问 retrieval 的具体实现：embedding 模型的选择（不是越新越好，医疗领域可能要用专门训练的 PubMedBERT）、相似度计算方式（cosine vs dot product vs 归一化前的原始距离）、向量数据库的选型（不是 Pinecone 一定好，要考虑数据隐私和合规）。代码面通常不是让你从头写个向量数据库，而是实现某个核心模块，比如一个带缓存机制的检索器，或者一个基于 LLM 的 query rewriter。代码质量考察的是：你能不能写出可维护、可测试、有边界情况处理的工业级代码，不是 leetcode 那种一次性跑通就行。
第五轮可能是 cross-functional 面，产品经理或数据科学家来面。这一轮考察的是你不是个纯技术宅，能理解 RAG 系统的业务价值怎么衡量。PM 可能会问："如果我们把 retrieval 的 recall 从 80% 提升到 90%，但延迟增加了 200ms，这个 trade-off 你做不做？
"不是 recall 越高越好，而是这 10% 的 recall 提升覆盖的是哪些 query 分布、这些 query 对应的业务价值有多大、200ms 延迟对用户体验的量化影响是什么。数据科学家可能会问："你怎么设计 A/B test 来验证 RAG 改动的效果？"不是简单对比新旧版本的 answer relevance，而是要考虑用户行为的延迟反馈、session 级别的指标设计、以及如何避免 novelty effect。
最后一轮通常是 bar raiser 或 senior leader 面，考察的是你的技术判断力和长期视角。常见问题是："如果三年后 LLM 的上下文窗口长到能装下你们整个知识库，RAG 还有存在的必要吗？
"这个问题没有标准答案，但面试官想听的是你的判断逻辑：不是简单地说"有"或"没有"，而是分析上下文窗口增长和 RAG 各自解决的是什么问题——前者解决的是"能不能装下"，但装得下不等于检索效率高、不等于能处理多用户并发、不等于能解决幻觉和溯源问题。RAG 的本质是检索增强，不是 context 受限时的权宜之计。
> 📖 延伸阅读：John Deere数据科学家面试真题与SQL编程2026
具体场景：debrief 室里在争论什么
参加过 hiring committee 的人会知道，关于 RAG 候选人的讨论经常围绕一个核心分歧：这个人是"搭过 RAG 系统"还是"设计过 RAG 系统"。两者的区别在 debrief 中体现得淋漓尽致。
一个具体案例：候选人在面试中描述了一个基于 hybrid search 的方案，dense retrieval 用 cosine similarity，sparse retrieval 用 BM25，然后用一个线性层融合两者分数。面试官追问"这个线性层的权重怎么定"，候选人回答"我们调参调的，最终效果比较好"。debrief 时，面试官 A 认为候选人"有实践经验，能干活"，面试官 B 认为"没有结构化思维，不知道权重背后的业务含义"。HC 里的争论焦点是：这个权重是固定的还是 query-dependent？
如果是固定的，意味着所有类型的查询都用同一套融合策略，这显然不合理；如果是 query-dependent，候选人为什么没有主动提到？最终这个 candidate 的 feedback 是"hire with concern"，concern 就在于"能复现已知方案，但面对新场景时缺乏第一性原理的思考"。
另一个 debrief 场景是关于 evaluation 的讨论。候选人在面试中花了大量时间讲他们怎么建 evaluation dataset，怎么标注 relevance，怎么算 NDCG。听起来很专业，但 hiring manager 问了一个问题："你们这个 evaluation，和实际上线后的用户满意度，correlation 是多少？
"候选人愣了一下，说"我们没有专门算过"。debrief 时， senior staff 评论："这是典型的指标 vanity，把 evaluation dataset 的分数当成了目标本身，不知道最终要优化的是什么。"不是 evaluation 不重要，而是你的 evaluation 必须和 business outcome 建立联系，否则就是自嗨。
还有一个更微妙的分歧点：candidate 对 LLM 本身的态度。有些 candidate 把 LLM 当成黑盒，RAG 的作用就是把相关上下文塞进 prompt 里，让 LLM 去发挥；另一些 candidate 会仔细分析 LLM 在生成阶段的 failure mode，比如当检索到的上下文互相矛盾时 LLM 会怎么处理，从而设计相应的 prompt 策略或后处理逻辑。
debrief 时，前者常被标记为 "RAG engineer"，后者才是 "RAG system designer"。硅谷这边，前者的 base 可能在 $130K-$160K，后者的 base 可以到 $200K-$250K，差别不在工作年限，而在问题拆解的深度。
准备清单
- 画一张你自己的 RAG 架构图，但不是标准教科书版本，而是标注了每个模块的"如果失败会怎样"——query rewriting 失败导致检索偏差、retrieval 失败导致生成幻觉、generation 过度自信导致错误答案被包装得很确定。这张图的目的是让你在面试中被追问时，能快速定位问题环节。
- 准备三个你亲自处理过的 RAG 失败 case，按照"现象-根因-你的判断-最终方案"来组织。不是准备成功案例，失败 case 更能体现你的分析深度。面试中主动提失败 case，比等面试官问出来要加分。
- 系统性拆解面试结构，PM 面试手册里有完整的系统设计实战复盘可以参考，特别是关于如何在信息不完整时做合理假设、如何在技术深度和表达效率之间平衡的章节。不是让你去买书，而是这类结构化的面试训练材料能帮你把零散的知识点组织成可输出的判断逻辑。
- 针对你的目标公司，调研他们的 RAG 应用场景。做客服的、做企业知识库的、做医疗的、做法律的，每个领域的约束条件完全不同。面试时提到你对他们场景的理解，比泛泛而谈"RAG 的五大优化方向"要有效得多。
- 准备一份你自己的"RAG 决策清单"：什么情况下用 dense retrieval、什么情况下必须用 sparse、什么情况下需要 reranking、什么情况下可以跳过 generation 直接返回检索结果。这份清单不是标准答案，而是体现你做过足够多判断的积累。
- 找一个人做 mock interview，但不要让对方当面试官，而是让对方扮演"故意听不懂的面试官"——你每说一句，对方就问"为什么"或"然后呢"，逼你把 implicit 的判断 explicit 化。RAG 面试中最常见的 gap，就是你以为你讲清楚了，但面试官没听到他的判断点。
常见错误
错误一：把 RAG 当成 LLM 的配件，而不是一个独立系统来设计
BAD：候选人回答"RAG 就是用向量数据库给 LLM 提供上下文，让 LLM 回答得更准确"。面试官追问"如果向量检索召回的文档和用户问题相关但包含过时信息，怎么办"，候选人回答"那可能是 embedding 模型不够好，我们可以换更好的模型"。
GOOD：候选人回答"RAG 的核心挑战不是'让 LLM 有上下文'，而是'确保给 LLM 的上下文是相关、及时、无矛盾的'。针对过时信息，我的判断是这个问题不能只在 retrieval 阶段解决，需要在 indexing 阶段建立文档版本管理和时效性标注，在 retrieval 阶段增加时效性过滤，在 generation 阶段 prompt LLM 标注答案时效性。
如果三个环节都失败了，还需要一个后验检测模块来捕获用户反馈中的时效性质疑。"
错误二：evaluation 只讲 offline metric，不提和业务目标的连接
BAD：候选人说"我们的 RAG 系统 NDCG@5 从 0.72 提升到 0.81，说明检索质量显著改善"。面试官问"那用户满意度有变化吗"，候选人回答"应该也有提升吧，我们没有专门测"。
GOOD：候选人回答"NDCG 的提升覆盖的是 head query，但我们的业务增长主要来自长尾 query。所以我同时 tracked 了一个 proxy metric：覆盖长尾 query 的 session 占比，以及这些 session 的后续转化率。
最终我们发现 NDCG 提升确实带来了长尾 query 满意度的提升，但转化率的提升幅度比 NDCG 小，说明 generation 环节还有优化空间，可能是答案过长导致用户没有 get 到关键信息。"
错误三：忽视多轮对话中的 context management
BAD：候选人被问到多轮对话时，回答"我们把历史对话也做 embedding，一起参与检索"。面试官问"如果历史对话中有用户纠正过系统错误，怎么处理"，候选人回答"可以加上一个权重，让最近的对话权重更高"。
GOOD：候选人回答"多轮对话中的 context 不是简单地加进检索，而是要区分三种信息类型：用户确认的（可以作为 strong signal）、用户纠正的（需要被抑制甚至反向标记）、中性的（正常处理）。我的判断是，用户纠正的信息比用户确认的信息更有价值，因为它直接揭示了系统的 failure mode。
所以我们设计了一个轻量的 feedback loop，把用户纠正的场景自动加入 negative sampling，用于持续优化 retrieval 模型。"
FAQ
Q1: 我没有做过完整的 RAG 系统，只在项目中用过 LangChain 或 LlamaIndex，面试时会不会露馅？
会，但不是因为工具用得少，而是因为你没有经历过"这个参数为什么要这样设"的决策过程。用 LangChain 搭个 demo 五分钟，但面试不会问你 chain 怎么拼，会问"为什么选择这种 chunking 策略、overlap 设多少、为什么"。没做过完整系统没关系，关键是你要把用过的每一个组件都变成一道判断题。
建议你把之前用 LangChain 做过的项目重新拆解一遍：每个默认参数你有没有改、为什么改、改了之后怎么验证的。如果全是默认参数，那说明你没有进入设计者的角色，面试时需要诚实承认这一点，同时展示你在其他场景下的判断能力。一个真实的 hiring manager 视角：我们招过的人里，有从无代码平台转过来的，但他能清楚讲出"之前平台封装的 chunking 不够灵活，我在某个 case 里发现固定 size 会切断表格结构，所以尝试了基于文档结构的 chunking，虽然最终没上线但验证了思路"——这种有判断过程的描述，比"我熟练使用 LangChain"有价值得多。
Q2: 面试官问"如果给你一个礼拜，你会怎么优化现有的 RAG 系统"，我该怎么答才能体现深度？
这个问题考察的不是你的优化清单有多长，而是你的优先级判断依据。最差的回答是列 10 个优化点，从 embedding 模型换到 reranker 再换到 generation 的 decoding strategy，没有主次。中等回答是按"影响面 x 实施难度"做个矩阵，挑出高性价比的先做。最好的回答是先问清楚约束条件：这个系统的核心痛点是什么（是准确率不够、还是延迟太高、还是新文档上线后很久才能被检索到）、用户最不能容忍的失败模式是什么、这个礼拜后有没有明确的 demo 或评估节点。一个具体的例子：我在面试中被问到这个问题时，先确认了系统当前最大的问题是医疗专业术语的召回率低，导致医生用户频繁反馈"查不到"。
我的判断是这个问题不能通过换通用 embedding 模型解决，因为医疗术语的语义空间和通用语料差异很大；同时考虑到一个礼拜的时间限制，从头训练领域模型不现实。所以我选择了基于现有检索结果的 error analysis，快速标注 200 条 bad case，找出术语变体（缩写、全称、英文混用）的模式，用基于规则的 query expansion 做快速缓解，同时启动领域 embedding 的微调作为中长期方案。面试官后续追问的都是 error analysis 的具体做法，而不是那个礼拜后的计划。
Q3: RAG 和 Fine-tuning 的关系在面试中怎么答才不会踩雷？
不是"RAG 更灵活所以优先 RAG"，也不是"Fine-tuning 更底层所以更 advanced"，而是要看你的知识更新频率、任务定义清晰度、以及标注数据的可获得性。一个高区分度的回答框架是：RAG 解决的是"知识从哪里来"的问题，Fine-tuning 解决的是"模型怎么更好地完成特定任务"的问题，两者不是互斥的。面试中一个经典的追问场景：面试官问"如果你们的知识库每天更新，RAG 和 Fine-tuning 怎么配合"。低质量的回答是"每天 Fine-tuning 成本太高，所以用 RAG"；
高质量的回答会分析：RAG 保证了知识的时效性，但 retrieval 的质量依赖于 embedding 模型对 query 和 document 的理解，这部分可以通过 Fine-tuning 来优化——不是 Fine-tuning LLM 本身，而是 Fine-tuning 嵌入模型或 reranker，让它们更好地理解领域特定的 query intent 和 document structure。更进一步，如果业务场景有明确的输出格式要求（比如医疗报告必须包含置信度标注），可以在 RAG 的 generation 环节配合轻量的 Fine-tuning 或 prompt tuning 来强化格式合规。面试官想听的判断是：你知道每个技术的边界在哪里，以及它们在系统里的协作关系，不是简单地站队。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。