使用 OpenSearch 實作電商搜尋系統 - 開放搜尋

本文將介紹如何使用阿里雲OpenSearch基於電商情境構建出一個簡單的商品搜尋原型，從而滿足業務對商品搜尋的需求。在構建類似電商平台建設中，有一塊重要的業務要求是可通過關鍵字搜尋的方式對商品資訊中不同屬性進行搜尋，同時可對搜尋出的商品列表進行分類的過濾，採用阿里雲OpenSearch產品實現一個商品搜尋的原型，能很好的滿足專案的需求。

環境準備

第一次開通阿里雲帳號並登入控制台時，會提示先建立access key才能繼續使用。

建立及使用應用依賴access key參數，主帳號下access key參數不可為空。
在為主帳號建立access key參數後，還可以再建立RAM子帳號access key通過RAM子帳號進行訪問，RAM子帳號賦予對應存取權限，請參考授權訪問鑒權規則。

基本架構

整個原型的系統架構如下：

建立應用

1.登入阿里雲OpenSearch控制台，在左側導覽列單擊執行個體管理，在執行個體管理頁面單擊左上方建立執行個體：

2.選擇應用類型：

本文基於電商情境下，涉及多表關係映射，所以選擇支援簡單多表join邏輯的進階版應用類型。關於應用類型的詳細介紹請參考OpeanSearch應用類型說明。

3.填寫應用資訊：

選擇商品類型：目前系統支援預付費和後付費，具體區別可參考：計費方式與價格。選擇地區和可用性區域域：目前OpenSearch支援的可用性區域域有

中國地區：華南1、華北1、華北2、華北3、華東1、華東2、中國香港
亞太地區地區：新加坡
歐美地區地區：德國（法蘭克福）、美國（維吉尼亞）

應用程式名稱：應用程式名稱由以英文字母開頭的數字、英文字母或底線組成，長度不超過 30 個字元；注意：應用程式名稱建立後無法修改！應用類型：進階版、標準版。購買規格：目前OpenSearch支援的有共用通用、共用計算、共用儲存、獨享通用、獨享計算、獨享儲存，詳情可參考：計費方式與價格。儲存容量和計算資源：按實際而定，計算資源估算方法：LCU個數=QPS*單次查詢消耗的LCU。其中單次查詢消耗的LCU可以先購買一個入共用通用型應用後，在搜尋測試功能中進行測試查看單次查詢消耗的LCU。

4.配置應用：

手動建立應用結構：可以自訂應用結構進行應用建立。
通過模板建立應用結構：系統預設提供了幾種常用的模板樣式，使用者也可以將自己定義的應用結構建立成模板，可以通過已有模板快速建立出一個新的應用。
上傳文檔產生應用結構：您可以上傳已有的資料檔案（僅支援JSON格式），系統會自動解析並建立出初始的應用結構（注意欄位類型等需要重新定義）
通過資料來源建立應用結構：適用於通過RDS、MaxCompute（原ODPS）、PolarDB等資料來源同步的情境，可以快速由源表結構建立出初始的應用結構，節省手動構造的工作量，降低出錯機率。這裡以RDS為例，其他資料來源操作類似，具體詳見資料來源配置。

使用阿里雲開放儲存服務ODPS、RDS、PolarDB可以在OpenSearch控制台直接配置使用相應的資料來源，資料將自動同步進入OpenSearch，簡單、方便、可靠。本文將以RDS為例，選擇通過資料來源建立應用結構。

5.串連資料來源

填寫資料庫配置，具體參見下圖：

6.選擇資料來源：

7.定義應用結構

我們採用商品表為主表，商品價格表為輔表的方式建立了應用結構即商品價格表主鍵pid關聯商品表外鍵id。原型所用的結構如下圖： 7.1 8.定義索引結構

將商品表、商品價格表中需要搜尋的相關欄位添加到索引列表“default”中，這樣就能通過query=default:“關鍵字”，對商品進行搜尋操作了。具體配置見下圖：

說明

注意：分詞方式直接影響搜尋結果，請謹慎選擇，關於分詞方式的選擇具體請參考文檔。

9.配置資料來源

在這裡，您可以選擇是否開啟資料自動同步功能。開啟後，資料更新將自動同步至OpenSearch。

10.配置完成後，單擊“完成”，此時在應用詳情頁中就可以看到，應用的狀態處於“應用初始化中.”：

上傳資料

上面我們是以RDS為例，索引構建中會預設開始匯入全量資料，可以在應用詳情頁中看到具體進度。當然也可以調用OpenSearch API或者SDK來手動上傳資料：

測試

資料上傳成功後就開始搜尋體驗了，OpenSearch控制台內建了OpenSearch搜尋可以通過API/SDK或者搜尋測試頁面進行查詢（詳見API及SDK說明），本文以系統中搜尋測試頁面為例，搜尋文法請參考API開發人員手冊搜尋介面及query子句介紹。搜尋結果如下圖所示：

您還可以利用OpenSearch各種自訂的功能，來獲得更優的搜尋體驗。例如解決目前使用者長尾query召回少、搜尋字詞填寫錯誤無法召回、輸入拼音無法召回等問題，具體請參考查詢分析和相關性實戰。

