《京東億級(jí)商品搜索核心技術(shù)解密》要點(diǎn)：
本文介紹了京東億級(jí)商品搜索核心技術(shù)解密，希望對(duì)您有用。如果有疑問，可以聯(lián)系我們。

作者：王春明,現(xiàn)任京東搜索平臺(tái)部負(fù)責(zé)人,2011年加入京東搜索團(tuán)隊(duì),期間一直負(fù)責(zé)京東搜索引擎研發(fā)工作,主導(dǎo)了多次搜索架構(gòu)升級(jí)工作保障其滿足京東發(fā)展需求,擅長(zhǎng)搜索引擎、高性能服務(wù)開發(fā)、分布式系統(tǒng)架構(gòu).

招聘：?京東搜索平臺(tái)部木有有高級(jí)/資深搜索引擎研發(fā)工程師(C/C++)??、高級(jí)/資深算法工程師(C/C++)、高級(jí)/資深數(shù)據(jù)系統(tǒng)工程師(java)等職位,期待您的加入,一起打造彈性搜索平臺(tái).簡(jiǎn)歷投遞至：wangchunming@jd.com,工作地點(diǎn)：北京-北辰世紀(jì)中心A座.

京東商品搜索簡(jiǎn)介

京東商品搜索引擎是搜索推薦部自主研發(fā)的商品搜索引擎,主要功能是為海量京東用戶提供精準(zhǔn)、快速的購(gòu)物體驗(yàn).目前入口主要有PC/移動(dòng)/微信/手Q搜索、移動(dòng)列表頁(yè)、店鋪搜索、店鋪列表等.雖然只有短短幾年的時(shí)間,系統(tǒng)已經(jīng)能夠支持日均PV過億的請(qǐng)求,并且經(jīng)過了多次618店慶和雙11的考驗(yàn).

與人們?nèi)粘Ｊ褂玫娜绻雀琛俣鹊却笏阉?或稱為“全文搜索”)引擎相比,京東商品搜索引擎與前者有相通之處,比如“覆蓋海量數(shù)據(jù)”、“超高并發(fā)查詢”以及“超快速的請(qǐng)求響應(yīng)時(shí)間”,同時(shí)又有自身顯著的業(yè)務(wù)特點(diǎn)：

• 結(jié)構(gòu)化的商品數(shù)據(jù),需要從商品、庫(kù)存、價(jià)格、促銷、倉(cāng)儲(chǔ)等多個(gè)系統(tǒng)進(jìn)行抽取；
• 極高的召回率要求,保證每一個(gè)狀態(tài)正常的商品都能夠被搜索到；
• 商品信息的及時(shí)更新,目的是為了保證用戶極佳的購(gòu)物體驗(yàn)——比如不能給用戶展示出下柜的商品,或者商品的實(shí)時(shí)價(jià)格超出了用戶搜索限定的范圍.這就要求我們的搜索引擎要做到和各個(gè)系統(tǒng)的信息時(shí)刻保持同步,目前每天更新次數(shù)過億；
• 邏輯復(fù)雜的商品業(yè)務(wù),需要存儲(chǔ)的商品屬性信息是倒排索引信息的2倍之多；
• 用戶購(gòu)物的個(gè)性化需求,要求系統(tǒng)實(shí)現(xiàn)用戶標(biāo)簽與商品標(biāo)簽的匹配.

正是由于既要兼顧大搜索引擎的通用需求,同時(shí)要契合京東的業(yè)務(wù)特點(diǎn),我們將系統(tǒng)架構(gòu)分為四個(gè)部分：1. 爬蟲系統(tǒng)、2. 離線信息處理系統(tǒng)、3. 索引系統(tǒng)、4. 搜索服務(wù)系統(tǒng).

