语义层，能不能不靠人一条条建？

Data Agent 需要语义层，已经是一个普遍的行业共识。当前，更现实的问题是：这层语义如何构建，要花多长时间构建？

目前，我们大约有超过八成的潜在客户会仔细思考这个问题：平台可以买，指标谁来盘？如果还得先花几个月，找业务人员、分析师和 ETL 工程师把指标口径一条条梳理清楚，Data Agent 的上岗就被卡在了数据语义的准备工作上。

指标口径盘点，为什么这么难？

过去建设一个指标，大致要走这样一遍：业务人员说明想看什么，分析师找出已有报表和相近口径，ETL 工程师沿着数仓加工脚本追来源、看计算。大家一起核对统计对象、时间、过滤条件、去重方式和关联关系。如果两套报表算出的数字不同，还要 IT 查明差异从哪里开始，由业务负责人决定该统一，还是各自保留。

讨论有了结论，才写成指标口径文档，再配置到 Aloudata CAN 这样的语义平台里，最后拿实际数据验证。

从我们的项目经验看，配置本身只占大约 10% 的工作量，另外 90% 工作量花在找材料、读代码、还原口径和对齐分歧上。

这也解释了一个看似矛盾的现象：语义平台已经能把指标定义得很清楚，项目推广仍然要很久。缺的不是一个系统配置按钮，或者有一个自动的表关联建模的功能，而是企业多年积累的业务知识并没有整齐地放在一份文档里。它散落在报表、SQL、存储过程、任务调度参数、项目文档和人的经验中。即使终于盘点完一次指标口径，上游业务系统、ETL 代码和业务口径规则还会继续变化，存在指标口径漂移，过一段时间又得重新核对。

所以，要降低语义层成本，先要看这些人工盘点的工作里，哪些事情是机器能够接过去完成的。

机器能不能替人读代码、盘口径？

我早年做 ETL 工程师时，接到口径核查任务，不会只看表名和字段注释，而是从业务正在使用的报表往回查：这个报表的数据集来自数仓哪张表，这张表经过了哪些加工步骤，在哪一步做了过滤、关联、分组和计算？再查 ETL 调度参数，拿实际数据验证统计口径。

我们做 Aloudata BIG 主动元数据平台（https://aloudata.com/products/big） 的技术出发点，就是模拟 ETL 工程师“读代码、追加工链路”的能力。

它通过阅读 SQL 代码和任务执行日志，解析 SQL 加工逻辑，建立算子级血缘。所谓算子级，是不仅知道结果来自哪些表，还能追到中间的关联、过滤、聚合和表达式。加工链路经常跨了很多层，Aloudata BIG 可以把相关逻辑沿链路归纳出来；一段脚本同时处理多类数据，Aloudata BIG 具备口径裁剪的能力，可以裁掉与这个指标无关的部分，免得盘点报告被无关代码淹没。这样，从报表上的一个指标往回看，机器就有机会还原它实际怎么算，这叫基于元数据的口径提取能力。

光有数据血缘还不够，从报表名称、数据集里的指标与维度名称、以及码值词典等能补充口径的业务含义，指标口径的数据探查与报表数据的对账能检查某些推断是否成立。

大模型适合在这些证据之上梳理业务口径、组织解释，并提出还缺什么材料、请谁确认。

我们希望机器交付的是一份可以让人继续工作的盘点报告：

• 哪些指标找到了完整计算链；

• 哪些指标存在同名不同义、同义不同名的情况；

• 计算差异发生在哪一步；

• 哪些结论可以由代码和数据支持，哪些属于待确认的业务选择，该选择又会影响哪些报表和分析任务。

（指标口径端到端盘点效果图）

机器能盘点指标口径，这前后的变化很大。过去，语义平台项目组收到的是指标盘点任务，要从头按上述步骤人工逐步找线索，对口径；以后，项目组收到的是机器整理好的口径、证据、分歧，可以直接核实、纠错和决策。

机器自动口径盘点这条路能不能走通，技术突破有两点：机器能不能在复杂、真实的加工链路里稳定读懂代码；读出来的口径，能不能经客户核对后真正执行，可做数据比对。

• 第一个点，Aloudata BIG 的算子级血缘解析、构建和裁剪能力，已经在银行客户的大批量复杂脚本环境里得到验证，覆盖超过 50% 的股份制银行和头部城商行，你可以在我们的官网查看相关客户案例（https://aloudata.com/cases）。

