“風控演算法工程師”這個職位按字面意思可以拆成3個詞：風控、演算法、工程師，對應的能力就是業務知識、算法理論、程式設計能力。
如果經過一定時間的學習和培養你在這三個方面還有特別明顯的短板，那很難稱之為“合格”。
1. 業務知識
熟悉業務知識是基本功。
瞭解業務才能夠建立實際可用的模型，目前還不存在解決所有問題的萬能演算法，還是回到現實，從業務學習開始。
網際網路金融領域有著非常豐富的業務場景，同時它和傳統銀行業務場景差別非常大。使用者沒有面籤不直接見面，依賴的資料是弱資料、大資料，是資料和技術驅動的業務場景，但這並不代表你不需要去理解業務的內涵。
每一個現實場景就是一個應用題，作為演算法人員需要理解題幹，從場景中抽象出需要解決的問題，將它翻譯成演算法問題，然後再使用合適的演算法去解決它。
很多時候對業務問題的理解和抽象，相當於在設定模型開發的大綱。比如在白條場景中，我們想要預測授信使用者的信用風險，我們首先就需要考慮以下問題：
我們要觀察多久的訂單？
逾期多少天才算壞使用者？
逾期定義中是否需要考慮金額限制？
好使用者怎麼定義？
需不需要考慮樣本不均衡的問題？
為了保證模型的穩定性如何進行視窗驗證比較科學？
針對業務的一些變動，比如訂單制和賬單制的調整，我們如何去修正模型的目標變數？
總之基本的信貸概念和業務模式是必須去了解的，有助於你設計開發大綱。除了大綱，風控模型的開發也需要知道業務細節。這在Y變數定義，X變數加工，模型評估都會涉及。
以Y變數定義為例，一般金融行業會把樣本分為四部分：G（好使用者）；B（壞使用者）；I（不確定使用者）；E（剔除使用者）。
實操中對這四個群體通常會有不同定義的微調。有的時候是從演算法角度考慮，但更多時候是從業務需求角度考慮。預測使用者未來的白條消費金額，止付使用者就會被劃入E類使用者；預測欺詐使用者，因為樣本很少，信用風險使用者也被劃入了B類壞使用者。X變數除了根據業務知識挑選資料來源外，更多時候業務知識指導特徵構造。
這裡我插一句，不要輕視特徵工程，特徵工程仍然是非常重要的內功，不是你搞一個深度學習框架就可以解決一切。
金融行業的業務複雜通常和時間掛鉤，必須掌握業務概念的細節。對於白條業務，就有下單，到賬，應還款，實際還款，最低還款，逾期，退款等一系列細節概念，它們都是在一個時間軸上的，特徵加工很講究這些細節。
只有清楚這些概念，而且知道這些行為如何產生和被記錄，才能夠構造相關的有效特徵。好的特徵不但可以提高模型效果，也便於從業務上把握模型的跨時間有效性。
業務場景很多時候還決定了你模型效果評估的方式，因為業務很靈活，可以做到有取有舍。有些場景需要模型是為了在誤殺儘可能少的情況下抓住更多的壞人；有些場景需要模型需要有更好的排序能力但並不注重絕對值預測；有些場景需要模型需要有很準確的數值預測。
瞭解場景，挑選合適的評估方式，才能夠構造出合適的模型，當然爭辯是免不了的。
2.演算法
首先，演算法很多，沒有人能夠面面俱到，重在基本功。
作為演算法工程師，對演算法本身在公式的層面並不一定像考試那樣需要死記硬背。比如工作中不會有人問你LBFGS演算法對於海森矩陣是怎麼估計的的（即便在面試中背出來都未必是加分項）。但是，LR的基本公式，SVM的基本原理還是需要去熟練掌握。
對各個演算法的優缺點、適用範圍以及可能失效的場景需要了熟於胸，某種程度上演算法掌握深度和靈活度跟場景以及場景下資料很有關係。
企業工作時風控演算法工程師的典型工作是在面對場景需求進行建模，理論深度是有一定必要的。因為實際工作沒有時間讓你研究理論，但是需要你掌握理論。
演算法工程師搭建演算法模型的時候，往往沒有充分的時間去掃參調優，於是這會導致與在學校的時候建模發paper是完全不同的工作模式。
需要考慮的可能更應該是演算法的魯棒性，即演算法模型在資料和計算環境一定幅度的波動下，仍然能夠保持穩定的工作。
不然的話，支援線上工作的演算法模型一旦崩潰，輕則是大半夜不定的報警簡訊把你招到公司改bug，重則是造成重大財產損失——想想某業務本來大體只會授信一半的使用者，結果被奔潰的模型完全放行了……這將會是什麼畫風？
因為沒有太多的時間掃引數空間，所以最好對於各個常用模型的“效能”以及主要工作的引數空間有一個清晰的概念。
這意味著，你不能像以前在學校一樣，對於每個模型都用效果最佳的引數，而需要“常見”的引數，去實現基本的業務功能，日後業務方有需要再去最佳化。工程上，過度的演算法“潔癖”和“強迫症”都會耽誤很多事情。
特徵工程還得再強調一遍，雖然它看上去不像理論那麼高大上，但其實很多時候模型效果還就得靠那麼一點特徵工程作為作料。在演算法裡面我們更強調特徵工程的一些處理手法和技巧，比如點選流資料的處理方法，怎麼設定視窗，一些缺值資料的處理技巧，噪聲資料的去除等，都能提升模型的效果。
而且這其實有其近乎“藝術”的一面，正所謂“戲法人人會變，各有其奧妙不同”。
評價指標要選好，評價指標的坑很多，並不是說當你建好了模型之後，算一算precision、AUC、KS、F-measure就好了。
要對這些指標的原理，特別是侷限性瞭然於心。
再強調一遍，特別是他們的侷限性！甚至有時候你可能需要自己組合設計一些指標，來更好適應你的問題。
關於深度學習框架，目前各大廠小廠都在積極嘗試，但是尚且沒有全面推開在金融領域，我們在某些環節使用這些技術，同時也在向業務方普及這些技術。深度學習作為趨勢，日後廣泛應用是一定的，所以我們堅定看好它。
傳統機率論和數理統計方面的知識也不能丟。即便我們不去參與貝葉斯派和頻率派的撕逼，古典概型在考慮問題的時候也很有用。另外還有諸如隨機變數及其分佈、隨機過程、大數定理、中心極限定理等等。畢竟，金融產品的普遍是建立在人們對“未來”的預期上的，而這一過程則需要基於概統來理解。
3.程式設計
首先，總的來說，演算法工程師需要的是處理大資料和實施高效能計算。這在工程層面有多種實現方案，下面簡單羅列一下常見的部署場景，大家可以各自去攀相應的科技樹：
• 在資料層面，sql必不可少。
可以說SQL是資料的魔法石，讓資料流動，轉化，融合，迸發出巨大的威力。對於sql的熟練使用，以及一些小技巧的應用，能夠給下一步的特徵工程省很多事。在這個過程中，資料傾斜是要尤其關注的，拉資料或者計算過程中程序一直被卡在99%是一件很尷尬的事兒。
• 目前主流的程式語言越來越集中於python和R。
有新聞上說，有的中學已經在開始普及python了。所以至少最好能有所瞭解。這包括一些常用的庫，如pandas、sklearn等。
當然，其他語言也可以有，C++在我們非常追求效能時會去考慮，JAVA也會在我們提供服務的時候使用。
• 關於高效能的平行計算，Spark是一中常見的構架，它包含一個數據挖掘的庫MLlib。
• GPU（叢集）是實現更高效能平行計算的另一個流行的方案，同時考慮到一些CNN、RNN模型的使用，所以學習注入TensorFlow、Caffe等等演算法框架是很有必要的。
當然對於風控來說這是比較高階的應用。
• 在建模過程中，對資料的簡單統計分析進行視覺化是非常必要的。
資料直觀的展示出來之後，有些問題/方案就一目瞭然了。在這方面，python的視覺化工具、R、Matlab等各有各的優勢，大家可以按習慣取用。
• 最後，作為基礎，寫shell指令碼的基礎是必須的，要有一定的linux知識。
其次，特別是大型金融科技公司對編碼要求已經和互聯開發沒有什麼本質區別，因此要求在程式設計的過程中，工程考慮是一定要有的思維習慣。
這裡的“工程考慮”並不僅僅是指演算法的效能方面，還有考慮你自身的資料結構、表關係依賴關係、計算環境、伺服器效能、可用資源等等，很多問題需要與研發或者平臺的同學仔細溝通才能夠提供一個真正的風控演算法服務。
因為風控的敏感性，網上其實很少有相關的資料。尤其是現在金融科技公司中的新技術和傳統銀行技術差別較大，使得這個行業帶有一定的神秘性。
其實，風控演算法工程師和推薦系統演算法工程師、搜尋演算法工程師等等沒有太本質的區別，個人認為仍然屬於網際網路+下的演算法工作，但是同金融科技這個新生業務產生了交集，對人才有了更復合的要求：同傳統風控人員相比，它更強調了演算法能力和工程能力，同普通演算法人員相比，它更強調了金融業務理解能力。
從招聘的情況看，市場上目前具備這種綜合素質的人才很少，是一個很有發展前景的職業。
“風控演算法工程師”這個職位按字面意思可以拆成3個詞：風控、演算法、工程師，對應的能力就是業務知識、算法理論、程式設計能力。
如果經過一定時間的學習和培養你在這三個方面還有特別明顯的短板，那很難稱之為“合格”。
1. 業務知識
熟悉業務知識是基本功。
瞭解業務才能夠建立實際可用的模型，目前還不存在解決所有問題的萬能演算法，還是回到現實，從業務學習開始。
網際網路金融領域有著非常豐富的業務場景，同時它和傳統銀行業務場景差別非常大。使用者沒有面籤不直接見面，依賴的資料是弱資料、大資料，是資料和技術驅動的業務場景，但這並不代表你不需要去理解業務的內涵。
每一個現實場景就是一個應用題，作為演算法人員需要理解題幹，從場景中抽象出需要解決的問題，將它翻譯成演算法問題，然後再使用合適的演算法去解決它。
很多時候對業務問題的理解和抽象，相當於在設定模型開發的大綱。比如在白條場景中，我們想要預測授信使用者的信用風險，我們首先就需要考慮以下問題：
我們要觀察多久的訂單？
逾期多少天才算壞使用者？
逾期定義中是否需要考慮金額限制？
好使用者怎麼定義？
需不需要考慮樣本不均衡的問題？
為了保證模型的穩定性如何進行視窗驗證比較科學？
針對業務的一些變動，比如訂單制和賬單制的調整，我們如何去修正模型的目標變數？
總之基本的信貸概念和業務模式是必須去了解的，有助於你設計開發大綱。除了大綱，風控模型的開發也需要知道業務細節。這在Y變數定義，X變數加工，模型評估都會涉及。
以Y變數定義為例，一般金融行業會把樣本分為四部分：G（好使用者）；B（壞使用者）；I（不確定使用者）；E（剔除使用者）。
實操中對這四個群體通常會有不同定義的微調。有的時候是從演算法角度考慮，但更多時候是從業務需求角度考慮。預測使用者未來的白條消費金額，止付使用者就會被劃入E類使用者；預測欺詐使用者，因為樣本很少，信用風險使用者也被劃入了B類壞使用者。X變數除了根據業務知識挑選資料來源外，更多時候業務知識指導特徵構造。
這裡我插一句，不要輕視特徵工程，特徵工程仍然是非常重要的內功，不是你搞一個深度學習框架就可以解決一切。
金融行業的業務複雜通常和時間掛鉤，必須掌握業務概念的細節。對於白條業務，就有下單，到賬，應還款，實際還款，最低還款，逾期，退款等一系列細節概念，它們都是在一個時間軸上的，特徵加工很講究這些細節。
只有清楚這些概念，而且知道這些行為如何產生和被記錄，才能夠構造相關的有效特徵。好的特徵不但可以提高模型效果，也便於從業務上把握模型的跨時間有效性。
業務場景很多時候還決定了你模型效果評估的方式，因為業務很靈活，可以做到有取有舍。有些場景需要模型是為了在誤殺儘可能少的情況下抓住更多的壞人；有些場景需要模型需要有更好的排序能力但並不注重絕對值預測；有些場景需要模型需要有很準確的數值預測。
瞭解場景，挑選合適的評估方式，才能夠構造出合適的模型，當然爭辯是免不了的。
2.演算法
首先，演算法很多，沒有人能夠面面俱到，重在基本功。
作為演算法工程師，對演算法本身在公式的層面並不一定像考試那樣需要死記硬背。比如工作中不會有人問你LBFGS演算法對於海森矩陣是怎麼估計的的（即便在面試中背出來都未必是加分項）。但是，LR的基本公式，SVM的基本原理還是需要去熟練掌握。
對各個演算法的優缺點、適用範圍以及可能失效的場景需要了熟於胸，某種程度上演算法掌握深度和靈活度跟場景以及場景下資料很有關係。
企業工作時風控演算法工程師的典型工作是在面對場景需求進行建模，理論深度是有一定必要的。因為實際工作沒有時間讓你研究理論，但是需要你掌握理論。
演算法工程師搭建演算法模型的時候，往往沒有充分的時間去掃參調優，於是這會導致與在學校的時候建模發paper是完全不同的工作模式。
需要考慮的可能更應該是演算法的魯棒性，即演算法模型在資料和計算環境一定幅度的波動下，仍然能夠保持穩定的工作。
不然的話，支援線上工作的演算法模型一旦崩潰，輕則是大半夜不定的報警簡訊把你招到公司改bug，重則是造成重大財產損失——想想某業務本來大體只會授信一半的使用者，結果被奔潰的模型完全放行了……這將會是什麼畫風？
因為沒有太多的時間掃引數空間，所以最好對於各個常用模型的“效能”以及主要工作的引數空間有一個清晰的概念。
這意味著，你不能像以前在學校一樣，對於每個模型都用效果最佳的引數，而需要“常見”的引數，去實現基本的業務功能，日後業務方有需要再去最佳化。工程上，過度的演算法“潔癖”和“強迫症”都會耽誤很多事情。
特徵工程還得再強調一遍，雖然它看上去不像理論那麼高大上，但其實很多時候模型效果還就得靠那麼一點特徵工程作為作料。在演算法裡面我們更強調特徵工程的一些處理手法和技巧，比如點選流資料的處理方法，怎麼設定視窗，一些缺值資料的處理技巧，噪聲資料的去除等，都能提升模型的效果。
而且這其實有其近乎“藝術”的一面，正所謂“戲法人人會變，各有其奧妙不同”。
評價指標要選好，評價指標的坑很多，並不是說當你建好了模型之後，算一算precision、AUC、KS、F-measure就好了。
要對這些指標的原理，特別是侷限性瞭然於心。
再強調一遍，特別是他們的侷限性！甚至有時候你可能需要自己組合設計一些指標，來更好適應你的問題。
關於深度學習框架，目前各大廠小廠都在積極嘗試，但是尚且沒有全面推開在金融領域，我們在某些環節使用這些技術，同時也在向業務方普及這些技術。深度學習作為趨勢，日後廣泛應用是一定的，所以我們堅定看好它。
傳統機率論和數理統計方面的知識也不能丟。即便我們不去參與貝葉斯派和頻率派的撕逼，古典概型在考慮問題的時候也很有用。另外還有諸如隨機變數及其分佈、隨機過程、大數定理、中心極限定理等等。畢竟，金融產品的普遍是建立在人們對“未來”的預期上的，而這一過程則需要基於概統來理解。
3.程式設計
首先，總的來說，演算法工程師需要的是處理大資料和實施高效能計算。這在工程層面有多種實現方案，下面簡單羅列一下常見的部署場景，大家可以各自去攀相應的科技樹：
• 在資料層面，sql必不可少。
可以說SQL是資料的魔法石，讓資料流動，轉化，融合，迸發出巨大的威力。對於sql的熟練使用，以及一些小技巧的應用，能夠給下一步的特徵工程省很多事。在這個過程中，資料傾斜是要尤其關注的，拉資料或者計算過程中程序一直被卡在99%是一件很尷尬的事兒。
• 目前主流的程式語言越來越集中於python和R。
有新聞上說，有的中學已經在開始普及python了。所以至少最好能有所瞭解。這包括一些常用的庫，如pandas、sklearn等。
當然，其他語言也可以有，C++在我們非常追求效能時會去考慮，JAVA也會在我們提供服務的時候使用。
• 關於高效能的平行計算，Spark是一中常見的構架，它包含一個數據挖掘的庫MLlib。
• GPU（叢集）是實現更高效能平行計算的另一個流行的方案，同時考慮到一些CNN、RNN模型的使用，所以學習注入TensorFlow、Caffe等等演算法框架是很有必要的。
當然對於風控來說這是比較高階的應用。
• 在建模過程中，對資料的簡單統計分析進行視覺化是非常必要的。
資料直觀的展示出來之後，有些問題/方案就一目瞭然了。在這方面，python的視覺化工具、R、Matlab等各有各的優勢，大家可以按習慣取用。
• 最後，作為基礎，寫shell指令碼的基礎是必須的，要有一定的linux知識。
其次，特別是大型金融科技公司對編碼要求已經和互聯開發沒有什麼本質區別，因此要求在程式設計的過程中，工程考慮是一定要有的思維習慣。
這裡的“工程考慮”並不僅僅是指演算法的效能方面，還有考慮你自身的資料結構、表關係依賴關係、計算環境、伺服器效能、可用資源等等，很多問題需要與研發或者平臺的同學仔細溝通才能夠提供一個真正的風控演算法服務。
因為風控的敏感性，網上其實很少有相關的資料。尤其是現在金融科技公司中的新技術和傳統銀行技術差別較大，使得這個行業帶有一定的神秘性。
其實，風控演算法工程師和推薦系統演算法工程師、搜尋演算法工程師等等沒有太本質的區別，個人認為仍然屬於網際網路+下的演算法工作，但是同金融科技這個新生業務產生了交集，對人才有了更復合的要求：同傳統風控人員相比，它更強調了演算法能力和工程能力，同普通演算法人員相比，它更強調了金融業務理解能力。
從招聘的情況看，市場上目前具備這種綜合素質的人才很少，是一個很有發展前景的職業。