在数据栈中落地Genie Ontology：为AI代理构建共享业务上下文

超越语义模型：为AI代理构建共享业务上下文

大型语言模型知道如何推理，但它们不了解你的业务。为企业AI提供所需的业务上下文，不仅仅是将其连接到数据。代理还需要理解你的定义、关系、业务规则、权威来源和权限。Genie本体通过将建模的业务语义与从你团队已经使用的受治理表、查询、仪表板、笔记本和其他支持的资产中学到的上下文相结合，弥合了这一差距。Genie根据权威性和相关性对这些上下文进行排名，应用权限，并在回答时向Genie提供最有用的上下文。外部代理也可以通过MCP访问Genie的智能。

良好的语义模型提供了权威核心。语义模型捕获你精心定义的业务概念；本体则通过更广泛的关系、知识和上下文扩展该基础，这些是AI理解业务实际运作所需的。用Databricks的说法，Unity Catalog语义结合Metric Views、Pages和Domains来建立可信的业务定义。Genie本体随后通过纳入从现有资产推断的上下文来构建该建模核心，赋予代理比单独语义模型更广泛的业务理解。

关键是“建模头部，让Genie本体推断尾部”。Genie从第一天起从它能自动学习的内容开始，而精心策划则改善必须正确的关键定义和来源。

以下六层是随时间提高信任的渐进实践，并非Genie开始交付价值的前提条件。

让我们深入了解每一层。

第0层：为代理打好数据基础

在描述或建模任何内容之前，底层数据必须处于代理可以推理的形状。这一层是关于物理基础：干净的数据表、健全的模式，以及每个真实世界实体的一致身份。逻辑业务建模在第2层进行。这一层容易被跳过，但后期修复成本高昂，因为任何良好的元数据或语义建模都无法弥补破碎的物理基础。

打好数据基础意味着关注两个关键领域：

1. 围绕业务流程建模持久的黄金层。这包括识别具有清晰粒度和可重用、一致性维度的事实。星型模式或混合模式为你提供可靠的事实和维度基础，而无需将业务逻辑复制到每个下游表中。这并不意味着代理应该推理原始维度表。代理看到的界面可以更窄，而且通常应该更窄：一个Metric View或专门构建的视图，预连接一个领域的常见维度，仅暴露重要的字段，文档化粒度，并规范定义度量。你将在第2层构建这些。关键在于在健全模型之上刻意塑造消费表面，而不是将代理扔给数据转储。宽表不是问题。具有混合粒度、重复业务概念和没有规范度量定义的宽表是猜测的邀请。
2. 将实体解析为黄金记录。如果“客户”在销售中意味着活跃账户，在支持中意味着所有历史账户，代理将不知道信任哪个定义。如果同一客户在系统中具有三个不同ID，也可能被重复计数。跨来源对同一真实世界实体进行对账，使一个客户就是一个客户。

第1层：丰富元数据

元数据是描述性基础，帮助语义层和上下文提取理解数据。当表名为fct_rev_daily，列名为rev_amt时，代理必须猜测它们的含义。当同一张表带有“按产品每日确认收入，扣除退款”的描述，列注释为“以美元确认的收入”时，代理就有了真正可推理的依据。良好的描述是你所能做的回报最高、成本最低的投资之一，它们改善每个下游工具，而不仅仅是Genie。

以下是三个基本步骤。

1. 在Unity Catalog中添加表描述和列注释。为新分析师编写，他们不了解你的模式：说明数据代表什么、业务用途，并标记任何已知的注意事项。将精力集中在收益显著的地方，即仪表板和代理实际查询的精选、业务就绪表上。
2. 应用标签以分类和组织。描述提供叙述性含义；标签提供分类、发现和治理的结构化信号。使用它们捕获敏感性（PII、PHI、PCI）、所有权、业务功能和其他需要在整个数据资产中一致理解的属性。受治理的标签允许管理员定义批准的键和值集，以便分类保持一致，而不是团队间漂移。这些信号以后也可以用于访问策略和其他治理控制。
3. 在数量使手动工作不切实际时自动化第一轮。Databricks解决方案加速器dbxmetagen使用大型语言模型生成描述、检测和标记敏感数据，并提出分类建议。在人工审核和批准之前，不会向Unity Catalog写入任何内容，因此它加速工作而不是替代判断。

