91% 对 45%：企业数据 Agent 的差距藏在 notebook 注释里

Databricks CEO Ali Ghodsi 在推文里说，他比一年前强 10 倍，整个公司跑在 Genie 上。理由落在 Agentic Ontology：它持续为公司整理和演化上下文，让 agent 质量更高，成本明显下降。

这句话容易被当成 CEO 的场面话。Databricks 随后放出的 benchmark 更像证据。博客作者 Jeff Fletcher 和 Rishabh Singh 写了一个新企业数据 Agent 评测，和 Turing 合作，把 Genie 与两个前沿 Agent 放在同一个实时 Databricks workspace 里比较。

评测用的是一家虚构公司 Calderwick Energy，英国电力和燃气供应商。它有数百张表，最大一张约 1.2 亿行半小时电表数据。表上面还堆着不同团队留下的 notebook、定时任务、dashboard、保存的 SQL、代码、指标、文档和 Genie Agents。也有真实环境里的脏东西：复制的 notebook、废弃分析、旧文档、开发副本、冻结的报表和几个月没人碰的 dashboard。

Genie Ontology 是企业上下文层。它自动从这些资产里抽取业务知识，整理成每个 agent 都能用的共享理解。可以看这个 Ontology manager 的演示：

结果很直接。

Genie 通过率 91%，Agent A 45%，Agent B 58%。Genie 用的 token 不到它们一半，速度快 3 到 4 倍。

博客里给了一个很具体的例子。任务是找 Calderwick Energy 历史上 Commercial planning rate。表 bill cost stack 有个字段 cfd_rate_p，FY24/25 的行里写着 0.31 pence per kWh。看起来查表就能答。

但造这张表的 notebook 里还有一条信息：Commercial 每年设定 planning rate，这个 mart 用的是 FY25/26 假设，包括把假设应用到更早的账期。另一段 Planning rates by year 保留历史：FY24/25 是 0.52 p/kWh，FY25/26 是 0.31 p/kWh，FY26/27 草案是 0.45 p/kWh。

问题问的是 Commercial 团队在 FY24/25 设定的 planning rate。表里那个 0.31 已经被 FY25/26 假设覆盖。表里只有一个被覆盖后的数字，真正的答案在造表那个 notebook 的注释和历史表里。

Genie Ontology 找到了包含历史费率的片段，并把它链接到源 notebook 45_mart_bill_cost_stack。Genie 检查 notebook 后，第一次回答就返回 0.52 p/kWh。5 次运行，第一次答案都是 0.52。其他 agent 没拿到这个历史费率：一个一直返回 0.31，另一个返回 0.31 或质疑有没有按年份记录的 planning rate。

这个例子的价值不在数字本身。它说明企业数据问题经常卡在业务定义：收入怎么算，活跃客户指什么，某个费率在哪年设定，报表里的数被哪条假设覆盖过。模型再强，没读到 notebook 里那句话也会答错。

有网友 John Rood 指出，token 减半这个数字更有意思。Ontology 是共享意义编译一次，agent 不用每次运行都重新推导这家公司里的 revenue 或 active customer 是什么意思，歧义消除的循环消失了，成本下降是因为工作在请求之前已经发生。

也有网友 0xlukewae 说，ontology 是 moat，模型是租的。这个判断有点狠，但方向清楚：前沿模型能力在商品化，每个新模型发布都在刷榜，企业 agent 的差异越来越落在 harness 和它能检索到的上下文上。

治理问题也跟着来。有网友问，这些 snippet 是谁点的 Promote，人还是 Genie 自己？另一个网友 Max Petrusenko 说，ontology 的好坏取决于它的删除队列，过期条目的成本比缺失条目更高。这两个问题都不是模型参数能解决的。

博客也写了限制：这个 benchmark 测的是已经在 Databricks 部署里积累了大量 workspace 知识的环境。新部署还没攒下知识，或者问题能直接从表和 schema 回答时，agent 之间的差距会小一些。这也解释了为什么一些只看表的数据 agent benchmark 差距不大。

Genie Ontology 的活，大部分在问题发生之前。