RAG 怎么解决大模型幻觉?
技术原理、核心组件与工作流程详解
原题：请详细解释检索增强生成（RAG）的技术原理、核心组件以及完整的工作流程，并说明其在解决大模型幻觉问题方面的优势。
重排与优化 · 京东真题
30 秒回答
- 清晰阐述RAG"检索-增强-生成"三段式架构
- 说明向量数据库和Embedding的核心作用
- 解释检索策略（相似度搜索、重排序）的关键设计
- 分析RAG缓解幻觉的机理（事实锚定+可溯源）
回答与解析
答案要点
- 清晰阐述RAG"检索-增强-生成"三段式架构
- 说明向量数据库和Embedding的核心作用
- 解释检索策略（相似度搜索、重排序）的关键设计
- 分析RAG缓解幻觉的机理（事实锚定+可溯源）
- 提及RAG的局限（检索质量瓶颈、上下文窗口限制）
核心架构：检索-增强-生成
RAG的本质是给大模型外挂一个"可查询的知识库"，让生成过程有据可依。
三大核心组件
1. 索引层（Indexing）
- 文档切分（Chunking）：按语义或固定长度分块，通常512-1024 token
- Embedding编码：用BGE、M3E等模型将文本转为稠密向量
- 向量存储：Milvus、Faiss、Elasticsearch等，支持ANN近似最近邻搜索
2. 检索层（Retrieval）
- 相似度计算：余弦相似度或点积，召回Top-K候选
- 重排序优化：Cross-Encoder精排，提升相关性
- 混合检索：向量检索 + 关键词BM25，覆盖语义和字面匹配
3. 生成层（Generation）
- 上下文组装：检索结果 + 用户Query拼接成Prompt
- 大模型生成：基于锚定的事实进行回答
工作流程
用户Query → Embedding编码 → 向量库检索Top-K → 重排序筛选 →
Prompt组装（系统指令+检索上下文+Query） → LLM生成 → 输出+溯源引用
缓解幻觉的核心优势
| 机制 | 作用 |
|---|---|
| 事实锚定 | 生成内容被约束在检索到的上下文范围内，减少自由发挥 |
| 可溯源 | 输出可附带原文出处，便于人工校验 |
| 知识时效性 | 无需重训模型，更新知识库即可同步最新信息 |
| 领域适配 | 低成本注入私有/垂直领域知识 |
关键局限：检索质量是天花板——"检索错则生成错"，需配合查询改写、多路召回、答案一致性校验等手段优化。
口语版讲法(约4分钟)
- 一句话定位：RAG的本质是给大模型外挂一个可查询的知识库
- 核心组件：索引、检索、生成，重点讲检索和切分
- 工作流程：用客服退款场景串一遍
- 缓解幻觉的机理：事实锚定和可溯源，但前提是检索质量
- 风险与收尾：检索错则生成错，我更倾向把它当兜底方案
这道题其实是在问：怎么在不重训模型的前提下，让大模型说人话、说真话。RAG 的答案很直接，给模型外挂一个可查询的知识库，让它生成时有个事实锚点。
具体说，RAG 分三大块：索引、检索、生成。索引层最容易被低估，其实它是整个系统的地基。文档怎么切？固定长度切 512 token 还是按语义切？我的经验是，如果文档是标准化的，比如企业 SOP 或合规文档，语义切分更好，因为段落边界天然是逻辑单位。但如果是客服退款这种长对话记录，固定长度加重叠窗口反而更稳，不会把一个完整诉求拦腰切断。切完后用 Embedding 模型转成向量，存到 Vector Database 里，比如 Milvus 或 Faiss。
检索层是真正的瓶颈。你不能只靠向量相似度，因为用户的 query 可能很口语化，比如「我订单咋还没退钱」，向量召回容易偏。我会用 Hybrid Search，向量加 BM25 关键词两条腿走路，召回后再用 Cross-Encoder 做一次 Rerank，把相关性提上来。这里有个坑：如果知识库频繁更新，比如商家满减政策隔天变，检索不能只依赖向量索引的增量插入，因为删除操作如果原地动图索引，召回质量会崩。我会用软删除加异步重建，再配合影子索引做原子切换。
整个流程走下来就是：用户 query → 编码成向量 → 去向量库搜 Top-K → 重排 → 拼 Prompt → 大模型生成。举个例子，客服场景里用户问「我满200减50的券为什么用不了」，系统先检索到最新的满减规则和该券的使用记录，然后大模型基于这些事实回复，最后还能附上原文链接，方便客服复核。
说到缓解 Hallucination，RAG 的核心优势就是事实锚定和可溯源。生成内容被约束在检索到的上下文里，模型不容易自由发挥。而且知识库一更新，模型立马能用新知识，不用重训。但前提是检索质量得过硬，检索错则生成错。上线我会特别关注两件事：一是检索的 Recall@K 能不能稳定在 90% 以上，二是生成时模型是否忠实于上下文，会跑 Faithfulness 指标。常见失败场景是用户 query 太模糊，比如「我的订单有问题」，这种需要先做 query 改写或 Self-RAG 让模型自己判断要不要追问。
其实 RAG 还有一个隐含前提：知识库本身的质量。如果库里有矛盾或过时的信息，检索再准也是错的。所以我更倾向把 RAG 看成兜底方案，而不是万能药，它能低成本注入领域知识，但最终效果上限取决于检索质量，下限取决于知识库质量。
关键一句:RAG的效果上限取决于检索质量，下限取决于知识库本身的质量
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做一个电商客服助手，用户问“iPhone 16多少钱”，你回答完。过两天他又问“那和小米15比呢”，如果不查知识库，模型可能瞎编价格。你会怎么用RAG来保证回答准确？
- 问法 2 · 层层追问
大模型回答容易出错，你怎么解决？……如果给它外挂一个知识库，怎么让模型用上？……那具体怎么检索、怎么把结果塞进Prompt里，整个流程你拆解一下？
- 问法 3 · 直球架构
讲一下RAG的核心架构和工作流程，包括文档怎么处理、怎么检索、最后怎么生成，以及它为什么能减少幻觉？