亞馬遜雲端創新「神經稀疏檢索」：只需要文字匹配就能實現語意搜索

AIxiv專欄是本站發布學術、技術內容的欄位。過去數年，本站AIxiv專欄接收通報了2,000多篇內容，涵蓋全球各大專院校與企業的頂尖實驗室，有效促進了學術交流與傳播。如果您有優秀的工作想要分享，歡迎投稿或聯絡報道。投稿信箱：liyazhou@jiqizhixin.com；zhaoyunfeng@jiqizhixin.com

本文作者是來自 OpenSearch 中國研發團隊的機器學習負責人楊揚博士以及機器學習工程師志超志超和管聰。 OpenSearch 是一個由亞馬遜雲端科技發起的純開源搜尋和即時分析引擎專案。目前軟體超過 5 億下載量，社群在全球擁有 70 個以上的企業合作夥伴。

自從大模型爆火以來，語意檢索也逐漸成為熱門技術。尤其是在 RAG（retrieval augmented generation）應用中，檢索結果的相關性直接決定了 AI 產生的最終效果。

目前市面上絕大部分的語義檢索實現方案，都是利用語言模型（Language Model）將一串文本編碼為一個高維向量，並利用近似k - 鄰近搜索（k-NN）進行檢索。面對 VectorDB 和語言模型部署（需要 GPU）高昂的費用，許多人望而卻步。

近日，亞馬遜OpenSearch 連同亞馬遜上海人工智慧研究院，在OpenSearch NeuralSearch 插件中推出了Neural Sparse 功能，解決了當前語意檢索正在面臨的以下三個挑戰：

• 相關性表現在不同查詢上的穩定性
：zero-shot 語義檢索要求語義編碼模型在不同背景的資料集上都有不錯的相關性表現，即要求語言模型即開即用，無需用戶在自己的數據集上fine-tune。利用稀疏編碼與詞向量（Term Vector）同源的特性，Neural Sparse 可以在遇到陌生文字表述（行業專有詞、縮寫等等）的時候向文本匹配降級，從而避免離譜的檢索結果。
• 線上搜尋的時間效率
：低時延對於即時檢索應用的意義是顯而易見的。目前流行的語意檢索方法一般都會包含語意編碼以及索引兩個過程，這兩者的速度決定了一個檢索應用端到端的檢索效率。 Neural Sparse 獨特的 doc-only 模式，無需線上編碼，即能在與文本匹配相近的時延情況下，達成與一流語言模型相媲美的語義檢索的精度。
• 索引的儲存資源消耗
：商業化的檢索應用對儲存資源的消耗是非常敏感的。在對海量資料進行索引時，搜尋引擎的運作成本與儲存資源的消耗強烈相關。在相關實驗中，索引相同規模的數據，Neural Sparse 僅需要 k-NN 索引的 1/10。同時記憶體消耗也大大小於 k-NN 索引。

                     Relevance Demo

🎜🎜

• 文件首頁：https://opensearch.org/docs/latest/search-plugins/neural-sparse-search/
• 專案Github 網址：https://github.com/opensearch-project/neural- search

技術亮點

稀疏編碼與原生Lucene 索引語的而查詢文字都會被語言編碼模型轉換為一個高維度空間中的向量。例如 Sentence-BERT 中的 TASB 模型會產生 768 維的向量，All-MiniLM-L6 則會將文字轉換為 384 維的向量。這一類高維度向量的索引需要用到特殊的k-NN 搜尋引擎，例如最早基於樹結構的FLANN、基於雜湊的LSH、還有後來出現基於鄰近圖與跳表的HNSW 以及最新基於量化的FAISS 引擎。

而稀疏編碼（Sparse Encoding）則會將文字轉換為一組 token 與權值的組合。這裡的 token 是語言編碼模型採用分割器切割文字後產生的文字單元。例如使用 WordPiece 分割器，token 可以在一定程度上理解為“單字”，但也會出現單字過長而被切分為兩個 token 的情況。

                               稀疏編碼上與稠密編碼對比

吧

吧OpenSearch 中可以採用原生的Lucene 索引去儲存文檔稀疏編碼。相較於 k-NN 搜尋引擎，原生的 Luence 引擎會更加輕便，佔用的資源也較少。 下表展示了採用 Lucene 進行文本匹配，採用 k-NN 引擎存儲稠密編碼以及採用 Lucene 存儲稀疏編碼的磁碟消耗以及運行時內存（runtime RAM）消耗的比較。

                             *整個系統中對點上使用OpenSearch 時的記憶體，包括JVM 的堆疊內部和外部記憶體

