先定義什麼叫可接受的錯誤
企業談 AI 幻覺時，常見問題是把所有錯誤混在一起。模型把公司政策講錯、把 ERP 欄位解讀錯、把不存在的客戶案例說得很像真的，風險都不同。工程上第一步不是調模型，而是把場景分級：哪些回答只能提供摘要，哪些可以建議下一步，哪些絕對不能自動執行。
例如內部知識助理回答請假規則，錯誤會造成員工困擾，但通常可由引用來源和人資窗口修正；若 AI 直接根據錯誤理解建立採購單或回覆客戶，影響就進入流程與商務風險。企業要先決定每個場景的容錯邊界，再決定技術控制強度。
- 低風險：摘要、翻譯、會議記錄整理，可允許使用者自行判斷，但要標示不確定處。
- 中風險：內部 SOP 問答、客服草稿、業務資料查詢，需要引用來源、權限控管與回饋機制。
- 高風險：報價、合約條款、醫療法規、財務決策、系統寫入動作，通常需要人員覆核或規則引擎把關。
用資料邊界限制模型的想像空間
多數企業 AI 助理不應該像開放式聊天工具一樣自由回答。RAG 的價值不只是讓模型知道更多，而是讓模型只能根據被授權、被索引、可追溯的資料回答。這裡的重點是資料工程，不只是向量資料庫。
實務上要先清理知識來源：版本過期的 PDF、重複的規範、命名混亂的表格、跨部門衝突的 SOP，都會讓檢索結果不穩。若檢索階段拿到錯的資料，模型再強也只是把錯誤講得更順。工程團隊通常會建立文件擁有者、更新週期、資料類型、權限標籤與引用規則，讓模型回答時能回到具體來源。
檢索設計也有取捨。切段太小，模型容易失去上下文；切段太大，答案會混入不相關內容。只用語意搜尋可能找不到料號、客戶代碼、表單編號；只用關鍵字搜尋又容易錯過同義描述。企業場景常需要混合檢索、metadata 過濾、權限過濾與 reranking，並且在查不到資料時明確回答目前找不到，而不是補一段看似合理的內容。
把回答流程設計成可驗證的管線
控制幻覺不能只靠最後一句請根據事實回答。比較穩的做法是把任務拆成多個步驟：理解問題、判斷意圖、查詢資料、生成回答、檢查引用、套用政策、決定是否需要人工覆核。每一步都可以留下紀錄，也比較容易定位問題是在檢索、提示、權限、資料品質還是模型本身。
在企業助理、LINE 官方帳號、CRM 客服台或 ERP 查詢介面中，我們通常會避免讓模型直接碰核心系統寫入權限。模型可以產生建議、草稿或結構化參數，但真正送出前要經過白名單工具、欄位驗證、商業規則和使用者確認。這種設計會犧牲一點流暢度，但能換來可控性。
- 答案必須附來源：沒有來源就降低信心，或改成建議使用者聯絡負責窗口。
- 工具呼叫必須有 schema：不要讓模型自由組 SQL、API payload 或 ERP 指令。
- 重要欄位要二次確認：金額、日期、客戶名稱、料號、合約版本都應明確顯示給使用者確認。
- 低信心要能退出：系統應能回答不知道、需要更多條件、或轉人工，而不是硬答。
評測、監控與責任分工要長期運作
AI 幻覺控制不是上線前測一次就結束。企業資料會更新，部門流程會改，模型版本會變，使用者問法也會慢慢偏離原本測試集。因此要建立一組代表真實工作的測試問題，包含常見問題、邊界問題、權限問題、找不到答案的問題，以及容易混淆的相似問題。
上線後，系統應記錄問題、檢索片段、模型回答、引用來源、工具呼叫、使用者回饋與人工修正。這些紀錄不是為了監控員工，而是為了讓工程團隊能判斷問題模式：是某類文件需要重整，還是某個 prompt 太寬，或是某個 API 工具需要加驗證。沒有觀測資料，幻覺只會變成感覺問題。
最後，責任分工要清楚。業務部門負責定義正確答案與例外流程，IT 負責權限、整合與系統可靠性，法務或資安負責敏感資料與合規邊界，工程團隊負責模型管線與評測機制。AI 在企業裡不是單一模型專案，而是一個接到資料、流程和人員責任的系統。若能從一開始就用這個角度設計，幻覺不會完全消失，但會變得可管理、可追蹤，也比較能真正落地。