跟随实体：面向智能体搜索的语料库地图 Follow the Entities: A Corpus Map for Agentic Search
离线构建实体-文档导航层，让智能体沿实体页面收集跨文档证据，质量与token效率双提升。
前置知识
Agentic Search（智能体搜索）
让 LLM 以智能体身份通过多步工具调用（本论文中是 find、grep、cat 等 shell 命令）在完整语料库上迭代“搜索→阅读→推理→再搜索”，直到收集足够证据才生成答案。区别于传统 RAG 的一次性 top-k 检索，它不受首轮检索结果限制，可按需追加搜索，每个问题有固定的执行步数预算。
本文的基线方法就是裸语料上的 agentic search，CORPUSMAP 是叠加在其上的导航层；理解 agent 如何用 shell 工具与语料交互，才能理解 Entity Page 为何被设计成“文件”。
跨文档实体解析（Cross-document Entity Resolution）
判断不同文档中不同写法的提及（如“Project Atlas”“Atlas migration”“the project”）是否指向同一现实主体，并将其聚类到统一标识的过程。通常包括提及抽取、类型归类、候选检索与逐个判定，判定结果可以是链接到已有实体、新建实体或放弃（unresolved）。
CORPUSMAP 的地图完全由跨文档实体解析产出，“哪些文档共享同一实体”正是论文要离线预计算并跨查询复用的关键关系。
二部图（Bipartite Graph）
节点分成两个互不相交的集合、边只允许跨集合连接的图结构。CORPUSMAP 的地图 $G = (E \cup D, L)$ 以实体集 $E$ 和文档集 $D$ 为两类节点，链接 $(e,d)$ 只出现在实体与其源文档之间；两份文档通过共享实体间接连通。
论文用消融实验证明二部图优于稠密的实体-实体知识图谱（后者只是缩短 agent 本可通过搜索跨越的路径），理解图结构才能领会这一关键设计权衡。
Entity Page（实体页面）
CORPUSMAP 为每个跨文档实体渲染出的文件，包含简短概述、逐条标注来源文档 ID 的关键事实、该实体的各种名称变体，以及指向所有源文档的路径链接，类似维基百科条目加引用列表的结合体。它与原始文档并存，agent 用普通工具即可搜索和读取。
它是方法的全部用户界面——导航层的价值都通过这种页面暴露给 agent，其内容设计（来源接地、禁止从提及推断关系）直接决定系统的可靠性。
GraphRAG 与 HippoRAG
两类把语料组织成实体关系图的检索增强方法。GraphRAG 从文档抽取实体与关系构建知识图谱并生成社区摘要；HippoRAG 借鉴海马体索引理论，在实体图上用个性化 PageRank 做多跳检索。两者的图都只在检索器内部使用，生成器拿到的仍是一次性检索出的固定上下文。
它们是本文最重要的“图结构”对照组（Table 3 中被大幅超越）；理解差异所在——图属于检索器还是直接暴露给智能体——是把握本文定位的关键。
研究动机
企业环境中回答一个问题往往需要拼接散布在多个应用里的证据：判断一个项目能否上线，可能要综合项目跟踪器里的最新状态、邮件里的批准记录、运维文档里的需求，以及会议纪要里的最终决定，而这些文档还淹没在数十万份无关文件中。为了找到证据，检索增强生成（RAG）通常在推理前一次性选出与查询最相似的 top-k 文档；agentic search 则让 LLM 用工具调用迭代搜索整个语料库，不再受首轮检索限制。但论文指出，即使能访问全量语料，它仍是一个“扁平的文件集合”：文档之间的关系（比如哪几份文件都在说同一个项目）没有任何显式表示，agent 只能靠反复 grep 和通读自行推断。这带来两个可量化的代价：其一，查询文本可能够不着关键文档——会议纪要可能用项目内部代号记录上线决定，按查询关键词搜索会漏掉它，实测 GPT-5.5 的裸语料搜索在 EnterpriseRAG-Bench 多文档问题上文档召回率仅 61.62%；其二，每个查询独立处理，重读文档、重新发现关系的 token 开销每个问题都要重复支付，GPT-5.5 平均单题消耗高达 20.65 万输入 token。
本文的目标是论文把上述挑战正式定义为“语料库导航问题”（corpus navigation problem）：需要一个持久的导航层（navigation layer），在不替代原始文档的前提下，把跨文档的可复用结构显式暴露给 agent。作者明确了该结构应满足的设计标准：它所链接的文档应当是查询文本本身不易触及的；它应当可以仅凭语料库本身（不依赖任何查询）预先识别，从而能离线构建、跨查询复用，使查询时推理保持高效。具体目标可拆成三条：一是提升证据发现——让 agent 从任一已读文档出发即可顺着结构化链接找到互补证据，提高文档召回与上下文召回；二是提升答案质量——证据发现的改善应转化为正确性、完整性、事实性等答案指标的提升；三是提升效率——利用结构减少需要检查的文档数量，使每题 token 消耗低于裸语料搜索。此外，作为面向真实部署的系统，地图还需支持增量更新（文档持续涌入时不必全量重建）、可用非 LLM 工具构建（降低成本）、并能被不同 LLM 复用（建一次图多方受益）。
与已有工作不同的是，已有工作各自处理了一部分问题，但都没把“把结构直接暴露给智能体”作为设计核心。GraphRAG、HippoRAG 等图结构 RAG 确实把语料组织成实体关系图，但图只在检索器内部使用，生成器拿到的仍是一次性检索出的固定上下文（top-k 段落或图摘要），检索漏掉的文档生成器永远无法触及；agentic search 虽解放了搜索策略，语料本身却仍是独立文档的集合，单次查询中推断出的关系下一个问题就要重新推断；LLM Wiki（Karpathy, 2026）让 LLM 自由编写交叉链接的 wiki 页面，但“给什么建页、如何合并内容”完全由模型即兴决定，随语料增长这些决定会退化（Zhou et al., 2026）；Corpus2Skill（Sun et al., 2026a）把文档组织成主题技能树，但每篇文档只归入一两个分支，同一主体散布在邮件、会议、文档中的证据被硬生生拆散。本文的独特切入是先回答“导航层应该暴露什么关系”这一设计问题，并把答案锁定在“实体”上：企业文档天然围绕人物、项目、产品等主体生成；实体仅凭语料即可识别、无需查询；一篇文档可同时属于多个实体的邻域（打破树结构的单分支限制）；实体-文档关系跨查询稳定，天然适合离线预计算与复用。
核心方法
直觉上，企业文档天然围绕反复出现的主体（人、项目、事故、产品）写成，只要把这些主体做成“卡片”，每张卡片列出“哪些文档提到它、各说了什么”，agent 就能像点超链接一样从一份文档跳到所有相关文档，而不必每次重新搜索。技术路线：CORPUSMAP 将语料表示为实体-文档二部图 $$G = (E \cup D, L), \quad L = \{(e,d) \mid e \in E,\ d \in N(e)\}$$ 其中 $E$ 是跨文档实体（被至少两个文档提及、能提供可复用导航路径的主体集合），$N(e) \subseteq D$ 是构建阶段确认提及实体 $e$ 的文档邻域。每个 $e$ 渲染成一个 Entity Page 文件：含简短概述、逐条标注来源文档 ID 的关键事实、该实体的各种出现名称，以及指向 $N(e)$ 全部文档的文件路径。Entity Pages 与原始文档并列存储，agent 用同样的 shell 工具即可搜索、读取地图；共享同一实体的两份文档经该实体连通，一篇文档也可同时属于多个邻域，无实体链接的文档仍作为孤立节点留在语料中、随时可被原始搜索触达。推理时 agent 以 $\text{Agent}(q, D; G)$ 方式工作：随问题收到相关 Entity Pages 及其链接文档的候选路径列表（BM25 选出、只列标题与路径不含内容），随后可读页面→打开链接文档，也可从文档出发反查提及它的页面。
核心思想一句话：把“文档之间如何关联”从推理时逐查询重新发现，变成离线一次性解析、此后所有查询共享复用的资产。与已有方法的本质区别在于结构的“归属”和“组织单位”。归属上：GraphRAG/HippoRAG 的实体图属于检索器，生成器只能被动接受检索结果；LLM Wiki 的页面组织属于模型即兴发挥；而 CORPUSMAP 的地图属于整个语料库，以普通文件形式与文档并存，agent 用 find/grep 就能访问，且结构由确定性的四阶段流水线产出、可控可审计。组织单位上：本文论证“实体”是最佳导航锚点——它由语料自身定义、可跨源链接（一封邮件、一份合同、一次站会只要都提 Project Atlas 就被连起来）、一篇文档可挂多个实体邻域，从而一个页面就能把散落在不同文件夹、不同应用的互补证据聚在一处。作者还验证了“不加冗余”的克制设计：附录 B.4 表明若模仿知识图谱再加实体-实体边，只会把 agent 本可通过搜索轻易跨越的路径略微缩短（无边时 86-90% 的新页面已靠搜索发现），却令页面膨胀 27-52%、token 最多增 28%，文档召回变化仅 -2.6~+0.2 点——二部图已覆盖全部有效连接，这是经过实验检验的设计选择而非偷懒。
方法步骤详情
构建协议（Algorithm 1）四阶段，全部离线完成。第一步 Cataloging（编目）：输入为采样文档；实体类型（产品、事故、配置项等）因语料而异无法预先穷举，于是用 LLM 从多组小样本各自提议候选类型目录，再综合为一份，经独立的对抗性验证器审查后按验证结果修订定稿；输出类型目录 $\mathcal{C}$，每个类型含名称、定义、身份判定标准与观测实例，此后固定不变。第二步 Extraction（抽取）：输入为目录与每篇文档；逐文档识别并归类实体提及，把文内指同一主体的多个说法合并为一个文档局部实体，无法归类的记为 unresolved；输出每篇文档的局部实体表。第三步 Resolution（解析）：维护从空开始累积的共享注册表 $R$，对每篇文档的每个局部实体检索候选注册条目，权衡当前文档上下文与候选证据后三选一——LINK 到已有实体（更新注册表并记录实体-文档链接 $(e,d)$）、ADD 新建实体（同样记录链接）、UNRESOLVED（不产生链接，宁缺毋滥不强连）；输出注册表与链接集 $L$。第四步 Rendering（渲染）：只保留链接到至少两个文档的跨文档实体 $E$，对每个 $e$ 汇集 $N(e)$ 中各文档关于它的陈述生成 Entity Page，每条事实必须带来源文档 ID，渲染 prompt 明令禁止从提及本身推断别名、关系、所有权；输出地图 $G$ 与页面集合。导航阶段：Entity Page 存为与原始文档并列的文件并列出链接文档路径；随问题附上 BM25 从页面名称/概述/事实中选出的候选 Entity Pages 及其链接文档路径；agent 可搜索页面与文档、点开链接读文档、或从文档反查哪些页面提到它。
技术新颖性
技术新颖性有四层。第一，问题框架的转移：先前工作比拼“搜索策略”（多步检索、工具调用、训练搜索 agent），本文指出真正的瓶颈是“语料组织”，把关系计算从查询时挪到离线、跨查询摊销，这一成本摊销视角是全文最根本的洞察，也解释了为何质量与效率能同时提升。第二，锚点选择有消融支撑：以跨文档解析实体作为锚点并非直觉假设——实体-实体边消融（附录 B.4）与四个替代导航层基线（Document Page、Group Page、LLM Wiki、Corpus2Skill）共同证明，实体是唯一同时满足“可离线识别、可跨源链接、可跨查询复用”三条件的组织单位；且多个基线反而劣于裸语料（GROUP PAGE 在 Sol 上仅 31.23、CORPUS2SKILL 在 GPT-5.5 上仅 45.49），说明“选什么做组织单位”比“有没有导航层”更关键。第三，工程完备性：类型目录的归纳-验证-修订管线解决了“实体类型因语料而异、无法预先枚举”的问题；增量更新只需复用注册表并重渲染受影响页面，节省全量重建 token 的 34%-71%；GLinker 等现成工具可完全替代 LLM 建图，这是与其他“LLM 自组织”方法之间的可复现性代差。第四，来源接地的防幻觉设计：页面每条事实标注来源 ID、解析阶段允许 UNRESOLVED 而不强制匹配，这套保守策略让导航层本身不易被模型幻觉污染，链接可靠才有导航价值。
实验结果
主实验（Table 1，4 个 GPT 模型 × 3 基准 × 3 次运行取均值±标准差）显示 CORPUSMAP 是所有检索方法中唯一稳定最优的：GPT-5.5 上 Overall Quality 72.55 对裸语料 66.11（+6.44），相对 token 0.43×；四个模型相比 RAW CORPUS 提升 +6.45~+11.74 点（Luna 53.85→65.58、Terra 65.75→72.51、Sol 67.69→74.68），输入 token 平均省 34%-57%，配对 bootstrap（10 万次重采样、Holm 校正）后全部 $p < 10^{-4}$（Table 6）。分基准看（GPT-5.5）：EnterpriseRAG-Bench 文档召回 76.17 对 61.62、正确率 73.75 对 62.08，token 88.1k 对 206.5k；WixQA 上下文召回 82.70 对 73.31；HERB 内容分 64.37 对 62.31。关键对照：其余导航层并不稳定有效——GROUP PAGE 在 Sol 上跌至 31.23，CORPUS2SKILL 在所有模型上大幅劣化，说明组织单位的选择比“有无导航层”更关键。Table 3：EnterpriseRAG-Bench 上超过 BM25（63.66）、稠密检索（65.05）、HippoRAG（64.66）、GraphRAG（47.95）。Table 2：跨模型家族有效，DeepSeek-V4-Pro 68.02→71.11、MAI-Thinking-1 34.06→45.07。Table 4：地图可跨模型复用，最便宜的 Luna 建图（≤$74.65）让 GPT-5.5 达 73.59。Figure 3：增量更新每次省全量重建 token 的 34%/69%/71%，新覆盖问题正确性提升 +30.4/+40.0/+40.0。Figure 5：约 9.0K~26.3K 次查询后成本 break-even。Figure 4：GLinker 无 LLM 建图与 LLM 版相当，2.8k~20k 文档及开源 Qwen3.8-27B 上全面占优。Table 5：以单文档问题为主的其余 280 题上也更准（94.76 对 89.05）且省 31% token。Table 7：换 DeepSeek 做 judge 结论不变。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 多文档问答-证据发现（EnterpriseRAG-Bench, GPT-5.5） | Document Recall (%) | 76.17 | RAW CORPUS 61.62 | +14.55 |
| 多文档问答-综合质量（3 基准平均, GPT-5.5） | Overall Quality | 72.55 | RAW CORPUS 66.11 | +6.44（四模型范围 +6.45~+11.74，Holm 校正后 p<10^-4） |
| 效率（3 基准平均, GPT-5.5） | 相对输入 token（几何平均，RAW=1.00×） | 0.43×（494.7k 对 598.4k） | RAW CORPUS 1.00× | -57%（四模型范围 34%~57%） |
| 与检索式 RAG 对比（EnterpriseRAG-Bench, GPT-5.5） | Quality | 76.60 | HippoRAG 64.66 / BM25 63.66 / GraphRAG 47.95 | +11.94（对最强检索基线 DENSE 65.05 为 +11.55） |
| 多文档问答-上下文召回（WixQA, GPT-5.5） | Context Recall (%) | 82.70 | RAW CORPUS 73.31 | +9.39 |
| 跨模型建图复用（EnterpriseRAG-Bench，Luna 建图→GPT-5.5 回答） | Overall Quality | 73.59（建图成本 ≤$74.65） | RAW CORPUS 65.60 | +7.99 |
| 开源模型验证（EnterpriseRAG-Bench, Qwen3.8-27B + GLinker 建图） | 检索/答案质量与 token | 所有语料规模（2.8k/10k/20k 文档）全面优于 RAW CORPUS 且 token 更少 | RAW CORPUS (Qwen3.8-27B) | 各规模一致提升，最高省 75k token |
局限与改进
作者承认的局限：其一，隐私与权限风险——Entity Page 把散落各文档的个人信息（某人、某项目）聚合一页，可能造成敏感信息集中暴露或向无权用户泄露文档，伦理声明明确指出实际部署需按访问权限分级建图并加入隐私与内容过滤；其二，摊销依赖查询量——建图有一次性成本（GPT-5.5 建图 ≤$4,732），需约 9.0K~26.3K 次查询才在成本上 break-even，低频使用的语料库可能不划算。我的补充观察：其一，实验语料最大仅 2 万文档，真实企业语料常达数十万级，BM25 页面排序与逐文档串行解析注册表的大规模扩展性未经充分验证；其二，系统对候选路径质量敏感——随机候选使 GPT-5.5 质量从 76.60 跌至 60.76 且 token 大增，一旦候选选择器（BM25）失效收益会明显缩水；其三，论文未报告实体解析本身的准确率，也不讨论错误合并（把两个不同项目连成一个实体）对下游答案的传染性影响；其四，地图不建模时间与版本，同一实体的最新状态与历史事实在页面上如何取舍没有机制，而企业问题常问“现在怎么样”；其五，Oracle 上限（约 79.6~80.0）与 CORPUSMAP（72.55~74.68）仍有约 5~7 点差距，说明证据齐全后答案合成仍是另一重瓶颈；其六，三个基准问题量偏小（80/79/238 题），跨任务泛化还需更大规模验证。
独立分析的弱点
弱点一：静态结构假设。地图的有效性建立在“实体-文档关系跨查询稳定”上，但企业语料高频增删时，长期增量更新会导致注册表实体碎片化与陈旧链接积累，论文只测了沿时间戳顺序的 3 次更新，未评估数十次更新后的结构漂移；改进方向是引入周期性的注册表合并去重与链接置信度衰减机制。弱点二：候选选择器是 BM25。论文自己的动机例子（项目内部代号导致搜索失灵）恰恰是词面匹配的软肋，附录 B.3 显示收益几乎全部来自候选相关性；改进方向是用轻量语义检索器或训练一个候选排序模型替代 BM25，并允许 agent 主动请求补充候选。弱点三：无时间意识。页面把不同时期的事实并列呈现，回答“当前状态”类问题（如 Conflicting Info 类别）时完全依赖 agent 自行判断新旧；改进方向是在渲染时加入时间戳感知的事实排序或“最新状态/历史沿革”分节。弱点四：隐私方案停留在伦理声明。多租户场景下按 ACL 分片建图会使实体邻域破碎（同一项目的高管级文档与员工级文档分属不同图），如何在权限约束下共享导航结构是未解的工程问题。弱点五：评估对小基准与 LLM judge 的依赖。附录 B.2 显示换 judge 后上下文召回的方法排序一致性仅 Kendall's τ=0.47，说明部分指标对 judge 选择敏感，应补充人工标注校准；80/79 题的基准规模也让细粒度结论（如分类型表现）统计功效不足。
未来方向
作者在结论中展望“从反复搜索孤立来源，转向导航和推理互联知识”的更宏大转变，CORPUSMAP 意在成为这一转变的基础设施。基于成果可延伸的方向：其一，丰富锚点类型——在实体之外引入事件、因果关系等锚点，同时遵守论文“不添加冗余边”的验证原则，可能进一步提升需要多跳推理的问题表现；其二，学习化导航——当前候选选择用 BM25、导航策略依赖模型通用能力，可用强化学习（如 GrepSeek 式训练搜索 agent 的思路）端到端优化“何时信任页面摘要、何时回到原始文档”的决策策略；其三，与持续学习结合——HippoRAG 后续工作把语料结构视为非参数持续记忆，CORPUSMAP 的增量更新协议天然适配该视角，可研究“地图更新即记忆写入”的理论性质与遗忘策略；其四，多模态扩展——把实体解析与页面渲染推广到图表、幻灯片、代码仓库等多模态企业语料；其五，冲突推理——针对 Conflicting Info 类问题，沿实体-文档路径做来源可信度加权与时间排序的证据链验证；其六，压缩建图成本——把四阶段管线蒸馏进小型专用模型，把 9K~26K 次查询的 break-even 点大幅提前，让低频语料库也能受益；其七，超越问答——探索地图在多轮对话、任务规划中的应用，Entity Page 可充当 agent 可持久化、可共享的工作记忆。
复现评估
复现性中等偏上。有利面：方法规格完整——Algorithm 1 伪代码清晰，附录 C 公开了全部 7 个构建 prompt（目录提议/综合/验证/修订、抽取、解析、渲染），正文与附录 A 交代了各基准的具体问题子集（80/79/238 题）、语料构成（2,819/6,221/6,365 文档）、指标定义、agent 可用的 16 条 shell 命令清单及 API 调用时间窗（2026 年 8-9 月）；统计检验规范（10 万次配对 bootstrap + Holm-Bonferroni 校正）；消融充分（候选路径、实体-实体边、增量更新、GLinker 替代、judge 鲁棒性）。不利面：论文未声明开源代码或建图产物，读者需从零实现流水线；主实验依赖 GPT-5.5/5.6 闭源 API，成本不菲——单是 GPT-5.5 建图就报告 ≤$4,732，主表 6 方法 × 4 模型 × 3 次运行的 agent 轨迹总成本可观；HERB 需要其官方模拟环境。最经济的复现路径是论文自证过的组合：开源 Qwen3.8-27B 做 agent + GLinker 开源模型建图（渲染无需任何 LLM 调用），Figure 4 显示该配置已能复现核心收益；若追求对齐主表数字，则需 API 预算并使用 GPT-5.6 Sol 做 judge。总体难度：有 NLP 工程经验的团队约需 1~2 个月实现与调试。
论文图表
构建协议伪代码：第 1 行从采样文档归纳实体类型目录；第 2 行逐文档抽取并归类局部实体；第 3-13 行遍历文档与局部实体，对每个实体在共享注册表中检索候选后决定 LINK/ADD/UNRESOLVED 并记录链接；第 14-15 行只保留链接到至少两个文档的跨文档实体；第 16-19 行为每个保留实体渲染其邻域为 Entity Page；第 20-21 行输出二部图 G 与页面集合。
方法是围绕这 21 行伪代码展开的，它是复现整个系统的骨架，四阶段各自的输入输出一目了然。
在检索-生成范式下（一次性检索固定上下文、不访问完整语料）与 BM25、稠密检索、HippoRAG、GraphRAG 对比：GPT-5.5 上 CORPUSMAP 76.60，显著高于 DENSE 65.05、HippoRAG 64.66、BM25 63.66、GraphRAG 47.95（RAW CORPUS 为 65.60）；Luna 上排序一致（CORPUSMAP 73.20 对 HippoRAG 61.74）。
与图结构 RAG（HippoRAG/GraphRAG）的直接对比凸显本文定位差异：把结构暴露给生成器继续搜索，优于把结构埋进检索器一次性取上下文。
解析提示词：给定文档、目录与每个局部实体的候选注册条目，决定链接到已有实体、新建实体或保持 unresolved；明确警告注册表不完整、名称相似或检索排名不能作为同一性证据、须对照最强竞争候选仍无法区分时返回 unresolved；新实体的规范名必须是原文精确出现的形式。
体现“宁缺毋滥”的保守解析策略，这是实体链接质量、进而地图可靠性的核心保障。
渲染提示词：为已解析实体写统一的记忆页，要求简洁朴素地总结源文档中记录的不同上下文，只用文档显式信息、合并重叠内容并保留具体细节与日期，每条关键事实必须以 [dsid x] 形式标注全部来源文档 ID，禁止从提及本身推断别名/身份/关系/所有权，并要求忽略文档内嵌指令（防注入），输出固定形状的 Markdown（Overview + Key facts）。
Entity Page 是方法的用户界面，此 prompt 的来源接地与防推断、防注入规则直接决定导航层的可信度，是复现与改进的关键参考。