數據生而不平等. 不同產業欲推動數位化, AI 化時, 所面臨的挑戰以及可預的期效益大相逕庭. 在設計 AI 產品時, 首要考量為數據的擷取, 閉環的形成, 以及從中產生效益. 然而, AI 模型對數據的依賴性, 以及本身的容錯性, 對於整個產品的設計同等重要. 針對模型特性設計容錯的配套, 隨著數據迭代進行模型更新, 並加速整個數據閉環的循環, 才能讓數據發揮最大的效用. 此演講從宏觀至微觀, 以理論輔以實際案例, 幫助產品經理與工程師 / 架構師在推動 AI 產品化時, 更能掌握上述各點之間的取捨.

1. 數據特性
vs
AI產品設計與實作
陳彥呈博士 Albert Y. C. Chen, Ph.D.
http://slideshare.net/albertycchen/
albert.y.c.chen@gmail.com

2. 陳彥呈博士 Albert Y. C. Chen, Ph.D.
● 現職
○ 美國 OfferUp 主任資料科學家 (美國最大移動端二手電商 , 估值 >$1B)
✓ 架構企業數位神經、自動反應，提昇用 戶體驗、協助優化營運
● 經歷
○ Clobotics US 總經理 (風電 & 零售, 估值 $60M → $150M, 2018--2020)
○ Viscovery 研發副總 (廣告 & 零售, 估值$15M → $30M, 2015--2018)
○ Siemens、GE、Tandent Vision Science、Nervve Technologies
○ 英、美、中、日、台，多間公司 AI顧問
○ 台灣人工智慧學校 (台北1-3期, 新竹1期, 台中1期) 教師
○ 科技部、經濟部 AI計畫審查委員；工研院、資策會 計畫顧問
○ 台大駭客松、台大創客松、教育部創業競賽、廣達創業競賽 評審、冠軍隊導師
● 學歷
○ 美國紐約州立大學水牛城分校博士 (主攻電腦視覺、機器學習 )
○ 國立清華大學 資工學士

3. WHY?
● 年輕時，朋友約就衝了
● 現在我得先問足 “why”
○ Why?
○ Why not?
○ Why us?
○ Why now?
● 想清楚大戰略，是領導人最
重要的事情。
○ 前仆後繼仍無法攻克目標，不
是執行力有問題，而是戰略有
問題。
○ 別用戰術上的勤奮去掩飾你
戰略上的懶惰。

4. 產品的數據戰略
● 由產品衍生的數據，能源源不絕的驅動產品成長，使其更有競爭力；在制定產品
戰略時，若不思考數據戰略，則枉然。
○ 數據特性佳，未必適合做成 產品；在此當下，也未必是個適合進場的時機。
○ 數據特性差，未必不能做，端視進場者有多少競爭力。
● 有些時候，不管數據戰略怎麼變，一些實作原則與架構是普遍通用的。
● 此分享：
○ 先討論各種數據特性，再討論不同數據特性做 產品時的關鍵點，與現行市場競爭情況。
○ 以「欲創造競爭力之 產品」為限；研究、專案、非營利，不在討論範圍 內。

5. 數據生而不平等
更新頻率、獲取標註之難易度、價值、衍生模型之移轉性、衍生模型之容錯度皆不同

6. 數據循環速度：高速循環 vs 低速循環
由數據訓練出模型後，需要過多長時間，才能驗證此模型的好壞？
企業數據 週期
數位廣告成效評估 即時--天
行銷策略評估 週--月
業務成效評估 季--年
營運成效評估 年
研發成效評估 年--十年
融資增資數據 年--十年
人臉數據 週期
手機人臉解鎖 即時
門禁系統人臉識別 即時
社交平台人臉識別 天--週
警政系統人臉識別 週--月
美顏美籹效果反饋 月--季
語音識別數據 週期
機器人客服 即時--天
數位個人助理 即時--天
智慧家電語音助理 即時--天
影音平台自動字幕 月--年

