揭秘:為什么一家風控公司要通過網頁重要性分析來進行機器學習?

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

主導各處的挖坑工作,擅長挖坑于悄然不息,負責生命不息,挖坑不止。

起源

1我們是誰,為什么要做這些

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

bigsec

2為什么要分析網站結構、網站關鍵路徑?

分析、計算成本的上升

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

報警監控

最基礎的監控可能只是針對訪問量、流量和一些服務器機器性能指標的,如果監控所有的頁面,又顯得目標太散,換句話說就是我們盯著全北京的所有路面情況全面標紅沒有意義,我們只關心我們到家的路徑上是否堵車,對客戶也是一樣,只關心核心資源、活動頁面這樣的關鍵節點是否被攻擊就足夠了。但是只是簡單的篩選出需要監控的頁面,監控其余所有頁面的系統資源也是一種奢侈的浪費,所以我們的結論就是:只監控我們關心的重要頁面就好,不關心多余的頁面,不需要多余的服務器計算資源,豈不是一步到位?

bigsec 北京交通流量全線標紅

bigsec 目的地: 家, 導航全綠

機器學習

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

3為什么要用機器學習來分析風險IP、用戶、設備?

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

人工分析的成本

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

過程

那么分析網站結構、網站關鍵路徑我們遇到了哪些坑呢?

理想中的架構

少量的網站入口,層次分明的訪問層級,每個關鍵資源都是這棵樹的一個葉子節點,一顆理想完美的網站樹結構,只要找到了網站的入口,剩下的問題只是遍歷圖中的路徑了,單純的筆者,一開始是這么以為的。

現實

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

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

  3. 單頁應用這樣動態前端的網站,隨著前后端分離的趨勢,跟App端流量類似的是業務、頁面訪問的邏輯都放到了前端,前端控制后端接口調用,所以我們只知道了用戶調用了什么接口,不知道用戶從哪里來在什么地方調用的接口。

  4. 很多URL是由像id這樣的動態內容構成的,所以沒人知道URL究竟有多少個。

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

理想情況

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

回歸現實

  1. 樣本少,靠人工復審效率也不高;因為每個客戶的實際情況不同,模型的通用性有待考證的情況下,初始樣本就只有傳統策略引擎貢獻的相對少的量,另外的話,因為我們的風控服務追求的是準確,所以只能犧牲分析師的時間效率,初期訓練模型的話,還需要分析師的復審之后篩選出新的樣本,擴充了樣本庫之后,再重新訓練如此反復,反而增加了分析師的分析負擔。

  2. 訓練出來的模型通用性, 因為我們服務的是各行業的客戶,各個客戶的現實問題各不相同,有的被爬蟲困擾,有的是活動營銷被薅羊毛,所以在每個客戶的私有化部署環境里面訓練出來的模型很有可能是不具備通用性的。

  3. 特征的增加和篩選很糾結;當一些常見的統計特征,例如總量、比率,都加上之后,可能就一百出頭的特征,這時候訓練的效果并不是太好 ,愁的是如何增加特征,但是當我們的特征增加到十幾k的時候,訓練結果并沒有飛躍性的提升,這時候我們愁的是如何自動化的篩選出完全無關的特征,特征太多的時候,不僅僅是無法解釋,數據量過大,對于程序而言,還需要針對內存使用進行專門的優化。

  4. 因為錯誤懲罰的后果嚴重仍然無法完全脫離分析師的復審; 跟挑西瓜失敗不同的是,我們不能簡單的重頭來過,因為這樣錯怪一個好人導致的結果很可能是客戶需要面對一個憤怒的正常用戶的投訴,一個失誤就可能引發對我們系統可靠性的嚴重懷疑,面對如此嚴重的錯誤懲罰,所以我們只能對于模型預測的風險再通過分析師的專家復審去尋求一個合理的解釋,才能加入到傳統策略引擎的風險預測的結果中。

成果

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

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

  • 第二步,在折疊URL的基礎上,構建網站的訪問圖,再進一步通過pagerank算法的計算和我們自己累計的一些統計指標,分析得出流量入口、關鍵索引頁面、關鍵資源節點、必經路徑,一些黑名單頁面(例如404跳轉頁面), 然后再通過訪問流量構建這些關鍵節點之間的訪問關系圖,至此我們成功的將page頁面維度的對象數量減少至小于100的常數級別。

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

  • 我們在分析好的網站重要網頁關系圖上重放流量,根據統計的IP、用戶、設備的各種行為作為特征,每個小時跟策略引擎產生的風險IP、用戶、設備做新的樣本集,來繼續增強學習已有的模型,并且產出一些不在樣本集的風險IP、用戶、設備供給分析師做復審。

  • 每個小時會以上個小時的模型為基礎,根據樣本集,來遍歷所有算法、自動調優所有的特征,給出一個當前小時最佳模型。

大发快3