Download as PDF, PPTX
![代表性應用：數據 vs 模型特性
模型 數據 高價 + 低頻 高價 + 高頻 低價 + 低頻 低價 + 高頻
移轉性高 +
容錯率高
美顏 人臉偵測 智慧CRM [3] 文字情感分析、網
路廣告推薦 [5]
移轉性高 +
容錯率低
OCR [6] 、語音識
別 [6]
人臉識別 機器翻譯 [6] 聊天機器人 [5]
移轉性低 +
容錯率高
虛擬試妝 智慧安防 商品推薦 [4] 電商產品搜尋、新
聞推薦 [4]
移轉性低 +
容錯率低
智慧工安、醫療影
像 [1]、自駕車 [1]
工業檢測、無人商
店 [2]
企業營運數據分析
[3]
訊息過濾
顏色僅代表從數據與模型的要求高低，來區分不同應用的入門門檻（綠低紅高），不代表目前競爭情況。](https://image.slidesharecdn.com/datavsproduct-201111180738/75/vs-AI-13-2048.jpg)
![[1] 取回反饋數據代價高，要先預留接口
● 特色：
○ 數據更新頻率雖不高，但難取回。模型對數據相依性高，且模型容錯率低。
● 代表性應用：自駕車
○ 在產品設計之初，就得想好如何取回標註過的數據。
○ 例如：Tesla先讓車子上路，捕捉數據，再同步完善模型。
● 代表性應用：醫療影像
○ 需和醫療院所相關人員有深度合作，才有機會取得有限的、標註過的數據。
○ 模型訓練好後，要驗證、取回標註過的數據，週期很長。
● 小結：
○ 設計好數據取回的方式，比優化數據擷取流程重要。
○ 此類應用，要由第三方提供服務較困難；但由數據擁有方自行研發，對模型要求度高，較難用普
通工具自行建模。](https://image.slidesharecdn.com/datavsproduct-201111180738/75/vs-AI-14-2048.jpg)
![[2] 數據難取又易變，要先打通數據迭代的任督二脈
● 特色：
○ 數據取得成本高、更新頻率高，且模型對數據相依性高，需耗費大量資源
才能做出第一版產品。
● 代表性應用：無人商店
○ 可口可樂在美國就有 1萬5千個SKU，每季商品推陳出新。
○ 在做第一版產品時，就得同時設計並佈署以下機制：數據取回、抽樣、標
註、自動用新數據去更新模型，並自動檢驗新模型好壞。如此，才能跟上數
據的快速變動。
● 小結：
○ 做這事情之前，要想清楚，決策者不能有「先做做看再評估」的心態。
○ 不是不能做，而是需要相對應資源才能打這仗。計畫管理，首重目標與資
源的匹配。資源不足卻硬幹，只會兵敗如山倒。
○ 此應用，建議大量採用雲平台已提供之架構，避免重刻工具與零件。](https://image.slidesharecdn.com/datavsproduct-201111180738/75/vs-AI-15-2048.jpg)
![[3] 數據成堆又雜亂，要先建好數據清理capacity
● 特色：
○ 企業很容易自行用各種 SQL、noSQL資料庫記錄數據。每家企業記錄的數據 內容與格式皆不相
同；即便是單一企業，資料庫的欄位，未必都正確、完整。
○ 即便是採用第三方系統，由於選擇眾多，不同系統間數據兼容性常是個問題。
● 代表性應用：企業營運數據分析
○ 從數據中挖出有用資訊的需求雖頻繁又大量，但常是一次性的需求，很難做成標準化的 產品。
○ 過往偶有成功案例，僅限做部分工具或非常侷限的數據。
● 小結：
○ 採用第三方方案時，由於導數據、清理數據費時，多半只能處理到「表層」數據、離「錢」最近的數
據（如CRM）。
○ 欲處理分析更深層營運數據，通常需自建團隊處理；常見金字塔型的團隊（人數由多至寡）： BI
(Business Intelligence) 分析師 → BI 工程師 → DW (Data Warehouse) /DP (Data Platform) 工
程師 → 數據科學家](https://image.slidesharecdn.com/datavsproduct-201111180738/75/vs-AI-16-2048.jpg)
![[4] 有些事，數據擁有者做得輕鬆，外部供應商做得艱辛
● 特色：
○ 推薦系統的數據，是 B2C生意的命門，一年動輒上億筆數據。
○ 所用的模型不複雜；大如 Amazon、AirBnB，仍重度倚賴算法相對簡單的 collaborative filtering做
推薦、gradient boosting tree做搜尋。
○ 關鍵在於數據：數據越乾淨、大量、完整，數據飛輪轉得越快，推薦與搜尋系統就會越好。
● 代表應用：電商商品搜尋、推薦
○ 數據擁有者的內部數據團隊，可以玩得很開心。
○ 外部供應商要賣進去，要在 產品與商務模式上都有所突破。
● 小結：
○ 人口大的市場（>6000萬人），數據擁有者，多已自行推動數據飛輪。
○ 人口小的市場，數據擁有者常未充分利用；自行開發效果有限，外部解決方案不能搔到癢處。](https://image.slidesharecdn.com/datavsproduct-201111180738/75/vs-AI-17-2048.jpg)
![[5] 數據充足又低價？先進者已持續推動飛輪多時！
● 特色：
○ 天下沒有白吃的午餐；數據充足又低價，完全就是比推動數據飛輪的速度！
● 代表應用：數位廣告推薦
○ 2015年之前，數位廣告投放優化，蔚為顯學；有諸多新創，前仆後繼的進入此市場。然而，沒人能
像Google與Facebook般收集到那麼多使用者、那麼多面向的資料。至 2017時，數位廣告投放市
場已被Google與Facebook兩家寡佔。
● 小結
○ 後進者，是否能後發先至，端視其推動數據飛輪的速度。 Google兩週更新搜尋引擎一次，後進者
若能做到7天一次，則有望於一半時間追上。當先進者已不只於單一領域累積使用者資料，而於
諸多應用上累積，則難追矣。
○ 然，若使用者習慣改變，如：年輕人由 Facebook → Instagram → Discord，則後進者仍有機會更
快速累積、創造優勢。](https://image.slidesharecdn.com/datavsproduct-201111180738/75/vs-AI-18-2048.jpg)
![[6] 即便是低頻數據，也要追求數據積累、模型迭代
● 特色
○ 有些乍聽之下很古老、成熟、改變緩慢的應用，實際上仍在不斷演進，同樣要競爭數據積累與迭
代的速度。
● 代表應用：機器翻譯
○ IBM投入早，但未形成數據閉環，未能有效推動模型迭代，故已被後進者超越並遠 拋在後。
○ Google在各語言間的翻譯支援最齊全，但後進者如百度、騰訊，在特定語言間已並駕齊驅。](https://image.slidesharecdn.com/datavsproduct-201111180738/75/vs-AI-19-2048.jpg)
Uploaded byAlbert Y. C. Chen
數據特性 vs AI產品設計與實作
本文件探讨了数据特性对人工智能产品设计和实施的影响，强调产品战略中应包括数据战略。作者指出，数据的更新频率、获取难易度及其价值等特性各异，并影响模型的转移性和容错度。最终强调了数据和模型之间的关系，以及如何在不同场景中利用数据优势来提升企业竞争力。
數據特性 vs 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