別迷信 LLM 的「一次性正確」：在生產環境建構「驗證-修正」循環 (Verification Loop)

在 AI Lab 的交付現場，許多開發者習慣於追求一個「完美的 Prompt」，試圖透過不斷增加指令細節，讓模型在一次推論中就給出 100% 正確的答案。

但在處理複雜邏輯（如多步推論、複雜資料擷取或程式碼生成）時，這種做法往往會觸及 LLM 的能力上限。無論 Prompt 多麼精妙，模型依然會有機率在某個關鍵步驟產生幻覺或邏輯跳躍。

核心痛點：單次推論的不可靠性

單次推論（Single-pass Inference）最大的問題在於：模型沒有機會自我審視。 當它在第二步產生一個微小的錯誤時，後續的所有步驟都會基於這個錯誤繼續推演，最終導致結果徹底崩盤。

在生產環境中，我們不能依賴運氣。我們需要將「生成」與「驗證」解耦，建構一套 Verification Loop（驗證-修正循環）。

Verification Loop 的工程實作模式

一個成熟的驗證循環通常包含三個階段：生成 (Generate) $\rightarrow$ 驗證 (Verify) $\rightarrow$ 修正 (Correct)。

1. 生成階段 (Generate)

模型根據輸入產生初步結果 $R_1$。此時不需要追求極致的完美，而應追求結構化的輸出（如 JSON），以便於後續驗證。

2. 驗證階段 (Verify)

這是最關鍵的一步。驗證不應由原模型簡單地問一句「你確定對嗎？」，而應採用以下三種硬核手段：
- 確定性校驗 (Deterministic Check)：例如，如果結果是 SQL，則嘗試在沙箱中執行；如果結果是 JSON，則校驗 Schema 和必填欄位。
- 交叉驗證 (Cross-Verification)：使用另一個獨立且更強的模型（或同一模型的不同 Temperature 設定）對 $R_1$ 進行審計，尋找邏輯漏洞。
- 反向推演 (Reverse Reasoning)：要求模型將結果 $R_1$ 反向推導回原始輸入 $\text{Input}$。如果推導不一致，則判定為錯誤。

3. 修正階段 (Correct)

一旦驗證失敗，系統不應直接報錯給使用者，而是將 [原始輸入 + 錯誤結果 + 具體的驗證失敗原因] 作為新的上下文重新餵給模型。
指令範例：「你之前的輸出在第 3 步出現了邏輯矛盾（具體原因：...），請重新審視並修正。」

實戰案例：複雜報表擷取 Agent

我們在開發一個從非結構化 PDF 中擷取財務資料的 Agent 時發現，單次擷取的準確率僅為 82%。其中大部分錯誤源於模型將「去年」和「今年」的資料行搞混。

我們引入了 Verification Loop：
1. 生成：擷取資料並輸出 JSON 表格。
2. 驗證：編寫一個簡單的 Python 腳本計算表格中的各項總和是否等於 PDF 中標註的總計金額（確定性校驗）。
3. 修正：如果總額不符，將差異金額和相關行號回饋給模型重新擷取。

經過這一循環，最終交付的準確率提升至 98%，且回應時間僅增加了約 2 秒。

給工程團隊的建議

不要試圖透過增加 Prompt 的長度來消除幻覺，因為 Token 的增加會帶來更多的雜訊。相反，你應該把精力花在建構一個高效的 Verifier（驗證器） 上。

記住：一個平庸的模型 + 一個強大的驗證器 $\gg$ 一個頂尖的模型 + 一個簡單的 Prompt。