清华提出NaviRAG：让RAG学会"主动导航"，长文问答F1涨4.8分

一句话讲清楚👉🏻 清华、南大、东北大学团队提出 NaviRAG，把文档组织成可导航的层次知识树，让 LLM Agent 像翻书一样"先定位、再觅食"，在五大长文问答基准上相比扁平 RAG 全面胜出，F1 最高涨 4.8 分，召回率提升 5.5 个点，且 Token 消耗只是 GraphRAG 的一半不到。

RAG 卡在哪里

打开过一本厚书找答案的人应该都有体会：你不会把整本书切成小纸条撒一地再挨个翻——你会先看目录、再翻章节、然后定位段落。但过去几年的 RAG （检索增强生成） 系统，基本就是在干撒纸条的事。

主流做法把文档切成固定粒度的文本块，建向量索引，查询来了算相似度，取 top-k 喂给大模型。这套流程在简单问答上跑得不错，可一旦遇到跨章节、多跳、条件复杂 的长文档问题就开始掉链子，主要卡点有三个：

GraphRAG 、 RAPTOR 、 HippoRAG 这些后继方案做了很多补救，有的建图、有的造树、有的加记忆。但检索本身仍是一次性的被动过程，没有真正模仿人类查阅资料的节奏。

清华大学孙茂松教授团队（联合南京大学、东北大学）这次给出了一个新答案：NaviRAG——从被动检索转向主动导航。

从"觅食"到"导航"：方法论灵感

NaviRAG 的方法论底子来自认知心理学里的信息觅食理论（ Information Foraging Theory ， Pirolli & Card, 1999 ）。这套理论有一个朴素的观察：人类获取信息不是一次性抓取，而是沿着"信息气味（ information scent ）"做序列化探索——看到一条线索，顺藤摸瓜，发现信息不足就回头换路径。

把这个直觉搬到 RAG 上，作者提出一个两阶段的 "先定位，再觅食" 检索范式：

这样做的好处很直接：检索的粒度不再是预先固定的，而是随查询需求动态调整——要宽泛背景就停在高层摘要，要具体证据就下钻到叶子节点。

NaviRAG 的整体流程

整个框架拆成两个阶段——离线的知识组织 和在线的导航检索。

范式定义

给定文档集合 D 和查询 q ，离线阶段把文档组织成层次结构 H ，在线阶段在 H 上做导航，得到最终上下文集合 C ，然后交给 LLM 生成答案 y 。

上下文集合由三部分组成：

分别对应初始向量检索片段、中间层摘要 和按需展开的原始文本。三种粒度混合，才能覆盖从概念到证据的不同需求。

知识树是怎么建起来的

NaviRAG 里每一个节点都包含三个字段：

建树的过程分三步：

第一步：搭骨架。 先让 LLM 基于文档生成一份高层语义大纲，形成知识树的初始 H0 。

第二步：往里塞。 把文档切成片段（ chunk token size = 512 ， overlap 0.2 ），一块一块插入树里。插入不是随便挂的，而是由 LLM 决定这块内容属于哪个节点，可能合并进已有节点，也可能新建子节点。论文给出的核心算法是这样：

这里有两个值得注意的控制参数：τ_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

数据集覆盖五大长文档问答基准：

文档规模从 2 万 token 到近 8 万 token ，覆盖叙事小说、脚本、维基百科等不同文本类型。

主结果：六项指标四项第一

在 LLaMA3.3-70B 作为生成模型的设定下， NaviRAG 与四个基线的全面对比：

关键观察：

跨模型一致提升

一个方法能不能在不同规模的模型上都奏效，是判断其通用性的关键。论文用四个 LLM 做了交叉验证（下表括号内是相对 Vanilla 的绝对提升）：

召回率维度，四个模型上 NaviRAG 都能带来 +4.5 ~ +5.6 的稳定提升；生成质量维度 整体向上，只有个别组合略有下滑（如 LongBench v2 在小模型上 -1.94 ， Long-Script 在 MoE 模型上 -0.63 ）——说明检索的增益在大模型上表现更充分。

消融实验：拆哪个都掉

层次结构和导航机制到底哪个更重要？论文的消融实验给出了答案：

砍掉导航， Recall 从 78.69 掉到 73.00 ， F1 掉 2 分；砍掉层次结构， Recall 直接从 78.69 崩到 59.09 ， F1 也退回 Vanilla 水平。两个模块是协同起效 的——光有树但没人导航，或光有 Agent 但没树可爬，都走不通。

记忆模块的加成

在 LLaMA3.3-70B 的 LooGLE-long 上做了记忆模块的对比：

记忆模块让 Script 再涨 0.47 、 Wikipedia 再涨 2.39 。虽然不是所有场景都需要，但对跨段依赖强的任务有额外收益。

效率账本： NaviRAG 并不烧 Token

很多"更强的 RAG"代价是猛涨 Token 和时间。 NaviRAG 在这方面表现克制：

F1 排第一，Token 只有 GraphRAG 的 45%、 LightRAG 的 17%，延迟 3.23 秒比 GraphRAG 的 14.30 秒快了四倍多。这在实际部署里是关键——效果一般、但成本可控。

知识库一次性构建时间：

开启批量模式后 NaviRAG 的构建时间压到 51 分钟，比 LightRAG 还快。

更少的 top-k ，更高的上限

一个有意思的附加实验是不同 top-k 下的效率对比：

NaviRAG 在 k=3 时的 F1 （ 30.57 ）已经超过 Vanilla k=15 的 31.28 的大部分。换句话说，同样的预算下 NaviRAG 能用更少的候选集做出更好的答案，因为导航阶段把每一份 token 都用在了刀刃上。

文本类型偏好：脚本比维基受益更大

作者观察到 NaviRAG 在脚本类文档 上的提升幅度显著大于维基百科文档。背后的解释很直接：

这个发现对实际应用选型有启示：文档结构越"流式"、证据越分散的场景， NaviRAG 的收益越大；而对已经高度模块化的文档库（如产品手册、知识百科），投入产出比可能不如直接上 Vanilla 。

关键超参数速查

局限与展望

作者自己点明了当前版本的边界： NaviRAG 目前聚焦于受限语义上下文下的复杂推理任务，面对多源知识整合场景还需要更多探索。未来的方向主要有三条：

写在最后

NaviRAG 这篇论文传达的核心观点其实很朴素：检索不是一次性的抓取，而是一个可导航的序列探索过程。这和过去几年 RAG 领域各种改造（建图、造树、加链、加记忆）的底层诉求是一致的——让检索更智能、更自适应、更像人类读书的样子。

NaviRAG 的价值不在于哪个数字涨了多少，而在于它把"主动导航"这件事的工程实现做得足够简洁、成本足够可控——层次树 + Agent 决策，没有非常重的额外组件，却能在五大基准上全面压制更复杂的 GraphRAG 、 LightRAG 。对工业界要落地长文档 RAG 系统的人来说，这是一个很值得参考的中间答案。