CorporateBench: Large-Scale Q&A Benchmarking with Temporal Knowledge Bases —— 精读

论文链接：https://arxiv.org/abs/2608.27391

数据集：https://huggingface.co/datasets/epiq-ai-labs/corporatebench

发表时间：2026 年 8 月 27 日（arXiv:2608.27391v1）

发表机构：Epiq AI Labs、康奈尔大学（企业+高校合作：一作为康奈尔博士生，Epiq 提供企业场景与工程支持）

作者：Sil Hamilton、Albert Yu Sun、Oscar J. Romero、Carl-Leander Henneking、David Mimno、Bishan Yang、Igor Labutov

一、论文背景

LLM 越来越多地被用于知识工作、文档分析和围绕组织及其社会网络的通用推理。虽然上下文窗口已扩展到百万 token 级别，但最先进的 LLM 在企业场景常需的多文档复杂推理上依然挣扎，这阻碍了 LLM 在产业界的规模化落地。问题在于：现有评测根本测不出这种失效模式。

症结有两点。第一，企业不愿公开内部通信——真实的公司邮件受保密协议（NDA）保护，于是多数"企业基准"只能把非企业数据改头换面凑数。第二，合成数据集又过于简单——大名鼎鼎的"大海捞针"（needle-in-a-haystack）测试只考"能不能在长文本里找到一根针"，与真实企业知识工作的复杂性相去甚远；而新兴的 LLM 合成企业语料（如深度搜索类基准）规模普遍不超过 3 万文档，且用提示词生成没有可靠方法保证标注正确。

另一个此前被忽视的维度是逻辑一致性。真实企业里，“张三向李四汇报"这一事实会同时体现在组织架构图、会议纪要、日常邮件等多个文档中。如果基准里各文档互相矛盾，或者答案只靠 LLM 生成而非确定性推导，那模型分数的波动就无法归因——到底是推理能力不行，还是数据本身有噪声？

本文要回答的核心问题是：如何在保证跨文档逻辑一致与答案可验证的前提下，把企业问答基准的规模推到 10 万文档级，逼近真实企业通信网络的体量？

二、论文定位和关联工作

论文将自身定位在三条研究线的交汇处，其 Related Work 部分梳理如下：

长上下文评测。LLM 普遍存在"迷失在中间”（Lost in the Middle）等长上下文理解缺陷。测试手段从大海捞针及其变体（Michelangelo、MRCR），到基于书籍、剧本、小说的叙事类基准。这类基准要么牺牲真实感换取生成速度，要么文档数量太少，够不上"企业规模"。

企业基准。基于财务记录（KPI-EDGAR、FinBen、SuperCLUE-Fin）、法律（LegalBench、LawBench）、知识工作（WorkArena/WorkArena++、WorkBench、TheAgentCompany）等的基准大量涌现，但共同问题有二：一是数据源常为"非企业数据变形"以规避 NDA，质量存疑；二是即便用 LLM 模拟企业活动生成合成语料（如企业深度搜索沙盒），规模也止步于约 3 万文档，且用提示词生成的数据没有单一方法能保证输出符合全部期望特性——ground truth 不可靠。

合成知识库。知识库长期用于表示人类知识（Freebase 等），近年用于生成接地（grounded）合成文档。早期研究因难以从非结构化文本解析关系而很少刻画企业环境这类复杂系统；LLM 出现后，从文本构造 KB 与从文本转结构化查询都变得可行。本文正是看中 KB 能提供"单一、任意详细的世界状态"，从而（i）以百万级规模合成文档集合，（ii）通过查询底层图得到精确标准答案。

与最接近的 EKRAG（企业 RAG 基准）相比，CorporateBench 的证据/问题比达到 87.6 文档/题（EKRAG 仅 1.5）——高比值意味着回答一个问题需要综合大量文档的信息，这才贴近真实企业知识工作的复杂度。

三、问题定义