7. 數據成本：廉價易得 vs 昂貴稀有
● 結構化數據 < 非結構化數據
● 線上數據 < 線下數據
● 簡單標註 < 詳細標註
● 應用自然產生標註 < 另外找人工標註
● 單訊號源數據 < 多重訊號源+多感應器之標註數據
↖ 某些人臉應用
，需要精細標註
到上百個點
← Google 自駕
車的數據，需多
感測器融合，標
註費用極為昂貴
https://medium.com/syncedreview/data-annotation-the-billion-dollar-business-behind-ai-breakthroughs-d929b0a50d23

8. 數據飛輪 (數據循環速度 + 數據成本)：
流量自然推動 vs 必須不斷施力
● Amazon的「流量飛輪」：
○ 持續施力，即便初速緩慢，但一遍遍累積，終會形成極大的前進慣性
● AI模型的「數據飛輪」：
○ 數據獲取速度、數據標註速度在不同應用場景上有極大的先天性差異
數據
優勢
AI
優勢
商業
優勢
技術 數據來源 數據標註 數據飛輪速度
人臉識別 FB, IG用戶自行上傳的生
活照, 自動識別親友
用戶自行修正識
別錯誤的人臉
★★★★★
人臉識別 中國各城鎮監視系統 公安手動修正 ★★★★
美顏 app使用者 需另外找人標註 ★★
虛擬試妝 app使用者 需另外找人標註 ★★
數據飛輪
客戶體
驗更佳
更大
流量
更多
賣家
多選擇
更便利
Amazon流量飛輪

9. 數據價值
數據「頻率」與「成本」和「數據價值」未必相關。擁有以下特色的數據更有價值：
https://themerkle.com/how-much-is-your-personal-data-worth/
● 和「營收」與「獲利」越直接相關的數據
越有價值。
● 越能幫助驅動「數據飛輪」的數據越有
價值。
● 越即時的數據越有價值。
● 越能形成競爭壁壘的數據越有價值。
然而，稀缺、限定特定應用的數據，並非數
據價值的保證。

10. 模型：移轉性高 vs 移轉性低
● 有些模型，不管數據怎麼換，表現並不會受太大影響
○ 過往消費記錄 vs 未來購買力
○ 車輛偵測、人臉偵測、
○ 語音識別、聊天機器人
○ OCR、機器翻譯
○ 人臉識別（不是直接學單個人臉，而是已預先學會所有人臉的 embedding）
● 有些模型，數據一換，就完全不適用了
○ 推薦系統
○ 商品識別
○ 醫療影像
○ 自駕車
○ 不當訊息過濾
○ 工業檢測

11. ● 模型通常是越準確越好；有時因其他限制，不得不妥協，尋找配套
○ 樣本量限制：例如，一人一照的人臉訓練樣本。
○ 變異性太大：商品樣式、種類繁多，即便品牌商都沒有一個完整、正確的資料庫。
○ 噪訊比太高：大量無法有效標註的資料，或有大量歧義的標註資料。
○ 樣本分布一直變：例如，二手平台的違規商品與訊息。
○ 應用場景限制：例如，瑕疵檢測；先檢出，才能訓練。
● 有些應用，容錯率天生就比就高
○ 美顏、廣告、商品推薦
● 容錯度低，但準確度又低時的常見配套
○ 於精確度與召回率之間做取捨，人工處理漏檢或誤判。
○ 調整產品與商業模式，讓Beta版先行，採回數據：如 Tesla自駕。
○ 調整模型分類類別；並非所有類別都能輕易訓練出二 值分類器。
模型：容錯度高 vs 容錯度低

12. 在同樣準確度 (accuracy) 要求下，
精確度 (precision) vs 召回率 (recall)
● 相同準確度下，可調整模型特性：
○ 多錯一點但不要漏掉（高召回率）
○ 少錯一點但可能會漏掉（高精確度）
● 有些應用，需要高精確度：
○ 相機之人臉偵測
○ 手機、門禁系統之人臉解鎖
● 有些應用，需要高召回率：
○ 智慧安防之人臉搜尋
○ 訊息過濾（須輔以人工複檢機制）
○ 醫療影像之病症識別（須輔以人工複檢機制）
● 有些應用，會故意參雜更多樣性的內容：
○ 搜尋引擎，電商商品搜尋、推薦

