Mais conteúdo relacionado
Semelhante a 數據特性 vs AI產品設計與實作 (20)
Mais de Albert Y. C. Chen (18)
數據特性 vs AI產品設計與實作
- 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?
● 想清楚大戰略,是領導人最
重要的事情。
○ 前仆後繼仍無法攻克目標,不
是執行力有問題,而是戰略有
問題。
○ 別用戰術上的勤奮去掩飾你
戰略上的懶惰。
- 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流量飛輪
- 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在各語言間的翻譯支援最齊全,但後進者如百度、騰訊,在特定語言間已並駕齊驅。
- 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團隊卻一直堅持模型沒問題,要以實際上線抽檢錯誤為準。若上
線後數據改變,沒理由模型不重新訓練。
- 28. 不要為了省錢而浪費時間;最珍貴的,就是時間。
● 企業的壽命比人還短
○ 台灣創業,平均只存活 4年。
○ 美國極為成功、被選入 S&P 500指數的上市公司,平均只存活 18年。
● 不要所託非人
○ 不是找個顧問評估,再找幾個年輕人試一試,做幾年不成功再修正。
○ 一試不成,就落後競爭對手很遠了。
● 不要閉門造車
○ 不要花一年半載的自建機房、自己設計架構、自己寫數據、訓練、上線系統。
○ 這些表面績效最容易騙自己、騙主管,讓人誤以為有在做事,但對達成目標一點幫助也沒有。
● 不要因小失大
○ 有些雲平台比較便宜,但托管服務不全備,使用起來功能東缺西缺,屢遇預期外的錯誤。
○ 即便有很強的團隊能幫忙填補平台與架構上的缺失,團隊時間寶貴,應花在更重要的事情上。