經常刷知乎的你是否好奇過這個問題：知乎的AI應用在哪些領域？應用了哪些技術和模型，產生了哪些作用？本文將從內容生產、內容消費與分發、內容連接、內容治理這四大應用場景來為你揭曉答案。
我們相信，在垃圾泛濫的互聯網海洋中，真正有價值的信息是絕對的稀缺品。
知乎CTO李大海曾在全球移動互聯網大會提到知乎誕生的初心，而這位CTO也在各種場合不遺餘力的提到知乎對於AI投入和應用。
知乎合伙人、CTO李大海
對於一個的坐擁1.4億多用戶，平均日活躍用戶量超過 3400 萬，人均日訪問時長 1 小時，月累計頁面訪問量達到 230 億的大廠來說（數據截止2018年 3 月），知乎的AI都到底應用在了哪些領域，這中間應用到了哪些技術和模型，又產生了哪些作用？
今日第1期數智方法論將從內容生產、內容消費與分發、內容連接、內容治理這四大應用場景帶你一窺知乎AI。
一、內容生產
為了讓用戶快速看到自己感興趣的提問並且激發用戶的創作慾望，知乎在內容生產上從兩個方向進行了布局：問題提出與問題路由。
1.1 問題提出
問題提出是一個從用戶的查詢中識別出意圖，發現知乎現在還無法滿足的意圖，引導用戶進行提問，並根據用戶的意圖生成合理的問題的過程，得到提問和描述后，後台的卷積神經網路模型會從知乎超過二十五萬個話題中選擇出最匹配的話題，進行話題的推薦和綁定。
1.2 問題路由
問題路由是如何分發問題以讓合適的用戶看到問題、激發他們的創作慾望。
這是一個典型的機器學習排序（learning to rank）問題：先在眾多用戶中通過召回定位合適的範圍，然後通過 pointwise／pairwise／listwise 等排序方法，找出最有可能接受邀請以及最有可能產生優質回答的用戶，進行推薦，或讓用戶選擇委託系統進行邀請。
問題路由在其中起到的就是提升匹配精準度和效率的作用。
二、內容分發和消費
內容的分發和消費部分，知乎從首頁信息流、搜索和相關推薦、首頁架構等進行了不斷地優化和升級，力圖讓每個用戶能快速、便捷地獲得更多感興趣、有用的內容。
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 已讀服務的升級
為了避免把用戶已經看過的內容再次推薦給他，信息流產品通常需要記錄下來哪些內容已經推薦給用戶過，這個信息是一個 NXN 的大表，數據量非常大且稀疏，另一方面，這個服務在讀寫上都有很高的訪問量，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++ 編寫的類似系統所能達到的水平。
三、用戶連接
知乎為了加強社區內用戶與用戶的聯繫，通過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」已經滿足了日常的策略需求，但是在使用過程知乎也發現了不少的痛點：
- 策略學習曲線陡峭, 書寫成本高：上面提到的策略採用嵌套結構，一方面對於產品運營來說學習成本有點高，另一方面書寫過程中也非常容易出現括弧缺失的錯誤。
- 策略制定周期長：在「悟空 V1」上線一條策略的流程大概會經過這幾步, 產品制定策略 – 研發實現策略 – 研發上線策略召回 – 產品等待召回 – 產品確認策略效果 – 上線處理。整個環節涉及人力與環境複雜，策略驗證麻煩，耗時長，因此策略試錯的成本也會很高。
鑒於此，「悟空 V2」著重提升了策略自助配置和上線的體驗，下面是「悟空 V2」的架構圖：
策略結構優化
參考函數式語言，新的策略結構引入了類 spark 的運算元：filter, mapper, reducer, flatMap, groupBy 等等，一般基礎的策略需求通過前三者就能實現。
舉個例子，上面提到的策略在優化之後，會變成下面這種格式：
結構上變得更清晰，可擴展性也更強，工程上只需要實現可復用的運算元即可滿足日常策略需求，不管是機器學習模型還是業務相關的數據，都可以作為一個運算元進行使用。
策略自助配置
完成了策略結構的優化，下一步需要解決的，是策略上線流程研發和產品雙重角色交替的問題，「悟空 V2」支持了策略自助配置，將研發徹底從策略配置中解放出去，進一步提升了策略上線的效率。
策略上線流程優化
為了使策略上線變得更敏捷，知乎在每一條上線的策略都在準確率和召回率之間權衡，在盡量高準確的情況下打擊盡量多的 Spam，因此每條要上線的策略都需要經過長時間的召回測試，這是一個非常耗時並且亟待優化的流程。
「悟空 V2」策略上線的流程優化成了：創建策略 – 策略測試 – 策略試運行 – 策略上線處理 – 策略監控。
策略測試主要用於對策略進行初步的驗證，避免策略有明顯的語法錯誤。
策略試運行可以理解成快照重放，通過跑過去幾天的數據，快速驗證策略效果，一切都可以在分鐘級別完成。這部分的實現將策略運行依賴的資源複製了一份，與生產環境隔離，實現一個 coordinator 將歷史的事件從 MongoDB 讀出並打入隊列。
值得注意的是，入隊速度需要控制，避免隊列被瞬間打爆。
通過試運行的驗證之後，策略就可以上線了。上線之後，策略監控模塊提供了完善的指標，包括策略執行時間、策略錯誤數、策略命中及處理量等等。
悟空 V3
2016 年中旬，知乎主站各業務開始垂直拆分，相應的，「悟空」業務接入成本的簡化開始提上日程。
Gateway
Gateway 負責與 Nginx 交互，作為通用組件對在線流量進行風險的阻斷。
目前 Gateway 承擔了所有反作弊和帳號安全用戶異常狀態攔截、反作弊功能攔截和反爬蟲攔截。
這樣一來，這部分邏輯就從業務剝離了出來，尤其是在業務獨立拆分的情況下，可以大大減少業務的重複工作。作為通用組件，也可以提升攔截邏輯的穩定性。
Gateway 當前的架構如下圖所示：
由於是串列組件，所有請求要求必須在 10ms 內完成，因此所有的狀態都緩存在 Redis。Gateway 對外暴露 RPC 介面（Robot），相關服務調用 Robot 更新用戶，IP，設備等相關的狀態到 Redis。
當用戶請求到達時，Nginx 請求 Gateway，Gateway 獲取請求中的 IP，用戶 ID等信息， 查詢 Redis 返回給 Nginx。當返回異常狀態時 Nginx 會阻斷請求，返回錯誤碼給前端和客戶端。
TSP – Trust & Safety Platform
TSP 主要為反爬蟲和反作弊提供服務：
一方面解析旁路鏡像流量，通過 Spark 完成流量清洗和基礎計數，再通過 Kafka 將計數數據打給反爬蟲策略引擎，進行檢測和處理，從而實現業務零成本接入；另一方面，由於反作弊依賴較多業務數據，難以從流量中獲取，故以 kafka 接入替代 RPC 接入，實現與業務進一步解耦，減少對業務的影響。
隨著「悟空」策略上線效率的提升，在線的策略逐漸增多，知乎開始著手優化「悟空」的檢測性能與檢測能力。
策略充分并行化
「悟空 V2」策略檢測以行為為單位分發，帶來的問題是策略增多之後，單行為檢測時長會大大增強。
在 V3優化了這部分邏輯，將策略檢測分發縮小到以策略為粒度，進一步提升策略運行的并行度，並實現了業務級別的容器隔離。
優化后，事中檢測模塊演化成了三級隊列的架構。第一級是事件隊列，下游的策略分發 worker 將數據落地，並按照事件的業務類型進行策略分發。
策略執行 worker，從二級隊列獲取任務，進行策略檢測，並將命中的事件分級處理，分發到對應的第三級隊列。第三級隊列即處理隊列，負責對命中規則的內容或者用戶進行處理。
緩存優化
因為每個策略檢測都會涉及到歷史數據的回溯，自然會帶來較多的重複查詢，存儲的壓力也會比較大，所以存儲上又增加了多級存儲，除了 MongoDB，在上層對於近期的業務數據，存儲在 Redis 和 localcache。
圖片識別能力增強
隨著文本內容檢測能力的增強，不少 spam 開始使用圖片的方式進行作弊。
在「悟空 V3」增強了圖片相關的檢測能力：圖片 OCR，廣告圖片識別，色情圖片識別，違法違規圖片識別，政治敏感圖片識別。
針對圖片類的廣告 Spam 的檢測一直是空缺，需要投入大量的人力進行模型訓練，所以這一塊知乎藉助第三方快速提升這一塊的空缺。接入之後，著實提升了解決站內廣告和詐騙圖片 Spam 的能力。
風險數據進一步積累
早期由於系統還未成熟，知乎很多的工作時間都花在 Spam 問題的應急響應上，很少去做各維度的風險數據累積。
在「悟空 V3」知乎分別在內容、帳號、IP、設備維度開始累積相關的風險數據，供策略回溯和模型訓練使用。
目前知乎有三個數據來源：策略、第三方介面和人工標註。
鑒於離線人工標註效率低，並且抽取數據項繁雜的問題，知乎專門搭建了一個標註後台，提升運營標註數據的效率，使標註數據可復用，可追溯。
以下是一些知乎比較常用的風險維度：
1. 內容維度：e.g. 導流類廣告，品牌類廣告，違反法律法規
2. 帳號維度：e.g. 批量行為（批量註冊，刷贊，刷粉等），風險帳號（社工庫泄露等）， 垃圾手機號，風險號段
3. IP 維度: e.g. 風險 IP ，代理 IP
4. 設備維度：e.g. 模擬器，無頭瀏覽器
回溯能力增強
在「悟空 V3」，知乎還增強了策略的回溯能力。
一方面，搭建失信庫覆蓋新增內容中與失信內容相似的 Spam 內容，相似度的演算法目前知乎使用的是 consine-similarity 和 jaccard；
另一方面，基於 Redis，知乎支持了基於導流詞、標籤、社區的快速回溯。這樣的話相關的行為更容易被聚集到一起，使得知乎可以突破時間的限制，對相似的 Spam 一網打盡。
此外，知乎工程和演算法團隊在演算法模型引入做了諸多嘗試。
結網 – ZNAP (Zhihu Network Analysis Platform)
過去做反作弊的很長一段時間，知乎花了很多功夫在行為和內容層面去解決 Spam 問題。但換個角度知乎發現，黑產團伙固然手上的資源巨多，但是也得考慮投入產出比，不管怎麼樣，資源都會存在被重複使用的情況，那用什麼方式去表示這種資源的使用情況呢？
知乎想到了圖，也成為了知乎做「結網」這個項目的出發點。這個項目分成了幾個階段：
第一階段，實現基於圖的分析能力：
這個階段旨在提供一種通過網路圖譜分析問題的渠道，提升運營和產品的效率，快速進行社區（設備，IP……）識別，團伙行為識別以及傳播分析。
圖譜分析平台的數據基於用戶的寫行為，將用戶，設備，IP， Objects (提問，回答……) 作為節點，具體行為作為邊。當行為發生時，將用戶與設備，用戶與 IP， 用戶與對應的 object 關聯, 而每個節點的度就代表發生關聯的數量。
圖數據存儲的部分知乎當時調研了 Titan, Neo4j 和 TinkerPop，三者之中最終選擇了 TinkerPop 作為存儲框架，底層用 HBase 作為存儲。
TinkerPop 是 Apache 的頂級項目之一，是面向 OLTP 及 OLAP 的圖計算框架，其擴展性非常之強，只要實現了 TinkerPop 定義的 API，就能作為驅動讓存儲支持圖查詢，可以減少存儲額外維護和遷移的成本。
目前 Tinkerpop 支持 HBase, Neo4j, OrientDB 等等。另外也通過 GraphComputer 支持使用 Spark 進行查詢和計算。
Gremlin 是 TinkerPop 定義的 DSL，可以靈活的用於圖數據的查詢。
第二階段，基於圖實現社區發現的能力：
將相似的用戶通過社區的形式化成一個圈子，便於日常分析和策略運用基於一個圈子去處理。
知乎採用了 modularity + fast-unfolding 實現了社區發現的演算法，拿設備社區為例，演算法的輸入是設備與用戶的關聯，輸出是每個設備節點和每個用戶節點以及他們的社區號。模塊度（modularity）是衡量網路劃分非常常用的維度，模塊度越大，意味著比期望更多的邊落在了一個社區內，劃分效果越好。
Fast-unfolding 則是一個迭代演算法，主要目標就是提升劃分社區效率，使得網路劃分的模塊度不斷增大，每次迭代都會將同一社區的節點合併，所以隨著迭代的增加，計算量也在不斷減少。迭代停止的條件是社區趨於穩定或者達到迭代次數上限。
第三階段，在社區的基礎上，實現社區分類的能力：能夠有效地識別可疑和非可疑的社區，幫助日常分析和策略更好地打擊 Spam 團伙。
知乎使用的是可解釋性比較高的邏輯回歸，使用了一系列社區相關的特徵和用戶相關的特徵進行訓練，作為運營輔助數據維度和線上策略使用，都有非常好的效果, 從 2017 年 6 月以來知乎已經積累了 4w 的可疑社區和 170w 的正常社區。
文本相似度聚類
知乎站內的 Spammer 為了快速取得收效，往往傾向於大批量地產生相似的 Spam 內容，或者密集地產生特定的行為。
針對這種大量，相似，和相對聚集的特點，使用了 Spark 通過 jaccard 和 sim-hash 實現了文本聚類，通過把相似的文本聚類，實現對批量行為的一網打盡。
未登錄熱詞發現
品牌類內容也是知乎站內佔大頭的 Spam 類型。
目前站內大部分的惡意營銷都是出於 SEO 的目的，利用知乎的 PageRank 來提升搜索引擎的關鍵詞權重。因此這類內容的特點就是大量的關鍵詞（品牌相關，品類屬性相關的辭彙）會被提及。
由於都是一些小眾品牌和新品牌，這類關鍵詞一般都未被切詞詞庫收錄，就是所謂的未登錄詞 (Unknown Words), 於是知乎從辭彙的左右信息熵和互信息入手，去挖掘未登錄詞, 並取得了比較好的效果。
導流詞識別
針對站內的導流內容，最開始在識別導流信息上採用的是干擾轉換+正則匹配+匹配項回溯的方式進行異常導流信息的識別與控制，取得了很好的效果。
此外，隨著整治加強，知乎發現站內導流變體的現象也在愈演愈烈，對此，也成功引入模型進行整治，通過 BILSTM-CRF 來識別導流變體，目前在提問和回答的識別準確率分別達到 97.1%、96.3%。
通用垃圾內容分類
對於垃圾內容的治理，雖然線上一直有策略在覆蓋，但是策略的泛化能力有限，始終會有新型的 Spam 繞過策略。知乎嘗試使用深度學習構建通用垃圾文本分類模型。
模型使用字向量作為輸入，多層 Dilated Convolution 提取文本特徵，通過 Attention 對卷積后的表達重新加權得到高層特徵，最後得到垃圾內容的概率。
針對近期知乎遇到的批量 Spam 內容單條規則召回率可以達到 98% 以上，準確率達到95.6%。
至此，「悟空」整個體系的架構演進已經介紹完了，當前的整體架構如下圖所示一共有這麼幾個部分：
1. Gateway: 負責異常用戶狀態攔截，業務同步攔截，反爬攔截。
2. 業務層：對接的各個業務方。
3. 數據接入層：數據接入層有兩種方式，一種通過 RPC 透傳，一種通過 kafka 消息，實現業務與反作弊系統的解耦。
4. 策略決策層：策略決策層，分為事前同步決策和事中事後非同步決策，橫向對應的還有策略管理服務，一系列風險分析和運營工具。根據決策結果的可疑程度不同，要麼送審要麼進行不同程度的處理，確認是 Spam 的行為會進入風險庫，回饋到策略再次使用。
5. 數據存儲層：數據存儲層包括基礎的基礎的事件庫，風險庫，離線 HDFS 的數據落地等等， 這一塊的數據不僅僅面向反作弊系統開放使用，並且會提供給外部進行模型訓練使用和在線業務使用。
6. 數據計算層：這一層包括一些離線的機器學習模型，每日定時計算模型結果，並將數據落地。
7. 數據服務層：因為反作弊不僅僅要依賴自己內部的數據，還會涉及到從業務取相關的數據，所以這一層會涉及到與業務數據，環境數據以及模型演算法服務的交互。
基於知乎四大場景的AI技術與應用就整理到這裡，為了方便大家回顧，數智君對於文中所提到的部分技術、模型和演算法做了簡要腦圖整理：
從這篇能大致看出知乎做起AI來也真的是很「知乎」，一步步改進，一步步優化，並且基於場景和業務本身也做了許多符合自身情況的嘗試。
既然「穩定而高質量的知識內容」被譽為知乎的護城河，不知道知乎的AI能否持續加固這個護城河？
歡迎在評論區發表你的看法，如果這篇方法論讓你有所收穫，對我的文章感興趣點擊收藏、訂閱~
參考文獻
（1）知乎技術專欄；
（2）知乎產品專欄；
（3）邱陸陸，《知乎：源自社區又服務於社區的 AI 技術》，機器之心公眾號，2018年06月13日；
（4）極客邦科技 InfoQ，《知乎 CTO 李大海：知識內容平台 AI 技術應用思考》，2019 年 1 月 16 日；
（5）阿司匹林，《呵呵，你開心就好！——AI向杠精宣戰》，AI科技大本營公眾號，2018年07月02日；
（6）王藝瑾，《融資2.7億美元，知乎仍面臨護城河焦慮》，36氪, 2018-08-11；
編譯：捲毛雅各布
公眾號：數智物語（公眾號ID：decision_engine）出品策劃