13. 代表性應用：數據 vs 模型特性
模型 數據 高價 + 低頻 高價 + 高頻 低價 + 低頻 低價 + 高頻
移轉性高 +
容錯率高
美顏 人臉偵測 智慧CRM [3] 文字情感分析、網
路廣告推薦 [5]
移轉性高 +
容錯率低
OCR [6] 、語音識
別 [6]
人臉識別 機器翻譯 [6] 聊天機器人 [5]
移轉性低 +
容錯率高
虛擬試妝 智慧安防 商品推薦 [4] 電商產品搜尋、新
聞推薦 [4]
移轉性低 +
容錯率低
智慧工安、醫療影
像 [1]、自駕車 [1]
工業檢測、無人商
店 [2]
企業營運數據分析
[3]
訊息過濾
顏色僅代表從數據與模型的要求高低，來區分不同應用的入門門檻（綠低紅高），不代表目前競爭情況。

14. [1] 取回反饋數據代價高，要先預留接口
● 特色：
○ 數據更新頻率雖不高，但難取回。模型對數據相依性高，且模型容錯率低。
● 代表性應用：自駕車
○ 在產品設計之初，就得想好如何取回標註過的數據。
○ 例如：Tesla先讓車子上路，捕捉數據，再同步完善模型。
● 代表性應用：醫療影像
○ 需和醫療院所相關人員有深度合作，才有機會取得有限的、標註過的數據。
○ 模型訓練好後，要驗證、取回標註過的數據，週期很長。
● 小結：
○ 設計好數據取回的方式，比優化數據擷取流程重要。
○ 此類應用，要由第三方提供服務較困難；但由數據擁有方自行研發，對模型要求度高，較難用普
通工具自行建模。

15. [2] 數據難取又易變，要先打通數據迭代的任督二脈
● 特色：
○ 數據取得成本高、更新頻率高，且模型對數據相依性高，需耗費大量資源
才能做出第一版產品。
● 代表性應用：無人商店
○ 可口可樂在美國就有 1萬5千個SKU，每季商品推陳出新。
○ 在做第一版產品時，就得同時設計並佈署以下機制：數據取回、抽樣、標
註、自動用新數據去更新模型，並自動檢驗新模型好壞。如此，才能跟上數
據的快速變動。
● 小結：
○ 做這事情之前，要想清楚，決策者不能有「先做做看再評估」的心態。
○ 不是不能做，而是需要相對應資源才能打這仗。計畫管理，首重目標與資
源的匹配。資源不足卻硬幹，只會兵敗如山倒。
○ 此應用，建議大量採用雲平台已提供之架構，避免重刻工具與零件。

16. [3] 數據成堆又雜亂，要先建好數據清理capacity
● 特色：
○ 企業很容易自行用各種 SQL、noSQL資料庫記錄數據。每家企業記錄的數據 內容與格式皆不相
同；即便是單一企業，資料庫的欄位，未必都正確、完整。
○ 即便是採用第三方系統，由於選擇眾多，不同系統間數據兼容性常是個問題。
● 代表性應用：企業營運數據分析
○ 從數據中挖出有用資訊的需求雖頻繁又大量，但常是一次性的需求，很難做成標準化的 產品。
○ 過往偶有成功案例，僅限做部分工具或非常侷限的數據。
● 小結：
○ 採用第三方方案時，由於導數據、清理數據費時，多半只能處理到「表層」數據、離「錢」最近的數
據（如CRM）。
○ 欲處理分析更深層營運數據，通常需自建團隊處理；常見金字塔型的團隊（人數由多至寡）： BI
(Business Intelligence) 分析師 → BI 工程師 → DW (Data Warehouse) /DP (Data Platform) 工
程師 → 數據科學家