為了使各位讀者能夠深入了解京東商品搜索引擎的架構(gòu),本文首先介紹了商品搜索的總體架構(gòu),然后依次介紹了爬蟲系統(tǒng)、離線信息處理系統(tǒng)等各個(gè)部分,并且對(duì)搜索技術(shù)的最新研究方向做展望,希望對(duì)各位讀者有所幫助.

總體架構(gòu)

京東商品搜索引擎的整體架構(gòu)如下圖所示：

從上到下共分為3層.最上層是由搜索的前端UI層,負(fù)責(zé)頁(yè)面展示.

中間層是由搜索索引服務(wù)、SUG搜索、相關(guān)搜索、劃詞服務(wù)和兜底服務(wù)組成.其中,SUG搜索提供輸入框下拉提示詞功能；相關(guān)搜索提供與query相關(guān)的其他搜索詞服務(wù)；劃詞服務(wù)提供去除query部分詞的功能；兜底服務(wù)用于索引服務(wù)異常情況下提供托底,保證用戶基本的搜索可用.

最下層是索引生產(chǎn)端,主要功能是對(duì)接商品、庫(kù)存、價(jià)格、促銷、倉(cāng)儲(chǔ)等眾多外部系統(tǒng),整合相關(guān)數(shù)據(jù)生產(chǎn)全量和增量數(shù)據(jù)的索引,為在線檢索服務(wù)集群提供全量索引和實(shí)時(shí)索引數(shù)據(jù).

爬蟲系統(tǒng)

商品搜索引擎的核心是建立商品索引,而建立索引需要詳細(xì)的商品信息數(shù)據(jù).我們利用大數(shù)據(jù)平臺(tái)的數(shù)據(jù)庫(kù)抽取接口和中間件系統(tǒng),實(shí)現(xiàn)了站內(nèi)商品爬蟲系統(tǒng),用來抽取數(shù)據(jù)庫(kù)中的商品信息和及時(shí)發(fā)現(xiàn)變化的商品信息.從實(shí)踐的效果上來看,爬蟲系統(tǒng)表現(xiàn)是非常穩(wěn)定和可靠的.

離線信息處理系統(tǒng)

離線信息處理系統(tǒng)主要功能是用來建立商品搜索引擎的待索引數(shù)據(jù),包括全量待索引數(shù)據(jù)和增量待索引數(shù)據(jù).

目前商品全量待索引數(shù)據(jù)按天進(jìn)行更新,一部分是商品的基礎(chǔ)屬性信息,如商品sku、商品名稱、顏色、規(guī)格、風(fēng)格、材質(zhì)面料等等,屬于比較穩(wěn)定、短時(shí)期內(nèi)不會(huì)變化的數(shù)據(jù).另外一部分是商品銷售信息,如商品銷量、銷售額、評(píng)論等,屬于易變數(shù)據(jù).這些數(shù)據(jù)散布于多個(gè)系統(tǒng)中,使用的存儲(chǔ)也各不相同.因此需要對(duì)這些來源分散的數(shù)據(jù)在商品維度進(jìn)行合并,生成“商品全量待索引寬表”.目前我們建立的全量待索引寬表,不僅應(yīng)用于搜索引擎服務(wù),還同時(shí)應(yīng)用于個(gè)性化推薦等其他產(chǎn)品服務(wù)當(dāng)中.但是僅生成寬表是無法完成搜索引擎的索引需求的,因此我們利用Hadoop/MapReduce計(jì)算框架對(duì)寬表數(shù)據(jù)進(jìn)行清洗,并且依照離線業(yè)務(wù)邏輯規(guī)則對(duì)數(shù)據(jù)進(jìn)行二次“加工”,最終生成一份全量待索引數(shù)據(jù).

