Databricks 宣布 Genie Ontology 正式可用

Databricks：Blog·2026-11-11 23:00· 1 小时前AI 评分53

宣布 Genie Ontology 正式可用

AI 导读

Databricks 宣布 Genie Ontology 正式可用（GA），该本体由 Agent 从仪表板、SQL 查询、notebook 和 Power BI 等语义模型中自动学习业务上下文，人工通过 Unity Catalog 治理关键定义，并经 OntoRank 按权威度排序供给 Agent。

正文 · 原文

AI Agent 的实用价值取决于它对自身所处业务的理解程度。在特定领域内，团队可以手工整理这种理解。如今已有数千家客户以这种方式在生产环境中运行 Genie Agents，包括 7-Eleven、Virgin Atlantic 和 General Motors。然而，企业不再为单一领域部署单个 Agent。它们正在每个职能中部署众多 Agent，而每个 Agent 都需要对业务运作方式拥有一致、准确且完整的理解。

Agent 所需的企业上下文远超任何团队能够手工记录或建模的范围。它存在于数千个生产仪表板、SQL 查询、notebook 和 BI 语义模型背后的逻辑中，也存在于团队记录定义、维护“谁负责什么”工作知识的文档和应用中。它还会随着产品发布、营销活动开展和团队重组而每周变化。

这正是本体在企业中历来举步维艰的原因。本体由专家构建、手工维护，只覆盖了业务的狭窄切片，并随着业务演进迅速过时。Agent 改变了这一问题的两个方面。它们如今是企业上下文的主要消费者，也能通过从团队已有的工作中学习来生产上下文。由此产生了一种新型的 Agent 本体：由 Agent 构建、供 Agent 使用，并由了解业务的人治理。

我们相信，每个组织都将需要一个统一的 Agent 本体，连接其所有数据，持续从业务运作中学习，并为每个 Agent 提供同样受治理的理解，无论该 Agent 运行在 Databricks 还是其他地方。逐个 Agent 地构建上下文会产生彼此分离且不完整的业务视图，而这些视图不可避免地会相互冲突。因此，企业本体应当成为共享基础设施，由 IT 和数据负责人像拥有其底层数据平台一样拥有它。

在 Data + AI Summit 上，我们推出了 Genie Ontology作为这一层。今天，我们宣布其正式可用（General Availability），并新增了供 Agent 学习的来源，以及供人员策展和治理其学习内容的新工具。我们还分享了与 Turing 共同开发的基准测试结果，展示 Agent 借助它工作时准确率能提升多少。

是什么让 Genie Ontology 成为 Agent 本体？

Genie Ontology 之所以是 Agent 本体，是因为 Agent 持续构建其知识供其他 Agent 使用，同时由人员治理需要精确性的业务定义。它结合了学习到的知识和建模的知识，按权威度排序，并在尊重现有用户权限的前提下，将最可信的上下文交付给 Agent。

由 Agent 构建

Genie Ontology 的大部分 知识是自动学习得到的，来源于反映组织运作方式的系统和工件。智能体从团队已经在使用的资产中提取业务上下文，包括 Databricks 仪表板、SQL 查询、notebook，以及 Power BI 等工具中的语义模型。这些知识被捕获为 Ontology Snippets，即可复用的业务上下文片段，例如计算逻辑、业务规则和数据关系，并随着底层来源的演进而持续更新。通过直接从日常工作中学习，Genie Ontology 会随着时间推移变得更有用，并捕获那些手动建模和维护不切实际的、团队特有的长尾知识。

由人治理

学习到的知识由建模知识补充，后者是团队显式定义并通过 Unity Catalog 语义进行治理的业务含义。这包括保存已认证 KPI 的 Metric Views、按业务领域组织知识的 Domains，以及记录业务概念权威定义的 Pages。组织对必须精确的相对少量定义（例如确认收入或 ARR）进行建模，Genie Ontology 会在这些定义适用的任何地方将其视为事实来源。

被每个智能体使用

当智能体提出问题时，Genie Ontology 的权威感知排序算法 OntoRank 会评估学习到的知识和建模知识，以识别最可信的上下文。它会权衡来源权威性、认证情况、知识背后人员的专业性和相关性、流行度以及时效性等信号，以解决定义冲突，并为每个用户和问题选择最佳上下文。随后，Genie Ontology 将该上下文直接交付给智能体，智能体可以立即基于正确的定义进行推理，而不必花费时间和 token 对数据进行开放式探索。

