一句话里，藏着两个层级的问题
某公司的周会上，运营总监问了 AI 助手一句话：
「上个月华东区客户的 DAU 是多少？」
一句话，十二个字，听上去没什么刁难的意思，每个词你都觉得不会有歧义。
可它其实踩中了两类完全不同的问题，而这两类问题分属两个不同的层。
第一个问题：DAU怎么算
AI 答了：12.7 万。
数据负责人皱眉：「你这个 DAU，去重到什么粒度？」
这家公司的 DAU 至少有三种算法同时在用：
-
按账号去重------一个人两个账号，算两个
-
按自然人去重------同一身份证下的多个账号合并算一个
-
按设备去重------一人多端就算多个
再往下还有更细的分歧：算「登录即活跃」，还是「有一次有效操作才算活跃」？跨零点的会话归哪一天？「上个月」是自然月还是最近 30 天？
每换一种，数字都不一样。而三种都有正在跑的报表在用。
口径就是答案本身。同一个问题，换个算法就是另一个结论。
这类问题问的其实是「这个数到底怎么算出来的」。这是语义模型该管的事：把「DAU」这个词钉成唯一一段计算逻辑，可预览、可验算、能追到血缘。
第二个问题：「客户」指的是谁
这个问题比上一个更隐蔽，因为它连「算」都还没开始。
注意那句话里最不起眼的两个字：客户。
听起来这是个不需要解释的词。但在这家公司内部，它从来没被定清过。
销售部的看法：注册了、下过单、有转化的，才叫客户。
市场部的看法：注册了、天天在用、明显有需求但还没下单的，那也是我们的人。
这两批人在系统里长得几乎一样，都有账号、都有行为日志、都能算出 DAU。但在业务上，它们是两个不同的对象：
同一批账号，在业务上其实是客户与商机两个不同的对象。
现在回头看那个 12.7 万。它里面混着这两类人。
如果这个数是拿来判断「我们的客户还活跃吗、要不要启动挽留」，那把大量尚未转化的商机算进来，会让留存看起来比实际好得多------一个正在流失的客户群，被一批活跃的潜在用户掩盖掉了。
反过来，如果这个数是拿来评估「市场投放带来的潜在需求有多少」，那把已成交客户算进来，又会让转化潜力被严重高估。
同一个 12.7 万，可以同时支撑两个相反的经营判断。
而这并不是算错了。DAU 的计算逻辑可以完全正确，每一行日志也都真实。真正错的是它统计的那群人：他们在业务上本来就该被分成两个对象。
口径错了，你得到一个错的数字；对象错了，你得到一个错的世界。
两个问题，两个层级
一个错在算法、归语义模型，一个错在分类、只有本体模型能解决。
放回那句提问里看，它们的位置是这样的：
一句话里相邻的两个词，「DAU」归语义模型、「客户」归本体模型，分属两层。
「DAU 怎么算」，公司里一定有人能说清三种算法的差别。它是那种有人懂、只是没统一的问题，缺的只是把哪一种定为准。
「客户指的是谁」不一样，它从来没被正式回答过。销售总监心里有一套答案，市场总监心里有另一套，两套都对，两套都没写进系统。于是 AI 拿到的是一个悬空的词。
大多数团队只做了第一件事，把口径统一就以为完事了，结果养出一个「算得越来越准、却始终不知道自己在算谁」的助手。
接下来一个一个解决，先从看起来简单的那个说起。
先解决第一个：让「DAU」只有一个数
既然有人懂，为什么还是有三个答案？因为这个共识从来没被写在同一个地方。它散落在十几张报表的 SQL 里、几个数据同学各自的习惯里、某次会议的口头约定里，谁要用谁就近拿一个版本。
语义模型做的，就是把它收拢成唯一一段可执行的定义：
-
「日活跃客户数」= 按自然人去重 · 有一次有效操作即算活跃 · 自然月口径
-
这段定义只存在一份，谁问都走它
-
它可以「预览 SQL」------业务方能亲眼看到这个数是怎么算出来的
-
它能一路追到底表字段------出了问题知道去哪查
语义建模具体在做什么
「收拢成一段定义」听着还是抽象。落到操作上，语义建模是在建好的 DWD / DIM 明细层之上做两件事。
第一步是搭模型。以事实表为中心，把相关维度表按业务关系连成星型或雪花模型，维度自己有层级的就让它分层。这一步固定下两件事：JOIN 路径（哪张表用哪个键连哪张表，写死，不再让 Agent 每次猜），以及可用维度（每张维度表能提供哪些维度，在这里圈定好）。
第二步是定指标。先定不可再拆的原子指标，再往上层层派生衍生指标，加筛选、算同比、做累积、多指标混算都行。指标不是孤立的，它挂在某个模型上，所以天然知道自己能按哪些维度拆、数据从哪张底表来，血缘一路可查。
这两步走完，「DAU」就不再是十几段各写各的 SQL，也不再是某张 ADS 表里的一列，而是一个挂在明确模型上、口径唯一、可层层追溯的指标定义。它能按任意已声明的维度去拆，不必为每种拆法预先建一张表。
语义建模不是给字段起中文名，是把「表怎么连、维度有哪些、指标怎么算」一次性定下来。
指标口径页------口径、计算逻辑、维度、血缘与权限一屏可查，并支持「预览 SQL」。
到这里，第一个问题解决得很干净。「DAU」有了唯一去重粒度、唯一活跃判定、唯一时间窗，可预览 SQL、可追到底表字段。任何人、任何 Agent 问 DAU，拿到的都是同一段逻辑算出的同一个数。
顺带省掉的事：不用再堆 ADS 表
上面这套建法除了让「DAU」只有一个数，还顺带改变了数仓要建到哪一层。这件事平时藏在语义建模背后，但它对数据团队的影响，可能比「口径统一」还大。
传统链路是明细层（DWD / DIM）、轻度汇总（DWS）、应用层（ADS）一层层往上堆。每来一个新口径、每多一个看数角度，数据团队就得写一条新 ETL、加一张 ADS 表。时间一长，ADS 层膨胀成几百张互相重叠、口径又微妙不同的表，而这些表里大部分只是同一批明细数据的不同切法而已。
语义建模换了个思路：只要把 DWD / DIM 这两层建标准、建干净，往上的 DWS 和 ADS 就可以不再用 ETL 去堆。
因为「怎么切」这件事被挪到了语义层，用声明来表达。模型声明表怎么连、指标声明数怎么算，查询进来时引擎按声明实时编译成 SQL，直接在明细层上算。换个维度看数，不是加一张表，而是换一个 group_by。
只需建好 DWD / DIM 两层，往上的语义模型与指标全靠声明，不再逐场景堆 DWS / ADS 表。
口径变化不该靠新增一张表来承接。DWD / DIM 建标准，往上的切法交给语义层声明。
数据团队的工作重心也跟着变了：以前是不断响应取数需求、不断加 ADS 表，永远在救火；现在是把明细层的标准建好、把语义声明维护准，一次建好就能长期复用。
再解决第二个：先说清「客户」是什么
可是回到最开始那个数，那个 12.7 万，还是错的。 因为它统计的那群人里，依然混着客户和商机。口径修得再干净，也回答不了「这个数算的是谁」。
行业里大部分语义层方案做到「指标口径统一」就收工了。但那个 12.7 万说明，这只是中途站。
问题出在一个更根本的地方：AI 手里攥着一堆读数，却不知道这些读数属于谁。
它能把 DAU、留存率、客单价都算得分毫不差，可它不知道业务世界里有「客户」和「商机」两类对象，不知道它们各自该被怎么对待、能对它们做什么。这不是再加几个指标能解决的，读数再多，也说不清读的是谁。
要补的不是语义模型的「加强版」，而是一副业务骨架。客户、商机、订单、销售、合同，以及它们之间负责、持有、转化的关系，构成了业务的真实结构；「DAU」「留存率」「转化率」这些指标和维度，只是挂在这副骨架上的元素。
指标和维度是骨架上的读数，本体是那副骨架本身。读数再准，也不构成一副骨架。
还是那个 DAU。一旦「客户」和「商机」被声明成两个对象，事情立刻不一样了。它们不只是分开统计，而是挂着完全不同的骨架：
客户与商机挂着的属性、关系、规则、动作，是两副完全不同的骨架。
看最下面那行：同样叫 DAU，挂在客户上问的是「还活跃吗」，挂在商机上问的是「有多少可能成单」。同一个读数，挂在不同对象上，业务含义完全变了。
更关键的是它们之间那条「转化」关系。有了它，AI 才能回答一类以前根本答不上来的问题：上个月有多少商机转成了客户？转化后的客户留存如何？哪个渠道来的商机转化最快？这些问题不需要任何新指标，只需要那条关系被声明出来。
这也正是本体和「知识图谱」最容易被混淆、又必须分清的地方。图数据库能存关系，但如果所有连线都叫「关联」，Agent 仍然只知道两个对象相连，不知道这种关系会不会影响下一步动作。组成、来源、触发、责任、约束，画出来都是一条线，业务含义却天差地别。本体要的不是「有关系」，而是「关系到底是什么语义」。
骨架由什么构成
本体真正做的事，是把散落的业务元素串联成一个完整的业务模型。这副骨架由五个要素搭起来：
-
对象是骨架的节点，比如客户、商机、订单、渠道，每一个都是业务里真实存在、需要被单独辨认的一类东西。
-
属性是节点的画像，比如客户的累计消费额、商机的意向评分、订单的成交金额。有了它们，一个对象才从「一个名字」变成可被度量的实体。
-
关系是节点之间的连线，比如「商机可以转化为客户」「客户由客户成功负责」「订单归属某个渠道」。连线一旦被声明出语义，Agent 才能沿着它走，而不是在一张宽表里靠相关性猜。
-
规则是骨架上的约束，比如「累计消费额 > 50 万的客户，流失预警必须同步客户成功团队」，它规定了这副骨架在什么条件下该触发什么。
-
动作是骨架上可执行的操作，比如派跟进任务、发起挽留、升级预警，它让骨架不只被「看」，还能被「用」。
前三个（对象、属性、关系）划定了 AI 面对的是一个什么样的世界，决定它能不能做对决策；后两个（规则、动作）规定了它能做什么、该怎么做，决定它能不能按决策把事办对。这五个要素缺一个，骨架就塌一块：只有对象没有关系，是一堆孤立的点；只有读数没有规则和动作，AI 永远停在「会算」，走不到「会办」。
对象、属性、关系、规则、动作五者，共同构成一副完整的业务骨架。
关键在于：这一层不需要补任何数据
有人会问：这不就是加个字段、洗一遍数据的事吗？
不是。订单表里有没有成交记录，系统从第一天就知道，不需要补采、清洗或人工梳理。
缺的是一句声明：「有转化的叫客户，没转化但活跃的叫商机，这是两个对象；客户归客户成功、商机归销售；商机可以转化为客户。」
这句话不产生任何新数据。它做的，是把一个一直存在、却只活在人脑子里的业务结构，变成机器可读的声明。这样一来，每个 Agent、每张报表、每次提问，都按同一副骨架理解业务。
数据齐不等于结构在。本体补的不是数据，是那句从没被写下来的业务声明。
这也是本体建模往往比想象中好落地的原因：大多数时候你不缺数据，缺的是把业务共识写下来。
实体图谱按业务域组织，实体与关系一目了然。
骨架一旦立起来，Agent 的工作方式就变了。问「这批商机为什么迟迟不转化」，它可以沿着「商机 → 跟进记录 → 销售 → 所属渠道」这条链走，而不是在一张宽表里做相关性猜测；问「该怎么办」，它能读到「高意向商机 7 天未跟进须升级提醒」这条规则，给出合规的处置。沿着图走因果，跟用提示词猜因果，是两种完全不同的可靠性。这些实体、属性、关系、规则、动作，在 DataBuddy 里都是界面可配、可发布、可下线的资产，不再是散落在文档和口头约定里的经验。
但骨架上的规则，离不开语义给的刻度
不过这里还有关键的一环：骨架能立起来，前提是它上面挂着的每一个读数都由语义模型保证唯一。本体划定「算的是谁」，语义模型回答「怎么算」，正是开场那两个问题，现在它们咬在了一起。
本体负责「算的是谁」，语义负责「怎么算」，缺一边另一边都立不住。
最能说明这种依赖的，是规则。本体上有这样一条：
「累计消费额 > 50 万的客户，流失预警必须同步客户成功团队。」
这条规则能不能生效，完全取决于「累计消费额」这个口径是否唯一。含不含税？退货要不要扣减？跨子公司要不要合并？如果这个数有三个版本，规则就有三种触发结果，等于失效。一条会随口径漂移的规则，不是规则，是掷骰子。
反过来，正因为语义模型保证了「累计消费额」只有一个版本、可预览 SQL、可追到底表字段，本体上这条规则才是可执行、可审计、能被业务背书的。这也是「统计口径可控、可信」的真正含义：本体上挂的每一个属性、每一条规则的阈值，背后都对应一个口径明确、可验算的语义模型指标。
本体决定 Agent 看到什么样的世界，语义决定这个世界里的每个数字是否可信。
没有语义的本体，是一副没有刻度的骨架；没有本体的语义，是一堆没有归属的读数。
完整形态：三层 + 双翼
真正落地时，这两层并不是凭空立着的。
DataBuddy Unity Semantics 的完整形态是这样：纵向三层语义主线，横向两翼治理，最上面是消费它的 Agent。
Unity Semantics 整体架构------三层语义主线纵向递进，质量与安全治理双翼横向贯穿，顶部由 Agent 消费。
纵向三层各自回答前面提过的一个问题：统一 Catalog 让物理表变得可读，语义模型让每个读数唯一（回答「怎么算」），本体模型把这些读数装回业务骨架（回答「算的是谁」）。
从下往上走，每一层回答的问题都在变深：
-
统一 Catalog：元数据、全域血缘。它是另外两层的地基，得先把「这张表这个字段是什么、从哪来」摸清楚，字段来源说不清，上面就没法定口径，更没法挂进骨架。
-
语义模型：指标、维度、Join 关系。它回答「过去有多少」。
-
本体模型：对象、属性、关系、规则、动作。它回答「是什么、为什么、会怎样、该怎么办」。
双翼：质量治理 + 安全治理
骨架立起来之后，新的风险也跟着来了：语义会腐化，也会失控。定义过时了没人改，就成了「更漂亮的歧义」；而 Agent 一旦从「只会说」变成「能动手」，就可能读到不该读的数据、触发不该触发的动作。能力越往行动端走，治理就越不能事后再补。
所以在 Unity Semantics 里，质量治理防腐化，安全治理防失控，两者跟语义一起生长，横向贯穿全部三层。
它们被画成「翼」而不是某一层里的一个模块，是因为每一层都用得上：Catalog 层要给字段打安全分级、标出加密项，语义层要保证口径定义不过时，本体层要约束哪些动作能被 Agent 执行、由谁执行。权限在查询编译期就生效，模型根本看不到它无权看的数据，也就谈不上「不小心说漏」。
缺语义 → 幻觉；缺治理 → 腐化 / 失控。两者结合，才是护城河。
为什么这套东西可信
讲到这里，一个务实的追问会浮上来：当 Agent 开始派单、改状态、写回系统，凭什么相信它不会出错，又凭什么信它每一步都说得清依据？
这个问题分三层来答：执行是确定的，结果可溯源，准确率经过实测。
第一层：语义查询到物理 SQL，全程无 LLM
这是最容易被忽略、却最决定可信度的一环。很多人以为「AI 取数」是模型一路生成 SQL，在 DataBuddy 里并不是。
模型（Agent）只负责读懂问题、检索语义层、匹配出该用哪个指标、哪个语义模型、哪些维度，然后调用指标查询引擎。从语义查询翻译到物理 SQL 的全过程，都发生在这个引擎内部，没有一步经过 LLM。
Agent 只负责检索匹配语义，翻译成 SQL 交给引擎内的确定性流水线，六段无一步经过大模型。
不堆 ADS 表，性能靠什么撑？答案也在这里：物化由引擎按代价自动决定，而不是人按场景手工建表。同一份语义声明，引擎判断走聚合表更划算就走聚合表，否则直接算明细。口径只有一份，加速是引擎的事。
降低幻觉靠的是这套结构，不是提示词技巧。同一个语义查询，任何时候执行都得到同一个结果。
第二层：每个数都能被追问「凭什么」
语义资产建好之后，它不属于某一个应用，而是所有消费者的共同底座。分析 Agent、AI 看板、业务系统，走的都是同一套定义。
Agent 直接向语义层取数，每次查询都带来源与 QueryId，可回放、可审计。
AI 生成的看板，每个指标都能展开溯源、同样受治理。
不只是数。当 Agent 开始派单、改状态、写回系统，每一次动作也要留痕：命中了哪条规则、用的哪个口径、谁有权执行。业界主流语义层大多只做到指标口径这一层，规则语义只是局部覆盖，动作语义普遍缺失，这正是「算得出 DAU、却推不动任何一次跟进」的根源。要让 Agent 真动手，数和动作都得说得清依据。
价值不在于「AI 给了你一个数」，而在于它同时告诉你：这个数怎么来的、用的是谁拍板的口径、执行了什么 SQL。
第三层：准确率 95.9%，而这不是靠更强的模型换来的
前面两层讲的是机制，这一层给结果。
我们做过一组内部评测：同一批业务问题、同一套底层数据，分两条路径跑。
DataBuddy 内部评测------走语义层准确率 95.9%，裸 NL2SQL 仅 83.5%。
走语义层的那条，准确率 95.9%。
这个数字的意义在于，它跨过了「业务愿不愿意用」的门槛。到了 95% 以上，业务方才敢把 AI 给的数直接拿去做判断；不到这个线，每个答案都得人工复核一遍，等于没省事。
另一条路径是不接语义层的裸 NL2SQL。这不是一个随便搭的对照组：我们在它身上把该做的算法优化都做了，schema 召回、few-shot 示例、SQL 自校验和重试全上。它最终跑到 83.5%，这个成绩其实已经高于业界公开的 NL2SQL 平均水平。
但 83.5% 换成业务语言就是：每 6 个问题里有 1 个是错的，而且你不知道是哪一个。
两条路径差 12.4 个百分点，恰好横跨了「能演示」和「能上生产」之间那道线。
真正值得琢磨的是这 12.4 个百分点从哪来。不是换了更大的模型，也不是调了更好的提示词，两条路径用的是同一个模型。差别只在于其中一条路径上，表怎么连、维度有哪些、指标怎么算，都已经写下来了。
准确率的天花板不在模型那一侧，而在你有没有把业务定义交给它。
人机协同：这些模型不用人肉写
讲到这里，一个很现实的顾虑会浮上来：听起来都对，但这不又是个「建三年都建不完」的工程吗？
这个顾虑没错。语义层和本体在业内被讨论了很多年，落不下去的主要原因从来不是价值不清楚，而是建设成本太高------得把散落在几百张表、十几个部门、若干位老员工脑子里的业务共识，一条一条录进系统。指望人从零手写，这事永远排不到优先级。
所以我们从一开始就把它设计成人机协同：在 DataBuddy 里，语义模型和本体模型的构建，都可以用自然语言交给 Agent 起草。
人机协同建模四步闭环------人提需求、Agent 起草、人审改拍板、自动落地。
落到产品里，这条闭环有两个入口。一个是 AI 智能建模，用一句业务描述，让 Agent 直接起草本体和语义模型；另一个是导入历史资产，把存量 SQL、老文件传上去，让 Agent 自动解析成结构化草案。两者指向同一件事：冷启动不再是从零手写，而是从一份草稿改起。
语义工作台------管理各个业务域的实体、指标与模型，可直接被 Agent 消费。
但 Agent 起草的方案不会直接生效。它把读到的元数据、历史 SQL，连同人给的业务需求，整理成一份完整的语义建模和本体建模草案：事实表和维度表怎么 Join、建哪些指标、建哪些实体、实体有哪些属性、实体之间是什么关系。然后它会停下来，等人审。这一步是我们刻意不做成「全自动」的地方------能从数据里推断的交给 Agent，只有业务才能拍板的留给人。
Agent 起草的建模方案逐项可改，确认后再一键落地，拍板权始终在业务方手里。
最后：那句话，现在能被答对了
回到开篇那个问题------「上个月华东区客户的 DAU 是多少？」
现在再问一次，链路是这样的：
本体先回答「算的是谁」：「客户」是一个已声明的对象，判据是有成交转化，跟「商机」严格区分，「华东区」按客户签约主体所在地归属。语义模型接着回答「怎么算」：DAU 按自然人去重、有效操作即活跃、自然月口径，一段唯一逻辑，可预览 SQL，可追到底表字段。
于是 AI 给出的不再是一个孤立的 12.7 万，而是客户 DAU 8.3 万（留存该看这个数）和商机 DAU 4.4 万（转化潜力该看这个数），还顺手告诉你上月有多少商机转成了客户。
再往下走一步。因为这两个对象各自挂着规则和动作，Agent 可以对客户侧活跃度下滑的年框大客户，按规则同步客户成功团队；对商机侧高意向、却超 7 天没跟进的，直接派发跟进任务写回 CRM，全程受权限约束、留下可审计记录。从「答一个数」到「据此办一件事」，正是从取数工具走到决策中枢的那一步。
本体先答「算的是谁」，语义再答「怎么算」，两层合力把一句话落成一次受治理的业务动作。
一句话之所以能被答对、还能被接着执行，是因为问题被拆成了两层，而这两层都被分别补上了：语义模型管住口径，本体模型定住对象。开篇那句话反过来说同样成立：口径对了、对象也对了，你才第一次拿到一个既准确、又问对了人的答案。
这件事的价值，其实比「让 AI 答得更准」要大得多。
当企业把对象、关系、规则、动作显式地写下来，它做的是一件过去从没做过的事：把那副只存在于资深员工经验、制度文件、部门口头默契里的业务骨架，第一次变成机器可读的资产。过去这副骨架每次人员流动都会损耗一点，每换一套系统就得重新口口相传一遍。
而一旦写下来，模型可以换、Agent 可以换、前端可以换，这副骨架都还在。
企业 AI 的竞争，最终拼的不是谁的模型更强。护城河不是买来的工具，是谁先把自己的业务骨架写了下来。
从统一 Catalog 到语义模型再到本体模型，让数据可理解、可推理、可治理，DataBuddy用「语义 × 治理」为企业数据筑起 AI 护城河。