複雜風控場景下，如何打造一款高效的規則引擎

| 在互聯網時代，安全已經成爲企業的命脈。美團信息安全團隊須要採用各類措施和手段來保障業務安全，從而確保美團平臺上的用戶和商戶利益不會受到侵害。

本文主要介紹了美團在打造自有規則引擎Zeus（中文名「宙斯」）的過程當中，信息安全團隊遇到的挑戰以及對應的解決方案，並分享了不少踩過的坑，同時還有一些思考和總結。但願對從事安全領域相關工做的同窗可以有所啓發或者幫助。

背景

美團App天天都面臨着各種的欺詐、盜號、做弊、套現以及營銷活動被惡意刷單、惡意搶佔資源等風險。而業務安全團隊採用的主要措施和手段就是在業務請求中識別出誰、在什麼時間、經過什麼方式、作了什麼事。這個識別邏輯的制定過程叫作策略的生產。同時，還要對已經完成生產的策略進行快速的驗證和落地，以防止風險變化後策略失效。從發現風險通過策略生產、驗證，再到最終的落地部署，全流程的處理速度和效果將決定整個業務的成敗。

在業務發展初期，咱們能夠經過硬編碼的方式將風控邏輯部署在業務邏輯中實現，但美團的業務比較複雜，從最初的團購形式，通過與大衆點評、摩拜、貓眼等業務的融合，發展到涵蓋餐飲、到店、貓眼、外賣、金融、酒店、旅遊、大交通等多個垂直領域。隨着業務的快速發展，適用於初期的硬編碼方式出現了策略分散沒法管理、邏輯同業務強耦合、策略更新迭代率受限於開發、對接成本高等多種問題。此時，咱們須要有一套可配置化的規則管理平臺，進而實現風控策略與業務解耦、快速部署、驗證。

但規則引擎的建設初期，會面臨着各類困難和挑戰，主要包括如下幾個方面：

• 在業務層面：垂直領域多，包含幾乎全部的吃喝玩樂服務。美團細分業務多達百個。服務用戶角色多（用戶、商戶、供應商、渠道商），交易頻率高，日訂單量大。
• 在風險層面：存在用戶做弊、商家刷單、帳號盜用冒用、支付和信貸等多種風險。
• 在企業外部環境層面：黑產已造成自下而上的產業鏈，攻擊方式升級比較快速。

針對以上這些挑戰，咱們打造了自有的規則引擎 Zeus（中文「宙斯」，來源於「宙斯盾」做戰系統的啓發，指望規則引擎平臺能同「宙斯盾」同樣成爲先進的中央做戰決策系統，實現對風險的精準、高效打擊）。

下面，咱們就來具體介紹一下，美團信息安全團隊在系統構建過程當中面臨的挑戰以及對應的解決方案。

挑戰與方案

1. 業務多-接入成本高

規則引擎最先只是業務系統中的一個函數，逐步演化成了獨立的服務。而這個獨立服務與業務後臺的交互是單點方式，即業務後臺在關鍵動做節點前調用規則引擎，判斷「有沒有風險」。但這樣每次新增長一個業務或新出現一個風險場景時，規則引擎和業務都要從新進行對接聯調。頻繁地調整給上下游團隊都帶來了不小的負擔，並且在頻繁的更改中，系統質量也難以保證。如何便捷、快速地實現業務接入是系統設計的核心目標之一。

在接入成本上，一次性集中接入每每是最便捷的方式。所以咱們選擇在每一個業務都會通用節點接入規則引擎，例如：用戶中心、商戶中心、訂單中心、收銀臺等均爲各種業務的通用節點，規則引擎同這些通用節點對接，業務在調用通用節點時，通用節點調用規則引擎便可完成業務的接入。

隨着美團業務和場景種類的增多，如今也存在不通過通用節點的業務。所以，咱們須要提供通用的接入接口，目前業務側直接調用一個獨立服務接口便可得到風控判斷。

2. 風險點多-邏輯複雜、邏輯複用

風險點多且業務多，進一步增長了場景、策略邏輯的複雜度。表達式語言可支持的邏輯計算範圍有限，複雜的邏輯若仍經過硬編碼實現，會存在效率低、不易複用等問題。

