训练知识库：监督式结构学习如何让文档库学会“该在哪里建索引”

《Training a Knowledge Base: Supervised Structure Learning for Agent-Curated Document Stores》：将知识库视为一个非参数模型，用（问题，答案）对训练一个 curator agent 来增量构建索引结构，从而以极少的链接数量实现与全量无监督索引相当的检索性能提升。

文档库为什么需要被训练

传统 RAG 把文档库当作冻结的输入：嵌入一次，查询时检索，从不回写。这种方式把结构构建问题外包给离线管道，但那些管道是无监督的——GraphRAG 构建实体图，RAPTOR 构建摘要树，HippoRAG 构建个性化 PageRank 链接图，它们在没有任何查询信号的情况下对整个语料库均匀用力。这意味着系统不知道未来会问什么问题，只能把所有可能的结构都预先建好，结果浪费了大量结构预算，甚至引入了噪声。

论文的作者团队问了一个更直接的问题：如果知识库本身就是一个可以被训练的非参数模型，会怎样？训练过程让 curator agent 根据验证过的答案来编辑文档库的结构，这一过程替代了梯度下降。这相当于给 RAG 系统增加了一个“反向传播”阶段。

从无监督索引到监督式结构学习

论文的核心抽象是把知识库当成模型参数。一个 curator agent 面对当前文档库回答一个带监督标签的问题，然后看到 gold answer，根据差异编辑文档库：添加、删除、链接文档，或者构建索引文档。这个编辑后的文档库就是更新后的参数。训练数据是 (question, answer) 对；损失是冻结文档库后独立 reader 在测试集上的准确率和动作成本。

这个视角与现有方法的关键区别在于结构构建的信号来源。无监督索引从语料库本身推断结构，不知道哪些结构会被查询；监督式学习则把问题当作标签，让结构直接服务于实际查询分布。论文精确地定义了这种区别：无监督方法构建的是没有标签、没有提问概念的语料结构，而 (question, answer) 对是标签，结构是针对验证过的答案优化的。

这个差异带来的不是天花板上的提升，而是效率上的提升。同样是构建索引，监督式方法能把结构预算花在真正会被问到的地方。

KBGym 环境：一个可测量污染为零的实验台

为了度量这种训练是否有效，论文构建了一个名为 KBGym 的虚拟环境。它生成一个虚构的 500 人世界，包含家谱、配偶、朋友、职业、爱好、城市等属性，以及大量同名的干扰项。世界被渲染成 5,864 条原子单句文档（如“Alice Johnson’s job is arborist.”），初始文档库零链接，只是一个事实袋。十类诊断性问题覆盖一至三跳命名实体链、聚合计数、多约束连接、集合交集、出生日期最高值、反向查找等，答案精确可程序化判断，整个测量过程没有 LLM 裁判参与。

这个环境解决了一个关键问题：公开多跳 QA 语料库已经被当前大模型参数化污染，模型可以不需要检索就答对。在 KBGym 中，没有文档库的 reader 得分几乎为零，因此每个性能提升都必须来自文档库本身。

训练循环：前向回答，后向编辑

训练协议很简单。Phase 1 使用和测试时完全相同的 reader 工具集和预算，回答一个问题，看到 gold answer，记录轨迹。Phase 2 是 consolidation，curator agent 看到自己的轨迹、gold answer 和 F1，以及统一指令：找出这个问题提到的所有 key（人、地方、职业、爱好、关系），确保每个 key 都有一个完整的索引文档，缺失则建，不完整则扩展，已经完整则保持不动。

关键约束是索引文档不列举成员，而是通过链接指向成员。这样的索引在事实变化时依然有效。另一个约束是精确优先于完整：搜索返回的是相似的东西，不是真正属于 key 的东西，如果把整个搜索结果集都链接起来，就破坏了索引存在的确定性。完整性是一个承诺：reader 找到索引就会停止搜索，所以部分索引不仅表现不佳，还会让 reader 自信地数错。

最后，解析简约性：重复的文档会在搜索中互相竞争，把彼此埋没。论文提到早期版本中，没有这个约束的训练让本来已经组织好的文档库膨胀了五倍，reader 性能反而下降了 17 个 F1 点。

实验设计：三个基线，两个基准

论文对比了三个无监督基线。B1 是平铺文档库，完全没有结构；B2 是 GraphRAG 风格的社区摘要；B3 是 HippoRAG-2 风格的实体枢纽文档。三个基线都使用相同的 reader、测试集和预算，区别只在文档库是如何准备的。