论文要构建的基准需同时满足两个形式化性质：

1. 任意规模（Arbitrary Scale）：对任意期望的语料规模 n，管线能生成 ≥n 份文档，且在文档数增长时保持质量一致——为 LLM 上下文窗口继续增长预留前瞻性。
2. 逻辑一致性（Logical Consistency）：∀d∈C，文档 d 中的任何陈述都不与知识库确立的事实矛盾。理想情况下，从采样出的所有文档可以重建整张知识图。

在此之上定义评测任务（两大类五项）：

• 抽取类：考察模型能否从原始文档构建结构化知识库。包括 KB 评测（抽取实体与关系三元组，按人工标注的 ground truth 三元组计算 F1）与主题分类（多分类，macro-F1）。
• 问答类：考察模型对已构建表示的推理。包括 KB QA（实体、关系及其时序性问答）、Topic QA（文档主题问答）、Integrated QA（前两者结合）。答案类型有字符串、日期、整数、布尔和字符串集合，除集合用 F1 计分外均用精确匹配。模型在两种工具设置下作答：RAG（向量检索工具，贴近真实部署）与 KB（SQL 直查结构化真值，代表性能上界参照）。

四、问题解法

管线的核心思想是**“先造世界，再造文档”**：不直接生成文档，而是先程序化生成一个自洽的世界状态（时序知识库），再从中采样出证据一致的企业邮件。

4.1 定义本体

用 Turtle/RDF 形式化定义公司 C=(D, T, E)：员工 E 组成团队 T，团队归属部门 D。本体定义 Entity 与 Relationship 两个基类，扩展出组织实体（公司、部门、团队、员工）与工作实体（项目、会议、任务），由七种关系谓词连接：MemberOf、ReportsTo、WorksOn、WorksAt、Attends、Organize、BelongsTo——把员工沿组织（隶属/汇报层级）、工作（任务分配）、沟通（会议出席/组织）三根轴编织起来。序列化时用 OWL 解析器校验约束。

4.2 生成公司

六步流程：①按员工数对数缩放部门/团队数量，生成有效树状层级；②模拟一个季度（90 天）的任务流，每天以 P=1/45 给员工分配任务；③按六类会议（直接汇报、团队会、任务协作、高管会、项目评审、部门会）模拟会议，参与者由角色与汇报关系决定——例如直接汇报会只配对员工与其经理；④季末招聘约 10% 新员工并拆分团队，这刻意制造时序陷阱：旧 MemberOf 关系标记结束日期，确定某人的雇佣状态至少需要两份文档；⑤把每个实体自顶向下递归传给 Claude Haiku 4.5 注入姓名、头衔等属性，并为员工和项目生成别名；⑥渲染为 N-Quads 三元组文件。

4.3 生成文档

邮件必须"坐实"KB 中的关系。方法是插入证据字符串：预定义 3,217 条字符串，覆盖七种关系类型，按时间阶段（关系开始/进行中/结束）与证据强度（显式/隐式）分箱。例如"Just going through the {{object}} onboarding materials today"是一条隐式证据，表明某员工的 WorksOn 关系已经开始；会议类证据则按任务进度（0-25%/25-50%/50-75%/75-100%）分箱。证据字符串之外，正文其余部分交给 Claude Haiku 4.5 补全。为保证词汇多样性做了三件事：邮件格式模仿公开的 Enron 语料；主题从 Dirichlet 分布（α=0.75，3000 商务+3000 非商务主题）采样以贴近真实世界话题不均匀分布；每位员工分配 MBTI 十六型人格之一，邮件随机正式/随意语气。

4.4 答案导出与验证

QA 问题由 250 个人工撰写的问题模板生成，占位变量由人工验证过的 SPARQL 查询从 KB 确定性填充——不由 LLM 生成，杜绝标注噪声。人工验证环节：随机抽 100 封邮件，用 Claude Sonnet 4 反转证据字符串制造负例，10 组×5 名评审对 1000 条判断做二分判断，评审以 76.2% 的正确率识别出文档所断言的关系。

