面试官问我RAG是什么，我差点只答了「向量库加大模型」

本文是「RAG 面试通关」系列的第 1 篇。 下一篇预告：第 2 篇《RAG 效果差，很多时候不是模型不行，是文档切错了》

上周帮一个学员模拟面试，我问他一个特别基础的问题：

「你说你做过 RAG，那你先讲讲，RAG 是什么？」

他很快回答：

「RAG 就是向量数据库加大模型。先把文档转成向量存进去，用户提问的时候再检索出来，让大模型回答。」

这个回答错吗？

不算错。

但如果面试只答到这一步，基本就停在了 Demo 层。

因为面试官真正想听的，不是你会不会把 LangChain、向量库、大模型串起来，而是你到底有没有理解：

RAG 为什么存在？ 它解决了什么问题？ 一个完整的 RAG 系统有哪些链路？ 上线之后为什么经常效果不稳定？ 什么时候该用 RAG，什么时候不该用 RAG？

很多人面试 AI 应用岗位，最容易栽在这里。

简历上写着「熟悉 RAG」，结果一问，只会说「切分、Embedding、向量检索、Prompt」。

今天这篇，作为 RAG 面经系列第 1 篇，我先把 RAG 面试开场最常见的 10 个问题一次性讲清楚。

如果你是想进互联网的学生，或者是想从传统开发转 AI Agent 开发的程序员，这篇建议你收藏。

因为 RAG 几乎是大模型应用面试绕不开的第一关。

01 什么是 RAG？

RAG 的全称是 Retrieval-Augmented Generation，中文一般叫检索增强生成。

你可以先用一句人话理解：

RAG 就是让大模型在回答问题之前，先去外部知识库查资料，再基于查到的资料生成答案。

这句话里有三个关键词。

第一，检索。

系统不是直接让模型拍脑袋回答，而是先从文档、数据库、网页、知识库里找相关内容。

第二，增强。

检索出来的内容会作为上下文补充给大模型，相当于给模型一份参考资料。

第三，生成。

大模型再基于用户问题和参考资料，组织成自然语言答案。

新手回答通常是：

「RAG 就是先检索，再生成。」

高手回答会多一层：

「RAG 是一种把外部知识引入大模型推理过程的应用架构。它不直接修改模型参数，而是在推理时通过检索相关知识，增强模型回答的准确性、实时性和可追溯性。」

这两种回答的区别很大。

新手讲的是流程。

高手讲的是本质。

RAG 的本质不是「向量库加大模型」，而是「外部知识管理 + 检索系统 + 生成模型」的一整套协同机制。

如果面试官继续问：「那为什么不直接让大模型回答？」

你就进入第二个问题了。

02 RAG 解决了大模型的哪些问题？

大模型很强，但它不是万能的。

在真实业务里，直接用大模型回答问题，通常会遇到 4 类问题。

第一，知识不够新。

模型训练完成后，参数里的知识基本就固定了。比如公司上周刚更新的制度、昨天发布的产品文档、今天新增的接口说明，模型本身不可能天然知道。

第二，私有知识不知道。

企业内部文档、项目代码规范、客户合同、售后手册、知识库文章，这些内容一般不会出现在模型训练数据里。

第三，容易编。

如果模型不知道答案，但又被要求回答，它可能生成一个看起来很像真的答案。这就是我们常说的幻觉问题。

第四，难追溯。

模型直接回答时，你很难知道它的依据来自哪里。企业场景里，这一点很致命。因为很多回答不是「看起来对」就行，还要能追溯来源。

所以 RAG 解决的核心问题可以概括成四个词：

新知识、私有知识、降低幻觉、来源可追溯。

面试时可以这样回答：

「RAG 主要解决大模型知识更新慢、缺少企业私有知识、容易产生幻觉、答案缺乏来源依据的问题。它通过外部知识检索，把相关资料动态注入上下文，让模型基于资料回答。」

注意，这里不要说 RAG 能彻底消除幻觉。

这是技术性错误。

更准确的说法是：RAG 可以降低幻觉概率，但不能完全消除幻觉。

