電商檢索系統總結——功能篇

本身做爲後端研發工程師，一直在公司電商項目中參與和檢索相關的工做。工做的時間也不短了，一直但願能寫一些文章來總結、整理下本身接觸到的知識點，一方面是爲了梳理本身的思路，另外一方面也做爲一種分享和交流。

本文簡單總結一下，電商檢索系統須要向用戶提供哪些功能。

搜索頁面結構

下圖是一個電商搜索結果頁的基本結構：

你們能夠看到，頁面基本上有如下幾種元素構成：

• 搜索欄
• 商品列表
• 麪包屑
• 分類樹
• 篩選項
• 商品推薦

每一種元素，都爲用戶展示了不一樣緯度的檢索結果；同時，部分元素也爲用戶提供了進一步的檢索、過濾功能。

搜索欄，提供了query檢索的功能，用戶最經常使用的尋找商品的方式；

分類樹和麪包屑，一方面從分類緯度展現了搜索結果，同時用戶也能夠對於上面的結果進行分類檢索；

篩選項，提供了對於檢索出的商品屬性的聚合，同時用戶又能夠對於本身感興趣的屬性進行單獨篩選；

商品列表，是呈現給用戶的最終結果；

商品推薦，除了天然的檢索結果，還會根據用戶當前的檢索行爲以及歷史行爲，進行商品推薦。

功能

 

上面提到的元素，都是爲了讓用戶使用電商檢索系統的某些功能，或者向用戶展示某些功能的最終結果。下面就具體講一下電商檢索系統須要具有的基本功能：

Query檢索

即關鍵詞檢索，用戶經過輸入一個檢索詞來描述本身的需求，好比「iphone5s」、「三星Galaxy」、「Nike運動鞋」等等。關鍵詞檢索，涉及到創建一個檢索系統的一些基本步驟：

• 切詞（將一段文本轉化爲一個一個單元，即term）
• 創建倒排索引（Inverted Index）
• 索引歸併
• 排序

切詞以前，首先須要肯定的是：商品的哪些字段須要被切詞而且建入索引。商品的標題是須要建索引的，另外，通常來講，商品的品牌名稱、商家名稱、分類名也是須要建索引。選擇建索引字段的範圍，實際上是須要一些權衡的，範圍選得過大，固然能夠提升召回率，但這樣也會出現一些bad case（好比將商品描述中一些不相關的term建進了索引），同時倒排拉鍊過長也會影響性能。

分類檢索

通常來講，綜合型電商網站的首頁，都會有一個分類樹全集，供用戶直接點擊查詢。例以下圖：

除了Query檢索，用戶按照商品的分類進行檢索的比例也會較大。分類檢索和Query檢索相比，不一樣點只是少了切詞步驟，另外將term改成商品的分類ID。

說到分類，就要涉及到分類體系。通常來講，有兩種分類體系：後端分類體系，和前端分類體系。後端分類體系相對穩定，幾乎不變，用戶感知不到後端分類；前端分類體系結構能夠很靈活，隨意變化，通常由運營同窗來維護。前、後端分類體系都是樹狀的結構，然後端分類樹的任意節點能夠「掛載」至一個或者多個前端分類樹的葉子節點上面，這樣兩套分類體系之間就產生了關聯。

這兩個分類體系能夠類比爲超市的貨物分類（嚴格來講應該是電商參考了零售行業的分類方式），一開始貨物都是放在後臺的庫房裏面的，它們按照一種分類體系（後端分類系統）來存放，非工做人員是看不到的；而等到貨物須要從庫房擺放到貨架時，超市工做人員能夠以時令、促銷活動等爲依據，讓貨架上的商品按照另外一種體系（前端分類體系）進行組織，顧客只能看到這種組織形式。

排序

用戶經過query或者分類檢索出的商品結果，默認都是按照相關性排序的。（關於相關性排序，內容仍是比較複雜的，另外本身也不是專門作這一塊的，這裏就不展開講了）除了按照相關性進行排序，用戶還能夠按照其它條件進行排序，例如：

• 價格
• 折扣
• 評論數
• 好評度
• 上架時間
• 是否正在促銷
• ……

上面都是用戶能夠看獲得、本身能夠選擇的排序方式。除了這些，還會有一些其它因素影響商品結果的排序。

首先是一些基本的業務邏輯，好比在天然排序下，有庫存的商品排在前面，無庫存的排在後面；SPU商品排在前面，SKU商品排在後面。（SKU、SPU的概念後面會講到）

另外還有一些運營方面的考慮。好比，發現搜索結果中有一個很不相關的商品出現，這時就急需在query粒度上對這個商品進行打壓、甚至是不容許展示。或者，因爲某種合做關係，在某些query或者分類下，必須將某個商家的商品排在前面。所以，檢索系統後臺就須要維護這麼一份各個維度的商品「黑白名單」。

標籤聚合

所謂標籤，就是用一些「鍵-值」的概念來描述一個商品的特色。好比說MacBookPro，能夠有以下標籤：

• 品牌：Apple
• 尺寸：13寸
• 處理器：Intel i7
• 價格：9288 RMB
• ……

當用戶檢索商品時，檢索系統除了直接展現商品之外，還會將商品上面的標籤進行聚合，通常都是經過「標籤名 + 標籤值的列表」的形式展示給用戶（以下圖），方便用戶經過標籤進行進一步的篩選。

分類樹

