降低 AI 幻覺怎麼做?生產環境要顧的五道防線

一名乘客因為奔喪買了機票,客服聊天機器人告訴他,回程之後一樣可以申請奔喪優惠票的退費。乘客照做,航空公司卻說退費規定寫在官網的另一頁,機器人的說法根本是錯的。這起真實發生在加拿大的官司,最後法院判企業必須負責,理由是聊天機器人講出口的每一句話,都算公司自己講的,而這正是為什麼降低 AI 幻覺,在生產環境裡從來不是一句口號,而是實際的法律風險。

這種一本正經講錯話的現象叫 AI 幻覺(AI Hallucination),指模型在缺乏依據時,仍用流暢自信的語氣,講出不存在或不正確的內容。放在展示場合,AI 幻覺頂多讓人尷尬,重問一次就過去;一旦放進真正在服務客戶、天天回話的生產環境,講錯的那句話已經送到使用者手上,沒有重來一次這回事。企業真正該問的問題,不是「AI 會不會講錯話」,畢竟目前沒有一個模型敢說自己零幻覺,而是怎麼把出錯的機率壓到可控,並且在它一發生的當下就攔下來。

先從生產環境的幻覺跟展示現場差在哪講起,再一路拆到能實際落地的幾道防線。

降低 AI 幻覺的五道防線縱深防禦:提示詞設計、RAG 檢索增強、上線後監控、分層護欄、人工複核,一句回答依序通過才輸出可信賴結果
降低 AI 幻覺靠的是五道各自獨立的防線層層疊加,而不是單靠一個更聰明的模型。

生產環境的 AI 幻覺,跟展示用的 demo 有什麼差異?

Demo 展示的時候,答錯了頂多重新問一次,反正台下沒有人會拿著那句話去做決定。生產環境完全是另一回事,它面對的是真實使用者,沒有人站在旁邊即時訂正,而且每一句輸出都可能被當真、被存證,甚至被拿去當成下一步行動的依據。

前面那起航空公司的官司,正好把這個落差攤在陽光下。仲裁庭審理時,航空公司主張聊天機器人是能夠獨立回答問題的個體,公司不必為它講錯的內容負責。這個說法被法官直接駁回,理由是航空公司沒有解釋清楚,為什麼乘客不應該相信官網聊天機器人提供的資訊,換句話說,聊天機器人講的話,就代表公司講的話。最後航空公司被判賠償乘客 812.02 加拿大元的機票差額與訴訟費用。

這起案子點出一個常被忽略的重點,AI 幻覺造成的傷害,不會等到模型變得更聰明就自動消失,而是企業一旦把 AI 放進生產環境,就得用管理正式對外溝通的標準去對待它。至於模型到底有多常講錯話,下面的最新數字會讓你重新評估風險。

幻覺有多常見?最新基準測試把答案攤開來看

目前業界最常被引用的幻覺量測,是 Vectara 維護的幻覺評估排行榜。2025 年 11 月,這份排行榜推出新一代版本,把測試資料集從原本的 1,000 篇文件,大幅擴充到超過 7,700 篇,文件長度最長拉到 32,000 個 token,更貼近企業實際會遇到的長文件與複雜場景。它的評分邏輯很直接,讓每個模型摘要一篇文章,再用 Vectara 自家的幻覺偵測模型(HHEM)判斷摘要有沒有加進原文沒有的內容。

新版排行榜攤開之後,兩個發現值得你記住。第一,沒有一個模型是零幻覺,連目前表現最好的 Gemini-2.5-flash-lite 也有 3.3% 的幻覺率。第二,越會推理的模型,不代表越不會幻覺——Gemini-3-Pro 的幻覺率來到 13.6%,甚至擠不進排行榜前 25 名;Claude Sonnet 4.5、GPT-5、Grok-4、DeepSeek-R1 全數超過 10%。

模型Vectara 新版排行榜幻覺率
Gemini-2.5-flash-lite3.3%(目前最低)
Gemini-3-Pro13.6%
Claude Sonnet 4.5超過 10%
GPT-5超過 10%
Grok-4超過 10%
DeepSeek-R1超過 10%

Vectara 的解讀是,推理模型會投入更多算力去想清楚答案,這個過程反而容易讓它離開原文、自行加進推論,而不是老實貼著文件講。OpenAI 自己的技術報告也印證了同一個現象,在 PersonQA 這個測人物事實準確度的基準上,o3 的幻覺率是 33%,比前一代 o1 的 16% 與 o3-mini 的 14.8% 高出將近一倍;o4-mini 更高達 48%。OpenAI 坦承,目前還需要更多研究才能解釋原因,只推測強化學習訓練的方式可能放大了原本會被一般後訓練流程壓下去的問題。這兩份資料共同指出一個一致的趨勢,文件越長、任務越複雜,幻覺率就越高,而這正是生產環境的日常,不是 demo 那種被精心挑過的簡單問答。

OpenAI 四款模型在 PersonQA 基準的幻覺率長條圖,o1 為 16%、o3-mini 14.8%、o3 33%、o4-mini 48%,越新的推理模型幻覺率反而越高
越會推理的新模型,幻覺率反而更高(資料來源:OpenAI o3 and o4-mini System Card)。

