RAG System Design 面试：检索、Rerank、Eval 与生产化

💡 核心要点 (Key Takeaways)

• RAG 面试的核心不是背 pipeline 名字，而是能按层讲清每层的 trade-off：chunk 策略影响召回、hybrid retrieval 影响精确词匹配、rerank 影响精度与延迟的平衡、ACL 影响企业场景安全。
• Eval 是 RAG 面试的分水岭：只讲 demo 的人说准确率，讲生产的人讲 recall@k、faithfulness、citation accuracy 和 regression，面试官会追问你怎么定义好以及怎么防止退步。
• 成本与延迟必须量化到层：embedding 成本、向量库查询延迟、rerank 延迟、LLM token 消耗，每一层都要能说出它对总延迟和总成本的贡献。
• 故障处理是区分中级和高级候选人的关键：embedding 服务挂了怎么降级、向量库挂了怎么兜底、质量下降怎么回滚，这些必须在面试中主动说出来。
• 7 天计划按每天一个模块推进，第 7 天做 45 分钟完整 mock 并录音回听，检查自己是否讲清了 trade-off 和 failure handling 而不是只讲了 happy path。

RAG System Design 面试考什么

RAG System Design 面试通常出现在 AI Engineer、Applied AI 和 MLE 岗位的 System Design 轮次，考察的不是你是否背过 pipeline 的名字，而是你能不能在 45 分钟内把一个模糊需求拆成可落地的架构，并在追问中讲清每一层的取舍。面试官给出的题目通常是「为一个企业知识库设计一个 RAG 系统」或「设计一个带引用的产品文档问答系统」，没有标准答案，但有一个明确的评分结构。作为 AI Engineer 面试，RAG 题的侧重点是生产化（成本、延迟、ACL、freshness），和 MLE 面试侧重评估体系不同；岗位侧的轮次结构和公司差异见 AI Engineer 角色页、MLE 角色页、OpenAI 公司攻略 和 Anthropic 公司攻略。

• 第一层：需求澄清。面试官期待你主动问出：文档规模和更新频率、用户是谁（内部员工还是外部客户）、答案是否需要引用、延迟要求（实时还是批量）、成本预算、权限模型。跳过这一步直接画架构图是最常见的扣分点，因为它说明你只会在 demo 层面思考。
• 第二层：架构分层。一个完整的 RAG 系统至少包含五层：数据接入与清洗、chunking 与 embedding、检索与 rerank、生成与引用、评估与监控。每层都要能说出它解决什么问题、有哪些常见方案、以及为什么选当前方案而不是别的。
• 第三层：生产化细节。成本与延迟的量化、故障降级路径、权限控制（ACL）、数据新鲜度（freshness）、评估体系（eval）和回归测试。这一层是区分「做过 demo」和「做过生产」候选人的关键，也是 AI Engineer 面试和传统 SWE System Design 最大的差异点。

需求澄清：面试前 5 分钟决定答案质量

需求澄清不是走过场，它直接决定你后面 40 分钟讲什么。一个结构化的澄清清单能帮你在 5 分钟内锁定题目的关键约束，避免答非所问。

• 数据规模与更新频率：文档量是 1,000 份还是 1,000,000 份？更新是实时的还是天级？这直接决定向量库选型（内存型 vs 分布式）和重建索引的频率。
• 用户与权限：用户是内部员工还是外部客户？是否需要按部门或角色做 ACL？外部场景的 prompt injection 风险和权限泄露风险显著高于内部场景，必须提前声明。
• 输出要求：答案是否需要附带引用（citation）？引用粒度是段落级还是句子级？是否需要拒答（abstention）——当检索不到相关内容时，系统是回答「我不知道」还是尽力猜？拒答策略对评估指标影响很大。
• 延迟与成本：P95 延迟要求是多少？如果用户等 5 秒可以接受，rerank 和长上下文都可行；如果要求 2 秒以内，必须做 embedding 缓存和 rerank 降级。成本预算决定你能用多大的 embedding 模型和 LLM 模型。
• 成功指标：面试官最在意你如何定义「好」。在澄清阶段就要说出：我会用 recall@k 衡量检索质量，用 faithfulness 和 citation accuracy 衡量答案质量，用 P95 延迟和成本 per query 衡量系统效率。

数据接入、Chunking 与 Embedding

数据层是 RAG 系统质量的下限，很多生产事故根因不在模型而在数据。面试中这一段的重点是讲清 chunking 策略的取舍，而不是罗列工具。

