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

在企业知识库的问答场景中，最具挑战性的往往不是“某段话在哪里”，而是“几段事实如何串联起来”。例如：文档A说明某业务由团队甲负责，文档B指出李明是团队甲负责人，文档C透露李明后来加入项目Y。当用户提问“负责这个业务的团队负责人后来去了哪个项目”时，传统RAG系统很可能只检索到A和B，导致关键证据C未能进入上下文，最终答案链在最后一跳断裂。这类失败在企业知识库应用中极为普遍，很多团队本能地选择调优Prompt、换用更大的模型或扩大上下文窗口，却忽视了真正的问题根源——召回链路断了。

Event-Entity轻量索引结构

SAG（Subgraph Augmented Generation）知识库提供了一种更优雅的解决方案。它将文档片段提炼为语义完整的Event（事项），并通过Entity（实体）建立可扩展索引。与GraphRAG提前维护全局知识图谱的高成本不同，SAG选择在查询发生时，用关系型数据库动态组织局部关系链。Event保存事项语义，Entity负责连接和扩展，二者形成轻量级二部结构，无需预先整理所有实体关系。

动态局部关系链的构建机制

在实际架构中，Chunk（文档切片）经过处理后生成Event和Entity两类核心元素。Event代表一个语义完整的事项，说明“发生了什么”；Entity则涵盖人、组织、项目、产品、时间等连接点。每个Event可以关联多个Entity，每个Entity也能连接多个Event。这种结构在新增文档时只需增加新的Event、Entity和关系记录，系统无需重建整张图谱。

两条检索路径的协同配合

SAG的精髓在于查询阶段的动态关系构建。当用户提出问题时，系统首先定位一组种子实体或种子事项，随后通过SQL读取这些事项关联的其他实体，再利用新实体召回更多事项。这个过程如同在当前问题周围动态展开一张局部关系图，论文中称之为“动态超边”。它与静态知识图谱的核心差异在于构建时机：静态图试图提前描述所有关系，而SAG只在问题到来时组织当前所需的局部关系，从而将“维护完整图谱”的难题转化为数据库更擅长的增量写入、索引和JOIN操作。

可解释性：检索链路透明化

SAG支持两种检索模式以适应不同场景。极速模式使用全文或BM25匹配结合向量召回，适合默认交互场景，减少在线LLM调用；标准模式则先由LLM抽取查询实体，再结合语义召回，更适合质量对比和疑难问题处理。两种模式共享Event-Entity索引和SQL扩展机制，差异主要在于种子实体的来源和候选筛选策略。这种设计明确了三层职责分工：向量检索负责语义邻近，实体和关系表负责确定连接，SQL负责多跳扩展，Rerank负责控制最终上下文规模与相关性。

如有侵权，请联系删除。