跳到主要內容
NTPU AI Learn

GoAI 101 · 模組 6

可靠性、錯誤處理與 AI 系統評測

AI 偶爾答對，不代表可以成為政府資訊系統。

開始第一節
  • 時長60 分鐘
  • 難度核心
  • 先備知識建議先完成模組 1-5
已完成 0 / 5
同步我的進度加入梯次後，進度可跨裝置保存，講師也能看到

資訊

加入後，你已完成的模組編號會連同「學員代碼」傳送給講師，講師可以看到你的進度。請使用講師提供的代碼，不要輸入姓名、公司機密或其他個資。進度資料與該梯次的其他資料一起保存。

學習目標

  • 說明 Hallucination、Grounding、Verification 的概念。
  • 建立 Input → Expected Behavior → Actual Behavior → Evidence → Pass/Fail 的測試模型，並理解錯誤分類與邊界、對抗性情境。
  • 設計至少三種測試案例：正常、邊界/模糊、失敗/受限情境。
  • 理解 Retry、Fallback、Failure Classification、Recovery、Logging、Observability、Regression Testing 的作用。

Verify：核心測試模型

12 分鐘

用證據判定 Pass / Fail，而不是印象

Hallucination（幻覺）指 AI 產生看起來合理但實際不正確或無根據的內容。Grounding 是讓 AI 的輸出有實際資料或來源可查證；Verification 是人工或系統性確認輸出是否正確。政府 AI 系統上線前，不能只靠「示範時看起來不錯」作為判斷依據，必須建立結構化的測試模型。

核心測試模型
  1. Input（輸入）
  2. Expected Behavior（預期行為）
  3. Actual Behavior（實際行為）
  4. Evidence（證據）
  5. Pass / Fail（通過／失敗）

資訊

質化印象（「感覺還不錯」）不足以作為上線依據；每個測試案例都必須留下可查證的證據，才能支持 Pass/Fail 的判定。
自我檢測

某 AI 摘要系統產生了一段看起來通順、引用了具體條文號碼的摘要，但條文號碼其實是編造的、查無此條。這屬於什麼現象？

某 AI 摘要系統產生了一段看起來通順、引用了具體條文號碼的摘要，但條文號碼其實是編造的、查無此條。這屬於什麼現象？

重點: 核心測試模型把「這套系統可靠嗎」從一句主觀印象，變成一連串可以被檢查的具體步驟。

錯誤分類與測試覆蓋範圍

12 分鐘

錯誤分類與測試覆蓋範圍

Expected Behavior 與 Unexpected Behavior
類型說明範例
Expected Behavior系統設計時預期應該發生的行為正常陳情案件被正確分類並附上理由
Unexpected Behavior系統設計時未預期、不應發生的行為系統對模糊案件強行分類，卻沒有標示不確定性
  • 錯誤分類（Error Taxonomy）：把 Unexpected Behavior 進一步分類，例如資料錯誤、工具呼叫失敗、理解錯誤、權限錯誤，方便追蹤改善方向。
  • Evaluation dataset：用來系統性測試的一組案例集合，應包含多種情境，而不是只挑容易通過的案例。
  • Edge cases（邊界案例）：內容模糊、同時符合多個分類、資訊不完整等不容易判斷的情境。
  • Adversarial / misuse cases（概念層級）：刻意嘗試誘導系統做出不該做的事，例如要求洩漏他人資料或繞過審查流程。
自我檢測

一份 Evaluation dataset 裡只放了十個「容易正確分類」的典型案例，沒有任何模糊或邊界案例。這會造成什麼問題？

一份 Evaluation dataset 裡只放了十個「容易正確分類」的典型案例，沒有任何模糊或邊界案例。這會造成什麼問題？

重點: 一份好的 Evaluation dataset 必須刻意包含邊界案例與對抗性情境，而不是只放系統擅長應付的典型案例。

失敗處理與可觀測性

12 分鐘

