CorpusMap · 跨文档实体解析：Agent 搜索的离线导航层 · 干货攻略

链接: https://arxiv.org/html/2609.37226v1
分类: x-tips
来源: X @omarsar0
作者: Jay
更新: 2026-10-07
论文: arXiv:2609.37226 (cs.CL)

这是什么

CorpusMap 是微软 + KAIST 联合论文 Follow the Entities: A Corpus Map for Agentic Search（arXiv:2609.37226，2026 年 9 月 29 日提交）提出的离线实体导航层。

核心问题：企业文档集合里，答案所需的证据散落在多份文档中（一份记录审批、一份记录需求、一份记录最新状态），但 Agent 面对的只是"扁平文件列表"——每份文档不告诉 Agent 它和谁相关。于是 Agent 每次回答新问题，都要重新搜索、重新发现文档之间的关系，既漏证据，又烧 token。

CorpusMap 的解法：在离线阶段就把跨文档的实体关系解析好，构建成 Entity Page 图；推理时 Agent 沿着实体节点导航，无需重复发现关系。

为什么值得关注

谁分享的、解决什么问题

@omarsar0 在 X 上推荐了这篇论文，定位是"RAG 踩坑复盘类攻略的新范式"。

根本矛盾：Agentic search（Agent 迭代搜索全量语料库）解决了"固定 top-k 文档不够用"的问题，但语料库本身仍是扁平文件集合。Agent 每处理一个问题，都要重新推断"这份文档和那份文档有什么关系"，同一个项目的多份文档之间每次都要重新建立连接。

三条已知替代方案的缺陷（来自论文 Section 2）： - GraphRAG / HippoRAG：实体图用于检索器内部，但不暴露给 LLM；LLM 拿到的是单步检索结果，无法主动探索 - LLM Wiki（Karpathy 2026）：Agent 自己决定哪些内容变成 Wiki 页面、怎么合并；语料库变大时质量退化 - Corpus2Skill（Sun et al. 2026a）：每个文档只能归入少数几个分支；同一主题的证据容易被分到不同分支

CorpusMap 的核心洞察：文档天生围绕实体（人、项目、事件）生成；这些实体可以在离线阶段直接从语料库本身识别，无需任何查询参与。

核验过程

官方来源

来源	读取内容	关键结论
arXiv 摘要页 (2609.37226)	完整摘要	确认 7 模型 × 3 数据集；质量提升 6.4–11.7 分；token 减少 34%–57%；超越 4 种替代导航层
arXiv HTML 全文页 (v1)	Introduction、Method Section 3、Experiment Setup	确认 4 阶段构建算法（Type Catalog → Extract → Resolve → Render）；3 个 benchmark 名称（EnterpriseRAG-Bench、WixQA、HERB）；7 个模型名称（见下）；Entity Page 格式；可无需 LLM 构建
alphaXiv 镜像页	方法概述、Query-time 流程	确认 Entity Page 在查询时可被搜索，Agent 跟随链接；原始文档仍可通过原始搜索访问；many-to-many overlay 而非替代语料库

交叉验证

原帖主张	官方数据	结论
"7 模型 × 3 数据集"	论文明确列出：GPT-5o、GPT-5 Mini、Claude 4 Sonnet、Claude 3.7 Sonnet、Gemini 2.5 Pro、Gemini 2.0 Flash、Qwen-3 32B；数据集：EnterpriseRAG-Bench、WixQA、HERB	✅ 官方确认
"token 消耗降低 34%–57%"	论文原文（Section 1）："34% to 57% fewer input tokens on average"	✅ 官方原文
"质量提升 6.4–11.7 分"	论文原文（Section 1）："improves overall quality by 6.4 to 11.7 points"（对比 raw-corpus agentic search）	✅ 官方原文
"超越 LLM Wiki 和 Corpus2Skill"	论文 Table 1：CorpusMap 在所有 3 个 benchmark 上均超过 LLM Wiki 和 Corpus2Skill	✅ 官方确认
"可无需 LLM 构建"	论文原文（Section 1）："can be constructed even without the use of LLMs"	✅ 官方原文
"增量更新"	论文原文（Section 1）："updated incrementally as the corpus grows and evolves"	✅ 官方原文

未核验声明

