SAG 不是又一个 RAG 变体：它在重建知识库的证据链

很多 RAG 系统的问题不是找不到文字，而是找不到关系。向量检索能把相似片段捞出来，但一旦问题涉及事件先后、人物关系、多个文档之间的因果链，答案就很容易变成“看起来像那么回事”。SAG 这类做法想补的，就是这条证据链。

普通 RAG 容易断在哪

最常见的流程是：文档切块，做 embedding，查询时按相似度召回，再交给模型回答。这个流程简单、便宜、好落地，但它天然更关心“哪段文字像问题”，不太擅长保存“这些片段为什么连在一起”。

比如同一个公司、同一个产品、同一次事故，可能分散在不同文档里。单看每个片段都相关，合起来却缺少顺序和关系。模型最后只能自己补，这就容易产生断链、误连或者过度推断。

Event、Entity 和动态超边在做什么

可以把 Event 理解成“发生了什么”，Entity 理解成“谁和什么参与了”，动态超边则是在查询时把相关事件和实体临时连起来。它不是把所有资料塞进一个固定大图里，而是根据问题激活局部关系。

这样做的好处是，系统既保留了结构，又不至于让图变得过重。查询时先找到相关实体和事件，再顺着关系扩展候选，最后交给模型组织答案。答案不是简单拼段落，而是沿着一条比较清楚的线索往下走。

它适合什么知识库

如果只是几十篇 FAQ，普通向量检索就够了。SAG 更适合资料多、关系多、时间线多的场景，比如研究资料、事件复盘、产品变更记录、法律或合规材料、故障知识库。这里的核心不是“回答更长”，而是“回答能不能说明根据”。

对企业知识库来说，这一点很重要。用户问的常常不是“某个词在哪”，而是“这件事为什么变成这样”“前后依赖是什么”“有没有相反证据”。这时单纯语义相似度就不够用了。

落地时别把结构想简单

结构化检索不是免费午餐。事件抽取、实体消歧、关系维护、增量更新，任何一环做得粗糙，后面的检索都会受影响。资料源本身混乱，SAG 也不会自动变魔法。

更现实的做法，是先挑一个关系明确的领域试，比如故障复盘、项目日志、研究笔记。先看系统能不能把“事件—实体—证据”连起来，再考虑扩大范围。

SAG 的价值不在名字新，而在它提醒 RAG 系统别只看相似度。很多时候，用户要的不是一段顺口答案，而是能站得住的证据链。