別讓「AI 交付」變成「AI 幻覺」：從 10 個真實專案看 AI Lab 的工程化陷阱

在許多 AI Lab 或新創團隊中，最常見的一個場景是：研究員在 Notebook 裡跑通了一個 Demo，指標驚人，然後信心滿滿地交給工程團隊：「邏輯很簡單，就是調個 API + 一個 Prompt，趕緊上線。」

結果上線一週後，產品經理開始抱怨：
- 「為什麼同一個問題，使用者 A 得到了完美答案，使用者 B 卻得到了胡言亂語？」
- 「為什麼回應時間從 2 秒變成了 15 秒？」
- 「為什麼之前能處理的格式，現在突然報錯了？」

這就是典型的 「Demo 陷阱」。將 AI 從實驗室（Lab）推向生產環境（Production），其核心矛盾不在於模型能力，而在於確定性（Determinism）的缺失。

1. 機率性輸出 vs. 工程化確定性

傳統的軟體工程是基於邏輯閘和狀態機的：if (A) then (B)。但 LLM 是基於機率的：if (A) then (probably B, maybe C, or sometimes a hallucination)。

在實際交付中，我們發現最致命的錯誤往往發生在「邊緣情況」上。例如，一個處理財務報表的 AI Agent，在處理 99% 的標準 PDF 時表現完美，但一旦遇到一個帶有複雜巢狀表格的掃描檔，它可能會自信地編造一組數字。

工程化對策：
- 結構化輸出強制化：絕對不要依賴 LLM 「盡量輸出 JSON」。必須使用 JSON Mode 或 Function Calling（工具呼叫），並在程式碼層面對 Schema 進行嚴格校驗（如使用 Pydantic）。如果校驗失敗，立即觸發重試或回退到預設的安全答案。
- Few-Shot 的版本管理：Prompt 中的 Example 不要隨手寫。建立一個 examples.json 的版本庫，每次修改 Example 後，必須執行回歸測試集（Eval Set），確保修復 A Bug 的同時沒有引入 B Bug。

2. 「Prompt 工程」的規模化失效

很多團隊習慣於透過不斷微調 Prompt 來解決問題：「加上『請深呼吸』或『一步步思考』就解決了。」這種方法在單次對話中有效，但在規模化交付時是災難。

隨著業務複雜度增加，Prompt 會變得臃腫不堪（所謂的 Prompt Bloat）。當一個 Prompt 達到 3k tokens 時，模型對中間指令的注意力會下降（Lost in the Middle），導致某些關鍵約束被忽略。

工程化對策：
- 任務原子化（Chain of Thought $\rightarrow$ Chain of Agents）：將一個複雜的長 Prompt 拆分為三個短 Prompt。第一個負責提取實體 $\rightarrow$ 第二個負責邏輯推理 $\rightarrow$ 第三個負責格式潤飾。雖然增加了 API 呼叫次數，但極大地提升了每一步的可觀測性和可除錯性。
- 動態上下文注入：不要把所有背景知識都塞進 System Prompt。採用 RAG（檢索增強生成）或動態範本，只在需要時注入最相關的上下文片段。

3. 被忽視的效能與成本之牆

在 Lab 環境下，我們習慣於等待模型生成完整個答案。但在生產環境中，使用者對首字回應時間（TTFT）極其敏感。

我們曾經歷過一個案例：為了追求極致的準確率，使用了最強的模型並開啟了複雜的 CoT 推理。結果導致端到端延遲高達 20 秒。使用者在第 5 秒時就關閉了頁面。

工程化對策：
- 串流傳輸（Streaming）優先：無論後端多慢，前端必須立即開始串流渲染文字。這在心理學上能顯著降低使用者的感知等待時間。
- 模型分級路由（Model Routing）：並非所有請求都需要 GPT-4o 或 Claude 3.5 Sonnet。建立路由機制：簡單查詢 $\rightarrow$ 輕量級模型 (GPT-4o-mini/Haiku)；複雜推理 $\rightarrow$ 重量級模型。這能降低 60% 以上的成本並提升整體吞吐量。

4. 建構你的「AI 回歸測試集」 (Eval Set)

AI 專案最怕的是「感覺變好了」，而不是「資料證明變好了」。如果沒有 Eval Set，你永遠不知道這次 Prompt 修改是優化還是退化。

一個合格的 AI 工程交付流程應該是：
1. 收集 Bad Cases $\rightarrow$ 將其轉化為測試用例（輸入 + 預期輸出）。
2. 建構黃金資料集 (Golden Dataset) $\rightarrow$ 定義什麼是「正確」的答案（可以是精確匹配、關鍵字包含或由更高階模型打分）。
3. 自動化評測流水線 $\rightarrow$ 每一次程式碼提交或 Prompt 修改 $\rightarrow$ 全量跑一遍 Eval Set $\rightarrow$ 輸出 Pass Rate 和 Latency Report।

總結：從鍊金術到化學工程

AI 開發在早期像鍊金術——嘗試不同的咒語（Prompt），期待奇蹟發生。但要實現商業級交付，必須將其轉化為化學工程——定義輸入、控制變數、量化產出、建立標準流程。

記住：最好的 AI 產品，應該是讓使用者感覺不到 AI 在透過機率猜測答案，而是在執行一套極其可靠的邏輯流程。