OpenAI 剛發(fā)布 Sora 2，用幾句話就能生成一段電影級的視頻。趁著國慶假期，我也體驗了一下，效果確實震撼。但不知道你有沒有想過一個問題：為什么你公司的可視化看板和報表，至今還得靠IT團隊手動拉數(shù)據(jù)、熬夜整理？

首先我要回答的是，AI工具，比如市場上有很多Chat BI工具，你只要輸入自然語言，他們是能幫你生成業(yè)務報表的。而且像我們濤思數(shù)據(jù)7月底推出的“無問智推”，更是連提問都不用，它就能基于采集的數(shù)據(jù)，自動把實時面板、報表、實時分析任務推薦給你。

但現(xiàn)實是，你周圍真正用AI直接從企業(yè)數(shù)據(jù)平臺生成看板和報表的公司，少之又少。TDengine 推出“無問智推”功能，發(fā)布兩個多月，大家基本還是處于好奇嘗鮮的狀態(tài)。說到底，問題出在哪兒？主要有兩個原因：

1. 任務本質(zhì)不同： Sora 是“創(chuàng)造性生成”，追求驚艷，不求100%準確；而業(yè)務報表是“精確性還原”，追求100%可信，決策無法容忍AI的“幻覺”。大家對于需要生成的報表總是半信半疑，自然就難一下火爆起來。
2. 數(shù)據(jù)基礎(chǔ)不同： Sora 訓練使用的是公開、標準的互聯(lián)網(wǎng)數(shù)據(jù)；而企業(yè)數(shù)據(jù)卻深陷“孤島化、不標準、語義缺失、質(zhì)量低下”的泥潭。更關(guān)鍵的是，這些數(shù)據(jù)都在內(nèi)網(wǎng)里，AI 想用也用不了。

第二個原因，才是真正卡住AI在企業(yè)落地的“脖子”。它不僅讓AI做不出報表和看板，更無法滲透到運營的每個環(huán)節(jié)去提效。那有沒有解決辦法？至少在我所熟悉的物聯(lián)網(wǎng)和工業(yè)數(shù)據(jù)領(lǐng)域，答案是肯定的。

企業(yè)數(shù)據(jù)平臺的幾大問題

絕大部分企業(yè)都看到了數(shù)據(jù)的價值，把數(shù)據(jù)作為重要的生產(chǎn)要素，因此搭建了各式各樣的數(shù)據(jù)平臺。但這些平臺在AI時代暴露出一系列問題：

1. 數(shù)據(jù)規(guī)?？涨?，分析滯后: 物聯(lián)網(wǎng)、網(wǎng)絡(luò)技術(shù)的普及大幅降低了數(shù)據(jù)采集與傳輸?shù)某杀竞图夹g(shù)門檻，企業(yè)得以采集更多設(shè)備、更多流程、更高頻次的數(shù)據(jù)，導致數(shù)據(jù)量呈指數(shù)級增長。傳統(tǒng)的工業(yè)數(shù)據(jù)平臺，實時數(shù)據(jù)庫，乃至當前流行的數(shù)據(jù)湖、數(shù)據(jù)倉庫，都難以高效處理和實時分析如此龐大的數(shù)據(jù)體量。當前普遍做法僅是“先存起來”，至于這些數(shù)據(jù)到底要解決什么業(yè)務問題、挖掘什么價值，很多人心里并沒數(shù)。
2. 多源異構(gòu)數(shù)據(jù)難以整合：SCADA、DCS、PLC、IoT平臺等系統(tǒng)往往來自不同廠商，采用各異的數(shù)據(jù)協(xié)議（如Modbus、OPC-UA、MQTT）和存儲格式。這導致數(shù)據(jù)分散在孤立的系統(tǒng)中，難以統(tǒng)一標準，阻礙了跨部門、跨廠區(qū)的數(shù)據(jù)流動。例如，供應鏈的數(shù)據(jù)、銷售數(shù)據(jù)、設(shè)備運行數(shù)據(jù)、工藝參數(shù)與質(zhì)檢記錄常分處不同平臺，形成“數(shù)據(jù)煙囪”，企業(yè)難以獲得全局運營視圖。
3. 語義和上下文丟失：采集的原始數(shù)據(jù)（如溫度值、電壓值）往往缺乏必要的上下文信息（如“智能電表A的實時溫電壓”）、計量單位（如瓦, 千瓦）及有效范圍定義。當這些數(shù)據(jù)傳輸至IT系統(tǒng)（如ERP、MES）時，關(guān)鍵元數(shù)據(jù)容易丟失，導致難以進行后續(xù)的分析預警。例如，儲罐溫度數(shù)據(jù)若無法區(qū)分是罐體溫度還是內(nèi)部液體溫度，且無合理范圍界定，其價值大打折扣。
4. 數(shù)據(jù)質(zhì)量參差不齊: 工業(yè)數(shù)據(jù)普遍存在采集頻率不一致、信號噪聲大、字段缺失等問題。傳感器漂移造成的數(shù)據(jù)失真、通訊中斷導致的數(shù)據(jù)斷層，都直接影響預測性維護等模型的準確性。此外，受限于存儲與計算成本，企業(yè)常被迫降低采集頻率，丟失關(guān)鍵的數(shù)據(jù)變化特征，進而影響各類分析的精準度。目前絕大部分企業(yè)對數(shù)據(jù)質(zhì)量的監(jiān)測手段都不具備，因此提升數(shù)據(jù)質(zhì)量還僅僅是一句口號。

