前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >从零开始了解语义搜索中的嵌入模型

从零开始了解语义搜索中的嵌入模型

原创
作者头像
点火三周
发布2023-08-25 15:55:32
3.4K0
发布2023-08-25 15:55:32
举报
文章被收录于专栏:Elastic Stack专栏

实现语义搜索的挑战

正如大多数矢量搜索供应商所宣传的那样,语义搜索系统的基本设计有两个简单的(这很讽刺) 步骤:

  1. 计算文档和查询的嵌入。某处。不知何故。你自己想办法吧。
  2. 将它们上传到矢量搜索引擎并享受更好的语义搜索。

良好的嵌入模型对于语义搜索至关重要
良好的嵌入模型对于语义搜索至关重要

您的语义搜索的最终效果取决于您的嵌入模型。但选择模型通常被认为超出了大多数早期采用者的能力范围。所以大家一上来就选择 sentence-transformers/all-MiniLM-L6-v2,并希望得到最好的结果。

然而,这种方法存在的问题要比它所提供的答案还要多:

  • 嵌入模型之间有区别吗?OpenAI 和 Cohere 的付费模型是否更好?
  • 他们如何处理多种语言?参数超过10亿的模型是否更有优势吗?
  • 使用嵌入的密集检索是许多语义搜索方法之一。它比 SPLADEv2ELSER 这样的新时代稀疏方法更好吗?

Transformer:所有LLM的祖先

最初的 Transformer 架构可以看作是一个将输入文本转换为输出文本的黑盒子。但神经网络本身并不理解文本,它们只懂数字——所有内部的转换都是数字形式的。

Transformer 由两个主要模块组成:

  1. 编码器:接受以数字形式呈现的文本输入,并生成输入语义含义的嵌入表示。
  2. 解码器:反转这个过程,接受嵌入表示,并预测下一个文本标记

原始 Transformer 架构的编码器和解码器部分
原始 Transformer 架构的编码器和解码器部分

因此,在编码器和解码器之间,有一个输入的嵌入表示。输入和嵌入都是数值向量,但它们之间仍然存在显着差异:

  • 输入向量只是来自预定义字典的术语标识符序列(对于 BERT,词汇表大小为 32K),并填充到固定长度。
  • 嵌入向量是输入的内部表示。这就是网络如何看待您的输入。您可能期望相似的文档将具有相似的内部表示
中间的嵌入是神经网络如何看待你的输入。解码器的输出被简化了——它发出下一个标记的概率,而不是整个短语
中间的嵌入是神经网络如何看待你的输入。解码器的输出被简化了——它发出下一个标记的概率,而不是整个短语

几年后,出现不少充满活力的基于 transformer 的不同文本处理模型系列,有两个主要的独立分支:

  • 类似BERT,仅使用 transformer 的编码器部分。擅长分类、概括和实体识别。
  • GPT 系列,仅限解码器。擅长翻译和质量保证等生成任务。

transformer 家族谱
transformer 家族谱

在上图中,您可以看到 BERT 和 GPT 模型子系列之间的划分。传统上,BERT 后代最常用于语义搜索领域

BERT模型

BERT 模型似乎非常适合我们的语义搜索问题,因为它可以简化为特定查询的相关和不相关文档的二元分类任务。

但 BERT 嵌入最初并不是为了语义相似性:该模型被训练来预测大型文本语料库上的屏蔽词。事实上,相似的文本具有相似的嵌入,这是一个很好的自然产生的副作用。

BERT 的预训练是在 masked token 预测任务上完成的
BERT 的预训练是在 masked token 预测任务上完成的

但“最初并不是为了语义相似”只是一种观点。有没有办法客观地衡量参考数据集的好坏?

BEIR 基准

学术论文 “ BEIR:信息检索模型零样本评估的异构基准” 提出了 IR 方法的基准和数据集的参考集。并且使模型质量之争变得不再那么有趣:现在有一个排行榜可以将您的嵌入模型与竞争对手进行比较。

衡量相关性的方法有太多
衡量相关性的方法有太多

BEIR 基准提出了一组 19 个不同的 IR 数据集和用于搜索质量评估的所有机制。

原始论文还在整个数据集上对几种基线方法进行了基准测试。2021年得出的主要结论是BM25是一个经久不衰的技术和一个强大的基线。

