SAG2开源：不调大模型不建向量库，11656段文本建库仅2.36秒

大家好，我是袋鼠帝，常年跟知识库打交道。

AI 圈天天冒新东西，可让我看完起鸡皮疙瘩的，已经很久没出现过了。

最近开源的 SAG2 就做到了。RAG 说不定要被它掀翻——文件不用预处理，本地文件直接当知识库用，速度快得离谱，准确度也高，偏偏连 embedding 都不需要……

https://github.com/Zleap-AI/SAG-Wiki

当然，SAG2 还是理论层面的东西，已经落地能用的工具叫 SAG Wiki，后面会细说。

这么牛的开源项目，作者得单独说一句：广州智跃深空（Zleap）。从 SAG 到 SAG2 全是他们自己研发的，团队确实厉害。

老读者可能有印象，6 月我写过一篇讲 SAG 第一版的稿子。

那时候 SAG 刚开源，它用 SQL 现场串起多跳线索的路子把我吸引住了，我还建议大家把它当 MCP 接进 FastGPT。

可用过的朋友清楚，一代落地时还得调大模型逐段抽事项、抽实体，建库耗时挺长，不少人觉得工程上有点折腾。

结果才 4 个多月，他们把这些全砍了。

现在的 SAG2 建库不调大模型，不做 Embedding，不要向量数据库，也不用 GPU。同样是 11,656 段文本，SAG 一代建库要 4.57 小时，SAG2 只要 2.36 秒，速度提升 7000 倍！

效果反而更好了。三个多跳检索测试集，8 项指标全部第一。

卧槽。。

知识库那个不可能三角——又轻、又便宜、又准，过去最多占两样。SAG2 一口气给打破了。

我为什么这么兴奋

大概是因为，从 24 年初裸辞 All in AI 开始，我就一直在跟知识库打交道，也写了不少相关文章。

我 24 年初裸辞，靠帮一位老板部署 FastGPT、建知识库、调效果挣到第一笔钱。之后这类活又零零散散接了很多。

搭知识库其实不难，难的是后续维护和调优。

分块也头疼：张三负责 A 项目和 500 万预算，被切成两段，线索就断了。score 调低噪音多，调高又容易漏东西，经常按下葫芦浮起瓢。我有个好朋友的公司，组了六个人的团队，整整花了半年，才把回复准确率调到比较满意的状态。

维护更烦。文件一改，就得重新上传、重新切块、重新向量化一遍。

预处理、调优、维护这几个坑我基本都踩过。所以看到 SAG2 的思路，我是真有点激动。

先简单捋一下知识库这几年怎么走过来的，不然很难讲清 SAG2 到底新在哪、好在哪。

RAG 这个词 2020 年就有了，出自 Facebook（现在的 Meta）的一篇论文。

真正火起来是 23 年 ChatGPT 之后：

公司的情况大模型并不了解，办法是先把资料切碎、转成向量存好，用户提问时挑出最相似的几块喂给它。FastGPT、Dify 这些平台把这套流程包装成了点几下就能完成的界面操作。

后来大家意识到，只靠向量并不够用，全文检索、向量检索再加重排序的混合检索逐渐成了常见配置。这套方案到今天仍是最成熟的工业做法，日常的单文档问答用它绰绰有余。

短板就出在多跳上。拿上次那个例子来说：

文档1：A公司全资收购了B公司。

文档2：张三被任命为A公司的CTO。

文档3：张三离职，加入了盘古大模型项目。

问：收购了B公司的企业，其CTO后来加入了哪个项目？

文档3里头，收购、B公司、CTO这几个词一个都没出现，线索到这儿就断了。

知识图谱因此登场：

24 年微软把 GraphRAG 开源出来，之后又冒出 LightRAG、HippoRAG 2 等方案。它们的做法是入库前先让大模型把人名、公司、事件之间的关系逐一抽出来，拼成一张大图。多跳能力确实上去了，可代价是贵、是重：索引环节要反复调用大模型，一旦有新文件进来，关系说不定还得重新算。

今年 4 月，卡帕西分享了 LLM Wiki 的思路：

思路是让大模型把原始资料通读一遍，编译成一套 wiki 页面，问答针对 wiki 来做，产出的结果再回填进去。我写仓颉.Skill 时就专门参考过它。拿来整理个人知识挺顺手，页面读着也舒服。问题是资料一多，大模型一篇篇读、一篇篇写，时间和 Token 都跟着涨，原文一改，对应页面照样得重写。

