你以为的"加个向量数据库"≠真正的 RAG——2023 年这篇论文,把所有 RAG 团队第一次拉到了同一张白板前
- 关联论文：2312.10997
如果你做过大模型应用,大概率踩过这种坑——
公司里 5 个工程师都在做 RAG,但他们互相听不懂对方在说什么:
- 有人说"我用的是 Naive RAG,接 BM25"
- 有人说"我们做了 Advanced RAG,加了 reranker"
- 有人说"我搞了 Modular RAG,带 routing"
- 还有人在内部群里争"到底要不要做 GraphRAG"
争论到最后,所有人发现一件事:我们其实在用不同语言描述同一件事。
arXiv 2312.10997（Gao et al., RAG 综述, 2023 年 12 月发表,S2 引用 3,901 次, GitHub 持续维护 v5）做的事,就是给整个行业发了一本统一词典——把所有人用的术语、范式、模块,压成一张所有人都能对得上的图。
它给的不是某个新算法,而是两套坐标系:
「Naive / Advanced / Modular」三阶段范式 + 「Retrieval / Generation / Augmentation」三支柱矩阵
任何一个 RAG 团队,把这张图打印贴墙上,就能 5 分钟对齐"我们在做的事属于哪一档、用的是哪几个模块、还差什么"。
——这是 RAG 从"一堆 trick"变成"一门工程学科"的关键论文。
为什么这事值得每个人关心?
你用过的每一个"看起来懂你"的 AI 产品,几乎都是 RAG:
- 客服机器人能准确回答"我家订单怎么办退货"
- 法律 AI 能引用你给的合同具体条款
- 医疗 AI 能基于最新论文给你建议
- 代码助手能引用你公司内部的 SDK 文档
这些功能没有一个是"模型自己记住"的——它们都是 RAG:实时从外部知识库查,再让 LLM 组织答案。
但 RAG 是个看似简单实则复杂的事:
- 怎么切文档?按段落、按 token、按语义、按层级?
- 怎么检索?BM25、稠密向量、混合检索?
- 检索后怎么办?直接喂给 LLM?rerank 一下?压缩一下?
- 多跳推理怎么办?跨文档的关联谁负责?
- 长文档怎么办?上下文塞不下怎么办?
每个公司、每个团队、每个开源项目都有自己的实现,互相听不懂对方在说什么——直到这篇综述把这事变成了一门有结构的方法论。
一句话核心
RAG 不只是"LLM 套个向量数据库",而是一套有阶段、有模块、有评测的工程学科——Naive → Advanced → Modular 三阶段 + Retrieval / Generation / Augmentation 三支柱,让全行业第一次用同一张图说话。
三个关键洞察
1. 三阶段范式:RAG 不是"做不做",而是"做到哪一档"
论文把 RAG 切成三个阶段,这三个阶段不是替代关系、是叠加关系:
┌─────────────────────────────────────────────────────────┐
│ Naive RAG Advanced RAG Modular RAG │
│ ────────── ──────────── ─────────── │
│ Indexing → Pre-Retrieval → 多种模块组合 │
│ Retrieval Retrieval (Rerank, Fusion, │
│ Generation Post-Retrieval Memory, Routing) │
│ Generation │
└─────────────────────────────────────────────────────────┘
- Naive RAG(2020 起):Indexing → Retrieval → Generation 三步走。最朴素版本,没有 query 改写、没有 rerank、没有 hybrid search。
- Advanced RAG(2023 上半年):在 Naive 前后加"零件"——Pre-Retrieval 加 query 改写、HyDE;Retrieval 加 BM25+dense hybrid;Post-Retrieval 加 rerank、context 压缩。
- Modular RAG(2023 下半年起):把 Advanced RAG 拆成可替换模块,允许非线性关系——Routing 模块决定"这个 query 走 RAG、还是走工具、还是直接答";Memory 模块把多轮对话当 retrieve 对象。
论文关键论点:绝大多数"我做了 RAG 没用"的团队,都是 Naive 阶段。从 Naive 到 Advanced,通常 1 周工作量就能拿到显著收益——这远比你换一个更强的 embedding 模型更划算。
2. 三支柱矩阵:你的 RAG 系统可以画成一张填表图
论文把 RAG 拆成三个支柱,每个支柱下列出 2023 年的所有主流选项:
| 支柱 | 关键维度 | 2023 SOTA 选项 |
|---|---|---|
| Retrieval | 数据源 / 切分粒度 / Embedding / 索引 / 检索范式 | BM25、Contriever、E5、BGE、ColBERT / FAISS、HNSW、Milvus / single-hop、multi-hop、tree-like |
| Generation | LLM 选型 / 上下文管理 / 输出控制 | 开源 vs 闭源 / Lost-in-the-Middle、context 压缩 / fact-grounding、citation-aware |
| Augmentation | 检索前 / 检索后 / 训练时 | query 改写、HyDE、step-back / rerank、compression / retriever+generator 联合训练 |
这张表的真正力量:你不需要从零设计"我的 RAG 系统长啥样",你只要对着三个轴填具体方案——这就是你和同事、技术评审、产品经理沟通的语言。
3. Routing 模块:RAG 进化成 AI Agent 的桥
论文里最被低估的一个模块是 Routing:
- 简单 query → 直接让 LLM 答(不查文档)
- 事实性 query → 走 RAG
- 多步 query → 走工具调用
- 数据库 query → 走 SQL
Routing 让 RAG 从"每次都查"变成"按需查"——这是 RAG 演化成 Agent 的关键拐点。
论文里没明说但社区共识是:Self-RAG、FLARE、GraphRAG、Agentic RAG 都可以理解为"带特殊 routing 策略的 Modular RAG"——也就是说,今天所有热门的 RAG 进阶方向,本质都是 Modular RAG 的不同 routing 哲学。
关键实验与数据
论文系统梳理了 2023 年的 RAG 评测,分为三类:
1. 下游任务质量
| Benchmark | 任务 | 评估指标 |
|---|---|---|
| TriviaQA / NaturalQuestions | 开放域 QA | EM / F1 |
| HotpotQA / MultiHop | 多跳 QA | Answer F1 / Support F1 |
| FEVER | 事实核查 | Accuracy |
2. 检索质量(标准 IR)
- Recall@k / MRR / NDCG——可以直接对比你的 retriever 好不好
3. RAG-specific(论文配套提出)
- RGB:把评测拆为「噪声鲁棒性 / 负面拒答 / 信息集成 / 反事实鲁棒性」四轴
- RECKE:检索增强的事实核查专项
- ARES:LLM-as-judge 自动评估 RAG 三组件
- RAGAS:开源自动化评测框架——faithfulness / answer_relevance / context_relevance 三指标
⚠️ 数字守约: - 论文表格里的具体 SOTA 数字需要回查原文 Table 2-5 - 「3700+ 引用」为摘要口径,S2 实时被引以 3,901 为准(2026-08-21 抓取) - 各 RAG 方法在 RAGAS / RGB / ARES 上的具体得分本解读未逐项核对
落地前的硬约束(2026 年视角)
- Pre-Retrieval + Post-Retrieval 是最高 ROI 的优化带——绝大多数 Naive RAG 失败不是 embedding 模型差,是query 没改写、rerank 没加、context 没压缩。从这两个口进去改 1 周,比换 embedding 模型收益大 10 倍。
- Modular ≠ "啥都加"——每加一个模块都带来维护成本、延迟、failure mode。Routing 决策错了会引发"该查的不查、不该查的乱查"。从 Advanced 起步,等真的撞到 Advanced 解决不了的场景再升级到 Modular。
- RAG vs Long Context 是伪二选一——RAG 提供精确、可追溯的知识;长上下文提供整体阅读感。最佳系统两者结合(GraphRAG、Self-RAG、FLARE 都属于这条路线)。
- chunk_size 是隐性成本大头——chunk 太大 → token 暴涨、Lost-in-the-Middle;chunk 太小 → multi-hop 推理断裂。512 tokens + 50 overlap 是大多数 QA 场景的起点,按 recall@5 调优。
- Hybrid Search 的 α 权重是玄学——BM25+dense 线性组合,α 全靠人工调。用 RAGAS answer_relevance 搭 grid search,α 从 0.1 到 0.9 跑一遍选最优。
- Embedding 模型升级 = 重建向量库——向量漂移让旧向量与新向量不在同一语义空间。模型升级必须重建索引(或用「新向量追加、旧向量静默」策略)。
- 评测必须独立于产品——RAGAS、ARES 这类工具让你不用靠肉眼就能对比两版 prompt / 两版 chunk size。生产团队应该把评测当成 CI 的一环。
一段给普通人的话
RAG 综述 (2312.10997) 是那种"你不读它,也能做 RAG;但你读了它,能少走 6 个月弯路"的工作。
它没提出什么新算法、没刷新什么 SOTA、没开源什么新框架——它做的是更难的事:把整个行业的混乱术语,变成一门所有人能对得上的工程学科。
读完这篇,你再听别人说"我做了 RAG",你的第一个问题应该是:
"你们做到哪一档?Naive / Advanced / Modular?用了哪些模块?Pre-Retrieval 做了没?Post-Retrieval 做了没?评测用 RAGAS 还是 ARES?"
——如果对方答不上来,大概率就是 Naive 阶段,生产时遇到 hallucination 也不要奇怪。
📌 论文 ID:2312.10997
📂 持续维护版本:论文 v5(2024-03-27 更新),GitHub awesome-rag 列表同步追踪新工作
三个标题变体
- 你以为的"加个向量数据库"≠真正的 RAG——2023 年这篇综述,把全行业的术语第一次拉通
- 5 个工程师做 5 种 RAG,互相听不懂——这篇被引 3901 次的论文,给了所有人一张白板
- RAG 不是 LLM + 向量库——Naive / Advanced / Modular 三阶段,你的系统在第几档?
小红书风格卡片文案(可直接发布)
🤖 你以为的"加个向量数据库",根本不是真正的 RAG 🤖
如果你做过大模型应用,你一定见过这种场景:
公司里 5 个工程师都在做 RAG——但他们互相听不懂对方在说什么 🤯
- 有人说"我用的是 Naive RAG,接 BM25"
- 有人说"我们做了 Advanced RAG,加了 reranker"
- 有人说"我搞了 Modular RAG,带 routing"
- 还有人在群里争"到底要不要做 GraphRAG"
争论到最后,所有人发现——我们其实在用不同语言描述同一件事。
arXiv 2312.10997(Gao et al., 2023 年 12 月,S2 引用 3,901 次, GitHub 维护 v5)给整个行业发了一本统一词典 📖
它做的事不是发明新算法,而是两套坐标系:
「Naive / Advanced / Modular」三阶段范式 + 「Retrieval / Generation / Augmentation」三支柱矩阵
任何 RAG 团队拿这张图打印贴墙上,就能 5 分钟对齐—— ✅ 我们做的事属于哪一档? ✅ 用的是哪几个模块? ✅ Pre-Retrieval 做了没? ✅ Post-Retrieval 做了没? ✅ 评测用 RAGAS 还是 ARES?
——这就是 RAG 从"一堆 trick"变成"一门工程学科"的关键拐点。
🎯 一句话核心
RAG 不只是"LLM 套个向量数据库",而是一套有阶段、有模块、有评测的工程学科——绝大多数"我做了 RAG 没用"的团队,都是 Naive 阶段,从 Naive 到 Advanced,1 周工作量就能拿到显著收益,远比你换 embedding 模型更划算。
⚠️ 2026 年视角的硬约束: - Pre-Retrieval + Post-Retrieval 是最高 ROI 优化带 - 从 Advanced 起步,等真撞到瓶颈再升级 Modular - RAG vs Long Context 是伪二选一——最佳系统两者结合 - chunk_size 512 tokens + 50 overlap 是大多数 QA 场景的起点 - Embedding 模型升级 = 重建向量库(向量漂移无法避免) - 评测必须独立于产品——把 RAGAS / ARES 当 CI 的一环
📎 论文 ID:2312.10997 💬 你们团队的 RAG 系统在 Naive / Advanced / Modular 哪一档?Pre-Retrieval 做了什么?