AI 問答上線前的評估方法：固定題庫、信心門檻與拒答設計

AI 問答在展示現場答得準，不代表上線後可靠。展示的題目由人挑選，上線後的提問事先無從得知，而且經常落在資料範圍之外。問答系統先檢索資料、再交給模型生成回答，這種做法稱為檢索增強生成（Lewis 等，2020），原理與適用情境見RAG 的運作原理。本文談下一步：上線前怎麼評估，才能在使用者遇到問題之前先找到問題。

引用出處不等於答案有根據。有研究評估多個商用生成式搜尋引擎，發現回答裡常有句子得不到所附引用的支持，引用本身也有相當比例撐不起所附的句子（Liu 等，2023，依人工評估）。另一項研究提出 ALCE 基準，以自動指標評估流暢度、正確性與引用品質，這些指標與人工判斷有很強的相關；在 ELI5 資料集上，最好的模型其引用也只有約一半能完整支持主張（Gao 等，2023）。兩項研究指向同一件事：評估要看的是每一個要點有沒有被出處支持，而不是整段讀起來順不順。

固定題庫：先把考什麼固定下來

固定題庫是整個評估的基礎。題庫由客戶提供真實會被問到的問題，每題附上認定正確的原文段落，再加入一批不該回答的題目，例如資料範圍之外的問題，或需要個案判斷的問題。題庫固定之後，程式、檢索權重或知識內容每次改動，都用同一批題目重跑，直接看哪些題變好、哪些題變差，而不是憑印象。上線準備度的檢核表也是同樣的思路：ML Test Score 同時列出上線前與上線後應有的測試與監控項目（Breck 等，2017）。

• 回歸題庫：約 50 題，每題有明確的正解與評分斷言，用來確認改動沒有弄壞原本答得出的題目。
• 防守題庫：約 40 題，涵蓋不該回答、超出範圍與刻意誘導的問題，記錄可接受的處理方式，例如拒答或轉人工。
• 感受測試：不到十題，用真實使用者的口吻提問，不計分，重點是由人直接讀輸出文字，因為分數看不出讀起來順不順。
• 純函式檢查：排序、防守與字面規則各有一支獨立檢查，不連網、不用金鑰，結束碼為 0 才算通過。

資安領域把檢查分成重複執行的弱點掃描，與靠人設計情境的滲透測試。問答評估可以借用同樣的分法：固定題庫負責重複執行、結果可比對；人工設計的刁難題負責補上題庫沒有涵蓋的缺口，發現之後再補進題庫。兩種檢查的差異，可參考弱點掃描與滲透測試的差異。

回放：把模型呼叫換成檔案

評測的成本問題出在每次重跑都要呼叫真實模型。批次測試會消耗客戶的 API 額度，輸出也會因模型的細微差異而每次不同，程式改動前後無法逐題比對。解法是把每個模型呼叫換成檔案：沒有答案的呼叫寫成一份請求檔，由代答者逐題回答，把答案寫成對應的答案檔。一輪評測，是每一題往前走到第一個還沒有答案的呼叫，依序是拆解問題、撰寫回答、判定是否合格，答案補齊後再跑下一輪。同樣的請求永遠對應同一個檔名，所以重跑不會重答；程式改動後以回放模式沿用既有答案，就能逐題比對前後差異。

取捨要講清楚。代答者是小型模型，不是正式上線的模型，所以這套離線評測只能驗證流程、驗證器與規則是否咬合，不能代表正式模型的措辭。另外保留一道端到端測試，在測試環境用真實模型跑完整流程，單份輸出的花費約 0.02 美元。離線模式本身也有防護，見圖中不離開邊界的部分。

信心門檻：用考題量出來，不用猜

問答系統要先決定一題有沒有足夠把握可以回答。檢索階段替每個候選答案打分，排序採用 BM25，這是源自機率相關性框架的排序方法（Robertson 與 Zaragoza，2009）；中文以相鄰兩字為單位切分，搭配同義詞展開，使用者問法、關鍵詞與答案各自加權。門檻有兩個：檢索分數，以及適配值（檢索分數乘上覆蓋率）。兩者都不憑經驗設定，而是用題庫量出來。

