檢測字段內容（以…開頭：136，字段：手機號）+檢測時間差（小于24H，字段1：注冊時間，字段2：當前時間）

通過這樣的抽象，我們盡可能的把核心邏輯保留下來，把其余的內容都參數化放到特征的配置中。

策略的設計（有人也稱作規(guī)則）：

那我們該如何讓策略更難以被黑產突破呢？我們知道邏輯越簡單，特征越單一，策略越容易被繞過。邏輯復雜，組合特征，則繞過策略的成本就會增加。所以在策略上，我們需要每一個策略是一個復雜特征的集合，為了實現這種集合，我們需要在策略上實現特征組合的能力。

特征組合一般就是在特征之間實現與或非的邏輯運算：

• 與關系：滿足A特征并且滿足B條特征的時候才命中。例如：ip歸屬地在國外并且發(fā)帖城市在北京。
• 或關系：滿足A或者滿足B條件任意條件的時候命中。例如：芝麻信用分小于350或被列入失信人名單。
• 非運算：不滿足A特征的時候。例如：A代表用戶在黑名單中。那么非運算就是用戶不在黑名單中。

實現與或非的邏輯運算與特征的組合其實比較簡單，但是在前端交互時如何能高效的操作是比較復雜的，尤其是在非常復雜的特征組合下。推薦大家兩種方案：

1. 簡單的邏輯前端通過選擇器進行選擇，復雜的邏輯通過在文本框中填寫表達式生成，兩種方式可進行切換。
2. 通過評分卡設計實現特征組合和邏輯運算。這種見得比較少，在這里解釋一下。這種方案是由用戶將每個特征賦予一個分值，策略總分就是所有特征分值的加和。通過每個特征得分的控制來間接實現邏輯運算。

舉個例子：

• 策略1：A與B。如果A特征命中得分50，B特征命中得分50。那么當策略得分等于100時策略命中。
• 策略2：A或B。如果A特征命中得分50，B特征命中得分50。那么當策略得分等于50時候策略命中

通過這樣的方法，對策略得分和特征得分進行控制，就可以實現組合和運算。

策略狀態(tài)的設計：

策略核心的業(yè)務狀態(tài)有三種，分別是上線狀態(tài)、預上線狀態(tài)和下線狀態(tài)。

其中預上線狀態(tài)尤為重要，因為一切策略在上線產生影響之前都應該準確的預知效果才能操作上線，一旦評估不充分，可能在上線后對線上產生非常嚴重的影響。所以預上線狀態(tài)是確保策略效果的一個重要狀態(tài)。在預上線的狀態(tài)下，風控引擎應該有足夠的能力去預測策略上線后的效果。常用的方案有兩種：

1. 是將歷史已知明確結論的數據重新灌入風控引擎，以此來證明策略對已知數據的準召情況。這種方法通常需要將歷史流量做鏡像備份，已保證重新灌入時數據不會發(fā)生偏移。但是這樣的方法也有一些弊端，就是當攻擊行為與歷史行為有著大幅差異的時候，準召率的判斷可能出現不準確的情況。

2. 是將預上線后命中的數據進行隨機抽樣，比如抽取5‰的數據進行離線驗證。這種方法因為使用的是真實的線上數據，結論比上一種更加精準，但是對數據的核驗成本非常高，很難快速的產出結論。

所以建議上面兩種方式混合使用，通過第一種方案做日常策略維護。當策略的召回數量非常大時（代表對線上產生了足夠的影響），這個時候做第二種，確保策略上線的嚴謹。

進行策略的執(zhí)行順序：

在資源充足的前提下，一般來說策略的執(zhí)行都是并行執(zhí)行的，但是在一些情況下也會要求策略有先后的執(zhí)行順序。比如有些策略會依賴一些第三方數據源，這些數據在調用的時候就會產生成本，我們常見的有銀行卡四要素、手機三要素等等。

所以有的時候為了節(jié)省成本，會將這些策略執(zhí)行順序后置，當前面的策略已經足夠產出明確的結論時（比如拒絕這次申請/發(fā)帖等），就無需執(zhí)行后續(xù)策略。在運算資源上也是同理，會優(yōu)先執(zhí)行對運算資源消耗小的策略。

2. 處置模塊的設計

處置的設計，很大程度的決定了風控對正常用戶產生的影響。

之前在另一篇文章里講過去做處置時的一些基本思路，大家可以參考《風控對抗中的常規(guī)特征及處置選擇》，在這篇文章里主要講處置還有哪些需要關注的重點。

優(yōu)先級：

在執(zhí)行處置的時候，難免會遇到同時命中了多種處置方式的情況。這種時候，我們需要去確認以哪個執(zhí)行為準。一般來說，越是處罰嚴重，優(yōu)先級越高。嚴重的處置方式會覆蓋較輕的處置方式。比如封禁用戶和刪除帖子同時命中，會執(zhí)行封禁用戶。

