目錄

一.前言

二.搜索系統(tǒng)架構(gòu)演進(jìn)

    2.1.到家搜索系統(tǒng)1.0

        基于LBS搜索召回場景

        建立“可用”的搜索系統(tǒng)

        小結(jié)

    2.2.到家搜索系統(tǒng)2.0

        重構(gòu)召回

        排序模型小試牛刀

        建立索引容災(zāi)能力

        小結(jié)

    2.3.到家搜索系統(tǒng)3.0

        精細(xì)化多路召回

        模型升級 算法賦能

        路由平臺自動容災(zāi)

三.搜索系統(tǒng)整體架構(gòu)

四.展望與總結(jié)

一.前言

京東到家作為行業(yè)領(lǐng)先的即時零售電商平臺，依托達(dá)達(dá)快送的高效配送和大量優(yōu)秀零售合作伙伴，為消費者提供海量商品小時達(dá)的極致服務(wù)體驗。隨著平臺中的商品供給日益豐富，幫助用戶準(zhǔn)確尋找目標(biāo)商品的能力就會顯得越來越重要，而搜索系統(tǒng)在電商平臺中即承擔(dān)著這樣的職責(zé)。

在到家平臺中，搜索系統(tǒng)承接了多個主要流量入口，在不同業(yè)務(wù)場景下為用戶提供了多元化的關(guān)鍵字商品檢索能力。目前，搜索系統(tǒng)在平臺中覆蓋的主要場景有首頁搜索、頻道頁搜索、秒殺活動頁搜索、券購搜索及到家小程序平臺搜索等，如下圖所示：

隨著到家業(yè)務(wù)發(fā)展，到家的用戶量級也在持續(xù)增加，為了滿足用戶購物需求，給用戶一個便捷的購物體驗，搜索系統(tǒng)一直在持續(xù)地進(jìn)行架構(gòu)迭代和策略升級。本文將對到家搜索系統(tǒng)架構(gòu)演進(jìn)歷程進(jìn)行詳細(xì)介紹。

二.搜索系統(tǒng)架構(gòu)演進(jìn)

2.1 到家搜索系統(tǒng)1.0

基于LBS搜索召回場景

由于到家是基于LBS的即時零售業(yè)務(wù)場景，所以在搜索系統(tǒng)架構(gòu)上與傳統(tǒng)電商搜索相比也會有所區(qū)別?；贚BS的搜索系統(tǒng)在保證商品相關(guān)性和排序結(jié)果合理性的同時還要通過地理位置因素對召回商品范圍進(jìn)行限定。在到家系統(tǒng)中，我們采取的方法是通過墨卡托投影原理將門店的配送范圍映射為多個有限區(qū)域塊，再結(jié)合倒排索引找出覆蓋目標(biāo)位置的門店供給列表。對應(yīng)到搜索場景中，我們所需要做的就是在給定的門店列表范圍內(nèi)通過Query進(jìn)行高效地商品查詢。

建立“可用”的搜索系統(tǒng)

在到家發(fā)展初期，搜索系統(tǒng)設(shè)計思路以簡單、可用為目標(biāo)，架構(gòu)上采用分層單體架構(gòu)。在實現(xiàn)上，通過對當(dāng)前供給門店列表進(jìn)行ES terms查詢來保證LBS條件限定，而Query與商品的匹配主要依靠對Sku名稱進(jìn)行ES的query_string查詢。同時,對用戶輸入的Query會通過分詞方式進(jìn)行簡單的品牌品類成分信息提取，并用于對查詢語句的boost提權(quán)中。ES查詢結(jié)果順序就是搜索系統(tǒng)的返回順序，分頁也交由ES來控制。這樣一來，就實現(xiàn)了1.0版本的到家搜索系統(tǒng)。

小結(jié)

隨著業(yè)務(wù)的發(fā)展，平臺上門店和商品的供給數(shù)量呈爆發(fā)式增長，最初這版搜索架構(gòu)在業(yè)務(wù)支持上顯得愈發(fā)吃力。主要體現(xiàn)在以下幾點：

