別把“複雜化”視為高大上,優秀的資料科學家不會創造複雜的模型

作者 | Hari Devanathan

譯者 | 王強

策劃 | 李冬梅

如果你決定成為一名資料科學家。祝賀你!作為一名資料科學家同行,我可以說這一職業是充實和有價值的。話雖如此,現實總是會和人們對工作的期望有差距。

很多有抱負的資料科學家問我他們應該關注什麼內容。

我聽過的範圍包括深度學習 Udacity Nanodegrees、Coursera 上的高階統計分析、Tableau 培訓網站上的視覺化教程、關於資料管道 /Spark 的軟體工程文件等等。雖然這些都是同樣重要的,但要關注這麼多內容確實並非易事。

當我第一次參加工作時,我並沒有掌握所有這些知識,但我只學習了完成手頭任務所需的部分。是的,這需要犧牲一些週末和停機時間來學習某種技術。但是,只學習我的確需要的那些資訊是很重要的,因為這樣我就不會被外面龐大的內容資源所困擾。

成為資料科學家好奇心是必選項

所以,是的,學習新工具和概念的好奇心是必要的。作為一名資料科學家 / 軟體工程師,你已經意識到了軟體世界的變化有多快。每個月,你的工具所依賴的軟體包都會更新。此外,每 6 個月就會有新的軟體工具釋出,解決你之前試圖解決的問題。

此外,我相信還有一項技能是每一位資料科學家都應該掌握的:分析資料的能力。等一下。資料科學家不應該做更復雜的工作嗎,比如構建機器學習模型?並非如此。構建一個機器學習模型是非常簡單的。假設我想提取 Medium 部落格文字來構建我自己的 NLP 分類器。首先我想構建一個標籤系統,確定哪些博文是政治、體育相關、商業相關、娛樂相關等等。我真正需要做的是寫一行程式碼來讀取文字和相關標籤,寫一行程式碼來向量化文字和標籤(從文字轉換為數字格式),寫一行程式碼來構建一個在文字 + 標籤上訓練的樸素貝葉斯分類器,寫一行程式碼來將分類器部署到終端(Sagemaker 等)。這一共就 4 行程式碼,就能在生產環境中構建一個模型了。

當然,也有一些資料科學家可以使用 Pytorch 構建自己的神經網路。這確實需要研究生水平的數學和統計學知識。但這些工作很少見,而且通常是為 FAANG/ 擁有研究工作資料基礎設施的公司才會做的。

許多資料科學家堅持使用簡單的機器學習模型,並專注於為它們提供正確的資料。確定正確的資料需要分析他們有哪些資料,並提取其中有用的部分。但如果我們想提高預測速度呢?我們不應該有一個複雜的機器學習模型來實現這樣的目標嗎?也許吧。微軟 AI 已經構建了一個驚人的梯度提升模型,稱為 Light-GBM。我對它做了測試,並與 XGBoost 做了對比,後者是最快的 skikit-learn 分類器之一。Light-GBM 是輕量級的,所以預測的速度比 XGBoost 快。Light-GBM 還支援並行和 GPU 學習,因此優化了速度。然而在有些情況下不建議使用 Light-GBM。Light-GBM 建議至少有 10,000 個訓練資料點才能有效。否則,它很容易過度擬合。

此外,如果你不完全瞭解一個演算法的工作原理,僅僅為了速度而選擇該演算法是不明智的。

就拿我們前面例子中的 NLP 分類器來說吧。為什麼我使用樸素貝葉斯而不是提升演算法?為什麼我選擇樸素貝葉斯而不是決策樹演算法?原因是,樸素貝葉斯是直接了當的數學方法。這是你能得到的最快速度。它確實是假設你對每個類別 / 標籤的觀察是相互獨立的。但是樸素貝葉斯在速度上優於任何提升演算法。提升演算法和決策樹演算法的速度較慢,因為它們需要透過一定的樹形路徑來獲得最佳預測。此外,樸素貝葉斯在較小的資料集上表現良好,而決策樹在這些資料集上表現過剩。

退一步講,從廣義上考慮 NLP。當構建一個演算法時,你需要為你的模型提供特徵。在 NLP 中,這些特徵最終是文字中的獨特詞彙。在一段部落格文字中,這可能意味著超過 2000 個特徵!其中可能包括過濾掉停頓的詞語 / 不必要的詞 / 等等。想象一下,構建一個有 2000 個特徵的隨機森林演算法需要多長時間。

在一個 CPU 上構建這個演算法需要幾個小時,而對一段新的部落格文字進行分類可能需要接近幾秒鐘的時間。在預測速度方面,Boosting 比決策樹有進步,但樸素貝葉斯仍然會比任何決策樹演算法更出色。然而,準確度則是另一回事。決策樹演算法比樸素貝葉斯更準確,但它們可能過度擬合,這取決於你的資料集。

如果你要為你的公司構建一個 NLP 分類器,你必須瞭解你可以接受什麼樣的權衡取捨。這一切都取決於你所擁有的資料,你必須對其進行分析,以確定哪種演算法效果最好。

