大数据基建如何迈向 AI Infra？（下）

第二篇如约而至～

本篇基于大数据基建如何迈向 AI Infra？（上）的问题延拓，来针对性的提出落地时的有效价值方案。

后续该系列的工程化落地方案会内更到元一技术社区内部，如有想加社区的小伙伴可以文末加我微信我拉你。

那我们继续～

一、数据负责人现在应该提前准备什么

很多团队听到本体化语义层，容易直接跳到产品实现。

买哪个平台？要不要上知识图谱？要不要建图数据库？要不要让大模型自动建模？要不要把所有业务对象一次性梳理完？

这些问题可以往后放一放。

对大多数数据部门来说，当前更该做的是准备工作。

准备做得好，后面选择自研、采购、混合建设，都有基础。准备做得差，再强的 Agent 也会被烂口径、烂关系、烂权限、烂数据拖住。

1. 从表清单升级到业务对象清单

很多企业有表清单、字段清单、数据目录，但没有业务对象清单。

表清单回答的是：系统里有哪些表。

业务对象清单回答的是：企业经营里有哪些核心对象值得被 AI 理解。

建议数据部门先选一条业务线，不要全企业铺开。

比如零售企业可以从客户、订单、商品、门店、库存、活动开始；制造企业可以从订单、物料、设备、工单、产线、质量事件开始；ToB 企业可以从客户、商机、合同、项目、回款、服务工单开始。

每个对象至少整理这些信息：

• • 对象名称和业务定义。
• • 对象主键和跨系统身份映射。
• • 对象来源系统和主事实表。
• • 对象关键属性。
• • 对象生命周期状态。
• • 对象关联的核心指标。
• • 对象关联的高频经营问题。

业务对象清单是本体化语义层的入口，没有对象，后面的指标、关系、事件和动作都会漂在空中。

2. 把指标从公式升级成“对象上的经营含义”

很多企业已经有指标平台，但指标仍然停留在公式层。

销售额等于什么，毛利等于什么，活跃用户等于什么，退款率等于什么。公式当然要准确，但这还不够。

AI 参与经营分析时，还要知道指标挂在哪个对象上、适用于哪些场景、能解释哪些问题。

同样是销售额，可能挂在订单、门店、商品、区域、客户群、渠道上。

同样是活跃，运营、产品、销售、客服可能有不同理解。

同样是毛利，财务口径、经营口径、商品口径可能会有差异。

所以指标梳理时，建议补充这些维度：

• • 指标归属对象。
• • 指标适用业务场景。
• • 指标粒度和时间窗口。
• • 指标依赖的事件或状态。
• • 指标的互斥口径和近似口径。
• • 指标是否允许跨部门复用。
• • 指标异常时常见的归因方向。

这项工作看起来像指标治理的升级版，但它为后面的 Agent 分析提供了关键约束。

否则模型只能知道“这个指标怎么算”，却不知道“这个指标在经营上怎么用”。

3. 梳理对象关系，别让 join 路径全靠模型猜

数据团队最容易低估关系建模。

因为在传统 SQL 开发里，很多 join 路径是靠经验完成的。老同学知道客户表怎么连订单表，订单表怎么连商品表，商品表怎么连库存表，门店表怎么连区域表。

但对 Agent 来说，这些经验如果没有资产化，就等于不存在。

所以数据部门应该把高频对象关系显式整理出来。

至少包括：

• • 对象 A 和对象 B 的业务关系是什么。
• • 关系是一对一、一对多、多对多，还是时间相关关系。
• • 关系依赖哪些字段或中间表。
• • 哪些关系路径适合分析，哪些只适合明细追踪。
• • 哪些 join 会带来口径膨胀或重复计算。
• • 哪些关系需要权限或租户隔离。

比如客户到订单，订单到商品，看起来很自然。

但如果客户 ID 在多个系统里不统一，订单里既有下单人又有支付人，商品有 SKU、SPU、类目多层结构，区域归属又可能按收货地址、门店地址、销售组织分别计算，那么 join 路径就不再简单。

Agent 会被两类问题拖住：没有数据，以及关系路径看似存在、实际含义不清；后者更隐蔽。

这类问题越早梳理，后面 AI 数据应用越稳。

4. 建一套经营问题集，别只建 SQL 样例库

很多团队会收集历史 SQL，作为 AI 生成 SQL 的参考。

这有用，但不够。

因为 SQL 样例只记录了某次取数的技术实现，它未必记录当时的业务问题、口径选择、边界条件和解释方式。

更有价值的是经营问题集。

比如：

