引言一家年?duì)I收十幾億的制造企業(yè)花了一年多把 ERP、MES、財(cái)務(wù)系統(tǒng)之間的接口全部打通數(shù)據(jù)倉庫里跑著幾百張表技術(shù)負(fù)責(zé)人覺得地基已經(jīng)打牢?？衫习逶谠露葧想S口問一句上個(gè)月華東區(qū)哪個(gè)產(chǎn)品線毛利掉得最多IT 查了兩天給出的答案還被財(cái)務(wù)總監(jiān)當(dāng)場質(zhì)疑口徑不對。系統(tǒng)之間的管道是通的但這個(gè)問題依然答不準(zhǔn)問題出在哪一步很多團(tuán)隊(duì)至今沒想明白。一、連上了只是管道通了系統(tǒng)打通在工程上通常指數(shù)據(jù)能流動接口調(diào)通了、ETL 定時(shí)任務(wù)在跑、數(shù)倉里能看到各系統(tǒng)的表。這解決的是數(shù)據(jù)到?jīng)]到的問題沒有解決數(shù)據(jù)怎么被理解的問題。同樣一張銷售表財(cái)務(wù)系統(tǒng)里客戶按開票主體算銷售系統(tǒng)里按簽約主體算兩邊數(shù)據(jù)合并之后同一家公司可能被記成兩條記錄。更常見的還有字段命名的差異系統(tǒng) A 里叫款號系統(tǒng) B 里叫產(chǎn)品編碼指的是同一個(gè)東西機(jī)器不知道。數(shù)倉里幾百張表、幾千個(gè)字段真正說得清每個(gè)字段業(yè)務(wù)含義的人往往只剩當(dāng)初建倉的那一兩個(gè)人。管道鋪好之后數(shù)據(jù)只是物理上到了一起。它們之間的業(yè)務(wù)關(guān)系、口徑差異、定義邊界還散在各業(yè)務(wù)部門腦子里沒有沉淀下來。這一步?jīng)]做后面的 AI 問數(shù)、指標(biāo)分析全都建在流沙上。向量空間JBoltAI做過不少企業(yè)數(shù)據(jù)調(diào)研多數(shù)受訪企業(yè)都處在物理通了、語義沒通的階段報(bào)表體系越復(fù)雜這個(gè)斷層越明顯。二、AI 問數(shù)把口徑問題放大了傳統(tǒng)報(bào)表時(shí)代口徑問題靠人來兜底。IT 寫 SQL 的時(shí)候會問業(yè)務(wù)這個(gè)回款含不含壞賬沖回業(yè)務(wù)會回答寫進(jìn)報(bào)表邏輯里錯(cuò)了也只在月度復(fù)盤時(shí)被發(fā)現(xiàn)。到了 AI 問數(shù)階段模型聽不懂部門之間的潛規(guī)則它只會按字面意思找數(shù)據(jù)。回款兩個(gè)字對應(yīng)哪張表、哪個(gè)字段、哪條口徑模型不知道也問不到人。有人想用微調(diào)解決方向就錯(cuò)了?？趶揭?guī)則不在模型參數(shù)里在業(yè)務(wù)規(guī)則里今天財(cái)務(wù)調(diào)整一條確認(rèn)收入的規(guī)則模型重訓(xùn)一遍也未必跟得上。有人想用知識庫兜底效果也有限知識庫管得住文檔管不住賬文檔里寫的口徑和系統(tǒng)里跑的數(shù)據(jù)經(jīng)常是兩套。賬這一層的語義靠文檔喂不進(jìn)去必須單獨(dú)梳理這也是向量空間JBoltAI接手問數(shù)項(xiàng)目時(shí)先做口徑調(diào)研的原因。更深層的問題在關(guān)系。跨系統(tǒng)問數(shù)比如2 號產(chǎn)線停產(chǎn) 8 小時(shí)影響哪些訂單需要沿著產(chǎn)線到工單到訂單到客戶的鏈路逐級追蹤。數(shù)據(jù)即使都在數(shù)倉里表與表之間的關(guān)聯(lián)關(guān)系沒有梳理成機(jī)器可讀的形態(tài)模型就只能在字段名上做模糊匹配答出來的結(jié)果自然不靠譜。三、補(bǔ)語義這一層才是真正的打通讓 AI 把業(yè)務(wù)系統(tǒng)用起來中間要補(bǔ)一層語義。這一層做三件事把散落在各系統(tǒng)的業(yè)務(wù)對象理成關(guān)系網(wǎng)訂單連著客戶工單連著產(chǎn)線和設(shè)備把各部門打架的口徑收斂成一套定義寫清楚計(jì)算邏輯和適用范圍把上述兩者建成機(jī)器可讀的模型讓問數(shù)請求先對齊語義再取數(shù)。這三件事的先后順序和顆粒度直接決定問數(shù)準(zhǔn)確率比較穩(wěn)妥的次序是先理對象關(guān)系、再收口徑最后才碰模型參數(shù)。工程上這層通常以語義模型的形式存在問數(shù)的自然語言先被解析成查詢意圖再映射到語義模型上的對象和指標(biāo)最后才落到具體系統(tǒng)的數(shù)據(jù)返回時(shí)每個(gè)數(shù)字都帶著出處用戶點(diǎn)開能看到取自哪張表、按什么口徑算的。模型在這一層里只負(fù)責(zé)理解問題不直接編造數(shù)字瞎編的空間被壓縮到很小。JBoltAI本體語義平臺在這條線上的做法是把解析、映射、溯源做成標(biāo)準(zhǔn)鏈路語義模型在前口徑治理和血緣追蹤兜底問數(shù)請求不再直接碰原始表。一個(gè)常被問的問題是只有一套 ERP 加一堆 Excel 的企業(yè)能不能做。能做但要從高頻問題清單起步把老板和核心部門最常問的幾十個(gè)問題拆開反推需要理清哪些對象、哪些口徑先覆蓋最痛的部分再逐步擴(kuò)。語義梳理的工程量主要集中在前期系統(tǒng)越多、口徑越亂前期越重但這一步省不掉。四、落地節(jié)奏里的三個(gè)坑第一口徑定義必須由業(yè)務(wù)方確認(rèn)。IT 自己拍板的口徑上線后大概率被業(yè)務(wù)推翻返工成本比前期對齊高一個(gè)數(shù)量級。正確的做法是拉著財(cái)務(wù)、銷售、生產(chǎn)的關(guān)鍵用戶逐條過定義簽字確認(rèn)后再進(jìn)模型。這類項(xiàng)目里口徑梳理通常占去大半工時(shí)剩下的才是技術(shù)實(shí)施。第二語義資產(chǎn)要有人持續(xù)維護(hù)。業(yè)務(wù)規(guī)則會變促銷政策改一版毛利口徑可能就要跟著調(diào)。語義模型上線不是終點(diǎn)要有明確的維護(hù)責(zé)任人JBoltAI本體語義平臺的交付節(jié)奏里上線后會留出明確的維護(hù)窗口很多項(xiàng)目其實(shí)是死在上線三個(gè)月后沒人管語義這一關(guān)上。第三用對賬思維驗(yàn)收。上線前拿企業(yè)真實(shí)數(shù)據(jù)跑一輪追問測試隨機(jī)抽幾十個(gè)問題讓業(yè)務(wù)人員核對答案與出處答不上出處的全部返工。這個(gè)動作能擋住九成以上的演示級成功?？偨Y(jié)系統(tǒng)連上了只是把數(shù)據(jù)搬到了一起AI 問數(shù)答得準(zhǔn)靠的是管道之上還有一層統(tǒng)一的業(yè)務(wù)語義。物理打通解決數(shù)據(jù)到?jīng)]到語義層解決AI 懂不懂兩者缺一不可。JBoltAI本體語義平臺是新一代智能數(shù)據(jù)中臺它的做法正是把關(guān)系梳理、口徑治理、語義模型做成平臺能力讓問數(shù)跑在語義之上。數(shù)據(jù)存在一起不等于 AI 懂關(guān)系把這一層補(bǔ)上老板問的數(shù)才能答得清、追得到。經(jīng)驗(yàn)上這類項(xiàng)目的成敗大頭不在模型選型而在口徑梳理和業(yè)務(wù)確認(rèn)這兩件看似不起眼的活上向量空間JBoltAI交付過的項(xiàng)目幾乎都驗(yàn)證了這一點(diǎn)。