阿里云 Elasticsearch 向量检索,轻松玩转人脸识别、搜索推荐等29个业务场景-阿里云开发者社区

开发者社区> Elasticsearch 技术团队> 正文

阿里云 Elasticsearch 向量检索,轻松玩转人脸识别、搜索推荐等29个业务场景

简介: 简介:我们知道,市面上有不少开源的向量检索库供大家选择使用,例如 Facebook 推出的 Faiss 以及 Nswlib,虽然选择较多,但业务上需要用到向量检索时,依旧要面对四大共性问题。

本文作者:清豆 — 阿里巴巴高级开发工程师

本文字数:2979
阅读时间:3~6分钟

您将了解:
1、开源向量检索库存在的问题
2、源自阿里Proxima向量检索库的优势
3、阿里云向量检索的技术原理
4、阿里云向量检索的应用场景
5、如何使用阿里云向量检索

image.png

【全链路云上Elastic Stack 全景图】100%兼容开源,9大独有能力

----> 直播回顾 | 请点击观看 :阿里云Elasticsearch向量检索介绍

寻根问源


image.png

(图一:开源向量检索库面临的问题)

我们知道,市面上有不少开源向量检索库供大家选择使用,例如 Facebook 推出的 Faiss 以及 Nswlib,虽然选择较多,但当业务上需要用到向量检索时,依旧要面对四大共性问题。

1、离线方案,增量不可查

市面上大多向量检索库都是对增量数据不友好,有的需要做一次性全量数据来构建索引,有的需要用户接受很少的增量数据,才能保证检索准确率。在业务随时都有实时增量数据的情况下,每次都要重建全量,并利用线上低峰期来切换最新的全量索引。比如在每天晚上12点,我们做一次最新的全量索引,那么你只能查到前一天的增量数据。

2、无 Failover 及分布式能力

由于市面上的向量索引库,往往不会考虑分布式场景的使用问题。在索引落盘前,任何一步出现机器故障,比如进程宕机,都会导致索引完全丢失并重新创建一遍。而且随着我们的业务增长数据越来越多,需要使用分布式来做索引构建,是无法然由这些库来满足。

3、性能弱

对 Elasticsearch 熟悉的同学会知道,X-pack 在 7.x 推出了 dense-vector 的向量检索字段,但对于前两个问题依旧没有解决,在我们实际测试中发现,dense-vector 这个字段,或者说向量检索,是基于线性暴力计算来实现的,基本原理是对每个文档,计算与你 query 的相似度,延时随着数据量增长而成正比例函数关系,在实测2KW的向量数据时,dense-vector 召回时间在 10s 左右。那么在用 X-pack 的向量字段做人脸识别时,对于10秒的响应时间,相信大家是无法接受的。

4、额外学习成本

由于大多向量检索库是运用 C++ 来实现的,有些也提供了 Python 的接口。二 C++ 的学习成本大家知道,且非常难上手,而且这种重客户端的模式不管是灵活性还是可维护性,都没有办法跟 REST API 交互的方式相媲美

优势介绍


image.png

(图二:阿里云向量检索优势)

1、以阿里云 Elasticsearch 插件的形式使用,一键安装。同时由于封装了阿里巴巴达摩院自研的 Proxima 高性能向量检索库。该向量检索库已经应用于阿里集团多个大规模核心生产业务,性能和稳定性都历经了多年考验。

2、基于 Lucene code-c 机制无缝扩展了向量的索引,阿里云 Elasticsearch 分布式容灾能力都与原生 Elasticsearch 完美兼容,支持Failover,横向弹性扩展、快照恢复等容灾能力。

3、基于在线引擎的方案,与原生 Elasticsearch 的NRT近实时机制相同,在线的向量增量数据写入阿里云 Elasticsearch 后,只需Refresh即可查到,最快能够做到秒级的可见性延迟。

4、封装了与原生 Elasticsearch DSL 协议一直的向量 QueryBuilder,阿里云 Elasticsearch 用户无需任何额外的学习成本即可快速上手向量检索引擎。

实现原理


image.png

(图三:技术原理)

方案的核心是运用 Lucene code—c机制。codec 是索引数据结构的抽象接口,可以自定义倒排/正排等索引;Lucene具体的工作流程是:当refresh刷出segment时,调用自定义 Proxima 的 Code-C,按照segment的力度,构建向量索引,即达摩院的向量索引。在查询时,按照 segment 维度,返回向量检索库 Proxima 找到的文档和分数即可,之后上传阿里云 Elasticsearch,并做全局打分的排序、召回的工作。

image.png

(图四:测试数据)

这里是一些测试的数据,我们可以看到,基于 hnsw 算法的向量检索插件,召回率和延迟都比较理想,实现98%的召回率和几十毫秒的延迟。

场景应用


image.png

(图五:达摩院向量检索引擎在阿里体系的业务)

图五例举了部分达摩院向量检索库在阿里体系的业务应用。在图像搜索应用领域,可以运用在拍立淘、图搜云、阿里妈妈反作弊等。推荐场景应用到了首页的猜你喜欢、推荐、广告检索,虾米音乐、飞猪等核心业务,同时还包括语言、视频之类,同时在天猫精灵、优酷核心场景均有落地。

image.png

(图六:向量检索应用领域)

典型场景一“人脸识别”

