詳解：知乎反作弊系統(tǒng)「悟空」架構(gòu)演進！

Hi there! 距離 2015 年 4 月「悟空」正式與大家見面，已經(jīng)整整三個年頭了。隨著知乎的不斷發(fā)展壯大，過去的一段時間，「悟空」不斷面臨著新的考驗，并持續(xù)地在優(yōu)化升級。接下來跟大家系統(tǒng)分享一下這幾年「悟空」的架構(gòu)演進和構(gòu)建過程中積累的經(jīng)驗與教訓。

業(yè)務(wù)現(xiàn)狀

截止今年 5 月，知乎已擁有 1.6 億注冊用戶，近幾年在問答，專欄文章之外，社區(qū)衍生出了一些新的產(chǎn)品線和產(chǎn)品形態(tài)。因此「悟空」對接的業(yè)務(wù)形態(tài)也得到了擴展，從最初重點控制的內(nèi)容類 Spam ，擴展到行為類 Spam，交易風險等等。目前「悟空」已經(jīng)覆蓋了知乎 10 個業(yè)務(wù)線，近 100 個功能點。

總的來說，在知乎長期存在，且比較典型的 Spam 有這么幾類：

• 內(nèi)容作弊 Spam：這類 Spam 的核心獲益點一方面是面向站內(nèi)的傳播，另一方面，面向搜索引擎，達到 SEO 的目的。內(nèi)容類的 Spam 是社區(qū)內(nèi)主流的 Spam 類型，目前主要包括四種形式：

• 導流內(nèi)容：這類 Spam 大概能占到社區(qū)中 Spam 的 70% - 80%，比較典型的包括培訓機構(gòu), 美容，保險，代購相關(guān)的 Spam。導流內(nèi)容會涉及到 QQ，手機號，微信，url 甚至座機，在一些特殊時間節(jié)點還會出現(xiàn)各類的專項 Spam，比如說世界杯，雙十一，雙十二，都是黑產(chǎn)大賺一筆的好時機。

• 品牌內(nèi)容：這類內(nèi)容會具有比較典型的 SEO 特色，一般內(nèi)容中不會有明顯的導流標識，作弊形式以一問一答的方式出現(xiàn)，比如提問中問什么牌子怎么樣？哪里的培訓學校怎么樣？然后在對應(yīng)的回答里面進行推薦。

• 詐騙內(nèi)容：一般以冒充名人，機構(gòu)的方式出現(xiàn)，比如單車退款類 Spam，在內(nèi)容中提供虛假的客服電話進行詐騙。

• 騷擾內(nèi)容：比如一些誘導類，調(diào)查類的批量內(nèi)容， 非常嚴重影響知友體驗。

行為作弊 spam：主要包括刷贊，刷粉，刷感謝，刷分享，刷瀏覽等等，一方面為了達到養(yǎng)號的目的，躲過反作弊系統(tǒng)的檢測，另一方面通過刷量行為協(xié)助內(nèi)容在站內(nèi)的傳播。

治理經(jīng)驗

治理上述問題的核心點在于如何敏捷、持續(xù)地發(fā)現(xiàn)和控制風險，并保證處理成本和收益動態(tài)平衡，從 Spam 的獲益點入手，進行立體防御。所謂立體防御，就是通過多種控制手段和多個控制環(huán)節(jié)增強發(fā)現(xiàn)和控制風險的能力。

三種控制方式

策略反作弊：在反作弊的初期，Spam 特征比較簡單的時候，策略是簡單粗暴又有用的方式，能夠快速的解決問題，所以策略在反作弊解決方案里是一個解決頭部問題的利器。

• 產(chǎn)品反作弊：一方面通過改變產(chǎn)品形態(tài)來有效控制風險的發(fā)生，另一方面通過產(chǎn)品方案，對用戶和 Spammer 痛點趨于一致的需求進行疏導，有時候我們面對 Spam 問題，對于誤傷和準確會遇到一個瓶頸，發(fā)現(xiàn)很難去區(qū)分正常用戶和 Spammer，這種情況下反而通過產(chǎn)品方案，可能會有比較好的解決方案。

