資料科學，會如何向我們撒謊？

【IT168 編譯】原文作者： Dima Shulga，HiredScore資料科學家

原文連結：

最近我讀了Darrel Huff寫的《統計陷阱》(How to lie with statistics)這本書。這本書講的是如何利用統計資料使人們得出錯誤的結論。我發現這是一個令人感興趣的話題，認為它與資料科學非常相關。因此我想要寫一個書中所舉例子的“資料科學”版，其中有些是書中提到的，有些則是筆者在現實生活中看到的相關例子。

這篇文章所講的並非如何透過資料科學進行撒謊。相反，它會告訴我們：我們會如何因為沒有對資訊渠道中不同部分的細節給予充分的關注而被愚弄。

圖表（Charts）

現在，把自己想象成某個公司的新進資料科學家。這家公司之前已經有了一個資料科學團隊，透過建立模型來預測一些重要的事情。你是一個非常有才華的資料科學家，一個月後，你能夠將他們的模型精確度提高3%。難以置信!你希望向別人展示你的進步，所以你準備了下面這個表格：

這個看起來不錯，但似乎無法給人留下深刻的印象。而你想讓大家都對你的成果印象深刻，那麼你能做什麼?(除了進一步最佳化你的模型)

為了更加突出地展示相同的資料，您需要做的就是稍微更改圖表，你需要讓表格專注於“變化”。所有在80%以下的資料不需要展現，它可以是這樣的：

這樣看起來，你的模型比舊模型好了四倍!當然，聰明人稍微一想就會確切地知道發生了什麼，但這張圖表看起來確實令人印象深刻——很多人會記住這個巨大的差距，而不是確切的數字。

我們可以做同樣的事情。假設你和你的團隊在做一些模型，最近幾周你有了突破，所以你的模型效能提高了2%，它看起來像這樣:

其中的變化很難直觀看到，實際數字分別是[90.02、09.05、90.1、92.2]。同上，2%的增長或許是一個不錯的進步，但在這個圖表中並不十分友好。

我們用與上述大致相同的方法對圖表進行一次改進，數字是相同的，但這個圖表看起來比前一個要好得多。

度量標準(Measurements)

通常來說，初級資料科學家往往對使用什麼度量標準來度量他們的模型效能這件事缺乏認真考慮。這可能會讓他們常常去使用一些預設的度量標準，而大多數情況下，這可能是錯的。以準確性為例，在現實生活中(大多數情況下)，這是一個非常糟糕的度量標準。因為在現實生活的大多數問題中，資料都是不平衡的。比如Titanic乘客生還預測模型，這是一個非常受歡迎的Kaggle入門專案。如果我告訴你，我建立的模型有61%的準確度，這個結果可以稱作好嗎?很難說，但總比沒有結果強吧!讓我展示一下我具體做了什麼：

predicted = np.zeros(len(test_df))

print accuracy_score(predicted, test_df['Survived'])

是的，我所做的就是，預測所有的例項都為“0”(或“NO”)，然後就可以得到這個準確率(61%)，因為倖存的人比遇難的人要少。更極端的情況是資料非常不平衡，在這種情況下，即使99%的準確率可能也沒有任何意義。這種極端不平衡資料的一個例子就是，當我們想要正確地分類一些罕見的疾病時，如果只有1%的人患有這種疾病，那麼每次只要預測“不”，我們就能得到99%的準確率!

準確性的問題只是其中一個個例。當我們閱讀一些研究/試驗/論文的結果(或者如果我們釋出了我們的結果)時，我們需要確保所使用的度量標準適合我們試圖去度量的問題。

我們需要做的另一件重要的事情是瞭解結果的好壞。即使我們使用了正確的度量標準，有時也很難知道它們是好是壞。90%的精度對於一個問題來說可能是很好的，但是對於其他問題來說就很糟糕了。一個不錯的辦法是設定一個基準，建立一個非常簡單的(甚至是隨機的)模型，並將您/其他人的結果與它進行比較。對於泰坦尼克號的問題，我們已經知道，只要輸出結果都為“NO”，我們就會有61%的準確率，所以當某個演算法擁有70%的準確率時，我們就可以說這個演算法有所貢獻——當然，它可能做得更好。

漏洞(Leaks)

我想談談我在資料科學領域中遇到過的三種漏洞。特徵工程/選擇漏洞、依賴資料漏洞和不可用資料漏洞。

特徵工程/選擇漏洞: 在大多數情況下，我們需要對資料進行預處理和/或特徵工程，然後再將其放入一些分類器中。很多時候使用一些類(Transformer)很容易做到這一點，這裡有一個sklearn示例:

X, y = get_some_data()

X = SomeFeaturesTransformer().fit_transform(X)

X_train, X_test, y_train, y_test = train_test_split(X, y)

classifier = SomeClassifier().fit(X_train, y_train)

在第一行中，我使用某種方法獲取資料。然後我使用SomeFeaturesTransformer類從資料中提取特徵。然後我把資料分成訓練和測試，最後訓練分類器。

