發表文章

把資料變成資訊：二十年前我要求部屬做的事，今天叫 AI 品保

我接下整個處的時候，第一件動的不是設備，是 人手裡的剪貼簿 。 那時候的品質工作是這樣運作的：檢驗員在機台前量完，把數字抄到紙上或鍵入表單；有人把它整理進試算表；再有人把幾張表湊成一張報告；最後在會議上，大家看著那張報告討論。 從量測到看見，中間隔了三次人工搬運。 我提的要求只有一句： 檢驗數據要能從量測機台自動下載，然後直接判定合格或不合格。 進料、製程、出貨三道檢驗都一樣。這是我的最低要求，不是理想。 一、剪貼的代價，不是時間 多數人反對自動化的理由是「現在這樣也做得完」。確實做得完。但剪貼的代價從來不在時間上。 每一次人工搬運，都是一次可能出錯的介入，而且不留痕跡。 你在報告上看到一個數字，它已經被搬過三次。如果它是錯的，你無法回頭指出是在哪一次搬錯的——中間沒有任何紀錄。 還有一個更安靜的代價： 人會順手修一下 。看到一個明顯不對的值，順手改成合理的；看到一格空白，順手補上前一筆。每一次都是善意，每一次都讓資料離現場更遠一點。 自動化真正買到的不是速度，是 可追溯 。 二、順序不能顛倒：標準化 → 自動化 → 簡化 我當時給的順序是這三個詞，而且順序是有意義的。 標準化在最前面。 因為自動化是放大器——你把一個沒有統一判準的流程自動化，只會得到「更快、更大量、更一致地做錯的事」，而且因為它是機器做的，沒有人會去質疑它。 所以自動化之前必須先回答： 這個項目的合格線在哪裡？誰訂的？寫在哪份文件上？ 答不出來，那就不是自動化的問題，是這個檢驗項目本身還沒被定義。 簡化排在最後 ，也是刻意的。簡化是自動化跑順之後的事——你要先看到完整的流程實際跑起來，才知道哪些步驟真的多餘。先簡化再自動化，砍掉的往往是你後來才發現需要的那一步。 三、「資料」和「資訊」差在哪裡 我當時說的是： 我要資料在第一時間變成資訊。 這兩個詞平常混著用，但在品質工作裡它們差很遠： 資料 資訊 是什麼 一個量到的值 一個已經被判讀過的狀態 例子 「這片的厚度是 X」 「這片合格／不合格／要複檢」 能不能行動 不能，還要有人判 能，可以直接決定下一步 誰在等 沒人等，它躺在檔案裡 現場在等，它決定這片往哪走 資料躺著不會自己變成資訊，中間那一步一定有人在做判讀。 問題是：那個判讀如果發生在「人事後看報告」的階段，那就太晚了——片子早就流到下一站了。判...
張貼留言
閱讀完整內容

可靠度是設計出來的，不是測出來的

那半年，是我這輩子第一次看清楚一件事： 一個產品可以每一項製程指標都漂亮，同時完全撐不住時間。 一、那時候看起來全是好消息 新廠的設備一台一台到位，第一批面板開始產出。我負責的那個關鍵結構是我自己設計的，鍍膜、結構參數，到那時候對我來說已經稀鬆平常。尺寸一階一階往上做，離量產看起來越來越近。 公司甚至從國外買了一套模擬軟體來算，但真正把參數定下來的，還是一輪一輪的實驗設計。所有人都覺得這個產品已經成了。 那時候沒有任何一張報表是紅的。 二、我為什麼不信 因為 沒有人量過時間 。 我們量的都是「現在」：厚度、均勻性、亮度、良率。這些數字回答的是同一個問題—— 今天做出來的這一片，合不合規格。 沒有一個數字回答另一個問題： 它明年還在不在。 這兩個問題不是同一件事，而且第二個比第一個難得多。第一個問題你當天就能知道答案；第二個問題，你要嘛等一年，要嘛用設計去推算。 那個產品是自發光的——每一個發光單元自己點火，背後有上千個電子元件在驅動它、產生高壓、送出畫面訊號。 元件越多，時間的風險就越不是一兩個零件的事，而是一整串的事。 一台整機當時的價格，大概等於一輛新車。做一次落摔測試，就是把一輛車摔在地上。所以沒有人想主動去問這個問題。 三、怎麼查——從最便宜的那一步開始 我那時候剛從製程被調去做品保，一個人的單位。我做的第一件事不是買設備，是 把最便宜的一步先做掉 。 第一步：去看已經在做的人怎麼做。 集團裡有另一個單位在做同類產品的可靠度認證，我先過去看他們的流程。不是去學技術，是去看 他們的判準長什麼樣 ——用什麼門檻、卡在哪一關、哪些項目是客戶真的會問的。這一步花的是交通費。 第二步：分清楚「算」和「測」哪個先。 這類產品的壽命有兩道關： 預測 （Prediction）和 實證 （Demonstration）。順序不能顛倒—— 預測先過，實證才有意義。 如果算出來就不夠，去測只是把錢燒掉，換一張你已經知道答案的報告。 這是整件事裡最省錢的一條判準，也是最常被跳過的一條。大部分人的直覺是「做個測試看看」，因為測試看起來比較像在做事。 第三步：預測其實沒有技術難度，是耐心活。 向每個元件的供應商要它的失效數據，照電路圖的串並聯關係算總和；再實測每個元件在機器上實際承受的最高負載，看它離額定值還剩多少餘裕；然後看關鍵元件有沒有備援。 公...
張貼留言
閱讀完整內容