有些商品信息,比如“價(jià)格”、“庫(kù)存”、“上下架”等,經(jīng)常會(huì)產(chǎn)生變化,因此對(duì)這些數(shù)據(jù)做全量索引滿足不了商品搜索引擎的需求.為了解決數(shù)據(jù)實(shí)時(shí)性的強(qiáng)需求,我們建立了增量索引作為全量索引的補(bǔ)充.具體細(xì)節(jié)上,采用和全量索引類似的方法對(duì)數(shù)據(jù)進(jìn)行處理,生成增量待索引數(shù)據(jù).為了保證增量數(shù)據(jù)的及時(shí)性和準(zhǔn)確性,離線信息處理系統(tǒng)會(huì)實(shí)時(shí)調(diào)用各商品信息接口獲取數(shù)據(jù),完成增量待索引數(shù)據(jù)的在線組裝和生產(chǎn).

索引系統(tǒng)

索引系統(tǒng)是商品搜索引擎的核心,主要功能是把以商品為維度進(jìn)行存儲(chǔ)的待索引數(shù)據(jù),轉(zhuǎn)換成以關(guān)鍵字為維度進(jìn)行存儲(chǔ)的數(shù)據(jù),用于搜索引擎上層服務(wù)進(jìn)行調(diào)用.這里待索引數(shù)據(jù)指前面離線信息處理系統(tǒng)生成的全量待索引數(shù)據(jù)和增量待索引數(shù)據(jù).

此系統(tǒng)對(duì)于全量和增量的處理是一致的,唯一的區(qū)別在于待處理數(shù)據(jù)量的差異.一般情況下,全量數(shù)據(jù)索引由于數(shù)據(jù)量龐大,采用Hadoop/MapReduce進(jìn)行；實(shí)時(shí)數(shù)據(jù)量小,采用單機(jī)進(jìn)行索引生產(chǎn).

為了滿足分布式檢索的需求,索引系統(tǒng)還會(huì)對(duì)索引數(shù)據(jù)進(jìn)行分片處理,即按照一定策略將索引數(shù)據(jù)拆分成較小索引片,用于搜索服務(wù)系統(tǒng)調(diào)用.

搜索服務(wù)系統(tǒng)

搜索索引服務(wù)系統(tǒng)主要功能是接受用戶請(qǐng)求并響應(yīng),返回搜索結(jié)果.搜索服務(wù)系統(tǒng)的發(fā)展也經(jīng)歷了從無到有,從簡(jiǎn)單到豐富到過程.主要分為如下幾個(gè)階段：

• 最初,搜索服務(wù)只有1列searcher組成在線檢索服務(wù),能夠完成一些簡(jiǎn)單的商品搜索；
• 隨著訪問量的增長(zhǎng),搜索服務(wù)系統(tǒng)增加了緩存模塊,大大加快了請(qǐng)求處理的速度；
• 接下來為了提高用戶體驗(yàn),我們?cè)黾恿薗uery Processor服務(wù),負(fù)責(zé)用戶查詢意圖分析,提升搜索的準(zhǔn)確性.目前Query Processor已經(jīng)成為了一個(gè)融合自然語(yǔ)言處理、機(jī)器學(xué)習(xí)等先進(jìn)技術(shù)的成熟服務(wù),并且還在不斷的進(jìn)行優(yōu)化；
• 為了支持個(gè)性化,增加了User Profile服務(wù),負(fù)責(zé)查詢用戶標(biāo)簽.將商品的標(biāo)簽與用戶標(biāo)簽是否匹配,作為一個(gè)特征加入排序因子,實(shí)現(xiàn)搜索的千人千面；
• 接著隨著數(shù)據(jù)量(商品量)的增長(zhǎng),我們將結(jié)果包裝功能從檢索服務(wù)中獨(dú)立出去,成為detail服務(wù)(基于緩存云實(shí)現(xiàn)的商品信息KV查詢服務(wù))；
• 將檢索服務(wù)進(jìn)行分片化處理,即采用類似數(shù)據(jù)庫(kù)分庫(kù)分表的思想,對(duì)商品id,進(jìn)行hash處理后進(jìn)行分片,保證各個(gè)分片數(shù)據(jù)均勻.查詢時(shí),將一個(gè)搜索請(qǐng)求分配到多個(gè)searcher列上,并行檢索,進(jìn)行局部排序后返回給merger.然后merger服務(wù),將多個(gè)分片的檢索結(jié)果進(jìn)行歸并,然后再進(jìn)行業(yè)務(wù)排序和加工,確定要返回的商品,最后調(diào)用detail服務(wù)包裝,將結(jié)果返給給blender.blender將多個(gè)搜索的結(jié)果進(jìn)行融合,返回給前端.需要說明的是,此時(shí)搜索服務(wù)系統(tǒng)已經(jīng)成為了一個(gè)“多blender&多Searcher&多merger”的系統(tǒng).今后無論是訪問量的增長(zhǎng)或者數(shù)據(jù)量的增長(zhǎng),都可以通過擴(kuò)容來滿足.尤其對(duì)于618店慶、11.11之類的峰值搜索量劇增的情況下,可通過增加每個(gè)searcher列服務(wù)器的數(shù)量來滿足需求.隨著商品數(shù)據(jù)的不斷增加,只要適時(shí)對(duì)數(shù)據(jù)做更多的分片,相應(yīng)增加searcher列就可以了.檢索服務(wù)分片化機(jī)制的建立也標(biāo)志著京東搜索基礎(chǔ)服務(wù)系統(tǒng)已經(jīng)趨于完備.

