RAG 前沿现状入门说明

面向读者：刚了解 RAG，希望知道它现在发展到什么程度、工程上怎么用、哪些概念值得继续学。 时间范围：截至 2026-06-01。RAG 相关技术发展很快，模型、框架和 benchmark 会持续变化，但本文里的核心趋势相对稳定。

一句话结论

RAG 没有过时，但最朴素的 RAG 已经不是前沿了。

过去常见的 RAG 是：

用户问题 -> 向量检索 top-k 文档片段 -> 把片段塞进 prompt -> 大模型回答

现在更先进的 RAG 更像一个“带证据管理能力的问答系统”：

用户问题
-> 判断要不要检索
-> 改写/拆解问题
-> 多路检索
-> rerank
-> 证据筛选/压缩
-> 带引用生成
-> 校验答案是否被证据支持
-> 必要时继续检索或拒答

所以，RAG 的前沿已经从“向量库怎么查”扩展到了：

• 怎么切文档、怎么保留上下文
• 怎么同时用关键词、向量、结构化字段、权限过滤
• 怎么排序、筛选、压缩证据
• 怎么让模型自己判断是否需要继续查
• 怎么处理表格、图片、PDF、PPT
• 怎么评测答案是否真实、引用是否可靠
• 怎么避免知识库投毒、权限泄漏、间接 prompt injection

RAG 到底是什么

RAG 是 Retrieval-Augmented Generation，通常翻译为“检索增强生成”。

可以把它理解成：

先查资料，再让大模型基于查到的资料回答。

大模型本身有很多训练时学到的知识，但有几个天然问题：

• 它不知道训练之后发生的新事情。
• 它不知道公司内部文档、业务规则、私有数据库。
• 它可能凭记忆“猜”，也就是幻觉。
• 它无法天然给出可靠出处。

RAG 的核心做法是把外部知识库接到模型旁边。用户提问时，系统先从知识库里找相关材料，再把材料作为上下文交给模型，让模型基于材料回答。

最早的 RAG 论文来自 2020 年，核心思想是把语言模型的参数记忆和外部非参数记忆结合起来，用检索结果辅助生成。参考：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。

一个最小 RAG 系统长什么样

一个入门版 RAG 通常有两个阶段。

1. 离线建库

把资料提前处理好：

原始文档
-> 解析文本
-> 切成 chunk
-> 生成 embedding
-> 存入向量库

这里的 chunk 可以理解为小段文本。比如一篇 20 页的文档会被切成很多 300-800 token 的片段。

embedding 可以理解为“把文字变成向量坐标”。意思相近的文本，向量距离更近。

2. 在线问答

用户提问时：

用户问题
-> 问题转 embedding
-> 在向量库里找相似 chunk
-> 把 top-k chunk 放入 prompt
-> 大模型生成答案

这种方案容易搭起来，也确实有用。但它有很多问题：

• 找到的片段不一定真能回答问题。
• 相似不等于相关。
• embedding 对精确词、编号、代码、专有名词可能不敏感。
• chunk 被切开后，可能失去上下文。
• top-k 里可能混入无关信息，模型反而被干扰。
• 答案看起来很顺，但未必被证据支持。

所以现在的前沿方向，本质上是在补这些短板。

传统 RAG 的主要短板

短板 1：向量相似不等于答案相关

比如用户问：

TS-999 报错怎么处理？

向量检索可能找到很多“报错处理”的通用文档，却漏掉精确包含 TS-999 的片段。

这就是为什么现在很多生产系统仍然重视 BM25、关键词、倒排索引。向量检索适合理解语义，关键词检索适合抓精确匹配。

短板 2：chunk 会丢上下文

假设文档里有一句：

该产品在第二季度收入增长了 3%。

如果单独把这句话切出来，它不知道“该产品”是谁，也不知道是哪一年、哪份财报。

人读原文能靠上下文理解，检索系统却可能只看到这个孤立 chunk。结果就是：chunk 明明包含答案，但检索不到，或者检索到了也不好用。

短板 3：检索错了，模型也会认真胡说

RAG 很容易给人一种错觉：只要接了知识库，模型就不会幻觉。

实际不是。模型会受到检索结果影响。如果检索结果错了、旧了、被污染了，模型可能会基于错误材料生成很有信心的错误答案。

短板 4：多跳问题很难

简单问题：

报销上限是多少？

可能一个片段就能回答。

复杂问题：

如果我是上海员工，出差到北京三天，其中一天请假，住宿和餐补分别怎么算？

这可能需要同时查：

• 员工所在地规则
• 出差目的地规则
• 天数计算规则
• 请假扣减规则
• 住宿标准
• 餐补标准

朴素 top-k 检索不一定能一次性把所有证据找齐。

短板 5：评测很难

