企業(yè)AI應(yīng)用痛點（四）-長期建設(shè)與決策層的項目預(yù)期不符

　　企業(yè)AI應(yīng)用最大的痛點并非上周所說的那三個，而是今天我們要討論的這個。雖然很多企業(yè)都把AI當(dāng)成戰(zhàn)略來提，不過這種提法僅僅限于主席臺上，而實際上，目前絕大多數(shù)企業(yè)的領(lǐng)導(dǎo)腦子里并沒有真正的AI時代企業(yè)的新藍圖，而僅僅把AI當(dāng)成一個工具，把推行AI技術(shù)當(dāng)成項目來做，就像當(dāng)年很多企業(yè)做數(shù)字孿生一樣。

　　在前幾期里我提到了企業(yè)AI應(yīng)用落地需要數(shù)據(jù)治理，需要對業(yè)務(wù)做數(shù)字化建模，構(gòu)建企業(yè)業(yè)務(wù)的“語義層”定義。目前哪怕數(shù)據(jù)治理做得很好的企業(yè)（雖然我 還沒見到是否存在，假設(shè)是存在的），擁有高質(zhì)量的數(shù)據(jù)，但是缺乏讓人一看就懂的理解數(shù)據(jù)的語義化描述，一些復(fù)雜的業(yè)務(wù)，師傅帶徒弟的情況下，徒弟要搞明白也不是三兩個月就能完成的。在這種情況下，我們怎么去教會"AI"這個徒弟如何理解數(shù)據(jù)和業(yè)務(wù)呢？

　　想讓企業(yè)實現(xiàn)AI轉(zhuǎn)型，首先在頂層必須構(gòu)建起企業(yè)級的戰(zhàn)略藍圖，用以指導(dǎo)未來十年二十年的建設(shè)。而在基層需要慢慢完成業(yè)務(wù)語義層的描述，先跑通一些點狀的業(yè)務(wù)，然后慢慢鋪開，隨著數(shù)年的努力逐步連接成網(wǎng)，最終達成目標。我這一說都是三五年起步的，領(lǐng)導(dǎo)可能等不了這么長時間，因為領(lǐng)導(dǎo)的領(lǐng)導(dǎo)可能希望馬上就啟動，年內(nèi)就見效，任內(nèi)就結(jié)項。

　　這是一種不太符合客觀規(guī)律的項目為導(dǎo)向的AI建設(shè)方案。其工程依據(jù)是經(jīng)過科學(xué)分析，覺得AI能把那么麻煩的年終報告都寫得滴水不漏了，再加上這一年多時間里層出不窮的AI技術(shù)，以及AI大模型能力的快速提升，再加上自己的企業(yè)愿意真金白銀往下投，做個把AI項目還不是手拿把攥的。

　　實際上這些想法還都過于“項目化”了，AI大模型技術(shù)的發(fā)展確實十分迅速，從去年Deepseek開源開始，再到阿里的qwq、Qwen3，基礎(chǔ)模型的能力確實提升很快，在通識領(lǐng)域的應(yīng)用效果也十分不錯。不過在專業(yè)領(lǐng)域上，AI大模型很難理解你的行業(yè)，以及個性化管理特征差異極大的企業(yè)個體的管理流程，因此你必須在上下文中有十分嚴格的描述，才能讓 AI充分理解業(yè)務(wù)，實現(xiàn)精準的輸出。

　　最近我們團隊測試了最新的Qwen3.5,雖然在通識領(lǐng)域，Qwen3.5開源模型的進步巨大，Qwen3.5-27b在綜合能力上遠超Qwen3-32b，Qwen3.5-35b-a3b對比Qwen3-30b-a3b也進步巨大。不過測試的結(jié)果是，我們決定暫時繼續(xù)使用原來的 Qwen3-32b。顯然在AIOPS這種對于推理準確性要求很高的領(lǐng)域，MOE模型對于大量具有復(fù)雜邏輯關(guān)聯(lián)度的數(shù)據(jù)的綜合分析方面與密集模型差距甚大，目前還不堪使用，而Qwen3.5-27b則因為目前各種工具的適配還不夠完善，我們決定暫時不在生產(chǎn)上使用，未來成熟后，可能會作為目前Qwen3-32b的替代，不過這種替代無論從推理速度還是從資源開銷上，更重要的是準確性上，并沒有帶來本質(zhì)的提升。對于AIOPS這個業(yè)務(wù)領(lǐng)域而言，這一年時間里，AI大模型進化的摩爾定律似乎按下了暫停鍵，AI應(yīng)用暫時無法從模型能力的提升中受益了?；诖耍承╊I(lǐng)導(dǎo)指望的等待模型成熟后自行解決AI應(yīng)用問題的想法可能會落空了 。

