轉行如何開啟機器學習之旅？

作為一個轉行的人，自然要介紹一下自己的專業背景。筆者在本科的時候的專業是數學與應用數學，外行人可以理解為基礎數學。在博士期間的研究方向是動力系統和分形幾何，所做的還是基礎數學，和計算機的關係不大。

如果有人想了解筆者究竟在做什麼科研的話，可以參考知乎文章：

復動力系統（1）--- Fatou集與Julia集

連結：https://zhuanlan.zhihu.com/p/30952328

至於機器學習的話，在讀書期間基本上也沒接觸過，甚至沒聽說過還有這種東西。不過在讀書期間由於專業需要，C++ 之類的程式碼還是能夠寫一些的，在 UVA OJ 上面也留下過自己的足跡。

行路難，行路難，多歧路，今安在？

在 2015 年畢業之後機緣巧合，恰好進入騰訊公司從事機器學習的相關工作。不過剛進來的時候壓力也不小，現在回想起來的話，當時走了一些不該走的彎路。用李白的《行路難》中的詩詞來描述當時的心情就是“行路難，行路難，多歧路，今安在？”

在 2015 年 10 月份，第一次接觸到一個不大不小的專案，那就是 XX 推薦專案。而這個專案是當時組內所接到的第二個推薦專案，當年的推薦系統還是搭建在大資料叢集上的，完全沒有任何說明文件和前端頁面，當時的整個系統和全部流程複雜而繁瑣。不過在接觸這個系統的過程中，逐步開始學習了 Linux 作業系統的一些簡單命令，SQL 的使用方法。

瞭解 SQL 的話其實不只是通過了這個系統，通過當時的 ADS 值班，幫助業務方提取資料，也把 SQL 的基礎知識進一步的加深了。SQL 的學習的話，在2015年讀過兩本非常不錯的入門教材《SQL基礎教程》與《HIVE程式設計指南》。Linux 的相關內容閱讀了《Linux 命令列與 Shell 指令碼程式設計大全》之後也就大概有所瞭解了。於是工作了一段時間之後，為了總結一些常見的 SQL 演算法，寫過一篇文章 "HIVE基礎介紹"。

在做推薦專案的過程中，除了要使用 SQL 來處理資料，要想做機器學習，還需要了解常見的機器學習演算法。當年接觸到的第一個機器學習演算法就是邏輯迴歸（Logistic Regression），既然提到了機器學習的邏輯迴歸，無法避免的就是交叉驗證的概念，這個是機器學習中的一個基本概念。

通過物品的類別屬性和使用者的基本特徵來構造出新的特徵，例如特徵的內積（inner product）。後來在學習的過程中逐步新增了特徵的外積和笛卡爾積，除了特徵的交叉之外，還有很多的方法來構造特徵，例如把特徵標準化，歸一化，離散化，二值化等操作。除了構造特徵之外，如何判斷特徵的重要性則是一個非常關鍵的問題。

最常見的方法就是檢視訓練好的模型的權重，另外還可以使用 Pearson 相關係數和 KL 散度等數學工具來粗糙的判斷特徵是否有效。在此期間也寫過一些文章“交叉驗證”，“特徵工程簡介”，“KL散度”。關於特徵工程，除了閱讀一些必要的書籍之外，最重要的還是要實踐，只有實踐才能夠讓自己的經驗更加豐富。

在做推薦系統的時候，之前都是通過邏輯迴歸演算法（Logistic Regression）離線地把模型的權重算好，然後匯入線上系統，再進行實時的計算和打分。除了離線的演算法之外，在 2015 年的 12 月份瞭解到了能夠線上學習的 FTRL 演算法。調研了之後在 2016 年初在組內進行了分享，同時在zr9558.com 上面分享了自己的總結。

在做 XX 推薦專案的過程中，瞭解到了資料才是整個機器學習專案的基石，如果資料的質量不佳，那就需要進行資料的預處理，甚至推動開發人員去解決資料上報的問題。

