2024 領航計畫已開放報名,請點擊後查看報名資訊
前往 Medium 閱讀好讀版

黃柏翰 (David Huang) | Research Fellow@Innopeak

數據分析在智慧手機設計上的應用

活動主辦單位:Taiwan Data Science Meetup 台灣資料科學社群

講者介紹

David從南加州大學獲得博士學位後,在矽谷開始了他的軟件工程師職業生涯。 David於2011年加入nvidia,致力於通過優化移動GPU的性能和電池壽命來改善用戶體驗。他的作品之一是BatteryBoost,這也是nvidia 當年的主打功能之一。2013年David加入了Apple,並且是Apple Watch,Genius Bar服務工具iOS Diagnostics,功耗檢測系統,以及Xcode Energy Gauge開發工具的第一代作者。 David還在2015年的蘋果全球開發者大會上介紹了他的作品。為了追求更大的舞台,David於2016年加入華為美國研究中心,設計並領導了用於智能手機和平板電腦的大數據架構的開發。自推出以來,該系統每天為超過3億台設備提供服務。華為美國研究中心關閉後,David以科學家職務加入Oppo美國研究中心Innopeak。他正在建立一個用於優化用戶體驗的大數據和AI平台,並使用數據驅動的方法改進現有的工作流程。

大綱

  1. 神速除錯
  2. 即時異常檢測
  3. 魚與熊掌怎麼兼得 (成本與用戶期望間的取捨)

神速除錯

🎯 目標:讓除錯(Debugging)速度大幅提升,不只有10%、20%的提升,而是10倍、20倍以上的提升。

發現Bug的管道主要有以下兩種:第一種是公司內部,主要為開發人員測試手機時發現Bug。第二種是客戶,產品已經上架後,客戶找到Bug並且到論壇反饋或者直接找公司客服請求幫助或要求退貨。Bug主要分為以下兩種:

1. Functional Bug:這種問題通常很容易被客戶發現,通常產品上架後沒多久就會被發現,通常幾天就能解決。

2. Quality Bug:(前公司案例),某次軟體更新後,造成手機在某個狀態下不太睡覺,非常耗費電池容量,總體來說多耗3–5%的電,非常難找出原因,可能是因為用戶行為不同或者其他App更新導致。通常用戶要過幾週才會發覺,然後才到論壇或公司抱怨,通常用戶描述不是很清楚,然後工程師花很多時間Debug,這種問題可能會要花幾個月才解決。但我們透過數據分析去縮短這個時間到一週就可以完成。

👉 怎麼解決

透過建立用戶體驗大數據儀表板來加速除錯。以上面Quality Bug的例子來說,我們首先觀察用戶每天電量的使用情形,透過將新版及舊版的用電量呈現在圖表上來進行比較,David舉例用累積密度函數圖(縱軸為機率密度、橫軸為耗電量,數值越大表現越差),藉由比較新版跟舊版的累積密度函數來判斷是否用電量真的有明顯差別。

接著,再來細分每一個手機硬體零件(Component)的電量消耗,David舉例用箱型圖來呈現,一樣對比新版和舊版,比較每一個零件在新版跟舊版的耗電量差異,藉由此方法去量化去並了解哪個零件(CPU、Wifi等)的耗電量差異最大。

假設我們發現耗電量差異主要來自CPU,但有可能是用戶用得多,接下來就要探討要怎麼區分到底是不是主動意願跟非主動意願,比較FG (Fullground) & BG (Background),一樣透過箱型圖來比較,進而發現大部分用戶體驗成分是在BG。

最後可以再來細分到底是因為哪個App耗電量多,透過類似的圖表,我們可以找出某個App耗電量較高。雖然我們有看到主要是因為哪個App耗電量高,但如果反饋給該App的開發公司,他們可能會說是因為其他問題而導致的,接著就再更細的分類,在CPU的計算量的差異。在這例子裡是因為Wake Lock讓手機不睡覺的原因大幅增加。有可能是因為某個App因為某種原因讓手機不睡覺,進而讓手機耗電很高。

註解

- Big Core 計算能力強、能效爛

- Small Core計算能力弱、能效好

- Wake Lock 讓手機不睡覺的機制

以上是如何運用數據來加速除錯的方法,透過自動化的方式我們可以在1–2天內知道Bug在哪,並開始修復Bug,等到內部開發人員修復好Bug後,再透過一樣的方法來看到底Bug有沒有被解決。

即時異常檢測

🎯 目標:精準判斷異常,立即採取措施,來解決用戶體驗不好的問題。

有時候我們可能可以很快偵測到Bug,但Debug會花開發人員很多時間,對於賣手機的廠商不好,可能用戶會退貨,修得越慢、成本越高。我們能不能知道有異常之後馬上進行Reset。

例子ABC App,新版Software有Bug,發現兩天內有16個人退貨,因為App有Bug讓電池容量燒光,ABC App有馬上被下架,但整體來說用戶體驗不好。如果我們有辦法當偵測到App有Bug的時候,就馬上Reset軟體到前一個版本進行修復,這樣就可以降低用戶體驗的損害。

