Skip to main content
When-Metrics-Drift-Trust-Breaks-Why-Analytics-and-AI-Need-Consistent-Semantics

没有什么比两个仪表盘对同一个业务问题给出不同的答案更能迅速破坏人们对数据的信任了。

事情通常始于看似无害的环节。销售主管要求提供各地区的收入数据。财务部门给出的数据与销售运营部门给出的数据有所不同。商业智能团队可以解释其中的差异,但前提是必须先追溯筛选条件、连接方式、排除项、时间段以及每个团队对“收入”的定义。其实并没有人做错什么。每个团队都只是根据自身需求做出了合理的选择。

这就是问题所在。

许多组织已经改进了数据存储、集成、管理和访问方式。他们投资了云平台、数据仓库、数据湖、目录、商业智能工具,以及最近的人工智能助手。但一个棘手的问题依然存在:重要指标背后的业务逻辑往往分散在仪表板、SQL 查询、报告、电子表格和应用程序中。

只要这种逻辑仍然支离破碎,信任就仍然脆弱。

指标不仅仅是计算

人们很容易把指标想象成公式。收入等于单价乘以数量。利润等于收入减去成本。完成率等于已完成项目数除以总项目数。从理论上讲,这些听起来很简单。

在真实的商业环境中,这种情况很少发生。

指标通常包含一系列业务假设。哪些交易计入?退款是否包含在内?活跃客户的定义是什么?应该使用哪个日期:订单日期、发货日期、发票日期还是付款日期?指标的计算应该在客户级别、订单级别、账户级别还是区域级别进行?计算的每个部分分别使用哪些权威数据源?

这些决策至关重要,因为指标会影响人们对绩效的解读。它们会影响预测、预算决策、运营计划、激励薪酬、客户策略和高管报告。如果同一个指标在不同的地方代表不同的含义,组织就会花费更多时间来协调数据,而不是根据数据采取行动。

SQL几乎可以计算任何内容,但单靠SQL并不能解决治理问题。查询中嵌入的指标通常与特定的报表、粒度、连接路径和业务上下文相关联。如果将该逻辑复制到另一个仪表板,并针对新的用例进行修改,则指标的定义就会开始发生变化。

指标漂移是一个业务问题

当 KPI 的定义随着团队、工具和用例的变化而改变时,就会发生指标漂移。

乍看之下,这些差异似乎微不足道。一个仪表盘排除了已取消的订单,而另一个则包含了已取消的订单,但扣除了退款。一份报告根据账户状态计算客户流失率,而另一份报告则使用产品使用情况。一个团队按交易级别汇总利润,而另一个团队则使用预先计算好的利润率的平均值。

最终,人们会注意到这些数字不符。当他们注意到这一点时,讨论的焦点就从“我们应该怎么办?”转变为“哪个数字才是正确的?”

这种转变代价高昂。它会延缓决策,增加分析师的工作量,削弱用户对自助式分析的信心,迫使业务用户重新依赖电子表格或个人报告,这只会加剧问题。此外,它还会让数据和IT团队陷入尴尬境地,不得不不断地解释、辩护或重建原本应该标准化的逻辑。

随着组织机构扩大数据访问权限,这个问题变得愈发重要。自助式分析依赖于用户能够自信地探索数据。如果用户能够访问更多数据,却无法信任基于这些数据构建的指标的含义,那么自助式分析的普及应用将会停滞不前。

语义层需要包含度量指标

语义层弥合了复杂数据环境与业务语言之间的鸿沟。它为用户提供了一种更一致的方式来理解分布式系统中的数据、关系、术语和策略。

但业务意义并不仅仅局限于字段、表和关系,它还包括组织衡量绩效的方式。

现代语义层需要支持受控的指标定义。这意味着重要的KPI应该定义一次,并进行清晰的文档记录,集中管理,以便在BI工具、应用程序、数据产品和AI体验中重复使用。用户不应该每次提出新问题时都重新编写相同的逻辑。AI代理也不应该从原始数据表或不完整的上下文中推断出正确的计算方法。

这时,指标视图就显得尤为重要了。

指标视图使关键绩效指标 (KPI) 自然地融入到受管语义模型中。组织无需将指标逻辑隐藏在单独的仪表板或查询中,而是可以将指标定义为可重用的业务资产。一个指标可以包含已批准的公式、相关的数据关系、有效的维度、适当的筛选条件以及正确使用所需的上下文信息。

这改变了用户体验。用户无需从原始表和自定义 SQL 开始,而是可以从可信的业务指标入手,并选择所需的分析维度。

