国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

經(jīng)常刷知乎的你是否好奇過這個問題：知乎的AI應(yīng)用在哪些領(lǐng)域？應(yīng)用了哪些技術(shù)和模型，產(chǎn)生了哪些作用？本文將從內(nèi)容生產(chǎn)、內(nèi)容消費與分發(fā)、內(nèi)容連接、內(nèi)容治理這四大應(yīng)用場景來為你揭曉答案。

我們相信，在垃圾泛濫的互聯(lián)網(wǎng)海洋中，真正有價值的信息是絕對的稀缺品。

知乎CTO李大海曾在全球移動互聯(lián)網(wǎng)大會提到知乎誕生的初心，而這位CTO也在各種場合不遺余力的提到知乎對于AI投入和應(yīng)用。

知乎合伙人、CTO李大海

對于一個的坐擁1.4億多用戶，平均日活躍用戶量超過 3400 萬，人均日訪問時長 1 小時，月累計頁面訪問量達到 230 億的大廠來說（數(shù)據(jù)截止2018年?3 月），知乎的AI都到底應(yīng)用在了哪些領(lǐng)域，這中間應(yīng)用到了哪些技術(shù)和模型，又產(chǎn)生了哪些作用？

今日第1期數(shù)智方法論將從內(nèi)容生產(chǎn)、內(nèi)容消費與分發(fā)、內(nèi)容連接、內(nèi)容治理這四大應(yīng)用場景帶你一窺知乎AI。

一、內(nèi)容生產(chǎn)

為了讓用戶快速看到自己感興趣的提問并且激發(fā)用戶的創(chuàng)作欲望，知乎在內(nèi)容生產(chǎn)上從兩個方向進行了布局：問題提出與問題路由。

1.1 問題提出

問題提出是一個從用戶的查詢中識別出意圖，發(fā)現(xiàn)知乎現(xiàn)在還無法滿足的意圖，引導(dǎo)用戶進行提問，并根據(jù)用戶的意圖生成合理的問題的過程，得到提問和描述后，后臺的卷積神經(jīng)網(wǎng)絡(luò)模型會從知乎超過二十五萬個話題中選擇出最匹配的話題，進行話題的推薦和綁定。

1.2 問題路由

問題路由是如何分發(fā)問題以讓合適的用戶看到問題、激發(fā)他們的創(chuàng)作欲望。

這是一個典型的機器學(xué)習(xí)排序（learning to rank）問題：先在眾多用戶中通過召回定位合適的范圍，然后通過 pointwise／pairwise／listwise 等排序方法，找出最有可能接受邀請以及最有可能產(chǎn)生優(yōu)質(zhì)回答的用戶，進行推薦，或讓用戶選擇委托系統(tǒng)進行邀請。

問題路由在其中起到的就是提升匹配精準度和效率的作用。

二、內(nèi)容分發(fā)和消費

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

2.1 首頁「水晶球」推薦系統(tǒng)

知乎的「水晶球」信息流推薦框架是一個基于多策略融合的多源內(nèi)容推薦系統(tǒng)，關(guān)于「水晶球」的來源知乎首頁負責(zé)人張瑞提到：

我們把系統(tǒng)命名為「水晶球」，是希望能夠通過這個系統(tǒng)得以一窺用戶想要看到什么內(nèi)容，然后推薦給他。

如下圖所示，在這個系統(tǒng)中，首頁上出現(xiàn)的內(nèi)容會經(jīng)歷兩次排序： 第一次是從數(shù)十個推薦隊列里被「召回」，第二次是在合并后經(jīng)過深層神經(jīng)網(wǎng)絡(luò)（DNN）的「排序」。

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

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

• 「召回」的第一個步驟是，召回模塊根據(jù)用戶的歷史行為表現(xiàn)（用戶畫像），確定數(shù)十個推薦隊列，或者說數(shù)十個「召回源」的召回比例和召回數(shù)量。推薦隊列是一個個含有特定標簽的內(nèi)容合集。有些隊列里內(nèi)容性質(zhì)相似，比如熱點新聞隊列、視頻隊列。還有的隊列與用戶行為緊密相關(guān)，比如關(guān)注的人隊列、搜索關(guān)鍵詞隊列。
• 「召回」過程的第二個步驟是各召回源根據(jù)用戶的需求分別將自己的隊列中的內(nèi)容做排序后，按召回數(shù)量返回內(nèi)容。
• 「召回」過程會選出數(shù)百條候選內(nèi)容進入「排序」過程，最后，DNN 可以在一百毫秒內(nèi)對這數(shù)百條完成打分和排序過程，決定推送給用戶的內(nèi)容。

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

