【 第三篇 】搜索 / RAG 系统设计面试怎么答：一个做了一年检索的人的视角

这两年 RAG 火起来之后，system design 面试里出现了一类新题：「设计一个搜索系统」 或者 「给我们的文档库设计一个 RAG 问答」。
我自己这一年在流媒体广告这块做检索和 RAG，一边踩坑一边也面过人、被面过。感受是：这类题的答题模式还没有像「设计一个短链服务」那样被固化下来，所以八股文的收益很低，而真做过的人一开口就听得出来。这对有实际经验的人是好事。
这篇整理一下我认为的答题框架，以及哪些点说出来是加分项、哪些答法是雷。
一、先搞清楚面试官在考什么
先说个观察：这类题考的重点不在「你知不知道 HNSW 的原理」。
面试官真正想看的是三件事：
        1.        你能不能把一个模糊的业务需求，翻译成检索系统的具体约束（数据规模、延迟预算、更新频率、精确 vs 泛化）。
        2.        你有没有分层的意识——知道检索系统是漏斗，每一层的成本和职责不一样。
        3.        你怎么定义「做得好」，以及怎么验证。
第三点是最大的分水岭。绝大多数候选人能把架构图画出来，但一问「你怎么知道你的搜索变好了」就卡住了。能把评估讲清楚的人，在这类面试里是稀缺的。
二、开场：别急着画架构，先问清楚约束
上来就说「我们用向量数据库存 embedding 然后做相似度检索」是最常见的减分开局。太快跳到方案，而且暴露了你只见过一种做法。
正确的开场是花两三分钟把约束问出来。我一般问这几个：
规模类
        •        文档量级？百万还是十亿？（这直接决定索引选型和是否需要分片）
        •        QPS 多少？峰值和均值差多少？
        •        单文档多大？是短标题还是长文档？（决定要不要 chunk、怎么 chunk）
延迟类
        •        端到端延迟预算？100ms 还是 2s？
        •        这个预算是给纯检索的，还是包含 LLM 生成？（RAG 题里这个必须问清楚，生成往往占大头）
质量类
        •        用户的 query 长什么样？是关键词还是自然语言？
        •        精确匹配重要还是语义泛化重要？（这个问题问出来，面试官通常会眼前一亮）
        •        有没有「必须命中」的硬需求，比如按 ID 查、按权限过滤？
数据类
        •        文档更新频率？实时、准实时还是批量？（决定索引更新策略，很多人完全不提这块）
        •        有没有多租户 / 权限隔离？
问完这些，你已经比一半候选人强了。而且后面所有的设计选择都可以挂回这些约束上——这才是 system design 面试真正想看的能力：不是记住方案，是能论证方案。
三、主体框架：把检索讲成一个漏斗
推荐用分层漏斗来组织整个回答，这是工业界的通行结构，也最容易讲清楚：

Query 理解  →  召回（L1）  →  融合（L2）  →  精排（L3）  →  [ RAG: 组装上下文 → 生成 ]


每一层讲三件事：干什么、候选量级、成本量级。 这个讲法很容易让面试官跟上。
Query 理解层
很多人直接跳过这层，但它恰恰是投入产出比最高的地方，也是加分点。
        •        意图分类 / 路由：判断这是精确查询（ID、SKU、错误码）还是探索型自然语言查询，走不同的检索策略。
        •        Query 改写：补全省略、纠错、扩展同义词。注意这是热路径，要用小模型 + 缓存。
        •        RAG 特有：多轮对话里的指代消解——用户第二轮说「那它的价格呢」，你得先把「它」还原成上一轮的实体，否则检索出来的东西完全不相干。
召回层（L1）
目标是从百万/十亿缩到几百到一千，要快要便宜。
标准答案是双路并行：
        •        关键词路（BM25 / 倒排索引）：擅长精确 token、专有名词、ID。
        •        向量路（ANN，一般是 HNSW 或 IVF）：擅长语义泛化，query 和文档一个字不重叠也能召回。
讲的时候把两者的互补性说清楚：keyword 精确但不泛化，vector 泛化但对精确 token 迟钝——搜一个具体 ID，embedding 会给你一堆「语义很像但不是那个」的结果。这是它的固有特性，不是调参能解决的。
融合层（L2）
两路召回出来的分数量纲完全不同（BM25 分数 vs 余弦相似度），不能直接加。
RRF（Reciprocal Rank Fusion） 是工业界的默认解：只看排名的倒数，不看分数绝对值，天然规避量纲问题。能说出「为什么不能直接加权求和」比只报出 RRF 这个名字更有分量。
进阶加分点：RRF 默认两路等权，但你可以按 query 类型动态调各路的 k 值——精确 query 压低向量路的 k，探索型放大。这就把「召回该多宽」变成了一个可调参数。
精排层（L3）
这层最贵，所以只处理 top-K（通常 50 上下）。
        •        一般是 cross-encoder。和双塔 embedding 的区别要说清楚：双塔是 query 和文档分别编码、离线可预计算，所以快但精度有限；cross-encoder 把 query 和文档拼在一起过一遍模型，精度高但没法预计算，所以只能放在最后一层处理少量候选。
        •        这个「为什么不能拿 cross-encoder 直接扫全库」是很经典的追问，答得干净利落是加分的。
        •        现成方案（比如 Azure AI Search 的 semantic ranker）vs 自建（bge-reranker 系列）的取舍也可以顺带提一句。
