謝邀！知乎 CTO 來分享下内容社區的 AI 架構搭建與應用。

　　「在信息爆炸的互聯網海洋中，有價值的信息仍然是稀缺的」。知乎的誕生源于這樣一個非常簡單的初心。

　　而在挖掘真正有價值的信息過程中，知乎很好地利用了 AI 技術。

　　在今年上海召開的 2020 世界人工智能大會雲端峰會開發者日「企業及 AI 架構專場」分論壇上，知乎合夥人、首席技術官李大海老師為分享了知乎作為一個内容社區，在 AI 架構上的搭建和應用。

　　李大海老師擁有多年的搜索算法經驗，曾擔任 Google 中國軟件工程師，雲雲網工程總監，并曾擔任豌豆莢搜索技術負責人，讓豌豆莢成為最早涉足應用内搜索和 Deep Link 的公司。

　　2015 年李大海以合夥人身份加入知乎，先後負責知乎廣告技術團隊、數據、算法業務。在出任 CTO 之後，李大海統籌負責包括大數據團隊、内容流通、AI 新業務拓展等在内的知乎整體技術業務。

　　以下為演講主要内容，機器之心進行了不改變原意的整理：

　　大家好，我是李大海。很榮幸代表知乎來世界人工智能大會開發者日做分享。特殊時期，以這種特殊的方式跟大家作交流，心情是很複雜的。2020 年上半年是非常不容易的半年，不過我們也很高興地看到，很多企業通過技術創新應對疫情，幫助大家維持正常的工作和生活。知乎也是其中的一員。

　　從 2016 年引入機器學習以來，AI 技術已經在知乎社區很多環節紮下根。以前我們講算法講得比較多，今天我想重點說一下我們在 AI 架構的搭建和應用上的經驗。

　　在知乎，我們的 AI 架構的不同是由不同的 AI 場景和實踐催生的。當然，介紹這些應用場景之前，我們應該先簡單了解一下知乎。知乎是一個内容社區，包括問答、熱榜、知識服務、圈子、直播等等各種産品功能和業務闆塊，沉澱了數億的問題、回答、專欄、電子書等等内容，這些内容每天都在被生産、分享、消費。對于一個平台來說，是一個浩大的工程。為了讓内容在社區運轉得更高效，知乎引入了 AI 技術。

　　到目前為止，知乎的 AI 應用已經觸及到業務的方方面面，并且在實踐的過程中，逐步形成幾個不同的算法框架。

　　基礎 AI 架構

　　首先是基礎 AI 架構。2017 年，知乎成立專門的 AI 團隊，為各個業務提供一個基礎算法能力輸出。這個團隊基于知乎海量的内容及用戶行為數據，通過數據挖掘、機器學習、自然語言處理等技術，精準、全面地理解内容及用戶，并将基礎算法能力以标準統一的形式輸出，為公司各業務賦能。

　　AI 團隊自成立以來，為各種不同的業務提供了非常多的應用。随着時間的推移，也産生了一些痛點。比如說，由于沒有統一的系統開發框架，各個業務模塊和子項目都是單點作戰，隻有一個同事清楚業務細節，并且新建一個項目要寫很多和業務無關腳手架類型的代碼。再比如，有的線上代碼沒經過代碼審核、存在非主幹分支發布、個人倉庫開發等問題，非常不利于協同和維護。另外，服務和模塊的複用性比較低，有些常用的邏輯，比如識别打壓大話題，被多人、多項目分别實現。另外，像監控不完善，部分問題發現不及時等等，都是小應用太多帶來的問題。

　　因此，急需統一的系統架構來整合所有資源，搭建穩定的基礎架構，加速 AI 技術積累并助力業務創新。

　　我們首先考慮設計統一的基礎服務架構，統一定義基礎 AI 算法的工作流和數據流。有了這個統一框架之後，很方便在框架上添加監控、報警等等功能，及時發現可能出現的問題，提高服務質量、穩定性和可用率。

　　在設計良好的架構和統一代碼管理的模式下，方便我們去構建這個場景下的通用代碼庫，提高基礎功能的代碼複用率，并解決項目和代碼的散亂問題。

　　在統一的基礎服務架構上，團隊成員的開發工作模式一緻，并且溝通語言都是基于此，一定程度上會提升協作效率和溝通效率。

　　同時，開發人員更容易理解非自己主導項目的脈絡主線，可以極大地降低工作内容調整和交接的複雜度。從另一個角度提升了協作、溝通效率。

