開放搜尋(Opensearch)之下拉提示

下拉提示是搜尋引擎的标配功能，它能起到減少使用者輸入的作用，自動補全搜尋關鍵字，提升使用者使用搜尋引擎的體驗，好的下拉提示還可以引導使用者輸入品質高的 

query

，這些高品質 

query

 最終能輸出使用者想要的搜尋結果。既然是标配，那麼提供雲搜尋服務的開放搜尋産品，必然不會缺失這方面的能力，而且開放搜尋面向的客戶是廣大的搜尋提供商，由于他們的需求具備多樣性的特點，是以下拉提示方面的功能隻會更為豐富。

本文會從以下幾個方面對開放搜尋的下拉提示進行介紹

1. 設計理念
2. 核心功能
3. 未來展望

https://www.atatech.org/articles/119737#0

網際網路産品注重快速疊代是衆所周知的事情，開發效率高的團隊和産品才能适應不同的需求，使用者不斷被滿足，他們才會依賴這個産品，這樣的産品才能把使用者留住，這也是為什麼我們會把「擁抱變化」作為一個團隊乃至一個公司内部的核心價值觀的原因。

其實它還有另一個原因，就是很少有團隊能真正做到「擁抱變化」，這種能力是稀缺的，是以它很重要。究其原因無非也是大家經常抱怨的：使用者的需求是無限的，而團隊的人數是有限的。為了解決這個沖突，人們又總結出另一個重要的開發原則——先「把核心功能做到極緻」，之後再由一個點擴充到面，最後由面到體。可以看到，這裡的原則并不适用于雲服務産品，因為雲産品一開始就是一個面，它的每一個客戶，都是一個不同的點，如何解決這方面的問題進而做到高效就成了開放搜尋團隊首先要面對的。

如何提升雲産品的開發效率？這個問題其實作業系統已經給出了答案，那就是抽象，作業系統中一切皆檔案的思想，簡化了作業系統的設計；而虛拟檔案系統的抽象，讓它可以很容易的适配不同的檔案系統……

是以，在雲産品的設計中，一個核心的理念就是把整套服務抽象為幾個标準的流程，所有的使用者按照這個流程來，就可以建構屬于他自己的服務，然後再在不同的流程中實作定制化的需求，這樣就形成了分工協作——雲平台團隊專注于平台建設，豐富定制化能力；而其客戶則專注于實作多樣的需求。

可以預想到，開放搜尋的下拉提示也遵循了這一開發理念，我們可以把下拉提示服務的整個過程分為3個部分

1. 資料處理部分ETL（Extact、Transform、Load），解析并加載使用者的資料
2. 資料訓練部分，訓練有意義的 query 資訊，産生下拉提示索引
3. 線上查詢部分，能快速根據使用者敲入的關鍵字，傳回下拉提示清單

其中前兩個步驟，客戶擁有一定的定制化空間，在第1步中，使用者可以根據自己的需要，選擇性的導入 query 日志、點選資料、可被訓練的文本字段、黑白名單等，每一類資料都有其不同的作用，例如點選資料可以用來調整 query 品質，由文本字段抽取的 query 可以避免服務冷啟動等（下文有詳細介紹）。

在第2步，我們會提供不同的訓練算法（如不同場景下的分詞算法），根據這些算法，客戶可以按需進行選擇，調整其中的參數，最終輸出符合自己業務的 query 資料集。

最後一步，每個使用者的需求應該都是一樣的，即要求高qps、低延遲、服務高可用，這也是搜尋事業部沉澱下來的 Ha3 或 D2 所擅長的工作，這裡複用它就好了。

https://www.atatech.org/articles/119737#1

豐富的查詢方式

可以通過中文字首、拼音全拼、拼音首字母簡拼以及漢子加拼音等查詢候選 query，例如“連衣裙”這個 query，可以通過以下方式查詢得到：

1. 中文字首：連，連衣
2. 全拼字首：li，lianyi，lianyiqun
3. 簡拼字首：l，ly，lyq
4. 漢字加拼音：連yi，連衣qun

除了字首查詢之外，還支援中間詞字首獲得下拉推薦，例如”port antigua“這個 query，可以通過以下兩種方式召回

1. 字首：p，po 或 port
2. 中間詞字首：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 如果部分比對或全部比對黑名單詞條時，相關的下拉提示結果會被屏蔽。

https://www.atatech.org/articles/119737#2

前面提到了，目前的下拉提示的 query 抽取比較依賴于分詞器的詞性辨識能力，而詞性之間的組合對抽取結果的影響也不夠靈活，更為彈性的做法是分析資料源，利用詞和詞之間組合的機率來确定哪些詞組是有意義的，這種方法會讓抽取過程更為智能，它能夠适應于不同的資料源場景，同時将來和 OpenSearch 的算法平台結合後，客戶也可以通過簡單的修改幾個參數，可視化的調整訓練結果，獲得更好的搜尋體驗。

回到下拉提示的初衷，它是為了讓使用者在使用搜尋産品時，推薦給使用者好的 query，以輸出他想要的搜尋結果，對于使用者所期望的結果，這裡還有很多優化方案，例如篩選 query 時，對這些 query 的搜尋結果有要求，優先召回高品質結果的 query；除此之外，還要具備防作弊的能力，要能夠識别相同使用者做出的重複請求，以及惡意刷 query 數的行為。

在移動網際網路時代，需要在手機端做更多的優化和體驗，典型的有優化輸入體驗，例如對下拉提示清單頁的結果進行分類，讓使用者在有限的輸入情況下能獲得到更豐富的内容，可以想象在一個旅行類 app 的場景下，當使用者輸入“北京“這個關鍵字時，系統會同時給出以”北京景點”相關的下拉提示以及“北京酒店”、“北京美食”等相關的下拉提示。

總之，開放搜尋讓搜尋技術更簡單，為更多商家挖掘出商業價值，未來可期。

推薦與搜尋技術釘釘交流群