你好我是袋鼠帝。上周有客户找我聊了个需求大意是想做一个本地「小秘书」会议纪要、立项材料、批复文件这些都要能通过Agent对话直接查询项目金额、开始时间这类确定信息也要能查而且准确率要高可用性要强他自己有本地服务器和大模型数据量大概不超过1500个文档。我当时第一反应是用FastGPT来上传文档打造知识库。24年的时候我接过不少类似需求基本都是用fastgpt快速搭建的。然后我拉了一位好朋友来一起看仔细分析过后感觉这个事儿没那么简单。知识库最难的从来不是「搭建」是调优。。之前跟这位好朋友交流过知识库调优这块她说她们公司本来想外采一个知识库系统但是大厂开价有点高。然后就自己组了个六人团队做知识库搞了整整半年才把回复准确率调到一个相对满意的状态。。我觉得不是他们能力的问题而是传统 RAG 的调优本来就是这样是黑盒的比较模糊的你不知道改了哪里会造成「按下葫芦浮起瓢」。有可能你调低个过滤的score获取的信息范围是增大了但是可能又回出现很多噪音。更要命的是这个客户的需求里肯定还有一种场景普通RAG方案搭建的知识库遇上基本都会GG。就是 多跳推理。举个例子。假设他的知识库里有三份独立文档文档 12023年A公司全资收购了B公司。文档 2张三被任命为A公司的CTO。文档 32024年张三离职加入了盘古大模型项目。用户问收购了B公司的企业其CTO后来加入了哪个项目传统向量检索或混合检索全文向量重排拿着问题里的关键词去库里搜能找到文档1和文档2但绝对找不到文档3。原因很简单文档3里根本没出现「收购」「B公司」「CTO」这几个词字面和语义都毫不沾边线索在这里断了。最后只能给出「抱歉资料中未找到相关内容。。。。」会议纪要这种场景这类多跳检索需求一定是非常多的。这中途我也想过用 GraphRAG但我一直都觉得 GraphRAG 太重了它需要在文件入库之前大量调用 LLM 去提取三元组谁-做了什么-对谁然后把整个语料库的知识图谱在离线状态下全部构建好。光是索引成本据我了解一个中等规模的数据集就能烧好几万块钱。对于这个客户的项目有点杀鸡用牛刀而且图谱构建好之后只要有新文件进来就可能要重新算一遍关系维护成本贼高。所以我找了一圈发现了一个前几天刚开源新东西SAG。已经在Github斩获1.3K Star了。https://github.com/Zleap-AI/SAG我打开论文一看标题SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges--基于查询时动态超边的 SQL 检索增强生成好家伙SQL我特别熟悉看到这个思路我一下子就来精神了SAG 到底是什么SAG 是 广州智跃深空人工智能科技有限公司 Zleap 提出的一套开源检索架构。它的核心思路简单来说就是把文档转成「事项event-实体entity」索引存进 SQL 关系型数据库查询时用 SQL 动态组装关联关系代替GraphRAG的那种离线预构建的静态知识图谱。这句话你可能没搞懂我换个更简单的解释就好理解了。你可以把传统 RAG 想象成一个图书馆管理员每次你问问题比如你想要医学相关的书他就拿着你的关键词在书架上找相关的医学书籍找到了递给你。这个方式在大多数情况下够用但如果你问的问题需要从三本书里各抽一段看似没有关联的内容才能拼出答案他就挠头了因为他是靠「字面意思匹配」找书的没有能力自动把三本书的线索串起来。传统RAG工作流程图GraphRAG 的做法是在你把书放进图书馆之前先花大量时间把整个图书馆的所有人名、公司名、事件提前画一张巨大的关系图挂在墙上。查询的时候顺着关系图谱找效果确实很好。但问题是画这张图非常耗时耗钱而且每进来一本新书就得重新画。SAG 走了第三条路它不画全局关系图而是在你上传文档的时候用 AI 把每个文档片段提炼成一张「事项卡片」记录发生了什么事同时提取出这件事涉及的「实体」公司名、人名、项目名等把这些存进一个普通的 SQL 数据库和向量库里。查询时用 SQL 的 JOIN 语句动态把有共同实体的事项拎出来组成局部关系网实时串联多跳线索。比如用刚才那个例子跑一遍知识库里有三份文件文档1说「A公司全资收购了B公司」文档2说「张三被任命为A公司的CTO」文档3说「张三离职加入了盘古大模型项目」。用户问「收购了B公司的企业其CTO后来加入了哪个项目」SAG 拿到问题两件事同时在跑一边用普通 RAG 一样做向量语义搜索找意思最相关的段落另一边从问题里提取实体「B公司」「CTO」去数据库里用SQL查哪些事项涉及了这两个实体最后命中文档1和文档2。到这里SAG 做到了普通 RAG 很难做到的一步扫描已命中的文档1和文档2从里面发现了一个新实体「张三」。这个名字在用户原始问题里根本没出现过但它是两份文档之间的连接点。于是数据库自动触发第二轮查询「哪些事项涉及了张三」命中文档3。三份文档全部到位加上向量搜索的结果一起交给大模型拼出最终答案。普通 RAG 做完向量搜索就停了因为找到了文档1和文档2但不会从里面挖出「张三」这个新线索继续追文档3对它来说可能是永远的盲区。SAG 在向量搜索的基础上多了实体关联这条链从已经找到的内容里挖出新线索、接着往下查让多跳推理变成一件确定的事而不是靠运气。和 FastGPT 混合检索有什么区别其实我看完论文之后还有一个疑问就是SAG和Fastgpt自带的混合检索有啥区别FastGPT 里的「全文检索向量检索重排序」其实就是目前最成熟的工业标准 RAG 方案它本身并没有什么问题对绝大多数日常知识库问答足够好。SAG 和它的区别主要也是在SQL部分对应具体的能力就是SAG「多跳推理」更强。日常的单文档问答FastGPT 完全够用速度也快。但涉及需要跨多个文档逻辑串联的问题FastGPT本质上是扁平的相似度匹配就触到了物理上限而 SAG 靠 SQL 结构兜底。除此之外SAG 还有几个让我觉得有意思的地方可解释性传统 RAG 检索问题排查是黑盒你可能只知道「相似度不够」要不是分块没弄好要不是Score设置的有问题大部分时候是去调试但不知道具体是哪个环节出了问题。SAG 的检索链条是完全可追溯的 SQL 调用记录大模型提取了什么实体 - 同义词扩展命中了哪些 - SQL 走通了哪条路径。哪里断了工程师一眼就能定位去修。这一条对调优来说是革命性的。传统 RAG 调优有点像「炼丹」你改切块大小、改向量模型、改重排阈值改完一个可能又会出现另一个问题永远不知道瓶颈在哪。SAG 的调优更像程序员们熟悉的「找 Bug 和修 Bug」有问题看日志找具体的问题点只能砍掉团队80%像无头苍蝇一样瞎摸索的时间。入库逻辑的转变传统 RAG 的调优大量时间花在切块、参数上按500字切还是1000字一块切重叠的部分要不要如果切块切坏了把「张三负责A项目」和「500万预算」切成两段线索就断了。SAG 把这个问题前移了在文档入库之前用 AI 把内容提炼成完整的「事项卡片」一件事就是一张卡不用关心切块的问题。入库的数据是完整的后续检索准确率自然就会更高。SAG不挑模型论文里有一个很有意思的消融实验研究员故意把 SAG 底层的向量模型换成了一个很普通的开源弱模型结果其他高级 RAG 方案的准确率暴跌了将近10%SAG 几乎没什么变化依然稳定在80%左右。原因就在于SAG 找线索的主干力量是确定的 SQL 实体关联不是模糊的向量距离换个弱模型不太能影响 SQL 找东西。这对有行业黑话的企业场景更加重要因为通常向量模型不认识你们公司内部的一些黑话但只要 SQL 里存了这个实体就能查出来不需要专门微调向量模型SAG到底行不行Zleap在三个多跳推理标准数据集HotpotQA、2WikiMultiHop、MuSiQue上跑了评测。其中在 MuSiQue 上的 Recall5 达到80.04%比 HippoRAG 2 的 65.13% 高出约 15 个百分点。MuSiQue 是这三个测试集里最难的要求最多4跳的组合推理且不允许跳过中间步骤是公认的RAG里面的「地狱难度」测试集。而HippoRAG 2是目前比较推崇的方案之一灵感来自神经科学里的「海马体索引理论」原理是把知识图谱和 Personalized PageRank 算法结合起来做多跳推理。简单来说就是一种模仿人脑海马体的AI检索技术。跟 SAG 相比HippoRAG 2 在构建阶段也需要离线预先建好知识图谱依赖图结构的静态全局关系而 SAG 把图的构建时机后推到查询时会用 SQL 动态激活避开了全局图重建和维护的开销。PSSQL动态激活就是 SAG 把图的构建时机后推到了查询时。也就是你提问的那一刻SAG 才通过 SQL 把事项之间的关联关系查询出来不是提前把全图建好等着你来用。另外目前SAG 已经在约5亿条数据规模的生产环境里完成了部署在线检索延迟保持在秒级以内。而一般的RAG在数据量上了百万就 OOM内存溢出或者速度拉跨。这次SAG直接刷新了SOTA。也可以本地docker-compose部署我用codex帮我一键完成了部署我让codex帮我造了一些数据丢进去测试了一些问题命中率比我预期的高回到这个客户的需求落地方案怎么搞我觉得 SAG 目前主要还是一套检索架构。如果你想纯按 SAG 的思路从零做一个完整的知识库产品还是需要自己搭前端、做权限管理、写文档解析引擎、搞部署运维工程量很大对一个预算有限的项目来说烂尾风险很高。而 FastGPT对话界面完善、权限管理成熟、接微信/飞书都很快能瞬间满足客户对「可用性」的要求。所以对于这个客户的项目可以两者结合在成熟的系统如 FastGPT之上使用 SAG 作为知识库的实现方案。既能复用 FastGPT 的工程成熟度同时用 SAG 的思想解决了「切块破碎」和「结构化检索」的问题。后续的调优也更加的方便快捷。目前最简单的方式应该是把SAG作为MCP工具丝滑的接入Fastgpt当然如果 FastGPT 或其他主流知识库系统哪天把 SAG 的架构思想丝滑地融进官方工作流那更好拿来即用就行。PS也可以通过MCP丝滑接入Codex、Claude code等本地Agent使用「最后」RAG 这几年的演化路径从最早的纯向量检索到混合检索到 GraphRAG 引入知识图谱再到现在 SAG 把知识图谱的构建时机从「离线」挪到「查询时」用 SQL 关系型数据库作为动态组织层。每一步看起来都是在加复杂度但感觉 SAG 这一步有点返璞归真的意思。SQL 关系型数据库大家用了几十年稳定、可解释、可维护把它拉进检索架构工程落地的难度反而降低了不少。而且对于很多企业来说开发团队可能会天天写 SQL贼熟接起来也比较丝滑。创新不一定是发明全新的东西有时候是把已经被验证过的工具重新组合用在对的地方站在巨人的肩膀上。然后我觉得SAG将成为 Agent 的数据底座因为 Agent 很多时候就是在完成多跳推理工作先查 A用 A 的结论决定去查 B每一步输出都是下一步的输入。这正好也是 SAG 解决的问题。传统 RAG 给 Agent 的是「大概相关的几段内容」SAG 给的是更确定的结构化的事项和实体拿到就能直接推理不用再从相似的文本里自己挖掘出幻觉的概率也低很多。并且有了精确且高效的查询能更好的发挥本地小模型的优势。这种私有知识库的数据底座设计好了本地Agent 的能力也会更上一层楼。我是袋鼠帝一个致力于帮你把AI变成生产力的博主。我们下期见
再见RAG！AI知识库还得是SAG，又快又准～
你好我是袋鼠帝。上周有客户找我聊了个需求大意是想做一个本地「小秘书」会议纪要、立项材料、批复文件这些都要能通过Agent对话直接查询项目金额、开始时间这类确定信息也要能查而且准确率要高可用性要强他自己有本地服务器和大模型数据量大概不超过1500个文档。我当时第一反应是用FastGPT来上传文档打造知识库。24年的时候我接过不少类似需求基本都是用fastgpt快速搭建的。然后我拉了一位好朋友来一起看仔细分析过后感觉这个事儿没那么简单。知识库最难的从来不是「搭建」是调优。。之前跟这位好朋友交流过知识库调优这块她说她们公司本来想外采一个知识库系统但是大厂开价有点高。然后就自己组了个六人团队做知识库搞了整整半年才把回复准确率调到一个相对满意的状态。。我觉得不是他们能力的问题而是传统 RAG 的调优本来就是这样是黑盒的比较模糊的你不知道改了哪里会造成「按下葫芦浮起瓢」。有可能你调低个过滤的score获取的信息范围是增大了但是可能又回出现很多噪音。更要命的是这个客户的需求里肯定还有一种场景普通RAG方案搭建的知识库遇上基本都会GG。就是 多跳推理。举个例子。假设他的知识库里有三份独立文档文档 12023年A公司全资收购了B公司。文档 2张三被任命为A公司的CTO。文档 32024年张三离职加入了盘古大模型项目。用户问收购了B公司的企业其CTO后来加入了哪个项目传统向量检索或混合检索全文向量重排拿着问题里的关键词去库里搜能找到文档1和文档2但绝对找不到文档3。原因很简单文档3里根本没出现「收购」「B公司」「CTO」这几个词字面和语义都毫不沾边线索在这里断了。最后只能给出「抱歉资料中未找到相关内容。。。。」会议纪要这种场景这类多跳检索需求一定是非常多的。这中途我也想过用 GraphRAG但我一直都觉得 GraphRAG 太重了它需要在文件入库之前大量调用 LLM 去提取三元组谁-做了什么-对谁然后把整个语料库的知识图谱在离线状态下全部构建好。光是索引成本据我了解一个中等规模的数据集就能烧好几万块钱。对于这个客户的项目有点杀鸡用牛刀而且图谱构建好之后只要有新文件进来就可能要重新算一遍关系维护成本贼高。所以我找了一圈发现了一个前几天刚开源新东西SAG。已经在Github斩获1.3K Star了。https://github.com/Zleap-AI/SAG我打开论文一看标题SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges--基于查询时动态超边的 SQL 检索增强生成好家伙SQL我特别熟悉看到这个思路我一下子就来精神了SAG 到底是什么SAG 是 广州智跃深空人工智能科技有限公司 Zleap 提出的一套开源检索架构。它的核心思路简单来说就是把文档转成「事项event-实体entity」索引存进 SQL 关系型数据库查询时用 SQL 动态组装关联关系代替GraphRAG的那种离线预构建的静态知识图谱。这句话你可能没搞懂我换个更简单的解释就好理解了。你可以把传统 RAG 想象成一个图书馆管理员每次你问问题比如你想要医学相关的书他就拿着你的关键词在书架上找相关的医学书籍找到了递给你。这个方式在大多数情况下够用但如果你问的问题需要从三本书里各抽一段看似没有关联的内容才能拼出答案他就挠头了因为他是靠「字面意思匹配」找书的没有能力自动把三本书的线索串起来。传统RAG工作流程图GraphRAG 的做法是在你把书放进图书馆之前先花大量时间把整个图书馆的所有人名、公司名、事件提前画一张巨大的关系图挂在墙上。查询的时候顺着关系图谱找效果确实很好。但问题是画这张图非常耗时耗钱而且每进来一本新书就得重新画。SAG 走了第三条路它不画全局关系图而是在你上传文档的时候用 AI 把每个文档片段提炼成一张「事项卡片」记录发生了什么事同时提取出这件事涉及的「实体」公司名、人名、项目名等把这些存进一个普通的 SQL 数据库和向量库里。查询时用 SQL 的 JOIN 语句动态把有共同实体的事项拎出来组成局部关系网实时串联多跳线索。比如用刚才那个例子跑一遍知识库里有三份文件文档1说「A公司全资收购了B公司」文档2说「张三被任命为A公司的CTO」文档3说「张三离职加入了盘古大模型项目」。用户问「收购了B公司的企业其CTO后来加入了哪个项目」SAG 拿到问题两件事同时在跑一边用普通 RAG 一样做向量语义搜索找意思最相关的段落另一边从问题里提取实体「B公司」「CTO」去数据库里用SQL查哪些事项涉及了这两个实体最后命中文档1和文档2。到这里SAG 做到了普通 RAG 很难做到的一步扫描已命中的文档1和文档2从里面发现了一个新实体「张三」。这个名字在用户原始问题里根本没出现过但它是两份文档之间的连接点。于是数据库自动触发第二轮查询「哪些事项涉及了张三」命中文档3。三份文档全部到位加上向量搜索的结果一起交给大模型拼出最终答案。普通 RAG 做完向量搜索就停了因为找到了文档1和文档2但不会从里面挖出「张三」这个新线索继续追文档3对它来说可能是永远的盲区。SAG 在向量搜索的基础上多了实体关联这条链从已经找到的内容里挖出新线索、接着往下查让多跳推理变成一件确定的事而不是靠运气。和 FastGPT 混合检索有什么区别其实我看完论文之后还有一个疑问就是SAG和Fastgpt自带的混合检索有啥区别FastGPT 里的「全文检索向量检索重排序」其实就是目前最成熟的工业标准 RAG 方案它本身并没有什么问题对绝大多数日常知识库问答足够好。SAG 和它的区别主要也是在SQL部分对应具体的能力就是SAG「多跳推理」更强。日常的单文档问答FastGPT 完全够用速度也快。但涉及需要跨多个文档逻辑串联的问题FastGPT本质上是扁平的相似度匹配就触到了物理上限而 SAG 靠 SQL 结构兜底。除此之外SAG 还有几个让我觉得有意思的地方可解释性传统 RAG 检索问题排查是黑盒你可能只知道「相似度不够」要不是分块没弄好要不是Score设置的有问题大部分时候是去调试但不知道具体是哪个环节出了问题。SAG 的检索链条是完全可追溯的 SQL 调用记录大模型提取了什么实体 - 同义词扩展命中了哪些 - SQL 走通了哪条路径。哪里断了工程师一眼就能定位去修。这一条对调优来说是革命性的。传统 RAG 调优有点像「炼丹」你改切块大小、改向量模型、改重排阈值改完一个可能又会出现另一个问题永远不知道瓶颈在哪。SAG 的调优更像程序员们熟悉的「找 Bug 和修 Bug」有问题看日志找具体的问题点只能砍掉团队80%像无头苍蝇一样瞎摸索的时间。入库逻辑的转变传统 RAG 的调优大量时间花在切块、参数上按500字切还是1000字一块切重叠的部分要不要如果切块切坏了把「张三负责A项目」和「500万预算」切成两段线索就断了。SAG 把这个问题前移了在文档入库之前用 AI 把内容提炼成完整的「事项卡片」一件事就是一张卡不用关心切块的问题。入库的数据是完整的后续检索准确率自然就会更高。SAG不挑模型论文里有一个很有意思的消融实验研究员故意把 SAG 底层的向量模型换成了一个很普通的开源弱模型结果其他高级 RAG 方案的准确率暴跌了将近10%SAG 几乎没什么变化依然稳定在80%左右。原因就在于SAG 找线索的主干力量是确定的 SQL 实体关联不是模糊的向量距离换个弱模型不太能影响 SQL 找东西。这对有行业黑话的企业场景更加重要因为通常向量模型不认识你们公司内部的一些黑话但只要 SQL 里存了这个实体就能查出来不需要专门微调向量模型SAG到底行不行Zleap在三个多跳推理标准数据集HotpotQA、2WikiMultiHop、MuSiQue上跑了评测。其中在 MuSiQue 上的 Recall5 达到80.04%比 HippoRAG 2 的 65.13% 高出约 15 个百分点。MuSiQue 是这三个测试集里最难的要求最多4跳的组合推理且不允许跳过中间步骤是公认的RAG里面的「地狱难度」测试集。而HippoRAG 2是目前比较推崇的方案之一灵感来自神经科学里的「海马体索引理论」原理是把知识图谱和 Personalized PageRank 算法结合起来做多跳推理。简单来说就是一种模仿人脑海马体的AI检索技术。跟 SAG 相比HippoRAG 2 在构建阶段也需要离线预先建好知识图谱依赖图结构的静态全局关系而 SAG 把图的构建时机后推到查询时会用 SQL 动态激活避开了全局图重建和维护的开销。PSSQL动态激活就是 SAG 把图的构建时机后推到了查询时。也就是你提问的那一刻SAG 才通过 SQL 把事项之间的关联关系查询出来不是提前把全图建好等着你来用。另外目前SAG 已经在约5亿条数据规模的生产环境里完成了部署在线检索延迟保持在秒级以内。而一般的RAG在数据量上了百万就 OOM内存溢出或者速度拉跨。这次SAG直接刷新了SOTA。也可以本地docker-compose部署我用codex帮我一键完成了部署我让codex帮我造了一些数据丢进去测试了一些问题命中率比我预期的高回到这个客户的需求落地方案怎么搞我觉得 SAG 目前主要还是一套检索架构。如果你想纯按 SAG 的思路从零做一个完整的知识库产品还是需要自己搭前端、做权限管理、写文档解析引擎、搞部署运维工程量很大对一个预算有限的项目来说烂尾风险很高。而 FastGPT对话界面完善、权限管理成熟、接微信/飞书都很快能瞬间满足客户对「可用性」的要求。所以对于这个客户的项目可以两者结合在成熟的系统如 FastGPT之上使用 SAG 作为知识库的实现方案。既能复用 FastGPT 的工程成熟度同时用 SAG 的思想解决了「切块破碎」和「结构化检索」的问题。后续的调优也更加的方便快捷。目前最简单的方式应该是把SAG作为MCP工具丝滑的接入Fastgpt当然如果 FastGPT 或其他主流知识库系统哪天把 SAG 的架构思想丝滑地融进官方工作流那更好拿来即用就行。PS也可以通过MCP丝滑接入Codex、Claude code等本地Agent使用「最后」RAG 这几年的演化路径从最早的纯向量检索到混合检索到 GraphRAG 引入知识图谱再到现在 SAG 把知识图谱的构建时机从「离线」挪到「查询时」用 SQL 关系型数据库作为动态组织层。每一步看起来都是在加复杂度但感觉 SAG 这一步有点返璞归真的意思。SQL 关系型数据库大家用了几十年稳定、可解释、可维护把它拉进检索架构工程落地的难度反而降低了不少。而且对于很多企业来说开发团队可能会天天写 SQL贼熟接起来也比较丝滑。创新不一定是发明全新的东西有时候是把已经被验证过的工具重新组合用在对的地方站在巨人的肩膀上。然后我觉得SAG将成为 Agent 的数据底座因为 Agent 很多时候就是在完成多跳推理工作先查 A用 A 的结论决定去查 B每一步输出都是下一步的输入。这正好也是 SAG 解决的问题。传统 RAG 给 Agent 的是「大概相关的几段内容」SAG 给的是更确定的结构化的事项和实体拿到就能直接推理不用再从相似的文本里自己挖掘出幻觉的概率也低很多。并且有了精确且高效的查询能更好的发挥本地小模型的优势。这种私有知识库的数据底座设计好了本地Agent 的能力也会更上一层楼。我是袋鼠帝一个致力于帮你把AI变成生产力的博主。我们下期见
