论文链接：https://arxiv.org/abs/2606.15971
大家好，我是 Jomy。 今天，我们 SAG 论文的 V2 版本正式发布。
V1 发布以后，我们继续做了两件事：改进扩展阶段的剪枝，把大家关心的机制、效果和规模问题做成更完整的实验。
改进以后，SAG 在 MuSiQue、2WikiMultiHopQA 和 HotpotQA 的 Recall@5 与端到端问答 F1 上全部达到 SOTA。V1 唯一落后的 2WikiMultiHopQA，也从 88.00% 提高到 93.34%。
今天，我也会集中回答几个大家最关心的问题，希望可以解答一些质疑。
全部SOTA
相同设置下，SAG 前 5 条结果的证据召回率（Recall@5）和端到端问答 F1
在 MuSiQue、2WikiMultiHopQA 和 HotpotQA 上，SAG 的 Recall@5 分别为 80.36%、93.34% 和 96.50%，平均值为 90.07%。
端到端问答使用相同回答模型。SAG 的 F1 分别为 61.15、78.06 和 79.66，平均 F1 为 72.96，三个数据集均达到 SOTA。
V1 发布后，有人关心 SAG 是否过拟合了 MuSiQue。我们一直重点看 MuSiQue，因为它最长包含四跳推理，并经过反事实过滤，是三套数据中最难的一套。
这次，我们重新运行了大部分主流 RAG 框架，并在统一设置下完成对比。结果显示，SAG 在 MuSiQue、2WikiMultiHopQA 和 HotpotQA 三个数据集上，从 Recall@5 到端到端问答 F1 全部领先。我们还在多个私有生产环境数据集上做过对照，SAG 的表现也保持最佳。
Benchmark 代码已经开源，大家可以直接复现，也欢迎在产品中体验。
SAG怎么工作
离线保存 event 与 entity 的关系，查询时扩展相关 event，最后返回原始 chunk。
SAG 先把文档切成一个个 chunk。每个 chunk 只做两件事：整理成一个语义完整的事项 event，再提取其中的人、组织、地点、产品等实体 entity。
event 负责保留这段内容讲了什么，entity 负责把不同文档里的相关事项连接起来。它们会写入 SQL、向量索引和全文索引。每个 chunk 都可以独立处理，新数据来了直接追加，已有数据不用重新计算。
查询时，SAG 同时走两条路。一条根据问题里的 entity 找 event，另一条直接根据问题的语义找 event。找到第一批 event 以后，系统再沿着共享 entity 找到更多相关事项。
最后，SAG 把选中的 event 映射回原始 chunk，再交给模型回答。event 只负责找证据，回答依据始终来自原文，生成答案也不会自动写回索引。
SAG只是把知识图谱换成SQL了吗？
先说结论：SAG 确实在建图。它采用动态超边结构，而非传统的三元组图谱。
传统知识图谱以“主体—关系—客体”三元组为基本单元。一件事涉及多个人、组织、地点和时间时，通常会被拆成多条关系。SAG 以语义完整的 event 为基本单元，让一个 event 同时连接多个 entity。
这是 SAG 与传统三元组图谱的根本区别，也是我们的核心创新。
SQL 负责执行关系查询。event 与 entity 在数据库中是多对多关系，两个 event 共享同一个 entity，就有一条可以被 JOIN 找到的关联。SQL 本身不会产生语义，语义来自 event-entity 的组织方式。
为什么这套方法到现在才变得可行？因为 LLM 已经能够把一个 chunk 稳定地整理成语义完整的 event，并提取足够多的 entity。早期的 NER 和三元组抽取很难同时保留完整语义与跨文档连接。
不同方法的索引连通性。
我们在 V2 里专门做了索引连通性实验，比较不同方法的孤立节点、连通分量和最大连通分量，看看动态超边能否用更少的连接覆盖更多内容。
MuSiQue 上，SAG 在 95,341 个节点中只有 1 个孤立节点，占比约 0.001%；最大连通分量覆盖 96.7%。HippoRAG 2 的连接数约为 SAG 的 4.5 倍，仍有 59 个孤立节点。
这就是动态超边在结构上的优势。一个 event 可以同时把多个 entity 纳入关系，SAG 用更低的连接密度，让几乎全部内容都进入可扩展的索引。
数据库中的多行记录只是超边的物理存储方式，共同的 event_id 可以恢复完整实体集合。查询到来以后，系统只调用与当前问题相关的一小部分超边，“动态”指的就是这个过程。
SAG 和 LLM Wiki 的区别很明确。LLM Wiki 本质上仍然是摘要索引：根据摘要或标签找到文档，检索过程到这里就结束。后续需要把大量文档放进 LLM 的长上下文，由模型继续阅读、筛选和推理。数据越多，需要进入上下文的内容越多，速度、Token 成本和最终效果也越来越依赖模型能力。
SAG 在进入模型之前还会继续检索。系统沿共享 entity 找到新的 event，再返回真正支持答案的原始片段。这样，LLM 只需要处理少量高相关证据，上下文更短，对模型能力的依赖也更低。SAG 把大部分工作放在数据组织和检索阶段，不把所有问题都留给模型解决。
一层扩展真的能解决多跳问题吗？
针对这个问题，我们在 V2 里做了两个实验。第一个实验直接关闭扩展，看扩展能否补回多跳证据；第二个实验把扩展深度从 L=0 调整到 L=4，看一层扩展与更深扩展之间还有多大差距。
先看第一个实验：关闭扩展。
MuSiQue 上的关键设计消融。
关闭扩展后，MuSiQue Recall@5 从 80.36% 降到 69.41%，Recall@1 只从 36.82% 变为 35.70%。这说明种子召回通常已经找到第一篇证据，扩展主要负责补回证据链后面的桥接内容。
SAG 的一层扩展会先从种子 event 取出相关 entity，再通过这些 entity 找到新的 event。这个查询流程负责补回桥接证据；动态超边把同一事项中的多个 entity 保留在一起，让扩展获得更完整的关联信息。
同一组消融只把底层超边换成独立三元组，SAG 的召回、扩展和最终选择流程保持不变，Recall@5 从 80.36% 降到 77.61%。结果表明，动态超边的表示能力优于独立三元组；同时，由于一层扩展、双路召回和最终选择仍然发挥作用，整体下降幅度有限。
把 LLM 联合选择换成逐条评分的 Qwen3-Reranker-8B 后，Recall@5 降到 67.11%。一层扩展负责找回多跳素材，LLM 负责从候选中选出能够组成完整证据链的内容。
再看第二个实验：调整扩展深度。我们把扩展深度从 L=0 一直增加到 L=4，同时测试候选 event 数量和结构路径输出数量。
扩展深度与候选预算实验。
结果很直接：从 L=1 增加到 L=4，Recall@5 只从 80.36% 变化到 80.71%。超边在第一层已经展开了足够多的关联，继续增加深度带来的提升很小。
两个实验放在一起，结论就很清楚：关闭扩展后，Recall@5 会下降 10.95 个百分点；从一层增加到四层，只提高 0.35 个百分点。多跳证据主要由第一层扩展找回，继续增加深度的收益已经很小。
既然扩得更深帮助不大，重点就变成了第一层应该保留哪些候选。V2 的剪枝改进发生在这里：新的保留策略减少了桥接 entity 过早退出候选的情况，2WikiMultiHopQA Recall@5 因此提高了 5.34 个百分点。
不做实体合并，会影响效果吗？
SAG 没有采用复杂、耗时的全局实体合并流程。索引阶段，每个 chunk 都独立提取 event 和 entity，随后只做字符串归一和 SQL 去重。不同 chunk 之间没有前后依赖，可以用高并发同时处理，从而加快大规模数据的入库速度。新增数据也可以直接追加，无需重新处理已有数据。
没有复杂的全局实体合并，不代表查询只能依赖完全一致的字符串。SAG 在查询时会同时走两条召回路径。
第一条是 entity 路径。我们先从问题中提取关键 entity，再通过实体向量检索找到高度相似的表达，默认相似度阈值为 0.9，然后用 SQL JOIN 找回相关 event。在索引阶段，我们也要求模型尽量提取实体的全称、缩写和别名，增加不同表达被找到的机会。
第二条是 event 路径。系统直接用问题向量召回语义相关的 event，不依赖实体名称能否匹配。即使某个别名没有对齐，相关 event 仍然可以先进入种子集合，再参与后续扩展和选择。
两个检索案例，展示 entity 路径和 event 路径如何共同召回证据。
第一个案例中，种子召回先找到两篇正确证据，再通过共享 entity「Venice」扩展到第三篇正确证据。第二个案例没有找到可用于扩展的共享 entity，但 event 路径仍然直接召回了两篇正确证据。
所以，SAG 不要求先完成全局实体合并。匹配明确的 entity 用来建立跨文档连接，event 语义召回负责补充没有形成实体连接的内容，动态超边继续扩展桥接证据，最后再从候选集合中选出完整证据链。SAG 的检索效果来自这几个环节共同工作。
当然，别名没有对齐时，仍然可能漏掉一部分实体连接。生产环境中，我们可以增加一张轻量的别名表，把常见的全称、简称和别名关联起来，进一步提高召回效果。这种补充不需要进行全局实体消歧，也不会影响数据的持续写入。
数据到了数亿条，查询成本还能控制吗？
能。生产环境中，SAG 先用向量相似度排除明显无关的数据，只保留前 Kpool 个高相关 chunk。实体扩展、SQL JOIN 和 LLM 选择都在这个候选池内完成，真正进入计算的数据量始终受预算控制。
这一步使用 Elasticsearch 的 HNSW 近似搜索，无需把查询向量和所有向量逐一比较。HNSW 找到高相关候选后，SAG 再在小范围内计算关系。
V2 专门测试了候选池大小。MuSiQue 全量 11,656 个 chunk 的 Recall@5 为 80.36%；只保留 500 个时达到 79.57%，相当于全量结果的 99%。约 1% 的性能损耗换来 95% 以上的计算范围缩减。
语料从 11,656 个 chunk 增长到 11,656,000 个时，Kpool 和 Kcand 仍可保持不变，SQL 扩展和 LLM 选择的工作量不会同步放大 1,000 倍。
HippoRAG 2 的全局 Personalized PageRank 需要在不断扩大的图上执行传播与排序。SAG 把查询限制在局部工作集内，规模增长主要交给数据库索引。
固定工作集解决了数据规模扩大后的查询成本，接下来还要看精度会不会随着数据增长明显下降。真实生产数据每天都在增加，所以我们在 V2 中固定评测问题，持续向语料库加入内容，模拟这一过程。
从左到右：候选池大小、四种 embedding，以及语料持续增长时的结果。
加入更多语料后，NQ 的结果整体稳定；MuSiQue 的精度只轻微下降，并始终保持领先。SAG 面对持续增加的数据仍然稳定。
图中间测试 embedding 鲁棒性。更换四种 embedding 后，SAG 的结果变化很小；使用 BGE 和 NV-Embed-v2 时，Recall@5 分别为 80.36% 和 81.71%。优势来自动态超边和检索流程，不依赖某个特定模型。
SAG 的索引采用仅追加写入，新增语料不用重新处理已有数据。生产系统可以持续写入，并保持秒级检索。
SAG和Agentic RAG是什么关系？
SAG 本身就可以 Agentic，我们称为Agentic-SAG。
这里要先区分论文里的高精度模式和生产环境里的 SAG-Lite。
Benchmark 保留最后一步 LLM 精排，是为了尽量减少轻量排序器对结果的限制，更完整地验证动态超边和一层扩展能否找回多跳证据。
MuSiQue 高精度模式的离线索引成本，以及 1,000 个问题的平均在线成本。
Kcand 控制最后一步交给 LLM 精排的候选 event 数量。Kcand=100 时，Recall@5 为 80.36%，F1 为 61.15；把 Kcand 减到 50 后，Recall@5 为 79.35%，F1 为 60.41。候选数量减少一半，Recall@5 只下降 1.01 个百分点，F1 只下降 0.74。
成本下降更明显。Kcand 从 100 减到 50 后，单次查询的 Token 从 11,536 降到 8,236，减少约 28.6%；平均端到端时间从 25.03 秒降到 22.68 秒，减少约 9.4%。这组数字描述的是论文里的高精度模式。
这说明大部分有效证据在种子召回和一层扩展后，已经进入前 50 个候选。继续扩大 Kcand，可以给最终选择更多余量，但带来的分数提升很小。单轮检索因此可以使用较小的候选池，同时保留大部分效果。这正是 Agentic-SAG 能够成立的基础。
真实工程使用 SAG-Lite。它去掉最后一步 LLM 精排，改用 RRF 快速融合 SQL、向量、全文和结构路径的排序结果。RRF 不需要模型推理，速度和成本都更稳定。
Agent 会围绕问题多次调用 SAG-Lite，每一轮使用一个小候选池，并根据当前找到的证据继续调整下一轮查询。不同轮次的候选通过 RRF 合并，再交给回答模型生成答案，同时输出对应证据。这样，每一轮的成本都受到控制，多轮检索又可以覆盖不同的方向和证据链。这就是我们实际使用的 Agentic-SAG。
Zleap 个人版 https://github.com/Zleap-AI/Zleap-Agent 已经开源，个人版和企业版目前都在使用这套 Agentic-SAG 模式，欢迎大家下载体验。
企业知识的基础设施
我们做 Zleap，核心目标一直是推进企业的 AI 化。
企业 AI 化通常从模型、Agent 和自动化流程开始。但 Agent 能做什么，首先取决于它能看到什么。
企业真正有价值的知识，分散在文档、会议、聊天记录、客户系统、代码库和每天发生的业务过程里。很多信息没有被整理，有些信息互相关联，还有些信息每天都在变化。企业拥有这些知识，不等于 Agent 能够准确找到、理解和使用它们。
所以，企业 AI 化需要先解决一个基础问题：建立一套动态的、能够承载海量数据的企业知识基础设施。
这套基础设施需要持续接入新数据，保留知识之间的关系，并在需要时快速找到准确证据。数据规模增加以后，查询成本和检索精度也要保持稳定。
过去，SQL 关系型数据库擅长保存确定性关系，向量数据库解决了语义检索。两种能力长期存在于不同的系统里。LLM Wiki 进一步尝试用摘要索引文档，再把检索结果交给模型理解。
数据量较小时，这些方法可以工作。到了海量数据规模，把大量摘要和文档交给模型处理，会让上下文不断增长，延迟和 Token 成本也难以控制。企业知识基础设施不能长期依赖模型读取更多内容来维持效果。
SAG 把关系和向量重新放进同一套架构。
向量检索先找到语义相关的范围，动态超边保存事项之间的完整关系，SQL 在局部数据中完成确定性扩展，最后只把少量高相关证据交给模型。数据可以持续写入，查询始终在受控范围内进行，回答也可以回到原始证据。
目前，基于 SAG 机制的生产系统已经在持续接入和处理企业数据。企业每天产生的新知识，可以进入同一套系统，并被后续的 Agent 调用。
SAG代表了我们对下一代企业知识基础设施的判断：轻量、确定性关系和可持续增长的数据结构，需要在同一套系统中协同工作。
基于 SAG，我们会继续建设 memory、context infra 和 Agent 运行时，让 Agent 能够理解企业的历史、当前状态和正在发生的变化，并参与真实业务。对所有企业来说，这就是推进企业 AI 化的起点。
SAG 企业版已经推出，有兴趣的企业可以在公众号内或官网给我们留言。
论文与代码：
