鑽石舞台

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

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

我聽過的範圍包括深度學習 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