第2层：使用语义层建模业务

元数据解释单个表。语义层在上方定义业务逻辑，使最重要的指标在任何使用的地方含义相同。第0层建立了物理基础，本层创建逻辑模型：度量、关系、领域和术语。

以下是四个重要步骤：

1. 声明关系。代理连接表以回答问题，如果他们不得不猜测表如何连接，有时会猜错。在Unity Catalog中声明主键和外键告诉代理表之间的关系，因此它们能正确连接而不是凭空捏造路径。这些约束仅为信息性而非强制性的，因此您的治理流程必须保持其准确性，但声明它们是减少连接错误最直接的方法之一。关系与指标本身一样都是模型的一部分。
2. 使用度量视图构建语义模型。一个度量视图是一个Unity Catalog对象，它一次性地以受治理的代码定义您的度量（聚合数字，如总收入）和维度（切分方式，如区域或月份）。由于聚合在查询时解析而非预先固化，查询度量视图的使用者使用相同的受治理定义。这是提高准确性的最重要步骤之一，因为它消除了导致代理选择错误定义的歧义。首先将关键KPI定义为度量视图：这些绝对不能出错的数字，如收入、活跃客户和核心合规度量。
3. 向指标添加面向代理的元数据。度量视图可以携带显示名称和同义词，因此“销售”等自然语言会映射到正确的度量、货币和日期的格式模式以及示例查询。这些元数据流入Genie本体，因此您为建模度量所做的工作也使代理更容易找到并正确使用它。
4. 组织和文档化。Unity Catalog域和子域将资产分组为业务对齐的集合，使上下文保持范围。这提高了Genie的速度和准确性，因为它可以专注于相关业务领域内的资产，而不是搜索整个环境。Unity Catalog页面捕获业务用户和代理用于推理的共享业务术语、概念和定义。每个页面列出与该概念关联的权威资产，因此当本体从问题解析术语时，它已经知道要利用哪些表、度量视图和查询，而不是搜索环境并猜测。所有者审核保持这些定义的可信度，并且由于它们是人类断言和审核的，在本体必须解决冲突时，它们比推断的上下文更具权威性。

使用Genie Code自动化语义建模

当然，语义建模过程不必纯粹是手动工作。您可以使用Genie Code通过自然语言指令创建和维护度量视图。在Genie Code提示中，描述源表、连接、字段、度量和过滤器，它会生成YAML供您在保存前审核。您还可以使用Genie Code中的/importBI技能来导入Tableau或Power BI语义模型，它会构建一个度量视图，然后您将其提升到Unity Catalog以进行重用、治理、血缘和可发现性。

Genie Code还可以起草页面。在页面编辑器中，选择一个域，附加相关文件、链接、Unity Catalog资产或MCP连接的内容，Genie Code会起草结构化字段和富文本页面正文。审核草稿，添加适当的来源和相关资产，然后保存或发布。对于多个概念，使用批量导入页面。Genie Code从您的文档和来源中提取并去重建议的页面，标记冲突、重复和低置信度术语以供审核，并将批准的页面创建为草稿以供后续编辑和发布。

第3层：策展具有丰富上下文的资产

推断的本体部分从您的团队已经生成的资产中学习，如仪表板、笔记本、SQL查询、Genie代理和文档。您的数据环境越丰富、越可信，推断的上下文就越有用。第3层是关于使这些资产值得学习的。

以下是四个基本步骤：

