刚开源就 SOTA，这个项目有点东西：SAG 凭什么跑赢 GraphRAG，省钱，还扛得住海量企业数据？

假设你是某家科技公司的技术负责人。

去年你用 GraphRAG 搭了一套内部知识库，拿两万份合同做 PoC，问答效果惊艳，老板当场拍板立项、批预算、上生产。

然后文档涨到五百万份。

问题开始不对劲了：

建一次知识图谱要跑整整一个周末，研发费和 token 费比这次查询产生的业务价值还高；

合规部改了一份合同，知识库三天后才更新完；

安全团队坚持数据不能出域，可你依赖的云端大模型又非得把文档传出去。

你心里冒出三个问题：

1 GraphRAG 跑分明明是 SOTA，为什么一进企业真实场景就集体拉胯？

2 多跳问答这种「张经理 → 他去年签的客户 → 那客户今年的续约」式连环追问，到底卡在哪一层？

3 有没有一种方案，既能在跑分上赢，又能扛住五亿文档、当天增量、私有化部署这三件事？

这篇论文给出了一种新的思考和路径：

https://arxiv.org/abs/2606.15971

SAG给了一个反直觉的答案：

SQL 检索增强生成，SQL 已经成熟应用于几乎所有的存储系统几十年了，

把这种成熟的结构化标准直接用于检索和Agent系统！

That’s the point!

很聪明的做法。

让我想到了最近 ClaudeCode 基于已有文件系统的 Agentic Search 方案，有异曲同工之妙。

猛一看上去不太性感，但是又有效又实用。

而且该项目已开源：

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

SAG 将每个数据块转换为一个语义完整的事件和一组索引实体，然后使用 SQL 连接查询将共享实体的事件动态链接到局部超边，并在查询时构建动态实例化的局部索引结构。

这种设计避免了全局图重建和持续维护的需要。

它在最难的 MuSiQue 多跳问答上把 Recall从 65.13% 拉到 80.04%，还扛住了约 5 亿条数据的线上秒级检索。

本文会拆解 SAG 到底做对了什么——以及它为什么可能让 GraphRAG 这类「重图」路线在企业里显得又慢又贵。

多跳问答，向量召回早就到顶了

企业里最难答的问题，几乎都是多跳的。

「我们上海办公室负责合规的张经理，去年签的那个客户，今年的续约情况怎么样？」——要答出来，得先找到张经理，再找到他去年签的客户，再找到那个客户今年的续约记录。

三跳，三份分散在不同文档里的证据。

普通向量检索在这类问题上很早就到顶了。

它只会找语义相近的片段，拼凑不出「张经理 → 客户 → 续约」这条证据链。

更要命的是，Agent 做多步检索时，单步误差会沿推理链累积放大——第一步漏了一个关键实体，后面三步全在错误地基上盖楼。

对 Agent 来说，检索系统真正该提供的能力，是在多跳查询里稳定把证据组织成一条链。

向量检索给不了这个能力。于是行业分出几条路线，核心区别就一个：

什么时候建结构、建多大。

Naive RAG：切块、向量化、top-k。快、便宜、能扛量，但精度卡在语义浅层匹配。 GraphRAG：入库时就把全局知识图谱建好，先全文抽实体、抽关系，再做社区聚类。 HippoRAG 2：模仿人类海马体做认知图谱，是目前公认的多跳强基线。 SAG：几乎不预先建图，入库时只抽一个轻量的局部结构，检索时再就地「长」出一条链。

前三者方向都对，份量却都很重。SAG 押的是相反的注。

GraphRAG 真正的病根：结构建了，查询时却没用上

GraphRAG（图增强检索增强生成）是一种将**知识图谱（Knowledge Graphs）**与大语言模型（LLM）相结合的先进检索技术。传统的 RAG 依赖于将文本切片并利用向量相似度进行检索，这在处理跨文档的“全局问题”或复杂的“多跳推理”时极易抓瞎。

而 GraphRAG 通过构建结构化的实体与关系网络，让 AI 具备了像人类一样“顺藤摸瓜”连点成线的能力。

