文章發佈於公號【數智物語】 （ID：decision_engine），關註公號不錯過每一篇乾貨。

數智物語（公眾號ID：decision_engine）出品

策劃、編寫：捲毛雅各布

「我們相信，在垃圾泛濫的互聯網海洋中，真正有價值的信息是絕對的稀缺品。」知乎CTO李大海曾在全球移動互聯網大會提到知乎誕生的初心，而這位CTO也在各種場合不遺餘力的提到知乎對於AI投入和應用。

知乎合伙人、CTO李大海

對於一個的坐擁1.4億多用戶，平均日活躍用戶量超過 3400 萬，人均日訪問時長 1 小時，月累計頁面訪問量達到 230 億的大廠來說（數據截止2018年 3 月），知乎的AI都到底應用在了哪些領域，這中間應用到了哪些技術和模型，又產生了哪些作用？今日第1期數智方法論將從內容生產、內容消費與分發、內容連接、內容治理這四大應用場景帶你一窺知乎AI。

目錄：

1 內容生產

   1.1 問題提出

   1.2 問題路由

2 內容分發和消費

   2.1 首頁「水晶球」推薦系統

   2.2 知乎首頁信息流演算法進化史

   2.3 首頁架構改進

   2.4 知乎搜索系統

3 用戶連接

   3.1 基於用戶行為的 Embeeding 表示

   3.2 基於用戶社交關係的 Embeeding 表示

4. 內容治理

   4.1 瓦力治杠精

   4.2 悟空反作弊

1. 內容生產

為了讓用戶快速看到自己感興趣的提問並且激發用戶的創作欲望，知乎在內容生產上從兩個方向進行了佈局：問題提出與問題路由。

1.1 問題提出

問題提出是一個從用戶的查詢中識別出意圖，發現知乎現在還無法滿足的意圖，引導用戶進行提問，並根據用戶的意圖生成合理的問題的過程，得到提問和描述後，後臺的捲積神經網路模型會從知乎超過二十五萬個話題中選擇出最匹配的話題，進行話題的推薦和綁定。

1.2 問題路由

問題路由是如何分發問題以讓合適的用戶看到問題、激發他們的創作欲望。這是一個典型的機器學習排序（learning to rank）問題：先在眾多用戶中通過召回定位合適的範圍，然後通過 pointwise／pairwise／listwise 等排序方法，找出最有可能接受邀請以及最有可能產生優質回答的用戶，進行推薦，或讓用戶選擇委托系統進行邀請。問題路由在其中起到的就是提升匹配精準度和效率的作用。

2. 內容分發和消費

內容的分發和消費部分，知乎從首頁信息流、搜索和相關推薦、首頁架構等進行了不斷地優化和升級，力圖讓每個用戶能快速、便捷地獲得更多感興趣、有用的內容。

2.1 首頁「水晶球」推薦系統

知乎的「水晶球」信息流推薦框架是一個基於多策略融合的多源內容推薦系統，關於「水晶球」的來源知乎首頁負責人張瑞提到：『我們把系統命名為「水晶球」，是希望能夠通過這個系統得以一窺用戶想要看到什麼內容，然後推薦給他』。

如下圖所示，在這個系統中，首頁上出現的內容會經歷兩次排序： 第一次是從數十個推薦隊列里被「召回」，第二次是在合併後經過深層神經網路（DNN）的「排序」。

「水晶球」信息流推薦框架

對於如何「召回」和「排序」，知乎團隊也做過詳細介紹：

「召回」的第一個步驟是，召回模塊根據用戶的歷史行為表現（用戶畫像），確定數十個推薦隊列，或者說數十個「召回源」的召回比例和召回數量。推薦隊列是一個個含有特定標簽的內容合集。有些隊列里內容性質相似，比如熱點新聞隊列、視頻隊列。還有的隊列與用戶行為緊密相關，比如關註的人隊列、搜索關鍵詞隊列。

「召回」過程的第二個步驟是各召回源根據用戶的需求分別將自己的隊列中的內容做排序後，按召回數量返回內容。

「召回」過程會選出數百條候選內容進入「排序」過程，最後，DNN 可以在一百毫秒內對這數百條完成打分和排序過程，決定推送給用戶的內容。

2.2 知乎首頁信息流演算法進化史

2.2.1 Edge Rank 演算法

