【51CTO.com原創(chuàng)稿件】眾所周知，美團(tuán)為用戶提供了全方位的生活服務(wù)，包括外賣、出行、甚至是零售和生鮮等方面。

面對紛繁復(fù)雜的服務(wù)與選項，用戶怎樣才能快速地找到自己想要的結(jié)果呢？這就需要美團(tuán)平臺的搜索服務(wù)來幫忙。

2018 年 11 月 30 日-12 月 1 日，由 51CTO 主辦的 WOT 全球人工智能技術(shù)峰會在北京粵財 JW 萬豪酒店隆重舉行。

本次峰會以人工智能為主題，來自美團(tuán)的高級算法技術(shù)專家蔣前程在推薦搜索專場，從美團(tuán)搜索的主要特點(diǎn)，以及他們是如何使用自己的算法模型去應(yīng)對挑戰(zhàn)等方面，向大家介紹《美團(tuán) O2O 服務(wù)搜索的深度學(xué)習(xí)實(shí)踐》。

美團(tuán)搜索業(yè)務(wù)現(xiàn)狀

目前，美團(tuán)搜索覆蓋了平臺 40% 的交易，具有所謂***的 POI（Point of Interest，興趣點(diǎn)）和億級別的 SPU（Standard Product Unit，標(biāo)準(zhǔn)化產(chǎn)品單元），而且用戶每天的搜索頻次（即：日 PV），也能達(dá)到億級。

那么，美團(tuán)搜索具體涉及到哪些方面呢？如上圖所示，除了左圖上方的首頁搜索欄，其下方的各個業(yè)務(wù)頻道里的搜索服務(wù)，也是由我們團(tuán)隊來負(fù)責(zé)的。

因此，我們搜索的服務(wù)目標(biāo)可分為許多種，包括：主體 POI，每個 POI 下不同業(yè)務(wù)所提供的不同服務(wù)，如：買單服務(wù)、外賣服務(wù)、傳統(tǒng)團(tuán)購業(yè)務(wù)、預(yù)付業(yè)務(wù)、以及酒店預(yù)付業(yè)務(wù)等。

作為美團(tuán)搜索的平臺，我們的使命是把用戶流量進(jìn)行高效的分發(fā)，并且在分發(fā)內(nèi)容的基礎(chǔ)上盡量提升他們的搜索體驗(yàn)。

在保持用戶黏性的同時，我們不但要提高用戶的交易效率，而且要為他們的決策提供更多的信息幫助。

另一方面，對于商家而言，我們需要把更優(yōu)質(zhì)的用戶流量導(dǎo)向他們，從而帶來更高的轉(zhuǎn)化效率。這便是我們作為美團(tuán)入口的各項使命。

美團(tuán)搜索的特點(diǎn)和挑戰(zhàn)

下面我們來討論一下 O2O 的搜索與其他網(wǎng)頁及電商的搜索，有什么相同與相異之處，以及我們面臨著哪些挑戰(zhàn)。

首先，就目標(biāo)而言，我們的業(yè)務(wù)種類繁多，而且每種業(yè)務(wù)在不同的發(fā)展階段有著不同的優(yōu)化目標(biāo)：有的需要優(yōu)化點(diǎn)擊率、有的需要優(yōu)化轉(zhuǎn)化率、有的需要優(yōu)化 GMV（Gross Merchandise Volume，成交總額）。

因此對于我們平臺而言，利用現(xiàn)有的大流量、服務(wù)好業(yè)務(wù)方、提高效率、加固平臺的交易，便是我們的整體大目標(biāo)。

其次，對于用戶而言，他們需要根據(jù)不同的用戶屬性搜索到個性化的結(jié)果。另外，我們也需要根據(jù)搜索時的時間和空間等場景的不同，提供差別化的結(jié)果。

再次，對于商家而言：

• 異構(gòu)性非常大。每個業(yè)務(wù)及其字段的關(guān)注點(diǎn)都有所不同。由于他們所提供的服務(wù)存在著差異性，因此其數(shù)據(jù)和檢索層面，也與傳統(tǒng)搜索存在著巨大的差異。
• 非標(biāo)屬性。從平臺上的餐飲店鋪可以看到，商家的菜品本身就是一些非標(biāo)準(zhǔn)化的產(chǎn)品。這與電視和空調(diào)之類的標(biāo)準(zhǔn)品，有著本質(zhì)上的區(qū)別。

