一位機器學習工程師的獨白：影響你未來職業生涯的 12 件小事

雷鋒網 AI 科技評論按：如果未來的你將踏上機器學習工程師這條道路，那你很大可能將遇到和機器學習工程師 Daniel Bourke 相似的經歷。在這一年的機器學習相關工作中，他發現很多事情都和想像的不同，有些事情也許看似沒有意義，卻價值無窮。

於是，他將這些經歷與感悟總結起來，寫成了下面這篇文章。雷鋒網 AI 科技評論將其編譯如下，相信這些經歷與建議也會給未來將踏入 AI 行業的你帶來很大的啟發。

工作站，家庭辦公室和藝術工作室（照片由作者提供）

引入

實際上，機器學習和數據科學領域所涉及的工作並非想像那麼單一；相反的是，它所涵蓋的內容非常廣泛。往往一位數據科學家所做的與另一位會有很大的不同。機器學習工程師也是如此，只有在使用歷史（數據）來理解或預測未來（建模）這方面比較相似。

為了將這些要點展現在下文中，我首先解釋一下我工作中所擔任的角色。我們有一個小機器學習諮詢團隊，其中的內容包含了從數據收集到操作、模型構建再到能想到的每個行業的服務部署，所以我們每個人都扮演著多種角色。

作者?Daniel Bourke?的社交動態

工作日常

早上 9 點我走進辦公室，問候大家早安，然後把食物放在冰箱里，倒一杯咖啡，走到我的辦公桌前坐下，看前一天的筆記，順便打開 Slack ，閱讀消息以及團隊共享論文或博客文章的鏈接。這個領域發展很迅速，因此每天都有一些新文章。

所以通常在讀完未讀消息後，我會花一陣時間來瀏覽論文和博客文章，並仔細研究那些理解起來較困難的內容。這其中，有一些內容可能對我正在做的工作有所幫助。

關於閱讀時長：一般來說，閱讀會花費我大概一個小時甚至更久，這取決於文章本身。有些朋友會疑惑為什麼我在閱讀上花費這麼久的時間。但在我看來，閱讀是一種終極元技能。因為一旦有更好的方式來完成我當前在做的事情，我可以通過學習並使用它，從而節約更多的時間和精力。但閱讀也有特殊情況，如果有一個項目的截止日期臨近，那麼我將把閱讀時間縮短來推進該項目。

然後我會檢查前一天的工作，檢查我的記事本所記下的被擱置的工作，這是每天最重要的一部分。

我的記事本是當天的流動日記，例如：「我已經將數據處理為正確格式，現在需要在模型中運行它。我將訓練的啟動變得迅捷，當程序完成後就馬上進行訓練。」如果我在工作過程中遇到了困難，則會寫下類似於：「發生了數據不匹配的情況，接下來我將嘗試修復混合匹配，並在嘗試新模型之前獲得基線。」

然後到下午 4 點，我會開始整理今天的工作，包括：整理寫下的混亂代碼，使其清晰明了，然後添加註釋，最後將它們進行更好的組合。因為我常常會想，如果其他人不得不讀這個怎麼辦？而剛好通常閱讀這個代碼的人就是我自己，我還經常會在短時間內忘記一連串的思路......

下午 5 點時分，我的代碼已經被更新在 GitHub 上了，然後我就會在筆記本上記下第二天要做的事情。

這是理想的一天，但並非每一天都如此。有時我也可能在下午 4:37 時，突然產生一個新穎的想法，然後去嘗試完成它。

現在你已經大致了解機器學習工程師日復一日的工作日常了，接下來我將具體闡述在工作中所學到的一些關於機器學習的經驗與教訓。（希望對你有幫助~）

從機器學習工程師中學到的12件事

1. 機器學習始終與數據有關

很多時候，機器學習工程師會專註於構建更好的模型，而不是改進構建它的數據。儘管構建更大的模型並使用更強的計算能力可以提供令人興奮的短期結果；但是只在意眼前，你最終會在長期目標上栽跟頭。

首次接觸一個項目時，請花費大量「不正常」的時間去熟悉數據。我這裡說的「不正常」，通常是你預估時間的三倍。但從長遠來看，這將節省你的時間。

這並不意味著你不應該從細節著手，因為對於任何新數據集，你首先應該明確的目標是成為這方面的「專家」。檢查分布、找到不同類型的特徵、異常值在哪兒、為什麼它們是異常值……如果你無法講出當前使用的數據信息，那又怎麼讓模型更好的處理這些數據呢？