　　在統一的基礎服務架構下，團隊不再需要關心一些通用的細節，隻是按需調用 / 複用通用組件，将主要的精力用在解決問題的核心算法 / 模型上，這樣一來，加速了團隊的技術積累，快速地推進業務的創新。

　　這張圖可以簡單的展示知乎基礎 AI 架構的體系。

　　我們的統一框架取名叫 zai，本質上是一個工作流水線。其中的每個部件都是可定制的。workflow 分為三大類：

　　base workflow，通常隻包含一種推斷服務或預測服務。

　　series workflow ，其可以串聯多個不同的 base workflow，形成一個更複雜的服務鍊，比如關鍵詞服務，需要前序依賴分詞服務。

　　parallel workflow ，其可以并聯多種 series workflow，形成相對比較複雜的網絡，比如監聽内容創建 kafka topic，并分别進行多種預測處理。

　　在這個框架中，我們選擇 proto buffer 來進行數據 schema 的定義，滿足速率快和存儲小的需求。

　　zai-serving 是預測 / 推薦模塊，加載 zai-model 模塊訓練出來的模型來進行推斷服務。模型可以支持傳統模型和 NN 模型。其中 NN 模型基于 tensorflow estimator 做了改造和封裝，這樣具備以下優點：

　　數據管道和模型分離。

　　保留足夠的模型靈活度，具有模型自定義的自由和模型相關超參調整的自由。

　　封裝了訓練、預測、評估、模型輸出；隻需要關心模型本身。

　　基礎 AI 架構的主要應用場景，一般是各種離線的數據處理場景。在典型的線上推薦場景中，我們也正在形成統一推薦框架。

　　統一推薦 AI 架構

　　當越來越多的業務都需要用到推薦服務時，我們開始了統一推薦框架的工作：我們期望通過統一 Ranking 框架，将推薦系統全局排序階段的技術統一，降低開發和維護成本，提高效率。

　　知乎的統一推薦框架包括以下模塊：

　　統一的完備的數據 schema，打通各業務線的數據，減少重複特征數據的落地成本，并成為統一推薦框架的标準輸入。

　　統一的特征落盤服務，各業務線可根據業務特點，靈活填充 schema 中的特征字段，減少在特征落盤和訓練數據管理部分的開發工作。特定業務還可以低成本的實現跨部門數據複用，打通不同部門之間的數據協同作用。

　　統一的訓練數據流水線。

　　統一的特征工程框架。

　　統一的訓練代碼庫。有利于模型結構複用，兼容離線訓練和 online learning 訓練。

　　統一的線上預測服務。支持 tensorflow 和 xgboost 的模型；支持模型的自動加載和更新；提供通用的特征、預測分數監控。支持 CPU 或 GPU 部署。優化公共特征計算。

　　我重點講一下其中的幾個模塊。

　　第一個是特征引擎。

　　特征數據處理，是要把結構化的特征數據（如用戶畫像，内容畫像等）轉換成向量化的訓練數據。我們的特征引擎具備以下功能：

　　特征工程配置化：管理使用哪些特征；增删特征無需改代碼。避免了離線數據處理和線上預測服務代碼不一緻的情況。

　　特征工程模塊化：我們把對特征數據的操作抽象成一個個操作子 (operator)。比如：Echo, OneHot 等。規範了 operator 的輸入輸出；每個 operator 可以處理不同的特征數據；大部分 operator 和具體的業務無關，代碼可複用性大大增強。每個 operator 必須有嚴格的單元測試，保證了特征工程代碼質量。

　　結構化數據字段獲取動态加速，有效的提升效率。

　　自定義向量化特征數據格式：避免了 parse protobuf 的序列化、反序列化 cpu 開銷，比 tensorflow 的 tf record 快很多，典型場景有 10 倍的性能差異。

　　第二個是特征落盤服務。

　　為了對特征覆蓋率等指标進行監控，并讓落地的數據在多個業務之間低成本複用，特征在落地之前需要經過統一落盤處理。落盤服務提供的主要功能有：

　　流式特征覆蓋率統計監控，特征分布統計。

　　樣本數據分流。大的樣本數據盡量落成一份，小的特殊業務可以進行靈活的分流。

　　跨業務的進行特征補全。

　　未來，知乎的統一推薦框架将在三個方面進行完善和升級：

　　一站式配置管理、數據流管理、特征監控、指标監控。

　　通用化 online learing，讓更多業務可以直接用在線學習的優勢。

　　AutoML，降低業務使用機器學習模型的門檻。

　　社區治理、反作弊、首頁推薦算法 AI 架構

