摘要：為什么要用機(jī)器學(xué)習(xí)來分析風(fēng)險(xiǎn)用戶設(shè)備咋眼一看，風(fēng)險(xiǎn)分析師根據(jù)一個(gè)用戶或者設(shè)備的各種統(tǒng)計(jì)性數(shù)據(jù)來分析風(fēng)險(xiǎn)的用戶或者設(shè)備，這個(gè)分析判斷的過程是適合機(jī)器學(xué)習(xí)的目的。

toyld   豈安科技搬運(yùn)代碼負(fù)責(zé)人
主導(dǎo)各處的挖坑工作，擅長挖坑于悄然不息，負(fù)責(zé)生命不息，挖坑不止。

我們是一家業(yè)務(wù)風(fēng)控公司， 公司的一項(xiàng)主要業(yè)務(wù)是提供給客戶私有化部署的風(fēng)控系統(tǒng)和長期的風(fēng)控分析服務(wù)，最后提供給客戶的產(chǎn)出，簡單歸納來說就是哪些ip，哪些用戶，哪些設(shè)備，哪些頁面存在風(fēng)險(xiǎn)，并提供確實(shí)的證據(jù)。因?yàn)榭蛻舻男枨蟆⒃L問流量、內(nèi)部架構(gòu)情況各不相同，前期雙方對接中涉及爬蟲、訂單、營銷活動等大量業(yè)務(wù)信息需要大量的時(shí)間投入，接入之后分析師需要大量的時(shí)間來觀察、分析、跟客戶的不斷溝通，因?yàn)楫?dāng)遇到某些業(yè)務(wù)細(xì)節(jié)的時(shí)候，溝通的成本就會被放大，才能確認(rèn)最后完成策略的制定，然后觀察效果，如此反復(fù)來確定風(fēng)險(xiǎn)IP、風(fēng)險(xiǎn)用戶、風(fēng)險(xiǎn)設(shè)備和風(fēng)險(xiǎn)頁面，即客戶所需的業(yè)務(wù)風(fēng)險(xiǎn)評估。

分析、計(jì)算成本的上升

一個(gè)最簡單的博客，只有博文的增刪改查4個(gè)功能，1個(gè)URL接口，但是這樣一個(gè)博客現(xiàn)在是不可能作為產(chǎn)品投入使用的，自然而然的，評論、標(biāo)簽、類別、用戶權(quán)限系統(tǒng)、分享... 隨著功能的不斷完善，接口數(shù)量也隨之不斷增加，更恐怖的是后端程序經(jīng)常將id之類的非固定內(nèi)容放到URL當(dāng)中，所以我們在給客戶提供私有化風(fēng)控服務(wù)的時(shí)候常有幾十萬甚至百萬量級的URL進(jìn)行數(shù)據(jù)統(tǒng)計(jì)，這一點(diǎn)在一開始的時(shí)候確實(shí)會造成我們計(jì)算和運(yùn)營分析資源的浪費(fèi)，因?yàn)榉治龅膶ο筮h(yuǎn)遠(yuǎn)超過了可人工審查的范圍，最后也只能靠分析師通過和客戶的交涉和自己去使用客戶網(wǎng)站的最原始的方法來縮減需要特別關(guān)注或需要制定阻斷策略的。
簡而言之就是隨著業(yè)務(wù)的不斷發(fā)展， 復(fù)雜度無疑是以更快的速度增長，由此帶來我們運(yùn)營分析的溝通、時(shí)間成本和我們風(fēng)控系統(tǒng)計(jì)算成本的浪費(fèi)，我們迫切的想解決這個(gè)問題。

報(bào)警監(jiān)控

最基礎(chǔ)的監(jiān)控可能只是針對訪問量、流量和一些服務(wù)器機(jī)器性能指標(biāo)的，如果監(jiān)控所有的頁面，又顯得目標(biāo)太散，換句話說就是我們盯著全北京的所有路面情況全面標(biāo)紅沒有意義，我們只關(guān)心我們到家的路徑上是否堵車，對客戶也是一樣，只關(guān)心核心資源、活動頁面這樣的關(guān)鍵節(jié)點(diǎn)是否被攻擊就足夠了。但是只是簡單的篩選出需要監(jiān)控的頁面，監(jiān)控其余所有頁面的系統(tǒng)資源也是一種奢侈的浪費(fèi)，所以我們的結(jié)論就是：只監(jiān)控我們關(guān)心的重要頁面就好，不關(guān)心多余的頁面，不需要多余的服務(wù)器計(jì)算資源，豈不是一步到位？

北京交通流量全線標(biāo)紅

目的地: 家， 導(dǎo)航全綠

機(jī)器學(xué)習(xí)