因为检索可能错，资料可能冲突，Prompt 可能写得不好，模型也可能没有严格遵循上下文。

03 为什么有了大模型还需要 RAG？

很多面试官会追问这个问题。

「现在大模型上下文越来越长，能力越来越强，为什么还要 RAG？」

新手容易回答：

「因为大模型不知道业务知识。」

这只答对了一部分。

更完整的回答应该从三个角度说。

第一，成本角度。

如果每次都把一整本文档、整个知识库、全部历史记录塞进上下文，成本会非常高，延迟也会变长。

RAG 的价值是先筛选，只把最相关的内容交给模型。

第二，准确性角度。

长上下文不等于一定能用好上下文。资料越多，噪音也越多。模型可能忽略关键段落，也可能被无关信息干扰。

RAG 做的是信息过滤，把候选范围缩小。

第三，工程治理角度。

企业知识不是一次性写死的，它会更新、删除、授权、分版本、做审计。

RAG 可以把知识管理和模型能力解耦。文档变了，更新知识库即可，不一定要重新训练模型。

所以高手回答可以是：

「大模型解决的是通用语言理解和生成能力，RAG 解决的是业务知识接入和可控回答问题。即使模型上下文变长，RAG 仍然有价值，因为它能降低成本、减少噪音、支持知识更新、权限控制和来源追溯。」

记住一句话：

RAG 不是让大模型变聪明，而是让大模型记性变好，而且这份记忆可以更新、可以管理、可以追溯。

04 RAG 和 Fine-tuning 的区别是什么？

这是面试高频题。

很多人会把 RAG 和微调对立起来，好像只能二选一。

其实不是。

RAG 和微调不是替代关系，而是互补关系。

先讲区别。

RAG 是在推理时引入外部知识。

Fine-tuning 是通过训练改变模型参数。

RAG 更适合解决「知识内容」问题。

Fine-tuning 更适合解决「行为模式」问题。

举个例子。

如果你希望模型知道公司最新报销制度，适合用 RAG。因为制度经常变化，你把制度文档放进知识库，更新起来更方便。

如果你希望模型稳定按照某种客服话术回答，或者学会某个垂直领域的表达风格，这更适合微调。因为你想改变的是模型的输出习惯和任务能力。

可以做一个简单对比。

面试里最好的回答不是背表格，而是能说清楚选择标准。

如果问题是「模型不知道某些资料」，优先考虑 RAG。

如果问题是「模型会，但总是不按你想要的方式做」，可以考虑微调。

如果企业场景复杂，二者也可以结合。

比如用 RAG 接入最新知识，用微调让模型更符合行业问答风格。

05 一个完整的 RAG 系统包含哪些模块？

如果你只说「文档切分、Embedding、向量库、LLM」，面试官会觉得你做过 Demo，但不一定做过真实项目。

一个完整的 RAG 系统，至少可以拆成 9 个模块。

第一，数据接入。

文档可能来自 PDF、Word、Markdown、网页、数据库、工单系统、代码仓库。不同来源的解析方式不一样。

第二，文档解析。

把原始文件解析成可处理的文本，同时尽量保留标题、表格、段落、页码、链接等结构信息。

第三，文档切分。

把长文档切成 Chunk。切太大，检索不精确；切太小，语义不完整。后面这个系列会专门讲。

第四，向量化。

用 Embedding 模型把文本转成向量，方便做语义相似度检索。

第五，索引存储。

把向量、原文、元数据一起存起来。元数据包括文档 ID、标题、路径、权限、时间、版本等。

第六，召回检索。

根据用户问题，从知识库中召回相关内容。这里可以是向量召回，也可以是关键词召回，还可以是混合召回。

第七，重排。

召回只是粗筛，Rerank 可以进一步判断哪些内容和问题最相关。

第八，上下文组装和 Prompt。

把检索结果按一定格式拼进 Prompt，并要求模型基于资料回答，必要时给出引用来源。

第九，生成、评估和监控。

模型生成答案之后，还要看答案是否准确、是否引用来源、是否命中权限、是否有风险，并持续监控效果。

所以面试时可以这样答：