判退率突然變好,先問尺有沒有變

一、一個看起來是好消息的數字 某天的品質日報上，一條產線的判退率從六成五掉到不到三成。 這是所有人都想看到的數字。當天的會議上，大家的討論很自然地往「哪個改善見效了」去走：是前段的參數調整？還是新的清潔程序？要不要複製到其他產線？ 我沒有跟著討論。我問了一個不太受歡迎的問題： 「那天，判的人有沒有換？判的標準有沒有換？」 二、為什麼我不信 品質數字有一個特性，和製程數字不同： 它是「判」出來的，不是「量」出來的。 線寬是量出來的，尺不變，數字就有可比性。但外觀判退不是——它經過一個人、一份限度樣本、一套判定標準。這條鏈上任何一環變了，數字就會跳，而製程可能一點都沒動。 更麻煩的是， 兩種原因造成的跳躍，在圖上長得一模一樣 ：都是某一天之後，均值換到另一個水準，而且穩定地停在那裡。統計上做變點偵測，兩者都會被抓出同一個日期，分不出誰是誰。 所以我的習慣是： 當判退率出現階梯式的大幅改善，先假設是量測系統變了，直到證明它不是。 這不是悲觀，是因為兩件事的後果差很多： 若是真的製程改善，你該去複製它。 若是判準改了，你複製的是一個不存在的東西，而且 你從此失去了跨越那一天比較的能力 。 第二種情況最傷的不是那一天，是 往後一整年的趨勢圖全部不能用 。 三、怎麼查 查證的順序是固定的，從最便宜的查起： 第一步：問人，不要先算。 那段期間判定人員有沒有異動？有沒有新人接手？有沒有因為人力調度換班？這個問題花五分鐘，卻能省下三天的分析。 第二步：查限度樣本與判定標準的版本。 限度樣本有沒有換一套？判定基準有沒有改版？文件有沒有留下生效日？ 這裡最常見的失敗是：標準確實改了，但沒有人把生效日記在品質數據旁邊 ，所以三個月後沒人記得。 第三步：對日期。 把變點日期、人員異動日期、標準改版日期三條時間軸疊在一起看。如果變點正好落在改版日或換人日的那一兩天，它幾乎不會是巧合。 第四步：看缺陷結構，不要只看總率。 這一步最有力。如果是真的製程改善，通常是 某幾類特定缺陷 減少，其他類別維持不動。如果是判準變鬆或換人，則往往是 某一類邊界模糊的缺陷整批消失 ——就是那種「判 A 也可以、判 B 也說得過去」的類別。 總率一樣降，結構卻完全不同。 第五步：找還在的實物。 如果那段期間的樣片還留著，拿改版前後的實物讓同一位判定人員重判一次。...
張貼留言
閱讀完整內容

AI 說「做好了」，不算數

一、一個看起來是好消息的回報 我讓 AI 幫我建一套品質報表系統。其中一頁是中文網頁，給現場主管每天看。 AI 回報：「已完成，已驗證。」 它不是隨口說說。它跑了程式，程式沒有報錯；它檢查了每個連結，連結都指得到檔案；它還派出好幾個「子代理」互相複查，每一層都回報通過。 前後十一天，它派了兩百多次子代理，留下兩百多 MB 的紀錄。每一份紀錄都寫著綠燈。 可是那一頁，主管打開來，中文全是亂碼。 二、為什麼那麼多綠燈都沒用 做了三十年品保，這個場景我很熟。只是以前出現在產線上，這次出現在 AI 身上。 問題不在 AI 不夠努力，而在它 驗的東西，跟使用者看到的東西，不是同一個 ： 「程式跑完沒報錯」——驗的是程式有沒有執行，不是畫面對不對。 「連結都指得到檔案」——驗的是檔案存在，不是檔案打開後看得懂。 「子代理互相複查都通過」——它們用的是同一套推論，錯在同一個地方，就一起通過。 品保的老話叫 共模失效 ：兩道檢驗站用同一把尺，一起量錯的時候，不會有任何一站報警。AI 派十個分身去檢查，如果十個都只是「再推論一遍」，就等於同一把尺量十次。 三、怎麼查出來的 最後抓到問題的，是另一個 AI。它做的事情非常簡單： 開一個真的瀏覽器，把那一頁點開，看一眼。 一眼就看到亂碼。再往下查，原因是網頁少了一行宣告文字編碼的設定。十一天沒抓到的問題，點一下就現形。 差別不在聰明，在 順序 ： 做法 它回答的問題 程式跑完、連結可解析、型別檢查通過 「看起來應該對」——這是推論 另一個 AI 再推論一遍 還是推論，只是多了一層 打開真的畫面、跑一次真的流程、看原始檔案 「實際上對不對」——這才是驗證 四、真相：順序倒過來，錯誤會被放大 我後來把這件事整理成一條規則，叫 驗證階梯 ，順序不准倒： 先接觸真實 ：打開畫面、實際跑一次、直接看原檔、親眼看圖。 再獨立審核 ：換一個沒參與製作的人(或 AI)去做第 1 步，不是去再推論一遍。 最後才機器化 ：量大了才派一堆代理、寫自動流程。它解決的是「量大」，不解決「真假」。 如果跳過第 1 步，直接做第 3 步，你得到的不是更可靠的檢查，而是 把錯誤工業化 ：同一個幻覺被分裝到好幾層，每一層都發綠燈，最後所有人都很有信心。 這跟工廠一模一樣：首件...
張貼留言
閱讀完整內容