两个基准臂共享同一个协议：KBGym 和 PhantomWiki。PhantomWiki 来自外部生成器，不归作者控制，提供了外部效度证据。

结果：覆盖度是关键梯度

最核心的实验是 E2，关键覆盖梯度。他们构造了四个问题组，按照训练集触碰问题 key 的程度分层：

• • 训练过的问题：完全重叠；
• • 双 key 覆盖：每个问题有两个 key，训练见过其中两个；
• • 单 key 覆盖：只见过一个；
• • 无 key 覆盖：一个都没见过。

这些组从相同的模板组合中抽取，样本量相同，已经排除了组成差异。结果非常清晰：

衰减是单调的，说明结构转移的半径取决于训练集覆盖了多少 key，而不是问题本身的新颖性。在 PhantomWiki 上，训练过的问题组是唯一在两个基准上都显著的单元格，准确率提升方向一致。

更有趣的是覆盖度当作货币的计算。HippoRAG-2 索引了整个语料库（100% 覆盖），用了 196,112 个链接，达到动作节省 ρ=0.75 和 F1 0.919。本文的监督方法只覆盖了 27.6% 语料库，用了 1,913 个链接，达到 ρ=0.9 和 F1 0.831。按每一点语料覆盖算，监督方法的动作节省是 HippoRAG 的 1.5 倍，准确率增益是 2.1 倍。

图片说明了 agent 构建的文档网络。结构从零开始，长成一个导航层：枢纽索引文档扇形展开到主题集群，所有链接都由索引介导，agent 从不直接把两个来源文档连接起来。

智能体到底构建了什么

追踪重放显示，训练期间增加了 287 个文档和 1,913 个链接，几乎全部集中在 epoch 1。分类检查发现 84.3% 是真正的索引文档，15% 是空壳（如一个名字索引但没有任何链接），2 个是物化的答案。索引精度达到 94%，成员召回 91%。属性索引（城市、爱好）几乎是完美的，关系索引更小但更嘈杂。两层关系的索引并不比一层关系更差——深度不是问题，广度才是。

但覆盖度只有 27.6%，这是所有结果的约束。训练只碰到了一百个问题，它们命名了语料库中大约四分之一的 key。覆盖度随问题数量线性增长，每问一个问题增加约 0.25 个百分点。按这个斜率外推，需要约 400 个不同问题才能达到全覆盖，约 4800 万 tokens。方法尚未饱和，限制因素是训练量。

两个 epoch 揭示的不同收益

训练分两个 epoch，每个 epoch 100 个问题。第一遍建立导航，让答案变得便宜：动作数从 10.35 降到 8.59，但准确率几乎没动。第二遍让答案变对：准确率从 0.765 跳到 0.912，但动作数只小幅下降到 8.00。第二遍并不是通过补全半成品的索引，而是增加了 45 个针对相同问题的新索引。这意味着在线场景下，一个服务重复流量的文档库可以免费获得更多遍历关键 key 的机会。

训练的意义与局限

这项工作的真正贡献是提供了一个测量协议和效率基准。它把知识库构建从一种工程习惯变成了一个可以严格训练和评估的非参数模型。它揭示了覆盖度是当前瓶颈，而不是结构质量。它也指出了在线变体的自然路径：一个从真实流量中消费问题并原地编辑的文档库，会自动将结构集中在它实际服务的查询分布上，这是离线构建无法做到的。

局限也很明确。模板生成的语言比自然文本简单，可能有利于词法匹配；reader 和 curator 共享同一个模型家族，结构可能过度适应这个模型的习惯；单种子运行；PhantomWiki 上没有支持集诊断。更重要的是，覆盖度不足是一个真正的限制——论文报告的所有绝对数字都低于全量索引的 HippoRAG，只是因为训练量不足。

总结

这篇论文把一个被忽视的问题——文档库的结构构建——拉到了监督学习的框架下。它证明了知识库可以像模型一样训练，而且监督信号能极大地提高结构预算的使用效率。对于任何需要在复杂查询负载下服务 RAG 的团队来说，这个方向提供了一个可操作的原语：让一个 curator agent 消费 (question, answer) 对，将验证过的推理路径物化为可遍历的链接。它把非参数的那部分变成了一个真正可学习的对象。这是 RAG 从静态索引走向上下文工程的一个小而坚实的步骤。