知乎從 2013 年就上線了信息流產品。當時的主邏輯是一套叫做 Edge Rank 的演算法。把用戶關註的所有人和話題所產生的所有新內容，當成候選池，候選池裡的每個內容的權重與三個因素相關，分別是表示用戶對關註對象的關註度的權重，內容的類型，以及時效性權重。

2.2.2 GBDT 演算法

隨著知乎體量的增長，Edge Rank 已經不能滿足分發效率的需要。知乎從 2016 年開始升級首頁產品。首先使用 GBDT 來進行 CTR 預估，並以 CTR 預估值作為排序的主要考慮因素。GBDT 演算法的引入，對知乎首頁的分發效率提升是非常可觀的。GBDT 的演算法首次上線，用戶停留時長就有了 12% 的提升，後續不斷改進演算法，一年時間裡面，累積獲得了 70% 的用戶線上時長的增長。GBDT 的優勢是可解釋，並且需要的訓練數據量級不算太大，GBDT 的研發、調試和訓練成本都較低，從 0 開始構建的時間成本也比較可控，特別適合研發及計算資源比較受限、但又亟需使用機器學習改進業務的團隊嘗試。

2.2.3 深度學習技術

從 2017 年開始，知乎將深度學習技術引入了首頁推薦產品之中。原有GBDT 模型的容量和表示能力有很大的限制，當模型的訓練樣本量達到千萬數量級時，再增加訓練樣本的規模，模型精確度已經得不到明顯的改善。所以知乎轉向了深度學習技術。

知乎用戶的興趣比較廣泛，一個用戶在知乎上往往會對幾十、上百個話題感興趣。在這種情況下，用傳統的 content based 演算法，會有大量的分發策略需要人工設計，例如興趣的衰減、交叉、去重等。而要是用 ALS 之類的協同過濾演算法，又會面臨數據過於稀疏的問題，知乎到了一個用戶和內容都達到了上億量級規模的推薦場景。

所以，他們參考了 word2vec 的設計思路，設計了一個 DNN 網路，希望把每個用戶和每一篇內容都表示成同一個空間的向量。任意兩個向量的距離越小，表示它們越相關，如果這兩個向量一個是用戶，一個是內容，那就代表該用戶對該內容感興趣的概率越高。有了這個表示之後，對於每個用戶，都可以利用 ANN 演算法（Approximate Nearest Neighbor，近似最近鄰搜索）召回它可能喜歡的內容。

這個 DNN 網路結構比較簡單，但作為召回系統的效益是非常明顯的。知乎衡量推薦系統的召回模塊有效性時，主要看一個關鍵的指標，從幾萬條數據中挑出的 100 個結果的準確度有多少，這 100 個結果里有多少準確預測到用戶下次點擊的數據。在這個指標上， DNN 比起 ALS 來講提升了 10 倍的量級。當然，這個 DNN 網路也有一個問題，那就是新內容的表示不會在老的網路中自動被學習到。

為了保證新內容能夠比較快地被感興趣的用戶看到，知乎採用一個離線流水線來解決這個問題。這條流水線使用 spark streaming 來實現了內容 embedding 的批量更新。這個 spark streaming 應用會採集線上的數據，根據線上內容的分髮狀況，以及用戶對這些內容的行為反饋情況，通過一個簡單的、兩層神經網路的梯度下降，快速更新內容庫中內容的 embedding 表示。

隨後知乎也把 DNN 用在了排序中。最初上線的 DNN 是一個比較簡單的全連接版本。

在上線後知乎持續地對這個模型進行了各種優化，包括引入 FM 層作特征之間的自動交叉、利用捲積神經網路處理文本輸入、利用 LSTM 處理時序序列數據等，都取得了較好的效果。採用 DNN 模型的召回和排序上線後，再結合這些持續不斷地優化，Feed 流的人均閱讀量和人均使用時長均增長了 50% 以上。

2.2.4 多目標學習

在知乎上，除了「閱讀」這種行為非常重要外，其他的一些交互動作，例如點贊、評論、分享、收藏等，也都是反映用戶體驗的重要的行為指徵。

對於首頁的優化，除了上面介紹的方法之外，知乎也進行了多種方向的嘗試。其中一個方向是多目標學習。從 GBDT 開始到現在的 DNN 網路，本質上都是 CTR 預估。所以知乎設計了一個機制來進行多目標學習，拋棄只看點擊率的局限性。

