本文是本系列文章的第二部分，將介紹我們的 NLP 即服務系統(tǒng) HAL 的架構(gòu)。要想大概了解我們構(gòu)建該系統(tǒng)的動機和應用示例，請閱讀第一部分。

系統(tǒng)架構(gòu)

第一部分已經(jīng)討論過，HAL 用于為 Condé Nast 各個品牌的用例和應用程序賦能，從推薦系統(tǒng)與參與度到受眾定位、數(shù)據(jù)產(chǎn)品和編輯類產(chǎn)品。

為了處理這些不同的用例，我們需要一個能夠組合分析并引入新的分析器的系統(tǒng)。該系統(tǒng)應該能夠?qū)⒎治銎髟诓煌挠美兄赜?，還要提供靈活、抽象的輸出和處理流。為了實現(xiàn)這種靈活性以及分析重用，我們不僅將 HAL 設計成了一個內(nèi)容分析處理框架，還將其設計成了一套使用預訓練或自定義訓練模型的 in-JVM 和 out-of-JVM 分析器。

HAL 處理流程高級視圖

HAL 的接口是一個簡單的 HTTP 服務——希望提取特性的消費者通過路由將負載直接 POST 到一個指定的 Processor 。該 Processor 對象會直接映射到相關路由。Processor 定義了一個 ProcessorEngine 實例，通過類構(gòu)建器的連貫接口（fluent interface）。

下面是 Processor 其中一個實現(xiàn)的示例——該實現(xiàn)用于處理來自 Copilot（Condé Nast 專有 CMS）的內(nèi)容。

CopilotProcessor 類

ProcessorEngine 實例搭配使用三個實現(xiàn)了以下接口的對象：

內(nèi)容讀取器：負責將輸入請求的格式轉(zhuǎn)換成標準化的 ContentAnalysis 對象，該對象即所有分析器將要標注的文檔對象。不同的實現(xiàn)允許讀取不同種類的輸入，例如普通文本、Copilot 內(nèi)容 JSON 或 URL。該接口實現(xiàn)了抽象化的目標，將不同的輸入映射到了標準化的 ContentAnalysis 對象，其中包含供所有分析器使用的映射地圖。分析管道：負責定義有向無環(huán)圖處理流，編排多個分析器。針對不同的用途和用例，我們有不同類型的管道。所有管道的輸出都是一個 AnalyzedContent 對象，該對象是不同用例的標準化輸出對象，類似 ContentAnalysis 表示標準化輸入。分析管道接口實現(xiàn)了抽象化不同處理流的目標，重用分析器，為不同用例提供一個標準化的知識表示對象，即 AnalyzedContent。分析結(jié)果消費者：將 AnalyzedContent 轉(zhuǎn)換成響應格式。該接口實現(xiàn)了為不同用例提供不同輸出格式的抽象化目標。對于絕大多數(shù)用例，我們使用 AnalyzedContent 的一種默認的 JSON 語義表示，它在各種媒體類型間都保持一致。下文提取出的特征一節(jié)里提供了 JSON 表示的示例。標注和分析器

上文已經(jīng)提到，分析管道基于 Java 8 CompletableFuture實現(xiàn)了一個簡單的 in-JVM、可并行的有向無環(huán)圖流。節(jié)點會交換代表已標注文檔的 ContentAnalysis 對象。每個標準器都可以消費 ContentAnalysis，以及向 ContentAnalysis 貢獻標注?；跇俗⒌哪Ｐ驮贕ATE、Apache UIMA、Stanford CoreNLP等自然語言處理庫和框架中非常常見。

標注模型示例

內(nèi)容讀取器將輸入轉(zhuǎn)換成 ContentAnalysis 對象，不同格式和模式的輸入數(shù)據(jù)（JSON、HTML、普通文本等）都采用同樣的方式標注。

接下來，每個分析器都可以消費和生成標注。在上面這個簡單的例子里，文本中不同類型的命名實體都使用文本偏移量標注了出來。最后生成的 AnalyzedContent 輸出，將不同的提及（mention）聚合成了文檔中提取出的推斷知識。

每條標注是對文檔的一個說明，如：

文檔 XYZ 中從 0 到 15 的文本表示組織

標注也可以是文檔層面的，比如在主題提取時：

文檔 XYZ 的主題是商業(yè)

