【 第三篇 】搜索 / 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一下，以后再来狗尾续貂

多谢楼主，最近我也面试了很多agent相关的，感觉企业关心的最多的是security，这个东西是textbook上基本上不会教的，比方说ACL metadata prefilter, cache should also be ACL aware. ingestion pipeline 怎么monitor ACL change especially permission removal for certain group.

还有就是跨国公司的一些data compliance的问题，比方说gdpr如何做到data在eu储存和处理，你的control plane和data plane如何设计。

eval harness, observability和deployment 也都很重要

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