向量检索的典型应用之一就是人脸识别。这个场景是比较简单且好理解的,比如我们的刷脸支付,由于原始数据量不会特别大,但却对召回的准确率和延迟都有非常高的要求。因为我们不会希望,别人刷了脸从我的账户里扣钱。

除了刷脸支付,在安全监控场景也有运用,比如我们专有云客户,他们会用阿里云 Elasticsearch 向量检索引擎,来做路口交通的监控系统,通过一些具体的时段、路段标签字段作为一个协同,并根据人脸信息、车辆信息,抽取特征做向量字段,这些字段联合起来做查询,监测异常出现的轨迹。

典型场景二“商品推荐”

在商品推荐场景中,比如经常看到的淘宝“猜你喜欢”。大家都知道要做到个性化的商品推荐,用户的行为历史、画像、Query 的特征,都是非常重要的一项参数,这些特征我们都可以做 Rebuilding,作为表征用户特征的向量。然后结合用户向量表征数据与商品侧召回的向量,利用一个近似距离的计算,我们就知道这个物品与用户特征之间,他们的相似度是怎么样的,那我就可以通过这个相似度的排序,作为商品的推荐的重要参考标准。

对于一些比较长尾的 Query,如果按照传统的倒排和字典的方式,可能无法特别准确的召回文档,甚至可能出现没有结果的情况。这类情况下,向量检索就可以派上用场。比如当我们搜索“日式煎茶”这个物品时,通过精确查询召回的商品会特别的少,甚至可能召回一个完全不同的类目,比如召回“日式煎饼”。

当我们通过提前抽取商品特征以及 Query 特征,来做向量的近似召回就不同了。由于我们抽取了这些特征,所以我在搜索“日式煎茶”的时候,如果精确查询没有结果,我们也可以召回像“日式抹茶”、“日式清茶”这种实际特征相似的商品,作为补充召回的功能。不仅可以提升商品的曝光量,同时提升用户的使用体验。

典型场景三“智能助理”

在“智能助理”应用场景中,如天猫精灵这种智能音箱,亦或是淘宝的客服系统 — 阿里小蜜这种智能文本客服,这类对话的场景对反馈延迟的要求非常高,并且数据量较少。如果做一些 Query 类目、情感等标签,以及多入口知识库召回,那可能匹配的知识项就非常多了。那么到精排阶段,我们向量检索就可以派上用场,通过精排阶段在向量检索库打分的时候,可以按照近期热点问题、近期促销活动等方式,通过向量近似计算,做到快速打分排序,返回给用户最精准的结果。

所以向量检索应用场景还是非常多的,只要业务上有近似需求,那我们都可以用向量检索的方案来做。

实操—快速运用向量检索


一、安装aliyun-knn插件

image.png

(图七:阿里云 Elasticsearch 控制台)

我们可以登录阿里云Elasticsearch控制台页面,向量检索是以插件的形式来提供服务的,从【插件配置】Tab进入后,找到Aliyun-Knn(向量检索)安装即可。他是作为系统的默认插件存在,需要手动安装后使用,目前支持阿里云Elasticsearch 6.7、7.4版本,测试仅需2核8G就可以测试,实际线上生产,我们建议4核16G以上节点来安装。

二、创建索引

image.png

(图八:创建索引)

与原生索引一致,图八中是一个 test 索引,除了传统的副本数、shard数以外,还有一个 proxima code-c 的 setting,这个是必须要加的。

在 mapping 的地方,由于 proxima 向量索引是字段,比如图中向量字段叫“feature”,那么我们需要加上feature的properties,“type”就是“proxima_vector”,这个就是指定 proxima 的向量字段,图八中指定了维度为“2”的向量字段,另外增加了一个字段ID,是keyword,演示的时候会用到。

三、添加文档

image.png

(图九:添加文档)

添加文档与原生一样,图九中共写了3个文档,第一个文档ID为“1”,向量是【1,2】;后两个文档都是ID为“2”,而feature为【3,4】、【5,6】,也就是ID为“1”的字段,ID为“2”的字段有2个。

四、近似查询

image.png

(图十:近似查询)

做近似查询时,我们可以看到 “hnsw” 这个 query,就是我们向量查询的写译。他可以跟其他类型的查询做交并。我们可以看到,向量查询跟term查询是可以放在同一个must,或者同一个 feature ,在这种原生布尔查询里同时协同工作。

如果我们想查特征字段是【5.5,6.5】,ID为“2”的文档时,那根据图八中第三个文档【5,6】,那么这个文档是最相近的查询结果,那么这个文档的打分是最高的,排在第一位。且由于指定ID为“2”,所以我的 feature 生效仅召回了两个文档,另一个就是【3,4】,而ID为“1”的文档没有被召回。

相关活动


更多折扣活动,请访问阿里云 Elasticsearch 官网

• 阿里云 Elasticsearch 商业通用版,1核2G首月免费
阿里云 Elasticsearch 日志增强版,首月六折,年付六折
阿里云 Logstash 2核4G首月免费


image.png

image.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

Elasticsearch 作为一个分布式、高扩展、实时的搜索与数据分析引擎,因其轻量级、稳定、可靠、快速等特性受到越来越多开发者的青睐,在搜索、日志分析、运维监控和安全分析等领域得到广泛应用。

官方博客
友情链接