用了 RAG 就不會幻覺?法律 AI 工具的實測戳破了這個行銷話術

降低幻覺最有效的單一手段,是別讓模型靠記憶回答,而是先把正確、相關的資料餵到它面前,這就是檢索增強生成(RAG,Retrieval-Augmented Generation)在做的事。它先到你指定的知識庫裡撈出相關段落,連同問題一起交給模型,要求它根據這些資料回答,模型有了可以貼著走的軌道,就不必自己亂補。

問題是,不少廠商把 RAG 講成能徹底杜絕幻覺的萬靈丹,而這個說法禁不起實測。史丹佛大學 RegLab 團隊做了第一個針對 AI 法律研究工具的預先註冊實證研究,找來 202 道真實法律問題,由法律專家逐題評分。結果是,連標榜用了 RAG、宣稱「零幻覺」的法律 AI 工具(Lexis+ AI、Westlaw AI-Assisted Research、Ask Practical Law AI)實測仍有 17% 到 33% 的幻覺率,比起沒有 RAG 的通用聊天機器人確實低很多,卻遠遠不到廠商宣傳的零幻覺。

這個結果對用 RAG 的人是個提醒,它是必要條件,不是充分條件,成敗有一半在於檢索撈得準不準。如果知識庫切分得亂、向量檢索常常撈錯段落,模型拿到一堆無關資料,照樣會出現幻覺。真正該投入心力的地方,是資料怎麼整理、怎麼切塊,確保最相關的內容真的被撈出來,而不是接上一個檢索元件就以為高枕無憂。

怎麼幫每一個 AI 回答打一個「忠實度」分數?

RAG 把出錯的機率壓下來之後,下一步是處理那條漏網的尾巴,也就是在 AI 已經上線、天天回話的環境裡,你要有辦法即時知道它這次是不是在亂講。很多團隊上線前做過評測,通過就以為沒事了,問題是評測用的是準備好的題目,真實使用者的問法千奇百怪,常常把模型逼進測試集沒涵蓋的角落。沒有持續監控,對線上幻覺的能見度幾乎是零。

生產環境裡偵測幻覺,核心指標叫忠實度或基礎性(faithfulness、groundedness),指這次回答有沒有被檢索到的依據支持。這已經不是抽象口號,幾家大型雲端服務商都把它做成了可以直接串接的產品。Google Cloud 在 Gemini Enterprise Agent Platform 提供的「基礎」(Grounding)機制,會把模型輸出連結到可驗證的資料來源,來源可以是 Google 搜尋、企業自己的文件與網站、Elasticsearch 索引,甚至外部搜尋 API;官方文件明講,這麼做能減少模型捏造內容,並讓每一句回答都有出處可以稽核。

Microsoft 在 Azure AI Content Safety 裡則提供一支「基礎性偵測」(Groundedness Detection)API,拿模型的回答直接跟你提供的依據來源比對。它有兩種模式:一種是快速偵測,回傳「有依據/無依據」的二元判斷,適合即時上線的場景;另一種會附上詳細解釋,適合開發階段除錯用。官方文件給的示範很具體,模型回答「利率是 5%」,但你提供的依據資料寫的是「4.5%」,這支 API 會偵測出兩者不符,還能自動把回答修正成「4.5%」。落地時可以照著這個邏輯做,記錄每次回答的「問題、依據、回答」三件套,對低分回答即時告警,再把這些分數做成能看趨勢的儀表板,當某類問題的分數突然集體變差,往往代表知識庫過期了,或檢索開始撈錯。

上線後幻覺監控四步流程:記錄問題依據回答三件套、打忠實度分數、低分即時告警、匯進儀表板看趨勢,即時揪出線上幻覺
把每次回答的忠實度做成可監控指標,低分就攔、趨勢下滑就查,線上幻覺才不再是盲區。

護欄要分層設,不是每個環節都要鎖死

監控讓你看得到幻覺,護欄則是在它真的傷到人之前攔下來。但護欄不是越多越好,它有成本、會拖慢回應,全面鎖死反而讓 AI 變得綁手綁腳。OWASP 旗下跨國專家社群維護的生成式 AI 安全專案,對這類系統提出的建議是縱深防禦(defense-in-depth),用多層各自獨立的防線疊加,而不是靠單一一道萬用護欄擋住所有風險。

落地時比較務實的做法,是先分清楚哪裡該攔、哪裡放行。多數應用場景只要有「上線前評測加上線後監控」這個基本盤就夠了,護欄則只選擇性地加在高風險環節:客服回覆涉及金額、退款、保固承諾的部分,自動化流程裡 AI 判斷會直接驅動下一步動作的環節,以及法律、醫療、財務這類答錯有合規或人身後果的領域。模型講不出明確依據,或分數過不了門檻時,寧可回「這部分無法確認,已轉由專人協助」,也不要硬給一個可能是錯的答案。至於一般性的資訊問答、內部草稿生成這種偶爾出錯也只是重問一次的低風險場景,套上太重的護欄只會拖慢體驗、增加成本,不划算。

