MMEnterprise-Bench：基于演化多模态记录的企业智能体评测基准 MMEnterprise-Bench: Evaluating Enterprise Agents over Evolving Multimodal Records

完整流程分八步。第一步源信息提取：输入种子文档全文与图表，输出结构化 JSON——方法名、任务摘要、带精确数字的配置事实、定量声明、流水线步骤，以及图表的 image-only facts（只能从像素读出的事实），规则禁止改写任何数字。第二步组织构建：选定公司原型（research_lab 或 analysis_firm）、虚构公司与客户、团队成员人设（每人有 owns 职责和 voice 语气）、频道与访问限制、里程碑。第三步事件调度：输出按时间排序的一周事件表，包括结果行（baseline/progression/release/analysis）、刻意脚本化的错误（错误值—发现者—修正时刻）、决策日志与状态漂移事实，每个演化事实有多个带时间戳的版本。第四步记录生成：按事件生成 PDF 报告版本（v1 中未定结果标 pending）、slides、Slack 消息（纠正必须写成错值到对值）、渲染表格与图表图像，每条记录带 ID、时间戳与来源元数据。第五步记录质检：程序化检查 JSON 格式、数值与源文档一致、事件顺序正确；对每个频道用 LLM 评审 Slack 自然度（5 分制，2 分以下触发重写）。第六步 QA 生成：规则式与 LLM 式结合出题，输出问题、参考答案、2-5 步解题方案与代表性充分证据集；UNS 题由可答案题改动一个实体或条件生成并验证全库不可答。第七步三阶段 LLM 验证：独立求解器仅看引用证据作答并判断 knowable；比对候选与金标（容许等价措辞与合理舍入）；全项目校验竞争答案、数字核验与答案泄漏，裁决为 pass/fix/drop。第八步人工盲验证：3 名标注者盲评 100 题（50 条 LLM 接受加 50 条 LLM 拒绝），LLM 接受题 100% 通过人工，29 条人工拒绝题全部被 LLM 拒绝，说明 LLM 验证与人类一致且更保守。

技术新颖性体现在三点。第一，基准设计层面：Table 2 的六维对比（工作区、多模态、跨源冲突、时序冲突、不可回答性、真实文档奠基）显示本文是唯一全占的基准——EnterpriseRAG-Bench 缺多模态与真正的时序金标，CONFLICTS 有冲突但无工作区与多模态，MMLongBench-Doc 有多模态却无演化，LongMemEval 有时序但面向个人对话。第二，数据构造层面：把冲突内生于「错误—发现—纠正」事件脚本与「只增不删」的版本保留策略，而非事后插入对抗样本，保证了冲突场景在时间戳、访问权限、消息语气上的全局一致性；统计上 CR 题的平均证据数（跨源 2.23、时序 2.93 条）显著高于 ER 题（1.32-1.95），证明这种构造天然产生多证据难题。第三，评测分析层面：首次系统解耦证据召回与答案准确率——用同一语料在 $k \in \{10, 50, 100\}$ 与 2B/8B 两个检索器上做对照实验，证明 $\mathrm{Recall}@k$ 提升不必然带来准确率提升，指出瓶颈在证据整合推理而非检索本身。

独立分析五个弱点。第一，UNS 维度太薄：仅 87 题且构造方式单一（替换实体），真实部署中证据不足的形态远比换个查询对象丰富——证据部分过期、来源可信度未知、单位不一致等；改进方向是引入对抗性多类型 UNS（部分支持、时效过期、前提矛盾各占一定比例）并扩到数百题规模。第二，judge 单点依赖：全程用 GPT-5.6 Luna 评分，对同家族专有模型可能存在风格偏好；改进方向是双 judge 交叉验证（如并用 Gemini 系 judge）并报告 judge 间一致率，或对随机子集做人工全量复核。第三，检索设置过于理想化：记录按时间戳排序后整包喂给模型，低估了上下文长度压力——单项目平均 8.88 万 tokens，$k=50$ 时弱模型未必能有效利用全部检索记录，其准确率随 $k$ 下降正暗示这一点；改进方向是报告不同排序策略（最新在前或相关度在前）、上下文压缩与长上下文消融。第四，冲突类型以数值被修正为主：剧情模板集中在错误—纠正与截止日期变更，缺少两个来源各自部分正确需合并、精度不同的等价表述等更细粒度的冲突语义；改进方向是为 CR 增加冲突类型标签并分类报告成绩，帮助诊断模型究竟败在哪一类冲突。第五，语料规模偏小（7,140 条记录、约 266 万 tokens），检索难度可能低于真实企业级语料库；改进方向是用同一 pipeline 扩展到数百个项目并测试规模效应。

作者的结论指出：提升检索并不必然提升回答，需要能对多模态证据与演化记录状态进行推理的模型，MMEnterprise-Bench 将作为开发可靠企业助手的测试床。基于此可延伸的方向包括：冲突感知检索与重排序——把同一事实的多个版本作为检索单元分组，让模型显式看到版本链而非离散记录；时间感知索引——为每条记录引入 valid time（事实有效时刻）与 transaction time（记录写入时刻）双时间轴，精确支持 as-of 查询；拒答校准——把 UNS 扩展为带置信度的弃权目标，研究为何总体能力强的模型（GPT-5.6 Sol 65.5%）反而不如 Gemini 3.8 Flash（87.4%）会拒答；多智能体检索—核对流水线——让检索器、视觉读取器、冲突仲裁器分工协作，直接针对跨多图像崩塌（27.5%）的问题；以及把基准扩展到权限感知评测（谁能看哪条记录）与会话中途的在线演化更新，进一步逼近真实部署形态。

复现难度总体中低，资源友好。基准本体：代码与数据已在项目页开源（https://mlvlab.github.io/MMEnterprise-Bench/），语料基于 CC BY 4.0、Public Domain、OGL 3.0 等明确许可的公开文档构建，附录 A 列出全部 30 个种子的来源与权利信息。评测复现：协议简单——Qwen3-VL-Embedding-2B 检索 top-$k$（$k \in \{10, 50\}$），记录按时间戳排序，temperature 0；开源模型用 vLLM 0.24.0（bfloat16）即可运行，2B-9B 模型单张工作站 GPU 可承受，27B 约需多卡或 A100/H100 级别；专有模型走 API；judge 依赖 GPT-5.6 Luna API。数据构建复现：附录 B 公开了从源提取、组织构建、事件调度到 Slack 与报告生成的全部 prompt 模板，附录 C 公开验证 prompt，工程上可照搬；但完整重建语料需要大量 LLM API 调用（每个项目 203-274 条记录）与人工盲验环节（作者由作者本人完成、未招募外部标注者），第三方从零复现到题级一致较难；直接使用发布数据做评测则门槛很低，适合作为即取即用的测试床。