完整题目
请详细描述RAG（检索增强生成）系统的完整工作流程，从用户提问开始，涵盖检索、重排序、上下文构造到最终生成答案的全过程。
本文目录
RAG完整工作流程
1. 查询理解与改写
- 查询扩展：识别用户意图，必要时进行query改写（如多跳问题分解）
- 向量化：将query编码为dense/sparse向量，用于相似度检索
2. 检索召回（多路并行）
| 方式 | 特点 | 适用场景 |
|---|---|---|
| Dense Retrieval | 语义匹配，泛化性强 | 同义改写、概念理解 |
| Sparse Retrieval (BM25) | 关键词精确匹配 | 实体、专有名词 |
| 混合检索 | 两者加权融合 | 通用场景 |
- 召回Top-K（通常50-200），追求高召回率，允许一定噪声
3. 精排/重排序（Rerank）
- 使用交叉编码器（Cross-Encoder）或轻量重排模型
- 对召回文档精细打分，筛选Top-N（通常3-10）送入生成
- 关键作用：弥补双塔向量检索的语义鸿沟
4. 上下文构造
- 格式组装：按相关性排序，添加文档标识（如
[Doc 1]） - 长度控制：截断、摘要压缩、或分层检索（摘要→全文）
- 去重与连贯性：处理重复段落，保证上下文逻辑流畅
5. 生成答案
- 构造Prompt：系统指令 + 检索上下文 + 用户问题
- 模型生成时结合上下文约束，输出带引用的答案
6. 后处理（可选）
- 答案与来源的归因校验
- 置信度判断，触发"无法回答"兜底
核心权衡：检索阶段重召回、生成阶段重精准，中间靠重排序桥接。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设你在做电商客服机器人，用户问“上次那件红色羽绒服还有货吗？”，你需要从知识库检索商品信息。从用户提问到最终给出答案，你是怎么把检索、排序、生成串起来的？能详细说说每个步骤吗？
层层追问
RAG系统的完整流程你熟悉吧？从用户提问开始……第一步你通常做什么？……检索完拿回一堆文档，你会直接丢给模型吗？……中间加一个重排序步骤有必要吗？……最后怎么把上下文塞进prompt里？
直球架构
请详细描述RAG系统的完整工作流程：从用户提问开始，涵盖查询改写、多路检索、重排序、上下文构造到生成答案。每一步具体怎么做，用了什么技术？
练习口述回答 · 约4分钟
- RAG本质是检索+生成的分治
- 检索阶段重召回，多路并行与边界
- 重排桥接检索与生成
- 上下文构造与生成中的风险
- 落地权衡与工程师判断
这道题问的是[[RAG]]的完整流程，我觉得本质上是在问：怎么把外部知识可靠地注入到生成模型里，同时控制住[[幻觉]]。它不是单纯讲检索或者生成，而是两者怎么分工、怎么衔接。
具体来说，我会把流程拆成几个阶段。首先是查询理解，用户问的问题可能比较模糊，比如“退款为什么没到账”，我会想用户到底在问退款状态、到账时间还是异常原因。必要的时候做query改写，比如多跳问题拆解成子问题。这一步的难点在于，改写不能偏离原始意图，否则后面检索全是歪的。
然后是检索召回。这里我倾向于 多路并行，因为单一检索方式有盲区。[[Dense Retrieval]] 语义泛化强，但碰到专有名词比如订单号“ORD2024xxxx”就容易丢；[[BM25]] 精确匹配好，但同义改写“退款”和“退钱”它就不认识。所以真正落地常常是 [[Hybrid Search]]，把向量和关键词加权融合，召回Top-K，比如100条，追求高召回率，允许带一些噪声。这里有个前提：如果知识库里的文档本身质量不行，比如切分太碎或语义不完整，召回再多也没用。所以 [[Chunk]] 策略 很关键，我一般会先试固定大小加重叠，再根据业务场景调整，比如合同条款按段落切，FAQ按问答对切。
召回之后是[[重排]]。为什么要重排？因为[[双塔]]向量检索虽然快，但语义匹配不够精细。我会用 [[Cross-Encoder]] 对召回的100条重新打分，选出最相关的3到5条送生成。这一步的边界在于：重排不是万能的，如果检索阶段完全没召回相关文档，重排也救不回来。所以我会特别关注 召回率和重排的精度平衡，上线前用一批标注数据验证，比如看Top-5准确率。
上下文构造这块，我会按相关性排序，给每个文档加个标识，比如[Doc1]，然后拼接成一段上下文。但有个坑：上下文太长会稀释生成质量，我一般会做长度控制，要么截断，要么用轻量摘要压缩。还有就是去重，有时候不同文档内容重复，比如两篇都讲同一个政策，我会只保留信息最全的那篇。
最后是生成答案。我会把系统指令、检索上下文和用户问题拼成Prompt，让模型基于上下文回答。这里有个常见失败场景：模型可能忽略上下文，自己编答案。所以我会在 Prompt 里加约束，比如“请只基于以下文档回答，如果文档中没有相关信息，请说‘无法回答’”。后处理还可以做归因校验，把答案里的关键实体和来源文档对应起来。
说到归因，其实现在有个趋势是用 [[Self-RAG]] 让模型自己判断哪些段落可信、哪些需要再查，而不是靠外部规则。这块我觉得是RAG往更鲁棒方向演进的思路。