具體來說，是使用豐富的閱讀數據來訓練一個基準網路，然後利用這個基準網路的前面一些層做參數共用，在後兩層，分別對於不同的學習目標，進行參數的微調。

這是一種遷移學習的思路，可以大大節省離線模型訓練和線上多目標推斷時的計算量。多目標排序目前在知乎的實際應用中已經有一些初步的結果，通過小流量對比發現，使用多目標模型來排序，除閱讀之外的行為量都能有 10% 左右的增長。

另外，知乎也在探索如何在排序學習中體現推薦列表的多樣性。CTR 預估實際上是一種 pointwise 的排序方法，可能造成的後果是，如果用戶對很多內容感興趣，在內容質量相當的情況下，這種排序會將「最喜歡的一類內容」全都排到最前面，造成用戶閱讀時的疲憊感和單調感。

一般來說，線上都會使用一些 Rerank 的方法，例如打散、隔離等規則，來保證多樣性。但人工規則既不精確，設計起來也非常容易出 badcase。所以，知乎正在嘗試利用 seq2seq 的方法，來為用戶直接生成推薦內容的列表。在 seq2seq 模型中，會將用戶已經看到的內容考慮進去做為模型的輸入，來體現用戶推薦列表的多樣性。

2.2.5 人機結合

知乎CTO李大海毫不避諱地提到知乎目前的機器學習演算法並不完美，尤其是在 NLP 領域，在語義理解方向上，AI 技術還有很大的提升空間。為了讓用戶得到更好的體驗，知乎的 AI 應用自始至終都伴隨著人的高度參與，人機結合是避免「演算法偏見」出現的有效方法之一。

所以知乎在今年啟動了一項名為「泰戈爾」的計劃，從標簽定義、標簽生產、質量審核、標簽應用等方面，建立了一套對內容進行識別和應用的閉環，並明確了演算法、運營、業務團隊在這個閉環中的角色。

這個計劃啟動以後，在機器識別方面，接入了領域識別、內容質量判定、內容時效性識別等多個維度的識別演算法，同時，知乎內容運營的同事會在機器識別的基礎上，每天都會對健康、影視、法律等多個領域的，成千上萬篇內容進行標註和演算法結果的糾正。

2.3 首頁架構改進

除了演算法方面的改進之外，首頁推薦團隊在架構上從兩個方面進行了改進：

2.3.1 已讀服務的升級

為了避免把用戶已經看過的內容再次推薦給他，信息流產品通常需要記錄下來哪些內容已經推薦給用戶過，這個信息是一個 N X N 的大表，數據量非常大且稀疏，另一方面，這個服務在讀寫上都有很高的訪問量，hbase 這樣的服務在響應時間的穩定性上，不能達到知乎的要求，所以知乎實現了一個叫 Rbase 的系統，這個系統綜合利用了 MySQL 的存儲能力和可靠性以及 Redis 的低時延和高吞吐。

在緩存失效的情況下對同一個熱鍵值的併發讀取不會產生驚群效應。利用寫通緩存的更新策略再加上變更下推來維護緩存的一致性，所以不需要對緩存數據設定過期時間。知乎使用分層緩存來從空間維度和時間維度提高命中率。利用分層緩存還可以更有效的應對跨數據中心部署時帶寬受限的問題。最重要的是 Rbase 提供了 BigTable 一樣的數據模型，並且和 Hbase 的 API 在功能和用法上非常接近，方便遷移。

2.3.2 推薦架構的改造

知乎早期廣泛採用 python 語言來進行開發，包括首頁推薦的業務框架也不例外。在經過長時間的功能疊加之後，老系統在響應時間優化以及可維護性等方面，已經很難提出比較高的要求。所以知乎在 18 年使用 java 進行了系統的重寫，不僅大幅度優化了響應時間，節約了比較多的機器資源，還引入了多隊列召回的能力，允許從不同維度召回與用戶相關的內容，進一步提高多樣性。

2.4 知乎搜索系統

搜索是知乎在壯大過程中逐步優化的一個功能。知乎希望通過個性化推薦和搜索系統，儘可能縮短用戶和內容之間的距離，讓用戶在知乎擺脫信息過載帶來的負擔和壓力。

2.4.1 搜索演算法改進與應用

