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

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

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

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

HAL 處理流程高級(jí)視圖

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

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

CopilotProcessor 類

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

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

上文已經(jīng)提到，分析管道基于 Java 8 CompletableFuture實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的 in-JVM、可并行的有向無(wú)環(huán)圖流。節(jié)點(diǎn)會(huì)交換代表已標(biāo)注文檔的 ContentAnalysis 對(duì)象。每個(gè)標(biāo)準(zhǔn)器都可以消費(fèi) ContentAnalysis，以及向 ContentAnalysis 貢獻(xiàn)標(biāo)注。基于標(biāo)注的模型在GATE、Apache UIMA、Stanford CoreNLP等自然語(yǔ)言處理庫(kù)和框架中非常常見。

標(biāo)注模型示例

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

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

每條標(biāo)注是對(duì)文檔的一個(gè)說(shuō)明，如：

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

標(biāo)注也可以是文檔層面的，比如在主題提取時(shí)：

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

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

然后下游分析器就可以消費(fèi)那些新生成的標(biāo)注作為輸入，以此類推。

語(yǔ)言知識(shí)金字塔

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

語(yǔ)言知識(shí)模型金字塔

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

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

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

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

合而為一

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

DefaultNlpPipeline 類

下圖是上述 DefaultNlpPipeline 代碼的 DAG 流表示，以及分析器之間的相關(guān)標(biāo)注：

帶標(biāo)注的默認(rèn) NLP 管道 DAG 流

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

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

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

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

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

提取出的特征

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

折疊后的 HAL 輸出

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

提取出的關(guān)鍵詞

entities：是一個(gè)命名實(shí)體列表，如人物、地點(diǎn)或組織，對(duì)于英語(yǔ)和德語(yǔ)，我們使用了一個(gè)開源的 in-JVM 分析器，對(duì)于其他語(yǔ)言，則使用供應(yīng)商的服務(wù)；

提取出的實(shí)體

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

關(guān)聯(lián)實(shí)體

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

LDA 主題

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

文本嵌入

textMetrics： 關(guān)于文本的句法和語(yǔ)法指標(biāo)，由自定義的 in-JVM 分析器計(jì)算生成。

文本指標(biāo)

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

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

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

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

特征庫(kù)

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

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

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

要了解更多關(guān)于存儲(chǔ)庫(kù)服務(wù)的信息，請(qǐng)閱讀這篇博文。

演進(jìn)

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

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

可以從以下 3 個(gè)維度來(lái)評(píng)價(jià)內(nèi)容分析的成熟度水平：

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

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

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

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

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

互操作性的演進(jìn)

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

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

小結(jié)

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

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

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

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

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

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