量法是把題庫分成兩組：該答的題，與不該答的題。取該答的題裡最低的分數，與不該答的題裡最高的分數，門檻就落在兩者之間。兩組分數若有重疊，代表檢索本身還不夠好，要先改檢索或補知識內容，不能靠調高門檻掩蓋。改了權重或知識內容，門檻都要重量一次。

拒答是機器學習的經典問題。選擇性分類的研究讓使用者先設定可接受的風險水準，分類器在測試時拒絕部分輸入，使風險以高機率維持在該水準內（Geifman 與 El-Yaniv，2017）。評測簡短事實題的 SimpleQA 把回答分成正確、錯誤與未作答三類，並指出理想的模型在不確定時應選擇不答（Wei 等，2024）。問答系統的做法與這兩項研究的原則一致：先量出可接受的風險，再讓系統在把握不足時不輸出答案。

回答閘門：每個要點附出處，驗證不過就拿掉

檢索分數夠高，只代表找到了相關資料，不代表模型的回答忠實。Ragas 把忠實度列為 RAG 評估的面向之一，也就是模型是否忠實運用檢索到的內容（Es 等，2023）；FActScore 的做法，是把長文拆成細小的事實單位，逐一檢查有沒有可靠的知識來源支持，再算出被支持的比例（Min 等，2023）。上線的回答閘門採相近的粒度，一次只檢查一個要點。

• 模型只依檢索排名最前面的幾筆來源回答，來源以外的內容不得引用。
• 每個要點都附出處編號，讀者可以回到原文核對。
• 回答中的數字必須出現在引用的出處，或出現在使用者的問題裡。
• 評價字眼不能由模型自行加入；也不對使用者本人下判斷，例如斷言對方符合資格或機會很大。
• 保留出處的語氣與範圍：出處寫「許多」「原則上」，回答不能改寫成「無法」「一律」；使用者說出處寫法不同時，不否定，改為回答「不確定」。
• 驗證失敗時，帶著失敗原因重試一次；第二次只拿掉有問題的要點。

驗證器本身也會出錯，必須靠端到端測試找出來。一條不對使用者下判斷的規則，若把「未達」「低於」「高於」列為禁字，而官方規定本身就這樣寫，就會造成誤擋；較好的做法是拿掉這幾個字，只擋對使用者本人的斷言。標題長度、重述類回答等規則也一樣，要在端到端測試中看到該答的題被擋下，才知道要放寬。驗證規則過緊，會把該答的題也擋掉，所以規則與題庫要同步調整。

這題還沒有答案：拒答與轉人工

問答系統最重要的一句話，是「這題還沒有整理好的官方答案」。把握不足時，系統就說這句話，列出最接近的三個既有問題供參考，記錄一筆未命中，並轉人工。回答閘門的結果也一樣：所有要點都被拿掉時，系統不硬答，改走轉人工的流程；兩次驗證都沒有通過時，回傳錯誤並且不扣使用額度。未命中的記錄累積起來，可以作為下一輪補充知識內容的清單。拒答不是失敗，而是把不確定的題交給人，讓系統答出的內容維持在可驗證的範圍內。

結構化資料：每個值附原文，由第二位獨立複核

問答的知識內容，常需要先把官方資料整理成結構化的條件，例如資格、等級與條件門檻。官方條件的數字最怕被 AI 順手改寫，所以每個結構化的值都附原文片段：程式驗證片段確實是原文的子字串，數字確實在片段裡，「或」「且」照原文，原文沒寫的不加。接著由另一位獨立的複核者重讀，提示明確要求假設前一位有錯，逐列重讀。兩關都要通過程式檢查，仍需人看的列另外標出，交給客戶一張表。

官方資料更新後，用差異比對列出新增、消失與有改動的項目，只對條件有改的部分重新交給 AI，其餘由程式套用。消失的項目只列為候選，先問客戶，不自動下架。連只差括號內英文的改動也要重做，因為片段必須逐字出現在原文，拿掉英文後可能對不上。首次處理近 300 份官方資料頁，抽出數百組條件；後續兩次增量分別約 100 份與約 60 份。每次動手前先估花費，規模較大時先報價。

上線之後：看起來成功的故障

