亚马逊云创新「神经稀疏检索」：语义搜索只能通过文本匹配来实现——人工智能

首页 2024-07-01 22:13:42

AIxiv专栏是本网站发布学术技术内容的专栏。在过去的几年里，AIxiv专栏收到了2000多篇报道，覆盖了世界各大高校和企业的顶级实验室，有效地促进了学术交流和传播。如果您有优秀的工作要分享，请提交或联系报告。投稿邮箱：liyazhou@jiqizhixin.com；zhaoyunfeng@jiqizhixin.com

作者来自这篇文章 opensearch 中国研发团队机器学习负责人杨洋博士、机器学习工程师耿志超、关聪。opensearch 这是一个纯开源搜索和实时分析引擎项目，由亚马逊云科技发起。现在的软件已经超过了 5 1亿下载量，社区在全球拥有 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 索引结合

当前语义检索的主要方法来自于密集编码（Dense Encoding），要检索的文档和查询文本将被语言编码模型转换为高维空间中的向量。例如 Sentence-BERT 中的 TASB 模型会生成 768 维的向量，All-MiniLM-L6 将文本转换为文本 384 维的向量。这种高维向量索引需要特殊使用 k-NN 比如最早基于树结构的搜索引擎， FLANN、基于哈希的 LSH、后来，基于相邻图片和跳表的出现 HNSW 以及基于量化的最新 FAISS 引擎。

而稀疏编码（Sparse Encoding）然后将文本转换为一组文本 token 与权值的结合。这里的 token 它是用分割器切割文本后产生的语言编码模型的文本单元。例如使用 WordPiece 分割器，token 在一定程度上可以理解为「单词」，但也会有过长的单词被分成两个 token 的情况。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?稀疏编码与稠密编码的对比

稀疏编码产生的稀疏编码 token - 与传统文本匹配方法采用的权值组合 term-vector 非常相似，所以在 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 对比100万量级数据集上的速度。我们可以清楚地看到，只有文档编码模式有和谐 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 获取详细的注册信息：

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

3. 设置预处理管道

在索引之前，需要编码的文本字段需要将每个文档转换为稀疏向量。 OpenSearch 这个过程是通过预处理器自动实现的。您可以使用以下内容 API 创建离线索引时的处理器管道：

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"? ? ? ? }? ? ? }? ? }? ]}

如果需要打开两阶段加速功能，则需要打开加速功能 (非必要功能)需要建立两个阶段的搜索管道，并在索引建立后设置为默认的搜索管道。

建立默认参数的两个阶段加速搜索管道的方法如下。请参考更详细的参数设置和意义 2.15 以后版本 OpenSearch 官方文档。

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."? ? ? }? ? }? ]}

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、全文搜索等。

以上是亚马逊云创新「神经稀疏检索」：语义搜索的详细内容只需要文本匹配，请多关注其他相关文章！

阅读全文

亚马逊云创新「神经稀疏检索」：语义搜索只能通过文本匹配来实现——人工智能

首页 2024-07-01 22:13:42

最新文章

相关文章