　　除了統一推薦，知乎還有一個很特殊的場景，就是社區治理。除了垃圾信息、有害信息的處理，一些對社區内容建設和人們的需求沒幫助的信息，也在知乎的治理範圍内，比如答非所問、陰陽怪氣等等。這個場景沉澱出來的基礎框架，和前面提到的 zai 框架是比較相似的，但是整個框架針對圖片、視頻等多媒體内容，做了很多特化的優化處理，比如通用的緩存轉碼之類的。具體細節在這裡就不贅述了。

　　機器學習架構—Jeeves 機器學習平台

　　除了直接面向業務應用場景的三個框架之外，我們還構建了機器學習平台 Jeeves，用于幫助算法工程師快速構建、訓練和部署機器學習任務。Jeeves 将算法工程師從繁重的部署和配置工作中解放出來，專注于高質量模型的開發。

　　随着機器學習對 GPU 資源的需求快速增加，僅通過算法工程師自行管理、調度，不僅增加了業務部門管理成本，也造成了 GPU 等計算資源一定程度的浪費。具體包括以下幾點：

　　訓練前部署難。算法工程師需投入大量精力進行運行環境的配置和資源調配，不便于工程師專注于模型優化和調參。

　　資源配置優化難。算法工程 shi 難以判斷機器學習任務的性能瓶頸在哪快（如 CPU、GPU、内存等），不便于全局優化資源調配。

　　單機訓練瓶頸。縱向擴展成本高、提升小。機器學習需要快速叠代試錯，性能瓶頸制約了其最終産出的質量和速度。

　　Jeeves 将 Tensorflow 容器化，通過容器進行訓練資源的調度和管理，并為算法工程師提供方便的資源申請和釋放流程。具體來說，Jeeves 提供：

　　一鍵部署能力。算法工程師隻需要申請資源、載入訓練數據和代碼，即可一鍵部署環境并開展工作。

　　資源消耗監控。監控資源在每個任務的消耗情況，便于識别瓶頸所在，針對性的進行性能優化和資源調配。

　　算力水平擴展。支持分布式機器學習，支持算力的快速擴展。

　　下圖是 Jeeves 及其學習平台架構。Jeeves 通過容器管理 GPU 集群的資源，底層使用 Docker 來隔離 GPU 資源，并通過 Kubernetes 對 Docker 容器進行調度。并提供訓練數據挂載，日志和模型的持久化的功能。同時 Jeeves 還會監測空閑資源并保證其及時回收，提高資源利用效率。

　　功能層面，Jeeves 主要提供兩類功能：一種是「筆記本」，用于在線交互式試驗訓練代碼；另一種是「項目」，用于創建單機或分布式訓練。

　　筆記本為算法工程師提供交互式體驗和數據科學可視化的工具，用戶可以通過浏覽器快速叠代優化訓練代碼。對于不習慣使用浏覽器或者不方便使用浏覽器的用戶，Jeeves 還提供了 ssh notebook 的功能。

　　項目分為單機訓練和分布式訓練兩類。單機訓練使用一立服務器執行訓練任務；而分布式訓練根據用戶申請的資源用量，将任務合理拆分後，交由對應集群執行。項目啟動後，Jeeves 會提供 TensorBoard，輔助用戶掌握訓練過程。

　　總結

　　以上是知乎最近在 AI 應用實踐中逐步沉澱出來的一些基礎框架和提效平台。AI 應用本質上是能夠對海量數據進行高效應用的前沿計算機算法系統，因此，過去常規計算機系統在數據規模和業務請求量增大到一定程度後，會遇到的各種問題，AI 應用也同樣會遇到。如果解決這些問題，就需要有良好的架構設計，否則再好的數據和模型，也都會受制于系統的計算能力和吞吐能力，不能發揮數據和模型完整的表達能力。所以，在工業界真實的生産環境中，AI 應用必須同時兼顧數據、算法和架構三者的投入。作個不太适當的比喻，這三者的關系就好像食材、菜譜和廚具，要想把 AI 應用的用戶體驗這道菜做的色香味俱全，三樣東西每樣都要做好、做足、做精。

　　通過這些框架的落地和應用，我們也希望知乎這個内容社區，能夠在更多的産品細節上，輕松使用各種 AI 技術，成為一個人與技術、人與機器、人文與技術有效融合「智能社區」。

　　最後，打個廣告，歡迎更多對 AI 技術有興趣和熱情的同學加入我們，加入知乎，一起做些更有趣、更有挑戰性的工作。我的分享就到這裡，謝謝大家。

　　,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!