GraphRAG 的卖点是用图表达实体关系，但实际查询时，系统要么在图节点上做相似度检索，要么在社区摘要上做匹配——它并没有真正去「走」那张图的多跳结构。

离线建好的精细结构，和在线实际执行的召回逻辑，是脱节的。

你付了建图的钱，买到的却只是「查询时能走多跳」的错觉。

这个「结构-检索脱钩」，才是企业里 GraphRAG 最让人沮丧的地方：

它建得起的精致，用的时候用不上。

再把账拆细，这三笔企业都跑不掉：

第一笔：入库成本

GraphRAG 要对每份文档做实体抽取、关系抽取，再跨文档做社区聚类和摘要。

而且传统知识图谱用「主体-关系-客体」这种三元组来表达关系，可现实事件几乎都是多元的：

一笔交易涉及买方、卖方、产品、金额、时间好几个主体，硬拆成两两的三元组，语义被切碎，冗余还成倍增加。

五亿份文档，光建图就是一笔可观的钱，还要扛住三元组拆分的误差累积。

第二笔：增量成本

企业文档每天都在变。GraphRAG 的全局图谱一旦某份文档变了，社区结构就可能跟着变，理论上得重新聚类。实践中没人真重跑，于是图谱和现实越漂越远，知识库变成「永远停留在上周三」的快照。有句话说得很准：当数据持续演化时，维护一张全局图的开销，甚至可能超过初始构建。

第三笔：私有化成本

这个最要命。金融、医疗、政务、法务的数据不能出域，可 GraphRAG 那几轮重型抽取，要么依赖很强的云端大模型，要么得在内网私有部署一个足够强的模型来扛。无论哪种，都是钱和合规的双重压力。

三条加起来，就是企业里那句最常见的吐槽：

「GraphRAG 我们试过，效果好是好，就是用不起、改不动、上不了线。」

HippoRAG 2

HippoRAG 2通过知识图谱、Passage Node 和 Personalized PageRank 将传统向量检索升级为“关联记忆检索”，在多跳推理（Multi-hop Retrieval）、跨文档关联和复杂上下文理解场景下明显强于传统 RAG。

HippoRAG 2 本质上是在向量检索之外增加了一层“长期记忆网络”，解决的是关联推理问题，代价是引入了图构建、实体对齐和记忆维护等额外复杂度。

HippoRAG 2 在检索效率和推理能力之间找到了一个不错的平衡点，用较低的索引成本获得了接近图推理系统的效果。但对于企业场景来说，认知图谱仍然需要持续构建和维护，面对长期增量数据时，系统复杂度并没有完全消失。

SAG 的判断：把结构搬进检索本身

既然病根是「结构建了却用不上」，解法就清楚了——把结构化能力搬进检索执行本身，别在离线阶段把结构建死。

在离线阶段，每个数据块被转换为一个事件和一组实体，并写入 SQL、向量和全文索引。

在在线阶段，系统执行初始召回，然后进行查询时扩展，最后在压缩后的候选集中完成选择。

SAG 的核心结构很简单。对每个文档切片，它只抽两样东西：

一个事项（event）保留这个切片的完整语义，一组实体（entities）负责索引和桥接。

chunk -> event        # 一个完整事项，保留语义 chunk -> entities     # 多个实体，负责索引 event <-> entities    # 事项和实体之间多对多连接

理解它的关键在于：

事项和实体是对同一个切片的两类并列结果。

事项承载语义，实体只做索引和桥接，

两者通过数据库的关联查询连起来。

一个事项关联着好几个实体（人物、时间、地点、组织、产品……），这本来就是一张天然的关系网。

这就是 SAG 和 GraphRAG 最根本的区别。

GraphRAG 是「预先把整张图画好贴在墙上，谁动一下都得重画」；

SAG 是「查询的时候，根据这个问题，从命中的实体出发，沿着事项-实体的连接，临时算出一条链路」。

用企业能听懂的话说：

GraphRAG 像一家公司花半年画了一张巨型组织架构图贴在墙上，谁调岗都得重新画；

SAG 像一个查询系统，你问的时候它现查现算，「张经理 → 他去年签的客户 → 那客户今年的续约」这条线是按需长出来的，不动那面墙。