1. ES深分頁瓶頸在召回期間通過ES的from size方式進(jìn)行分頁控制。在深度分頁情況下，這種查詢方式非常低效，查詢性能會直線下降。

2. 缺乏完整召回能力由于通過ES進(jìn)行分頁控制，所以每次請求搜索服務(wù)內(nèi)部只能從ES拿到當(dāng)前頁的返回數(shù)據(jù)，無法得到完整召回數(shù)據(jù)。但一個完整的搜索系統(tǒng)應(yīng)該包含對搜索結(jié)果多維度篩選功能、搜索結(jié)果聚合展示功能，如果每次只能拿到一頁數(shù)據(jù)，那么在業(yè)務(wù)玩法上就會受到極大的限制。

3. 排序干預(yù)能力有限在商品搜索場景中，ES的bm25評分可以反映出Query與Sku名稱間的文本相關(guān)性，但除此之外，搜索排序邏輯還需要關(guān)注商品的價格、評價、門店信用、商家質(zhì)量、促銷力度等維度特征，僅通過bm25評分作為排序依據(jù)是遠(yuǎn)遠(yuǎn)不夠的。但如果所有排序因素都通過ES加權(quán)語句實現(xiàn)，最終查詢語句就會變得十分復(fù)雜，并且在索引中還要維護(hù)所有排序特征信息，這顯然不太現(xiàn)實。所以，需要建立一套獨立的搜索排序服務(wù)來承接這樣的職責(zé)。

4. ES集群單點依賴搜索業(yè)務(wù)最基本的能力就是召回，而召回能力又建立在了底層索引數(shù)據(jù)基礎(chǔ)之上。在搜索1.0版本中底層索引由一套ES集群支撐，但這就會造成整個搜索系統(tǒng)對這套ES集群的單點依賴，如果ES出現(xiàn)問題那么整個搜索業(yè)務(wù)就會面臨癱瘓的風(fēng)險。

2.2 到家搜索系統(tǒng)2.0

將1.0版本搜索系統(tǒng)中的主要問題進(jìn)行歸類可以發(fā)現(xiàn)，除了底層集群單點依賴之外，其余三個問題之間都有著直接或間接關(guān)系。

ES分頁依賴 ——> 無法完整召回 ——> 排序干預(yù)能力有限

所以，優(yōu)化工作的核心目標(biāo)是要替換掉當(dāng)前的ES分頁方式，將全部命中數(shù)據(jù)完整召回?；谝陨纤伎?，我們提出了以下方案：

• 棄用ES分頁，全量召回內(nèi)存分頁

• 抽象排序模塊，獨立服務(wù)化部署

重構(gòu)召回

首先需要考慮的問題是如何將全量數(shù)據(jù)召回到內(nèi)存中。如果from 0 size n設(shè)置一個較大的數(shù)值，那么ES每一個分片均會召回n條數(shù)據(jù)后再匯總重排，引發(fā)上文中提到的深分頁問題。而ES的另外兩種分頁方式scroll和search after更是不滿足C端場景使用需求，尤其是scroll在高并發(fā)場景下還會有極大的性能風(fēng)險。相比之下，還是from size的查詢方式更適合當(dāng)前C端搜索場景需要。

在確定from size查詢方式后，我們嘗試找到一個即滿足業(yè)務(wù)需求又符合性能要求的size臨界值。隨著size增大,ES的查詢性能持續(xù)下降。例如，在600qps和5000qps場景分別測試不同size查詢性能，得出如下結(jié)果:

再結(jié)合上下游接口超時要求，最終確定size可取的最大值為1500左右（不同業(yè)務(wù)需要結(jié)合實際使用的ES集群配置、索引結(jié)構(gòu)以及查詢語句進(jìn)行實際測試）。但是，面對區(qū)域內(nèi)動輒上千的門店覆蓋，召回1500個商品顯然無法滿足業(yè)務(wù)需要。

