軟體軟體倫理:為什麼演算法偏見

computer%20screen%20showing%20data%20visualization...
發表時間:2026 年 10 月 27 日 | 更新日期:2026 年 10 月 27 日 | 編輯:雅寶社區編輯團隊
軟體軟體倫理:為什麼演算法偏見 - 雅寶社區 · 頂客論壇

二、偏見是怎麼被「製造」出來的?一條完整的責任鏈

演算法偏見很少是單一環節的錯,它更像是生產線上每一站都稍微歪一點,最後組裝出來的產品就歪得很明顯。理解這條鏈,是評測與改善的前提。

2.1 資料層:歷史歧視的數位化

資料不是「被撿到的」,而是「被生產出來的」。誰有機會被記錄、誰被警察攔檢、誰的申訴被立案、誰的病歷被完整登載,本身就受資源與權力分布影響。美國的警務預測系統若以「該區域過去的逮捕數」作為犯罪熱度指標,就會形成一個自我實現的循環:過去巡邏多的地方逮捕多,逮捕多的地方被預測為高風險,高風險的地方巡邏更多。模型學到的是「警察去哪裡」,卻被解讀為「犯罪在哪裡」。

評測時的第一個動作,永遠是問:這份資料是怎麼產生的?誰被記錄、誰被漏掉、記錄的標準是否一致?

2.2 標籤與代理變數:我們以為在測 A,其實在測 B

監督式學習需要有「正確答案」,但我們真正關心的問題,往往沒有現成的正確答案。於是我們找代理:用「是否錄取」代理「是否適任」,用「是否再犯」代理「是否危險」,用「醫療支出」代理「健康狀況」,用「按讚與停留時間」代理「使用者滿意度」。

代理變數本身不是錯,錯在忘記它是代理。一旦忘記,模型就會把代理變數裡所有與目標無關的雜訊一併學進去。醫療支出與種族、社經地位高度相關,於是「預測誰需要照護」悄悄變成了「預測誰付得起照護」。

2.3 目標函數與模型選擇:你優化什麼,就會得到什麼

目標函數是整個系統的價值宣言,只是它寫在數學裡,很少有人讀。當你告訴模型「最大化整體營收」,它就沒有理由在乎少數族群被錯誤拒絕;當你告訴它「最大化點擊率」,它就會學會餵給使用者最容易被點、而不是最有益的東西。

更隱微的是特徵工程。把「郵遞區號」放進模型,看起來只是地理資訊,實際上它常常是族裔與社經地位的強力代理。把「姓名」放進去,模型可能學到語言與國籍的關聯。工程師未必有歧視意圖,但特徵的選擇本身就是在做價值判斷。

2.4 部署與回饋迴路:偏見會自己長大

模型上線之後,偏見不會靜止,它會透過回饋迴路自我強化。推薦系統把某類內容推給某群人,那群人的行為資料就更多,模型於是把「這類內容適合這群人」學得更牢。信用模型拒絕了某個地區的申請人,該地區就永遠不會產生「按時還款」的紀錄,下一代模型更確信那個地區風險高。

這就是為什麼偏見稽核不能只做一次。它必須是持續的、有週期的,並且要能捕捉「系統上線後世界如何改變」。

偏見來源

典型症狀

評測切入點

訓練資料

某子群樣本量偏低、分布異常

分層統計、樣本數與覆蓋率檢查

代理變數

模型高度依賴與敏感屬性相關的特徵

特徵重要性分析、反事實測試

目標函數

整體指標漂亮、子群落差大

分群誤差指標、混淆矩陣分層比對

部署情境

人類過度信任或誤用輸出

使用者研究、流程觀察、申訴紀錄分析

回饋迴路

模型越跑越極端、群體差距逐季擴大

長期監控、定期再訓練紀錄

三、真實世界案例:那些已經發生的傷害

抽象討論偏見很容易變成道德說教,但這些案例都是有名有姓、有判決、有論文、有撤回的產品。它們的共同點是:出事的時候,系統的總體指標通常都很好看。

