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