17. [4] 有些事，數據擁有者做得輕鬆，外部供應商做得艱辛
● 特色：
○ 推薦系統的數據，是 B2C生意的命門，一年動輒上億筆數據。
○ 所用的模型不複雜；大如 Amazon、AirBnB，仍重度倚賴算法相對簡單的 collaborative filtering做
推薦、gradient boosting tree做搜尋。
○ 關鍵在於數據：數據越乾淨、大量、完整，數據飛輪轉得越快，推薦與搜尋系統就會越好。
● 代表應用：電商商品搜尋、推薦
○ 數據擁有者的內部數據團隊，可以玩得很開心。
○ 外部供應商要賣進去，要在 產品與商務模式上都有所突破。
● 小結：
○ 人口大的市場（>6000萬人），數據擁有者，多已自行推動數據飛輪。
○ 人口小的市場，數據擁有者常未充分利用；自行開發效果有限，外部解決方案不能搔到癢處。

18. [5] 數據充足又低價？先進者已持續推動飛輪多時！
● 特色：
○ 天下沒有白吃的午餐；數據充足又低價，完全就是比推動數據飛輪的速度！
● 代表應用：數位廣告推薦
○ 2015年之前，數位廣告投放優化，蔚為顯學；有諸多新創，前仆後繼的進入此市場。然而，沒人能
像Google與Facebook般收集到那麼多使用者、那麼多面向的資料。至 2017時，數位廣告投放市
場已被Google與Facebook兩家寡佔。
● 小結
○ 後進者，是否能後發先至，端視其推動數據飛輪的速度。 Google兩週更新搜尋引擎一次，後進者
若能做到7天一次，則有望於一半時間追上。當先進者已不只於單一領域累積使用者資料，而於
諸多應用上累積，則難追矣。
○ 然，若使用者習慣改變，如：年輕人由 Facebook → Instagram → Discord，則後進者仍有機會更
快速累積、創造優勢。

19. [6] 即便是低頻數據，也要追求數據積累、模型迭代
● 特色
○ 有些乍聽之下很古老、成熟、改變緩慢的應用，實際上仍在不斷演進，同樣要競爭數據積累與迭
代的速度。
● 代表應用：機器翻譯
○ IBM投入早，但未形成數據閉環，未能有效推動模型迭代，故已被後進者超越並遠 拋在後。
○ Google在各語言間的翻譯支援最齊全，但後進者如百度、騰訊，在特定語言間已並駕齊驅。

20. 因應數據特性設計產品，並架構合宜數據系統
● 不變的是：快！快！快！
1. 收到新數據，花多久才能標註完？
2. 數據標註好後，花多久才能更新數據集？
3. 數據集有做版本控制嘛？
4. 如何決定新數據訓練的新模型可以上線？
● 改變的是：如何快？
1. 如何加快數據收集*？
2. 如何加快數據標註？
3. 如何加速數據集更新？
4. 如何加速模型訊訓練？
5. 如何加速模型驗證？
6. 如何加速模型上線？
*有些數據不能離開用 戶端，得用federated learning，不在此次討論範圍 內。

21. 1. 如何加快數據收集？
● 曾經誤花很多時間進行各種SQL、NoSQL資料庫在不同性質數據間寫入與讀取
速度的比較。
○ 每種方案，都還有進一步優化，建立 index、cache的方法，很難有個相同的比較基準。
○ 標準化寫入/讀取的效能差異不大。關鍵差異在於從海量數據（例如：從近半年 內、數億筆記錄中
，排列出網路市集的店家，於促銷前 /促銷後的平均瀏覽、點擊、交易數據，並按地區排序），篩選
出符合條件數據的效能差異。。
● 能透過標準SQL Query，自動調節資源，按用量計費的雲端托管服務 （cloud
managed service），能幫我們更快架起數據架構，讓我們加速到下一步。
○ Snow Flake, AWS redshift, Azure SQL Data Warehouse, Google BigQuery 各有千秋。
○ 選定一個就持續用下去；同樣是 SQL query，不同平台的Query語法支援差異太大，不 值得搬來
搬去。同時，也不建議在「數據收集 → 模型上線」的各環節間，於不同平台跳來跳去。

