CorpusMap：让 Agent 用"实体导航"代替"裸语料检索"

关联论文：2609.37226
作者：flyP
更新：2026-09-30

一句话结论

当 LLM Agent 在大型文档集合上完成检索任务时，传统做法是把语料暴露为扁平的"文件列表"——相关文档之间没有相互引用的指示，导致 Agent 必须对每个 query 都重新发现这些关系，并常常在漏掉互补证据的同时消耗大量 token。CorpusMap 提出一个离线预构建的导航层：把语料围绕"反复出现的实体（recurring entities）"组织，每实体对应一个聚合所有提及该实体的文档链接的 Entity Page，在 7 个模型 × 3 个基准的实验中既提升证据发现与最终答案质量，又平均消耗更少 token，并优于 4 个替代导航层方案。

解决的真问题

Agentic Search（让 LLM Agent 在大型文档集上多轮检索 → 推理 → 回答）是新一代 IR 的重要形态：

真实任务里，答案往往横跨多份文档——某项目的审批在一份文件里，需求在另一份，最新状态又在第三份。
现有做法（OpenAI Deep Research、Search-o1、Gemini Deep Research 等）让 Agent 对原始语料做反复检索，但：
相关文档不暴露它与其他文档的关系，Agent 必须对每个 query 都重新探索这些关联。
多个相关文档被分别发现，互补证据容易被遗漏。
反复探索消耗大量 token，时延与成本同步上升。
根本问题：缺少一个离线、共享、可复用的"语料地图"。

CorpusMap 把这张地图做成以实体为锚点的导航层，让 Agent 通过"先在实体上提问，再跳到相关文档"的多跳方式连接证据。

核心方法

1. 实体（Entity）作为锚点

实体可识别：从文档自身可识别（人名、组织、项目、术语、产品代号等）。
实体跨文档：同一实体可能出现在多份文档中，自动把多份文档"通过这个实体"串联起来。
离线解析：通过对文档做 mention resolution（同一实体的不同提及 → 同一规范形式）得到实体集合与文档-实体关系图。

2. Entity Page

每个反复出现的实体对应一个 Entity Page，结构上类似维基百科条目：

Entity Page(e):
  - canonical_name: 规范实体名
  - description(e):  从所有提到 e 的文档聚合出的简短描述
  - mentions(e):     提到 e 的文档列表 + 文档中相关段落链接
  - related_entities: 与 e 共同出现频率较高的实体

Agent 在检索时先访问一个或多个 Entity Page，再由 Entity Page 跳转到所有相关文档，避免了"全语料重搜"。

3. 离线构建，跨 query 共享

CorpusMap 完全离线构建：对文档做一次 mention resolution + 聚合，输出实体-文档图与 Entity Page。
一份 CorpusMap 服务于所有 query：每个 query 都直接复用同一张图，不再为每个 query 重新发现实体关系。
工程意义：构建一次性成本，换取每次 query 的边际 token 成本下降。

4. Agent 工作流（伪代码）

# 传统 agentic search（baseline）
docs = agent.search(corpus, query)        # 全语料搜索
answers = agent.read(docs, query)         # 反复读

# CorpusMap 增强的 agentic search
related_entities = corpus_map.lookup_entities(query)   # 从 query 找相关实体
docs = set()
for e in related_entities:
    docs |= corpus_map.entity_pages[e].mentions        # 跨文档聚合
answers = agent.read(docs, query)

关键实验与数据

模型：7 个不同模型（含闭源 SOTA 与开源 LLM）。
基准：3 个 benchmark 数据集。
对比：4 个替代导航层（baseline 是"无导航层"的原始语料检索，其余 3 个是其他候选导航结构）。
核心结论（abstract 一手陈述）：
在证据发现（evidence discovery）与答案质量（answer quality）上均优于 raw-corpus agentic search。
平均消耗更少 token——离线导航层摊薄了逐 query 探索成本。
优于 4 个替代导航层——表明"以实体为锚点"是一种有效导航结构。
⚠️ abstract 未给出具体 nDCG / F1 / token 节省率的数字，原文未明确列量化指标，必须读正文 Section 4/5 实验段才能完成硬核对比。
作者 Soyeong Jeong（首作）2026-09-29 提交至 arXiv cs.CL/cs.AI/cs.IR/cs.LG。