2.2.1 Edge Rank 算法

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

2.2.2?GBDT 算法

隨著知乎體量的增長，Edge Rank 已經(jīng)不能滿足分發(fā)效率的需要。

知乎從 2016 年開始升級首頁產(chǎn)品。首先使用 GBDT 來進行 CTR 預(yù)估，并以 CTR 預(yù)估值作為排序的主要考慮因素。

GBDT 算法的引入，對知乎首頁的分發(fā)效率提升是非常可觀的。

GBDT 的算法首次上線，用戶停留時長就有了 12% 的提升，后續(xù)不斷改進算法，一年時間里面，累積獲得了 70% 的用戶在線時長的增長。

GBDT 的優(yōu)勢是可解釋，并且需要的訓(xùn)練數(shù)據(jù)量級不算太大，GBDT 的研發(fā)、調(diào)試和訓(xùn)練成本都較低，從 0 開始構(gòu)建的時間成本也比較可控，特別適合研發(fā)及計算資源比較受限、但又亟需使用機器學(xué)習(xí)改進業(yè)務(wù)的團隊嘗試。

2.2.3 深度學(xué)習(xí)技術(shù)

從?2017 年開始，知乎將深度學(xué)習(xí)技術(shù)引入了首頁推薦產(chǎn)品之中。

原有GBDT 模型的容量和表示能力有很大的限制，當模型的訓(xùn)練樣本量達到千萬數(shù)量級時，再增加訓(xùn)練樣本的規(guī)模，模型精確度已經(jīng)得不到明顯的改善。所以知乎轉(zhuǎn)向了深度學(xué)習(xí)技術(shù)。

知乎用戶的興趣比較廣泛，一個用戶在知乎上往往會對幾十、上百個話題感興趣。

在這種情況下，用傳統(tǒng)的 content based 算法，會有大量的分發(fā)策略需要人工設(shè)計，例如興趣的衰減、交叉、去重等。而要是用 ALS 之類的協(xié)同過濾算法，又會面臨數(shù)據(jù)過于稀疏的問題，知乎到了一個用戶和內(nèi)容都達到了上億量級規(guī)模的推薦場景。

所以，他們參考了?word2vec 的設(shè)計思路，設(shè)計了一個 DNN 網(wǎng)絡(luò)，希望把每個用戶和每一篇內(nèi)容都表示成同一個空間的向量。

任意兩個向量的距離越小，表示它們越相關(guān)，如果這兩個向量一個是用戶，一個是內(nèi)容，那就代表該用戶對該內(nèi)容感興趣的概率越高。

有了這個表示之后，對于每個用戶，都可以利用 ANN 算法（Approximate Nearest Neighbor，近似最近鄰搜索）召回它可能喜歡的內(nèi)容。

這個?DNN 網(wǎng)絡(luò)結(jié)構(gòu)比較簡單，但作為召回系統(tǒng)的效益是非常明顯的。

知乎衡量推薦系統(tǒng)的召回模塊有效性時，主要看一個關(guān)鍵的指標，從幾萬條數(shù)據(jù)中挑出的 100 個結(jié)果的準確度有多少，這 100 個結(jié)果里有多少準確預(yù)測到用戶下次點擊的數(shù)據(jù)。在這個指標上， DNN 比起 ALS 來講提升了 10 倍的量級。

當然，這個 DNN 網(wǎng)絡(luò)也有一個問題，那就是新內(nèi)容的表示不會在老的網(wǎng)絡(luò)中自動被學(xué)習(xí)到。

為了保證新內(nèi)容能夠比較快地被感興趣的用戶看到，知乎采用一個離線流水線來解決這個問題。

這條流水線使用 spark streaming 來實現(xiàn)了內(nèi)容?embedding 的批量更新。這個 spark streaming 應(yīng)用會采集線上的數(shù)據(jù)，根據(jù)線上內(nèi)容的分發(fā)狀況，以及用戶對這些內(nèi)容的行為反饋情況，通過一個簡單的、兩層神經(jīng)網(wǎng)絡(luò)的梯度下降，快速更新內(nèi)容庫中內(nèi)容的 embedding 表示。

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