受模塊化思惟啓發，咱們將複雜的邏輯封裝成模版，實現配置化，並支持邏輯複用。這樣就大大提高了規則引擎可實現的邏輯範圍。目前，咱們已經建設的幾類經常使用的封裝邏輯以下：

1. 擴展函數：主要用於數據格式的提取和處理，好比字符串、數組等格式轉換、數據提取等。經過擴展函數功能，對業務側數據格式要求大大下降，也下降了業務側數據處理的負擔。
2. 累計因子：在業務中會高頻使用到與累計相關的邏輯。例如，在登錄、下單、支付等事件須要同IP的UserID進行計數計算，計算結果做爲特徵引用在規則中。規則引擎引入了內部研發的高效事件計數服務，實現累計通用邏輯的封裝，好比支持累計週期、計數/求和/最近幾回、累計值等計算邏輯配置化等等。
3. 決策表因子：部分業務中須要引擎處理的判斷條件較多，各條件又相互組合，存在多種決策方案的狀況，這就須要用精確、簡潔的方式來描述這類複雜邏輯。在低頻使用時，咱們能夠經過硬編碼的case-when、if-else等語句實現，但在實時性和配置化上不盡人意。最終，咱們經過決策表將多個獨立的條件和多個動做直接地聯繫、清晰地表示出來，並實現了邏輯的封裝。
4. 名單庫因子：與名單庫聯動過程當中，將查詢名單的邏輯進行封裝。
5. 工具因子：將一堆規則進行打包造成大的邏輯集合，並對組成的規則設置評分。在執行時輸出評分結果並實現跨場景、跨業務應用，同時將大邏輯進行「黑盒」處理，簡化邏輯複用時的配置、溝通成本。

風險點多的另外一個挑戰點是在多業務中會存在同質性，即制定的風險策略是可複用的。當一百條規則須要複用在幾十個場景中，逐個配置的效率過低，不只一致性難以保障，後續的修改也是問題。同時又衍變出部分複用、部分差別化，讓業務直接複用場景行不通。所以，咱們引入【規則組】的概念，將規則聚類管理。好比衆包識別規則組、虛假設備規則組、涉黃內容識別規則組等。業務在應用時，可在本身的場景中進行差別化的應用。

3. 風險變化快、長期對抗-效果驗證速度

當外部風險變化時，風控的對抗也須要及時響應，這是一個爭奪「主導權」的比賽。風控經過對不一樣階段的組合打擊，實現策略的健壯性，包括用於識別有沒有風險的基礎對抗階段、引導節奏混淆視聽的「短平快」階段、誘敵深刻的「高精尖」階段。對應系統須要支持不一樣階段的策略配置、迭代和驗證需求。而在策略迭代和部署階段，須要特別注意因配置錯誤致使的誤命中問題。

參考開發環境分類：測試環境、預發佈環境和生產環境。規則引擎在規則的部署和迭代上，可經過標記、雙跑和回溯功能，咱們經過應用實時線上流量和歷史數據來驗證策略的有效性。

• 標記：規則在場景中的狀態，標記狀態的規則邏輯將灰度執行，即：與生效規則相似會實時執行，但決策信息不實時返回給上游業務方，不影響決策。同時用戶可在實時日誌查詢中查看標記規則的命中狀況。
• 雙跑：規則在場景中的狀態，雙跑狀態的規則邏輯將灰度執行，但僅會出如今修改生效規則、因子（因子修改致使引用規則的邏輯執行變化）時，纔會存在的狀態。
• 回溯：規則在場景中的狀態，回溯狀態的規則邏輯將灰度執行，但僅使用回放的歷史數據。

經過這些功能，能夠下降策略迭代的風險，縮短策略部署上線的時間週期。

思路總結

在確認清楚挑戰和解決方案以後，規則引擎的總體建設思路就已經造成了。現今，規則引擎隨着業務的快速擴張，由一個內部系統逐漸發展爲服務多個風控團隊的公共平臺。