• • 本月销售额为什么低于目标？
• • 哪些门店最近毛利异常？
• • 哪些客户复购下降值得重点关注？
• • 哪些商品库存周转变慢？
• • 哪些项目回款风险上升？
• • 哪些区域活动投入产出不匹配？

每个问题最好补充：

• • 问题所属业务场景。
• • 需要涉及哪些对象。
• • 需要涉及哪些指标。
• • 可能的归因路径。
• • 必须避开的误解。
• • 需要返回的证据。
• • 适用角色和权限边界。

这套经营问题集，未来可以变成语义层测试集、Agent 回归集、业务验收集。

如果企业只能沉淀 SQL 样例，AI 会越来越像一个会写 SQL 的外包；如果企业能沉淀经营问题集，AI 才有机会进入经营分析工作流。

5. 把权限从数据权限升级成语义权限

传统数据权限多半围绕库、表、字段、行级规则展开。

这些仍然需要保留。

但 Agent 场景里，权限还会更复杂。

用户能不能看到某个字段，只是第一层。更复杂的问题包括：

• • 用户能不能看到某类经营对象。
• • 用户能不能看到对象之间的关系。
• • 用户能不能看到聚合后的敏感指标。
• • 用户能不能获得 AI 的归因解释。
• • 用户能不能让 Agent 给出行动建议。
• • 用户能不能触发后续任务或写回流程。

比如一个区域经理可以看自己区域的销售额，也许不能看全国所有区域的门店明细。

一个门店店长可以看本店客户复购情况，也许不能看客户跨门店行为。

一个财务角色可以看毛利和费用，运营角色可能只能看脱敏后的经营指标。

如果权限只停留在表和字段层，Agent 很容易在解释、归因、总结时越过业务边界。

所以数据部门要提前准备语义权限视角。

哪些对象对哪些角色可见，哪些关系可见，哪些指标可见，哪些解释可见，哪些建议可见。

AI 数据应用的权限治理，不能只管查到了什么，还要管它理解了什么、解释了什么、建议了什么。

6. 给语义资产建立版本、审核和回滚意识

很多企业做指标治理，最痛苦的环节通常出现在定义之后：指标变更后，组织如何保持一致。

本体化语义层也一样。

业务对象会变，关系会变，指标口径会变，权限策略会变，经营问题也会变。

如果这些变化没有版本管理，Agent 的回答会逐渐变得不可追踪。

所以团队要提前建立几个意识：

• • 语义模型有版本。
• • 语义发布要审核。
• • 高频问题要回归。
• • 错误回答要能追踪到语义路径。
• • 口径变更要能解释影响范围。
• • 发布后要能回滚。

这听起来像研发流程，但数据语义资产进入 AI 场景后，本来就应该具备工程治理能力。

过去一个指标口径错了，可能影响一张报表。

Agent 场景里，一个语义定义错了，可能影响问答、归因、报告、建议、任务触发和管理动作。

语义资产一旦成为 Agent 的工作底座，就必须从“文档资产”升级成“可发布、可回归、可审计的工程资产”。

7. 让业务专家进入建模流程，不要幻想完全自动建模

大模型可以帮助做很多建模辅助工作。

它可以读 PRD，可以整理访谈纪要，可以归类业务问题，可以生成对象候选，可以总结指标口径，可以发现字段命名差异，可以把散落的规则整理成草案。

但业务语义不能完全交给模型决定。

原因很简单：模型可以从文本和数据里推断模式，却不能替企业承担业务责任。

哪些指标采用哪个口径，哪些关系在经营上成立，哪些字段属于敏感信息，哪些动作需要审批，哪些结论可以对外展示，这些都需要业务专家和数据负责人共同确认。

所以本体化语义层的建设，天然需要人机协同。

模型负责加速候选生成、文档整理、差异发现和问题聚类。

人负责定义边界、审核口径、签署发布、处理争议。

AI 能降低语义建模的体力成本，但不能取消语义责任。

这也是数据部门负责人必须提前设计的组织机制。

如果没有语义资产 Owner，没有审核流程，没有变更记录，没有争议处理机制，后面做出来的 AI 数据系统很难进入核心经营场景。

二、先别急着做全能经营助理，先把结构化数据的语义地基铺稳

很多企业一聊 AI，就想做全能经营助理。

能查数，能分析，能写报告，能做 PPT，能拉群，能发任务，能触发审批，能写回系统。

愿景可以有，但落地顺序不能乱。

尤其对数据部门来说，如果结构化数据的语义地基没铺好，直接做全能 Agent，会把所有问题混在一起。

回答错了，到底是模型理解错了，还是指标口径错了？

查不出来，到底是权限问题，还是关系路径缺失？

解释不清，到底是业务对象没建模，还是 RAG 没召回？