「完整 RAG 系统不只是向量库和大模型。离线侧包括数据接入、解析、切分、Embedding、索引存储。在线侧包括 Query 处理、召回、Rerank、上下文组装、Prompt、LLM 生成、引用返回、日志评估和监控。」

这就是从 Demo 思维进入工程思维。

06 RAG 的基本流程是什么？

RAG 的基本流程，可以分成两个阶段：建库阶段和问答阶段。

建库阶段做的是把资料变成可检索的知识。

流程大概是：

文档上传 → 文档解析 → 清洗和结构化 → 文档切分 → Chunk 向量化→ 写入向量数据库→ 保存原文和元数据

问答阶段做的是根据用户问题找到资料，再生成答案。

流程大概是：

用户提问 → Query 预处理 → Query 向量化→ 检索相关 Chunk→ 可选的关键词召回和混合召回 → Rerank 重排 → 选择最相关内容 → 组装 Prompt→ 调用大模型 → 返回答案和引用来源

这里有一个面试加分点。

你要主动区分「离线链路」和「在线链路」。

离线链路主要影响知识质量和可检索性。

在线链路主要影响回答准确性、延迟和用户体验。

如果面试官问你「RAG 效果不好怎么排查」，这个区分非常关键。

因为如果离线切分错了，在线 Prompt 写得再好也很难救。

如果召回没找到正确资料，模型就只能基于错误上下文回答。

如果召回找对了但模型答错了，问题可能在 Prompt、上下文冲突、模型能力或拒答策略。

07 文档从上传到可检索经历了哪些步骤？

这个问题表面问文档处理，实际是在考你有没有做过真实知识库。

一个文档从上传到可检索，至少经历这些步骤。

第一，文件接入。

系统接收文件，并记录文件名、上传人、所属空间、权限、版本、时间等信息。

第二，格式解析。

PDF、Word、HTML、Markdown、Excel 的处理方式都不同。尤其是 PDF，可能存在扫描件、分栏、表格、页眉页脚等问题。

第三，文本清洗。

去掉无意义内容，比如重复页眉、页脚、目录噪音、乱码、空白字符等。但不能过度清洗，避免把有用结构删掉。

第四，结构保留。

保留标题层级、段落关系、表格说明、页码位置。这些结构信息会影响后续检索和答案引用。

第五，Chunk 切分。

根据文档类型选择切分策略。常见方式包括固定长度切分、按标题切分、按语义切分、递归切分等。

第六，生成 Embedding。

把每个 Chunk 转成向量。注意，Embedding 模型一旦更换，历史向量通常需要重新生成，否则向量空间不一致。

第七，写入索引。

把向量写入向量数据库，把原文、文档 ID、标题、权限、来源、版本等元数据一并保存。

第八，质量校验。

检查是否解析成功、是否有空 Chunk、是否重复、是否缺少标题、是否向量写入失败。

很多新手忽略最后一步。

但真实项目里，文档处理失败非常常见。

如果没有质量校验，用户问问题时才发现知识库根本没建好，排查会很痛苦。

08 用户输入一个问题后，系统内部发生了什么？

这个问题很适合用来判断候选人有没有完整链路意识。

用户看到的只是一个输入框和一个答案。

但系统内部至少发生了 8 件事。

第一，接收问题并做基础处理。

比如去掉无意义空格、识别语言、判断是否为空问题、是否包含敏感内容。

第二，做 Query 理解。

有些问题很短，比如「报销怎么弄」。系统可能需要结合上下文，把它改写成更明确的问题，比如「公司差旅报销流程是什么」。

第三，做权限过滤。

用户只能检索自己有权限看的知识。企业级 RAG 里，这一步不能省。

第四，做召回。

用向量检索找语义相关内容，用关键词检索补充精确匹配内容。很多生产系统会采用混合召回。

第五，做重排。

把召回结果进一步排序，选出和问题最相关的内容。

第六，做上下文组装。

把相关 Chunk、来源信息、回答要求、拒答规则一起放进 Prompt。

第七，调用大模型生成答案。

模型根据问题和上下文生成回答。如果资料不足，理想情况是回答不知道，而不是编造。

第八，返回答案并记录日志。

