RAG 找不到跨文档答案的时候，问题可能不在模型 最近看了一篇讲企业知识库落地的文章，里面有个场景特别真实：员工问“跨区域采购谁来审批、需要什么材料”，答案散落在财务制度、采购规程、历史项目的七八份文件里。普通RAG按语义相似度检索，结果是新旧规定混在一起、金额条件对不上、每个说法都找不到出处。 我就在想，RAG做了这么久，为什么这个场景还是这么难？ 传统RAG靠向量检索，本质是“找相似的”。但“相似”不等于“相关”——尤其是问题涉及多个文档、多个条件的时候。GraphRAG试图用知识图谱解决这个问题，但建图成本高、维护难，项目越做越重。 我们团队的做法不太一样。我们做了一个叫SAG的东西，核心思路是：不建图，用SQL做关联。 具体来说，把文档拆成Event（事项）和Entity（实体）——Event保留完整语义，Entity负责跨文档连接。查询的时候，先找到相关的Event，再通过共享的Entity做SQL JOIN，动态“生长”出一小片临时图谱。不需要预先维护一张巨大的知识图谱，查询的时候现关联。 效果还行。在HotpotQA、2WikiMultiHopQA、MuSiQue三个标准多跳检索基准上，多项Recall指标达到业界领先水平。生产环境已经跑了约5亿条数据，检索延迟保持在秒级以内。 SAG已经在GitHub开源了（Zleap-AI/SAG），目前2.5K Star。论文也挂在了arXiv上。 我们公司叫Zleap（智跃） ，做的事情不只是SAG——我们在做一整套企业AI化的组织基建：SAG负责组织企业知识（Context Infra），Zleap OS负责让Agent进入组织关系、可治理可协作，FDE负责把技术落地到企业现场。 如果你也在搞RAG、Agent、企业知识库这些东西，欢迎来碰卡聊聊。 我们团队在招人，方向是Agent架构和知识库相关。带上你的GitHub或Blog来聊，比简历酷多了。