别急着上AI，你的数据还是一锅粥

你们公司的数据字典，上次更新是什么时候？

同一个指标，不同部门算出来的数一样吗？

如果你需要想一想——我要说一件没人想听的事：你们公司根本没准备好上AI。

不是预算不够，不是人才不够，是你们的数据，还是一锅粥。

而偏偏没有人想承认这件事，因为大模型的demo太好看了。

一个让人尴尬的真相

数据团队辛辛苦苦搭了半年的智能问答系统，用的是最新的大模型，RAG架构做得也很规范。

上线之后，业务同学问了一个最简单的问题：

“上个月华东区的GMV是多少？”

系统回答了一个数字。

但业务运营说，这个数和她自己算的差了300万。

数据工程师去查，发现系统拿的是”交易GMV”，运营算的是”结算GMV”，两个口径在公司里从来没有统一过，一直靠人脑记忆区分。

大模型不知道这件事。它只是忠实地从数据里找了一个叫”GMV”的字段，然后告诉你答案。

这不是模型的问题。这是数据的问题。

模型是放大器，不是净化器

很多人对AI有一个根本性的误解：认为AI足够智能，能自己处理数据里的噪音和歧义。

但事实恰恰相反。

大模型是一个极其强大的放大器。它会把你数据里的每一个问题，以你从未预料到的方式放大并呈现出来。

数据里有多个口径？模型会以极大的自信给你一个混合了多个口径的答案。

数据里有历史遗留的脏数据？模型会把那些异常值当成事实，纳入它的推理逻辑。

数据资产之间没有语义关联？模型不知道”高价值用户”这个标签和”ARPU”这个指标有什么关系，就算这两件事在你们公司密不可分。

垃圾进，垃圾出——这条铁律在AI时代不但没有失效，反而因为模型的”流利表达”变得更加危险。以前脏数据只会让报表出错，现在脏数据会让AI用非常自信的语气告诉你一个错误的商业决策。

AI时代，数据工程到底该沉淀什么

我不是说数据质量要做到100分才能碰AI。但我想认真说说，AI时代的数据工程，沉淀的重心应该和过去不同。

过去的数据工程，核心价值是**”把数据搬过来、算出来、放进报表”**。做好ETL、跑通调度、保证产出，就算交差了。

AI时代需要的，是另一套东西。

1. 语义，而不只是数据

模型读得懂字段名，但它不理解你的业务。

你的”user_id”在订单表里代表下单用户，在会员表里代表注册用户，在行为日志里代表设备用户——这三个在你们公司是三个不同的概念，但字段名一模一样。

AI不知道这件事，除非你告诉它。

AI时代的数据工程，要开始沉淀的是业务语义：这个指标是什么意思、口径是什么、和哪些数据有关、由谁定义、在什么业务场景下使用。

这些知识过去活在人的脑子里，活在口口相传里，活在钉钉消息里。现在必须结构化地沉淀下来，成为机器可以理解和检索的知识。

元数据管理、指标体系、数据字典、知识图谱——这些在过去被很多公司当成”锦上添花”的事，在AI时代变成了地基。

2. 血缘，而不只是报表

过去我们在乎的是报表能不能跑出来。

AI时代更重要的是：这个数据从哪来、经过了什么加工、和哪些业务行为有关。

因为模型要做推理，推理需要上下文。上下文需要的不只是一个数字，而是这个数字背后的来龙去脉。

当AI告诉你”这个月用户增长放缓”，下一步它需要能回答”是哪个环节出了问题”。这就需要它能沿着数据血缘，追溯到是注册转化率低了还是次留率低了还是召回效果差了。

没有血缘，AI的推理到”数字”这一层就断了。有了血缘，AI可以一直追溯到业务行为本身。

这也是为什么数据血缘正在从”技术管道图”升级为”语义知识图谱”——不只记录数据流向，更记录业务概念之间的关系。

3. 信任，而不只是准确

准确是数据质量的基本线，但AI时代还需要一件额外的事：数据要让使用者知道它是可信的，可信到什么程度。

模型生成的答案没有置信区间，没有”这个数可能有问题”的提示——除非你的数据系统主动告诉它。

所以数据工程需要沉淀的，还有数据质量的元信息：这张表多久更新一次、上次更新有没有异常、这个字段的缺失率是多少、这个指标口径最近是否发生了变更。

这些信息注入给模型，它才能说”根据昨天更新的数据，这个月GMV大约是X，但该数据今天还未完成更新，建议下午再确认”——而不是以相同的语气回答一个可能过期的数字。

4. 关联，而不只是孤岛

很多公司的数据现状是这样的：用户标签是用户标签，业务指标是业务指标，数据API是数据API，没有人知道它们之间是什么关系。

这在报表时代问题不大，因为每张报表只用自己的数据。

但AI要做的事，往往需要跨越这些孤岛。”高价值用户的复购周期比普通用户短几天”——这个问题同时需要用户标签、行为数据、订单数据、指标定义，协同作答。

AI时代的数据工程，要开始认真建立资产之间的语义关联。哪个标签和哪个指标相关？哪个API依赖哪张表？哪个指标是另一个指标的细分？

这些关联，不是让数据工程师手动维护一张Excel，而是要有系统性的知识图谱来承载它，让AI能遍历这张图，找到回答问题所需的完整上下文。

我理解为什么大家不愿意做这件事

做语义、做血缘、做关联——这些事有一个共同特点：短期看不到直接产出，长期才能看到价值。

而大模型的诱惑就在这里：它能给你一个看起来很厉害的demo，不需要你做任何数据基础建设。

所以很多公司的AI项目路径是这样的：

3周出demo → 管理层看到很兴奋 → 开始全面推广 → 业务发现答案不对 → 追问为什么 → 发现是数据问题 → 回头重新搞数据 → 但这时项目已经延期半年

这不是假设，这是我见过的真实路径，不止一次。

我不是说不能先做demo。Demo有它的价值，可以快速验证方向、拉齐认知。

但demo的成功不等于数据基础建设可以跳过。它只是推迟了面对数据问题的时间，代价通常是推翻重来的成本。

AI时代的数据工程师，要学会讲一门新语言

最后说一件更重要的事。

过去，数据工程师是”幕后”的角色。把数据管好，保证任务不挂，就是价值。

AI时代，数据工程师需要能和业务对话——不是用技术语言，而是用业务语言。

你需要能说清楚：“你们现在想做的这个AI场景，需要什么样的数据基础，现在差什么，补上这些差距需要多长时间，如果不补会出现什么问题。“

这需要你不只懂技术，还要理解业务逻辑，理解指标口径背后的业务含义，理解用户标签背后的运营策略。

这也是为什么AI时代的数据基础建设，不只是技术工程的问题，而是整个数据组织能力的升级。

数据工程要从”搬运工”升级为”翻译官”——把业务世界里散落的知识，翻译成机器能理解的结构化语义。

这件事很难，也很值得做。

因为当你做完这件事，你的AI才真的是你的AI——理解你的业务、说你的语言、在你的数据上做出可信的推理。

而不是一个借用了最先进模型、却在回答你自己公司的问题时不停说错话的，聪明的外乡人。

作者正在构建面向AI时代的元数据智能化平台，探索数据语义层如何成为企业AI的基础设施。欢迎交流。