• 模型反作弊：機器學習模型可以充分提高反作弊系統(tǒng)的泛化能力，降低策略定制的成本。模型應(yīng)用需要酌情考慮加入人工審核來保證效果，直接處理內(nèi)容或用戶的模型算法，要千萬注意模型的可解釋性。我們過去的使用經(jīng)驗來說，初期一些無監(jiān)督的聚類算法能夠在比較短時間內(nèi)達到較好的效果。而有監(jiān)督的分類算法，在時間上和人力上的耗費會更多，樣本的完整程度，特征工程做的好壞，都會影響算法的效果。

三個控制環(huán)節(jié)

事前：事前涉及到的幾個環(huán)節(jié)包括風險教育、業(yè)務(wù)決策參與、監(jiān)控報警以及同步攔截。反作弊需要提升業(yè)務(wù)的風險意識，明確告知反作弊可以提供的服務(wù)；并在早期參與到業(yè)務(wù)決策，避免產(chǎn)品方案上出現(xiàn)比較大的風險；業(yè)務(wù)接入后，針對業(yè)務(wù)新增量、處理量、舉報量，誤傷量進行監(jiān)控，便于及時發(fā)現(xiàn)風險；在策略層面，在事前需要針對頭部明顯的作弊行為進行頻率和資源黑名單的攔截，減輕事中檢測的壓力。

• 事中：面向長尾曲線的中部，主要針對那些頻率較低，且規(guī)律沒有那么明顯的作弊行為，針對不同嫌疑程度的行為與帳號，進行不同層級的處理，要么送審，要么限制行為，要么對內(nèi)容和帳號進行處罰。

• 事后：面向長尾曲線最尾部的行為，即那些非常低頻，或者影響沒那么大，但是計算量相對大的作弊行為。由一些離線的算法模型和策略負責檢測與控制，另外事后部分還涉及到策略的效果跟蹤和規(guī)則的優(yōu)化，結(jié)合用戶反饋與舉報，形成一個檢測閉環(huán)。

悟空V1

初期 「悟空」主要由事前模塊和事中模塊構(gòu)成。

事前模塊與業(yè)務(wù)串行執(zhí)行，適用于做一些耗時短的頻率檢測，關(guān)鍵詞和黑白名單攔截。由于是同步接口，為了盡量少的減少對業(yè)務(wù)的影響，大部分復雜的檢測邏輯由事中模塊去處理。

事中模塊在業(yè)務(wù)旁路進行檢測，適合做一些相對復雜，耗時長的檢測。事中主要由 Parser 和一系列 Checker 構(gòu)成，Parser 負責將業(yè)務(wù)數(shù)據(jù)解析成固定格式落地到基礎(chǔ)事件庫，Checker 負責從基礎(chǔ)事件庫里取最近一段時間的行為進行策略檢測。

事件接入

在反作弊的場景數(shù)據(jù)落地一般會涉及到這幾個維度：誰，在什么時間，什么環(huán)境，對誰，做了什么事情。對應(yīng)到具體的字段的話就是誰 (UserID) 在什么時間 (Created) 什么環(huán)境 (UserAgent UserIP DeviceID Referer) 對誰 (AcceptID) 做了什么事情 (ActionType ObjID Content)。有了這些信息之后，策略便可以基于維度進行篩選，另外也可以獲取這些維度的擴展數(shù)據(jù)（e.g. 用戶的獲贊數(shù)）進行策略檢測。

策略引擎

「悟空」的策略引擎設(shè)計，充分考慮了策略的可擴展性。一方面支持橫向擴展，即支持從基礎(chǔ)維度獲取更多的業(yè)務(wù)數(shù)據(jù)作為擴展維度，例如用戶相關(guān)的信息，設(shè)備相關(guān)的信息，IP 相關(guān)的信息等等。另一方面縱向擴展也被考慮在內(nèi)，支持了時間維度上的回溯，通過檢測最近一段時間內(nèi)關(guān)聯(lián)維度 (e.g. 同一個用戶，同一個 IP) 上的行為，更高效地發(fā)現(xiàn)和打擊 Spam。

下面是一條典型的 V1 的策略：

這條策略主要實現(xiàn)了這樣的邏輯：

最近 10 分鐘在同一話題下創(chuàng)建的回答，與當前用戶，注冊時間在一小時之內(nèi)，同一 IP 下注冊的用戶數(shù)大于等于 3 個。