通过 Genie MCP，同样的上下文可供 Databricks 之外的智能体使用，例如 ChatGPT、Claude 和 Microsoft Copilot，因此团队已经在使用的智能体会更了解业务，而无需重建。

智能体式本体的影响

对智能体式本体最清晰的检验，是使用它的智能体是否优于那些必须自行寻找上下文的智能体。现有的数据智能体基准主要关注表，前沿智能体目前在这些基准上的得分相近，尽管真实的企业问题往往依赖于分散在 notebook、仪表板和文档中的业务上下文。为了更好地近似真实世界，我们与 Turing 合作构建了一个新基准，模拟一家虚构的英国能源供应商的实时、真实的 Databricks 工作区。它将由 Genie Ontology 驱动的 Genie 与两个领先的前沿智能体（标记为 Agent A 和 Agent B）进行比较。每个智能体对每个任务相同的问题回答五次，每个答案都根据运行开始前定义的评分标准进行评分。

Genie 在 91% 的运行中正确作答，是更强前沿智能体正确率的 1.6 倍，同时使用的 token 不到其一半，完成速度快三到四倍。由于三个智能体都能很好地编写 SQL，差异来自上下文。Genie 借助 Ontology 已从工作区中学到的知识，直接找到每个问题所需的业务规则，而前沿智能体每次运行都必须重新发现这些知识，并经常返回不符合这些规则的答案。这些结果反映的是一个已建立的部署环境，团队在其中已积累了这些知识， 基准研究博客介绍了方法论和任务演练。你的客户团队可以帮助你在自己的工作区中运行同样的评估。

将 Genie 连接到你的所有数据。

智能体式本体只能从其智能体能够访问的数据中学习，因此面向整个企业的上下文层依赖于连接到多种多样的数据源。结构化数据要么通过 Lakeflow Connect 进入 Unity Catalog，要么就地联合，因此 Genie 可以直接从实时运营数据中计算答案。然而，企业所知道的很多信息都存在于湖仓之外的文档、工单和 wiki 中，团队在这些地方记录决策并解释事物如何运作。通过本次发布，我们大幅扩展了本体所连接的系统。

Genie Search

Genie Search 现已正式发布，让人们和智能体能够在他们已有的权限范围内，查找并使用文档、工单和 wiki 中的企业知识，以及受治理的 Databricks 资产。用户可以在企业中的任何位置查找文档，或一次性提出跨越多个文档的问题。Genie 会在他们已使用的仪表板、表和 Genie Agents 旁边返回经过综合并带有引用的答案。由于索引内容也会为 OntoRank 提供信息，这些文档和工单中的知识会成为 Genie Ontology 在决定信任哪些来源时权衡的证据的一部分。

要 配置 Genie Search，管理员需通过管理控制台连接每个来源并启用索引。 

随后，Genie 可以在一次遍历中搜索整个索引，而不是分别查询每个来源，从而使答案更完整，并让智能体以更少的工具调用和 token 找到正确的信息。对于实时工作，例如检查 Jira 工单状态或创建新工单，Genie Search 会与 MCP 连接器协同工作。Genie 会为每项任务决定在多大程度上依赖索引、MCP 或 SQL。Genie Search 目前支持 Google Drive、Jira、Confluence 和 Workday，SharePoint 处于 Beta 阶段，更多连接器即将推出。

重建并维护源权限是企业搜索部署中最困难的环节之一。Genie Search 通过 Unity Catalog 连接，在摄取每个源内容的同时一并摄取其访问控制，并在返回任何结果之前强制执行这些控制，因此用户和智能体只能看到他们在原始应用中本就能打开的内容。由于 Genie Search 作为 Databricks 上的托管服务运行，组织无需维护单独的权限模型，也无需采购单独的搜索基础设施。Genie Search 现已在 Genie 中提供，并可用于 Discover 页面上的资产搜索。

为智能体提供更多可学习的内容

学习到的知识是 Genie Ontology 中占比最大的部分，通过此次发布，它从工作区扩展到外部 BI 工具，以及决定谁的知识对每个人最相关的组织关系。

Ontology Snippets

