編輯導語：資料分析師，乍一聽好像只需要與資料打交道，收集分析資料並且做出相應地決策判斷。但是，真的是這樣子的嗎？資料分析師其實也需要學習演算法知識，並且在實際的工作中去做大量的驗證。在本篇文章中，作者就帶我們去解資料分析師與演算法的前世今生。

透過和一些朋友交流，發現目前一些資料分析師，其實不是很清楚機器學習可以如何應用於業務，也不清楚自己到底要不要去學習演算法知識。實際業務中一些複雜演算法場景例如商品推薦、內容推薦、匹配策略等，其實都需要資料分析師做大量的探索驗證工作。

分析師前期可以為建模指導方向，中後期也為模型的最佳化提供一些新的思路與資料洞察，此外用演算法還可以大大提升分析效率與分析科學性。今天，就讓我們詳細的來了解一下資料分析師與演算法的前世今生。

本篇目錄：

對演算法的一些理解

哪些場景下需要用到機器學習演算法

演算法的產出物及形態，如何應用於業務

為什麼資料分析師需要會機器學習

資料分析師與演算法工程師的職責差異

實際業務中如何分工配合可以效用最大化

資料分析師應該掌握的程度

一、對演算法的一些理解

在講分析師與演算法之前，先來理解一下什麼是演算法（Algorithm），專業術語在很多書籍、文章裡面都有分別的定義，通俗一點理解，大致上可以認為演算法是為了解決某個問題的固定化計算方法與步驟。

拆解一下上面這句話：

目的：為了解決某個/某類問題，需要在這之前瞭解到背後的業務背景、關聯場景；

方法：透過計算來實現，也就意味著需要具備具體的、可量化的資訊輸入，且可計算，而非不可執行的概念體；

步驟：有先後順序，先做什麼然後做什麼最後做什麼，每個過程之間還必須具備可行性，執行次數也一定是有限的；

結論：是否能夠解決這個問題，效果如何，最終必須得有一個產出物。在演算法之外，還有幾層擴充套件；

決策：根據一個或者多個結論進行判斷，這個過程是不是符合預期的，如何調整最佳化，是否可直接應用於業務；

應用拓展：除了解決最初的那個問題外，還有哪些同質型別的問題也可以得到解決，也就是場景的拓展。

具體的演算法搭建過程就不說了，在不少工具書、專業書、案例書裡面都有非常詳細的講解。回到問題上，什麼場景下需要用到演算法去解決問題。舉幾個生活裡面的例子：

譬如說做菜：為了能吃的更好點，選擇一本合適的食譜來準備食材、輔料，根據步驟和技巧“小火燉、中火炸、大火炒”，“一炒、二燉、三燜、四涮”，起鍋裝盤；

譬如上學：從家門出發，直走50米，第一個十字路口右轉，繼續直行100米，到達公交站，乘402路車，5站後下車，沿人行道繼續行走200米，左轉，再直行150米，最終到達校門。

這些都可以理解為演算法，生活裡面比比皆是，不過多數情況下成為了我們習慣的一種方式罷了。

二、哪些場景下需要用到機器學習演算法

在很多場景下都需要用到機器學習演算法，換一個角度，來說說我對應用場景的理解。本質上說，我過去的一些專案裡面透過演算法解決的問題大致上可以分為這麼幾類

1. 供需匹配的問題

量變產生質變，過去的十年時間，無論是在B2C，還是B2B、S2B、B2G，我們去建立使用者畫像做精準營銷、做好推薦系統實現千人千面、對使用者進行分層分類打標籤、給使用者的評價資訊劃分情緒好壞等等，都是為了更好的去做供需關係管理匹配。

影片個性化推薦是供需管理，商品個性化推薦是供需管理，網約車是供需管理，供需管理即“ 誰可以找誰消費到一件相對比較合適的東西（內容、物品、資訊、線索、商機），在這個過程中還可能需要透過哪幾個誰才能打通彼此之間的聯絡。”

衍生出的問題立馬就出現了，如何從千萬級甚至億級的商品裡面去做匹配召回，如何從萬億級的會話內容資訊中定位線索，如何明確哪些人才是我們目標的特定人群，如何把相應的資訊透過什麼渠道push到最合適的人，如何去做到好的觸達，又如何去回收這些人收到資訊之後的反饋效果。

如果只有幾千條資料，一個團隊裡面10來個人，每個人分個百來條逐一去確認，則不需透過分析也能實現，耗費的只不過是人力上的一些時間投入。

所以日常對接需求過程中，接到一個需求時，一般會先進行資源匹配評估，這個事情能不能透過疊人力的方式解決，如果透過線下大概需要花多少人力成本，用一些小樣本資料的歸納總結能不能得出通用的規則。做調研然後去推行的成本有多少，產出有多少。