對此，我們采取了一個折中邏輯，將全部門店等量拆分為多組（以下圖為例，每個group包含m個門店)，每組門店單獨進(jìn)行一次ES查詢，size設(shè)置為1500。雖然1500的召回量不足以覆蓋所有門店的全部相關(guān)商品，但對于一組門店還是相對充足的。通過調(diào)整門店分組大小可以對召回率和ES負(fù)載進(jìn)行平衡，在到家搜索的實踐場景中，采取的是30個門店一組。

排序模型小試牛刀

在有了完整召回能力后，下一步優(yōu)化的重點就是建立對全量召回結(jié)果的排序能力，我們的具體做法如下:

• 首先，將排序邏輯與搜索核心服務(wù)解耦，抽象后獨立部署維護(hù)，以便后期排序邏輯的頻繁迭代不會對搜索召回模塊造成影響。

• 其次，引入大量業(yè)務(wù)特征，例如促銷、價格、銷量、復(fù)購等，并將ES返回的bm25評分作為其中一項特征，通過所有特征加權(quán)分來進(jìn)行排序。這種排序方式簡單有效，在早期時候也取得了不小的收益。

• 最后，在此基礎(chǔ)上引入了LR線性模型，通過LR模型來計算權(quán)重w取值，排序效果又進(jìn)一步得到了提升。

建立索引容災(zāi)能力

到家在這個時期無論業(yè)務(wù)體量還是用戶體量相比最初均有了幾何倍數(shù)增長，所以解決單點依賴風(fēng)險保障服務(wù)的高可用性也同樣十分迫切。

從宏觀鏈路上看，整個搜索服務(wù)中最薄弱的環(huán)節(jié)就是底層索引。雖然ES采用了高可用的分布式節(jié)點部署、主副分片自動平衡等優(yōu)秀的架構(gòu)設(shè)計，但在極端情況下依然會有集群異常情況產(chǎn)生，例如ES集群由網(wǎng)絡(luò)異常引起的腦裂問題、主副分片節(jié)點同時宕機問題等。

所以，建立索引層容災(zāi)能力才是搜索系統(tǒng)穩(wěn)定性的關(guān)鍵，常見的做法有以下幾種：

1. ES節(jié)點跨機房異地部署

• 描述：將ES集群中不同節(jié)點部署在不同機房，降低單機房網(wǎng)絡(luò)或故障導(dǎo)致集群不可用的風(fēng)險。

• 優(yōu)點：實現(xiàn)簡單、無需額外操作、索引文件一定無法橫向擴展。

• 缺點：需要解決跨機房網(wǎng)絡(luò)訪問延遲問題，集群存在腦裂風(fēng)險增加。

2. 定期快照

• 描述：定期對ES索引生成快照，并將快照數(shù)據(jù)備份到外部存儲。備份的數(shù)據(jù)可以在備集群中恢復(fù)。

• 優(yōu)點：如果集群宕機，可以通過快照文件將數(shù)據(jù)恢復(fù)到其他備用集群，保證主要數(shù)據(jù)不會丟失。

• 缺點：部分增量數(shù)據(jù)丟失、恢復(fù)時間長、無法提供集群的橫向擴展能力。

3. 集群雙寫

• 描述：在上層寫入應(yīng)用中將索引數(shù)據(jù)雙寫到兩（多）個集群中，多個集群數(shù)據(jù)保持一致。

• 優(yōu)點：由雙集群保證高可用，異常概率大大降低。還可以借助上層路由策略，對請求流量在集群間分流,做到真正意義上高擴展。

• 缺點：多集群數(shù)據(jù)難以保證絕對一致；硬件資源成本成倍增加；多集群使用需要增加路由邏輯控制。

在到家的搜索應(yīng)用場景中，我們更在意的是服務(wù)穩(wěn)定性以及故障短時間恢復(fù)能力，所以最終采用了異地部署加集群雙寫的綜合方案。底層索引由兩套ES集群支撐，所有ES節(jié)點分布在兩個機房部署。上層服務(wù)雙寫保證索引數(shù)據(jù)的準(zhǔn)一致。