完整的搜索索引服務(wù)架構(gòu),如下圖所示：

搜索請(qǐng)求流程如下：

1. 外部請(qǐng)求通過vip到達(dá)blender；
2. Blender調(diào)用QP,QP調(diào)用運(yùn)營(yíng)平臺(tái),其中運(yùn)營(yíng)平臺(tái)主要負(fù)責(zé)將日常運(yùn)營(yíng)數(shù)據(jù)服務(wù)化,QP負(fù)責(zé)分析query；
3. Blender同時(shí)請(qǐng)求Merger和其他垂直搜索服務(wù)；
4. Merger調(diào)用UserProfile獲取用戶標(biāo)簽信息；
5. Merger將請(qǐng)求發(fā)給每列searcher；
6. 每個(gè)searcher召回商品并返給Merger；
7. Merger合并多列searcher的結(jié)果,確定需要輸出的商品,請(qǐng)求Datail包裝對(duì)應(yīng)的商品信息；
8. Detail包裝商品信息返給Merger；
9. Merger將包裝好的商品返給blender；
10. Blender將merger返回的結(jié)果與其他垂直搜索結(jié)果進(jìn)行合并,最終返回給前端.

Blender、Merger、Searcher和Detail是整個(gè)系統(tǒng)的核心組件,它們之間的調(diào)用關(guān)系由Clustermap管理.各個(gè)模塊將自己的服務(wù)注冊(cè)到ClusterMap,同時(shí)從ClusterMap訂閱其調(diào)用模塊的信息來確定實(shí)際調(diào)用關(guān)系.

簡(jiǎn)要搜索服務(wù)流程,如下圖所示(搜索服務(wù)系統(tǒng)內(nèi)部處理流程)：

圖中名詞解釋如下：

• Page cache：頁(yè)面緩存,blender模塊直接緩存輸出的頁(yè)面,merger緩存了多頁(yè)商品id；
• Attr cache：屬性緩存,緩存的搜索屬性導(dǎo)航區(qū)的數(shù)據(jù)；
• Doc cache：緩存查詢?cè)~從全量索引召回的結(jié)果；
• OP：運(yùn)營(yíng)平臺(tái)服務(wù),負(fù)責(zé)搜索運(yùn)營(yíng)數(shù)據(jù)的服務(wù)化；
• QP：query processor,負(fù)責(zé)query意圖識(shí)別.

