中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

之前介紹了基本的風控對抗思路，今天筆者再來給大家分享一下風控引擎的設計實現思路。

本文將從兩個部分來對風控引擎進行拆解：

1. 風控引擎的演進歷程
2. 風控引擎的設計思想

一、風控引擎的演進歷程

1. 硬編碼階段

通常在一個業務的發展初期，所有資源的投入重點都在用戶量或者流量上，在這個階段，因為用戶量級較小，所以黑產對業務的關注度比較低，黑產的變現效率也比較低。

在硬編碼階段，所有策略上線都是通過RD開發然后部署在線上的，這種形式就會導致策略的開發周期很長，并且在線上之前無法有效預估效果，上線之后對策略準召率也難以掌控。所以在這個階段整個策略對抗是一個極其低效的過程，但是因為業務階段比較初級，所以風險大致還都可以控制住。

2. 初級產品化階段

隨著業務的發展，用戶量開始變多，業務對黑產的價值開始體現，在這個階段開始就會有黑產涌入進行攻擊，當攻擊的情況達到了一定的程度，我們就會發現，原有處于“硬編碼階段”的策略體系因為自身的低效性，很難做到及時攔截黑產的攻擊。

所以，這個階段業務的負責人會自然而然地想到——能不能把原有的硬編碼模式做得靈活一些。

這個時候，就會通過一些產品設計手段將原有的策略體系產品化，這個階段我們把他稱之為“初級產品化階段”。

在初級產品化階段，通常做的事情都是將原有的策略從代碼中遷移出來，展示在風控引擎中。并且能夠簡單的修改一些策略的參數以及做一些策略上下線配置。

舉個例子，比如“判斷用戶1天內發帖量是否大于5”，這里“發帖量”就是可以配置的參數。雖然在這階段實現了一些基礎的配置化，但是通常在這個階段，策略依然是一條一條相互獨立并行執行的，絕大部分的策略邏輯依然是由RD直接進行開發部署到風控引擎中的。

3. 成熟產品階段

當業務進入到真正的高速成長期，或者從成長期進入成熟期的時候，業務會變得空前龐大，用戶量會達到頂峰。這個時候業務對于黑產的吸引力也會同時達到頂峰。我們會發現黑產攻擊已經變成每天都會發生的事情，跟吃飯喝水一樣自然。

因為黑產的攻擊時刻不停，雖然我們實現了部分策略參數的配置，但是我們的需求僅僅通過一些閾值的調整已經無法真正滿足了。我們在風控對抗上衍生出了很多的想法，比如：

• 我們能不能不依賴技術直接自己實現大部分的策略邏輯？
• 我們能不能讓策略實現與或非關系？
• 我們能不能有一些能力支撐特征的有效產出？
• 我們能不能提前預知風險的發生？
• 我們能不能提前預測策略的效果？

這個時候我們會發現我們會搭建一個體系化的解決方案，這個階段我們把它稱之為“成熟產品階段”

在這個階段，整個風控引擎已經能滿足高強度的風控對抗需要，并且開始通過風控引擎本身衍生出更多的邊緣安全產品。通常一般的公司風控引擎就會停留在這個階段不會再有大幅的變化了。

4. 中臺化產品階段

絕大部分公司的風控引擎都不會進入這一階段，只有一些業務十分復雜的集團企業才會在原有的風控體系中衍生出這種需求。

一般來說，在企業主營業務達到穩定期之后，企業一般會尋求其他方向發展的可能性，新業務就會跟隨著需要不斷產生。但是原有的風控體系都是圍繞著主營業務展開的，與原業務耦合通常比較嚴重。這個時候在原有的成熟產品下，很難快速的將所有的風控能力移植到新的業務場景中，這個時候就會出現主業務風險可控但新業務風險失控的現象。

為了解決這樣的問題，風控引擎就必須要將所有的功能進行高度抽象，實現低成本復用，完成對企業新增業務的安全賦能。這個階段我們稱之為“中臺化產品階段”

在這個階段的風控引擎更像是一個ToB的商業產品，因為想讓業務方更好的解決風控問題，就必須要覆蓋絕大部分業務的安全需求，并且在體驗上盡可能的優秀，讓業務更簡單的理解和掌握風控對抗。如果類比的話，此時的產品就像是一個第三方安全公司提供的服務，所有的事情都是為了讓極低成本的解決風控問題變成現實。

以上就是風控引擎演進的常規過程，一般都是跟隨著業務需求自然而然發生的迭代和進化。下面我們來看一下一個風控引擎在功能設計上的思路應該是什么樣的。

二、風控引擎的設計思想

想設計一款好的風控引擎，我們需要知道風控的核心要點有哪些。

風控引擎的核心點：

• 滿足高效率的策略迭代
• 策略盡可能的難以突破
• 盡可能的降低對正常用戶的影響
• 充分的運營支撐
• 確保服務穩定可靠

1. 策略管理模塊的設計

策略的設計實現直接影響著策略的迭代效率和是否容易被突破。

特征的設計（有些人稱作變量）：

要實現迭代效率足夠快，要求策略的底層邏輯特征要進行原子化的抽象設計。

什么叫做抽象，我們舉一個例子：

我們有這樣一個策略：用戶手機號碼是136開頭并且注冊時長小于1天則對用戶發起驗證碼挑戰，可以看到136手機和注冊時長兩個特征組成了這個策略的識別邏輯。

那我們如何讓這個策略變化起來更靈活呢？我們可以把這個策略拆成兩個特征：

檢測用戶手機號開頭（自定義：136）+檢測用戶注冊時長（自定義：24H內）

這個時候原來一個策略就變成了兩個可配置的特征，這樣一來，如果我檢測170的號段也是可以直接實現的。但是這樣依然不夠靈活，難道我們只有檢測手機號開頭的需求么？并不是，我們應該更靈活地應用字段。我們還可以將這兩個特征進一步抽象，由檢測用戶手機號開頭+檢測用戶注冊時長變為：

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

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

策略的設計（有人也稱作規則）：

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

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

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

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

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

舉個例子：

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

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

策略狀態的設計：

策略核心的業務狀態有三種，分別是上線狀態、預上線狀態和下線狀態。

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

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

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

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

進行策略的執行順序：

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

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

2. 處置模塊的設計

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

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

優先級：

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

留證：

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

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

反饋與出口：

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

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

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

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

風控前：

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

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

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

風控中：

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

風控后：

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

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

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

4. 系統的穩定性

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

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

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

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

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

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

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

本文由 @gology 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議