1. 构建深度且广泛使用的资产基础。一个拥有许多文档完善、广泛使用的仪表板、查询和Genie代理的工作空间为本体提供了比稀疏的更多的学习材料。随着这些资产被使用和改进，可用于上下文提取的信号变得更加丰富。
2. 使您的资产上下文丰富。资产越丰富，本体从其学习的越多。当您用定义、示例和说明丰富Genie代理时，您不仅获得更高效的代理，还让Genie本体有更强的上下文在环境中提取和排名。对您的其他资产也这样做：使用Markdown单元格记录笔记本，带注释的保存SQL查询，以及带描述和注释的AI/BI仪表板。这些共同提供了Genie本体依赖的丰富的长尾业务知识。
3. 认证您信任的资产。认证将您的数据和AI资产（如度量视图、Genie代理或笔记本）标记为已验证和批准，并作为确定哪些来源是权威的强信号。认证和广泛使用的资产比未经审查的资产更具权威性，因此认证您信任的资产直接影响在冲突中哪个上下文占主导。弃用陈旧资产是另一面：将人员和代理从您不再支持的内容中引导开。
4. 对敏感数据进行分类并监控质量。数据分类识别并标记敏感数据，以便一致地治理，数据质量监控在漂移和异常影响依赖数据的人和代理之前捕获它们。两者都有助于确保喂养本体的资产可信。

第4层：构建治理层

治理使Genie的答案安全和可信。因为权限决定Genie本体可以检索什么上下文，两个人可以问相同的问题，并根据各自被授权看到的内容收到不同的答案。

让我们从三个具体领域来看治理：

1. 从Unity Catalog访问控制开始。Unity Catalog的权限模型是基础。它控制对目录、架构、表和其他工作区资产的访问，而Genie Ontology尊重这些权限。Genie只使用提问者被授权查看的内容，因此相同的问题可能因用户不同而产生不同的答案。通过组而非个人来管理访问，使得权限在扩展时更易于维护。
2. 在数据需要的地方添加细粒度控制。对于敏感数据，行级安全限制用户可以看到的行，列掩码掩盖敏感值。两者都在查询时强制执行。基于属性的访问控制允许你利用受治理的标签驱动这些保护，因此与敏感性标签关联的策略适用于该标签出现的所有地方，而不是逐表定义。这提供了一种可扩展的方式，在大型资产中一致地强制执行行级和列级保护。
3. 治理AI层。Unity AI Gateway为管理员提供了一个集中管理模型访问、速率限制、有效负载日志和AI工作负载成本控制的地方，以及对发送给模型的内容进行安全和敏感数据控制。它是治理代理行为及其使用增长时花费的控制点。

综合起来，这些控制决定了本体可以检索哪些上下文，以及哪些用户能接收它。未经授权的内容不参与检索，因此它不能间接影响答案。

第5层：评估和改进

前五层构建Genie回答问题所用的业务上下文。评估和改进层随着业务变化保持该上下文的准确性。指标被重新定义，表变得过时，新产品被引入。定期衡量答案质量有助于在过时或不正确的答案侵蚀用户信任之前，识别本体需要何时调整。

需要考虑四个关键领域：

