AI 問答上線之後：拒答門檻、濫用防守與可信度怎麼維持

AI 客服的缺點可以講得很具體：會答錯，答錯時的語氣與答對時一樣篤定，而且沒有人發現。前兩項是語言模型的特性，第三項才是上線之後的維運問題，也是花費最高的一項：使用者拿著錯誤的答案去行動，系統這邊卻沒有任何異常訊號。

生成式 AI 的錯誤資訊風險有正式文件可循。NIST 的生成式 AI 風險管理配套文件指出，生成內容可能難以分辨事實與意見，也可能被用於大規模的錯誤與不實資訊活動（NIST，2024）。上線之後要處理的，就是這些風險落到單一系統上的具體情形。

「這題還沒有答案」比硬答有價值

問答系統最重要的一句話是「這題還沒有整理好的答案」。永遠都回答的系統，會把錯誤包成流暢的句子送到使用者面前；會拒答的系統，至少把不確定的部分留給人處理。

拒答門檻是量出來的，不是憑感覺設定的。量法已在上線前怎麼評估 AI 問答寫過，這裡不重複。上線後要記得的是：只要檢索權重或知識庫內容一改，門檻就要重量。

這個做法有學術基礎。Geifman 與 El-Yaniv 針對神經網路分類器提出選擇性分類：使用者先設定可接受的風險水準，分類器在測試時拒絕部分輸入，讓風險以高機率維持在該水準內（Geifman 等，2017）。SimpleQA 評測把答案分成正確、錯誤與未作答三類，並以「不確定時應選擇不答」作為理想模型的標準（Wei 等，2024）。問答系統的拒答門檻，與這類研究的想法相近。

沒有信心時，回覆的方式很重要：直接說明還沒有整理好的官方答案，列出最接近的 3 題，記一筆未命中，並轉人工處理。每一筆未命中，都是知識庫下一個要補的題目。

回答之後，驗證器再擋一次

過了門檻不代表可以放行。模型只能依檢索到的前幾題來源回答，其餘規則由程式逐條檢查：

• 每個要點都附出處編號。
• 答案裡的數字，必須出現在引用的來源，或出現在提問者自己的問題裡。
• 評價字眼不能是模型自己加的。
• 驗證失敗時，帶著失敗原因重試一次；第二次只拿掉有問題的要點。
• 要點全被拿掉，就不硬答，回到「還沒有答案」；兩次都不過，回傳錯誤，且不扣使用者的次數。

驗證器本身也會誤擋。不對提問者下判斷的規則，若把「未達」「低於」「高於」列為禁字，而官方規定本身就是這樣寫的，正確的答案會被擋下。較好的做法是只擋對提問者本人下結論的說法，例如斷言對方符合資格、機會很大。標題長度、重述題目卻不回應等規則也一樣，要靠端到端測試看到正確的答案被擋下，才知道該放寬。

語氣也會被放大。模型會把來源裡的「許多」「原則上」寫成「無法」「一律」，所以規則要求保留來源的語氣與範圍。提問者說手上的文件寫法不同時，系統不否定也不附和，回覆「不確定」。

最貴的故障不報錯：看起來成功，其實沒做事

當機通常很快被發現，真正昂貴的是沒有錯誤訊息的故障：回傳成功，實際上什麼都沒做。AI 自動化流程常見五種，共通點是都沒有任何錯誤訊息。

1. 分類清單沒有傳給模型。跑完一輪才發現，產出多數是廢的。型別檢查抓不到，只有專門比對「呼叫真的接上」的接線檢查抓得到；斷言也要比對真正的呼叫，太弱的斷言一樣會放過。
2. 寫入看似成功。更新語句帶著「未刪除」的條件，目標已刪除時更新 0 列，函式沒有檢查影響列數，回傳和成功一模一樣，資料就此被誤標。
3. 任務被漏掉。新增的任務沒有接進排程，往往多日後才被發現。
4. 連錯資料庫。連到另一台時，讀取待處理清單回傳空陣列，畫面印出「沒有待處理的需求」，和真的沒有長得一模一樣。
5. 設定從未生效。例如後台可以選模型的 AI 功能，後台選定的模型被程式改寫成另一家供應商的模型，備援邏輯又永遠不會執行，後台設定因此從沒作用；或是環境檔有一行空值，載入後成為空字串，預設值不會補上，系統讀到沒有尾碼的資料表，還建出一張空表。

防範的做法都很樸素。接線檢查，確認每個任務、每份清單真的被呼叫；寫入後回讀，確認資料真的變了；「沒有資料」與「連錯資料庫」分開檢查，作業前先確認連的是正式庫；新增有預設值的環境變數時，用能處理空字串的寫法，並確認正式機的環境檔沒有空行。呼叫日誌只能證明呼叫成功，不能證明答對，所以日誌取代不了這幾項。這些檢查應該在AI 問答系統開發時就列入規格，而不是出事之後才補。

防守要加在每一條會呼叫模型的路徑

問答服務的入口先過一層程式化的防守：提示注入、辱罵、索取別人的個資、要求寫程式碼、亂碼、自傷字眼。命中就不呼叫模型，直接回固定的句子；日誌只記類別、不存原文，也不扣使用者的次數。OWASP 的 LLM 應用風險清單把提示注入（LLM01:2025）與錯誤資訊（LLM09:2025）列為主要風險（OWASP Gen AI Security Project，2025）。同一道防守不限於問答，任何會呼叫模型的產品功能都適用，包括互動產品裡的 AI 設定功能。