配置一個查詢分析：這裡我們以拼字錯誤修正為例配置一個查詢分析：

第一步：建立查詢分析幹預詞典： 1.1 依次單擊控制台首頁功能 搜尋演算法中心--召回配置--詞典管理 進入查詢分析幹預詞典頁面：

1.2 單擊右上方“建立”，詞典類型為拼字錯誤修正，輸入詞典名稱單擊“儲存”：1.3 在詞典列表中剛剛建立的詞典後單擊詞條管理進入幹預詞典頁面：1.4 單擊新增幹預詞條配置您的幹預詞條：1.5 單擊儲存，添加成功。您可以在幹預詞條列表中看到您建立的幹預詞條：第二步：OpenSearch控制台左側導覽列中依次單擊召回配置→查詢分析配置進入查詢分析頁面：第三步：單擊建立添加一個未上線規則，幹預詞典選擇我們剛剛建立的dic_error：

停用詞：根據系統內建的停用詞典過濾查詢中無意義的詞（一般是使用頻度過高的但不影響查詢結果的詞，比如標點符號、語氣助詞等）。例如：查詢詞“奔跑吧!兄弟”，經過停用詞處理後標點符號“!”不參與召回。
拼字錯誤修正 ：檢查使用者查詢串中的拼字錯誤，並給出錯誤修正建議。對於確定的拼字錯誤將直接改寫原始查詢串，然後進行檢索；對於可能的拼字錯誤將仍然使用原始查詢串進行檢索。例如：查詢詞“阿里爸爸”，經過拼字錯誤修正會改寫為“阿里巴巴”，然後進行檢索。
詞權重 ：分析查詢中每個詞的重要程度，並將其量化成權重，權重較低的詞可能不會參與召回。例如：查詢詞“OpenSearch好不好”，經過詞權重處理，只要包含“OpenSearch”的文檔都可以召回。
同義字：根據系統提供的通用同義字和語義模型，對查詢串進行同義字擴充，以便擴大召回。例如：查詢原詞為”KFC”，經過同義字處理後，包含”肯德基”或者”KFC”的文檔都會被召回（配合詞權重功能使用效果更佳）。
實體識別：具名實體識別（Named Entity Recognition，簡稱NER）是系統對Query分詞後將每個語義實體進行需求識別的功能。每個語義實體會被打上相應的類型標籤，類型標籤重要性低的語義實體在查詢中可能會被省略；類型標籤重要性高的語義實體會直接影響類目預測模型的訓練。比如“耐克修身連衣裙”，實體識別的結果為“耐克/品牌/中”“修身/款式元素/低”“連衣裙/品類/高”。

第四步：建立之後，可在查詢分析介面，單擊“搜尋測試”進行效果驗證：第五步：調試無誤後，可返回查詢分析介面，在切換到“索引視角”後，將其設定為預設查詢分析：

配置排序運算式：排序運算式允許使用者為應用自訂搜尋結果排序方式，通過在查詢請求中指定運算式來對結果排序，具體請參考搜尋相關性配置。

第一步：依次單擊應用首頁排序配置→策略管理進入搜尋結果排序管理頁面：

第二步：單擊右上方的建立，添加新的基礎排序（粗排）：

基礎排序（粗排）對效能影響較大，盡量選用最有代表性的欄位。這裡我們以配置文本分、文檔新舊程度的算分配置為例。

第三步：添加新的業務排序（精排）：這裡我們以配置商品名相關性為例。

第四步：完成配置。搜尋結果如下圖所示：這裡搜尋測試支援普通查詢和設定策略排序後的查詢結果對比。

配置下拉提示：電商情境中，為了減少使用者輸入，協助使用者儘快找到想要的內容，我們可以使用OpenSearch的下拉提示功能。關於下拉提示功能的配置請參考下拉提示。

配置類目預測：您也可以使用類目預測功能預測使用者想要查詢那個類目的結果，具體步驟請參考類目預測。

其他常用配置：

電商情境中，如果某個商家的多個商品的文檔分值都比較高，則都排在了搜尋結果的前面。這樣既不利於結果展示，也不利於使用者體驗。我們可以採用多樣性彙總distinct子句來提升結果的多樣性。具體用法請參考彙總子句-distinct。
業務上還支援按價格區間進行結果的查看，需要採用filter子句，更多用法請參考過濾子句-filter。我們以價格欄位進行過濾為例，操作相關代碼如下：
```
if(!lowPrice.equals("")){
  queryElement.addFilter("price>=" + lowPrice);
}
if(!highPrice.equals("")){
  queryElement.addFilter("price<=" + highPrice);
}
```

總結

至此一個簡單的基於阿里雲OpenSearch構建的電商情境下的搜尋原型已經構建完成。OpenSearch提供了比較完善的搜尋服務和API介面，能夠基於OpenSearch快速實現業務對於搜尋的需求，大大減少了開發工作，提高了搜尋功能開發的實現效率，同時也減少了搭建複雜搜尋引擎平台帶來的系統部署和營運的工作量和成本。使用者可以根據業務情境的不同選擇OpeanSearch各種自訂配置和功能，從而獲得更優的搜尋體驗。