根據BEIR 文章中提及的，由於目前絕大部分的稠密編碼模型都是基於MSMARCO 資料集上精調（fine-tune）得到，模型在該資料集上表現非常優越。然而在其他的 BEIR 的資料集上進行 zero-shot 的測試時，稠密編碼模型在大約有 60%～70% 的資料集上的相關性無法超越 BM25。這一點也可以從我們自己復現的對比實驗中間看出（見下表）。

                              部分中對中幾個方法的相關性表現比較中發現的相關性表現相匹配

。雖然目前還沒有更詳細的量化資料來印證，但根據在部分樣本上的分析，其優勢主要在兩點：1）稀疏編碼在近義詞的聯想方面更加突出，2）在遇到完全陌生的文本表述，例如一些專業術語，稀疏編碼會更傾向於增強這些術語token 的權值而弱化聯想出的token 的權值，使得檢索過程向關鍵字匹配退化，追求的一個穩定的相關性表現。

在 BEIR 基準上的實驗中我們可以看到，Neural Sparse 的兩個方法相較於稠密編碼模型以及 BM25，相關性得分更高。

極致速度：僅文檔編碼模式

Neural Search 同時提供了一種能夠提供極致線上檢索速度的模式。在這種模式下，僅有待檢索的文件會進行稀疏編碼。相反，在線上檢索的過程中，查詢文字並不會呼叫語言編碼模型進行編碼。而僅使用分割器（tokenizer）對查詢文字進行分割。由於省去了深度學習模型的呼叫過程，不但大幅降低了線上檢索的時延，也節省了模型推理所需的大量運算資源，例如 GPU 算力等。

下表比較了文本匹配檢索方法BM25、稠密編碼檢索BERT-TASB 模型、稀疏編碼檢索帶查詢編碼bi-encoder 方式以及稀疏編碼檢索僅文檔編碼doc-only 在MSMARCO v2 一百萬量級資料集上的速度比較。我們可以清楚地看到僅文擋編碼模式具有和BM25 相近的速度表現，而且從上一節的表格中我們可以看到僅文檔編碼模式的相關性表現，並沒有與帶查詢稀疏編碼的方法差太多。可以說，僅文檔編碼模式是一個非常具有性價比的選擇。

還要更快：使用兩段式搜尋進行加速

前文中提到，在稀疏編碼的過程中，文本被轉化為一組 token 與權值的組合。這種轉換產生了大量權值較低的 token，這些 token 雖然在搜尋過程中佔用了大部分時間，但對最終搜尋結果的貢獻並不顯著。

因此，我們提出了一種新的搜尋策略，首先在第一次搜尋中過濾掉這些低權值 token，僅依賴高權值 token 來定位排名較高的文件。隨後在這些精選的文檔上，重新引入先前被過濾的低權值 token 進行第二次詳細評分，從而獲取最終得分。

透過這種方法，我們顯著減少了兩部分的延時：首先，在第一階段搜尋中，僅透過高權值token 在倒排索引中進行匹配，大幅減少了不必要的計算時間。其次，在精確的小範圍結果文件內再次評分時，我們僅對具有潛在相關性的文檔計算低權值 token 的分數，進一步優化了處理時間。

最終，這種改進的方法在僅文檔編碼模式（doc-only）上實現了與BM25 搜索接近的延時表現，在帶查詢編碼模式(bi-encoder) 上則加快了5到8 倍，大大提升了Neural Search 的延時表現和吞吐量。以下是在四個典型BEIR 資料集上標準neural sparse、兩階段neural sparse、BM25 的延遲比較：

              用5 步在OpenSearch 中搭建Neural Sparse語意檢索應用

1. 設定啟用Neural Search

首先設定叢集配置來讓模型可以在本地叢集上運行。

PUT /_cluster/settings{"transient" : {"plugins.ml_commons.allow_registering_model_via_url" : true,"plugins.ml_commons.only_run_on_ml_node" : false,"plugins.ml_commons.native_memory_threshold" : 99}}

2. 部署編碼器

Opensearch 目前開源了 3 個模型。相關註冊資訊都可以在官方文件中取得。我們以amazon/neural-sparse/opensearch-neural-sparse-encoding-v1 為例，首先使用register API 來註冊：