每個分析器都可以消費前述標注，作為其模型的輸入。該模型可以創(chuàng)建其他標注，并把他們添加到 ContentAnalysis 對象。

然后下游分析器就可以消費那些新生成的標注作為輸入，以此類推。

語言知識金字塔

這個過程類似于語言知識金字塔，層次較低的抽象構(gòu)成了層次較高的抽象的輸入知識（標注）。

語言知識模型金字塔

從下往上，每一層都有從具體媒體和語言中提取出來的更高層次的抽象。例如，在 Morphological 層，我們關心的是組成句子的詞以及詞與詞之間的關系。這一層與媒體（語音 vs. 文本 vs.圖像）和語言（基于字母的語言 vs. 基于象形表意文字的語言）非常接近。舉例來說，這一層的分析器有 Tokenizer、Language Identifier、Lemmatizer等。

在 Syntax 層，我們更多關注的是一個句子中詞之間的關系，即句子是什么結(jié)構(gòu)的，每個詞在其中承擔了什么角色。通常，這一層的分析器需要前一層提供的信息，尤其是分詞。舉例來說，這一層的分析器有 Part of Speech Tagger（確定一個詞是名詞、動詞還是限定詞，諸如此類） 、Dependency Parser （定義一個句子中詞的角色以及詞之間的關系，例如，一個詞是 Subject 還是 Object，和哪個動詞相關聯(lián)）等。

一旦系統(tǒng)推斷出了句法結(jié)構(gòu)，它就可以脫離具體的媒體和語言，開始在語義層面理解句子的“意思”了。前文圖中關于不同類型實體的標注（任務、地點、組織等）就是Named Entity分析器的輸出示例。通常，這些模型會將前一層中 Part Of Speech Tagger 及其他分析器的輸出作為輸入。

最后是 Pragmatic 層，這一層試圖從整體上理解文本。舉例來說，這一層的分析器有Topic建模、Coreference/Anaphora解析、Summarization等。

合而為一

在 HAL 中，分析器之間的標注流是由一個 DAG 流管理的。下面的代碼片段是為 DefaultNlpPipeline（適用于我們大部分自然語言處理用例）定義的 DAG 流：

DefaultNlpPipeline 類

下圖是上述 DefaultNlpPipeline 代碼的 DAG 流表示，以及分析器之間的相關標注：

帶標注的默認 NLP 管道 DAG 流

圖的頂點代表分析器實現(xiàn)，例如 Language Identifier 或 Copilot Entity Linker。邊代表 ContentAnalysis 對象狀態(tài)及其標注在分析器之間傳遞。正如之前說過的那樣，每個分析器都可以消費來自上游分析器的標注，并生成新的標注供下游使用。上圖是管道中一個經(jīng)過簡化的邊與標注的示例（實際會更多）。

這些分析器有些是在 JVM 中運行，有些是在 JVM 外運行，有些是定制的，有些是使用開源組件或由供應商實現(xiàn)的。不同的流并行運行，然后合并。

規(guī)范化標注模型是所有分析器之間的通用語。通過這種方式，我們可以利用不同來源的分析器來增加和豐富分析內(nèi)容。

HAL 生態(tài)系統(tǒng)

在 HAL 項目開始的時候，其中許多分析器在云服務中并不存在，但 2018 年，我們看到“商品化”自然語言處理服務的爆炸式增長。在確定供應商的服務可以提供更好的質(zhì)量、更多的特征或更低的成本時，HAL 利用了其中一些現(xiàn)成的分析器。不過，對于某些特征，如果云 API 比較貴或質(zhì)量不高，抑或是沒有這樣的云服務，我們?nèi)匀粫褂米远x模型或開源模型。

提取出的特征

HAL 以不同的方式返回內(nèi)容分析的輸出，通過不同的 AnalyzedContent 消費者實現(xiàn)來支持不同的場景。不過，默認響應（大多數(shù)用例都使用這種）是一個包含以下數(shù)據(jù)的 JSON 文檔——注意，以下是英語中可用的特征，其他語言的話，特征可能會少一些：

折疊后的 HAL 輸出

language：由標注器 Language Identifier 提取，這是一個 in-JVM 開源模型；keywords：一個按顯著性排名的名詞短語列表，由 in-JVM 模型Keywords Extractor 的自定義構(gòu)建所提取；

提取出的關鍵詞