看到漏洞了嗎?大多數時候，特徵提取/選擇是模型的一部分，所以，由於是在分割之前執行這個步驟，致使我正在測試集上訓練模型中的一部分!一個簡單的例子是，當我們想要使用一些關於特徵的統計資料時。例如，我們的一個特徵可能是偏離均值。假設我們有一個關於房子大小-價格的預測，我們想用當前房子大小和平均房子大小的不同作為一個特徵。透過計算整個資料的平均值(而不僅僅是訓練集)，我們將關於測試集的資訊引入到了我們的模型中。(資料的平均值是模型的一部分)。在這種情況下，我們可能在測試集上得到突出的結果，但是當我們在生產中使用這個模型時，它將產生不同的/更糟糕的結果。

我們的模型不僅僅是渠道末端的分類器。我們需要確保模型的任何部分都不能訪問關於測試集的任何資訊。

依賴資料洩漏: 在我的論文中，我建立了一個系統，試圖將話語的記錄分為典型和非典型的話語。我有30個參與者，每15個話語重複4次。總共有30*15*4=1800次錄音。這是非常少的資料，所以我想做交叉驗證來評估我的演算法，而不是把它分解成訓練和測試。但是，我需要非常小心，即使沒有交叉驗證，當我隨機選擇我的一些資料作為一個測試集時，我將會(高機率)得到測試集中所有參與者的記錄!這就意味著我的模型是在參與者身上訓練的，他們將在上面進行測試!當然，我的結果會很好，但是我的模型將學會的是識別不同參與者的不同聲音，而不是典型的或非典型的話語!我會得高分，但實際上，我的模型並沒有價值。

正確的方法是在參與者級別上分割資料(或進行交叉驗證)，即將5人作為測試組，另外25人作為訓練組。

這種型別的依賴資料可能出現在不同的資料集中。另一個例子是當我們嘗試在工作和候選人之間建立匹配演算法時。我們不希望向我們的模型作業顯示將出現在測試集中的資料。我們需要確保模型的所有部分絕對不會看到來自測試集中的任何資料。

不可用資料漏洞: 這是很常見的。有時，我們的資料中有的列在將來是不可用的。這裡有一個簡單的例子:我們想要預測使用者對我們網站上的產品的滿意度。我們有很多歷史資料，所以我們用它來建立模型。我們有一個叫使用者滿意度的欄位，它是我們的目標變數。從調查結果看，使用者滿意度還不錯。然而，當我們在生產中使用我們的模型時，它會造成絕對非理性的預測行為。結果表明，除了總體使用者滿意度之外，使用者還提供了其他欄位，比如使用者是否滿意交付、發貨、客戶支援等等。對我們來說，這些欄位在預測時是不可用的，並且與一般使用者滿意度有很大的相關性(和預測性)。我們的模型使用它們來預測總體的滿意度，並且做得很好，但是當這些領域不可用的時候(我們把它們歸為一類)，這個模型就不需要佔太大的比重。

機會和運氣

讓我們回到典型與非典型話語問題。正如我說的，只有30個參與者，所以如果我做一個簡單的20%-80%的訓練-測試分級，我只會讓6個參與者來測試。6個參與者非常少，我可能只是碰巧把其中的5個分類正確，因為運氣。這將給我100%的準確性!這個結果可能看起來很優秀，當我釋出我的結果時，它看起來會非常令人印象深刻，但事實上這個分數並不重要(甚至並不真實)。

這裡正確的方法是“省略一個交叉驗證”，並使用所有的參與者作為測試。

人

將學習演算法與人類進行比較是很有吸引力的。這在很多醫學領域都很常見。然而，比較人類和機器並不是一件小事。假設我們有一個可以診斷罕見疾病的演算法。我們已經看到，對於不平衡的資料，使用精度作為測量標準不是一個好主意。在這種情況下，如果我們使用精度和查全率來進行模型評估和比較，可能會更好。我們可以使用精度和一些醫生的查全率，並將其與我們的演算法進行比較。然而，在精確和查全率之間總有一個權衡，我們並不總是清楚我們想要的是什麼，高精確度還是高查全率。如果我們的演算法有60%的準確率和80%的查全率，醫生有40%的準確率和100%的查全率，誰更好?我們可以說演算法精度更高，因此演算法“優於人類”。此外，作為一種演算法，我們可以控制這種權衡，我們需要做的就是更改分類閾值，並將精度(或查全率)設定為我們想要的程度(看看查全率會發生什麼)。

因此，更好的選擇是使用ROC AUC評分或“平均精度”進行模型評估。這些度量考慮了精確-查全率權衡，並提供了關於我們的模型如何“預測”的更好的度量方法。人類沒有ROC自動控制系統，也沒有“平均精度”。我們(在大多數情況下)不能控制任何一個醫生的這個閾值。有不同的技術可以為一組人類決策者提供精確的查全率曲線，但這些技術幾乎從未使用過。這裡有一篇關於這方面的文章，非常棒，而且要詳細得多:

機器真的能打敗醫生嗎?ROC曲線和效能指標

醫學的深度學習研究現在有點像美國西部淘金時代：有時你會發現金子，有時你會發現……

結論

在這篇文章中，我展示了當我們嘗試釋出一些演算法結果或解釋其他結果時可能出現的不同陷阱。我認為從中得出的主要觀點是“當它(結果)看起來好得讓人難以置信時，它很可能真的不可信”。當我們的模型(或其他模型)看起來非常好時，我們必須確保過程中的所有步驟都是正確的。