POST /_plugins/_ml/models/_register?deploy=true{    "name": "amazon/neural-sparse/opensearch-neural-sparse-encoding-v1",    "version": "1.0.1",    "model_format": "TORCH_SCRIPT"}

在集群的返回中，可以看到task_id

{"task_id": "<task_id>","status": "CREATED"}

在集群的返回中，可以看到task_id

GET /_plugins/_ml/tasks/

詳細的註冊資訊：

{"model_id": "<model_id>","task_type": "REGISTER_MODEL","function_name": "SPARSE_TOKENIZE","state": "COMPLETED","worker_node": ["wubXZX7xTIC7RW2z8nzhzw"],    "create_time":1701390988405,"last_update_time": 1701390993724,"is_async": true}

在API 回傳中，我們可以拿到具體的model_id:

PUT /_ingest/pipeline/neural-sparse-pipeline{  "description": "An example neural sparse encoding pipeline",  "processors" : [    {      "sparse_encoding": {        "model_id": "<model_id>",        "field_map": {           "passage_text": "passage_embedding"        }      }    }  ]}

3. 設定預處理管

3. 設定預處理管被編碼的文字欄位需要被轉變成稀疏向量。在 OpenSearch 中，這個過程是透過預處理器來自動實現的。你可以使用以下API 來建立離線索引時的處理器管線：

PUT /_search/pipeline/two_phase_search_pipeline{  "request_processors": [    {      "neural_sparse_two_phase_processor": {        "tag": "neural-sparse",        "description": "This processor is making two-phase processor."      }    }  ]}

如果需要開啟兩階段加速功能(非必需功能)，則需要建立一個兩階段搜尋管線，並在索引建立之後設定為默認的搜尋管線。

建立一個預設參數的兩階段加速搜尋管線方式如下，更詳細的參數設定和意義請參考 2.15 及以後版本的 OpenSearch 官方文件。

PUT /my-neural-sparse-index{  "settings": {    "ingest":{        "default_pipeline":"neural-sparse-pipeline"    },    "search":{        "default_pipeline":"two_phase_search_pipeline"    }  },  "mappings": {    "properties": {      "passage_embedding": {        "type": "rank_features"      },      "passage_text": {        "type": "text"      }    }  }}

4. 設定索引

🎜

神经稀疏搜索利用 rank_features 字段类型来存储编码得到的词元和相对应的权重。索引将使用上述预处理器来编码文本。我们可以按以下方式创建索一个包含两阶段搜索加速管线的索引（如果不想开启此功能，可把 `two_phase_search_pipeline` 替换为 `_none` 或删除 `settings.search` 这一配置单元）。

PUT /my-neural-sparse-index{  "settings": {    "ingest":{        "default_pipeline":"neural-sparse-pipeline"    },    "search":{        "default_pipeline":"two_phase_search_pipeline"    }  },  "mappings": {    "properties": {      "passage_embedding": {        "type": "rank_features"      },      "passage_text": {        "type": "text"      }    }  }}

5. 使用预处理器导入文档并搜索

在设置索引之后，客户可以提交文档。客户提供文本字段，而摄取进程将自动将文本内容转换为稀疏向量，并根据预处理器中的字段映射 field_map 将其放入 rank_features 字段：

PUT /my-neural-sparse-index/_doc/{   "passage_text": "Hello world"}

在索引中进行稀疏语义搜索的接口如下，将 替换为第二步中注册的 model_id：

GET my-neural-sparse-index/_search{  "query":{    "neural_sparse":{      "passage_embedding":{        "query_text": "Hi world",        "model_id": <model_id>      }    }  }}

关于 OpenSearch

OpenSearch 是一种分布式、由社区驱动并取得 Apache 2.0 许可的 100% 开源搜索和分析套件，可用于一组广泛的使用案例，如实时应用程序监控、日志分析和网站搜索。OpenSearch 提供了一个高度可扩展的系统，通过集成的可视化工具 OpenSearch 控制面板为大量数据提供快速访问和响应，使用户可以轻松地探索他们的数据。

OpenSearch 由 Apache Lucene 搜索库提供技术支持，它支持一系列搜索及分析功能，如 k - 最近邻（KNN）搜索、SQL、异常检测、Machine Learning Commons、Trace Analytics、全文搜索等。

以上是亞馬遜雲端創新「神經稀疏檢索」：只需要文字匹配就能實現語意搜索的詳細內容。更多資訊請關注PHP中文網其他相關文章！