先搞清楚：没有RAG的Agent会怎样？
Agent只靠大模型回答 → 大模型不知道你的业务知识 → 开始编。这就是幻觉。
你问："我们公司的退货政策是什么？" → Agent不知道 → 编一个"7天无理由退货"。但如果你们公司是15天呢？
RAG解决的就是这个问题。把知识库给Agent，让它先查资料再回答。
用户："退货政策是什么？"
↓
┌─────────────────┐
│ 1. 检索(Retrieve)│→ 在知识库中搜"退货政策"
│ 找到相关文档 │ 找到《退换货政策.pdf》
└────────┬────────┘
↓
┌─────────────────┐
│ 2. 增强(Augment) │→ 把文档内容 + 用户问题
│ 拼成Prompt │ 一起喂给大模型
└────────┬────────┘
↓
┌─────────────────┐
│ 3. 生成(Generate)│→ 大模型基于真实文档回答
│ 精准答案 │ "根据公司政策，退货期为15天"
└─────────────────┘
RAG核心三件套
1. 📄 文档切分（Chunking）
知识库文档不能整本塞给AI（太长），要切成小块。每块通常300-500字。
原文档："公司退货政策...（5000字）"
切分后：
块1："退货条件：未拆封、7天内..."（350字）
块2："退款流程：提交申请→审核→原路退回..."（400字）
块3："特殊商品：食品、内衣不可退换..."（300字）
2. 🔢 向量化（Embedding）
把每个文本块转成一串数字（向量），语义相近的文本向量也相近。
- "退货政策" 和 "退换流程" 的向量距离很近
- "退货政策" 和 "公司团建" 的向量距离很远
常用Embedding模型：OpenAI text-embedding-3-small / 通义千问embedding / BGE（开源）
3. 🔍 检索（Retrieval）
用户问题也转成向量 → 在知识库中找距离最近的文本块 → 拼成Prompt给大模型。
Coze/Dify上怎么配RAG？
Coze 方式（零代码）
- 创建Bot → Knowledge 标签 → Create Knowledge
- 上传文档（PDF/Word/TXT/Markdown/网页链接）
- Coze自动切分+向量化
- 在Bot设置中启用知识库
- 测试：问一个只有你文档里有的问题
Dify 方式（更灵活）
- 知识库 → 创建知识库 → 上传文档
- 选择分段方式（自动/自定义）和Embedding模型
- 创建应用 → 关联知识库
- 在Prompt中用
{{knowledge}} 变量引用检索结果
RAG进阶技巧
| 技巧 | 作用 |
|---|
| 混合检索 | 向量检索 + 关键词检索结合，召回率更高 |
| 重排序（Re-rank） | 检索后对结果二次排序，更精准 |
| 元数据过滤 | 按时间/类型/来源过滤（如"只要2026年的政策"） |
| 父子文档 | 检索小块，但返回大块上下文，信息更完整 |
| 多轮改写 | 把"那个怎么退"→"商品退货流程"，提高检索精度 |
常见RAG翻车现场
- 文档质量差：塞了一堆过时的、自相矛盾的文档。RAG输入的是垃圾，输出的也是垃圾。
- 切分不当：把一段完整内容切断了，检索出来的片段不完整。
- Embedding选错：中文文档用了英文优化的Embedding模型，检索精度下降。
- 不更新：知识库三个月没更新，Agent在用过时信息回答问题。
RAG的质量取决于两个东西：文档质量和检索精度。花80%精力在这上面，比调模型参数有用100倍。