本文作者：清豆 — 阿里巴巴高级开发工程师
本文字数：2979
阅读时间：3~6分钟
您将了解：
1、开源向量检索库存在的问题
2、源自阿里Proxima向量检索库的优势
3、阿里云向量检索的技术原理
4、阿里云向量检索的应用场景
5、如何使用阿里云向量检索
【全链路云上Elastic Stack 全景图】100%兼容开源，9大独有能力
----> 直播回顾 | 请点击观看 ：阿里云Elasticsearch向量检索介绍
寻根问源
（图一：开源向量检索库面临的问题）
我们知道，市面上有不少开源向量检索库供大家选择使用，例如 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 交互的方式相媲美
优势介绍
（图二：阿里云向量检索优势）
1、以阿里云 Elasticsearch 插件的形式使用，一键安装。同时由于封装了阿里巴巴达摩院自研的 Proxima 高性能向量检索库。该向量检索库已经应用于阿里集团多个大规模核心生产业务，性能和稳定性都历经了多年考验。
2、基于 Lucene code-c 机制无缝扩展了向量的索引，阿里云 Elasticsearch 分布式容灾能力都与原生 Elasticsearch 完美兼容，支持Failover，横向弹性扩展、快照恢复等容灾能力。
3、基于在线引擎的方案，与原生 Elasticsearch 的NRT近实时机制相同，在线的向量增量数据写入阿里云 Elasticsearch 后，只需Refresh即可查到，最快能够做到秒级的可见性延迟。
4、封装了与原生 Elasticsearch DSL 协议一直的向量 QueryBuilder，阿里云 Elasticsearch 用户无需任何额外的学习成本即可快速上手向量检索引擎。
实现原理
（图三：技术原理）
方案的核心是运用 Lucene code—c机制。codec 是索引数据结构的抽象接口，可以自定义倒排/正排等索引；Lucene具体的工作流程是：当refresh刷出segment时，调用自定义 Proxima 的 Code-C，按照segment的力度，构建向量索引，即达摩院的向量索引。在查询时，按照 segment 维度，返回向量检索库 Proxima 找到的文档和分数即可，之后上传阿里云 Elasticsearch，并做全局打分的排序、召回的工作。
（图四：测试数据）
这里是一些测试的数据，我们可以看到，基于 hnsw 算法的向量检索插件，召回率和延迟都比较理想，实现98%的召回率和几十毫秒的延迟。
场景应用
（图五：达摩院向量检索引擎在阿里体系的业务）
图五例举了部分达摩院向量检索库在阿里体系的业务应用。在图像搜索应用领域，可以运用在拍立淘、图搜云、阿里妈妈反作弊等。推荐场景应用到了首页的猜你喜欢、推荐、广告检索，虾米音乐、飞猪等核心业务，同时还包括语言、视频之类，同时在天猫精灵、优酷核心场景均有落地。
（图六：向量检索应用领域）
典型场景一“人脸识别”
向量检索的典型应用之一就是人脸识别。这个场景是比较简单且好理解的，比如我们的刷脸支付，由于原始数据量不会特别大，但却对召回的准确率和延迟都有非常高的要求。因为我们不会希望，别人刷了脸从我的账户里扣钱。
除了刷脸支付，在安全监控场景也有运用，比如我们专有云客户，他们会用阿里云 Elasticsearch 向量检索引擎，来做路口交通的监控系统，通过一些具体的时段、路段标签字段作为一个协同，并根据人脸信息、车辆信息，抽取特征做向量字段，这些字段联合起来做查询，监测异常出现的轨迹。
典型场景二“商品推荐”
在商品推荐场景中，比如经常看到的淘宝“猜你喜欢”。大家都知道要做到个性化的商品推荐，用户的行为历史、画像、Query 的特征，都是非常重要的一项参数，这些特征我们都可以做 Rebuilding，作为表征用户特征的向量。然后结合用户向量表征数据与商品侧召回的向量，利用一个近似距离的计算，我们就知道这个物品与用户特征之间，他们的相似度是怎么样的，那我就可以通过这个相似度的排序，作为商品的推荐的重要参考标准。
对于一些比较长尾的 Query，如果按照传统的倒排和字典的方式，可能无法特别准确的召回文档，甚至可能出现没有结果的情况。这类情况下，向量检索就可以派上用场。比如当我们搜索“日式煎茶”这个物品时，通过精确查询召回的商品会特别的少，甚至可能召回一个完全不同的类目，比如召回“日式煎饼”。
当我们通过提前抽取商品特征以及 Query 特征，来做向量的近似召回就不同了。由于我们抽取了这些特征，所以我在搜索“日式煎茶”的时候，如果精确查询没有结果，我们也可以召回像“日式抹茶”、“日式清茶”这种实际特征相似的商品，作为补充召回的功能。不仅可以提升商品的曝光量，同时提升用户的使用体验。
典型场景三“智能助理”
在“智能助理”应用场景中，如天猫精灵这种智能音箱，亦或是淘宝的客服系统 — 阿里小蜜这种智能文本客服，这类对话的场景对反馈延迟的要求非常高，并且数据量较少。如果做一些 Query 类目、情感等标签，以及多入口知识库召回，那可能匹配的知识项就非常多了。那么到精排阶段，我们向量检索就可以派上用场，通过精排阶段在向量检索库打分的时候，可以按照近期热点问题、近期促销活动等方式，通过向量近似计算，做到快速打分排序，返回给用户最精准的结果。
所以向量检索应用场景还是非常多的，只要业务上有近似需求，那我们都可以用向量检索的方案来做。
实操—快速运用向量检索
一、安装aliyun-knn插件
（图七：阿里云 Elasticsearch 控制台）
我们可以登录阿里云Elasticsearch控制台页面，向量检索是以插件的形式来提供服务的，从【插件配置】Tab进入后，找到Aliyun-Knn（向量检索）安装即可。他是作为系统的默认插件存在，需要手动安装后使用，目前支持阿里云Elasticsearch 6.7、7.4版本，测试仅需2核8G就可以测试，实际线上生产，我们建议4核16G以上节点来安装。
二、创建索引
（图八：创建索引）
与原生索引一致，图八中是一个 test 索引，除了传统的副本数、shard数以外，还有一个 proxima code-c 的 setting，这个是必须要加的。
在 mapping 的地方，由于 proxima 向量索引是字段，比如图中向量字段叫“feature”，那么我们需要加上feature的properties，“type”就是“proxima_vector”，这个就是指定 proxima 的向量字段，图八中指定了维度为“2”的向量字段，另外增加了一个字段ID,是keyword，演示的时候会用到。
三、添加文档
（图九：添加文档）
添加文档与原生一样，图九中共写了3个文档，第一个文档ID为“1”，向量是【1,2】；后两个文档都是ID为“2”，而feature为【3,4】、【5,6】，也就是ID为“1”的字段，ID为“2”的字段有2个。
四、近似查询
（图十：近似查询）
做近似查询时，我们可以看到 “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首月免费
