当RAG在多跳推理中失效时，SAG知识库凭借动态构建局部关系链，精准召回缺失证据。核心内容：
- 传统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丢掉了关键证据？
这类追踪对知识库调优至关重要。仅凭最终回答，很难判断是生成失败还是检索失败。
SAG的Event-Entity结构天然更适合暴露这条链路。每一步召回的事项、实体和引用都能被记录，排查时可以看到证据链是如何断开的。
这比“模型回答不对，再换个prompt”要可控得多。
结语
SAG值得关注的地方，并非又实现了一种更复杂的图，而是将关系构建放回查询现场。
事项保存语义，实体承担连接，SQL负责局部扩展，向量和Rerank控制相关性。它将多跳RAG的核心问题从“模型能不能想出来”，拉回到“证据能不能被找进来”。
对企业知识库而言，这个判断非常关键。很多答案并非生成失败，而是召回链路断了。先把证据链补全，再谈模型推理，系统才有机会稳定提升。