「垃圾進,垃圾出」這句話,搞IT的人應該沒有人沒聽過,也都瞭解是甚麼意思;但這句話如果拿到現在最熱門的「資料分析」或「AI應用」的場景中,說法卻必須做一點調整,怎麼說呢?
根據我自己的研發經驗,需要使用資料或數據做分析的問題可以分成兩大類(聽起來好像繞口令):
- 第一類:「我們知道我們不知道」的問題
- 第二類:「我們不知道我們不知道」的問題
「我們知道我們不知道」
第一類是比較容易瞭解、也是一般常面臨解決的。
簡單來說,就是我們對問題本身已經有了一個假設、甚至已經有可以運作的模型,只是對其中的一些參數還不知道;此時蒐集資料的目的,就是要來決定這些參數。
大家熟知的「
A/B測試」,就是很常用的工具:對已經存在的兩組(或多組)介面設計,如果想知道哪一種比較受歡迎(設計參數),就把設計發給兩組使用者群,藉由蒐集使用的頻率,或是直接進行意見調查,就可以決定哪一組設計比較好。
如果蒐集進來的數據有問題,推論出來的參數就是錯的。
這個說明當然經過簡化再簡化,只是用來讓大家瞭解問題的性質。
資料的正確性,在這一類的問題自然具有決定性的關鍵;如果蒐集進來的數據有問題,推論出來的參數就是錯的。
然而,第二類的問題就沒有這麼直接了當、而且也比較稀少;但是一旦解決,卻是價值比較大的分析類型。
「我們不知道我們不知道」
這一種型態的問題,解決方案之所以那麼稀少,主要還是因為發現問題所在的運氣成分非常重,更不要說成功地解出問題。
不過,回顧這些相關的案例就會知道,它們被發現的「觸發點」還是有許多相似之處:多半是在解決第一類問題的時候,陰錯陽差找到一些令人驚訝的事實,然後被有觀念的人鍥而不捨地繼續鑽研。
在這裡舉另一個例子,讓大家進一步瞭解這種現象。
兩類分析資料
在使用者同意傳回資訊的前提之下,回傳的資料大致分成兩類:
- 第一類是前一篇所說明的、事先計畫好的遙測資料;
- 另一類(資料量其實超過六成以上)是當系統中的應用程式發生記憶體毀損、或是某一段程式執行同一段碼過久時,系統就會發出一個對話方塊,詢問使用者要不要回傳記憶體的內容下載(memory dump)給微軟,以便做進一步的分析。
我記得有一個數據,是即使多數的使用者都持保守態度、不願傳回的情況下,微軟還是每天會收到超過一百萬次回傳。那個時候,我們都笑稱那些資料是「應用程式垃圾」。
但仔細想一下就能瞭解:如果這些回傳是由微軟自己寫的、或是友商的應用程式所產生的還好,的確可以回溯問題的發生點、找出先前沒有找到的臭蟲。
但實際的情況是,這些回傳有八成以上是微軟「不認識」的應用所製造出來的。這讓毀損程式碼的分析,變成一種不可能的任務;微軟再有錢,也找不到那麼多人來做反組譯和追蹤(trace)錯誤所在的工作。
也因為如此,早期有許多收回的資料其實跟廢物沒兩樣。
從分類中挖黃金
不過,微軟究竟是對資料具有極大興趣的公司,也不想因為很難做就放棄;因此還是投入了很多工程師和研究人員,試著將這些回傳資料做自動分類。
有些分類是從毀損點的程式碼模式,有些則是從毀損時堆疊的資料內容分析,看看能不能找出類似的模式(pattern)。讓我印象很深刻的是,有一個團隊甚至將機器碼和資料在記憶體中的分布做成圖型,試著透過電腦視覺的方法來找出模式。
其中一個很有價值的發現,是一位工程師在檢視有問題的下載資料段內容時,發現了一連串的IP位址;剛好這位工程師之前在防毒產品團隊待過,懷疑這些IP是「殭屍網路」的一部份。
經過反組譯處理,工程師確認有一段的確是惡意程式的一部分;於是這位工程師大膽假設,製作惡意病毒的人跟一般開發者一樣,寫出來的程式也會有臭蟲、也會當掉。
好玩的是,即使寫惡意軟體的人刻意在檔案中對IP特別加密,以避免被防毒程式掃到,但它在記憶體中一定會回復成明碼形式,否則程式無法使用。所以,如果在資料中找到殭屍網路的IP,就有九成九的可能是個惡意程式,值得進一步追查。
這個假設一出來,有好幾位工程師持續去驗證,果然找出許多已知的惡意程式的片段。之後公司發現這有非常大的價值,甚至還與執法和國安單位合作,成立了獨立的產品組,對大型企業或公務單位提供分析惡意程式的服務,成為超高利潤的業務。
結語
簡言之,這類問題的解決核心,在於能不能從「垃圾」裡找到黃金;而對於能從中挖出黃金的垃圾,我們還能稱這些是垃圾嗎?
我雖然不是資料科學和AI的專家,但看得出對於有能力掌握資料的高科技公司而言,這些方法論是很有價值的。之前的這些發現,都必須仰賴人們不屈不撓的對一堆垃圾進行挖掘和測試,而且還有很多運氣成分。
如果這些過程能用自動化的程序和電腦來取代,結果會不會更好?
在新的時代中,資料是不是垃圾,恐怕不會是人類說了算。