從初期主要圍繞風控防控痛點進行搭建的表達式服務包，升級到配置化平臺，在配置效率和執行效率也獲得了很大的提高。同時，隨着人工智能技術的應用和風控對抗進入白熱化，規則引擎也將從配置化快速迭代至自動化、智能化。

1. 肯定核心快速論證、快速落地

在系統建設中，進行了充分的論證後就須要快速落地，避免因長項目週期需求發生裂變而致使不可控。在初期，咱們已經創建了aviator表達式服務包並穩定服務。所以，配置化平臺搭建時仍基於表達式語言，引入場景、規則、因子、決策等概念搭建，將策略的執行分爲執行層和計算層。

執行層：經過場景得到一堆規則集合，規則執行完成後將其結果和對應的決策返回。

結果和：在規則執行時會進行其構成因子計算。

2. 根據角色，進行定向提效

規則引擎搭建的初衷之一是提高風控對抗的總體效率。在對抗過程當中，咱們須要各類角色配合，例如開發建設系統、策略制定者、策略使用者和風險用戶等，所以須要針對各種角色定向開展提效工做。

（1）風險用戶處理提效（風險用戶）

業務已經能夠實時得到風控的決策，但發現風險用戶會在不少場景下重複攻擊。對這類用戶的處理，除了對當次行爲阻斷，還要阻斷其將來的行爲，所以就有名單管理的訴求。咱們經過與名單庫的聯動，提高該類用戶的處理效率。

例如：在美團金融項目場景下，嚴重逾期的用戶會加入禁貸名單，再次申貸時取消其貸款資格。

（2）業務接入提效（業務方）

除了上面介紹的統一接入外，還有一種常見的狀況：業務沒法在發起請求時就將執行所須要的所有參數準備好，此時就須要引擎能主動獲取外部數據。針對這類狀況，規則引擎經過數據接口的方式實現了外部數據的補充，在策略執行時根據計算須要動態獲取相關的參數。在實現與外部數據聯動的功能後，大大下降了使用規則引擎業務方數據準備階段的壓力，從所有參數準備簡化爲僅提供核心參數便可，剩餘參數按需引擎自行調度便可。

（3）策略管理提效（產品）

策略產品是規則引擎的主要用戶，主要的工做流程是圍繞策略管理、分析、驗證進行提效。如何管理大量的規則和應用場景？怎樣快速驗證策略有效性、評估誤傷率？客訴反饋問題，如何快速還原規則命中狀況？針對這些維度，咱們分別提供不一樣的產品功能進行提效。

• 在策略管理層面，可經過規則組方式、因子工具等，進行同類規則集合的管理、打包和複用。
• 在規則分析層面，可經過實時查詢規則的執行詳細數據和將規則執行流程進行回放提高分析效率。
• 在策略驗證層面，提供標記、雙跑和回溯提高策略驗證速度。

（4）工程效率提效（工程師）

複雜的邏輯且具備通用性就能夠對特徵邏輯封裝，避免工程師重複進行邏輯開發工做，釋放出的開發資源能夠進行其它維度的提效。

（5）算法/模型接入提效（算法工程師）

當對抗升級時，策略的產生者由人變爲算法/模型。而機器的生產效率遠遠高於人，人工搬運算法/模型會成爲迭代效率的瓶頸，怎樣跟算法、模型平臺進行快速聯動呢？最簡單、快速的方式就是使用引擎提供的外部數據聯動方式，將模型結果包裝成數據接口使用。但在實踐過程當中，咱們發現模型的出入參數較多且存在變化，總體的配置化效率低，模型應用和迭代頻率受限制。公司內部提供的深度學習仍是算法工程平臺，目前主攻計算、訓練等場景，在上下游應用提供標準化的數據產出，但沒法同相似引擎的平臺對接。

所以，僅聚焦在引擎與算法平臺的聯動上，可經過建設調度模塊實現：1.訓練樣本預處理-->2.算法平臺對接-->3.自動化生成接口-->4.自動註冊接口/策略至引擎-->5.評估任務啓動-->6.評估結果處理（策略上下線、樣本數據沉澱）-->1.訓練樣本預處理的閉環流程。

3. 發現問題、橫向擴展、兼容更多場景