再之後才是透過演算法方案去解決，投入的工程師要幾人月，裝置資源效能上的要求，能夠持續多久，可以影響的層面，以及最後的產出估測。最後再綜合考慮，這個投入產出比的情況下，到底是透過小資料分析去形成規則，還是需要透過演算法去挖掘特徵，以及方案的可持續性。

大公司裡面資源較豐富，往往這兩者會並行。從某種程度也就嚴格的區分了資料分析和資料演算法間的職責邊界；而中小企業資源有限，可能造成分析即演算法的現象。

我們發現，供需匹配過程中涉及的演算法，基本都是有監督演算法，不論是人群分類、商品召回、需求匹配，都可以透過過去的經驗進行一個初步標籤建立，然後逐步去對劃分的準確性進行校驗和最佳化。

值得一談的是，在供需的某些場景過程中會並存很多涉及物聯網的知識，譬如物流排程、配送匹配、路線最佳化、倉庫建設等等供應鏈最佳化方面的事情，這些場景下除了演算法外，還需要去了解下運籌學的內容。

2. 異常識別和診斷

異常檢測，在前幾年p2p還沒有暴雷的時候，金融領域裡面遍地都是，主要的場景就是風控，風控的場景細分：

信用卡交易反欺詐：分類任務，GBDT演算法 / XGBT演算法+LR邏輯迴歸；

信用卡申請反欺詐：分類任務，GBDT演算法 / XGBT演算法+LR邏輯迴歸；

貸款申請反欺詐：分類任務，GBDT演算法 / XGBT演算法+LR邏輯迴歸；

反洗錢：分類任務，GBDT演算法 / XGBT演算法+LR邏輯迴歸。

金融領域涉及到風控的幾乎都是GBDT / XGBT+LR，因為在金融行業有一個非常特別的屬性：監管。

對於演算法結果必須有非常好的模型解釋，對於LR模型來說，這是天然的優勢，特徵可解釋，特徵工程清晰，每個特徵的貢獻度、相關程度也可以被統計出來。

換了其他深度學習的模型，從最終的模型效果上來看，roc/auc/ks的表現沒差，但是解釋性極差，也就造成了很多應用上的壁壘。換一個通俗點說法，你很高階，然而並不實用，華而不實。

3. 排序

排序之所以單拎出來，它的應用場景其實有一定的侷限性，但是怎麼做好排序，客觀、合理，卻是一個值得去考究的事情。常見的排序應用場景有熱點榜單、搜尋排序、推薦排序等。

知乎的問題回答排序是一個經典的排序應用場景，既要保證優質高贊內容可以排在前面被使用者瀏覽，又要保證新增內容有一定曝光量，同時需要綜合考慮話題熱度及社群調性等多重因素。

故需要將回答贊/踩數量、回答使用者該領域權威性、贊/踩使用者領域權威性、回答時間、回答爭議性、回答使用者的歷史畫像特徵等綜合權重進行演算法排序。

4. 預測

數值預測與分類預測都屬於預測場景。銷售預測、股票預測、流量預測，這些都是常見的預測場景。11、12年的時候清一色的都會用arima，spss在手天下我有，沒有什麼是時序不能解決的，到後面就變成xgboost、LightGBM了。

5. 知識圖譜

2012年的時候google推出了一個叫Knowledge Graph的產品，能夠直觀的看到詞和其背後知識的關係。

很多大公司都已經在知識圖譜的建設上進行佈局了，知識圖譜最早的應用是提升搜尋引擎的能力，隨後在輔助智慧問答、自然語言理解、大資料分析、推薦計算、物聯網裝置互聯、可解釋性人工智慧等多個方面展現出豐富的應用價值，這幾年推廣比較成功的應該是AI輔助司法進行案件判決。

資訊檢索/搜尋：搜尋引擎中對實體資訊的精準聚合和匹配、對關鍵詞的理解以及對搜尋意圖的語義分析等；

自然語言理解：知識圖譜中的知識作為理解自然語言中實體和關係的背景資訊；

問答系統：匹配問答模式和知識圖譜中知識子圖之間的對映；

推薦系統：將知識圖譜作為一種輔助資訊整合到推薦系統中以提供更加精準的推薦選項，知識圖譜+推薦系統；

電子商務：構建商品的知識圖譜用於精準匹配使用者的購買意願和商品候選集，知識圖譜+推薦系統；

金融風控：利用實體之間的關係分析金融活動的風險以提供在風險觸發後的補救措施（如反欺詐等）；