基本上這樣的模式足夠滿足日常的 Spam 檢測需求，但是我們可以發(fā)現(xiàn)這種嵌套結(jié)構(gòu)對于書寫與閱讀來說還是不太友好，這個部分的優(yōu)化會在 V2 作詳細描述。

考慮到策略變更會遠大于基礎(chǔ)模塊，在 V1 的架構(gòu)中，我們特別將策略維護的邏輯單獨拆分成服務(wù)，一方面，可以實現(xiàn)平滑上下線，另一方面，減少策略變更對穩(wěn)定性帶來的影響。

存儲選型

存儲上，我們選擇了 MongoDB 作為我們的基礎(chǔ)事件存儲，Redis 作為關(guān)鍵 RPC 的緩存。選擇 MongoDB 的原因一方面是因為我們基礎(chǔ)事件庫的業(yè)務(wù)場景比較簡單，不需要事務(wù)的支持；另一方面，我們面對的是讀遠大于寫的場景，并且 90% 都是對最近一段時間熱數(shù)據(jù)的查詢，隨機讀寫較少, 這種場景下 MongoDB 非常適合。另外，初期由于需求不穩(wěn)定，schema-free 也是 MongoDB 吸引我們的一個優(yōu)點。由于我們策略檢測需要調(diào)用非常多的業(yè)務(wù)接口，對于一些接口實時性要求相對沒那么高的特征項，我們使用 Redis 作為函數(shù)緩存，相對減少業(yè)務(wù)方的調(diào)用壓力。

悟空V2

「悟空 V1」已經(jīng)滿足了日常的策略需求，但是在使用過程我們也發(fā)現(xiàn)了不少的痛點：

策略學習曲線陡峭, 書寫成本高：上面提到的策略采用嵌套結(jié)構(gòu)，一方面對于產(chǎn)品運營的同學來說學習成本有點高，另一方面書寫過程中也非常容易出現(xiàn)括號缺失的錯誤。

• 策略制定周期長：在「悟空 V1」上線一條策略的流程大概會經(jīng)過這幾步, 產(chǎn)品制定策略 - 研發(fā)實現(xiàn)策略 - 研發(fā)上線策略召回 - 產(chǎn)品等待召回 - 產(chǎn)品確認策略效果 - 上線處理。整個環(huán)節(jié)涉及人力與環(huán)境復雜，策略驗證麻煩，耗時長，因此策略試錯的成本也會很高。

鑒于此，「悟空 V2」著重提升了策略自助配置和上線的體驗，下面是「悟空 V2」的架構(gòu)圖：

策略結(jié)構(gòu)優(yōu)化

參考函數(shù)式語言，新的策略結(jié)構(gòu)引入了類 spark 的算子：filter, mapper, reducer, flatMap, groupBy 等等，一般基礎(chǔ)的策略需求通過前三者就能實現(xiàn)。

舉個例子，上面提到的策略在優(yōu)化之后，會變成下面這種格式：

結(jié)構(gòu)上變得更清晰了，可擴展性也更強了，工程上只需要實現(xiàn)可復用的算子即可滿足日常策略需求，不管是機器學習模型還是業(yè)務(wù)相關(guān)的數(shù)據(jù)，都可以作為一個算子進行使用。

策略自助配置

完成了策略結(jié)構(gòu)的優(yōu)化，下一步需要解決的，是策略上線流程研發(fā)和產(chǎn)品雙重角色交替的問題，「悟空 V2」支持了策略自助配置，將研發(fā)同學徹底從策略配置中解放出去，進一步提升了策略上線的效率。

策略上線流程優(yōu)化

如何使策略上線變得更敏捷？這是我們一直在思考的問題。每一條上線的策略我們都需要在準確率和召回率之間權(quán)衡，在盡量高準確的情況下打擊盡量多的 Spam，因此每條要上線的策略都需要經(jīng)過長時間的召回測試，這是一個非常耗時并且亟待優(yōu)化的流程。「悟空 V2」策略上線的流程優(yōu)化成了：創(chuàng)建策略 - 策略測試 - 策略試運行 - 策略上線處理 - 策略監(jiān)控。

策略測試主要用于對策略進行初步的驗證，避免策略有明顯的語法錯誤。

