跳至主要內容

    缺失值、重複資料與異常值怎麼處理?

    先追查資料為什麼變成這樣,再決定刪除、修正、填補或保留,避免把真正重要的樣本清掉

    sunny 桑尼· · 18 MIN READ · 147 次瀏覽

    缺失值、重複資料與異常值怎麼處理?
    本文目錄

    資料裡有空白,就補平均;看到特別大的值,就刪掉;訂單編號重複,就只留一筆。這些動作很容易寫成程式,也很容易把一份資料清得失去原本意義。

    一張訂單還沒送達,配送時間當然可能是空白;同一張訂單有三個品項,訂單編號就會出現三次;大雨時配送60分鐘,雖然少見,卻可能正是你希望模型能處理的情況。

    資料清理首先要回答:這是記錄錯誤、尚未發生的結果、合理的重複結構,還是真正的極端事件? 接著才選擇處理方法。這篇用原教材的前後對照圖拆開各種動作,並說明它們會改變什麼。

    先固定一列的意義,再談重複

    假設分析單位是一張訂單,主鍵是 order_id。某批資料因為重送而把完全相同的紀錄存了兩次,確實應該按事先定義的去重規則處理。否則這張訂單就會在平均、總額與模型訓練中得到雙倍份量。

    圖1|來源示例把一整段數值重複記錄。重複的是紀錄結構,不能只因兩筆數值相同就判定為重複樣本。來源:Google,Numerical data: Scrubbing,CC BY 4.0,原圖未改。

    但如果一列是一個訂單品項,主鍵就可能是 order_id + line_id。同張訂單出現三次,是三個不同品項,不該只按訂單編號保留一列。時間序列也可能對同一設備每分鐘記一筆,設備編號重複完全正常。

    遇到同一個主鍵、內容卻不一致時,先查資料更新規則:是不同版本、部分欄位晚到,還是合併資料源發生衝突?「留最後一筆」只有在時間戳與版本定義可信時才有意義。處理後也要確認連接其他表格時,沒有把一對多關係意外放大。

    超出範圍,不一定等於應該截斷

    有些欄位有可驗證的限制,例如商品件數不能為負,訂單建立時間不應晚於同一筆紀錄的完成時間。這些檢查適合直接做成規則,輸出待追查紀錄。

    圖2|Google先設定有效溫度範圍為10到30,再指出98超出範圍。判定依據是欄位規格,不是「98看起來很大」。來源同圖1,原圖未改。

    發現異常後,優先找可恢復的原始資料:是否把秒當分鐘?把分當元?文字小數點是否解析錯誤?能從正確來源修復,就比任意改成平均值更有依據。

    反過來,60分鐘的配送可能完全有效。如果你的目標是預警嚴重延遲,刪掉它,正好會移除最需要辨認的情境。統計上的少見與業務上的錯誤,需要分開。

    缺失值先保留原因,不要急著變成0

    空白至少可能代表三種不同狀態:沒有收集到、不適用,或結果尚未產生。資料系統若把它們都存成空字串,你要先回到來源分辨;必要時新增狀態欄,而非只保留一個模糊的空白。

    以配送時間為例:尚未送達的訂單若全部被排除,報表就可能只剩較快完成的訂單。把它補成平均也沒有解決問題,因為你不知道真正的完成時間。特別是要預測的答案缺失時,不能把補出的數值當成已觀察標籤來驗證模型。

    若缺的是預測當下可用的輸入特徵,則可以比較刪除樣本、填補、缺失指標或支援缺失值的模型。選擇要看缺失機制、比例、資料量與使用情境,沒有通用的「缺超過幾成就整欄刪除」門檻。

    均值與中位數填補:讓程式可用,也改變了分布

    假設一個教學特徵有四個已知值 [10,12,14,60],第五個值缺失。已知值的均值是24,中位數是13。補24或補13,都是以觀察到的其他資料猜測缺口,不是找回那筆資料的真值。

    若補均值24,五筆的平均仍是24,卻把一筆原本未知的觀察固定放在中心,讓變異的估計改變。若補中位數13,新的平均變成21.8;中位數對60較不敏感,也不表示13就一定更接近缺失的真值。

    圖3|來源使用房屋資料的LotFrontage,右側把缺失補成訓練集均值,於填補位置產生明顯集中。這是均值填補示例,不能從圖上推論中位數填補的效果。來源:Feature-engine,MeanMedianImputer,Feature-engine developers,BSD 3-Clause,完整聲明見文末;原圖未改。

    填補值還會影響特徵彼此的關係:多個未知值被放進相同位置,可能削弱原本的相關結構,也可能在模型裡形成特殊聚集。因此,做完後要同時看缺失率、填補位置、分布與下游驗證結果。

    可以另外加一欄 was_missing:原本缺失的列為1,其他為0。這讓模型有機會分辨「實際量到24」與「因缺失而補成24」。但缺失指標也可能記住某個舊系統或特定採集流程,資料流程換了就要重驗。

    類別缺失:新增「未知」,不要混進一個真實類別

    城市缺失時,補成最常見的「台北」很方便,卻會把未知訂單當成已知台北。另一種做法是設一個獨立類別,例如「未提供」,清楚保留資訊缺口。

    圖4|來源的房屋材料類型MasVnrType補入字串missing後,右端出現一個很小的新類別。原有的字串None本來就是合法類別,不能把它和真正的NaN當成同一件事。來源:Feature-engine,CategoricalImputer,BSD 3-Clause,完整聲明見文末;原圖未改。
    圖5|另一種策略用最常見的類別填補,本例是字串None,缺失資料因此併入該類,沒有獨立的missing柱。兩圖比較不同填補策略,不是填補前後;使用的是來源測試資料,未展示本文訂單分布。來源同圖4,原圖未改。

    「未知」也應該和「不適用」分開,例如沒有折扣資格,與折扣資格尚未查得,對業務決策可能完全不同。處理後還需編碼成模型能接受的表示;不是把NaN改成文字,任何估計器就都能直接使用。

    用−999代表缺失,距離與尺度也會跟著改變

    任意常數填補會選一個特殊數值,例如−999,把缺失資料放到明顯的位置。好處是規則簡單;代價是對許多模型而言,這仍然是一個普通數字。

    圖6|來源將LotFrontage缺失補成−999。藍線是原始非缺失資料、紅線是填補後;原圖兩個圖例同名,本圖說補充其區別。KDE是平滑估計,不能把負值區域的平滑尾端當成額外測量資料。來源:Feature-engine,ArbitraryNumberImputer,BSD 3-Clause,原圖未改。

    對依距離找鄰居的模型,−999可能讓缺失樣本彼此很近、與其他樣本很遠;對線性模型,極端數值可能放大某一項的作用。樹模型可能藉一次分割把它隔開,但仍需要驗證,不能因模型能執行就認定方法合適。

    有些估計器,例如scikit-learn的HistGradientBoosting系列,可原生處理數值特徵中的NaN。這讓「保留缺失並讓模型學處理方式」也成為候選,但不會免除追查缺失原因與監控流程改變的工作。

    截尾:保留樣本,壓住極端數值

    如果你有明確理由限制極端特徵對模型的影響,可以設定上下限,把超出範圍的數值改成邊界。這常稱clipping或capping。它保留樣本,但捨棄極端值之間的差異。

    圖7|來源的rooms per person特徵有長尾。少見的高值需要查資料定義與真實性,不能只因位於尾部就認定錯誤。來源:Google,Numerical data: Normalization,CC BY 4.0,原圖未改。
    圖8|高於4的值被壓到4,右端因此堆積。原圖同時放大橫軸0–4的範圍;不要只憑柱子變高,就認為樣本突然增加。來源同圖7,原圖未改。

    例如把前面四個值的上限設成40,資料就從 [10,12,14,60] 變成 [10,12,14,40],均值從24變19。這是本文的算術示例,不是建議配送時間一律設40分鐘上限。若要分析延遲尾端,把真實60改成40,會直接改掉你要研究的現象。

    實務上可以保留原欄,另外產生供模型使用的截尾欄,並記錄規則與被改動比例。新資料若大量撞上邊界,可能是原本規則不再適用,也可能是上游資料出錯,需要分開追查。

    哪個填補方法比較好,要放回同一個驗證問題

    較複雜的填補方式可能利用鄰近樣本,或以其他特徵輪流預測缺口。多做一層模型,會增加計算與假設,也可能改變下游模型的誤差。

    圖9|來源先在人為設定的位置移除特徵值,再用隨機森林回歸比較填0、均值、KNN與迭代填補,並加入缺失指標。橫軸MSE越小越好,誤差棒為交叉驗證分數的標準差,不是自動等同95%信賴區間。左右是不同資料與尺度,不能直接比數值大小。來源:scikit-learn developers,Imputing missing values before building an estimator,BSD 3-Clause,完整聲明見文末;原圖未改,本文未重跑此實驗。

    這類比較回答的是「在該缺失模式、資料與估計器下,哪個方法的驗證誤差較小」。現實中若剛好是高額訂單較容易缺資料,結果可能不同。因此不能把一張比較圖當成某個填補法永遠第一名的證據。

    還有一個必要的順序:先切分資料,再只用訓練資料估計均值、中位數、最常見類別或資料導出的截尾門檻;驗證與測試資料只套用已學好的規則。 交叉驗證時,每一折也要重新用該折訓練資料估計,不能先對整份資料填好再切。Pipeline可以幫你把這個順序固定下來。

    清理完成後,留下能追查的結果

    一份有用的清理紀錄應該讓下一個人知道:原本一列代表什麼、哪些欄位違反規格、修復依據來自哪裡、多少列被刪除或改動,以及填補值從哪一批資料估出。

    清理前後都要看分布與分組。如果某個城市被刪掉一半資料,整體缺失率下降不能單獨代表品質變好;如果延遲訂單大量被當成異常移除,模型可能只是失去困難樣本。

    把資料整理到能執行,是第一步。把每個動作對問題的影響說清楚,才算完成這一輪清理判斷。

    來源與圖像授權

    文中的四個已知值、均值/中位數與40上限都是另外設計的教學算例,沒有代表來源的房屋資料或實際營運訂單。

    圖像授權聲明

    以下保留Feature-engine與scikit-learn原圖的完整BSD著作權、條件及免責聲明;原作者沒有為本站背書。

    BSD 3-Clause License
    
    Copyright (c) 2018-2024 The Feature-engine developers.
    All rights reserved.
    
    Redistribution and use in source and binary forms, with or without
    modification, are permitted provided that the following conditions are met:
    
    1. Redistributions of source code must retain the above copyright notice, this
       list of conditions and the following disclaimer.
    
    2. Redistributions in binary form must reproduce the above copyright notice,
       this list of conditions and the following disclaimer in the documentation
       and/or other materials provided with the distribution.
    
    3. Neither the name of the copyright holder nor the names of its
       contributors may be used to endorse or promote products derived from
       this software without specific prior written permission.
    
    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
    IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
    DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
    FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
    DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
    SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
    CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
    OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
    OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    
    BSD 3-Clause License
    
    Copyright (c) 2007-2026 The scikit-learn developers.
    All rights reserved.
    
    Redistribution and use in source and binary forms, with or without
    modification, are permitted provided that the following conditions are met:
    
    * Redistributions of source code must retain the above copyright notice, this
      list of conditions and the following disclaimer.
    
    * Redistributions in binary form must reproduce the above copyright notice,
      this list of conditions and the following disclaimer in the documentation
      and/or other materials provided with the distribution.
    
    * Neither the name of the copyright holder nor the names of its
      contributors may be used to endorse or promote products derived from
      this software without specific prior written permission.
    
    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
    IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
    DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
    FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
    DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
    SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
    CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
    OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
    OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    

    封面沿用本篇已註明來源的配圖,僅等比縮放並加白邊以保留全圖;圖片原有的署名與授權條件同樣適用於封面版本。

    留言0

    登入後就能留言。

    登入
    sunny 桑尼
    sunny 桑尼

    AI 資料科學 · 產品經理 · 蒙奇 D 桑尼

    專注於 AI 工具應用與資料科學教育,致力於讓每個人都能用 AI 提升工作效率。曾任職於科技業,現為全職教育創作者。

    讀更多文章 →想自己動手試?領免費 Starter Kit →