3.1 COMPAS:再犯風險評估與那場沒有結論的公平性大辯論

2016 年,調查報導媒體 ProPublica 分析了美國佛州布勞沃德郡約七千名被告的再犯風險評估資料,指出一套名為 COMPAS 的工具在「預測高風險但兩年內未再犯」的比例上,黑人被告明顯高於白人被告。報導一出,立刻引爆全球關於「演算法是否歧視」的討論。

開發商的反駁同樣有力:如果看「預測準確度」,也就是模型把高風險與低風險分開的能力,兩個族群其實差不多。問題在於,這兩種「公平」在數學上無法同時成立——當兩個族群的再犯基準率不同時,你不可能同時做到「校準一致」、「偽陽性率相等」與「偽陰性率相等」。(這個結論後來由多位學者正式證明,也就是所謂的「公平性不可能定理」,下一節會細談。)

這場辯論的重要遺產不是「COMPAS 到底有沒有歧視」的單一答案,而是讓實務界認清一件事:「公平」不是一個技術參數,而是一個需要被明確定義、公開討論、並承擔後果的選擇。

3.2 招募 AI:亞馬遜那場沒有對外宣布的撤退

2014 年起,亞馬遜著手開發一套履歷篩選輔助工具。它以過去十年的履歷與錄取結果為訓練資料,學會替新履歷打分數。問題是,科技業過去十年的錄取結果本身就偏向男性,模型於是學到「男性化的用詞比較像成功履歷」,甚至對履歷中出現「women's」這類字樣降低評價。團隊雖然嘗試移除性別相關欄位、修正關鍵詞權重,但很難徹底清除這條學習路徑,該專案最終在 2018 年前後被解散。

這個案例最值得記住的一點是:「把性別欄位刪掉」完全無法解決問題。模型可以從社團名稱、職稱描述、用字習慣、甚至休閒活動中,重新拼湊出性別的訊號。

3.3 醫療演算法:用「花多少錢」代替「病得多重」

2019 年發表於《Science》的一項研究,分析了一套影響美國約兩億人就醫決策的商用風險分層演算法。這套演算法宣稱要預測「誰的健康風險高、需要額外照護」,但它實際使用的預測目標是未來的醫療支出。由於在相同健康狀況下,黑人患者平均花費較少(可能源於就醫可近性、信任度、經濟壓力等結構因素),演算法便系統性低估了黑人患者的健康需求。

研究團隊估計,若把預測目標從「花費」改成「可預防的健康需求指標」,被納入額外照護計畫的黑人患者比例會從約 18% 顯著提升至約 47%。這個數字的意義是:偏見不是模型不夠準,而是模型太準地預測了一件不該被預測的事。

3.4 臉部辨識與生成式 AI:錯誤率的膚色與性別落差

2018 年的「Gender Shades」研究測試了三款當時市面上的商用性別分類服務,發現深色膚色女性的分類錯誤率最高可達三成以上,而淺色膚色男性的錯誤率不到 1%。類似的落差也出現在後續的臉部辨識、情緒辨識與影像生成工具上:某些族群的臉被生成得比較模糊、某些職業的圖像預設為男性、某些國家的文化在訓練語料中幾乎缺席。

生成式 AI 讓這個問題變得更棘手,因為偏見不再只影響「分類結果」,而是影響「被生成的內容」。當一個工具被用來產生履歷範本、產品文案、新聞插圖、教育素材時,它輸出的刻板印象會被大量複製、擴散,然後再被下一輪的訓練資料吸收回去。

案例

偏見類型

核心教訓

COMPAS 再犯風險評估

量測偏見、目標定義爭議

公平的定義彼此衝突,必須明示選擇

亞馬遜招募工具

歷史偏見、代理變數

刪除敏感欄位無法消除訊號

醫療風險分層演算法

標籤選擇錯誤