• 数据清洗：去重、格式转换（PDF / HTML / Markdown 统一为纯文本）、元数据提取（来源、作者、更新时间、权限标签）。元数据是后续 ACL 和 freshness 的基础，面试中要主动提到。
• Chunking 策略：固定长度（512 / 1024 token）、按语义边界（段落、标题层级）、滑动窗口（overlap 10-20%）。固定长度简单但会切断语义，按语义边界更准但实现复杂。面试中要能说出你选哪种以及为什么：文档结构规整（如法律合同）用标题层级切分，文档结构混乱（如论坛帖子）用固定长度加滑动窗口。
• Embedding 模型选择：多语言场景选 multilingual embedding，英文场景选专用英文模型。模型越大效果越好但成本越高，面试中要能说出一个具体的 trade-off 点，例如「在 10 万份文档规模下，embedding 成本占总成本 5-10%，换更大模型对召回率的提升通常小于 2 个百分点，不值得」。
• Contextual Chunking：Anthropic 提出的方法，在 chunk 前用 LLM 为每个 chunk 生成一段上下文说明（这个 chunk 属于哪个文档、哪一章、核心主题是什么），再对「说明 + chunk」做 embedding，能显著提升检索命中率。代价是 embedding 前多一轮 LLM 调用，成本增加，适合文档量不大但检索质量要求高的场景。

Hybrid Retrieval 与 Rerank

纯向量检索有一个已知弱点：对专有名词、错误代码、产品版本号的精确匹配能力弱。Hybrid retrieval 和 rerank 就是为解决这个问题而生的，面试中这一段的重点是讲清两者各自的定位和组合方式。

• BM25 与向量检索的组合：BM25 擅长精确词匹配（用户搜 error code E-5003 时 BM25 直接命中），向量检索擅长语义匹配（用户搜「数据库连不上」时向量检索命中「connection timeout」文档）。Hybrid retrieval 是两路召回后融合，常见融合方式是 reciprocal rank fusion（RRF），不需要调权重，实现简单。
• Rerank 的位置：rerank 在召回之后、生成之前，用 cross-encoder 对 top-20 候选做精排，取 top-3 到 top-5 进 prompt。Rerank 对精度的提升通常比单纯加大召回数量更明显，但延迟成本也更高（cross-encoder 推理比 embedding 慢 10-100 倍）。面试中要能说出：rerank 是精度换延迟的 trade-off，延迟敏感场景可以关掉 rerank 直接用 top-k 向量检索。
• Top-k 的选择：k 太小召回不足，k 太大 prompt 膨胀且噪声增加。经验值是 k=3 到 5，超过 10 通常收益递减。面试中如果面试官追问「k 怎么定」，正确答案是：用 golden set 跑 recall@k 曲线，找到边际收益拐点，而不是拍脑袋。
• 检索质量监控：上线后需要持续监控 recall@k 和 MRR（Mean Reciprocal Rank），如果文档更新后这两个指标下降，说明索引质量退化，需要触发重建或排查 chunking 问题。

ACL、Citation 与 Freshness

这三个是企业 RAG 面试的高频追问点，也是区分「做过 demo」和「做过生产系统」的关键。Demo 不需要权限，生产必须；demo 不需要引用，用户投诉全靠引用兜底；demo 用静态数据，生产数据每天都在变。

• ACL（访问控制）：企业场景中不同用户能看到的文档不同，RAG 必须在检索前做权限过滤。实现方式是在向量库的 metadata 里存权限标签（部门、角色、密级），检索时加上用户身份的 filter 条件。关键细节：权限过滤必须在检索层做，不能在生成层做——如果检索层把无权文档召回了，即使 prompt 里说「只用你有权限的内容」，模型也可能泄露。面试中要能说出：单端权限过滤（只靠 prompt）不可靠，必须双端（检索层 filter + 生成层验证）。
• Citation（引用）：答案中的每个关键论断都要能追溯到具体文档和段落。实现方式是在 prompt 中要求模型标注 [doc_id, chunk_id]，生成后做后处理验证引用是否真实存在。Citation 不只是用户体验问题，它是用户投诉时的兜底证据，也是评估 citation accuracy 指标的基础。
• Freshness（新鲜度）：文档更新后索引必须跟上，否则用户会拿到过期答案。实现方式有三档：实时（每次文档变更触发增量索引，延迟最低但成本最高）、定时（每小时或每天全量重建，成本可控但有过期窗口）、版本号（给每个 chunk 打时间戳，检索时过滤掉超过 N 天的旧版本）。面试中要能说出你选哪一档以及为什么，并补充：freshness 问题不能只靠索引更新解决，还要监控「用户问到的文档是否已经过期」这个指标。