用戶請(qǐng)求發(fā)送到blender,首先解析參數(shù).如果命中blender page cache直接返回給用戶.如果沒有命中,則調(diào)用運(yùn)營(yíng)平臺(tái)服務(wù)(OP)和QP,并將其傳給Merger,Merge會(huì)檢查是否命中Attr cache,如果命中并且恰好僅請(qǐng)求屬性匯總結(jié)果,直接返回給blender.否則進(jìn)一步查看是否命中merger page cahce,如果命中直接調(diào)用detail包裝,返給blender.如果沒有命中,則調(diào)用User Profile獲取用戶標(biāo)簽,將其傳給searcher(篇幅所限,圖中只列了一個(gè)searcher,實(shí)際是多個(gè)).Searcher接到請(qǐng)求,判斷是否命中doc cache,如果命中doc cache,則拉取增量結(jié)果；如果沒有命中doc cahe,則拉取全量和增量結(jié)果.然后依次進(jìn)行排序、在線業(yè)務(wù)處理,把結(jié)果返給merger.Merger合并多個(gè)searcher結(jié)果,排序、在線業(yè)務(wù)處理,最后調(diào)用detail包裝,最后將結(jié)果返給blender,blender合并多個(gè)搜索結(jié)果后返回給用戶.

作為一個(gè)高并發(fā)系統(tǒng),為了保證高召回率和低響應(yīng)延時(shí),我們把整個(gè)搜索服務(wù)流程的處理全部放在內(nèi)存當(dāng)中進(jìn)行計(jì)算.多個(gè)searcher并發(fā)處理請(qǐng)求,同時(shí)單個(gè)searcher內(nèi)部采用線程池技術(shù),即所有線程之間共享倒排索引和商品屬性信息,提高內(nèi)存使用效率；每個(gè)查詢使用一個(gè)獨(dú)立線程串行執(zhí)行,保證并發(fā)的多個(gè)查詢線程之間互不影響.此外通過合理的設(shè)置線程池的大小,我們可以保證系統(tǒng)的CPU資源得到充分利用.在上述兩個(gè)方面對(duì)系統(tǒng)進(jìn)行優(yōu)化之后,整個(gè)搜索服務(wù)系統(tǒng)的穩(wěn)定性、召回率、內(nèi)存使用率、計(jì)算速度等指標(biāo)都有大幅度的提高.但是我們改進(jìn)系統(tǒng)的步伐并沒有停歇,因?yàn)橥ㄟ^實(shí)踐發(fā)現(xiàn)基于內(nèi)存和線程池的搜索服務(wù)仍然有幾個(gè)瓶頸點(diǎn)亟需解決,主要包括：拉取倒排、排序和在線業(yè)務(wù)處理.針對(duì)這些問題,我們進(jìn)行了二次優(yōu)化,主要包括如下措施：

1. 多級(jí)緩存策略

1. Blender Page cache：由于搜索符合互聯(lián)網(wǎng)的二八法則,20%熱門查詢頻度非常高,占每天搜索請(qǐng)求量80%.針對(duì)這一特點(diǎn),搜索第一級(jí)緩存以查詢請(qǐng)求為key,將返回給用戶的頁(yè)面作為value.對(duì)于完全相同的請(qǐng)求,直接從緩存返回結(jié)果.頁(yè)面緩存策略上線伊始,緩存命中率就接近了30%,基本解決了當(dāng)時(shí)的性能問題.
2. Merge Page cache：隨著業(yè)務(wù)的發(fā)展,排序結(jié)果需要針對(duì)不同用戶實(shí)現(xiàn)個(gè)性化訂制,這就導(dǎo)致請(qǐng)求中會(huì)包含用戶的user pin.如果直接將user pin放入緩存作為key,會(huì)導(dǎo)致blender cache的key數(shù)量暴增,不但需要超大的緩存空間,同時(shí)緩存的命中率也會(huì)極低,最終會(huì)導(dǎo)致線上個(gè)性化服務(wù)的體驗(yàn)滿意度降低.為了解決這個(gè)問題,將user_pin加入key,但是value只保存排序好的商品id,這樣需要的緩存空間遠(yuǎn)遠(yuǎn)小于blender cache.當(dāng)命中緩存后,調(diào)用detail直接進(jìn)行結(jié)果包裝.為了進(jìn)一步提高緩存命中率,利用用戶搜索的翻頁(yè)習(xí)慣,即離線統(tǒng)計(jì)出用戶的翻頁(yè)數(shù)TP99,然后在value中緩存這些頁(yè)面涉及到所有的商品id,從實(shí)踐效果來看,用戶后續(xù)的翻頁(yè)請(qǐng)求大部分會(huì)命中cache.
3. 在深入分析了業(yè)務(wù)和排序的需求之后,我們發(fā)現(xiàn)拉取倒排的結(jié)果只和“查詢?cè)~&篩選條件”有關(guān),而與用戶無關(guān),因此可以按照“查詢?cè)~&篩選條件”作為key的方式對(duì)其進(jìn)行緩存.

