一次討論 Agent 的場合，話題碰到偏見與 guardrails，對方提出「偏見因人而異」的看法。我想到的例子很日常：購物系統因為知道使用者的性別，就推薦裙子，這算不算偏見？

我的疑問是：如果連這個例子都說不清楚，採購時說系統「有防護」到底代表什麼？

群體的傾向，不等於這個人的需要

某一類顧客比較常買某項商品，可能是資料中的統計現象。但個別顧客今天想找什麼，還要看用途、預算、尺寸、風格，以及他自己表達的偏好。顧客也可能是在替別人買東西。

因此，「統計上常見」並不足以回答「這次推薦是否合適」。如果使用者明確說不想要裙子，系統仍因為性別持續推薦，那就連需求本身都沒有處理好。

反過來，使用者明確想買裙子時，系統也不應因為某個身分標籤就拒絕協助。關鍵在於系統如何使用資訊，以及這種使用方式造成什麼結果。

把抽象承諾改成能檢查的例子

我會希望產品團隊先回答：這個 Agent 要完成什麼任務？什麼結果算錯誤？誰可能被排除？使用者能不能修正系統的假設？

例如，可以設計以下測試。這是整理文章時提出的測試構想，並非當時已經執行的評測結果：

  • 保持需求、預算與偏好相同，只改變性別資訊，觀察推薦內容和理由如何變化。
  • 不提供性別，檢查系統是否仍能根據需求完成任務。
  • 明確提供與群體常見傾向不同的偏好，確認系統能否遵循。
  • 告訴系統先前的推測錯了，檢查後續推薦是否真的調整。

不同輸入得到不同結果，未必就能單獨證明有害偏見；完全相同的結果，也不等於已經公平。這些測試是用來找出需要解釋的差異，還要回到任務與影響來判斷。

Guardrails 需要有適用脈絡

NIST AI RMF把使用情境、影響辨識和公平性評估連在一起。對我而言，這也很適合拿來理解採購問題：先說清楚希望系統怎麼做，再談防護能涵蓋哪些失敗。

我不期待廠商用一句「沒有偏見」解決所有爭議。我期待的是具體範例、測試方法、已知限制和改善機制。這樣使用者遇到問題時，才有共同的語言可以討論，而不是最後只剩下各自對偏見的定義。