完整题目
请详细描述检索增强生成（RAG）技术的完整工作流程，包括检索、增强和生成三个核心阶段的实现细节。
本文目录
答案要点
- 离线知识库构建（文档解析、分块、向量化）
- 检索阶段的双路召回策略（向量+关键词）
- 重排序优化
- 上下文拼接与提示模板设计
- 生成阶段的引用溯源与幻觉控制
RAG完整工作流程
一、离线知识库构建（预处理）
- 文档解析：处理PDF/Word/网页等多格式，提取结构化文本
- 知识分块（Chunking）：按语义/固定长度/递归分割，通常512-1024 token，块间保留重叠防止断句
- 向量化：用Embedding模型（如BGE、M3E）将文本转为稠密向量
- 索引存储：写入向量数据库（Milvus/Faiss/Elasticsearch），建立HNSW等近似索引加速检索
二、在线检索阶段
双路召回策略：
- 向量检索：Query向量化后ANN搜索，捕获语义相似性
- 关键词检索：BM25等传统方法补充，确保专有名词命中
- 结果融合：RRF（Reciprocal Rank Fusion）合并两路结果
重排序优化：
- 用Cross-Encoder（如BGE-Reranker）精排Top-K候选，提升相关性
三、增强与生成阶段
- 上下文拼接：按相关性排序检索结果，拼入Prompt模板
- 提示工程：明确指令"基于以下参考资料回答"，约束模型引用来源
- 生成控制：
- 引用溯源：要求模型标注信息来源块
- 拒答机制：检索置信度低时触发"信息不足"回复
- 多轮优化：检索失败时自动扩展Query重写
关键工程细节
| 环节 | 典型选型 | 注意点 |
|---|---|---|
| Embedding | BGE-large-zh | 领域适配需微调 |
| 向量DB | Milvus | 考虑增量更新与版本管理 |
| 重排序 | BGE-Reranker-v2 | 计算成本高，控制候选规模 |
| 幻觉控制 | 引用+置信度阈值 | 不能100%消除，需人工兜底 |
高德场景下，地图POI、实时路况等结构化数据需特殊处理：先SQL过滤再向量检索，混合查询提升精度。
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服助手，用户问“上次那个订单发货没”，你首先得从知识库里找到他的订单信息。能从头到尾讲一下，从文档处理到最终回答，RAG是怎么一步步干的吗？
层层追问
RAG你熟悉吧？先说说你一般怎么把知识库准备好……然后用户提问了，你怎么把相关内容捞出来……捞出来之后又怎么拼给模型让它回答？
直球架构
请详细描述RAG的完整工作流程，包括离线知识库构建、检索阶段的向量与关键词双路召回、重排序，以及增强生成阶段的上下文拼接和幻觉控制，每个环节怎么实现？
练习口述回答 · 约4分钟
- RAG本质是给大模型配外挂知识库
- 离线建库的坑：分块和向量化
- 在线检索：混合检索加重排才是常态
- 生成阶段：引用溯源和拒答机制
- 落地风险：前提和取舍
这道题问[[RAG]]的工作流程，其实本质是在问怎么把大模型的知识边界扩展出去，让它能回答训练数据里没有的东西。我理解RAG不是单一技术，而是一套工程组合拳，核心就三件事：先把外部知识存成索引，再根据问题准确定位到相关片段，最后让模型基于这些片段生成答案，同时还要避免它胡编。
先说离线建库。这一步很多人只关注选哪个[[向量数据库]]，但我认为真正的难点在[[分块]]和[[向量化]]。分块不是简单按512 token切，要结合业务场景。比如客服退款场景，一个订单的完整上下文往往跨越多个段落，固定长度切分会把因果链条切断。我倾向用语义分块加[[滑动窗口]]，块间是否保留重叠、保留多少都作为候选变量，用同一评测集验证边界证据是否更完整。Embedding模型也不是通用的，如果处理的是企业合规文档，大量专业术语和内部缩写，通用 BGE 效果可能不好，需要领域适配微调。
然后是检索阶段。这里有个常见误区，以为纯向量检索就够了。实际落地中，向量检索对语义相似性很敏感，但遇到精确匹配的场景，比如订单号、错误码，向量检索反而会跑偏。所以线上我一般用 [[混合检索]]，向量走 [[ANN]] 搜语义，关键词走 [[BM25]] 搜精确匹配，最后用 RRF 融合排序。但这样就够了吗？不够。融合后的Top-K候选里，可能还有一两篇不相关的，所以我会再加一层 [[重排]]，用 [[Cross-Encoder]] 精排一下。重排计算成本高，所以只对Top-50做，控制延迟。这里有个坑：重排模型本身也有偏差，如果训练数据分布和线上不一致，排序可能反而变差，所以上线前一定要用线上query回测。
接下来是生成阶段。这一步最关键的工程细节是上下文拼接和提示设计。我会按相关性从高到低把检索结果拼进Prompt，但不会全塞，信息太多模型会迷失，我一般限制在3到5个片段，每个不超过500 token。提示模板里明确写“请基于以下参考资料回答”，并且要求模型标注引用来源，比如“根据文档第X块”。另外，我还会加一个置信度阈值：如果检索结果和query的相似度低于某个值，直接触发拒答机制，返回“当前信息不足以回答”，而不是让模型硬猜。这能显著降低 [[幻觉]] 风险。
不过，RAG不是万能的。它的前提是知识库质量够高，如果文档本身就有错，或者分块把关键信息切碎了，检索再强也白搭。所以我会把RAG看成一种“快速扩展知识边界”的方案，适合知识频繁更新的场景，比如实时政策、产品手册；但如果是需要深度推理或常识性知识，我更倾向结合微调或[[知识图谱]]。
总结下来，RAG落地的核心不是哪个环节最酷，而是整个链路的一致性：从分块策略、Embedding选型、检索融合，到生成控制，每一步都要对齐业务场景。