AO2 FIELD GUIDE · N053 · AI 問答與 RAG 應用
RAG 驗收題組需包含問題、核准來源、必要條件與預期行為。附情境覆蓋表，分開記錄檢索、回答、補問及權限限制的測試結果。
RAG 驗收題組：題目要來自使用任務，不只從文件標題倒推
從去識別的業務與客服提問開始，保留常見省略、別名與追問。文件標題「通訊介面規格」與使用者問的「這個能接我們現在那台嗎」有很大距離。測試題若全部沿用文件措辭，可能只證明系統會找到熟悉的字，沒有測到真實任務。
先挑一條產品線，區分已知答案、需補問、資料矛盾、超出範圍與無權取得的情境。每個問題都要有可核准的預期行為。若來源本身尚未裁決，就把該題標為待定，不要由測試撰寫者憑印象寫出標準答案，再要求模型符合。
| 欄位 | 內容 | 用途 |
|---|---|---|
| 問題與情境 | 原問法、角色與已知條件 | 避免只測文件標題 |
| 來源 | 文件 ID、版本與段落 | 確立可核准依據 |
| 必要主張 | 必留條件及不得擴寫內容 | 核對答案邊界 |
| 預期行為 | 回答、補問、拒答或轉接 | 評估不同情境 |
| 實際結果 | 檢索來源、回答與時間 | 追查失敗原因 |
標準答案可以是一組條件，不必只有固定句子
對產品適配問題，預期答案通常應包含型號、版本、限制和下一步。驗收重點不是逐字相同，而是必要主張有沒有被保留、是否加入來源不支持的承諾。若問題缺少關鍵條件，正確行為可能是補問；如果文件互相矛盾，應說明無法確認並交接，而不是挑一份回答。
資料引用也要逐項核對。回答附了連結，只能證明有引用，不代表引用段落支持全部主張。可以在題組中指定預期來源與必要段落，再讓審核者記錄實際取得的來源、答案與差異。測試中的私人或限制資料應依組織政策處理，不能為了方便驗收而改成全面可讀。
| 類型 | 測什麼 | 失敗訊號 |
|---|---|---|
| 來源完整 | 能否回答且保留條件 | 漏掉配置或版本 |
| 資料不足 | 能否只補問必要條件 | 直接猜型號 |
| 不適用 | 能否說清限制 | 把相近產品能力搬來 |
| 來源矛盾 | 能否停止確定性結論 | 任選一份當答案 |
| 權限限制 | 是否只取授權來源 | 利用問法取得限制內容 |
IoT 示例：一個問題至少拆出四種情境
以下為虛構測試設計。「這款模組能否遠端更新？」可以分成：已指定型號且來源清楚；型號未提供；指定舊韌體而功能不適用；來源文件互相矛盾。第一題測回答條件，第二題測補問，第三題測限制，第四題測不確定性處理。只保留第一題會高估系統可用範圍。
還可以加上同義詞或前後文變形，確認系統沒有因問法變化而漏掉限制。但題目變形不能只是大量複製同一答案，否則整體分數會被單一簡單情境稀釋。報告應按情境分組，明確列出失敗類型，而不只提供一個總正確率。
把檢索失敗與生成失敗分開記錄
Microsoft 的 RAG 概覽說明，以企業內容支持回答仍需處理查詢理解、來源存取與治理等問題。測試時若來源根本沒被取回，先查文件內容、切段、索引與權限；來源已取得但答案漏條件，則回到回答規則與模型輸出。不要每次失敗都只修改提示詞，也不要用模型自評代替負責人的核對。
保存來源版本、系統配置、測試日期與執行結果，才知道後一次變好或變壞可能來自哪裡。若更新切段或產品資料，應重跑受影響的題組與關鍵回歸題。把開發時反覆調整的題目與較少接觸的保留題分開，也有助於看出系統是否只對熟悉測試表現良好。
先定失敗處置，再定通過門檻
不同錯誤的後果不同：漏掉參考連結和錯誤承諾產品能力，不能只視為各扣一分。先列必須阻擋上線的錯誤，例如越權取得資料、捏造來源或給出明確不適用的建議，再依實際用途約定其他品質門檻。本文不提供通用及格百分比，因為樣本、風險與人工覆核方式都不同。
常見問題
可以全部由 AI 產生測試題嗎？
可讓 AI 擴充問法，但代表性與預期答案必須回到真實任務和核准資料。每題保存問題來源、使用者角色、適用版本、預期依據及應有行為；將正常題、無答案題、版本衝突題與越權題分開。去識別後的實際詢問可用來補足模型想不到的用語。由負責人確認測試題沒有錯誤前提，再保留一部分題目供獨立回測，避免只調到熟悉題目看起來很好。
測試過一次就能交付嗎？
一次通過只能作為當時版本的基線。資料、切段、檢索、權限或回答規則改動時，先列影響範圍，再重測相關題組與關鍵邊界題。紀錄問題、期望、實際來源、答案與缺陷原因，分開看找錯資料和用錯資料。若出現越權或高影響規格錯誤，應先限制相關功能並修正，再回復使用；不能用整體成功率掩蓋少量但嚴重的失敗。
參考資料與方法範圍
查核日期：2026 年 10 月 21 日。官方文件支援文中對應的平台或可及性說明；工作表與決策流程為本文整理，產業情境另行標示為假想示例。作者公開分享作為工作觀點來源，不作客戶成效或資格背書。