在上線后知乎持續(xù)地對這個模型進行了各種優(yōu)化，包括引入?FM 層作特征之間的自動交叉、利用卷積神經(jīng)網(wǎng)絡(luò)處理文本輸入、利用 LSTM 處理時序序列數(shù)據(jù)等，都取得了較好的效果。

采用 DNN 模型的召回和排序上線后，再結(jié)合這些持續(xù)不斷地優(yōu)化，F(xiàn)eed 流的人均閱讀量和人均使用時長均增長了 50% 以上。

2.2.4 多目標學(xué)習(xí)

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

對于首頁的優(yōu)化，除了上面介紹的方法之外，知乎也進行了多種方向的嘗試。

其中一個方向是多目標學(xué)習(xí)。從?GBDT 開始到現(xiàn)在的 DNN 網(wǎng)絡(luò)，本質(zhì)上都是 CTR 預(yù)估。所以知乎設(shè)計了一個機制來進行多目標學(xué)習(xí)，拋棄只看點擊率的局限性。

具體來說，是使用豐富的閱讀數(shù)據(jù)來訓(xùn)練一個基準網(wǎng)絡(luò)，然后利用這個基準網(wǎng)絡(luò)的前面一些層做參數(shù)共享，在后兩層，分別對于不同的學(xué)習(xí)目標，進行參數(shù)的微調(diào)。

這是一種遷移學(xué)習(xí)的思路，可以大大節(jié)省離線模型訓(xùn)練和線上多目標推斷時的計算量。

多目標排序目前在知乎的實際應(yīng)用中已經(jīng)有一些初步的結(jié)果，通過小流量對比發(fā)現(xiàn)，使用多目標模型來排序，除閱讀之外的行為量都能有?10% 左右的增長。

另外，知乎也在探索如何在排序?qū)W習(xí)中體現(xiàn)推薦列表的多樣性。

CTR 預(yù)估實際上是一種 pointwise 的排序方法，可能造成的后果是，如果用戶對很多內(nèi)容感興趣，在內(nèi)容質(zhì)量相當?shù)那闆r下，這種排序會將「最喜歡的一類內(nèi)容」全都排到最前面，造成用戶閱讀時的疲憊感和單調(diào)感。

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

2.2.5 人機結(jié)合

知乎CTO李大海毫不避諱地提到知乎目前的機器學(xué)習(xí)算法并不完美，尤其是在 NLP 領(lǐng)域，在語義理解方向上，AI 技術(shù)還有很大的提升空間。

為了讓用戶得到更好的體驗，知乎的?AI 應(yīng)用自始至終都伴隨著人的高度參與，人機結(jié)合是避免「算法偏見」出現(xiàn)的有效方法之一。

所以知乎在今年啟動了一項名為「泰戈爾」的計劃，從標簽定義、標簽生產(chǎn)、質(zhì)量審核、標簽應(yīng)用等方面，建立了一套對內(nèi)容進行識別和應(yīng)用的閉環(huán)，并明確了算法、運營、業(yè)務(wù)團隊在這個閉環(huán)中的角色。

這個計劃啟動以后，在機器識別方面，接入了領(lǐng)域識別、內(nèi)容質(zhì)量判定、內(nèi)容時效性識別等多個維度的識別算法，同時，知乎內(nèi)容運營的同事會在機器識別的基礎(chǔ)上，每天都會對健康、影視、法律等多個領(lǐng)域的，成千上萬篇內(nèi)容進行標注和算法結(jié)果的糾正。

2.3 首頁架構(gòu)改進

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

2.3.1 已讀服務(wù)的升級

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

在緩存失效的情況下對同一個熱鍵值的并發(fā)讀取不會產(chǎn)生驚群效應(yīng)。

利用寫通緩存的更新策略再加上變更下推來維護緩存的一致性，所以不需要對緩存數(shù)據(jù)設(shè)定過期時間。

知乎使用分層緩存來從空間維度和時間維度提高命中率。利用分層緩存還可以更有效的應(yīng)對跨數(shù)據(jù)中心部署時帶寬受限的問題。

最重要的是?Rbase 提供了 BigTable 一樣的數(shù)據(jù)模型，并且和 Hbase 的 API 在功能和用法上非常接近，方便遷移。

2.3.2 推薦架構(gòu)的改造