最终产出四家公司（见下表），每一档恰好比上一档大一个数量级。

五、评估指标与实验证据

评测五个轻量级前沿模型：Claude Haiku 4.5、Claude Sonnet 4.5、GPT-5 Nano、GPT-5.1、Gemini 2.5 Flash Lite（选轻量模型是为控制 26.3 万文档全集评测的 API 成本）。

5.1 抽取任务：实体稳、关系崩

KB 评测结果（三模型对比）：

关键发现：实体抽取跨规模基本稳定（F1 0.715–0.824），关系抽取却显著恶化，时序关系最惨——所有模型在 XL 上 F1 不超 0.173。误差分析显示两类主因：实体抽取错误级联传导给关系抽取；跨文档矛盾的关系描述不断累积。细分看，attend（出席会议）关系的漏报率高达 63–71%，worksOn 关系被 Gemini 2.5 Flash Lite 过度预测 69%，而 reportsTo/worksAt 等层级结构关系错误率大多低于 10%。

主题分类上，LLM 少样本效率惊人：Biocure 上 50-shot 即达 F1 0.963–0.982，用 200 倍更少的数据逼近 TF-IDF+LR 万样本水平（0.993）；但 Pound 上主题层级合并造成语义边界模糊，LLM 50-shot 仅 0.598–0.751，不敌 10 万样本基线（0.983）。

5.2 问答任务：KB 直连全面胜 RAG，差距随规模拉大

KB QA 最优成绩（KB vs RAG 设置）：

三个要点：①所有 QA 类型上，最优 KB 成绩均超最优 RAG 成绩，且差距随规模扩大——KB QA 上从 S 的 0.24 增至 XL 的 0.37，说明小语料 RAG 尚可应付，规模一大检索噪声就成为瓶颈；②KB QA 与 Topic QA 随规模退化，但 Integrated QA 反而随规模略升（更大语料提供更丰富的跨源综合上下文）；③模型画像分化：两个 GPT-5 系模型在 RAG 下占优，Claude Sonnet 4.5 在 KB 查询上全面最佳（KB QA 0.628–0.767、Topic QA 0.571–0.848、Integrated QA 0.611–0.647），但 GPT-5.1 存在早停缺陷——收到工具响应后返回空字符串，KB 设置下发生 191 次（RAG 仅 56 次）。

5.3 程序性错误分析

30,000 次运行共 697 次失败（2.3%）。KB 查询产生的错误是 RAG 的 4.7 倍（547 vs 150），主因是工具调用与输出校验引入新失效面；“Prompt too long” 几乎只出现在 L/XL 规模（72 次）；GPT-5.1 失败率最高（4.1%），Sonnet 4.5 最稳健（3.0%）。

六、效果优势的根源解释

这篇论文本身是基准构建工作，其"效果"体现为基准的评测分辨力。为什么 CorporateBench 能揭示出前人基准测不出的失效模式？建立如下因果链：

方法差异一：KB 先行、文档后采样（而非直接生成文档）→ 机制变化：ground truth 由 SPARQL 从单一世界状态确定性导出，规模扩大时世界状态只是变"大"不变"乱"→ 指标提升：规模成为受控变量，模型分数随 S→XL 的衰减可归因于推理能力而非数据噪声。 反观"提示词生成语料"路线，文档间无一致性保证，标注不可验证，规模一大噪声便淹没信号。

方法差异二：季末 10% 招聘 + 关系结束日期 → 机制变化：确定雇佣状态必须联合至少两份文档做时序推理 → 指标提升：精准暴露时序关系这一最大短板（XL 上 F1≤0.173）。 若所有关系在任意时刻都单文档可判，模型只需局部匹配，时序推理根本不会被触发。