后来 BEIR 被合并到一个更广泛的基准套件中:MTEB,大规模文本嵌入基准。运行它非常简单(如果您有 128GB RAM、现代 GPU 和 8 小时的空闲时间):

代码语言:python
代码运行次数:0
复制
from mteb import MTEB
from sentence_transformers import SentenceTransformer

# load the model
model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")

# run a subset of all benchmarks
evaluation = MTEB(tasks=["MSMARCO"])
results = evaluation.run(model, output_folder="results")

就像我们之前聊过的,咱们回到论文的中心思想,“原始的BERT嵌入不能用于语义搜索”。如果我们将 bert-base-uncased(一种语言模型)和顶尖的句子转换模型 all-MiniLM-L6-v2 以及 all-mpnet-base-v2 放在一起,用BEIR/MTEB基准来测试,我们会得到下面这些数字:

从这张表中我们可以得出两个明显的结论:

  • 最初的原始BERT 嵌入是为了下一个单词预测而设计的,并不是用于语义搜索和文档相似性。现在你可以明白为什么了。
  • BM25 仍然是一个强大的基线——即使是针对语义相似性进行调整的大规模 MPNET 模型也无法始终胜过它

但是为什么相似的嵌入模型在语义搜索任务中表现会有如此大的不同呢?

排行榜

当前(2023 年 6 月)的 MTEB/BEIR 基准排行榜看起来充满了不知名的名字:

SBERT 模型在 BEIR 任务集上排名第 18 位以上
SBERT 模型在 BEIR 任务集上排名第 18 位以上

我们可以通过以下方式总结当前最先进的语义搜索:

  • SBERT 模型(all-MiniLM-L6-v2、all-MiniLM-L12-v2 和 all-mpnet-base-v2)在简单性和排名质量之间取得了良好的平衡。
  • SGPT (5.8B、2.7B、1.3B)是LoRa微调的开源 GPT-NeoX 排名模型的最新版本
  • GTR-T5是 Google 用于语义搜索的开源嵌入模型,使用 T5 LLM 作为基础。
  • E5(v1 和 v2)是 Microsoft 最新的嵌入模型。

我们可以通过构建语义搜索模型的两种哲学的棱镜来看待这四个模型系列:

  • 性能。模型越小,搜索延迟越低,索引速度越快。巨大的 SGPT GTR 模型只能在昂贵的 GPU 上运行。
  • 尺寸。模型中的参数数量越多,检索质量就越好。all-MiniLM-L6-v2 是一个很棒的模型,但它太小,无法用 10M 参数捕获搜索中的所有语义差异。

在大小和性能之间找到平衡对于构建出色的嵌入模型至关重要。

嵌入与稀疏检索

嵌入是进行搜索的多种方式之一。旧的 BM25 仍然是一个强大的基线,并且有一些新的“稀疏”检索方法,例如 SPLADEv2 和 ColBERT - 结合了分词术语搜索和神经网络的优势。

在下面的表格中,我们试图汇总所有公开可得的BEIR分数,这些分数来自以下几个来源:

如果将此表与两年前发布的 BEIR 表进行比较,您可能会注意到 BM25 被认为是一个强大的基线 - 但BM25 在 2023 年不再是明显的赢家

另一个观察结果是稀疏(例如,ELSER 和 SPLADEv2)和密集(E5)检索方法在质量上非常接近。因此,这个领域没有明显的赢家,但看到如此多的竞争是很棒的。

作者对稀疏与密集检索方法争论的个人看法:

  • 密集检索更加面向未来。从 SBERT 升级到 E5 只需 10 行代码,检索质量大幅提高。而且您的矢量搜索引擎保持不变,无需额外的工程。
  • 稀疏检索产生的幻觉较少,并且可以处理精确匹配和关键字匹配。NDCG@10 并不是衡量搜索质量的唯一标准。

从 OpenAI 的角度来看,爱与恨之间只有 0.08 点的差异
从 OpenAI 的角度来看,爱与恨之间只有 0.08 点的差异

但争论仍在继续,我们将随时向您通报最新动态。

大型模型的隐性成本

人们普遍认为模型越大,其检索质量就越好。从 MTEB 排行榜上可以清楚地看到这一点,但它忽略了服务这些模型的简单性和廉价性这一重要且实用的特征。

嵌入模型应该同时在线和离线提供
嵌入模型应该同时在线和离线提供

实际上,您需要运行嵌入模型两次:

  • 索引阶段处于离线状态。这是一个批处理作业,需要高吞吐量,但对延迟不敏感。
  • 在每个搜索请求上在线嵌入搜索查询