　　可能有些朋友會說，不僅是模型在進步，AI技術(shù)進步也是很快的，AI Agent、RAG、上下文工程、MCP、Skills等一系列技術(shù)的出現(xiàn)，難道不會讓AI應(yīng)用變得更簡單嗎？確實，AI應(yīng)用技術(shù)發(fā)展也很快，不過這些技術(shù)都是讓AI應(yīng)用變得更簡單的，并沒有解決AI理解企業(yè)數(shù)據(jù)和企業(yè)業(yè)務(wù)的問題。

　　很多企業(yè)雖然擁有數(shù)據(jù)，但是缺少對于理解數(shù)據(jù)的規(guī)則的描述。因此企業(yè)無法直接把數(shù)據(jù)交給AI，讓AI去完成業(yè)務(wù)操作。前些年，我和一些企業(yè)的領(lǐng)導(dǎo)談起AI應(yīng)用的時候，他們都希望我們幫他們做一個NL2SQL的工具，他們覺得只要這個工具能跑得靠譜了，企業(yè)數(shù)字化的AI轉(zhuǎn)型就沒有技術(shù)障礙了。其實這些領(lǐng)導(dǎo)對于數(shù)據(jù)的理解并不十分準確，企業(yè)數(shù)字化并不是體現(xiàn)在企業(yè)信息系統(tǒng)的數(shù)據(jù)庫表上。一套系統(tǒng)可能有數(shù)千張甚至上萬張表，其實這些表中的大部分都不是用正確的方式去描述業(yè)務(wù)的，而是ISV為了完成系統(tǒng)功能設(shè)計出來的，這些表很難與“企業(yè)語義層”直接映射。

　　拿我們做DBAIOPS舉例，傳統(tǒng)的數(shù)據(jù)庫監(jiān)控工具中的指標集、儀表盤、基線、告警規(guī)則、分析巡檢工具等都只是為了實現(xiàn)以前的白屏運維目標的，與AI所需要理解的“數(shù)據(jù)庫內(nèi)核語義”并不完全兼容。因此想要真正實現(xiàn)數(shù)據(jù)庫的AIOPS，必須換一個角度，從“本體論”的視角去重新組織數(shù)據(jù)，構(gòu)建數(shù)據(jù)庫運維的業(yè)務(wù)語義層，才能有好的效果。要想做好數(shù)據(jù)庫的 AIOPS，無法指望框架提升，AI模型能力提升，必須踏踏實實地一個個地標注語義數(shù)據(jù)。過去的一年里，我們已經(jīng)完成了2萬多條語義的標注，目前這個工作還在繼續(xù)，估計還要持續(xù)數(shù)年。而且這個過程很難加速，因為只有少量的幾個專家具備標注的能力，指望多投點錢，多招幾個人來提速，難度極大。

　　因此，要想在企業(yè)業(yè)務(wù)里真正實現(xiàn)AI賦能，構(gòu)建企業(yè)語義層以及梳理出企業(yè)語義層所需要的數(shù)據(jù)層是必須要做的事情，是無法通過AI大模型或者AI應(yīng)用框架的提升就直接解決掉的。企業(yè)想要全面AI轉(zhuǎn)型，這一步總是繞不過去的。而這一步是最為耗時的，與領(lǐng)導(dǎo)的短期見效的期望完全違背。

　　想要盡快走出企業(yè)擁有數(shù)據(jù)，但是無法真正理解數(shù)據(jù)，因此也無法讓AI真正實現(xiàn)全面的業(yè)務(wù)賦能這個怪圈，首先企業(yè)的領(lǐng)導(dǎo)要能夠理解AI應(yīng)用的真實特征，真正以務(wù)實的態(tài)度來對待AI轉(zhuǎn)型，甚至轉(zhuǎn)過頭去重新審視數(shù)字化轉(zhuǎn)型、數(shù)字孿生等以前做得完全脫了像的爛攤子，企業(yè)信息化方面的 AI轉(zhuǎn)型才算是走上了正軌。關(guān)鍵問題又來了，領(lǐng)導(dǎo)愿意這樣做嗎？