在應(yīng)用服務(wù)內(nèi)部使用Supplier的方式對ES連接進(jìn)行管理，再通過外部Zookeeper進(jìn)行集群路由配置的存儲和通知。當(dāng)需要修改路由配置時可在Zookeeper中進(jìn)行調(diào)整，由Zookeeper通知所有應(yīng)用服務(wù)實例。具體如下圖所示:

小結(jié)

通過一系列優(yōu)化改造，搜索召回能力得到極大提升，漏召回現(xiàn)象明顯減少。排序方面借助線性模型對召回集合整體排序，也做到了將高質(zhì)量、高銷量類型商品排在前邊。但是此時整體召排結(jié)構(gòu)和業(yè)內(nèi)高水準(zhǔn)架構(gòu)設(shè)計相比還是有不小差距，很快又遇到了新的痛點：

• 召回策略單一所有Query均使用統(tǒng)一分詞匹配+品牌分類提權(quán)的方式召回，在召回策略控制上過于單一。不同Query在語義上強調(diào)的重點不同，很難通過一套策略適配所有Query。

• 線性排序模型瓶頸雖然線性模型排序結(jié)果相比1.0版本上有了很大的提升，但線性模型也存在一些天然的弊端。例如需要對特征歸一化處理，O2O場景非標(biāo)品比例較高，特征統(tǒng)一歸一效果太差，導(dǎo)致模型效果不及預(yù)期。另外線性模型學(xué)習(xí)交叉特征能力弱，無法表達(dá)復(fù)雜場景，模型優(yōu)化天花板較低。

在容災(zāi)能力上，雖然初步實現(xiàn)了對底層多集群的調(diào)度控制，但在實際使用場景中也發(fā)現(xiàn)了很多問題，例如：

• 非平臺化接入方式接入雙集群需要在應(yīng)用代碼中進(jìn)行額外開發(fā)，代碼侵入嚴(yán)重，且能力無法復(fù)制。

• 異常處理需要人工介入發(fā)生異常時集群流量無法自動熔斷，需要人工操作集群切換。

雖然到家搜索2.0在召排能力及容災(zāi)能力上都得到了一定的加強，但也只能算是將1.0版本的“可用”水平提升到了“易用”水平，距離“好用”的水平還有著不小的距離。

2.3 到家搜索系統(tǒng)3.0

3.0版本的搜索系統(tǒng)優(yōu)化目標(biāo)上主要分成策略和架構(gòu)兩個部分。

策略上，需要在保證召回率的同時限制錯召過召問題，對召回結(jié)果需要建立一套更完善的排序策略，使排序結(jié)果更加合理，整體流量分發(fā)更加高效。

架構(gòu)上，期望打造一個高性能、高可用、高擴展的搜索系統(tǒng)，進(jìn)一步增強底層容災(zāi)能力，提升系統(tǒng)橫向擴展能力。

為此，提出了以下幾點優(yōu)化方向：

• 細(xì)分query類型，差異化多路召回

• 迭代排序模型，提升排序效果

• 集群路由控制平臺化，異常自動熔斷

精細(xì)化多路召回

在之前的版本中，搜索主要的索引匹配邏輯是通過Query對ES中Sku名稱進(jìn)行分詞查詢。但如果底層分詞策略調(diào)整導(dǎo)致分詞字典發(fā)生變化，那么就需要對整個索引進(jìn)行重建才能生效，十分不靈活。另外一些隱藏的商品屬性在Sku的名稱中可能并不存在，導(dǎo)致無法與Query匹配，這也會引起一系列的漏召問題。

為了提升召回匹配相關(guān)性，我們在離線對商品的名稱、品牌、分類、屬性、聚類主題等進(jìn)行多維度成分提取，將提取出來的數(shù)據(jù)作為召回通道存儲在ES中。同時對實時請求的Query也做類似的成分提取。在召回時，我們將原來分詞匹配方式改為了Query與Sku之間的成分匹配，通過不同成分信息間的組合限制方式保證了召回的相關(guān)性。

