RAG入门：一文搞懂向量RAG、BM25、知识图谱(GraphRAG)、SAG、PageIndex工作逻辑、演进-育师

你可能看过很多关于RAG的文章，介绍某种新的技术、新的理念，都说要干翻RAG。

在我看来这大都是吸引人眼球的噱头，事实上这些很多都属于广义上的RAG。

为什么需要RAG？

RAG存在的目的就是为了解决大模型上下文受限、幻觉问题。

大语言模型（LLM）是经过海量的数据训练出来的，最终被使用（用来推理，简单说就是问答）的成品是一个权重文件，就像一个知识的数据压缩包，本身是“无状态”的，它的知识基本就停留在训练数据截止的那一刻。

很多知识大模型是不具备的，比如你的企业内部文档、个人私密数据、高时效性的行业新闻等。如果你问到LLM不掌握的知识，那么它就会胡说八道（编造事实，所谓的“幻觉”）。

RAG就是给LLM外挂一个知识库，在问答的时候给模型“塞小抄”，目标是解决幻觉问题。

RAG工作逻辑

RAG称为检索增强生成，由三个英文单词构成Retrieval-Augmented Generation。

其中的G（生成）代表的是配合LLM完成问答，即生成答案。

但是最难的部分是“检索”的构建，我们做知识库其实就在做这个“检索引擎"，这里大部分工作的内容还涉及不到LLM，本文也不细说G（生成）的部分。

RAG 1.0（Vector RAG）

这也是应用最为广泛也是最经典的RAG范式，其核心工作逻辑就是把文档经过解析、切片、向量索引、召回。

// 经典RAG构建流程 // 重排、过滤等都属于后处理了，不展开说 文档解析 ─> 文本分片 ─> 计算文本向量化 ─> 存入向量数据库 ─> 向量相似度召回

工作模式依赖的是“向量”：在大模型的世界里，向量就是把人类的语言、图片、音频等内容转为一串数字列表，因为大模型是无法直接理解人类语言的，比如“苹果”，所以需要通过一个叫做嵌入（Embedding）的模型，把词句转为一串长长的数字序列，比如用3个维度来表示苹果：

// 三个维度，实际应用中维度一般更高，比如是1024维，称为高维空间 苹果 -> [0.8, 0.7, 0.9]

向量能“理解”语义，因为含义相同的词句其“数字序列”比较接近，在向量空间里，苹果和香蕉比较近，但是和电脑非常远。这就是通过计算两个向量的空间距离来判断语义相似度的。

所以在这类系统中向量数据库（如 Milvus, Pinecone, LanceDB）是必要的模块之一，这些数据库通过提供的SDK/API把复杂的过程全部封装好，只需要调用就行了。

向量能理解“意思”，计算效率也高，但是也有很多缺点：

缺乏多跳推理的能力，比如“张三在李四的公司做过什么项目？”（后面引入了基于图数据库的 GraphRAG）
无法应对复杂逻辑、条件筛选类的查询：“找出 2025 年之后的、关于Agent在企业应用落地的、且大于5000字的调研报告。”（这在SQL数据库里轻松拿捏）。
容易产生噪音，很多词句向量化后虽然空间数值很近，但是意思截然相反，比如：“我去年买了台苹果电脑” 与 “我昨天吃了个苹果”，也会被判定为高相关度，不相关内容进入LLM上下文，影响回答质量。

向量只擅长基于语义的“模糊匹配”。

RAG 1.5 （混合检索）

为了弥补向量只擅长基于语义的模糊检索，大家又把传统的关键词检索算法（BM25）请了回来。

比如在很多场景中，用户只想查询比较精确的问题，比如“编号9527”、“苹果16 Pro Max”等，这就是BM25关键词检索的优势。

“BM”是Best Match（最佳匹配），“25”是第25次算法调整的版本（前24次都不太行），它在上个世纪90年代就诞生了，也是很多搜索引擎的底层。

它的核心逻辑是：看关键词在文中出现的“次数”和“稀有度”，次数越高、越稀有，那么文档的权重就越高（排在前面）。