留證：

當我們對用戶進行處置之后，因為所有的風控策略準確率不可能達到100%，這樣一來就一定會產生用戶申訴的情況。所以我們每一次的處置操作，都應該盡量做到留證全面。

當用戶申訴的時候，我們可以很清晰地看到每一次處置都是因為什么樣的問題而產生的。常見的留證實現方式是數據快照或者內容快照。數據快照可以更好的復現行為，內容快照可以更好的復現內容。留證模塊準備的越充分，風控的每一次處置就會越有底氣。

反饋與出口：

用戶對處置的感知主要是通過的我們的通知下發(fā)，所以確保處置信息向用戶的有效傳遞是尤為重要的。越是對用戶影響大的處置，越是要多渠道分別下發(fā)，確保用戶可以接收到信息。同時用戶在被處理之后通常會產生為什么處理我的疑問，那么處置相關的話術也是需要用心設計的。因為風控的特性，很多的特征不能直接對外明示，特征選取的越偏向行為，越復雜則越難以向用戶解釋，所以話術的設計要盡可能的既解決用戶的疑惑，又保護核心識別邏輯。

對于部分用戶而言，誤判和話術的不清晰一定會導致用戶體驗變得極差，所以針對誤判的出口是非常必要的，所有的判罰都應該有有效的出口和流程去解決用戶被誤判的問題，只有實現了這樣處置閉環(huán)，才是相對完整的產品體系。

3. 數據運營支撐產品模塊設計

一款好的風控引擎僅僅有策略對抗的能力是不夠的，完善的運營支撐同樣重要。整個運營體系可以從風控前，風控中和風控后三個階段來搭建。

風控前：

簡單來說，在真正的做對抗之前，我們關注的就是風險何時出現。所以風控前的運營支撐應該是一個比較完備的預警體系。預警體系的作用就是讓風險盡可能快的被定位。

常見的預警監(jiān)測項可以提供一些給大家參考：

業(yè)務的產生量、 過風控的量、出現頻率高的top資源（IP、手機號、UID、設備等）、出現頻率高的top內容（文本、圖像、音頻、視頻）、數量異常的top群組等等

風控中：

在做對抗的時候，運營支撐的設計考慮的就是如何輔助策略人員快速的產生決策。所以風控中的支撐在產品表現上更像是一個數據大屏。這個大屏可以很好的展示一個資源從在業(yè)務中出現到目前為止的全貌。一個資源的全生命周期的行為或內容表現都可以很好的在這個模塊中進行展現，并且在此之上，提供一些簡單的統(tǒng)計和分析來將特征提取的過程盡可能的縮短。

風控后：

在策略上線之后，我們更應該關注的應該是策略在線上產生的效果和影響。所以風控后的運營支撐體系應該是個效果的評估體系，通過各種核心指標的展現輔助策略人員優(yōu)化策略。

常見的一些評估指標可以給大家參考：

污染率（有問題的數量/總量），策略的命中量，策略的獨立命中量（用來說明某條策略的不可替代性），策略的準召率、策略造成申訴的量等等。

4. 系統(tǒng)的穩(wěn)定性

跟所有系統(tǒng)一樣，風控引擎的穩(wěn)定性也是非常重要的，在一些比較大的企業(yè)中，風控引擎一天承載的檢測量級甚至可以達到上百億次。在如此龐大的業(yè)務量級中，穩(wěn)定性就變成一個必須要考慮的問題。

怎么解決穩(wěn)定性問題偏技術實現，這里就不做具體的介紹。但是發(fā)生異常后的方案選擇應該比較清晰和明確。

拿兩個場景舉例子，比如當用戶發(fā)帖時，如果我們風控檢測超時或發(fā)生異常，我們可能會選擇放直接放過這個帖子或者直接將帖子推入人工審核。這個時候因為用戶一次發(fā)帖動作帶來的風險有限，所以在面對異常情況的時候，我們通常就會不處理來避免對用戶產生不良的影響。

但是如果用戶在app上申請一個小額貸款，這個時候檢測環(huán)節(jié)出現異常，因為這個結論會直接跟資金掛鉤，所以我們通常會進行重試，如果重試依然不通，我們可能會選擇拒絕這次申請操作。

所以在面臨不同的業(yè)務場景時，我們應該能清晰的判斷業(yè)務對風險的接受程度，通過這個來設計兜底策略。

以上就是風控引擎的演進歷史及基本的設計思路，本來還想分享一下風控引擎中臺化的產品思路以及對這個產品后續(xù)發(fā)展的一些思考和設想，但是因為時間原因，這部分就放到后面有時間再說吧。

希望這篇文章能對大家理解風控和風控產品有所幫助~就這樣。

本文由 @gology 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協(xié)議