Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki 深度解读
1. 问题与动机
这篇论文的核心判断是：面向 LLM Agent 的检索不应该继续被建模成一次性 top-k 上下文查找，而应该成为 Agent 推理过程的一部分。作者用 2WikiMultiHopQA 的四跳问题说明传统 dense retriever 的典型失败模式：问题只显式提到两个电影名，向量检索能召回电影页面，却容易漏掉导演人物页，因为导演生日这一关键证据与原始 query 语义距离较远。对多跳问答、事实核验、深度研究报告这类任务，Agent 真正需要的是先读一个实体，再沿关系找到中间实体，然后继续读取和判断证据是否充分。
作者把现有 RAG 的问题概括成三类。第一，扁平 chunk 把检索降格为匹配，适合局部事实查找，但不适合关系跟随、属性比较和跨文档聚合。第二，固定检索结果在推理前一次性给出，Agent 无法根据中间观察决定下一步看哪个实体、是否改写搜索或是否停止。第三，LLM 生成的结构化知识库如果没有长期自修复机制，会积累悬空链接、引用格式错误、 unsupported facts 和跨页面矛盾。论文的动机不是简单替换 embedding 模型，而是改变知识库与 Agent 的接口契约：让知识以可搜索、可阅读、可遍历、可维护的形态暴露出来。
2. 方法详解
LLM-Wiki 的方法可以拆成三个层次：Wiki 结构化知识、组合式检索工具、Error Book 自演化修复。索引阶段，系统不把文档直接切成 chunk 存向量库，而是把原始文档编译成持久化的 Wiki。每个页面包含 metadata、aliases、tags、facts、source references 和双向 wikilinks；目录页提供局部导航，source archives 保留原始来源。每个新 source batch 会先选择相关既有页面，再生成结构化页面更新，随后执行结构与内容校验，把错误写入 Error Book。这个增量过程使页面、链接和目录随语料演化，而不是每次全量重建。
查询阶段，Agent 拿到的不是固定 top-k passage，而是两个标准工具。wiki_search(query) 优先搜索页面名、别名、标签和描述，再回退到页面内容，返回候选页面和元数据。wiki_read(paths) 可以批量读取目录页或知识页；知识页中的链接会成为下一步遍历入口。Agent 的策略按查询类型变化：已知实体可以直接读页或先搜后读；bridge query 会先读 A 页，从结构化字段发现 B，再沿链接读 B；开放式枚举问题会先读目录索引形成空间概览，再选择页面深入。每次 read 后，Agent 都要判断证据是否足够，直到推理链闭合、工具预算耗尽或连续空搜索超过 patience threshold；论文还要求至少一次 wiki_read 后才能回答。
Error Book 是这篇论文最工程化的部分。作者把编译错误分成结构有效性和内容一致性两层：结构类包括 dangling links、incomplete pages、malformed refs、unseen overwrite、index inconsistency；内容类包括 unsupported facts 和 cross-page contradictions。处理流程是 Discover、Attribute、Constrain、Inject、Verify & Close 五步：先由确定性校验器和 LLM 验证器发现错误，再归因成“发明不存在页面链接”“实体属性没有来源支撑”等根因，转成自然语言约束注入后续编译 prompt，之后周期性复验并关闭已解决错误。修复也分两层：每批次后的 code auto-fix 处理悬空链接、格式和索引问题；周期性 LLM fix 处理缺页、事实不支撑、跨页矛盾等语义问题。论文没有依赖新模型结构，而是用可维护的知识组织和工具协议改变 Agent 检索行为。
3. 核心技术贡献
第一，论文明确提出 Retrieval-as-Reasoning 范式，并用 Wiki compilation 把检索从“隐藏排序器”改造成 Agent 可规划的显式动作空间。相较 Vanilla RAG、RAPTOR、GraphRAG、LightRAG、HippoRAG 2，它强调的不是更强索引，而是人类可审计、机器可遍历的页面与链接。
第二，组合式 traversal 是性能提升的关键。Agent 可以在 search、read、follow links、sufficiency check 之间循环，把中间观察转化成后续检索动作。消融显示去掉 progressive traversal 会带来 11.7 到 13.8 个 F1 点的下降，说明仅有多轮工具调用不够，必须让结构化链接被主动利用。
第三，Error Book 把知识库质量维护做成长期闭环。作者统计发现 dangling links 在四个语料中占检测错误的 29.1% 到 63.8%，malformed refs 占 18.9% 到 28.5%，说明结构和引用问题会直接破坏可遍历性。去掉 Error Book 后 F1 下降 3.4 到 4.0 点，证明自修复不仅是离线清洁工具，也会影响下游检索效果。
第四，论文把适用边界讲得比较清楚：LLM-Wiki 对关系跟随、证据枚举、跨文档聚合和动态探索更有价值；对单文档局部细节问题，直接召回原文的 HippoRAG 2 在 AuthTrace Single-doc 上反而高 2.3 个 AC 点。
4. 实验结果分析
作者在 HotpotQA、MuSiQue、2WikiMultiHopQA 各取前 500 个样例，并在 AuthTrace 上评估结构化多文档证据构造。所有方法使用 GLM-5.1 作为回答模型；涉及 embedding 的方法使用 Qwen3-Embedding-8B；基线包括闭卷、BM25 RAG、Dense RAG、RAPTOR、GraphRAG、LightRAG 和 HippoRAG 2。
| 方法 | HotpotQA F1/EM | MuSiQue F1/EM | 2WikiMHQA F1/EM |
|---|
| Dense RAG | 0.764 / 0.642 | 0.611 / 0.500 | 0.815 / 0.724 |
| LightRAG | 0.819 / 0.682 | 0.659 / 0.550 | 0.847 / 0.764 |
| HippoRAG 2 | 0.805 / 0.668 | 0.624 / 0.514 | 0.831 / 0.706 |
| LLM-Wiki | 0.839 / 0.710 | 0.739 / 0.634 | 0.911 / 0.854 |
主结果显示，LLM-Wiki 在三个数据集上都是最高。相对最强基线 LightRAG，HotpotQA 提升 2.0 F1，MuSiQue 提升 8.1 F1，2WikiMHQA 提升 6.4 F1；相对 Dense RAG，MuSiQue 提升 12.9 F1。作者认为差距在更强组合推理数据集上扩大，是因为预编译链接让中间实体显式可发现，而不是靠单次相似度查询碰运气。
AuthTrace 进一步验证多文档证据聚合。LLM-Wiki 总体 AC 为 70.4，高于 HippoRAG 2 的 68.3；在 Low multi-doc 上是 64.6 对 59.6，在 High multi-doc 上是 55.4 对 46.5，分别高 5.0 和 8.9 个 AC 点。但 Single-doc 上 LLM-Wiki 为 76.0，低于 HippoRAG 2 的 78.3，说明编译后的 concise facts 可能丢失局部细节，适用场景不是所有查询。
消融更能解释机制贡献：完整 LLM-Wiki 在 HotpotQA/MuSiQue/2Wiki 上是 0.839/0.739/0.911；去掉 Wiki Structure 降到 0.778/0.669/0.844；去掉 Progressive Traversal 降到 0.722/0.601/0.789；去掉 Error Book 降到 0.801/0.699/0.877。最大降幅来自 traversal，说明索引结构只有被 Agent 迭代读取和沿链接扩展时才发挥价值。
细粒度分析也支持这一点。在 2WikiMHQA 上，LLM-Wiki 相对 LightRAG 的 F1 差距从 2-hop 的 5.7 点扩大到 4-hop 的 8.3 点，4-hop F1 达到 0.983。按问题类型看，compositional questions 上 LLM-Wiki 得到 0.833，Dense RAG 为 0.677，LightRAG 为 0.760。换成 GPT-4o 做回答模型后，LLM-Wiki 仍比 Dense RAG 高 5.1、10.5、16.9 个 F1 点，说明收益主要来自知识组织和检索接口，而不是某个回答模型。
效率结果也值得注意。LLM-Wiki 查询延迟在 HotpotQA/MuSiQue/2Wiki 上分别为 14.9s、27.1s、15.9s，接近或快于 BM25/Dense RAG，并明显快于 LightRAG 的 41.4s/51.3s/39.7s、HippoRAG 2 的 33.5s/38.2s/32.4s、RAPTOR 的 19.9s/40.2s/28.0s。作者解释是预编译链接减少了运行时 LLM 调用，Agent 平均只需读取 2.5 到 3.9 个页面，而不是固定读 5 段 passage。
5. 局限与未来方向
作者明确提出两个主要局限。第一是编译成本：每个 source passage 都要经历 SelectPages 和 CompileWikiPages，初始构建比 chunk-and-embed 昂贵，虽然可以在后续查询中摊销。第二是规模化：当 Wiki 增长到数万页面时，目录索引可能变得笨重，页面选择质量也可能下降。
论文给出的未来方向包括层级索引、sharding、过期事实处理和全局目录维护，以支持 web-scale 或频繁变化的语料；还提到多模态 Wiki 和跨语料迁移。作者没有充分展开线上动态更新中的一致性成本，例如多用户并发写入、权限隔离、内容删除后链接清理、UGC 垃圾内容污染 Error Book 等问题。对工业系统来说，Error Book 的 LLM 修复还需要审计和回滚机制，否则自动修复可能把局部错误传播为全局约束。
6. 工业实践意义
对搜索/推荐从业者，这篇论文最直接的启发是：不要把 Agentic RAG 简化成“多轮调用向量检索”。如果业务查询需要多跳关系、证据对比、观点汇总或可解释回答，真正的瓶颈可能是知识组织方式。社区 UGC 搜索中，帖子、评论、作者、话题、地点、商品、问题和回答之间天然存在关系；把这些对象编译成可遍历页面或轻量知识卡片，会比单纯扩大 top-k 更有利于复杂查询。
可落地的试点路径是先选一个高价值垂直域，例如旅游攻略、装修问答、数码评测或本地生活经验，把优质内容编译成 Wiki-like 结构：页面保留来源引用、别名、标签、事实、关联实体和更新时间；查询时让 Agent 先搜索入口页，再读取相关页并沿链接扩展，最后要求证据充分性检查。Error Book 可以映射到工程质量体系：悬空链接对应失效实体，malformed refs 对应引用格式错误，unsupported facts 对应无来源结论，cross-page contradictions 对应不同帖子或知识卡之间的事实冲突。
部署时要注意两类预算。离线侧，编译和修复成本会高于普通索引，适合先覆盖高频、高商业价值、高问答复杂度的内容，而不是全站 UGC。在线侧，论文显示查询延迟可以接近 Dense RAG，但这是在预编译结构有效、平均只读少量页面的前提下；真实业务要设置工具调用上限、空搜索 patience、引用强制返回和降级策略。对 CTR/nDCG 指标，可以先把 LLM-Wiki 用在少量“复杂意图识别后触发”的答案增强模块，而不是替代主排序链路。
Google
Alibaba