论文：ZoomRAG: Hierarchical Random-walk Zooming across Multi-scale Information Graphs for Fast and Accurate RAG
会议：ACL 2026
单位：华东师范大学 · 复旦大学 · 西南石油大学
联系：52285901020@stu.ecnu.edu.cn | kzhang@cs.ecnu.edu.cn假如让一个人去一个陌生城市找一家小店，他通常不会一开始就把地图放到最大。
他会先看整个城市，大致定位街区，再双指放大到具体门牌。一次"缩放"比在全景里满街扫要高效得多。
但今天的RAG（Retrieval-Augmented Generation，检索增强生成）系统，主流路线却常常不是这样工作的。
面对一个动辄上万文档的知识库，它们要么把所有文本切成小块，全语料上算相似度（像拿放大镜扫全城找店铺）；要么先花几小时调用大模型，把整个知识库抽成一张"实体---关系"的知识图谱，再在图上反复多跳搜索（像为了找一家店先把整座城市重新测绘一遍）。
这两条路线看似在两端取舍，其实都卡在同一个困境里：RAG 的"索引开销"、"在线速度"、"并发能力"这三件事 很难同时做好，一是离线索引太贵。
以基于知识图谱的方法为例，构建一次索引往往要调用 LLM 反复抽取"实体---关系---实体"三元组，耗时动辄数小时甚至数十小时，内存占用也常常高达几十 GB。
二是在线检索太慢 。显式的图路径搜索和复杂的多跳推理，使单条 query的延迟动辄几秒到十几秒，很难满足真实产品对响应时间的要求。三是并发几乎无解。
现有基于结构化索引的方法大多只能串行执行，如果用朴素的数据并行直接复制整张图，几十条并发就会把显存打爆。
ACL 2026论文ZoomRAG(华东师范大学、复旦大学、西南石油大学联合提出）给了一个干脆的答案：完全不建知识图谱，只用最便宜的命名实体识别(NER）搭两层不同粒度的关系图，让带重启的随机游走像双指缩放地图一样------先在一张全局粗粒度图上锁定少量相关文档，再在这些文档内部的细粒度局部图上精准定位证据块，从而系统地激活RAG的"先粗后细"能力。
这个设计听起来朴素，但把RAG系统在四个维度上一起往前推了一大截：准确率、离线索引开销、单条延迟、以及并发吞吐。方法的整体结构如下图。
图 1：ZoomRAG 的两阶段检索流程------先在全局图上做 DocZoom 粗筛，再在局部图上做 ChunkZoom 精筛。
ZoomRAG 的三件事
第一，粗粒度 DocZoom：在全局图上锁定相关文档。
ZoomRAG第一层图是一张三部图：一个查询节点、所有文档节点、所有实体节点。边也只有四种------文档与文档的语义相似度（Jina embedding 内积并稀疏化）、查询与文档的相似度、文档里出现的实体、查询里提到的实体。
从查询节点出发跑一次带重启的随机游走（Random Walk with Restart），就能在整个语料上得到 Top-K 最相关文档。
这里有个容易被忽略但很关键的细节：HippoRAG、LinearRAG等方法在游走时把查询节点用完就丢，只让它的一阶邻居继续传播；ZoomRAG则把查询节点保留在每一轮的重启分布里，让"查询语义"像一根锚一样贯穿始终，避免游走漂走。
第二，细粒度 ChunkZoom：在选中的文档内部定位证据块。
拿到 Top-K 文档后，ZoomRAG 在这些文档内部再搭一张小图，只含文本块节点和实体节点，通常只有几十个节点。这层图的巧思在于------把"时间"也编码进了边权：块和块之间的边不只是语义相似度，还叠加了一个基于原文位置的高斯邻近项。
为什么这一点重要？多跳推理中，关键证据之间往往有天然的顺序（"因为A所以B导致C"）。把这种顺序信号直接写进图里，等于在检索阶段就帮下游LLM做了一次证据排序，而不是扔一堆零散片段让它自己拼逻辑。由于图极小，这一步还可以直接解稳态方程（一次小矩阵求逆），比迭代传播更精确。
第三，算法级并行：让一张图服务成百条查询。
ZoomRAG最容易被忽视、但工业界最在意的贡献，是它的 Algorithm-Parallel版本。传统做法面临两难：串行太慢；朴素数据并行又要每次复制一整张全局图，几十条并发就会 OOM。
ZoomRAG在数学上把"跨查询共享的文档---实体图 "和"每条查询独立的向量"严格解耦，只存一份全局图，再用批量矩阵运算把所有query的随机游走一次算完。三种方案的时间/空间复杂度对比如下。
图 2：三种并行方案的时间/空间复杂度------算法级并行在保持速度的同时大幅压缩内存。
实验结果
评估围绕三件事展开：多跳QA的答题准确率、证据检索的召回率、以及端到端的系统开销（离线索引、在线延迟、并发可扩展性）。
作者在 2WikiMultiHopQA、HotpotQA、MuSiQue 三个多跳问答榜单上与12个基线（RAPTOR、SiReRAG、GraphRAG、HippoRAG/HippoRAG 2、HopRAG、LightRAG、LinearRAG 等）做了严格对比，所有方法均用官方代码复现，统一采用GPT-4o-mini 作答、jina-embeddings-v3 做嵌入。
准确率：三个榜单全部 SOTA。 ZoomRAG平均 F1 达到 68.01，比此前最强的HippoRAG 2高3.0个百分点，EM/F1 在不同数据集上的绝对提升稳定在 2.2%--4.9%。
图 3：三个多跳问答榜单上的 EM/F1 对比
**召回率：先粗后细没有丢证据。**多阶段检索的固有风险是第一阶段漏文档、后面再精细也救不回来。
ZoomRAG三个数据集上的证据召回率全部最高，平均达到 94.32%，比 HippoRAG 2高2.61个百分点，在 MuSiQue上差距拉到+5.55个百分点------这说明ZoomRAG的粗筛阶段依靠全局图上的随机游走保证文档覆盖率，细筛阶段再在局部图上精确定位关键证据块，两步形成互补而不是串联叠错。
图 4：三个数据集上的证据检索召回率
效率：这可能是 ZoomRAG 最有冲击力的数字。 离线索引平均只要 346 秒------对比 LightRAG 的 153,474 秒（约 42 小时），是440 倍加速；对比 HippoRAG 2的3,343 秒，快 10 倍、省 6 倍内存。
在线单条query平均0.019 秒（即 19 毫秒），对比GraphRAG的15.35秒是807倍加速，对比目前最快的基线LinearRAG也仍有 6.8 倍优势。而且ZoomRAG的索引支持增量更新------新文档只需往邻接矩阵追加新行，不必重建整张图。
图 5：离线索引开销与在线检索效率对比
并发：512条query，内存几乎不动。 从1条并发扩到512条，ZoomRAG内存增长不到1%，单条延迟从 0.129 秒一路降到 0.019 秒；朴素数据并行的基线在 27 条并发时就 OOM 了。这个差距直接决定了系统能不能真的放进产品里服务大规模用户。
图 6：并发设定下的内存占用与单条延迟------算法级并行几乎不随 batch size 增长。
大规模扩展：5M 到 50M token 近线性。 把语料从 5M 扩到 50M token，ZoomRAG 索引时间和内存都近线性增长；50M token 下 5,753 秒、32.5 GB------相比 LinearRAG 的 136,426 秒、124.9 GB，是 23 倍加速、73% 内存节约。
图 7：5M--50M token 语料下 ZoomRAG 与 LinearRAG 的索引开销对比。
一个反直觉的发现：索引做减法，效果反而更好
在所有参与对比的方法中，准确率最高的不是那些花费数万秒、调用LLM反复抽取三元组的知识图谱方法，而是ZoomRAG这个只依赖命名实体识别（NER）、甚至显得"朴素"的方案。
这说明，对RAG而言，"索引做得更重"和"检索效果更好"之间没有必然的正相关。知识图谱理论上能表达更丰富的关系，但三元组抽取本身是噪声来源------大模型在长文本里抽出的关系常常带幻觉和冗余，越大的图越容易把错误放大。
ZoomRAG的性能优势反而来自另一种思路：不再试图在一张大图里把所有关系一次性刻画清楚，而是让不同尺度的信息在不同阶段各司其职。对需要穿透多跳关系、找到正确证据链的任务来说，这种"先粗后细"的状态，反而比一张显式但充满噪声的知识图谱更利于检索的稳定性。
消融实验也印证了这一点：去掉粗粒度文档---文档边，平均 F1 掉 14个点；去掉细粒度块---块边（含时序和语义），再掉10个点；去掉实体节点，整体塌15.6个点。ZoomRAG 里每一条边都不是摆设------这种"精确到位"的设计，恰恰是臃肿的知识图谱很难做到的。
图 8：消融实验
写在最后
这几年结构化 RAG 的研究里，有一种"越重越强"的路径依赖：索引越做越大，图越建越复杂，好像更强的RAG必然意味着更昂贵的知识图谱。
ZoomRAG反着走一步------把索引做减法，把算法做加法:十分之一的索引开销、百倍级的在线加速、以及可扩展到上百并发的算法设计，换来的却是三个多跳榜单上最高的准确率。
这或许也是一个信号：在知识图谱之外，结构化 RAG 还有尚未被充分挖掘的空间。至于那些曾被默认"必须付出"的索引代价，也许值得重新审视一下。