再见 RAG！AI 知识库还得是 SAG，又快又准～

📌 一句话摘要

本文介绍了一种名为 SAG 的新型检索架构，通过将文档转化为事项-实体索引并用 SQL 动态关联，比传统 RAG 和 GraphRAG 在多跳推理、可解释性和部署成本上更具优势，并给出了结合 FastGPT 的落地建议。

📝 详细摘要

文章从作者接到的一个客户需求出发——搭建本地智能知识库，需要支持多跳推理（如从多个关联文档中拼出答案）。作者回顾了传统 RAG 的局限性（向量检索无法跨文档串联线索）和 GraphRAG 的弊端（离线图构建成本高、维护困难），然后引入近期开源的新方案 SAG（SQL-Retrieval Augmented Generation）。SAG 的核心思路是：入库时将文档提炼为「事项卡片」并提取「实体」，存入 SQL 数据库；查询时用 SQL JOIN 动态将有共同实体的事项串联，解决多跳问题。文章用具体例子演示了 SAG 如何找到传统 RAG 遗漏的文档，并与 FastGPT 的混合检索做了对比，强调 SAG 的实体关联链是确定性而非概率性的。作者还测试了 SAG 的实际部署（通过 codex 一键 Docker 部署），引用了其在 MuSiQue 等数据集上 Recall@5 达 80% 的表现。最后建议将 SAG 作为 MCP 工具接入 FastGPT，兼顾工程成熟度与检索效果。文章还对 SAG 的可解释性、入库逻辑转变、对弱向量模型的鲁棒性做了点评，认为 SAG 将成为 Agent 的数据底座。

💡 主要观点

- SAG 通过事项-实体索引与 SQL 动态关联，解决了传统 RAG 在多跳推理上的失效问题。 传统 RAG 基于向量相似度检索，无法自动从已命中文档中提取新实体继续查询，从而漏掉关联文档。SAG 在入库时提取事项和实体存入 SQL，查询时用 JOIN 操作动态串联，可精确追溯多跳线索。

SAG 相比 GraphRAG 降低了构建和维护成本，不依赖离线知识图谱。 GraphRAG 需要在入库前大量调用 LLM 构建全局静态图，新文档加入需重算；SAG 将图构建后推到查询时，仅用 SQL 实时检索关联，索引成本低且维护简单。

SAG 提供可解释的检索链条，调优更接近 Debug 而非炼丹。 传统 RAG 的检索失败原因模糊（切块、评分阈值等），SAG 的 SQL 调用记录可完整追溯实体提取、同义词扩展、路径命中，工程师能快速定位断点。

实际落地建议将 SAG 作为检索层与成熟系统（如 FastGPT）结合。 纯 SAG 搭建完整知识库工程量大，FastGPT 提供完备的前端、权限和集成能力，SAG 通过 MCP 工具接入可补充多跳检索能力，降低烂尾风险。

💬 文章金句

- 创新不一定是发明全新的东西，有时候是把已经被验证过的工具，重新组合用在对的地方。

SAG 在向量搜索的基础上多了实体关联这条链，从已经找到的内容里挖出新线索、接着往下查，让多跳推理变成一件确定的事，而不是靠运气。
知识库最难的从来不是「搭建」，是调优。。

📊 文章信息

AI 初评：85

来源：袋鼠帝AI客栈

作者：袋鼠帝AI客栈

分类：人工智能

语言：中文

阅读时间：19 分钟

字数：4681

标签： AI知识库, RAG, SAG, 多跳推理, GraphRAG

阅读完整文章

再见 RAG！AI 知识库还得是 SAG，又快又准～

🤖 問 AI