為什麼 AI 專案要先做 PoC?一個省下六位數學費的習慣

我們看過的 AI 專案災難,劇情大同小異:規格書寫了三個月、系統開發了半年、預算燒了六七位數,上線後才發現模型在真實資料上的表現,跟當初簡報裡的示範差了十萬八千里。這種學費,其實花兩週和一小筆錢就能免掉——這就是 PoC(概念驗證)存在的意義。

我們自己養 AI 產品線,每一個功能在寫正式程式之前都先跑 PoC。不是因為我們特別謹慎,是因為模型帳單和開發工時都是自己付的,痛過就學乖了。

PoC 在驗證什麼?不是「能不能動」

很多人以為 PoC 是「做個 demo 證明技術可行」。錯,demo 誰都做得出來,挑十筆漂亮的測試資料,什麼模型都很神。PoC 真正要驗證的是三件事:

• 真實資料上的準確率:拿你自己的資料——包含那些格式亂七八糟、夾雜注音文和錯字的真實資料——跑至少一兩百筆,看模型的表現。不是廠商準備的範例,是你資料庫裡撈出來的原始樣本。
• 單位成本:每處理一筆要花多少 token、多少錢、多少秒。把這個數字乘上你的真實量體,看看規模化之後帳單長什麼樣。我們有個功能在 PoC 階段就發現成本乘開後不划算,直接改用小模型加規則引擎,省下的錢夠付好幾個月薪水。
• 錯誤的樣態:模型錯的時候是怎麼錯的?是明顯的錯(容易攔截)還是一本正經的胡說(危險)?錯誤樣態決定了你之後要建多少防護,這部分我們在 幻覺防護的工程做法 裡有完整展開。

兩週見真章的 PoC 怎麼設計

我們的標準流程,壓在兩週內:

1. 第 1-2 天:定義成功標準。開工前就白紙黑字寫下「準確率高於多少、單筆成本低於多少、就算通過」。先射箭再畫靶是 AI 專案最常見的自欺。
2. 第 3-5 天:準備測試集。從真實資料抽樣一至兩百筆,人工標好正確答案。這步最枯燥,但沒有標準答案的 PoC 只能得出「感覺還不錯」,等於白做。
3. 第 6-10 天:用最省事的方式接模型。不要建置架構、不要寫後台,一支 Python 腳本直接打 API 就好。這階段的程式碼是消耗品,寫漂亮是浪費。
4. 第 11-14 天:跑分、算成本、看錯誤樣態,對照第一天的標準,做決定。

PoC 最有價值的產出不是那個 demo,而是一個有數字背書的「做」或「不做」。

什麼結果該喊停

喊停不是失敗,是 PoC 的正常功能之一。我們自己的停損訊號:準確率離門檻超過十個百分點(提示詞優化通常只能撈回幾個點,補不了大洞)、單位成本乘上量體後超過現在人力成本(那你自動化是為了什麼)、或是錯誤樣態屬於「難以攔截的一本正經胡說」而場景又承受不起(例如涉及金額或法規)。遇到這三種,我們會直接跟客戶說先不要做,等模型再進化一代,或改小範圍切入。短期少接一張單,長期省下彼此的信任——這是我們一貫的做法。

PoC 過了,然後呢

通過的 PoC 會留下三樣資產:一份有數字的可行性報告、一組標好答案的測試集(之後正式開發的迴歸測試就靠它)、以及對成本結構的掌握(這直接決定訂價和規模策略,詳見 AI 專案的 ROI 怎麼算)。正式開發時,這些東西會讓你少走一半冤枉路。

收束成一句:在 AI 專案裡,兩週的 PoC 是你能買到最便宜的保險。如果你手上有個想法,不確定值不值得驗證,歡迎 找我們聊聊,或先看看 AI 應用開發服務 我們是怎麼做這類專案的——我們的報價單裡,PoC 永遠是獨立的一期,做完你隨時可以喊停,不用被綁著走完全程。