另外，為了能實現(xiàn)針對不同類型Query靈活制定召回策略，我們將Query按照組成成分結(jié)構(gòu)劃分成了多種類型，并且針對每一種Query類型都分別制定不同的三級召回策略（以下簡稱L1，L2，L3）。三級召回策略定位不同，

• L1精準(zhǔn)意圖召回:必須保證Sku與Query成分完全匹配

• L2意圖擴展召回:犧牲部分非核心成分匹配限定，但對品類這種核心成分保持了限定，用于擴充召回豐富度

• L3補充召回:文本分詞匹配，不做成分限定

不同類型下具體三級召回策略均不相同，在語義相關(guān)性限制力度上依次遞減，L1 > L2 > L3。

在召回階段，將三級召回策略與2.0版本引入的門店分組召回方式相結(jié)合，每組門店分別進(jìn)行三次策略召回。在3.0版本中對門店分組策略也進(jìn)行了優(yōu)化，原來按數(shù)量等分的方式可能會將多個供給充足的門店分到同一組中，這樣在面對召回范圍寬泛的搜索詞時就會發(fā)生召回截取，導(dǎo)致召回率降低。所以，在處理分店分組階段，我們結(jié)合了門店的靜態(tài)供給數(shù)量、行業(yè)類型對門店分組打散處理，將同行業(yè)中供給量充足的門店分配到不同組中，降低召回截取概率，進(jìn)一步提升了召回率。

在系統(tǒng)架構(gòu)上，將意圖識別模塊、召回模塊從原系統(tǒng)中解耦獨立部署。將流程調(diào)度以及搜索相關(guān)的業(yè)務(wù)處理邏輯封裝在搜索中臺內(nèi)部，與意圖服務(wù)、召回服務(wù)以及排序服務(wù)共同組成了搜索的核心模塊，在架構(gòu)上做到低耦合與高內(nèi)聚。

模型升級 算法賦能

在2.0版本中我們嘗試了通過簡單線性模型對搜索結(jié)果進(jìn)行排序優(yōu)化，并且取得了不錯的效果，但也很快就觸碰到了線性模型的天花板。業(yè)務(wù)發(fā)展到這個時期，通過幾個簡單業(yè)務(wù)特征結(jié)合線性模型的排序方式已經(jīng)難以滿足業(yè)務(wù)需要，需要深入挖掘多維度特征甚至交叉特征，結(jié)合更復(fù)雜的模型對整個排序流程進(jìn)行重構(gòu)。

搜索排序的最基本原則是要優(yōu)先保證與Query相關(guān)性更高的商品排到前邊?；谒阉?.0版本在多路召回上的調(diào)整，使得召回結(jié)果帶有了天然的相關(guān)性屬性，并且L1、L2、L3的召回結(jié)果在相關(guān)性上逐層遞減。但是面向召回的三級分層方式在排序場景下還是顯得粒度過粗，所以在召回三級Level的基礎(chǔ)之上排序內(nèi)部又將其分為了六層Rank，所有排序邏輯均在Rank層內(nèi)執(zhí)行，不同分層的商品不跨層調(diào)整，如圖:

在排序流程上，采用了預(yù)排、粗排、精排、策略重排這樣的四級排序方式，每級排序邏輯的實現(xiàn)方式各有不同，承載的主要職責(zé)也有所不同。

• 預(yù)排:主要用于精選召回商品，將召回后的商品通過召回Level等級和靜態(tài)質(zhì)量分進(jìn)行預(yù)排序，最終選取Top 3000結(jié)果進(jìn)入到粗排階段。

• 粗排:負(fù)責(zé)初步篩選召回結(jié)果中用戶可能感興趣的商品，盡量讓這類商品排到前邊并有機會進(jìn)入精排階段?？紤]到粗排商品量級較大，實現(xiàn)上我們選擇了性能較好的XGB樹模型。