亮点

结构简单、可解释：把"实体"作为导航锚点是检索/百科领域的经典做法，CorpusMap 把这一思路迁移到 Agentic IR，让人容易理解和复用。
离线一次性构建 + 跨 query 复用：工程友好——生产环境对"一次性批处理"的容忍度远高于"逐 query 实时重算"。
通用性强：不绑定特定检索模型或 LLM，可在任意 agentic search 框架上做插件式升级。
可扩展到多模态：实体概念可以扩展到图像、表格、代码符号（symbol、function name），未来空间大。
多基线对比充分：7 模型 × 3 基准 × 4 替代导航层，结论可信度高。

局限与诚实标注

量化数字缺位：abstract 没给出 nDCG / Recall@k / token 节省率 / 端到端时延等具体数字，原文未明确，需查 Section 5 表格。
实体识别错误的级联影响：CorpusMap 严重依赖 mention resolution 质量——若同一实体的不同提及被错分成不同实体、或不同实体被合并到一起，导航层立刻失效。原文未明确 mention resolution 的 F1。
冷启动成本：第一次为新语料构建 CorpusMap 的开销（含 mention resolution、Entity Page 聚合、相关度排序）在 abstract 中未量化，对小型语料可能反而不划算。
领域依赖：实体密度高的领域（法律、医学、企业知识库）收益大；实体稀少的领域（短新闻、聊天记录）可能与原始语料检索打平，原文未明确给出按领域拆分。
Graph 大小与查询延迟：Entity Page 之间可能形成超大图，Agent 多跳遍历时是否会再次陷入"遍历代价大于搜索代价"的问题，原文未明确。

对工程落地的启发（按坑点分项）

坑：mention resolution 错配会让导航层变成噪音源。 现象：把同名不同人合并、或把同一实体拆成多个；影响：Agent 跳错分支，证据质量骤降；修复：在 CorpusMap 上线前用 200 条人工样本做 mention resolution 质量抽检，F1 < 0.85 不上生产。
坑：Entity Page 描述生成使用了 LLM，描述可能"幻觉"。 现象：description(e) 由 LLM 聚合而来，可能凭空捏造不存在的关联；影响：Agent 基于幻觉描述跳转；修复：把描述生成限定为"只引用 mention(e) 中真实存在的句子"，并对每条描述附 source-span。
坑：离线构建成本被低估。 现象：mention resolution + 实体聚合 + 相关度排序在小语料上几分钟搞定，但万级文档的语料上可能数小时；影响：CI/CD 流水线阻塞；修复：把 CorpusMap 构建拆成增量任务（按文档桶异步跑），并维护构建产物的 hash。
坑：导航层与原检索的优先级混乱。 现象：Agent 同时支持"按 Entity 跳"和"按关键词搜"，Agent 不知道何时用哪个；影响：要么过度依赖导航、要么完全不用；修复：在 system prompt 里明确触发条件（如"若 query 含已知实体名则先查 Entity Page"）。
坑：长尾 query 在导航层误导下 token 反而更多。 ⚠️ 原文修正：abstract 未给出"平均节省 30% / 2 倍"等具体数字；此坑是合理推断但未经原文量化。现象：某些复杂 query（如跨领域多实体、长尾专业术语）导航层可能给出错误引导，导致 Agent 先走错分支再回退；影响：少数 query token 用量反超裸语料 baseline；修复：监控 P50/P95/P99 token 用量并按 query 类型分桶，若 P95 > baseline P95 则触发告警。
坑：Graph 漂移问题。 现象：语料每日更新，但 CorpusMap 是离线构建；影响：新增文档不进图、消失实体仍被引用；修复：把 CorpusMap 构建纳入每日 ETL，并把"未覆盖文档比例"作为上线告警指标。

与同方向工作的关系

