当只看脸的RAG学会了顺藤摸瓜

过去两年，AI Agent的能力实现了显著跃升，从简单的问答逐步演进到能够执行复杂的多步骤任务。然而，一个支撑Agent运行的核心组件——RAG（检索增强生成）技术的准确率，却始终没有取得突破性进展。这直接制约了Agent在需要跨文档、跨步骤推理场景中的表现。

传统向量RAG的局限性

在MuSiQue多跳问答基准测试中，目前表现最好的结构化检索方案HippoRAG 2，其Recall@2仅为49.5%。这意味着当Agent需要查找一个需要跨越多个文档进行推理的问题时，使用返回的前2条结果中，有超过一半的正确答案根本不在其中。这种检索不准的问题会导致Agent在后续推理中不断叠加误差，最终偏离正确方向。

GraphRAG的尝试与困境

传统向量RAG的工作原理相对简单直接：将文本转换为向量表示，当用户提出问题时，通过向量相似度匹配找出最相关的文本片段。这种方式的优势在于速度快、成本低、部署简单，在简单问答场景下确实能够满足需求。 然而，其根本性的短板在于：向量搜索只能判断「像不像」，而无法理解「谁跟谁有关系」。当用户提出类似这样的问题：「A公司收购了B公司，B公司的CTO后来加入了C项目，C项目影响了哪个产品路线？」答案分散在三篇完全不同的文档中。单独看任何一篇文档，都与问题不太「像」，只有将它们串联起来，才能形成完整答案。向量RAG要稳定找到这条推理链条的概率相当低。

SAG技术：超边结构的突破

针对这一问题，GraphRAG（基于知识图谱的RAG）提出了不同的解决思路：从文本中抽取实体和关系，构建知识图谱，然后沿着图谱进行多跳检索。这个方向本身是正确的，但实现起来却面临重重挑战。 GraphRAG需要将文本拆解为「头实体→关系→尾实体」的三元组形式，每一步都要依赖大语言模型进行实体抽取、名称归一化、重复合并、社区发现和摘要生成。这个过程既耗时又昂贵。更棘手的是，现实世界的数据并非一成不变，新实体和新关系不断涌现，旧关系也可能过时。如何高效更新图谱，成为另一个难以解决的问题。

检索流程：两条路径协同

面对这些挑战，一项名为SAG（SQL-Retrieval Augmented Generation）的新技术应运而生。它采用了一种完全不同的设计理念：不为每个文本块建图谱、不拆分三元组、不维护全局图结构，而是为每个chunk（文本块）配备一张「索引卡」。 这张索引卡包含两个核心组件：event（事项摘要）和entity（实体）。event保留完整语义，将整个chunk总结为一个完整的事件描述；entity则从原始chunk中抽取多种类型的实体，包括人物、组织、地点、时间、产品、话题等11种标签。两者通过SQL关联查询建立多对多连接，共同定义了一条潜在的超边。 与三元组路线本质不同的是，三元组将完整事件拆解得支离破碎，质量高度依赖每条关系抽取的准确性。而SAG只让大语言模型做两件相对稳定的事情：把chunk总结成完整事项，同时尽可能多地抽取实体。事项保留上下文完整性，实体负责索引和连接。这种超边结构更像是一个事件将所有相关的人、地点、组织、时间串联在一起，而不是两点之间的一条线。

如有侵权，请联系删除。