只防守主要路徑並不夠。常見的漏洞是：有些會呼叫模型的路徑不計入任何額度，可以被無限次呼叫；API 的呼叫紀錄若對任何請求都寫入資料庫與檔案，可以被灌爆磁碟。對策是為模型呼叫加上每位會員每小時的上限，並補上每個來源位址每分鐘的請求上限。

教訓很簡單：每新增一條會花錢的路徑，額度與限流要在同一次改動裡補上。漏掉一條，其餘的防守就失去意義。開發團隊的資安檢查腳本專門檢查這一點。

額度依用途分帳

模型呼叫的額度要依用途分帳。使用者的請求，不能被內部的批次處理或測試吃掉。

常見的情況是：原本只服務最終使用者查詢的金鑰被拿去跑批次標註，批次一旦提示詞寫錯，整批丟棄的呼叫就是純浪費，前台的正當查詢卻可能因額度耗盡而失敗；測試站的 API 額度通常很小，批次測試就足以把使用者要用的額度用完，測試站的問答因此全部失敗。對策是劃線，如下表。

分帳還有一個與成本無關的好處。大量並行呼叫失控、用量暴增時，第一個反應往往是懷疑金鑰外洩，而用量圖本身分不出「正常工作」與「金鑰被盜」。額度依用途分開之後，使用者那把金鑰上出現的任何異常，就是異常。

進來的資料先驗證，每天算一次品質燈號

問答服務依賴兩類資料：知識內容，以及使用過程產生的記錄。資料變差時，系統不一定會報錯，答案可能只是慢慢變差。Sculley 等人指出，機器學習系統的快速進展看似免費，實際會累積可觀的長期維護成本，其摘要明列資料相依性是風險來源之一（Sculley 等，2015）。

以一個內容平台的前台事件接收為例，這一層是資料底層。事件與共同欄位的規格只有一份，由前台維護；後端同步一份，只新增、不刪除，內容不同就報錯；舊版本保留一段期間。上線順序固定在同一天：先合併前台，當天同步規格並部署後端，最後部署前台。順序反了，症狀是後端回報不認得的事件與版本。

每一筆資料進來都逐步驗證：事件名稱、是否在計畫內、共同欄位、版本、使用者同意、個資清除、參數規格、去重。不合格就拒收，而且不存值，只存原因與路徑。個資在前台已攔過一次，接收端再用同一組樣式掃一次，命中就把整個參數清掉，而不是遮蔽；寧可清掉可疑欄位，也不讓個資進資料庫。IP 與原始的瀏覽器識別字串都不入庫。

每天固定時間彙總一次，算出拒收率、遺失率、重複率、必填欄位缺漏率、延遲到達的比例，以及事件量與前七日中位數的偏離。超過門檻亮紅燈，超過門檻一半亮黃燈，樣本太少就不評。燈號用形狀加文字呈現，不靠顏色。彙總結果中人數太少的格子不寫入，以落實個資最小化。

對帳來源沒有接上時，也不假裝正常。介面標示「未接」，永遠不評。

狀態放在記憶體，擴充上限要寫進文件

有些簡化是刻意的，但必須把上限講明。常見的例子是把同一台裝置同時只能產生一份報告的鎖、排隊機制、比對結果的快取、外部資料的快取與限流計數，全部放在記憶體。多個程序或多台主機同時跑時，這些狀態各自一份，鎖與限流都會失效，所以文件要明寫「不要跑多個程序」。

流量成長時，下一步是把鎖、佇列與限流搬進共享儲存。把上限寫明，是為了日後擴充時不會被意外卡住。

上線後固定看的訊號

監控的通則可以直接沿用。Ewaschuk 在〈監控分散式系統〉一章整理出延遲、流量、錯誤與飽和度四個黃金訊號，並主張告警原則上只針對需要人工介入、影響使用者的問題，以症狀為主、原因為輔（Ewaschuk，2017）。Breck 等人的 ML Test Score 則提供一份檢核表，列出機器學習系統上線前與上線後都該有的測試與監控項目（Breck 等，2017）。

針對 AI 問答，在這幾項通則之外，還要加上只有問答系統才有的訊號。

規則改了之後，先用固定題庫重放前後兩個版本，逐題比對。同樣的請求永遠使用同一把 key，所以重放不必重新答題，也就不消耗額度。分數看不出「讀起來順不順」，所以另外抽少量真實口吻的題目，直接讀輸出的文字，這一項不計分。

不適合的情況

• 提問必須依個人狀況判斷，或每個回答都要由人負責承諾的場合。這類問題應該由人處理，AI 問答只適合負責分流。
• 知識內容沒有人維護，或上線後沒有人看未命中記錄與資料燈號的團隊。缺點會直接出現在使用者面前。
• 題目數量有限、答案固定的情形。預先整理好的答案頁就夠用，不需要即時生成，也不需要拒答門檻。

下一步：要準備什麼

要評估問答系統能不能守得住，先整理四樣東西：現有的官方文件與常見問題，以及誰負責更新；過去實際被問到的題目，最好保留原本的口吻；哪些問題一定要轉人工；目前有哪些功能會呼叫模型，各自用哪一把金鑰。整理好之後，可以直接聯絡開發團隊，從現況開始談。