通常來說，要想做好一個推薦專案，除了特徵工程和演算法之外，最重要的就是資料的核對。當時的經驗是需要核對多方的資料，那就是演算法離線計算出來的結果，線上計算出來的結果，真實產品中所展示的結果這三方的資料必須要完全一致，一旦不一致，就需要覆盤核查，而不是繼續推進專案。在此期間，踩過無數的資料的坑，因此得到的經驗就是一定要反覆的核查資料。

站在巨人的肩膀上，才能看得更遠。-—學習推薦系統

“站在巨人的肩膀上，才能看得更遠。”到了 2016 年的 2 月份，除了 XX 推薦專案的首頁個性化調優演算法之外，還開啟了另外一個小專案，嘗試開啟首頁的 tab，那就是針對不同的使用者推薦不同的物品。這個小專案簡單一點的做法就是使用 ItemCF 或者熱傳導傳播的演算法，在使用者收聽過某個節目之後，就給使用者推薦相似的節目。

這種場景其實在工業界早就有了成功的案例，也不算是一個新的場景。就好比與使用者在某電商網站上看中了某本書，然後就被推薦了其他的相關書籍。之前也寫過一篇推薦系統的簡單演算法“物質擴散演算法”，推薦給大家參考一下。至於 ItemCF 和熱傳導演算法的相關內容，會在後續的 Blog 中持續完善。

“讀書千遍，其義自見。”在使用整個推薦系統的過程中，筆者只是大概知道了整個系統是如何搭建而成的。而要整體的瞭解機器學習的相關演算法，光做專案則是遠遠不夠的。在做推薦業務的這段時間，周志華老師的教材《機器學習》在2016年初上市，於是花了一些時間來閱讀這本書籍。但是個人感覺這本書難度不大，只是需要另外一本書結合著看才能夠體會其中的精妙之處，那就是《機器學習實戰》。在《機器學習實戰》中，不僅有機器學習相關演算法的原理描述，還有詳細的原始碼，這足以讓每一個初學者從新手到入門了。

路漫漫其修遠兮，吾將上下而求索。

說到從零到一，其實指的是在這一年體驗瞭如何從零到一地做一個新業務。到了 2016 年的時候，為了把機器學習引入業務安全領域，在部門內部成立了 XX 專案組，這個專案在部門內部其實並沒有做過大規模的嘗試，也並沒有成功的經驗，甚至也沒有一個合適的系統讓人使用，而且安全業務和推薦業務基本上不是一回事。

因為對於推薦系統而言，給使用者的推薦是否準確決定了 CTR 是否達標，但是對於安全系統而言，要想上線打擊黑產的話，準確率則需要 99% 以上才行。之前的推薦系統用得最多的演算法就是邏輯迴歸，而且會儲存物品和使用者的兩類特徵，其餘的演算法主要還是 ItemCF 和熱傳導演算法。這就導致了當時做 XX 專案的時候，之前的技術方案並不可用，需要基於業務安全的實際場景來重新搭建一套框架體系。

但是當時做安全專案的時候並沒有實際的業務經驗，而且暫定的計劃是基於 XX1 和 XX2 兩個業務來進行試點機器學習。為了做好這個專案，一開始筆者調研了幾家號稱做機器學習+安全的初創公司，其中調研的最多的就是 XX 這家公司，因為他們家發表了一篇文章，裡面介紹了機器學習如何應用在業務安全上，那就是搭建一套無監督+有監督+人工打標籤的對抗體系。

筆者還是總結了當時兩三個月所學的異常點檢測演算法，文章如下：

• 異常點監測演算法（一）

• 異常點檢測演算法（二）

• 異常點檢測演算法（三）

• 異常點檢測演算法綜述

在 2016 年底的時候，說起來也是機緣巧合，有的同事看到了我在 2016 年 11 月份發表的文章，就來找筆者探討了一下如何構建遊戲 AI。當時筆者對遊戲AI的應用場景幾乎不瞭解，只知道 DeepMind 做出了 AlphaGo，在 2013 年使用了深度神經網路玩 Atari 遊戲。在12月份花費了一定的時間研究了強化學習和深度學習，也搭建過簡單的 DQN 網路進行強化學習的訓練。

