RAG：检索增强生成
RAG（Retrieval-Augmented Generation，检索增强生成）先从外部知识库检索相关信息，再结合这些信息一起生成回答，从而提升模型的准确性和知识时效性。
RAG 解决的核心问题
大模型的固有局限
| 问题 | 影响 | RAG 的解决方案 |
|---|---|---|
| 知识截止 | 模型不知道训练数据之后发生的事 | 实时检索最新信息 |
| 幻觉 | 模型可能编造不存在的事实 | 回答基于真实检索到的资料 |
| 专业知识 | 通用模型缺乏细分领域深度知识 | 接入专业领域知识库 |
| 数据隐私 | 不能把机密数据用于模型训练 | 检索私有化数据，不暴露给第三方 |
| 可追溯性 | 无法验证回答的信息来源 | 每个回答都可以溯源到引用文档 |
RAG vs 微调 vs 提示词
知识时效性强 → RAG
行为模式调整 → 微调
简单任务引导 → 提示词
三者通常结合使用：用提示词引 导输出格式，用 RAG 提供知识，用微调统一回答风格。
RAG 核心原理与架构
经典 RAG 工作流
用户提问
↓
[检索阶段]
↓ 查询改写
↓ 向量化
↓ 相似度搜索
↓ 结果重排序
↓ 上下文组装
[生成阶段]
↓ LLM 结合上下文回答
↓
最终回答
完整架构详解
1. 文档处理流水线（离线）
原始文档
↓
文档加载 → 支持 PDF、Word、网页、代码等
↓
文档切分 → 按语义或固定大小分块
↓
向量化 → 用 Embedding 模型转为向量
↓
存储 → 存入向量数据库
关键参数：分块大小
| 分块大小 | 适用场景 | 优缺点 |
|---|---|---|
| 256 tokens | 问答、事实检索 | 精度高，召回率可能低 |
| 512 tokens | 通用场景 | 平衡各指标 |
| 1024+ tokens | 长文档理解 | 上下文完整，但噪声也多 |
2. 查询处理（在线）
用户查询
↓
查询改写 → 优化表述，补充意图
↓
向量化 → 用相同的 Embedding 模型
↓
检索 → 从向量库返回 Top-K 结果
↓
重排序 → 用交叉编码器精确排序
查询改写的常用策略：
- 问题分解：将复杂问题拆分为多个子问题
- 假设生成：生成可能的答案形式辅助检索
- 多视角：从不同角度改写同一个问题
3. 回答生成
系统提示词 + 检索到的文档 + 用户问题
↓
LLM 生成回答
↓
引用标注 → 标明信息来源
↓
后处理 → 格式校验、安 全检查
上下文组装模板：
请根据以下参考信息回答用户的问题。
如果参考信息中没有相关内容，请诚实说明你不知道。
【参考信息】
{{% for doc in documents %}}
来源 {{% loop.index %}}：{{% doc.content %}}
{{% endfor %}}
【用户问题】
{{% question %}}
【回答要求】
- 基于参考信息，不要编造内容
- 在关键信息后面标注来源编号
- ...
RAG 的本质：补充知识，不改变能力
RAG 最初被提出是为了缓解大模型的幻觉问题——让模型在回答时基于真实检索到的资料，而不是凭"记忆"编造。这个动机决定了一个关键事实：RAG 解决的是"知识"问题，不是"能力"问题。
| RAG 能解决的 | RAG 解决不了的 |
|---|---|
| 训练时未见过的私有知识 | 模型的推理 / 智力水平（参数没动） |
| 时效性强的最新信息 | 训练阶段就掌握的核心能力 |
| 需要溯源的事实型问题 | 私有知识之外的世界知识 |
| 与微调有部分重叠的知识注入场景 | 需要让模型"更聪明"的任务 |
RAG 没有改变模型根本能力，没有使模型变得更聪明，所以它能起到的作用也是有限的。想真正提升模型能力，最终还是要动参数（Fine-tune）或者直接用更强的基座。
但即便如此，RAG 相对微调仍然是更轻量的方案——成本低、迭代快（小时级 vs 月级）、永不过期（不依赖基座版本）。这也是为什么 RAG 在"注入私有知识"场景里几乎成了事实标准。
RAG 质量评估与优化
关键评估指标
| 指标 | 说明 | 测量方式 |
|---|---|---|
| 检索准确率 | 检索到的文档是否真的相关 | 人工标注 Top-K 结果的相关性 |
| 答案忠实度 | 回答是否忠实于检索到的文档 | 检查回答与文档的一致性 |
| 答案完整度 | 是否完整回答了用户问题 | 评估回答的全面性 |
| 引用准确率 | 来源标注是否正确 | 验证每条引用确实支持对应的内容 |
常见问题与优化方案
问题 1：检索不到相关内容（召回率低）
可能原因：
- 分块策略不合理，语义被切断
- Embedding 模型不匹配领域
- 查询与文档表述差异大
优化方案：
✅ 优化分块策略（重叠分块、语义分块）
✅ 适配领域的 Embedding 模型
✅ 引入查询改写和 HyDE
✅ 混合检索（向量 + 关键词）
问题 2：检索结果太多噪声
可能原因：
- Top-K 值设得太大
- 相似度阈值太低
- 文档本身质量不高
优化方案：
✅ 增加重排序（Rerank）步骤
✅ 调整相似度阈值
✅ 文档预处理和质量过滤
✅ 元数据过滤（按时间、来源等）
问题 3：回答幻觉，不忠实于原文
可能原因：
- 模型太强的先验知识
- 提示词约束不够
- 相关文档排名靠后
优化方案：
✅ 强化提示词的约束力度
✅ 加入引用验证步骤
✅ 降低模型温度（temperature）
✅ 后处理校验回答与文档的一致性
进阶 RAG 技术
1. 高级检索策略
父子分块（Parent-Child Chunking）
大文档 → 拆分为大的"父块"
每个父块 → 拆分为小的"子块"
检索时：用子块做精确匹配
返回时：返回对应的完整父块
优势：既有精确检索，又有完整上下文。
混合检索（Hybrid Search）
向量检索 + 关键词检索
↓ 加权融合
最终排序结果
适用场景：
- 需要精确匹配术语或代码
- 专有名词多的专业领域
多轮查询改写
第一轮：原始查询 → 初步检索
第二轮：基于初步结果，LLM 优化查询 → 再次检索
第三轮：...
2. 高级 RAG 架构
Self-RAG（自我评估 RAG）
模型自己判断：
- 什么时候需要检索？
- 检索到的内容有用吗？
- 需要继续检索还是直接回答？
Graph RAG（知识图谱增强）
文档 → 提取实体与关系 → 构建知识图谱
查询 → 图谱推理 → 增强检索结果
Agentic RAG（Agent 化的 RAG）
把检索作为 Agent 的工具之一：
- Agent 决定要不要检索
- Agent 决定用什么关键词检索
- Agent 决定要不要多次检索
3. 生产级 RAG 的工程实践
缓存策略
热门问题缓存 → 直接返回答案
相似问题缓存 → 缓存检索结果
Embedding 缓存 → 避免重复计算
监控与可观测性
- 记录每次检索的查询和结果
- 记录回答质量的用户反馈
- 监控检索延迟和准确率
- 定期采样人工审核
成本控制
Embedding 成本 → 批量处理、缓存
LLM 调用成本 → 选择合适的模型、缓存
向量存储成本 → 索引优化、冷热分层
RAG 的未来发展方向
1. 端到端优化
从"检索 + 生成"的两阶段，走向端到端训练的统一架构。
2. 主动学习
RAG 系统能自动发现知识缺口，主动向知识库补充内容。
3. 多模态 RAG
不仅支持文本，还支持图片、表格、音频、视频等多种模态的检索和理解。
4. 记忆化 RAG
结合长期记忆，记住用户之前问过什么，避免重复检索和回答。
RAG 不只是"外挂知识库"那么简单，它是让大模型连接真实世界的桥梁，是 Agent 获取外部信息的核心机制。