3.7 KiB
3.7 KiB
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 适合"海量知识库的精准检索"。实际应用中两者经常组合使用。