以深度學習為代表的搜索相關性語義特征，知乎的搜索演算法近幾年獲得了長足的發展：從最早的以 DSSM 為代表的 Query/Doc 分別提取深度表徵的方法，到近期的以MatchPyramid, KNRM 等為代表的 Query/Doc 相互交叉為相關度圖再做計算的方法，再到這兩類方法相互融合的方法，以及最近的 BERT 模型。知乎在實踐過程中發現 MatchPyramid, KNRM 等第二類方法的效果，普遍優於 DSSM 等第一類方法。深度語義特征上線之後，知乎在頭部、腰部、長尾的搜索點擊比普遍提升了約 2% - 3% 不等。

2.4.2 搜索架構優化

除了演算法方面的改進，知乎也投入了不少人力在搜索的架構優化上。早年採用 ES 作為索引引擎，隨著數據量的增加，知乎遇到了 ES 集群的服務穩定性問題，以及 ES 對排序演算法支持不友好等問題。所以在 17 年，知乎自己開發了一套在索引格式上完全相容 ES 的引擎系統，逐步替換了線上上服務的 ES 集群。這個系統使用 Rust 開發，Rust 語言是一種類似於 C/C++ 的無 GC 語言，李大海曾提到雖然 Rust 語言的學習曲線非常陡峭，但是在團隊熟悉語言後，由於 Rust 能在編譯器層面避免記憶體安全問題和併發安全問題，所以整體獲得的收益是非常顯著的。目前知乎全部的搜索請求都由新的索引服務支撐，在可用性達到了 5 個 9 的同時性能上也不輸於 C++ 編寫的類似系統所能達到的水平。

3. 用戶連接

知乎為了加強社區內用戶與用戶的聯繫，通過Graph Embedding 模型對用戶進行隱式表示的學習，計算出兩個用戶之間的親密度、興趣相似度，以此進行更精準的推薦，讓用戶更多地在社區里發生連接。

3.1 基於用戶行為的 Embeeding 表示

基於用戶行為的 Embeeding 表示，主要使用用戶搜索內容、關註、收藏、點贊、閱讀的回答、文章等對應的話題，作為用戶的特征，整理成 0-1 的向量。使用變分自編碼器（Variational Auto-Encoder，VAE） ，使樣本對應到正態分佈，計算此正態分佈和標準正態分佈的 KL 散度距離作為額外的 loss，最終為得到用戶的 Embedding 表示。

3.2 基於用戶社交關係的 Embeeding 表示

基於用戶社交關係的 Embeeding 表示，主要使用 skip-gram 模型，得到用戶的特征表示，從用戶關註優秀回答者的關註關係網路中抽取數據集，採用 Randomwalk 方法抽樣有序的節點，從而將社交網路轉化為有序節點進行學習。

Embedding 模型主要應用在了知乎的以下場景：

1. 用戶聚類：使用用戶聚類來在推薦中做召回，使用用戶 Embedding 表示，經過聚類計算後，得到用戶的人群，可以把這個群體的高互動內容作為 feed 候選，放入到推薦系統當中。

2. 用戶親密度：使用用戶 Embedding 表示 + 用戶對用戶的互動行為特征，可以預測用戶的關註關係，得到用戶親密度值。這個值用在很多和社交相關的策略之中。

3． 基於種子用戶和 user representation 的人群擴展：人工給定或者策略圈定種子用戶，使用用戶 Embedding 表示計算得到和種子用戶最相近的 top n 用戶進行目標人群擴展，這個能力目前主要應用於商業化產品中。

4. 內容治理

36氪報道過知乎一直把「穩定而高質量的知識內容」作為重要的護城河，但隨著用戶的不斷增加，以及演算法的普遍應用，甚至是競爭對手「挖牆腳」（2017年今日頭條挖走300個知乎大V ，並且簽約後禁止發知乎，今日頭條後續推出了悟空問答，騰訊新聞客戶端也推出過問答產品），似乎知乎的推送內容與頭條並無太大區別，知乎社區的內容質量也有所下降。在內憂外患情況下知乎對於內容治理也進行了大刀闊斧的改革，「瓦力」、「悟空」等演算法和系統不斷出擊，並且加大了人工質檢的投入。

4.1 瓦力治杠精

瓦力：社區管理的「大腦」

所謂「杠精」是指抬杠成癮的一類群體。不管別人說的是什麼，先反駁挑刺，為了反對而反對，通過反駁別人來凸顯自己的優越感，再加上「只有我一個人覺得……」句式的加持，基本上能成功惹翻他人。 2018年12月3日，詞語「杠精」被《咬文嚼字》公佈為2018十大流行語。而「杠精」在知乎具體體現為各種「陰陽怪氣」的言論，「瓦力」就專門針對這類杠精言論而生。