Eval：RAG 面试的分水岭

Eval 是 RAG System Design 面试中最能拉开差距的部分。只讲 pipeline 的候选人到这里就停了，讲生产的候选人会继续说：我怎么知道这个系统好不好、怎么防止它变差、怎么在上线前发现问题。

• 检索层指标：recall@k（top-k 中是否包含正确文档）、MRR（正确文档排在第几位）。这两个指标衡量的是「检索有没有找到该找的东西」，与生成质量无关。面试中要能说出：检索层指标差的时候，先查 chunking 和 embedding，再查 query 改写，不要急着换 LLM。
• 答案层指标：faithfulness（答案是否忠实于检索到的上下文，不编造）、answer relevance（答案是否回答了用户的问题）、citation accuracy（引用是否指向正确的文档和段落）。OpenAI Cookbook 给出了用 LlamaIndex 测量这三类指标的标准方法，面试中如果提到具体工具名会加分。
• LLM-as-judge 的角色：人工评估成本高，生产中通常用 LLM-as-judge 做全量初筛，人工抽检 10-20% 做校准。但 LLM-as-judge 有已知偏差（位置偏差、长度偏差、自我偏好），面试中要能说出至少一个偏差和对应的缓解方法，例如「裁判模型和生成模型用不同家系，避免自我偏好」。
• Regression 与版本门禁：每次模型升级、prompt 修改或 chunking 策略变更，都要在 golden set 上跑 regression，关键指标不能低于阈值才能上线。这道门禁是防止「改了一个小地方，整体质量退步」的最后防线，也是 LLM 应用和传统软件最大的差异点——传统软件有 unit test，LLM 应用有 eval regression。
• 更完整的评估体系设计（golden set 构建、pointwise / pairwise、human rubric、A/B test）见 LLM Eval 面试：Golden Set、Human Eval 与线上指标。

成本与延迟：每一层都要能算账

面试中如果面试官问「这个系统的成本是多少」，只答「取决于规模」是零分。正确答案是把成本拆到每一层，给出量级估算，并说出哪些层可以优化。

• Token 成本拆解：总成本 = embedding 成本 + 向量库查询成本 + rerank 推理成本 + LLM 生成成本。其中 LLM 生成通常占 60-80%，是优化重点。具体到每层：embedding 成本与文档量成正比，一次性（增量更新后几乎为零）；rerank 成本与每次查询的候选数成正比；LLM 成本与 prompt 长度（= top-k chunk 总 token 数）和生成长度成正比。
• 延迟拆解：P95 延迟 = embedding 延迟 + 向量检索延迟 + rerank 延迟 + LLM 首 token 延迟 + 生成延迟。典型量级：embedding 50-100ms、向量检索 50-200ms（取决于规模和索引类型）、rerank 200-800ms（cross-encoder）、LLM 首 token 300-1,000ms、生成 500-2,000ms。总延迟通常 1.5-4 秒，如果要求 2 秒以内，必须做 embedding 缓存（相同 query 不重复 embedding）和 rerank 降级（低延迟场景跳过 rerank）。
• 成本优化手段：embedding 缓存（相同或相似 query 复用 embedding 结果）、rerank 只处理 top-20（不处理全部召回）、LLM 模型分层（简单问题用小模型、复杂问题用大模型）、流式输出（用户感知延迟降低，实际生成时间不变）、并发限流（防止突发流量打爆向量库）。
• 面试表达框架：先说总量级（「这个系统每 1,000 次查询大约 X 美元，P95 延迟 Y 秒」），再说拆解（「其中 LLM 生成占 70% 成本和 50% 延迟」），最后说优化（「如果要降 30% 成本，我会先做 embedding 缓存和 rerank 降级，预计能降 20-25%」）。

故障场景与降级路径

故障处理是区分中级和高级候选人的关键部分。面试官问「如果 embedding 服务挂了怎么办」，不是考你运维知识，而是考你有没有在生产环境中思考过失败路径。