entities：是一個命名實體列表，如人物、地點或組織，對于英語和德語，我們使用了一個開源的 in-JVM 分析器，對于其他語言，則使用供應商的服務；

提取出的實體

linkedData：提取出的實體和短語最終通過兩個不同的實體鏈接器鏈接到兩個特定的知識庫，鏈接數(shù)據(jù)使用了schema.org JSON-LD格式：Copilot-Linker：自定義的 out-of-JVM 分析器，可以鏈接到我們內(nèi)部的 CMS 系統(tǒng) Copilot，這也是一個由我們的編輯錄入的知識庫。Copilot 不僅可以對文章、相冊或典型的內(nèi)容類型進行建模，還可以對人物、餐廳、主題以及其他許多基于實體的內(nèi)容類型及其關系進行建模。Copilot-linker 可以用于本系列文章第一部分的“自動鏈接”用例。Wiki-linker：開源 out-of-JVM 分析器，可以鏈接到維基百科的文章。如下所示，Person 實體類型使用 JSON-LD schema.org 語義模式既鏈接到了維基百科，也鏈接到了 Copilot 知識庫：

關聯(lián)實體

topicsPrediction 和 categoriesPrediction：這是一個 out-of-JVM 分析器，使用我們內(nèi)部的 Prediction API（使用我們自定義構(gòu)建的 LDA Topic Models）來預測文章主題。主題廣泛應用于下游數(shù)據(jù)產(chǎn)品、回流產(chǎn)品、報表以及一些試驗性搜索流量預測模型。

LDA 主題

embeddings：內(nèi)容的數(shù)值向量表示，用于計算內(nèi)容相似度，從而實現(xiàn)推薦或受眾定位的目的。我們有一個自定義的 out-of-JVM 分析器和模型負責計算向量并生成特征。它使用doc2vec算法來生成向量，該算法是由DeepLearning4j 庫提供的。

文本嵌入

textMetrics： 關于文本的句法和語法指標，由自定義的 in-JVM 分析器計算生成。

文本指標

在構(gòu)建這個 HAL 默認的 JSON 響應時，我們試圖建立一個多模態(tài)知識表示模型，從而達到將內(nèi)容分析輸出模型用于不同用例、內(nèi)容類型和分析類型的目的。

多模態(tài)實體提取

讓我們用一個例子來說明下多模態(tài)分析表示。有一個實體 Jack McBrayer，我們通過 speech-to-text 組件從音頻片段中識別到了，從文本片段中也識別到了。type: textual interval 使用文本跨度偏移量來標記在文本中被提及的位置，而 type: temporal interval 使用時間跨度來標記實體在音頻中被提及的位置。

HAL 聚合分析器會將上述信息整合到一個實體中，生成的 JSON 對象包含上述所有“提及”，并獨立于媒體源，通過維基鏈接器鏈接到維基百科知識庫條目。除了文本和音頻外，我們將在內(nèi)容管理系統(tǒng)的下一個版本中通過 type: spatial interval 使用邊界框來引用實體、主題及其他特征在圖像中的提及。通過這種方式，系統(tǒng)將更接近于消費包含多種媒體類型的內(nèi)容時真實的用戶體驗。

特征庫

受Uber關于Michelangelo的博文啟發(fā)，內(nèi)容分析輸出最近保存到了一個經(jīng)過策劃的存儲中。該存儲用于保存由不同模型（包括 HAL 分析器）生成的內(nèi)容、用戶和實驗的機器學習特征。

特征庫服務旨在提供一個統(tǒng)一的、經(jīng)過策劃的持久化特征庫，并提供一個可以跨團隊使用的、既支持在線也支持離線特征消費的 API。在線的例子如推薦（包括借助Multi-Armed Bandit求解算法自動優(yōu)化）和二次排序；離線場景如批量分析、報表和新模型訓練。

此外，對于沒有變化的內(nèi)容（如發(fā)送到 HAL 的請求），特征庫可以避免重復的、成本高昂的特征提取，保證新鮮度和完整性。在使用昂貴的計算或外部供應商的分析器提取特征時，存儲庫的這項能力還特別有助于節(jié)省成本。

要了解更多關于存儲庫服務的信息，請閱讀這篇博文。

演進