RAG 部分：检索之后
如果题目是 RAG，检索讲完还有下半场，很多人这里就草草收尾了：
        •        Chunk 策略：大小和 overlap 直接影响召回质量和 token 成本，应该当成超参来调而不是拍脑袋定死。加分说法：chunk 的粒度要匹配「用户问题的粒度」。
        •        上下文组装：不是把 top-10 全塞进去。要考虑顺序（模型对首尾更敏感）、去重、以及 token 预算。
        •        引用和溯源：生产级 RAG 必须能指回原文，这是可信度的基础，也是面试里容易被追问的点。
        •        兜底：检索不到相关内容时，明确让模型说「不知道」，而不是硬编。
四、几个能明显拉开差距的加分点
上面是骨架，下面这些是我认为最能体现「真做过」的细节。
1. 主动提「先诊断瓶颈在 recall 还是 precision」
被问到「要不要上 embedding」的时候，不要直接回答要或不要，而是说要先做诊断：
拿一批真实 query，用现有 keyword 链路召回 top-100，标注其中真正相关的比例，得到 recall ceiling；再看当前的 nDCG@10。
        •        recall ceiling 高、nDCG 低 → 瓶颈在排序，投资 reranker
        •        recall ceiling 低 → 瓶颈在召回，embedding 是刚需
        •        两个都低 → 先修召回，因为排序修不了不存在的东西
最后这句是关键。reranker 再强，也重排不出一个没被召回的文档——这句话说出来，基本就把「背过八股」和「真做过」区分开了。
2. 索引更新策略
绝大多数候选人只讲查询路径，完全不提写入路径。主动提这块很占便宜：
        •        全量重建 vs 增量更新的取舍
        •        向量索引重建的代价（HNSW 增量插入会导致图结构退化，需要定期重建；IVF 类的分区索引在这方面更友好）
        •        更新期间怎么保证服务不中断（别名切换 / 双索引）
3. 成本意识
系统设计面试里主动算成本的人不多，但这在真实工作里是最重要的能力之一：
        •        向量存储和 embedding 调用是持续烧钱的，不是所有字段都值得向量化
        •        语义缓存：相似的 query 直接复用历史结果，能省掉整条检索+生成链路。RAG 场景 ROI 极高，但很多人想不到
        •        分层本身就是成本设计：贵的模型只碰最少的数据
4. 多租户和权限过滤
企业场景几乎必考。要点是 prefilter vs postfilter：
        •        postfilter（先检索再过滤）会导致结果数不足，且浪费算力
        •        prefilter 更好，但要注意：过滤太狠会让进入精排的候选量不足，重排质量直接崩
这个细节非常「实战」，讲出来很加分。
五、常见的雷
按我见过的频率排：
雷一：全程只讲向量检索。 张口闭口 embedding、向量数据库，完全不提关键词检索。这几乎是「只跟着教程做过 demo」的标志。真实系统里 BM25 依然是主力。
雷二：不问约束直接上方案。 百万文档和十亿文档是完全不同的系统，不问就答等于放弃了展示论证能力的机会。
雷三：说不清怎么评估。 「用户觉得好用」不是答案。至少要能讲出：离线 golden set + nDCG / recall@k / MRR，线上 A/B + 业务指标，以及离线指标只是业务指标的代理，两者的最优点不一定重合。
雷四：把 semantic search 和 vector search 混为一谈。 在 Azure AI Search 这类系统里，semantic ranker 是挂在召回之上的重排层，它本身不负责召回。这两个概念混用会被听出来。
雷五：只讲 happy path。 不提冷启动、不提没有召回结果时怎么办、不提索引更新、不提降级。
六、如果你想往这个方向准备
给几个我觉得实际的建议：
把一个项目讲到能经受追问。 这类面试里，「你做过什么」比「你知道什么」重要得多。挑一个你真做过的检索项目，把它的约束、选型理由、踩过的坑、以及最后怎么验证效果，整理成一条能讲十分钟的线。面试官一定会往细节问，能答出「我们当时为什么没选 X」这种，可信度是几个量级的差别。
自己搭一遍完整链路。 不用大，几万条文档就够，但要把 keyword、vector、hybrid、rerank 都跑通，并且建一个几百条的评估集去对比它们的效果差异。这个过程里你会遇到的问题，正好就是面试里被问的问题。
指标要能张口就来。 nDCG、recall@k、MRR 各自衡量什么、什么场景下该看哪个，这是基本功。
关注成本和工程，而不只是模型。 这个方向真正稀缺的不是会调模型的人，是能把检索做到又准又便宜又能扩的人。面试里体现出成本意识和工程权衡，比多背两个模型名字有用得多。
最后
总结一下：
        •        先问约束再画架构，所有选择都挂回约束
        •        用漏斗结构组织：query 理解 → 召回 → 融合 → 精排 →（生成）
        •        把「怎么评估」讲清楚，这是最大的分水岭
        •        主动提索引更新、成本、权限过滤这些「只有做过才会想到」的东西
也留几个我自己还在琢磨的问题，欢迎讨论：
        •        你们面这类题的时候，会考具体的索引参数（HNSW 的 M、efConstruction 之类）吗？还是只看架构层面？
        •        RAG 方向的岗位，面试里 coding 环节一般考什么？跟传统后端有区别吗？
        •        有没有人被问过「怎么防止 RAG 幻觉」这种偏产品的题？一般期待什么样的答案？
有帮助的话点个赞（狗头）。

三篇都认真看过了，干货不少，谢谢分享。

可能每个人理解文章的方式不同，我理解时有点没懂一些逻辑，不过放进我local model整理了一下，立刻明白 LZ 一些行文是什么意思，完全通了。虽然看到版主加精了，但我作为之前也做过一点RAG的经历，实名推荐一下这三篇。

讨论先Mark一下，以后再来狗尾续貂

感谢楼主分享，真的是干货满满！ 请问一下RAG在工业界都有哪些use case呢？ 我只做过oncall automation相关的rag项目，如果自己练手的话，楼主还有哪些用例推荐的呢？