知乎早期廣泛采用?python 語言來進行開發(fā)，包括首頁推薦的業(yè)務(wù)框架也不例外。

在經(jīng)過長時間的功能疊加之后，老系統(tǒng)在響應(yīng)時間優(yōu)化以及可維護性等方面，已經(jīng)很難提出比較高的要求。所以知乎在 18 年使用 java 進行了系統(tǒng)的重寫，不僅大幅度優(yōu)化了響應(yīng)時間，節(jié)約了比較多的機器資源，還引入了多隊列召回的能力，允許從不同維度召回與用戶相關(guān)的內(nèi)容，進一步提高多樣性。

2.4 知乎搜索系統(tǒng)

搜索是知乎在壯大過程中逐步優(yōu)化的一個功能。知乎希望通過個性化推薦和搜索系統(tǒng)，盡可能縮短用戶和內(nèi)容之間的距離，讓用戶在知乎擺脫信息過載帶來的負擔(dān)和壓力。

2.4.1?搜索算法改進與應(yīng)用

以深度學(xué)習(xí)為代表的搜索相關(guān)性語義特征，知乎的搜索算法近幾年獲得了長足的發(fā)展：從最早的以?DSSM 為代表的 Query/Doc 分別提取深度表征的方法，到近期的以MatchPyramid, KNRM 等為代表的 Query/Doc 相互交叉為相關(guān)度圖再做計算的方法，再到這兩類方法相互融合的方法，以及最近的 BERT 模型。

知乎在實踐過程中發(fā)現(xiàn) MatchPyramid, KNRM 等第二類方法的效果，普遍優(yōu)于 DSSM 等第一類方法。深度語義特征上線之后，知乎在頭部、腰部、長尾的搜索點擊比普遍提升了約?2% – 3% 不等。

2.4.2?搜索架構(gòu)優(yōu)化

除了算法方面的改進，知乎也投入了不少人力在搜索的架構(gòu)優(yōu)化上。早年采用?ES 作為索引引擎，隨著數(shù)據(jù)量的增加，知乎遇到了 ES 集群的服務(wù)穩(wěn)定性問題，以及 ES 對排序算法支持不友好等問題。所以在 17 年，知乎自己開發(fā)了一套在索引格式上完全兼容 ES 的引擎系統(tǒng)，逐步替換了在線上服務(wù)的 ES 集群。

這個系統(tǒng)使用 Rust 開發(fā)，Rust 語言是一種類似于 C/C++ 的無 GC 語言，李大海曾提到雖然 Rust 語言的學(xué)習(xí)曲線非常陡峭，但是在團隊熟悉語言后，由于 Rust 能在編譯器層面避免內(nèi)存安全問題和并發(fā)安全問題，所以整體獲得的收益是非常顯著的。

目前知乎全部的搜索請求都由新的索引服務(wù)支撐，在可用性達到了?5 個 9 的同時性能上也不輸于 C++ 編寫的類似系統(tǒng)所能達到的水平。

三、用戶連接

知乎為了加強社區(qū)內(nèi)用戶與用戶的聯(lián)系，通過Graph Embedding 模型對用戶進行隱式表示的學(xué)習(xí)，計算出兩個用戶之間的親密度、興趣相似度，以此進行更精準的推薦，讓用戶更多地在社區(qū)里發(fā)生連接。

3.1 基于用戶行為的?Embeeding 表示

基于用戶行為的?Embeeding 表示，主要使用用戶搜索內(nèi)容、關(guān)注、收藏、點贊、閱讀的回答、文章等對應(yīng)的話題，作為用戶的特征，整理成 0-1 的向量。

使用變分自編碼器（Variational Auto-Encoder，VAE） ，使樣本對應(yīng)到正態(tài)分布，計算此正態(tài)分布和標準正態(tài)分布的 KL 散度距離作為額外的 loss，最終為得到用戶的 Embedding 表示。

3.2 基于用戶社交關(guān)系的?Embeeding 表示

基于用戶社交關(guān)系的?Embeeding 表示，主要使用 skip-gram 模型，得到用戶的特征表示，從用戶關(guān)注優(yōu)秀回答者的關(guān)注關(guān)系網(wǎng)絡(luò)中抽取數(shù)據(jù)集，采用 Randomwalk 方法抽樣有序的節(jié)點，從而將社交網(wǎng)絡(luò)轉(zhuǎn)化為有序節(jié)點進行學(xué)習(xí)。

