完整题目
请详细解释检索增强生成（RAG）的基本原理、系统架构、工作流程以及相比纯生成模型的优势。
本文目录
答案要点
- RAG核心原理：检索+生成的两阶段架构
- 系统组件：索引模块、检索模块、生成模块
- 工作流程：查询向量化、相似度检索、上下文拼接、LLM生成
- 核心优势：缓解幻觉、知识实时更新、可溯源、降低微调成本
基本原理
RAG（Retrieval-Augmented Generation）将外部知识检索与大模型生成结合，解决纯生成模型的知识截止和幻觉问题。
核心思想：不依赖模型参数记忆知识，而是动态检索相关文档作为上下文，让模型基于检索结果生成回答。
系统架构
| 模块 | 功能 |
|---|---|
| 索引模块 | 文档切分 → Embedding编码 → 向量数据库存储 |
| 检索模块 | 查询向量化 → 相似度搜索（Top-K召回） |
| 生成模块 | 检索结果+原始查询 → 拼接Prompt → LLM生成 |
工作流程
- 离线准备：文档分块 → 向量化（如BGE、OpenAI Embedding）→ 入库（Milvus/Faiss/Elasticsearch）
- 在线查询：用户问题向量化 → 向量相似度检索 → 取Top-K相关文本块
- 增强生成：将检索结果作为上下文，与问题一起输入LLM，生成最终回答
核心优势
| 对比维度 | 纯生成模型 | RAG |
|---|---|---|
| 知识时效性 | 训练数据截止，无法更新 | 知识库实时更新，无需重训 |
| 幻觉问题 | 容易编造事实 | 基于检索文档生成，可控可溯源 |
| 成本 | 全量微调昂贵 | 只需更新知识库，零训练成本 |
| 可解释性 | 黑盒生成 | 可展示引用来源，便于审计 |
典型变体
- Naive RAG：基础检索+生成
- Advanced RAG：查询重写、重排序（Rerank）、混合检索（向量+关键词）
- Modular RAG：引入路由、多跳检索、主动选择等复杂流程
换一种问法，检查是否真正理解
场景切入
假设你在做一个智能客服，用户问“我的订单什么时候到”，你直接让大模型回答，结果它瞎编了一个物流信息。如果换成RAG，你会怎么设计来避免这种问题？
层层追问
大模型生成答案容易胡说八道，你一般怎么缓解？……那如果让模型先去查资料再回答呢？……具体怎么查、怎么把资料喂给模型，你觉得这个流程的关键是什么？
直球架构
讲讲RAG的基本原理和系统架构，从索引、检索到生成整个链路怎么设计，以及它相比纯生成模型的核心优势体现在哪些方面？
练习口述回答 · 约4分钟
- 一句话定位：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 做回归。