要点
- Databricks 与 Turing 围绕虚构的英国电力和天然气供应商 Calderwick Energy，构建了一个可分享的企业基准。其中有数百张表，最大的一张约有 1.2 亿行半小时电表数据，此外还有笔记本、仪表盘、已保存查询，以及过时的副本。
- 每个智能体在同一个真实的 Databricks 工作区里，对每道题运行 5 次。答案按事先设定的评分细则判定。
- Genie 的通过率为 91.0%，平均墙钟时间 100.3 秒，平均每次运行消耗 431,829 个 token。未具名的 Agent A 为 45.0%，耗时 434.6 秒，token 为 889,019。Agent B 为 58.0%，耗时 306.5 秒，token 为 1,051,070。
- Genie 带着 Genie Ontology 在原生环境中运行。其他智能体使用一套 Databricks 工具带，并被明确排除了 Genie MCP，因此拿不到正在被测试的那层上下文。
- 在一个工作实例中，表的一列把 FY24/25 显示为 0.31 便士/千瓦时，但笔记本记录的历史商务规划费率是 0.52。Genie 五次运行都返回了 0.52。其他智能体没有做到。
在 Week of Genie 期间，Databricks 与 Turing 合作发表了一篇基准测试博客，比较 Genie 加 Genie Ontology，与两个领先的前沿智能体，在真实 Databricks 工作区里回答业务问题的表现。标题数字很刺眼。Genie 通过了 91.0% 的任务，两家未具名对手为 45.0% 和 58.0%，耗时约只有对方的四分之一到三分之一，token 用量不到一半。这些数字不应当被读成一次干净的模型对模型结果。Genie 是在主场运行，并且带着为这个工作区准备的上下文层。其他智能体没有得到这一层。排行榜下面有一个更经得起看的要点：在杂乱的企业问题里，那张看起来像答案的表，有时并不是正确的对象，真正的数字藏在一个搜索必须知道如何找到的笔记本里。
[1]测试了什么
Databricks 认为，现有的数据智能体基准大多只提供一组表，有时再加上构建这些表的流水线代码，而且各家智能体在这类测试上的分数看起来差不多。它说，真正的业务问题要依赖存在于笔记本、仪表盘、已保存 SQL、文档和其他分析资产中的知识，其中也包括复制的笔记本、半途放弃的分析、冻结的报表，以及很久没人动过的仪表盘。
公司与 Turing 构建了一家虚构公司 Calderwick Energy，这是一家英国电力和天然气供应商，其杂乱程度意在接近典型数据团队的工作区。其中有数百张表，最大的一张约有 1.2 亿行半小时电表数据。上面还有笔记本、定时作业、仪表盘、已保存查询、代码、指标、文档和 Genie Agents。Databricks 称，此前对 Genie 加本体的评估使用的是专有数据集，而这一次的设计是为了让其他人也能运行。
每个智能体拿到相同的问题，并在同一个真实工作区里对每道题运行五次。评分使用经过校准的细则，可接受的数字误差事先设定。只有满足必要检查的回答才算通过。文章还记录了智能体如何找到并使用业务上下文。公布的总分是：Genie，通过率 91.0%，100.3 秒，431,829 个 token；Agent A，45.0%，434.6 秒，889,019 个 token；Agent B，58.0%，306.5 秒，1,051,070 个 token。博客标题把这写成 1.6 倍准确率、不到一半的 token，这与 91 除以 Agent B 的 58 相符，而不是与 Agent A 之间更大的差距。
[1]0.31 对 0.52 这个例子
这篇文章最有用的部分不是排行榜，而是一道关于历史商务规划费率的题。账单成本栈表里有一列 cfd_rate_p，FY24/25 的行里写着 0.31 便士/千瓦时。一个智能体只要找到这张表，按期间过滤，再读这一列，就会返回 0.31。再多看几行似乎还能印证，因为同一费率贯穿整张表。
构建这张集市表的笔记本说的是另一件事。商务部门每年设定规划费率。这张集市表使用的是 FY25/26 的假设，包括把这些假设应用到更早的计费期间。一节题为 Planning rates by year 的内容保留了历史：FY24/25 为 0.52 便士/千瓦时，FY25/26 为 0.31，FY26/27 草案为 0.45。题目问的是商务团队为 FY24/25 设定的费率。表里的数字，是后来的假设被反过来写进了更早的行。
Databricks 称，Genie Ontology 找出了一段包含历史费率的片段，并把它链接到源笔记本 45_mart_bill_cost_stack。Genie 的五次运行里，第一次回答每次都是 0.52。其他智能体没有得到这个历史费率。一个始终返回 0.31。另一个返回 0.31，或怀疑是否记载了分年度费率，或两者都有。
这个例子把论点缩成了一件小事。错误答案并不是通常意义上的幻觉，而是对错误对象的正确读取。一个能找到笔记本注释的系统，就有路径到达正确数字。一个擅长读表、却必须在工作区里四处搜寻才能发现这张表已经过时的系统，在这类问题上很容易被超过。
[1]这场对比是如何叠起来的
Genie 在原生环境中运行。其他智能体通过一套 Databricks 工具带接入。工具带被明确排除了 Genie MCP，也就是本来可以把 Genie 本身提供给这些智能体的接口。文章说，否则它们就会获得正在被测试的 Genie 能力。这是一个清楚的设计选择，也是最核心的保留条件。基准证明的是：一个拥有并维护着工作区知识本体的智能体，可以胜过必须通过更通用的工具带去发现这些知识的前沿智能体。它并不能证明，如果给这些前沿模型同样的本体，它们仍然会输。
对手没有具名。工作区是 Databricks 的。文章写明，获取这套基准要经过 Databricks 的客户团队来安排。作者自己也指出，在还没有积累多少工作区知识的新部署里，或者当问题可以直接从表和模式中回答时，智能体之间的差距可能会更小；这也是其他数据智能体基准分数更接近的原因。
这些限制并不会让那个例子变成假的。它们意味着，91% 这个数字是在主场得到的结果，而且规则把那层上下文从对手那里拿走了。
[1]一个公平的反对意见，以及在它之后仍然成立的要点
最有力的反对意见很简单。Databricks 构建了一项有利于自己在售产品的测试，然后用 1.6 倍准确率差距来宣传，对手却是匿名的，而且被拿走了正在测试的功能。厂商有权在自己的软件为之设计的环境里展示它。读者也有权不把这当成“企业智能体”的总排行。
在这个反对意见之后仍然成立的内容，还是值得写下来。机构知识常常并不在表里，而在表旁边的那条注释中，例如某一列已经被后来的规划假设覆盖。前沿模型已经很擅长遵循书面指令和编写查询。如果企业准确率的下一次提升，来自便宜而可靠地取到那条注释，那么稀缺的资产就是一份得到维护的业务地图，而不是模型原始分数的又一次跃升。这场不对等的基准，不是给冠军加冕的好办法。它倒是展示这种失败模式的一种合理方式。
[1]未来六个月该看什么
有用的下一步，是再跑一次：让每个智能体，包括那些未具名的前沿系统，都拿到同一份本体，或同一包导出的上下文，而且工作区并不只能通过销售团队获得。如果共享了上下文层之后，91% 对 58% 的差距缩小，那么教训关乎本体，而不是 Genie 作为独特推理器的地位。如果差距仍在，Databricks 就会得到比本周发布的更强的结果。在那之前，把 0.52 对 0.31 当作发现，把 91% 当作主场分数。
[1]