愛奇藝逗芽表情搜尋分析與實踐

愛奇藝逗芽表情（）是一款透過影片AI演算法演算法，針對UGC、PGC等來源進行表情圖片生產，並在愛奇藝內外部多渠道分發的創新產品。使用者透過文字輸入搜尋好玩有趣的表情圖片是逗芽的核心功能之一。

透過文字進行表情搜尋常見的請求類別包括：

1. 實體名稱，比如熱門的明星名、角色名、影視劇名等，以及實體的別名與縮寫；

2. 偏口語化的感情、動作描述，如“開心”，“抱抱”，“想睡了”等；

• 實體與動作的組合，如“加油蔡徐坤”，“虞書欣說的好”；

• 流行的梗、短語，如“奧力給”，“專業團隊”，“我是誰我在哪”；

• 表達完整含義的句子，如“你好，很高興認識你”。

在不考慮視覺語義嵌入（Visual-Semantic embedding）[1]及其他相關度比較方式的情況下，表情圖片的搜尋主要依賴於使用者請求與圖片標籤（文字格式）的相關度做檢索。標籤可能包括圖片中的實體、文案、動作、情緒、類別等內容，具體標籤的生產一般會結合演算法與人工標註，不在本次討論範圍之內。對於不同類別的標籤，在匹配時可能有不同的排序策略。另外在搜尋口語化的短語、短句時，需要有一定的泛化能力來滿足召回。在業務層面，不同業務可能還需要過濾不同的圖片來源、型別、大小等。

目前關於“全文檢索”比較流行的技術選型當屬ElasticSearch（ES）[2]，它是一款基於Lucene [3]的開源分散式近實時搜尋引擎，對外提供了簡單易用的HTTP API。

圖1 ElasticSearch索引分層

一個圖片文件主要包括三類欄位：

一類，是圖片元資訊如各個尺寸的大小、解析度、CDN地址等；

二類，是運營相關資訊如圖片的來源、入庫時間、稽核、推薦狀態等；

三類，是前面提到的標籤資訊如圖片的文案、人物、表情、動作、分類標籤等。

依賴上述欄位ES search API可以透過布林查詢過濾符合業務需求的圖片，再透過function_score自定義評分函式進行圖片排序，比如不同標籤欄位和運營欄位在匹配時可以有不同的權重。因此對不同的業務會去維護不同的相對複雜的查詢JSON檔案。

圖2 ES圖片搜尋框架

圖3 Lucene架構

總體上切換到Lucene基於如下考慮：

1.    業務對搜尋內容實時性要求不高，可以按天離線建立只讀索引，百萬量級索引的構建在十分鐘內就可以完成，在必要時（如有圖片急需上下線）也可以運營透過介面手動觸發索引建立。

2.    百萬量級索引大小在一百兆位元組左右，可以輕鬆放全量儲存在單機記憶體中，不需要做分片和搜尋合併，保證了效能。

3.    不同業務間索引隔離，配合容器可以針對業務獨立部署，橫向擴充套件和跨地域部署都極為方便。

4.    更容易定製分詞、排序等功能。

圖4 Lucene搜尋框架

索引服務和搜尋服務透過Zookeeper進行索引資訊的同步。不同業務方包含了不同版本號，不同版本號有不同的索引建立規則。不同時間建立的索引資訊會寫入對應到業務方對應版本號節點下。索引服務定期更新分詞器使用的實體、停用詞詞典，並掃描圖片總庫將不同業務方需要的圖片標籤資訊和圖片ID寫入不同的Lucene索引。完成寫入的索引透過forceMerge最佳化索引分段，儲存到物件儲存儲存中，並更新對應Zookeeper節點。搜尋服務透過監聽相關Zookeeper節點線上更新索引，並回收舊的索引。

業務服務透過gRPC訪問搜尋服務，再透過圖片ID獲取圖片元資訊儲存返回給使用者。圖片元資訊使用多級快取最佳化效能，如記憶體快取配合CouchBase，也可以將原ES搜尋引擎作為圖片元資訊的降級儲存。

基於Lucene的搜尋架構QPS擴充套件方便，效能也由原300毫秒的P99延時下降到100毫秒以內，搜尋相關度也有提高，滿足了業務需求。

表情搜尋一個比較明顯的特點是請求中包含有較多日常情緒、動作類短語，在召回時如果僅使用TF-IDF或BM25做字元級別的召回，容易導致召回或相關度偏低的情況。透過引入語義層面的召回我們可以解決這個問題，比如，“興高采烈”在Lucene下很難召回圖片，透過語義則可以關聯到“眉開眼笑”、“喜滋滋”等相關標籤圖片提高召回；“混吃等死”在Lucene下會把“等”字單獨分出來導致“等著”、“等你”這類相關度比較低的圖片被召回，透過語義相似度過濾也可以避免這種情況。