隨着引擎在多業務場景的應用，咱們發現幾個實時引擎很差處理的場景。好比拉新場景，須要結合「註冊+登錄+交易」等多種行爲來判斷是否有「薅羊毛」等黑灰產行爲，須要將不少事件放到一塊兒去綜合斷定。當發現風險時，或在當前時間點漏過的變異風險在發現以後，須要對歷史數據進行回撈，這些在實時引擎中都不太好實現。當前已有的異步引擎也沒法很好地進行覆蓋。爲了不作「重複造輪子」的事情，團隊充分地討論了實時、異步和離線引擎的定位和服務邊界。

在實時引擎已經覆蓋的邏輯基礎上，咱們引入新的封裝邏輯-個體因子，全局因子實現SQL語句的配置化管理，進而實現批量累計、聚合特徵的計算，好比：近一年某商家的平均下單金額，近30天商戶大盤下單均值，標準差等批數據的複雜邏輯。並基於Spark和實時引擎底層，實現多流和批數據的處理，解決上述場景沒法處理的一些問題。

4. 業務實踐結果

交易安全

策略產品在平常工做中，經過對業務分析發現風險、挖掘風險特徵並應用在策略中。經過Zeus實現策略的部署和應用，大大下降了業務風險，提高風險防控效率。例如：在某業務地推場景中發現B、C端聯合刷單風險，以返利、送贈品收到誘騙下單。

金融安全

金融風控主要有反欺詐和信用安全。反欺詐同業務安全在策略形態上相同，都是判斷有無風險，在決策結果上是經過和拒絕。所以，經過普通決策便可知足業務需求。

但信用安全會比前二者複雜一些，在決策上，除了經過和拒絕外，對於經過的請求要進行分層實現金融的差別化訂價。所以，須要在規則引擎中引入更多功能，來知足業務需求。主要包括：

• 路由場景：可支持多層，決策流模式，即一堆規則的集合，支持按照邏輯進行分流，知足指定條件能夠指定走向在每一個節點進行條件設置，實現最終流向。例如：對於某分期場景用戶申請一筆貸款，須要通過欺詐識別、信用評估後方可給出最終的額度、訂價。
• 決策衍生參數：適用於複雜的多級路由決策場景Key-Value型數據，在決策中指定衍生參數信息從而在路由場景中產生全局傳遞變量，好比：流轉過不一樣的場景須要將用戶進行等級分類。
• 決策附加信息：適用於複雜決策場景Key-Value型數據，在決策中指定附加信息從而實現更多決策信息的計算及返回，好比：加入風控名單庫，加入什麼風險類型、風險等級、名單類型。

將來發展與思考

目前規則引擎正處於配置化階段，正在向自動化、智能化的階段發展，從而不斷提高策略的管理和迭代的速度。但業務間的智能化訴求和進程不一樣，平臺能夠提供更多集成託管服務，從而提高各業務的智能化覆蓋度。

其次，引擎仍然存在沒法處理的幾個問題：

一些長時間週期特徵沒法快速應用的問題，例如近一年的時間週期。如何將離線引擎和實時引擎在特徵計算上組合，實現特徵的快速生產、驗證和應用，從而擴展引擎的計算能力範圍、提高風控業務的對抗效率。

當前引擎的接入對非複雜邏輯需求的業務就比較重。而接入成本是各業務接入時重點評估的因素，如何實現快速、低成本的業務接入（包括技術接入和人員操做接入），考慮提供模塊化的引擎計算服務能力適用於各種業務訴求，實現按需接入，比較「臃腫」的全局接入會更快速和便捷。但這種在引擎側怎樣更好地管理這些模塊，也是一個挑戰。

最後，業務流量和策略的增加速度仍在高速增加，引擎的穩定性和策略管理效率也須要持續提高。

踩過的坑

1. 如何實現產品功能高聚合架構上低耦合

