GraphRAG 这两年被捧成 RAG 的「下一代形态」：把文档抽成实体和关系，建成知识图谱，再沿图做多跳推理。听起来很美，但落地时有个挥之不去的尴尬——面对「某某生于哪一年」这种简单事实查询，老老实实的 BM25 或 TF-IDF 反而能赢过复杂的图检索。问题不出在「图」本身，而出在检索策略「一刀切」：不管什么 query，都从顶层社区摘要往下灌，简单问题被全局噪声拖累，复杂问题又被局部检索截断。

VLDB 2026（8/31-9/4 波士顿）录用的 PKU-DAIR 论文《QA-GraphRAG》点破了这件事，并给出了一个轻量到有点反直觉的解法。

先承认：图 RAG 也会「用力过猛」

作者做了一个朴素的实证分析。他们用 LLM 把现有问答数据集的 query 分成「局部（Local）」和「全局（Global）」两类：局部查询只依赖具体事实，不需要多跳；全局查询则要高层次的总结性知识。结果很说明问题——传统 KGQA 数据集（MuSiQue、2WikiMQA、HotpotQA）里，局部查询占压倒多数，2WikiMQA 中局部查询高达 82%。

更关键的发现是具体度（Specificity）指标：局部查询明显包含更多命名实体、大写词元，需要更细粒度的知识。而一旦把检索分支固定，「双分支」图 RAG（比如同时检索局部文本块和全局摘要）对大量简单 query 是纯浪费——既引入冗余噪声，又把每条 query 的响应时间显著拉长。

换句话说，图 RAG 的痛点不是「图建得不够大」，而是检索深度和 query 特性不匹配。这恰恰是过去一年大家很少正面讨论的盲区。

QA-GraphRAG：一个会「看 query 下菜」的路由器

QA-GraphRAG 的核心是一个即插即用的路由器（Router）模块，兼容大多数以层级方式建库、检索文本块的图 RAG 框架（GraphRAG、RAPTOR、LightRAG、TREX、HiRAG 都行）。它做的事很简单：根据 query 的特征，预测应该从知识库的哪一层开始检索。

实现上反而很克制——一个三层 MLP，而不是再塞一个 LLM 当裁判。作者对比了用 Qwen2.5-3B 做路由的方案，结论是 LLM 路由没有带来一致收益，反而把每条 query 的延迟显著拉高；MLP 在效果和效率之间拿到了最优解。在线推理时，MLP 几乎零开销地输出「该从哪层起跳」，检索器再从那一层向下遍历，避免无谓的顶层抽象或底层冗余。

论文还给了两种部署策略：跨领域预训练的「通用路由器」（用 HotpotQA、NQ、TriviaQA 等 6000 样本训，无需目标域标注），以及有少量样本时的「专家路由器」微调。在 GraphRAG-Bench 和多个 KGQA 数据集上，集成 QA-GraphRAG 的变体几乎全面超过原版；最惊艳的一幕是——装备了自适应路由的 7B 模型（GraphRAG-QA-7B），在 HotpotQA 等任务上甚至越级打过了用更大 14B 模型跑的固定策略原版。一个聪明的检索策略，确实能在一定程度上弥补底座参数的劣势。

同一届会议的另外一条路：HyGRAG 的「融合」

WWW 2026 录用的《HyGRAG》走了另一条互补路线：不再把 chunk（文本块）和 entity（实体）分成两个各自检索的通道，而是融合进同一张层级图，配双通道检索 + 附件式动态更新。它在五个静态 QA 数据集上多跳推理平均 +9.7%，同时比拼接式方案更省 token；增量更新时社区质量仅下降 1-2%。

两条路合起来看，2026 年的 GraphRAG 研究主线已经清晰：要么让检索「会挑层级」（QA-GraphRAG），要么让知识「会融合」（HyGRAG）。目标一致——把多跳推理的成本和噪声压下来。

为什么「RAG 已死」是错的，但旧 RAG 也确实不够

同期 ainewsgrid 的综述《RAG Is Not Dead 2026》把背景说得很透：当某模型带着 1M 上下文窗口发布时，总有人喊「直接把文档塞进上下文就行」。但这忽略了三件事——成本（每次请求塞 1M token 可能要几美元，RAG 只取相关片段能省 100-500 倍）、长上下文本身会掉精度（900K+ token 时检索准确率掉到 74%），以及最关键的企业权限隔离（RAG 能按用户权限过滤，上下文塞满则把一切暴露给模型）。2026 年的生产级 RAG 栈，早就不是「向量相似度搜索」了，而是 GraphRAG + 混合检索（向量+关键词）+ 多级 rerank（召回→cross-encoder→LLM 过滤）的组合。

我的判断：GraphRAG 的下一站是「路由器」

过去一年行业对 GraphRAG 的注意力大多放在「怎么把图建得更大、摘要抽得更准」。QA-GraphRAG 和 HyGRAG 一起把矛头指向了另一个一阶变量：检索深度该由谁决定。答案越来越清楚——不该由工程师拍脑袋固定，而该由 query 自己决定。

对企业知识库来说，真实痛点从来不是图不够大，而是「简单问题被全局噪声拖慢、复杂问题被局部检索截断」。自适应路由把「检索深度」变成一个可被观测、可被优化的独立组件：你能看到它给每个 query 选了哪一层，也能用几百条样本微调出领域专属路由器。这比「全量上 GraphRAG」务实得多——先用向量/BM25 把局部查询跑顺，再按需上图，把 router 当成系统里可观测的一环。

图检索的故事，正从「建一张更大的图」，转向「养一个更会看 query 的调度员」。

参考来源

• PKU-DAIR《QA-GraphRAG: Query-Adaptive Plug-and-Play Retrieval Integration for Graph-based RAG》（VLDB 2026）及 GitHub：https://github.com/PKU-DAIR/Query-Adaptive-GraphRAG
• 《HyGRAG: A Unified Framework for Context-Aware and Relation-Aware Graph RAG》（WWW 2026，arXiv 2606.18075）：https://arxivlens.com/PaperView/Details/a-unified-framework-for-context-aware-and-relation-aware-graph-retrieval-augmented-generation-8713-8e4589fa
• BAAI 视点对 QA-GraphRAG 的中文解读：https://hub.baai.ac.cn/view/54807
• 《RAG Is Not Dead: How Retrieval-Augmented Generation Evolved in 2026》：https://ainewsgrid.com/blog/rag-not-dead-retrieval-augmented-generation-2026
• 智源社区关于 LightRAG / nano-GraphRAG 生态的整理：https://ima.qq.com/wiki/?shareId=5290662a81503203bcfb3020826556eca932dad8e8508405b17703b02baae921