推荐语
清华团队提出NaviRAG，让RAG系统像人类一样“先定位、再觅食”，在长文档问答中实现更精准、高效的检索。
核心内容：
1. 传统RAG在长文档问答中的三大痛点
2. NaviRAG“先定位、再觅食”的两阶段检索范式
3. 在五大基准测试上的显著性能提升与效率优势
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
一句话讲清楚👉🏻 清华、南大、东北大学团队提出 NaviRAG，把文档组织成可导航的层次知识树，让 LLM Agent 像翻书一样"先定位、再觅食"，在五大长文问答基准上相比扁平 RAG 全面胜出，F1 最高涨 4.8 分，召回率提升 5.5 个点，且 Token 消耗只是 GraphRAG 的一半不到。
RAG 卡在哪里
打开过一本厚书找答案的人应该都有体会：你不会把整本书切成小纸条撒一地再挨个翻——你会先看目录、再翻章节、然后定位段落。但过去几年的 RAG （检索增强生成） 系统，基本就是在干撒纸条的事。
主流做法把文档切成固定粒度的文本块，建向量索引，查询来了算相似度，取 top-k 喂给大模型。这套流程在简单问答上跑得不错，可一旦遇到跨章节、多跳、条件复杂 的长文档问题就开始掉链子，主要卡点有三个：
•粒度两难：切得太细，片段缺少上下文，模型看不懂；切得太粗，噪声过多，关键证据被淹没。•被动一次性：查询一次检索一把，拿到什么是什么，信息不够也没法补。•扁平化：忽略了文档本身天然的层次结构——目录、章节、子节、细节——这些语义关系全被拍扁成了平面。
GraphRAG 、 RAPTOR 、 HippoRAG 这些后继方案做了很多补救，有的建图、有的造树、有的加记忆。但检索本身仍是一次性的被动过程，没有真正模仿人类查阅资料的节奏。
两类典型的复杂长链推理场景：示例查询、检索难点、传统 RAG 的局限，以及 NaviRAG 的应对思路。
清华大学孙茂松教授团队（联合南京大学、东北大学）这次给出了一个新答案：NaviRAG——从被动检索转向主动导航。
从"觅食"到"导航"：方法论灵感
NaviRAG 的方法论底子来自认知心理学里的信息觅食理论（ Information Foraging Theory ， Pirolli & Card, 1999 ）。这套理论有一个朴素的观察：人类获取信息不是一次性抓取，而是沿着"信息气味（ information scent ）"做序列化探索——看到一条线索，顺藤摸瓜，发现信息不足就回头换路径。
把这个直觉搬到 RAG 上，作者提出一个两阶段的 "先定位，再觅食" 检索范式：
1.先定位：用传统向量检索快速圈出一个相关的语义子空间，避免在整个语料里乱撞。2.再觅食：在这个子空间内，由一个 LLM Agent 沿着预先组织好的层次结构自顶向下导航，每一步决定是"吸收当前节点"还是"继续向下展开"。
这样做的好处很直接：检索的粒度不再是预先固定的，而是随查询需求动态调整——要宽泛背景就停在高层摘要，要具体证据就下钻到叶子节点。
NaviRAG 的整体流程
整个框架拆成两个阶段——离线的知识组织 和在线的导航检索。
NaviRAG 的两阶段框架：离线阶段把文档组织成层次结构（自顶向下的语义路由 + 自底向上的 refusion 与摘要）；在线阶段先做语义定位，再在定位到的子树内导航检索。
范式定义
给定文档集合 D 和查询 q ，离线阶段把文档组织成层次结构 H ，在线阶段在 H 上做导航，得到最终上下文集合 C ，然后交给 LLM 生成答案 y 。
上下文集合由三部分组成：
Cvec ∪ Csum ∪ Craw
分别对应初始向量检索片段、中间层摘要 和按需展开的原始文本。三种粒度混合，才能覆盖从概念到证据的不同需求。
知识树是怎么建起来的
NaviRAG 里每一个节点都包含三个字段：
•title：语义标识符，像章节标题一样概括节点内容；•summary：跨层访问时的摘要字段，让上层能快速感知下层的语义。
建树的过程分三步：
第一步：搭骨架。 先让 LLM 基于文档生成一份高层语义大纲，形成知识树的初始 H0 。
第二步：往里塞。 把文档切成片段（ chunk token size = 512 ， overlap 0.2 ），一块一块插入树里。插入不是随便挂的，而是由 LLM 决定这块内容属于哪个节点，可能合并进已有节点，也可能新建子节点。论文给出的核心算法是这样：
输入: 知识树 H, 片段 s_i, 当前路径 p
1. N ← Children(H, p)
2. A ← Select(s_i, N) // 选择匹配的子节点
3. if A = ∅ then
4. H ← CreateNode(H, p, s_i); return H // 没有匹配，新建节点
5. end if
6. for each node n ∈ A do
7. if n 是中间节点 then
8. H ← U(H, s_i, n) // 递归下降
9. else
10. H ← MergeContent(H, n, s_i) // 叶节点合并内容
11. if Len_tokens(n) > τ_text then
12. H ← SplitNode(H, n) // 超长则分裂
13. end if
14. end if
15. end for
16. if NumberOfNodes(level(p)) > τ_level then
17. H ← SoftGrouping(H, level(p)) // 同层过多则软聚类
18. end if
19. return H
这里有两个值得注意的控制参数：τ_text 控制叶节点内容长度，超过就分裂；τ_level 控制同一层节点数，超过就触发软聚类（ soft grouping ），保持树的平衡性。
第三步：回炉精炼。 塞完所有片段后，做一次 refusion 和 summary——自底向上整理内容、生成各节点摘要，让整棵树的语义表述更加干净一致。
整个过程完全由 LLM 驱动（论文里用的是 Qwen2.5-72B ），嵌入模型用的是 bge-m3 。
导航检索： Agent 怎么"读书"
知识树建好以后，在线检索的流程就像一个 Agent 在读一本有目录的书。
步骤一：向量检索定位候选集。 对查询 q 在所有节点（叶子 + 中间节点的摘要）上做向量检索，拿到 top-k 候选集 R ，再把这些节点映射到它们所在的语义子树 H_sub 。这一步是粗筛，目的是把检索范围从整本书收敛到一两个相关章节。
步骤二：逐层节点选择。 从子树顶层开始，每一层让 LLM 挑选与查询最相关的节点集合 A_t 。
步骤三：节点决策。 对每个选中的节点， Agent 做一个二元决策：π(n) 属于 {absorb, expand}——要么把节点内容吸收进最终上下文，要么继续展开它的子节点。这个决策是迭代进行的， Agent 可以根据已经收集到的信息判断"还缺什么"。
步骤四：混合上下文生成答案。 最终 Agent 吐出一个由向量检索片段、中间层摘要、按需展开的原始文本混合而成的上下文集合 C ，交给生成模型作答。
除了基础版，论文还提出了一个探索性的记忆增强版 ——维护一个动态记忆状态 m_t ，每吸收一个节点就更新一次记忆，下一步节点选择时把记忆也作为输入，让 Agent 对"已经知道了什么、还缺什么"有更全局的感知。
实验配置
基线方法： Vanilla RAG （扁平向量检索）、 GraphRAG 、 LightRAG 、 HippoRAG2 。
模型配置：
- 知识组织阶段统一用 Qwen2.5-72B
- QA 评估涵盖四个模型： Qwen3-14B 、 Qwen3-32B 、 Qwen3-30B-A3B 、 LLaMA3.3-70B
- 嵌入模型 bge-m3
- top-k 默认取 5
数据集覆盖五大长文档问答基准：
| 数据集 | 查询数 | 文档数 | 平均文档长度（ k tokens ） |
|---|
| NarrativeQA | 293 | 10 | 59.56 |
| Loogle Short | 501 | 24 | 23.84 |
| Loogle Long-Script | 642 | 80 | 41.26 |
| Loogle Long-Wiki | 459 | 60 | 22.12 |
| LongBench v2 | 103 | 103 | 77.92 |
文档规模从 2 万 token 到近 8 万 token ，覆盖叙事小说、脚本、维基百科等不同文本类型。
主结果：六项指标四项第一
在 LLaMA3.3-70B 作为生成模型的设定下， NaviRAG 与四个基线的全面对比：
| 方法 | NarrativeQA F1 | NarrativeQA Recall | Loogle Short | Loogle Long-Script | Loogle Long-Wiki | LongBench v2 |
|---|
| Vanilla | 27.80 | 73.23 | 76.64 | 41.58 | 44.66 | 40.78 |
| GraphRAG | 30.17 | 85.34 | 66.46 | 44.85 | 42.48 | 38.83 |
| LightRAG | 28.98 | 86.69 | 67.46 | 37.38 | 36.81 | 34.95 |
| HippoRAG2 | 27.88 | 74.57 | 86.02 | 41.74 | 44.66 | 40.78 |
| NaviRAG | 32.60 | 78.69 | 79.04 | 45.01 | 44.88 | 42.72 |
关键观察：
•在 NarrativeQA F1 上， NaviRAG 达到 32.60 ，相比 Vanilla 提升 4.8 分（+17%）；•在 Loogle Long-Script 和 LongBench v2 这两个对跨段推理要求最高的基准上， NaviRAG 都是第一；•LightRAG 在召回率上最高，但 F1 表现不够稳定——这说明召回率高不等于最终答案好，证据的定位精度比单纯的覆盖面更重要；•HippoRAG2 在 Loogle Short 上表现亮眼，但到了更长的文档就退回基线水平。
跨模型一致提升
一个方法能不能在不同规模的模型上都奏效，是判断其通用性的关键。论文用四个 LLM 做了交叉验证（下表括号内是相对 Vanilla 的绝对提升）：
| LLM | NarrativeQA F1 | Recall | Loogle Short | Long-Script | Long-Wiki | LongBench v2 |
|---|
| Qwen3-14B | 28.10 (+2.34) | 78.81 (+5.58) | 76.24 (+0.8) | 40.03 (+5.61) | 40.95 (+2.61) | 32.04 (-1.94) |
| Qwen3-32B | 28.92 (+1.87) | 78.82 (+5.59) | 77.84 (+0.2) | 44.85 (+3.27) | 43.79 (+1.31) | 40.78 (-0.97) |
| Qwen3-30B-A3B | 27.43 (+1.12) | 77.82 (+4.59) | 79.44 (+2.6) | 42.67 (-0.63) | 49.23 (+2.39) | 45.63 (+2.91) |
| Llama3.3-70B | 32.60 (+4.80) | 78.69 (+5.46) | 79.04 (+2.4) | 45.01 (+3.43) | 44.88 (+0.22) | 42.72 (+1.94) |
召回率维度，四个模型上 NaviRAG 都能带来 +4.5 ~ +5.6 的稳定提升；生成质量维度 整体向上，只有个别组合略有下滑（如 LongBench v2 在小模型上 -1.94 ， Long-Script 在 MoE 模型上 -0.63 ）——说明检索的增益在大模型上表现更充分。
消融实验：拆哪个都掉
层次结构和导航机制到底哪个更重要？论文的消融实验给出了答案：
| 设置 | NarrativeQA F1 | Recall | Loogle Short | Long-Script | Long-Wiki | LongBench v2 |
|---|
| NaviRAG （完整版） | 32.60 | 78.69 | 79.04 | 45.01 | 44.88 | 42.72 |
| w/o reading （去导航） | 30.52 | 73.00 | 72.85 | 39.71 | 41.17 | 42.72 |
| w/o knowledge base （去层次结构） | 27.69 | 59.09 | 77.64 | 40.03 | 43.13 | 40.78 |
砍掉导航， Recall 从 78.69 掉到 73.00 ， F1 掉 2 分；砍掉层次结构， Recall 直接从 78.69 崩到 59.09 ， F1 也退回 Vanilla 水平。两个模块是协同起效 的——光有树但没人导航，或光有 Agent 但没树可爬，都走不通。
记忆模块的加成
在 LLaMA3.3-70B 的 LooGLE-long 上做了记忆模块的对比：
| 方法 | Script | Wikipedia |
|---|
| Vanilla | 41.58 | 44.66 |
| NaviRAG | 45.01 | 44.88 |
| NaviRAG w/ Memory | 45.48 | 47.27 |
记忆模块让 Script 再涨 0.47 、 Wikipedia 再涨 2.39 。虽然不是所有场景都需要，但对跨段依赖强的任务有额外收益。
效率账本： NaviRAG 并不烧 Token
很多"更强的 RAG"代价是猛涨 Token 和时间。 NaviRAG 在这方面表现克制：
| 方法 | F1 | Tokens | Time (s/query) |
|---|
| Vanilla | 27.80 | 2560 | 1.01 |
| HippoRAG2 | 27.88 | 2635 | 1.36 |
| GraphRAG | 30.17 | 7249 | 14.30 |
| LightRAG | 28.98 | 18896 | 4.27 |
| NaviRAG | 32.60 | 3305 | 3.23 |
F1 排第一，Token 只有 GraphRAG 的 45%、 LightRAG 的 17%，延迟 3.23 秒比 GraphRAG 的 14.30 秒快了四倍多。这在实际部署里是关键——效果一般、但成本可控。
知识库一次性构建时间：
| 方法 | 构建时间（ min ） |
|---|
| HippoRAG2 | 40.58 |
| LightRAG | 61.93 |
| GraphRAG | 225.93 |
| NaviRAG | 99.95 |
| NaviRAG (batch) | 51.28 |
开启批量模式后 NaviRAG 的构建时间压到 51 分钟，比 LightRAG 还快。
更少的 top-k ，更高的上限
一个有意思的附加实验是不同 top-k 下的效率对比：
| 方法 | k=3 | k=5 | k=7 | k=9 | k=15 |
|---|
| Vanilla F1 / Tokens | 25.06 / 1536 | 27.80 / 2560 | 29.75 / 3584 | 30.24 / 4608 | 31.28 / 7908 |
| NaviRAG F1 / Tokens | 30.57 / 2089 | 32.60 / 3305 | 33.75 / 4392 | 33.22 / 5422 | 34.27 / 8411 |
NaviRAG 在 k=3 时的 F1 （ 30.57 ）已经超过 Vanilla k=15 的 31.28 的大部分。换句话说，同样的预算下 NaviRAG 能用更少的候选集做出更好的答案，因为导航阶段把每一份 token 都用在了刀刃上。
文本类型偏好：脚本比维基受益更大
作者观察到 NaviRAG 在脚本类文档 上的提升幅度显著大于维基百科文档。背后的解释很直接：
•脚本文本语义连续性强、跨段依赖紧密——故事的前因后果往往隔着几十页，导航式检索恰好能把这些跨段证据串起来；•维基百科由相对独立的章节 组成，段落间依赖较弱——传统扁平检索就已经够用，层次结构和导航带来的边际收益较小。
这个发现对实际应用选型有启示：文档结构越"流式"、证据越分散的场景， NaviRAG 的收益越大；而对已经高度模块化的文档库（如产品手册、知识百科），投入产出比可能不如直接上 Vanilla 。
关键超参数速查
| 类别 | 参数 | 取值 |
|---|
| 组织阶段 | Chunk Token Size | 512 |
| 组织阶段 | Overlap Rate | 0.2 |
| 组织阶段 | Num Select Titles | 2 |
| 组织阶段 | Max Content Length | 1536 |
| 组织阶段 | Max Titles Num | 12 |
| 检索阶段 | Top-k | 5 |
| 检索阶段 | Max Context Tokens | 8192 |
局限与展望
作者自己点明了当前版本的边界： NaviRAG 目前聚焦于受限语义上下文下的复杂推理任务，面对多源知识整合场景还需要更多探索。未来的方向主要有三条：
1.混合检索机制：把垂直的树形导航与水平的图结构检索结合，统一多种知识组织方式；2.结构感知的知识组织：利用文档本身的显式结构（章节、标题、元数据），减少对 LLM 重组的依赖；3.记忆驱动的全局导航：扩展记忆机制让 Agent 具备跨查询、跨文档的全局信息整合能力。
写在最后
NaviRAG 这篇论文传达的核心观点其实很朴素：检索不是一次性的抓取，而是一个可导航的序列探索过程。这和过去几年 RAG 领域各种改造（建图、造树、加链、加记忆）的底层诉求是一致的——让检索更智能、更自适应、更像人类读书的样子。
NaviRAG 的价值不在于哪个数字涨了多少，而在于它把"主动导航"这件事的工程实现做得足够简洁、成本足够可控——层次树 + Agent 决策，没有非常重的额外组件，却能在五大基准上全面压制更复杂的 GraphRAG 、 LightRAG 。对工业界要落地长文档 RAG 系统的人来说，这是一个很值得参考的中间答案。
粤ICP备14082021号
免费POC，
零成本试错
