這系列文章為 AlfredCamera 工程和設計團隊閱讀 Google People + AI 內容綱要和討論筆記，期望透過平常設計 AI 產品的設計師和工程師的補充，讓文件中的知識更容易被各種背景的人員吸收應用。由於在討論中也發現 AI 產品設計的中文資料較少，因此整理分享期望能幫助到其他團隊。原文摘要在文中以白底區塊為主，團隊的討論會以灰底區塊呈現，方便大家閱讀。如果有任何建議歡迎留言討論，或來信 hello@alfred.camera 😊
章節主旨
當 AI 系統產生錯誤或失敗時，事情就會變得很複雜，以下是本章主題：
- 當用戶將低預測視為錯誤時
- 如何在複雜的 AI 中定位錯誤
- 即使發生錯誤用戶能否繼續使用
在錯誤處理上 AI 系統不同之處
用戶往往以我們無法預期的方式使用產品，在這過程中誤解、不當操作就會隨之發生，不過錯誤亦是轉機，用戶可以從錯誤中學習，建立良好的認知模型，在過程中鼓勵用戶提供反饋，正確的將這類行為納入產品設計考量才稱得上是以用戶為核心出發的產品設計。在 Error Messaging Guidelines from the Nielsen Norman Group 有更詳盡的說明。
幾個 AI 系統關鍵的錯誤處理：
- 定義「錯誤」與「失敗」
用戶所認知到的錯誤往往來自於他們對產品的期待，例如說有著 60% 成功率的推薦系統是成功還是失敗，取決於用戶與系統設計的目的；
在錯誤發生時應對措施可以引導用戶的心智模型與重拾用戶的信任。 - 定位錯誤來源
從用戶或是系統設計者的角度很難準確的定位錯誤，因為可能來自多個地方。 - 遇到錯誤時的應對措施
AI 可以隨著時間改變，當使用者遇上錯誤時，適時的給予資訊引導，使他們對系統更有耐心，並提供更好的整體體驗。
一、定義「錯誤」與「失敗」
將 AI 整合入產品當中意味著產品會隨著用戶的互動而有所改變，用戶可能會期待 AI 透過互動觀察出他們個人獨特的品味與行為。
當要定義錯誤時，每個用戶基於自身的期待、目標、心智模型與過往的產品使用經驗而有所不同，例如某用戶認為音樂推薦系統是基於他的喜愛列表中推薦歌曲，如果 AI 是基於喜愛列表以外的因素進行推薦，用戶可能就是為這是個錯誤；相反的另一個用戶認為 AI 的推薦機制是基於廣泛的因素，對他來說這就不是個錯誤。針對用戶對於系統的功能、侷限與互動方式的認知，可以參閱 Mental Models。
定義用戶、系統、場景錯誤
- 用戶錯誤：從系統設計者角度出發，錯誤是因為用戶誤操作導致
- 系統錯誤：從用戶角度，錯誤是因為產品設計不夠有彈性，無法達到用戶的需求
- 場景錯誤：AI 對於用戶預期的行為抱持錯誤的假設，導致用戶感到困惑、無法滿足需求或是棄用產品，使用場景會根據用戶自身的偏好或是更廣泛的文化所影響
以食譜推薦應用為例，某個用戶時常在下午時段拒絕推薦，這樣的行為模式背後可能有一致的緣由，如果用戶是上晚班，在上班前他們會偏好早餐食譜推薦；然而如果是某個群組在一年的某特定時段拒絕肉類相關的食譜推薦，這可能是文化影響或是其他產品團隊尚未掌握的緣由。
為了避免場景錯誤發生，你應該要確認 AI 基於何種資訊去假設用戶的行為，並驗證假設是否正確、被忽視、被過度看重等。
分類用戶感知的錯誤
- 場景錯誤
這通常是 True-Positive，系統認為預測是正確的且結果也應該是正確的，但用戶可能因為系統沒有給予足夠的解釋導致錯誤的認知，例如朋友的飛機航班確認信件在你的行事曆上出現紀錄，但其實你根本不想要知道。
根據錯誤的頻率與嚴重性，可以透過調整系統去更符合用戶的期待，或是在用戶初次使用產品時給予正確的心智模型，將用戶的認知從錯誤引導成預期行為。 - 失敗的狀態
基於根深柢固的系統限制，導致 AI 無法給予正確的答案，對於 AI 來說這類型錯誤是 True-Negative，因為輸入無法得到合理的輸出，但用戶認為應該要得到答覆，例如說圖形辨識應用，用來分辨多種動物，但用戶輸入了一個不存在於資料集的動物，對系統而言會產生 True-Negative 的結果
這種狀況下應盡可能告知用戶系統的侷限
用戶沒有感知到的錯誤
- 有娛樂效果的插曲
系統會標記某些狀況是無法處理的侷限或錯誤，但在某些少數的場景下可能變得有用或有趣，例如用戶叫智能音響去倒垃圾，即便用戶知道智能音響無法做到，但他和他的家人可能因為音響的回應而感到有趣 - 背景錯誤
在某些錯誤狀況下，用戶或系統並沒有發現錯誤，例如搜尋引擎回傳錯誤的搜尋結果，但用戶無法確認這是否正確
長遠來看，一直沒有發現這類型的錯誤會有嚴重的影響，同時會影響系統對於服務錯誤比例的評估，因為用戶不會給予反饋，必須透過更仔細的品質追蹤測試出系統的「未知的未知錯誤」
用戶歷程的不同階段
在不同的歷程階段，用戶對於錯誤的反應可能會有所不同，同樣會影響 AI 如何跟用戶溝通錯誤與引導用戶繼續使用，例如當用戶第一次使用音樂推薦系統，當系統推薦不相關的資訊，他們不會意識到這是個錯誤；但是經過一年的操作，聽音樂、點讚某首歌曲與加入喜愛清單，用戶期待推薦的歌曲會有高度的關聯性，如果關聯性低就會被視為錯誤。
評估錯誤利害關係
在某些情況，AI 的錯誤僅帶來些許的不方便，但在某些場景就嚴重許多，例如 AI 推薦的 Email 回覆系統跟自駕車系統相比，錯誤所導致的風險就差異很大；對於非 AI 系統也是如此，但是基於 AI 系統的複雜性與場景錯誤的可能性，在設計 AI 系統應該更仔細考量每個決策的利害關係；任何場景都有直接相關的利害關係，但還有些外部場景會導致錯誤的風險增加，例如用戶可能一心多用或是在時間壓力下，他們沒有多餘的心力再次檢查系統的輸出。
評估潛在的錯誤風險
- 低風險
1. 用戶有相關經驗
2. 系統有高信心度
3. 有多個可能的成功結果 - 高風險
1. 用戶相關經驗不足
2. 注意力不足或時間不足 (分心)
3. 系統信心度不足
4. 難以達到成功結果
評估場景的利害關係
- 低利害相關
1. 實驗性質
2. 創意性
3. 娛樂
4. 不重要的推薦 - 高利害相關
1. 健康、安全、財務相關
2. 敏感社交場景
考量到在不同的情況下對應不同的系統回應、用戶回應與訊息表達，可以參考 User Needs + Defining Success 中的 reward function 設計；針對高利害相關的場景所對應的解釋，可以參考 Explainability + Trust。
[關鍵概念] 在開始設計系統的錯誤處理之前，試著找出用戶可能遇到的錯誤或是你能預期的錯誤，並分成兩類：1. 系統侷限：因為限制導致系統無法給出正確答案 2. 場景：系統預定設計的行為，但可能因為用戶認知不同或是基於不充分的假設，導致用戶認為是錯誤 3. 背景錯誤： 哪些錯誤可能發生後用戶無法察覺 接著詢問你自己，這些錯誤會如何影響用戶以及後續的利害關係分析，可以參考表單填寫 https://pair.withgoogle.com/worksheet/errors-failure.pdf
二、定位錯誤來源
User Needs + Defining Success 章節描述了如何制定並衡量回饋函數，有部分的錯誤是源自於回饋函數的設計，但大致上來說還有數種錯誤來源。
1. 預測與訓練資料錯誤
某些錯誤來自訓練資料集本身，而訓練資料是用來調整模型本身，例如說導航應用因為訓練資料集沒有包含某個特定地點的道路，所以限制了使用範圍。
a. 結果被標記錯誤或誤判
有時因為資料集殘缺導致系統的結果標記錯誤或誤判，例如分辨植物的應用因為莓果類的標記錯誤導致誤把草莓當作山莓。
應對措施
允許用戶糾正資料或標記，並反饋至模型的訓練資料集或提醒團隊去更新資料集。
b. 採樣不足或模型錯誤
當資料集足夠時，機器學習模型可能訓練過程導致不夠精準，例如準備了足夠的訓練資料集並包含了莓果類，但是在調教模型時有差錯導致辨識莓果類時產生大量的 False-Positive。
應對措施
允許用戶糾正資料或標記，透過反饋去調整模型。
c. 資料不足或錯誤
模型的服務範圍會基於資料集所決定，但用戶的使用方式可能超出服務範圍時，例如用戶將植物辨識應用對著狗使用。
應對措施
跟用戶溝通產品的運作方式與範圍，例如解釋產品的不足或限制，並允許用戶反饋產品無法解決的需求。
參考 Data Collection + Evaluation 與 Explainability + Trust 了解如何辨識正確的資料來源並給予解釋。
2. 預測並設法解決輸入錯誤
用戶可能預期系統能「理解」他們所表達的意思，不論 AI 是否真的理解會導致以下錯誤。
a. 不預期輸入
用戶預期系統會自動糾正或補齊輸入，例如系統能自動糾正錯字。
應對措施
檢查用戶輸入並產生多組可能的答案，例如「你是否要搜尋 XYZ?」。
b. 使用習慣改變
當用戶在系統 UI 互動過程中產生操作習慣時，任何的改動會導致用戶產生不預期行為。
例如說檔案儲存應用，用戶習慣操作的檔案資料夾是放在右上角，但設計介面導入 AI 驅動時，資料夾被頻繁的搬動，用戶可能因為肌肉記憶而開啟錯誤的資料夾。
應對措施
盡可能不要讓 AI 破壞使用習慣，例如說規劃某區塊給預測信心程度不夠的 AI 結果(?)，或是允許使用者移除更動、選擇或是保留操作介面，關於使用習慣可以參考這篇來自 Google Design 部落格的文章
c. 反應失真
系統對於某些選擇或行為給予不適當的權重，例如用戶在音樂應用中搜尋過某歌手，結果跑出無止盡該歌手的音樂推薦。
應對措施
向用戶解釋系統的輸入與輸出關係，讓用戶能夠給予正確的反饋。
3. 透過系統輸出品質檢查關聯性錯誤
AI 驅動的系統不可能總是在正確的時間提供正確的資訊，系統的設計跟用戶的實用需求落差導致關聯性低的輸出，也就是場景錯誤的發生原因；這並不像資料集錯誤或是用戶輸入錯誤，這類型問題不是探討輸出的正確性或系統的決策過程，而是結果用何種方式或何種時機傳達給用戶 — 或是不傳達給用戶。
a. 低信心度
當模型因為某些不確定性侷限而無法完成任務時，例如資料不足、沒有達到足夠精準度或預測不穩定，例如機票價格預測系統因為狀況多變難以預測明年的價格。
應對措施
允許用戶反饋並改善系統運作方式。
b. 關聯性低
即便系統對於輸出很有信心，但表達方式可能使用戶覺得結果跟需求不合，例如用戶因為家人喪禮而預定了飛往休士頓，但是旅遊應用卻推薦「愉快的休假活動」。
應對措施
允許用戶反饋並改善系統運作方式。
4. 釐清系統架構錯誤
當使用多個獨立運作的 AI 系統時，可能因為功能重疊導致錯亂，預先設想你的 AI 系統可能會與其他 AI 系統互動，提供用戶不同層級的控制避免衝突產生。
a. 多重系統
當用戶將你的產品與其他產品連結時，有時不容易知道是由哪個系統負責，例如用戶安裝了「智能溫度調節器」與「智能能源量測器」，兩者可能會採用不同方式去優化能源的使用效率，衝突的信號會使運作出現問題。
應對措施
解釋多個連結的系統，並讓用戶設定優先順序，可以考慮圖形化顯示各個系統間的交互關係。
b. 訊號干擾
當多個系統同時監聽類似的信號而發出警報時，用戶內心會感到壓力，因為他同時需要釐清多種不同的警報內容，並思考下一步行動，例如說用戶的語音輸入同時被多個語音偵測系統監聽，並以不同的方式同時發出警報，用戶會感到徬徨不知道下一步該怎麼辦。
應對措施
允許用戶獨立設置，避免與其他產品衝突，例如智能音響只有在聽到關鍵字後才開始監聽，再不產生場景錯誤的情況下，可能會吸引注重隱私的用戶
[關鍵概念]
試著釐清錯誤發生的類型
1. 預測與訓練資料錯誤是因為當… 系統的功能受限於資料集
2. 輸入錯誤是因為當… 用戶期待 AI 自動修正他們的輸入，或是他們的習慣被干擾
3. 關聯性錯誤是因為當… AI 回覆的時間、地點、方式不合乎用戶的需求
4. 系統架構錯誤是因為當… 用戶將你的 AI 系統與其他產品連結，而系統間不知道誰要負責三、發生錯誤後如何繼續使用
給予用戶正確的產品功能預期，在面臨錯誤時依然有不錯的使用體驗，但是讓用戶即便遇到錯誤也能繼續使用，能夠更增加產品的使用性。
假設你是位餐廳服務員，當客戶點選了已經售完的餐點，你可以依據他們先前的偏好推薦其他替代方案，例如說「可樂沒有了改換氣泡水可以嗎？」
在面臨高度利害關係時，需要再多次檢查替代方案是否安全，例如說替代的餐點可能是好發過敏的食物，服務生就需要再三思考這項推薦是否合宜，主要目標是在不造成傷害下讓用戶能在錯誤狀況下持續使用。
創造用戶反饋的時機
如同前面的章節，許多錯誤需要用戶的反饋才能改善系統，特別是那些系統無法識別的錯誤，像是資料標記錯誤等。
當顯示錯誤時，提供用戶給予反饋的機會，例如系統推薦失敗時，詢問用戶希望看到的內容，並提供回報不適合的推薦。
控制權交還用戶
當系統失敗時，最簡單的做法是改由用戶操控，但不一定要讓用戶全盤接手，在某些情況這樣反而是危險的做法，例如說在交通尖峰時刻導航系統停止給予用戶導航建議。
當從 AI 模式切換回手動模式，這是你的職責讓用戶可以簡單、直接的接管，這意味著用戶有足夠的資訊了解現有狀況、知道下一步該做什麼以及如何做到。
預想濫用行為
雖然針對錯誤提供足夠的資訊與可行解法是很重要的，但要小心被用戶濫用的可能，如同 User Needs + Defining Success 所介紹，要試著讓錯誤安全、無聊並視為產品的一部分，避免讓錯誤看起來有利可圖，或是過度解釋系統的漏洞。
例如用戶每次手動標記垃圾郵件時，系統都仔細解釋為什麼系統不認為這是垃圾郵件的原因，這會讓垃圾郵件發送者知道如何避免被當作垃圾信件。
為了更有可能找出系統設計死角，增加 beta 測試或是試驗性計畫，許多產品就像是處處是機遇的迷宮，設計師只專注在正確的答案上，而用戶則是在迷宮中四處碰壁。
[關鍵概念] 透過品質檢測或是試驗找出錯誤，此外每當新功能發布需要持續的觀測，可以透過不同的管道收集用戶的發現，以下是幾種錯誤回報管道
1. 客服
2. 社群媒體上的建議
3. 產品內的調查
4. 產品內的指標
5. 用戶研究
a. 深度訪談
b. 日誌研究
找出錯誤後，團隊便能針對問題設想解決方案總結
在學習的過程，錯誤總是難免，在系統設計時將錯誤納入考量增加與用戶溝通的機會，變成是有效的解決方案，同時能讓用戶達成目的。
當設計錯誤情境體驗時，試著從用戶角度出發而不是機器，錯誤訊息或許需要揭露為何系統發生錯誤，但是在溝通上需要更加人性化，在解釋系統限制之餘讓用戶能夠繼續使用。
定義「錯誤」與「失敗」
處理機率性、動態的系統，用戶認知的錯誤可能是系統的預設行為，承認系統還有進步空間能夠鼓勵用戶給予更多的接納與反饋。
定位錯誤
AI 系統的複雜性使得錯誤不容易被定位，團隊內需要討論如何發現錯誤並找出錯誤來源。
發生錯誤後如何繼續使用
這項技巧不是要去逃避錯誤，而是以用戶為中心設計產品，不管在如何努力打造「預期正常的系統」，AI 是有隨機性的，就像所有的系統錯誤在所難免，但發生錯誤後需要提供用戶持續使用的方式，並設法改善 AI。
本文編者名單主筆：Jacky
討論：AIUX 讀書會成員 Cheyu, Frank, Jacky, Ron, 宜婷, Weiyun