• 数据源中断：上游文档系统（Confluence、Notion）不可用时，RAG 继续用旧索引回答，但要标记「答案基于 N 天前的数据」，并触发告警。不能直接返回错误，因为用户可能只是查历史文档。
• Embedding 服务故障：降级到 BM25-only 检索（不需要 embedding 服务），精度下降但系统可用。这是 hybrid retrieval 架构的额外好处——它天然提供了降级路径。如果 BM25 索引也挂了，返回「检索服务暂时不可用，请尝试直接联系支持团队」。
• 向量库故障：主库故障时切换到读副本（如果架构支持），或降级到 BM25。向量库故障通常是最高级别事故，因为所有查询都会失败，必须有监控和自动切换。
• LLM 超时或限流：换备用模型（小模型或不同供应商），或降级到「只返回检索到的文档摘要，不做生成」。LLM 限流是生产中最常见的故障，面试中要能说出：限流时不要重试（会雪崩），直接降级或排队。
• 质量下降：eval 指标（faithfulness、recall@k）连续下降时触发告警，自动回滚到上一个版本。这是 LLM 应用特有的故障类型——系统没有报错，但答案质量在退化，传统监控（CPU、错误率）抓不到，必须靠 eval 监控。

端到端示例：企业产品文档问答系统

假设面试官说「为你的公司设计一个产品文档问答系统，员工可以问任何产品相关问题」，下面是一个 45 分钟面试中可以按顺序讲出的完整答案框架（教学用虚构场景，非真实公司系统）。

• Step 1 — 需求澄清（5 分钟）：文档规模约 5 万份产品文档（API 文档、用户指南、FAQ），内部员工使用，需要按部门做 ACL（安全团队文档只对安全部门可见），答案必须带引用，P95 延迟要求 3 秒以内，预算每月 2,000 美元以内。成功指标：recall@5 ≥ 80%，faithfulness ≥ 0.9，citation accuracy ≥ 0.95。
• Step 2 — 数据层（5 分钟）：文档从内部 Wiki 同步，每天凌晨全量重建索引（文档更新频率是天级，实时重建成本不值得）。Chunking 按标题层级切分，chunk 大小 512 token，overlap 64 token。Embedding 用 multilingual 模型（文档含中文和英文），元数据包含部门、密级、更新时间。
• Step 3 — 检索层（8 分钟）：Hybrid retrieval，BM25 + 向量双路召回，RRF 融合，取 top-20。Rerank 用 cross-encoder 精排，取 top-4 进 prompt。ACL 在向量检索层做 metadata filter（用户部门 + 密级 ≤ 用户密级）。Freshness：每天重建索引，chunk 带时间戳，检索时不过滤（内部文档更新频率可控）。
• Step 4 — 生成层（5 分钟）：Prompt 要求模型只用检索到的上下文回答，必须标注 [doc_id, chunk_id] 作为引用，如果上下文不足以回答则输出「我无法基于现有文档回答这个问题」。生成后用后处理验证引用是否真实存在，不存在的引用删除。
• Step 5 — Eval 与监控（5 分钟）：Golden set 300 条，覆盖正常问题、边界问题（跨部门文档）、拒答场景（文档中不存在的答案）。上线前跑 regression，门禁：recall@5 ≥ 80%、faithfulness ≥ 0.9、citation accuracy ≥ 0.95。上线后监控：每日 recall@5 和 faithfulness（从用户真实 query 抽样 50 条跑 LLM-as-judge），P95 延迟和成本 per query。
• Step 6 — 成本与延迟估算（5 分钟）：Embedding 成本约 50 美元/月（5 万文档 × 512 token，一次性 + 每日增量），向量库（托管服务）约 200 美元/月，rerank 推理约 100 美元/月（假设每天 1,000 次查询），LLM 生成约 1,200 美元/月（假设平均 prompt 2,000 token + 生成 500 token，用中档模型）。总成本约 1,550 美元/月，在预算内。P95 延迟：embedding 80ms + 检索 150ms + rerank 500ms + LLM 1,800ms ≈ 2.5 秒，满足 3 秒要求。
• Step 7 — 故障与追问（7 分钟）：Embedding 服务挂了 → 降级 BM25-only，精度下降但可用；向量库挂了 → 切换到读副本，同时告警；LLM 限流 → 换备用小模型，生成质量下降但系统可用；质量退化 → eval 指标连续 3 天下降触发回滚。面试官追问「如果文档量增加到 500 万份」→ 向量库换分布式架构，embedding 成本上升 10 倍但仍在预算内（换更便宜的 embedding 模型），rerank 只处理 top-10 控制延迟。

失败案例：引用漂移导致用户投诉

下面是一个教学用失败案例，演示面试中如何组织「我遇到过的问题 + 根因 + 修复 + 预防」四段式回答（虚构场景，非真实事件）。

