面试题 · 模型微调
请详细解释检索增强生成（RAG）的基本原理、系统架构、工作流程以及相比纯生成模型的优势。
RAG（Retrieval-Augmented Generation）将外部知识检索与大模型生成结合，解决纯生成模型的知识截止和幻觉问题。
核心思想：不依赖模型参数记忆知识，而是动态检索相关文档作为上下文，让模型基于检索结果生成回答。
| 模块 |
|---|
按学习路线查看教程、项目和面试题。
| 功能 |
|---|
| 索引模块 | 文档切分 → Embedding编码 → 向量数据库存储 |
| 检索模块 | 查询向量化 → 相似度搜索（Top-K召回） |
| 生成模块 | 检索结果+原始查询 → 拼接Prompt → LLM生成 |
| 对比维度 | 纯生成模型 | RAG |
|---|---|---|
| 知识时效性 | 训练数据截止，无法更新 | 知识库实时更新，无需重训 |
| 幻觉问题 | 容易编造事实 | 基于检索文档生成，可控可溯源 |
| 成本 | 全量微调昂贵 | 只需更新知识库，零训练成本 |
| 可解释性 | 黑盒生成 | 可展示引用来源，便于审计 |
场景切入
假设你在做一个智能客服，用户问“我的订单什么时候到”，你直接让大模型回答，结果它瞎编了一个物流信息。如果换成RAG，你会怎么设计来避免这种问题？
层层追问
大模型生成答案容易胡说八道，你一般怎么缓解？……那如果让模型先去查资料再回答呢？……具体怎么查、怎么把资料喂给模型，你觉得这个流程的关键是什么？
直球架构
讲讲RAG的基本原理和系统架构，从索引、检索到生成整个链路怎么设计，以及它相比纯生成模型的核心优势体现在哪些方面？
这道题其实问的是，怎么让大模型在不重训的情况下，能回答实时、专业、可溯源的问题。[[RAG]]的核心思路很简单：不把知识全塞进模型参数里，而是动态拉取相关文档作为上下文，让模型基于检索结果来生成。你可以把它理解成给模型配了个外挂知识库，模型负责推理和表达，知识库负责提供事实。
具体架构分三块：索引模块、检索模块、生成模块。先说索引，离线阶段要把原始文档切成小块，然后用 [[Embedding]] 模型转成向量存到 [[Vector Database]] 里。这里有个关键取舍：切分策略直接影响召回质量。固定长度切分最简单，但容易把完整语义砍断；语义切分虽然准，但计算成本高。我一般先按段落切，对超长段落再用[[滑动窗口]]重叠处理，这样既能保留上下文，又控制单块长度。另外，纯向量检索对关键词不敏感，比如搜“退款政策”可能因为语义偏差召不回“退货流程”，所以生产上我倾向 [[Hybrid Search]]，把向量检索和 [[BM25]] 关键词检索结合起来，再通过 [[Rerank]] 模型做最终排序。
工作流程分两步走。离线准备阶段，文档切分、向量化、入库，这部分可以离线跑。在线查询时，用户问题先向量化，到向量库做[[近似最近邻]]搜索，取 Top-K 块，然后把这些块和原始问题拼成一个 Prompt，喂给大模型生成答案。这里有个常见失败场景：检索回来的文档质量差，或者和问题不相关，模型就会基于错误上下文胡编。所以我会在检索后加一道置信度过滤，如果 Top-K 的相似度分数普遍低于阈值，就降级处理，比如告诉用户“知识库没有相关答案”，而不是硬生成。
相比纯生成模型，RAG 的优势很明显。最核心的是知识实时更新，知识库改一条记录，下次查询就生效，不需要重新训练。其次是可溯源，模型引用了哪几段文档能展示给用户，方便审计和调试。但和微调比，RAG 不是万能的。微调适合让模型学会特定风格或复杂推理模式，比如把公司内部术语的表达方式固化下来；而 RAG 适合高频更新、需要引用外部事实的场景，比如客服的退款政策、电商的满减规则。真正落地往往是 RAG 加微调一起上，RAG 负责事实，微调负责表达。
不过 RAG 也有前提和风险。知识库本身的质量决定天花板，如果文档本身有错、过期、或者切分不合理，检索结果就会带偏模型。另外，检索延迟和精度要平衡，Top-K 取太多会让 Prompt 过长，影响模型推理速度和效果。上线我会特别关注 [[RAGAS]] 评估指标，比如上下文精度和召回率，定期用一批标注 query 做回归。
还有一个进阶方向是 [[Self-RAG]]，让模型在生成过程中自己判断是否需要检索、检索结果是否可信，而不是每次都无脑拼接。这能进一步减少噪声引入，但实现复杂度也更高。
所以整体上，我把 RAG 看作一个工程系统，核心是在检索质量和生成质量之间做取舍。我更倾向先用混合检索加重排保证召回精度，再通过置信度过滤和降级策略兜底，而不是一味堆高检索召回率。