檢測字段內(nèi)容（以…開頭：136，字段：手機(jī)號）+檢測時間差（小于24H，字段1：注冊時間，字段2：當(dāng)前時間）

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

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

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

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

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

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

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

舉個例子：

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

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

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

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

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

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

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

所以建議上面兩種方式混合使用，通過第一種方案做日常策略維護(hù)。當(dāng)策略的召回數(shù)量非常大時（代表對線上產(chǎn)生了足夠的影響），這個時候做第二種，確保策略上線的嚴(yán)謹(jǐn)。

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

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

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

2. 處置模塊的設(shè)計

處置的設(shè)計，很大程度的決定了風(fēng)控對正常用戶產(chǎn)生的影響。

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

優(yōu)先級：

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

留證：

當(dāng)我們對用戶進(jìn)行處置之后，因為所有的風(fēng)控策略準(zhǔn)確率不可能達(dá)到100%，這樣一來就一定會產(chǎn)生用戶申訴的情況。所以我們每一次的處置操作，都應(yīng)該盡量做到留證全面。

當(dāng)用戶申訴的時候，我們可以很清晰地看到每一次處置都是因為什么樣的問題而產(chǎn)生的。常見的留證實現(xiàn)方式是數(shù)據(jù)快照或者內(nèi)容快照。數(shù)據(jù)快照可以更好的復(fù)現(xiàn)行為，內(nèi)容快照可以更好的復(fù)現(xiàn)內(nèi)容。留證模塊準(zhǔn)備的越充分，風(fēng)控的每一次處置就會越有底氣。

反饋與出口：

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

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

3. 數(shù)據(jù)運營支撐產(chǎn)品模塊設(shè)計

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

風(fēng)控前：

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

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

業(yè)務(wù)的產(chǎn)生量、 過風(fēng)控的量、出現(xiàn)頻率高的top資源（IP、手機(jī)號、UID、設(shè)備等）、出現(xiàn)頻率高的top內(nèi)容（文本、圖像、音頻、視頻）、數(shù)量異常的top群組等等

風(fēng)控中：

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

風(fēng)控后：

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

常見的一些評估指標(biāo)可以給大家參考：

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

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

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

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

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

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

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

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

希望這篇文章能對大家理解風(fēng)控和風(fēng)控產(chǎn)品有所幫助~就這樣。

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

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