SAG 不应该被当成“又一个向量库”。它想解决的是知识库里很常见的一类问题：答案需要多段证据串起来，但普通向量检索只把相似 chunk 捞出来，证据之间的关系经常断掉。
普通 RAG 容易丢掉关系
很多 RAG 系统会把文档切成 chunk，然后按 embedding 相似度召回。这个方法适合找局部事实，但遇到多跳问题就容易断。比如一个问题同时涉及人物、事件、时间、地点和后续影响，单个 chunk 可能都相关，却没有说明它们之间怎么连起来。
Event、Entity 和动态超边
SAG 的思路是把文本块、事件、实体和关系一起组织起来。Entity 负责稳定对象，Event 负责描述发生了什么，动态超边则用来把多个实体和事件临时连成一条证据链。这样检索不只是“找相似文本”，还可以沿着结构扩展。
这对知识库很重要。因为很多真实问题不是问“某句话在哪里”，而是问“这几件事之间是什么关系”。结构化检索能让模型少一点猜测，多一点可追踪证据。
它适合什么场景
- 企业知识库里的流程、责任人、事件追踪。
- 新闻、研究、政策类资料的多跳问答。
- 需要引用来源和解释路径的 RAG。
- 同名实体、时间线和上下游关系复杂的资料。
不要把它神化
结构化检索也有成本。实体抽取会错，事件边界会模糊，关系扩展太多会引入噪声。真正可用的系统要保留原文 chunk、记录抽取版本、限制扩展深度，并允许用户回到原始证据。
SAG 提醒我们：知识库不是一袋向量。好的检索系统既要能找相似内容，也要能保留事件和实体之间的关系。