策略試運行可以理解成快照重放，通過跑過去幾天的數(shù)據(jù)，快速驗證策略效果，一切都可以在分鐘級別完成。這部分的實現(xiàn)我們將策略運行依賴的資源復制了一份，與生產(chǎn)環(huán)境隔離，實現(xiàn)一個 coordinator 將歷史的事件從 MongoDB 讀出并打入隊列。值得注意的是，入隊速度需要控制，避免隊列被瞬間打爆。

通過試運行的驗證之后，策略就可以上線了。上線之后，策略監(jiān)控模塊提供了完善的指標，包括策略執(zhí)行時間、策略錯誤數(shù)、策略命中及處理量等等，數(shù)據(jù)有所體現(xiàn)，方能所向披靡。

悟空V3

2016 年中旬，知乎主站各業(yè)務(wù)開始垂直拆分，相應(yīng)的，「悟空」業(yè)務(wù)接入成本的簡化開始提上日程。

Gateway

Gateway 負責與 Nginx 交互，作為通用組件對在線流量進行風險的阻斷。目前 Gateway 承擔了所有反作弊和帳號安全用戶異常狀態(tài)攔截、反作弊功能攔截和反爬蟲攔截。這樣一來，這部分邏輯就從業(yè)務(wù)剝離了出來，尤其是在業(yè)務(wù)獨立拆分的情況下，可以大大減少業(yè)務(wù)的重復工作。作為通用組件，也可以提升攔截邏輯的穩(wěn)定性。Gateway 當前的架構(gòu)如下圖所示：

由于是串行組件，所有請求要求必須在 10ms 內(nèi)完成，因此所有的狀態(tài)都緩存在 Redis。Gateway 對外暴露 RPC 接口（Robot），相關(guān)服務(wù)調(diào)用 Robot 更新用戶，IP，設(shè)備等相關(guān)的狀態(tài)到 Redis。 當用戶請求到達時，Nginx 請求 Gateway，Gateway 獲取請求中的 IP，用戶 ID等信息， 查詢 Redis 返回給 Nginx。當返回異常狀態(tài)時 Nginx 會阻斷請求，返回錯誤碼給前端和客戶端。

TSP - Trust & Safety Platform

TSP 主要為反爬蟲和反作弊提供服務(wù)，一方面解析旁路鏡像流量，通過 Spark 完成流量清洗和基礎(chǔ)計數(shù)，再通過 Kafka 將計數(shù)數(shù)據(jù)打給反爬蟲策略引擎，進行檢測和處理，從而實現(xiàn)業(yè)務(wù)零成本接入。另一方面，由于反作弊依賴較多業(yè)務(wù)數(shù)據(jù)，難以從流量中獲取，故以 kafka 接入替代 RPC 接入，實現(xiàn)與業(yè)務(wù)進一步解耦，減少對業(yè)務(wù)的影響。

隨著「悟空」策略上線效率的提升，在線的策略逐漸增多，我們開始著手優(yōu)化「悟空」的檢測性能與檢測能力。

策略充分并行化

「悟空 V2」策略檢測以行為為單位分發(fā)，帶來的問題是策略增多之后，單行為檢測時長會大大增強。在 V3 我們優(yōu)化了這部分邏輯，將策略檢測分發(fā)縮小到以策略為粒度，進一步提升策略運行的并行度，并實現(xiàn)了業(yè)務(wù)級別的容器隔離。優(yōu)化后，事中檢測模塊演化成了三級隊列的架構(gòu)。第一級是事件隊列，下游的策略分發(fā) worker 將數(shù)據(jù)落地，并按照事件的業(yè)務(wù)類型進行策略分發(fā)。策略執(zhí)行 worker，從二級隊列獲取任務(wù)，進行策略檢測，并將命中的事件分級處理，分發(fā)到對應(yīng)的第三級隊列。第三級隊列即處理隊列，負責對命中規(guī)則的內(nèi)容或者用戶進行處理。

緩存優(yōu)化

因為每個策略檢測都會涉及到歷史數(shù)據(jù)的回溯，自然會帶來較多的重復查詢，存儲的壓力也會比較大，所以存儲上我們又增加了多級存儲，除了 MongoDB，在上層對于近期的業(yè)務(wù)數(shù)據(jù)，存儲在 Redis 和 localcache。詳細的內(nèi)容過往的技術(shù)文章已經(jīng)有了比較詳細的介紹，感興趣的同學們可以去看：Wukong 反作弊系統(tǒng)緩存的優(yōu)化