優化錯誤的目標,越準越有害

商用臉部分析服務

代表性偏見

平均值掩蓋了子群體的極端落差

荷蘭兒少福利津貼稽查系統

代理變數、部署偏見

行政系統的誤判會造成制度性傷害

最後一列值得多說兩句。荷蘭稅務機關曾以風險模型與國籍、雙重國籍等特徵篩選育兒津貼申請人,導致數千個家庭被錯誤追討、陷入債務,最終於 2021 年引發內閣總辭。這不是實驗室裡的假設情境,而是真實發生在一個法治國家的行政體系裡。它提醒我們:當演算法被嵌進有強制力的行政流程,偏見的代價不是「體驗不佳」,而是有人失去房子、失去監護權。

四、為什麼「把敏感欄位刪掉」解決不了問題

4.1 代理變數:郵遞區號往往比種族更能說明一切

在許多資料集中,郵遞區號、就讀學校、手機型號、瀏覽器版本、甚至打字節奏,都與族群、社經地位高度相關。這些特徵被稱為「代理變數」。你可以把種族欄位刪得一乾二淨,模型照樣能從其他特徵重建出高度相關的訊息。

反過來說,這也是為什麼「差分隱私」或「去識別化」不能單獨當作公平性的解方——它處理的是「能不能辨識出個人」,而不是「推論結果對群體是否一致」。

實務上比較合理的做法有兩條路:一是限制模型對代理變數的依賴(例如做特徵重要性審查、對高風險特徵做擾動測試),二是直接量測結果層面的差異(例如檢查不同群體的通過率、誤判率),而不是只盯著輸入欄位。後者往往更有效,因為它繞過了「到底算不算敏感屬性」的無盡爭論。

4.2 公平的數學定義彼此打架