方法差异三：证据/问题比 87.6 文档/题（次优基准 1.5）→ 机制变化：每题需要跨大量文档综合，且总规模可超上下文窗口，迫使模型依赖工具 → 指标提升：RAG 与 KB 的差距随规模从 0.24 扩大到 0.37，GPT-5.1 早停缺陷被专门放大（KB 191 次 vs RAG 56 次）。 低比值基准里"一查即中"的检索几乎等价于直查，两种工具设置的差异无从显现。

方法差异四：实体稳定而关系崩坏的分层发现 → 归因于机制。 实体（人名、公司名）是局部特征，单文档即可识别，故 F1 跨规模稳定；关系需要跨文档聚合与去重（邮件重复提及同一汇报关系），错误随文档量累积；attend 类事件关系散落在海量日历邀请中，漏报率 63–71% 顺理成章。这说明当前 LLM 的瓶颈不在"读"而在"聚"——把多次局部观察整合成全局一致的世界模型，恰是企业知识工作的本质。

七、必要知识反推

若想读懂乃至复现这篇论文，需要掌握以下知识点（按依赖顺序）：

1. RDF/Turtle/OWL 本体与 SPARQL 查询：论文的世界模型用 Turtle 序列化、OWL 校验、SPARQL 导出答案。需要理解三元组（主语-谓语-宾语）、N-Quads 格式、图查询的基本语法。
2. 知识库接地生成（KB-grounded generation）：与"直接提示 LLM 写文档"相对，先建结构化真值再采样文档的范式，理解"证据字符串"如何充当文档与 KB 之间的锚点。
3. RAG 系统工程：向量数据库（pgvector）、嵌入模型（text-embedding-3-small）、HNSW 索引、top-k 检索，以及 ETL 管线（截断、批处理、幂等加载）。
4. Agent 工具调用评测：Pydantic AI 式 agent 框架、工具调用次数上限（5 次）、few-shot 提示设计、以及"输出校验失败/空响应/超限"等程序性错误的分类学。
5. 评测指标：精确匹配 vs 集合 F1 的取舍（集合题给部分分）、macro-F1（按类平均，对类别不平衡敏感）、precision/recall 分解诊断过度预测与漏报。
6. 时序知识表示：关系的 beginning/end 日期、ongoing/bounded 分类、“世界状态在时刻 t 成立"的语义——这是理解时序陷阱设计的前提。

八、通用性灵感

跳出基准本身，这项工作有几条可迁移的思想：

1. “先造世界，再造文本"是合成数据质量的总开关。任何需要内部一致性的合成数据（代码仓库、多智能体对话、交易流水）都可以套用：先定义结构化世界状态，再让 LLM 把状态"渲染"成自然表达。一致性由结构保证，多样性由渲染注入，两者解耦。
2. 时序变更是天然的难度放大器。往任何关系型数据里注入"季末招聘式"的状态变更，就能把任务从模式匹配升级为跨文档时序推理——这是低成本提升评测区分度的通用手法。
3. 评测要给"规模"装上控制旋钮。四个数量级的同构数据让任何性能曲线都能对规模作图，暴露 scaling 行为（实体稳/关系崩、Integrated QA 反升）。做系统评测时值得默认提供 2–3 个数量级的同类数据。
4. 工具 A vs 工具 B 的对照设置比绝对分数更有信息量。RAG vs KB 的差距随规模扩大，直接量化了"检索噪声税”；同理可对比不同检索器、不同 schema、不同工具接口的相对税负。
5. 程序性错误也是评测产出。空响应、工具超限、上下文超长这些"工程失败"在 30,000 次运行中只占 2.3%，却精准定位了 GPT-5.1 的早停缺陷——基准报告应保留并分析失败模式，而非仅报成功样本分数。
6. 轻量模型的评测经济学。作者明确说明选轻量模型是为了控制 API 成本。当基准规模到达十万文档级，评测成本本身成为设计约束，这一权衡在自建评测时同样成立。