圖片識別能力增強

隨著文本內(nèi)容檢測能力的增強，不少 spam 開始使用圖片的方式進行作弊。在「悟空 V3」我們增強了圖片相關(guān)的檢測能力：圖片 OCR，廣告圖片識別，色情圖片識別，違法違規(guī)圖片識別，政治敏感圖片識別。針對圖片類的廣告 Spam 的檢測一直是我們的空缺，需要投入大量的人力進行模型訓練，所以這一塊我們借助第三方快速提升這一塊的空缺。目前接入之后，著實提升了我們解決站內(nèi)廣告和詐騙圖片 Spam 的能力。

風險數(shù)據(jù)進一步積累

早期由于系統(tǒng)還未成熟，我們很多的工作時間都花在 Spam 問題的應(yīng)急響應(yīng)上，很少去做各維度的風險數(shù)據(jù)累積。在「悟空 V3」我們分別在內(nèi)容、帳號、IP、設(shè)備維度開始累積相關(guān)的風險數(shù)據(jù)，供策略回溯和模型訓練使用。 目前我們有三個數(shù)據(jù)來源：策略、第三方接口和人工標注。鑒于離線人工標注效率低，并且抽取數(shù)據(jù)項繁雜的問題，我們專門搭建了一個標注后臺，提升運營同學標注數(shù)據(jù)的效率，使標注數(shù)據(jù)可復用，可追溯。以下是一些我們比較常用的風險維度：

• 內(nèi)容維度：e.g. 導流類廣告，品牌類廣告，違反法律法規(guī)

• 帳號維度：e.g. 批量行為（批量注冊，刷贊，刷粉等），風險帳號（社工庫泄露等）， 垃圾手機號，風險號段

• IP 維度: e.g. 風險 IP ，代理 IP

• 設(shè)備維度：e.g. 模擬器，無頭瀏覽器

回溯能力增強

在「悟空 V3」，我們還增強了策略的回溯能力。一方面，搭建失信庫覆蓋新增內(nèi)容中與失信內(nèi)容相似的 Spam 內(nèi)容，相似度的算法目前我們使用的是 consine-similarity 和 jaccard。另一方面，基于 Redis，我們支持了基于導流詞、標簽、社區(qū)的快速回溯。這樣的話相關(guān)的行為更容易被聚集到一起，使得我們可以突破時間的限制，對相似的 Spam 一網(wǎng)打盡。

此外，我們工程和算法團隊在算法模型引入做了諸多嘗試。

「結(jié)網(wǎng) - ZNAP (Zhihu Network Analysis Platform)」

過去做反作弊的很長一段時間，我們花了很多功夫在行為和內(nèi)容層面去解決 Spam 問題。但換個角度，我們會發(fā)現(xiàn)，黑產(chǎn)團伙固然手上的資源巨多，但是也得考慮投入產(chǎn)出比，不管怎么樣，資源都會存在被重復使用的情況，那用什么方式去表示這種資源的使用情況呢？我們想到了圖，也成為了我們做「結(jié)網(wǎng)」這個項目的出發(fā)點。我們將這個項目分成了幾個階段：

第一階段，實現(xiàn)基于圖的分析能力：這個階段旨在提供一種通過網(wǎng)絡(luò)圖譜分析問題的渠道，提升運營和產(chǎn)品的效率，快速進行社區(qū)（設(shè)備，IP..）識別，團伙行為識別以及傳播分析。幫助我們養(yǎng)成從圖的角度去挖掘問題的習慣，并幫助我們在日常分析的過程中，總結(jié)一些經(jīng)驗，輸出一些策略。圖譜分析平臺的數(shù)據(jù)基于用戶的寫行為，將用戶，設(shè)備，IP， Objects (提問，回答..) 作為節(jié)點，具體行為作為邊。當行為發(fā)生時，將用戶與設(shè)備，用戶與 IP， 用戶與對應(yīng)的 object 關(guān)聯(lián), 而每個節(jié)點的度就代表發(fā)生關(guān)聯(lián)的數(shù)量。 圖數(shù)據(jù)存儲的部分我們當時調(diào)研了 Titan, Neo4j 和 TinkerPop，三者之中最終選擇了 TinkerPop 作為存儲框架，底層用 HBase 作為存儲。TinkerPop 是 Apache 的頂級項目之一，是面向 OLTP 及 OLAP 的圖計算框架，其擴展性非常之強，只要實現(xiàn)了 TinkerPop 定義的 API，就能作為驅(qū)動讓存儲支持圖查詢，可以減少存儲額外維護和遷移的成本。目前 Tinkerpop 支持 HBase, Neo4j, OrientDB 等等。另外也通過 GraphComputer 支持使用 Spark 進行查詢和計算。Gremlin 是 TinkerPop 定義的 DSL，可以靈活的用于圖數(shù)據(jù)的查詢。