通過幾次的接觸和交流之後總算 2017 年 1 月份做出一個簡單的遊戲 AI，通過機器學習也能夠進行遊戲 AI 的自主學習。雖然不在遊戲部門，但是通過這件事情，筆者對遊戲 AI 也產生了濃厚的興趣，撰寫過兩篇文章“強化學習與泛函分析”，“深度學習與強化學習”。

在做日常專案的同時，在 2017 年也接觸量子計算。在後續幾個月的工作中，持續調研了量子計算的基礎知識，一些量子機器學習的技術方案，寫了兩篇文章“量子計算（一）”，“量子計算（二）”介紹了量子計算的基礎概念和技巧。

三十功名塵與土，八千里路雲和月。

提到再整旗鼓，其實指的是在 2017 年再次從零到一的做全新的專案。到了 2017 年 7 月份，隨著業務安全的機器學習框架已經逐漸完善，XX 專案也快走到了尾聲，於是就又有了新的專案到了自己的手裡，那就是織雲智慧運維專案。運營中心這邊還在探索和起步階段，業界的智慧運維（AIOPS）的提出也是在2017年才逐步開始，那就是從手工運維，自動化運維，逐步走向人工智慧運維的階段，也就是所謂的 AIOPS。只有這樣，運營中心才有可能實現真正的咖啡運維階段。

正式接觸到運維專案是 2017 年 8 月份，從跟業務運維同學的溝通情況來看，當時有幾個業務的痛點和難點。例如：織雲Monitor 時間序列的異常檢測，哈勃的根因分析，織雲ROOT 系統的根源分析，故障排查，成本優化等專案。在 AIOPS 人員短缺，並且學術界並不怎麼研究這類技術方案的前提下，如何在運維中開展機器學習那就是一個巨大的難題。

就像當年有神盾系統，無論怎麼做都可以輕鬆的接入其餘推薦業務，並且也有相對成熟的內部經驗，學術界和工業界都有無數成功的案例。但是智慧運維這一塊，在 2017 年才被推廣出來，之前都是手工運維和 DevOps 的一些內容。於是，如何儘快搭建一套能夠在部門內使用的智慧運維體系就成了一個巨大的挑戰。面臨的難題基本上有以下幾點：

• 歷史包袱沉重

• AIOPS 人員短缺

• 沒有成熟的系統框架

在這種情況下，外部引進技術是不可能了，只能夠靠自研，合作的同事主要是業務運維和運營開發。當時第一個接觸的智慧運維專案就是哈勃的多維下鑽分析，其業務場景就是一旦發現了成功率等指標下跌之後，需要從多維的指標中精準的發現異常，例如從運營商，省份，手機等指標中發現導致成功率下跌的原因，這就是經典的根因分析。這一塊在調研之後發現，主要幾篇文章可以參考，綜合考慮了之後撰寫了一份資料，那就是“根因分析的探索”。

PS：除了哈勃多維下鑽之外，個人感覺在 BI 智慧商業分析中，其實也可以是這類方法來智慧的發現“為什麼DAU下跌？”“為什麼收入沒有達到預期”等問題。

除了哈勃多維下鑽之外，織雲Monitor 的時間序列異常檢測演算法則是更為棘手的專案。之前的 Monitor 異常檢測演算法，就是靠開發人員根據曲線的特點設定三個閾值（最大值，最小值，波動率）來進行異常檢測。這樣的結果就是準確率不準，覆蓋率不夠，人力成本巨大。

在上百萬條曲線都需要進行異常檢測的時候，每一條曲線都需要人工配置閾值是完全不合理的。於是，導致的結果就是每週都需要有人值班，有了問題還不一定能夠及時發現。而對於時間序列演算法，大家通常能夠想到的就是 ARIMA 演算法，深度學習的 RNN 與 LSTM 演算法，Facebook 近期開源的 Prophet 工具。這些方法筆者都調研過，並且未來會撰寫相關的文章介紹 ARIMA，RNN，Prophet 的使用，歡迎大家交流。