1. 在推广前验证体验。从每个优先领域的一组代表性业务问题开始。为每个问题定义预期答案、权威来源和接受标准。然后在Genie One中测试这些问题，确保它们涉及用户将依赖的指标视图、页面、Genie代理、仪表板、查询和其他来源。Genie代理基准提供了一种内置方式来评估单个Genie代理随时间的变化。在聊天模式中，基准可以将结果与经过验证的SQL答案进行比较；在代理模式中，响应使用LLM评判器和可选的评估标准进行评估。对于Genie One以及更广泛的Genie本体，你的团队应定义并拥有问题集、基础事实、来源验证、人工审查流程和接受阈值。当答案失败时，追溯到其底层来源或上下文并修复根本原因。这可能意味着在指标视图中定义受治理的指标逻辑、在页面中澄清业务定义、改进Unity Catalog元数据、认证或弃用资产，或优化领域特定Genie代理的策展。
2. 监控答案、使用情况和来源质量。使用Genie本体所利用资产的监控能力。Genie代理监控器提供对单个代理问题、响应、反馈、标记响应和使用趋势的可见性。在Genie One中，来源引用帮助用户和管理员检查哪些本体来源促成了答案。查询历史、审计日志和计费系统表可以提供对SQL执行、事件和使用的额外可见性。
3. 当问题是业务定义或同义词时，使用页面。
4. 当问题是受治理的度量、维度、关系或计算时，使用指标视图。
5. 当问题出在来源资产时，使用Unity Catalog元数据、权限、认证或弃用。
6. 当问题特定于该代理的领域时，使用Genie代理的指令、示例SQL、SQL表达式、可信答案或知识库。Genie代理有几个内置功能来捕获并响应用户反馈，包括点赞和点踩、请求审查、生成SQL检查、添加为指令以及添加为基准。

注意资产间的漂移。漂移可能发生在许多地方：业务定义、KPI逻辑、表元数据、连接、仪表板、笔记本、管道、Genie代理指令和来源使用模式。为每个关键领域的资产建立所有者并设定审查节奏。在处理漂移时，利用你已构建的模型：用于权威概念的页面、用于受治理度量和维度的指标视图、用于组织和管理的领域，以及用于标记推荐或过时内容的认证或弃用。保持源表、视图、仪表板、笔记本和查询最新，因为它们都汇入推断上下文，并使用权限将实验性或退役内容与不应看到它们的人和代理隔离。对于Genie代理，在其数据、指令、示例或可信资产发生实质性更改后，重新运行其基准套件。

评估不是在启动前的一次性门禁；而是对所有促成答案的资产持续进行的习惯。Databricks为你提供受治理的语义资产、本体检索和引用、代理级评估和监控，以及系统表遥测。你带来基础事实、所有权、审查流程和定期维护，使Genie保持可信。

从一个领域开始，然后扩展

一个关键要点是，你不必一次构建全部六个层次。你不应该在上线前就试图覆盖整个业务。实际路径是直接开始使用Genie，然后选择一个高价值领域，有针对性地加强最重要的定义、数据源、治理和评估。这是一种“边学边扩展”的方法，而不是试图一蹴而就。

慎重选择第一个领域。从重复性高、摩擦大的工作流程开始，在这些流程中，团队已经花费时间手工核对数字，例如预测电话会议或规划周期。这些地方是可信答案价值最高的地方，也是你已经知道“正确”是什么样子的地方。在实践中，从小处着手：选择像销售这样的领域和像ARR这样的指标，然后加强头部。认证关键指标，定义重要术语，识别权威资产，管理访问权限，并评估重要问题。使用结果来指导下一个领域。

最后一点比听起来更重要。这些实践的目标不是追求技术完整性本身，而是信任：业务用户是否相信一个答案并据此行动。每一层都赢得一点信任，而评估循环使这种信任变得可见和可辩护，而不是主观意见。

随着推进，有两件事会相互促进。每个已解析的实体、已记录的资产、已认证的指标、术语表页面定义和受治理的数据集都加强了权威核心。每次交互都可能揭示反馈，团队利用这些反馈进行改进。结果是共享的业务理解越用越好，而不是逐渐衰退。

将Genie Ontology付诸实践不是建模的大工程。这是对数据模型、元数据、业务语义、企业上下文、治理和评估的稳定、分层的投资，一次一个领域交付，为AI提供对业务的真正理解。

了解更多

如果你想了解更多，请阅读Genie Ontology 公告博客 并访问 Genie One 和 Genie Agents 网页。另外，请查看 Unity Catalog Semantics 网页，深入了解Metric Views。我们才刚刚开始看到，当AI能够利用共享的、可信的业务理解时，可能实现什么。我们迫不及待地想看到客户如何使用Genie Ontology做出更快的决策，以更大的信心行动，并创造新的工作方式。