Embedding 模型主要應(yīng)用在了知乎的以下場景：

1.?用戶聚類：使用用戶聚類來在推薦中做召回，使用用戶?Embedding 表示，經(jīng)過聚類計算后，得到用戶的人群，可以把這個群體的高互動內(nèi)容作為 feed 候選，放入到推薦系統(tǒng)當中。

2.?用戶親密度：使用用戶 Embedding 表示 + 用戶對用戶的互動行為特征，可以預(yù)測用戶的關(guān)注關(guān)系，得到用戶親密度值。這個值用在很多和社交相關(guān)的策略之中。

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

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

4.1 瓦力治杠精

瓦力：社區(qū)管理的「大腦」

所謂「杠精」是指抬杠成癮的一類群體。不管別人說的是什么，先反駁挑刺，為了反對而反對，通過反駁別人來凸顯自己的優(yōu)越感，再加上「只有我一個人覺得……」句式的加持，基本上能成功惹翻他人。

2018年12月3日，詞語「杠精」被《咬文嚼字》公布為2018十大流行語。而「杠精」在知乎具體體現(xiàn)為各種「陰陽怪氣」的言論，「瓦力」就專門針對這類杠精言論而生。

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

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

下圖比較完備地展示了知乎識別陰陽怪氣評論的技術(shù)方案。

知乎把評論和相應(yīng)回答的文本特征、標點符、表情符統(tǒng)計特征、是否命中反諷詞表等多維度?feature 作為模型的輸入，采用 CNN 和 LSTM 相結(jié)合的網(wǎng)絡(luò)拓樸結(jié)構(gòu)訓(xùn)練二分類模型。

在訓(xùn)練數(shù)據(jù)獲取方面，使用站內(nèi)有大量一致用戶行為的語料，來自動生成二元的標注；為了提高模型泛化能力，通過 active learning 方法選取站內(nèi)評論，經(jīng)過人工標注加入訓(xùn)練集。

2018年?6 月，「瓦力」的陰陽怪氣識別功能上線，在召回率 25% 的情況下，準確率達到了 95%。

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

1. 進行數(shù)據(jù)增強，以提升模型的泛化能力；

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

2. 提取相關(guān)數(shù)據(jù)特征，利用卷積網(wǎng)絡(luò)以及人工特征等來獲得更多更詳細的特征；

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

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

特征學(xué)習(xí)層方面，主要考慮了評論和上文的文本特征，包括字，詞，標點，表情符號等，并利用知乎全量數(shù)據(jù)訓(xùn)練?word2vec 模型。

知乎將評論上文與評論經(jīng)過 embedding 層后分成兩個金字塔型 CNN 網(wǎng)絡(luò)，目的是訓(xùn)練各自獨立的參數(shù)，知乎采取 CNN 網(wǎng)絡(luò)是因為 CNN 卷積可以捕獲字詞的位置關(guān)系也可以比較有效的提取特征。

除上述文本特征外，知乎也充分考慮了其它特征，比如評論長度，評論中句號，問號等標點的個數(shù)，評論中是否包含陰陽怪氣關(guān)鍵詞等；這些特征離散化后，與評論的卷積提取特征進行拼接，最后與評論上文的卷積輸出進行?dot-attention ，目的是獲取評論上文與評論不同的權(quán)重。

最后，知乎將特征數(shù)據(jù)全連接層以 softmax 方式進行了分類。

盡管瓦力在各個維度進行的社區(qū)治理準確度已超過?90%，但卻是無法取代人工的，知乎也沒有將內(nèi)容和社區(qū)管理的任務(wù)全部集于算法一身，而是采用算法 + 人工的方式。

對瓦力處理的內(nèi)容，知乎會每天進行質(zhì)檢，同時也有專門的團隊對于用戶申訴進行復(fù)核和響應(yīng)。

4.2 悟空反作弊

Wukong 是知乎的反作弊系統(tǒng)，主要負責(zé) SPAM 的召回和處理。

從 2015 年 4 月上線，隨著知乎的不斷發(fā)展壯大，悟空也進行著持續(xù)地優(yōu)化升級。接下來分享下知乎「悟空」的架構(gòu)演進和構(gòu)建過程中積累的經(jīng)驗與教訓(xùn)。

4.2.1 知乎典型?Spam

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

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