Google 的 NotebookLM 也算一条路。年初那篇工具推荐里我提过它，资料丢进去就能问答、出摘要、生成播客，啃大部头很好使。但资料要上传到云端，每个笔记本可放的来源有上限，想叫本地 Agent 直接调它，也不太方便。

规律其实很清楚：每往前进一步，多半是在入库时多掏一点钱、多调一次模型，换来检索更准。

SAG 一代走的也是这个路子，只不过比 GraphRAG 轻一些：

它不画全局大图，只提炼事项和实体，查询时再用 SQL 把它们串起来。

SAG2 却把这条路掉了个头。

建库阶段，SAG2 一个模型都不调，直接对原文建关键词索引，用 BM25 打分。

BM25 这名字不少人可能没听过，其实是个老古董，90 年代就有了。你熟悉的 Elasticsearch（开发者应该很熟），默认打分用的就是它。

同样面对 11,656 个段落，原 SAG 论文给出的建库时间是 4.57 小时，消耗 2,826 万 tokens。

这回他们在一台 M4 Pro、64 GB 内存的 Mac 上，从空数据库连续重建三次，中间值只有 2.36 秒，而且没有 token 消耗～

4.57 小时对 2.36 秒，两次记录的建库耗时差了约 7,000 倍！！

一个刷新 SOTA 的新方案，底座竟是三十年前的老算法。这算不算返璞归真？🤔

那语义理解从哪来？靠 JEV。

JEV 是前

所以 SAG2 的分工是这样的：

BM25 先把候选粗粗筛一遍，JEV 再从中判断哪些算得上有用的证据；随后算法从这些有用段落里提取关键词，继续往下搜，JEV 则结合已经到手的证据，对新搜到的内容再做一次判断。

仍以张三为例，SAG2 的走法是这样：

第一轮用收购、B公司去搜，命中文档1，JEV 判定有用。接着从文档1里挑出关键词 A公司继续搜，命中文档2，得知 CTO 是张三。再拿张三去搜，命中文档3：盘古大模型项目。

SAG 一代串线索，靠的是事项和实体，这两样得提前让大模型抽出来。

SAG2 改成关键词和段落：一个关键词连着好几个段落，一个段落里也装着好几个关键词，这些关联直接来自原文，事前不用做任何处理。

打个比方，以前图书馆还没开门，就得先安排人把每本书通读一遍、逐张写好卡片；如今则是你开口问的当口，管理员顺着目录快速翻找，边上还守着一位老师傅，书一递到跟前，他瞟一眼便给出判断：这本管用，那本白搭。靠计算机撑起来的这种速度，确实快得离谱。

我上次写 SAG 时，最难的 MuSiQue 上 Recall@5 是 80.04%，这次是 80.68%，比 HippoRAG 2 高了 15.55 个百分点。本来以为砍掉预处理效果得退一点，结果没退反进。

更让我佩服的是 EnterpriseRAG-Bench，51 万份模拟企业邮件、工单、会议记录的文档。一项规模研究里，LightRAG、MS-GraphRAG、HippoRAG 2 这些图谱方案都没跑完全量。SAG2 全部跑完，建库 8 分 32 秒，文档 Recall@10 达到 81.10%。

另外，基于 SAG2，他们还开源了桌面端 SAG Wiki（这就非常方便了）：

Windows 版约 13 MB，macOS 约 18 MB。非常轻量～

添加一个本地文件夹就是知识库，文件不用动，改了自动增量更新。问答模型我配的是 DeepSeek V4.1 Flash。

https://github.com/Zleap-AI/SAG-Wiki

配置起来就两步。先在设置里把两个模型填好：问答模型管生成回答，选哪个随你（比如性价比高的 DeepSeek ）；决策模型管找线索，官方论文里用的是 TypeSafe 的 Jev 模型，这也是官方定死的决策模型，配置时把对应的 Jev Key 填进去就行，想换别的决策模型同样可以。

配置好后，就可以回到首页添加文件夹（知识库）了

然后，即便你电脑上有无数种格式的文件，SAG Wiki都能索引，并识别到，甚至能识别音频、视频。

位置在：设置->文件设置->其他格式

我把放着 383 篇历史公众号文章的文件夹扔进去实测：

先问了一下「之前蒸馏公众号文章时，到底处理了多少篇、多少字？」

它搜了两次，翻出了对应的文章，直接给出准确数字：138 篇、79 万字！

说实话，我蒸馏的文章写了好多篇了。它居然能一次搞定，没有找错，确实有东西。

我又追问：

之前有哪些把视频或多模态工具通过 CLI、Skill 接进 Agent 的实测？