相比 BM25 / dense retrieval / ColBERT（单跳检索）：CorpusMap 不替换检索，而是提供一个"先看哪"的导航层，检索仍由 BM25 / dense 模型完成；二者是叠加关系。
相比 GraphRAG / RAG over Knowledge Graph / HippoRAG：GraphRAG 等用 LLM 抽取的 KG 节点-关系-实体三元组作为索引，CorpusMap 更轻——只用 mention resolution + 实体聚合，不抽关系。工程实现门槛更低。
相比 OpenAI Deep Research / Search-o1 / Gemini Deep Research：这些是端到端 agentic search 系统，CorpusMap 是可嵌入的导航层；理论上可作为这些系统的"前置索引"加速收敛。
相比 WikiLink / DBpedia / Wikipedia hyperlinks：CorpusMap 的 Entity Page 类似维基百科的实体页，但针对当前语料自动构建，无需依赖外部知识库；这对企业内网等无维基百科的场景特别有价值。
相比 Entity Linking（命名实体链接）研究：CorpusMap 把 EL 的输出（mentions → entities）作为导航输入，复用而不是重做了 EL 研究的成果。
相比 Hyperlink-based Retrieval / Web IR 的链接图：CorpusMap 不依赖人工超链接，而是从文档自身抽取实体并自动构建跨文档导航；二者核心思想同源（链接图导航），CorpusMap 在没有 wiki/链接的语料上同样可用。
相比 Hierarchical Index / Document Summarization Tree：这些是把语料按章节 / 摘要建树，CorpusMap 是按实体建图——前者偏结构化文档（论文、报告），后者偏任意集合（合同、邮件、工单）。

场景适配速查表

场景	CorpusMap 适配度	主要原因
企业内部合同库	高	实体密集、跨文档引用频繁
法律判例库	高	法官、律所、案号、条款均为高复用实体
医学文献库	高	病症、药物、基因、试验均为跨文档实体
短新闻聚合	低	实体稀疏、时效性强，建图成本不划算
社交媒体 / 聊天记录	低	实体识别质量差，导航误导风险高
多模态语料（图文混排）	中	实体概念可扩展到图像对象，abstract 未明确
实时流式语料（>1k doc/h）	低	离线构建链路长，需引入增量图更新机制

实验细节补充

7 个模型：abstract 明说"7 个不同模型"，但未列出具体模型名称，原文未明确；从跨厂商对比的角度推测应包含闭源 SOTA（如 GPT-4 系、Claude 系）与开源 LLM（Llama 系、Qwen 系、Mixtral 系）的代表，但具体名单需查正文 Section 5.1。
3 个 benchmark 数据集：abstract 明说"3 个 benchmark 数据集"，未明确具体名字；从 agentic search 领域的常用基准看，可能包含 HotpotQA、FEVER、MuSiQue、QASper、QuALITY 等候选，但需查正文确认。
4 个替代导航层：abstract 明说"4 个替代导航层"，未明确具体结构；候选可能包括"按文档标题检索""按文档向量相似度聚簇""按章节/段落树状导航""无导航层 baseline 之一"，需查正文 Section 5.3。
评价维度：abstract 明说"证据发现 + 答案质量 + token 用量"三轴评价，未给出每个轴的具体数字，原文未明确；典型的"证据发现"指标包括 Recall@k、supporting-fact F1；"答案质量"包括 EM、F1、LLM-judge；"token 用量"是绝对值或相对 baseline 的百分比。

这部分细节属于只能等论文正文 / 附录才能核实的范畴，写作时已标注"原文未明确"，不臆造。

与传统 agentic search 的对比直觉

让不熟悉本领域的读者快速建立"为什么这是突破"的直觉：

传统 agentic search（裸语料）：Agent 拿到 query 后反复 full-corpus 搜索，每次都从零开始发现文档关系。优点是不需要任何预处理，缺点是每个 query 都要重新探索关联——同样的"项目 A 涉及文档 B/C/D"要被发现 N 次。
CorpusMap 增强：Agent 先查 Entity Page（一次性的离线索引），Entity Page 直接告诉 Agent 相关文档清单，跳过"反复探索"环节。优点是单 query 边际成本骤降，缺点是冷启动构建成本。
关键判断：若 query 量 << 文档量，CorpusMap 摊薄明显；若 query 量 ≈ 文档量，可能与裸语料检索打平；若 query 量极少（一次性分析任务），离线构建成本可能不值。