在实际应用中，我们常常把向量检索和BM25结合起来一起使用，这就是混合检索（Hybrid Search），比如向量数据库Milvus内置BM25和混合检索模式，使用起来非常方便。

// Milvus 向量数据库 https://github.com/milvus-io/milvus

现在向量 + BM25关键词的混合检索成了主流知识库的标配。

RAG 2.0 （GraphRAG）

针对复杂关系的多跳查询怎么办呢？后来大家把目光瞄向了图数据库。微软也开源了个GraphRAG项目，给大家做了示范：

https://github.com/microsoft/graphrag

图数据库能把知识变成一张带关系的网，这张网的线条是“边”，线条交汇的点就是“节点”。

用“节点”代表知识的“实体”：人物、地点、事件、公司等。
用“边”代表知识的“关系”：任职于、发生在、推出了等类似的描述都可以是“边”

举例：“张三在2026年加入了腾讯公司，主要负责公司的知识库产品ima的开发。”，在图数据库里是：

// 张三、腾讯公司、ima知识库 是实体，其他是边 张三 - 2026年加入 -> 腾讯公司 张三 - 负责开发 -> ima知识库 腾讯公司 - 拥有产品 -> ima知识库

问题来了，这种实体、关系怎么建立起来？如果靠人力去提取不太现实。

主要依靠LLM去提取实体、关系，具体构建流程：

// 你会注意到，这里还是需要分片！ // 为什么还需要向量处理？这是为了以后的混合检索 文档解析 ─> 文本分片 ─┬─> 提取实体关系 ─> 全局融合(合并去重) ─> 存入图数据库(Graph) └─> 计算文本向量化 ─> 存入向量数据库(Vector)

当把成千上万的文档，丢给大模型可以把里面的实体和关系都提取出来，存入图数据库，这样就构建了一张“铺天盖地的网”，称为知识图谱。

关系搜索能力是知识图谱的强项

图数据库的搜索模式是顺着线（边、关系）爬，比如用户问：“张三的公司做了什么产品？”，向量搜索可能基于语义匹配不能把“张三”和“产品”匹配到一起，但是图数据库可以：

1、找到 “张三” 2、找到加入的公司 “腾讯” 3、找到 “ima知识库”

基于2次关系就确定了问题的答案，技术上称为多跳推理。即使你的数据非常庞大，图数据库处理关系检索的速度也极快。

你可能已经意识到了，通过LLM提取关系、实体本身可能就是问题，因为LLM的能力有差距、自身就有幻觉，无法确保提取的内容是完善的、准确的。

我们本来想依赖RAG去解决LLM的幻觉问题，但是我们居然在构建RAG的时候先引入了“幻觉”！

而且基于LLM提取实体关系还有巨大的token消耗，维护成本又高又慢，一个文件的更新可能要重算整个图关系。

既然GraphRAG问题也是那么多，那么是不是还有更好的办法？

RAG 演进、增强 (结构化RAG/SAG)

图数据库更新太慢、太贵、还严重依赖LLM，现在可以换个思路：不建复杂的“全局图”，只把分片抽成“实体”、“事件”，存入SQL数据库，在用户提问的时候通过SQL语句动态的把关联的事件拼接起来，这就是SQL-RAG的思想。

向量依然是C位。SAG的本质就是在向量RAG在上增加了一层SQL结构查询，在实际的知识库实施中，我们也会给Chunk打标签（用LLM提取关键词，检索的时候通过Chunk映射的关键词再用SQL回查关系数据库）。

// 论文 https://arxiv.org/abs/2606.15971 // 开源参考仓库 https://github.com/Zleap-AI/SAG

SAG的整体逻辑比打标签更加完善，可以实现类似知识图谱的工作，但是把建图这件事变简单了，构建流程：

// 提取事件和实体 文档解析 ─> 文本分片 ─┬> (LLM提取事件实体) ─> 存入关系数据库(SQL) └> (计算文本向量化) ─> 存入向量数据库(Vector)

构建过程一样是要文档解析、分片、向量索引，特别的一点事件实体的提取。

提取实体与事件