數(shù)據(jù)規(guī)模的問題，可以通過選用更高性能的數(shù)據(jù)平臺或增加存儲、計算資源來解決，原則上不構(gòu)成使用AI的根本障礙。但后面幾個問題，就不是光靠“砸錢擴容”能搞定的了。我們必須老老實實做好數(shù)據(jù)目錄、標準化、情景化這些基礎(chǔ)性的“臟活累活”。而且，從建平臺的第一天起，就要想清楚：你要解決什么業(yè)務痛點？挖掘什么數(shù)據(jù)價值？而不是為了建平臺而建平臺。

數(shù)據(jù)目錄 – AI 需要的數(shù)據(jù)導航系統(tǒng)

企業(yè)的設(shè)備、流程很多，大型企業(yè)甚至有超過千萬個智能設(shè)備，因此數(shù)據(jù)源十分龐大。怎么快速找到這些設(shè)備、找到這些設(shè)備之間的關(guān)系，不是簡單的依靠搜索來解決的。就像人找地方需要地圖，AI 找數(shù)據(jù)，也需要一張“地圖”——也就是數(shù)據(jù)目錄。沒有它，AI 在企業(yè)的數(shù)據(jù)迷宮里寸步難行。

怎么建數(shù)據(jù)目錄呢？最簡單直觀的方式就是仿照計算機文件系統(tǒng)，一層一層的建樹狀結(jié)構(gòu)。這樣數(shù)據(jù)源之間的層級關(guān)系就有了。但這種目錄結(jié)構(gòu)，有個缺點，就是樹狀結(jié)構(gòu)里一個節(jié)點永遠只有一個父節(jié)點，無法描述現(xiàn)實世界的復雜關(guān)系。因此這類樹狀結(jié)構(gòu)的設(shè)計，一定要引入“引用”的概念。一個設(shè)備或一個數(shù)據(jù)源可以存在于多個樹狀結(jié)構(gòu)里，但數(shù)據(jù)本身并不拷貝，只是存在一個“引用”，與計算機文件系統(tǒng)里的”link”一致。

除樹狀結(jié)構(gòu)之外，圖也是一種不錯的方式來描述物體之間的關(guān)系。但工程實現(xiàn)難度大，而且不符合企業(yè)的層級管理結(jié)構(gòu)，讓數(shù)據(jù)的訪問控制難以實現(xiàn)，因此采用這種方式的工具很少。

數(shù)據(jù)標準化 – 對齊數(shù)據(jù)結(jié)構(gòu)與口徑

在實際場景中，即使是同一類數(shù)據(jù)，不同系統(tǒng)之間也會存在命名不統(tǒng)一、單位不一致、結(jié)構(gòu)不規(guī)范等問題。例如，有的系統(tǒng)記錄功率字段為 GL，有的命名為 power, 有的命名為“功率”；有的設(shè)備以瓦做計量單位，有的則使用千瓦。有的設(shè)備上報了10個物理量，有的上報了20個物理量。

對于業(yè)務分析和 AI 算法來說，這類不統(tǒng)一的數(shù)據(jù)是無法直接使用的，你必須進行數(shù)據(jù)標準化，說白了就是讓所有系統(tǒng)說同一種“語言”。

那么怎么標準化呢？你需要有個虛擬層，將實際存儲的的數(shù)據(jù)的表的結(jié)構(gòu)映射到一個虛擬表或視圖，這樣解決命名統(tǒng)一的問題；你需要記錄每列數(shù)據(jù)的計量單位，然后提供計量單位的自動轉(zhuǎn)換，這樣解決單位統(tǒng)一的問題；你需要建立模版，對于同類的設(shè)備或流程，必須按照模版上報數(shù)據(jù)。

數(shù)據(jù)情景化 – 讓 AI 讀懂你的數(shù)據(jù)

你需要為每個數(shù)據(jù)源配置豐富的業(yè)務語義信息，構(gòu)建帶有上下文的數(shù)據(jù)體系。比如：

• 為每個數(shù)據(jù)點和采集量添加描述，說明其業(yè)務含義；
• 靈活打上標簽，方便分類和篩選；
• 配置靜態(tài)屬性，如設(shè)備型號、安裝位置、規(guī)格參數(shù)等，增強資產(chǎn)識別能力；
• 為每個采集量設(shè)置計量單位、合理上下限、目標值等關(guān)鍵指標，為分析和告警提供判斷基準；
• 血緣感知，確定數(shù)據(jù)之間的上下游衍生關(guān)系
• 使用模式，系統(tǒng)要記錄用戶到底對哪些數(shù)據(jù)感興趣，哪些數(shù)據(jù)更重要