規則引擎建設時兼容各種業務場景，具有了極高的靈活性，同時自身也相對複雜。從頂層的路由場景到底層的參數（路由場景-場景-規則組-規則-決策-因子-參數-數據接口-參數）每個節點、節點間都是由用戶配置的，在產品上指望用戶的操做流程是連貫的，在一個操做流程中解決儘可能多的問題。系統架構上，包括配置層、執行層、計算層、數據獲取層等，各層之間相互依賴，對最終引擎的輸出結果負責，底層上須要儘可能的解耦合，纔將下降單模塊對引擎的影響。但在實踐中，隨着業務訴求的增多，慢慢就出現來產品上的低耦合、架構上的高耦合狀況。

例如：在用戶修改生產策略時的強制更新流程優化項目中 ，就涉及了這個問題。在產品功能上用戶修改策略-->雙版本策略並行執行-->兩版本數據覈驗-->修改完成；但在系統架構上，上述的產品流程就產生了系統架構高耦合，即生產修改雙版本問題，配置層、執行層、計算層高度耦合。項目一期上線後在性能上、後續功能擴展性上都有瓶頸。隨後，技術項目優化配置層的緩存模式，採用增量更新方式。產品功能上增長用戶進入修改模式後修改。從新立項後，實現了用戶修改流程閉環、系統架構上僅配置層兼容雙版本，執行層和計算層無耦合。

所以，在產品功能設計上除了用戶閉環操做外，還須要考慮是否低耦合。在技術優化時須要前瞻性的開展去耦合項目。

2. 如何平衡系統複雜度與業務需求

隨着接入業務的增多，又須要兼容新業務定製化需求，就面臨這一個問題：定製化的功能不具備通用性，大量定製功能將加劇平臺的複雜度。這個問題一直困擾引擎建設團。，目前，咱們採用的也許不是最優但比較有效的辦法。主要經過定、判、看Gap，將業務需求轉化爲系統模塊升級功能和非系統功能：

• 功：從新定義「定製和通用」。在現實中有些定製化需求實際上是業務速度已經遠遠領先於其它業務，全部需求看上去是定製化，其實是將來可預見性的問題。
• 未：將業務需求進行分類，判斷需求是針對主幹流程仍是分支節點。
• 看Gap：需求同當前建設狀況比對差距。

對於系統模塊升級功能，可逐個完成。對於非系統功能，可經過提供公共對接服務的外掛來實現。

3. 特別須要「防呆」設計

人工操做會存在各種誤操做引發的風險問題，在產品設計上，用戶操做簡潔的初衷是好的，但須要增長防止錯誤發生的限制方法。在實踐中這些「防呆」設置大大下降了人工誤操做Case，例如：

• 業務高峯期封版--->禁止業務高峯期時變動策略。
• 下降無邏輯驗證的誤傷狀況-->策略上線前，強制標記驗證執行是否符合業務預期；修改生產上應用的策略，強制雙跑驗證修改後的邏輯執行是否符合業務預期。
• 下降邏輯配置錯誤概率-->策略部署時強制測試邏輯正確性。
• 慣性操做-->驗證數據結果強制回填等。

4. 產品功能最佳實踐的意外驚喜

要認可一個事實就是，最瞭解功能使用的可能不是規則引擎的產品經理。在規則引擎的建設中出現了這樣的」驚喜」，例如：

1. 規則組功能建設初期目標是實現規則的高效管理、複用。在A業務場景基於規則組除實現規則的高效管理、複用外，還實現了決策計算。但這種用法在隨着其業務的發展複雜度增長，已經再也不利於策略高效管理，目前還在尋找更優的解決方案。
2. 累計因子的功能是將對多條請求進行計數或求和邏輯進行封裝。B業務基於上述功能上仍是實現了事件行爲記錄、多事件時序性累計和攔截行爲的累計。目前在其業務下普遍使用並有效地識別了跨事件風險。

總結而言，作好業務按期應用回訪和應用監控是很是有必要的。

招聘信息

美團信息安所有正在招聘實習生，業務方向包括：安全後端開發機器學習算法天然語言處理風控策略數據開發Web前端測試開發產品經理產品運營安全與隱私合規等。工做地點：北京/上海。歡迎感興趣的同窗發送簡歷至：tech@meituan.com（郵件標題註明：美團信息安全團隊）

閱讀更多技術文章，請掃碼關注微信公衆號-美團技術團隊！