能跑的 Demo 距離可靠產品還差一整套測量系統
我最近重新思考一個很常被低估的問題：為什麼很多生成式 AI Demo 看起來很驚艷，真正接進產品後卻開始失控？嚴格來說，差距通常不在 prompt 還能不能再精修一點，而在團隊有沒有把模型當成一個需要持續測試、監控和回滾的工程系統。
在研究室裡，我們常用一個 benchmark 分數描述模型好不好；但真人使用時，輸入不會乖乖落在測試集分布裡。有人會漏打字、貼進奇怪格式，有人刻意繞過限制，也有人問到系統根本沒設計過的 edge case。因此，真正有用的評測集不能只有幾個漂亮的 happy path，而要同時包含一般問題、邊界情境，以及對抗性輸入。我會把這些案例固定下來，讓每次 prompt 或 model 升版前都自動重跑，再搭配人工檢查。自動指標可以告訴我們哪裡退步，人工評分則能補上「答案雖然格式正確，但根本不適合人用」這類問題。
另一個常見盲點是只盯著平均延遲和平均成本。平均值對產品決策其實很不誠實：如果大多數請求很快，但少數請求卡到十幾秒，使用者感受到的會是系統不可靠。至少應該追蹤每次請求成本，以及 P50、P95、P99 延遲，並分開看不同模型、路由和工作類型。這些資料也會反過來影響架構，例如簡單任務走便宜模型，複雜任務才升級；主模型逾時或失敗時，有明確的 fallback，而不是讓整條流程一起掛掉。
我尤其在意「不確定時怎麼辦」。Guardrail 不只是擋掉幾個敏感詞，還包括輸入輸出檢查、rate limit、結構化日誌，以及低信心時交給真人處理。這裡的真人交接不是承認 AI 失敗，而是把不可避免的不確定性放在可控的位置。若系統只追求自動化率，最後往往會用更高的人工成本收拾錯誤。相反地，保留信心門檻和人工介入路徑，才有機會逐步收集錯誤案例，改善下一輪評測。
我會用三個問題判斷一個 AI 功能是否接近 production：它能不能用數據說明品質，而不是只展示幾個成功案例？升版出問題時，能不能快速回滾到上一個可用版本？面對真人多樣又不整齊的輸入時，能不能優雅降級，而不是自信地胡說？如果這三題答不出來，那現在擁有的仍然只是 Demo。
生成式 AI 的難點從來不是讓模型偶爾答對，而是讓它在數週、數月的版本變動和真實流量下，維持可預期的行為。把評測、成本、延遲、路由、guardrail 和人工接手串成閉環，工作量確實比做展示頁大很多；但這才是產品化本身，而不是額外的工程裝飾。
作者：陳思維