學界整理出的公平性定義至少有二十幾種,常用的包括:

  • 人口統計均等(demographic parity):各群體被判定為「通過」的比例應該相同。
  • 機會均等(equal opportunity):在真正符合資格的人當中,各群體被正確通過的比例應該相同。
  • 均等化機率(equalized odds):各群體的真陽性率與偽陽性率都應該相同。
  • 預測均等/校準(predictive parity):拿到同一個分數的人,不論屬於哪個群體,實際結果的機率應該相同。
  • 個體公平(individual fairness):相似的人應該得到相似的對待。
  • 問題是,除非各群體的基準率完全相同,否則這幾項無法同時滿足。COMPAS 的爭議本質上就是這個定理的現實版本:報導在意的是「偽陽性率不平等」,開發商在意的是「校準一致」,兩邊都對,因為他們量的是不同的東西。

    4.3 取捨不是藉口,而是需要被明示的價值決定

    「反正不可能全拿,那就隨便選一個」是最糟糕的結論。正確的做法是把選擇攤在陽光下:這個系統寧可多放過一些高風險者,也不要誤傷無辜者,還是反過來?這個問題沒有技術答案,只有政策答案。它應該由產品負責人、法務、領域專家與受影響的社群共同決定,並且留下書面紀錄。

    評測者的角色,就是去檢查這份紀錄存不存在。如果一個團隊說不出「我們選擇了哪種公平定義、為什麼」,那通常不是因為他們深思熟慮後做了艱難抉擇,而是因為他們根本沒想過這件事。

    五、評測實務:怎麼檢查一套軟體的演算法偏見

    5.1 評測前的三個問題

    在動手跑任何指標之前,先問三個問題。這三個問題答不出來,後面的數字都沒有意義。

  • 這套系統在做什麼決定,這個決定會影響誰的真實生活?如果影響的是「首頁推薦商品」與「是否核貸」,需要的嚴謹程度天差地別。
  • 有哪些群體可能被系統性影響?除了常見的性別、年齡、族群,也要考慮身心障礙、語言、地區、收入型態(例如自由工作者、家管)、甚至裝置類型。
  • 出錯的時候,誰來承擔後果?有沒有申訴管道?一個沒有救濟機制的系統,即使偏見輕微,傷害也會被放大。
  • 5.2 常用的量化公平性指標

    對外部評測者而言,最實用的做法是「分群混淆矩陣」:把資料按群體切開,分別計算真陽性率、偽陽性率、偽陰性率、精確率,然後比對。這個動作樸素但極其有效,因為它能把「平均值」背後的落差直接攤開。

    指標

    衡量什麼

    適用情境

    常見誤用

    人口統計均等

    各群體通過率是否相同

    資源分配、名額制篩選

    忽略資格分布本身可能不同

    機會均等

    合格者的通過率是否相同

    錄取、核准類決策

    需要可靠的「真正合格」標籤

    均等化機率

    真陽性率與偽陽性率是否同時相等

    高風險預測、安全篩檢

    條件嚴格,常無法同時達成

    校準誤差

    同分者的實際結果是否一致

    風險評分、機率輸出

    容易與「結果公平」混淆

    反事實一致性

    只改敏感屬性,輸出是否改變

    黑箱模型的外部測試

    需自行構造合理的反事實樣本

    5.3 黑箱產品的外部稽核方法

    多數評測者拿不到模型的原始碼與訓練資料,但這不代表無法評估。以下幾種方法在外部稽核中相當實用:

  • 配對測試(paired testing):構造兩份除了敏感屬性外幾乎完全相同的輸入(例如同名不同性別的履歷、同一地址不同姓名的申請),觀察輸出是否出現系統性差異。
  • 分群探測:用大量合成或公開樣本,統計不同群體的通過率與錯誤率,找出異常落差。
  • 邊界測試:針對決策門檻附近反覆測試,觀察是否存在「某些群體剛好卡在門檻外」的現象。
  • 文件審查:檢查廠商是否提供模型卡、資料卡、公平性報告、獨立稽核結果。沒有文件本身就是一種評測結論。
  • 申訴紀錄分析:如果產品有使用者申訴機制,申訴內容的分布往往比任何指標都更早揭露問題。
  • 六、法規與治理:從「自律」走向「問責」

    6.1 歐盟 AI 法案的分級管理

    歐盟的《人工智慧法案》於 2024 年正式通過並分階段生效,採取的是「風險分級」路線:不可接受的風險(如社會評分、部分即時遠端生物辨識)原則上禁止;高風險系統(如就業篩選、教育評分、關鍵基礎設施、部分醫療與執法應用)須負擔風險管理、資料治理、技術文件、紀錄保存、人類監督與透明度等義務;其餘系統則以透明義務為主。

    對台灣的軟體團隊而言,即使不直接在歐盟營運,這套架構也已成為事實上的國際標準。當客戶、投資人或跨國合作夥伴要求「你們的 AI 有沒有做過風險分級與偏見評估」,能夠拿出對應文件就是競爭力的一部分。

    6.2 美國、台灣與亞洲的現況

    美國聯邦層級目前沒有統一的 AI 專法,問責主要建立在既有的民權法與消費者保護法之上,例如就業領域的差別影響(disparate impact)原則、公平借貸法規,以及聯邦貿易委員會對「欺騙性或不公平行為」的管轄。這意味著企業在招募、核貸、住宅、保險等領域使用演算法時,傳統的反歧視法照樣適用,不會因為「是 AI 決定的」而免責。

    台灣方面,個人資料保護法構成最基本的框架,而行政院於 2024 年通過的「人工智慧基本法」草案,則朝向原則性立法、鼓勵創新與風險治理並行的方向設計。對實務工作者來說,短期內真正要盯緊的,仍然是個資法、消費者保護法、公平交易法,以及各目的事業主管機關的規範。

    6.3 組織內部的治理機制

    法規給的是底線,真正決定偏見會不會被發現的,是組織內部有沒有「敢說真話的流程」。幾個已被證實有效的機制:

  • 上線前的偏見審查關卡:在高風險系統的發布流程中,加入獨立的公平性審查,而且要有一票否決權或至少「必須留下書面理由」的權力。
  • 跨職能審查小組:成員應包含領域專家、法務、倫理、使用者代表,不能只有 ML 工程師。
  • 外部稽核與紅隊:定期邀請外部團隊進行對抗性測試,避免內部視角盲點。

  • 申訴與救濟管道:讓被系統影響的人能提出異議、取得解釋、獲得補救。這是最有效的早期預警系統。
  • 決策留痕:把「為什麼選這個定義、為什麼接受這個落差」記錄下來,供事後追溯。
  • 七、給開發團隊的實務建議

    7.1 資料卡與模型卡:讓偏見無所遁形

    資料卡(datasheet)記錄資料集的來源、蒐集方式、時間範圍、涵蓋族群、已知限制與建議用途;模型卡(model card)記錄模型的訓練目標、評估指標、分群表現、適用與不適用情境。這兩份文件的價值不在於「有寫就合規」,而在於它們強迫團隊在開發過程中面對那些平常會被忽略的問題:這份資料裡有誰?沒有誰?我們憑什麼認為它可以用在這個場景?

    7.2 把「偏見回歸測試」寫進 CI 流程

    多數團隊已經有單元測試、整合測試、效能回歸測試,但很少有「公平性回歸測試」。做法其實不難:準備一組固定的分群評估資料,在每次模型更新時自動跑一次,檢查各群體的關鍵指標是否偏離基準值超過門檻。一旦超標,就擋下合併。

    這套機制的心理效果往往大於技術效果:當偏見會讓 CI 變紅,它就從「理念」變成了「待辦事項」。

    7.3 人類覆核與申訴管道

    最後,也是最容易被忽略的一點:不要讓演算法成為唯一的最終決定者。在高風險場景中,模型應該是輔助,人類應該擁有實質的覆核能力——不是形式上的「按同意」,而是有時間、有資訊、有動機去質疑模型。同時,使用者必須知道自己被演算法評估了,並且知道可以去哪裡申訴。透明度不是把所有權重公開,而是讓人知道自己正被如何對待,以及可以怎麼反抗。

    八、結語:偏見不是 bug,是社會的鏡子

    我們習慣把軟體問題分成「功能缺陷」與「使用體驗」兩類,而演算法偏見通常兩者都不算。它不是程式寫錯,也不是介面難用,而是一套系統忠實地學會了社會原本的樣子,然後用更高的效率、更大的規模,把那個樣子複製回社會。

    這也正是它難以修復的原因。修一個 bug,改幾行程式就好;修一種偏見,往往要先承認「我們的資料裡有歷史的傷口」、「我們的目標函數裡藏著價值選擇」、「我們的流程預設了某些人的失敗不重要」。這些都不是工程問題,而是組織問題、制度問題,甚至是我們每個人的問題。

    但悲觀不是選項。過去十年,我們已經看到具體的進展:公平性指標從論文走進產品儀表板,模型卡與資料卡成為採購條件,歐盟把風險分級寫進法律,外部稽核變成一個真實的產業。這些改變不是因為技術變得更善良,而是因為有人願意問那句最尷尬的問題——「這套系統,對誰比較好?對誰比較不好?」

    下一次你在評測一套軟體時,除了跑分、比價、看評價,不妨多問這一句。這不是要每個使用者都變成倫理學家,而是因為在一個演算法替我們做越來越多決定的時代,願意問這個問題的人有多少,決定了這面鏡子會照出什麼樣的社會。

    論壇討論邀請:你在工作或生活中,遇過「明明很準,但就是哪裡怪怪的」的系統嗎?是推荐系統、信用評分、履歷篩選,還是學校的分班工具?歡迎在下方回覆分享你的觀察。也歡迎許願下一篇評測主題——我們正在考慮針對「開源公平性檢測工具」做一輪實測比較,有興趣的版友請 +1。

    🏠 返回首頁