完整题目
请详细描述检索增强生成(RAG)的完整工作流程，包括各个组件的功能、数据流向以及关键技术环节。
本文目录
答案要点
- 离线知识库构建流程（文档解析、分块、向量化、索引存储）
- 在线检索生成流程（查询向量化、相似度检索、上下文组装、LLM生成）
- 关键技术环节（分块策略、Embedding模型选择、重排序优化、检索结果融合）
- 能区分Naive RAG与Advanced RAG的差异
RAG完整工作流程
一、离线知识库构建（Indexing）
| 步骤 | 功能 | 关键技术 |
|---|---|---|
| 文档加载 | 解析PDF/Word/网页等多源格式 | OCR、表格识别、版式分析 |
| 文本分块 | 将长文档切分为语义完整的片段 | 固定长度/递归/语义分块；块大小通常256-512 token |
| 向量化 | 将文本块转为稠密向量 | Embedding模型（BGE、M3E、OpenAI text-embedding-3等） |
| 索引存储 | 构建高效向量索引 | HNSW、IVF等ANN算法；向量数据库（Milvus、Faiss、Qdrant） |
二、在线检索生成（Retrieval & Generation）
用户Query → Query改写/扩展 → 向量化 → 向量检索(Top-K)
↓
LLM生成 ← 上下文组装 ← 重排序优化 ← 候选文档关键组件：
- 查询优化：HyDE（假设文档嵌入）、查询扩展、多跳查询分解
- 检索策略：稠密检索（向量相似度）+ 稀疏检索（BM25）混合
- 重排序（Rerank）：Cross-Encoder模型精排，提升相关性
- 上下文组装：检索结果去重、截断、按相关性排序注入Prompt
三、核心技术要点
- 分块策略：按语义边界切分，避免切断关键信息；重叠窗口保持上下文连贯
- 检索精度：多路召回（向量+关键词）+ Rerank，解决语义漂移问题
- 生成控制：限制LLM仅基于检索内容回答，降低幻觉；引用溯源增强可信度
四、演进方向
| 阶段 | 特点 |
|---|---|
| Naive RAG | 基础检索+生成，容易检索噪声 |
| Advanced RAG | 加入查询改写、重排序、检索前/后处理 |
| Modular RAG | 动态路由、多知识源融合、Self-RAG反思机制 |
换一种问法，检查是否真正理解
场景切入
假设你做一个企业知识库问答系统，用户问“去年Q3的财报”，系统得先检索文档再生成回答。你具体说说，从用户提问到最终答案，整个流程里数据怎么流转、每一步干什么？
层层追问
RAG系统你了解吧？……那从原始文档开始，第一步要做什么？……怎么把文档变成可检索的形式？……检索出来的结果直接给大模型吗，中间有没有优化环节？
直球架构
请完整描述RAG的离线索引流程和在线检索生成流程，包括文档分块、向量化、检索、重排序、上下文组装等每个模块的功能和数据流向，以及你理解的关键技术点。
练习口述回答 · 约4分钟
- 一句话定位：RAG本质是给LLM外挂知识库，解决知识更新和幻觉问题
- 离线构建：文档切分、向量化、索引存储，重点讲分块策略的取舍
- 在线流程：查询优化、混合检索、重排序、上下文组装，用客服退款场景串起来
- 落地风险和边界：RAG vs微调，常见失败场景，以及上线前必须关注的指标
- 工程师判断：我更倾向混合检索加Rerank，并主动提Self-RAG作为延伸
这道题问的是[[RAG]]的完整工作流程，其实本质就是在问：怎么给大模型外挂一个知识库，让它既能回答私有域的问题，又能控制[[幻觉]]。整个流程分成离线构建和在线推理两段，我分别说一下。
先说离线构建，也就是建知识库。核心步骤是文档解析、[[分块]]、[[向量化]]、存索引。这里面最容易出问题的是分块。你可能会想，不就是把文档切成一段段嘛。但切多细、按什么切，直接影响检索质量。固定长度切分最简单，但容易把一句完整的话拦腰切断，导致检索时语义不连贯。我更倾向用语义分块，比如按段落或句子边界切，再配合一定的重叠窗口，保证上下文不丢。块大小一般256到512 token，具体看你的文档类型。比如企业SOP文档，每段本身就是一个独立指令，按段落切就很自然。但如果是合同条款，可能一条里包含多层条件，切太小反而丢失关系。所以落地时我会先分析文档结构，再定分块策略，没有银弹。
在线推理流程，简单说就是用户提问，系统去知识库里找相关内容，拼成上下文，最后让LLM生成回答。这里我重点讲三个环节：查询优化、检索策略、[[重排序]]。举个例子，客服退款场景。用户问“我昨天买的手机降价了，能退差价吗”。直接拿这句话去向量检索，可能匹配到的是“退差价政策”，但没抓到时间、商品这些细节。所以我会先做查询改写，比如用[[Hybrid Search]]把关键词和向量结合起来，或者用HyDE先生成一个假设的文档再检索，提高命中率。检索出来Top-K结果，一般几十条，但里面肯定有噪声。这时候需要重排序，用[[Cross-Encoder]]模型精排，把最相关的几条排到前面。我通常只保留前三到五条，太多会稀释有效信息。
这里有个坑，就是检索质量。如果知识库里本身就有错，或者分块不合理，检索结果全是无关的，那LLM再强也白搭。所以我上线前一定会做召回评估，看Recall@K和MRR，确保检索质量达标。另外，RAG和微调不是二选一。微调适合让模型学会特定格式或风格，但知识更新慢。RAG适合动态知识，比如价格、库存、政策。真正落地往往是两者结合：微调让模型理解业务语义，RAG提供实时知识。
最后说一下我的判断。我会把RAG看成一套系统工程，而不是简单的检索加生成。它的前提是知识库质量要够高，如果文档本身混乱、噪声多，RAG效果会大打折扣。常见的失败场景是检索结果和问题语义相关但没答到点上，比如用户问“订单号12345的状态”，检索到的是“订单查询流程”，而不是具体那条订单。所以我会特别关注检索的精度和上下文组装，必要时加入[[Faithfulness]]校验，确保生成内容忠实于检索结果。
其实现在已经有进阶方案，比如[[Self-RAG]]，让模型在生成过程中自己判断是否需要检索、检索结果是否可信，甚至自我纠错。这种动态路由的方式，能进一步提升RAG的鲁棒性。