Ontology Snippets 现已正式可用，是构成 Genie Ontology 学习知识的单元。Genie 会基于人们已在使用的仪表板、SQL 查询和笔记本自动且持续地构建它们，并随着这些工作的变化而刷新，因此 Ontology 无需任何人手动维护即可跟上业务变化。每个 snippet 始终与其来源资产保持关联，并继承该资产的权限，这意味着 Genie 仅使用用户已被允许查看的上下文。当 Genie 引用某个 snippet 时，用户可以看到该定义的来源、作者以及它为何可信。

外部知识源

组织的许多业务逻辑已经存在于 Power BI、Tableau 和 Sigma 等 BI 工具的语义模型中，为每个 AI 计划重建这些逻辑会造成重复工作并导致上下文漂移。外部知识源（现处于 Beta 阶段）通过连接外部 BI 平台，识别语义模型、度量值、计算列和关系，并据此生成 Ontology Snippets，从而将这些逻辑引入 Genie Ontology。目前支持 Power BI。Tableau 和 Sigma 支持即将推出，血缘支持也将随后提供。要开始使用，请查阅 产品文档。

组织目录

业务知识只是全貌的一半。要使其发挥作用，智能体还需要了解知识背后的人，以及他们与提问者之间的关系。 组织目录，现已正式可用，将这一上下文引入 Genie Ontology。它们从 Workday 开始，导入人员、团队和汇报关系，并通过 Genie 中的人员浏览器使其可访问。

Genie Ontology 将这些正式的组织关系与活动信号相结合，后者揭示谁通过其创建、共享和使用的资产真正在一起工作。OntoRank 利用两者，对来自团队成员和密切协作者的知识赋予更高权重，帮助智能体提供对每个用户更相关的答案。

治理智能体所学的内容

Genie Ontology 通过使用不断学习和改进，但智能体回答的质量仍取决于其所依赖知识的准确性。因此，组织需要能够审查、完善和治理其本体。Databricks 在治理底层数据的同一平台内提供这些能力，确保智能体基于可信的业务上下文运行。

治理建立在组织已在 Databricks 中使用的控制措施之上。 Unity Catalog 治理底层知识，管理权限、血缘和定义，确保用户和智能体只能访问其被授权查看的内容。 Unity Gateway 治理智能体与该知识的交互方式，控制连接、使用限制、防护措施和审计。随着 Genie Ontology 扩展到更多智能体和系统，二者共同提供一致的治理，而无需引入单独的控制平面。

Unity Catalog 域和子域

域和子域，现已正式可用，为 Genie Ontology 提供组织结构。它们按业务用途对数据和 AI 资产进行分组，因此当同一术语对不同团队意味着不同内容时，Genie 可以根据其关联的域应用最符合问题的定义。域还使人们能够根据其业务组织方式，在 发现页面上浏览和查找数据。策展和管理可以下放到域或子域级别，因此财务和营销部门可以各自维护自己的定义和资产，而无需依赖中央团队。

“让数据更易于发现和理解，是我们提升整个航空公司分析能力的重要一环。Databricks Domains 为我们提供了一种更清晰、更直观的数据组织方式，帮助我们的团队更有信心地应对日益复杂的数据环境。”- Tom Barber，Virgin Atlantic 商业智能与高级分析负责人

“域和子域让业务用户能够轻松找到并获取其业务角色所需的数据资产。”- Michael Poremba，McAfee 数据架构高级经理

Unity Catalog Pages

Unity Catalog Pages，现已正式可用，为 Genie Ontology 提供权威定义。每个 Page 都是对业务术语、实体或缩写的受治理解释，具有指定的负责人，并归属于某个域或子域。当问题涉及已定义的概念时，Genie 会将 Page 视为事实来源，优先于学习到的上下文，并引用它以便用户验证答案。

智能体既可以帮助创建 Pages，也可以使用它们。团队可以使用 Genie Code 中的“批量导入 Pages”提示，从 Confluence、Slack、Google Docs 和 GitHub 等 MCP 连接工具起草 Pages，或使用公共 API 与现有知识平台同步。Pages 直接链接到 Unity Catalog 资产、仪表板和其他 Pages，并且每个 Page 都始终由其指定负责人控制。

“以前在上一份工作中需要两周才能完成的事情，现在五分钟就能完成。借助 Unity Catalog Pages，Genie 能够理解 Agrifirm 如何定义活跃客户和非活跃客户，并计算不活跃时间窗口，从而使复杂的历史分析更快、更透明。通过展示数字背后的方法，Genie 帮助我们从一开始就建立对其答案的信任。”- Henri van Dijk，Agrifirm 数据治理与质量保证官

