RAG 开始“顺藤摸瓜”了：SAG 会取代 GraphRAG，还是又一个被高估的新范式？
过去两年，RAG 几乎成了企业接入大模型的标准配置。
把文档切成若干片段，生成向量，用户提问时召回几个相似片段，再交给大模型生成答案——这套流程简单、稳定，也足够实用。
但当问题从“这份文档说了什么”，升级为“几份不同文档之间到底发生了什么关系”时，传统 RAG 很快就会暴露出短板。
例如：
A 公司收购了 B 公司，B 公司原来的技术负责人后来加入了 C 项目，而 C 项目又属于 D 集团。请问，收购 B 公司的企业与 D 集团之间存在什么间接联系？
回答这个问题，需要系统在多份文档之间依次找到“收购关系”“人员关系”和“项目归属关系”。单纯依靠向量相似度，很可能只能召回其中一两个片段，无法稳定拼出完整链路。
GraphRAG 试图用知识图谱解决这个问题，而近期提出的 SAG，则选择了另一条路线：
不提前构建完整的全局图谱，而是把文档转化为事件和实体，在查询发生时，通过 SQL 动态激活局部关系。
这看起来像是一次从“相似内容检索”向“关系驱动检索”的转变。
但 SAG 究竟带来了什么？它真的解决了 GraphRAG 的维护难题吗？它的实验结果又是否足以证明这种架构会成为下一代 RAG？
答案没有宣传材料说得那么简单。
一、传统 RAG 的真正问题，不只是“召回不准”
传统 RAG 的基本链路通常是：
文档切分 → 向量化 → 相似度检索 → Top-K 片段 → 大模型回答
它最擅长的是局部、明确、语义接近的问题。
例如用户问：
产品退款规则是什么？
只要文档中存在内容相近的“退款规则”段落，向量检索通常就能快速找到答案。
传统 RAG 的优势非常明显：
- 架构简单，开发和维护成本低；
- 向量数据库已经非常成熟；
- 新增文档时只需切分、向量化和写入；
- 对单文档问答、制度查询和产品说明等场景已经足够有效；
- 查询速度快，容易控制模型调用成本。
所以，传统 RAG 并没有过时。相反，它仍然会长期作为企业知识检索的基础能力存在。
它的问题主要出现在三个方面。
1. 相似并不等于相关
向量检索判断的是文本在语义空间中是否接近，却不真正理解实体之间的业务关系。
“张三担任甲公司的 CTO”和“乙公司收购了甲公司”，两个片段在文本表达上未必相似，但它们可能是回答某个问题时必须组合的两条证据。
传统 RAG 很难主动沿着“张三—甲公司—乙公司”这样的路径继续寻找信息。
2. 检索结果通常是零散片段
传统 RAG 返回的是一个片段列表，而不是一条组织好的证据链。
大模型需要自己判断：
- 哪些片段属于同一件事；
- 哪些实体是同一个对象；
- 信息之间是时间关系、因果关系还是组织关系；
- 哪些片段只是碰巧提到了相同关键词。
当召回片段较多时，大模型不仅成本上升，还可能被无关上下文干扰。
3. 多跳问题容易出现错误累积
第一次检索没有找到正确的中间实体，后续推理就没有继续展开的入口。
这也是为什么单次向量召回在简单问答上表现不错，但在跨文档、多实体、多步骤的问题上容易失效。SAG 论文同样将传统密集检索的主要问题概括为：擅长发现语义相近内容，却难以稳定恢复实体之间的显式关联链。
二、GraphRAG 做对了什么，又付出了什么代价？
GraphRAG 的核心思想，是提前从文档中提取实体、关系和主题，把原本彼此独立的文本片段连接成图。
典型过程包括：
文档解析 → 实体识别 → 关系抽取 → 实体合并 → 图谱构建 → 图检索或社区摘要 → 大模型生成
这样做的优势是，系统不再只知道“哪些文本相似”，还知道：
- 某个人属于哪家公司；
- 某家公司收购了谁；
- 某个产品依赖哪些技术；
- 某项决策由哪些事件推动；
- 哪些实体属于同一个关系网络。
GraphRAG 因而更适合两类问题。
第一类是多跳关系问题，例如沿着人物、组织、项目和事件持续寻找证据。
第二类是全局认知问题，例如：
这一批文档的主要主题是什么？
哪些组织在整个事件中发挥了核心作用？
整个知识库中存在哪几类主要矛盾？
微软最初提出的 GraphRAG，重点之一正是解决传统 RAG 难以回答的“全局性问题”。它通过实体图谱、社区划分和社区摘要，让系统能够对整个语料库进行主题归纳，而不是只返回局部相似片段。
因此，把 GraphRAG 简单描述成“静态三元组图谱”并不完全准确。
GraphRAG 是一个较大的技术类别，既包括实体关系图，也包括社区摘要、层级结构、路径检索和图排序等不同实现。
但它确实面临较高的建设和维护成本。
GraphRAG 的主要代价
首先，图谱构建不是简单的数据导入。
系统通常需要完成：
- 实体提取；
- 关系提取；
- 同名实体消歧；
- 别名合并；
- 关系标准化；
- 冲突检测；
- 社区重新划分；
- 摘要重新生成。
其中任何一步出现错误，都可能污染后续图结构。
其次，全局结构对数据更新较为敏感。
新增一份文档并不只是增加几个节点，还可能改变实体关系、社区结构和摘要内容。对于新闻、销售记录、客服会话、项目进展等持续变化的数据，频繁维护全局图谱可能变得昂贵。
再次，离线构建出的复杂结构，不一定能在查询阶段被充分利用。
有些系统花费大量成本建立图谱，但最终仍然把图节点转换成向量，再进行一次相似度检索。结果是离线阶段高度结构化，在线阶段却重新退化为平面召回。
这正是 SAG 试图改变的地方。
三、SAG 的创新：不提前画完整地图，而是查询时临时连线
SAG 的全称是：
SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges
更准确的中文表达是：
基于 SQL 检索和查询时动态超边的增强生成架构。
它并不是完全不构建结构，而是不构建一个需要长期维护的完整全局知识图谱。
SAG 在数据写入阶段，会把每个文档片段转化为两个部分。
第一部分：事件
事件是对当前片段核心语义的完整概括。
例如原文是：
2025 年 3 月，甲公司以现金方式收购乙公司，乙公司原管理团队继续负责产品运营。
系统可能将其表示为：
2025 年 3 月，甲公司收购乙公司，并保留乙公司的原管理团队负责产品运营。
这个事件尽量保留完整语义，而不是拆成多个彼此孤立的三元组。
第二部分：实体
系统同时抽取事件中可用于检索和关联的实体，例如：
- 时间：2025 年 3月；
- 组织：甲公司、乙公司；
- 动作：收购；
- 主题：产品运营；
- 群体：乙公司原管理团队。
SAG 论文默认定义了时间、地点、人物、组织、群体、主题、作品、产品、动作、指标和标签等11类实体，并允许针对业务领域进行扩展。
事件负责承载完整语义，实体主要负责建立索引和关联入口。
在存储上，它形成的并不是传统意义上的完整知识图谱，而是类似以下结构的关系表：
- 文档片段表；
- 事件表；
- 实体表；
- 事件与实体关联表；
- 向量索引；
- 全文索引。
一个事件可以关联多个实体，因此可以被看作一条尚未真正展开的“潜在超边”。
四、SAG 查询时到底做了什么？
用户提问后，SAG 并不是直接执行一条复杂 SQL 得到答案，而是分成三个阶段。
第一阶段：找到关系入口
系统一方面从问题中提取人物、组织、时间、地点等实体，另一方面直接对问题进行事件向量检索。
也就是说，它同时走两条路径：
- 通过实体寻找结构化入口；
- 通过向量寻找语义相近事件。
这样可以避免纯实体匹配过于严格，也能避免纯向量检索缺少关系能力。
第二阶段：沿共享实体扩展
假设第一个事件关联了“甲公司”和“乙公司”，系统就可以通过 SQL Join 找到其他包含这些实体的事件。
随后，再提取新事件中的实体，继续寻找下一批事件。
其逻辑大致类似：
问题实体 → 相关事件 → 事件中的其他实体 → 新事件 → 新实体
SAG 将这种在查询时形成的局部多实体关系称为“动态超边”。
需要特别说明：
SQL 本身并没有在进行人类意义上的推理。
SQL 执行的是确定性的过滤、连接和候选扩展。真正的语义判断仍然依赖实体提取模型、向量召回和最终的 LLM 排序。
因此，把 SAG 描述成“SQL 推理引擎”并不严谨。更准确的说法是：
SAG 使用 SQL 完成可控、可追踪的关系检索，再使用大模型完成语义选择和证据组合。
其在线链路包括实体识别、向量别名扩展、SQL 多跳连接、候选压缩和 LLM 重排序。
第三阶段：压缩候选并重新排序
SQL 扩展可能得到较多候选事件。
SAG 会先使用向量相似度进行粗排，再把压缩后的候选集合交给大模型进行最终筛选，最后映射回原始文档片段。
因此，SAG 并不是用 SQL 取代向量数据库和大模型，而是重新分配三者的职责：
- SQL：处理明确条件和实体连接；
- 向量检索：处理语义相似、别名和近义表达；
- LLM：处理高价值的语义判断和最终排序。
这才是 SAG 最值得关注的地方。
五、传统 RAG、GraphRAG 与 SAG 的核心差异
三种方案并不是简单的前后替代关系，而是分别优化了不同问题。
传统 RAG：以文本相似度为中心
它回答的是：
哪些文本片段和当前问题最相似？
优势是简单、便宜、快速。
不足是无法稳定组织跨文档关系。
GraphRAG：以全局知识结构为中心
它回答的是：
整个知识库中有哪些实体、关系、社区和主题结构？
优势是全局关系清晰，适合稳定知识、主题归纳和全局分析。
不足是建设和维护成本较高，更新过程更复杂。
SAG：以查询时局部关系为中心
它回答的是：
围绕当前问题，哪些事件可以通过共享实体临时连接起来？
优势是无需提前枚举全部关系，新增数据可以相对独立地写入。
不足是每次查询都要承担关系扩展和候选筛选成本，而且关系质量高度依赖事件和实体抽取结果。
换句话说：
传统 RAG 是“先找相似内容”；
GraphRAG 是“提前画好完整地图”；
SAG 是“只围绕当前问题临时规划路线”。
六、SAG 的实验结果很亮眼，但不能过度解读
SAG 论文在 HotpotQA、2WikiMultiHopQA 和 MuSiQue 三个多跳问答数据集上进行了测试。
在统一模型配置下，SAG 的平均 Recall@2 为79.3%，HippoRAG 2 为68.14%。
这里需要区分两种表达：
- 绝对提升：约11.16个百分点；
- 相对提升：约16.4%。
所以，“提升16.4%”只有在表达相对增幅时才正确，不能写成“提升16.4个百分点”。
在更强调长推理链的 MuSiQue 数据集上，SAG 的 Recall@5 为80.04%，HippoRAG 2 为65.13%。
对应的是：
- 绝对提升：约14.91个百分点；
- 相对提升：约22.9%。
这些数据与公开论文及复现仓库中的结果基本一致。
不过，这些数字至少存在四个需要谨慎看待的地方。
1. 评估的是检索召回，不是最终回答正确率
论文主要指标是 Recall@K，即正确证据是否出现在前 K 个结果中。
它没有充分证明：
- 模型最终是否得出了正确答案；
- 是否找齐了完整推理链；
- 是否正确理解了证据之间的关系；
- 是否产生了幻觉。
更重要的是，论文采用的是“any-hit”标准：只要 Top-K 中出现至少一条支持证据，就可以算召回成功。
论文作者自己也指出，这种指标衡量的是单条证据的可访问性，可能高估严格多跳场景下的真实表现。
因此，不能仅凭 Recall@2 或 Recall@5 就宣称 SAG 已经实现了更强的“端到端推理”。
2. 实验规模仍然有限
三个数据集分别抽样了1000个问题，对应的本地语料规模约为6119到11656个段落。
这能够验证算法方向，但和企业实际环境中的复杂情况仍有明显差距，例如：
- 大量同名人物和公司；
- 数据持续更新；
- 文档重复和相互矛盾；
- 中文简称、别名和错别字；
- 权限隔离；
- 数千万甚至数亿事件之间的热点实体扩散；
- 复杂时间关系和版本冲突。
3. 对比对象主要是 HippoRAG 2
SAG 对 HippoRAG 2 进行了统一模型配置下的重新测试，这有助于减少模型差异带来的影响。
但这仍然不能代表 SAG 已经全面优于所有 GraphRAG、动态 GraphRAG、迭代式 RAG 和 Agentic RAG 方案。
尤其是微软 GraphRAG 所重点解决的全局主题归纳，与 SAG 当前重点验证的多跳证据召回，本身就不是完全相同的问题。
4. “数亿级生产落地”仍属于作者自述
论文称 SAG 已经在数亿级数据规模的生产环境中部署，并将在线检索延迟控制在秒级。
这是一个重要的工程信号，但目前公开材料中缺少足够详细的数据，例如：
- 具体数据量和表结构；
- 并发量与查询吞吐；
- P95、P99延迟；
- 单次查询成本；
- SQL 分片和索引策略；
- 热点实体的处理方式；
- 故障率与数据一致性方案；
- 与传统 RAG 的线上 A/B 测试结果。
因此，更客观的表述应当是：
SAG 已经报告了数亿级生产实践，但其大规模工程收益仍需要更多公开案例或第三方验证。
七、SAG 真正解决了哪些问题？
抛开宣传语言，SAG 至少提供了四个有价值的创新。
1. 用“事件”代替过度碎片化的三元组
传统知识图谱经常把一句完整事实拆成多个三元组。
例如：
甲公司于2025年收购乙公司，并保留原管理团队。
可能被拆成：
- 甲公司—收购—乙公司；
- 收购—发生时间—2025年；
- 乙公司—保留—原管理团队。
拆分之后，原始事件的整体语义容易被削弱。
SAG 将一个片段压缩成一个语义完整事件，再通过多个实体建立索引。其消融实验显示，在 MuSiQue 上，事件超边表示的 Recall@5 为80.0%，三元组版本为77.1%。这说明保留事件整体语义确实可能带来收益。
2. 把关系激活放到查询阶段
SAG 不提前穷举所有事件之间的边。
它只在用户提问后，围绕当前问题涉及的实体构建局部关系网络。
这可以减少无关关系的构建和维护工作，也让新增事件更容易独立写入。
3. SQL 路径更加可审计
向量召回失败时，通常很难解释为什么某个片段没有被找到。
SAG 的链路相对明确：
问题抽取出了什么实体 → 找到了哪些近义实体 → SQL 连接到了哪些事件 → 哪一步进行了裁剪 → 最终为什么选择这些片段
对于企业知识库、销售智能体、风控和合规系统，这种可追踪性非常有价值。
4. 它比传统图谱更适合追加型数据
销售沟通记录、新闻、会议纪要、客服工单和智能体记忆，都具有持续新增的特征。
如果每次新增内容都要重新维护全局图结构，成本很高。
SAG 的事件—实体索引可以按片段独立处理，更符合流式写入和并行处理的工程模式。
八、SAG 没有解决什么问题？
SAG 的创新很有价值，但它远没有消除所有复杂性。
1. “增量更新零成本”是不准确的
SAG 避免的是全局图谱重建成本，而不是所有更新成本。
每增加一个文档片段，系统仍然需要：
- 调用模型生成事件；
- 抽取实体；
- 生成事件和实体向量；
- 写入关系数据库；
- 更新全文索引；
- 更新向量索引；
- 处理失败重试和多存储一致性。
所以更准确的说法是：
SAG 支持低耦合的增量写入，避免全局图谱重计算，但新增和更新本身仍然有模型、索引与存储成本。
2. 一个片段不一定只有一个事件
SAG 当前采用“一段对应一个事件”的设计。
但现实文档中，一个段落可能同时包含：
- 一次收购；
- 一次人事变动；
- 一个经营结果；
- 一个后续计划。
把多个事实压缩成一个事件，可能造成信息遗漏；如果强行拆成多个事件，又会重新面临事件切分和关系判断问题。
3. 共享实体不代表真实关系
两个事件都提到“阿里巴巴”，只能说明它们具有共同实体，不能直接证明它们之间存在因果、时间先后或业务依赖关系。
如果不增加关系类型、时间约束和事件角色，SQL Join 可能只是把大量“提到同一个热门实体”的事件连接在一起。
因此，SAG 的动态超边更接近一种候选关系结构，而不是经过严格验证的事实关系。
4. 实体识别和别名仍然是关键瓶颈
“北京字节跳动科技有限公司”“字节跳动”“ByteDance”可能指向同一实体。
反过来，两个同名人物也可能完全不是同一个人。
SAG 当前主要采用字符串规范化和 SQL 去重，没有完整实体消歧机制。论文也承认，不同表达可能被当成不同实体，从而削弱跨文档连接密度。
这意味着它虽然降低了实体治理成本，但并没有让实体治理问题消失。
5. SQL Join 的查询压力被转移到了在线阶段
GraphRAG 的主要成本集中在离线图谱构建。
SAG 则把部分计算转移到用户查询期间。
当某个实体关联几十万甚至几百万个事件时，例如“人工智能”“中国”“微软”，直接扩展会产生巨大的候选集合。
系统必须依赖：
- 实体频率过滤；
- 复合索引；
- 分区或分片；
- 候选数量上限；
- 热点实体降权；
- 时间窗口；
- 业务类型过滤；
- 查询超时和熔断。
论文中的固定实体前沿裁剪预算已经导致部分低频关键实体被提前舍弃，使 SAG 在2WikiMultiHopQA的 Recall@5 上低于 HippoRAG 2。
这说明 SQL Join 并没有免费解决图遍历问题，只是将图扩展转化成了数据库查询和候选裁剪问题。
6. SAG 仍然依赖较强的 LLM 排序
在 MuSiQue 实验中，将最终的 Qwen3.6-Flash 排序替换成0.6B轻量重排模型后，Recall@5 从80.0%下降到62.2%。
这说明 SAG 的效果并不只来自 SQL。
SQL 负责扩大候选范围，但从大量事件中找出真正构成推理链的组合，仍然高度依赖大模型。
因此，在线成本、延迟和模型稳定性仍然是必须考虑的问题。
7. 当前更适合“追加”，不擅长“事实被覆盖”
企业知识并不只是不断新增。
还会发生：
- 员工职位变化；
- 产品状态改变；
- 项目已经取消；
- 客户偏好被新信息覆盖；
- 制度新版本替代旧版本；
- 错误信息被修正。
如果旧事件仍然存在，系统可能同时召回相互冲突的事实。
SAG 论文也承认，目前主要支持追加型事件索引，对事件失效、覆盖、历史版本和状态变化的处理仍属于未来工作。
九、三种技术应该如何选择？
企业并不需要在传统 RAG、GraphRAG 和 SAG 之间只选一个。
适合传统 RAG 的场景
- 产品手册问答；
- 制度和合同条款查询；
- FAQ；
- 单文档摘要；
- 技术文档检索；
- 对成本和速度高度敏感的应用。
这些问题的答案通常已经集中存在于某个片段中，没有必要引入复杂关系检索。
适合 GraphRAG 的场景
- 组织关系分析；
- 产业链和股权关系；
- 稳定领域知识图谱；
- 全局主题和趋势归纳；
- 跨大量文档的整体认知；
- 需要人工维护本体、关系类型和高质量实体治理的场景。
GraphRAG 的价值不只是多跳问答，还包括长期稳定的全局知识结构。
适合 SAG 的场景
- 新闻和舆情事件；
- 销售拜访记录；
- 客户与商机变化；
- 客服工单关联；
- 项目进展和会议纪要；
- 编码智能体运行记忆；
- 持续写入、关系频繁变化的企业事件数据；
- 既要结构过滤，又要语义检索的问答场景。
这些数据更新频繁，提前维护完整图谱的投入可能大于收益，而事件化存储和查询时动态关联更合适。
十、SAG 未来最可能的定位，不是替代 RAG，而是成为“关系检索层”
SAG 最值得期待的未来，并不是宣布传统 RAG 或 GraphRAG 已经过时。
更可能出现的是一种混合架构：
向量检索负责广泛召回，
SQL 负责条件过滤和局部关系扩展，
图结构负责稳定的全局知识，
LLM 负责查询规划、候选判断与答案生成。
未来的企业知识系统，很可能包含三类数据层。
第一层：原始文档层
保存合同、制度、产品资料、聊天记录和附件原文，为答案提供可追溯依据。
第二层：事件与实体索引层
将动态内容转化为可查询事件，支持时间、人物、组织、项目、产品和动作等多维关联。
这将是 SAG 最有机会占据的位置。
第三层：稳定知识图谱层
保存经过治理的稳定事实，例如：
- 组织架构；
- 产品体系；
- 客户归属；
- 业务术语；
- 权限关系；
- 标准流程；
- 核心实体主数据。
这部分仍然适合传统知识图谱或 GraphRAG。
SAG 不需要替代它，而可以利用这些稳定实体作为事件关联的锚点。
十一、下一阶段真正重要的技术方向
SAG 若要从一篇有亮点的论文发展成广泛采用的企业架构，还需要继续解决几个问题。
1. 从追加事件升级为版本化事件
事件需要增加：
- 生效时间；
- 失效时间；
- 版本号；
- 当前状态；
- 来源优先级；
- 是否被新事件覆盖；
- 与旧事件的冲突关系。
只有这样，SAG 才能真正成为智能体的长期记忆基础设施。
2. 引入轻量实体主数据
完全不做实体治理会降低连接质量，构建完整知识图谱又成本太高。
更现实的路线是增加轻量实体别名表和主实体ID：
原始表达 → 标准实体 → 别名集合 → 业务主数据
这能够在保留增量写入能力的同时，提高跨文档连接准确率。
3. 让系统自动选择检索策略
不是所有问题都需要 SQL 多跳扩展。
未来系统应当根据问题类型自动判断：
- 简单事实查询：直接向量检索；
- 带时间、状态和组织约束：SQL过滤；
- 多跳事件关系：SAG扩展；
- 全局主题分析：GraphRAG社区摘要；
- 实时业务数据：调用数据库或业务API。
这比让所有问题固定走一条复杂链路更高效。
4. 从 Recall@K 转向完整业务指标
未来评估不能只看召回率，还需要同时评估：
- 完整证据链覆盖率；
- 最终答案准确率；
- 引用正确率；
- 时间一致性；
- 冲突识别率；
- 单次查询成本；
- P95和P99延迟；
- 高并发下的稳定性；
- 新数据写入到可检索的延迟；
- 权限泄漏率。
只有这些指标同时达标，才能证明 SAG 是生产系统的真正升级，而不仅是检索基准上的提升。
结语：SAG 的价值，不是让 SQL 取代知识图谱
SAG 最有价值的地方，不是提出了一个新的缩写，也不是简单地把 GraphRAG 换成 SQL。
它真正提出了一个值得重视的思想：
企业知识不一定要先被整理成一张完整、永久的关系网络，才能进行关系检索。
系统可以先把知识保存为相对独立、语义完整的事件，再根据当前问题，动态组织局部关系。
这让 RAG 从“找到相似文本”，开始向“围绕问题组织证据”迈进。
但 SAG 仍然处于较早阶段。
它没有消除事件抽取、实体消歧、查询扩散、版本管理和大模型排序等问题；目前的实验也主要证明了检索召回优势，而不是完整端到端推理能力。
因此，现阶段最客观的结论是：
SAG 不是传统 RAG 的替代品，也不是 GraphRAG 的终结者。
它更可能成为下一代企业知识系统中的一个新层次：
面向动态业务数据的事件索引与关系检索层。
传统 RAG 负责快速找到内容，GraphRAG 负责维护稳定的全局知识，而 SAG 负责在变化的数据中临时连接事件。
真正的未来不会是三选一。
而是让向量、关系数据库、知识图谱和大模型各自做最擅长的事情。