和報(bào)警監(jiān)控的需求類似，機(jī)器學(xué)習(xí)需要關(guān)注的只是少量關(guān)鍵資源節(jié)點(diǎn)上IP、用戶、設(shè)備的行為統(tǒng)計(jì)數(shù)據(jù)，因?yàn)榕老x、訂單之類業(yè)務(wù)風(fēng)險(xiǎn)流量是不會盯著一個(gè)404頁面做文章的。

咋眼一看，風(fēng)險(xiǎn)分析師根據(jù)一個(gè)IP、用戶或者設(shè)備的各種統(tǒng)計(jì)性數(shù)據(jù)來分析風(fēng)險(xiǎn)的IP、用戶或者設(shè)備，這個(gè)分析判斷的過程是適合機(jī)器學(xué)習(xí)的目的。

人工分析的成本

筆者所接觸到的傳統(tǒng)風(fēng)控都是世代累計(jì)的案例構(gòu)成的成百上千的策略來完成的，通過初篩一些可疑的用戶，然后堆人來分析案例，然后復(fù)審，逐漸累計(jì)匯總成為策略，口耳相傳。但是我們的風(fēng)控服務(wù)是面向各行業(yè)的客戶的，所以只靠堆人已經(jīng)不能滿足我們的，我們還需要加快效率。我們的愿景是教會機(jī)器學(xué)習(xí)這個(gè)學(xué)生，能夠幫助分析師更快的發(fā)現(xiàn)風(fēng)險(xiǎn)，最終不斷的自我學(xué)習(xí)，接近人工分析的準(zhǔn)確。

那么分析網(wǎng)站結(jié)構(gòu)、網(wǎng)站關(guān)鍵路徑我們遇到了哪些坑呢？

理想中的架構(gòu)

少量的網(wǎng)站入口，層次分明的訪問層級，每個(gè)關(guān)鍵資源都是這棵樹的一個(gè)葉子節(jié)點(diǎn)，一顆理想完美的網(wǎng)站樹結(jié)構(gòu)，只要找到了網(wǎng)站的入口，剩下的問題只是遍歷圖中的路徑了，單純的筆者，一開始是這么以為的。

現(xiàn)實(shí)

當(dāng)網(wǎng)站被搜索引擎全網(wǎng)索引的時(shí)候，網(wǎng)站的大量流量是直接從搜索引擎頁面直接抵達(dá)，網(wǎng)站的入口成了擺設(shè)，人們可以直達(dá)想要的內(nèi)容頁面，從此沒有了清晰的訪問路徑， 對于用戶可能是一件好事，但是網(wǎng)站規(guī)劃的訪問路徑被繞過，損失的可能就不止是廣告的瀏覽量了，一旦爬蟲之流偽裝成搜索引擎，到時(shí)候的難題就是無法分辨真實(shí)的爬蟲還是真實(shí)的流量。

App端，隨著移動端的流量逐年增大，很多公司的后端架構(gòu)都往微服務(wù)方向轉(zhuǎn)型，既后端只提供API，具體的業(yè)務(wù)是放到了具體平臺的App中，這樣帶來的結(jié)果是，雖然用戶可以離線使用任何不帶網(wǎng)絡(luò)訪問的本地內(nèi)容，但是用戶在App客戶端中的訪問路徑之類的數(shù)據(jù)的不再像傳統(tǒng)網(wǎng)站一樣是現(xiàn)成的了。

單頁應(yīng)用這樣動態(tài)前端的網(wǎng)站，隨著前后端分離的趨勢，跟App端流量類似的是業(yè)務(wù)、頁面訪問的邏輯都放到了前端，前端控制后端接口調(diào)用，所以我們只知道了用戶調(diào)用了什么接口，不知道用戶從哪里來在什么地方調(diào)用的接口。

很多URL是由像id這樣的動態(tài)內(nèi)容構(gòu)成的，所以沒人知道URL究竟有多少個(gè)。

機(jī)器學(xué)習(xí)來預(yù)測業(yè)務(wù)風(fēng)險(xiǎn)我們遇到了哪些坑呢？

理想情況

機(jī)器學(xué)習(xí)來根據(jù)客戶流量日志來預(yù)測風(fēng)險(xiǎn)就跟機(jī)器學(xué)習(xí)來判斷瓜是否好吃的經(jīng)典案例一樣，我們清楚的知道瓜的好吃與否與你看到瓜時(shí)殘留的藤的長度無關(guān)(既特征篩選符合直覺), 只跟瓜的外表圖案、響聲，品種等有限的特征有關(guān)(特征新增、挑選簡單)， 結(jié)果是否準(zhǔn)確，吃一口就知道了(判斷條件簡單，可解釋性就強(qiáng)，特征好壞容易判斷), 判斷錯(cuò)了，反省一下挑的原則就好了(幾乎沒有錯(cuò)誤懲罰)。