可見，用戶與商家之間是通過實(shí)時性相關(guān)聯(lián)的。也就是說用戶的需求會隨著所處位置，以及早中晚餐的時間會有所不同。

而商家的運(yùn)能也會隨著一天中的不同時段，以及是否下雨等天氣因素有所變化。因此，這些都被視為美團(tuán)搜索的特點(diǎn)和挑戰(zhàn)。

總結(jié)而言，我們搜索服務(wù)的愿景便是：讓更多人更便捷地找到更多他們想要的生活服務(wù)。

其中“找到更多想要的”，可以通過智能匹配技術(shù)來實(shí)現(xiàn)；而“更便捷地找到”，則需要有個性化的排序。面對這兩條關(guān)鍵路徑，我們在深度學(xué)習(xí)方面進(jìn)行了如下探索。

美團(tuán)搜索深度學(xué)習(xí)探索實(shí)踐

智能匹配

一般說來，用戶的意圖表達(dá)分為顯式和隱式兩種輸入類型：

• 顯式就是他直接通過篩選條件所傳遞的搜索要求。
• 隱式則包括用戶的搜索時間、地理位置和個人偏好。

因此，智能匹配就要求我們通過搜索結(jié)果，展現(xiàn)出用戶需要的集合。

那么如何才能做好智能匹配呢？我們總結(jié)起來會涉及到如下兩個方面：

• 用戶意圖的匹配。
• 多維度的匹配。

就用戶意圖而言，雖然搜索的是同一條詞匯，但是不同種類用戶的期望結(jié)果會有所不同。

例如：“北京南站”一詞：

• 對于北京本地常住的用戶來說，他們搜索的目的居多是出自餐飲外賣需求。
• 對于北京本地但少去的用戶來說，他們搜索的目的居多是出自公交換乘需求。
• 對于外地游客來說，他們搜索的目的居多是出自火車與住宿需求。

因此，這就要求我們針對不同“背景”的用戶展現(xiàn)不一樣的內(nèi)容。

可見，用戶的意圖可以大致分為兩個維度：

• 場景意圖，即基于用戶的隱式條件，我們要探究其需求是以美食為主、酒店為主、還是以旅游為主。這是業(yè)務(wù)級別上的需求。
• 成分分析，即針對用戶的顯式輸入，我們要分析其中間的有效成分，并籍此制定出有針對性的標(biāo)準(zhǔn)。

業(yè)務(wù)識別

下面我來看看業(yè)務(wù)識別的基本流程。首先，我們要有一個行業(yè)知識庫，或稱為詞表。

接著，我們挖掘出一些通用的詞匯，以保證每個詞都能對應(yīng)某個需求，以及 Top 的相關(guān)問題。

在系統(tǒng)上線之后，我們通過迭代來匹配用戶的反饋，包括他們的點(diǎn)擊、下單、品類等業(yè)務(wù)分布。然后，我們得出此類需求分布的概率，并執(zhí)行各種召回。

當(dāng)然，這種簡單統(tǒng)計行為的泛化能力是存在一些問題的。如果用戶的行為特征反饋并不充分的話，他們的需求也就不太明確。

此時我們自然而然地想到了使用各種機(jī)器學(xué)習(xí)模型，對文本和用戶行進(jìn)行向量化，通過諸如 FastText 或 CNN 之類的分類模型，對用戶的各種特征予以分類，從而得到用戶的意圖，并解決泛化的問題。

不過我們也曾經(jīng)發(fā)現(xiàn)：通過機(jī)器學(xué)習(xí)所得到的分布，雖然對整體而言是合理的，但是對于某些用戶卻并不合理。

因此，我們最近采用了一些強(qiáng)化學(xué)習(xí)的方法：在細(xì)微之處，我們探索性地為用戶提供業(yè)務(wù)需求的入口，從而收集到用戶后續(xù)的反饋。

通過此類迭代，我們可以識別出用戶在某方面的業(yè)務(wù)需求是否強(qiáng)烈。

