企業 AI 的「最後一哩」問題:PoC 到生產線之間到底卡了什麼?

企業 AI 的「最後一哩」,指的是模型在 PoC 環境裡跑得通、Demo 現場人人點頭,卻無法在真實業務流程中被穩定使用、被員工信任、被納入日常決策的那一段落地距離。它不是技術問題,是把技術嵌進「這一家公司」的問題。

我先講一個現場。某製造業客戶花了一季做出一套設備異常預測模型,離線測試準確率 91%,結案報告漂亮到可以裱框。半年後我進場,產線根本沒人看那個儀表板。原因不是模型爛,是它預測出來的告警,平均比現場老師傅的直覺晚 40 分鐘,而且不會告訴人「該關哪一台、找誰」。技術上它答對了,業務上它遲到了。這就是企業 AI 最後一哩的典型死法:通過了驗收,通過不了現實。

死因一:資料在 PoC 是乾淨的,在生產線是髒的

PoC 階段的資料,通常是人工挑過、對齊過、去過重的一份「樣品」。它安靜、完整、格式一致。真實生產線的資料是活的:欄位會臨時新增,同一個客戶名在三個系統裡有三種拼法,ERP 昨天半夜跑批把時間戳全改成 UTC,上游一個表單改版就讓你的 pipeline 靜默吐出空值。

我們踩過最痛的一次,是一套合約審閱 RAG 系統。測試用的 200 份合約都是 PDF 文字層完整的版本,上線後才發現客戶真正的存量合約有六成是掃描件,OCR 完的文字錯字連篇,模型引用的條號整段對不上。PoC 沒有錯,錯在它從沒見過這家公司資料真實的樣子。落地缺口的第一個,永遠是資料的熵。

死因二:權限,是 Demo 從不處理的那道牆

Demo 帳號通常是超級管理員,看得到所有資料,所以 Agent 什麼都查得到、什麼都答得出來。真實企業裡,權限是業務邏輯本身。業務員不能看到別人的客戶名單,分行 A 不能碰分行 B 的授信資料,HR 的 Copilot 絕不能在小主管面前把薪資帶進上下文。

問題在於,RAG 和 Agent 的檢索層天生是「越權」的——它為了答得好,會把所有相關文件都撈進來。你必須在檢索、重排、生成每一層都把權限邊界重新織進去,而且要能對每一次引用做稽核。這件事在 PoC 幾乎不存在,在生產線卻是能不能上線的一票否決權。很多案子不是死在模型不夠聰明,是死在資安部門問了一句「這答案的來源,這個人本來有權限看嗎?」,然後全場沉默。

死因三:邊角案例,才是使用者記住你的地方

Demo 只演 happy path。使用者卻專門用邊角案例來判斷一個系統值不值得信任。第一次問了一個罕見情境,系統一本正經地胡說,信任就崩了,之後再準也沒用——這就是採用率卡在個位數的心理機制。

下面這張表,是我們把常見缺口對照 PoC 與生產線兩種狀態的整理:

會發現,真正卡住的那幾格,沒有一格是「模型能力」。它們全是把系統嵌進組織的工序。

最後一哩,是工程,不是加購

這幾年我們學到一件事:最後一哩不能靠買一個更強的模型跨過去,它是靠人蹲在客戶現場,一週一週把資料管線、權限模型、失敗兜底、責任流程一項項織進去,織到真的有人願意每天打開它。這也是我們把交付定義成「工程師進場」而不是「交付一份報告」的原因——Demo 很美不算數,上線且有人在用,才算過了那一哩。