雖然拉取倒排結(jié)果緩存的key很快就解決了,但是我們?cè)诮鉀QValue的存儲(chǔ)時(shí)遇到了兩個(gè)問題：1)拉取倒排的結(jié)果非常之多,導(dǎo)致緩存過大；2)對(duì)此結(jié)果緩存,會(huì)降低實(shí)時(shí)索引的時(shí)效性.

對(duì)于問題1),在分析了業(yè)務(wù)之后,對(duì)需要緩存的信息進(jìn)行了大量的精簡(jiǎn)并采用壓縮存儲(chǔ),最終將一個(gè)查詢的緩存控制在0.5M以下.

對(duì)于問題2),我們將拉取倒排結(jié)果分為兩部分,第一部分是從全量索引拉取倒排的結(jié)果,第二部分是從實(shí)時(shí)索引拉取倒排的結(jié)果.為了和全量索引的更新頻率保持同步,我們把第一部分?jǐn)?shù)據(jù)進(jìn)行緩存的周期置為1天.對(duì)于第二部分?jǐn)?shù)據(jù),由于增量結(jié)果遠(yuǎn)遠(yuǎn)少于全量結(jié)果(一般增量只有全量5%不到),每次緩存都進(jìn)行實(shí)時(shí)計(jì)算,這就是圖3中的doc cache機(jī)制.從實(shí)踐中來看,命中doc cache的響應(yīng)時(shí)間比未命中的降低了1-2個(gè)數(shù)量級(jí).將來隨著增量結(jié)果的積累,如果實(shí)時(shí)拉取倒排結(jié)果成為性能瓶頸,可以對(duì)增量索引分段也進(jìn)行緩存.

2. 截?cái)嗖呗?/strong>

對(duì)于有些熱門查詢,由于其結(jié)果較多,比如“男裝”、“鞋”之類的query,原始查詢結(jié)果幾千萬個(gè),如果對(duì)這些結(jié)果挨個(gè)進(jìn)行處理,性能會(huì)非常差.同時(shí),從用戶角度分析,一個(gè)查詢只有排在最前面的結(jié)果對(duì)用戶才有意義.通過分析用戶翻頁(yè)次數(shù),可以得到截?cái)啾Ａ魌opN結(jié)果.如何保證截?cái)嗖挥绊懹脩趔w驗(yàn)?zāi)?首先我們對(duì)商品建立離線模型,即為每個(gè)商品計(jì)算出一個(gè)質(zhì)量分?jǐn)?shù)據(jù).然后在索引階段,將所有商品按照質(zhì)量分降序排列,保證在倒排鏈中,排在前面的商品質(zhì)量分總是高于后面的.在線從前往后拉取倒排過程中,如果結(jié)果數(shù)達(dá)到10*topN時(shí),停止拉取倒排.隨后對(duì)結(jié)果計(jì)算文本相關(guān)性,再按照文本相關(guān)性取topN個(gè).截?cái)嗨惴ㄉ暇€前后,雖然KPI指標(biāo)無明顯變化,但是對(duì)大結(jié)果查詢性能提升了一個(gè)數(shù)量級(jí).