更妙的是，SAG 的多跳扩展就是数据库的关系扩展，靠 SQL 的关联查询，沿着共享实体在不同事项之间跳过去，默认只跑一跳。

它不需要图数据库那套重家伙，一个会做表连接的数据库就够。

三个角色各司其职：SQL、向量、LLM 谁干什么

SAG 还有个务实的设计：

把检索流水线拆成三个角色，各干各的活，谁都不越界。

SQL 负责确定性的过滤和连接——实体与事项的关联、多跳扩展，全靠数据库的关系查询，精确、可解释、便宜。

向量检索负责语义扩展——别名、近义词，比如「张经理」和「老张」、「续约」和「续签」，靠向量相似度桥接。LLM 只在最后压缩过的候选集上做一次精排——前面两路把候选从几十万压到一百个之后，它才出场。

这正好对应企业的成本账。

过去很多 RAG 动不动就把 LLM 塞进检索主路径，每一步都问模型、每一步都花 token。

SAG 反过来：能交给 SQL 的绝不交给模型，把贵的调用往后压，用在刀刃上。

还有个取舍值得说：

SAG 在实体处理上故意「够用即可」——只做简单字符串归一和查重，不追求完美的实体对齐。

这听起来像偷懒，其实很清醒：

真正承载语义的是事项，实体只是个「能桥接就行」的路标。

与其花大力气做完美实体对齐（GraphRAG 在这上面烧了不少钱），不如把预算省下来。

硬证据：跑分到底高在哪

在三个标准多跳问答数据集上，用相同配置（bge-large-en-v1.5 + qwen3.6-flash）和公认强基线 HippoRAG 2 对比：

MuSiQue 是公认最难的多跳数据集，SAG 把 Recall@5 从 65.13% 拉到 80.04%，绝对提升接近 15 个百分点。

三集平均 Recall@2 提升了 11.16 个点，相对提升约 16.4%。

这里有个细节值得企业的人多看一眼：

提升最猛的是 Recall@2，也就是「只检索两条就命中关键证据」的能力。

这直接意味着 Agent 能用更少的上下文、更早地把证据喂给模型——

在企业里这就是省钱，更少 token、更低延迟、长任务里更少被无关上下文干扰。

还有一个对照实验很说明问题。

把 embedding 换成更强的 NV-Embed-v2，MuSiQue 的 Recall@5 进一步到 81.71%，

HippoRAG 2 换上同模型是 74.55%。

换更强的模型当然能涨，但 SAG 的领先依然在。

这说明它的收益主要来自结构设计——对要私有化部署、模型选择受限的企业来说，这点很关键。

SAG 的强项是真正需要长链条、跨文档串联的多跳——而这恰好是企业里最难、最值钱的那类问题。

能不能在企业里真跑起来：看代码和规模

体验地址：https://wiki.zleap.com/search

跑分是研究的事，企业只认一件事：

这套东西能不能在自己机房里、自己数据上、自己模型上跑起来。

SAG 给了两个仓库。

一个是配套的 Benchmark 复现代码（github.com/Zleap-AI/SAG-Benchmark），带版本管理、带实验记录，是把评测脚本原样开源：

上传数据集：把评测数据转成 corpus，写入数据库和 ES

uv run python scripts/run_upload.py –dataset musique

跑复现 benchmark：多路召回 + 多跳扩展

uv run python scripts/run_search_benchmark.py
  –dataset-name musique
  –strategy multi
  –top-k 10
  –k-values “1,2,5,10” 
  –max-concurrency 10

复现脚本支持 MLflow 记录实验、支持固定数据源版本，输出 Recall、Precision、F1 完整评估。

可复现、可对账、可追溯，这是企业技术评审愿意看到的。

另一个是开箱即用的本地工作台（github.com/Zleap-AI/SAG）

技术栈是 TypeScript 全栈，数据层用 PostgreSQL + pgvector + 全文检索 + SQL 多跳，

模型侧兼容 OpenAI-compatible 接口——企业可以用自己私有部署的模型，数据完全不离开内网。

对企业落地，有几个设计尤其对路：

写入以 chunk 为并发单元。

