核心思想：把文档目录树从 Prompt 里卸载到外部存储，按需访问；用”证据缺口”驱动多轮检索而不是全量序列化；把检索轨迹物化为经验边复用。Token 消耗降到 SOTA 的 5.1%–32.5%，同时精度持平。

1. 论文信息

2. 问题：文档结构是双刃剑

结构化文档（章节、段落、目录树）包含了检索的重要线索——一个事实在哪个章节、局部细节如何关联到上层主题、证据可能分布在哪些位置。

现有方法的问题：

方法 做法 缺陷
朴素 chunk-embed-retrieve 把文档压成扁平块 丢失结构信息
SQL-RAG 关系数据库做检索 不适合自由文本
GraphRAG 建语义图 忽略原始目录结构
MoDora / BookRAG / KohakuRAG 利用文档结构导航 缺乏”证据缺口驱动的多轮检索”——无法判断还缺什么
DeepRead Agent 多轮导航目录 把完整目录全文塞进 Prompt，token 爆炸

核心矛盾：结构信息对检索很有用，但把它全部塞进 Prompt 成本太高。

3. 核心技术：三招压缩 token

3.1 存储模型：Prompt 解耦 + 目录结构保留

VikingRAG 的核心设计是把文档目录树从 Prompt 里搬出去，存成外部可寻址状态：

文档目录树 → URI 可寻址对象
  ├── 叶子节点 = chunk 内容
  ├── 内部节点 = 摘要（从子节点汇总生成）
  └── 路径保留结构包含关系

语义搜索（向量索引）和结构导航（目录浏览）共用同一套 URI，所以：

  • 语义搜索结果 → 直接跳转相关对象及其上层目录
  • 目录 URI → 限定后续语义/词法搜索的范围

Agent 不是在 Prompt 里读目录，而是调用四个文档访问工具：

工具 作用
Search 语义搜索，返回相关 chunk/节点 URI
List 查看某个目录下的内容
Grep 在指定目录内做词法搜索
Read 按 URI 读取具体内容

这样 Prompt 里的结构上下文按需暴露，而不是全量序列化。

3.2 证据缺口驱动的多轮检索

不是预先定义好要查哪些章节，而是：

  1. Agent 拿到当前问题 + 已积累的证据
  2. 判断证据是否充分回答问题
  3. 如果不充分 → 识别缺口 → 调用访问工具补充证据
  4. 重复直到证据充分或达到轮次上限

这和 DeepRead 的思路一致，但 token 效率完全不同：DeepRead 把完整候选文档目录全量序列化到 Prompt，VikingRAG 只访问实际需要的目录片段。

3.3 经验边：检索轨迹物化复用

VikingRAG-E 的优化：多轮检索跑完后，把”初始检索 URI → 答案支撑 URI”这条路径记成一条经验边，并记录查询上下文。

后续相似 query 来了，直接激活匹配的经验边，不需要重新跑多轮探索。

3.4 自适应升级：简单 query 直接放行

VikingRAG-E+ 加了一层证据充分性检查：

一轮检索 + 经验边增强
    ↓ 证据充分性检查
通过 → 直接生成答案
失败 → 升级到多轮 Agent 检索

这样简单 query 或已被经验覆盖的 query 不触发昂贵的多轮检索。

4. 评估结果

场景 Token 相对 SOTA
VikingRAG（基础） 11.6%–51.9%
VikingRAG-E（+经验边） 更低
VikingRAG-E+（+自适应升级） 5.1%–32.5%

精度保持竞争力，存储性能实用。

5. 为什么这个工作值得注意

工程角度：结构化文档 RAG 的正确打开方式

企业知识库、长文档问答、合规材料检索——这些场景文档都有明确的目录结构。VikingRAG 展示了”把结构信息外部化、按需访问”这条路是走得通的，而且 token 收益显著。

架构角度：存储模型决定 Prompt 形状

大多数 RAG 优化集中在检索算法或生成模型上。VikingRAG 的启示是：如果存储模型设计得当，很多上下文根本不需要进 Prompt。这是架构层面的压缩，比压缩已有 Prompt 更根本。

当前局限

  • 经验边的冷启动问题：新文档库没有历史轨迹，初期收益有限
  • 目录结构的质量依赖文档解析的准确性
  • 多轮检索轮次上限需要人工设定

6. 一句话总结

VikingRAG 把文档目录从 Prompt 里卸载到外部存储，按需访问；用证据缺口驱动多轮检索代替全量序列化；把检索轨迹物化为可复用经验边。三招下来，Token 消耗降到 SOTA 的 5.1%–32.5%，同时精度持平。这重新定义了结构化文档 RAG 的工程边界：不是让模型更聪明，而是让存储和检索更懂事。

论文：“VikingRAG”，arXiv 2609.11390