• 第二个点，我们某个客户选取两个业务域，对大约 2000 个指标进行了自动盘点。客户校对后认为，生成的指标口径可以直接执行，数据比对的准确性超过 99%。在这次验证的范围内，自动盘点已经能够替代原先人工查找、还原和整理指标口径的工作，客户只需要负责核对结果，决定口径如何正式使用。我们在某个银行客户经初步验证，口径盘点及业务语义归纳效率提升 300 倍，原定于 60 个人月的口径盘点工作减少到一周。

这两项验证分别回答了“能不能批量读懂复杂加工代码”和“读完之后能不能用于真实业务”。经过确认的指标口径定义再进入 Aloudata CAN 语义平台，让指标管理、指标执行和指标消费统一起来，实现“管研用一体化”。

怎么用好口径自动盘点能力？

有了生产级可用的口径自动盘点能力，会带来非常多的高价值应用。

第一个应用：把口径自动盘点能力内置在 Aloudata Data Agent 中，Data Agent 就具备了“30 分钟上岗”的能力。

就像数据分析师上岗一样，企业开通数据和报表的访问权限之后，Aloudata Agent 会主动摸清业务环境和指标口径，并通过真实任务完成校准，然后开始承担分析工作，过程中可以边干边问，交付口径清晰的分析结果。

这个过程很像企业招聘数据分析师，哪个业务版块想要招聘分析师，就给 Data Agent 开通那个版块的报表和数据仓库的访问权限，并给它相应的历史作业，Data Agent 就会先盘点有关的数据、报表和口径，承担这个版块的数据分析工作。随着工作表现得到越来越多人的认可，可以再逐步增加其他业务版块的分析工作，比如从会员运营进入商品运营，再进入财务分析等。

这个过程，就把指标盘点从一个巨大的全域前置项目，变成一项随工作范围逐步发生，“以用促治”、“边用边治”的长期机制。

这才是 Data Agent 走向广泛使用的前置技术突破。

第二个应用：通过口径自动盘点能力，数据治理可以更紧地跟着真实使用走。

过去做数据治理，要不事前出规范，但欠缺有效的事中跟踪和执行能力，很容易变成治理、开发、使用各自一张皮。要不事后运动式治理，每隔 2-3 年来一波集中治理，治标不治本。这导致企业数据治理工作虽然非常重要，但又长期得不到突破。

口径自动盘点，可能理解成是“数据架构师”的内核 Skill：读懂 ETL 链路代码是一个很基础的 Skill，指标的口径判重是一个更高阶的 Skill，基于口径判重的数据链路优化要考虑的因素就更多了，是一个更复杂的 Skill。

我们通过口径自动盘点这一核心能力，叠加相应的 Skill，就可以提供“数据架构师 Agent”，在业务需求发起的时候，能够与“数据分析师 Agent”协作，让数据分析与数据工程在需求侧就开始协同。

这就跳出了原有的数据治理偏事前和事后的框架结构，在事中完成工作协同，比如数据分析师 Agent 在引用数据架构师 Agent 的治理成果时，遇到答不出的题或相互冲突的结果，可以把问题送回数据治理流程，由数据架构师 Agent 进行问题分析，发现有可能是语义层欠缺相应的维度，也有可能是没有相应口径的指标，这会变成一次增强语义层的待办任务。

这样，数据治理不只是一次项目交付，而是发现问题、拿出依据、推动修正的持续迭代，这才是我们希望推进的 AI 数据治理，其数据治理的成果是一个持续增强、持续保鲜的企业语义库，这是企业在 Agent 时代最大的数据资产。

下一步，让 Data Agent 30 分钟上岗

随着模型能力的不断提升，和 Harness 工程实践的不断成熟，Data Agent 承担一部分或大部分数据分析师的真实工作正不断得到验证，我看到不少大型企业的 Data Agent 月活用户已经过万，越来越多的 ETL 工程师的工作内容开始切换到为 Data Agent 准备语义模型，一个新的冲突正在形成：

一方面是如何尽快释放 Data Agent 带来的企业分析生产力，另一方面如何低成本地构建和治理企业数据语义。

如何解决这个冲突成为企业数据团队新的工作方向。

Aloudata 在创立之初，就以“Data Always Ready”（让数据随时就绪）为使命，持续投入大量研发资源研究算子级血缘解析技术，并不断在客户交付中实践和提升该技术的应用场景，当前其口径盘点技术已经具备企业生产级应用的条件。

近期我们将在 Aloudata Agent 产品中内置口径自动盘点功能，并以“30 分钟上岗”的直观方式呈现给大家，欢迎大家在官网或添加 Aloudata 小助手给我们留资，第一时间预约体验相关功能。