面试题 · RAG
搜索「外部知识库」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请解释检索增强生成（Retrieval-Augmented Generation, RAG）的基本概念、核心架构组成及工作流程，说明其解决的关键问题，并对比分析在哪些应用场景下RAG优于纯参数化记忆的大模型，举例说明其优势与局限性。
RAG将大模型的参数化记忆（训练学到的权重）与非参数化记忆（外部知识库）结合，通过检索实时引入上下文，解决纯LLM的知识固化问题。
三核心组件：
标准流程： 用户Query → 向量化 → 向量检索召回 → 重排序（可选） → 上下文拼接 → LLM生成
学习内容与项目面试，在同一条路上。
| 问题 | 说明 |
|---|---|
| 事实幻觉 | 生成内容有检索文档支撑，可溯源验证 |
| 知识时效性 | 无需重训即可更新知识库 |
| 领域专业知识 | 注入企业私有数据，弥补通用模型短板 |
| 生成可控性 | 通过限定检索范围约束回答边界 |
RAG显著更优的场景：
纯LLM更合适的场景：
| 局限 | 表现 | 缓解思路 |
|---|---|---|
| 检索失效 | 召回文档不相关或遗漏 | 混合检索（BM25+向量）、查询重写、重排序 |
| 上下文爆炸 | 多文档超出窗口限制 | 摘要压缩、分层检索、长上下文模型 |
| 多跳推理弱 | 需跨文档关联时易断链 | 引入知识图谱、迭代检索（Self-RAG） |
| 生成与检索耦合 | 模型过度依赖或忽略检索内容 | 训练时加入"无相关信息"样本、调整prompt权重 |
典型失败案例： 用户问"对比A和B产品的差异"，若检索分别返回A、B的独立介绍而无直接对比文档，模型难以自行归纳差异——这是RAG在综合推理类问题上的天然瓶颈。
建议先掌握大模型基础知识，再学习信息检索与RAG流程，结合开源项目如LangChain动手实践，理解检索与生成的协同机制。
场景切入
假设你的客服机器人要回答用户关于公司最新产品的售后问题，但模型训练数据里没有这款产品。你怎么让机器人既能知道产品细节，又能保证回答准确、不瞎编？
层层追问
大模型直接回答容易产生幻觉，这个你怎么看？……如果给它外挂一个知识库呢，具体怎么结合？……那检索回来的信息怎么跟问题拼在一起，流程上每一步怎么做？
直球架构
请解释RAG的核心架构和工作流程，包括检索器和生成器如何协同。相比纯参数化模型，它解决了哪些关键问题？在什么场景下RAG有绝对优势，举例说明它的优点和局限。
这道题其实在问，当大模型的知识不够用时，我们怎么往外挂知识。[[RAG]]的核心思路很简单：把模型的参数化记忆，就是它训练学到的权重，和非参数化记忆，也就是外部知识库，结合起来。你可以把它理解成，给一个很聪明但可能记错事的助手配一本随时可查的参考书。
具体流程上，标准的三段式：先有一个知识源，比如文档库，要预先[[向量化]]建好索引；然后用户提问时，检索器把问题也向量化，去库里做相似度搜索，召回最相关的Top-K文档；最后生成器把原始问题和这些文档拼在一起，作为上下文让LLM生成答案。中间还可以加[[重排]]步骤，让召回结果更精准。
RAG解决的核心问题，说白了就是三个：一是事实[[幻觉]]，因为回答有检索文档支撑，可以溯源验证；二是知识时效性，不用重新训练，更新知识库就行；三是领域专业知识，把企业私有数据注入进去，补通用模型的短板。
那RAG和纯参数化模型怎么选？我的判断是，高事实准确性、知识更新快、长尾知识密集、需要可解释性的场景，RAG显著更优。比如企业客服处理退款，用户问'我订单超时了但货没到，能不能退'，RAG可以实时检索最新的退款政策文档，然后给出准确答复，还能给出政策原文链接。纯模型可能凭训练数据里的旧规则给出错误判断。反过来，纯模型在通用创意写作、开放式闲聊、常识推理这些场景更合适，因为不需要外部事实约束，知识已经内化在模型里了。但真正落地时，往往RAG和微调一起上，比如用RAG做实时知识检索，同时用微调让模型更懂业务术语和回答风格。
落地时有个前提：检索质量必须高。如果召回文档不相关或遗漏，生成结果肯定差。常见失败场景是，用户问'对比A和B产品的差异'，但检索分别返回A和B的独立介绍，没有对比文档，模型很难自己归纳差异，这是RAG在综合推理类问题上的天然瓶颈。我上线时会特别关注检索的召回率和精确率，用[[混合检索]]，比如[[BM25]]加向量搜索，来提高覆盖率，再配合查询重写、重排来优化。另外，多文档可能超出上下文窗口，这时需要做摘要压缩或分层检索。还有一个坑是模型过度依赖检索内容，或者干脆忽略它，我一般会在训练时加入'无相关信息'的样本，或者调整prompt里检索文档的权重。
说到多跳推理，比如需要跨文档关联信息的问题，RAG很容易断链。我最近在看[[Self-RAG]]，让模型自己判断是否需要检索、检索什么，然后反思生成结果，这样能缓解这个问题，但还远没完美。
所以整体上，我会把RAG看作一个基础能力，不是银弹。它解决的是知识来源问题，但推理能力、上下文管理这些仍然需要模型本身的改进和工程上的精细调优。我更倾向根据业务场景，把RAG和微调、[[Agent]]这些方案组合起来用，而不是指望一个方案包打天下。