你肯定知道，Agent 的能力在过去两年变得越来越强。但你可能不知道，有一个 Agent 极为依赖的东西，它的能力却几乎没怎么变过：RAG 检索的准确率。
举个例子，在 MuSiQue（一个需要最多 4 跳推理的多跳问答基准测试）上，目前最强的结构化检索方案 HippoRAG 2，但是……它的 Recall@2 只有 49.5%。
这是什么概念呢？
你让 Agent 去查一个需要跨文档推理的问题，在用它返回的前 2 条结果里，有一半以上的答案根本不在里面。就好比你派了个实习生去档案室查资料，他翻半天弄回来两份文件后你一看，居然全是别的案子……
而 Agent 在发现查不到后，就会多查几轮，然后每一轮的误差就开始不断叠加。当它查到了五轮之后，可能已经偏到十万八千里去了……
那，怎么办呢？
便是今天要介绍的：来自 Zleap AI 团队的 SAG（SQL-Retrieval Augmented Generation）。它把 MuSiQue 上的 Recall@2 从 49.5% 暴力拉升到了 64.1%，Recall@5 则直接干到了 80.04%。
在三个多跳基准测试上的平均 Recall@2 为 79.3%，领先了 HippoRAG 2 11.1 个百分点。
并且，这并不只是停留在论文里的模拟数字，SAG 已经在 5 亿级数据规模的生产环境中稳定运行。论文、Benchmark 复现代码、在线 Demo 均已公开。
只会看脸
传统向量 RAG 的逻辑简单好理解：把每段文本变成一个向量，当问题来了，就找几段最「像」的文本。
它优势是：快、便宜、好部署。在许多简单问答的场景下，确实是够用的。
但它有个根本性的短板在于：向量搜索只知道「像不像」，不知道「谁跟谁有关系」。
这个问题的答案，分散在三篇完全不同的文档里。单独拿出其中的任意一篇，和你的问题都不太「像」。只有连起来，才是完整的答案。
向量 RAG 稳定找到这条链的概率，可以说是……相当之低。
因为，它只会「看脸」，不会「顺藤摸瓜」。
GraphRAG 看到了这个问题，它的思路是：先从文本里把实体和关系抽出来，建一张知识图谱，沿着图谱做多跳检索。
方向应该是对了。但……
图谱太重
GraphRAG 会把文本拆成三元组：「OpenAI → 发布 → GPT-5」「GPT-5 → 属于 → LLM」「发布 → 时间 → 2025年」。
它的每一步都要靠 LLM 来抽取实体、归一化名称、合并重复、发现社区、最后生成摘要。
跑一遍，又慢又贵。
而麻烦的在后面：这个世界并不是一成不变的。新的实体、新的关系会不断出现，而旧关系也可能过时。如何有效更新，也是个问题。
HippoRAG 2 是目前结构化 RAG 里公认的强基线，它证明了 RAG 必须结合结构化记忆和多跳检索，这在大方向上倒没什么问题。
但 HippoRAG 2 依赖全局 Personalized PageRank 来做图排序，这在 benchmark 规模下还行，一旦数据量上来并且每天增量增长，全局 PageRank 的负担就会相当的大了。
打个比方，你每次往图书馆加一本新书，就得把整个图书馆的书重新排列一遍。
实践中则是，Agent 的数据底座必须支持持续写入、持续更新。
每来一批新数据，就要全局重建？这显然也不太行……
索引卡片
于是，SAG 换了个思路。
不建图谱，不做三元组，不搞全局图。
它给每个文本 chunk 加了一张「索引卡」：
event 保留完整语义，entity 负责索引和连接。
两者通过 SQL 的关联查询建立多对多连接，共同定义了一条潜在的超边。
这和三元组路线有着本质的区别。
三元组是「头实体 → 关系 → 尾实体」，把一件完整的事拆得支离破碎。拆碎之后，质量高度依赖每条「关系」抽得准不准。
同一件事，不同模型可能抽出「使用」「基于」「提出」「支持」四个不同谓词。到了真实数据里，这种差异会被迅速放大，一发不可收拾。
但 SAG 只让 LLM 做两件相对稳定的事：
把一个 chunk 总结成一个完整的事项，同时从原始 chunk 里应提尽提地抽取实体。
事项保留上下文，实体负责桥接。
在图结构上，这更像超图中的超边：一个 event 同时连接多个 entity。不像两点之间的一条线，更像一件事把所有相关的人、地点、组织、时间全部串在一起。
原因在于 RAG 到最后还是要回到原文证据，三元组太碎，容易丢上下文。而 SAG 的 event 则保留了上下文，同时提供了可检索、可扩展的结构。
我（让 Codex）翻了一下它的代码，也发现有一个细节是：SAG 在抽取 event 时，会强制做代词消歧。子事项必须把所有的「他」、「该公司」、「这个产品」替换成完整名称。从而每个 event 就是一段独立可搜的完整描述，不依赖上下文就能被理解。
跟着线索跳
SAG 分两步：离线写入，在线检索。
离线阶段，系统把文档切成 chunk，每个 chunk 提取一个 event 和多个 entity，写进 MySQL，同时写入 Elasticsearch 的向量索引和全文索引。
这里有一个细节是，每条 event-entity 关系自身也带有一段描述文本，还有自己的 embedding 向量。
同一个实体「OpenAI」在不同 event 里的角色描述可能完全不同，「OpenAI，发布 GPT-5 的公司」和「OpenAI，Sam Altman 创立的公司」在向量空间里是不同的点。
这也让实体的召回变得更加精准了。
在线检索是重点。
问题进来后，LLM 先从问题里识别出关键实体。然后走两条路并行：
为什么要两条路呢？路径 A 通过实体关联覆盖结构化的多跳线索，路径 B 通过语义匹配覆盖直接相关的事项。两者在证据召回上高度互补。
论文的消融实验也印证了这一点：纯语义路径的 Recall@5 只有 56.2%，而加入少量结构化路径的事项候选后，就直接飙到了 80.0%。
这就是多跳。
实现方式上，用的只是 SQL 里的关系扩展，不需要全局 PageRank，不需要让 LLM 临时推理一张图。
就是数据库里的 JOIN，而已。
SAG 提供了两个使用模式：快速模式省掉 LLM 精排，便于追求速度。高精度模式加一步 LLM 重排序，更追求准确率。两者都用到了 event/entity 索引和多跳检索，核心架构上是一样的。
新 SOTA
那么，SAG 的效果怎么样呢？
在 HotpotQA、2WikiMultiHop、MuSiQue 三个多跳基准测试上，同样的 embedding 模型（BGE-Large-EN-v1.5）和 LLM（Qwen3.6-Flash）配置下：
相当于每 3 次查询，SAG 就能比 HippoRAG 2 多命中 1 次关键证据。对 Agent 来说，对应的则是更少的无效查询，更短的推理链路，更低的 token 消耗，更能扛的订阅额度……
你可能会问：为什么 Recall@2 比 Recall@10 更重要呢？
这应该很好理解啊哥…… Agent 显然不希望每次拿回一大堆上下文再自己挑，那 context 几下就干满了…… Agent 需要的是，在更少的返回结果里更早拿到关键内容。否则后面 LLM 要读更多内容，成本高、延迟高、干扰也多。
在三个数据集里最难的 MuSiQue，包含最多 4 跳推理，且每条推理链都不可跳过，跳过就会失败。SAG 在这上面的优势也最为突出，这也利益于 event/entity 索引在复杂关联问题里发挥的作用。
论文里还有一组关键的消融实验：超边 vs 三元组。
更简单的结构，反而效果更好。
原因在于，三元组只保留了部分语义，向量检索容易匹配到与查询关键词重合但实际上无关的片段。而完整事项将多个实体压缩在一条超边内，多跳扩展时等效连接更密，每一步累积的误差也更小。
还有一组对比是，HippoRAG 2 原论文使用的是更强的 NV-Embed-v2，在 MuSiQue 上 Recall@5 达到了 74.6%。但当换成 BGE-Large-EN-v1.5 后，直接掉到了 65.1%，损失近 10 个百分点。
而 SAG 在同样的 BGE-Large-EN-v1.5 下跑出 80.0%，换成 NV-Embed-v2 后升到 81.7%，几乎不受影响。
从这个不对称的结果中可以看到：HippoRAG 2 的高分很大程度上依赖更强的嵌入模型，而 SAG 的增益，主要来自算法结构本身。
五亿条也能跑
我们知道，学术 benchmark 上好看是一回事，能不能在生产环境里跑起来，则又是另一回事了。
SAG 有几个天然适合规模化的特点。
简单到听起来有些草率，完全不像是实力派……但这也正是 SAG 的鲁棒性：即使只靠简单的字符串校验，超边结构也已经能跑出 SOTA 的效果。毕竟 entity 在 SAG 里本质上就是索引点，真正保留语义的是 event。
这更像数据库的增量写入，跟图谱的全局重建完全是两种思路。
Zleap AI 团队已经在实际生产中积累了 5 亿级的数据量，而且还在持续增长。在这个规模下，SAG 仍然稳定运行，在线检索延迟保持在秒级以内。
为了让大家直观体验，团队还做了一个 Wikipedia 的 SAG Demo：https://wiki.zleap.com。把 Wikipedia 的数据放进 SAG，你可以直接测试多跳检索效果。
Demo 支持快速模式和高精度模式，输入一个多跳问题，SAG 会实时构建局部超边图谱，从维基百科中找出跨文档的关联证据。
Agent 最佳底座
可以说，SAG 是面向 Agent（目前）的最佳数据底座。
我们知道，Agent 和普通问答系统不同，普通问答系统检索一次答一次，而 Agent 往往要连续查很多次，先查一个线索，再根据线索查下一个，再根据新结果决定下一步。
检索准确率在这个场景下，就显然不只是个体验问题了。它会直接关系到整条任务链路的稳定性。
如果第一次查错了，后面的推理就建立在错误材料上；而如果第一次没查到，Agent 就可能会换一个错误方向继续查。在复杂任务里，这种错误会不断叠加、放大，然后失败。
而同时，Agent 的记忆能力是 SAG 天然适合的另一个场景。
Agent 的记忆并不是由孤立文本组成，同一个用户、项目、偏好，可能在不同时间反复出现。且新的记忆可能补充、修正，甚至推翻旧的记忆。
纯向量记忆更像是在找相似文本。但 Agent 其实需要知道的是：哪些是历史背景，哪些是当前状态。
SAG 的结构对这个问题来说也是非常地合适：event 保留完整事项，entity 把同一个人、项目、任务连接起来，再在 SQL 里加上时间和关联 id，就能区分出新旧状态。
用 SAG 来做记忆，是因为它本身就在给数据建立「事项 + 实体 + 时间 + 关系」的索引。
RAG 要解决的核心问题，在于数据进入 Agent 系统时应该被组织成什么样子。
SAG 给出的答案是：
用 event/entity 给原始数据加一层轻量索引，用 SQL 做多跳检索，让数据可以增量写入、并发处理、持续增长。
