、SAG、PageIndex工作逻辑、演进)
你可能看过很多关于RAG的文章介绍某种新的技术、新的理念都说要干翻RAG。在我看来这大都是吸引人眼球的噱头事实上这些很多都属于广义上的RAG。为什么需要RAGRAG存在的目的就是为了解决大模型上下文受限、幻觉问题。大语言模型LLM是经过海量的数据训练出来的最终被使用用来推理简单说就是问答的成品是一个权重文件就像一个知识的数据压缩包本身是“无状态”的它的知识基本就停留在训练数据截止的那一刻。很多知识大模型是不具备的比如你的企业内部文档、个人私密数据、高时效性的行业新闻等。如果你问到LLM不掌握的知识那么它就会胡说八道编造事实所谓的“幻觉”。RAG就是给LLM外挂一个知识库在问答的时候给模型“塞小抄”目标是解决幻觉问题。RAG工作逻辑RAG称为检索增强生成由三个英文单词构成Retrieval-Augmented Generation。其中的G生成代表的是配合LLM完成问答即生成答案。但是最难的部分是“检索”的构建我们做知识库其实就在做这个“检索引擎这里大部分工作的内容还涉及不到LLM本文也不细说G生成的部分。RAG 1.0Vector 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/SAGSAG的整体逻辑比打标签更加完善可以实现类似知识图谱的工作但是把建图这件事变简单了构建流程// 提取事件和实体 文档解析 ─ 文本分片 ─┬ (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时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