AI 自動化最難抓的故障不是當機，而是看起來成功。例如自動化流程跑完一輪，多數產出無效，卻沒有任何錯誤訊息，原因是分類清單沒有傳給模型。型別檢查抓不到這類問題，只有專門比對「呼叫真的有接上」的接線檢查抓得到，而且斷言要比對真正的呼叫，太弱的斷言一樣會放過。這類故障有幾種常見形態：

• 寫入看似成功：更新語句因條件不符而影響零列，函式沒有檢查影響列數，回傳與成功一模一樣，資料就此被誤標。對策是寫入後回讀，確認資料真的改了。
• 任務被漏掉：新增的任務沒有接進排程，往往多日後才被發現。對策是接線檢查，確認每個任務都有被排程呼叫。
• 連錯資料庫：連到另一台時，待處理清單回傳空陣列，畫面顯示沒有待處理項目，與真的沒有長得一模一樣。對策是先確認連的是正式資料庫，並把「沒有資料」與「連錯庫」分開檢查。
• 日誌只證明有回應：呼叫日誌顯示成功，只代表呼叫成功，不代表答對。答對要靠題庫與出處驗證，上線後也要持續抽查。

問答上線後會產生使用事件，例如提問、拒答與未命中，這些資料要先管品質，後續的分析才可信。開發團隊在事件接收端的做法是：事件規格由單一來源維護，進來先驗證，不合格的一律拒收，只存原因與路徑，不存內容；個資用同一組樣式再掃一次，命中就整個參數清掉，而不是遮蔽。每天彙總一次拒收率、遺失率與重複率，超過門檻就亮燈。沒有接上的外部對帳，介面直接標示「未接」，不假裝正常。

回應太慢：不關思考，改拆段平行

生成等待時間偏長時，直覺的做法是關掉模型的思考換速度，但代價是規則遵守度。在測試環境以真實模型實測，開著思考一次寫完整份輸出，單次先花超過 1 萬個 token 在思考，寫作約 15 至 75 秒，十多題中有兩題逾時；即使調低思考強度也一樣。關掉思考後速度快了許多，但被驗證刪掉的句子約變成三倍，多數題目生不出標題，所以不關。

解法是拆段平行：同一份資料包分給幾位寫作者同時寫，每個子問題一位，直接回答與標題由一位負責，提醒、規劃與其餘部分各有一位，每位只拿到自己欄位的提示，總時間約等於最慢的一位。某一段失敗，只是那一塊留空，由程式用資料中的事實保底；全部失敗才整份失敗。拆段後，同一批題目全數完成，最慢不到 50 秒。使用者端用輪詢取結果，送出後立即收到受理回應，沒有任何一條連線在乾等。即時問答的總期限約 45 秒，低於反向代理預設的 60 秒讀取逾時。

評測的分工

評測不是單方的工作。題目要代表真實的提問，正解要由熟悉資料的人認定，這兩件事只有客戶能做；跑分、量門檻與調整檢索，由開發團隊負責；結果要雙方共同複核，被拒答與被判不合格的題，有時代表知識內容有缺口，而不是系統出錯。NIST 的 AI 風險管理框架把管理分為 GOVERN、MAP、MEASURE、MANAGE 四項功能，其中 MEASURE 以量化、質化或混合的方法分析、評估、比較與監控 AI 風險（NIST，2023）；上線前的固定題庫與門檻量測，可視為 MEASURE 的一種具體做法。

這類 AI 問答與評測的合作方式，見AI 服務；把多輪詢價改成四步取得分級菜單的做法，見乖獸（Cooking Monsters）的案例。

不適合的情況

• 只做內部試用，沒有人會依答案做決定：固定題庫與門檻的成本大於收益，先上線觀察即可。
• 沒有人能標正解：題庫沒有正解，門檻就量不出來，要先找到能認定答案的人。
• 來源文件互相矛盾：先整理資料，再談評估；否則評測量到的是資料的矛盾，不是系統的表現。

下一步：準備題庫

1. 20 個使用者最常問的問題，每題附上認為正確的原文段落。
2. 幾題不該回答的題目，例如資料範圍之外的問題，或需要個案判斷的問題。

備齊這些，就可以與開發團隊討論題庫與評測方式，先用這批題目量出第一版門檻，再決定要補哪些知識內容。