日志里通常要记录用户问题、召回内容、模型输入输出、耗时、Token 成本、引用来源、用户反馈等。

这套链路说出来，面试官就能感受到你不是只跑过一个 Notebook。

你理解的是一个可上线、可排查、可优化的系统。

09 RAG 的离线链路和在线链路分别是什么？

这一题建议你一定背下来。

因为它是 RAG 面试里最容易体现专业度的问题之一。

离线链路，就是用户提问之前已经完成的部分。

主要包括：

1. 数据采集
2. 文档解析
3. 文本清洗
4. 文档切分
5. Embedding 生成
6. 向量和元数据入库
7. 索引构建
8. 文档更新和删除
9. 质量校验

在线链路，就是用户发起问题之后实时执行的部分。

主要包括：

1. Query 预处理
2. Query 改写或扩展
3. 权限判断
4. 向量召回
5. 关键词召回
6. 混合召回结果合并
7. Rerank 重排
8. 上下文压缩和组装
9. Prompt 构造
10. LLM 生成
11. 引用来源返回
12. 日志、反馈和监控

离线链路看的是知识库质量。

在线链路看的是问答质量和响应效率。

如果候选人能把这两个链路说清楚，面试官通常会继续追问一些工程问题，比如：

文档更新后怎么处理历史向量？Chunk 删除后索引怎么同步？ 权限过滤是在召回前做还是召回后做？ TopK 取多少合适？Rerank 会不会影响延迟？

这些问题后面系列都会讲。

10 RAG 适合哪些场景，不适合哪些场景？

这个问题很重要。

因为真正懂技术的人，不会说一个技术适合所有场景。

RAG 适合什么？

第一，企业知识库问答。

比如制度查询、产品文档问答、客服知识库、内部培训资料查询。

第二，内容经常更新的场景。

比如政策法规、产品手册、接口文档、运营活动规则。

第三，需要引用来源的场景。

比如医疗、法律、金融、企业合规。注意，这些高风险场景还需要人工审核和严格风控，不能只靠 RAG。

第四，私有数据问答。

比如公司内部文档、项目资料、客户资料。前提是权限控制必须做好。

第五，多文档综合问答。

比如从多个文档中找信息，再汇总成答案。

那 RAG 不适合什么？

第一，问题不依赖外部知识，而是依赖模型通用推理能力。

比如写一段通用文案、做简单翻译、总结一段用户直接提供的文本，不一定需要 RAG。

第二，知识高度结构化，普通数据库查询更准确。

比如订单金额、库存数量、用户余额。这类问题应该优先查数据库，而不是把数据切成 Chunk 放进向量库。

第三，要求强一致、强事务、强精确计算的场景。

比如财务结算、风控决策、实时库存扣减。大模型和 RAG 都不应该替代确定性系统。

第四，知识规模很小，直接放进 Prompt 就够。

如果资料只有几段文本，没必要引入复杂 RAG 架构。

第五，检索结果本身无法覆盖答案。

如果知识库里根本没有正确资料，RAG 也不能凭空变出正确答案。

面试时可以这样总结：

「RAG 适合知识更新频繁、需要接入私有文档、需要答案可追溯的问答场景。不适合强结构化查询、强一致计算、知识库缺失、以及不依赖外部知识的普通生成任务。」

这句话很关键。

它能证明你知道 RAG 的边界。

面试里怎么把这 10 个问题串成一个高级回答？

如果面试官开场只问一句「你讲讲 RAG」，你不要一上来就讲技术名词。

可以按这个顺序回答：

第一句话，先定义。

「RAG 是检索增强生成，它通过在推理时检索外部知识，把相关内容作为上下文提供给大模型，让模型基于资料生成答案。」

第二句话，讲价值。

「它主要解决大模型知识更新慢、不了解私有知识、容易幻觉、缺乏来源追溯的问题。」

第三句话，讲链路。

「完整 RAG 分成离线建库和在线问答。离线侧做文档解析、切分、Embedding 和索引入库；在线侧做 Query 处理、召回、Rerank、上下文组装和生成。」

第四句话，讲边界。

