AI分析时代的语义层是什么？定义与实践
DataHot 速览
文章讨论在AI分析时代语义层的角色，作者原本认为语义层是任何AI分析工作的前提，但近期测试后观点有所松动。语义层是机器可读的业务含义所在，统一定义收入、活跃用户、客户等，让工具、人员和AI模型得到一致数字。它包含指标、维度和业务逻辑，Metabase中的segments和glossary可将规则转为保存过滤并以自然语言解释。AI提高了跳过语义层的代价，也降低了构建语义层的成本。
为什么值得关注：语义层是AI分析与Text-to-SQL准确性的关键基础设施，文章解释其定义演变及AI时代的实践方式，值得数据从业者关注。
译文
AI 逐段翻译如果你是一名用 AI 构建数据的人，你可能一直在质疑语义层的角色。你是构建一个全面的语义层来提供上下文？还是让模型自己构建上下文？我的立场一直是：语义层是任何 AI 分析工作的前提。但经过近期的测试，这一观点已经有所松动。
在我解释原因之前，我想退一步，为你定义在当今 AI 驱动的环境中什么是语义层，这个定义如何变化，以及它在实践中是什么样子。
基础
语义层是业务含义以机器可读形式存在的地方。
它将原始表转化为业务语言，一次性定义“收入”、“活跃用户”或“客户”，使每个工具、每个人和每个 AI 模型都拉取同一个数字。
这个理念已有三十年历史，但它的构建方式已经改变。
语义层过去需要由一个专业团队进行数月的前期建模。如今，定义可以从现有查询中起草，用通俗语言编写，并在数小时内修订。
AI 提高了跳过它的成本，降低了构建它的成本。
一个编写 SQL 的模型如果“收入”尚未定义，仍然必须猜测它的含义，但修正该定义很快，而且文档可以自动生成。
记住这一点：语义层是数据与业务之间的翻译层
它一次性定义指标、维度和业务逻辑，而不是在每个仪表板、电子表格和查询中重新实现它们。
在实践中，语义层包含三样东西：
- 指标：具有单一商定定义的计算，例如月度经常性收入或流失率
- 维度：你可以用来切分这些指标的方式，例如地区、套餐层级或注册月份
- 业务逻辑：底层的规则，例如哪些订单算作已退款，或哪些账户是内部测试账户。在 Metabase 中，分段将这些规则转化为保存的筛选器，而词汇表用通俗语言为人�� AI 解释它们。
指标层是一种更窄的版本，只包含指标定义。
新变化：语义层比过去更具可塑性
过去的大型前期项目正日益成为一种持续的、迭代的实践。
传统的构建方式深思熟虑且缓慢。一个中央数据团队采访利益相关者，在任何人提出问题之前就对指标建模，并控制每一次变更。批评者认为这造成了瓶颈：业务的发展速度快于语义层的更新速度（Ben Bausili），而且这个过程制造了新的守门人，而不是扩大访问（MotherDuck）。
三个转变改变了这一点：
- 定义可以被发现，而不仅仅是被设计。 AI 可以从查询历史和使用模式中推断出候选定义，然后由人进行审查和批准。
- 定义是为新的读者编写的。 消费者日益成为 AI 模型，而不仅仅是人或 BI 工具。一些作者现在称之为“上下文层”（Benn Stancil；George Xing）。
- 定义修订成本更低。 当定义发生变化时，更新它更接近于编辑文档，而不是重建模型。
尽管工作变得更轻松，但风险更高。
在 Futurum Group 对 818 位企业决策者的一项调查中（2026 年上半年，收入超过 1 亿美元的公司），约 59% 计划在未来 24 个月内增加或新采用语义层支出，其中准确性和幻觉风险是首要关注点（Futurum Group）。MIT CISR 发现，拥有完善数据治理实践的组织在数据和 AI 举措上成功的可能性是其他组织的 3 倍，但只有 21% 的组织如此评价自己的实践（MIT CISR）。在一项基准测试中，经过治理的语义层将 AI 准确率从 93% 提升到 100%（MotherDuck）。
以下将传统方法与当今语义层的样子进行了比较：
| 传统语义层 | AI 驱动环境中的语义层 | |
|---|---|---|
| 如何构建 | 在提出问题之前预先建模 | 从现有查询和使用情况中起草，然后审查 |
| 由谁维护 | 中央数据或 IT 团队 | 数据团队加上领域负责人，通常有 AI 辅助 |
| 主要读者 | 人和 BI 工具 | 人、BI 工具和 AI 模型 |
| 更新时间 | 通常数周到数月 | 通常数小时到数天 |
| 格式 | 专有建模语言 | 代码或通俗语言描述，受版本控制 |
| 范围 | 整个组织的一个通用模型 | 共享核心，同时为团队特定视图留出空间 |
实际示例：语义层在实践中是什么样子
大多数定义都很小、具体，而且出人意料地存在争议。
下面的每一行都是一个常见的业务术语、AI 助手可能收到的问题，以及在有和没有受治理定义的情况下会发生什么。
| 业务术语 | 提出的问题 | 没有定义 | 有定义 |
|---|---|---|---|
| 收入 | “上个季度的收入是多少？” | 模型选择一个表，可能包含退款、税费或测试账户 | 已支付发票，扣除退款，排除内部账户 |
| 活跃用户 | “我们有多少活跃用户？” | 模型可能统计登录数、任何事件或每个账户 | 在过去 30 天内至少运行过一次查询的用户 |
| 客户 | “有多少客户流失了？” | 模型可能统计个人用户或免费试用 | 在付费计划上的组织；流失意味着计划在 30 天内结束且未续订 |
| 地区 | “按地区显示收入” | 一个查询使用账单地址，另一个使用配送地址 | 账单国家，映射到四个销售区域 |
在传统模型中，每一项都需要一次会议来确定，并在一个冲刺中实现。如今，模型可以根据查询已经如何使用这些字段来提出定义，然后由人批准或编辑。如果你正在使用 AI 构建仪表板，我建议在未提供严格指标定义的情况下，要求输出业务逻辑。
好的一面是，如果你是刚组建新团队并需要快速获得洞察的人，Metabase 可以为你预先构建语义层，并将其全部加载到 Data Studio 中供你参考。更改定义就像让 Metabase 去做一样简单。
未解决的问题
定义语义层是容易的部分。决定要构建其中多少则不是。
市场上的每一个实现都是对这些问题的成套回答：
- 它应该预先构建，还是从使用中逐步发现？
- 它应该是一个通用的层，还是许多个与团队相匹配的小层？
- 定义应该是通用的，还是针对读取它们的特定 AI 模型进行调优？
- 它应该是独立的基础设施，还是捆绑在 BI 工具中？
- 仅仅给数据打标签就足够了吗，还是像 Customer 和 Order 这样的概念需要定义好的关系？
如果你正在为你的团队构建语义层，你的方法是什么？你是在一个拼凑起来的数据栈中刻意建模指标，还是用一体化工具来简化？中央语义层仍然至关重要，还是狭窄的、特定于模型的定义才是获得准确输出的更好选择？
如果你正在为自己的数据栈权衡这些取舍，探索将语义建模与分析整合到一个地方会是什么样子。
这篇内容对你有用吗？
反馈只用于改善内容筛选，不等同于收藏