传统搜索可以看召回率、排序指标。传统问答可以看答案是否匹配。

RAG 还要看：

• 检索到的材料是否相关
• 答案是否完整
• 答案是否忠实于材料
• 引用是否真的支持对应句子
• 没有答案时是否会拒答
• 是否泄露用户没有权限看的资料

这比“回答对不对”复杂得多。

当前前沿方向 1：混合检索

现在比较稳妥的做法不是只用向量检索，而是混合检索。

常见组合：

向量检索 + BM25/关键词检索 + metadata 过滤 + 权限过滤 + rerank

为什么要混合

不同检索方式擅长不同事情：

一个工程上常见的流程是：

1. 向量检索取 top 100
2. BM25 检索取 top 100
3. 合并去重
4. 用 reranker 对候选片段重新排序
5. 取 top 5-20 给大模型

Anthropic 在 Contextual Retrieval 文章里也强调了 embedding + BM25 + reranking 的组合价值。参考：Introducing Contextual Retrieval。

当前前沿方向 2：Contextual Retrieval

Contextual Retrieval 可以理解为：

给每个 chunk 补一小段“它在原文里的上下文说明”，再拿去建索引。

例如原始 chunk 是：

收入比上一季度增长 3%。

补上下文后变成：

这段来自 ACME 公司 2023 年 Q2 财报，讨论云服务业务收入变化。收入比上一季度增长 3%。

这样 embedding 和 BM25 都更容易找到它。

它解决什么问题

主要解决 chunk 被切碎后丢上下文的问题。

适合：

• 长文档
• 财报
• 合同
• 技术文档
• 论文
• 有大量“本公司”“该产品”“上述方案”这类指代的文档

不适合盲目滥用，因为它会增加离线处理成本，也可能把错误上下文写进 chunk。

当前前沿方向 3：Reranking 和证据筛选

朴素 RAG 经常直接把 top-k 检索结果交给模型。但 top-k 的排序不一定可靠。

Reranker 的作用是：

对“用户问题 + 候选 chunk”重新打分，判断哪个 chunk 更能回答这个问题。

常见做法：

粗召回：向量/BM25 找 50-200 个候选
精排序：reranker 重排
最终上下文：取前 5-20 个

这像招聘：

• 粗召回是海选简历。
• reranker 是面试筛选。
• 最终上下文是进入终面的候选人。

为什么 reranking 很重要

因为检索阶段宁愿多召回一些，避免漏掉答案。但给模型的上下文不能太多，否则：

• 成本升高
• 延迟增加
• 模型注意力被干扰
• 可能出现“lost in the middle”，中间证据被忽略

所以先进 RAG 通常会做：

• 候选召回
• rerank
• 去重
• 证据覆盖度检查
• 上下文压缩

当前前沿方向 4：长上下文模型和 RAG 的结合

现在很多模型支持很长上下文。于是出现一个问题：

既然模型能读很多 token，还需要 RAG 吗？

简单答案：需要，但用法变了。

长上下文适合：

• 文档数量很少
• 需要整体阅读
• 用户愿意接受更高成本
• 问题需要跨大段上下文推理

RAG 适合：

• 文档库很大
• 问题只需要部分资料
• 对成本和延迟敏感
• 需要权限过滤、版本控制、引用追踪

研究里也有类似结论：资源足够时，长上下文模型在一些任务上可以超过传统 RAG，但 RAG 成本更低；混合路由是更实用的方向。参考：Retrieval Augmented Generation or Long-Context LLMs?。

实用判断

如果资料只有几十页，可以直接长上下文。

如果资料有几千、几万、几十万页，就必须检索。

更好的方式是：

小资料：直接长上下文
大资料：RAG
复杂问题：RAG 找材料 + 长上下文模型综合推理

当前前沿方向 5：Agentic RAG

Agentic RAG 可以理解为：

让模型不再只被动接收一次检索结果，而是能主动规划、检索、验证、继续查。

传统 RAG：

查一次 -> 回答

Agentic RAG：

理解问题
-> 判断缺什么信息
-> 拆成子问题
-> 分别检索
-> 生成临时答案
-> 检查证据是否足够
-> 不够就继续查
-> 最后回答

适合什么场景

Agentic RAG 适合复杂问题，例如：

• 多跳问答
• 法律/合规分析
• 财务分析
• 故障排查
• 跨多个系统查信息
• 需要调用数据库、搜索引擎、代码执行器的任务

例如金融文档问答中，问题可能同时涉及表格、脚注、不同年份财报，还要做数值计算。2026 年有论文提出 FinAgent-RAG，用迭代检索、程序化计算、自校验来做金融问答。参考：Agentic Retrieval-Augmented Generation for Financial Document Question Answering。

代价是什么

Agentic RAG 更聪明，但也更难控：

