RAG 是 AI 应用开发里最容易被低估的模块。
很多人以为 RAG 就是“文档切块 -> 转向量 -> 存向量库 -> 检索 -> 拼 Prompt”。Demo 阶段这么理解没问题，但一到真实业务，问题马上变复杂：文档解析不干净、Chunk 切碎了语义、Embedding 模型选错、召回结果不准、权限过滤漏了、知识库更新后旧版本还在、模型拿到证据却没有正确回答。
所以，RAG 面试真正考的不是“你会不会接向量数据库”，而是：你能不能把一个检索增强生成系统拆成可定位、可优化、可评测、可更新的工程链路。
这份 RAG 面试题根据 AI 专栏现有文章整理。建议你用下面这条主线复习：
- 先理解 RAG 解决什么问题，以及它和微调、长上下文、传统搜索的区别。
- 再理解 Embedding、相似度、ANN 索引和向量数据库选型。
- 接着理解文档处理、Chunk 策略、元数据和权限过滤。
- 然后掌握 Hybrid Search、Query Rewrite、Rerank、上下文压缩等优化手段。
- 最后补上 GraphRAG、知识库更新和评测闭环。
面试官真正想考什么
RAG 题通常会从概念开始，但很快会追到排查和优化。你可以按下面几个层次准备。
| 考察方向 | 面试官想确认什么 | 常见扣分点 |
| --- | --- | --- |
| RAG 基础 | 你是否知道 RAG 解决知识更新、私有数据和可溯源问题 | 只说“降低幻觉”，讲不出链路 |
| Embedding 和索引 | 你是否理解向量检索的近似性和成本取舍 | 把向量数据库当普通数据库 |
| 文档处理 | 你是否知道召回质量从文档进入系统前就开始决定 | 只调 TopK，不看解析和 Chunk |
| 检索优化 | 你是否能定位召回不准、排序不准、上下文噪声问题 | 遇到效果差只改 Prompt |
| GraphRAG | 你是否理解多跳关系和全局问题为什么难 | 认为 GraphRAG 一定比向量 RAG 好 |
| 更新与评测 | 你是否能维护长期运行的知识库 | 没有版本、灰度、回滚和评测意识 |
回答 RAG 题时，尽量把问题拆成“数据进入索引前、检索召回时、上下文注入时、模型生成后、线上持续更新”几个阶段。这样面试官会更容易感受到你的系统化思维。
RAG 基础
参考文章：《万字详解 RAG 基础概念》
这一组题是 RAG 面试的入口。重点要讲清楚 RAG 的价值和边界：它不是让模型突然变聪明，而是给模型提供外部证据，让回答更可引用、可审计、可更新。
建议掌握这些关键点：
- RAG 主要解决大模型知识过时、缺少私有数据、回答不可溯源等问题。
- 传统搜索返回文档列表，RAG 返回基于证据综合后的答案。
- RAG 和微调不是替代关系。知识频繁变化、需要引用来源时优先 RAG；要固定风格、格式或能力倾向时再考虑微调。
- 长上下文适合少量材料深度分析，但企业级知识库仍然需要检索来控制成本、权限和噪声。
- RAG 不能彻底消灭幻觉。检索错、证据不足、上下文噪声、模型不遵循证据，都会导致错误答案。
高频面试题：
- 什么是 RAG？为什么需要 RAG？
- RAG 和传统搜索引擎有什么区别？
- RAG 和微调怎么选？什么时候用 RAG，什么时候微调，什么时候两者结合？
- RAG 系统中 Embedding 模型怎么选？为什么？
- 余弦相似度、内积和欧氏距离有什么区别？
- RAG 的幻觉问题怎么解决？RAG 一定不会产生幻觉吗？
- 什么是 Lost in the Middle 问题？怎么应对？
- 长上下文窗口是否会取代 RAG？
- RAG 系统的评估指标有哪些？
- RAG 的优势和局限性是什么？
- 什么场景适合用 RAG？什么场景不适合？
一个更完整的回答方式是：RAG 的价值在于把模型回答绑定到可检索证据上，但它的上限由检索质量决定。如果正确证据没有被召回，后面的 Prompt 写得再漂亮也救不回来。
向量数据库与索引
这一组题会考到一些底层概念，但面试官通常不是让你推公式，而是看你是否理解向量检索的取舍：速度、召回率、内存、构建成本、过滤能力和运维复杂度。
建议掌握这些关键点：
- Embedding 把文本映射到语义向量空间，相似文本在空间中距离更近。
- ANN 近似检索牺牲一部分精确性，换取更高查询性能，这是大规模向量检索的常见取舍。
- Flat 适合小规模和评测基准，HNSW 查询快但内存成本高，IVFFLAT 更节省资源但依赖聚类和参数调优。
- PostgreSQL + pgvector 适合中小规模和已有 PostgreSQL 技术栈，专业向量数据库更适合大规模、高并发、复杂检索场景。
- 向量检索经常要和元数据过滤、权限过滤、关键词检索结合，不能只看相似度。
高频面试题：
- 什么是 Embedding？为什么需要把文本转成向量？
- RAG 场景为什么需要向量数据库？
- ANN 算法为什么可以接受不是 100% 精确的结果？
- 有哪些向量索引算法？各自优缺点是什么？
- Flat、HNSW、IVFFLAT、IVF-PQ 分别适合什么场景？
- HNSW 和 IVFFLAT 有什么区别？
- HNSW 的
ef_search参数怎么调？调大和调小分别会怎样？ - 向量数据库和传统数据库最核心的区别是什么？
- 如果向量数据从 100 万增长到 1 亿，架构上需要做什么调整？
- 为什么选择 PostgreSQL + pgvector？什么时候应该换专业向量数据库？
如果被问“向量数据库怎么选”，不要只报产品名。更好的回答是先问规模、延迟、过滤条件、运维能力、云服务偏好、数据安全要求，再给方案。技术选型不是榜单投票，而是约束匹配。
文档处理与 Chunk 策略
参考文章：《RAG 文档处理与切分策略：从解析、清洗、Chunking 到多模态内容处理》
很多 RAG 问题的根源不在模型，也不在向量库，而在文档处理。垃圾内容进索引，后面检索出来的也只是高相似度垃圾。
建议掌握这些关键点：
- 文档处理管线通常包括解析、清洗、结构化、切分、元数据补全、Embedding、入库和校验。
- Chunk 切分不能只按固定长度切。标题层级、段落语义、表格、代码块、FAQ、章节边界都要考虑。
- Chunk 太大，召回不精准且上下文成本高；Chunk 太小，语义不完整，容易丢失上下文。
- Overlap 可以缓解切分边界问题，但过大容易引入重复内容和检索噪声。
- 元数据很关键，包括来源、标题、页码、更新时间、权限范围、文档版本和业务标签。
高频面试题：
- RAG 文档处理管线通常包含哪些步骤？
- 文档解析、清洗、结构化分别解决什么问题？
- Chunk 切分为什么不能只按固定长度切？
- Chunk 大小、Overlap、语义边界应该怎么取舍？
- 表格、代码块、图片、多模态内容进入 RAG 前怎么处理？
- 文档处理阶段如何保留标题层级、页码、来源和权限元数据？
- Chunk 质量差会带来哪些召回和生成问题？
- 如何从零搭建一套企业级文档处理管线？
面试里如果问“Chunk 怎么切”，建议不要直接说固定 500 字或 1000 字。更稳的回答是：先根据文档类型和问答粒度确定基本范围；优先按标题、段落、语义边界切；对表格、代码、FAQ 做特殊处理；保留父级标题和元数据；最后通过检索评测验证 Chunk 策略，而不是凭感觉调参数。
RAG 检索优化
参考文章：《万字详解 RAG 优化：从召回、重排到上下文工程的系统调优》
这一组题最能体现实战经验。RAG 效果差时，不要一上来就改 Prompt。先判断问题发生在哪一段：没有召回正确证据、召回了但排得太后、放进上下文的内容太吵、模型没有正确使用证据，还是评测样本不稳定。
建议掌握这些关键点：
- Hybrid Search 结合关键词检索和向量检索，适合专业术语、编号、实体名、语义表达混杂的场景。
- Query Rewrite 解决用户问题表达不规范、口语化、多意图、缩写和上下文省略问题。
- Rerank 负责在候选结果里重新排序，解决向量相似度不等于答案相关性的问题。
- 上下文压缩可以降低噪声和成本，但压缩错误会丢失关键证据。
- RAG 优化必须基于失败样本集，不能只拿几条主观案例反复调。
高频面试题：
- RAG 召回率低应该怎么排查？
- Chunk 策略、Metadata、Hybrid Search、Query Rewrite、Rerank 分别解决什么问题？
- Hybrid Search 是什么？BM25 和向量检索怎么融合？
- Query Rewrite、HyDE、Self-Query 分别适合什么场景？
- Rerank 解决什么问题？为什么不能只依赖向量相似度排序？
- 上下文压缩有什么价值？什么时候会伤害答案质量？
- RAG 优化为什么必须先建立失败样本集？
- 线上 RAG 出现“答非所问”，应该按什么路径定位？
推荐的排查顺序是：先看正确文档是否进入候选池，再看排序位置是否靠前，再看上下文是否被截断或污染，最后看模型是否忠实使用证据。这样能避免把检索问题误判成 Prompt 问题。
GraphRAG
参考文章：《万字详解 GraphRAG：为什么只靠向量检索撑不起复杂知识问答》
GraphRAG 题通常出现在更深入的面试里。它不是标准 RAG 的银弹，而是用图结构补足向量检索在实体关系、多跳推理和全局性问题上的短板。
建议掌握这些关键点：
- 标准向量 RAG 擅长局部相似内容召回，但不擅长跨文档关系、多跳推理和全局总结。
- GraphRAG 会抽取实体和关系，构建知识图谱，再通过局部检索、全局检索或社区摘要回答复杂问题。
- 社区摘要可以帮助回答全局问题，但构建和更新成本很高，也可能引入摘要偏差。
- GraphRAG 的权限过滤比文档级过滤更复杂，因为节点、边、邻居和摘要都可能带来信息泄露。
- 成熟系统往往不是纯 GraphRAG，而是根据问题类型在关键词检索、向量检索、多向量、图检索之间动态路由。
高频面试题：
- GraphRAG 解决什么问题？和标准向量 RAG 有什么区别？
- 为什么说 Chunk 是信息孤岛？
- 向量相似度为什么不擅长多跳推理？
- GraphRAG 中实体、关系、社区发现分别是什么？
- 全局检索和局部检索有什么区别？
- GraphRAG 的社区摘要有什么价值？它的成本在哪里？
- GraphRAG 如何做权限过滤？
- 什么场景适合 GraphRAG？什么场景不适合？
- 成熟系统为什么通常不是纯 GraphRAG，而是混合路由架构？
如果被问“要不要上 GraphRAG”，不要默认回答要。更稳的判断是：如果业务问题大量涉及跨文档关系、组织网络、实体关联、多跳推理和全局总结，可以评估 GraphRAG；如果只是 FAQ、产品文档、政策查询，标准 RAG 加检索优化通常更划算。
知识库更新与评测
参考文章：《RAG 知识库文档如何更新：增量更新、版本控制、去重与全量重建》、《AI 应用评测体系：从 Golden Set 构建到线上灰度闭环》
RAG 上生产后，最容易被忽视的是“长期维护”。文档会更新，Embedding 模型会升级，Chunk 策略会调整，权限会变化，业务问题分布也会变。没有更新和评测机制，RAG 很快就会从“知识库问答”变成“旧知识随机复读”。
建议掌握这些关键点：
- 知识库更新要处理新增、修改、删除、版本、去重、权限、灰度和回滚。
- Embedding 模型升级通常意味着向量空间变化，旧向量和新向量混用会带来检索质量问题。
- Chunk 策略变更可能影响所有历史切片，通常需要全量重建。
- RAG 评测要分检索指标和生成指标。检索差和生成差，优化方向完全不同。
- 线上失败样本要回流到评测集，形成持续改进闭环。
高频面试题：
- RAG 知识库为什么不能只新增不删除？
- 增量更新和全量重建怎么选？
- Embedding 模型升级后，为什么通常需要重建索引？
- Chunk 策略变更会影响哪些历史数据？
- 如何避免同一文档多个版本同时被召回？
- 知识库更新如何做灰度、回滚和审计？
- RAG 评测为什么要分检索质量和生成质量？
- MRR、NDCG、Recall@K、Context Precision、Faithfulness 分别衡量什么？
回答更新题时，可以用“数据版本 + 索引版本 + 灰度发布 + 指标监控 + 快速回滚”这条线。这样比只说“定时同步文档”更像生产系统。
排查框架
RAG 效果差，可以按下面路径排查：
- 问题理解：用户问题是否口语化、缩写、多意图、需要多跳推理。
- 文档处理：原始文档是否解析正确，Chunk 是否保留语义和元数据。
- 召回阶段：正确证据是否进入候选池，召回池是否足够大。
- 排序阶段：正确证据是否排在前面，是否需要 Rerank。
- 上下文阶段：证据是否被截断、重复、污染，是否存在 Lost in the Middle。
- 生成阶段：模型是否忠实基于证据回答，是否需要引用和拒答策略。
- 评测阶段：是否有稳定样本集，是否能复现问题。
这个框架非常适合面试，因为它能把 RAG 从“一个链路”拆成“多个可诊断模块”。
常见扣分点
- 把 RAG 简化成向量数据库接入。
- 只关注 TopK，不关注文档解析、Chunk、元数据和权限。
- 效果差时只改 Prompt，不看检索和排序。
- 认为向量相似度高就等于答案相关。
- 认为 GraphRAG 一定优于标准 RAG，不考虑成本和适用场景。
- 没有知识库版本管理、灰度、回滚和评测闭环。
复习建议
建议按“基础概念 -> 向量索引 -> 文档处理 -> 检索优化 -> GraphRAG -> 更新与评测”的顺序复习。
复习时要始终记住一句话：RAG 的核心能力不是生成，而是把正确证据稳定、低成本、可治理地送到模型面前。 如果你能围绕这句话展开，RAG 面试基本不会跑偏。