這一套機制，能讓數(shù)據(jù)不再是冰冷的數(shù)字，而是帶有背景、語義和業(yè)務價值的 “可用信息”——只有這樣，AI 才能讀懂它。這正是目前逐漸興起的 Context Engineering（上下文工程），也是 TDengine IDMP 重點構(gòu)建的能力之一。

這些臟活、累活能靠 AI 解決嗎？

很遺憾，目前還不能。

建數(shù)據(jù)目錄、做數(shù)據(jù)標準化、補數(shù)據(jù)情景……這些基礎(chǔ)工作，就像AI模型訓練之前的數(shù)據(jù)標注，仍然高度依賴人工。你別指望把企業(yè)數(shù)據(jù)直接丟給大模型，它就能自動把這些事搞定。

大模型訓練所用的數(shù)據(jù)集，一般在1–10T之間；而一家大型企業(yè)的數(shù)據(jù)量動輒達到PB級別。把這么多數(shù)據(jù)“喂”給大模型，算力消耗將是天文數(shù)字，投入產(chǎn)出完全不成正比——對絕大多數(shù)中小企業(yè)來說，根本負擔不起。再加上每家企業(yè)數(shù)據(jù)結(jié)構(gòu)千差萬別，缺乏通用訓練工具，強行上馬，結(jié)果只能是 “垃圾進，垃圾出”。

正因如此，TDengine 在7月底發(fā)布了 AI原生的工業(yè)數(shù)據(jù)管理平臺 IDMP，就是想為企業(yè)提供一個高效的數(shù)據(jù)管理工具，幫你低成本、高效率地完成數(shù)據(jù)目錄建設(shè)、標準化與情景化的工作。

AI-Ready：讓數(shù)據(jù)自己說話

一旦你做好數(shù)據(jù)目錄、數(shù)據(jù)標準化、數(shù)據(jù)情景化的工作，你的數(shù)據(jù)平臺就成為了一個AI Ready的數(shù)據(jù)平臺，AI就能輕松的找到你的數(shù)據(jù)，讀懂你的數(shù)據(jù)，AI自然能生成你需要的可視化看板和報表了。

那能不能直接把企業(yè)的生產(chǎn)數(shù)據(jù)喂給大模型？

絕對不行——不僅是出于安全考慮，哪怕是私有化部署的大模型也不行。生產(chǎn)數(shù)據(jù)是實時的，體量也很大。我們有個新能源客戶，一天就產(chǎn)生超過3TB的實時數(shù)據(jù)，目前沒有任何算力平臺能直接處理。

TDengine 的做法是：只把數(shù)據(jù)平臺的元數(shù)據(jù)（比如層次結(jié)構(gòu)、設(shè)備名稱、屬性、單位等）喂給大模型，由大模型生成看板和報表的建議?？窗濉蟊淼臄?shù)據(jù)本身都是從數(shù)據(jù)庫里獲取的，而不是大模型生成的，因此絕對可信。大模型產(chǎn)生的幻覺只在看板、報表的模版和樣式。

比起一般的 Chat BI 產(chǎn)品，TDengine 的 “無問智推” 更進一步：它能基于實時采集的數(shù)據(jù)，自動感知業(yè)務場景，主動推薦你需要的可視化面板、報表和實時分析任務，真正做到 “讓數(shù)據(jù)自己說話”，讓數(shù)據(jù)分析進入“抖音”時代。這大大降低了對IT和數(shù)據(jù)分析師的依賴，讓業(yè)務人員也能實時挖掘數(shù)據(jù)價值。這是一種數(shù)據(jù)消費方式的變革，也讓全球數(shù)百萬請不起數(shù)據(jù)分析團隊的中小企業(yè)，第一次擁有了數(shù)據(jù)洞察的能力。

目前，TDengine 這個 AI 原生的物聯(lián)網(wǎng)、工業(yè)大數(shù)據(jù)平臺，主要解決的是 “data to insight”（從數(shù)據(jù)到洞察） 的問題。我們下一步將發(fā)力 “data to execution”（從數(shù)據(jù)到執(zhí)行），目標是直接從數(shù)據(jù)中給出實時決策建議，包括根因分析、能效提升策略等。

AI?不是魔法。

AI 技術(shù)還在飛速發(fā)展，但AI 能否在企業(yè)中真正落地，發(fā)揮作用，不取決于模型多強、算力多大，而取決于企業(yè)是否愿意扎扎實實把數(shù)據(jù)底層建設(shè)好，打造一個 AI Ready 的數(shù)據(jù)平臺。這是一堆“臟活累活”，但誰先做好，誰就能在AI時代領(lǐng)先一步，真正讓數(shù)據(jù)成為生產(chǎn)力。

陶建輝 

2025年國慶中秋長假寫于北京望京