SAG 评测：用 SQL 动态超边取代 RAG 与 GraphRAG 的第三种检索架构
A new SOTA for RAG — an original retrieval architecture and an open-source knowledge base for humans and agents.
秒懂
- 它是什么？
- SAG 是一个本地优先、单用户的知识库应用，底层是名为 SAG 的原创检索架构。它既不是传统 RAG 与 GraphRAG 的融合，也不是两套系统的拼接，而是用事件、实体和查询时动态超边，把语义检索与关系推理放进同一条管道。
- 适合谁用？
- SAG 适合那些厌倦了同时维护向量检索与图检索两套系统的个人开发者，也适合需要为 Agent 提供可溯源、可引用答案的团队，尤其是数据规模可控、愿意接受新检索范式的场景。不适合需要成熟生态、大规模分布式部署或强多用户协作的企业，也不适合那些不能接受论文尚未被广泛复现的保守型项目。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个声称要取代 RAG 和 GraphRAG 的项目
SAG 不是一个普通的 RAG 工具。它的定位很极端，README 里写得很清楚，它不是传统 RAG 和 GraphRAG 的融合，而是一种原创检索架构，要同时取代两者。项目由一个知识库应用、一个 Python 包 zleap-sag、一个命令行客户端 @zleap-ai/sag-cli，以及一篇 arXiv 论文组成。目标用户有两类，一类是个人，想把自己的文档变成可搜索、可追溯的知识库；另一类是 Agent 开发者，需要通过 API 或 MCP 让 AI 助手能检索并引用来源。它刻意做成 local-first 和 single-user，默认用 SQLite 和 LanceDB，不需要外部数据库。这个定位让它和那些面向企业级、多租户的 RAG 平台形成了鲜明对比。
事件、实体与查询时动态超边，核心机制拆解
SAG 的数据模型围绕三个概念展开。每个 chunk 被解析成一个语义完整的事件，事件不会被拆成独立的三元组，它保留了 chunk 的完整含义。同时每个 chunk 会提取出多个实体，实体只是轻量级的索引和扩展点，不承载事件的意义。关键在第三层，事件和实体之间的关联会形成一个潜在的 hyperedge，但 SAG 不会预先构建或全局维护这些超边。相反，在查询时，系统通过 SQL 把共享实体的那些事件连接起来，动态生成一个局部超边。这意味着图结构不是静态存储的，而是在每次查询时根据当前问题临时组装。语义路径和结构路径都是 SAG 管道的内生部分，不是两套服务并行跑。
离线索引与在线检索，数据流怎么走
离线阶段，文档先被解析成语义连贯的 chunk，然后并行地从每个 chunk 提取一个事件和多个实体。这些内容被持久化到关系存储中，包括 chunk、事件、实体和事件与实体的关联。同时，chunk、事件和实体的向量表示会被写入向量和全文索引。在线检索时，系统根据查询动态地执行 SQL 连接，找出共享实体的相关事件，形成超边，然后把选中的事件映射回原始 chunk，作为生成的依据和引用来源。这个设计保证了输出边界始终是原始证据，任何检索结果都可以追溯到原文。README 强调，SAG 不需要维护两套 RAG 系统，也不需要合并两条检索路径，因为语义相似度和关系推理发生在同一条管道里。
从安装到接入 Agent，真实命令与配置
项目提供多种运行方式。桌面应用可以通过 GitHub Releases 获取，README 显示有 desktop release 标签。Python 包通过 PyPI 分发，包名是 zleap-sag，需要 Python 3.11 以上。命令行客户端是 @zleap-ai/sag-cli，文档在 docs/sag-cli.en.md。最直接的接入方式是运行 sag agent connect codex 或 sag agent connect claude-code，这条命令会把 SAG Knowledge MCP 挂载到 Codex 或 Claude Code，免去了手动复制 JWT 和编辑配置文件的麻烦。内置的 DeepSeek Harness 连接器则通过 @zleap-ai/dsh-sag 让 DSH Agents 可以搜索知识库、读取来源和管理文档。系统还支持 REST/OpenAPI 自托管、OpenAI 兼容的聊天接口，以及 MCP 协议。后端存储从 SQLite 和 LanceDB 起步，文档提到有一条清晰的路径可以迁移到 PostgreSQL 和 pgvector。
本地优先的代价，规模与多用户限制
local-first 和 single-user 的设计带来明确的天花板。SQLite 和 LanceDB 的组合适合个人知识库和中小规模数据集，但一旦数据量增长到需要水平扩展，或者多个团队成员需要同时读写同一个知识库，这套默认配置就会成为瓶颈。README 承认有通往 PostgreSQL 的路径，但这条路径需要多少改造工作，文档里没有细说。另一个限制是背景处理，文档提到文档生命周期控制和后台处理，但具体如何调度、是否支持分布式任务队列，都看不出来。对于需要高并发、多租户隔离或企业级权限管理的场景，SAG 目前不是合适的工具。它的优势在于简单和可追溯，而不是规模。
与 GraphRAG 的本质区别，不是两套系统拼接
传统 GraphRAG 需要在离线阶段做三元组提取、实体合并、关系归一化，并且要维护全局图结构，增量更新非常困难。SAG 绕开了这些步骤。它不预构建全局超边，而是在查询时用 SQL 动态生成，这省去了图维护的负担，也让增量更新变得更容易，因为新文档只需要提取事件和实体，不需要重新合并全局实体。这个设计取舍很清晰，SAG 用查询时的计算换取了离线构建的复杂度。代价是，每次查询都要执行动态连接，如果事件数量巨大，查询延迟可能成为问题，但 README 没有给出任何性能数据。与 dense RAG 相比，SAG 多了关系推理能力，但这也意味着它比纯向量检索更复杂，不是所有应用都需要这种复杂度。
维护与升级成本，v1 分支的教训
2026 年 7 月 14 日，项目发布了一个完全重建的版本，基于 zleap-sag 包，UI 完全重新设计。旧版本被归档到 v1 分支，不再维护。这个信息很重要，意味着如果你在 v1 分支上做了定制，升级到新版本不是小改动，而是迁移到一套新的架构。版本号更新频繁，v1.8.4 到 v1.8.6 在四天内连续发布，说明项目处于快速迭代期，API 可能不稳定。许可证是 MIT，你可以自由使用和修改，但 README 没有提到贡献指南或行为准则。对于依赖此项目的团队，需要密切关注每次发布，因为快速迭代可能带来破坏性变更。
编辑结论
SAG 适合那些厌倦了同时维护向量检索与图检索两套系统的个人开发者，也适合需要为 Agent 提供可溯源、可引用答案的团队，尤其是数据规模可控、愿意接受新检索范式的场景。不适合需要成熟生态、大规模分布式部署或强多用户协作的企业，也不适合那些不能接受论文尚未被广泛复现的保守型项目。采用前应先在 HotpotQA、2WikiMultiHopQA 与 MuSiQue 上复现论文指标，确认 SAG 的检索质量在你自己领域的数据上确实优于你现有的 dense RAG 或 GraphRAG 方案，再迁移数据。SAG 的 MIT 许可让你可以自由修改，但 v1 分支已归档，升级到 zleap-sag 包版本是唯一受支持的路径，旧版不应作为生产依赖。
社区笔记