「碰！」
隨著遠方廠區反應爐安全閥頂破、伴隨濃煙與震耳欲聾的爆炸聲落下，台北總部頂樓的冷氣會議室頓時炸開了鍋。
投影幕上還停留在幾分鐘前廠區回傳的即時大儀表板——壓力指數全線綠燈、設備震動完美合規，甚至連過去兩年每季定期上繳的自主巡檢報告，每一筆數字都無懈可擊地落在標準管制線正中央。
大老闆緩緩摘下眼鏡，會議室裡的空氣瞬間降到冰點。
「每季的自主檢查都合格？所有指標都在管制線內？」董事長抬起頭，嘴角揚起一抹極度冰冷的冷笑，白板筆重重敲在投影幕上的那條平直線上：
「整整兩年、七百多個日子，你交上來的監控數據，每一次都剛好長得一模一樣？！」
回到這場爆炸會議的開頭。翻開設備維護紀錄，每一項巡檢指標都「完全合規」、全數打勾，但拉出監控歷史一查，感測數值整整一年完全沒動過。
現場實際情況就是人為疏失，至於是哪個人的責任這裡就不提了。但在製造現場，常見的情況不外乎兩種：
很多人做專案有一種慣性思維：題目一開，連目標變數 Y到底長什麼樣都沒瞄過一眼，就抓著幾百個欄位稀哩嘩啦刻了一堆特徵X。
這種做法一點意義都沒有。
演算法的本質是映射Y = f(X)。如果你連要打的靶心（Ground Truth）是真是假都沒搞清楚，後續再花俏的特徵工程與模型調參，都只是在沙灘上蓋摩天大樓。所謂「標籤不歪」，講得最直白、最本質的一件事，就是數據必須具備真正的「代表性」。
在工業與企業現場，最常出現的黑色幽默就是：KPI 是一條毫無起伏的死平線。
這裡要分清兩種情況：如果是在高良率成熟產線，幾個月沒出瑕疵，那是極端不平衡資料（Imbalanced Data），該做的是異常偵測而不是回歸；但更常見、也更致命的，是物理數值根本沒在動的「假定值」。
沒有變異（Variance），就沒有資訊。演算法是靠著變數之間的共振波動在摸索因果與規律；如果目標變數常年不動，你的模型到底是在學物理規律，還是在陪著系統的假象學寂寞？拿這種毫無變異的假定值當 Ground Truth，專案做出來的預測系統除了自欺欺人，只能等著現場實體設備用一聲巨響來替你揭曉真相。
標籤的質，往往就爛在大家對「平均值」的盲目崇拜，以及缺乏對物理常識的敬畏。
前面章節曾提過那個在頂級醫學期刊（SCI）裡發現「血壓是負數」的荒謬活人案例。活人的血壓怎麼可能是負的？但這筆荒誕的數字，就這樣被直接算進平均值裡，一路暢行無阻地產出顯著的統計成果。這正是平均值最危險的地方：它能輕易抹平荒謬，讓人對底層的致命錯誤視而不見。
所以，在檢視任何目標變數與特徵時，請務必養成「看最小值（Min）與最大值（Max）」的習慣：
當你把資料畫成盒鬚圖（Box Plot）時，如果發現「盒寬（IQR = Q3 - Q1）極小，而平均數卻比整個盒子還要大」，這就已經亮起刺眼的警訊。
更致命的陷阱在於工業現場的編碼慣例：有些機台場景習慣用 999、9999 或 888 這類數值，來表示「量測達到硬體上限」或是「根本沒有這個值（Null/Sensor 斷線）」。
如果底層感測器經常斷訊或破表，導致 999 剛好變成了這批資料的「眾數」，而分析人員又無腦地直接取平均——那你算出來的平均值簡直慘不忍睹，會徹底與現實物理世界脫鉤！
所以我自己做專案時，算完平均數之後，絕對、絕對會拜託現場師傅或製程工程師幫我瞄一眼。
我會直接問他們：「這個平均值，你們聽起來跟現場實際狀況會不會脫鉤？」
這一步千金難買。在實務上，只要現場老手眉頭一皺、嘴裡吐出一句「這數字怪怪的」，八成就是前置的資料處理在哪個環節出現疏漏了。
談完數據的「質」，我們來看下一個核心議題——「量」。
常聽到有人問：「做這個題目，我要準備多少資料量才夠？」
換個更接地氣、更具商業靈魂的問法，其實就是：
「你拿多少東西來驗證，你才能有信心它足以代表未來的使用場景？」
這牽涉到資料代表性從「普查」與「抽查」的本質分野。
談到量這件事情，俗話說夏蟲不可語冰；對於資料有明顯季節效應的場景更是如此。雨季時防水用品需求量大，夏天大家排隊要吃冰。如果你手邊拿的是乾旱季或嚴冬整整三個月的完整歷史資料，看似筆數海量、採樣扎實，拿去推估梅雨季或盛夏的需求，當然會牛頭不對馬嘴！你的訓練資料如果只涵蓋了局部週期，根本不具備推估未來場景的代表性。
在 Kaggle 競賽裡，平台早就幫你準備好了幾十萬筆切割工整的樣本；但在真實企業現場，光憑「訓練量」這件事情，某種程度在初期就能決定這案子的生死。
曾經有個公司內部委託的專案找上門，業務是做會計審計與單據查核。開會時業務單位信誓旦旦地說：「我們資料非常多！只是平常準備起來很困難。」
結果團隊在旁邊搞了老半天、等了又等，對方千辛萬苦最後「先給了 10 份單據」。
拿到那 10 筆資料時我整個人愣在原地：這東西到底要怎麼驗證？拿 8 份訓練、留 2 份拿來看結果好不好？這在統計與機器學習上根本毫無信心可言。更何況，就算這套系統真的被硬做出來上線了，全公司每個月難道真的有足夠的需求量來支撐這套軟體的維運嗎？
這是不符合投入產出比的死局，我當場評估後直接回絕不接。
但會計單位基於當初向上呈報的立案壓力，轉身找了外面的廠商做。廠商為了做生意，開開心心地接下合約，拍胸脯說「絕對沒有問題」。後續的結局毫不意外：系統硬著頭皮上線後，遇到真實環境的未知單據直接全面炸掉，最後雙方撕破臉，直接辦理「異常結案」。
資料量太少無法代表未來，但資料「太多」往往也不見得是好事。它不僅僅帶來雜訊（Noise），更可能是底層資料處理管線出了嚴重問題。
曾經有專案同仁在特徵工程與模型收斂上徹底卡關，愁眉苦臉地跑來問我演算法上有沒有其他想法。
我把他的資料接過來，做了一輪最基礎的檢視與清理。清理完後我隨口問他一句：
「你現在模型的輸入資料筆數，總共有多少？」
同仁很有信心地回答：「4 百多筆！」
我整個人愣了一下，盯著螢幕上的原始日誌看著他：
「……你從現場拿到的原始資料才 300 多筆，中間我還沒提資料清理時剔除的髒資料，你處理完後的筆數怎麼會比原始資料還要多？！」
結果追查下去才發現，他在清理資料的某個環節多寫了一個迴圈，導致部分資料被硬生生重複放大了 5 倍（我也不知道怎麼會這麼瞎）。
如果你有看過正規的生物醫學期刊，他們在論文裡展示資料筆數時，是有嚴格的流程圖（Flowchart）的——從原始收案多少人、排除條件是什麼、每一步驟減少多少筆資料，每輪的縮減都必須清清楚楚標註原因。這在學術與嚴謹工程上幾乎是標準流程。連前處理後的筆數到底有沒有邏輯閉環都沒驗證，就急著去找高深的演算法解法，只會讓模型在人為複製的虛胖幻象中徹底翻車。
當然，有人會說：「工程師，你上面講的這些看極值、確認物理上下界、找現場校對平均值、檢查管線筆數的方法，特徵變數 X 不也應該全部照做一遍嗎？」
沒錯，理論上 X 當然也得這麼做。
但現實是極度骨感的：現場的特徵欄位動輒幾十個甚至上百個，而你在摸底階段通常只有短短 14 天，手頭上往往也絕不會只有這 1 個案子要顧。在資源與時間被壓縮到極致的戰場上，你不可能第一天就把幾百個 X 全部地毯式排查一遍。
所以，先看 Y。
先看 Y，最核心的價值是幫忙確認整個專案的「問題定義」到底有沒有錯、有沒有哪些關鍵的 Domain 知識在立案時被徹底漏掉了。 只要看到數據分佈有任何違背物理常識的怪異之處，第一步就是拿著數字直接去問現場。
這件事情，在學校課堂或 Kaggle 競賽裡通常根本沒有人會教你。教科書永遠把一切當成理所當然——考卷發下來直接跟你說「Y 是預測病患死亡率」、「Y 是預測房地產價格」，接著所有篇幅就急不可耐地切入後面的特徵工程怎麼做、變數怎麼篩選、有哪些最新最潮的演算法可以套用。
但在真實世界裡，根本沒有人會把乾淨端正的靶心雙手奉上。先看 Y 非常重要，而在實務上它最大的好處往往只有一個：看完 Y，有時候你就可以直接喊停了。
先看 Y 是為了以最快速度踩下煞車。如果連唯一的靶心都是假的、是條毫無波動的死平線、缺乏變異、或者有效樣本數連 10 筆都湊不齊，這題在第 3 天就能乾脆地宣告陣亡撤案，及早少掉一整件注定失敗的白工。
但如果 Y 幸運地過關了，你也先別高興得太早——因為更多專案的真正死因，是靶心立得極其端正，但當你轉身準備拉弓時，才驚恐地發現裝箭的箭筒（X）裡，根本空無一物。
說完了 Y。如果我們初步檢視下來，目標變數有變異、物理合理、樣本數足夠、而且也禁得起現場老師傅的常識拷問——恭喜你，靶心終於定下來了。
但接下來，你得面對更殘酷的泥淖：那特徵變數 X 該怎麼處理？
面對工廠裡動輒幾百個感測點、看似豐富的海量資料庫，現場長官總會拍著胸脯向你保證：「放心，我們這幾年投了幾千萬做數位化，機台數據全都有留存，要什麼有什麼！」
然而，當你真正挽起袖子走進資料管線，才會驚恐地發現：很多欄位號稱「都有存」，但它究竟是即時客觀的物理事實，還是充滿斷點、抽樣失真與人工粉飾的空氣？沒有米，再深的神經網路也蒸不出一碗熟飯。
下一篇，我們來拆解專案暴斃的第三個元兇：《第十三章｜危險徵兆 3：巧婦難為無米之炊——關鍵數據（X）的重要性》。
iThome鐵人賽
看影片追技術