RAG 是 AI 应用里落地多的方案，几乎每家做知识库、客服、企业助手的公司都会问。面试官通常会顺着链路一路追问：文档怎么切、向量怎么存、为什么检索不到、怎么证明效果变好了。
能把问题定位到具体环节（解析、切块、召回、重排、生成）的候选人，比只会说「加个向量库」的更有说服力。
题库
RAG 的基本流程是什么？和微调相比，它适合解决什么问题？
- 离线入库：解析文档（PDF、网页、表格）→ 清洗 → 切块 → 用 Embedding 模型向量化 → 连同元数据存进向量库。
- 在线问答：用户问题向量化 → 检索相关块 → 重排 → 拼进提示词 → 模型依据资料生成回答并标注来源。
- 适合 RAG：知识经常更新、是私有数据、需要给出处的场景。改知识只需更新知识库，不用重新训练。
- 适合微调：固定输出格式、语气风格、特定任务的行为方式。微调不是往模型里「灌知识」的可靠办法。
- 两者可以结合：微调让模型更会用检索结果，RAG 提供最新知识。
文档切块（chunking）怎么做？块的大小和重叠会怎样影响检索效果？
- 怎么切：优先按文档结构切——标题、段落、条款、问答对，而不是机械地每 500 字切一刀。表格和代码要单独处理，避免被切碎。
- 块太大：混了多个主题，语义被稀释，检索不准，还占上下文。
- 块太小：丢失上下文，检索到了也看不懂，比如只有「同上」两个字。
- 重叠：相邻块保留一小段重叠，避免关键句被切在边界上。
- 常用技巧：每个块带上标题路径、文档名、更新时间等元数据；用小块检索、返回它所在的大块（父子块）。
- 块大小没有通用最优值，要用评测集对比几组参数。
Embedding 是什么？选 Embedding 模型时你会看哪些因素？
- Embedding 把一段文本映射成一个固定长度的向量，语义相近的文本向量距离也近，检索时常用余弦相似度衡量。
- 选型看：
- 中文和你所在领域的效果——公开榜单（如 MTEB）只能参考，要在自己的数据上测召回；
- 向量维度：维度越高存储和计算越贵；
- 最大输入长度是否覆盖你的块大小；
- 价格、速度，以及是否需要私有部署。
- 注意：查询和文档必须用同一个模型编码；更换 Embedding 模型就要把整个知识库重新向量化、重建索引。
向量数据库是怎么在海量向量里做到快速检索的？常见的 ANN 索引有哪些？
- 逐个计算距离（暴力检索）在百万、千万级时太慢，所以用 ANN（近似最近邻）：牺牲少量召回率，换取数量级的速度提升。
- HNSW：多层图结构，从上层粗跳到下层细找。召回高、查询快，但内存占用大，常见默认选择。
- IVF：先把向量聚类分桶，查询时只搜离得近的几个桶。
- PQ 等量化：把向量压缩存储，节省内存，精度有损，常与 IVF 组合。
- 调参：HNSW 的 ef、IVF 的 nprobe 越大召回越高、越慢。
- 选型：数据量不大、已有 PostgreSQL 可用 pgvector；规模大用 Milvus 等专门的向量库；已有搜索集群可用 Elasticsearch / OpenSearch。还要看元数据过滤能力。
只用向量检索有什么不足？混合检索（hybrid search）怎么做？
- 向量检索的短板：擅长语义相似，但对专有名词、产品型号、错误码、人名、精确短语不敏感。问「E1032 报错」，可能召回一堆讲其他错误码的文档。
- BM25 关键词检索正好补足：按词频和稀有度精确匹配，但它不理解同义词和换一种说法的问题。
- 混合检索：两路各自召回一批结果，再合并。常用 RRF（倒数排名融合），只看各路的排名，不用对齐两种分数的尺度；也可以把分数归一化后加权。
- 合并后通常再交给重排模型精排。两路权重按业务场景用评测集调。
Rerank（重排）在 RAG 里起什么作用？为什么不直接用检索时的分数？
- 检索阶段用双塔模型：查询和文档分别编码成向量，文档向量可以提前算好，所以快，但两者没有直接「对照着看」，精度有限。
- 重排阶段用交叉编码器（cross-encoder）：把查询和每个候选文档拼在一起输入模型打分，能捕捉细粒度的相关性，更准，但每对都要实时计算，慢。
- 所以分两段：先宽召回（比如 50 条），再用重排精选前 5 条放进上下文。
- 收益：进入上下文的无关内容少了，回答更准、token 更省。
- 代价：多一次模型调用的延迟和费用。也可以让大模型做重排，效果好但更贵。
用户的问题很口语化或者很模糊，导致检索不到相关内容，你会怎么处理？
- 查询改写：结合对话历史补全指代和省略（「那它多少钱」→「X 产品的价格」），把口语转成更接近文档的表达。
- 扩展与拆分：生成多个改写版本分别检索再合并；复杂问题拆成子问题分别检索。
- HyDE：先让模型写一段假设的答案，用它去检索，因为答案和文档的表述更接近。
- 关键词路径：抽出关键实体走 BM25；用元数据（产品线、时间）缩小范围。
- 兜底：确实检索不到时，如实告诉用户或追问澄清，不要硬编一个答案。
- 定期分析日志里检索失败的查询，补文档或调整策略。
怎么评测一个 RAG 系统？你会看哪些指标？
- 分两段评，才能知道问题出在检索还是生成。
- 检索指标：Recall@k（相关文档有没有被召回到前 k 条）、命中率、MRR（第一个相关结果排第几）、上下文精确度（召回的内容里有多少是有用的）。
- 生成指标：忠实度（回答是否只基于检索到的内容，没有编造）、答案相关性（有没有答到问题上）、正确性（和标准答案比）。
- 测试集：每条含问题、标准答案和应命中的文档，覆盖常见题、难题和「知识库里没有答案」的题。
- 方法：LLM 评分加人工抽检，可借助 RAGAS 等工具；上线后收集点赞、点踩和追问，持续补充测试集。
回答里怎么给出引用来源？知识库的更新和不同用户的访问权限又要怎么处理？
- 引用：每个块带上文档名、页码或段落、链接；拼提示词时给每块编号，要求模型按编号标注引用；程序校验编号确实存在，再渲染成可点击的来源。
- 更新：按文档的内容哈希或版本号做增量更新，只重新处理变化的部分；删除或下线文档时同步删除对应向量；Embedding 模型或切块策略变化时全量重建。
- 时效：块带上发布或更新时间，检索时可以过滤或优先新内容。
- 权限：检索时按用户、部门或租户过滤，没权限的块根本不进上下文。不能把全部内容交给模型再靠提示词让它「别说」。
GraphRAG 是什么？什么场景下它比普通的向量 RAG 更合适？
- 做法：用大模型从文档抽取实体和关系建成知识图谱，再做社区划分，为每个社区生成分层摘要；查询时结合图结构和摘要回答。
- 更合适的场景：
- 多跳关系问题，比如「A 公司的供应商里，哪些也给 B 供货」；
- 跨大量文档的总结类问题，比如「这批访谈里反复出现的问题有哪些」——普通 RAG 只取几个块，很难答好。
- 查询方式：局部查询围绕具体实体展开，全局查询基于社区摘要汇总。
- 代价：建图要对全部文档调用模型，成本高、耗时长，增量维护也麻烦。多数事实型问答，普通 RAG 加混合检索和重排就够了。
答题思路
RAG 题几乎都可以沿着链路来答，先说结论，再定位环节：
- 先结论：「检索不到，我会先判断是查询的问题、切块的问题还是召回策略的问题。」
- 再原理：说明这一环为什么会出问题。「向量检索对型号、编号这种精确词不敏感，所以……」
- 再实践与取舍：给出具体手段和代价。「加 BM25 做混合检索，用 RRF 合并，再重排；多一次调用，延迟增加一两百毫秒，但召回率提升明显，我们用评测集对比过。」
RAG 面试特别看重数据：你怎么知道优化有效？准备一个自己项目里的例子——优化前后召回率或正确率是多少、用了多大的测试集——会让回答扎实很多。
延伸阅读：RAG 面试题总结、RAG 优化：从召回、重排到上下文工程、RAG 文档处理与切分策略、GraphRAG。
模拟面试
5 道题从上面的题库随机抽，逐题作答，每题都会得到打分、点评和要点。回答时尽量说清「问题出在哪一环、怎么验证改进有效」。
🎤 模拟面试每场 5 题，AI 面试官逐题打分点评，总分 = 平均分 × 10
登录后开始模拟面试小结
- RAG 是一条链路：解析、切块、向量化、召回、重排、生成，每一环都可能出问题。
- 混合检索、重排、查询改写是常用的三类优化，各有延迟和成本代价。
- 评测要把检索和生成分开看；引用、更新和权限是上线前必须想清楚的工程问题。
下一课 D4 讲 AI 应用系统设计：网关、限流、流式、缓存、成本、容错、可观测和长任务。