面试题 · 检索
请详细解释检索增强生成（RAG）的技术原理、核心组件以及完整的工作流程，并说明其在解决大模型幻觉问题方面的优势。
RAG的本质是给大模型外挂一个"可查询的知识库"，让生成过程有据可依。
1. 索引层（Indexing）
2. 检索层（Retrieval）
按学习路线查看教程、项目和面试题。
3. 生成层（Generation）
用户Query → Embedding编码 → 向量库检索Top-K → 重排序筛选 →
Prompt组装（系统指令+检索上下文+Query） → LLM生成 → 输出+溯源引用| 机制 | 作用 |
|---|---|
| 事实锚定 | 生成内容被约束在检索到的上下文范围内，减少自由发挥 |
| 可溯源 | 输出可附带原文出处，便于人工校验 |
| 知识时效性 | 无需重训模型，更新知识库即可同步最新信息 |
| 领域适配 | 低成本注入私有/垂直领域知识 |
关键局限：检索质量是天花板——"检索错则生成错"，需配合查询改写、多路召回、答案一致性校验等手段优化。
场景切入
假设你在做一个电商客服助手，用户问“iPhone 16多少钱”，你回答完。过两天他又问“那和小米15比呢”，如果不查知识库，模型可能瞎编价格。你会怎么用RAG来保证回答准确？
层层追问
大模型回答容易出错，你怎么解决？……如果给它外挂一个知识库，怎么让模型用上？……那具体怎么检索、怎么把结果塞进Prompt里，整个流程你拆解一下？
直球架构
讲一下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 看成兜底方案，而不是万能药，它能低成本注入领域知识，但最终效果上限取决于检索质量，下限取决于知识库质量。