很多企业知识库问答失败不是模型不会推理而是关键证据没有被检索进上下文。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 的核心问题从“模型能不能想出来”拉回到“证据能不能被找进来”。对企业知识库来说这个判断很关键。很多答案不是生成失败而是召回链路断了。先把证据链补齐再谈模型推理系统才有机会稳定变好。推荐阅读Agent Memory 架构拆解别再把向量库当唯一记忆系统Agent 评测系统架构从指标分层到 GT/Judge 闭环的工程化落地Agent 工程化新底座用 CLI 契约层打通 HTTP 接口与业务能力SkillOpt 架构拆解把 Skill 文本当参数用执行轨迹训练 AgentGEPA 架构拆解让 Prompt 和 Skill 优化不靠玄学