SAG 知识库检索机制：Event-Entity 索引、SQL 动态超边与多跳 RAG 召回链路

很多企业知识库问答失败，不是模型不会推理，而是关键证据没有被检索进上下文。SAG 的思路是把文档片段提炼为 Event，再用 Entity 建立可扩展索引，通过 SQL 在查询时动态构造局部关系链。它不是用全局知识图谱替代向量检索，而是让向量、关系表和重排各自承担更清晰的职责。

企业知识库里最难的问答，往往不是"某段话在哪里"，而是"几段事实怎么连起来"。

比如文档 A 说某业务由团队甲负责，文档 B 说李明是团队甲负责人，文档 C 说李明后来加入项目 Y。用户问：

负责这个业务的团队负责人后来去了哪个项目？

模型如果只拿到 A 和 B，很可能答不出来。不是它不会推理，而是 C 没进上下文。

这类失败很常见。很多时候我们会本能地调 prompt、换模型、扩大上下文窗口，但真正的问题发生在更前面：召回链路断了。

图：企业知识库里的证据链，往往要跨文档、跨实体重新接起来

多跳问题的关键，不是生成，而是证据进入上下文

普通 RAG 擅长找"相似内容"。用户问题和文档片段越相似，向量检索越容易命中。

但多跳问题经常不是这样。最后一跳证据可能和原问题没有明显字面重合，语义距离也很远。

图：多跳问题里，答案常常断在最后一段没有进入上下文的证据

如果检索只命中 A 和 B，答案链就在最后一跳断掉。

这时给生成模型加"请仔细推理"没有用。缺少证据时，推理只会变成猜测。

GraphRAG 可以缓解这个问题，但维护全局知识图谱也有成本：关系抽取、图构建、增量更新、冲突处理、全局一致性。对持续变化的内部文档来说，这些成本可能比搭知识库本身还重。

SAG 的选择更轻：不提前维护一张完整大图，而是在查询发生时，用关系型数据库动态组织局部关系。

Event-Entity：事项保存语义，实体负责连接

SAG 的入库仍然从 Chunk 开始，但 Chunk 不直接作为唯一检索对象。系统会把每个 Chunk 提炼成 Event，并抽取相关 Entity。

概念	作用
Chunk	原始文档切片，保留文本来源
Event	语义完整的事项，说明发生了什么
Entity	人、组织、项目、产品、时间、概念等连接点
Event-Entity 关系	把事项和实体关联起来，形成可扩展索引

Event 避免语义被切得太碎，Entity 负责连接和扩展。

一个 Event 可以关联多个 Entity，一个 Entity 也可以连接多个 Event。这是一种轻量二部结构，不需要预先把所有实体关系整理成全局图。

图：Event 保存事项语义，Entity 负责把不同事项连接起来

新增文档时，只要增加新的 Event、Entity 和关系记录。系统不必重建整张图。

动态超边：查询时才生成局部关系

SAG 的关键在于查询阶段。

当用户提出问题，系统先找到一组种子实体或种子事项。然后通过 SQL 读取这些事项关联的其他实体，再用新实体召回更多事项。

这个过程像在当前问题周围临时展开一张局部图。

图：查询发生时，系统围绕种子实体和事项动态展开局部关系链

论文里把这种查询时形成的关系称为动态超边。可以把它理解成：多个事项因为共享实体，在当前问题中临时组成一条证据链。

它和静态知识图谱的差别在于构建时机。

静态图试图提前描述所有关系。SAG 只在问题到来时组织当前需要的局部关系。这样把"维护完整图"的问题，转成数据库更擅长的增量写入、索引和 JOIN。

图：SQL 扩展、向量粗排和重排，各自承担证据召回链路中的不同职责

两条检索路径：速度和语义判断的取舍

SAG 的检索可以分成两种模式。

模式	工作方式	适用场景
极速模式	用问题在实体库做全文或 BM25 匹配，同时生成查询向量召回标题相关事项，再做 SQL 扩展和重排	默认交互，更少在线 LLM 调用
标准模式	先由 LLM 抽取查询实体，再结合实体名称和实体向量召回，最后由 LLM 选择候选事项	质量对比、疑难问题、需要更多语义判断的场景

两种模式共享 Event-Entity 索引和 SQL 扩展。区别主要在种子实体怎么来，以及最终候选怎么筛。

这说明 SAG 不是抛弃向量检索，也不是让 SQL 独自承担全部召回。更准确的分工是：

向量检索负责语义邻近。
实体和关系表负责确定连接。
SQL 负责多跳扩展。
Rerank 负责控制最终上下文规模和相关性。

为什么这比"扩大上下文"更可靠

面对多跳问答，一个常见想法是把更多文档塞进上下文。

这能解决一部分问题，但它不是根治。上下文变大后，仍然要回答两个问题：

哪些文档值得进入上下文？
证据之间的关系是否能被保留？

只扩大窗口，会把召回问题推迟到模型阅读阶段。SAG 则是在检索阶段就让证据链更完整。

方案	优点	风险
扩大上下文	简单直接，减少漏召回概率	成本高，噪音多，关系链不一定完整
全局知识图谱	关系清晰，可解释性强	构建和维护成本高
SAG 动态关系	增量友好，查询时构造局部链路	依赖事件抽取质量和索引设计

它适合的不是所有知识库，而是那些跨文档、多跳证据、实体关系密集、又需要持续增量写入的场景。

FAQ、单文档问答、关键词稳定的资料库，用普通混合检索可能更简单。

可解释性来自检索过程，而不只是最终答案

多跳检索系统还有一个很实际的要求：它必须能解释自己怎么找答案。

如果最终答案错了，团队要知道问题出在哪一段：

实体没有识别出来？
种子事项没召回？
SQL 扩展没有命中下一跳？
向量粗排把正确事项排后了？
Rerank 丢掉了关键证据？

这类 trace 对知识库调优很重要。只看最终回答，很难判断是生成失败还是检索失败。

SAG 的 Event-Entity 结构天然更适合暴露这条链路。每一步召回的事项、实体和引用都能被记录，排查时能看到证据链怎么断。

这比"模型回答不对，再换个 prompt"要可控得多。

结语

SAG 值得关注的地方，不是又做了一种更复杂的图，而是把关系构建放回查询现场。

事项保存语义，实体承担连接，SQL 负责局部扩展，向量和 Rerank 控制相关性。它把多跳 RAG 的核心问题从"模型能不能想出来"，拉回到"证据能不能被找进来"。

对企业知识库来说，这个判断很关键。很多答案不是生成失败，而是召回链路断了。先把证据链补齐，再谈模型推理，系统才有机会稳定变好。