瓦力演算法系統作為整個知乎社區管理的「大腦」，以知乎社區管理規範為標準，主要應用於不友善、答非所問、低質提問、色情低俗、違法違規等方面的治理。從18年4月自上線至今，瓦力已經過多次的迭代更新，被應用多個使用場景中。

目前，這個系統可以做到：實時篩查並處理社區新生產內容中的不友善因素；結合知友們的舉報，在 0.3 秒內識別判斷被舉報內容是否包含不友善因素，並做出相應處理；每天清理約 5000 條新產生的「答非所問」內容，以及此前現存的近 120 萬條「答非所問」內容，還能實時對社區內提問進行篩查，每天處理約 900 條封建迷信、求醫問藥類的低質提問；能夠識別色情圖文、違法違規、垃圾廣告等內容。

下圖比較完備地展示了知乎識別陰陽怪氣評論的技術方案。知乎把評論和相應回答的文本特征、標點符、表情符統計特征、是否命中反諷詞表等多維度 feature 作為模型的輸入，採用 CNN 和 LSTM 相結合的網路拓樸結構訓練二分類模型；

在訓練數據獲取方面，使用站內有大量一致用戶行為的語料，來自動生成二元的標註；為了提高模型泛化能力，通過 active learning 方法選取站內評論，經過人工標註加入訓練集。2018年 6 月，「瓦力」的陰陽怪氣識別功能上線，在召回率 25% 的情況下，準確率達到了 95%。

具體來說，解決方案分為了以下三個步驟：

1. 進行數據增強，以提升模型的泛化能力

數據增強是為了提升模型在大量數據上的泛化能力。在這方面，知乎進行了兩種嘗試：提取陰陽怪氣關鍵詞做替換，比如同音異字變換，洗地黨→洗滌黨，真的很噁心 → 震得很噁心；此外，知乎也利用提取出的陰陽怪氣關鍵樣本，隨機構造評論上文與評論。

2. 提取相關數據特征，利用捲積網路以及人工特征等來獲得更多更詳細的特征

特征構建層方面，知乎從文本特征、數值特征、陰陽怪氣詞以及表情詞著手。文本特征即文本加入陰陽怪氣關鍵詞進行分詞後，保留標點，表情等；數值特征即句子長度，句號數量，感嘆號數據等；陰陽怪氣詞即提取社區內被踩過很多次的表示陰陽怪氣關鍵詞；表情特征：劃分正負樣本表情。

3. 將提取出的特征輸入分類器

特征學習層方面，主要考慮了評論和上文的文本特征，包括字，詞，標點，表情符號等，並利用知乎全量數據訓練 word2vec 模型。知乎將評論上文與評論經過 embedding 層後分成兩個金字塔型 CNN 網路，目的是訓練各自獨立的參數，知乎採取 CNN 網路是因為 CNN 捲積可以捕獲字詞的位置關係也可以比較有效的提取特征。

除上述文本特征外，知乎也充分考慮了其它特征，比如評論長度，評論中句號，問號等標點的個數，評論中是否包含陰陽怪氣關鍵詞等；這些特征離散化後，與評論的捲積提取特征進行拼接，最後與評論上文的捲積輸出進行 dot-attention ，目的是獲取評論上文與評論不同的權重。最後，知乎將特征數據全連接層以 softmax 方式進行了分類。

儘管瓦力在各個維度進行的社區治理準確度已超過 90%，但卻是無法取代人工的，知乎也沒有將內容和社區管理的任務全部集於演算法一身，而是採用演算法 + 人工的方式。對瓦力處理的內容，知乎會每天進行質檢，同時也有專門的團隊對於用戶申訴進行覆核和響應。

4.2 悟空反作弊

Wukong 是知乎的反作弊系統，主要負責 SPAM 的召回和處理。從 2015 年 4 月上線，隨著知乎的不斷發展壯大，悟空也進行著持續地優化升級。接下來分享下知乎「悟空」的架構演進和構建過程中積累的經驗與教訓。

4.2.1 知乎典型 Spam

在知乎長期存在，且比較典型的 Spam有這麼幾類：

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