• 導(dǎo)流內(nèi)容：這類?Spam 大概能占到社區(qū)中 Spam 的 70% – 80%，比較典型的包括培訓(xùn)機構(gòu), 美容，保險，代購相關(guān)的 Spam。導(dǎo)流內(nèi)容會涉及到 QQ，手機號，微信，url 甚至座機，在一些特殊時間節(jié)點還會出現(xiàn)各類的專項 Spam，比如說世界杯，雙十一，雙十二，都是黑產(chǎn)大賺一筆的好時機。
• 品牌內(nèi)容：這類內(nèi)容會具有比較典型的?SEO 特色，一般內(nèi)容中不會有明顯的導(dǎo)流標識，作弊形式以一問一答的方式出現(xiàn)，比如提問中問什么牌子怎么樣？哪里的培訓(xùn)學(xué)校怎么樣？然后在對應(yīng)的回答里面進行推薦。
• 詐騙內(nèi)容：一般以冒充名人，機構(gòu)的方式出現(xiàn)，比如單車退款類?Spam，在內(nèi)容中提供虛假的客服電話進行詐騙。
• 騷擾內(nèi)容：比如一些誘導(dǎo)類，調(diào)查類的批量內(nèi)容，非常嚴重影響知友體驗。

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

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

4.2.2 三種控制方式

• 策略反作弊：在反作弊的初期，Spam 特征比較簡單的時候，策略是簡單粗暴又有用的方式，能夠快速的解決問題，所以策略在反作弊解決方案里是一個解決頭部問題的利器。
• 產(chǎn)品反作弊：一方面通過改變產(chǎn)品形態(tài)來有效控制風(fēng)險的發(fā)生，另一方面通過產(chǎn)品方案，對用戶和?Spammer 痛點趨于一致的需求進行疏導(dǎo)，有時候面對 Spam 問題，對于誤傷和準確會遇到一個瓶頸，發(fā)現(xiàn)很難去區(qū)分正常用戶和 Spammer，這種情況下反而通過產(chǎn)品方案，可能會有比較好的解決方案。
• 模型反作弊：機器學(xué)習(xí)模型可以充分提高反作弊系統(tǒng)的泛化能力，降低策略定制的成本。模型應(yīng)用需要酌情考慮加入人工審核來保證效果，直接處理內(nèi)容或用戶的模型算法，要注意模型的可解釋性。初期一些無監(jiān)督的聚類算法能夠在比較短時間內(nèi)達到較好的效果。而有監(jiān)督的分類算法，在時間上和人力上的耗費會更多，樣本的完整程度，特征工程做的好壞，都會影響算法的效果。

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

• 事前：事前涉及到的幾個環(huán)節(jié)包括風(fēng)險教育、業(yè)務(wù)決策參與、監(jiān)控報警以及同步攔截。反作弊需要提升業(yè)務(wù)的風(fēng)險意識，明確告知反作弊可以提供的服務(wù)；并在早期參與到業(yè)務(wù)決策，避免產(chǎn)品方案上出現(xiàn)比較大的風(fēng)險；業(yè)務(wù)接入后，針對業(yè)務(wù)新增量、處理量、舉報量，誤傷量進行監(jiān)控，便于及時發(fā)現(xiàn)風(fēng)險；在策略層面，在事前需要針對頭部明顯的作弊行為進行頻率和資源黑名單的攔截，減輕事中檢測的壓力。
• 事中：面向長尾曲線的中部，主要針對那些頻率較低，且規(guī)律沒有那么明顯的作弊行為，針對不同嫌疑程度的行為與帳號，進行不同層級的處理，要么送審，要么限制行為，要么對內(nèi)容和帳號進行處罰。
• 事后：面向長尾曲線最尾部的行為，即那些非常低頻，或者影響沒那么大，但是計算量相對大的作弊行為。由一些離線的算法模型和策略負責(zé)檢測與控制，另外事后部分還涉及到策略的效果跟蹤和規(guī)則的優(yōu)化，結(jié)合用戶反饋與舉報，形成一個檢測閉環(huán)。

4.2.4 知乎「悟空」的架構(gòu)演進

悟空 V1

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

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

事中模塊在業(yè)務(wù)旁路進行檢測，適合做一些相對復(fù)雜，耗時長的檢測。事中主要由 Parser 和一系列 Checker 構(gòu)成，Parser 負責(zé)將業(yè)務(wù)數(shù)據(jù)解析成固定格式落地到基礎(chǔ)事件庫，Checker 負責(zé)從基礎(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)了不少的痛點：