回歸現(xiàn)實(shí)

樣本少，靠人工復(fù)審效率也不高；因?yàn)槊總€(gè)客戶的實(shí)際情況不同，模型的通用性有待考證的情況下，初始樣本就只有傳統(tǒng)策略引擎貢獻(xiàn)的相對少的量，另外的話，因?yàn)槲覀兊娘L(fēng)控服務(wù)追求的是準(zhǔn)確，所以只能犧牲分析師的時(shí)間效率，初期訓(xùn)練模型的話，還需要分析師的復(fù)審之后篩選出新的樣本，擴(kuò)充了樣本庫之后，再重新訓(xùn)練如此反復(fù)，反而增加了分析師的分析負(fù)擔(dān)。

訓(xùn)練出來的模型通用性， 因?yàn)槲覀兎?wù)的是各行業(yè)的客戶，各個(gè)客戶的現(xiàn)實(shí)問題各不相同，有的被爬蟲困擾，有的是活動營銷被薅羊毛，所以在每個(gè)客戶的私有化部署環(huán)境里面訓(xùn)練出來的模型很有可能是不具備通用性的。

特征的增加和篩選很糾結(jié)；當(dāng)一些常見的統(tǒng)計(jì)特征，例如總量、比率，都加上之后，可能就一百出頭的特征，這時(shí)候訓(xùn)練的效果并不是太好 ，愁的是如何增加特征，但是當(dāng)我們的特征增加到十幾k的時(shí)候，訓(xùn)練結(jié)果并沒有飛躍性的提升，這時(shí)候我們愁的是如何自動化的篩選出完全無關(guān)的特征，特征太多的時(shí)候，不僅僅是無法解釋，數(shù)據(jù)量過大，對于程序而言，還需要針對內(nèi)存使用進(jìn)行專門的優(yōu)化。

因?yàn)殄e(cuò)誤懲罰的后果嚴(yán)重仍然無法完全脫離分析師的復(fù)審； 跟挑西瓜失敗不同的是，我們不能簡單的重頭來過，因?yàn)檫@樣錯(cuò)怪一個(gè)好人導(dǎo)致的結(jié)果很可能是客戶需要面對一個(gè)憤怒的正常用戶的投訴，一個(gè)失誤就可能引發(fā)對我們系統(tǒng)可靠性的嚴(yán)重懷疑，面對如此嚴(yán)重的錯(cuò)誤懲罰，所以我們只能對于模型預(yù)測的風(fēng)險(xiǎn)再通過分析師的專家復(fù)審去尋求一個(gè)合理的解釋，才能加入到傳統(tǒng)策略引擎的風(fēng)險(xiǎn)預(yù)測的結(jié)果中。

分析網(wǎng)頁重要性的解決方案

第一步，折疊動態(tài)URL, 簡單說來就是通過將URL分層，通過配置的閾值來控制動態(tài)層次的總體大小 ，一旦超過閾值就自動折疊， 最后的結(jié)果是我們page頁面維度的對象數(shù)量下降了至少2個(gè)數(shù)量級，從一般幾十萬縮減到了幾千，我們滿意了么？還沒有。

第二步，在折疊URL的基礎(chǔ)上，構(gòu)建網(wǎng)站的訪問圖，再進(jìn)一步通過pagerank算法的計(jì)算和我們自己累計(jì)的一些統(tǒng)計(jì)指標(biāo)，分析得出流量入口、關(guān)鍵索引頁面、關(guān)鍵資源節(jié)點(diǎn)、必經(jīng)路徑，一些黑名單頁面(例如404跳轉(zhuǎn)頁面), 然后再通過訪問流量構(gòu)建這些關(guān)鍵節(jié)點(diǎn)之間的訪問關(guān)系圖，至此我們成功的將page頁面維度的對象數(shù)量減少至小于100的常數(shù)級別。

基于機(jī)器學(xué)習(xí)的風(fēng)險(xiǎn)預(yù)測的解決方案

我們在分析好的網(wǎng)站重要網(wǎng)頁關(guān)系圖上重放流量，根據(jù)統(tǒng)計(jì)的IP、用戶、設(shè)備的各種行為作為特征，每個(gè)小時(shí)跟策略引擎產(chǎn)生的風(fēng)險(xiǎn)IP、用戶、設(shè)備做新的樣本集，來繼續(xù)增強(qiáng)學(xué)習(xí)已有的模型，并且產(chǎn)出一些不在樣本集的風(fēng)險(xiǎn)IP、用戶、設(shè)備供給分析師做復(fù)審。

每個(gè)小時(shí)會以上個(gè)小時(shí)的模型為基礎(chǔ)，根據(jù)樣本集，來遍歷所有算法、自動調(diào)優(yōu)所有的特征，給出一個(gè)當(dāng)前小時(shí)最佳模型。