揭祕：爲何一家風控公司要經過網頁重要性分析來進行機器學習？

toyld 豈安科技搬運代碼負責人

主導各處的挖坑工做，擅長挖坑於悄然不息，負責生命不息，挖坑不止。

起源

1咱們是誰，爲何要作這些

咱們是一家業務風控公司， 公司的一項主要業務是提供給客戶私有化部署的風控系統和長期的風控分析服務，最後提供給客戶的產出，簡單概括來講就是哪些ip，哪些用戶，哪些設備，哪些頁面存在風險，並提供確實的證據。由於客戶的需求、訪問流量、內部架構狀況各不相同，前期雙方對接中涉及爬蟲、訂單、營銷活動等大量業務信息須要大量的時間投入，接入以後分析師須要大量的時間來觀察、分析、跟客戶的不斷溝通，由於當遇到某些業務細節的時候，溝通的成本就會被放大，才能確認最後完成策略的制定，而後觀察效果，如此反覆來肯定風險IP、風險用戶、風險設備和風險頁面，即客戶所需的業務風險評估。

2爲何要分析網站結構、網站關鍵路徑？

分析、計算成本的上升

一個最簡單的博客，只有博文的增刪改查4個功能，1個URL接口，可是這樣一個博客如今是不可能做爲產品投入使用的，天然而然的，評論、標籤、類別、用戶權限系統、分享... 隨着功能的不斷完善，接口數量也隨之不斷增長，更恐怖的是後端程序常常將id之類的非固定內容放到URL當中，因此咱們在給客戶提供私有化風控服務的時候常有幾十萬甚至百萬量級的URL進行數據統計，這一點在一開始的時候確實會形成咱們計算和運營分析資源的浪費，由於分析的對象遠遠超過了可人工審查的範圍，最後也只能靠分析師經過和客戶的交涉和本身去使用客戶網站的最原始的方法來縮減須要特別關注或須要制定阻斷策略的。
簡而言之就是隨着業務的不斷髮展， 複雜度無疑是以更快的速度增加，由此帶來咱們運營分析的溝通、時間成本和咱們風控系統計算成本的浪費，咱們迫切的想解決這個問題。

報警監控

最基礎的監控可能只是針對訪問量、流量和一些服務器機器性能指標的，若是監控全部的頁面，又顯得目標太散，換句話說就是咱們盯着全北京的全部路面狀況全面標紅沒有意義，咱們只關心咱們到家的路徑上是否堵車，對客戶也是同樣，只關心核心資源、活動頁面這樣的關鍵節點是否被攻擊就足夠了。可是隻是簡單的篩選出須要監控的頁面，監控其他全部頁面的系統資源也是一種奢侈的浪費，因此咱們的結論就是：只監控咱們關心的重要頁面就好，不關心多餘的頁面，不須要多餘的服務器計算資源，豈不是一步到位？

北京交通流量全線標紅

目的地: 家， 導航全綠

機器學習

和報警監控的需求相似，機器學習須要關注的只是少許關鍵資源節點上IP、用戶、設備的行爲統計數據，由於爬蟲、訂單之類業務風險流量是不會盯着一個404頁面作文章的。

3爲何要用機器學習來分析風險IP、用戶、設備？

咋眼一看，風險分析師根據一個IP、用戶或者設備的各類統計性數據來分析風險的IP、用戶或者設備，這個分析判斷的過程是適合機器學習的目的。

人工分析的成本

筆者所接觸到的傳統風控都是世代累計的案例構成的成百上千的策略來完成的，經過初篩一些可疑的用戶，而後堆人來分析案例，而後複審，逐漸累計彙總成爲策略，口耳相傳。可是咱們的風控服務是面向各行業的客戶的，因此只靠堆人已經不能知足咱們的，咱們還須要加快效率。咱們的願景是教會機器學習這個學生，可以幫助分析師更快的發現風險，最終不斷的自我學習，接近人工分析的準確。

過程

那麼分析網站結構、網站關鍵路徑咱們遇到了哪些坑呢？

理想中的架構

少許的網站入口，井井有條的訪問層級，每一個關鍵資源都是這棵樹的一個葉子節點，一顆理想完美的網站樹結構，只要找到了網站的入口，剩下的問題只是遍歷圖中的路徑了，單純的筆者，一開始是這麼覺得的。

現實

當網站被搜索引擎全網索引的時候，網站的大量流量是直接從搜索引擎頁面直接抵達，網站的入口成了擺設，人們能夠直達想要的內容頁面，今後沒有了清晰的訪問路徑， 對於用戶多是一件好事，可是網站規劃的訪問路徑被繞過，損失的可能就不止是廣告的瀏覽量了，一旦爬蟲之流假裝成搜索引擎，到時候的難題就是沒法分辨真實的爬蟲仍是真實的流量。