1. 策略學(xué)習(xí)曲線陡峭, 書寫成本高：上面提到的策略采用嵌套結(jié)構(gòu)，一方面對于產(chǎn)品運營來說學(xué)習(xí)成本有點高，另一方面書寫過程中也非常容易出現(xiàn)括號缺失的錯誤。
2. 策略制定周期長：在「悟空 V1」上線一條策略的流程大概會經(jīng)過這幾步, 產(chǎn)品制定策略 – 研發(fā)實現(xiàn)策略 – 研發(fā)上線策略召回 – 產(chǎn)品等待召回 – 產(chǎn)品確認策略效果 – 上線處理。整個環(huán)節(jié)涉及人力與環(huán)境復(fù)雜，策略驗證麻煩，耗時長，因此策略試錯的成本也會很高。

鑒于此，「悟空 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)可復(fù)用的算子即可滿足日常策略需求，不管是機器學(xué)習(xí)模型還是業(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)將策略運行依賴的資源復(fù)制了一份，與生產(chǎn)環(huán)境隔離，實現(xiàn)一個 coordinator 將歷史的事件從 MongoDB 讀出并打入隊列。

值得注意的是，入隊速度需要控制，避免隊列被瞬間打爆。

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

悟空 V3

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

Gateway

Gateway 負責(zé)與 Nginx 交互，作為通用組件對在線流量進行風(fēng)險的阻斷。

目前 Gateway 承擔(dān)了所有反作弊和帳號安全用戶異常狀態(tài)攔截、反作弊功能攔截和反爬蟲攔截。

這樣一來，這部分邏輯就從業(yè)務(wù)剝離了出來，尤其是在業(yè)務(wù)獨立拆分的情況下，可以大大減少業(yè)務(wù)的重復(fù)工作。作為通用組件，也可以提升攔截邏輯的穩(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)的第三級隊列。第三級隊列即處理隊列，負責(zé)對命中規(guī)則的內(nèi)容或者用戶進行處理。

緩存優(yōu)化

因為每個策略檢測都會涉及到歷史數(shù)據(jù)的回溯，自然會帶來較多的重復(fù)查詢，存儲的壓力也會比較大，所以存儲上又增加了多級存儲，除了 MongoDB，在上層對于近期的業(yè)務(wù)數(shù)據(jù)，存儲在 Redis 和 localcache。

圖片識別能力增強

隨著文本內(nèi)容檢測能力的增強，不少 spam 開始使用圖片的方式進行作弊。

在「悟空 V3」增強了圖片相關(guān)的檢測能力：圖片 OCR，廣告圖片識別，色情圖片識別，違法違規(guī)圖片識別，政治敏感圖片識別。

針對圖片類的廣告 Spam 的檢測一直是空缺，需要投入大量的人力進行模型訓(xùn)練，所以這一塊知乎借助第三方快速提升這一塊的空缺。接入之后，著實提升了解決站內(nèi)廣告和詐騙圖片 Spam 的能力。

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

早期由于系統(tǒng)還未成熟，知乎很多的工作時間都花在 Spam 問題的應(yīng)急響應(yīng)上，很少去做各維度的風(fēng)險數(shù)據(jù)累積。

在「悟空 V3」知乎分別在內(nèi)容、帳號、IP、設(shè)備維度開始累積相關(guān)的風(fēng)險數(shù)據(jù)，供策略回溯和模型訓(xùn)練使用。

目前知乎有三個數(shù)據(jù)來源：策略、第三方接口和人工標注。

鑒于離線人工標注效率低，并且抽取數(shù)據(jù)項繁雜的問題，知乎專門搭建了一個標注后臺，提升運營標注數(shù)據(jù)的效率，使標注數(shù)據(jù)可復(fù)用，可追溯。

以下是一些知乎比較常用的風(fēng)險維度：

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

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

3. IP 維度: e.g. 風(fēng)險 IP ，代理 IP

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

回溯能力增強

在「悟空 V3」，知乎還增強了策略的回溯能力。

一方面，搭建失信庫覆蓋新增內(nèi)容中與失信內(nèi)容相似的 Spam 內(nèi)容，相似度的算法目前知乎使用的是 consine-similarity 和 jaccard；

