避坑指南：AI Agent 落地中的「幻覺」治理與工程化閉環

在很多 AI Lab 的交付專案中，最讓工程師頭疼的不是模型能不能生成答案，而是如何讓它在生產環境下「穩定地不胡說八道」。

很多團隊在 Demo 階段透過精心設計的 Few-shot Prompt 就能達到 90% 的準確率，但一旦進入真實業務場景，面對海量且不可控的使用者輸入，Agent 的幻覺（Hallucination）會迅速將可用性拉低到 60% 以下。

本文分享我們在建構企業級 AI Agent 時，從「調優 Prompt」轉向「工程化閉環」的三次關鍵迭代。

第一階段：從 Prompt Engineering 到 RAG 增強

最初，我們嘗試透過增加 System Prompt 的約束來減少幻覺。例如：「你必須嚴格基於提供的上下文回答，如果不知道請直接說不知道。」

結果： 模型變得極其保守，經常出現「我無法回答這個問題」的死迴圈，或者在上下文稍微模糊時依然強行拼接答案。

工程化方案： 我們引入了結構化的 RAG（檢索增強生成）鏈路。
1. 混合檢索 (Hybrid Search)： 不再依賴單一的向量檢索（Vector Search），而是結合 BM25 關鍵字檢索。因為在工程領域，特定的錯誤代碼（如 ORA-00600）或元件名稱是強特徵，向量化後反而會丢失精確度。
2. 重排序 (Reranking)： 檢索出的 Top-K 文件並不一定都相關。我們增加了一個輕量級的 Cross-Encoder 重排模型，剔除雜訊文件，確保餵給 LLM 的上下文是高純度的。

第二階段：引入「反思」機制與自我校驗 (Self-Correction)

即便有了高品質的上下文，LLM 在推理過程中仍可能產生邏輯跳躍。

實戰案例： 在一個自動化維運 Agent 中，模型在分析日誌後給出的修復建議有時會包含不存在的 API 參數。

工程化方案： 我們設計了一個 $\text{Generator} \rightarrow \text{Verifier}$ 的雙環結構。
- 生成環： Agent 根據知識庫生成初步方案。
- 校驗環： 呼叫另一個獨立 Prompt（或更強模型）扮演「審計員」，其唯一任務是檢查方案中的每一個技術點是否在上下文中有所支撐。
- 閉環： 如果校驗環發現矛盾點 $\rightarrow$ 將錯誤詳情回饋給生成環 $\rightarrow$ 重新生成。

這種「自我反思」機制雖然增加了 Token 開銷和延遲，但將關鍵指令的準確率提升了約 15%。

第三階段：建立可量化的評估集 (Eval Set) 與回歸測試

最危險的狀態是：「我改了一個 Prompt 解決了 A 問題，結果 B 問題崩了。」

痛點： 依賴人工抽檢無法支撐快速迭代。

工程化方案： 建構一個包含 $\sim 500$ 個典型 Case 的黃金資料集（Golden Dataset）。
1. Case 定義： 每個 Case 包含 Input $\rightarrow$ Expected Output $\rightarrow$ Critical Constraints（必須包含的關鍵字/禁止出現的詞）。
2. LLM-as-a-Judge： 使用 GPT-4o 或同級別模型作為裁判，根據預設的評分維度（準確性、完整性、安全性）對 Agent 的輸出進行打分。
3. CI/CD 整合： 將 Eval 整合到 Git Pipeline 中。每次修改 Prompt 或更新知識庫後，自動跑一遍全量測試。只有當整體得分不下降且核心 Case 通過率 $100\%$ 時才允許合併程式碼。

總結與啟示

AI Agent 的落地不是一次性的「煉金術」，而是一場持續的工程優化。

如果你發現你的 Agent 在生產環境中不穩定，請停止盲目地修改 Prompt 字眼，嘗試從以下三個維度切入：
- 資料端： 檢索品質是否足夠高？是否有雜訊？
- 邏輯端： 是否有獨立的校驗環節？能否實現自我糾錯？
- 評估端： 你是否有一個能快速回饋修改影響的量化資料集？

真正的穩定性來自於對不確定性的管理，而非對完美 Prompt 的追求。