至此，我們是否可以認(rèn)為整體的業(yè)務(wù)已經(jīng)識別清楚了呢？其實(shí)，我們不難發(fā)現(xiàn)：在用戶僅輸入單個詞語進(jìn)行搜索的情況下，平臺基于大量用戶數(shù)據(jù)所統(tǒng)計出來的需求分布，并不一定能夠準(zhǔn)確地反映出用戶的意圖。

另外，用戶的歷史意圖是否會影響他的實(shí)時意圖呢？面對此類時序化的問題，我們需要基于此前他在我們系統(tǒng)中發(fā)生過的搜索行為，采用大數(shù)據(jù)統(tǒng)計來提取相關(guān)特征，利用 RNN 模型去預(yù)測他的下一個行為。

當(dāng)然，我們也會參照上述一些非業(yè)務(wù)方面的因素。

成分分析

第二個方面是成分分析。考慮到用戶可能會搜索各種短語，如：“中關(guān)村火鍋”，其中，“中關(guān)村”是地址，“火鍋”是品類，那么我們需要做好針對性的檢索。

例如：我們將地址信息轉(zhuǎn)化成地圖上的坐標(biāo)畫圈，將品類信息轉(zhuǎn)呈到已有成品類的檢索中，進(jìn)而實(shí)現(xiàn)成分分析和智能匹配的***結(jié)合。

由于成分識別實(shí)際上是一個序列標(biāo)注的問題，因此我們起初采用的是傳統(tǒng)的 CRF 模型。

雖然該模型的精度與召回尚可，但是它對于語義的理解，以及相關(guān)性的考慮是不夠的，而且它需要人工進(jìn)行特征提取與數(shù)據(jù)標(biāo)注。因此，我們想到了使用基于 LS 的深度學(xué)習(xí)與 CRF 結(jié)合的方法。

初期，由于數(shù)據(jù)量太小，算法不能很好地學(xué)習(xí)到各種標(biāo)簽的正確性，因此效果不如 CRF。

于是，我們采用了如下的方法來擴(kuò)充數(shù)據(jù)量：

• 我們將已訓(xùn)練的 CRF 模型擴(kuò)展出更多的語料，使之將預(yù)測出來的結(jié)果作為標(biāo)志數(shù)據(jù)。
• 對于已總結(jié)的數(shù)據(jù)庫，我們根據(jù)用戶反饋的規(guī)則，挖掘出更多的數(shù)據(jù)。

通過各種擴(kuò)充，待樣本增長了***的規(guī)模時，我們再運(yùn)用深度學(xué)習(xí)模型進(jìn)行實(shí)體識別。

在實(shí)體識別的過程中，我們所用到的輸入特征包括：值向量特征，以及以前 CRF 所用到的人工特征，通過 BiLSTM 再進(jìn)行 CIF，***達(dá)到了實(shí)體識別。而由此所產(chǎn)生的效果相對于 CRF，已經(jīng)有了大幅的提升。

當(dāng)然根據(jù)業(yè)務(wù)屬性，由于商家的名稱以及微信地址都是五花八門的，因此我們無法做到及時的全面覆蓋，召回也就不那么的理想。

前面提到的是用戶意圖在智能匹配上的作用。下面我們來看為何要進(jìn)行多維匹配。

例如：某個用戶輸入了“減肥餐”，那么我們僅僅使用文本匹配予以返回顯然是不夠的。

他的潛在需求，可能還包括：低油、低脂、輕食、蔬菜、水果等一系列方面。因此，這就產(chǎn)生了需求之間的語義 Gap。

為了彌補(bǔ)該 Gap，我們需要建立向量化的召回框架結(jié)構(gòu)，由上方的示意圖可見，我們將文本數(shù)據(jù)和用戶行為序列數(shù)據(jù)，導(dǎo)入語義模型，處理完畢后得到了 Query、POI、User 三者的向量，再根據(jù)這些向量執(zhí)行召回。

如今，該框架已經(jīng)能夠被在線使用到了。

語義模型

下面我們來介紹一下美團(tuán)在語義模型方面的具體嘗試。