受监管的指标使自助服务更安全

自助式分析通常要求业务用户既要理解业务问题,又要掌握数据背后的技术复杂性。这并非总是现实的。

用户可能非常清楚自己想要问什么。他们可能想比较不同国家的收入,分析不同产品的退款率,或者了解各个细分市场的客户增长情况。但要正确回答这些问题,他们可能还需要知道要连接哪些表,应用哪些筛选条件,使用哪个日期字段,以及采用哪种聚合级别才合适。

如果将这种逻辑交给每个用户或每个仪表盘开发人员自行决定,那么出现不一致的情况几乎是不可避免的。

受监管的指标可以减轻这种负担。用户可以使用已批准的关键绩效指标 (KPI) 和有效维度,而无需重新构建其背后的逻辑。分析师可以加快工作速度,因为他们无需不断地重新计算常用指标。数据团队可以提高控制力,因为业务逻辑的管理更接近语义层,而不是分散在下游工具中。

其结果不仅仅是更清晰的报告,更是一种更高效的分析运营模式。团队可以减少对定义的争论,将更多精力投入到解读数据背后的意义。

人工智能提高了风险

在商业智能领域,指标的一致性一直都很重要。人工智能使这一点变得尤为紧迫。

随着企业将聊天机器人、副驾驶和人工智能代理引入分析工作流程,他们赋予软件更多责任来解读业务问题并生成答案。这固然强大,但前提是人工智能能够获取正确的上下文信息。

如果没有规范的语义,人工智能代理可能会生成看似合理的查询,但实际上可能使用了错误的连接路径、应用了错误的过滤器,或者以错误的粒度计算了指标。即使答案在技术上有效,但对于业务而言仍然是错误的。

这正是随着企业从人工智能实验走向生产,语义上下文变得越来越重要的原因之一。Denodo 的技术讲座“利用一致的语义为人工智能代理提供支持,并为业务用户提供支持”正是聚焦于这一挑战:如何通过统一的语义层连接复杂的数据生态系统和日常业务语言,从而更精准地服务于用户和人工智能代理。

对于人工智能而言,指标不一致不仅仅是报告问题,更会演变成推理问题。如果人工智能代理不了解“收入”、“活跃客户”或“试用成功率”在业务语境中的具体含义,它就只能靠猜测。而当人工智能对业务逻辑进行猜测时,信任度就会迅速下降。

从数据访问到业务背景

多年来,各组织一直致力于改善数据访问方式。这项工作仍然至关重要。但仅仅提供访问方式是不够的。

人和人工智能系统都需要上下文信息。他们需要理解数据的含义、数据与其他数据的关系、适用的规则、谁可以使用数据,以及企业如何定义指导决策的指标。

指标视图通过将业务指标纳入受控语义基础架构,支持了这种转变。它们有助于在仪表板、应用程序、数据产品和人工智能代理之间一致地重用关键绩效指标 (KPI)。它们还为数据团队提供了一种管理业务逻辑的实用方法,而无需每个团队都在各自的工具中重新构建业务逻辑。

这一点在分布式数据环境中尤为重要。大多数组织并非朝着将所有数据、逻辑和使用集中在一个地方的单一系统发展。它们跨云平台、数据仓库、数据湖、SaaS 应用、运营系统、BI 工具和 AI 框架运行。在这种环境下,一致性必须来自共享的业务上下文层,而不是寄希望于每个下游工具都以相同的方式实现相同的逻辑。

可信的决策需要可信的指标

分析的目标从来都不是生成更多的数据看板,而是帮助人们做出更好的决策。

人工智能也是如此。其目标并非生成更多答案,而是生成人们能够理解、信任和使用的答案。

这需要的不仅仅是数据访问,还需要一致的业务含义,需要对影响组织绩效衡量方式的指标进行规范的定义,并且这些定义必须在所有决策环境中可用,无论是在仪表盘、应用程序、数据产品还是人工智能驱动的体验中。

指标视图是朝着这个方向迈出的切实一步。通过将关键绩效指标 (KPI) 作为受控语义资产进行管理,组织可以减少指标偏差,提高对自助式分析的信任度,并为人工智能代理提供生成更可靠答案所需的上下文信息。

当每个人都用相同的方式衡量业务时,讨论的重点就会改变。团队花在争论数字上的时间会减少,而花在决定下一步行动上的时间会更多。

 

Kevin Bohan

Director of Product Marketing

免费下载

立即下载 Denodo 平台,探索、学习并构建受治理的数据访问方案。

免费下载