结论：语义层正在从 BI 配置变成 AI 公共底座
随着 AI Agent 开始读取企业数据，语义层的服务对象不再只是报表工具。问数、报告、预警、流程智能体都需要知道字段含义、表关系、指标公式、业务术语和权限范围。把这些知识分别写进每个提示词，会产生重复、漂移和无法追溯的问题，因此可复用、可版本化的语义层重新成为基础设施。
dbt Semantic Layer 的官方文档强调集中定义指标并通过接口复用；Databricks AI/BI Genie 要求在数据空间中配置可供自然语言使用的数据与指令。不同厂商实现方式并不相同，但共同方向是：模型之前需要一个稳定的数据和业务上下文层。
数据库结构为什么不足以支撑业务问题
数据库保存的是技术结构，不会自动说明“有效客户”是否排除测试账号、“销售额”按下单还是支付时间统计，也不会告诉模型 `cust_lvl` 的枚举含义。主外键可能没有显式约束，历史表与实时表也可能同时存在。模型看到更多表，反而可能增加错误连接和口径选择。
语义层要把技术对象转换为业务可用对象：表与字段描述、主键和关系、指标公式、默认时间、枚举值、同义词、过滤规则、负责人和生效版本。权限也应成为模型上下文的一部分，但最终授权必须由查询层执行，不能只靠提示词提醒。
为什么现在比传统 BI 时代更需要治理
传统 BI 通常由分析师在数据集和报表里预先选好字段，错误空间相对有限。AI Agent 会根据问题动态选择表、字段和分析路径，同一份语义可能被多个应用调用。只要一个指标定义过期，影响范围就可能从一张报表扩大到多种自动生成结果。
因此，语义变更需要像代码一样具备审查、测试、版本和回滚。指标应有样例查询和边界用例，关系要验证基数与重复，术语要测试同义问法，权限要用不同身份执行相同问题。只有把语义当作数据产品，才能支撑规模化 AI。
企业可以怎样开始
不要先为所有表编写百科全书。选择一个业务主题和 20 个真实问题，列出回答所需的表、关系、指标、术语和角色。先解决同名指标、默认时间、主键和数据范围，再把语义输出给问数或 Agent 做回归测试。
验收时既看回答，也看可维护性：业务人员能否读懂定义，数据团队能否定位来源，变更是否知道影响哪些问题，旧版本是否可以恢复。语义层并不会修复源数据质量，但它可以明确暴露质量前提和不可回答边界。
参考与适用边界
本文参考 dbt Semantic Layer、Databricks AI/BI Genie 官方文档及 BuildTable.ai 当前公开建模定位，资料核验日期为 2026-08-20。各平台对指标、权限和接口的实现不同，正式架构选择需结合现有数仓、BI 和 Agent 技术栈验证。