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