3. 均勻分片策略

從總體架構(gòu)圖中我們可以看到,如果我們將一個(gè)term的倒排鏈進(jìn)行均分,那么相應(yīng)term的拉取倒排也會(huì)被分配至各個(gè)searcher列.正是由于各個(gè)searcher列是并行計(jì)算的,這樣的均分操作就可以大大減少每個(gè)查詢的平均響應(yīng)時(shí)間.從理論上來講,我們采用的均勻分片策略,也有效的契合了拉取倒排、排序、在線業(yè)務(wù)處理等CPU密集型的任務(wù).但是分片增加,會(huì)帶來硬件成本增高的后果,同時(shí)集群節(jié)點(diǎn)間的通信成本也會(huì)增加,需要進(jìn)一步權(quán)衡折衷.

4. 業(yè)務(wù)優(yōu)化

京東的搜索業(yè)務(wù)并不只有上面所述的策略和工程邏輯,還必須融合很多業(yè)務(wù)邏輯.由于每一次搜索幾乎都會(huì)召回很多結(jié)果,如果業(yè)務(wù)邏輯處理不好,也會(huì)導(dǎo)致搜索體驗(yàn)不好.針對(duì)這一問題并沒有通用的解決方法,但是通過實(shí)踐我們總結(jié)出一個(gè)基本原則：在離線階段完成盡可能多的業(yè)務(wù)邏輯,減少在線計(jì)算量!例如進(jìn)行搜索排序時(shí),我們需要根據(jù)用戶搜索歷史行為(瀏覽、點(diǎn)擊、購(gòu)買等)對(duì)召回的結(jié)果進(jìn)行排序上的調(diào)整,在工程實(shí)現(xiàn)上我們會(huì)先離線統(tǒng)計(jì)出同一個(gè)query下所有用戶對(duì)每個(gè)展示商品的行為,然后建立模型,計(jì)算出該query下每個(gè)商品的權(quán)重,將其以hash結(jié)構(gòu)存儲(chǔ)；在線排序時(shí),直接以query+商品id為key,取出權(quán)重作為反饋特征參與綜合排序.

搜索技術(shù)的新發(fā)展

我們?cè)诋?dāng)前的架構(gòu)基礎(chǔ)之上,正在進(jìn)行一些新的探索,比如場(chǎng)景搜索和圖像搜索.

場(chǎng)景搜索

隨著目前京東集團(tuán)的業(yè)務(wù)的擴(kuò)展,用戶在使用搜索時(shí),目的不僅僅是查找商品,還可能查詢促銷活動(dòng)信息.為了滿足這些新的需求,我們?cè)谀壳吧唐匪饕诤狭舜黉N系統(tǒng)的數(shù)據(jù).我們首先在Query Processor中增加對(duì)應(yīng)意圖的識(shí)別,然后將促銷等數(shù)據(jù)轉(zhuǎn)換為索引數(shù)據(jù).只要Query Processor識(shí)別出用戶提出這方便的查詢意圖,將對(duì)應(yīng)的結(jié)果返回.

圖像搜索

傳統(tǒng)搜索僅僅針對(duì)文字,但是電商系統(tǒng)的商品圖片非常重要,很多購(gòu)買決策依賴于它.目前我們利用deep learning技術(shù)離線訓(xùn)練圖片特征,并將其做成索引.當(dāng)用戶使用實(shí)拍圖或者網(wǎng)圖來搜索時(shí),采用相同的方式提取特征,然后從索引中召回最相似商品返回給用戶.

文章出處：開濤的博客(訂閱號(hào)ID：kaitao-1234567)

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4381.html