完整题目
请系统阐述检索增强生成（RAG）系统的整体工作流程，详细说明从用户输入查询开始，经过检索、上下文融合到最终生成回答的各个关键阶段，并解释每个环节的技术实现要点及其对结果质量的影响。
本文目录
RAG系统五阶段工作流程
1. 查询理解与改写
- 技术要点：Query扩展（同义词、HyDE生成假设文档）、意图识别、多轮对话历史融合
- 质量影响：查询语义漂移直接导致检索偏差，是RAG失效的首要环节
2. 文档检索（召回阶段）
| 方法 | 适用场景 | 实现要点 |
|---|---|---|
| 向量检索（Dense） | 语义匹配、长尾查询 | Embedding模型选择（BGE/M3E）、向量数据库（Milvus/Faiss）、HNSW索引 |
| 关键词检索（Sparse/BM25） | 精确匹配、实体查询 | 分词策略、词频权重调优 |
| 混合检索 | 通用场景 | RR融合或线性加权，兼顾语义与精确匹配 |
- 质量影响：召回率决定答案上限，需平衡速度与精度（Top-K通常取20-100）
3. 重排序（精排阶段）
- 必要性：双塔Embedding检索牺牲精度换速度，需Cross-Encoder二次精排
- 实现：ColBERT轻量交互、LLM-based重排（成本高但效果好）
- 质量影响：过滤噪声文档，Top-5重排后准确率可提升15-30%
4. 上下文构建与压缩
- 关键挑战：上下文窗口限制（4K/8K/128K）、信息密度不均
- 技术方案：
- 文本切片策略：按语义段落/滑动窗口，非固定长度
- 上下文压缩：LLMLingua选择性压缩、摘要式压缩
- 引用标记：为生成内容附加来源，便于溯源
5. 生成与后处理
- 提示工程：明确指令（"仅基于以下文档回答"）、Few-shot示例约束格式
- 生成控制：温度参数、重复惩罚、结构化输出（JSON模式）
- 质量影响：幻觉抑制依赖上下文相关性与指令遵循能力的平衡
各环节协同关系
检索质量是天花板，生成能力是地板——检索不准则生成必错，检索准确但生成指令不清则答案冗余。实际系统中需建立检索-生成联合评估闭环，持续优化Embedding模型与领域数据对齐。
学习建议
建议先掌握RAG基本流程框架，再结合实际案例理解检索器、重排序和生成模型的协作机制，多动手搭建简单RAG系统加深理解。
换一种问法，检查是否真正理解
场景切入
假设你们在给电商客服做一个知识库问答系统，用户问“这款手机支持快充吗”，系统先要检索产品文档再生成回答。你从头到尾讲讲这个过程会经过哪些阶段，每个阶段要注意什么？
层层追问
RAG系统里，用户输入查询后，第一步你会做什么？……那检索完拿到的文档直接扔给LLM生成吗？……如果检索结果太多、质量参差不齐怎么办？……好，最后生成时怎么保证答案不瞎编？
直球架构
请你系统阐述RAG的工作流程，从查询理解、检索、重排序、上下文构建到生成，每个环节的技术要点和对最终结果的影响，说清楚就行。
练习口述回答 · 约4分钟
- RAG本质是给大模型配外挂知识库
- 检索阶段：混合检索平衡语义与精确
- 重排序：精排过滤噪声
- 上下文构建与生成：压缩、指令、幻觉抑制
- 协同关系与落地风险
这道题问的是[[RAG]]整体流程，我觉得本质上是在问：你怎么给大模型配一个靠谱的外挂知识库，让它既能查得准，又能用得好。我一般把整个过程拆成五个阶段来理解：先是对用户查询做理解和改写，然后是检索，接着[[重排序]]，再构建上下文，最后生成答案。每个环节都有取舍，我重点说几个关键点。
先说查询理解。用户输入往往很糙，比如一句“上次那个订单为什么没退款”，如果直接拿这个去搜，可能命中率很低。所以我会做两件事：一是意图识别，判断用户是想查订单状态还是问政策；二是查询改写，比如用 [[Hybrid Search]] 里提到的技术，把问题转成更规范的表述，或者补充同义词。这一步如果做不好，后面的检索方向就偏了，这是RAG失效最常见的入口。
接下来是检索阶段，这是整个系统的天花板。检索质量决定了答案的上限。这里有个经典选择：用向量检索还是关键词检索。向量检索擅长语义匹配，比如“退运费险”能关联到“退货包运费”，但遇到精确的订单号或商品编码就抓瞎；关键词检索（比如 [[BM25]]）正好相反，精确匹配强，但不懂语义。所以真正落地我通常会把两者混合起来，用 Hybrid Search 的思路，比如对搜索结果做线性加权或RR融合，这样既能抓到语义相关的，也能保住精确匹配的。这里有个前提：你得有好的分词和 [[Embedding]] 模型，不然两边都跑偏。召回数量我一般设Top-K=50到100，太少漏信息，太多塞不进上下文。
检索完不能直接喂给模型，因为向量检索用的 [[Bi-Encoder]] 为了速度牺牲了精度，结果里经常混着不相关的噪声。所以我一定会加一道重排序。重排序就是用更精细的模型对候选文档重新打分，比如用 [[Cross-Encoder]]，它能把查询和文档逐对做深度交互，准确率高很多。一般把Top-50重排成Top-5，准确率能提15到30个点。代价是慢，所以只对少量候选做。
然后是把这些文档拼成上下文。这里最大的坑是上下文窗口有限，而且信息密度不均匀。我一般不会用固定长度的[[切片]]，而是按语义段落或章节切，保证一个块讲一个完整意思。如果文档太多，我还会用压缩技术，比如 LLMLingua 选择性删掉不重要的词，或者让模型自己摘要。另外，我会在上下文里加引用标记，比如“[来源：文档3]”，这样生成时可以溯源，方便排查[[幻觉]]。
最后是生成。提示工程很重要，我会在 [[System Prompt]] 里明确说“只基于以下文档回答，不知道就说不知道”，再给一两个 [[Few-shot]] 例子约束输出格式。生成时调低温度到0.1左右，减少随机性。生成的质量取决于上下文相关性和指令遵循能力的平衡，上下文再准，指令不清照样答非所问。
说到幻觉，其实有一个常见场景是用户问“这个政策什么时候改的”，但文档里只有政策内容没有时间戳，这时候模型可能会自己编一个，这就是 Hallucination。所以上线后我会特别关注 [[Faithfulness]] 指标，比如用 [[RAGAS]] 框架评估答案是否忠于上下文，同时做 [[Self-RAG]] 让模型自己判断有没有证据支撑。