開放搜尋(Opensearch)之下拉提示
下拉提示是搜尋引擎的標配功能，它能起到減少使用者輸入的作用，自動補全搜尋關鍵字，提升使用者使用搜索引擎的體驗，好的下拉提示還可以引導使用者輸入質量高的 query ，這些高質量 query 最終能輸出使用者想要的搜尋結果。既然是標配，那麼提供雲搜尋服務的開放搜尋產品，必然不會缺失這方面的能力，而且開放搜尋面向的客戶是廣大的搜尋提供商，由於他們的需求具備多樣性的特點，所以下拉提示方面的功能只會更為豐富。
本文會從以下幾個方面對開放搜尋的下拉提示進行介紹
- 設計理念
- 核心功能
- 未來展望
設計理念
網際網路產品注重快速迭代是眾所周知的事情，開發效率高的團隊和產品才能適應不同的需求，使用者不斷被滿足，他們才會依賴這個產品，這樣的產品才能把使用者留住，這也是為什麼我們會把「擁抱變化」作為一個團隊乃至一個公司內部的核心價值觀的原因。
其實它還有另一個原因，就是很少有團隊能真正做到「擁抱變化」，這種能力是稀缺的，所以它很重要。究其原因無非也是大家經常抱怨的：使用者的需求是無限的，而團隊的人數是有限的。為了解決這個矛盾，人們又總結出另一個重要的開發原則——先「把核心功能做到極致」，之後再由一個點擴充套件到面，最後由面到體。可以看到，這裡的原則並不適用於雲服務產品，因為雲產品一開始就是一個面，它的每一個客戶，都是一個不同的點，如何解決這方面的問題從而做到高效就成了開放搜尋團隊首先要面對的。
如何提升雲產品的開發效率？這個問題其實作業系統已經給出了答案，那就是 抽象 ，作業系統中一切皆檔案的思想，簡化了作業系統的設計；而虛擬檔案系統的抽象，讓它可以很容易的適配不同的檔案系統……
因此，在雲產品的設計中，一個核心的理念就是把整套服務抽象為幾個標準的流程，所有的使用者按照這個流程來，就可以構建屬於他自己的服務，然後再在不同的流程中實現定製化的需求，這樣就形成了分工協作——雲平臺團隊專注於平臺建設，豐富定製化能力；而其客戶則專注於實現多樣的需求。
可以預想到，開放搜尋的下拉提示也遵循了這一開發理念，我們可以把下拉提示服務的整個過程分為3個部分
- 資料處理部分ETL（Extact、Transform、Load），解析並載入使用者的資料
- 資料訓練部分，訓練有意義的 query 資訊，產生下拉提示索引
- 線上查詢部分，能快速根據使用者敲入的關鍵字，返回下拉提示列表
其中前兩個步驟，客戶擁有一定的定製化空間，在第1步中，使用者可以根據自己的需要，選擇性的匯入 query 日誌、點選資料、可被訓練的文字欄位、黑白名單等，每一類資料都有其不同的作用，例如點選資料可以用來調整 query 質量，由文字欄位抽取的 query 可以避免服務冷啟動等（下文有詳細介紹）。
在第2步，我們會提供不同的訓練演算法（如不同場景下的分詞演算法），根據這些演算法，客戶可以按需進行選擇，調整其中的引數，最終輸出符合自己業務的 query 資料集。
最後一步，每個使用者的需求應該都是一樣的，即要求高qps、低延遲、服務高可用，這也是搜尋事業部沉澱下來的 Ha3 或 D2 所擅長的工作，這裡複用它就好了。
核心功能
豐富的查詢方式
可以通過中文字首、拼音全拼、拼音首字母簡拼以及漢子加拼音等查詢候選 query，例如“連衣裙”這個 query，可以通過以下方式查詢得到：
- 中文字首：連，連衣
- 全拼字首：li，lianyi，lianyiqun
- 簡拼字首：l，ly，lyq
- 漢字加拼音：連yi，連衣qun
除了字首查詢之外，還支援中間詞字首獲得下拉推薦，例如”port antigua“這個 query，可以通過以下兩種方式召回
- 字首：p，po 或 port
- 中間詞字首：a，an，ant 等
智慧抽取query
該功能是下拉提示的亮點，也是開放搜尋這種雲搜尋場景下獨有的能力（區別於google、百度等全網搜尋引擎），旨在解決客戶接入搜尋服務後，由於沒有足夠多的query資料，無法提供完善的下拉提示體驗，於是智慧抽取 query 應運而生，它會根據使用者的 doc 文件資料，抽取相關性高，有意義的 term 組合，形成下拉提示資料集，這樣即便沒有任何搜尋請求，使用者也可以使用下拉提示功能，解決了搜尋應用的冷啟動問題。
具體的，我們在實現該功能時，先基於使用者期望的抽取欄位進行分詞，這裡我們會提供多種分詞演算法，使用者可以選擇新聞領域、電商領域或視訊領域的分詞庫。
接著，根據分詞後的詞性，我們會挑出有意義的詞性組合，形成候選 query，組合包括「地名+名詞」、「專有時間詞+專有名詞」等，例如“春款連衣裙”就會和後者匹配，根據訓練結果的好壞，我們篩選了20多種詞性組合。
最後，我們對這些有意義的候選 query 進行TF計算，選擇出現頻率較高的 TopN 的候選列表，當然，為了讓不同字首的 query 組合足夠的豐富，我們在做 TopN 時，會對超過一定數量的相同字首的 query 進行降權，例如：如果“iphone”這個字首非常多，我們只會抽取前 m 條，剩下的會降權處理，待下拉列表不足時，才會使用降權query進行補足，這種做法既滿足了資料的多樣性，也保證了資料的完備性。
可以看到，上面的演算法很大程度上依賴於分詞庫的能力，畢竟我們面向的是不同領域的服務商，不同客戶之間的資料集都有很大的差異，分詞庫很難覆蓋所有的場景和 case，所以在抽取使用者 query 的過程中，我們增加了一個策略：即保留欄位中長度較短的 term，例如10個字長度的 term，這樣，一部分無法被分詞器識別的專有詞彙會根據這些 term 的出現頻率自動的被篩選出來，而客戶也可以根據這種特性，把他們期望保留的 query 以這種形式儲存在文件欄位中。
干預能力
對於一些突增熱詞，例如當“iphone Xs”釋出時，它的 query 頻次肯定不及釋出了一年的“iphone X”，這種 case 下，客戶肯定希望當他的使用者敲入“iphone”時，“iphone Xs”排在下拉提示的最前面，這時我們提供的推薦名單功能就可以派上用場了，客戶可以手動輸入“iphone Xs”詞條，這樣它就可以排在最前面了。
相反，有些query客戶是不希望被展示的，例如一些法律敏感的詞彙，或 query 返回的結果集較少的詞彙，此時客戶可以使用我們提供的黑名單功能，運用該功能後，使用者輸入的 query 如果部分匹配或全部匹配黑名單詞條時，相關的下拉提示結果會被遮蔽。
未來展望
前面提到了，當前的下拉提示的 query 抽取比較依賴於分詞器的詞性辨識能力，而詞性之間的組合對抽取結果的影響也不夠靈活，更為彈性的做法是分析資料來源，利用詞和詞之間組合的概率來確定哪些片語是有意義的，這種方法會讓抽取過程更為智慧，它能夠適應於不同的資料來源場景，同時將來和 OpenSearch 的演算法平臺結合後，客戶也可以通過簡單的修改幾個引數，視覺化的調整訓練結果，獲得更好的搜尋體驗。
回到下拉提示的初衷，它是為了讓使用者在使用搜索產品時，推薦給使用者好的 query，以輸出他想要的搜尋結果，對於使用者所期望的結果，這裡還有很多優化方案，例如篩選 query 時，對這些 query 的搜尋結果有要求，優先召回高質量結果的 query；除此之外，還要具備防作弊的能力，要能夠識別相同使用者做出的重複請求，以及惡意刷 query 數的行為。
在移動網際網路時代，需要在手機端做更多的優化和體驗，典型的有優化輸入體驗，例如對下拉提示列表頁的結果進行分類，讓使用者在有限的輸入情況下能獲得到更豐富的內容，可以想象在一個旅行類 app 的場景下，當用戶輸入“北京“這個關鍵字時，系統會同時給出以”北京景點”相關的下拉提示以及“北京酒店”、“北京美食”等相關的下拉提示。
總之，開放搜尋讓搜尋技術更簡單，為更多商家挖掘出商業價值，未來可期。
推薦與搜尋技術釘釘交流群