公安刑偵：分析實體和實體之間的關係獲取案件線索等；

司法輔助：法律條文的結構化表示和查詢用於輔助案件的判決等；

教育醫療：提供視覺化的知識表示，用於藥物分析、疾病診斷等；

社交類業務：社交類業務具備高度連線的特點，比如好友關係等，。

三、演算法的產出物及形態，如何應用於業務

我們最近常聽到的一個詞叫“大資料殺熟”，應該是演算法在業務上非常常用的一種應用場景。通常來說，演算法的產出物有兩種，第一種是演算法產出的結果（分群、分類、預測值），第二種是演算法產出的規則。

1. 產出結果

降維：無論是對資料的分類，還是對數值的預測，對業務應用都可以作為篩選物件，進一步縮小目標，找到清晰的劃分邊界。在一些臨界點上演算法會減少人力決策成本，從諸多策略中選擇最優去做嘗試；

精細化：把結果作為標籤，結合CRM、廣告系統、營銷系統，幫助業務更便捷、更精準地獲取資訊，強化使用者感知，製造新奇感引起使用者注意，設定規則以提升使用者使用黏性；

策略：降低成本、提效增益，演算法本質上解決的就是這兩件事情，演算法產出結果可以有效的支撐策略制定，論證是或否的可行性。

2. 產出規則

很多時候我們往往只會關注到了結果本身，準確性、精確率、召回率怎麼樣，卻忽略了演算法產生的規則層應用。前面提到過的模型可解釋性，其實就是一種規則的具象化。

在關聯分析中，有提到過強相關、弱相關、不相關。作為一名業務，他可以說這個產出結果透過業務經驗也能知道，而作為分析，則需要把所謂“經驗”演繹為規則，這個規則就是透過數字串聯起來的。

於演算法而言，在模型解釋時，也會碰到一些特徵具備很強的規則，但往往容易只看資料結果，卻忽略了其在實際業務過程中的意義和因果關係，於是造成了“演算法分析出的結果不如根據經驗拍腦袋決策”的現象。

四、為什麼資料分析師需要會機器學習

我們先明確一個概念，即資料分析，它既可以作為一個社會中職業人的附加技能存在，也可以作為一個社會中職業人的主幹職業進行發展。

1. 多數情況下，我們僅在迎合這個世界的法則，卻並未去思考它為什麼存在

在挖掘分析應用的專案中，演算法是核心要素，大部分演算法的實現原理，都會涉及一些高等數學知識。

數學本身非常抽象，學的快忘的快，自然而然演算法對很多人來說具備某種神秘感。人類的好奇心和上進心，促進了人類的進化與生存，所以我要揭開那層神秘面紗去學習。

同樣人也會經常高估自己的毅力及短期內可取得成果，所以往往是：費勁周折投入大量時間搞明白幾個演算法原理實現後，就再也沒有繼續堅持下去。此時可能走向一個極端，只要能使用第三方的演算法庫在自己的電腦中成功執行並能輸出結果就可以，效果不好就再換一個演算法嘗試。

2. 資料分析為了達成業務目標，可以使用演算法來進行快速論證

分析師懂演算法非常有必要，最近幾年，資料分析師的崗位職責中，或多或少會寫一些演算法相關要求。

我的認知是，初級分析師不需要懂演算法即可cover大部分的工作內容。但是要想職業更上一層樓，增強分析的科學性嚴謹性和效率性，尤其是涉及演算法策略驅動的業務型別中，分析師必須懂一些常用機器學習演算法。

其實分析的重點還是聚焦在對目標問題的拆解、論證與實現上，對於絕大多數分析師而言，業務需求特徵大致可歸納為，交付時間短、實現成效快、資料維度豐富、結論支撐足夠、方便報告彙報。

大部分業務分析的場景都可以透過類似杜邦分析的方法進行層層下鑽拆解，而這個過程對數學知識以及演算法知識的涉及可能非常少。

業界已經有了非常多成熟的演算法應用實踐，有的時候為了做資料論證和探索，就需要用到類似演算法，其目的是用最短的時間找到一個可以去下結論的突破點。於是在實際應用時會碰到一個前提，即每種演算法都有其合適的應用場景及前置條件，且當具體使用時超級引數的影響也非常大。

所以如果我們不從更高層次去理解和對待演算法，那麼在實際運用時，就可能如刻舟求劍，難以取得預想效果或者過早的否掉一個本可以恰當解決當前問題的演算法模型，只因為相關的工作沒有足夠的重視（例如資料清洗、特徵選取方式不合理）。