當用戶進行query檢索時，檢索系統會進行query分析，將這個query可能對應的分類，經過分類樹的形式展示給用戶。好比用戶搜索「小米」，query分析出的分類既有「手機通信」，又有「糧油米麪」。

通常來講，檢索系統爲了保證query的準確率，會在檢索條件中添加query的預測分類，使得檢索結果不至於各類分類的商品混雜在一塊兒，影響用戶體驗。因此當用戶搜索「小米」時，檢索結果會限定在「手機通信」這個分類下，可是若是用戶真的是想搜索「糧油米麪」下的小米，也不要緊，只需在點擊分類樹中相應分類進行限定便可。

麪包屑

麪包屑，原來是用於在網站上面顯示當前頁面在整個sitemap中的位置，方便用戶跳轉至網站其它地方。在電商網站中，就變成了展示網站所在的分類路徑（ + 品牌名稱 + query），例如

電腦、辦公 > 電腦整機 > 筆記本 > 清華同方（THTF） > 清華同方鋒銳T200

點擊麪包屑上面的每一級分類，就能夠在某個分類下進行商品檢索，方便用戶擴大或者縮小檢索範圍。

過濾

除了進行各類觸發（query檢索、分類檢索等），還須要在觸發結果的基礎上面，再進行過濾。上面說到的標籤過濾、分類樹限定，都屬於過濾。總結下來，會有這麼幾種過濾方式：

• 分類過濾
• 標籤過濾
• 價格區間過濾
• 地域過濾
• 庫存過濾
• 是否自營
• 商家過濾（針對於微購這樣的電商平臺）

Query提示

所謂query提示，就是當用戶在搜索框中建入query時，系統能提供給用戶一個query list，或者一些分類建議，方便用戶向檢索系統提供給準確的query以及分類範圍，減小用戶進行重複搜索的次數。

如下是京東的query提示截屏，有拼音翻譯爲query、有分類預測、有每一個query對應的檢索商品數，作的比較完善。

相對而言，微購作的query提示就原始許多，輸入「shouji」，竟然連自己的「手機」都沒有，囧……

Query改寫

Query分析中的一項功能就是作「query correction」，經過算法或者人工標註的形式，判斷出用戶真正須要搜索的query是什麼。好比用戶輸入了「按着手機」，檢索系統須要能判斷出用戶搜索的真正query多是「安卓手機」，固然，好的產品確定能讓用戶自行選擇，而不是強姦用戶，就像上面提到的用戶能夠選擇分類樹上的分類，用以明確告知系統本身所須要查找的分類範圍。

如下是在京東搜索「按着手機」的截圖：

SPU聚合

首先須要提供兩個概念：SKU，以及SPU。

根據我在網上查找到的資料，SKU是Stock Keeping Unit，指的是庫存的最小單位；而SPU是Standard Product Unit，是指商品信息聚合的最小單位，是一組可複用、易檢索的標準化信息的集合，該集合描述了一個產品的特性。

簡單的理解就是，「iPhone4S」是一個SPU，「iPhone4S 白色 16G 電信版」就是一個SKU；「MacBookPro」是一個SPU，「MacBookPro 13寸 8G內存 128G硬盤」就是一個SKU。

所以，當用戶進行商品檢索時，須要將SKU粒度的商品聚合成SPU粒度，使得檢索結果比較多樣，從而不至於滿屏都是各類顏色、型號的同一款商品。等到用戶進行商品詳情頁以後，再來選擇具體的型號。

下圖是微購檢索結果頁SPU、SKU排列結果：

如下是京東商品詳情頁的截屏，紅框中的選項的每一種組合，都表明着不一樣的SKU。

推薦

推薦系統，是和檢索系統一樣負責的系統，另外我也並不熟悉相關的知識，因此這裏只是根據本身的理解，簡單的說一下。

從頁面角度來講，幾乎全部頁面上面均可以進行商品推薦：首頁、搜索結果頁、詳情頁、購物車頁面、下單成功頁、錯誤頁，等等。而不一樣的頁面，推薦的側重點也會不盡相同。

好比首頁推薦，用戶此次購物流程尚未任何行爲，因此通常都是經過該用戶的歷史行爲向用戶進行推薦。

在詳情頁，用戶則已經表現出對於這個商品的較強的需求，通常會有兩種類型的推薦：

• 推薦和該商品相似的商品
• 推薦能夠和該商品進行組合的商品

第一種推薦，在各分類商品中出現的都比較多，通常的推薦理由是「看（購買）過該商品的用戶也看（購買）了」；

第二種推薦，通常出如今數碼產品中。好比用戶在看一款手機時，向用戶推薦手機套、手機耳機、SD卡，讓用戶能夠「一頁式」完成許多商品的購買，減小用戶決策的過程，激發用戶的購物慾望（原來根本沒想到手機套這回事，既然你推薦了，又不貴，就買一個唄）。

到了購物車頁面，用戶的購物流程即將結束，能讓用戶在這個階段再購買的一個主要動力是：湊單，這樣能夠節省運費或者參加活動。因此在這個階段推薦的商品通常是：同店鋪的類似商品，以及一些單價較低的、平常消費的商品。

總結

本文並無講解與電商檢索相關的技術細節，只是單獨從產品的角度，羅列了一下一個電商檢索系統須要具有的功能，只能算是本身粗淺的整理和概括，確定有許多遺漏或者錯誤之處。有問題的話，歡迎你們反饋，我也會及時進行更正。之後有機會的話，還會對電商檢索系統中的技術細節進行一些概括和整理。