👉 怎麼解決

以往的方式都是預設一些條件,當條件觸發的時候就去啟動Reset,通常依照每家公司的經驗法則,找專家來定義在一個時間內消耗掉多少電池就Reset,這個方法的缺點是數據通常不會跟實際的數據一樣。

主因是因為每個用戶使用App的方法其實不一樣,比如說年長的人跟一位常開Uber的人,兩者的手機耗電量完全不同,如果依照整體來看,方法的精準度不好,我們應該要如何區分用戶?主動意願使用量 vs. 非主動意願開銷 BG vs. FG去做畫圖,兩者會有關聯性。

1. 最簡單的方法 — 把FG Bucket起來,假設他們的非主動意願是一樣的,然後在每個Group去找Outlier。可以Convert成Supervised Learning的方法、或者用Unsupervised Learning Threadshold法用一張表去涵蓋共種狀態,每當有一個新的Dimension,那表就會越來越大,可能會大到沒辦法傳到手機內做使用。導致此方法不能更廣泛地應用,因為有太多種可能。

2. 進階的方法 — 用模型,首先我們嘗試用Tree Based Model,但是False Positive Rate 達不到我們的預期。 最後用Neural Network來執行,做異常預測,檢測到異常之後在去做一些手段去Reset App。

以上是如何運用模型來做即時異常檢測,並立即採取措施,來解決用戶體驗不好的問題。

魚與熊掌怎麼兼得

🎯 目標:量化成本與用戶期望間的取捨,並找到最佳的方法來控制成本且滿足客戶需求。

企業目的是為了獲利,所以如何能夠降低生產成本就是企業獲利的關鍵,但是另一方面為了公司又不想因為降低成本而影響到用戶體驗,獲利和用戶體驗間的取捨變得十分重要,其實這種取捨可以把它制訂成數據分析的方法去量化。

例子cellular PA (Power Amplifier)技術中有兩種Spec,ET比較省電但價錢貴、APT比較耗電但價錢便宜,對於中低階的廠商來說,小錢非常重要,因為薄利化。

👉 怎麼解決

分析用戶的使用狀況,看ET省電的部分到底有多少,假設全部為ET或APT的兩種情況進行比較,並將其轉換成圖表,利用圖表來表達出兩者的取捨,然後提供給公司的設計師,讓他們看在不同的成本配置下,用戶體驗會是怎麼樣。

以上是如何運用圖表來呈現成本與用戶體驗的取捨,再提供給設計師方法來了解其關係。

Q&A精選

Q1 請問大數據儀表板這個,還是需要人肉眼去判斷藍色橘色群體嗎?還是把這些條件怎樣去設成alert,讓它自動寄警示信提醒?

  • 完全可以自動化,非常機械系都可以寫成code去解決。

Q2 謝謝精彩的分享! 好奇Nvidia, Apple, 華為這三間公司的文化有什麼樣的差異? 在這些公司的High performers大概具有怎麼樣的特質?

  • 華為和Apple的公司企業文化很強,但是很不同。Nvidia 相較之下比較沒有沒有那麼強。華為強調狼性和競爭性,有些惡性循環和惡性競爭是存在內部的,但成長及獲利速度飛快,而Apple則反之,比較正向的長期發展為主。

Q3 就自動發現能量消耗的問題,是用v1和v2為案例,但是會趕快升級到v2的人,可能使用行為會跟停留在v1的人不一樣,請問你們怎麼處理呢? 另外,如果這是第一版,沒有前一個版本來比較,要怎麼偵測呢?

  • 有一些數字可以去判斷,沒有大量數據很難去判斷,第一版沒有還是可以做比較,用橫向對比,找其他app去對比,小眾的app就不會花時間去,找競爭對手的來比用 Margin。

Q4 請問貴公司有分所謂的資料分析師和資料科學家嗎?還是都合稱叫做資料科學呢?我聽過的有些資料分析師比較少用機器學習或者人工智慧來做分析, 那些是資料科學家在做的事情

  • 看公司,講者公司都是歸類在分析師,除了講者真的都是用數據在做歸類的叫大數據科學家,Apple 都是叫資料科學家,BI & DA都是同一個名稱,工作上處理資料內容比較重要。

Q5 謝謝你的分享,在使用決策樹的模型在找出異常的例子,想請問在智慧型手機應用上,是怎麼評估多少準確度,才會把模型應用上去。

  • 模型的False positive要求要非常高,給一個期望值並要到99.95%以上的精準度,區域base怎麼都做不到,但後來用Neural Network,另外寫一個app去跑。Data Bias & Unbalance的問題,用artifical的方式去test。

筆手:Jason Wang
校稿:David Huang, Nina Chen
👉 歡迎加入台灣資料科學社群,有豐富的新知分享以及最新活動資訊喔!

資料科學協會

資料科學協會

社群分享筆記 更新紀錄

Copyright 2020-2024 資料科學協會 All Rights Reserved.

本網站由 資料科學協會 維護