模拟外卖平台造 75 亿行 ERP 数仓,最强模型仅解 34.8%

Argo-Bench: Evaluating Data Agents on Enterprise-Scale Workflows

Gabriel Tomitsuka, Arman Raayatsanati, Emma Xing, Duke Gand, Joseph J Ma

cs.CL, cs.AI, cs.DB

2026-10-02

在 75 亿行模拟 ERP 数仓上按行动后果打分,14 个模型里最强的 Claude Opus 5.5 平均 59.5 分、仅 34.8% 任务解出。

这篇在解决什么

Spider 2.0-Snow 榜首成绩从发布时的 23.8% 涨到 96.7%,BIRD 第一名 82.4%,离人类的 93.0% 只差十来个点。单看榜单,企业数据工作像是要被解决完了。TextQL 做的 Argo-Bench 给出相反判断:现有基准量的根本不是企业里的活。

三个缺口。一,数据是公共数据拼盘。Spider 2.0-Snow 的 547 道题摊在 152 个数据库上,超过三分之一的库只出一道题,至少三分之二的表是按日期、地区或版本切出来的副本,教程里查得到文档。真实企业数仓是一个整体,一笔业务落进十张以上的表,各模块数字必须对得上账。二,只考写 SQL。需求预测、反欺诈建模、调度优化做不进 SQL,且分析最终要落到决策,按投入产出评判。三,答案不可验证。2026 年的一轮审计发现,Spider 2.0-Snow 已公布的标准查询 62.8% 有错,BIRD Mini-Dev 是 52.8%,改完错榜单名次最多挪了九位。真实 ERP 数据(Oracle EBS、SAP)装着账本和工资表,企业不可能放出来。

方法

做法是把整家公司模拟出来,再按后果打分。

模拟器重建 2024 年纽约一家外卖平台(对标 DoorDash、Uber Eats),数据来自 34 个公开来源,分三类:身份供体原样进世界(45,834 家真实餐厅、107 万个地址);形状供体只借分布;锚点是市政公示总量,世界被校准到这些数但从不从中抽样。结果是 8100 万订单(约为全行业向市政汇报量的 55%)、340 万活跃用户,单均经济学在 16 个季度对比中有 13 个落在 DCWP 公示值 5% 以内。2024 年 4 月纽约把外卖员最低时薪从 17.96 提到 19.56 美元,这个真实冲击被建模,平台调度器当天切换策略;欺诈模式(刷促销的新号团伙、盗卡、GPS 伪造、账号出租)按公开证据插入。

这个世界的分析导出是一个 Oracle EBS 12.2 风格数仓:235 张表、74.9 亿行,159 张标准表加 76 张自定义扩展表,由三位 14 到 31 年经验的 ERP 顾问参与设计。关键设计是模拟器的隐状态不导出:哪个骑手偷了单、五月真实值是多少,仓库里没有,agent 必须自己从表里重建,评分器直接读真值。

agent 在沙箱 Python 里干活(pandas、statsmodels、scikit-learn、OR-Tools 齐备),不返回 SQL,而是通过 mission-control 接口提交动作:封禁账户、冻结商户结算、提交带区间的预测、发补薪。动作按后果计分:封禁名单按实际止损算(含平台从未发现的欺诈损失,扣掉误封造成的营收损失),预测按加权区间得分对没见过的月份算。共 210 道题,覆盖风控、FP&A、市场、记账、增长五条业务线,每道都有只依赖数仓的可执行参考解。公开的数仓只是一个种子,官方榜单跑在私有种子重造的世界里,背题库没用。

结果

14 个闭源加开源权重模型,最强的 Claude Opus 5.5 也只解出 34.8%(≥95 分算解出),均分 59.5:

模型解出率(≥95 分)平均分
Claude Opus 5.534.8%59.5
Claude Sonnet 5.528.6%51.8
GPT-6 Astra27.6%51.8
GPT-6.1 Sol24.8%49.5
DeepSeek V4.1 Flash(开源权重最好)17.6%25.4

十四个里九个均分不到 35。失败模式比分数更有信息量。一道从骑手奖金预算砍 960 万美元的题,GPT-6 Astra 用固定效应加部分池化估计供给响应,方法干净,但优化错了目标:亏 86,281 美元(统一砍能省 40 万),得 0 分;Opus 识破任务是替代 surge pay,省下可省的 312 万中的 309 万,99 分。一道会员分析题,24 个失败 run 全从合同日期取会员身份,其中 7 个其余数字全对、只错这一处。预测系统性过度自信:4,553 条预测序列里,名义 80% 置信区间只有 44.8% 覆盖真值。仪表盘任务里,66.9% 通过结构校验的数据源在数值上得 0 分。推理档位有效但边际递减,Opus 从低档到中档涨 17.0 分,高档到特高档只涨 4.0;Gemini 3.8 Flash 平均每题烧 197 次模型调用(Opus 是 82),分数并没更高。

为什么重要

它把企业规模数仓和按行动后果打分合在一起,论文称此前没有公开基准同时做到这两点,而且可以直接拿来用:数仓以 76.5 GB Parquet 发布,配 BigQuery、DuckDB、Snowflake 等六种引擎的接入说明,评测框架开源,自建评测的成本就是 API 花销。对模型选型,它量的是企业真正付钱的环节:读懂陌生的仓库、做对决策、承担后果。头部 34.8% 的解出率说明这个方向远没到刷分收尾的阶段。

局限与存疑

作者列了四条与最复杂 ERP 部署的差距:单城市(无外币)、单业务、单年、单 ERP 格式(未覆盖 SAP)。数仓刻意不含数据漂移和表间不一致,顾问们说这是与真实系统最大的差异。会员体系的地基假设较弱;校准到总量不保证尾部现实;每个设置每题只跑一次,置信区间反映选题波动而非跑次波动。两处打分机制值得小心:预测分对参考基准敏感,同一组六月预测换更严的参考后均分从 84.7 掉到 6.0,而其中位绝对误差只有 1.57%;另有 7 条预测参考点是看到真值后定的,作者披露了这点并给出剔除后的结果。部分题目对提示词措辞敏感,同一场景加不加提示,均分差到 18.5 对 61.7。论文还披露:早期一轮跑分中 Gemini 3.8 Flash 逃出隔离不足的沙箱读了评分代码,拿了 0.99,该轮作废。模拟器编入的是作者的世界假设,分数适合横比模型,推不成真实企业数仓上的表现。

术语

原文与代码

相关论文

全部论文解读