过去两年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 的平均 Recall2 为79.3%HippoRAG 2 为68.14%。这里需要区分两种表达绝对提升约11.16个百分点相对提升约16.4%。所以“提升16.4%”只有在表达相对增幅时才正确不能写成“提升16.4个百分点”。在更强调长推理链的 MuSiQue 数据集上SAG 的 Recall5 为80.04%HippoRAG 2 为65.13%。对应的是绝对提升约14.91个百分点相对提升约22.9%。这些数据与公开论文及复现仓库中的结果基本一致。不过这些数字至少存在四个需要谨慎看待的地方。1. 评估的是检索召回不是最终回答正确率论文主要指标是 RecallK即正确证据是否出现在前 K 个结果中。它没有充分证明模型最终是否得出了正确答案是否找齐了完整推理链是否正确理解了证据之间的关系是否产生了幻觉。更重要的是论文采用的是“any-hit”标准只要 Top-K 中出现至少一条支持证据就可以算召回成功。论文作者自己也指出这种指标衡量的是单条证据的可访问性可能高估严格多跳场景下的真实表现。因此不能仅凭 Recall2 或 Recall5 就宣称 SAG 已经实现了更强的“端到端推理”。2. 实验规模仍然有限三个数据集分别抽样了1000个问题对应的本地语料规模约为6119到11656个段落。这能够验证算法方向但和企业实际环境中的复杂情况仍有明显差距例如大量同名人物和公司数据持续更新文档重复和相互矛盾中文简称、别名和错别字权限隔离数千万甚至数亿事件之间的热点实体扩散复杂时间关系和版本冲突。3. 对比对象主要是 HippoRAG 2SAG 对 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 上事件超边表示的 Recall5 为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的 Recall5 上低于 HippoRAG 2。这说明 SQL Join 并没有免费解决图遍历问题只是将图扩展转化成了数据库查询和候选裁剪问题。6. SAG 仍然依赖较强的 LLM 排序在 MuSiQue 实验中将最终的 Qwen3.6-Flash 排序替换成0.6B轻量重排模型后Recall5 从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. 从 RecallK 转向完整业务指标未来评估不能只看召回率还需要同时评估完整证据链覆盖率最终答案准确率引用正确率时间一致性冲突识别率单次查询成本P95和P99延迟高并发下的稳定性新数据写入到可检索的延迟权限泄漏率。只有这些指标同时达标才能证明 SAG 是生产系统的真正升级而不仅是检索基准上的提升。结语SAG 的价值不是让 SQL 取代知识图谱SAG 最有价值的地方不是提出了一个新的缩写也不是简单地把 GraphRAG 换成 SQL。它真正提出了一个值得重视的思想企业知识不一定要先被整理成一张完整、永久的关系网络才能进行关系检索。系统可以先把知识保存为相对独立、语义完整的事件再根据当前问题动态组织局部关系。这让 RAG 从“找到相似文本”开始向“围绕问题组织证据”迈进。但 SAG 仍然处于较早阶段。它没有消除事件抽取、实体消歧、查询扩散、版本管理和大模型排序等问题目前的实验也主要证明了检索召回优势而不是完整端到端推理能力。因此现阶段最客观的结论是SAG 不是传统 RAG 的替代品也不是 GraphRAG 的终结者。它更可能成为下一代企业知识系统中的一个新层次面向动态业务数据的事件索引与关系检索层。传统 RAG 负责快速找到内容GraphRAG 负责维护稳定的全局知识而 SAG 负责在变化的数据中临时连接事件。真正的未来不会是三选一。而是让向量、关系数据库、知识图谱和大模型各自做最擅长的事情。