像 SBERT 和 E5 这样的小型模型可以在合理的延迟预算内轻松地在 CPU 上运行,但如果参数超过 500M(SGPT 的情况),则无法避免使用 GPU。如今 GPU 价格昂贵。

为了查看真实的延迟数字,我们在 https://github.com/shuttie/embed-benchmark 上提供了一个基于 JMH 的小型 ONNX 推理基准:

SBERT/E5 模型不同文档长度的 ONNX 推理延迟(以毫秒为单位)。CPU:16核Ryzen7/2600。显卡:RTX3060Ti
SBERT/E5 模型不同文档长度的 ONNX 推理延迟(以毫秒为单位)。CPU:16核Ryzen7/2600。显卡:RTX3060Ti

从表中可以看出:

  • CPU 和 GPU 上的参数数量和延迟之间存在线性依赖关系。对于简短的 4 字查询,像 SGPT-1.3B 这样的大型模型预计延迟为200 毫秒,这对于面向客户的工作负载来说通常太多了。
  • 存在延迟/成本/质量权衡。您的语义搜索快速、廉价、精确 —— 无法三者兼得,你只能选择其中两个

多语言模型

世界不仅用英语说话,而且大多数模型和评估框架都只关注英语:

  • 原始的 BERT 词汇主要是在英语数据上训练的,在其他语言上的训练相当薄弱。
  • 几乎所有的嵌入模型都是在英文文本语料库上训练的,因此它们都稍微偏向于英语文本语料库。

如果您向 BERT 分词器提供非英语文本,就会发生这种情况:

代码语言:python
代码运行次数:0
复制
from transformers import BertTokenizer, AutoTokenizer

bert = BertTokenizer.from_pretrained("bert-base-uncased")
e5 = AutoTokenizer.from_pretrained('intfloat/multilingual-e5-base')

en = bert.encode("There is not only English language")
print(bert.convert_ids_to_tokens(en))
# ['[CLS]', 'there', 'is', 'not', 'only', 'english', 'language', '[SEP]']

de = bert.encode("Es gibt nicht nur die englische Sprache")
print(bert.convert_ids_to_tokens(de))
# ['[CLS]', 'es', 'gi', '##bt', 'nic', '##ht', 'nur', 'die', 'eng', '##lis', '##che', 'sp', '##rac', '##he', '[SEP]']

de2 = e5.encode("Es gibt nicht nur die englische Sprache")
print(e5.convert_ids_to_tokens(de2))
# ['<s>', '▁Es', '▁gibt', '▁nicht', '▁nur', '▁die', '▁englische', '▁Sprache', '</s>']

BERT 分词器无法将德语单词作为单独的标记正确处理,必须将其拆分为子词。相比之下,多语言 XLM 分词器处理同一个句子要好得多。

幸运的是,本文中提到的大多数模型都有可用的多语言版本:

总结

总结一下,本文的主要结论如下:

  • BM25在搜索质量方面并不容易被超越。考虑到它需要零调整,并且您可以在 3 分钟内生成一个 Elasticsearch 集群 - 在 2023 年依赖它仍然是可行的。
  • 最近在稀疏和密集世界的检索领域发生了很多进展。SGPT和E5的历史还不到1年,SPLADE和 ELSER 的历史更年轻。
  • 稀疏/密集方法之间没有单一的赢家,但 IR 行业融合到一个基准测试工具中,通过 MTEB/BEIR 套件来衡量检索质量。

本文来源:https://blog.metarank.ai/from-zero-to-semantic-search-embedding-model-592e16d94b61

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 实现语义搜索的挑战
  • Transformer:所有LLM的祖先
  • BERT模型
  • BEIR 基准
  • 排行榜
  • 嵌入与稀疏检索
  • 大型模型的隐性成本
  • 多语言模型
    • 总结
    相关产品与服务
    Elasticsearch Service
    腾讯云 Elasticsearch Service(ES)是云端全托管海量数据检索分析服务,拥有高性能自研内核,集成X-Pack。ES 支持通过自治索引、存算分离、集群巡检等特性轻松管理集群,也支持免运维、自动弹性、按需使用的 Serverless 模式。使用 ES 您可以高效构建信息检索、日志分析、运维监控等服务,它独特的向量检索还可助您构建基于语义、图像的AI深度应用。
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档