• 延迟更高
• 成本更高
• 调试更难
• 每一步都可能出错
• 如果记忆或工具被污染，错误会传播

所以它不是所有场景的默认选择。简单 FAQ、规则查询、客服知识库，通常先把普通混合 RAG 做好。

当前前沿方向 6：GraphRAG

GraphRAG 是把文档里的实体和关系抽取出来，形成知识图谱，再辅助问答。

普通 RAG 更像：

从一堆文本片段里找相似片段

GraphRAG 更像：

先把人物、组织、产品、事件、关系整理成图
再根据问题沿着图找证据

它解决什么问题

普通 RAG 擅长回答“某个具体问题的答案在哪段文本里”。

GraphRAG 更适合回答：

• 这批材料的主要主题是什么？
• 哪些实体关系最关键？
• 某事件的关联方有哪些？
• 多个文档之间有哪些共同模式？
• 某个问题在整个语料中呈现什么趋势？

Microsoft 的 GraphRAG 论文强调，传统 RAG 对“全局问题”不够好，比如“这批材料的主要主题是什么”。GraphRAG 会抽取实体关系、构建社区摘要，再用 global/local search 回答问题。参考：From Local to Global: A Graph RAG Approach。

什么时候不适合

GraphRAG 不是银弹。

不适合：

• 文档少
• 问题简单
• 关系不重要
• 只需要查某条规则
• 没有预算做离线抽取和维护

它适合“关系和全局结构很重要”的场景，不适合把所有 RAG 都强行改成图。

当前前沿方向 7：多模态 RAG

很多真实资料不是纯文本：

• PDF 扫描件
• 合同盖章页
• PPT
• 表格
• 图表
• 产品截图
• 说明书
• 医疗影像

传统做法是先 OCR 或解析成文本，再做文本 RAG。但这会丢掉：

• 布局
• 表格结构
• 图片信息
• 标题层级
• 图表含义
• 页眉页脚
• 视觉强调

多模态 RAG 的思路是：

不只检索文本，也检索图片、页面、表格、图表，甚至直接把 PDF 页当图像理解。

例如 VisRAG 提出直接用视觉语言模型把文档作为图像 embedding，不先强行解析成纯文本。论文报告在多模态文档上比传统文本 RAG 有 20-40% 端到端增益。参考：VisRAG。

ColPali 这类方法也很有代表性：它把文档页面作为图像来检索，用视觉模型保留布局和图表信息。参考：ColPali。

实用建议

如果你的资料主要是纯文本，先做文本 RAG。

如果你的资料大量包含表格、图表、扫描 PDF、PPT，单纯文本 RAG 往往不够，需要考虑：

• OCR + 结构化解析
• 表格单独抽取
• 图片 caption
• 页面级视觉检索
• 文本和视觉混合检索

当前前沿方向 8：RAG 评测

RAG 工程里最容易被低估的是评测。

没有评测，就很难知道系统有没有真的变好。

应该评什么

至少要评这些维度：

ARES、RAGBench、TREC RAG Track 都是围绕这些问题展开的评测工作。参考：

• ARES
• RAGBench
• TREC 2025 RAG Track

一个简单的内部评测集

如果你要在项目里做 RAG，建议至少准备一个小评测集：

问题
标准答案
应该命中的文档/段落
不应该使用的干扰文档
是否允许拒答

哪怕只有 50-200 条，也比完全凭感觉调参好很多。

当前前沿方向 9：RAG 安全

RAG 引入了新的攻击面，因为模型会相信检索出来的内容。

常见风险：

• 知识库被投毒
• 文档里藏 prompt injection
• 用户越权检索到不该看的资料
• 旧版本文档覆盖新版本
• 低质量资料污染答案
• 多租户向量库隔离不严

PoisonedRAG 研究显示，攻击者只要往知识库里注入少量恶意文本，就可能让 RAG 系统对特定问题输出攻击者想要的答案。参考：PoisonedRAG。

实用防护思路

工程上至少要做：

• 文档来源可信度管理
• 文档入库审核
• ACL 权限过滤前置
• 检索结果带来源、版本、时间
• prompt 中明确区分“系统指令”和“检索资料”
• 检索资料不得覆盖系统指令
• 对高风险答案做二次校验
• 记录检索 trace，方便追查

RAG 安全不是最后加一个 prompt 就能解决的，它需要从数据、索引、检索、生成、审计全链路处理。

一个比较现代的 RAG 架构

可以用下面这个结构理解现代 RAG：

                  离线阶段
原始资料
  -> 文档解析/OCR/表格抽取
  -> 清洗、去重、版本管理、权限标签
  -> chunking
  -> contextualization
  -> embedding
  -> BM25/倒排索引
  -> 向量库/搜索引擎/元数据存储

                  在线阶段