注:如果你想了解這些演算法背後的細節,我推薦 StatQuest 來學習更多關於統計學和不同的機器學習演算法的知識。有道理,但這不就是資料分析師已經在做的事情嗎?資料科學家真的只不過是頭銜好聽的分析師嗎?是的。資料科學家只是比資料分析師擁有更多的技術能力(軟體工程、演算法設計、雲開發)。隨著工具越來越容易使用,這種情況在未來可能會改變。好吧,那麼為什麼我不能讓分析師做這項工作,而我則專注於很酷、很複雜的模型呢?你可以這樣做,但這隻會影響你作為一名資料科學家的發展前景。就像我之前的觀點,用乾淨的資料喂一個簡單的模型總是比用糟糕的資料喂一個複雜的模型要好。獲得乾淨的資料需要在你的終端分析資料,以便你能設計一個管道來有效地構建和訓練你的模型。

簡單的模型也能完成複雜的工作

為了說明這一點,我會分享一個實際案例。在我的工作中,我們的團隊正在為病人的醫療記錄構建一個 NLP 分類器。我們的客戶希望有一個自動化的標籤系統,這樣他們就可以遍歷 1000 頁的醫療記錄,瞭解每一頁記錄都說的什麼內容。我們有 50 多個分類標籤,範圍從心臟狀況到腦損傷等等。

我們還得到了每個分類的有限訓練資料。我們每個分類有 5 個 pdf,每個有 20-1000 頁的長度。我不能告訴你我們解決這個問題的方法細節,總之我們得到了 90% 以上準確率的模型。

我們的團隊想知道是否可以將這些模型釋出到 Github。我們希望有某種版本歷史來跟蹤我們為提高模型準確性所做的修改。問題是我們正在分析醫療記錄,我們必須確保任何程式碼 / 指令碼 / 模型中沒有受保護的健康資訊(PHI)的痕跡。如果 Github 資源庫對我們來說是私有的,這並不重要;如果 Github 將來發生資料洩露,我們將面臨暴露 PHI 的危險。

對於那些不熟悉的人來說,PHI 的範圍包括病人的名字、姓氏、SSN、地址、出生日期等。這些資訊理論上不會成為模型特徵的一部分,而且我們已經刪除了所有的痕跡。然而,當涉及到連字元時,病人的名字就很棘手了。以 hailey-hailey 為例,這是一種面板病的名字,而不是一個人的姓。對於我們的模型來說,這將是一個相關的特徵。因此,在我們保留連字元名字的時候會有一些邊緣情況。

我在仔細檢查背部受傷模型的模型特徵時發現了這個有趣的特徵。

注意,由於 PHI 的原因,我不能列出實際的病人姓名。我使用的是一個虛構的人物名字(Emma Geller-Green)。

所以在這種情況下,這是一個出現在某個特徵中的某位病人的全名。但我們對它是如何出現的感到疑惑,原因有二:

背部受傷訓練資料不應該把一個人的名字作為一個重要的特徵。一個人的名字通常在 400 頁的醫療記錄中出現 5 次,所以對於背部受傷模型來說,這個頻率是最低的。此外,在描述背部受傷的頁面中,很少提到這個人的名字。我們的停止詞列表中有像 emma 這樣的名字。由於我們沒有解決連字元姓氏的邏輯,所以應該用 green-geller 來代替。emma 應該被刪除。

我們接下來仔細檢查了光學字元識別(OCR)將這些醫療記錄的文字讀作什麼資料。我們檢查後發現,OCR 把 geller-greenemma 讀成了一個詞。像 Tesseract 這樣的 OCR 工具令人印象深刻,在閱讀混亂的 pdf 檔案時相當準確,但它們離完美還有很遠。

所以這解釋了為什麼 emma 沒有被刪除。但是,這仍然不能解釋為什麼背部受傷模型把這個全名作為一個關鍵特徵。我們回到了背部受傷模型的 5 個訓練 pdf,打開了一個 40 頁的訓練 pdf,幾乎每一頁都被歸類為“背部受傷”。令我們驚訝的是,該 pdf 是 20 世紀 80 年代的。那份 pdf 的每一頁都有 Geller-Green Emma 的大字標題,而且是加粗的。

一個機器學習模型並不知道什麼是“背部受傷”。它只是注意到各種模式並做出假設。Geller-Green Emma 出現在了每一個標記為“背部受傷”的訓練頁面上,這一事實足以讓模型假設這個名字代表了這個特殊的專業。當然,我們的團隊添加了邏輯來處理那些 1980 年代的 pdf,並從其中刪除了帶連字元的病人名字。我們沒有建立自己的 PyTorch 模型來處理這個異常,而是直接清理了資料集。這種方法對我們來說更容易測試,更容易快速部署到生產中。

在生產中,一個模型總是會對新的、未見過的資料進行預測,而且很可能在不同的名字上犯同樣的錯誤。在將資料部署到生產環境中時,分析資料和清理資料太重要了。

另外,我不希望僅僅因為我告訴醫生“我認為 Emma Geller-Green 的母親看起來很可愛”而被診斷出有背部問題。

https://towardsdatascience。com/want-to-be-a-valuable-data-scientist-then-dont-focus-on-creating-intricate-models-3fd7569c02e6

TAG: 模型資料演算法構建我們