工程上判断 ROI 的硬指标：平均每个 query 的"实体-文档关系发现次数"。如果一个 query 在裸语料下要 Agent 探索 10+ 次才能拼齐证据，CorpusMap 通常值得；如果 1-2 次就够，引入 CorpusMap 反而是负优化。

适合谁读

企业搜索 / 知识库工程师：内网文档量大、跨文档证据关联需求强的场景（如法律合同库、医疗病例库、研发文档库）。
Agentic Search 系统架构师：评估是否引入"导航层"作为加速层，把昂贵的多轮检索降到 1-2 轮。
RAG 平台工程师：现有 RAG 召回受限于 query-doc 相似度，CorpusMap 提供了一条绕过单跳相似度的路径。
KG / Entity Linking 研究者：mention resolution 误差如何影响下游任务的端到端鲁棒性，是一个值得量化的问题。
AI 工具产品 PM：把"实体"作为高级检索功能暴露给用户（如"按人物/项目检索"），是值得尝试的产品形态。

来源：paper_cards/1581-2609-37226.md + arXiv abstract https://arxiv.org/abs/2609.37226（v1 提交于 2026-09-29 10:39 UTC，由 Soyeong Jeong 等作者）

工程落地与核查（Jay）

双轨核查：构建侧 vs 查询侧

维度	构建侧（Offline Build）	查询侧（Online Query）
核心操作	mention resolution + Entity Page 聚合	Agent 查询 Entity Page → 跳转文档列表
成本特征	一次性大批量，语料规模越大越合算	单次 query 边际成本低，跨 query 摊薄
风险	mention resolution F1 低 → 整个导航层失效；冷启动成本被低估导致 CI 超时	导航层给出错误引导时 Agent 产生回退，token 浪费比裸语料更多
可验证性	可用 200 条人工样本抽检；构建产物 hash 可复现	在自家 trace 上测 P50/P95 token 用量 vs baseline
与现有 infra 的关系	作为 ETL pipeline 的一部分，可集成到文档入库流程	作为 Agent harness 的"导航插件"，不改动检索模型本身

工程可操作性评估

适合上生产的场景： - 文档集较大（>1k doc）且更新频率低（daily/weekly 而非 hourly） - 实体密度高的垂直领域（法律、医疗、企业知识库） - 多 Agent 协同场景，各 Agent 需要共享文档关系图

不适合直接上生产的场景： - 实时流式文档（每小时 >1k 新增 doc），离线构建链路跟不上 - 实体稀薄的短文本场景（新闻聚合、社交媒体） - 对 mention resolution F1 没有人工抽检能力的环境

落地核查清单

✅ mention resolution F1 抽检：上线前用 200 条人工样本评估，F1 < 0.85 则优化 mention resolution 后再上生产。
✅ CorpusMap 构建产物版本化：每次构建输出 hash，query 时校验 hash 与当前 CorpusMap 版本匹配，防止"新 query 用旧图"。
✅ P50/P95 token 用量监控：上线后按 query 类型分桶统计 token 用量，若 P95 > baseline P95 × 1.2 则触发告警并排查原因。
✅ 每日增量构建 ETL：把 CorpusMap 构建纳入每日 ETL，新增文档当天进图，消失实体比例 > 5% 时告警。
✅ Entity Page description 可溯源：description(e) 每条句子必须附 source-span，杜绝 LLM 幻觉描述进入生产。
⚠️ 多模态扩展：图像/表格实体的 mention resolution 质量未在 abstract 中验证，多模态语料上线前需专项评估。

存疑项（原文未明确，需查 PDF）

⚠️ 具体量化指标：abstract 未给出 nDCG / Recall@k / token 节省率；正文 Section 5 实验表是唯一可信来源。
⚠️ 7 个模型具体名单：闭源 SOTA（GPT-4/Claude）与开源 LLM 的具体型号需查 Section 5.1。
⚠️ 4 个替代导航层的具体结构：需查 Section 5.3 实验设计。
⚠️ mention resolution F1：原文未披露该指标，无法判断工程团队拿到手质量够不够用。
⚠️ GitHub 仓库是否公开：abstract 无链接；mention resolution 代码、Entity Page 生成代码是否开源未知。