完整题目
请详细描述检索增强生成（RAG）的技术流程和工作原理。
本文目录
答案要点
- 清晰描述RAG的完整流程（索引-检索-生成三阶段）
- 说明向量检索的核心机制（Embedding+相似度计算）
- 解释RAG解决的核心问题（知识时效性、幻觉、私有数据）
- 提及关键优化点（分块策略、重排序、混合检索）
- 能对比RAG与微调的区别和适用场景
RAG核心流程：索引 → 检索 → 生成
1. 索引阶段（离线）
- 文档解析：处理PDF、Word、网页等多格式文档
- 文本分块（Chunking）：按固定长度、语义段落或递归方式切分，控制块大小（通常256-512 tokens）
- 向量化：用Embedding模型（如BGE、M3E、OpenAI text-embedding-3）将文本转为稠密向量
- 存储：写入向量数据库（Milvus、Faiss、Pinecone等），建立索引加速检索
2. 检索阶段（在线）
- 查询向量化：用户问题同样转为Embedding向量
- 相似度搜索：用ANN（近似最近邻）算法快速召回Top-K相关块
- 重排序优化：用Cross-Encoder等精排模型提升相关性（可选但重要）
3. 生成阶段
- 上下文组装：将检索结果与用户问题拼接成Prompt
- 大模型生成：LLM基于"检索到的证据"生成回答，典型Prompt结构：
基于以下参考资料回答问题： [检索内容1] [检索内容2] 问题：{用户提问}
RAG解决的核心问题
| 问题 | 说明 |
|---|---|
| 知识时效性 | 大模型训练数据有截止日期，RAG可接入实时数据库 |
| 幻觉问题 | 生成有溯源依据，可标注参考来源 |
| 私有数据 | 无需训练即可利用企业内部知识 |
| 成本可控 | 比全量微调成本低得多 |
关键优化方向
- 混合检索：向量检索 + 关键词检索（BM25）结合
- 查询改写：HyDE、Query Expansion提升召回率
- 多路召回：摘要、标题、正文分别建索引
换一种问法，检查是否真正理解
场景切入
假设你要给电商客服做一个智能问答系统，需要实时查询商品库存和退换货政策，但大模型对内部数据一无所知。你会怎么设计，才能让模型准确回答“这款手机还有货吗”这种问题？
层层追问
大模型回答有时会胡说八道，你怎么保证它能基于真实知识来回答？……如果知识是动态更新的呢？……那你怎么把外部知识塞进去，又不重新训练模型？
直球架构
讲一下检索增强生成（RAG）从索引到检索再到生成的全流程技术实现，包括文档分块、向量化、相似度搜索和提示组装这些关键环节。
练习口述回答 · 约4分钟
- 本质定位：RAG不是万能药，是知识外挂
- 三阶段流程：索引、检索、生成
- 业务场景：客服退款政策
- 优化与风险：混合检索、分块策略
- 边界判断：RAG vs 微调
这道题问[[RAG]]，其实本质是在问：怎么让大模型在不改变参数的前提下，拥有实时、可信的外部知识。RAG解决的不是模型能力问题，而是知识边界问题。
流程上分三块：索引、检索、生成。我先说索引。离线阶段，我们把文档切碎、[[向量化]]、存进 [[Vector Database]]。这里有个常见的坑：[[分块]]策略。固定长度切分简单，但容易切断语义；语义切分效果好，但计算成本高。我的做法是混合：先用段落级粗切，再对超长块做递归切分，控制块大小在256到512 tokens之间。Embedding模型我倾向用 BGE 或 M3E，兼顾中文效果和推理速度。
检索阶段，用户问题同样转成向量，用 [[ANN]] 算法召回Top-K。但光靠向量不够，比如“退款”和“退货”语义相近但业务不同，所以我会加 [[Hybrid Search]]：向量检索加 [[BM25]] 关键词检索，两路结果合并后再用 [[Cross-Encoder]] [[重排序]]。这一步能显著提升召回相关性，尤其当知识库有大量相似文档时。
生成阶段，把检索到的文本和问题拼成Prompt，让LLM基于证据回答。Prompt结构很关键：先给检索内容，再给问题，明确要求模型引用来源。这里有个风险：如果检索内容有噪声或冲突，模型可能会混淆。所以我会设一个置信度阈值，低于0.6的块直接丢弃，避免污染上下文。
举个例子，电商客服场景。用户问“我买的手机降价了，能退差价吗？”系统先检索知识库，找到“7天价保”政策文档，然后LLM基于这个文档生成回答，并标注来源。如果知识库没更新，比如政策刚改，那RAG就抓不到，所以前提是知识库必须实时同步。常见失败场景是文档版本混乱，比如旧政策和新政策混在一起，检索出矛盾内容，模型会给出模棱两可的回答。
另一个优化方向是查询改写。比如用户问“怎么退款”，系统可以先把它改写成“退款流程和条件”，再检索，能提升召回。这块可以结合 [[ReAct]] 模式，让模型边思考边检索。
最后说一下RAG和微调的边界。微调适合让模型学习特定风格或格式，比如把回答变得幽默；但微调不能注入新知识，而且成本高、更新难。RAG适合知识频繁更新、需要溯源、或者涉及隐私数据的场景。真正落地时，我倾向于RAG为主，微调为辅：用RAG保证知识和溯源，用微调优化输出风格。
所以我会把RAG看成是模型的外挂知识引擎，而不是替代品。它的前提是知识库质量够高、检索够准，否则就是垃圾进垃圾出。