語義召回可以拆解為使用者請求和圖片標籤的短文字相似度檢索問題。將圖片庫內圖片標籤編碼為固定長度的稠密向量，並儲存到向量索引中，就可以實現使用者請求和標籤的最近鄰查詢。像Annoy或Faiss等向量索引都可以做到千萬量級下的毫秒級召回。

將短文字對映到稠密向量的方式也有不少，在NLP領域可以被歸納到句嵌入（sentence embedding）範疇。句嵌入編碼可以利用RNN、DAN（Deep Averaging Network）、Transformer等多種編碼器對句子做編碼的監督學習。下圖即為Google 2019年提出的多語言句編碼器的多工訓練框架[5]。

圖5 Google Universal Sentence Encoder訓練結構

句嵌入編碼也可以直接使用預訓練模型，先利用大語料非監督學習訓練出來的詞向量（如Word2Vec、Fasttext）或上下文編碼器（如BERT、ELMo）進行token級別的編碼，再透過工程或統計方式（平均、TF-IDF、SIF等）將非固定長度的token編碼轉化為固定長度的句嵌入。

在對比測試並考慮開發成本的基礎上，逗芽目前使用了預訓練詞向量取平均的方式進行句嵌入編碼，並進行了一些針對性最佳化。

我們採用基礎分詞加BiMM （Bi-directional Maximal Matching）的方式來儘可能匹配詞向量詞典中更長的詞，提高短語、短句的匹配度。其次由於詞向量本身基於詞語在語料中的上下文訓練，導致不少反義詞或同類詞向量空間中距離較近，如“難過”和“開心”，“美女”和“帥哥”，不符合語義召回的預期，我們透過自定義反義詞詞典進行了詞向量counter-fitting [6]微調，提升語義相關度。

圖6 Glove詞向量最近鄰counter-fitting前後對比

排序策略

在引入語義召回後我們把使用者搜尋請求做實體與非實體的區分，實體部分直接透過Lucene召回。非實體部分Lucene和語義都做召回，Lucene召回部分對匹配的長度和順序做了較嚴格的要求，語義召回部分會找到相似的topN標籤，再過Lucene全匹配召回對應圖片。

圖7 結合語義召回

神配圖是將使用者輸入直接新增到圖片上的一種新型表情互動方式，神配圖返回的圖片也可以作為表情搜尋的一個較好補充，尤其在使用者搜尋不到圖片的情況下。

圖8 神配圖示例

由於文字需要實時新增到圖片上，我們目前使用了讀請求的後端加字方式，即搜尋結果返回時並沒有真正的圖片加字，只有在使用者端上請求訪問圖片的CDN地址時並回源時才進行圖片的生產，保證了介面效能和整體使用者體驗。

本文回顧了逗芽表情搜尋在不同業務階段的不同實現方式。在定製化要求不多，實時性和吞吐量需求也不是很強的情況下ElasticSearch可以的滿足大部分使用場景。在定製化和服務能力需求更高的情況下，可以先基於ES做針對性的最佳化和配置，如果還不能滿足需求可以考慮直接使用Lucene。在語義召回方面，可以優先使用預訓練模型，以較低的開發成本獲得相對明顯的提升。如果服務體量更大可能需要從倒排索引開始自建搜尋引擎，就不在本次討論範圍之內了。

目前逗芽表情搜尋還有很多待最佳化的空間，例如標註語料最佳化句編碼模型讓語義召回更準確；引入更多維度特徵或L2R最佳化排序；支援實時性更高的增量索引等等。產品上還有不少和搜尋相關的應用場景可以繼續挖掘，如個性化推薦、表情對話、以圖搜圖、基於視覺語義的圖片檢索等等。

搜尋是一件原型容易，最佳化難的開發任務。軟體工程沒有銀彈，搜尋實現也沒有，但是作為開發者我們可以根據團隊資源和業務需求找到合適的搜尋落地之路。

參考文件

[1] 視覺語義嵌入（Visual-Semantic embedding）Frome, A. 2013. Devise: A deep visual-semantic embedding model

[2] ElasticSearch（ES）：

[3] Lucene：

[4] ES IK：

[5] 多語言句編碼器的多工訓練框架：https://ai.googleblog.com/2019/07/multilingual-universal-sentence-encoder.html

[6] counter-fitting：Nikola Mrki. 2016. Counter-fitting Word Vectors to Linguistic Constraints

[7] Annoy：

[8] NDCG：https://en.wikipedia.org/wiki/Discounted_cumulative_gain