22. 2. 如何加快數據標註？
● 架構選擇：
○ 標註工具的完整度與易用度
○ 能輕易的從雲端平台導入導出數據
○ 能進行採樣與標註結果管理
○ 能輕易的整合外包標註平台
○ 進行任務分配與標註者管理
● 標註任務設計：
○ 以一秒完成一個任務為目標。
○ 不論標得多細心，一定會有標錯的樣本。標
註任務應設計得越簡單越好，但同一樣本能
有多次標記。
● 方案比較
○ AWS的數據標註工具、外包系統整合、外包
服務市集，較MS Azure與GCP完整。

23. 3. 如何加速數據集更新？
● 標好的數據，一定要能自動驗證、自動更新到數據集
○ 數據標註一定會有錯，越能自動挑出需要複審的樣本，則數據集更新越快。
○ 若數據分布於一embedding上，只需找出和已驗證過的數據差異大者，即能有效挑出需要複審
的標註。若非，則用常見 EDA方式半自動挑選。
● 數據集一定要做版本管理
○ 數據集一定會有錯誤標註，一定需要回頭修正。
○ 數據集有做版本控制，才能自動加入新標好的數據，免去手動操作。
○ Git-LFS、DVC、Pachyderm各有優點。Pachyderm適合需要重度優化數據工作流者，但同時提供
數據版本控制。若僅需管理數據版本， DVC易上手且能輕易整合各雲存儲（ S3、Azure Storage、
GCS）。
● 分類索引，不可能一開始就定好；要能處理「不同數據集使用不同分類索引」
○ 為了標註速度，標註時所用的索引，不一定會是訓練模型的索引。
○ 訓練模型時，為了提昇效能，常需將多分類合併，或是將單分類分開。每個模型用的數據索引通
常都不同。

24. 4. 如何加速模型訓練？
● 不要為了省錢而買GPU做開發與訓練
○ 若為開發：線下GPU再怎麼便宜，也不比 免費的雲服務便宜；若工程師用不慣，歡迎 BYOM
○ 若為訓練：線下GPU最多不過4顆、8顆。資源若一人獨佔，則利用率總是比預期低。若多人共用，
沒有排程機制，會發生資源衝突；有排程機制但資源有限時，訓練週期會拉得很長。
● 模型要能多GPU/TPU進行訓練
○ 一個模型，若未經過百組的 hyperparameter tuning，每一組的hyperparameter，若未經五次時次
以上的反覆驗證，其效能提昇或穩定性，都不足為信。訓練架構的設計，應以在 24小時內完成這
數百次的訓練為目標下去設計。為此，訓練程式一定要能支援多 GPU/TPU。
● 系統要能手動/自動增加運算資源
○ 能利用雲平台托管服務，自動調升多 GPU/TPU訓練，即便單價稍貴，也是 值得的。
○ 若欲自建團隊共用的 auto-scaling training script，如GCP Burst Training，需確保團隊夠多人會
用，且維護成本低於自建 auto-scaling機制省下的錢。

25. 5. 如何加速模型驗證？ML團隊的好習慣非常重要！
● 應記錄模型訓練時的多次分數分佈：
○ 每一個模型的每一組 hyperparameter，不只記錄validation set上最好的一次precision / recall /
accuracy分數，應該要將訓練多次的分數分佈記錄下來，算出平均與標準差。
○ 如此，才能知道新模型的分數提昇是否具有 statistical significance。
● 應建立「移動標靶」的衡量機制：
○ 會持續改變的測試集， ML團隊通常不習慣也很排斥，但這是必要之惡。
○ 會持續改變的測試集，易使新模型表現時好時壞；決定新模型是否上線，同樣要看新模型表現與
舊模型相比是具有統計上的顯著差異。
● 模型要有pre-production/staging階段測試，要做版本控制：
○ 模型部屬在跟production相同環境，但僅抽樣輸入、抽樣檢驗輸出（有些應用，需避免新模型上
production做A/B test），自動記錄一兩週的分數。若分數提昇超過一定標準，則安排其自動上
線。
○ 自動驗證上線之模型，若於上線後收到超過一定比例的負面反饋，需有模型版本回溯機制。

