企业架构师常犯的 5 个语义建模误区以及破解方法 ｜ 技术实践

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！我最近面向欧洲、中东和非洲地区的 800 多名数据专业人士，做了一场关于主动式语义建模的在线演示。演示过程中收到的问题，是我见过最犀利的一批。而且，它们直指我经常看到团队反复犯下的五类架构错误。这篇文章，是我尝试为这些问题补上一份它们本应得到的长篇回答。语义建模正在经历一场复兴。我们当然都明白，为数据附加语义，也就是赋予数据明确的含义，能够极大促进人们对数据形成共同理解。但智能体 AI 系统的兴起，终于让“这些数据究竟意味着什么”这个问题变得前所未有地紧迫。当查询流程中还有人类参与时，这个问题并没有如此突出。人类分析师可以运用自身掌握的特定领域知识，实时消除歧义。AI 智能体却做不到。它会选择一种解释，沿着这个解释继续执行，并自信地返回一个错误答案，或者充其量只是一个不完整的答案。语义层正是防止这种情况发生的关键。它以受治理、机器可读的方式定义数据的含义：指标如何计算、维度之间如何关联，以及“活跃客户”或“净收入”等术语在你的具体业务语境中究竟意味着什么。没有语义层，你构建的每一个 AI 系统，都只能依据一种隐含且未经验证的数据解释开展工作。当我们对 AI 的推理结果感到失望时，往往是因为我们意识到，自己才是这个主题上更专业的人，也能够做得更好。而问题的根源，在于 AI 不理解底层数据，也就是它没有获得足够的上下文。挑战在于，构建语义层并不是一个一次性的项目。它是一套需要长期坚持的工作方法，是一种必须不断锻炼和维护的能力。但大多数组织采用的方式，往往制造了比原有问题更多的脆弱性。以下是我最常见到的五种模式，以及更合适的做法。错误一：认为必须从零开始引出这个问题的提问是：“纯维度建模与 Snowflake 语义视图之间有什么区别？我们能否对现有模型进行逆向工程？应该如何与 Erwin／IBM IDA 集成？SqlDBM 生成的是 dbt SQL，还是只生成 YAML？”很明显，提出这些问题的团队都已经拥有一些基础资产：维度模型、dbt 项目、BI 语义层，以及多年积累在数据转换、视图和文档中的业务逻辑。而这些问题真正想问的，其实都是同一件事：我必须把这些东西全部推倒重来吗？架构现实：现有资产并不是问题，碎片化才是问题。大多数企业的语义同时存在于四个位置：数据仓库层，包括维度模型和视图；数据转换层，包括 dbt 指标定义和暂存模型；BI 层，包括 Power BI 数据集和 Tableau 数据源；以及散落在电子表格和 Wiki 中的经验性知识。这些内容彼此之间无法沟通。当 AI 智能体提出一个问题时，它只会访问其中某一层，而忽略其他层，最终生成一个局部一致、但从全局来看错误的答案。理想状态：不要替换，而要整合。将现有维度模型作为结构基础，因为它已经编码了实体关系和数据粒度定义，而这些内容很难重新构建。将 dbt 模型作为数据转换和指标逻辑层。然后在这些基础之上构建语义模型，通过引用现有内容，而不是重新定义它们。对于具备逆向工程能力的工具，可以利用这些能力将已有定义提取到语义建模工具中，再对其进行审核和正式化。大语言模型在逆向工程方面的表现好得出人意料。目标架构应当是建立一个统一的语义层，并让它成为所有使用方的规范性参考，包括 BI 工具、AI 智能体和 API。数据仓库层和转换层应当作为位于语义层之下的实现细节，而不是与语义层相互竞争的语义载体。需要避免的反模式：因为从零构建一个平行的语义模型看起来更加整洁，就选择完全重建。它的确会很整洁——但大约只能维持三个月。之后，它就会逐渐偏离数据仓库，而 BI 工具仍然会继续使用自己的定义。最终，你不仅没有解决问题，反而从一个语义载体变成了三个。错误二：把语义建模当作一个工程问题引出这个问题的提问是：“业务专家掌握着相关知识，是否有适合他们编写和管理语义模型的界面，还是所有工作都必须由数据工程师完成？”还有：“是否支持业务术语表？能否嵌入企业级的统一定义？”这些问题揭示了一种极其常见的根本性误解：语义模型应当由数据团队负责构建和维护。事实并非如此。或者更准确地说，在大规模应用中，这根本行不通。架构现实：数据团队具备构建语义模型的技术能力，但他们并不具备定义“客户流失”“活跃账户”或“净收入”对业务而言究竟意味着什么的领域权威，也就是领域知识。更准确地说，他们无法定义这些概念对你的业务究竟意味着什么。真正的定义权掌握在那些依据这些数字做出决策的人手中，包括财务、商业、产品和运营团队。当数据团队单独完成这些定义时，他们实际上做出了一系列隐含选择，而业务部门要么根本不知道这些选择的存在，要么明确不认同它们。这些分歧最终会暴露出来，而且通常会发生在最糟糕的时刻，例如周一早上，董事会正在查看财务报告的时候。理想状态：围绕两个彼此独立的角色设计语义治理模式。语义架构师，也就是数据团队，负责技术结构，包括维度和指标如何实现、模型如何连接数据仓库，以及模型如何测试和部署。语义治理负责人，也就是业务领域负责人，则负责定义，包括指标意味着什么、边界在哪里、排除了哪些边缘情况，以及谁有权修改它。这种角色分离要求工具能够将定义层开放给非工程人员。理想情况下，业务分析师应当能够通过一个界面审核、标注指标定义，或者提出修改建议，而不必接触底层 YAML 或 SQL。与此同时，还需要建立审核与批准流程：对核心业务定义的修改，应当经历与修改财务报告类似的审查流程。将业务术语表嵌入语义模型，而不是将其作为一份独立的文档维护，是正确的架构选择。这样可以建立一个供人类和 AI 系统共同引用的单一事实来源，而不是维护一个逐渐落后于实际实现的文档层。如果你已经拥有业务术语表，大语言模型同样非常适合将其逆向转换为语义模型中的各类要素。需要避免的反模式：将语义定义记录在 Confluence 或 Wiki 中，让文档与技术模型相邻存在，却彼此分离。它们最终一定会发生偏离。文档往往只编写一次，之后便无人维护。语义模型则不同。如果治理得当，人们会持续维护它，因为一旦定义错误，系统就会出现故障。错误三：构建单体式中央模型引出这个问题的提问是：“在不向去中心化团队授予广泛访问权限的情况下，怎样让它们扩展中央语义模型？我们希望建立一个中央基础模型，同时允许各团队增加更多维度。”这是大规模应用中最常见的架构错误，而它源于一种非常合理的直觉：既然希望保持一致性，就应该由中央团队统一构建。但单体式中央语义模型最终会成为瓶颈。领域团队无法自行扩展模型，除非所有修改都经过中央团队。中央团队会逐渐变成一个排队队列，变更速度越来越慢。随后，领域团队便会开始在 BI 工具或临时 SQL 视图中构建各自的平行模型，于是你又回到了四套相互竞争的语义载体。架构现实：我们并不需要向远处寻找答案。许多组织已经采用去中心化的数据治理模式，现在可以把这种方式进一步扩展到数据语义治理。解决方案是建立一种中心辐射式语义架构，参考成熟的数据网格组织划分所有权的方式。中央模型，也就是中心节点，定义整个组织必须保持一致的核心实体和指标，例如客户、账户、收入和日期。这些定义由平台团队负责，经过严格的版本管理，并通过受治理的流程进行修改。领域团队，也就是辐射节点，则可以在核心模型基础上扩展自己的维度、指标和关系，但无权修改核心定义。理想状态：为语义层设计清晰的分级模型：第一级——核心层：通用实体和指标。由平台团队负责。任何修改都必须经过跨职能审核。例如：客户、账户、收入、日期、员工；第二级——领域层：针对核心实体进行的特定领域扩展。由领域团队负责。任何修改都必须经过领域内部审核。例如：营销活动，作为账户的扩展；产品 SKU，作为收入的扩展；第三级——探索层：草稿或实验性定义。由各个团队自行负责。在晋升到第二级之前，不得用于生产环境中的 AI 系统。访问控制应当遵循这一分级方式：领域团队拥有本领域第二级和第三级内容的写入权限，拥有第一级内容的读取权限，但无权写入其他领域的第二级内容。任何现代语义建模工具都可以通过基于角色的访问控制实现这一机制。关键设计原则是：扩展必须引用核心实体，而不能重新定义它们。领域团队可以为“客户”实体添加属性，但不能改变“客户”的含义。需要避免的反模式：为了追求速度，向中央模型开放广泛的写入权限。某个团队出于“提高便利性”而添加的指标定义，很可能在六个月内与另一个团队的定义发生冲突，随后你将花费数周时间协调和统一这些定义。错误四：没有决定上下文应该存放在哪里引出这个问题的提问是：“对于通过包含知识的 Skills 提供上下文，与扩展数据模型、加入额外定义和上下文这两种方式，你怎么看？”这个问题的重要性被严重低估了。大多数团队不会有意识地做出这一架构选择，而只是默认使用其 AI 工具最容易实现的机制，并在之后为此付出代价。随着 AI 系统逐渐成熟，当你拥有多个智能体、多个应用场景，以及多个基于同一套数据进行开发的团队时，上下文究竟存放在哪里，就会成为最具影响力的架构决策之一。架构现实：在 AI 系统中，上下文可以存在于三个位置：语义模型中，其特点是结构化、可进行版本管理且受到治理；Skills 和知识库等检索制品中，其特点是灵活、可搜索，但结构化程度较低；以及系统提示词中，其特点是可以即时使用，但十分脆弱，而且通常不受版本管理。大多数团队会同时使用这三种方式，却没有明确规定在什么情况下应该使用哪一种。理想状态：应用以下判断框架：判断某项内容是否应当放入语义模型的标准是：无论提出问题的是哪个 AI 智能体、哪个 BI 工具或哪个 API 端