Databricks 发布企业数据智能体基准，Genie 搭配 Genie Ontology 准确率 91% 且 token 用量减半

我们与 Turing 合作开发了一项新的企业数据智能体基准测试，在实时 Databricks 工作区中针对业务问题，将 Genie 与两个主要前沿智能体及其各自的 harness 进行比较。该评估衡量答案准确性、token 用量和完成任务所需时间。Genie 的通过率为 91%，而其他前沿智能体分别为 45% 和 58%，同时 Genie 使用的 token 不到它们的一半。

以往的数据智能体基准测试通常只包含表，而该基准测试还包含 notebook、仪表板、已保存的 SQL 查询、文档和其他分析资产，这些资产承载了企业知识、业务定义和计算规则。这些资产提供了仅靠表模式无法建立的关键企业上下文。Genie Ontology 是企业上下文层，让每个 AI 智能体对业务形成共同理解。它会自动提取并组织这些知识，在 Genie 回答问题时呈现相关上下文供其使用。

我们此前对 Genie 的评估使用了专有数据集。该基准测试使用为共享而设计的任务和支持性分析资产来评估 Genie，因此其他人也可以运行该评估。

正确回答业务问题需要获取关于组织如何解读和使用其数据的机构知识。团队通过日常分析工作积累这些知识：确立收入定义、维护反映当前报告规则的仪表板，以及编写处理业务特定异常的查询。该基准测试中的问题要求智能体访问并推理这些知识，以正确执行任务。

为什么需要新的基准测试

现有的数据智能体基准测试已经很多，但没有一个真正模拟真实世界的使用情况。我们需要一个基准测试来检验智能体发现并使用分布在 notebook、仪表板、已保存的 SQL 查询和其他文档中的业务知识的能力。

现有的数据智能体基准测试大多聚焦于一组表及构建这些表的管道代码，各智能体在这些基准测试上的表现相近。在真实的企业任务中，正确答案很少仅来自表。它需要利用来自许多不同来源的信息，例如构建报告表的特定 notebook、团队仪表板背后的 SQL 或已保存的查询。该基准测试中的问题要求智能体推理这些资产中蕴含的知识，并将它们结合起来正确回答问题。

结果

针对该基准测试，我们开发了一家名为 Calderwick Energy 的虚构公司，这是一家英国电力和天然气供应商，其面临的挑战与许多典型数据团队非常相似。该公司有数百张表（最大的表约有 1.2 亿行半小时电表数据），以及不同团队在这些表之上构建的资产，例如 notebook、计划任务、仪表板、已保存的 SQL 查询、代码、指标、文档和 Genie Agents。它还具有真实场景的杂乱性，例如复制的 notebook、被放弃的分析、旧文档和开发副本、冻结的报告表以及数月无人触碰的仪表板。

我们创建了多个数据分析问题和查询作为基准任务，并在同一个实时 Databricks 工作区中对每个智能体针对每个任务运行了 5 次。

我们在三个主要指标上对这些 agent 进行比较：

1. 准确率（满足任务评分标准的响应百分比）
2. Token 用量（每次运行平均使用的 token 数）
3. 实际耗时（每次运行平均花费的时间）

下表展示了三个 agent 在该基准测试上的整体表现。Genie 正确解决了 91% 的任务，而前沿 Agent A 为 45%，前沿 Agent B 为 58%。此外，Genie 的速度显著更快（相比 Agent A 快 4 倍，相比 Agent B 快 3 倍），并且 token 效率高得多，因为它可以利用 Genie Ontology 更高效地识别和推理相关的企业上下文。

你可以在 GA 公告博客或官方文档中了解更多关于 Genie Ontology 工作原理的信息。

如果你想在自己的工作区复现此基准测试，请联系你的客户团队，他们可以帮助你进行设置，以协助实现此测试，并展示 Genie 在实时 Databricks 工作区中的表现。

评估方法

除 Genie 外，我们还评估了来自前沿 AI 实验室的两个领先编码/知识 agent：“Agent A”和“Agent B”。Genie 原生运行，而其他 agent 通过 Databricks toolbelt 连接。它们都收到了相同的问题。toolbelt 特意排除了 Genie MCP，因为那会使其他 agent 获得我们正在测试的所有 Genie 能力。

我们使用经过校准的评分标准检查每个 agent 是否回答正确，该标准涵盖了期望的答案和 agent 行为。在数字存在微小差异可接受的情况下，我们事先设定了这些限制。只有当答案满足评分标准中的必要检查时，才算通过。我们还记录了 agent 如何找到并使用回答问题所需的业务上下文。追踪记录显示了 Genie 检索了哪些片段以及 agent 选择运行的查询。除准确率外，我们还测量了每个 agent 的延迟和 token 用量。