26. 6. 如何加速模型上線與迭代？
● 太早優化是萬惡之源 (The Art of Computer Programming, Dr. Donald Knuth)
○ 先不要花太多時間糾結於模型的大小、推論的速度、或是模型推論所用的服務與架構。
● 多利用雲端托管服務，自動調節運算資源，減少dev/ops成本
○ 若使用標準模型，且推論前後所需做的特殊處理甚少，建議直接將模型轉換成 ONNX或其他標
準格式，利用SageMaker Inference、Azure Machine Learning、Google Cloud Inference。
○ 若用自定義模型，或需額外進行前置 /後置處理，可用雲端托管服務部屬 Docker container。
Amazon ECR、Azure Container Registry、Google Cloud Container Registry皆能輕易整合。
○ 若選擇用Docker，除非必要（如：影片拆幀後直接大小暴增百倍），盡量不要把推論以外的功能整
合進Docker裡，以利日後模型之迭代。若有必要做額外處理，宜善用雲平台各種托管運算，如
AWS Lambda、Azure Functions、Google Cloud Function，可大幅減少dev/ops。
● 模型上線後，新數據與推論結果一定要取回
○ 莫讓ops團隊一直抱怨模型， AI團隊卻一直堅持模型沒問題，要以實際上線抽檢錯誤為準。若上
線後數據改變，沒理由模型不重新訓練。

27. 這些事情，以傳統的團隊分工，會很難推動
● 要打通數據的任督二脈，涉及AI團隊、前後端、QA、PM。在一個分工明確、個有
利害關係的組織，不是找個AI經理或總監，就能推動數據飛輪的。即便空降了AI
VP、CTO，在沒有戰功前，會很難服眾。
● 最尷尬的是，推動數據飛輪對技術主管的KPI少有直接幫助。除非CEO或董事長
有清楚的認知，不然技術主管只會淪落為人作嫁，讓業務與營運單位徒增績效，
數據單位看起來只是為企業徒增成本。
● 推動數據飛輪和推動AI一樣，需要組織內從上而下、橫跨多個單位，都有高度共
識、相同認知；這也正是台灣人工智慧學校創校的初衷。

28. 不要為了省錢而浪費時間；最珍貴的，就是時間。
● 企業的壽命比人還短
○ 台灣創業，平均只存活 4年。
○ 美國極為成功、被選入 S&P 500指數的上市公司，平均只存活 18年。
● 不要所託非人
○ 不是找個顧問評估，再找幾個年輕人試一試，做幾年不成功再修正。
○ 一試不成，就落後競爭對手很遠了。
● 不要閉門造車
○ 不要花一年半載的自建機房、自己設計架構、自己寫數據、訓練、上線系統。
○ 這些表面績效最容易騙自己、騙主管，讓人誤以為有在做事，但對達成目標一點幫助也沒有。
● 不要因小失大
○ 有些雲平台比較便宜，但托管服務不全備，使用起來功能東缺西缺，屢遇預期外的錯誤。
○ 即便有很強的團隊能幫忙填補平台與架構上的缺失，團隊時間寶貴，應花在更重要的事情上。

29. 一切，都還是以客為尊
● 以客為尊，在企業裡很容易被績效蓋過，容易在執行時被忽略、遺忘。
● 企業在推動數位化、AI化時，容易訂出疏遠消費者的錯誤戰略
○ 過度用語音、聊天機器人取代真人客 戶服務。
○ 演算法反應過快、大幅度調整尖峰時段費率。
○ 廣告或商品推薦系統過度個人化，讓客 戶感受到隱私受到侵犯。
○ 金融、社交、電商的防詐騙系統過度敏感，導致許多正常用 戶無法正常操作。
● 在團隊執行戰術時，也有很多坑，會疏遠消費者
○ 訂了錯誤的KPI：該優化召回率＋複檢，卻誤優化精確率
○ 模型更新時，未建立完整的配套，直接做 A/B testing