第二階段，基于圖實現(xiàn)社區(qū)發(fā)現(xiàn)的能力：將相似的用戶通過社區(qū)的形式化成一個圈子，便于日常分析和策略運用基于一個圈子去處理。我們采用了 modularity + fast-unfolding 實現(xiàn)了社區(qū)發(fā)現(xiàn)的算法，拿設(shè)備社區(qū)為例，算法的輸入是設(shè)備與用戶的關(guān)聯(lián)，輸出是每個設(shè)備節(jié)點和每個用戶節(jié)點以及他們的社區(qū)號。模塊度（modularity）是衡量網(wǎng)絡(luò)劃分非常常用的維度，模塊度越大，意味著比期望更多的邊落在了一個社區(qū)內(nèi)，劃分效果越好。Fast-unfolding 則是一個迭代算法，主要目標就是提升劃分社區(qū)效率，使得網(wǎng)絡(luò)劃分的模塊度不斷增大，每次迭代都會將同一社區(qū)的節(jié)點合并，所以隨著迭代的增加，計算量也在不斷減少。迭代停止的條件是社區(qū)趨于穩(wěn)定或者達到迭代次數(shù)上限。

第三階段，在社區(qū)的基礎(chǔ)上，實現(xiàn)社區(qū)分類的能力：能夠有效地識別可疑和非可疑的社區(qū)，幫助日常分析和策略更好地打擊 Spam 團伙。我們使用的是可解釋性比較高的邏輯回歸，使用了一系列社區(qū)相關(guān)的特征和用戶相關(guān)的特征進行訓練，作為運營輔助數(shù)據(jù)維度和線上策略使用，都有非常好的效果, 從 2017 年 6 月以來我們已經(jīng)積累了 4w 的可疑社區(qū)和 170w 的正常社區(qū)。

文本相似度聚類

知乎站內(nèi)的 Spammer 為了快速取得收效，往往傾向于大批量地產(chǎn)生相似的 Spam 內(nèi)容，或者密集地產(chǎn)生特定的行為。針對這種大量，相似，和相對聚集的特點，我們使用 Spark 通過 jaccard 和 sim-hash 實現(xiàn)了文本聚類，通過把相似的文本聚類，實現(xiàn)對批量行為的一網(wǎng)打盡。詳細的內(nèi)容可以參見：Spark 在反作弊聚類場景的實踐

未登錄熱詞發(fā)現(xiàn)

品牌類內(nèi)容也是知乎站內(nèi)占大頭的 Spam 類型。目前站內(nèi)大部分的惡意營銷都是出于 SEO 的目的，利用知乎的 PageRank 來提升搜索引擎的關(guān)鍵詞權(quán)重。因此這類內(nèi)容的特點就是大量的關(guān)鍵詞（品牌相關(guān)，品類屬性相關(guān)的詞匯）會被提及。由于都是一些小眾品牌和新品牌，這類關(guān)鍵詞一般都未被切詞詞庫收錄，就是我們所謂的未登錄詞 (Unknown Words), 于是我們從詞匯的左右信息熵和互信息入手，去挖掘未登錄詞, 并取得了比較好的效果。關(guān)于我們實現(xiàn)的細節(jié)，可以參考我們的系列文章：反作弊基于左右信息熵和互信息的新詞挖掘。

導流詞識別

