0
雷鋒網 AI 科技評論按：如果未來的你將踏上機器學習工程師這條道路，那你很大可能將遇到和機器學習工程師 Daniel Bourke 相似的經歷。在這一年的機器學習相關工作中，他發(fā)現很多事情都和想象的不同，有些事情也許看似沒有意義，卻價值無窮。
于是，他將這些經歷與感悟總結起來，寫成了下面這篇文章。雷鋒網 AI 科技評論將其編譯如下，相信這些經歷與建議也會給未來將踏入 AI 行業(yè)的你帶來很大的啟發(fā)。
工作站，家庭辦公室和藝術工作室（照片由作者提供）
實際上，機器學習和數據科學領域所涉及的工作并非想象那么單一；相反的是，它所涵蓋的內容非常廣泛。往往一位數據科學家所做的與另一位會有很大的不同。機器學習工程師也是如此，只有在使用歷史（數據）來理解或預測未來（建模）這方面比較相似。
為了將這些要點展現在下文中，我首先解釋一下我工作中所擔任的角色。我們有一個小機器學習咨詢團隊，其中的內容包含了從數據收集到操作、模型構建再到能想到的每個行業(yè)的服務部署，所以我們每個人都扮演著多種角色。
作者 Daniel Bourke 的社交動態(tài)
早上 9 點我走進辦公室，問候大家早安，然后把食物放在冰箱里，倒一杯咖啡，走到我的辦公桌前坐下，看前一天的筆記，順便打開 Slack ，閱讀消息以及團隊共享論文或博客文章的鏈接。這個領域發(fā)展很迅速，因此每天都有一些新文章。
所以通常在讀完未讀消息后，我會花一陣時間來瀏覽論文和博客文章，并仔細研究那些理解起來較困難的內容。這其中，有一些內容可能對我正在做的工作有所幫助。
關于閱讀時長：一般來說，閱讀會花費我大概一個小時甚至更久，這取決于文章本身。有些朋友會疑惑為什么我在閱讀上花費這么久的時間。但在我看來，閱讀是一種終極元技能。因為一旦有更好的方式來完成我當前在做的事情，我可以通過學習并使用它，從而節(jié)約更多的時間和精力。但閱讀也有特殊情況，如果有一個項目的截止日期臨近，那么我將把閱讀時間縮短來推進該項目。
然后我會檢查前一天的工作，檢查我的記事本所記下的被擱置的工作，這是每天最重要的一部分。
我的記事本是當天的流動日記，例如：「我已經將數據處理為正確格式，現在需要在模型中運行它。我將訓練的啟動變得迅捷，當程序完成后就馬上進行訓練?！谷绻以诠ぷ鬟^程中遇到了困難，則會寫下類似于：「發(fā)生了數據不匹配的情況，接下來我將嘗試修復混合匹配，并在嘗試新模型之前獲得基線?！?/p>
然后到下午 4 點，我會開始整理今天的工作，包括：整理寫下的混亂代碼，使其清晰明了，然后添加注釋，最后將它們進行更好的組合。因為我常常會想，如果其他人不得不讀這個怎么辦？而剛好通常閱讀這個代碼的人就是我自己，我還經常會在短時間內忘記一連串的思路......
下午 5 點時分，我的代碼已經被更新在 GitHub 上了，然后我就會在筆記本上記下第二天要做的事情。
這是理想的一天，但并非每一天都如此。有時我也可能在下午 4:37 時，突然產生一個新穎的想法，然后去嘗試完成它。
現在你已經大致了解機器學習工程師日復一日的工作日常了，接下來我將具體闡述在工作中所學到的一些關于機器學習的經驗與教訓。（希望對你有幫助~）
1. 機器學習始終與數據有關
很多時候，機器學習工程師會專注于構建更好的模型，而不是改進構建它的數據。盡管構建更大的模型并使用更強的計算能力可以提供令人興奮的短期結果；但是只在意眼前，你最終會在長期目標上栽跟頭。
首次接觸一個項目時，請花費大量「不正?！沟臅r間去熟悉數據。我這里說的「不正常」，通常是你預估時間的三倍。但從長遠來看，這將節(jié)省你的時間。
這并不意味著你不應該從細節(jié)著手，因為對于任何新數據集，你首先應該明確的目標是成為這方面的「專家」。檢查分布、找到不同類型的特征、異常值在哪兒、為什么它們是異常值……如果你無法講出當前使用的數據信息，那又怎么讓模型更好的處理這些數據呢？
探索性數據分析生命周期的示例，更多關于探索性數據分析的詳細介紹（https://towardsdatascience.com/a-gentle-introduction-to-exploratory-data-analysis-f11d843b8184）
2. 溝通問題比技術問題困難
我遇到的大多數主要障礙都不是技術性的，而是溝通問題。當然也總是存在技術挑戰(zhàn)，不過我認為這是工程師自身理應解決的難題。
永遠不要低估內部和外部溝通的重要性，沒有什么比解決「錯誤」的技術挑戰(zhàn)更糟的了。這個「錯誤」是怎么發(fā)生的呢？
從外部來看，這并不是客戶所追求的與機器學習提供的東西不匹配，而是們可以提供的東西與客戶需求不匹配；而在內部，因為很多人都有多項工作內容，所以很難確保每個人都能將整個項目很好的整合起來。
外部問題如何解決？答案就是：下到基層。你的客戶是否了解你可以提供的服務？你了解你的客戶的問題嗎？他們是否了解機器學習可以提供什么以及它不能提供什么？怎樣更有效的傳達你的想法？
而對于內部問題，根據嘗試解決問題的軟件工具數量，你就能大概判斷出內部通信有多難：Asana，Jira，Trello，Slack，Basecamp，Monday，Microsoft Teams。我找到的最有效的方法之一是在一天結束時，每個人在相關項目頻道中進行簡單的工作內容更新。更新內容包括：3-4 個工作重點、我做了什么、為什么，以及根據以上內容我接下來要做什么。這個方法完美嗎？并不，但似乎很有效。它給了我一個機會來反思我做了什么和我想從大家那里得到的建議與意見。
無論你是多么優(yōu)秀的工程師，你維護產品的能力和獲得新業(yè)務的能力都與你溝通技巧以及這些溝通所帶給你的益處息息相關。
3. 通常來講，穩(wěn)定性優(yōu)于最先進的技術
現在有一個自然語言問題：將文本分類到不同的類別，目標是讓用戶將一段文本發(fā)送到服務并將其自動分類為兩個類別之一；如果模型對當前問題把握不準，那么將文本傳遞給人類進行分類；每天的負載約為 1000-3000 個請求，標準規(guī)模大小。
盡管 BERT（https://github.com/google-research/bert ）這一年一直很火，但如果在這個任務中我們不用谷歌的大規(guī)模計算，而采用 BERT 訓練模型來做的話，我們需要的東西需要改動很多內容，而且這還是在投入生產之前需要進行的工作。
相反，我們使用了另一種方法 ULMFiT，盡管它不是最先進的，但仍然能夠產生期望的結果，并且使用起來更容易。
作者語錄：「Shipping something which works provides far more value than sitting on something you』re trying to push to perfection.」
4. 機器學習中的兩個鴻溝
將機器學習運用到實踐中存在兩個鴻溝。一個是從課程工作到項目工作的鴻溝，另一個是從筆記本中的模型到生產模型（模型部署）之間的鴻溝。
互聯(lián)網搜索機器學習課程會返回大量的內容結果，我用了很多來完成自己的 AI 碩士學位（https://hackernoon.com/my-self-created-ai-masters-degree-ddc7aae92d0e ）。
但即使在學完了許多最好的課程后，當我開始擔任機器學習工程師時，我的技能仍然是建立在課程的結構化主干上；但在實際工作中，項目并非按照課程那樣安排得井井有條。
我缺乏一些具體的知識，而這些知識并不能從課程中得到。例如：如何質疑數據？需要探索什么數據？需要利用什么數據？
那么如何修正這個問題呢？我很幸運能夠成為澳大利亞最優(yōu)秀的人才，但我也愿意學習并愿意做錯。錯誤當然不是目標；但為了正確，你必須弄清楚什么是錯的。如果你正在通過一門課程學習機器學習，那么繼續(xù)學習這門課程，但你需要通過在自己的項目上工作，把你正在學習的東西放到實踐中，用特定的知識武裝你自己。
作者語錄：「Specific knowledge: skills which can』t be taught in a course but can be learned.」
至于如何進行部署，在這點上我仍然做得不夠好，但我注意到了一種趨勢，即機器學習工程和軟件工程正在融合。通過像 Seldon，Kubeflow 和 Kubernetes 這樣的服務，很快機器學習將成為堆棧的另一部分。在 Jupyter 筆記本中構建模型是一回事，但是如何讓數千甚至數百萬人使用該模型呢？根據最近在 Cloud Native 活動上的討論情況來看，似乎大公司以外的人都不知道如何做到這一點。
5. 20％的時間
我們有一個規(guī)則——20％的時間。這意味著我們 20％的時間都會花在學習上。這里指的學習非常廣泛，只要是機器學習相關的都屬于學習范疇，并且我們身邊能夠找到有很多這樣的知識。
事實證明，這不僅僅是寶貴的，BERT 的 ULMFiT 使用時間也是 20％。20％的時間同時意味其余 80％將用于核心項目，即80％將用于核心產品（機器學習專業(yè)領域），20％用于與核心產品相關的新事物。
它并不總是需要分得這樣清楚，但這樣的分配是一個很好的目標。如果你的業(yè)務優(yōu)勢在于現在所做的最好，那么未來的業(yè)務則取決于你繼續(xù)做最擅長的事情，也就是不斷學習所得。
6. 閱讀十分之一的論文，并采用更少數量的論文
這是一個粗略的數字。但探索任何數據集或現象，你很快就會發(fā)現這個規(guī)律隨處可見。這是 Zipf 定律（https://en.wikipedia.org/wiki/Zipf%27s_law ）或 Price 定律（https://en.wikipedia.org/wiki/Price%27s_model ）其中之一，換句話說，在每年數以千計的提交中，可能會有 10 篇開創(chuàng)性的論文；而在這 10 篇開創(chuàng)性的論文中，有 5 篇可能來自同一所研究所或個人。
你無法跟上每一個新的突破，但可以在獲得基本原則的堅實基礎下應用它們。這些基礎經受住了時間的考驗，新突破也是基于這些基本原則實現了突破。
接下來是探索與開發(fā)問題。
7. 成為你自己最大的質疑者
探索與開發(fā)問題是嘗試新事物和重新應用已經發(fā)揮作用事物之間的兩難選擇，但是你可以通過成為自己最大的質疑者來處理探索與開發(fā)問題。
探索——通常來講，運行已經使用的模型并獲得高精度數字是一件很容易的事情，然后我們會將其作為新基準報告給團隊。但是如果你得到了一個更好的結果，記得返回檢查你的工作，并再次讓你的團隊這樣做。因為你是一名工程師兼科學家，時刻需要嚴謹。
開發(fā)——20％的時間花費在開發(fā)上是有幫助的，但如果你是在核心產品上花費 70％，在這個產品的二次開發(fā)上再花費 20％，而在 moonshots（可能短期之間不會起作用的事情）上花費 10％，這樣 70/20/10 的時間分配可能會更好。盡管我從來沒有在工作中刻意這樣安排，但這是我努力的方向。
8.「玩具問題」非常有效
特別是在為了幫助理解一個新概念、建立一些小事、數據集中的相關或者不相關一部分等問題上，將這些問題縮小到一個更小的「玩具問題」，是一個很有效的處理方法。
在一個小團隊中，處理問題的訣竅是先讓事情有效，然后再進行快速迭代。
9. 橡皮鴨
如果遇到問題，你坐下來盯著代碼可能會解決問題，也有可能不會。相反，與同事探討一下，假裝他們是你的橡皮鴨，可能事情會很容易解決，比如：
「Ron，我正在嘗試遍歷這個數組并跟蹤它的狀態(tài)，同時循環(huán)訪問另一個數組并跟蹤狀態(tài)，然后我想將這些狀態(tài)組合成一個元組列表?！?/p>
「循環(huán)中的循環(huán)？你為什么不把它矢量化呢？」
「我能這樣做嗎？」
「讓我們來看看?！?/p>
10. 從頭開始構建的模型數量正在下降（或者至少你不需要開始重新構建）
這和機器學習工程與軟件工程的融合有關。除非你的數據問題非常具體，否則許多主要問題非常相似，比如：分類、回歸、時間序列預測、建議。
谷歌和微軟的 AutoML 等服務正在為每個可以上傳數據集并選擇目標變量的人提供世界一流的機器學習。而在開發(fā)人員方面，你有像 fast.ai（https://github.com/fastai/fastai ）這樣的庫，它們可以在幾行代碼中提供最先進的模型，以及各種模型動畫（一組預先構建的模型），如 PyTorch hub（https://pytorch.org/hub ）和 TensorFlow hub（https://www.tensorflow.org/hub ）提供相同的功能。
這意味著了解數據科學和機器學習的基本原理仍然是我們所需要做的，但是知道如何將它們應用到實際問題中則更有價值。
11. 數學還是代碼？
對于我所處理的客戶問題，我們都是代碼優(yōu)先。所有的機器學習和數據科學代碼都是 Python。有時我會通過閱讀論文并復現它來學習數學，但 99.9％的情況下，現有的框架都包含了數學。
這并不是說數學是不必要的，畢竟機器學習和深度學習都是應用數學的形式。掌握最小矩陣操作、一些線性代數和微積分，特別是鏈式法則（https://www.khanacademy.org/math/ap-calculus-ab/ab-differentiation-2-new/ab-3-1a/v/chain-rule-introduction ）足以成為一名工程開發(fā)者。
請一定要記住，我們的目標不是發(fā)明一種新的機器學習算法，而是向客戶展示潛在的機器學習對他們的業(yè)務有（或沒有）幫助。
12. 你去年所做的工作明年可能會無效
這是一定的，因為軟件工程和機器學習工程的融合，這種情況正在變得越來越明顯。
但這正是你進入這個行業(yè)的原因?？蚣軐l(fā)生變化，圖書館將發(fā)生變化，什么會保持不變？基礎統(tǒng)計數據、概率、數學，這些事情都沒有過期日期。所以，最大的挑戰(zhàn)仍然是：如何應用它們。
作者還有更多的經驗與建議分享，但你如果能夠消化這 12 條，已經足夠用很久了。
更多關于作者的信息，可以通過他的博客聯(lián)系他（https://mrdbourke.com/ ），也可以訂閱他的最新信息（https://mrdbourke.com/newsletter ）。
原文鏈接
雷鋒網 AI 科技評論 雷鋒網
雷峰網原創(chuàng)文章，未經授權禁止轉載。詳情見轉載須知。
