语义工程-05.AI时代的语义层架构-上下文语义层

原创

已于 2026-07-12 23:13:22 修改 · 446 阅读

于 2026-07-09 12:46:17 首次发布

回顾十到十五年前的BI系统，数据先进入数据仓库，再创建数据集市，最后用BI工具构建报表。
在这种架构中，语义层只是数据库与可视化之间的工具，帮助重命名字段、定义计算指标，避免分析师重复编写SQL。
然而，随着企业数据被BI仪表盘、自助分析工具、机器学习系统和AI代理同时使用，语义层正从一个辅助工具演变为统一的数据操作接口。语义层已成为数据基础设施本身的一部分。

为什么AI时代语义层至关重要

当大语言模型或人工智能代理查询数据时，它面临一个根本性问题：它不了解业务，也无法理解元数据的含义。如果没有语义层：

它生成的 SQL 语句在技术上有效，但在业务上却行不通。
它不知道 usr_acct_status = 3 表示“已流失”。
它错误地连接了表，或者遗漏了关键筛选条件（例如，已软删除的行）。
相同的查询结果不一致
语义层通过为人工智能提供一个 受控的、具有业务感知能力 的数据接口来解决这个问题。包括：

查询准确性： 研究表明，当大语言模型通过语义层而非原始表进行查询时，其数据查询的准确率可提高 3倍。Databricks报告称，其Genie本体上下文引擎将答案准确率从约50%提升至 84.5% ，远超简单的文本转SQL方法。彭博媒体内部的“知识缺口代理”仅通过将缺失的机构知识捕获为受控上下文，就将其数据访问代理的SQL准确率提高了 63% 。由于业务逻辑已直接提供给模型，因此模型不再需要猜测业务逻辑。
当有人问“请显示上个季度各地区的总收入”时，语义层就能准确地理解这句话的意思：

业务查询：   “上季度各地区总收入”

语义解析：
  指标：总收入 → SUM(订单金额)
  维度：区域 → regions.region_name
  连接路径：订单 → 客户 → 区域（自动发现）
  时间筛选：订单日期 >= '2025-10-01'生成的 SQL：
  SELECT r.region_name, SUM(o.amount) AS total_revenue 
  FROM analytics.sales.orders o 
  JOIN analytics.crm.customers c ON o.customer_id = c.id 
  JOIN analytics.geography.regions r ON c.region_id = r.id 
  WHERE o.order_date >= DATE '2025-10-01' 
    AND o.order_date < DATE '2026-01-01' 
  GROUP BY r.region_name 
  ORDER BY total_revenue DESC

指标一致性： 只需定义 net_revenue 一次，所有客服人员、仪表盘和笔记本都将沿用。财务部门确认的数字就是客服人员向客户报价的数字。无需再费力调和三个“真相”。
数据治理： 优秀的语义层会在查询时强制执行基于角色的访问控制，并为每个结果提供血缘关系。Snowflake 的 Cortex Analyst 遵循基于角色的访问控制；Microsoft 的 Fabric Data Agents 遵循 Purview 策略和行/列级安全机制；AWS Context 通过 IAM 和 Lake Formation 使每个代理查询都具备身份感知能力。代理不会意外泄露用户无权访问的列，并且每个答案都带有“数据来源”的追踪信息。这正是趣味演示与合法合规、可正式发布的产品之间的区别。
成本控制： 当定义集中在一个受控的位置时，您无需在每个提示中重复定义，并且可以将更多问题保留在受控的业务逻辑中，而不是退化到成本高昂且不可预测的原始表行为。Databricks 现在将其封装在带有硬性支出上限的 Unity AI Gateway 中；更好的语义覆盖率直接意味着更低、更稳定的账单。
可解释性： 由于指标、关系和已验证的查询都是明确的，系统可以展示其工作原理。这使得“自信”的代理转变为值得信赖的代理，尤其是在代理从回答问题转向执行操作（调整价格、下单、处理工单）时。
互操作性： 只需定义一次指标，即可将其提供给 Claude、ChatGPT、您的内部代理和 Power BI，无需为每个平台单独编写代码。

从传统语义层到上下文语义层

最早语义层很薄，薄到可以说就是数据操作接口，以至于很多企业并没有明确提出语义层。此时语义层管理对象是受控的指标，例如“净收入”、“活跃客户”、“客户流失率”和“地区”等概念被统一定义并作为指标、维度和关系映射到您的物理表中，从而确保每个用户（无论是人还是机器）都能获得相同的结果。
在AI时代出现了上下文层，上下文层 比语义层范围更大，包含两个层面的含义：

运行时上下文：它是模型每次调用时你提供给模型的信息，例如当前对话、长期记忆的内容以及可以使用的工具。Anthropic 将这种上下文的构建称为“上下文工程”。
企业上下文层：它是代理持续可用的、跨场景的数据与知识源。企业上下文层是代理在任何地方都依赖的唯一数据源。上下文层比语义层更丰富，它将上下文描述为由六种元数据类型组成的多层结构：
- 技术元数据 ——模式、数据类型、安全标签（IAM），直接来自源系统。
- 语义元数据 ——业务本体、术语表、分类。
- 操作元数据 ——血缘关系、数据概况、使用统计、质量评分。
- 关系 ——有形资产与商业理念之间的联系。
- 信任元数据 ——指示数据是否来自经过认证的权威来源的信号。
- 代理指南 ——非结构化的“代理自述文件”：聚合之前要应用的过滤器、要遵循的连接路径、模式中不可见的注意事项。