針對站內(nèi)的導流內(nèi)容，最開始在識別導流信息上采用的是干擾轉(zhuǎn)換+正則匹配+匹配項回溯的方式進行異常導流信息的識別與控制，取得了很好的效果。此外，隨著整治加強，我們發(fā)現(xiàn)站內(nèi)導流變體的現(xiàn)象也在愈演愈烈，對此，我們也成功引入模型進行整治，通過 BILSTM-CRF 來識別導流變體，目前在提問和回答的識別準確率分別達到 97.1%、96.3%。想要了解的同學快去看看我們的系列文章：算法在社區(qū)氛圍的應(yīng)用（一）：識別垃圾廣告導流信息。

通用垃圾內(nèi)容分類

對于垃圾內(nèi)容的治理，雖然線上一直有策略在覆蓋，但是策略的泛化能力有限，始終會有新型的 Spam 繞過策略。我們嘗試使用深度學習構(gòu)建通用垃圾文本分類模型。模型使用字向量作為輸入，多層 Dilated Convolution 提取文本特征，通過 Attention 對卷積后的表達重新加權(quán)得到高層特征，最后得到垃圾內(nèi)容的概率。針對近期我們遇到的批量 Spam 內(nèi)容單條規(guī)則召回率可以達到 98% 以上，準確率達到95.6%。對于「通用垃圾內(nèi)容」定義，樣本的篩選以及模型訓練的過程，我們也積累了一些經(jīng)驗和教訓。后續(xù)我們的工程師也會單獨介紹細節(jié)，敬請關(guān)注噢。

至此，「悟空」整個體系的架構(gòu)演進已經(jīng)跟大家介紹完了，當前的整體架構(gòu)如下圖所示一共有這么幾個部分：

• 
  

• Gateway: 負責異常用戶狀態(tài)攔截，業(yè)務(wù)同步攔截，反爬攔截。

• 
  

• 業(yè)務(wù)層：對接的各個業(yè)務(wù)方。

• 
  

• 數(shù)據(jù)接入層：數(shù)據(jù)接入層有兩種方式，一種通過 RPC 透傳，一種通過 kafka 消息，實現(xiàn)業(yè)務(wù)與反作弊系統(tǒng)的解耦。

• 
  

• 策略決策層：策略決策層，分為事前同步?jīng)Q策和事中事后異步?jīng)Q策，橫向?qū)?yīng)的還有策略管理服務(wù)，一系列風險分析和運營工具。根據(jù)決策結(jié)果的可疑程度不同，要么送審要么進行不同程度的處理，確認是 Spam 的行為會進入風險庫，回饋到策略再次使用。

• 
  

• 數(shù)據(jù)存儲層：數(shù)據(jù)存儲層包括基礎(chǔ)的基礎(chǔ)的事件庫，風險庫，離線 HDFS 的數(shù)據(jù)落地等等， 這一塊的數(shù)據(jù)不僅僅面向反作弊系統(tǒng)開放使用，并且會提供給外部進行模型訓練使用和在線業(yè)務(wù)使用。

• 
  

• 數(shù)據(jù)計算層：這一層包括一些離線的機器學習模型，每日定時計算模型結(jié)果，并將數(shù)據(jù)落地。

• 
  

• 數(shù)據(jù)服務(wù)層：因為反作弊不僅僅要依賴自己內(nèi)部的數(shù)據(jù)，還會涉及到從業(yè)務(wù)取相關(guān)的數(shù)據(jù)，所以這一層會涉及到與業(yè)務(wù)數(shù)據(jù)，環(huán)境數(shù)據(jù)以及模型算法服務(wù)的交互。

經(jīng)過三年的團隊的努力，「悟空」構(gòu)建了一個模型 & 策略識別 - 決策 - 管控 - 評估 & 改進的閉環(huán)。未來「悟空」還會面臨更大的挑戰(zhàn)，我們的目標不止于處理垃圾信息，更重要的是保護用戶的體驗，「悟空」的升級之路沒有止境。我們會持續(xù)在知乎產(chǎn)品（Zhihu-product）、技術(shù)（Hacker's log ）專欄中和大家介紹知乎反作弊的相關(guān)信息，歡迎關(guān)注。

作者：周奧特 陳磊 張春榮 翟峰  原文鏈接：https://zhuanlan.zhihu.com/p/39482667，轉(zhuǎn)載自周奧特的知乎賬號。