```html Building with AI — Advanced | AESOP AI Academy Module 10
🎯 進階 · 第一課

先定義問題

在動手建構 AI 系統之前，清晰的問題定義決定了一切後續決策的品質。

為何許多 AI 專案失敗，並非因為技術，而是因為問題定義錯誤？

2018 年，IBM 的 Watson for Oncology（癌症診療輔助系統）在多家醫院被終止使用。STAT News 的調查報導揭露，該系統在真實臨床環境中給出的治療建議，有時與腫瘤科醫師的判斷相悖，甚至被內部文件描述為「不安全且不正確」。關鍵原因在於：Watson 的訓練資料主要來自紀念斯隆凱特琳癌症中心（MSKCC）少數專家的假設性案例，而非真實的全球患者資料。IBM 把「協助醫師做出最佳決策」這個模糊願景，直接交給工程師去實作，卻從未嚴謹地回答：「這個系統要解決哪一個具體的臨床決策問題？在什麼資料條件下？對哪些患者族群有效？」問題定義的缺失，比任何演算法缺陷都更具破壞力。

問題定義的四個維度

Watson for Oncology 的案例清楚說明：一個 AI 系統的成敗，往往在第一行程式碼寫下之前就已決定。優秀的問題定義需要從四個維度同時思考。

維度一：問題的可操作性

「改善醫療品質」不是一個可操作的問題。「在急診室分診時，協助護理師辨識需優先處置的敗血症疑似患者」才是。問題必須具體到可以被測量、被驗證。

維度二：資料的可得性與代表性

你希望解決的問題，是否存在高品質的訓練資料？Watson 的失敗之一，正是訓練資料無法代表真實的全球患者分布。在定義問題時，必須同步評估資料現實。

維度三：利害關係人的真實需求

AI 系統服務的對象，真正的痛點是什麼？癌症醫師需要的不是「第二意見」，而是在海量文獻中快速找到與眼前患者最相關的臨床證據。訪談最終用戶，往往能顛覆最初的假設。

維度四：成功的衡量標準

如何判斷系統「成功」了？是準確率？用戶採納率？患者預後改善？不同的指標會導向截然不同的設計決策。在開始建構之前，必須與所有利害關係人就成功標準達成共識。

問題-解決方案配適框架

Google 的研究員 Sculley 等人在 2015 年的論文〈Machine Learning: The High-Interest Credit Card of Technical Debt〉中指出，ML 系統中最難以察覺、代價最高的技術債，往往來自問題定義階段的模糊性。他們提出一個核心問題：你真的需要機器學習嗎？

許多被包裝為「AI 解決方案」的問題，其實用簡單的規則引擎、資料庫查詢、或人工流程優化就能更有效解決。在決定使用 AI 之前，應先確認：問題具有充分的資料支撐、AI 的預測誤差在可接受範圍內、且解決方案的收益超過建構與維護成本。

  • 問題分解：將大問題拆解為若干子問題，逐一評估哪些適合 AI 介入
  • 基準線建立：在引入 AI 之前，先建立人工處理的基準線效能
  • 失敗情境預想：列出系統在哪些情況下會出錯，並評估後果嚴重性
  • 最小可行問題：先解決最核心、最具體的子問題，再逐步擴展範疇
📝 第一課測驗

先定義問題

測驗你對問題定義框架的理解。

1. IBM Watson for Oncology 被多家醫院終止使用的主要原因是什麼？
✓ 正確！Watson 的核心問題在於訓練資料主要來自少數專家的假設性案例，而非真實全球患者資料，且問題定義從一開始就過於模糊。
✗ 再想想。問題不在技術限制，而是更根本的問題定義與資料代表性缺失。
2. 以下哪一個是「可操作的問題定義」的良好範例？
✓ 正確！選項 D 具備了具體的目標（退貨分類）、可測量的標準（30 分鐘、95% 準確率）與明確的應用情境。
✗ 其他選項的問題定義都過於模糊，缺乏可測量的成功標準與具體的應用範疇。
3. 根據 Sculley 等人的研究，ML 系統中最難察覺、代價最高的技術債來自哪個階段？
✓ 正確！問題定義的模糊性是 ML 系統最隱性也最昂貴的技術債根源，因為它會影響所有後續的設計決策。
✗ Sculley 等人特別指出，問題定義階段的模糊性才是最根本的來源，技術層面的債務相對容易被發現和修復。
🧪 第一課實作

問題定義工作坊

與 AI 導師一起，練習將模糊的 AI 願景轉化為可操作的問題定義。

實作目標

在這個對話實作中，你將描述一個你想用 AI 解決的問題（可以是真實的或假設的），AI 導師會引導你運用四個維度框架，逐步深化問題定義的品質。

建議起點：「我想做一個 AI 系統來幫助台灣的___，請幫我定義這個問題。」
  1. 描述你想解決的問題領域（教育、醫療、零售等）
  2. 回答 AI 導師關於可操作性、資料、用戶需求的追問
  3. 嘗試寫出一個符合四個維度的完整問題定義
🎯 問題定義導師 AI 助手
🎯 進階 · 第二課

提示詞即設計

提示詞工程（Prompt Engineering）不只是技巧，它是 AI 系統架構的核心設計決策。

改變提示詞的結構，如何根本改變 AI 系統的行為與風險？

2023 年，紐約律師 Steven Schwartz 在一起訴訟案中，向法院提交了一份引用六個先例判決的法律文件。問題是：這些判決全部是 ChatGPT 虛構的。Schwartz 在使用 ChatGPT 輔助法律研究時，使用了過於開放的提示詞，要求模型「找出支持此論點的相關案例」，卻沒有在提示詞中設定任何邊界：禁止模型生成無法驗證的引用、要求標示不確定性、或明確限制只引用可核實的真實資料庫。最終，Schwartz 與其律師事務所被聯邦法院裁定罰款 5,000 美元，並受到嚴厲訓誡。這個案例展示了：提示詞的設計決策直接決定了系統的可靠性與風險邊界。

提示詞作為系統架構

Schwartz 的案例揭示了一個關鍵認知：在 LLM（大型語言模型）應用中，提示詞（Prompt）不僅是用戶輸入，更是整個系統行為的設計規格。一個設計不良的提示詞，等同於一個設計不良的系統架構。

OpenAI、Anthropic 等公司的技術文件將提示詞結構分為三個層次：系統提示（System Prompt）、情境提示（Contextual Prompt）、以及用戶輸入（User Input）。在建構 AI 應用時，系統提示是最關鍵的設計元素，它定義了模型的角色、能力邊界、輸出格式、以及在哪些情況下應當拒絕或標示不確定性。

提示詞設計的四個原則

原則一：明確的邊界設定

一個好的系統提示必須明確告訴模型「不應該做什麼」，而不只是「應該做什麼」。Schwartz 案的根本問題在於提示詞缺乏對模型生成引用的邊界限制。

原則二：不確定性的強制標示

在高風險應用（法律、醫療、財務）中，提示詞應強制要求模型標示其信心程度，並在無法確認的情況下主動聲明。「當你不確定時，請明確說明你不確定，並說明原因」應成為標準指令。

原則三：輸出格式的結構化控制

結構化的輸出要求可以大幅降低解析錯誤與誤用風險。要求模型以 JSON、Markdown 表格、或特定欄位格式輸出，能讓下游系統更可靠地處理結果，也讓人工審查更有效率。

原則四：情境注入的最小化

2023 年 Bing Chat 的早期版本因大量用戶注入情境資訊，導致模型出現情緒化回應。Google 的研究顯示，提示詞中注入的情境越多，模型「越軌」的機率越高。最小化不必要的情境注入是提升系統穩定性的有效手段。

📝 第二課測驗

提示詞即設計

測驗你對提示詞工程設計原則的理解。

1. 律師 Schwartz 被法院罰款的根本原因是什麼？
✓ 正確！提示詞沒有限制模型只引用可核實的資料，也沒有要求模型標示不確定性，是根本設計缺失。
✗ 問題核心在提示詞設計，而非使用 AI 工具本身是否合規。
2. 在建構 AI 應用時，以下哪一層提示詞是定義系統行為最關鍵的設計元素？
✓ 正確！系統提示定義了模型的角色、邊界與輸出格式，是整個應用系統行為的核心規格。
✗ 雖然所有層次都重要，但系統提示是最根本的架構決策，決定了模型的整體行為框架。
3. 為什麼在高風險 AI 應用的提示詞中，「強制標示不確定性」是重要的設計原則？
✓ 正確！標示不確定性是讓人機協作發揮效用的關鍵機制，使人工審查能聚焦在最需要驗證的環節。
✗ 不確定性標示的核心價值在於支援人工監督，而非技術效能或法規遵循。
🧪 第二課實作

提示詞設計實驗室

練習設計符合四個原則的系統提示詞，探索不同設計決策的影響。

實作目標

在這個對話實作中，你將與 AI 導師討論提示詞工程的設計決策。描述一個應用場景，AI 會引導你思考如何設計更安全、更可靠的系統提示。

建議起點：「我想設計一個 AI 客服系統的系統提示，請幫我評估我的設計。」
  1. 描述你的應用場景與初步的系統提示草稿
  2. 討論各設計原則在你的場景中的應用方式
  3. 修訂你的提示詞，使其更符合安全設計標準
✍️ 提示詞設計導師 AI 助手
🎯 進階 · 第三課

評估 AI 輸出

建立系統性的評估框架，是確保 AI 系統在真實環境中可靠運作的核心能力。

如何設計一個評估流程，讓 AI 輸出品質可被持續衡量？

2023 年，Air Canada 的 AI 客服聊天機器人向一名旅客告知，公司有一項「事後申請喪假折扣」的政策。這個政策根本不存在。當旅客依據聊天記錄申請退款被拒後，提起訴訟。卑詩省消費者保護局的仲裁機構裁定 Air Canada 必須賠償旅客，並明確指出：公司不能以「這是 AI 說的」為由推卸責任。Air Canada 在部署聊天機器人時，顯然缺乏對 AI 輸出的系統性評估機制——沒有定期抽樣審查、沒有對「高風險主張」的自動標記、也沒有針對政策類問題的答覆準確率追蹤。

評估框架的三個層次

Air Canada 案揭示了一個普遍存在的部署陷阱：公司往往把大量資源投入在模型訓練，卻忽略了持續的輸出評估機制。評估 AI 輸出需要在三個不同的層次同時進行。

層次一：自動化指標評估

針對可量化的輸出品質指標進行自動化追蹤。包括：事實準確率（Factual Accuracy）、回覆一致性（Consistency）、拒答率（Refusal Rate）、以及與基準答案的相似度（BLEU、ROUGE 等）。這些指標應即時監控並設定警報閾值。

層次二：人工抽樣審查

定期由領域專家對 AI 輸出進行抽樣審查，評估自動化指標無法捕捉的面向：語義的微妙錯誤、文化敏感性、以及脈絡適當性。Air Canada 如果建立了每週抽查客服對話的機制，很可能在早期就能發現問題。

層次三：用戶行為信號分析

分析用戶對 AI 輸出的行為反應：他們是否頻繁要求重新回答？是否在 AI 答覆後立即聯絡人工客服？這些行為信號往往比任何自動化指標更能反映 AI 輸出在真實場景中的問題。

高風險主張的特殊處理

Meta 的 Llama 2 技術報告指出，在高風險領域（法律、醫療、財務、政策），AI 系統需要針對「高度主張性（High-Assertiveness）」的輸出建立額外的把關機制。所謂高度主張性，是指模型以確定語氣聲稱特定事實，而不標示任何不確定性。

  • 自動標記機制：使用分類器識別包含具體數字、政策聲明、法律條文引用的輸出，並路由至人工審查佇列
  • 反事實測試：定期向系統輸入包含錯誤前提的問題，觀察系統是否能正確糾正而非順從
  • 版本對比評估：每次更新模型或提示詞後，與前一版本進行系統性對比，確保沒有意外的能力退化
📝 第三課測驗

評估 AI 輸出

測驗你對 AI 輸出評估框架的理解。

1. Air Canada 的案例中，仲裁機構的裁決帶來了哪個重要的法律原則？
✓ 正確！這個裁決確立了一個重要原則：部署 AI 系統的組織對其輸出承擔法律責任，AI 不是免責的藉口。
✗ 裁決的核心在於責任歸屬，而非禁止使用 AI 或強制認證。
2. 「反事實測試」在 AI 輸出評估中的主要用途是什麼？
✓ 正確！反事實測試是評估 AI 系統是否容易被誘導提供錯誤資訊的有效方法。
✗ 反事實測試的核心是檢驗模型面對錯誤前提時的行為，不是壓力測試或安全掃描。
3. 以下哪一項屬於「用戶行為信號分析」的例子？
✓ 正確！用戶在 AI 回覆後的後續行為，是反映輸出品質最真實的信號之一。
✗ 前三個選項分別屬於自動化指標評估和人工審查，只有 D 是用戶行為信號分析。
🧪 第三課實作

輸出評估框架設計

為一個真實的 AI 應用場景，設計完整的三層評估機制。

實作目標

在這個對話實作中，你將選擇一個 AI 應用場景，並與 AI 導師討論如何為該場景設計三個層次的評估框架。

建議起點：「我正在部署一個 AI 系統用於___，請幫我設計評估框架。」
  1. 描述你的 AI 應用場景與主要風險
  2. 討論哪些自動化指標最適合你的場景
  3. 設計人工審查的頻率與抽樣策略
📊 輸出評估導師 AI 助手
🎯 進階 · 第四課

人機協作流程設計

有效的 AI 系統不是取代人，而是重新設計人與機器各自發揮優勢的分工結構。

在一個 AI 輔助的流程中，哪些決策應該保留給人類？

2016 年，美國第一家大規模部署 AI 量刑輔助工具的法院，開始使用 Northpointe 公司的 COMPAS 系統。ProPublica 的調查發現，COMPAS 在預測再犯風險時，對黑人被告的誤判率幾乎是白人被告的兩倍。然而更關鍵的問題是：法官在實際使用中，往往把 COMPAS 的風險評分視為決定性依據，而非參考資訊。設計者預設的人機分工是「AI 輔助、法官決定」，但實際的工作流程卻演變成「AI 建議、法官批准」。當人類退出了真正的決策迴圈，所有 AI 的偏誤都直接轉化為司法後果。

決策迴圈中的人機分工

COMPAS 的案例說明，人機協作的失敗往往不是設計問題，而是工作流程設計（Workflow Design）問題。即使系統設計者預設了正確的分工，如果工作流程的實際執行讓人類退出了真正的決策環節，整個系統就會失去設計時的安全假設。

Google 的 PAIR（People + AI Research）研究小組提出了一個核心框架：設計人機協作流程時，必須先區分三類決策——哪些應該完全由 AI 執行（低風險、高頻率、可逆的），哪些應該由 AI 建議、人類批准（中等風險），哪些應該完全由人類主導、AI 僅提供資訊（高風險、不可逆的）。

防止自動化偏誤的設計策略

自動化偏誤（Automation Bias）是指人類傾向於過度信任自動化系統建議的心理現象。這在航空、醫療、司法等高風險領域已有充分的研究文獻記錄。設計人機協作流程時，必須主動對抗自動化偏誤。

  • 強制獨立判斷：要求操作人員在看到 AI 建議之前，先記錄自己的初步判斷，再與 AI 對比
  • 多元意見呈現：向用戶呈現多個替代方案及其信心區間，而非單一「最佳答案」
  • 決策責任歸屬：讓人類明確「簽署」每一個重要決定，而非僅點擊「接受」
  • 異常高亮顯示：當 AI 判斷與歷史基準有顯著偏差時，主動提示操作人員仔細審查
  • 定期脫離演練：讓人員定期在沒有 AI 輔助的情況下執行任務，維持獨立判斷能力
📝 第四課測驗

人機協作流程設計

測驗你對人機協作框架與自動化偏誤的理解。

1. COMPAS 系統在司法實踐中最嚴重的流程設計問題是什麼？
✓ 正確！設計者預設「AI 輔助、法官決定」，但工作流程讓 AI 建議成為事實上的決定，這正是自動化偏誤的體現。
✗ 核心問題不是技術限制或培訓，而是工作流程設計讓人類實質退出了決策迴圈。
2. 根據 PAIR 框架，以下哪類決策最適合「完全由 AI 執行」？
✓ 正確！電子郵件分類符合「低風險、高頻率、可逆」的標準，適合完全自動化。其他選項都涉及高風險、不可逆的重大決定。
✗ 完全自動化最適合低風險、高頻率且可逆的任務。其他選項都涉及人身自由、生命安全或重大財務決定。
3. 「強制獨立判斷」策略如何對抗自動化偏誤？
✓ 正確！先記錄獨立判斷再對比，能確保人類保持真正的思考參與，而非直接採納 AI 建議。
✗ 完全不看 AI 建議會喪失 AI 的輔助效益；關鍵是確保人類在參照 AI 之前已形成獨立判斷。
🧪 第四課實作

人機協作流程設計工作坊

為一個真實場景設計防止自動化偏誤的人機協作流程。

實作目標

在這個對話實作中，你將描述一個組織中正在或計劃引入 AI 的工作流程，與 AI 導師共同分析決策分工，並設計防止自動化偏誤的機制。

建議起點：「我們公司計劃用 AI 來輔助___決策，請幫我設計人機協作流程。」
  1. 描述現有的工作流程與引入 AI 的目標
  2. 與導師討論哪些決策應由 AI 全自動、哪些需人類批准、哪些必須人類主導
  3. 設計至少兩種防止自動化偏誤的具體機制
🔄 人機協作設計導師 AI 助手
🎯 進階 · 第五課

測試與紅隊演練

在 AI 系統對外開放之前，系統性地尋找它的弱點，是負責任部署的必要條件。

你如何在危害發生之前，找出 AI 系統最危險的失敗模式？

2022 年 11 月，Meta 發布了 Galactica——一個專為科學研究設計的大型語言模型，宣稱能夠「總結學術論文、解釋數學、撰寫科學程式碼」。然而在發布後短短三天，Meta 就緊急下架了公開展示介面。研究人員發現，Galactica 在被要求撰寫關於熊的歷史、或描述摩洛哥的文化時，會以極高的信心生成大量事實錯誤的內容，且無任何不確定性標示。更嚴重的是，有研究人員發現它能輕易生成聽起來像是有學術依據的偽科學論述。Meta 後來承認，在公開發布前，該模型未經過充分的紅隊演練（Red-Teaming），特別是針對「看似合理的謬誤」這類失敗模式的系統性測試嚴重不足。

紅隊演練的方法論

紅隊演練（Red-Teaming）是一種借自軍事與資安領域的測試方法，指組織一組人以對抗性視角系統性地嘗試讓系統失敗。在 AI 系統的語境中，紅隊演練已成為負責任部署的標準流程——Anthropic、OpenAI、Google DeepMind 等公司都在發布前進行多輪紅隊演練。

有效的 AI 紅隊演練不是隨機嘗試讓系統出錯，而是針對特定的失敗模式類型進行系統性搜索。

失敗模式一：幻覺與虛假資訊

針對特定領域知識進行密集測試，特別是模型訓練資料可能較稀疏的領域。Galactica 的失敗正是未充分測試此類失敗模式。

失敗模式二：越獄與提示詞注入

嘗試通過精心設計的輸入繞過系統的安全限制。2023 年，多個大型語言模型被發現可以通過「角色扮演」框架繞過內容過濾。

失敗模式三：邊緣案例與分布外輸入

測試系統對訓練資料分布以外的輸入的行為。這包括罕見語言、非標準格式、或特定文化脈絡下的問題。

失敗模式四：長期與累積效應

測試系統在長對話或連續使用後的行為漂移。某些系統在短期表現良好，但在長時間互動後會出現不一致或越軌行為。

結構化的測試計畫

Anthropic 在其紅隊演練的公開描述中，強調了結構化測試計畫的重要性：測試必須在發布前完成、覆蓋所有預期使用場景、並包含至少一輪由外部專家執行的獨立評估。僅靠內部測試往往有系統性盲點，因為內部人員對系統的熟悉度會降低他們發現某些問題的敏感度。

  • 測試案例矩陣：針對每個失敗模式類型建立系統性的測試案例集
  • 多樣化測試人員：納入不同背景、文化、技術能力的測試人員
  • 嚴重性分級：將發現的問題按嚴重性與發生機率分級，優先修復高風險問題
  • 回歸測試：每次修復後重新運行完整的測試套件，確保修復未引入新問題
📝 第五課測驗

測試與紅隊演練

測驗你對紅隊演練方法論的理解。

1. Meta 的 Galactica 模型在發布三天後被緊急下架的直接原因是什麼？
✓ 正確！Galactica 在「看似合理的謬誤」這類失敗模式上缺乏充分測試，導致研究社群快速發現嚴重的可靠性問題。
✗ 下架原因是模型可靠性問題，特別是以高信心產出錯誤資訊，不是技術或法律問題。
2. 為什麼紅隊演練應包含外部專家的獨立評估，而不只是內部測試？
✓ 正確！熟悉度偏誤是內部測試的根本限制——對系統越了解，越難以用真正「陌生」的方式去尋找問題。
✗ 外部評估的核心價值是克服內部人員的熟悉度偏誤，而非成本或工具優勢。
3. 以下哪一項屬於「越獄與提示詞注入」的測試範疇？
✓ 正確！「角色扮演」框架是一種典型的越獄手法，通過重新框架化問題的性質來繞過內容過濾機制。
✗ 越獄測試專注於尋找繞過安全機制的方法，不是效能、語言品質或多語言能力測試。
🧪 第五課實作

紅隊演練規劃實作

為一個 AI 系統設計完整的紅隊演練計畫，識別其最關鍵的失敗模式。

實作目標

在這個對話實作中，你將描述一個 AI 系統，並與 AI 導師共同設計一份紅隊演練計畫，涵蓋失敗模式識別、測試案例設計、以及嚴重性分級。

建議起點：「我需要在發布前對一個___系統進行紅隊演練，請幫我規劃測試計畫。」
  1. 描述你的 AI 系統及其主要應用場景
  2. 識別最可能發生的失敗模式類型
  3. 為每個失敗模式設計具體的測試案例
🔴 紅隊演練導師 AI 助手
🎯 進階 · 第六課

負責任的部署

從實驗室到真實世界的過渡，是 AI 系統風險最集中、決策最關鍵的階段。

部署 AI 系統時，哪些機制能讓你在問題擴大前及時介入？

2016 年 3 月，Microsoft 發布了 AI 聊天機器人 Tay，定位為與 Twitter 用戶對話的社群媒體 AI。在正式上線後不到 24 小時，Tay 就開始發布種族主義、仇女、否認大屠殺等極端內容，Microsoft 被迫緊急下線。問題根源在於：Microsoft 的部署計畫假設用戶會進行「正常對話」，卻沒有為惡意協同操縱設計防護機制，也沒有在部署初期設置限制性的滾動上線（Staged Rollout）策略——讓系統在小範圍用戶群中運行，觀察並修正問題後再逐步擴展。這次事件直接推動了業界對「AI 系統滾動部署」標準的建立。

滾動部署策略

Tay 的案例讓業界深刻認識到：AI 系統的部署不應是一個「全有或全無」的開關，而應是一個有意識的、可控的漸進過程。滾動上線（Staged Rollout）是現代 AI 部署的基本策略，它將風險暴露控制在可管理的範圍內。

階段一：內部 Alpha 測試

僅限內部員工使用。目標是捕捉基本的功能性問題和明顯的安全缺陷。此階段的發現不應公開，以避免攻擊者提前掌握系統弱點。

階段二：封閉 Beta 測試

邀請少量外部用戶（通常為 1-5%）參與測試。應優先選擇能提供高質量反饋的用戶，包括領域專家和潛在的惡意使用者（在可控環境下）。

階段三：漸進式開放

依據前一階段的觀察指標，逐步將開放比例從 5% 提升至 20%、50%、最後全面開放。每個階段之間設置觀察期，並定義明確的「暫停條件」——若出現哪些情況應立即停止擴展。

緊急介入機制

即使在充分測試後，真實世界的部署仍可能出現意料之外的情況。每個 AI 系統都應在部署前設計完整的緊急介入機制，確保問題能被及時發現並遏制。

  • 即時監控儀表板：監控關鍵指標（錯誤率、拒答率、用戶投訴數），設定自動警報閾值
  • 緊急熔斷機制：可以在數分鐘內將系統回滾或下線的技術能力
  • 事件響應計畫：預先定義誰有權力決定暫停系統、通報流程與對外溝通模板
  • 用戶回報管道：為用戶提供簡單的問題回報機制，並建立快速分類響應的流程
📝 第六課測驗

負責任的部署

測驗你對滾動部署策略與緊急介入機制的理解。

1. Microsoft Tay 事件推動了業界的哪項標準的建立？
✓ 正確！Tay 的全面崩潰展示了「全或無」部署策略的危險，直接推動了滾動上線成為業界標準。
✗ 業界的回應是建立漸進式部署的標準，而非政府審查或全面禁止。
2. 在滾動部署的「封閉 Beta 測試」階段，為何應優先選擇能進行惡意使用的測試人員（在可控環境下）？
✓ 正確！主動在受控環境中測試惡意使用場景，是防止 Tay 式崩潰的核心策略。
✗ 核心邏輯是「主動尋找弱點勝於被動發現」，而非法規要求或使用體驗考量。
3. 「緊急熔斷機制」在 AI 部署中的主要功能是什麼？
✓ 正確！緊急熔斷機制的核心價值是速度——問題被發現後能多快被遏制，決定了最終的損害程度。
✗ 熔斷機制的核心是快速響應能力，讓決策者能在危機時刻迅速切斷損害源。
🧪 第六課實作

部署計畫設計實作

為一個 AI 系統設計完整的滾動部署計畫與緊急介入機制。

實作目標

在這個對話實作中，你將描述一個即將上線的 AI 系統，並與 AI 導師共同設計一份涵蓋各部署階段的計畫，包括每個階段的成功指標與暫停條件。

建議起點：「我們的 AI 系統即將部署，請幫我設計一份滾動上線計畫。」
  1. 描述你的系統及其潛在風險
  2. 設計三個部署階段的用戶範圍與觀察指標
  3. 定義各階段的「暫停條件」與緊急響應流程
🚀 部署計畫導師 AI 助手
🎯 進階 · 第七課

為公平而建構

AI 系統中的偏誤不是意外，它是設計決策、資料選擇與評估框架共同造就的結果。

一個在技術指標上表現良好的 AI 系統，是否可能對特定群體造成系統性傷害？

2018 年，MIT Media Lab 研究員 Joy Buolamwini 與 Timnit Gebru 發表論文〈Gender Shades〉，系統性評估了三家大型科技公司（IBM、Microsoft、Face++）的商用臉部辨識系統。結果顯示，這些系統在識別膚色較深女性時，錯誤率最高達 34.7%；而對膚色較淺男性，錯誤率僅為 0.8%。更關鍵的發現是：這三家公司的系統都聲稱達到了「高準確率」——因為他們的評估資料集主要由膚色較淺的男性組成。整體準確率掩蓋了對特定族群的系統性失敗。這篇論文直接促使美國多個城市立法限制政府使用臉部辨識技術。

偏誤的三個來源

Buolamwini 與 Gebru 的研究揭示了一個核心問題：整體準確率是一個具有欺騙性的指標，它可以掩蓋系統對特定子群體的系統性失敗。在為公平而建構時，必須理解偏誤的不同來源。

來源一：資料偏誤

訓練資料的組成反映了歷史上的社會不平等。臉部辨識資料集長期以來以白人男性為主要組成，導致模型在這個族群上表現最好。資料收集的邏輯直接嵌入了偏誤。

來源二：評估指標偏誤

僅使用整體準確率作為評估指標，等同於允許對少數群體的系統性失敗被平均值掩蓋。公平性評估需要按照人口統計子群體分別計算並比較指標。

來源三：用途偏誤

即使系統本身的準確率相對均衡，如果被部署在針對特定群體的高風險情境（如刑事調查），錯誤的後果分配也會造成系統性不公平。部署情境與偏誤後果同樣重要。

公平性指標的實踐框架

Google 的 Responsible AI Practices 文件提出，沒有任何單一的公平性定義能夠適用於所有情境——不同的問題需要選擇不同的公平性指標。建構者的責任是理解各種定義，並根據應用情境做出有依據的選擇。

  • 分組準確率評估：按照性別、年齡、種族等人口統計變數分別計算準確率，識別系統性差距
  • 誤差類型分析：區分假陽性（False Positive）與假陰性（False Negative）的分布，在高風險應用中，兩種誤差的後果往往截然不同
  • 代理變數偵測：識別訓練特徵中是否包含或高度相關於受保護屬性（如郵遞區號可能代理種族）
  • 社群參與：在系統設計階段納入受影響族群的代表，而非僅在系統建構完成後徵詢意見
📝 第七課測驗

為公平而建構

測驗你對 AI 偏誤來源與公平性評估框架的理解。

1. 〈Gender Shades〉研究發現，臉部辨識系統宣稱「高準確率」的最大問題是什麼？
✓ 正確！這正是評估指標偏誤的典型案例——評估資料集的組成決定了「準確率」的真正含義。
✗ 問題不在於資料授權或準確率造假，而是評估資料集的代表性不足導致整體指標具有欺騙性。
2. 「代理變數」在 AI 公平性問題中指的是什麼？
✓ 正確！代理變數是隱性偏誤的主要來源——即使模型沒有直接使用種族或性別，相關特徵仍可能傳遞同等的偏誤。
✗ 代理變數是公平性評估中的核心概念——看似中立的特徵可能成為受保護屬性的替代指標。
3. 為什麼在高風險 AI 應用中，需要分別分析假陽性（False Positive）與假陰性（False Negative）的分布？
✓ 正確！在刑事司法中，假陽性（誤判無辜者）和假陰性（放走罪犯）的後果性質完全不同，必須分別評估其在不同族群中的分布。
✗ 分開分析誤差類型的目的是識別不同錯誤對不同族群的差異性後果，而非美化指標或滿足法規要求。
🧪 第七課實作

公平性審查實作

為一個 AI 系統進行公平性審查，識別潛在的系統性偏誤並設計對應措施。

實作目標

在這個對話實作中，你將描述一個 AI 系統的應用情境，並與 AI 導師共同分析其可能存在的偏誤來源，設計公平性評估框架。

建議起點：「我正在開發一個用於___的 AI 系統，請幫我進行公平性審查。」
  1. 描述系統的應用情境與目標族群
  2. 識別資料偏誤、評估指標偏誤、用途偏誤的潛在風險
  3. 設計分組評估策略與代理變數偵測方法
⚖️ 公平性審查導師 AI 助手
🎯 進階 · 第八課

持續的責任

AI 系統的部署不是終點，而是一項長期責任的開始——監控、更新、問責。

當 AI 系統造成傷害時，誰應該負責，責任邊界如何劃定？

2019 年至 2020 年間，荷蘭政府使用自動化風險評估系統（SyRI，Systeem Risico Indicatie）對社會福利申請人進行欺詐偵測，主要針對低收入、移民比例較高的社區。2020 年 2 月，荷蘭法院裁定 SyRI 違反《歐洲人權公約》第 8 條（隱私權），判令立即停用。法院指出：政府未能清楚說明 SyRI 的工作原理、無法讓受影響公民提出異議、且系統的運作缺乏獨立的持續監督機制。這個案例確立了一個重要原則：AI 系統在部署後，必須持續維持可解釋性、申訴機制與外部問責。

部署後的三項核心責任

SyRI 案說明，AI 系統的法律與倫理責任不隨部署而終止。荷蘭法院的判決明確了：政府（以及任何使用 AI 影響他人的組織）在部署後仍需持續履行三項核心責任。

責任一：可解釋性的維持

受 AI 決策影響的人，有權得到系統如何做出決策的解釋。這不僅是法律要求（如歐盟 GDPR 第 22 條），也是基本的程序正義。「黑箱」系統在高風險決策中不應被接受。

責任二：申訴機制的設計

任何被 AI 系統做出不利決定的個人，必須有清晰、可行的申訴途徑。這包括：明確告知決定的依據、提供異議管道、以及確保申訴過程由人類審查，而非再次交由 AI 決定。

責任三：獨立的持續監督

部署方自我監督存在利益衝突。高風險 AI 系統需要獨立的外部稽核機制，定期評估系統的實際表現，特別是對不同族群的差異性影響。

AI 系統的全生命週期責任

歐盟的《人工智慧法》（AI Act，2024 年正式生效）建立了全球第一個對 AI 系統的系統性法律框架，明確要求高風險 AI 系統必須在整個生命週期中維持合規——包括初始設計、部署前測試、部署後監控，以及系統退役。

  • 效能監控與退化偵測：模型效能會隨時間退化（因資料分布變化、世界狀態改變），需要持續監控並設定再訓練觸發條件
  • 變更管理：每次模型更新、提示詞修改或系統架構調整，都應進行完整的重新評估，而非假設「小改動不影響大局」
  • 事後事件分析：當系統造成傷害時，進行系統性的根本原因分析，而非僅修復表面症狀
  • 文件化與透明度：維持詳細的系統文件，包括訓練資料來源、設計決策理由、評估結果與已知限制，使外部問責成為可能
📝 第八課測驗

持續的責任

測驗你對 AI 系統全生命週期責任與問責機制的理解。

1. 荷蘭法院裁定 SyRI 系統違法的主要理由是什麼？
✓ 正確！法院的判決確立了部署後責任的三個核心要素：可解釋性、申訴機制、獨立監督。
✗ 法院判決的核心是程序正義問題，而非技術準確率或採購合規。
2. 為什麼 AI 系統的效能會隨時間「退化」，需要持續監控？
✓ 正確！這稱為「資料漂移（Data Drift）」——當真實世界的狀態與訓練時不同，模型的預測能力就會下降。
✗ 效能退化的根本原因是訓練資料分布與現實世界的逐漸偏離，而非硬體或攻擊問題。
3. 歐盟《人工智慧法》（AI Act）對全球 AI 治理最重要的意義是什麼？
✓ 正確！AI Act 的歷史意義在於它是第一個涵蓋設計、部署、監控、退役整個生命週期的全面性 AI 法律框架。
✗ AI Act 不是禁令，也不要求開源，而是建立了風險分級的全生命週期法規框架。
🧪 第八課實作

持續責任框架設計

為一個已部署的 AI 系統設計完整的問責與持續監督機制。

實作目標

在這個對話實作中，你將描述一個已上線的 AI 系統，並與 AI 導師共同設計一套涵蓋可解釋性、申訴機制、持續監控的完整責任框架。

建議起點：「我們的 AI 系統已經上線運作，請幫我設計一套持續問責框架。」
  1. 描述系統的應用情境與可能影響的族群
  2. 設計可解釋性機制與申訴流程
  3. 規劃獨立監督的頻率、方法與觸發再訓練的條件
🏛️ 持續責任導師 AI 助手

📋 模組總測驗

涵蓋本模組全部八課的內容。共 15 題，測驗你對 AI 系統建構的綜合理解。

1. IBM Watson for Oncology 失敗的核心教訓是什麼？
✓ 正確！問題定義的品質決定了一切後續決策的品質。
✗ Watson 的核心教訓在問題定義與資料代表性，而非技術架構選擇。
2. 以下哪一項最能體現「問題-解決方案配適」的正確思維？
✓ 正確！許多「AI 解決方案」其實用更簡單的方法就能解決，先質疑是否需要 AI 才是正確起點。
✗ 問題定義應先於技術選擇，而非反過來讓技術決定問題框架。
3. Schwartz 律師事件對 AI 提示詞設計的最主要啟示是？
✓ 正確！提示詞設計是系統架構決策，不是使用技巧——邊界設定與不確定性要求是關鍵設計元素。
✗ 問題不在模型本身，而在提示詞設計缺乏邊界與不確定性標示機制。
4. 在 AI 輸出評估的三個層次中，哪一層次最能捕捉語義的微妙錯誤？
✓ 正確！自動化指標無法捕捉語義細節，需要領域專家的人工判斷。
✗ 語義的微妙錯誤需要人類的領域知識才能識別，自動化工具和行為信號都無法有效捕捉。
5. Air Canada 聊天機器人案例對 AI 部署者的法律責任帶來了什麼影響？
✓ 正確！裁定確立了一個重要原則：組織對自己部署的 AI 系統的行為和輸出負責。
✗ 裁定明確否定了「AI 說的，不是我說的」這種責任規避論述。
6. COMPAS 量刑系統的案例說明，「人機協作」最容易在哪個環節失敗？
✓ 正確！設計與執行之間的落差——預設「AI 輔助」變成實際的「AI 決定」——是協作失敗的核心原因。
✗ 工作流程執行層面的失敗往往比技術設計失敗更難被察覺，也更具破壞力。
7. 以下哪一項是「自動化偏誤」（Automation Bias）的典型表現？
✓ 正確！自動化偏誤是心理現象，指人類過度信任自動化建議而放棄獨立判斷。
✗ 自動化偏誤描述的是人類行為模式，而非 AI 系統本身的缺陷。
8. Meta Galactica 的快速下架案例，主要說明了 AI 發布前哪個流程的重要性？
✓ 正確！Galactica 在「高信心生成錯誤資訊」這個失敗模式上缺乏充分的紅隊測試，是下架的直接原因。
✗ Galactica 案例的核心教訓是發布前紅隊演練的重要性，特別是針對模型最可能出錯的場景。
9. Microsoft Tay 事件後，業界建立的「滾動上線」標準的核心邏輯是什麼？
✓ 正確！滾動部署的核心是風險控制——在問題影響範圍有限時發現並處理，而非等到全面開放後才應對。
✗ 滾動部署的本質是風險管理策略，而非人員監控或法規遵循。
10. 〈Gender Shades〉研究對 AI 評估方法論的最大貢獻是什麼？
✓ 正確！這是公平性評估方法論的核心貢獻——整體指標可以掩蓋對特定群體的系統性傷害。
✗ 研究的方法論貢獻在於揭示了評估指標的設計如何影響對 AI 系統公平性的理解。
11. 在 AI 公平性設計中，「代理變數」（Proxy Variable）最主要的危險是什麼？
✓ 正確！代理變數讓隱性歧視變得難以被發現——表面上遵守了不使用受保護屬性的規定，實際上仍在歧視。
✗ 代理變數的危險在於它讓歧視變得「合法且隱蔽」，而非影響技術效能。
12. 荷蘭法院 SyRI 判決對 AI 系統設計者的核心要求是什麼？
✓ 正確！SyRI 判決確立了 AI 系統部署後責任的三大支柱：可解釋性、申訴管道、外部問責。
✗ 法院沒有禁止使用 AI，而是明確了使用 AI 時必須持續維持的程序性保障。
13. 「資料漂移」（Data Drift）對已部署 AI 系統的影響是什麼？
✓ 正確！資料漂移是所有已部署 ML 系統都面臨的挑戰——世界在變化，但模型不會自動更新。
✗ 資料漂移是統計概念，指的是真實世界的輸入分布與訓練時的假設出現偏離。
14. 以下哪一項說法最準確描述了紅隊演練中「多樣化測試人員」的重要性？
✓ 正確！同質性的測試團隊有系統性盲點——他們傾向於以相似的方式使用系統，而不同背景的人員會發現不同的問題。
✗ 多樣化的核心價值在於增加測試行為的覆蓋範圍，而非認證合規或個人偏見管控。
15. 在本模組所討論的所有案例中，哪一個共同主題最能概括 AI 系統建構的核心挑戰？
✓ 正確！從 Watson 到 Tay、從 COMPAS 到 SyRI，每個案例都展示了技術能力與負責任設計之間的鴻溝——這正是本模組的核心命題。
✗ 本模組的案例共同揭示的不是技術或資源限制，而是設計決策與責任框架的重要性。
```