skl包提供了大量簡單函式，為了快速運用這些函式解決實際問題，我們不得不花時間去了解演算法的內部原理及實現細節。建築設計師不需要精通製造鋼筋水泥的工藝，但需要了解不同鋼鐵、水泥的性質用途及之間配合關係，道理同樣適用在這個環節。

3. 分析師要更好成長，橫向知識儲備必不可少

資料分析師的成長就像一場馬拉松，需要合理分配時間精力。專注力和自制力是一種稀缺資源，需要用在最合適的地方。經常提醒自己的目標是什麼，才能把事情做好，對於分析師來說尤其如此。

不僅僅是演算法，在這個大的社會環境下，對於市場、行業、細分領域、垂直領域、崗位、職業、技術、技能、商業很多個方面都需要有所涉獵，因為分析只是一個技能，把它作為職業更需要貼切實際場景下做出相應合理的策略。

五、資料分析師與演算法工程師的職責差異

1. 資料分析師的要求

懂業務是前提：視野需要儘可能寬，需要去了解行業大盤、市場動態、公司業務、商業模式、業務流程，建立自己的認知和判別思維，在指定場景下能夠去用科學嚴謹的方法得出合理結論；

懂分析是核心：資料分析的基本方法原理、專業高效的資料分析方法論、靈活性的組合技巧運用、結合業務的適用分析方法論、高度的資料敏感性；

懂彙報是臺階：好的分析離不開好的報告，好的報告離不開好的彙報技巧，在誰的面前怎麼說話，說什麼話，也是一項技術活兒。

2. 演算法工程師的要求

懂技術是前提：不同的演算法可能用不同的時間、空間或效率來完成同樣的任務，演算法的執行效能需要具備一定的coding技術支撐。

專業極其細分：按照研究方向劃分，主要是影片演算法工程師、影象處理演算法工程師、音訊演算法工程師、通訊基帶演算法工程師、訊號演算法工程師、NLP演算法工程師、生物醫學訊號演算法工程師等知識深度寬泛。

3. 兩者的共性和差異

共性：都需要對資料進行探索，發覺資料之間的模式和規律，從而運用一些列的規則和公式來解決實際的問題（都要讀統計學、機率論）；

區別：資料分析透過一些傳統的方法來解決實際問題，門檻低，人人都是資料分析，實現效果即可忽略效能；演算法工程師的門檻相對較高，需要對原有的方法進行一定程度的創新，來解決特定領域中的問題，且需要保證演算法的效能、效果、穩定。

六、實際業務中如何分工配合可以效用最大化

實際業務過程中，分析和演算法的需求方是存在一定差異的。在協同上，往往有可能不同部門的人，在做同一件事。可能會因為需求匯入時的背景、視角不同，造成結論之間存在差異性。

1. 一個案例

有一些人總是不及時向電信運營商繳錢，如何發現它們？

資料分析：透過對資料的觀察，我們發現不及時繳錢人群裡的貧困人口占82%。所以結論是收入低的人往往會繳費不及時。結論就需要降低資費；

資料演算法：透過編寫好的演算法自行發現深層次的原因。原因可能是，家住在五環以外的人，由於環境偏遠不及時繳錢。結論就需要多設立一些營業廳或者自助繳費點。

2. 如何協同

資料演算法之前，應該先進行資料的探索分析，透過對業務問題的定位和拆解，找到可用的資料維度特徵，採集資料，形成資料指標進行各種維度組合的統計分析，得出初步結論進行彙報，如上：人均收入低建議降低資費。

在業務資訊聚焦過程中，對發現出來無法具象描述出來的課題，組織進行專題研究，透過演算法的形式構建資料特徵進行深層次挖掘，得出潛在結論，如上：環境偏遠建議增加駐點。

之後針對演算法產出的結論，可以進行可行性分析，基於業務上的實際訴求，分析選址位置、人群覆蓋、套餐標準等等。

3. 小結

分析和演算法在某種程度上來說可以混淆在一起，小團隊裡面，1～2個資深的分析也可以hold 。很多事情都是需要自驅進行，但從實際專案的推進上，通常都是先分析，再專題，繼而深度結合業務分析，再分析驅動演算法迭代，如此反覆。

七、資料分析師應該掌握的程度

綜上，對於一個專業資料分析師來說，在各個層面需要掌握的能力要求可以如下：

行業知識 ★★★★

業務瞭解 ★★★★★

分析思維 ★★★★★

資料處理 ★★★★

演算法原理 ★★★

coding能力 ★★★

報告撰寫 ★★★★★

彙報演講 ★★★★

歸納總結 ★★★★★

資源整合 ★★★★

作者：趙小洛，公眾號：趙小洛洛洛

本文由 @趙小洛 原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議