生成式AI長成什麼樣了

前幾天OPENAI釋出會又成為了AI迷的一場盛宴，最近討論這個話題的人很多，今天我也來湊湊熱鬧。其實從CHATGPT 3.5釋出的時候開始，我就對生成式AI產生了興趣，我當時就認為，在DBA和智慧化運維領域，生成式AI會帶來革命性的技術。我很快就註冊了一個CHATGPT賬號，並用於解決我日常的一些問題。不過很可惜在幾個月後那次封賬號浪潮中，我的賬號被封了。註冊新賬號挺麻煩的，同時NewBing開始服務了，我沒有再嘗試去搞一個新賬號，而是用NewBing替代了Chatgpt。

利用大語言模型在智慧化運維領域做點事情一直是我的想法，不過因為資料庫運維領域的特殊性，因此我一直在尋求可私有化部署的生成式AI解決方案。幸好規模略小的可私有化部署的大模型層出不窮，給了我做嘗試的機會。曾經有兩三個月，我的主要心思都在構建私有化的資料庫智慧生成模型上，也嘗試了一些PTUNING工作。工作被證明是有效的，不過也被證明不是一般人能幹的。訓練所需要的硬體資源以及數量不高的高質量的樣本集都是需要很高的成本的(這裡的數量不高是和大模型相對應的，對於依靠專家人力來製作的模式來說，依然是很大的樣本件)。這段時間雖然也嘗試了自己訓練模型，利用現有大模型生成SPARKSQL等工作，不過僅僅限於現有模型的應用。

相對於能力不夠強的可私有化部署的模型，NewBing和ChatGPT這種巨無霸發展的十分迅速。週五我去樓下退房的時候，碰到上海的老薛。他看著酒店大堂裡的幾個國際時鐘說：“時間同步出問題了”，我當時還打趣他說是DBA的職業病犯了，看啥都像DBA在分析故障一樣。不過這玩意不經唸叨，高鐵剛剛開出不久，一個客戶就打電話來求救。說是他們正在做Oracle到某國產資料庫的複製。複製伺服器上的CPU使用率很高，併發上不去，特點是SYS CPU很高。

我讓他做一個perf top分析，看看哪些系統呼叫比較高，很快他就把perf top的截圖發過來了。

罪魁禍首居然是apci_pm_read，一個多小時前和老薛打趣的場面讓我很快的反應過來，是不是時鐘源出問題了。於是讓客戶查了一下時鐘源。果不其然，分散式資料庫的節點上的clocksource都是tsc,只有這臺複製伺服器上的clocksource設定為apci_pm。而且那臺伺服器上的可用時鐘源只有一個-“acpi_pm”，不能將時鐘源設定為tsc。這個環境是一臺華為的伺服器，上面安裝了阿里龍蜥作業系統。於是客戶諮詢了阿里與華為的客服，都無法得到相應的答案。我對硬體也是個半吊子，也想不出如何分析這個問題。於是想起了“萬事不決問NewBing”。搜一下就可以了。

NewBing給出的答案還是比較靠譜的，可能是BIOS中關閉了TSC功能，導致了OS只能使用APCI_PM這種比較低效的時鐘源了。

另外一個案例則更加神奇了，在我的微信群裡，有個朋友問一個PG的SQL執行效率的問題。他發來了一個上百行的執行計劃，我當時用試試的想法，問NewBing，作為一個PostgreSQL專家，你認為下面的這個執行計劃存在什麼問題?

執行計劃過於複雜，我只截圖了一部分。

NewBing給出的答案令人驚奇。後來我花了半個多小時認真閱讀了整個執行計劃。我根據我多年DBA的經驗發現的問題居然與NewBing的回答是一模一樣的。使用Newbing來輔助我分析問題已經成為了我的工作日常。

我已經習慣了讓NewBing作為我的助手，放棄了以前遇到問題找谷歌百度的習慣。谷歌與百度的不專業讓我浪費了不少的時間，而NewBing從來沒有讓我失望，總可以讓我在分析和思考某個問題的時候少走彎路。這是生成式AI日常對我的幫助。生成式AI不是萬能的，對於一些ZERO SHOT的問題，幻覺還是很嚴重的。很多時候生成式AI給出的答案還需要透過經驗去分析其準確性。不過作為工作輔助，生成式AI還是十分有效的。

生成式AI的基礎能力來自於基礎模型的能力，如果基礎模型能力不行，那麼生成出來的答案就要大打折扣了。這也是利用ChatGPT或者NewBing的使用體驗很好，但是在內網私有化部署的環境中效果就要大打折扣的主要原因。

生成式AI今後將會成為工作不可或缺的優秀助手，不過也僅限於助手，完全替代人類專家從事DBA的工作還離得很遠。上個月Oracle CAB上，O記也談到他們在生成式AI上也在加大投入，並會很快在Oracle資料庫裡推出一些產品。我提了是否會在METALINK中引入大模型，得到的回答是肯定的。這一點，在ASK ANDY環節，也得到了正面的回應。不過不論是ANDY還是其他O記的高管，他們都認為生成式AI存在的不準確與幻覺問題依然是目前很難解決的，因此在使用場景上是有限制的。這一點和我的感受差不多。