• 现象：RAG 系统上线两周后，用户投诉率上升，主要投诉是「答案里没有出处」和「引用的文档打开后找不到对应内容」。
• 根因排查：第一步查 LLM 输出，发现模型确实在生成引用，但引用 ID 是模型自己编的（hallucinated citation）——prompt 要求标注 [doc_id, chunk_id]，但模型在上下文不足时会编造看起来合理的 ID。第二步查检索层，发现当召回的 chunk 质量差（与问题相关度低）时，模型更倾向于编造引用而不是拒答。根因是：prompt 没有强制「如果引用不存在则不输出」，且没有后处理验证。
• 修复：三件事同时做——① prompt 加硬约束：「如果无法从上下文中找到支持某个论断的具体 chunk，不要为该论断生成引用，改为输出『此部分无可靠来源』」；② 后处理验证：生成后逐个检查引用 ID 是否在检索结果中存在，不存在的引用删除并标记该论断为「未验证」；③ 拒答阈值：当 top-4 chunk 的最高相关度分数低于阈值（0.6）时，直接走拒答路径，不进入生成。
• 预防：在 golden set 中加入「上下文不足以回答」的样本（占比 15%），回归测试中专门测 citation accuracy 和拒答率（abstention rate）。上线后监控「引用验证失败率」（后处理中删除的引用占总引用比例），超过 5% 触发告警。
• 面试表达：这类问题的标准回答结构是「现象 → 根因（分层排查，不是只查模型）→ 修复（多层同时做，不是只改 prompt）→ 预防（eval 指标 + 监控告警）」。面试官考的不是你遇到没有这个问题，而是你有没有分层排查的习惯和多层防御的意识。

7 天练习计划

按每天一个模块推进，第 7 天做完整 mock。每天 2-3 小时，总计约 18 小时。如果同时准备 RAG / Agent / Eval 三块，三篇的 7 天计划可以按 2:2:1 的时间比例合并成 14 天的完整 AI Engineer 冲刺路线，合并方法见 AI Agent 面试题。

• Day 1 — 需求澄清：准备三组不同场景的澄清问题清单（内部知识库、外部客服、合规问答），每组 8-10 个问题。计时 5 分钟，对镜子或录音输出澄清问题，检查是否覆盖了数据规模、权限、引用、延迟、成本、成功指标六个维度。
• Day 2 — 数据层：选 200 份公开文档（GitHub README、W3C 文档均可），手工做清洗和 chunking。比较三种 chunking 策略（固定 512、按标题层级、滑动窗口 overlap 20%）对同一组 20 个测试 query 的召回差异。写出你的选择理由，200 字以内。
• Day 3 — 检索与 Rerank：在本地数据集上实现 BM25 + 向量双路召回（用开源 embedding 模型和 FAISS 即可），比较纯向量、纯 BM25、hybrid + RRF、hybrid + RRF + rerank 四种配置的 recall@5。画出四条曲线，找出 rerank 的提升幅度。
• Day 4 — ACL 与 Citation：为 Day 3 的系统加 metadata filter（模拟部门权限），设计引用后处理逻辑。写一段 prompt，要求模型标注引用并在上下文不足时拒答。用 10 个测试 query 验证引用是否真实存在。
• Day 5 — Freshness 与成本：设计一个增量索引方案（文档变更 → 只重新 embedding 变更的 chunk），估算全量重建和增量重建的成本差异。为 Day 3 的系统算出每层的延迟贡献（用计时器实测），写出成本优化方案（至少三个手段）。
• Day 6 — Eval 与故障：用 30 条自建 golden set 跑 LLM-as-judge（用任意 LLM API），记录 faithfulness 和 citation accuracy。设计三个降级路径（embedding 故障、向量库故障、LLM 限流），写出每个路径的触发条件、降级动作和恢复条件。
• Day 7 — 完整 Mock：45 分钟完整讲一个 RAG 系统设计题（用「企业产品文档问答系统」作为题目），录音。回听时只检查三件事：① 是否讲清了每层的 trade-off（不是只讲 happy path）；② 是否主动提到了故障降级路径；③ 是否在 5 分钟内完成了需求澄清。不达标的项目第二天重做。

FAQ：RAG System Design 面试高频问题

以下 5 个高频问题覆盖 RAG System Design 面试中最容易失分的点。答案给出的是面试中可复用的评分框架，不是标准答案；每个问题都可以继续展开成 3-5 分钟的追问。