探索性數據分析生命周期的示例，更多關於探索性數據分析的詳細介紹（https://towardsdatascience.com/a-gentle-introduction-to-exploratory-data-analysis-f11d843b8184）

2. 溝通問題比技術問題困難

我遇到的大多數主要障礙都不是技術性的，而是溝通問題。當然也總是存在技術挑戰，不過我認為這是工程師自身理應解決的難題。

永遠不要低估內部和外部溝通的重要性，沒有什麼比解決「錯誤」的技術挑戰更糟的了。這個「錯誤」是怎麼發生的呢？

從外部來看，這並不是客戶所追求的與機器學習提供的東西不匹配，而是們可以提供的東西與客戶需求不匹配；而在內部，因為很多人都有多項工作內容，所以很難確保每個人都能將整個項目很好的整合起來。

外部問題如何解決？答案就是：下到基層。你的客戶是否了解你可以提供的服務？你了解你的客戶的問題嗎？他們是否了解機器學習可以提供什麼以及它不能提供什麼？怎樣更有效的傳達你的想法？

而對於內部問題，根據嘗試解決問題的軟體工具數量，你就能大概判斷出內部通信有多難：Asana，Jira，Trello，Slack，Basecamp，Monday，Microsoft Teams。我找到的最有效的方法之一是在一天結束時，每個人在相關項目頻道中進行簡單的工作內容更新。更新內容包括：3-4 個工作重點、我做了什麼、為什麼，以及根據以上內容我接下來要做什麼。這個方法完美嗎？並不，但似乎很有效。它給了我一個機會來反思我做了什麼和我想從大家那裡得到的建議與意見。

無論你是多麼優秀的工程師，你維護產品的能力和獲得新業務的能力都與你溝通技巧以及這些溝通所帶給你的益處息息相關。

3. 通常來講，穩定性優於最先進的技術

現在有一個自然語言問題：將文本分類到不同的類別，目標是讓用戶將一段文本發送到服務並將其自動分類為兩個類別之一；如果模型對當前問題把握不準，那麼將文本傳遞給人類進行分類；每天的負載約為 1000-3000 個請求，標準規模大小。

儘管 BERT（https://github.com/google-research/bert）這一年一直很火，但如果在這個任務中我們不用谷歌的大規模計算，而採用 BERT 訓練模型來做的話，我們需要的東西需要改動很多內容，而且這還是在投入生產之前需要進行的工作。

相反，我們使用了另一種方法 ULMFiT，儘管它不是最先進的，但仍然能夠產生期望的結果，並且使用起來更容易。

作者語錄：「Shipping something which works provides far more value than sitting on something you』re trying to push to perfection.」

4. 機器學習中的兩個鴻溝

將機器學習運用到實踐中存在兩個鴻溝。一個是從課程工作到項目工作的鴻溝，另一個是從筆記本中的模型到生產模型（模型部署）之間的鴻溝。

互聯網搜索機器學習課程會返回大量的內容結果，我用了很多來完成自己的 AI 碩士學位（https://hackernoon.com/my-self-created-ai-masters-degree-ddc7aae92d0e ）。

但即使在學完了許多最好的課程後，當我開始擔任機器學習工程師時，我的技能仍然是建立在課程的結構化主幹上；但在實際工作中，項目並非按照課程那樣安排得井井有條。

我缺乏一些具體的知識，而這些知識並不能從課程中得到。例如：如何質疑數據？需要探索什麼數據？需要利用什麼數據？

那麼如何修正這個問題呢？我很幸運能夠成為澳大利亞最優秀的人才，但我也願意學習並願意做錯。錯誤當然不是目標；但為了正確，你必須弄清楚什麼是錯的。如果你正在通過一門課程學習機器學習，那麼繼續學習這門課程，但你需要通過在自己的項目上工作，把你正在學習的東西放到實踐中，用特定的知識武裝你自己。

作者語錄：「Specific knowledge: skills which can』t be taught in a course but can be learned.」

至於如何進行部署，在這點上我仍然做得不夠好，但我注意到了一種趨勢，即機器學習工程和軟體工程正在融合。通過像 Seldon，Kubeflow 和 Kubernetes 這樣的服務，很快機器學習將成為堆棧的另一部分。在 Jupyter 筆記本中構建模型是一回事，但是如何讓數千甚至數百萬人使用該模型呢？根據最近在 Cloud Native 活動上的討論情況來看，似乎大公司以外的人都不知道如何做到這一點。

