完整题目
请详细解释检索增强生成（RAG）技术的工作原理和核心组件
本文目录
答案要点
- RAG的完整流程：索引、检索、生成三阶段
- Embedding模型的作用和选择
- 向量数据库的构建与检索算法（HNSW/IVF）
- 检索策略：稠密检索、稀疏检索、混合检索
- RAG的优化方向：查询改写、重排序、多路召回
RAG核心架构：索引-检索-生成三阶段
1. 索引阶段（离线）
- 文档切分：按语义/固定长度分块，chunk size通常256-512 token
- 向量化：用Embedding模型（如BGE、M3E、OpenAI text-embedding）将文本转为稠密向量
- 索引构建：存入向量数据库（Milvus、Faiss、Pinecone），采用HNSW或IVF-PQ等近似最近邻算法加速检索
2. 检索阶段（在线）
- 查询向量化：用户问题同样经Embedding模型编码
- 相似度计算：余弦相似度或点积，召回Top-K相关片段
- 检索策略演进：
- 稠密检索：语义匹配好，但可能漏关键词
- 稀疏检索（BM25）：精准匹配关键词，补充稠密检索
- 混合检索：稠密+稀疏融合，线性加权或RRF重排
3. 生成阶段
- 上下文组装：检索结果 + 用户Query构造Prompt
- 大模型生成：基于提供的上下文作答，典型Prompt模板包含"仅根据以下信息回答，不知道就说不知道"
关键优化点
| 环节 | 优化手段 |
|---|---|
| 检索质量 | 查询改写（HyDE）、多路召回、重排序（Cross-Encoder） |
| 上下文利用 | 长上下文压缩、信息去重、相关性过滤 |
| 端到端 | Self-RAG（模型自主判断是否需要检索）、RAG-Fusion |
一句话总结
RAG的本质是用检索代替记忆，让大模型基于外部实时知识生成，解决知识时效性和幻觉问题。
换一种问法，检查是否真正理解
场景切入
假设现在你要给电商客服做个智能问答系统，用户问题千奇百怪，比如查订单、问退货政策，而且知识库实时更新。你打算怎么让大模型准确基于最新知识回答，而不是瞎编？
层层追问
大模型有幻觉、知识也滞后，你一般怎么解决？……如果靠外挂知识库，那你怎么把问题和知识库里的文档匹配上？……匹配到的片段怎么组织给模型？整个流程有哪些关键环节？
直球架构
请从系统架构角度讲一下RAG的工作原理，包括离线索引、在线检索和生成三个阶段，核心组件有哪些？比如向量数据库、Embedding模型怎么选，检索策略和优化手段是什么？
练习口述回答 · 约4分钟
- RAG本质是让模型基于外部知识回答
- 三阶段：索引、检索、生成
- 检索策略对比与混合检索
- 落地常见坑：切分粒度与召回质量
- 优化方向与取舍
这道题我觉得核心是在问：你怎么让大模型知道它训练时没见过的东西？[[RAG]] 的思路很简单，用检索代替记忆。模型不需要记住所有知识，需要的时候去外部数据库里查，再把查到的信息塞进 Prompt 让它生成。这样好处很明显：知识更新快，可控，[[幻觉]]也能压下去。
具体分三步走。先说离线索引，就是把文档切碎、转成向量存起来。这里有个前提：切分的粒度直接影响后面召回质量。切太粗，一块里面混着好几件事儿，检索容易带偏；切太细，上下文断了，模型看不懂。一般 chunk size 在 256 到 512 token，但真正落地时我会根据文档结构调整，比如技术手册按章节切，客服对话按轮次切。然后调个 [[Embedding]] 模型把文本转成向量，存到 [[Vector Database]] 里，像 Milvus 或者 [[Faiss]]，用 [[HNSW]] 索引加速检索。
第二步是在线检索。用户提问后，同样用那个 Embedding 模型把问题转成向量，去库里做相似度搜索，召回 Top-K 个相关片段。这里有个常见的失败场景：纯用向量检索，碰上关键词匹配的场景容易翻车。比如用户问“订单号 ERR-2024-001”，向量检索可能因为语义不相似而漏掉精确匹配的文档。所以真正上线我一般用 [[Hybrid Search]]，把向量检索和 [[BM25]] [[稀疏检索]]结合起来，比如线性加权或者 RRF [[重排]]。举个业务场景：电商客服处理退款，用户说“我买的东西降价了，能退差价吗”，向量检索能召回满减政策，BM25 能精准匹配“差价”这个词，两个互补，召回率能提不少。
第三步是生成。把检索到的片段和用户问题组装成 Prompt，交给大模型。Prompt 里我会明确写“仅根据以下信息回答，不知道就说不知道”，防止模型自由发挥。这里有个优化点：检索出的片段不一定都相关，需要过滤和重排。我会加一层 Rerank，用 [[Cross-Encoder]] 对候选片段和问题做精细匹配，只取置信度高的，这样生成内容更准。
说到优化，现在更前沿的做法是 [[Self-RAG]]，让模型自己判断要不要检索、检到什么程度，甚至生成时反思检索结果够不够。比如模型发现当前上下文已经能回答，就不去检索，减少延迟。这种动态策略对长对话场景特别有用，但实现起来需要额外训练，对推理效率也有挑战。
所以整体来看，RAG 不是一套固定流水线，更像一套可插拔的组件。我的倾向是：先保证索引和检索的基础质量，再根据场景逐步加 Rerank、查询改写这些优化。如果上线前发现召回的片段质量波动大，我会优先排查切分粒度和 Embedding 模型的选择，而不是一上来上复杂策略。