(廢文模式 on)
Day 9 繼續加油～
(照這個速度不知道30天能不能把拿到衣服的課程進度要求寫完XDD)
(廢文模式 off)

本日文章

1. Introduction to specialization
2. What it means to be AI first
   • ...
   • Replacing heuristics
   • It's all about data
   • ...
   • Pre-trained models
   • The ML marketplace is evolving
   • A data strategy
   • Training and serving skew
3. How Google does ML
4. Inclusive ML
5. Python notebooks in the cloud
6. Summary

A data strategy

這個小節谷歌用一個例子來說明資料與模型在概念上的關聯性：

• 以谷歌地圖的導航功能為例，如果今天要去谷歌西雅圖辦公室，而谷歌地圖提供了三種可能的路徑，並且告訴我們某一種可以最快到達目的地，這算是「機器學習」嗎？
• 谷歌說明其實這樣的案例可以想像成是由一坨的「規則」所建立的。雖然谷歌本身確實收集了不少資料，但是對於在給定限制下求出任意兩點（Ａ與Ｂ）間的最短距離，「A Algorithm* (唸作 A star algorithm)」
• 如果對 A* algorithm 有些認識的人應該都知道它並不是一個稱得上非常艱澀難懂的演算法，甚至已經在資訊工程相關系所的大學部課程就能找到它的蹤跡。
• 在使用 A* algorithm 的前提下，只要有了資料，整個模型的建模並不會如想像中複雜。但這樣的方法能夠涵蓋所有的導航情況嗎？如果今天使用者所在的位置不是在戶外，而是在某棟大樓、某座車站內呢？
• 相信使用過谷歌地圖功能的人都有經驗，谷歌地圖在某些情況下可以非常準確地分析出使用者當所在的位置並給出相對應的路線建議，但谷歌地圖是如何知道使用者的位置呢？很明顯地，這樣的過程已經不是單純用一堆規則就能分析的完的了。
• 隨著不同使用者使用的情況不同，谷歌地圖也必須按照各種情況給出不同的結果，顯而易見地，這樣的狀況已經離不開巨量資料的使用。甚至可以說是一種資料問題。
• 的確，機器學習其實也能想像是「如何將以規則為主的方法進行規模化並且涵括更多原本規則所無法涵蓋的部分」的一種方式。
• 最後谷歌順著這樣的案例，給出了幾個小結論：
  • 「規則」以及「模型」本身相對資料而言是單純的，因此在解決許多複雜的大型問題時，需要的有可能只是「更多的資料」
  • 如果將「機器學習」比喻成「火箭」的話，「資料」就相當於是「燃料」
  • 當我們在對模型進行調参以追求更強大的表現時，往往容易忽略一個關鍵的要素：「資料永遠是核心關鍵」
  • 如果在「開發更複雜的模型」與「收集更多的資料」中做選擇，谷歌認為請把時間精力花在「收集更多資料」上。而收集的資料不僅僅只能是「量 (quantity)」的增長，也必須同時兼顧「多樣性 (variety)」
  • 機器學習的使用策略，第一步就是「資料策略」

Training and serving skew

谷歌在這個小節提出了一些關於要如何開始機器學習專案的撇步：

• 請從「正在進行手動資料分析」的專案開始下手。
• 之所以要從「手動資料分析」開始下手，粗略有以下三個原因：
  1. 如果「正在進行手動資料分析」，代表「有極大的可能已經擁有資料」。而「收集資料」這個步驟恰恰是機器學習整個環節中最耗時也困難的步驟。因此這也是為何需要「先進行手動資料分析」這個步驟的原因之一。
  2. 而若目前沒有資料，整個機器學習專案就會從最初的收集資料與評比資料的過程開始。而所謂「評比資料」其實就是在尋找資料所對應到的「標籤」。有了這樣的基礎才能進行「手動資料分析」。至於接著為何需要先進行手動資料分析的原因是：「如果沒辦法從資料中了解到當給定具有意義的輸入並且得到預期輸出時，接下去是完全沒有辦法進行機器學習的」雖然在這個步驟常常會面臨失敗，但失敗的同時也代表著能更快地思考新的想法並付諸實現，因此千萬不要小看資料分析這一步，它常常也能帶給我們一些隱藏在資料背後的意義。
  3. 最後一點則是：「如果要建出一個好的機器學習模型，必須了解資料」。而「了解資料」其實也就是整個機器學習專案中的第一步，那有什麼理由不進行資料分析呢？因此可千萬不要一拿到資料後就直接套用機器學習的模型來建模，這可能會消耗掉許多無意義的時間。
• 機器學習其實就是一趟「自動化 (automation)」與「規模化 (scalization)」的旅程，因此若沒有分析的基礎，也就甭談如何使用機器學習了。

接下來谷歌談論了有關機器學習在「學習」與「預測」兩種不同階段下所常見的問題：

• 機器學習的產品在許多情況下實際上很容易失敗的，這樣的狀況可稱之為「Training-serving Skew」

• 而原因則多數歸咎於在模型的學習階段與預測階段在「運作」上有著非常大的不同。例如：

  • 模型在建構的時候是由資料科學團隊使用以往的歷史資料來建模，但實際上線時是使用了完全不同於開發階段的環境。打個比方，建模時是使用「批量 (batch)」的方式，但上線時卻是以「串流 (streaming)」的方法來輸入資料。
  • 模型訓練時是在本地端的機器上使用 Python 來開發，而在上線時卻是將模型放在用 Java 為主體的網頁框架上運行，中間環境的相容勢必也是一個大問題。
  • 甚至模型訓練時的資料預處理方法也可能與實際上線後的方式有所差別。

• 這些原因族繁不及備載，因此要如何降低所謂「Training-serving Skew」也將會是一個棘手的問題。

• 接下來就到了谷歌的工商時間啦～ (谷歌建構了一個以雲端為基礎的架構，對於整個機器學習在開發階段以及上線維運階段都有一套 API 來串連，進而達到最大化降低「Training-serving Skew」的風險)

小結

基本上第一個小節是在強調「資料」的重要性，與前面幾節的內容依然一脈相承，可見得資料真的是非常重要ＸＤ

而第二小節雖然谷歌下的標題為「Training and serving skew」，但筆者認為重心應放在機器學習專案在建模前的「資料分析」。而筆者之所以這麼認為，並非覺得「Training and serving skew」這個問題不重要，而是Training and serving skew」發生的前提，必須是已經有一個成功並且值得上線的機器學習模型。倘若目前連一個成功的模型都沒有，自然這個問題也就不存在了是吧～

因此筆者認為在第二節中最重要的概念應該是「資料分析」。如同谷歌提到的，機器學習要能成功的關鍵跟資料脫不了關係。因此「對資料了解多深、多透徹」也勢必就是機器學習要能成功的關鍵之一。

千萬不要一拿到資料就很興奮的開始拿各種演算法套用... 運氣好可能有幾個會成功，但即便成功，也不會知道「為什麼成功」... 而更多的情況是，嘗試了一大圈的模型，發現怎麼試都失敗，回頭來看資料才發現資料本身有許多缺陷，當然不可能建構出一個好的模型，而在嘗試各種流派的模型中所消耗時間成本也就跟著煙消雲散了...

(禮拜二... Orz)