我們已在計劃改進內(nèi)容分析系統(tǒng)。特別地，我們認為，HAL 及其自然語言處理功能應該成為一個更成熟的內(nèi)容分析系統(tǒng)的一部分。該系統(tǒng)不僅能夠分析內(nèi)容的文本部分，而且要更貼近用戶體驗。特別地，新系統(tǒng)應該能夠分析用戶訪問的 URL 中的所有內(nèi)容，包括圖像、文本、視頻、相冊等，而不僅僅是將其看成一段文本。而且，系統(tǒng)還應該考慮它們在頁面和用戶消費中的相互關系，并把那種理解綜合到一個多模式知識表示中。

內(nèi)容分析成熟度

可以從以下 3 個維度來評價內(nèi)容分析的成熟度水平：

內(nèi)容類型維度：系統(tǒng)能夠分析的內(nèi)容類型數(shù)，如圖像、視頻、文本、音頻。為了在這方面有一個快速的提升，我們想利用最近興起的圖像和視頻云分析服務。此外，在垂直領域，我們也開始研究自定義的試驗性圖像分析模型，更多信息請閱讀博文：手袋品牌和顏色檢測。含義維度：系統(tǒng)能夠理解的內(nèi)容含義越來越多，不僅是理解更多的語義，舉例來說，還有情緒或內(nèi)容風格的理解。這個成熟度水平評價維度適用于所有內(nèi)容類型。整體性維度：從用戶的整體體驗出發(fā)分析內(nèi)容的能力，因此要考慮用戶所消費的內(nèi)容中包含的文本、圖像和視頻，以及不同類型的內(nèi)容在特定布局中的關系。在多媒體文檔里，含義往往是嵌入在相互補充的多種形式里。

內(nèi)容分析演進維度

演進后的系統(tǒng)架構(gòu)應該能夠根據(jù)用戶需求和使用場景單獨提升某個維度的成熟度。

多模式知識表示已經(jīng)就緒，和上面提到過的一樣，跨多種內(nèi)容類型。它應該可以幫助我們定義一致的輸出，提升系統(tǒng)的可用性，使下游系統(tǒng)更容易依附于內(nèi)容特征的共享表示。

在 Condé Nast 構(gòu)建的這樣一個全球性平臺上，對于不同的語言，內(nèi)容分析系統(tǒng)的成熟度水平難免會存在差異。

互操作性的演進

另一個演進方向是與其他系統(tǒng)的互操作性。雖然已經(jīng)有一個簡單的 HTTP API 可以幫助我們將 HAL 快速集成到其他系統(tǒng)中，使其得以推廣應用，讓其他系統(tǒng)獲益，但是，在流或離線場景中，當在多個下游系統(tǒng)中使用時就會變得復雜而低效。

我們正在研究將提取出的特征發(fā)布到一個Kafka主題。我們已經(jīng)將點擊流和內(nèi)容事件發(fā)布到 Kafka。除了已提取特征主題外，下游系統(tǒng)將能夠集成 Event-Driven API 而不是 Request-Response API 來獲取所有主要實體的事件流：上下文、已提取的特征、用戶、實驗以及它們之間的交互。

小結(jié)

在生產(chǎn)中使用軟件解決方案的其中一個主要好處是，我們可以更好地理解問題域并獲得更多的知識，這反過來又催生了更好的解決方案。這種情況在復雜的軟件項目中會經(jīng)常出現(xiàn)。

Condé Nast 幾年前開始開發(fā)一個專有內(nèi)容分析系統(tǒng)，并將其與 Copilot 及底層內(nèi)容 API、消費者應用程序、Spire（我們的專有用戶精準定位平臺）集成?，F(xiàn)在，不管是消費者角度，還是從編輯和廣告商角度，內(nèi)容分析在傳媒行業(yè)的應用都讓我們對真實的問題領域有了更好的理解。

我們正在努力改善直接從專有內(nèi)容 API 透明地使用內(nèi)容分析的能力，以便下游服務可以快速、透明地消費那些智能特性。例如，自動優(yōu)化、個性化、推薦或內(nèi)容生成支持。

在 Spire 和數(shù)據(jù)產(chǎn)品方面，我們正以流和批量方式改進已提取特征的消費，簡化數(shù)據(jù)分析和模型生成。

請繼續(xù)關注這篇文章中提到的其他主題的更多細節(jié)，比如我們開發(fā)的自定義分析器、推薦系統(tǒng)和特征庫服務。

查看英文原文：Natural Language Processing and Content Analysis at Condé Nast, Part 2: System Architecture