其實以上的幾種時間序列預測和異常檢測演算法，主要還是基於單條時間序列來做的，而且基本上是針對那些比較平穩，具有歷史規律的時間序列來進行操作的。如果針對每一條曲線都單獨搭建一個時間序列模型的話，那和閾值檢測沒有任何的區別，人力成本依舊巨大。而且在織雲Monitor的實際場景下，這些時間序列異常檢測模型都有著自身的缺陷，無法做到“百萬條KPI曲線一人挑”的效果。

於是在經歷了很多調研之後，我們創新性地提出了一個技術方案，成功的做到了“百萬條曲線”的異常檢測就用幾個模型搞定。那就是無監督學習的方案加上有監督學習的方案，第一層我們使用無監督演算法過濾掉大部分的異常，第二層我們使用了有監督的演算法來提升準確率和召回率。

在時間序列異常檢測的各類演算法中，通常的論文裡面都是針對某一類時間序列，使用某一類模型，效果可以達到最優。但是在我們的應用場景下，見過的曲線千奇百怪，筆者都說不清楚有多少曲線的形狀，因此只用某一類時間序列的模型是絕對不可取的。

但是，在學習機器學習的過程中，有一種整合學習的辦法，那就是把多個模型的結果作為特徵，使用這些特徵來訓練一個較為通用的模型，從而對所有的 織雲Monitor 時間序列進行異常檢測。這一類方法筆者總結過，那就是“時間序列簡介（一）”，最終我們做到了“百萬條曲線一人挑”，成功去掉了制定閾值的業務效果。

亦餘心之所善兮，雖九死其猶未悔。

在轉行的過程中，筆者也走過彎路，體會過排查資料問題所帶來的痛苦，經歷過業務指標達成所帶來的喜悅，感受過如何從零到一搭建一套系統。在此撰寫一篇文章來記錄筆者這兩年多的成長經歷，希望能夠盡微薄之力幫助到那些有志向轉行來做機器學習的人。從這兩年做專案的經歷來看，要想從零到一地做好專案，在一開始就必須要有一個好的規劃，然後一步一步的根據專案的進展調整前進的方向。但是如果沒有一個足夠的知識積累，就很難找到合適的前進方向。

“亦餘心之所善兮，雖九死其猶未悔。”在某些時候會有人為了短期的利益而放棄了一個長遠的目標，但是如果要讓自己走得更遠，最佳的方案是讓自己和團隊一起成長，最好的是大家都擁有一個長遠的目標，不能因為一些微小的波動而放任自己。同時，如果團隊或個人急於求成，往往會導致失敗，而堅持不懈的學習則是做科研和開展工作的不二法門。

詩人陸游曾經教育過他的後輩：“汝果欲學詩，功夫在詩外”。意思是說，如果你想真正地寫出好的詩詞，就要在生活上下功夫，去體驗生活的酸甜苦辣，而不是抱著一本詩詞歌賦來反覆閱讀。

如果看過天龍八部的人就知道，鳩摩智當時上少林寺去挑戰，在少林高僧面前展示出自己所學的少林七十二絕技，諸多少林高僧無不大驚失色。而當時的虛竹在旁邊觀戰，就對少林高僧們說：“鳩摩智所耍的招數雖然是少林絕技，但是本質上卻是使用小無相功催動出來的。雖然招數相同，但是卻用的道家的內力。”為什麼少林的高僧們沒有看出來鳩摩智武功的關鍵之處呢，那是因為少林高僧們在練功的時候，一直抱著武學祕籍在修煉，一輩子練到頭了也就13門絕技。

其實從鳩摩智的個人修煉來看，修練武學的關鍵並不在武學祕籍裡。沒有找到關鍵的佛經，沒有找到運功的法門，無論抱著武學祕籍修煉多少年，終究與別人有著本質上的差距。

筆者在 SNG 社交網路運營部的這兩年多，用過推薦專案，做過安全專案，正在做運維專案，也算是部門內唯一一個（不知道是否準確）做過三種專案的人，使用過推薦系統，從零到一搭建過兩個系統。目前筆者的個人興趣集中在 AIOPS 這個場景下，因為筆者相信在業務運維這個傳統領域，機器學習一定有著自己的用武之地。相信在不久的將來，AIOPS 將會在運維上面的各個場景落地，真正的走向咖啡運維。