![配图待生成]
一句话总结
RAG = 先检索，再生成。让AI基于真实文档回答，而不是凭空想象。
RAG是Context Engineering的核心技术，解决了AI的三大痛点：知识过时、私有数据、幻觉编造。
为什么需要RAG？
大语言模型有三个致命弱点：
1. 知识截止日期
- GPT-4的知识截止到2024年4月
- 它不知道2024年4月之后发生的事
2. 不知道你的私有数据
- 它没看过你公司的文档
- 它不知道你的个人笔记
- 它不了解你的项目代码
3. 会”幻觉”编造
- 当它不知道答案时，会一本正经地胡说八道
- 听起来很专业，但可能是错的
RAG就是解决方案： 先从你的知识库检索相关文档，再让AI基于这些文档回答。
RAG的完整流程
`
用户问题
↓
[1. 查询改写] 优化问题，提高检索质量
↓
[2. 文档检索] 从知识库找到相关文档
↓
[3. 重排序] 对检索结果重新排序
↓
[4. 上下文注入] 将文档注入到prompt中
↓
[5. 生成回答] AI基于文档生成回答
↓
[6. 来源标注] 标注回答来自哪些文档
`
第一步：文档分块（Chunking）
为什么要分块？
- 文档太长，塞不进上下文窗口
- 需要找到最相关的片段，而不是整个文档
分块策略
| 策略 | 优点 | 缺点 | 适用场景 |
|---|
|——|——|——|———-|
| 固定大小 | 简单快速 | 可能切断语义 | 结构化文档 |
|---|---|---|---|
| 按段落 | 保持语义完整 | 大小不均匀 | 文章、报告 |
| 按语义 | 最准确 | 实现复杂 | 重要文档 |
| 递归分块 | 兼顾效率和质量 | 需要调参 | 通用场景 |
最佳实践
- 保持上下文完整性：不要在句子中间切断
- 添加重叠：相邻chunk之间有重叠，避免信息丢失
- 合适的大小：通常500-1000 tokens，太小丢失上下文，太大不精确
- 添加元数据：每个chunk带上来源、标题、位置信息
第二步：向量化（Embedding）
是什么？
将文本转换为向量（一组数字），方便计算相似度。
为什么需要？
- 计算机不懂文字，只懂数字
- 向量可以计算”距离”，距离近 = 语义相似
常用Embedding模型
| 模型 | 维度 | 特点 |
|---|
|——|——|——|
| OpenAI text-embedding-3-small | 1536 | 快速，性价比高 |
|---|---|---|
| OpenAI text-embedding-3-large | 3072 | 更准确 |
| BGE-M3 | 1024 | 开源，多语言 |
| Jina Embeddings v3 | 1024 | 开源，长文本 |
最佳实践
- 选择合适的模型：根据语言、领域、预算选择
- 批量处理：一次处理多个文档，提高效率
- 缓存向量：相同文档只计算一次向量
- 归一化：向量归一化后，余弦相似度更准确
第三步：检索（Retrieval）
两种检索方式
1. 向量检索（Semantic Search）
- 计算问题向量与文档向量的相似度
- 优点：理解语义，”AI”能匹配”人工智能”
- 缺点：可能错过关键词精确匹配
2. 关键词检索（BM25等）
- 基于关键词匹配
- 优点：精确，快速
- 缺点：不理解语义，”AI”匹配不了”人工智能”
3. 混合检索（Hybrid Search）
- 结合向量检索和关键词检索
- 优点：兼顾语义和精确
- 缺点：需要调权重
最佳实践
- 混合检索：向量 + BM25，取长补短
- 多路召回：不同检索策略返回不同结果，合并去重
- 过滤条件：按时间、来源、类型过滤
- Top-K选择：通常检索top-20，再精排取top-5
第四步：重排序（Reranking）
为什么需要重排序？
- 初步检索可能不够准确
- 需要用更精细的模型重新排序
工作流程
`
初步检索（top-20）
↓
重排序模型（Cross-Encoder）
↓
精排结果（top-5）
`
常用重排序模型
| 模型 | 特点 |
|---|
|——|——|
| Cohere Rerank | 商业API，效果好 |
|---|---|
| BGE-Reranker | 开源，中文效果好 |
| Cross-Encoder | 开源，通用 |
最佳实践
- 先粗后精：先用向量检索top-20，再用重排序取top-5
- Token感知：根据剩余token预算决定取几个结果
- 多样性：确保结果不重复，覆盖不同角度
第五步：上下文注入
是什么？
将检索到的文档片段注入到prompt中，让AI”看到”这些知识。
注入格式
格式1：简单拼接
`
根据以下文档回答问题：
文档1：…
文档2：…
问题：…
`
格式2：结构化注入
`
文档1内容…
文档2内容…
基于以上上下文，回答：…
`
格式3：带元数据注入
`json
{
“retrieved_docs”: [
{“content”: “…”, “source”: “…”, “relevance”: 0.95},
{“content”: “…”, “source”: “…”, “relevance”: 0.87}
],
“question”: “…”
}
`
最佳实践
- 标注来源：让AI知道信息来自哪里
- 标注时间：新信息优先于旧信息
- 标注可信度：帮助AI判断信息质量
- 控制数量：不要注入太多，通常3-5个文档足够
第六步：生成回答
AI如何使用RAG结果？
- 理解上下文：AI阅读注入的文档
- 提取信息：从文档中找到答案
- 生成回答：基于文档生成自然语言
- 标注来源：告诉用户答案来自哪里
关键指令
`
请基于提供的文档回答问题。
- 只使用文档中的信息
- 如果文档中没有相关信息，明确说明
- 标注答案来自哪个文档
- 不要编造文档中没有的信息
`
RAG的常见问题和解决方案
问题1：检索不到相关文档
原因： 查询和文档的表述不同
解决： 查询改写（Query Rewriting）
`python
# 原始查询
“退货政策”
# 改写后的查询
“退货政策 退款 退货流程 退货条件 退货期限”
`
问题2：检索到但不相关
原因： 向量相似度高但语义不相关
解决： 重排序（Reranking）
问题3：相关文档太多，超出token限制
原因： 知识库太大
解决： Token感知检索，动态调整数量
问题4：AI不使用RAG结果
原因： 指令不明确
解决： 在prompt中明确要求”只使用文档中的信息”
🚇 地铁深读：RAG vs 长上下文
随着上下文窗口越来越大（GPT-4: 128K, Claude 3: 200K, Gemini: 1M），一个问题出现了：
还需要RAG吗？把整个文档塞进上下文不行吗？
长上下文的局限
- 成本高：1M tokens ≈ $15，每次调用都塞满太贵
- 速度慢：tokens越多，推理越慢
- 注意力稀释：研究表明，模型对中间位置的信息关注度降低（”Lost in the Middle”问题）
- 精确度下降：信息太多，模型可能找不到关键信息
RAG的优势
- 成本低：只检索相关片段，token少
- 速度快：处理的信息少
- 精确度高：只给最相关的信息
- 可扩展：知识库可以无限大
最佳实践：RAG + 长上下文
`
短文档（< 4K tokens）→ 直接塞进上下文
长文档（> 4K tokens）→ RAG检索相关片段
超长文档（> 100K tokens）→ 必须RAG
`
今日小结
| 步骤 | 作用 | 关键技术 |
|---|
|——|——|———-|
| 分块 | 切分文档 | 语义分块、重叠、元数据 |
|---|---|---|
| 向量化 | 文本→向量 | Embedding模型 |
| 检索 | 找相关文档 | 向量检索、BM25、混合检索 |
| 重排序 | 精排结果 | Cross-Encoder |
| 注入 | 塞进prompt | 结构化格式、来源标注 |
| 生成 | 基于文档回答 | 指令约束、来源标注 |
一句话记住： RAG = 先找再答，让AI基于真实文档说话，而不是凭空想象。
下期预告
AI PRO·Context Day 4 记忆管理：让AI拥有长期记忆
我们将深入解析AI的记忆系统：短期记忆、长期记忆、记忆分层、衰减机制，看看如何让AI”记住”重要的事情。
*攀岩者 | 技术总监 | 19年IT全栈实战*
*每天分享AI学习笔记，陪你从零基础到AI达人*
发表回复