从结果中我们观察到，Genie 的正确回答通过率显著优于两个前沿 agent，Agent A（+46%）和 Agent B（+33%）。它的速度也显著更快（3-4 倍），同时平均使用的 token 不到一半。我们现在对 Genie 如何高效正确地回答这些问题进行定性分析。

示例演示：找到正确的规划费率

以下是基准测试中的一个示例任务，要求 agent 识别 Calderwick Energy 的历史商业规划费率之一：

这看起来像是一个简单的查找。账单成本堆栈表中有一列名为 cfd_rate_p，FY24/25 的行包含 0.31 便士每千瓦时。agent 可以找到相关表格，筛选到请求的期间，并返回该数字。检查更多行会进一步印证答案：相同的费率出现在整个表格中。

改变答案的细节已经记录在构建账单成本堆栈的 notebook 中。

它解释了商业部门每年设定规划费率，并且该 mart 使用 FY25/26 假设，包括这些假设应用于较早账单期间的情况。一个单独的部分“按年份划分的规划费率”保留了历史记录：

问题问的是 Commercial 团队为 FY24/25 设定了哪个规划费率。目前应用于这些行的费率反映的是 FY25/26 的假设。该 notebook 已经记录了这种区别，并保留了回答该问题所需的历史费率。

Genie Ontology 找到了一个包含历史规划费率的片段，并将其链接到源 notebook，45_mart_bill_cost_stack。当我们运行该任务时，Genie 检查了 notebook 以确认费率，并在其首次响应中返回了 0.52 p/kWh。Ontology 面板同时显示了相关信息及其来源 notebook，使我们能够核对来源。

在 5 次 Genie 运行中，首次答案每次都是 0.52。其他 agent 在其运行中均未得到正确的历史费率。其中一个始终返回 0.31。另一个报告了 0.31，或质疑是否记录了特定年份的规划费率，或两者兼有。

要正确回答，需要理解表格中的费率代表什么，并找到 Commercial 团队记录的历史规划假设。Genie Ontology 将这些已有知识作为 Genie 响应的上下文提供。

成本与质量的权衡

前沿 agent 非常擅长基于书面文本完成大多数事情。为一项可以用计算机完成的任务输入文字，LLM 就会理解需求，然后制定并执行计划来完成该任务。每个新模型版本的发布都会逐步增加更多能力，前沿实验室似乎在各种基准测试中轮流占据第一名的位置。

这实际上使生成 token 的“智能”商品化，并将 agent 的力量和能力来源转移到 harness 及其能够检索的上下文中。这就是为什么该基准测试展示了上下文有多么重要，以及 Genie Ontology 如何针对为手头任务提供相关上下文进行优化。对于竞争 agent 而言，检索提取相关上下文所需的所有工件和元数据既耗时又昂贵，而且不一定能保证正确结果。这些基准测试结果为使用 Genie（包括 UI 和 MCP）以及 Genie Code 作为最可靠、最具成本效益的数据 agent 以及 AI 同事的入口提供了依据。

该基准测试旨在测试 Genie 和其他 agent 在已建立的 Databricks 部署中运行的情况，相关数据由 Unity Catalog 治理，业务知识记录在工作区资产中。Agent 需要发现并使用正确的上下文。在尚未有时间积累工作区知识的新部署中，或者当问题可以直接从表和 schema 回答时，agent 之间的差异可能较小。这解释了为什么其他现有的数据 agent 基准测试显示 agent 之间的差异较小。

了解更多

要了解更多信息，请联系您的客户团队以获取该基准测试的访问权限，他们可以帮助您进行设置，以展示 Genie 在繁忙的 Databricks 工作区中的工作方式。

Genie Ontology 现已正式发布。更多信息：

• 访问 Genie Ontology 产品页面
• 阅读产品文档
• 参加由 Ali Ghodsi 和 Greg Brockman 主讲的 Data + AI Live: Context is just the beginning 活动
• 下载电子书：Operationalizing the Enterprise Context Layer

这个基准测试只是我们 Genie 周活动的一部分，后续还会有更多关于 Genie、Genie Agents 和 Genie MCP 的消息，它们都由 Genie Ontology 的共享业务上下文驱动。

我们很高兴看到客户如何使用 Genie Ontology 在其组织中扩展可信 AI。