• 精排:使用TensorFlow深度模型對粗排結(jié)果中的Top 200個Sku進(jìn)行局部的精細(xì)化重排。

• 策略重排：基于模型排序的結(jié)果，根據(jù)具體的業(yè)務(wù)規(guī)則，對排序結(jié)果進(jìn)行最終的微調(diào)。

在算法模型預(yù)測邏輯的架構(gòu)設(shè)計上，采用了模型中臺的方式，將常用模型在其內(nèi)部進(jìn)行了封裝，結(jié)合配套的模型配置平臺可對模型特征及特征獲取方式進(jìn)行配置化管理。上層排序服務(wù)可通過預(yù)先在配置平臺設(shè)置的modelTag對模型中臺發(fā)起預(yù)測請求。具體的模型實現(xiàn)邏輯對外部無感知。

路由平臺自動容災(zāi)

為了解決2.0版本中的多集群管理方面的遺留問題，在3.0版本中對底層的集群路由方案也做了全面升級，具體如下圖：

首先，為了簡化接入流程，將原來應(yīng)用服務(wù)內(nèi)部代碼侵入的管理方式改為了路由管理客戶端接入的方式，路由策略配置交由服務(wù)端進(jìn)行管理，可以做到配置調(diào)整實時生效。這樣任何服務(wù)均可以通過平臺化的方式接入路由平臺，極大降低了接入成本。

其次，應(yīng)用服務(wù)通過通路由客戶端獲取ES集群連接對象，在執(zhí)行完成ES請求操作后，路由客戶端會將本次ES操作的成功失敗狀態(tài)上報到路由服務(wù)端。參考熔斷器的設(shè)計思想，由服務(wù)端對上報信息進(jìn)行定時匯總統(tǒng)計，如果發(fā)現(xiàn)近一個時間窗口內(nèi)ES的異常請求操作比例觸發(fā)了熔斷閾值，服務(wù)端就會通過主動修改路由配置策略屏蔽該集群的路由訪問，并將修改結(jié)果廣播通知到客戶端。

最后，在路由平臺的設(shè)計上還兼容了多套集群（超過兩套以上）災(zāi)備的問題，任何接入方均可根據(jù)需要靈活配置。

具體路由客戶端和服務(wù)端交互方式如下圖所示：

路由客戶端內(nèi)部實現(xiàn)了對所有集群路由規(guī)則邏輯的封裝，對外部黑盒處理。具體的路由策略配置交給路由服務(wù)端管理。搜索服務(wù)接入路由平臺后，可實時通過路由客戶端提供的ES路由查詢功能來獲取ES客戶端代理。完成與ES的請求交互后，客戶端代理會將請求的成功失敗狀態(tài)通過隊列+異步的方式自動上報到服務(wù)端，用于ES集群狀態(tài)監(jiān)控。

搜索系統(tǒng)整體架構(gòu)

經(jīng)過長期迭代，當(dāng)前的到家搜索系統(tǒng)從宏觀架構(gòu)上看可以被分為如下幾個模塊：搜索業(yè)務(wù)模塊、搜索核心模塊、算法模型預(yù)測模塊、索引數(shù)據(jù)模塊、輔助功能模塊。如下圖所示:

• 搜索業(yè)務(wù)模塊：承接來自前端所有搜索業(yè)務(wù)相關(guān)請求，是搜索服務(wù)的最上層出口。向下與搜索中臺對接，獲取搜索相關(guān)業(yè)務(wù)數(shù)據(jù)，并根據(jù)業(yè)務(wù)場景需要補全所需數(shù)據(jù)，結(jié)構(gòu)化封裝后返回給前端。起著承上啟下的作用。

• 搜索核心模塊：搜索核心模塊由搜索中臺、意圖識別、搜索召回、搜索業(yè)務(wù)排序幾個服務(wù)組成，是整個搜索架構(gòu)中最重要的組成部分。