App端，隨着移動端的流量逐年增大，不少公司的後端架構都往微服務方向轉型，既後端只提供API，具體的業務是放到了具體平臺的App中，這樣帶來的結果是，雖然用戶能夠離線使用任何不帶網絡訪問的本地內容，可是用戶在App客戶端中的訪問路徑之類的數據的再也不像傳統網站同樣是現成的了。

單頁應用這樣動態前端的網站，隨着先後端分離的趨勢，跟App端流量相似的是業務、頁面訪問的邏輯都放到了前端，前端控制後端接口調用，因此咱們只知道了用戶調用了什麼接口，不知道用戶從哪裏來在什麼地方調用的接口。

不少URL是由像id這樣的動態內容構成的，因此沒人知道URL究竟有多少個。

機器學習來預測業務風險咱們遇到了哪些坑呢？

理想狀況

機器學習來根據客戶流量日誌來預測風險就跟機器學習來判斷瓜是否好吃的經典案例同樣，咱們清楚的知道瓜的好吃與否與你看到瓜時殘留的藤的長度無關(既特徵篩選符合直覺), 只跟瓜的外表圖案、響聲，品種等有限的特徵有關(特徵新增、挑選簡單)， 結果是否準確，吃一口就知道了(判斷條件簡單，可解釋性就強，特徵好壞容易判斷), 判斷錯了，檢討一下挑的原則就行了(幾乎沒有錯誤懲罰)。

迴歸現實

樣本少，靠人工複審效率也不高；由於每一個客戶的實際狀況不一樣，模型的通用性有待考證的狀況下，初始樣本就只有傳統策略引擎貢獻的相對少的量，另外的話，由於咱們的風控服務追求的是準確，因此只能犧牲分析師的時間效率，初期訓練模型的話，還須要分析師的複審以後篩選出新的樣本，擴充了樣本庫以後，再從新訓練如此反覆，反而增長了分析師的分析負擔。

訓練出來的模型通用性， 由於咱們服務的是各行業的客戶，各個客戶的現實問題各不相同，有的被爬蟲困擾，有的是活動營銷被薅羊毛，因此在每一個客戶的私有化部署環境裏面訓練出來的模型頗有多是不具有通用性的。

特徵的增長和篩選很糾結；當一些常見的統計特徵，例如總量、比率，都加上以後，可能就一百出頭的特徵，這時候訓練的效果並非太好 ，愁的是如何增長特徵，可是當咱們的特徵增長到十幾k的時候，訓練結果並無飛躍性的提高，這時候咱們愁的是如何自動化的篩選出徹底無關的特徵，特徵太多的時候，不只僅是沒法解釋，數據量過大，對於程序而言，還須要針對內存使用進行專門的優化。

由於錯誤懲罰的後果嚴重仍然沒法徹底脫離分析師的複審； 跟挑西瓜失敗不一樣的是，咱們不能簡單的重頭來過，由於這樣錯怪一個好人致使的結果極可能是客戶須要面對一個憤怒的正經常使用戶的投訴，一個失誤就可能引起對咱們系統可靠性的嚴重懷疑，面對如此嚴重的錯誤懲罰，因此咱們只能對於模型預測的風險再經過分析師的專家複審去尋求一個合理的解釋，才能加入到傳統策略引擎的風險預測的結果中。

成果

分析網頁重要性的解決方案

• 第一步，摺疊動態URL, 簡單說來就是經過將URL分層，經過配置的閾值來控制動態層次的整體大小 ，一旦超過閾值就自動摺疊， 最後的結果是咱們page頁面維度的對象數量降低了至少2個數量級，從通常幾十萬縮減到了幾千，咱們滿意了麼？尚未。
• 第二步，在摺疊URL的基礎上，構建網站的訪問圖，再進一步經過pagerank算法的計算和咱們本身累計的一些統計指標，分析得出流量入口、關鍵索引頁面、關鍵資源節點、必經路徑，一些黑名單頁面(例如404跳轉頁面), 而後再經過訪問流量構建這些關鍵節點之間的訪問關係圖，至此咱們成功的將page頁面維度的對象數量減小至小於100的常數級別。

基於機器學習的風險預測的解決方案

• 咱們在分析好的網站重要網頁關係圖上重放流量，根據統計的IP、用戶、設備的各類行爲做爲特徵，每一個小時跟策略引擎產生的風險IP、用戶、設備作新的樣本集，來繼續加強學習已有的模型，而且產出一些不在樣本集的風險IP、用戶、設備供給分析師作複審。
• 每一個小時會以上個小時的模型爲基礎，根據樣本集，來遍歷全部算法、自動調優全部的特徵，給出一個當前小時最佳模型。