提示詞怎麼設計,模型才不會自己亂補答案?

很多幻覺其實是問法帶出來的。模型對輸入極度敏感,指令模糊、語意不清,或暗藏了錯誤前提,它為了把話接下去,就會自己延伸內容。把邊界講死是最便宜也最有效的一步,在提示詞裡明確圈定只能根據提供的資料回答,若資料裡找不到就回答無法確認,不要自行推測,同時要求逐句標明依據。相對地,誘導式的問法、藏著錯誤假設的提問,最容易把模型逼到編造,這類問法要刻意避開。

第二個原則是把理解和生成拆開做。與其要模型一口氣讀完資料又寫出完整的長篇回覆,不如把任務切成兩步:先讓它做抽取或分類,從資料裡找出關鍵事實,確認無誤之後,再請它根據這些已核對的事實去生成完整敘述。一次只做一件事,模型自行延伸的空間就小很多。

舉個常見的對照,與其問「幫我整理這批客戶的退貨權益」這種開放式問法(容易讓模型自己編規則),不如改成「先從以下條款列出與退貨相關的條目,只列文件中存在的,缺的標註查無」,拿到乾淨的事實清單後,再請它寫成完整說明。多花一步,省下的是事後抓錯的成本。

賠不起的環節,一定要留人在最後把關

前面幾道防線能把幻覺率壓得很低,但很低不等於零,而有些場合連萬分之一的錯都賠不起。2023 年,紐約一起人身傷害訴訟給出了一堂最貴的教材。原告的律師用 ChatGPT 起草訴狀,裡面引用了六個判例當作先例,結果對造律師怎麼查都查不到這幾個案子,法官也一樣找不到,要求原告律師提出判決全文。原告律師沒有立即承認錯誤,反而又交出一份「AI 生成的假判決全文」,試圖證明那些案例真的存在。主審法官最終認定兩位律師惡意行事,連同不實陳述,裁定罰款 5,000 美元,案子也被駁回。這起案子後來成為業界最常被引用的警世案例,提醒任何專業工作者,AI 寫出來的引用,沒查證就直接用,代價可能比重寫一份文件高得多。

這件事帶出一個清楚的分工原則。低風險、可逆、錯了重來成本很小的任務,像是產生內部草稿、整理參考資料,就讓 AI 自動跑,人工複查只會把效率賠光。但在那些一旦錯就難挽回的環節,像是對外的法律或財務建議、牽涉金額與承諾的決策,AI 的角色應該是提出建議,最終判斷仍由懂行的人確認後才放行。要提醒的是,人工複核要設計得讓人真的看得到該看的東西,如果系統把風險高的回答標出來、附上依據讓審核者一眼能比對,複核才有效率;要是丟一大坨未經整理的內容讓人從頭看,審核者很快就會疲乏,變成有名無實的橡皮圖章。

把幻覺分級管理,而不是每次都用同一套防線

把前面幾道防線放在一起看,會發現它們不該是各自獨立的技巧清單,而是一套依風險分級的治理思維。美國國家標準暨技術研究院(NIST)在其官方發布的《AI 風險管理框架:生成式 AI 專篇》(NIST AI 600-1)裡,把 confabulation(也就是幻覺)正式列為生成式 AI 的核心風險類別之一,並要求企業依循管理、對照、衡量、因應四項功能,針對不同風險等級的應用場景分別建立治理機制,不對所有 AI 應用套用同一套標準。

呼應這個精神,前面談到的做法可以收成一句話,低風險場景用基本盤(RAG 加監控)就夠,高風險場景才疊加護欄與人工複核,而這條分級的界線該寫進企業自己的治理制度、定期覆核,不是每次臨時憑感覺決定。

AI 幻覺分級治理對照:低風險場景用 RAG 加監控的基本盤,高風險場景再疊加分層護欄與人工複核
低風險場景用基本盤就夠,高風險場景才層層加固,這條分級界線該寫進治理制度、定期覆核。

幻覺不會因為換了一個更聰明的模型就消失,前面看到的數據已經說明,推理能力越強,有時反而越容易離開原文自行發揮。真正決定一套 AI 系統能不能被信任上線的,從來不是選哪一家模型,而是企業有沒有把看得見、攔得住、有人收尾這套機制搭起來。把這套機制建好,AI 才真正幫得上忙,不會變成隨時可能失控的風險。

資料來源
  1. Moffatt v. Air Canada, 2024 BCCRT 149 — 加拿大卑詩省民事解決法庭
  2. Introducing the Next Generation of Vectara's Hallucination Leaderboard — Vectara
  3. OpenAI o3 and o4-mini System Card — OpenAI
  4. AI on Trial: Legal Models Hallucinate in 1 out of 6 (or More) Benchmarking Queries — 史丹佛大學
  5. Grounding overview - Gemini Enterprise Agent Platform — Google Cloud
  6. Groundedness detection in Azure AI Content Safety — Microsoft Azure
  7. OWASP Top 10 for LLM and GenAI — OWASP
  8. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1) — NIST
  9. Mata v. Avianca, Inc., 678 F. Supp. 3d 443 (2023) — 美國紐約南區聯邦地方法院