RAG 找不到答案时，别急着怪模型，不如试试 SAG 知识库

当RAG在多跳推理中失败时，SAG知识库通过动态构建局部关系链，精准召回缺失证据。核心内容：

1. 传统RAG在多跳问题中的召回瓶颈
2. SAG知识库的Event-Entity轻量索引结构
3. 查询时通过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负责控制最终上下文规模和相关性。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

结语

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

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

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