拆解一個上不了線的企業 AI PoC:從 Demo Day 到停在原地的完整病歷

先講結論:這個 PoC 不是被技術殺死的,是被「沒有人負責讓它上線」這件事慢慢餓死的。

去年底我們被找去救一個案子。一家中型製造業客戶,想做一套內部知識問答,讓現場工程師用自然語言查設備維修手冊與歷史工單。他們找了一家不錯的整合商,做了三個月 PoC,Demo Day 那天我在場——回答又快又準,主管當場拍板要全廠推。半年後我們接手,系統還躺在測試環境,實際使用者:零。

這是一個很典型的企業 AI PoC 失敗案例。典型到我們把它的病歷拆開,幾乎每一條死因都能在別的專案上重演。所以這篇不談抽象方法論,只還原這一個病人的每一處病灶。

病歷摘要

死因一:Demo 用的是「精選過的 32 份文件」

我調出他們 PoC 的資料流,發現向量庫裡只有 32 份文件。全是整合商挑過、清洗過、格式統一過的漂亮 PDF。Demo 的那些問題,答案剛好都在這 32 份裡。

但這家公司真實的維修知識,散在 1.4 萬份工單、掃描件、Excel、還有老師傅腦袋裡。當我們把真實語料灌進去重測,同一批問題的正確率從 Demo 的「感覺 95%」掉到 41%。不是模型退步,是 Demo 本來就在一個不存在的世界裡跑。

教訓很直白:任何沒有在真實髒資料上測過的準確率,都不是準確率,是化妝照。 我們現在接案,第一週一定堅持用客戶最亂的那批真實文件跑基準,寧可 Demo 難看,也不要上線才發現落差。

死因二:整個專案沒有一個「上線 owner」

我問了一圈:這套系統上線後歸誰管?IT 說這是業務單位提的需求;業務單位說模型是 IT 在維護;整合商說我們負責到 PoC 驗收為止。

三方都對,合起來就是沒有人。

PoC 有明確的 owner——那個要拿專案獎金的窗口。但「讓 200 個現場工程師每天真的去用」這件事,合約裡沒寫,KPI 裡沒有,沒有人早上醒來覺得這是自己的責任。企業 AI 死在這一關的比例,遠高於死在模型能力。系統不會自己爬上生產線,得有一個人扛著它上去,還要在上線後守著它,看數據、修 badcase、逼流程改。

死因三:準確度變成一個永遠不會結束的藉口

卡關的官方說法是「準確度還要再調一下」。聽起來很負責。實際上這是一個沒有終點的坑——因為從來沒有人定義過「調到多少就上線」。

沒有驗收線,任何 badcase 都能無限期拖延上線。我們進場後做的第一件殘忍的事,是逼他們坐下來訂一條線:知識問答只要在 Top-3 引用裡給對答案、且附原文出處,就算通過;剩下的 badcase 進待辦,不阻擋上線。三天後,系統上了。上線兩週的真實使用數據,比他們調了半年的猜測有用一百倍。

死因四:沒有為「人願意用」設計任何東西

就算前面三關都過了,這系統還是會冷掉。因為它被設計成一個獨立網頁,工程師要另開瀏覽器、另登一次入、把問題重打一遍。現場的人手上戴著手套、盯著設備,誰會為了查一條資料切三個視窗。

真正的採用,得長在既有動線裡。我們後來把入口塞進他們原本就在用的工單系統,查詢直接帶出關聯手冊段落。使用率不是靠推廣爬起來的,是靠「不用改變習慣」爬起來的。上線一個月,週活躍到了 63%。

這份病歷想留下的一句話

回頭看,這四個死因沒有一個是「AI 不夠強」。模型從第一天就夠用了。它死於資料造假的 Demo、無人認領的責任、沒有終點的完美主義,以及把「能跑」誤當成「有人用」。

這也是為什麼我們在 Tenten 做 FDE(前線部署工程)時,工程師是進場到客戶現場、扛著上線與採用指標的,而不是交付一個驗收完就沒人管的 Demo。Demo 很美不算數,螢幕上跑得動也不算數;上線、而且真的有人每天在用,才算數。