这是「增量」成为原生能力的关键。每个切片独立抽取、独立入库，互不阻塞，等批处理、全局重算都不需要——当天改的合同，当天就能查到。

检索过程全程可视化。

每次提问，右侧面板实时展示走了哪条检索链路、多跳扩展到哪层、每步耗时多少。RAG 出问题时最头疼的是「不知道它为什么这么答」，能看到中间过程就能定位。

MCP 接入，做成 Agent 的数据底座。

工作台可作为 MCP Server 暴露给外部 Agent，企业内部的客服、风控、法务 Agent 共享同一套数据底座，文档抽一遍、多个 Agent 复用，各自存各自的。

是它已经在线上跑着一个约 5 亿条数据规模的 Wikipedia 检索 Demo（wiki.zleap.com/search），在线检索延迟保持在秒级以内。

PoC 拿两万份文档跑出效果不难，难的是五亿条数据在线上还能秒级响应。

这个规模证明 SAG 的「轻结构」在工程上真扛得住量。

把这几件事拼起来——可复现的 benchmark 脚本、能私有部署的工作台、

5 亿级在线验证、Agent 可复用的数据底座——它就是一份企业技术选型能拿去立项的材料，而远超一个论文里的 idea。

它的边界在哪，什么场景别用

第一，它依赖抽取质量。

SAG 的事项和实体是 LLM 抽出来的，模型太弱，抽取一塌糊涂，后面的检索全废。企业在私有化时如果想省钱用很小的本地模型，得先评估它的抽取质量能不能过关。地基不行，结构再巧也没用。

第二，简单场景它未必最优。

前面说过，2WikiMultiHopQA 上它的 Recall@5/10 反而略低。业务绝大多数是单跳、证据集中（比如纯 FAQ、单文档检索）时，普通向量检索甚至 BM25 就够，没必要上多跳结构。SAG 专为跨文档串联的长链条问题设计。

第三，长文档的切片仍是地基。

事项是按切片抽的，切片切得不好，事项就会残缺。这点和所有 RAG 一样，没有银弹。

第四，它需要 PostgreSQL + pgvector 这套基础设施。

比纯向量库（Milvus、Qdrant）重一点，但比 GraphRAG 要的图数据库加全套抽取管线轻得多。对已经用 PG 的企业，几乎零迁移成本。

诚实地说，SAG 要取代的，是那个「企业需要多跳、需要增量、需要私有化、需要扛规模，同时又想摆脱重图建图成本」的特定位置。

而这个位置，恰好是企业落地里最痛、最值钱的那块。

回到那个判断

文章开头说，企业 RAG 死在建不动、改不动、上不了规模。深一层看，真正的病根是：

你花了大成本建的结构，查询时根本没被用上。

SAG 给的解法就一句话：把结构化能力搬进检索执行本身，查询时按需长出一条链。

离线只建一层轻量索引，在线用 SQL 把多跳关系现查现算。结构重新变成查询时真正被执行的东西，而不再是挂在墙上的装饰品。

这个判断的可贵之处在于它敢做减法。

整个 RAG 圈这几年的默认动作是「加东西」——加更重的图谱、加更多的社区、加更强的模型。

SAG 反过来问：

真正必要的结构是什么？

能不能用最轻的那一版，把同样的事干成？

答案是能，而且跑分更好。

对企业技术选型的人来说，这里有个更实际的启示。

过去选 RAG 方案，主要看跑分和精度。

但真实的企业项目里，决定方案能不能活到第二年的，是建图成本、增量时效、私有化能力、规模上限这些东西。

跑分决定 PoC 漂不漂亮，工程指标决定系统活不活得下去。

我甚至觉得这件事还能往前看一步。

事项-实体的索引结构这么轻、又能持续增量写入，它天然适合做长期运行 Agent 的记忆底座——

带版本、带时间感知，能记住 Agent 三个月前查过什么、状态怎么演化的。

这或许是 RAG 之外，这套结构更远的想象空间。

但那都是后话。

眼下能确定的是：

RAG 下一轮的进步，大概率来自这种「把该重的地方重、该懒的地方懒」的拓扑取舍。

它代表的是一个方向，值得每个在企业里做 RAG 的人认真看一眼。