SAG 知识库要解决的是证据链，不是把答案写得更长

很多知识库问题不是“答案不够长”，而是证据组织得太松。传统向量检索擅长从相似文本里找片段，但当问题涉及多个实体、事件顺序、因果关系和版本变化时，单纯相似度很容易把相关内容拼在一起，却解释不清这些内容之间的关系。

SAG 这类思路更值得关注的地方，是把知识库从“段落仓库”往“证据网络”推进。实体、事件、关系和动态超边不是为了制造新术语，而是为了让系统知道一条结论背后连接了哪些事实，哪些事实已经过期，哪些关系还需要人工确认。

向量检索能找到相似文本，但不天然理解时间、责任主体、依赖关系和冲突证据。比如一个项目的部署文档、故障记录、API 变更和会议纪要都提到了同一个服务，向量库可以召回它们，却不一定能判断哪个信息最新、哪个结论已经被后续事故推翻。

如果把知识拆成实体和事件，再用关系连接，就可以更清楚地回答：谁在什么时候做了什么，影响了哪个系统，有哪些证据支持，后续有没有修正。这比只把 chunk 塞进向量库更接近真实排障和决策流程。

动态超边适合表达多个对象共同构成的关系。一次故障可能同时牵涉服务、版本、配置、负责人、时间窗口和外部依赖；一次产品决策可能同时关联用户反馈、成本、竞品、路线图和上线风险。把这些关系压成两个节点之间的一条边，会丢掉很多上下文。

真正有用的知识库应该允许关系更新。新的事故、新的评审、新的实验结果出现后，旧关系需要降权、标记或替换。否则知识库会变成“永远记得，但不知道什么已经不该信”。

• 先选一个边界清楚的知识域，例如故障复盘、API 变更或客户反馈。
• 定义实体、事件和关系类型，不要一开始就全自动抽取。
• 保留原始来源链接和更新时间，避免生成结论脱离证据。
• 让检索结果显示证据路径，而不是只输出回答。
• 定期处理冲突、过期和重复关系。

SAG 的价值不在炫技，而在让知识库更可追溯。只要证据链不可见，答案越长，反而越容易掩盖系统不知道的地方。