上周接了个需求,客户想在本地用 1500 个文档做一个“小秘书”Agent,查会议纪要、批复文件,要求准确率极高,特别是要能查确定性的项目金额和时间。
第一反应是用 FastGPT 直接搭。但我拉朋友仔细盘了一下,发现这事儿没那么简单。知识库最难的从来不是「搭建」,而是调优。
这种包含大量会议纪要的场景,传统 RAG 只要遇到多跳推理大概率就 GG 了。
举个例子:
文档1说“A公司收购了B公司”,文档2说“张三是A的CTO”,文档3说“张三离职加入了盘古项目”。
此时用户问:“收购B公司的企业,其CTO后来去了哪?”
传统检索拿着问题去找,能找到1和2,但绝对找不到3。因为文档3里根本没有“收购”、“B公司”这些词,字面没有交集,线索直接断了。
那用 GraphRAG 呢?太重了。大量调用 LLM 离线提取三元组建图,一个中等数据集光索引成本就大几万,进来新文件还得重算,维护成本贼高,杀鸡用牛刀。
找了一圈,发现个刚开源、在 GitHub 斩获 1.3K Star 的新架构:SAG (SQL-Retrieval Augmented Generation)。
github.com看到底层是用 SQL 动态组装超边,我一下子就来精神了。
它的核心思路特别“返璞归真”:不画全局关系图,而是文档入库时,用 AI 提炼成「事项-实体」存进普通 SQL 数据库。查询时,用 SQL 的 JOIN 语句动态把有关联的事项拎出来,实时串联线索。
换个接地气的比喻:
传统 RAG 是个死板的图书管理员,靠字面意思死找。
GraphRAG 是提前花大价钱把所有书的人名、事件画一张巨大的全局关系网挂墙上。
SAG 走了第三条路,把书变成独立卡片存表里。回到刚才那个问题,SAG 在搜出文档 1 和 2 的同时,用 SQL 发现了它们之间的隐藏实体「张三」,并自动触发第二轮查询,精准命中包含张三去向的文档 3。让多跳推理变成了确定的事。
除此之外,SAG 还有两个对开发者极其友好的特性:
1. 告别“黑盒炼丹”: 传统 RAG 调优基本是瞎摸索,改切块、改重排,按下葫芦浮起瓢。而 SAG 的检索链条是完全可追溯的 SQL 日志。大模型提了什么实体 -> 命中了哪些 -> 路线哪里断了,看一眼就能修,砍掉 80% 盲目调优的时间。
2. 不挑模型: 因为核心找线索靠的是确定的 SQL 实体关联,而不是模糊的向量距离。底层就算换个便宜的弱模型,准确率也极其稳定。
目前的评测里,SAG 在最难的多跳测试集 MuSiQue 上,把大火的 HippoRAG 2 按在地上摩擦,且已经在生产环境扛住了 5 亿条数据的秒级检索。
回到落地,这套怎么玩?
纯从头搭一套 SAG 工程量太大,烂尾风险极高。
比较推荐的解法是:站在巨人的肩膀上,把 SAG 作为 MCP 工具,丝滑接入 FastGPT。
既能复用 FastGPT 成熟的前端界面和飞书/微信接入能力,又能用 SAG 的思想彻底解决“切块破碎”和“多跳关联”的死穴。当然,你也可以通过 MCP 把它接入 Claude Code 或者 Trae 里作为本地 Agent 的利器。
把用了几十年的老古董 SQL 拉进 AI 检索,这波创新太稳了。拿到确定性更强的数据底座,本地 Agent 的推理能力绝对能更上一层楼。