OpenAI 刚发布 Sora 2，用几句话就能生成一段电影级的视频。趁着国庆假期，我也体验了一下，效果确实震撼。但不知道你有没有想过一个问题：为什么你公司的可视化看板和报表，至今还得靠IT团队手动拉数据、熬夜整理？
首先我要回答的是，AI工具，比如市场上有很多Chat BI工具，你只要输入自然语言，他们是能帮你生成业务报表的。而且像我们涛思数据7月底推出的“无问智推”，更是连提问都不用，它就能基于采集的数据，自动把实时面板、报表、实时分析任务推荐给你。
但现实是，你周围真正用AI直接从企业数据平台生成看板和报表的公司，少之又少。TDengine 推出“无问智推”功能，发布两个多月，大家基本还是处于好奇尝鲜的状态。说到底，问题出在哪儿？主要有两个原因：
- 任务本质不同： Sora 是“创造性生成”，追求惊艳，不求100%准确；而业务报表是“精确性还原”，追求100%可信，决策无法容忍AI的“幻觉”。大家对于需要生成的报表总是半信半疑，自然就难一下火爆起来。
- 数据基础不同： Sora 训练使用的是公开、标准的互联网数据；而企业数据却深陷“孤岛化、不标准、语义缺失、质量低下”的泥潭。更关键的是，这些数据都在内网里，AI 想用也用不了。
第二个原因，才是真正卡住AI在企业落地的“脖子”。它不仅让AI做不出报表和看板，更无法渗透到运营的每个环节去提效。那有没有解决办法？至少在我所熟悉的物联网和工业数据领域，答案是肯定的。
企业数据平台的几大问题
绝大部分企业都看到了数据的价值，把数据作为重要的生产要素，因此搭建了各式各样的数据平台。但这些平台在AI时代暴露出一系列问题：
- 数据规模空前，分析滞后: 物联网、网络技术的普及大幅降低了数据采集与传输的成本和技术门槛，企业得以采集更多设备、更多流程、更高频次的数据，导致数据量呈指数级增长。传统的工业数据平台，实时数据库，乃至当前流行的数据湖、数据仓库，都难以高效处理和实时分析如此庞大的数据体量。当前普遍做法仅是“先存起来”，至于这些数据到底要解决什么业务问题、挖掘什么价值，很多人心里并没数。
- 多源异构数据难以整合：SCADA、DCS、PLC、IoT平台等系统往往来自不同厂商，采用各异的数据协议（如Modbus、OPC-UA、MQTT）和存储格式。这导致数据分散在孤立的系统中，难以统一标准，阻碍了跨部门、跨厂区的数据流动。例如，供应链的数据、销售数据、设备运行数据、工艺参数与质检记录常分处不同平台，形成“数据烟囱”，企业难以获得全局运营视图。
- 语义和上下文丢失：采集的原始数据（如温度值、电压值）往往缺乏必要的上下文信息（如“智能电表A的实时温电压”）、计量单位（如瓦, 千瓦）及有效范围定义。当这些数据传输至IT系统（如ERP、MES）时，关键元数据容易丢失，导致难以进行后续的分析预警。例如，储罐温度数据若无法区分是罐体温度还是内部液体温度，且无合理范围界定，其价值大打折扣。
- 数据质量参差不齐: 工业数据普遍存在采集频率不一致、信号噪声大、字段缺失等问题。传感器漂移造成的数据失真、通讯中断导致的数据断层，都直接影响预测性维护等模型的准确性。此外，受限于存储与计算成本，企业常被迫降低采集频率，丢失关键的数据变化特征，进而影响各类分析的精准度。目前绝大部分企业对数据质量的监测手段都不具备，因此提升数据质量还仅仅是一句口号。
数据规模的问题，可以通过选用更高性能的数据平台或增加存储、计算资源来解决，原则上不构成使用AI的根本障碍。但后面几个问题，就不是光靠“砸钱扩容”能搞定的了。我们必须老老实实做好数据目录、标准化、情景化这些基础性的“脏活累活”。而且，从建平台的第一天起，就要想清楚：你要解决什么业务痛点？挖掘什么数据价值？而不是为了建平台而建平台。
数据目录 – AI 需要的数据导航系统
企业的设备、流程很多，大型企业甚至有超过千万个智能设备，因此数据源十分庞大。怎么快速找到这些设备、找到这些设备之间的关系，不是简单的依靠搜索来解决的。就像人找地方需要地图，AI 找数据，也需要一张“地图”——也就是数据目录。没有它，AI 在企业的数据迷宫里寸步难行。
怎么建数据目录呢？最简单直观的方式就是仿照计算机文件系统，一层一层的建树状结构。这样数据源之间的层级关系就有了。但这种目录结构，有个缺点，就是树状结构里一个节点永远只有一个父节点，无法描述现实世界的复杂关系。因此这类树状结构的设计，一定要引入“引用”的概念。一个设备或一个数据源可以存在于多个树状结构里，但数据本身并不拷贝，只是存在一个“引用”，与计算机文件系统里的”link”一致。
除树状结构之外，图也是一种不错的方式来描述物体之间的关系。但工程实现难度大，而且不符合企业的层级管理结构，让数据的访问控制难以实现，因此采用这种方式的工具很少。
数据标准化 – 对齐数据结构与口径
在实际场景中，即使是同一类数据，不同系统之间也会存在命名不统一、单位不一致、结构不规范等问题。例如，有的系统记录功率字段为 GL，有的命名为 power, 有的命名为“功率”；有的设备以瓦做计量单位，有的则使用千瓦。有的设备上报了10个物理量，有的上报了20个物理量。
对于业务分析和 AI 算法来说，这类不统一的数据是无法直接使用的，你必须进行数据标准化，说白了就是让所有系统说同一种“语言”。
那么怎么标准化呢？你需要有个虚拟层，将实际存储的的数据的表的结构映射到一个虚拟表或视图，这样解决命名统一的问题；你需要记录每列数据的计量单位，然后提供计量单位的自动转换，这样解决单位统一的问题；你需要建立模版，对于同类的设备或流程，必须按照模版上报数据。
数据情景化 – 让 AI 读懂你的数据
你需要为每个数据源配置丰富的业务语义信息，构建带有上下文的数据体系。比如：
- 为每个数据点和采集量添加描述，说明其业务含义；
- 灵活打上标签，方便分类和筛选；
- 配置静态属性，如设备型号、安装位置、规格参数等，增强资产识别能力；
- 为每个采集量设置计量单位、合理上下限、目标值等关键指标，为分析和告警提供判断基准；
- 血缘感知，确定数据之间的上下游衍生关系
- 使用模式，系统要记录用户到底对哪些数据感兴趣，哪些数据更重要
这一套机制，能让数据不再是冰冷的数字，而是带有背景、语义和业务价值的 “可用信息”——只有这样，AI 才能读懂它。这正是目前逐渐兴起的 Context Engineering（上下文工程），也是 TDengine IDMP 重点构建的能力之一。
这些脏活、累活能靠 AI 解决吗？
很遗憾，目前还不能。
建数据目录、做数据标准化、补数据情景……这些基础工作，就像AI模型训练之前的数据标注，仍然高度依赖人工。你别指望把企业数据直接丢给大模型，它就能自动把这些事搞定。
大模型训练所用的数据集，一般在1–10T之间；而一家大型企业的数据量动辄达到PB级别。把这么多数据“喂”给大模型，算力消耗将是天文数字，投入产出完全不成正比——对绝大多数中小企业来说，根本负担不起。再加上每家企业数据结构千差万别，缺乏通用训练工具，强行上马，结果只能是 “垃圾进，垃圾出”。
正因如此，TDengine 在7月底发布了 AI原生的工业数据管理平台 IDMP，就是想为企业提供一个高效的数据管理工具，帮你低成本、高效率地完成数据目录建设、标准化与情景化的工作。
AI-Ready：让数据自己说话
一旦你做好数据目录、数据标准化、数据情景化的工作，你的数据平台就成为了一个AI Ready的数据平台，AI就能轻松的找到你的数据，读懂你的数据，AI自然能生成你需要的可视化看板和报表了。
那能不能直接把企业的生产数据喂给大模型？
绝对不行——不仅是出于安全考虑，哪怕是私有化部署的大模型也不行。生产数据是实时的，体量也很大。我们有个新能源客户，一天就产生超过3TB的实时数据，目前没有任何算力平台能直接处理。
TDengine 的做法是：只把数据平台的元数据（比如层次结构、设备名称、属性、单位等）喂给大模型，由大模型生成看板和报表的建议。看板、报表的数据本身都是从数据库里获取的，而不是大模型生成的，因此绝对可信。大模型产生的幻觉只在看板、报表的模版和样式。
比起一般的 Chat BI 产品，TDengine 的 “无问智推” 更进一步：它能基于实时采集的数据，自动感知业务场景，主动推荐你需要的可视化面板、报表和实时分析任务，真正做到 “让数据自己说话”，让数据分析进入“抖音”时代。这大大降低了对IT和数据分析师的依赖，让业务人员也能实时挖掘数据价值。这是一种数据消费方式的变革，也让全球数百万请不起数据分析团队的中小企业，第一次拥有了数据洞察的能力。
目前，TDengine 这个 AI 原生的物联网、工业大数据平台，主要解决的是 “data to insight”（从数据到洞察） 的问题。我们下一步将发力 “data to execution”（从数据到执行），目标是直接从数据中给出实时决策建议，包括根因分析、能效提升策略等。
AI 不是魔法。
AI 技术还在飞速发展，但AI 能否在企业中真正落地，发挥作用，不取决于模型多强、算力多大，而取决于企业是否愿意扎扎实实把数据底层建设好，打造一个 AI Ready 的数据平台。这是一堆“脏活累活”，但谁先做好，谁就能在AI时代领先一步，真正让数据成为生产力。
陶建辉
2025年国庆中秋长假写于北京望京
