跟随实体:面向智能体检索的语料地图

TL;DR CorpusMap 以文档中共现实体为核心构建导航图，让 agent 沿实体页面跨文档汇聚证据，在 7 个模型、3 个数据集上提升答案质量与证据发现，并降低 token 消耗。

问题

问题背景

多文档问答与任务完成是当前 LLM agent 的重要应用方向，agent 需要在大型语料库中迭代搜索并连接分散证据。

现有方法局限

Raw-corpus agentic search 将语料库暴露为扁平文件集合，文档之间没有关系指示。Agent 针对每个 query 都必须重新发现文档间关联，具体局限包括：

• 相关文档无法提示与其相关的其他文档，agent 容易遗漏互补证据。
• 反复探索文档关系消耗大量额外 tokens，推理成本显著上升。
• 关系发现无法跨 query 复用，每个新问题都从头开始。

为什么这个问题难/重要

技术挑战 在于：从文档中自动识别重复实体，并跨文档解析指代一致性，离线构建实体-文档导航图。业界关注度 高，因为 agentic search 在实际企业知识库、研究文献库等场景中的推理效率与证据覆盖率直接影响可用性。一个可共享的导航层能摊薄构建成本，让 agent 专注于查询而非关系重建。

行业类比

类似自动构建的企业知识图谱导航页，让 agent 沿实体链接跳转，而非每次从原始文档堆中重新检索。

核心洞察

• 实体作为可跨文档链接的导航锚点，将平铺语料库重组为实体-文档图，使 agent 在推理时直接遍历关系而非每次从检索结果中临时推断。这与 raw-corpus agentic search 的本质差异在于：后者每次查询都要重新发现文档间隐含联系，容易遗漏互补证据且消耗大量 token；CorpusMap 则通过离线实体解析把这种关系显式固化，为多跳证据聚合提供稳定路径。
• 离线构建的 Entity Page 让跨查询共享链接，将一次性构建成本摊销到多次推理中，同时支持增量更新和跨模型复用。对比逐查询检索或动态索引方法，CorpusMap 在 token 效率和答案质量上取得平衡；实验显示 7 个模型、3 个数据集上平均 token 更少且优于 4 种替代导航层，表明实体锚点在工程上兼具可扩展性与可解释性。

方法

输入

原始输入是扁平文档集合(flat collection of files),以及需要跨文档证据的用户查询。每个文档仅是独立文件,不显式编码与其他文档的关系。

关键模块

CorpusMap 构建(离线完成):

1. Cataloging:扫描语料,建立文档索引。
2. Extraction:用实体抽取模型从各文档中识别出实体提及(entity mentions)。
3. Resolution:对跨文档的实体提及进行实体解析(entity resolution),将指向同一实体的不同表述合并,得到递归实体(recurring entities)。
4. Rendering:为每个递归实体生成一个 Entity Page,其中聚合该实体的上下文信息,并列出所有提及该实体的文档链接,形成实体-文档二部图。

导航层:在推理时,LLM agent 不再直接搜索原始语料,而是从查询出发,在 CorpusMap 上执行迭代式导航:

• agent 先定位相关 Entity Page;
• 从该页面跳转到多个关联文档;
• 通过文档反向发现新的实体页面;
• 重复此过程,逐步收集分散在多处的互补证据。

输出

输出是基于完整证据链的最终答案。由于实体-文档图在离线阶段预先构建,各查询共享同一套链接结构,推理时无需重复发现文档间关系,直接受益于导航图中已编码的关联。

CorpusMap 将一次性构建成本摊销到多次查询,在不同查询间复用实体链接,相比每次查询重新发现关系的 raw-corpus agentic search,显著降低推理 token 消耗,同时提升证据发现率和答案质量。

与同类方法差异

不同于单纯用检索器返回固定 top-k 文档的 retrieval-based 方法,也不同于在原始语料上做显式多跳推理的 agentic search,CorpusMap 以实体为锚点组织整个语料,提供可遍历的文档间关系图,使 agent 的搜索空间从线性扁平结构变为可解释的图结构。