5. 20％的時間

我們有一個規則——20％的時間。這意味著我們 20％的時間都會花在學習上。這裡指的學習非常廣泛，只要是機器學習相關的都屬於學習範疇，並且我們身邊能夠找到有很多這樣的知識。

事實證明，這不僅僅是寶貴的，BERT 的 ULMFiT 使用時間也是 20％。20％的時間同時意味其餘 80％將用於核心項目，即80％將用於核心產品（機器學習專業領域），20％用於與核心產品相關的新事物。

它並不總是需要分得這樣清楚，但這樣的分配是一個很好的目標。如果你的業務優勢在於現在所做的最好，那麼未來的業務則取決於你繼續做最擅長的事情，也就是不斷學習所得。

6. 閱讀十分之一的論文，並採用更少數量的論文

你無法跟上每一個新的突破，但可以在獲得基本原則的堅實基礎下應用它們。這些基礎經受住了時間的考驗，新突破也是基於這些基本原則實現了突破。

接下來是探索與開發問題。

7. 成為你自己最大的質疑者

探索與開發問題是嘗試新事物和重新應用已經發揮作用事物之間的兩難選擇，但是你可以通過成為自己最大的質疑者來處理探索與開發問題。

探索——通常來講，運行已經使用的模型並獲得高精度數字是一件很容易的事情，然後我們會將其作為新基準報告給團隊。但是如果你得到了一個更好的結果，記得返回檢查你的工作，並再次讓你的團隊這樣做。因為你是一名工程師兼科學家，時刻需要嚴謹。

開發——20％的時間花費在開發上是有幫助的，但如果你是在核心產品上花費 70％，在這個產品的二次開發上再花費 20％，而在 moonshots（可能短期之間不會起作用的事情）上花費 10％，這樣 70/20/10 的時間分配可能會更好。儘管我從來沒有在工作中刻意這樣安排，但這是我努力的方向。

8.「玩具問題」非常有效

特別是在為了幫助理解一個新概念、建立一些小事、數據集中的相關或者不相關一部分等問題上，將這些問題縮小到一個更小的「玩具問題」，是一個很有效的處理方法。

在一個小團隊中，處理問題的訣竅是先讓事情有效，然後再進行快速迭代。

9. 橡皮鴨

如果遇到問題，你坐下來盯著代碼可能會解決問題，也有可能不會。相反，與同事探討一下，假裝他們是你的橡皮鴨，可能事情會很容易解決，比如：

「Ron，我正在嘗試遍歷這個數組並跟蹤它的狀態，同時循環訪問另一個數組並跟蹤狀態，然後我想將這些狀態組合成一個元組列表。」

「循環中的循環？你為什麼不把它矢量化呢？」

「我能這樣做嗎？」

「讓我們來看看。」

10. 從頭開始構建的模型數量正在下降（或者至少你不需要開始重新構建）

這和機器學習工程與軟體工程的融合有關。除非你的數據問題非常具體，否則許多主要問題非常相似，比如：分類、回歸、時間序列預測、建議。

這意味著了解數據科學和機器學習的基本原理仍然是我們所需要做的，但是知道如何將它們應用到實際問題中則更有價值。

11. 數學還是代碼？

對於我所處理的客戶問題，我們都是代碼優先。所有的機器學習和數據科學代碼都是 Python。有時我會通過閱讀論文並復現它來學習數學，但 99.9％的情況下，現有的框架都包含了數學。

這並不是說數學是不必要的，畢竟機器學習和深度學習都是應用數學的形式。掌握最小矩陣操作、一些線性代數和微積分，特別是鏈式法則（https://www.khanacademy.org/math/ap-calculus-ab/ab-differentiation-2-new/ab-3-1a/v/chain-rule-introduction ）足以成為一名工程開發者。

請一定要記住，我們的目標不是發明一種新的機器學習演算法，而是向客戶展示潛在的機器學習對他們的業務有（或沒有）幫助。

12. 你去年所做的工作明年可能會無效

這是一定的，因為軟體工程和機器學習工程的融合，這種情況正在變得越來越明顯。

但這正是你進入這個行業的原因。框架將發生變化，圖書館將發生變化，什麼會保持不變？基礎統計數據、概率、數學，這些事情都沒有過期日期。所以，最大的挑戰仍然是：如何應用它們。

結語

作者還有更多的經驗與建議分享，但你如果能夠消化這 12 條，已經足夠用很久了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！