另一方面，基于 Redis，知乎支持了基于導(dǎo)流詞、標簽、社區(qū)的快速回溯。這樣的話相關(guān)的行為更容易被聚集到一起，使得知乎可以突破時間的限制，對相似的 Spam 一網(wǎng)打盡。

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

結(jié)網(wǎng) – ZNAP (Zhihu Network Analysis Platform)

過去做反作弊的很長一段時間，知乎花了很多功夫在行為和內(nèi)容層面去解決 Spam 問題。但換個角度知乎發(fā)現(xiàn)，黑產(chǎn)團伙固然手上的資源巨多，但是也得考慮投入產(chǎn)出比，不管怎么樣，資源都會存在被重復(fù)使用的情況，那用什么方式去表示這種資源的使用情況呢？

知乎想到了圖，也成為了知乎做「結(jié)網(wǎng)」這個項目的出發(fā)點。這個項目分成了幾個階段：

第一階段，實現(xiàn)基于圖的分析能力：

這個階段旨在提供一種通過網(wǎng)絡(luò)圖譜分析問題的渠道，提升運營和產(chǎn)品的效率，快速進行社區(qū)（設(shè)備，IP……）識別，團伙行為識別以及傳播分析。

圖譜分析平臺的數(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)的特征進行訓(xù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)打盡。

未登錄熱詞發(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), 于是知乎從詞匯的左右信息熵和互信息入手，去挖掘未登錄詞, 并取得了比較好的效果。

導(dǎo)流詞識別

針對站內(nèi)的導(dǎo)流內(nèi)容，最開始在識別導(dǎo)流信息上采用的是干擾轉(zhuǎn)換+正則匹配+匹配項回溯的方式進行異常導(dǎo)流信息的識別與控制，取得了很好的效果。

此外，隨著整治加強，知乎發(fā)現(xiàn)站內(nèi)導(dǎo)流變體的現(xiàn)象也在愈演愈烈，對此，也成功引入模型進行整治，通過 BILSTM-CRF 來識別導(dǎo)流變體，目前在提問和回答的識別準確率分別達到 97.1%、96.3%。

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

對于垃圾內(nèi)容的治理，雖然線上一直有策略在覆蓋，但是策略的泛化能力有限，始終會有新型的 Spam 繞過策略。知乎嘗試使用深度學(xué)習(xí)構(gòu)建通用垃圾文本分類模型。

模型使用字向量作為輸入，多層 Dilated Convolution 提取文本特征，通過 Attention 對卷積后的表達重新加權(quán)得到高層特征，最后得到垃圾內(nèi)容的概率。

針對近期知乎遇到的批量 Spam 內(nèi)容單條規(guī)則召回率可以達到 98% 以上，準確率達到95.6%。

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

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

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

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

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

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

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

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

基于知乎四大場景的AI技術(shù)與應(yīng)用就整理到這里，為了方便大家回顧，數(shù)智君對于文中所提到的部分技術(shù)、模型和算法做了簡要腦圖整理：

從這篇能大致看出知乎做起AI來也真的是很「知乎」，一步步改進，一步步優(yōu)化，并且基于場景和業(yè)務(wù)本身也做了許多符合自身情況的嘗試。

既然「穩(wěn)定而高質(zhì)量的知識內(nèi)容」被譽為知乎的護城河，不知道知乎的AI能否持續(xù)加固這個護城河？

歡迎在評論區(qū)發(fā)表你的看法，如果這篇方法論讓你有所收獲，對我的文章感興趣點擊收藏、訂閱~

參考文獻

（1）知乎技術(shù)專欄；

（2）知乎產(chǎn)品專欄；

（3）邱陸陸，《知乎：源自社區(qū)又服務(wù)于社區(qū)的?AI 技術(shù)》，機器之心公眾號，2018年06月13日；

（4）極客邦科技?InfoQ，《知乎?CTO 李大海：知識內(nèi)容平臺 AI 技術(shù)應(yīng)用思考》，2019 年 1 月 16 日；

（5）阿司匹林，《呵呵，你開心就好！——AI向杠精宣戰(zhàn)》，AI科技大本營公眾號，2018年07月02日；

（6）王藝瑾，《融資2.7億美元，知乎仍面臨護城河焦慮》，36氪,?2018-08-11；

編譯：卷毛雅各布

公眾號：數(shù)智物語（公眾號ID：decision_engine）出品策劃

本文由 @數(shù)智物語?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議