[AIUX] Ch2–1 將用戶需求轉換為數據需求
這系列文章為 AlfredCamera 工程和設計團隊閱讀 Google People + AI 內容綱要和討論筆記，期望透過平常設計 AI 產品的設計師和工程師的補充，讓文件中的知識更容易被各種背景的人員吸收應用。由於在討論中也發現 AI 產品設計的中文資料較少，因此整理分享期望能幫助到其他團隊。原文摘要在文中以白底區塊為主，團隊的討論會以灰底區塊呈現，方便大家閱讀。如果有任何建議歡迎留言討論，或來信 hello@alfred.camera 😊
這章節要了解
本節討論蒐集和評估餵給 AI model 的數據要考量的重點。包含：
- 我們的 dataset 是否包含了能準確評估 AI 滿足用戶需求的功能和廣度？
- 我們應該使用既有的 dataset 或是自己蒐集 dataset？
- 我們如何確保評估者在做 labeling 的時候不會將自己的偏見帶入 dataset？
為了要做出預測，AI 產品必須教會底層運算模型辨識 data 裡的模式和相關性。用來訓練 AI 模型的 dataset 就統稱為訓練數據（training data），格式可能是圖片、影片、文字、音頻等的集合。我們可以選擇使用現有數據或蒐集新數據來訓練系統，例如我們可以使用動物收容所的狗狗照片訓練模型，讓模型學會辨識一般狗的品種。我們所使用的 data 來源和標記（label）方式會直接影響系統的輸出質量及用戶體驗品質，一旦確定使用 AI 是做出滿足用戶需求的產品的必經之路（不確定的話可以回頭閱讀第一章，重新檢視用戶體驗和 AI 的關係），請考慮以下事項：
- 將用戶需求轉換為數據需求：確定訓練模型所需的數據類型。您需要考慮預測力、相關性、公平性、隱私權和安全性。
- 負責任地獲取數據：無論是使用已標記好的數據還是自行收集數據，評估數據及其收集方法以確保它們適合你的專案是至關重要的。
- 為評估者與標籤機制設計：對於監督學習，擁有準確的數據標籤對於從模型中獲得有用的輸出至關重要。被縝密設計過的評估說明（rater instructions）和 UI 流程有助於產生品質更好的標籤，進而獲得更好的輸出結果。
- 調整模型：模型運行後，需轉譯 ML 輸出的結果，以確保其與產品目標和用戶需求保持一致。如果沒有一致，則進行故障排除：探究數據的潛在問題。
一、將用戶需求轉化成數據需求
可用於訓練 AI 模型的資料集會包含範例（examples），範例包含一個或一個以上的功能（features），以及很有可能包含標籤（labels）。以下我們對第一節內容分成 1.1 定義數據需求和 1.2 數據需求的隱私和安全兩部分筆記：
1.1 定義數據需求
資料集當中，功能的範圍、標籤的品質以及範例的代表性都會是影響你 AI 系統品質的因素。
以上的表格以馬拉松自我訓練 app 為例，展示了用來訓練 ML 模型的數據，幫助模型預測用戶多享受一個 app 推薦的跑步路線。從這個範例中可以看到範例、功能和標籤如何影響 model 的品質：
1.1.1 範例（examples）
若拿來訓練推薦跑步路線算法的範例只來自於專業跑者，那麼這個演算法對於推薦路線給範圍更廣泛的普通用戶來說不一定有用，但對於專家用戶來說應該會非常好用。
📝 如何建構適合的範例範圍？可以簡單透過已知的使用者數據進行分群，若有餘力可以進一步透過問券設計搭配實際用戶訪問，建構出不同類型的使用者分群和場景。切記這是一個探索和定義不斷反覆的過程，所以應視當前的工作需求決定範例合理涵蓋的範圍。以阿福管家為例，初期產品用戶形象還很模糊，先參考既有商業模式、已有的用戶數據可初步劃分：居家安全用戶/非居家安全用戶、免費用戶/付費用戶、新手用戶/老用戶等幾大類，初步驗證這些劃分在使用行為上有關聯性，就可以先確定這些用戶都有被包含在產品設計的範例內。等確認這樣的劃分是實用的，就能再進一步詳細分析用戶比例，並對高價值的用戶詳細定義場景、行為特徵等細節。這個過程需要不斷溝通、不斷確認商業方向、不斷調整輸出的範例內容，千萬不能有「確定有這些範例就好了，收工！耶！」的心態。
1.1.2 特徵（features）
若數據中缺少了爬升量（elevation gain），模型就會將爬坡三英里和下坡三英里視為一樣的路線，但這對用戶來說是完全不同的體驗。
📝上一章提到過，AI 模型上具有不確定性，是否與這張定義特徵這件事矛盾呢？這在概念上分成兩個部分：資料特徵跟模型特徵。在模型特徵上，不同模型可能擅長分析的資料種類不一樣，的確因為有些算法上具有不易解釋性，無法直接說明其演算過程，不一定能清楚解釋決策過程。但這張提到的比較是資料特徵，我們應該清楚的知道這份資料對於我們的初始目的是否會產生盲點，比方說當把一份不帶有上下坡資訊的資料送入用來分析最佳運動時數的模型做訓練，因為資料本身就不存在，自然無法考慮到關聯，這需要在前期進行特徵工程的時候就納入評估，跟問卷的採樣階段有些類似。
1.1.3 標籤（labels）
標籤展示了跑者個人體驗，幫助系統定義有趣的慢跑體驗中會呈現怎樣的特徵。
1.1.4 結合用戶需求和數據需求
當要定義 examples, features 和 labels 的時候，建議用以下的方式思考數據需求。以下示例為協助用戶解決「我希望將跑步納入我的忙碌行程」的產品的數據需求：
- 使用者（user）：跑者
- 使用者需求（user need）：更頻繁的慢跑
- 使用者行為（user action）：使用 APP 成功完成整趟慢跑
- ML 系統輸出（ML system output）：建議路線以及建議時機
- ML 系統學習（ML system learning）：接受 APP 的提示、完成跑步並提高穩定性(註1)的行為模式
- 需要的數據集（datasets needed）：跑步相關的數據可以從 APP 中的數據、人口統計數據、生理數據和地理數據等等著手進行
- 關鍵數據集特徵（key features needed in dataset）：跑者人口統計、跑步的時間點、完成率、速度、里程、爬升高度、心律
- 關鍵數據集標籤（key lables needed in dataset）：跑者接受/拒絕建議，以及他們的回饋所代表的接受和拒絕的原因。
1.2 數據需求的隱私和安全性
保護用戶隱私和安全是任何產品都視為至關重要的事，即使前面提到的跑步相關示例，訓練此模型時所使用到的生理數據和人口統計數據也是被視為隱私敏感資料。
📝為何人口統計數據也算是敏感的資料？去年慢跑 App 在分享用戶活躍區域的資料的時候意外揭露軍事基地的地點應該就算是「統計數據包含敏感資訊」的例子。 https://www.bbc.com/news/technology-42853072 人口統計資料如果沒有進行完全去識別化動作，也有可能可以透過交叉比對定位到個人資訊。金融行業跟阿福管家這種特別重視隱私權的行業採用的去識別化方式，會盡可能讓資料無法追蹤到個人或源頭，卻能保有待分析的特徵關係。
由於 AI 和 ML 的技術特性，會有更多相關的問題浮現，在做產品設計時必須要跟公司內部專職處理隱私問題的成員討論作法。以下列舉兩例：
取得用戶同意使用數據時有哪些限制？
許多國家的法律要求，要讓用戶盡可能地對系統可以使用什麼數據以及如何使用數據保有控制力。建設系統時，要確保提供用戶退出及刪除其帳戶的功能。
📝當 user control 和商業目標有衝突時？這邊講到上一章也出現的 user control，意義也類似就是讓用戶保有退回動作的操作權力，這個原則在很多情況下可能跟商業目標有些違背，例如某支付 app 要刪銀行帳戶個資很難，從商業的角度來說會希望把這些流程放到很不明顯的位置。這時公司核心價值就很重要，當互相有衝突的作法出現時，做產品設計不是要走向某個極端而是取得平衡，例如把流失用戶的流程直接藏起來，還是正面邀請用戶填寫流失問卷做為改善。這個平衡點放在哪個位置，就視公司核心價值觀為主。因此在討論這樣的問題時，不斷和公司內部討論大家的看法是非常重要的。
是否存在著意外洩漏用戶數據的風險？後果可能是什麼？
例如，AI透過智能助手提醒用戶吃藥，同個房間可能會有其他人，就會有洩露私人醫療數據的可能性。又如以下的範例，即使用戶同意系統公開自己的名稱，但其他用戶可透過路線推斷出該使用者的活動範圍，作為系統設計者我們應該避免這種情況。
📝來談談反面：嚴密保護隱私所造成的不便阿福管家的工作流程上非常重視隱私和數據安全，都會盡可能的降低安全風險，包括通道滲透檢查，秘鑰與權限檢查，環境隔離，去識別化處理等等，model 也持續在關注相關解譯技術的進展，所以外流風險相對偏低。但同時，也因為做了以上安全處理，當用戶因為個人因素要求我們協助完全刪除使用資料，技術術上較難完全回溯（可能已經進行去識別化處理了），我們能把直接能追蹤到帳戶的資料刪除，但無法完全刪除根據其資料所抽取的特徵。所以回歸到如何叫做刪除資料的問題，如果是 GDPR 所稱「被遺忘權」的範圍，比較接近能追蹤到用戶本身的資料，是可以進行刪除，但如果刪除的定義包含該資料所產生的特徵，以目前的技術，大多數具有一定資料規模的公司應該都很難做到，因此會在使用前先取得用戶同意。因此在設計上也要跟用戶溝通清楚，所謂的「個人資料」包含什麼。
1.3 Dataset 的平衡 — 訓練數據不足與過適的情況（Balance underfitting & overfitting）
📝過度擬合？尼可以縮中文麻？overfitting 是統計學的用詞，意指過度緊密的匹配某個 dataset，以至於無法對其他 dataset 或新數據進行匹配，常見中文翻譯有：過度學習、過擬合、過度擬合、擬合過度、過適等。有 overfitting 現象的模型就稱為過適模型，在訓練的數據中表現良好，放到其他 dataset 或對新數據進行預測時就立刻表現變差。
為了讓 AI 產品能符合實際使用脈絡，需要使用能真實反應脈絡的 datasets。例如要建立用於演講的自然語言理解模型，選用用戶輸入關鍵字搜索的 dataset 幫助就不大，因為人們在鍵盤搜尋和口語的表達脈絡非常不一樣。
若你的訓練數據跟脈絡存在落差，就會增加「訓練數據不足或過度的風險」。過度（overfitting）意指 ML 模型太針對訓練數據調整，會導致 ML 模型在訓練數據表現很好，但對於其他的測試數據或新加入的數據可能表現更差。
但訓練數據與脈絡間的平衡不足（underfitting）也會導致模型做出差勁預測，因為模型無法適當捕捉訓練數據特徵之間的複雜關係，導致對訓練數據或新的數據都無法做出好的預測。
有一些現成工具可以從統計面協助評估 dataset overfitting & underfitting，但首先還是要跟團隊內的成員詳細討論 examples, features 和 labels，然後決定哪些 features 對於用戶需求來說最重要，挑選能涵蓋特徵的 dataset。
1.4 致力於公平
在各種開發階段，ML 模型都可能學習到人類的偏見。因數據是從真實世界收集的，所以人類有偏見，數據就會有偏見，ML 模型會識別和放大個人經歷及偏見。想辦法解決 AI 中的公平問題，並最大程度地減少不公平的偏見，是目前非常活躍的研究領域。可以參考 Responsible AI Practice 這份文件，裡面有更詳細的指引及最佳案例。
以下列舉一些 ML 讓用戶體驗失敗的範例：
- 代表性傷害（Representational harm）：當系統放大或反應對特定群體的負面刻板印象，就是一種傷害。
📝關於 amplify(放大)的概念是？AI模型訓練上容易受到主要，數量多的資料影響，可能完全消匿掉數特徵的存在，而模型進行自動化決策的速度非常快，因此所造成的影響也會跟著模型的產出效率成正比，造成系統結果放大這些特徵。案例：若水履歷篩選系統
- 阻絕機會（Opportunity denial）：當系統做出對個人真實生活中獲得機會、資源和生活質量產生持久影響的預測或決策。
- 失常的產品錯誤（Disproportionate product failure）：當產品無法正常工作，經常對特定使用群體提供偏差的輸出。
- 不利的危害（Harm by disadvantage）：當系統輸出對特定人口特徵與用戶行為或利益的不利關聯時，就會受到不利影響的危害。
公平性並不存在一套特定標準，模型的公平性也會根據情境而有所不同，以下是協助你減少 dataset 偏見的步驟：
1.4.1 使用可以應用於不同用戶群的數據
訓練數據應能反映出用戶的多元性和文化背景，可使用 Facets 了解 dataset 的偏差。為了達到這個目的，蒐集數據應要能平衡的反應現實用戶群的分佈比例。例如語音識別系統讓所有在美國的用戶都能正常使用，訓練的數據必須包括 50% 非英語母語者的數據，即使他們是少數。（意指美國有 50% 是非母語者，因此要針對美國設計產品的話，需要考量 50% 生活在美國的非母語者）
1.4.2 數據收集和評估過程中考慮到已知偏見
沒有真正中立的數據！即使單純如照片，最終呈現也會受到設備和光線影響。更何況蒐集和評估數據包含許多人類的判斷，所以有人類涉入就一定會包含人所帶來的偏見。假設你正在創建一個推薦系統，想要推薦使用者新的健身目標，如果你當初產品目的是要設定廣泛的用戶都可以實現的安全目標，而重要的訓練數據就是包括各種用戶類型的數據，你的目標用戶數據就不能僅僅只是年輕健康的人。後面 labeling 的小結會討論更多細節。
📝關於偏見
有時所謂的偏見未必真的是偏見，而是數據量或特徵關係上的問題，比方說 Google 模型誤將黑人辨識成黑猩猩，並不是有人存在這種偏見導致的，而是模型可能因為訓練資料量或訓練的時間、算法不足以讓他區分兩者的特征。📝在「追求公平」和「有商業利益的偏見」之間怎麼取捨？
文章中提及的例子裡，主要給英語人士用的系統，納入非母語的人可能會破壞精確度。這也是我在讀這章時認為比較少討論到的現實問題：用戶群體代表的商業價值，在很多產品中可能是與所謂的公平以及消除偏見等等相違背。公平的部分算是一個理想，只能在現實限制中盡可能做到，因為在人類的世界就已經不是公平的，資料範圍也不可能涵蓋所有人，也不一定是一開始定義目標族群與目標的範圍。另外，數據取得本身也是成本，實際上不太可能為了公平性投入過多資源取得數據。現行比較務實的做法是：先以快速取得的數據訓練並實際使用，發現問題時評估問題影響和解決成本，再決定是否要對 dataset 進行調整。
本文編者名單主筆：宜婷
編輯：Weiyun Hsu
討論：AIUX 讀書會成員 Cheyu, Frank, Jacky, Ron, 宜婷, Weiyun
