先定義什麼叫「不穩」，不要立刻調提示詞
使用者說 AI「有時答對、有時答錯」時，我們會先確認差異出現在哪裡：同一個問題重問後內容不同、不同使用者得到不同答案、引用資料不一致，或答案本身正確但格式不符合流程。這些現象可能分別對應模型取樣、權限過濾、知識檢索與輸出驗證問題。若一開始就修改提示詞，往往只是讓症狀暫時改變，卻沒有找到根因。
先建立最小可重現案例。保存原始問題、使用者身分與權限、對話歷史、時間、模型名稱與版本、取樣參數、系統提示詞版本、檢索查詢、取回文件、工具呼叫結果，以及最後送進模型的完整上下文。測試時固定所有可控變數，重複執行同一案例；再一次只改一個因素。溫度設為低值可以減少生成差異，但不能修復錯誤資料、遺漏文件或不穩定的外部 API。
沿著資料流逐層隔離問題
企業 AI 通常不是單一模型，而是一條由身分驗證、問題改寫、向量檢索、權限過濾、提示詞組裝、模型生成、工具呼叫及格式驗證組成的鏈。除錯時應逐層檢查中間產物，而不是只看最後答案。最實用的方法，是先問「模型當時實際看到了什麼」，再問「它依據那些內容做了什麼」。
- 輸入層：確認前端、LINE、CRM 或 ERP 傳入的文字是否被截斷、轉碼、去除換行，並檢查對話歷史是否混入其他工作階段。
- 檢索層：檢查搜尋查詢、排名分數、文件版本、切片邊界、metadata 與權限條件。若正確文件根本沒有進入候選集合，調整模型通常沒有幫助。
- 上下文層：確認重要規則是否因 token 預算被截掉，重複文件是否稀釋訊號，以及互相衝突的政策是否同時被放入提示詞。
- 生成層：檢查模型版本、溫度、top-p、最大輸出長度與結構化輸出設定。模型供應商切換或預設值改變，也可能造成行為漂移。
- 工具與整合層：記錄 API 請求、回應、逾時、重試及快取命中。ERP 查詢失敗後若系統靜默地讓模型自行回答，就會把整合錯誤偽裝成幻覺。
隔離時可用替身資料縮小範圍：固定一組已知正確的檢索文件直接送入模型；若答案穩定，問題多半在檢索或權限流程。若仍不穩，再固定模型回應來測試後處理與前端呈現。這種切割方式比同時重建索引、改提示詞與更換模型更慢一些開始，卻能避免無法判斷是哪個修改真正有效。
用可評估的測試集取代主觀印象
品質不能只靠團隊讀幾段答案後判斷。應從真實使用情境整理一組可持續執行的測試集，涵蓋常見問法、同義改寫、資訊不足、跨文件推理、過期資料、權限邊界與惡意指令。每個案例要定義可接受的來源、必要事實、禁止內容，以及在證據不足時應採取的行為，例如明確表示無法確認或要求補充條件。
評估最好拆成數個訊號，而不是只給整體分數。檢索是否找到正確文件、回答是否受文件支持、引用是否真的包含主張、工具參數是否正確、輸出是否符合 schema，都應分開記錄。可用規則檢查確定性的項目，例如 JSON 格式、日期或產品代碼；語意品質則可由模型評審協助初篩，但重要案例仍需要人工抽查。模型評審本身也可能漂移，因此要保存評審提示詞與版本，不能把它當成絕對真相。
依根因修復，並為正式環境保留證據
不同根因需要不同修法。檢索召回不足時，可改善切片、metadata、混合搜尋或查詢改寫；排名錯誤時，再考慮 reranker。文件彼此衝突時，應建立版本、生效日期與權威來源規則，而不是要求模型自行猜測。提示詞過長時，優先刪除重複規則並建立清楚的優先順序。若任務需要固定欄位或會觸發交易，應採結構化輸出、欄位驗證與明確的失敗路徑，不要只期待模型「照格式回答」。
- 需要事實一致性：降低取樣隨機性、要求來源，並在缺乏證據時拒絕推測。
- 需要自然語氣：可保留有限生成彈性，但把事實與措辭分成兩個階段處理。
- 需要即時資料：以工具查詢作為事實來源，設定逾時與失敗提示，避免用模型記憶補答案。
- 涉及高風險操作：加入規則引擎、權限檢查、人工確認與可稽核紀錄，不能只依賴提示詞。
正式環境至少要能追蹤每次請求使用的設定版本、檢索文件識別碼、工具結果、延遲、錯誤與使用者回饋，同時避免在日誌中暴露敏感資料。任何修正都應先跑回歸測試，再分階段發布並保留回滾能力。若系統橫跨 LINE、ERP、CRM、雲端與內部知識庫，整合團隊的價值就在於把整條鏈變成可觀測、可驗證、可持續改善的系統，而不只是替換模型或反覆修改提示詞。