用户问题
  -> 意图判断/权限确认
  -> query rewrite / query decomposition
  -> hybrid retrieval
  -> rerank
  -> evidence selection / compression
  -> grounded generation
  -> citation / verification
  -> answer or refuse

如果问题复杂，可以在中间加入 agentic loop：

生成临时答案 -> 检查缺口 -> 继续检索 -> 再回答

不同技术怎么选

如果只是刚开始学 RAG，应该怎么学

建议按这个顺序：

第一步：理解最小闭环

先搞清楚：

• 文档怎么切 chunk
• embedding 是什么
• 向量库怎么查相似文本
• prompt 怎么带上下文
• 模型怎么基于上下文回答

能手写一个最小 RAG，就算入门。

第二步：理解检索质量

重点学：

• top-k
• recall
• precision
• embedding 模型选择
• chunk size
• chunk overlap
• metadata filter

这一步会发现：RAG 的核心不是“大模型回答”，而是“证据能不能找准”。

第三步：加入 BM25 和 reranker

入门项目经常只做向量检索，但实际项目通常需要混合检索。

可以重点理解：

• 为什么关键词检索仍然重要
• 为什么先粗召回再精排序
• reranker 为什么比单纯向量相似更准

第四步：做评测集

不要只靠肉眼试几个问题。

最简单也要有：

• 20 个简单问题
• 20 个复杂问题
• 20 个应该拒答的问题
• 20 个容易混淆的问题

然后每次调 chunk、top-k、rerank、prompt，都跑一遍对比。

第五步：再看 Agentic / Graph / Multimodal

这些是进阶方向，不建议一开始就全上。

先把普通 RAG 做稳，再根据需求加：

• 多跳问题多：考虑 Agentic RAG
• 全局归纳多：考虑 GraphRAG
• 图表 PDF 多：考虑多模态 RAG
• 长文档多：考虑 Contextual Retrieval 或长上下文

常见误解

误解 1：接了 RAG 就不会幻觉

不对。RAG 只是减少幻觉，不是消灭幻觉。

如果检索结果错了，模型仍然可能错。

误解 2：向量库越大越好

不对。数据质量、切分、权限、去重、版本管理都很重要。

低质量知识库会让 RAG 更差。

误解 3：top-k 越大越好

不一定。

top-k 太小会漏证据，top-k 太大又会引入噪声，增加成本，还可能让模型忽略中间内容。

误解 4：GraphRAG 比普通 RAG 高级，所以应该默认用

不对。

GraphRAG 适合关系型、全局型、综合分析型问题。简单知识库问答不一定需要。

误解 5：长上下文会淘汰 RAG

短期看不会。

长上下文让模型能读更多材料，但你仍然需要决定“哪些材料值得读”。这个选择过程就是 RAG 的价值。

一个入门者可以记住的判断框架

遇到 RAG 项目时，先问 7 个问题：

1. 用户问的问题是简单查找，还是复杂推理？
2. 答案通常来自一个片段，还是多个片段？
3. 文档是纯文本，还是包含表格、图片、PDF 版式？
4. 有没有精确编号、人名、术语、报错码？
5. 是否需要权限控制？
6. 是否需要引用出处？
7. 是否有评测集证明系统变好了？

这些问题比“用哪个向量库”更关键。

给初学者的推荐默认方案

如果你只是想做一个相对靠谱的 RAG，可以先用这个默认配置：

1. 文档清洗、去重、加来源和权限标签
2. 按标题/段落结构切 chunk，而不是盲目固定长度切
3. chunk 大小从 300-800 token 起步
4. 使用向量检索 + BM25 混合召回
5. 候选取 50-100，再用 reranker 取 5-10
6. prompt 要求模型只基于材料回答，不足则拒答
7. 答案带引用
8. 准备一组评测问题持续回归

如果这些都做好，通常已经超过很多“看起来很先进、实际不稳定”的 RAG 系统。

术语表

延伸阅读

• RAG 原始论文：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Anthropic Contextual Retrieval：Introducing Contextual Retrieval
• Microsoft GraphRAG：From Local to Global: A Graph RAG Approach
• Self-RAG：Learning to Retrieve, Generate, and Critique through Self-Reflection
• CRAG：Corrective Retrieval Augmented Generation
• RAG vs 长上下文：Retrieval Augmented Generation or Long-Context LLMs?
• 多模态 RAG 综述：Scaling Beyond Context
• VisRAG：Vision-based Retrieval-augmented Generation
• RAG 评测 ARES：ARES
• RAGBench：RAGBench
• TREC 2025 RAG Track：Overview of TREC 2025 RAG Track
• RAG 安全：PoisonedRAG

最后再压缩成一句话

RAG 的本质不是“把向量库接到大模型上”，而是“让大模型在回答前拿到正确、足够、可信、可追溯的证据，并且在证据不足时知道不要乱答”。