導流內容：這類 Spam 大概能占到社區中 Spam 的 70% - 80%，比較典型的包括培訓機構, 美容，保險，代購相關的 Spam。導流內容會涉及到 QQ，手機號，微信，url 甚至座機，在一些特殊時間節點還會出現各類的專項 Spam，比如說世界盃，雙十一，雙十二，都是黑產大賺一筆的好時機。

品牌內容：這類內容會具有比較典型的 SEO 特色，一般內容中不會有明顯的導流標識，作弊形式以一問一答的方式出現，比如提問中問什麼牌子怎麼樣？哪裡的培訓學校怎麼樣？然後在對應的回答裡面進行推薦。

詐騙內容：一般以冒充名人，機構的方式出現，比如單車退款類 Spam，在內容中提供虛假的客服電話進行詐騙。

騷擾內容：比如一些誘導類，調查類的批量內容，非常嚴重影響知友體驗。

2.行為作弊 spam：主要包括刷贊，刷粉，刷感謝，刷分享，刷瀏覽等等，一方面為了達到養號的目的，躲過反作弊系統的檢測，另一方面通過刷量行為協助內容在站內的傳播。

治理經驗：治理上述問題的核心點在於如何敏捷、持續地發現和控制風險，並保證處理成本和收益動態平衡，從 Spam 的獲益點入手，進行立體防禦。所謂立體防禦，就是通過多種控制手段和多個控制環節增強發現和控制風險的能力。

4.2.2 三種控制方式

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

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

模型反作弊：機器學習模型可以充分提高反作弊系統的泛化能力，降低策略定製的成本。模型應用需要酌情考慮加入人工審核來保證效果，直接處理內容或用戶的模型演算法，要註意模型的可解釋性。初期一些無監督的聚類演算法能夠在比較短時間內達到較好的效果。而有監督的分類演算法，在時間上和人力上的耗費會更多，樣本的完整程度，特征工程做的好壞，都會影響演算法的效果。

4.2.3 三個控制環節

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

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

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

4.2.4 知乎「悟空」的架構演進

悟空 V1

初期 「悟空」主要由事前模塊和事中模塊構成。

事前模塊與業務串列執行，適用於做一些耗時短的頻率檢測，關鍵詞和黑白名單攔截。由於是同步介面，為了儘量少的減少對業務的影響，大部分複雜的檢測邏輯由事中模塊去處理。

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

事件接入

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

策略引擎

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

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

這條策略主要實現了這樣的邏輯：

最近 10 分鐘在同一話題下創建的回答，與當前用戶，註冊時間在一小時之內，同一 IP 下註冊的用戶數大於等於 3 個。

基本上這樣的模式足夠滿足日常的 Spam 檢測需求，但是知乎發現這種嵌套結構對於書寫與閱讀來說還是不太友好，這個部分的優化在 V2有作詳細描述。

考慮到策略變更會遠大於基礎模塊，在 V1 的架構中，知乎特別將策略維護的邏輯單獨拆分成服務，一方面，可以實現平滑上下線，另一方面，減少策略變更對穩定性帶來的影響。

存儲選型

存儲上，知乎選擇了 MongoDB 作為基礎事件存儲，Redis 作為關鍵 RPC 的緩存。選擇 MongoDB 的原因一方面是因為知乎基礎事件庫的業務場景比較簡單，不需要事務的支持；另一方面，知乎面對的是讀遠大於寫的場景，並且 90% 都是對最近一段時間熱數據的查詢，隨機讀寫較少, 這種場景下 MongoDB 非常適合。另外，初期由於需求不穩定，schema-free 也是 MongoDB 吸引知乎的一個優點。由於策略檢測需要調用非常多的業務介面，對於一些介面實時性要求相對沒那麼高的特征項，知乎使用了 Redis 作為函數緩存，相對減少業務方的調用壓力。

悟空 V2

「悟空 V1」已經滿足了日常的策略需求，但是在使用過程知乎也發現了不少的痛點：

1. 策略學習曲線陡峭, 書寫成本高：上面提到的策略採用嵌套結構，一方面對於產品運營來說學習成本有點高，另一方面書寫過程中也非常容易出現括弧缺失的錯誤。

2. 策略制定周期長：在「悟空 V1」上線一條策略的流程大概會經過這幾步, 產品制定策略 - 研發實現策略 - 研發上線策略召回 - 產品等待召回 - 產品確認策略效果 - 上線處理。整個環節涉及人力與環境複雜，策略驗證麻煩，耗時長，因此策略試錯的成本也會很高。