架構(gòu)設(shè)計與工程實踐：規(guī)則、模型與名單的混合策略)
1. 智能風控系統(tǒng)到底在解決什么問題先把場景說清楚。任何一個有交易、有用戶注冊、有內(nèi)容發(fā)布的線上業(yè)務只要涉及到“錢”或者“資源分配”就一定會有人想鉆空子。薅羊毛的、刷單的、盜號的、騙補貼的手段層出不窮。我最早接觸風控是在一個電商促銷項目里活動上線不到兩小時后臺就發(fā)現(xiàn)有一批賬號在瘋狂領(lǐng)券IP地址集中在幾個網(wǎng)段收貨地址高度相似。當時全靠人工封號運營同學盯著后臺一條條看效率極低還容易誤傷真實用戶。智能風控系統(tǒng)要干的事情說白了就是在毫秒級的時間內(nèi)判斷一筆請求“像不像壞人干的”。它不像傳統(tǒng)規(guī)則引擎那樣只靠幾條死規(guī)則而是結(jié)合了規(guī)則、模型、名單、畫像等多種手段動態(tài)地給出一個風險評分再根據(jù)評分決定放行、攔截還是二次驗證。這套東西適合誰看如果你是后端開發(fā)、數(shù)據(jù)開發(fā)、策略產(chǎn)品經(jīng)理或者正在從零搭建風控體系那下面的內(nèi)容應該能幫你少走不少彎路。我見過不少團隊一開始就想上深度學習模型結(jié)果連基礎(chǔ)的數(shù)據(jù)采集都沒做好模型跑出來的結(jié)果根本沒法解釋策略同學也不敢用。所以這篇文章我會從整體架構(gòu)講到具體實現(xiàn)把每一步的“為什么”都掰開說清楚。2. 整體架構(gòu)設(shè)計與核心模塊拆解2.1 為什么選擇“規(guī)則模型名單”的混合架構(gòu)純規(guī)則引擎的問題在于滯后性。你今天發(fā)現(xiàn)一個漏洞寫一條規(guī)則堵上明天黑產(chǎn)換個手法規(guī)則就失效了。純模型的問題在于冷啟動和可解釋性。新業(yè)務上線第一天沒有標注數(shù)據(jù)模型根本訓不出來就算訓出來了策略同學看到一個“0.87的風險分”也不知道該怎么跟老板解釋為什么攔截了這筆請求。所以業(yè)內(nèi)比較成熟的做法是三層混合名單層黑白名單命中直接放行或攔截響應時間在微秒級。黑名單來源包括歷史確認的欺詐賬號、設(shè)備指紋、IP等。規(guī)則層由策略同學配置的專家規(guī)則比如“同一設(shè)備一小時內(nèi)注冊超過5個賬號”“同一IP十分鐘內(nèi)下單超過20筆”。規(guī)則的好處是解釋性強壞處是需要不斷維護。模型層用機器學習模型對用戶行為、設(shè)備信息、交易特征進行綜合評分。模型負責發(fā)現(xiàn)那些規(guī)則覆蓋不到的、隱蔽的異常模式。這三層的執(zhí)行順序通常是先查名單再過規(guī)則最后跑模型。但也不是絕對的有些場景下模型會前置比如對高風險交易做實時評分規(guī)則只作為兜底。注意不要一上來就把三層都做全。我建議先從名單規(guī)則起步等積累了足夠的數(shù)據(jù)和標注樣本再引入模型。否則模型就是個黑盒擺設(shè)。2.2 數(shù)據(jù)采集層風控的“眼睛”和“耳朵”風控系統(tǒng)最核心的資產(chǎn)不是模型是數(shù)據(jù)。沒有高質(zhì)量的數(shù)據(jù)采集后面全是空中樓閣。數(shù)據(jù)采集主要分三塊第一塊是設(shè)備指紋。通過采集設(shè)備的硬件信息、瀏覽器特征、網(wǎng)絡特征等生成一個相對穩(wěn)定的設(shè)備ID。這樣即使用戶換賬號我們也能識別出是同一臺設(shè)備。設(shè)備指紋的穩(wěn)定性很關(guān)鍵我實測下來單純用User-Agent加屏幕分辨率碰撞率太高至少要把Canvas指紋、WebGL指紋、字體列表、時區(qū)這些維度都加上。第二塊是行為數(shù)據(jù)。包括用戶的點擊流、頁面停留時長、輸入速度、滑動軌跡等。黑產(chǎn)用腳本操作和真人操作在行為特征上有明顯差異。比如真人輸入密碼會有停頓和修正腳本則是一氣呵成。這些數(shù)據(jù)采集時要注意脫敏不能記錄用戶的密碼等敏感信息。第三塊是業(yè)務數(shù)據(jù)。訂單金額、收貨地址、支付方式、商品類型等。這些數(shù)據(jù)來自業(yè)務系統(tǒng)通過消息隊列異步同步到風控系統(tǒng)。這里有個坑如果同步延遲太高風控決策時拿不到最新的業(yè)務數(shù)據(jù)就會導致誤判。我們當時要求同步延遲控制在200毫秒以內(nèi)。2.3 實時計算層毫秒級決策的工程挑戰(zhàn)風控決策對延遲極其敏感。用戶點“提交訂單”之后如果風控系統(tǒng)要跑個兩三秒才返回結(jié)果用戶體驗直接崩了。所以實時計算層必須做到高吞吐、低延遲。我們當時的架構(gòu)是這樣的請求先進入接入層做限流和降級然后并行調(diào)用名單服務、規(guī)則引擎和模型服務最后在聚合層做綜合決策。并行調(diào)用是關(guān)鍵串行的話時間就是三者之和并行的話取決于最慢的那個。規(guī)則引擎我們選的是基于Rete算法的實現(xiàn)把規(guī)則編譯成網(wǎng)絡避免每次請求都重新匹配所有規(guī)則。模型服務用的是TensorFlow Serving把模型加載到內(nèi)存里支持熱更新。這里有個經(jīng)驗模型推理的耗時主要花在特征拉取上而不是模型計算本身。所以特征存儲一定要用低延遲的KV數(shù)據(jù)庫比如Redis或者本地緩存。模塊技術(shù)選型延遲要求備注名單服務Redis 本地緩存 5ms布隆過濾器防穿透規(guī)則引擎Rete算法實現(xiàn) 20ms規(guī)則數(shù)量控制在500條以內(nèi)模型服務TensorFlow Serving 50ms特征預計算緩存聚合決策內(nèi)存計算 5ms加權(quán)評分閾值判斷2.4 離線計算層模型訓練與策略迭代離線層主要負責三件事特征工程、模型訓練、策略效果評估。特征工程是最耗時的大概占整個流程70%的時間。我們當時建了一個特征平臺把常用的特征如用戶近7天交易次數(shù)、近30天退款率預計算好存到Hive表里模型訓練時直接讀取。模型訓練方面我們用的是XGBoost和LightGBM因為它們在表格數(shù)據(jù)上表現(xiàn)穩(wěn)定訓練速度快而且能輸出特征重要性方便策略同學理解。深度學習模型我們也試過但在我們的場景下提升不明顯反而增加了維護成本。策略效果評估是個容易被忽視的環(huán)節(jié)。新策略上線前一定要做離線回測和AB實驗。離線回測是用歷史數(shù)據(jù)模擬新策略的效果看攔截率和誤殺率的變化。AB實驗是把流量分桶一部分走新策略一部分走老策略對比實際效果。這里要注意AB實驗的周期要足夠長至少覆蓋一個完整的業(yè)務周期否則結(jié)論不可靠。3. 核心細節(jié)解析與實操要點3.1 設(shè)備指紋的生成與穩(wěn)定性優(yōu)化設(shè)備指紋是風控的基石。如果設(shè)備指紋不穩(wěn)定同一個設(shè)備每次生成的ID都不一樣那基于設(shè)備的規(guī)則和模型全都失效。我們踩過的坑是早期只用瀏覽器UA和IP做指紋結(jié)果用戶換個網(wǎng)絡、升級個瀏覽器指紋就變了。后來我們改成多維度加權(quán)的方式主要維度包括硬件維度CPU核心數(shù)、內(nèi)存大小、顯卡型號、屏幕分辨率瀏覽器維度User-Agent、語言、時區(qū)、插件列表、Canvas指紋、WebGL指紋網(wǎng)絡維度IP段、DNS服務器、TCP指紋每個維度算一個哈希值然后按權(quán)重組合成最終指紋。權(quán)重是根據(jù)歷史數(shù)據(jù)統(tǒng)計出來的穩(wěn)定性越高的維度權(quán)重越大。比如Canvas指紋的穩(wěn)定性就比IP高很多。實操心得設(shè)備指紋不要追求100%準確能達到95%以上的穩(wěn)定性就夠用了。剩下的5%可以通過行為特征來彌補。3.2 規(guī)則引擎的規(guī)則編排與沖突處理規(guī)則引擎的核心是規(guī)則編排。我們當時支持三種規(guī)則類型簡單規(guī)則單條件判斷如“訂單金額 10000”組合規(guī)則多條件與或非如“訂單金額 5000 且 收貨地址與歷史地址不一致”統(tǒng)計規(guī)則基于時間窗口的統(tǒng)計如“同一設(shè)備1小時內(nèi)下單超過10筆”規(guī)則沖突是常見問題。比如規(guī)則A說“命中黑名單設(shè)備直接攔截”規(guī)則B說“VIP用戶放行”。如果一個VIP用戶用了黑名單設(shè)備到底聽誰的我們的做法是給每條規(guī)則設(shè)置優(yōu)先級優(yōu)先級高的先執(zhí)行并且一旦命中攔截規(guī)則就不再執(zhí)行后續(xù)規(guī)則。規(guī)則的數(shù)量也要控制。我們實測下來規(guī)則超過500條之后匹配耗時會明顯上升。所以定期做規(guī)則清理很重要把長期沒有命中的規(guī)則下線把效果相似的規(guī)則合并。3.3 模型特征的選擇與處理模型效果好不好八成看特征。我們當時選了大概200個特征主要分四類用戶畫像特征注冊時長、歷史交易次數(shù)、歷史退款率、會員等級設(shè)備特征設(shè)備指紋、設(shè)備類型、操作系統(tǒng)、是否模擬器行為特征頁面停留時長、點擊次數(shù)、輸入速度、操作間隔業(yè)務特征訂單金額、商品類別、支付方式、收貨地址特征處理要注意幾點一是缺失值填充有些特征在冷啟動階段是空的我們用均值或者特殊值填充二是歸一化不同特征的量綱差異很大不做歸一化會影響模型收斂三是特征穿越訓練時不能用未來數(shù)據(jù)這個坑很隱蔽一定要在特征平臺層面做好時間對齊。3.4 風險評分的融合與閾值設(shè)定名單、規(guī)則、模型各自輸出一個風險分最后要融合成一個總分。我們用的是加權(quán)求和的方式總分 w1 * 名單分 w2 * 規(guī)則分 w3 * 模型分權(quán)重是根據(jù)業(yè)務經(jīng)驗設(shè)定的名單分權(quán)重最高因為命中黑名單基本就是確認的欺詐。規(guī)則分和模型分權(quán)重相近但會根據(jù)場景調(diào)整。比如促銷活動期間規(guī)則分權(quán)重會調(diào)高因為活動期間規(guī)則更精準。閾值的設(shè)定是個博弈過程。閾值太高攔截率低黑產(chǎn)容易漏過閾值太低誤殺率高真實用戶會投訴。我們的做法是先用歷史數(shù)據(jù)畫一條ROC曲線找到攔截率和誤殺率的平衡點然后在這個點附近做小范圍調(diào)整觀察實際效果。總分區(qū)間決策說明0-30放行低風險直接通過30-70二次驗證中風險觸發(fā)短信驗證或人工審核70-100攔截高風險直接拒絕4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 從零搭建風控系統(tǒng)的完整步驟如果你現(xiàn)在要從零開始搭一套風控系統(tǒng)我建議按下面的順序來第一步梳理業(yè)務場景和風險點。先搞清楚你的業(yè)務有哪些地方可能被薅、被刷、被騙。比如注冊環(huán)節(jié)有批量注冊登錄環(huán)節(jié)有撞庫下單環(huán)節(jié)有刷單支付環(huán)節(jié)有盜刷。每個場景的風險特征不一樣需要的策略也不一樣。第二步搭建數(shù)據(jù)采集管道。前端埋點采集設(shè)備和行為數(shù)據(jù)后端通過消息隊列同步業(yè)務數(shù)據(jù)。數(shù)據(jù)統(tǒng)一寫入數(shù)據(jù)倉庫實時部分走Flink計算離線部分走Spark。第三步實現(xiàn)名單服務。先用Redis做一個簡單的黑白名單支持增刪改查和批量導入。名單來源可以是歷史封禁賬號、第三方共享名單、人工審核確認的欺詐賬號。第四步實現(xiàn)規(guī)則引擎。可以先從硬編碼開始把規(guī)則寫在配置文件里每次請求加載配置進行匹配。等規(guī)則多了再考慮上專業(yè)的規(guī)則引擎。第五步接入模型服務。先用離線數(shù)據(jù)訓練一個簡單的邏輯回歸模型跑通整個流程。等數(shù)據(jù)量大了再換XGBoost或者LightGBM。第六步搭建監(jiān)控和告警。監(jiān)控攔截率、誤殺率、請求延遲等核心指標設(shè)置告警閾值。一旦指標異常及時排查。4.2 實時決策流程的代碼實現(xiàn)下面是一個簡化的實時決策流程用Python偽代碼展示def risk_decision(request): # 1. 查名單 if blacklist_service.contains(request.device_id): return Decision.REJECT, blacklist_device if whitelist_service.contains(request.user_id): return Decision.PASS, whitelist_user # 2. 過規(guī)則 rule_score rule_engine.evaluate(request) # 3. 跑模型 features feature_service.get_features(request) model_score model_service.predict(features) # 4. 融合評分 total_score 0.5 * rule_score 0.5 * model_score # 5. 閾值判斷 if total_score 70: return Decision.REJECT, high_risk elif total_score 30: return Decision.CHALLENGE, medium_risk else: return Decision.PASS, low_risk這段代碼看起來簡單但每個環(huán)節(jié)都有講究。比如名單查詢要用布隆過濾器防止緩存穿透規(guī)則引擎要支持熱更新模型服務要支持多版本灰度。4.3 特征計算的性能優(yōu)化特征計算是實時決策中最耗時的部分。我們當時的優(yōu)化手段包括預計算把一些變化不頻繁的特征如用戶近30天交易次數(shù)提前算好存到Redis里實時請求直接讀取。批量拉取一次請求需要多個特征時用pipeline批量從Redis拉取減少網(wǎng)絡往返。本地緩存在應用層加一層本地緩存緩存那些短時間內(nèi)不會變的特征比如用戶注冊時長。降級策略如果特征服務超時用默認值填充保證決策流程不阻塞。注意降級策略一定要有但降級后的決策要打標方便后續(xù)分析。我們當時因為降級導致誤殺了一批用戶后來在決策日志里加了降級標記才定位到問題。4.4 策略上線的灰度與回滾新策略上線絕對不能全量推。我們的流程是離線回測用歷史數(shù)據(jù)跑一遍新策略對比老策略的攔截率和誤殺率。小流量灰度切1%的流量走新策略觀察24小時。擴大灰度如果指標正常逐步擴大到10%、50%。全量上線確認無誤后全量推送?；貪L預案一旦發(fā)現(xiàn)異常立即切回老策略?；叶绕陂g要重點觀察誤殺率。如果誤殺率上升超過0.5%就要暫?；叶扰挪樵颉Ｎ覀儺敃r有一次灰度誤殺率突然飆升后來發(fā)現(xiàn)是新策略里用了一個新特征而這個特征在部分用戶上是空的導致模型評分偏高。5. 常見問題與排查技巧實錄5.1 誤殺率突然升高怎么排查誤殺率升高是最常見也最頭疼的問題。排查思路一般是先看是不是數(shù)據(jù)問題特征服務有沒有超時名單服務有沒有誤命中消息隊列有沒有積壓再看是不是策略問題最近有沒有上線新規(guī)則或新模型如果有先回滾。最后看是不是業(yè)務問題業(yè)務有沒有做活動有沒有新用戶大量涌入這些都會導致行為模式變化。我們當時遇到過一次誤殺率飆升排查了半天發(fā)現(xiàn)是設(shè)備指紋服務升級導致部分設(shè)備的指紋變了觸發(fā)了“設(shè)備異常”規(guī)則。后來我們在設(shè)備指紋服務加了兼容層新舊指紋同時保留一段時間才解決了問題。5.2 黑產(chǎn)繞過策略的常見手法與應對黑產(chǎn)繞過策略的手法一直在進化常見的包括改設(shè)備用模擬器、改機工具修改設(shè)備信息。應對方法是加強設(shè)備指紋的維度檢測模擬器特征。養(yǎng)號批量注冊賬號后養(yǎng)一段時間再使用。應對方法是分析賬號的行為軌跡養(yǎng)號賬號的行為模式通常很單一。分散操作用大量賬號小額操作避免觸發(fā)統(tǒng)計規(guī)則。應對方法是做關(guān)聯(lián)分析把同一設(shè)備、同一IP、同一收貨地址的賬號關(guān)聯(lián)起來。代理IP用代理IP池切換IP。應對方法是檢測IP的異常特征比如IP段是否來自數(shù)據(jù)中心。實操心得不要試圖一次性堵住所有漏洞。風控是個持續(xù)對抗的過程關(guān)鍵是建立快速響應機制發(fā)現(xiàn)新手法后能快速上線新策略。5.3 模型效果衰減怎么辦模型上線一段時間后效果會逐漸衰減因為黑產(chǎn)的手法在變用戶的行為也在變。應對方法包括定期重訓每周或每兩周用最新數(shù)據(jù)重新訓練模型。在線學習對于變化快的場景可以用在線學習的方式讓模型實時更新。特征監(jiān)控監(jiān)控特征的分布變化一旦發(fā)現(xiàn)某個特征的分布偏移嚴重就要排查原因。模型融合用多個模型投票降低單模型衰減的影響。我們當時的做法是每周重訓一次同時保留一個老版本模型做兜底。如果新模型效果不好可以快速切回老模型。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案誤殺率升高新策略上線對比新舊策略決策日志回滾策略誤殺率升高特征服務異常檢查特征服務監(jiān)控修復特征服務攔截率下降黑產(chǎn)繞過分析攔截失敗案例更新策略決策延遲升高規(guī)則過多檢查規(guī)則數(shù)量和匹配耗時清理規(guī)則決策延遲升高模型推理慢檢查模型服務和特征拉取耗時優(yōu)化特征緩存名單誤命中名單數(shù)據(jù)錯誤檢查名單導入日志修正名單數(shù)據(jù)5.5 風控系統(tǒng)的監(jiān)控體系監(jiān)控是風控系統(tǒng)的生命線。我們當時監(jiān)控的指標分三類業(yè)務指標攔截率、誤殺率、二次驗證率、投訴率。這些指標直接反映風控效果。技術(shù)指標請求量、響應時間、錯誤率、超時率。這些指標反映系統(tǒng)健康度。數(shù)據(jù)指標特征覆蓋率、特征分布、模型評分分布。這些指標反映數(shù)據(jù)質(zhì)量。每類指標都要設(shè)置告警閾值。比如誤殺率超過1%告警響應時間超過100ms告警。告警要能快速定位到具體模塊所以我們給每個模塊都加了獨立的監(jiān)控面板。6. 一些踩坑后的個人體會風控系統(tǒng)不是建好就完事了它更像一個需要持續(xù)運營的產(chǎn)品。我最大的體會是策略、數(shù)據(jù)、工程三者缺一不可。策略同學懂業(yè)務但不懂工程工程同學懂技術(shù)但不懂業(yè)務數(shù)據(jù)同學懂模型但不懂策略三者之間需要大量的溝通和協(xié)作。另外不要迷信模型。模型能解決一部分問題但解決不了所有問題。很多場景下一條簡單的規(guī)則比模型更有效。關(guān)鍵是找到規(guī)則和模型的平衡點讓它們各自發(fā)揮優(yōu)勢。最后分享一個小技巧每次策略上線后一定要做決策日志的抽樣分析。隨機抽100條攔截記錄人工看看有多少是誤殺。這個工作很枯燥但能發(fā)現(xiàn)很多自動化監(jiān)控發(fā)現(xiàn)不了的問題。我們當時就是通過抽樣分析發(fā)現(xiàn)了一個規(guī)則在特定場景下的誤判及時做了修正。 智能風控系統(tǒng)架構(gòu)設(shè)計與工程實踐：規(guī)則、模型與名單的混合策略
1. 智能風控系統(tǒng)到底在解決什么問題先把場景說清楚。任何一個有交易、有用戶注冊、有內(nèi)容發(fā)布的線上業(yè)務只要涉及到“錢”或者“資源分配”就一定會有人想鉆空子。薅羊毛的、刷單的、盜號的、騙補貼的手段層出不窮。我最早接觸風控是在一個電商促銷項目里活動上線不到兩小時后臺就發(fā)現(xiàn)有一批賬號在瘋狂領(lǐng)券IP地址集中在幾個網(wǎng)段收貨地址高度相似。當時全靠人工封號運營同學盯著后臺一條條看效率極低還容易誤傷真實用戶。智能風控系統(tǒng)要干的事情說白了就是在毫秒級的時間內(nèi)判斷一筆請求“像不像壞人干的”。它不像傳統(tǒng)規(guī)則引擎那樣只靠幾條死規(guī)則而是結(jié)合了規(guī)則、模型、名單、畫像等多種手段動態(tài)地給出一個風險評分再根據(jù)評分決定放行、攔截還是二次驗證。這套東西適合誰看如果你是后端開發(fā)、數(shù)據(jù)開發(fā)、策略產(chǎn)品經(jīng)理或者正在從零搭建風控體系那下面的內(nèi)容應該能幫你少走不少彎路。我見過不少團隊一開始就想上深度學習模型結(jié)果連基礎(chǔ)的數(shù)據(jù)采集都沒做好模型跑出來的結(jié)果根本沒法解釋策略同學也不敢用。所以這篇文章我會從整體架構(gòu)講到具體實現(xiàn)把每一步的“為什么”都掰開說清楚。2. 整體架構(gòu)設(shè)計與核心模塊拆解2.1 為什么選擇“規(guī)則模型名單”的混合架構(gòu)純規(guī)則引擎的問題在于滯后性。你今天發(fā)現(xiàn)一個漏洞寫一條規(guī)則堵上明天黑產(chǎn)換個手法規(guī)則就失效了。純模型的問題在于冷啟動和可解釋性。新業(yè)務上線第一天沒有標注數(shù)據(jù)模型根本訓不出來就算訓出來了策略同學看到一個“0.87的風險分”也不知道該怎么跟老板解釋為什么攔截了這筆請求。所以業(yè)內(nèi)比較成熟的做法是三層混合名單層黑白名單命中直接放行或攔截響應時間在微秒級。黑名單來源包括歷史確認的欺詐賬號、設(shè)備指紋、IP等。規(guī)則層由策略同學配置的專家規(guī)則比如“同一設(shè)備一小時內(nèi)注冊超過5個賬號”“同一IP十分鐘內(nèi)下單超過20筆”。規(guī)則的好處是解釋性強壞處是需要不斷維護。模型層用機器學習模型對用戶行為、設(shè)備信息、交易特征進行綜合評分。模型負責發(fā)現(xiàn)那些規(guī)則覆蓋不到的、隱蔽的異常模式。這三層的執(zhí)行順序通常是先查名單再過規(guī)則最后跑模型。但也不是絕對的有些場景下模型會前置比如對高風險交易做實時評分規(guī)則只作為兜底。注意不要一上來就把三層都做全。我建議先從名單規(guī)則起步等積累了足夠的數(shù)據(jù)和標注樣本再引入模型。否則模型就是個黑盒擺設(shè)。2.2 數(shù)據(jù)采集層風控的“眼睛”和“耳朵”風控系統(tǒng)最核心的資產(chǎn)不是模型是數(shù)據(jù)。沒有高質(zhì)量的數(shù)據(jù)采集后面全是空中樓閣。數(shù)據(jù)采集主要分三塊第一塊是設(shè)備指紋。通過采集設(shè)備的硬件信息、瀏覽器特征、網(wǎng)絡特征等生成一個相對穩(wěn)定的設(shè)備ID。這樣即使用戶換賬號我們也能識別出是同一臺設(shè)備。設(shè)備指紋的穩(wěn)定性很關(guān)鍵我實測下來單純用User-Agent加屏幕分辨率碰撞率太高至少要把Canvas指紋、WebGL指紋、字體列表、時區(qū)這些維度都加上。第二塊是行為數(shù)據(jù)。包括用戶的點擊流、頁面停留時長、輸入速度、滑動軌跡等。黑產(chǎn)用腳本操作和真人操作在行為特征上有明顯差異。比如真人輸入密碼會有停頓和修正腳本則是一氣呵成。這些數(shù)據(jù)采集時要注意脫敏不能記錄用戶的密碼等敏感信息。第三塊是業(yè)務數(shù)據(jù)。訂單金額、收貨地址、支付方式、商品類型等。這些數(shù)據(jù)來自業(yè)務系統(tǒng)通過消息隊列異步同步到風控系統(tǒng)。這里有個坑如果同步延遲太高風控決策時拿不到最新的業(yè)務數(shù)據(jù)就會導致誤判。我們當時要求同步延遲控制在200毫秒以內(nèi)。2.3 實時計算層毫秒級決策的工程挑戰(zhàn)風控決策對延遲極其敏感。用戶點“提交訂單”之后如果風控系統(tǒng)要跑個兩三秒才返回結(jié)果用戶體驗直接崩了。所以實時計算層必須做到高吞吐、低延遲。我們當時的架構(gòu)是這樣的請求先進入接入層做限流和降級然后并行調(diào)用名單服務、規(guī)則引擎和模型服務最后在聚合層做綜合決策。并行調(diào)用是關(guān)鍵串行的話時間就是三者之和并行的話取決于最慢的那個。規(guī)則引擎我們選的是基于Rete算法的實現(xiàn)把規(guī)則編譯成網(wǎng)絡避免每次請求都重新匹配所有規(guī)則。模型服務用的是TensorFlow Serving把模型加載到內(nèi)存里支持熱更新。這里有個經(jīng)驗模型推理的耗時主要花在特征拉取上而不是模型計算本身。所以特征存儲一定要用低延遲的KV數(shù)據(jù)庫比如Redis或者本地緩存。模塊技術(shù)選型延遲要求備注名單服務Redis 本地緩存 5ms布隆過濾器防穿透規(guī)則引擎Rete算法實現(xiàn) 20ms規(guī)則數(shù)量控制在500條以內(nèi)模型服務TensorFlow Serving 50ms特征預計算緩存聚合決策內(nèi)存計算 5ms加權(quán)評分閾值判斷2.4 離線計算層模型訓練與策略迭代離線層主要負責三件事特征工程、模型訓練、策略效果評估。特征工程是最耗時的大概占整個流程70%的時間。我們當時建了一個特征平臺把常用的特征如用戶近7天交易次數(shù)、近30天退款率預計算好存到Hive表里模型訓練時直接讀取。模型訓練方面我們用的是XGBoost和LightGBM因為它們在表格數(shù)據(jù)上表現(xiàn)穩(wěn)定訓練速度快而且能輸出特征重要性方便策略同學理解。深度學習模型我們也試過但在我們的場景下提升不明顯反而增加了維護成本。策略效果評估是個容易被忽視的環(huán)節(jié)。新策略上線前一定要做離線回測和AB實驗。離線回測是用歷史數(shù)據(jù)模擬新策略的效果看攔截率和誤殺率的變化。AB實驗是把流量分桶一部分走新策略一部分走老策略對比實際效果。這里要注意AB實驗的周期要足夠長至少覆蓋一個完整的業(yè)務周期否則結(jié)論不可靠。3. 核心細節(jié)解析與實操要點3.1 設(shè)備指紋的生成與穩(wěn)定性優(yōu)化設(shè)備指紋是風控的基石。如果設(shè)備指紋不穩(wěn)定同一個設(shè)備每次生成的ID都不一樣那基于設(shè)備的規(guī)則和模型全都失效。我們踩過的坑是早期只用瀏覽器UA和IP做指紋結(jié)果用戶換個網(wǎng)絡、升級個瀏覽器指紋就變了。后來我們改成多維度加權(quán)的方式主要維度包括硬件維度CPU核心數(shù)、內(nèi)存大小、顯卡型號、屏幕分辨率瀏覽器維度User-Agent、語言、時區(qū)、插件列表、Canvas指紋、WebGL指紋網(wǎng)絡維度IP段、DNS服務器、TCP指紋每個維度算一個哈希值然后按權(quán)重組合成最終指紋。權(quán)重是根據(jù)歷史數(shù)據(jù)統(tǒng)計出來的穩(wěn)定性越高的維度權(quán)重越大。比如Canvas指紋的穩(wěn)定性就比IP高很多。實操心得設(shè)備指紋不要追求100%準確能達到95%以上的穩(wěn)定性就夠用了。剩下的5%可以通過行為特征來彌補。3.2 規(guī)則引擎的規(guī)則編排與沖突處理規(guī)則引擎的核心是規(guī)則編排。我們當時支持三種規(guī)則類型簡單規(guī)則單條件判斷如“訂單金額 10000”組合規(guī)則多條件與或非如“訂單金額 5000 且 收貨地址與歷史地址不一致”統(tǒng)計規(guī)則基于時間窗口的統(tǒng)計如“同一設(shè)備1小時內(nèi)下單超過10筆”規(guī)則沖突是常見問題。比如規(guī)則A說“命中黑名單設(shè)備直接攔截”規(guī)則B說“VIP用戶放行”。如果一個VIP用戶用了黑名單設(shè)備到底聽誰的我們的做法是給每條規(guī)則設(shè)置優(yōu)先級優(yōu)先級高的先執(zhí)行并且一旦命中攔截規(guī)則就不再執(zhí)行后續(xù)規(guī)則。規(guī)則的數(shù)量也要控制。我們實測下來規(guī)則超過500條之后匹配耗時會明顯上升。所以定期做規(guī)則清理很重要把長期沒有命中的規(guī)則下線把效果相似的規(guī)則合并。3.3 模型特征的選擇與處理模型效果好不好八成看特征。我們當時選了大概200個特征主要分四類用戶畫像特征注冊時長、歷史交易次數(shù)、歷史退款率、會員等級設(shè)備特征設(shè)備指紋、設(shè)備類型、操作系統(tǒng)、是否模擬器行為特征頁面停留時長、點擊次數(shù)、輸入速度、操作間隔業(yè)務特征訂單金額、商品類別、支付方式、收貨地址特征處理要注意幾點一是缺失值填充有些特征在冷啟動階段是空的我們用均值或者特殊值填充二是歸一化不同特征的量綱差異很大不做歸一化會影響模型收斂三是特征穿越訓練時不能用未來數(shù)據(jù)這個坑很隱蔽一定要在特征平臺層面做好時間對齊。3.4 風險評分的融合與閾值設(shè)定名單、規(guī)則、模型各自輸出一個風險分最后要融合成一個總分。我們用的是加權(quán)求和的方式總分 w1 * 名單分 w2 * 規(guī)則分 w3 * 模型分權(quán)重是根據(jù)業(yè)務經(jīng)驗設(shè)定的名單分權(quán)重最高因為命中黑名單基本就是確認的欺詐。規(guī)則分和模型分權(quán)重相近但會根據(jù)場景調(diào)整。比如促銷活動期間規(guī)則分權(quán)重會調(diào)高因為活動期間規(guī)則更精準。閾值的設(shè)定是個博弈過程。閾值太高攔截率低黑產(chǎn)容易漏過閾值太低誤殺率高真實用戶會投訴。我們的做法是先用歷史數(shù)據(jù)畫一條ROC曲線找到攔截率和誤殺率的平衡點然后在這個點附近做小范圍調(diào)整觀察實際效果。總分區(qū)間決策說明0-30放行低風險直接通過30-70二次驗證中風險觸發(fā)短信驗證或人工審核70-100攔截高風險直接拒絕4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 從零搭建風控系統(tǒng)的完整步驟如果你現(xiàn)在要從零開始搭一套風控系統(tǒng)我建議按下面的順序來第一步梳理業(yè)務場景和風險點。先搞清楚你的業(yè)務有哪些地方可能被薅、被刷、被騙。比如注冊環(huán)節(jié)有批量注冊登錄環(huán)節(jié)有撞庫下單環(huán)節(jié)有刷單支付環(huán)節(jié)有盜刷。每個場景的風險特征不一樣需要的策略也不一樣。第二步搭建數(shù)據(jù)采集管道。前端埋點采集設(shè)備和行為數(shù)據(jù)后端通過消息隊列同步業(yè)務數(shù)據(jù)。數(shù)據(jù)統(tǒng)一寫入數(shù)據(jù)倉庫實時部分走Flink計算離線部分走Spark。第三步實現(xiàn)名單服務。先用Redis做一個簡單的黑白名單支持增刪改查和批量導入。名單來源可以是歷史封禁賬號、第三方共享名單、人工審核確認的欺詐賬號。第四步實現(xiàn)規(guī)則引擎。可以先從硬編碼開始把規(guī)則寫在配置文件里每次請求加載配置進行匹配。等規(guī)則多了再考慮上專業(yè)的規(guī)則引擎。第五步接入模型服務。先用離線數(shù)據(jù)訓練一個簡單的邏輯回歸模型跑通整個流程。等數(shù)據(jù)量大了再換XGBoost或者LightGBM。第六步搭建監(jiān)控和告警。監(jiān)控攔截率、誤殺率、請求延遲等核心指標設(shè)置告警閾值。一旦指標異常及時排查。4.2 實時決策流程的代碼實現(xiàn)下面是一個簡化的實時決策流程用Python偽代碼展示def risk_decision(request): # 1. 查名單 if blacklist_service.contains(request.device_id): return Decision.REJECT, blacklist_device if whitelist_service.contains(request.user_id): return Decision.PASS, whitelist_user # 2. 過規(guī)則 rule_score rule_engine.evaluate(request) # 3. 跑模型 features feature_service.get_features(request) model_score model_service.predict(features) # 4. 融合評分 total_score 0.5 * rule_score 0.5 * model_score # 5. 閾值判斷 if total_score 70: return Decision.REJECT, high_risk elif total_score 30: return Decision.CHALLENGE, medium_risk else: return Decision.PASS, low_risk這段代碼看起來簡單但每個環(huán)節(jié)都有講究。比如名單查詢要用布隆過濾器防止緩存穿透規(guī)則引擎要支持熱更新模型服務要支持多版本灰度。4.3 特征計算的性能優(yōu)化特征計算是實時決策中最耗時的部分。我們當時的優(yōu)化手段包括預計算把一些變化不頻繁的特征如用戶近30天交易次數(shù)提前算好存到Redis里實時請求直接讀取。批量拉取一次請求需要多個特征時用pipeline批量從Redis拉取減少網(wǎng)絡往返。本地緩存在應用層加一層本地緩存緩存那些短時間內(nèi)不會變的特征比如用戶注冊時長。降級策略如果特征服務超時用默認值填充保證決策流程不阻塞。注意降級策略一定要有但降級后的決策要打標方便后續(xù)分析。我們當時因為降級導致誤殺了一批用戶后來在決策日志里加了降級標記才定位到問題。4.4 策略上線的灰度與回滾新策略上線絕對不能全量推。我們的流程是離線回測用歷史數(shù)據(jù)跑一遍新策略對比老策略的攔截率和誤殺率。小流量灰度切1%的流量走新策略觀察24小時。擴大灰度如果指標正常逐步擴大到10%、50%。全量上線確認無誤后全量推送?；貪L預案一旦發(fā)現(xiàn)異常立即切回老策略?；叶绕陂g要重點觀察誤殺率。如果誤殺率上升超過0.5%就要暫?；叶扰挪樵颉Ｎ覀儺敃r有一次灰度誤殺率突然飆升后來發(fā)現(xiàn)是新策略里用了一個新特征而這個特征在部分用戶上是空的導致模型評分偏高。5. 常見問題與排查技巧實錄5.1 誤殺率突然升高怎么排查誤殺率升高是最常見也最頭疼的問題。排查思路一般是先看是不是數(shù)據(jù)問題特征服務有沒有超時名單服務有沒有誤命中消息隊列有沒有積壓再看是不是策略問題最近有沒有上線新規(guī)則或新模型如果有先回滾。最后看是不是業(yè)務問題業(yè)務有沒有做活動有沒有新用戶大量涌入這些都會導致行為模式變化。我們當時遇到過一次誤殺率飆升排查了半天發(fā)現(xiàn)是設(shè)備指紋服務升級導致部分設(shè)備的指紋變了觸發(fā)了“設(shè)備異常”規(guī)則。后來我們在設(shè)備指紋服務加了兼容層新舊指紋同時保留一段時間才解決了問題。5.2 黑產(chǎn)繞過策略的常見手法與應對黑產(chǎn)繞過策略的手法一直在進化常見的包括改設(shè)備用模擬器、改機工具修改設(shè)備信息。應對方法是加強設(shè)備指紋的維度檢測模擬器特征。養(yǎng)號批量注冊賬號后養(yǎng)一段時間再使用。應對方法是分析賬號的行為軌跡養(yǎng)號賬號的行為模式通常很單一。分散操作用大量賬號小額操作避免觸發(fā)統(tǒng)計規(guī)則。應對方法是做關(guān)聯(lián)分析把同一設(shè)備、同一IP、同一收貨地址的賬號關(guān)聯(lián)起來。代理IP用代理IP池切換IP。應對方法是檢測IP的異常特征比如IP段是否來自數(shù)據(jù)中心。實操心得不要試圖一次性堵住所有漏洞。風控是個持續(xù)對抗的過程關(guān)鍵是建立快速響應機制發(fā)現(xiàn)新手法后能快速上線新策略。5.3 模型效果衰減怎么辦模型上線一段時間后效果會逐漸衰減因為黑產(chǎn)的手法在變用戶的行為也在變。應對方法包括定期重訓每周或每兩周用最新數(shù)據(jù)重新訓練模型。在線學習對于變化快的場景可以用在線學習的方式讓模型實時更新。特征監(jiān)控監(jiān)控特征的分布變化一旦發(fā)現(xiàn)某個特征的分布偏移嚴重就要排查原因。模型融合用多個模型投票降低單模型衰減的影響。我們當時的做法是每周重訓一次同時保留一個老版本模型做兜底。如果新模型效果不好可以快速切回老模型。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案誤殺率升高新策略上線對比新舊策略決策日志回滾策略誤殺率升高特征服務異常檢查特征服務監(jiān)控修復特征服務攔截率下降黑產(chǎn)繞過分析攔截失敗案例更新策略決策延遲升高規(guī)則過多檢查規(guī)則數(shù)量和匹配耗時清理規(guī)則決策延遲升高模型推理慢檢查模型服務和特征拉取耗時優(yōu)化特征緩存名單誤命中名單數(shù)據(jù)錯誤檢查名單導入日志修正名單數(shù)據(jù)5.5 風控系統(tǒng)的監(jiān)控體系監(jiān)控是風控系統(tǒng)的生命線。我們當時監(jiān)控的指標分三類業(yè)務指標攔截率、誤殺率、二次驗證率、投訴率。這些指標直接反映風控效果。技術(shù)指標請求量、響應時間、錯誤率、超時率。這些指標反映系統(tǒng)健康度。數(shù)據(jù)指標特征覆蓋率、特征分布、模型評分分布。這些指標反映數(shù)據(jù)質(zhì)量。每類指標都要設(shè)置告警閾值。比如誤殺率超過1%告警響應時間超過100ms告警。告警要能快速定位到具體模塊所以我們給每個模塊都加了獨立的監(jiān)控面板。6. 一些踩坑后的個人體會風控系統(tǒng)不是建好就完事了它更像一個需要持續(xù)運營的產(chǎn)品。我最大的體會是策略、數(shù)據(jù)、工程三者缺一不可。策略同學懂業(yè)務但不懂工程工程同學懂技術(shù)但不懂業(yè)務數(shù)據(jù)同學懂模型但不懂策略三者之間需要大量的溝通和協(xié)作。另外不要迷信模型。模型能解決一部分問題但解決不了所有問題。很多場景下一條簡單的規(guī)則比模型更有效。關(guān)鍵是找到規(guī)則和模型的平衡點讓它們各自發(fā)揮優(yōu)勢。最后分享一個小技巧每次策略上線后一定要做決策日志的抽樣分析。隨機抽100條攔截記錄人工看看有多少是誤殺。這個工作很枯燥但能發(fā)現(xiàn)很多自動化監(jiān)控發(fā)現(xiàn)不了的問題。我們當時就是通過抽樣分析發(fā)現(xiàn)了一個規(guī)則在特定場景下的誤判及時做了修正。