首先是 DSSM 模型。我們在其原生模型的基礎(chǔ)上進(jìn)行了一些修改。在輸入方面，我們采用的是文檔（Doc）和查詢（Query）的雙塔結(jié)構(gòu)。此處，我們已經(jīng)做好了文本的過濾（包括低頻次的過濾）。

通常情況下，系統(tǒng)會經(jīng)過兩個隱藏層。而在此處，我們改進(jìn)為：讓第二層將***層向量選出來的隱性層轉(zhuǎn)到第三層，以便數(shù)據(jù)能夠更好地向下傳遞。

而在輸出層，我們會更細(xì)膩地考慮兩者之間的權(quán)重。我們會做一個相似度的矩陣，同時將這兩個向量傳遞到***的輸出層，以線性加權(quán)的方式得到最終的分?jǐn)?shù)，這便是我們在 DSSM 語義模型上的探索。

前面我們討論了監(jiān)督的模型，其實(shí)我們也嘗試了一些非監(jiān)督的模型。非監(jiān)督模型主要是基于用戶的行為序列。

例如：用戶會在某個查詢會話中會點(diǎn)擊多處（POI1、POI2），那么我們就將此序列當(dāng)成一個文檔。

相比前面提及的主要體現(xiàn)在文本上的模型，此處則更偏向于推薦的思想。如果用戶既點(diǎn)了 A，又點(diǎn)了 B，那么兩者之間就存在相似性，因此我們采用了單獨(dú)的模型來訓(xùn)練此類序列。

而且，我們在輸入層不只是把 POI 進(jìn)行了向量化，還將與 POI 相關(guān)的品類信息、GU 哈希信息等都拼接成額外的向量。這便是我們所做的簡單的改動。

上圖右側(cè)是一個向量的展現(xiàn)，可見系統(tǒng)能夠把一些相關(guān)的信息學(xué)習(xí)出來，以便我們進(jìn)行各種相關(guān)性的召回。

針對上述智能匹配技術(shù)，我們總結(jié)起來有兩個方面：

怎么做好用戶的意圖識別。

怎么實(shí)現(xiàn)多維度匹配，即：在傳統(tǒng)文本匹配的基礎(chǔ)上，加入了向量化召回的思路。

個性化排序

在完成了用戶匹配之后，我們幫用戶搜到大量的匹配結(jié)果。那么，我們勢必需要通過個性化排序，來優(yōu)先顯示用戶最需要的結(jié)果信息。

如上圖所示，排序的整體流程為：

• 我們使用召回層進(jìn)行簡單的粗排，它適用于一些簡單的特征，即通過線性模型對結(jié)果進(jìn)行初步過濾。
• 把少量的結(jié)果送到模型層，執(zhí)行點(diǎn)擊率和轉(zhuǎn)化率的預(yù)估。
• 在業(yè)務(wù)層會有一些可解釋性、業(yè)務(wù)規(guī)則的排序。

其中，模型層的演進(jìn)過程是：線性模型→決策樹模型（如 GBDT）→PairWise 模型→實(shí)時模型→深度學(xué)習(xí)，以滿足個性化的特征。

下面，我們來重點(diǎn)討論實(shí)時模型和深度學(xué)習(xí)的實(shí)現(xiàn)方式。

為了更好地滿足用戶的需求。我們有兩種實(shí)時化的方向：

• 許多公司會將包括實(shí)時行為、實(shí)時庫存、實(shí)時轉(zhuǎn)化等在內(nèi)的特征放入模型，以進(jìn)行實(shí)時更新。
• 通過在線學(xué)習(xí)，拼接各種實(shí)時流，實(shí)時更新參數(shù)，根據(jù)模型的評估，判斷是否要替換成新訓(xùn)練的模型。

實(shí)時特征

同時，在提取實(shí)時特征的過程中，我們需要將用戶實(shí)時的數(shù)據(jù)，如：點(diǎn)擊流、下單流等請求數(shù)據(jù)緩存到 Storm 里。

接著，基于這些數(shù)據(jù)，我們需要提取到用戶的實(shí)時行為特征，包括：品類偏好、價格偏好、距離偏好等。

