做过企业知识库的工程师，多半都有过「账单恐惧症」。原因不复杂：想让 RAG 在按章节组织的长文档上答得准，就得利用文档结构；而当前表现突出的结构感知方法，为了让 Agent 自由导航，会把候选文档的完整目录序列化进提示词。这相当于让图书管理员每回答一个问题，先把整本书的目录从头到尾背一遍——多轮检索下来，交互历史还会滚雪球式膨胀。9 月 10 日提交至 arXiv 的论文 VikingRAG（编号 2609.11390），试图把这个问题从「提示词技巧」拉回到「数据管理」的框架里解决。
先看那个让人血压升高的数字
据论文与相关技术解读，在 VersionQA 数据集上，被列为基线的 DeepRead 回答一个问题要消耗约 11.6 万 Token。这个量级放到企业场景里意味着什么？一家公司搭个知识库，一百名员工每人每天问二十个问题，成本会迅速放大到需要专门立项优化的程度。
论文把开销来源拆成两处：一是「结构上下文」，也就是把目录、层级、章节信息塞进提示词带来的开销；二是「多轮交互」，也就是 Agent 为凑齐分散各处的证据而反复检索、历史不断累积带来的开销。麻烦在于，简单砍掉任何一处都会伤精度——目录不进提示词，Agent 就看不见结构；多轮砍成单轮，散落在远处的隐性证据就凑不齐。这本质上是一个「既要马儿跑、又要马儿少吃草」的系统设计问题。
解法一：把目录从提示词里搬出来，变成可寻址的对象
据论文说明，VikingRAG 是一个「目录感知的语义数据管理系统」，紧密集成语义访问与结构访问，支持「证据缺口驱动」的多轮检索。它的做法是把结构节点物化为可寻址的 URI 对象，向智能体提供四类工具：检索（找到相关节点）、列举（查看某层级有哪些子项）、匹配（判断某个节点是否与问题相关）、读取（获取具体内容）。
这个改动的意义在于，目录不再需要被完整塞进提示词。Agent 可以先「列举」某个目录，判断方向对不对，再决定「读取」哪一部分；结构信息从「一次性搬运的文本」变成了「按需查询的状态」。这与数据库领域「把数据放在外面、按需索引读取」的思路一致，也是论文读起来更像数据管理系统工作、而非提示词工程技巧的原因。
解法二：把检索轨迹存成「经验边」，让相似查询抄近道
据论文说明，为降低多轮交互的 Token 开销，VikingRAG 把 Agent 式的多轮检索轨迹物化为「经验边」，并在遇到相似查询时复用这些边，避免重复的多轮探索。通俗地说，首次遇到某类问题时走过的路径被记录下来，下次遇到类似问题时，系统可以直接沿着已知路径取数，而不必从零开始试探。
这个设计的收益高度依赖查询分布。当企业知识库的提问集中在少数高频主题上时，轨迹复用的收益显著；当提问高度长尾、彼此差异很大时，可复用的轨迹有限，收益会打折。论文给出的实验结果是在真实数据集上取得，其区间跨度也印证了这种分布依赖性。
解法三：自适应升级，把多轮检索留给真正需要的查询
据论文说明，为进一步压低那些「其实不需要多轮」的查询成本，VikingRAG 引入了自适应升级策略：当一轮经验增强检索已能凑齐足够证据时，直接作答；只有当证据不足时，才触发 Agent 式的多轮检索。这样一来，昂贵的多轮探索只在必要时发生，而不是每次提问都走一遍。
据论文公布的实验结果，基础版 VikingRAG 在保持与 SOTA 方法相当精度的前提下，Token 消耗仅为后者的 11.6% 至 51.9%；在叠加检索轨迹复用与自适应升级后，Token 成本进一步降至 5.1% 至 32.5%，同时保持有竞争力的精度与实用的文档存储性能。论文作者把这套机制视为面向「新兴 AI 知识库」的可用方案，其核心机制已集成进开源项目 OpenViking。
放进「上下文工程」这条线看
据公开信息，OpenViking 是一个面向 AI Agent 的开源上下文数据库，把记忆、资源与技能统一放在 viking:// 协议下组织成一个虚拟文件系统，Agent 用类似 ls、tree、find 的方式浏览自己的上下文，而不是查询一个黑盒向量库。它把内容在写入时处理成三个层级——L0 摘要（约百 Token，用于快速判断相关性）、L1 概述（约两千 Token，用于规划阶段决策）、L2 详情（完整原文，按需读取），并保留每次检索的轨迹供观察与调试。
把 VikingRAG 与 OpenViking 放在一起看，指向的是同一个判断：RAG 的成本问题，正在从「向量检索调参」变成「上下文如何被结构化地管理与按需加载」。这与近期编码智能体领域的另一条线也相互印证——无论是把工具输出关进沙箱以减少上下文占用，还是坚持用文件承载记忆、用编辑规则保证正确，讨论的都是同一件事：不要把一切塞进提示词，而要让 Agent 学会按需取用。
中立思辨
需要理性看待这篇论文。其一，文中所有 Token 降幅与精度数据均为作者自报，需对照 arXiv 原文与开源实现独立复现，不同数据集与查询分布下的实际收益差异较大，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。其二，11.6% 至 51.9% 与 5.1% 至 32.5% 是两个区间而非单点，区间宽度本身说明效果对任务构成敏感，选型前应先用自有数据做基准测试。其三，「经验边」复用对高频、相似查询收益明显，对长尾查询收益有限，在提问高度分散的企业知识库里，实际节省可能低于预期。其四，自适应升级策略中「证据是否足够」的判定阈值，是精度与成本之间的关键旋钮，论文未充分展开其对不同文档类型的影响，这一阈值如何设定可能显著改变结果。其五，文档更新后旧检索轨迹是否仍然有效、经验边如何失效与重建，是生产环境中绕不开的问题，公开信息对这部分讨论有限。其六，该方法面向的是章节、段落等结构化文档，对完全非结构化数据（如散乱聊天记录、扫描件）的收益可能明显下降。其七，把结构节点物化为 URI 对象，意味着需要一套稳定的标识与存储方案，其长期维护成本与迁移成本需要纳入整体评估。其八，开源集成版本与论文版本在实现细节上可能存在差异，两者结论不宜混用。
趋势研判
短期，RAG 的优化重心会从「检索准不准」扩展到「结构上下文与多轮交互的 Token 效率」，成本将成为与精度并列的一等指标；中期，围绕上下文的「文件系统化」与「分层加载」可能形成事实做法，让 Agent 像操作文件一样操作自己的上下文；长期，企业知识库的竞争会回到两件基础工作——文档结构能否被稳定表达，以及检索轨迹能否被安全复用与及时失效。谁能把这两件事做扎实，谁的知识库才可能既便宜又可信。