「RAG 更适合知识库问答、企业文档问答、内容频繁更新和需要引用来源的场景；但不适合强结构化查询、强一致计算，以及知识库本身没有答案的场景。」

第五句话，讲和微调的关系。

「RAG 和微调不是替代关系。RAG 解决知识接入问题，微调更适合解决模型行为和输出风格问题，真实项目里可以结合使用。」

你看，这样回答就不是「向量库加大模型」了。

它包含了定义、价值、架构、边界、技术选型。

面试官自然会觉得你不是只会调包。

项目落地时，最容易被忽略的 5 个点

最后补一段真实项目里很重要，但很多面试者不说的内容。

第一，RAG 的效果上限很大程度取决于知识库质量。

文档解析错、Chunk 切错、标题丢失、表格变形，后面再怎么调 Prompt 都很难救。

第二，向量召回不是万能的。

向量检索擅长语义相似，但对编号、专有名词、精确关键词、代码符号不一定稳定。所以生产系统经常会用混合召回。

第三，TopK 不是越大越好。

TopK 太小可能漏召回，TopK 太大会引入噪音，还会增加 Token 成本。通常要结合业务测试集调参。

第四，权限控制不能事后补。

企业知识库里，不同用户能看的文档不一样。如果权限过滤没做好，RAG 可能把不该看的内容检索出来，这是严重问题。

第五，必须做评估和日志。

没有评估集，就不知道改动后效果有没有变好。没有日志，就很难定位一次错误回答到底是解析问题、召回问题、排序问题，还是生成问题。

这 5 个点，是 Demo 和生产系统的分水岭。

很多面试官不是想听你把概念背一遍，而是想知道你有没有踩过这些坑，或者至少知道这些坑在哪里。

面试官可能追问的 5 个问题

你准备 RAG 面试时，建议继续准备下面 5 个追问。

1. 如果 RAG 检索不到正确答案，你怎么排查？

核心思路：先看知识库有没有答案，再看文档解析和切分，再看 Embedding 和召回策略，最后看 TopK、Rerank 和 Query 改写。

1. 如果检索到了正确资料，但模型回答错了，怎么办？

核心思路：检查 Prompt 是否要求基于上下文回答，检查上下文是否有冲突，检查模型是否支持该任务，必要时增加引用、拒答和答案校验。

1. 为什么很多 RAG 系统需要混合召回？

核心思路：向量召回适合语义相似，关键词召回适合精确匹配。真实业务里两类问题都有，所以常用 Hybrid Search。

1. RAG 如何处理权限控制？

核心思路：文档和 Chunk 都要带权限元数据。检索时要结合用户身份做过滤，避免越权召回。企业场景里权限通常要前置设计。

1. 长上下文模型出现后，RAG 还重要吗？

核心思路：重要。长上下文能容纳更多内容，但不能替代知识治理、权限控制、成本控制、来源追溯和检索降噪。

最后总结一下

面试回答 RAG，不要只停在「向量库加大模型」。

你至少要讲清楚 5 层：

第一，RAG 是什么。

它是检索增强生成，在推理时引入外部知识。

第二，RAG 解决什么问题。

它解决知识更新、私有知识、幻觉降低和来源追溯问题。

第三，RAG 系统怎么跑。

它分为离线建库和在线问答两条链路。

第四，RAG 和微调怎么选。

RAG 解决知识问题，微调解决行为和风格问题。

第五，RAG 的边界在哪里。

它不是万能方案，不适合强结构化查询、强一致计算和知识缺失场景。

如果你能把这 5 层说清楚，RAG 面试第一关基本就稳了。

下一篇我们讲「文档切分」。

这是 RAG 里最容易被低估的一环。

很多系统回答不准，不是模型不行，也不是向量库不行，而是一开始文档就切错了。

本文是「RAG 面试通关」系列的第 1 篇。下一篇预告：RAG 效果差，很多时候不是模型不行，是文档切错了，记得星标不走丢。

最近我把大家公认最容易翻车的 Agent 开发面试考点 整理成了一份 PDF，我自己面了不少人，也被面了不少次，这些东西说实话，外面那些面经基本看不到。