RAG系统回答单跳问题还行，一遇到需要串联多个文档的问题就歇菜。

"张三在哪家公司工作？这家公司的CEO是谁？"——两个简单问题串起来，大多数RAG系统就答不上来。原因很简单：向量检索按相似度排序，两个文档如果关键词不重叠，即使通过同一个人关联，也检索不到。

主流解法是建知识图谱。GraphRAG、LightRAG、HippoRAG 2都在做这件事——先把文档拆成三元组，构建全局图谱，然后在图上做多跳检索。

问题是：知识图谱贵、慢、难更新。每加一篇新文档，可能要重建社区结构、重新计算PageRank。

Zleap AI在8月提出的SAG（SQL-Retrieval Augmented Generation），走了一条完全不同的路：不建图谱，用SQL做结构化检索。在最难的多跳评测MuSiQue上，SAG的Recall@5达到80.36%，比最强的图谱方法高11.52个百分点。

把文档变成事件和实体

SAG的索引结构很简单：每个文档片段（chunk）被提取为一个"事件"和一组"实体"。

事件是这个chunk的核心陈述，比如"张三2024年加入ABC公司担任CTO"。实体是从中提取的结构化要素，比如"张三"、"ABC公司"、"CTO"、"2024年"。

一个事件绑定它的所有实体，形成一条"隐式超边"（latent hyperedge）。这跟知识图谱的区别在于：知识图谱把事件拆成多个三元组（张三-加入-ABC公司、张三-担任-CTO），拆着拆着语义就碎了。SAG保持事件完整，只在索引层做实体关联。

存储也很简单：事件和实体的多对多关系存到SQL表，事件文本和实体名分别建向量索引。新文档来了直接追加，不需要重建任何东西。

*图：NaiveRAG（向量相似度）、GraphRAG（离线知识图谱）和SAG（SQL事件-实体索引）的架构对比。来源：arXiv:2608.12129*

查询时用SQL激活关联

当用户提问时，SAG做三步。

第一步：种子检索。 两条并行路径：一条提取问题中的实体，通过SQL JOIN找到包含这些实体的事件；另一条用向量相似度直接搜索事件文本。两条路径的结果合并为种子集。

第二步：扩展。 从种子事件出发，取出它们关联的所有实体，再通过SQL JOIN找到共享这些实体的其他事件。这一步相当于在图上走一跳——但不需要图存在，因为所有关联都是SQL JOIN实时计算的。

第三步：选择。 把所有候选事件按向量相似度排序，取top-100交给LLM做上下文选择。LLM从候选中挑出最多5个能共同支撑答案的事件，剩余名额用直接向量检索填充。

关键设计是：返回给LLM的证据始终是原始chunk，不是事件摘要或三元组。这避免了信息损失——LLM看到的是完整的文档段落，而不是被压缩过的结构化数据。

推理链越长，优势越大

SAG在三个多跳基准上做了统一评测。所有结构增强方法用同一个embedding模型（BGE-Large）和同一个reader（Qwen3.6-Flash），只有检索架构不同。

| 方法 | MuSiQue R@5 | 2Wiki R@5 | HotpotQA R@5 |

|------|:---:|:---:|:---:|

| NaiveRAG (BGE) | 56.32 | 69.83 | 89.20 |

| GraphRAG | — | — | — |

| HyperGraphRAG | — | — | — |

| SAG | 80.36 | 最高 | 最高 |

*数据来源：arXiv:2608.12129 Table 1，Zleap AI，2026年8月*

趋势很清楚：推理链越长（MuSiQue最多4跳），SAG的优势越大。在2跳的HotpotQA上，各方法差距不大；到了4跳的MuSiQue，SAG比第二名高11.52个百分点。

原因是图谱方法在构建过程中会丢失信息——把n元事件拆成三元组时，共享事件边界的实体可能分离。而SAG保持事件完整，SQL JOIN只激活需要的关联，不引入噪声。

图谱方法的三个痛点

知识图谱RAG的三个老问题，SAG一个都没遇到。

构建成本高。 GraphRAG需要对整个语料库做实体识别、关系抽取、社区检测。一个中等规模的企业知识库可能需要几天才能构建完成。SAG的索引是append-only的——新文档来了直接提取事件和实体，追加到SQL表，不需要重新处理已有数据。

增量更新难。 图谱方法在文档更新时需要重新计算社区结构和图算法。SAG不需要——因为根本没有全局图，只有随时可以JOIN的索引表。

维护复杂。 知识图谱需要持续的实体消歧和关系校正。SAG刻意不做完整实体消歧——只靠字符串归一化和SQL去重。这是一个务实的工程选择：生产环境的语料库是脏的、持续增长的，要求全局消歧会阻塞索引流程。

源势AI观点

SAG的核心洞见很朴素：多跳检索需要的结构，不一定要预先建好。查询时按需激活，比离线构建全局图更灵活、更经济。

这个思路对Agent领域的知识管理有直接启发。Agent需要检索的不只是"相关内容"，还有"跨文档的关联关系"。传统RAG只能做到前者，知识图谱能做到后者但代价太高。SAG提供了一个中间路径：用轻量级索引保留关联信息，查询时用SQL做即时推理。

SQL做JOIN这件事，比图算法做社区检测简单太多了。大部分企业的工程团队都会写SQL，但不一定会维护知识图谱。SAG的工程可行性是它最大的优势之一。

需要注意的是，SAG目前只验证了问答场景。在需要全局语料库理解的场景（比如"这个知识库的主要主题有哪些"），GraphRAG的社区摘要仍然有价值。但对于Agent最常遇到的多跳检索问题，SAG提供了一个更轻量的解法。

---

来源标注：

1. Zleap AI, "SAG: SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges", arXiv:2608.12129, 2026年8月12日

2. MuSiQue/2WikiMultiHopQA/HotpotQA多跳评测基准

3. GraphRAG (Edge et al., 2024) / LightRAG (Guo et al., 2025) / HippoRAG 2 (Gutiérrez et al., 2025)