【7千字深度看GraphRAG变体-SAG的叙事实现逻辑及4点辩证思考】最近社区看到一个GraphRAG的工作，《SAG: SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges》(http://t.cn/AXoqh7Rf， http://t.cn/AXoqh7RV)，讲的故事是（来自于其摘要）：不预先构建全局静态图，而是将每个文本块转换为一个语义完整的事件及其一组索引实体，随后利用SQL连接查询动态地将共享实体的事件链接成局部超边，从而在查询时构建动态实例化的局部索引结构。在效果上，避免了GraphRAG的全局图重建与持续维护的需求，通过依赖标准数据库基础设施，自然支持增量写入、并发处理和持续缩放。这个细看起来其实很包装，其实本质是打的是图数据库vs 关系型数据库的性能问题，MySQL 支持并发读写，比图数据库生态成熟，如果仔细去思考，会发现几个有趣的点。因此，本文先看看这个工作具体的实现方式，具体两个点：一个是具体是怎么做的；一个是关于SAG方案引发的4点辩证思考：SAG批判GraphRAG离线建图，但自己也在建图；增量是有损失的，实体问题还是回避掉了；真的是在解决多跳问题？还是索引密度问题？时下多跳问答数据集的失效可被拟合性。这其实是当下GraphRAG系列后期雕花论文作品的一个叙事泡沫缩影，两个点：一个是当前的RAG基准（如RGB、MultiHopQA）已严重饱和，新论文往往是在几个点位上做“排列组合”（层级检索+图谱+多模态）。这本质上是算力过剩导致的超参数搜索，而非范式创新。因为SOTA的边际提升已小于评估误差，所以“刷榜”确实成了工程活，失去了学术启发性。一个是“业务用不到+工程包装叙事”，绝大多数顶会花活（如复杂图谱构建）在真实业务中因延迟高、维护难而被弃用。业务中真正有效的RAG，往往是极简的Pipeline（元数据过滤+重排序+提示词工程）。这些“土办法”发不出论文，所以学术界刻意回避。这是论文研究的“假问题”与业务“真问题”错位，而工业界为了出圈，又会包装为学术界的叙事，显得也有些拧巴。http://t.cn/AXoqh7RI