“借助 Unity Catalog Pages，我们可以为 Genie Agents 提供可信的业务知识来源，这些知识按 Ontology 优先排序，从而对非常具体的问题给出好得多的答案。而且，由于我们使用 Pages 来定义行业术语和缩写，每个 agent 的指令可以精简得多，从而带来更好的工作记忆——并且再次——更好的答案。”- Ian Smith，Waste Connections Databricks 平台经理

Ontology Manager

随着 agent 不断向 Ontology 添加内容，负责它的人需要一种方式来查看它知道什么、找出它的不足之处，并策管最重要的知识。即将推出 Beta 版的 Ontology Manager 将是用于这项工作的首个可视化界面。数据管理员和上下文工程师将评估 Ontology 的整体健康状况，识别最重大的缺口，设置顶层领域结构并配置外部知识源。领域专家将组织和策管其业务领域内的知识，业务用户将能够在其现有权限范围内查看 Genie 所依据的上下文。

Ontology Manager 还将呈现高影响力的机会，例如覆盖薄弱的领域或缺乏受治理定义的高频提问概念，管理员将能够直接从审核队列中将 agent 学到的内容提升为权威 Pages。交互式图谱将让用户探索 Genie Ontology 中的实体和关系并创建新知识，而分层视图将支持特定领域内的日常策管。要了解有关 Ontology Manager 的更多信息，请观看产品演示。

客户评价

“我们看重 Genie Ontology 让答案背后的上下文更加透明和可检查；引用让人们能够将答案追溯到底层来源和业务定义，这有助于建立信任并改善我们利益相关者的体验。”- Jehan Saga，Superhuman 数据工程经理

“Genie Ontology 正是我们在不丢失使其有用的业务上下文的情况下扩展 AI 所需要的。它是我们数据团队的效力倍增器。”- Noah Cepela，Mode Global 分析与洞察高级副总裁

“Databricks Ontology 配合 Genie Code 对我们来说是颠覆性的。我们用它来构建仪表盘、应用、AI 智能体等。过去需要数天才能创建的 Power BI 报表，现在借助 Genie Code 数小时即可完成，我们的分析师对此体验非常兴奋，已经在考虑将更多报表迁移到 Databricks Dashboards。其影响远不止于报表：过去主要使用 Excel 和 SQL 的分析师，现在正使用 Genie Code 构建支持我们运营团队的 Databricks Apps。通过将这种能力直接交到分析师手中，我们能够更快地交付解决方案，每月为运营团队节省超过 1000 个工时。”- Kyle Burke，BHG Financial 数据平台副总裁

“业务语义使我们的 Genie 体验在 Genie、Agent 和 Code 中更加准确且具备上下文感知能力。我们不再通过技能和指令将业务知识嵌入单个智能体，而是可以一次性建立业务知识，并使其跨解决方案和领域可用。”- Kristoffer Absalonsen，Odfjell Technology 企业架构师

“在 Zepto，我们希望 AI 理解我们的业务如何运作，而不仅仅是它处理的数据。Genie Ontology 通过将业务定义和上下文结合在一起，帮助我们实现这一点。例如，订单履约时间、配送 TAT 和满足率等指标，只有在正确的业务上下文中被理解才有意义。这有助于 AI 超越报表指标，进而解读指标，将业务数据转化为可执行的洞察。”- Deepak Siroya，Zepto 分析副总裁

如何开始

Genie Ontology 现已正式可用。组织可以从已有的上下文开始，在 Unity Catalog 中治理最重要的定义，并让 Genie Ontology 从团队每天的工作中学习其余内容。了解更多：

• 欢迎参加由 Ali Ghodsi 和 Greg Brockman 带来的Data + AI Live：上下文只是开始活动
• 探索 Genie Ontology 产品页面
• 阅读 Genie Ontology 文档
• 下载电子书Operationalizing the Enterprise Context Layer
• 观看新的 Genie Ontology Manager 演示视频

这是我们在Week of Genie期间发布的众多公告之一。在接下来的几天里，我们将分享 Genie、Genie Agents 和 Genie MCP 的新内容，它们都构建在此处介绍的智能体本体之上。

我们迫不及待想看到 Genie Ontology 如何帮助你在整个企业中部署可靠的 AI 智能体。

来源：Databricks：Blog · databricks.com