當你初入江湖，迷茫不知道該幹什麼的時候，不妨去模仿前人是如何進行科研的，並從中歸納出最適合自己的道路。為此，我們推出“學術人生”專欄，介紹科研的方法與經驗，為你的科研學習提供幫助，敬請關注。
歷史文章：人工智慧前沿學生論壇
來源：知乎—機智的叉燒
地址：https://zhuanlan.zhihu.com/p/453799404、https://zhuanlan.zhihu.com/p/453799805、https://zhuanlan.zhihu.com/p/453800419
目錄：
模型策略篇。討論演算法方案的思考。
工作思路篇。工作思維，結果導向。
個人成長篇。如何讓自己更好地解決更多問題。
這次給大家介紹的是自己在解決特定演算法問題下的模型和策略思路上的經驗。
01
模型策略篇
從模型套用到方案設計：模型的套用和調參是不能解決所有問題的。
從單一指標到綜合效果：最佳化不能只盯著一成不變的指標。
從實現本身到可拓展性：開拓思路，思考戰勝更多問題的方法。
預警，有些東西可能比較扎心，說的是我自己的經歷，大家有則改之無則加勉。
從模型套用到方案設計
在我剛學習機器學習的時候（大概是16、17年的時候吧），躊躇滿志，自以為拿到一把屠龍寶刀，自然是想霍霍一下，找到一個問題，開始張羅準備資料，然後就開始整分類了，本以為效果非常好結果不行，手足無措的我開始了效果調優（當時寫的還是py2）：
X_train, X_test, y_train, y_test = train_test_split(textVectorList, YUse, test_size=0.33, random_state=10)
maxDepthArrary=[10,20,30,40,50,80,100]
nEstimatorsArrary=[10,50,100,300,500]
learningRateArrary=[0.2,0.4,0.6,0.8,1,1.2,1.4,1.6,1.8,2.0]
paraResult=[]
startAllTime = datetime.datetime.now()
for maxDepth in maxDepthArrary:
for nEstimators in nEstimatorsArrary:
for learningRate in learningRateArrary:
startTime = datetime.datetime.now()
print 'maxDepth:'+str(maxDepth)+',nEstimators:'+str(nEstimators)+',learningRate:'+str(learningRate)
clf = AdaBoostClassifier(DecisionTreeClassifier(max_depth=maxDepth),
algorithm="SAMME",
n_estimators=nEstimators, learning_rate=learningRate)
clf.fit(X_train, y_train)
score=clf.score(X_test,y_test)
print '計算精度：'+str(score)
paraResultItem={}
paraResultItem['maxDepth']=maxDepth
paraResultItem['nEstimators']=nEstimators
paraResultItem['learningRate']=learningRate
paraResultItem['score']=score
paraResult.append(paraResultItem)
endTime = datetime.datetime.now()
print endTime - startTime
print paraResult
endAllTime = datetime.datetime.now()
print endAllTime - startAllTime
print '程式真的結束了'
print '程式結束'沒錯，還是手動調參，非常暴力。
運氣好，找到一個比較不錯的調參結果，但問題是，後續可不是每次都這麼好運了。
這件事之後一直在反思一個點，就是這種調參到底是否健康合理，於是逐步走的方向是，挖掘問題、解決問題的道路，從而逐步擺脫“調參師”、“調包俠”的流程，這裡我要感謝很多工作中的導師，出於隱私的原因我這裡就不說名字了，懂得大家都懂。
那麼正確的方式是什麼呢，最簡單的就是讓自己的思路從使用特定方法來解決問題轉移到為了解決問題設計特定方案，這點能讓自己從模型本身跳出，把模型當做是自己解決問題的工具（這個在哲學上應該叫工具主義，不說對不對，至少這個思想更符合日常工作的需求），而不是我要去用這個模型。
舉個例子，收到一個需求，要做文字分類，那我就要去了解問題，例如看資料、看文件，充分了解資料後設計解決方案，來儘可能又好又快地解決問題，我們的目標就很明確，是一個特定的文字分類問題，深度學習也好，規則詞典也罷，我們要解決問題。
於是這裡會引申出一個比較關鍵的能力：自己手裡到底有多少方法。首先，方法不多，只知道上面的模型的話，是很難支援你為問題設計方案的，因為設計方案是一個選擇的過程，沒有足夠的方法知識支撐，何來選擇。其次，這個階段我們瞭解問題的核心是找方法，我們瞭解問題的方向其實就是套用方法的方向，自己手裡的方案是指導自己瞭解問題一個重要方向標，如果簡單規則這個方法你沒有掌握，你根本不會思考這個問題是不是一個規則就能解決。第三，方法的多少和質量決定了你能解決問題的程度，這個和集思廣益思路一致，多人想，自然更容易想到更好的方法，更多的方法支撐你是否能想到足夠好的方法。
所以，很多人問的一個問題：為什麼大家工作之後還要持續學習持續看論文，答案很明顯，就是擴充自己的知識面，以便解決更多更多複雜的問題，這個點放在很多領域都是正確的。
回到小標題本身，大家在成長的過程中，要逐步從模型套用解脫出來，不糾結於模型本身，考慮問題的解決方法，你會發現你成長了一大截。
扎心的話來了：如果給定一個問題，你張口就來一個方法，這時候記得反思自己是不是隻會這個方法。
從單一指標到綜合效果
指標是評價一個問題解決的重要手段，這點應該是毋庸置疑的，但是評價一個問題解決的手段能侷限在幾個指標裡，而是應該多看幾種甚至是為了觀測某些問題情況去設計一些自己需要的指標。
現在有1個病人，99個正常人，現在我手裡有一個判斷人是否得病的手段，結果是所有人都正常，我們很容易算出準確率是99%，明眼人很容易看出來這個99%裡面充滿了水分，因為病人壓根沒檢測出來，於是我們還要進一步設計一些指標來表達這個問題，於是我們設計了召回率，召回率顯示我們能找到的病人佔比為0%，於是輕鬆表達了這個問題。
這個問題的理解非常簡單，但是道理卻很深刻，我們需要明白的是，指標不是我們演算法的目標，而是一個表達問題的方法是，我們藉助指標來了解自己的問題現狀如何，從而保證我們達到目標，我們最終追求的其實是一個比較模糊的東西——“綜合效果”。
綜合效果是什麼？對於推薦系統，可能是使用者的點選率，停留時間等，對於對話系統，可以是需求的滿足率，可以是和使用者的平均多輪次數，可以是對話任務的完成率，我們是透過觀測這些指標，來判斷我們需要怎麼最佳化我們的方案，例如點選率高停留時間低，可能就要評估是不是要處理一下標題黨，點選率本身就不高，是不是因為推薦的東西使用者不喜歡等，最終，其實我們的綜合效果是各種維度指標的全面提升，當然這不容易，但確實我們各個領域演算法工程師所追求的。
另外需要討論的兩個關鍵點，是指標標準和評測集，這兩個點直接影響的是指標的表達能力，最終影響我們對問題的判斷。
首先是指標標準，舉個例子，文字分類，什麼叫做“天氣”意圖，我們需要有一個儘可能明確清晰的邊界去劃定什麼是天氣，或者什麼不是天氣，只有這個判斷清楚了，指標才可能正確，因此，這值得我們花費很多時間來保證這個點。
然後是評測集，由於大部分指標的計算來源於大量的資料，即評測集，因此在這裡談評測集，是希望大家關注評測集的數量、分佈、質量，這些方面的合理性才能支撐指標的準確，乃至對效果的評估。
因此回到問題，單一指標到綜合效果，我們作為一名演算法，雖然面向的是指標最佳化，但是我們最終希望得到的是綜合效果比較好，這要求我們把思路開啟，而又因為綜合效果是依賴各種指標來表現的，因此我們要關注指標的構成，關鍵就是指標標準和評測集。
科研可能會讓很多學生都關注於指標，指標的提升能帶來論文（真實），但實際應用中太關注於指標可能會把你帶到溝裡去。
從實現本身到可拓展性
開始我只是接受老師、領導給出的任務，這個任務往往比較明確，問題給到我，甚至把解決方案都告訴我了，然後按著寫程式碼就完事了，這個事情確實很簡單，一般按部就班的就能完成，但逐步發現，很多時候完成任務並不是任務本身，很多時候還包含了很多沒有在明面上。
- 程式碼是否具備可讀性和可拓展性。這是每一位工程師，不侷限於演算法工程師。
- 思考方案是否具備通用性，是否可以用比較穩定可靠的方式來完成相似的任務，一方面可以平臺化中臺化，另一方面對自己則是可以把一些演算法任務變成一個工程任務，提升效率降低風險，畢竟演算法本身的專案風險較高，一不小心效果出問題就會延期。
前者其實是比較基本的開發能力，寫程式碼，為了團隊合作，為了自己日後的維護，程式碼要規範，很多設計的細節需要考慮到：
- 命名、註釋是否具有可讀性。
- 函式意識，很多重用的、結構複雜的東西，需要構造成類，這個能力對於面向過程入門的python同學，是非常需要培養的。
- 工程服務的一些常見操作需要學習到，例如怎麼向外提供服務、怎麼熱更新、怎麼打日誌等。
- 服務效能的考慮，一些動不動上bert的同學，需要考慮這些問題哈~
至於後者，則是一個對解決問題更高的要求，就是你能不能想出一個類似問題都能解決的方案。
- 這一類的問題都具有什麼特點。
- 有沒有什麼能夠相似問題都用的模型、詞典。
- 在此基礎上，設計好構造指令碼，能快速完成。
不僅要學會打敗一個人的方法，還需要學習打敗一萬個人的方法。
小結
洋洋灑灑快3千字了（em...有一大部分是程式碼），是一些自己在演算法策略上的一些新的思路和總結，這些都有別於1年期、剛入門的自己，這些是思維的提升和覺醒是非常有利於真實能力的提升，模型固然是要學習提升，但是今天聊的種種其實都在告誡我們，不能侷限於模型，不能侷限於模型，不能侷限於模型。
02
工作思路篇
演算法工程師是職場內的崗位之一，從新人走來，自己是要負責或大或小的專案推進的，因此，如何在工作中保證自己的工作能正常推進將是不僅演算法需要掌握的必修課，所以在模型思路之外，特地安排了一期有關工作思路相關的討論。
從完成任務到解決問題
培養新人的其中一個思路是在基礎比較紮實的前提下，開始給新人一些簡單任務實踐，讓新人幹中學，我就是從這麼一個新人走過來的。
那麼，接受的這種任務，一般都是比較明確的，類似新手村任務，任務中會告訴你怎麼操作，教著你一步一步完成任務，但是隨著時間發展，你成長起來後分配給你的任務可能就沒有那麼多支援了，給到你手裡的可能就是一個問題，一個或模糊或清晰的問題，但是往往不能給到你什麼思路，這時候需要你自己去思考怎樣才能解決這個問題。
能到這個程度，一定情況說明老大是認可你的能力的，應該值得高興，但是要時刻有一些意識：
- 就是你手裡的方法不夠多的時候是無法解決問題的，我們不能沉迷與幾個baseline模型，不能說想幾條規則就完成，我們要持續去積累。
- 思路從模型本身開啟去，儘可能讓自己腦子裡有一個比較完整的解決方案，訓練的資料怎麼來，離線的模型怎麼訓，訓練完成後模型線上怎麼用，資料流怎麼流進來的，介面協議怎麼樣，自己能想的越完整越好，總有一刻獨當一面的時候你要解決這些所有大大小小的問題。
- 機器和模型都是死的，人是活的，上下游的溝通要自己嘗試去達成，不要等，主動負責起來。
從被動到主動
上面一點提到要把事情主動負責起來，需要展開說一下，這個非常重要。
從小大大，老師教知識，佈置作業，我們都是被動的接受，哪怕到了大學很多人都還是比較安分地完成任務就行，但是未來的日子可不能這樣，要是真的想把事情做好，想做自己想做的事，首先就是要主動，主動推進自己想做的事，無論是科研上需要自己主動閱讀論文，還是工作上主動學習，主動推進某一件事，當一件事情推進不太順利的時候，要自己主動找解決方案，找相關負責人，把這件事推進下去。
要主動，首先自己要明確問題和當前的難點，然後開始找解決方案，比較容易想到的是自己解決，但自己解決終究會有限制，例如技術上的難題、跨團隊溝通等，需要自己的老大或者其他團隊的大佬幫忙解決，此時自己要找到對應的人主動溝通，儘快推進處理，這種方式能更加有效地把事情搞定。
從學習到調研
大學以來，自己的學習更多是出於興趣，以及後續的一些可能面對的工作壓力，自己會去學習，看大量相關的技術文章，並且自由地開始進行嘗試，這可以說是一個有點壓力但還算輕鬆愉快的過程。
到了工作後，雖說加班不算嚴重，但是能自由學習的時間終究是被大大壓縮，而吸收知識的形式，更多地是變成一種調研的方式。調研和學習的區別在於，調研的目的性會更加明確，而且是後續是要求落地的，所以要找的方案需要是能夠快速可靠地實現，考慮到場景特定，我們可能還要加一些場景特定的策略，那我們在有限時間下就需要保證我們調研的主幹方法不是短板。
那麼調研的方式和學習，其實非常接近：
- 讀論文、讀部落格、讀程式碼。
有的時候可能要出一份調研報告，總結技術相關的發展情況，介紹一下方法，這樣一份文件下來，無論是自己還是老大，其實都對有關技術瞭解了。
這個過程對工作算是調研對自己其實也是一種學習和成熟，調研過程中自己也經常思考，這些方法的思路和設計原因是什麼，這都很有利於自己後續方案設計的思考。
從點到面
學校可言一個比較尷尬的點就是，都是對點的研究，更可怕的是我們對這個點還不一定就很深。但是到了工作中，要求的很可能就不是會一個點就夠了。
到你手裡的可能是一個比較完整的任務，例如完整某個技能，那你需要會的就不只是一個文字分類、文字匹配就夠了，你還要知道資料怎麼處理會比較好，會比較方便，另一方面，要從聚焦於模型演算法的思路擴充套件到工程、效能等的一些其實演算法也應該考慮的技能技術上，廣度在日常工作同樣非常重要。
當然，這並不意味著就不需要關注深度，論文要跟，實驗要嘗試，我們仍要持續學習，持續分析，一技之長是自己突出拔尖的重要因素。
從模型到技術
無論是學校裡做科研，還是在入門過程，我們毫無例外的首先接觸的就是各種各樣的模型，這導致我們在方案選擇的時候只能想到模型，在效果不好的時候只能想在模型修改上，但是實際上我們還有大量可以學、需要學的東西。
- 在效果調優上，規則詞典的方式，模型組合的方式，演算法架構的整體設計等。
- 工程技術上，資料庫類技術（mysql、redis等），大資料技術（hadoop、hdfs、hive），各種網路技術（http、grpc，以及zookeeper等），還有好多。
所以，藉助工作實踐，我們能擴大自己的知識面，讓自己知道了很多自己原來壓根就沒聽過的東西，我們都可以學起來。
模型固然要持續學習，但是工作中我們還需要用到大量的技術，有時間我們要把各種相關技術拾起，逐步成長起來。
獨立思考
資訊時代的我們其實並不非常缺乏足夠我們決策的資訊，我們實際上缺少的是辨別資訊的能力，識別什麼是有效資訊，什麼是可靠的資訊，什麼是我們需要的資訊。有關獨立思考我能寫一篇很長的文章，後續我會聊，這裡簡單展開。
所謂的獨立思考，其實是一種特質，在資訊時代其實尤為重要，他是一種甄別資訊的意識和能力，我們能在大量資訊中查詢或者篩選出自己需要的資訊，這時候需要我們有明確的、主動的目標，從而能讓我們從奶頭樂、販賣焦慮、錯誤冗餘資訊從解脫出來。
所謂的奶頭樂，其實是一種簡單的樂趣，當然我們生活中需要這種樂趣，但是不能任由這種樂趣充斥我們的世界，如我們在一些學習的時候不能被這個給帶走了。
販賣焦慮應該是我們這行最容易陷入的東西了，就是所謂的內卷。說實話，焦慮是真的焦慮，但是我們需要考慮這個東西其實應該更理性，我乾脆展開聊得了，我們要思考的是這個問題：
- 我到底是不是真的有問題，這個問題是否真的發生在我身上，要認清自己，明確問題。
- 我們需要解決的不是焦慮本身，而是根源，很多人容易陷入這裡，而我們需要的是行動，很多人的處理方式只是給自己一個安慰，並不是處理焦慮的根源，那焦慮會持續存在。
- 不要被情緒所影響，解決問題，解決問題，解決問題。
- 焦慮是看參照物的，平淡的我們不一定每天都和清北的比，我很坦然，現階段要我年薪100w也是不太可能的，我只希望能比之前的自己強一些，成長一些，足夠了。
- 事情的發展總有過程，自己要有規劃，或長或短，只要路徑正確，自己一步一步走，基本沒什麼問題，所以我們需要正確的方向、正確的路線以及堅定路線的信心，有一個說法叫做“路線自信”。
- 被報道多的，應該是更少的事，而不是多的。例如知乎上不是人均211985，首先具備發完整文章能力的人真的不多（這個是真的），其次混得不好的人大都不太會出來丟人現眼；例如年薪50w、100w的人被拿出來曬，託福110、120的被拿出來曬，為什麼拿出來炫耀，因為值得炫耀，為什麼值得炫耀，因為大家都沒有，這麼說懂了吧，想想自己在朋友圈放的，是不是都是不怎麼平常的東西。所以不要被鋪天蓋地的這種資訊給騙了。
錯誤冗餘的資訊經常會影響我們的判斷，網上很多輿論帶節奏能帶起來就是因為這個，我們需要甄別，一方面我們自己要足調研，另一方面我們自己要有足夠的知識儲備，這些東西越多，我們能甄別的能力就越強。
小結
說實話，第三年末期自己的可見成長其實不是很大了，好像是到了一個瓶頸，這個瓶頸讓自己多少會看不到進步的方向，但是近期盤算下來，其實只不過是因為有些東西不太好總結罷了，很模糊，和會了一個兩個模型完全不同，有一些開悟的感覺，這種開悟不見得是在解決某一兩個問題上，而是一系列問題上。
如果很早之前自己學的是武術，能打敗一兩個人甚至幾個人，而現在學的是兵法，能打敗的可能是一個軍隊，項羽本紀中有一段“劍一人敵，不足學，學萬人敵”，“學萬人敵”的重要性在此刻能逐步明白。
03
個人成長篇
技術人，還要一直做技術，總需要持續各級各個技術的發展，同時也要花時間來點亮自己的各個技能項，所以持續的學習成長就是必要的。
有關演算法模型類
演算法模型相關是演算法工程師的必修課，我們需要更新自己的知識，完善自己的裝備庫武器庫，從而保證甚至是提升自己的能力。
首先是基本的模型方案學習，雖如我經常談到的，我們日常應用中使用模型的情況並不多，但是我依舊建議大家還是要持續看模型方面的論文和文章，原因不只是讓大家學會這些模型方案，而是透過模型我們能吸收到的是我們日常其實能遇到的問題以及他的解決方案，問題我們是經常遇到，而方法確實多種多樣的，我們要能和作者產生首先共鳴是我和他能遇到相似的問題，然後是我們看看是否可以借鑑他的方式或者是用什麼降級或者升級方案來解決他的問題。
然後是完整的技術方案，非常建議大家好好看一下。這些資料大都來源於大廠的分享，一般大廠的分享會給大家介紹的都是一大個專案的完整方案，例如我的[前沿重器]欄目中就給大家介紹了不少，這些完整的技術方案其實為大家做技術設計提供了很多建議，同時也讓大家的水平和大局觀有提升，從小專案小問題的解決提升為更大專案的技術實現，這其實對個人晉升有很大好處。當然除此之外，自己所在專案相關的技術方案和整體架構也儘可能熟悉清楚，這會讓自己對技術設計的敏感度有新的提升。
多看資料。眾所周知演算法專案本身是一個數據依賴性特別嚴重的，而且最終的演算法效果也會隨著資料的變化會產生變化，因此只有我們更加熟悉資料、瞭解資料，才能夠更好地完善我們的資料方案。因此經常閱讀資料是非常有利於解決問題的，另一方面讀資料其實也對我們理解資料的能力有幫助，為什麼會有人問為啥我看資料看不出問題，一定原因就和看資料不夠有關，看的資料不夠對比不出資料的特色，這個和看人識物一樣的。建議產品經理也多看看，很多時候問題都反饋應在資料裡，無論是單條的資料還是整體資料分佈。
多實踐。很多問題實踐才會被暴露，對某些方法的理解才能得以加深，因此，我們在各種閱讀吸收知識的同時，要記得多實踐，對比多個方法之前的優缺點，這些優缺點的提煉其實非常有利於我們後續需要考慮的方案選擇。
有關工程技術類
演算法工程師是怎麼都避不開工程的，這個入行後的各位應該都有所感受，而沒入行的各位也需要時刻明白這點。而為了更好地應對這個問題，我們需要做的就是提升自己的工程能力。
總的來說，工作後我花了大概一年半的時間來集中補充工程方面的能力和知識，這個階段的整體學習雖然讓演算法這塊小幅度落後，但是工程這塊不再成為短板，還算值得，我來簡單聊聊我是怎麼做的，我的思路是這幾點：
- 以工作為起點，去查詢自己缺漏的技術點，然後按時學習。例如git、c++/java、shell、hadoop大禮包相關，這些工作中經常遇到的一定要儘快學習起來。
- 官方文件結合網上的教程，快速get起來是關鍵。
- 透過工作來驗證自己的技術，增強技術信心。
我們都知道我們的專長在於解決演算法問題，但這不代表所有的工程問題都要丟給工程，或者說不見得所有工程都可以丟給工程做，例如一些資料流的操作，為了不太依賴工程，其實我們需要自己多掌握一些，從而保證很多事情的推進不依賴別人，同時自己的技術也有提升，這對於晉升還是有用的。
有關工作技能的成長
很多時候，我們會發現有些事情的進展不佳，不是因為我們的技術不行，而是一些諸如溝通、專案管理等問題導致，因此我們可以沉迷技術，其實還可以多讀一些管理學、經濟學甚至哲學之類的書籍來提升自己，這種學習我一般是當做閒書來看，平時輕鬆愉快地閱讀一下其實也挺不錯的，這塊畢竟不是我們現階段的重點，我不展開啦~
學習時間的安排
說實話，學習的時間真的被壓縮到很少很少，比較無奈是正常的，我通常的學習時間就是通勤、晚上回家的時間，另外是工作過程有一些調研和方案分析的時候我們是可以藉此來學習的，不要太說沒時間，大部分時間都是因為自己摸魚給浪費了。
另外還有一個比較關鍵的事情就是要學會總結和積累，有一個比較合理的筆記庫，透過這個筆記庫記錄自己做過的事情，總結沉澱下來就是自己的東西了，此時很多東西能被快速記錄從而實現快速成長，透過這種方式的成長在新人期其實收穫會非常大，所以非常建議大家花點時間把基礎的筆記體系建立起來。
小結
一連3篇的小結到此結束，這也算是自己的一個里程碑式的結點吧，畢竟沒想到自己已經是一個3年的老人了，新人光環逐漸散去，很多事情也要開始獨當一面，當然工作中會遇到很多困難，但是這些沒打倒我的最終都會成為我的養料。
