![]()
【為什麼我們要挑選這篇文章】機器學習初學者，要做到哪些事情，才能成為一名優秀的機器學習工程師呢？這位入職一年的工程師，在這封信中提出了 12 點建議。（責任編輯：藍立晴）
「做自己的懷疑論者，不斷試錯，有時，溝通比技術本身能帶來更大的價值。」——佚名
親愛的讀者：
你們好！我是 Daniel Bourke，一位來自澳大利亞的機器學習工程師。我在這個崗位上從業有一年之久了，好吧，可能很多讀者對這個崗位不太熟悉，可以隨我看下一天的工作流程：
一位機器學習工程師的一天是這樣展開的
早上 9 點，我會走進公司，問同事早安，把我的食物放進冰箱，倒一杯汽水，然後走向我的辦公桌。我坐下來，看著我昨天的工作筆記，然後打開 Slack，接著我會閱讀訊息，打開團隊分享的每一篇論文或是部落格，每天都會有一些要看的消息，因為這個領域的更新發展很快。
訊息讀完後，我會瀏覽論文和部落格，並且會著重閱讀那些讓我困惑的內容。通常，那裡面會有一些內容能幫到我現在的工作。我會用一個小時進行閱讀，有時會更多，這取決於我看的內容，閱讀是最基礎也是最關鍵的能力，如果我現在做的事有更好的方法，那麼我會學習並運用這個方法，這可以節約我的時間和精力。
早上 10 點，如果工作任務的截止日期快要到了，我會縮減閱讀的時間來趕任務，這是我一天中花時間最多的地方。我會回看我昨天的工作內容，並且查看我寫下的後續工作步驟，我的筆記本記錄了我一天的工作流程。
在後續操作數據的過程中，如果我已經把數據處理成正確的形式了，那麼我就需要用模型跑數據，一開始我會把訓練時間調得很短，如果有了進展，我會把時間加長，如果我遇到問題，數據不匹配的問題出現了，那麼接下來，我會解決這個問題，然後在嘗試新模型前，先獲得一個基準。我絕大多數的時間是用來確定數據是不是處理成了模型所要求的形式。
下午 4 點就快到了，馬上可以放鬆一下了。我說放鬆，指的是清理我寫出的 code，讓它變得清晰易讀。我會加上一些註釋，重新調整 code 的結構，萬一別人要讀我的 code 呢？我會這麼問自己，通常，閱讀我 code 的人都是我自己，因為我經常會很快忘記那些寫 code 時產生的想法。
怎麼成為優秀的機器學習工程師？需要注意這 12 點
以上是一天工作最理想的樣子，但不是每天都這樣，有時候，一個美妙的想法在下午 4 點 37 分的時候迸發出來，那麼我會繼續我的工作，現在你已經對我每天的工作有了大致的了解，接下來我們聊聊機器學習的那些事。
人工智慧的浪潮不斷推進，相信很多讀者和我一樣加入了機器學習的隊伍，我的工作內容很全面：從數據收集、數據處理、建模、實施服務，業務範圍涉及你能想到的每一個產業。
當人工智慧發展進入關鍵十年，台灣人才與產業該如何自處才能在 2030 站穩國際腳步、培養 AI 國力？
8/10（六）【TechOrange 科技報橘 2019 年度論壇】CONNECT to the Future，帶你看見 2030 年的科技趨勢
一人早鳥 75 折、雙人早鳥 6 折優惠票全面開賣！
在這個崗位上呆久了，發現很多事情做起來都是有規律可循的，以一個前人的經驗，總結了一名優秀的機器學習工程師需要注意的 12 個方面，希望讀者在閱讀後，能對機器學習的從業和學習有所幫助！
把時間花在刀刃上：數據很重要！
如果你熟悉數據科學的一些基本原則，就會發現解決實際應用問題，處理 coding 問題，本質上是和數據打交道。可令人驚訝的是，我時常忘記這一點，很多時候，我著眼於建立更好的模型，而不是去提高數據的質量。
建立一個更大的模型、使用更多的運算資源可以在短時間內給你一個很好的結果。然而，出來混總是要還的，接下來你會遇到很麻煩的事。
當你參與第一個項目時，請花很多很多的時間去熟悉數據。之所以說很多很多，是因為你通常需要把你預計花的時間乘以 3。長遠上看，這會幫你在接下來的工作中節約不少時間。
當你拿到一個新的數據，你的目標應該是成為最了解這個數據的專家，你要檢查數據的分佈，找到不同類型的特徵，異常值在哪裡，為什麼它們是異常值？如果你不能把你的數據描述清楚，那你又怎麼能建立模型呢？
![]()
不要低估溝通的重要性
我遇到絕大多數的問題都不是技術問題而是溝通問題，的確，技術難題一直都有，但是那是工程師應該去解決的問題。永遠不要低估溝通的重要性，無論是公司內部的還是公司外部的。最糟糕的事莫過於解決了一個本不該被解決的技術問題。
為什麼會發生這種事呢？
對外來看，這種事發生的原因大多是因為客戶的期望和我們所能提供的服務出現了不匹配，雖然客戶的期望能夠用機器學習實現。對內來看，因為我們每個人在公司都負責很多方面事務，所以我們很難為了同一個目標而做到步調一致。
回到問題的本質。請經常這樣做。請問一問你自己，你的客戶是否明白你們能提供的服務？你是否理解客戶的問題？他們知道機器學習帶來什麼和不能帶來什麼嗎？什麼樣的交流方式能讓你很輕鬆地去展示你的工作成果？
為了解決內部溝通的問題，人們設計了很多軟體。從它們的數量上，你便可以明白解決內部溝通問題有多困難。這些軟件包括 Asana、 Jira、Trello、Slack、Basecamp、Monday、Microsoft Teams。
對我而言，一個最有效的辦法是，每天工作結束時，在項目相關的頻道上更新我的信息。
更新內容包括：
- 3-4 點 ideas
- 關於我的工作內容
- 為什麼
- 根據上面的內容，我接下來要做的
這樣很完美對嗎？不。但是它看上去是有效的，它讓我可以展示我已經做的工作和準備去做的工作。
把自己的計劃公開有一個額外的好處，如果你的工作方案不成立，別人會指出來。你是多好的工程師這並不重要，重要的是你有能力告訴別人你的技術是什麼、你的技術可以帶來什麼，這一點和你維持現有業務並開拓新業務的能力密切相關。
我們曾經有一個有關自然語言的問題：把文字內容歸為不同的類別。任務目標是幫用戶向服務中心發送一段文本，並且自動把文本歸為兩類中的其中一類，如果模型預測的不夠準確，那麼把文本交給人工處理，工作量大概是每天 1000-3000 次請求，不多也不少。
BERT 成為了今年最受矚目的名詞。但是如果沒有 Google 的規模化計算工具，想要使用 BERT 訓練模型來完成我們的需求則非常麻煩，而且這還僅僅是把模型用於生產前所需要的工作，因此，我們找到了另一種方法——ULMFiT。
這個方法雖然不是最前瞻的，但是它能產生足夠好的結果，並且這個方法也很容易使用。
與其將某個方法改進到完美，不如借鑒已有的模型，在這基礎上進行遷移學習，這樣能帶來更多的價值。
將機器學習付諸實踐存在兩個瓶頸：從課程成果到項目成果的瓶頸、從理論模型到生產模型（模型部署）的瓶頸。
網路搜索機器學習課程返回了大量的結果，我用了其中許多課程創建自己的 AI 碩士學位課程。
但即使在完成了最好的幾門課程，當我開始擔任機器學習工程師時，我的技能還是建立在課程的結構化主幹上，在現實問題中，項目並不是結構化的，我缺乏具體的知識，線上的互聯網課程中無法教會你一些技能，比如：怎麼質疑數據、探索與開發模型。
我很幸運能和澳大利亞最優秀的人才在一起工作，但我願意學習也願意做錯。當然，錯誤不是目標，但為了正確，你必須弄清楚什麼是錯的。
如果你正在通過一門課程學習機器學習，那麼繼續學習這門課程，同時要將學到的知識應用到自己的工程項目中，這樣才能使自己具備專業知識。
我在這方面的知識依舊很匱乏，但我注意到了一種趨勢——機器學習工程和軟件工程正在融合。隨著 Seldon，Kubeflow 和 Kubernetes 這些開源平台的發展，很快機器學習將成為其中的另一部分。
在 Jupyter 筆記本中構建模型是一回事，但是如何讓數千甚至數百萬人使用該模型就是另一碼事了。根據最近在 Cloud Native 活動上的討論情況來看，大公司以外的多數人並不知道如何做到這一點。
機器學習中也有一個二八定律，我們有一個 20％ 的規則，這個規則的意思是我們要把 20％ 的時間花在學習上。
事實證明，這段學習時間是寶貴的。比如說 ULMFiT 的使用率超過 BERT 就源於 20％ 時間的規則，20％ 的時間用來學習，意味著剩下 80％ 的時間將用於核心項目。
- 80％ 的核心產品（機器學習專業服務）。
- 20％ 與核心產品相關的新事物。
如果你的工作優勢在於你能將現在做的事情做到最好，那麼未來的工作同樣取決於你繼續做你最擅長的事情，這意味著不斷學習。
精讀論文
這是一個粗略的指標，但是在你探索過一些數據集和實驗現像後，你就會明白它是一種客觀事實。
這個概念來源於 Zinf/Price 定律，即在同一主題中，半數的論文為一群高生產力作者所撰寫，這一作者集合的數量約等於全部作者總數的平方根。
換句話說，在每年數以千計的提交中，你可能會發現 10 篇開創性的論文，在這 10 篇開創性的論文中，有 5 篇可能來自同一所研究所或作者。
如何緊跟時代的潮流？你無法跟上每一個新的突破，你最好紮實掌握和運用一些基本原理，這些基本原理經受住了時間的考驗，新突破需要依靠原創性的突破，然後便是需要新的探索與開發。
您可以通過懷疑自己來處理探索與開發問題。探索與開發問題是嘗試新事物和復用已有模型成果之間的兩難選擇。
運行你已經使用的模型並獲得高精度結果然後將其作為新基準報告給團隊是很容易的。但是如果你得到了一個好的結果，記得反覆再反覆地檢查你的成果，並讓你的團隊也這樣做，因為你是一名工程師、科學家。
20％ 時間的標准在這裡也有用武之地，但是時間分配如果是 70/20/10 會更好。也許你在核心產品上花費 70％，在核心產品的構造上花費 20％，在探索上花費 10％，不過探索的東西可能不會起作用，我本人從來沒有試過這個方法，但這是我正朝著這個方向發展的。
先積跬步，後至千里
不積跬步無以至千里，先建立一些小事，這樣就能快速理解一個新的概念，你可以使用自己的數據集或者不相關的小數據，在一個小團隊中，成功的訣竅是先成功一小步，然後快速迭代。
跟橡皮鴨解釋每行 code
很多工程師可能知道一種小黃鴨調試法（也稱橡皮鴨）調試法，這個概念說的是在調試 code 的時候隨身攜帶一隻小黃鴨，然後詳細地向它解釋每行 code。
可能很多讀者會覺得好笑，這是有原理依據的，類似有一種叫做 cone of answer 的常見現象，比如：你的朋友向你諮詢問題，等說到一半的時候他已經找到問題所在，徒留一臉茫然的你… 總的來說，當你試圖向別人表述自己的問題的過程中，自然地也在促使自己去調整思路，這種方法對工程師同樣適用。
橡皮鴨方法是同事 Ron 教會我的，遇到問題的時候，坐下來盯著 code 可能會解決問題，但也有可能不會，此時，不如用隊友的語言重述，就像你的橡皮鴨。
「Ron，我正在嘗試遍歷這個數組，並通過循環另一個數組以及跟跟蹤它的狀態來嘗試跟踪這個數組的狀態，然後我想將這些狀態組合成一個元組列表。」
「循環中的循環？你為什麼不把它矢量化呢？」
「我能這樣做嗎？」
「讓我們來看看。」
「…」
遷移學習很重要
你不需要從底層重構模型，這個問題來自於機器學習工程與軟件工程的融合。除非您的數據問題非常具體，否則許多主要問題非常相似，分類，回歸，時間序列預測，推薦系統。
Google 和微軟的 AutoML 等服務，只需要上傳數據集並選擇目標變量，就可以輕鬆使用機器學習。
但是這些事情還在初始階段，尚未成形。如果你是開發人員，只需要 fast.ai 這樣的庫，就可以在幾行 code 中使用最先進的模型，以及各種模型的預建的模型，例如，PyTorch hub 和 TensorFlow 提供相同的功能。
這意味著什麼？雖然機器學習已經如此方便，但是仍然需要了解數據科學和機器學習的基本原理，更重要的是要知道如何恰當的運用他們。
Math or Code？It is a problem
對於我處理的客戶端問題，code 優先，所有的機器學習和數據科學程式都是 Python。有時我會通過閱讀論文並進行複現來涉足數學，但 99.9％ 的情況下，現有的框架已經包含數學的庫。
雖說在現實生活中，數學並沒有想像中的那麼重要，畢竟機器學習和深度學習都是數學的應用。但是知道最小矩陣相乘，一些線性代數和微積分，特別是鍊式法則依舊是重中之重。
請記住，我的目標不是發明一種新的機器學習算法，而是向客戶展示機器學習對他們的業務是否有幫助, 有了堅固的基礎，你就可以建立你自己的最好模型，而不是重複使用已有的模型了。
軟體行業的快速迭代
你去年所做的工作明年可能就沒用了哦！這是客觀事實，由於軟體工程和機器學習工程的融合，這種情況越來越嚴重。
但是你既然已經加入了機器學習的大家庭，我來告訴你什麼保持不變——框架會變化，庫會變化，但基礎統計，概率論，數學永遠不會變。最大的挑戰仍然是：如何應用它們。
說了這麼多，希望以上建議能對與機器學習的入門者和從業者有所幫助，最後玩的開心，開啟你的數據之旅吧！
原文傳送門
（本文經合作夥伴 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈入职一年后，一位算法工程师给初学者的一封信 〉。首圖來源：Daniel Bourke。）
更多關於機器學習的消息
衝上 GitHub 熱門第四名！Python 機器學習最強教學資源，新手工程師快存起來
和 Google 頂尖工程師一起研究機器學習一整年，這是我的精華筆記
工程師挑戰機器學習極限，用 CoreML 成功把 AI 塞進一台 iPhone 裡！
我們正在找夥伴！
![]()
2019 年我們的團隊正在大舉擴張，需要你的加入跟我們一起找出台灣創新原動力！
我們正在徵
《採訪社群編輯》、《助理編輯》，詳細職缺與應徵辦法
請點我
i5-8265U 處理器與 1.6GHz 四核心處理器，記憶體 8GB，但跑起來卡卡的，不是很順。或許要高階的電腦才可以順暢運作，一般的電腦反而會被拖慢速度。
我是一名物理工程師，對目前的工作不那麼感興趣，甚至有點想回學校稍微逃避下現實和責任。