• 算法模型預(yù)測模塊：以模型預(yù)測中臺服務(wù)為統(tǒng)一出口，將常用的模型預(yù)測算法進(jìn)行了統(tǒng)一封裝，對接了例如LR、XGB、Tensorflow等算法模型，提供了多樣化的算法預(yù)測能力。在搜索服務(wù)鏈路中，模型預(yù)測模塊主要承擔(dān)著計算搜索結(jié)果排序分的作用。

• 索引數(shù)據(jù)模塊：到家搜索系統(tǒng)底層索引數(shù)據(jù)由兩套ES集群支持，兩套集群中索引數(shù)據(jù)內(nèi)容相同，由索引構(gòu)建服務(wù)負(fù)責(zé)對兩套ES進(jìn)行索引全量構(gòu)建以及增量更新。兩套集群既可以獨立承接線上流量互為主備，又可以同時承接峰值流量進(jìn)行壓力分流。

• 輔助功能模塊：結(jié)合研發(fā)、測試、運營人員的使用需求，在搜索平臺中提供了搜索結(jié)果Debug解釋、搜索策略Diff分析、搜索結(jié)果badcase干預(yù)、搜索字典動態(tài)管理配置等實用功能，極大提升了相關(guān)人員的工作效率。

從3.0版本的宏觀架構(gòu)上看，我們將搜索這樣的復(fù)雜業(yè)務(wù)按領(lǐng)域驅(qū)動設(shè)計思想進(jìn)行了系統(tǒng)拆分，每個子系統(tǒng)負(fù)責(zé)專屬業(yè)務(wù)功能，系統(tǒng)間設(shè)立邊界隔離，系統(tǒng)內(nèi)部根據(jù)業(yè)務(wù)特性進(jìn)行垂直化建設(shè)，整體模塊劃分已相對清晰。但是從細(xì)節(jié)邏輯的處理方式上看仍然存在著較多的問題，需要我們在未來的工作中繼續(xù)完善，例如：

• L3補充召回合理性

  隨著L1L2策略日趨完善，L3使用的文本召回的方式已經(jīng)很難對L1L2進(jìn)行有效的召回補充，補充的商品大多數(shù)相關(guān)性較差。

• 模型維護(hù)效率低下

  目前模型數(shù)量相對可控，模型的訓(xùn)練、更新等操作主要依靠人工完成。在未來模型越來越多的情況下，維護(hù)效率難以保證。

• 欠缺垂類場景專屬策略

  同樣的Query在不同垂類場景下會有不同的意圖含義。例如“蘋果”在生鮮場景下是水果意圖，但在3C場景下卻是手機意圖。建立不同垂類場景的個性化召排策略也是未來優(yōu)化工作的一個主要方向。

展望與總結(jié)

系統(tǒng)優(yōu)化永遠(yuǎn)沒有終點，目前我們已經(jīng)開始著手準(zhǔn)備到家搜索4.0版本的優(yōu)化工作。在下一個版本中，針對遺留問題有以下幾個重點優(yōu)化方向：

• 向量召回：萬物皆可embedding，使用向量召回方式替代現(xiàn)有的L3策略對召回結(jié)果進(jìn)行補充。

• 自動化模型迭代：構(gòu)建一個強大的算法平臺，通過任務(wù)托管的方式將模型訓(xùn)練及上線工作自動化運行，避免因為樣本過時導(dǎo)致的模型效果衰減，也可以提高模型的管理效率。

• 場景化召排策略：針對不同的上層業(yè)務(wù)入口或者垂類意圖，制定差異化的召排策略，挖掘搜索潛力。

經(jīng)過幾個版本的優(yōu)化，到家搜索系統(tǒng)在逐漸地向“好用”水平看齊。在這個過程中我們也深刻體會到“召回決定搜索的下限，排序決定搜索的上限”，二者相輔相成，是搜索系統(tǒng)最重要的兩大核心能力。在未來的工作中，我們依然會堅持以提升用戶搜索體驗為最終目標(biāo)，圍繞召回、排序兩大搜索核心能力不斷迭代。