# RAG 技术演进

> 检索增强生成（Retrieval-Augmented Generation）——让 AI 在有限上下文内"记住"无限知识。

## 核心论文时间线

| 时间 | 里程碑 | 说明 |
|------|--------|------|
| 2017.03 | FAISS 发布 | Facebook AI 相似度搜索库，向量检索的基础设施 |
| 2019 | Wizard of Wikipedia | 通过检索 Wikipedia 句子提升事实准确性 |
| 2020.02 | REALM 论文 | Google，检索增强语言模型预训练，可微分检索器 |
| 2020.05 | **RAG 论文**（Facebook/Meta AI） | Lewis 等，arXiv:2005.11401，组合 DPR + BART，奠定 RAG 范式 |
| 2020 | Dense Passage Retrieval（DPR） | 双 BERT 编码器，比 BM25 提升 9-19 个百分点 |

## 从 Naive RAG 到 Advanced RAG

### Naive RAG（2022-2023）

最简单的线性管道：

```
文档 → 分块(Chunk) → 向量化(Embed) → 存入向量数据库
                                          ↓
用户提问 → 向量化 → 相似度搜索 → 取 Top-K → 拼入 Prompt → LLM 生成
```

**问题**：检索质量不稳定、缺乏自我纠错、无法处理复杂查询。

### Advanced RAG（2023-2024）

| 时间 | 方法 | 论文/项目 | 改进点 |
|------|------|-----------|--------|
| 2023.10 | **Self-RAG** | arXiv:2310.11511 | LLM 学会自主决定是否检索、检索什么，通过反射 token 自我评估 |
| 2024.01 | **Corrective RAG (CRAG)** | arXiv:2401.15884 | 增加评估器判断检索结果相关性，不相关则触发 Web 搜索补充 |
| 2024.07 | **GraphRAG** | Microsoft 开源 | 用 LLM 从文档中提取知识图谱，支持全局摘要查询，GitHub 10K+ stars |

### Agentic RAG（2024-2025）

RAG 不再是固定管道，而是由 Agent 动态编排：

```
用户提问
  ↓
Agent 路由器（判断是否需要检索、从哪里检索）
  ↓
┌────────────┬────────────┬────────────┐
│ 向量数据库  │ 知识图谱    │ Web 搜索    │
└────────────┴────────────┴────────────┘
  ↓
Agent 评估器（结果够不够好？需不需要再查？）
  ↓
LLM 生成 → Agent 自检 → 输出
```

## 向量数据库生态

| 数据库 | 创建时间 | 类型 | 特点 |
|--------|----------|------|------|
| FAISS | 2017.03 | 库（非数据库） | Facebook 出品，高性能相似度搜索，行业基石 |
| Weaviate | 2018 末 | 开源数据库 | 最早的专用向量搜索数据库之一 |
| Milvus | 2019 | 开源数据库 | 专为向量构建，分布式架构 |
| Pinecone | 2019（成立） | 云托管 | 全托管服务，开箱即用 |
| pgvector | 2021.04 | PostgreSQL 扩展 | 给现有 Postgres 加向量能力，低迁移成本 |
| Qdrant | 2021 | 开源数据库 | Rust 编写，高性能 |
| Chroma | 2022.10 | 开源数据库 | 2023.04 获 $18M 种子轮，开发体验好 |

### 生态变化趋势

```
2017-2020：只有 FAISS 一个选择
2021-2022：pgvector、Qdrant、Chroma 涌现
2023：     向量数据库"百花齐放"，每个 LLM 项目标配
2024-2025：整合期——pgvector 因为"不用换数据库"逆袭；
           专用数据库开始差异化（图+向量、多模态、混合搜索）
```

## RAG vs 长上下文：替代还是互补？

| 维度 | 长上下文 | RAG |
|------|---------|-----|
| 适用数据量 | < 1M tokens | 无上限 |
| 延迟 | 上下文越长越慢 | 检索本身很快 |
| 成本 | 全量计费 | 只检索相关片段 |
| 准确性 | 全局理解好 | 可能漏检 |
| 实时性 | 需要重新装入 | 新增数据即时可搜 |

**结论**：不是替代关系。1M 上下文适合"需要全局理解的文档"，RAG 适合"海量知识库的精准检索"。实际应用中两者经常组合使用。