使用LLM去分析和处理分片后的结果，这里只处理两个问题：发生了什么（事件）？涉及到什么（实体）？

依然是这句话：“张三在2026年加入了腾讯公司，主要负责公司的知识库产品ima的开发。” 会被提取为：

事件：张三入职腾讯并开发ima（发生时间：2026年） 关联实体：张三、腾讯、ima

然后把结果存入关系数据库（如SQLite、PostgreSQL等），在数据库里建两张表：

事件表：记录事件内容、发生事件
实体关联表：记录哪个事件里提到了哪个实体

如何实现多跳查询呢？

是通过向量语义检索与SQL查询双剑合璧。

通过向量语义搜索找到“种子”选手chunk
通过原始chunk的映射关系找出SQL数据库里的记录，找出实体和事件
拿着实体到SQL精准查询关键词拿到所有的和张三相关的事件
最后把原始Chunk、SQL拼出的事件结果一起打包注入LLM上下文

举例，用户提问：“2026年加入腾讯的那个谁，他以前在阿里做什么？”，整个执行链条是这样的：

向量语义匹配搜索会拿到包含腾讯的Chunk，通过映射拿到实体“腾讯”，然后通过SQL精确查询“腾讯”，找到事件：“张三在2026年入职腾讯”。
基于上面的事件的SQL行记录，发现这个里面还有一个实体“张三”。
基于新线索“张三”继续在SQL数据库中精确查询。
拿到张三的所有数据，也就拿到了它的所有经历、事件。

这里面其实就类似图数据库的多跳查询（例子中是2跳）。

事件在系统中扮演的是检索桥梁和线索，在问答中也会被注入上下文作为高纯度的“小抄”。

所谓SAG依然是RAG，至于能不能替换GrapgRAG的工作，我不敢下结论，但是其思想值得学习。

其他范式：PageIndex：无向量、不切片

前面的RAG/BM25/SAG不管怎么变，多少都依赖向量和文档切片，但是有另一条路子确实与众不同：

PageIndex是由Vectify AI提出的一种新的方式，它不使用向量、不切片，项目开源在：

https://github.com/VectifyAI/PageIndex

工作逻辑依然是类似RAG的那套流程：

给文档建立可以索引的目录树（JsonTree），生成一个目录树json文件，这个目录树记录了文档的每个章节、节点以及定位（页码、行数），甚至可以给每个“节点”生成摘要。
在问答的时候先让LLM先看这个目录树，大模型基于目录找出问题的答案在哪些章节。
拿到章节索引，返回原文档定位到对应的正文，再把完整本文提取出来注入上下文。

// PageIndex的构建流程 文档解析 ──> 构建目录树(基于LLM) ──> 目录树存储(JsonTree) ──> 目录树导航召回(基于LLM)

看工作模式非常像人类查资料，先通过目录看结果在第几页，再直接翻到对应页码。

你会发现它完全不用分片、向量处理。但是它的每一步都强依赖LLM。不管是构建目录索引、摘要，还是在后面的检索都需要LLM参与，在真实的落地场景中，我认为小尺寸模型很难玩得转。（模型能力不足、幻觉严重，目录树都建不好！）

而且在海量文档场景，它似乎也很难应对。对于单篇文档（比如100页）的问答似乎挺好，但是对于100篇？1000篇怎么处理？

// 海量文档处理的思考 1、通过向量检索来缩小命中范围，对于命中的文档分别（给llm）注入JsonTree 2、给整体文档建立文件级目录树，这样可以让AI像人浏览文件夹一样，一级级打开子目录

最后

本文从经典的向量RAG、结合BM25的混合检索、GraphRAG到SAG，以及特立独行的PageIndex，几乎涵盖了主流RAG的范式。

在实际落地场景，没有最好的单一选择，通常是多种模式混合使用。

目前看来，向量RAG + BM25是企业知识库落地最扎实和性价比的路径，GraphRAG则补全了多跳推理的关系检索，SAG的思想也值得尝试用来轻量的实现图能力。

技术没有绝对的优劣，只有最适合业务的场景。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～