实验

实验设计

• 论文在 3 个多文档问答 / 任务型 benchmark 上评估 CorpusMap,覆盖 7 种 LLM(含开源与闭源家族),与 raw-corpus agentic search 及 4 种替代导航层 对比。
• 主要指标为 证据发现率(evidence discovery) 与 答案质量(answer quality),并统计 token 消耗。

关键发现

• CorpusMap 在证据发现与答案质量上均优于 raw-corpus 基线,同时平均 token 消耗更低。
• 在 7 种模型中一致提升,表明实体中心的导航层具有 跨模型泛化性。
• 相比替代导航层(如文档聚类、摘要、关键词图等),CorpusMap 在 4 个 baseline 上均表现更好,说明 recurring entities 是有效锚点。

与基线对比解读

• Raw-corpus 搜索让 agent 每次查询都需重新发现文档关系,而 CorpusMap 离线构建实体-文档图,查询时复用链接,减少重复推理与 token 开销。
• 与基于检索的固定 top-k 方法相比,CorpusMap 允许 agent 沿实体页遍历,能发现分散在多文档中的互补证据,避免遗漏。
• 成本摊销 是工程优势:一次性离线索引可服务多次查询,对大规模文档库友好。

行业影响

落地场景

CorpusMap 适用于需要跨文档证据合成的企业知识库、合规审计、客服支持和金融研究等场景。例如，在电商客服系统中，一个退款工单需要结合订单记录、商品政策、历史沟通记录和仓库日志等多份文档；CorpusMap 将“订单号”“SKU”等实体构建为 Entity Page，agent 可沿实体-文档图快速找到所有相关证据，避免在扁平文件集合中反复搜索。在医疗文献检索中，围绕“药物-靶点”实体聚合临床试验、副作用报告和基因数据，辅助循证决策。

商业价值

离线构建的实体链接图跨查询复用，避免 agent 在推理时重复发现关系，从而显著降低 token 消耗；论文显示在 7 个模型、3 个基准上平均减少 token 且提升答案质量。这直接压缩 LLM 推理成本，同时提高任务完成率和答案准确性，减少人工复核。对于高频、多步的企业搜索工作流，可带来明显的降本增效，并提升用户体验。

接口与集成

CorpusMap 可作为检索增强层嵌入现有 RAG stack：文档先经过离线管线（实体抽取、跨文档解析、Entity Page 渲染）生成图结构；运行时以 API 或索引形式暴露给 LLM agent，作为搜索工具之一。可以与向量数据库、关键词索引并存，作为候选文档路径生成器；也能集成到 LangChain、LlamaIndex 等 agent 框架中，通过自定义 tool 调用。增量更新支持持续接入新文档，工程上可逐步迁移。

局限

• **实体提取与解析质量**是瓶颈。CorpusMap 的性能高度依赖离线阶段的实体识别和跨文档消解准确率。若文档中实体提及稀疏、表达多样（缩写、指代、拼写错误），或文档本身缺乏结构化实体（如纯技术日志、图像描述），Entity Page 的构建和链接密度会显著下降，导致 agent 在导航时无法找到有效锚点。实际工程中，需要额外的实体标准化流程或领域词典，否则冷启动成本高。
• **离线构建与动态更新成本**。CorpusMap 需要离线解析全部文档并解析实体共指，对于大规模或频繁更新的语料，重建/增量更新开销大。论文提到增量更新，但未给出复杂度分析和具体策略。实际部署时，每次语料变更都需要重新运行提取和渲染流程，可能难以做到准实时。此外，Entity Page 的存储和检索需要额外索引结构，增加了系统复杂度。
• **对比基线有限**。实验对比了 raw-corpus 和 4 种 alternative navigation layers，但未与基于外部知识图谱或图检索的 agentic search 方法充分比较。另外，评估集中在问题回答任务，未覆盖更复杂的 agent 任务（如多步决策、工具调用），且仅使用 3 个 benchmark 数据集，领域覆盖可能不足。因此，CorpusMap 是否在更通用的 agentic workflow 中保持优势仍需验证。