另外，我們會對序列區(qū)分不同的時段，并逐一“兌換”特征，當(dāng)然，我們也會考慮該用戶會話（Session）內(nèi)部的 01 特征。結(jié)合業(yè)務(wù)特點(diǎn)的挖掘，我們最終把實(shí)時特征提取了出來。

深度模型

對于美團(tuán)而言，深度模型的需求源自如下三個方面：

• 場景非常復(fù)雜，每個業(yè)務(wù)的需求都存在著巨大差異。
• 前面提到的樹模型雖然有較好的泛化能力，但是缺少針對用戶行為的記憶能力。
• 需要對一些稀疏特征，以及特征組合進(jìn)行處理。

因此，基于業(yè)務(wù)和工程師的實(shí)際需求，我們有必要采用深度學(xué)習(xí)模型。

上圖是我們的深度學(xué)習(xí)框架。其特點(diǎn)在于如下三個方面：

• 能夠更好地在線支持超大規(guī)模的數(shù)據(jù)和模型，如：幾十個 G 的模型。
• 能夠方便地支持多種模型的定義。
• 能夠很好地支持流式模式的訓(xùn)練與上線。

簡單來看，該模型也分為三個部分：

• 離線訓(xùn)練，即Base模型，是從日志數(shù)據(jù)表里提取特征，通過訓(xùn)練，將參數(shù)存到離線集群之中。
• 流式訓(xùn)練，將實(shí)時收集到的數(shù)據(jù)作為日志予以拼接，通過特征的提取，***執(zhí)行訓(xùn)練。
• 在線預(yù)測，通過實(shí)時優(yōu)先級對模型進(jìn)行評估。如果通過，則更新到 PS 在線集群里進(jìn)行預(yù)測。

有了上述框架的感念，我們再來看看在該深度模型上的探索路徑。起初，我們直接將 Dense 特征拿過來，扔到簡單的 MLP 里執(zhí)行快速迭代。

憑借著更強(qiáng)的特征擬合能力，我們能夠?qū)崟r地迭代出參數(shù)的模型，進(jìn)而實(shí)現(xiàn)了在線式的實(shí)時更新。因此，相比之前的樹模型，深度學(xué)習(xí)模型的效果有了明顯的提升。

而針對稀疏特征，我們采用了如下兩種方法：

• 直接用模型去學(xué)習(xí)和訓(xùn)練 Embedding 特征，進(jìn)而輸入到模型之中。
• 通過 Wide 記錄模型來實(shí)現(xiàn)深度學(xué)習(xí)。

如上圖所示，在特征組合方面，我們嘗試了一些知名的模型。其實(shí)它們之間并無明顯的優(yōu)劣勢，就看哪個更適合業(yè)務(wù)項目罷了。

例如：PNN 是將特征作為一個組合放在了輸入層；DeepFM 則多了一個 FM 值；而 DCN 是做到了特征高階的模型。

因此，我們在不同的業(yè)務(wù)場景中，都嘗試了上述這些模型。一旦發(fā)現(xiàn)效果較好，我們就會將其替換成當(dāng)前業(yè)務(wù)的主模型。

總的說來，我們現(xiàn)在的主體模型是：流式的深度學(xué)習(xí)模型。從上圖的各項指標(biāo)可以看出，其整體效果都有了正向的提升。

未來展望

展望未來，我們會在如下兩大方面繼續(xù)個性化排序的探索：

• 智能匹配。在深度上，我們會深耕成分分析、用戶意圖、以及業(yè)務(wù)預(yù)測等方面。

在廣度上，我們會針對文本匹配效果不佳的場景，補(bǔ)充一些向量召回，進(jìn)而實(shí)現(xiàn)根據(jù)用戶的不同屬性，達(dá)到多維度個性化召回的效果。

• 排序模型。類似于阿里的 DIEN 模型，我們會對用戶的興趣進(jìn)行單獨(dú)建模，進(jìn)而與我們的排序模型相組合。

考慮到各種品類的相關(guān)性、文本的相關(guān)性、以及實(shí)際業(yè)務(wù)場景的不確定性，我們將在深度學(xué)習(xí)中嘗試多目標(biāo)的聯(lián)合優(yōu)化。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】