它把过往文章从头到尾扫了一遍，从各篇文章里翻出 LibTV、拓、Remotion 等案例，工具、接法、标题、日期被它齐整地列进一张表，点一下引用就能跳到原文。

这多跳检索，也完全不在话下，而且我检查了一下，真滴准。

随后我往 SAG Wiki 里装进了 10 万篇维基词条，再加上另外几个目录，这台电脑总共索引了 100,461 个文件。建库花了多久？具体时间我记不清了，只记得去趟洗手间回来，库就已经建好了。

下面这几道题换个场地，放到终端里，用 Claude Code 来跑。

接着做一组对照：

「Claude Code + DeepSeek」对「Claude Code + DeepSeek + SAG2」。

双方都以 DeepSeek V4.1 Flash 来查这个十万词条库，区别只在于一边挂了 SAG2，另一边是原生模型。

题目是：只给「李白」和「爱因斯坦」这两个看似毫不相干的名字，能不能顺着线索在几步之内把他俩连起来？条件只有一个——每一步都得有确凿出处，不许胡编。

PS：终端界面不好截图，截出来效果也差，图是让 AI 按真实结果画出来展示的。

两组最后给出的答案完全不一样：

原生组翻出了刘慈欣的作品表——《朝闻道》（又名爱因斯坦赤道）和《诗云》（又名李白），靠科幻作家的作品集让两人同框；

接了 SAG2 的那边则先用关键词锁定学者林庚先生，再沿 SAG 追他的生平著作：林庚年轻时在清华物理系痴迷爱因斯坦的相对论，后来成了写出《诗人李白》的文学巨擘。从相对论连到林庚，再连回李白，两头都有原文可查。

脑洞测完，再上一个更硬核的场景：啃几十万字的大部头专业研报。

平时研究算力硬件、折腾本地模型，免不了要翻半导体研报。可看英文研报的滋味大家都懂：动辄一两百页全英文，满篇专业缩写和黑话，想从里面挖出一个关键细节，头都大了。

举个例子，英伟达 H100 芯片用的是 SK 海力士的 HBM3 显存、走 MR-MUF 封装工艺，这大家都知道。但要是往下深挖：核心的底层填充胶水（Underfill），是谁独家供给 SK 海力士的？

这类隐秘的供应链事实，官方通稿里往往不写，科技新闻也不会细讲，多半埋在深度研报的某个角落。我手上正好有 26 份半导体深度研报，就拿来做这次测试。

结果差距悬殊：接了 SAG2 的一边只调用了 3 次工具就找到核心段落，一下就命中了 Namics 供货的那句原文；

原生查找组则在各个文档之间乱翻，像没头苍蝇，直到第 11 次工具调用才勉强蒙对。

最后一题，给两组 Claude Code 同一份 SAG Wiki v0.2.6 源码，查底层 Jev 碰到网络错误时的重试逻辑。

原生组抓出一堆文件逐个打开看；接了 SAG2 之后，问题直接扔过去，它就把文件、行号和关键代码一并带回来：明确命中 HTTP 499 状态码重试时不增加失败计数。

总耗时从原生组的 144 秒降到 95 秒。

这么看，SAG2 不光适合超大规模下的快速检索，哪怕数据量没那么大，也比原生模型强出不少。

在 AI 圈摸爬滚打这几年，我常有一种恍惚感。

大家似乎都陷进了一种技术执念：模型参数越堆越大，向量数据库要上集群，系统越做越庞大、越做越贵，门槛也越抬越高。

SAG2 走的路子跟这套思路正相反。它没碰那些重型架构，也没堆什么玄乎概念，而是退回到 Unix 那句最朴素的信条：一切皆文件。它用的是已经跑了几十年的 BM25 倒排索引，配上轻巧灵动的动态超边，把繁重的计算往后推，推到真正需要的那一刻才算。

建库只要几秒钟，体积 10几MB，过去很难啃的多跳推理，就这样被交到每个普通人手上。当然，这也得谢谢 Jev——新技术一旦突破，常常会把别的技术一起带起来。

还有一点，它把“数据得先处理、再存进库、然后才能检索”这条老规矩给破了。现在你的数据根本不用动，整个过程全自动😄。这让人想起老子在《道德经》里那句话：大道至简，少则得，多则惑。

SAG2 和 SAG Wiki 现在都已经全部开源，有需要的朋友不妨亲自上手试一试。这么🐂🍺的先锋开源项目，点个 Star 不过分吧？

我是袋鼠帝，一个致力于帮你把AI变成生产力的博主。我们下期见～