Lijie 的技术博客

Rag_Frontier_Intro

RAG 前沿现状入门说明

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

一句话结论

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

过去常见的 RAG 是：

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

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

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

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

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
-> 大模型生成答案

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

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

传统 RAG 的主要短板

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

比如用户问：

TS-999 报错怎么处理？

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

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

短板 2：chunk 会丢上下文

假设文档里有一句：

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

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

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

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

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

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

短板 4：多跳问题很难

简单问题：

报销上限是多少？

可能一个片段就能回答。

复杂问题：

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

这可能需要同时查：

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

短板 5：评测很难

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

RAG 还要看：

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

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

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

常见组合：

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

为什么要混合

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

| 方法 | 擅长 | 不擅长 | |---|---|---| | 向量检索 | 语义相似、同义表达 | 精确编号、代码、罕见术语 | | BM25/关键词 | 精确词、型号、报错码、人名 | 问法变化大时可能漏召回 | | metadata 过滤 | 时间、部门、文档类型、权限 | 本身不理解语义 | | reranker | 精排相关性 | 增加延迟和成本 |

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

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 个

这像招聘：

为什么 reranking 很重要

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

所以先进 RAG 通常会做：

当前前沿方向 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

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

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

多模态 RAG 的思路是：

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

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

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

实用建议

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

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

当前前沿方向 8：RAG 评测

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

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

应该评什么

至少要评这些维度：

| 维度 | 问题 | |---|---| | 检索召回 | 答案所需证据有没有被找出来 | | 检索精度 | 找出来的材料是不是相关 | | 答案忠实度 | 答案是否被材料支持 | | 完整性 | 是否遗漏关键点 | | 引用准确性 | 引用是否真的支持对应句子 | | 拒答能力 | 材料不足时是否会说不知道 | | 鲁棒性 | 遇到噪声、旧文档、冲突文档是否稳定 | | 权限正确性 | 是否只使用用户有权看的资料 |

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

一个简单的内部评测集

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

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

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

当前前沿方向 9：RAG 安全

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

常见风险：

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

实用防护思路

工程上至少要做：

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：

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

不同技术怎么选

| 技术 | 主要解决 | 适合场景 | 代价 | |---|---|---|---| | 向量检索 | 语义相似 | 通用知识库 | 可能漏精确词 | | BM25 | 精确匹配 | 编号、术语、代码、报错 | 不懂深层语义 | | 混合检索 | 召回更稳 | 大多数生产 RAG | 系统稍复杂 | | Reranker | 排序更准 | 候选多、要求高 | 增加延迟 | | Contextual Retrieval | chunk 丢上下文 | 长文档、财报、合同 | 离线成本高 | | 长上下文 | 整体阅读 | 小语料、深推理 | token 成本高 | | Agentic RAG | 多步查证 | 复杂任务 | 难控、慢、贵 | | GraphRAG | 全局关系和主题 | 调研、情报、复杂关系 | 建图成本高 | | 多模态 RAG | 图表/PDF/PPT | 视觉丰富文档 | 解析和模型成本高 | | RAG 评测 | 判断是否真的变好 | 所有生产系统 | 要维护测试集 | | RAG 安全 | 防投毒/越权 | 企业知识库 | 需要系统治理 |

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

建议按这个顺序：

第一步：理解最小闭环

先搞清楚：

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

第二步：理解检索质量

重点学：

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

第三步：加入 BM25 和 reranker

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

可以重点理解：

第四步：做评测集

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

最简单也要有：

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

第五步：再看 Agentic / Graph / Multimodal

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

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

常见误解

误解 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 | 检索增强生成，先查资料再回答 | | chunk | 文档切出来的小片段 | | embedding | 文本的向量表示 | | 向量库 | 存储和查询 embedding 的数据库 | | BM25 | 经典关键词检索算法 | | hybrid retrieval | 混合检索，通常是向量 + 关键词 | | reranker | 对候选结果重新排序的模型 | | top-k | 取最相关的 k 个结果 | | context | 放进 prompt 的上下文材料 | | groundedness | 答案是否被材料支撑 | | citation | 引用出处 | | Agentic RAG | 能多步规划、检索、验证的 RAG | | GraphRAG | 结合知识图谱的 RAG | | Multimodal RAG | 支持文本、图片、表格、PDF 等多模态资料的 RAG |

延伸阅读

最后再压缩成一句话

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