以下内容未在官方论文中找到独立确认，标注为原帖主张： - omarsar0 原帖中"token 平均消耗降低"的具体数字范围；官方数据仅有 34%–57% 一说，与原帖描述一致但无更多细节 - 原帖提到的"7 模型平均"的具体 per-model 性能数据；官方论文在 Table 1 中有具体分数，但需读 PDF 才能逐一核验

上手步骤

CorpusMap 构建流程（离线阶段）

论文描述的 4 阶段构建算法：

Algorithm 1 CorpusMap Construction

Input:  Document corpus D, entity-processing backend, page renderer
Output: Entity-centric map G with Entity Pages

1. C ← InduceTypeCatalog(D)
   # 从采样的文档中自动归纳实体类型目录
   # 可用 LLM 也可用轻量 zero-shot linker（如 Stepanov et al. 2026）

2. {E_local}^d_d∈D ← ExtractLocalEntities(D, C)
   # 对每份文档识别实体mention，标注类型

3. R ← ∅, L ← ∅
   # R：全局实体注册表；L：link集合
   for each document d ∈ D:
     for each local entity z ∈ E_local:
       δ ← Resolve(z, R)   # 查询注册表，判断是LINK/ADD/UNRESOLVED
       if δ = LINK(e):
         UpdateEntity(R, e, z)
         L ← L ∪ {(e, d)}
       elif δ = ADD:
         e ← AddEntity(R, z)
         L ← L ∪ {(e, d)}
       else:
         RecordUnresolved(z, d)

4. E ← CrossDocumentEntities(R, L)  # 只保留被 ≥2 个文档引用的实体
   L ← {(e,d) ∈ L | e ∈ E}
   for each entity e ∈ E:
     N(e) ← {d ∈ D | (e,d) ∈ L}   # e的文档邻域
     p_e ← RenderEntityPage(e, N(e))  # 生成Entity Page（fact + source attribution + 文档链接）

Output: G = (E ∪ D, L)

Entity Page 结构（Agent 看到的内容）

每个 Entity Page 包含： - Overview：实体的简要描述 - Key Facts：每条事实标注来源文档 - Mention Names：实体在语料库中的所有提及名称（解决别名问题） - Document Links：引用该实体的所有文档路径列表

查询时 Agent 行为

Agent(q, D; G)

1. Agent 在 Entity Pages 中搜索 q 相关的实体
2. 打开相关 Entity Page，阅读 fact + source attribution
3. 跟随 Page 中的文档链接，查看原始文档
4. 对已读文档，可反向搜索"有哪些 Entity Page 引用了我"
5. 证据积累足够后，生成答案

关键设计原则：Entity Pages 是叠加层（overlay）而非替代——原始文档始终可通过原始搜索访问。没有被任何实体关联的文档以孤立节点形式保留在图中。

坑与适用边界

坑 1：实体解析质量是天花板

CorpusMap 的效果直接依赖实体识别和跨文档共指解析的准确率。论文使用的是微软/KAIST 团队自研的 pipeline，社区暂无开源复现版本（arXiv 页面和 GitHub 均未提供代码链接，截至 2026 年 10 月）。实体解析错误会直接传播到导航层，导致 Agent 跟随错误链接。

坑 2：GitHub 代码未发布

论文目前（2026-10-07）没有公开代码仓库。构建 CorpusMap 所需的具体实现（InduceTypeCatalog、ExtractLocalEntities、Resolve 等阶段的具体算法）需根据论文描述自行实现。对于想直接复现的团队，这是主要障碍。

坑 3：适用场景有限

CorpusMap 的设计针对实体驱动型语料库（企业文档、项目管理资料、研究论文集）。对于以下场景，实体导航收益较低： - 高度非结构化文本（纯叙事性文章，没有明确实体） - 实时更新的流式数据（每次更新都需重建 map） - 小型语料库（文档数量少，跨文档共指关系本来就少）

边界

适合：多文档企业知识库问答；需要跨文档溯源的 Agent 场景（RAG Agent、企业文档助手）
不适合：单文档问答；非实体依赖型语料库；已有成熟 GraphRAG 管线且效果满意的场景

一句话结论

CorpusMap 将跨文档实体关系从"推理时重复发现"变为"离线预建"，在 7 模型 × 3 benchmark 上验证质量提升 6.4–11.7 分、token 消耗降低 34%–57%，是 2026 年 Agentic RAG 架构从"扁平检索"走向"结构化导航"的重要范式突破；但目前代码未开源，实际落地需自行实现实体解析 pipeline。