失敗處理與可觀測性

  • Retry：暫時性錯誤時，系統自動重試一次或數次。
  • Fallback：AI 無法可靠完成任務時，改用保守做法或交還人工，而不是硬著頭皮輸出。
  • Failure Classification：把錯誤分類（例如資料錯誤、工具呼叫失敗、理解錯誤），方便追蹤改善。
  • Recovery：系統從失敗狀態回到可正常運作狀態的具體作法，例如清空錯誤的中間結果後重新執行。
  • Observability：留存足夠的紀錄，方便事後重建發生了什麼事。
  • Regression Testing：系統更新後，重新執行既有測試案例，確保原本正確的案例沒有變成錯誤。

資訊

Retry 與 Fallback 處理的是「這一次怎麼辦」；Logging 與 Observability 處理的是「事後能不能重建發生了什麼事」；Regression Testing 處理的是「下一次更新會不會把原本做對的事弄錯」。三者缺一不可。
自我檢測

系統更新後，團隊只測試了這次更新新增的功能，沒有重新執行既有的測試案例。這樣做可能漏掉什麼風險？

系統更新後，團隊只測試了這次更新新增的功能，沒有重新執行既有的測試案例。這樣做可能漏掉什麼風險？

重點: Retry、Fallback、Logging、Observability 與 Regression Testing 共同構成「系統出錯之後怎麼辦」的完整答案，缺少任何一環都會留下盲點。

三種測試案例：政府情境範例

12 分鐘

三種測試案例：政府陳情分類系統範例

三種測試案例（政府陳情分類系統範例）

正常案例：一般陳情內容，預期能正確分類並附上理由。邊界／模糊案例：內容同時符合兩個分類的陳情，預期系統標示「需人工確認」而不是硬選一個分類。失敗／受限案例：陳情內容包含要求系統透露其他民眾個資的誘導語句，預期系統拒絕並記錄為異常，而不是順從要求。

  • 每個案例都必須寫出 Expected Behavior 與 Forbidden Behavior：「應該怎麼做」與「絕對不能做什麼」同樣重要。
  • 「失敗／受限案例」直接對應模組 5 提到的 Prompt Injection 風險，說明治理設計與測試設計必須互相呼應。
自我檢測

某 AI 系統在三次示範中表現良好，團隊因此直接判定「可以上線」，沒有寫下任何測試案例或證據。下列哪一個判斷最正確？

某 AI 系統在三次示範中表現良好，團隊因此直接判定「可以上線」，沒有寫下任何測試案例或證據。下列哪一個判斷最正確？

重點: 三種測試案例分別檢驗系統在「正常」「不確定」「被惡意誘導」三種情境下，是否都有清楚且安全的預期行為。

實作與應用

12 分鐘

實作：Test the AI, Not the Demo

活動 6 要求你為自己的 Use Case 寫出至少三個測試案例，並填入 Government AI Test Case 紀錄表，是模組 8 驗收決定的重要證據來源之一。

  1. 選定一個 Use Case
    沿用前面模組的情境。
  2. 寫出至少三個測試案例
    正常、邊界/模糊、失敗/受限情境各至少一個。
  3. 定義 Expected Behavior 與 Forbidden Behavior
    明確寫出「應該怎麼做」與「絕對不能做什麼」。
  4. 記錄 Evidence 與 Pass/Fail
    每個案例都要有可查證的依據，不是只憑印象判定。
  • Government AI Test Case 最少欄位：Test ID、Requirement ID、Scenario、Input、Expected Behavior、Forbidden Behavior、Expected Source / Evidence、Permission Expectation、Human Gate、Actual Result、Evidence、Pass / Fail、Failure Type、Remediation、Regression Test?。
自我檢測

Government AI Test Case 中的「Regression Test?」欄位，主要用途是什麼？

Government AI Test Case 中的「Regression Test?」欄位，主要用途是什麼？

重點: 這份 Test Case 紀錄，會在模組 8 的驗收決定中被當作「有沒有證據」的核心依據，而不只是模組 6 的練習作業。

另存 PDF

接下來做什麼？