建议不靠谱，到底是归因逻辑不完整，还是行动边界没定义？

没有语义层控制面，这些问题很难被拆开。

所以更稳的顺序，是先选择一个结构化数据相对清晰、经营问题频繁、业务负责人愿意配合的场景。

例如销售经营分析、门店经营分析、客户增长分析、库存周转分析、项目回款分析、财务费用分析。

围绕这个场景，先把五类东西准备好：

核心业务对象 核心指标口径 核心对象关系 高频经营问题 权限和证据边界

这五类资产准备出来以后，再考虑让 Agent 做问答、归因、解释、报告和任务建议。

这样做的好处，是团队可以把 AI 的能力限制在一个清楚的语义空间里。

它不会一上来就被全企业所有表、所有字段、所有口径、所有权限拖垮。

更关键的是，团队可以积累一套可复用的方法。

第一个场景做完以后，第二个场景就可以复用对象建模方法、指标治理方法、关系梳理方法、问题集方法、权限策略方法和回归测试方法。

本体化语义层的建设，不适合用“大干快上”的方式一口吃成胖子。

它更适合从高价值场景开始，把业务对象和经营问题一点点资产化。

数据负责人现在要争取的，是一个可以持续扩展的语义建模方法，接满系统要排在它后面。

三、Data Infra 团队的角色会被重新定义

AI 对数据部门的影响，不会只停留在工具层。

它会改变 Data Infra 团队在企业里的角色。

过去数据平台团队常常被看成支撑部门。

业务提需求，数据团队建表、跑任务、做报表、保稳定、保性能、保质量。

再往前走，数据团队开始做指标平台、数据治理、数据服务，逐步从交付团队变成平台团队。

AI 经营管理往前推进后，数据团队还会承担一类新职责：为 Agent 定义企业业务世界。

这个职责比写 SQL 更靠前，也比做报表更靠近经营。

它要求数据团队理解业务对象、经营问题、指标口径、系统关系、权限边界，也要求团队具备工程化治理能力。

未来一个优秀的数据负责人，可能要同时管理三类资产。

第一类是数据资产。

表、字段、任务、分层模型、数据质量、血缘、成本、性能。

第二类是语义资产。

对象、关系、事件、状态、指标、规则、权限、问题集、解释路径。

第三类是 Agent 可用资产。

工具、Skill、语义计划、问题回归、回答证据、运行 Trace、异常复盘。

这三类资产如果分散在不同团队、不同文档、不同系统里，AI 数据应用很难稳定。

如果能被统一组织起来，数据团队就会从“数据供给者”升级成“AI 经营基座建设者”。

下一阶段 Data Infra 的价值，不只在于把数据算出来，还在于把企业经营世界建成 Agent 可以理解、验证和治理的结构。

这也是为什么我认为，本体化语义层会成为结构化数据方向上非常值得提前准备的技术路线。

它的目的并非追概念。

它是在回答一个非常现实的问题：当 AI 要进入企业日常经营管理，现有数据基建还缺哪一块表达能力。

写在最后：别急着替换数仓，先把数仓资产升级成语义资产

如果把这篇文章压缩成一个判断，我想这样给大家表达一番：

AI 时代的数据基建升级，应该沿着一条更稳的主线推进：保留离线数仓、实时数仓和湖仓一体的事实供给能力，同时让沉淀下来的结构化数据资产长出可被 Agent 使用的业务语义控制面。

离线数仓仍然要做，实时数仓仍然要做，湖仓一体仍然有价值，OLAP 仍然要承担性能和交互查询。

这些底座不会因为 AI 出现就失去意义。

但如果数据部门只停留在表、字段、任务、指标和报表层，AI 数据应用就会长期卡在问答和演示阶段。

下一阶段更值得提前准备的是：

• • 业务对象清单。
• • 指标与对象的归属关系。
• • 对象之间的关系路径。
• • 事件和状态模型。
• • 高频经营问题集。
• • 语义权限边界。
• • 语义版本、发布、回归和审计机制。

这些准备工作短期看不如做一个炫酷 Agent 显眼，但它们会决定企业 AI 数据应用能走多深。

因为企业经营管理里的 AI，最终要面对的是一整个带有对象、关系、状态、规则、权限和责任的业务世界。这比一堆孤立表格复杂得多。

数据负责人如果能提前把这层业务世界建起来，AI 对数据部门带来的冲击，就不只是岗位压力。

它会变成 Data Infra 团队重新定义自身价值的一次机会。

看到这里了，来个“关注”、“点赞”“转发”吧，这是更新的唯一动力了～（原谅我要的有点多了哈哈哈哈哈）

我们一起进步～