共计 2744 个字符，预计需要花费 7 分钟才能阅读完成。
作者介绍：
James Zhang，飞书深诺团体的算法工程师，毕业于芬兰坦佩雷大学，感兴趣的方向包含自然语言解决、计算机视觉等机器学习相干畛域以及算法工程化。
飞书深诺团体是专一海内数字营销解决方案的综合服务团体，为中国出海企业提供可定制组合的全链路服务产品，满足游戏、APP、电商、品牌等典型出海场景需要。
Milvus 在电商场景中的千万量级素材搜寻实际
我的项目背景
在服务电商客户的场景下，创意部门经常要为客户制作素材，如：广告图、宣传视频、宣传文案等。创意部门往往通过以图搜图、以视频搜视频、文本搜文本的形式挖掘素材，为设计师们提供创意上的参考。同时，热度、成果值等其余条件也能够用来辅助搜寻，帮忙创意部门充沛抉择适合的素材。此我的项目的动机正是利用 Milvus 向量数据库在内的一系列技术，为创意部门提供一个素材的综合搜寻零碎。
技术选型
因为业务接口须要实时返回，并接受肯定水平的并发负载，因而咱们认为 Milvus 是比拟适合的向量检索工具。它对 FAISS、ANN 等工具进行了封装，建设本人的存储文件构造，同时提供了不便的服务化接口，能够算得上“开箱即用”了。在放弃检索速度快的同时，Milvus 能够通过参数设置，对向量检索的准确性、资源占用做肯定的 Trade-off，比拟适宜在理论工程中应用。
咱们在返回类似向量的同时，还须要图片 / 视频的一些对应信息，咱们通过 KV（Key-Value）的模式将这些信息放在 Redis 缓存里，放慢获取的速度。在 Web 接口封装方面，思考到团队内大部分为 Python 程序员，因而咱们选用了 Nginx + Flask + Gunicorn + supervisor 的 Web 经典套餐。
应用到的各工具和框架
- Milvus（图片 / 视频 / 文本的向量类似检索）
- Redis（业务缓存）
- Nginx（负载平衡）
- Flask + Gunicorn（Web 框架 + 并发服务）
- Supervisor（服务的过程启动与异样主动重启）
- Docker（容器隔离部署）
我的项目实现
在咱们的我的项目中，图片应用 EfficientNet 来提取特征向量；视频通过提取关键帧之后，再将每一帧图片进行向量提取之后叠加；文本采纳 BERT 做特征提取。
架构示意如下图所示：
抉择适合的索引：
在失去图片 / 视频 / 文本向量检索后果后，下层调用还要做一些业务操作，留给向量检索的接口的工夫就不能太多，零碎须要做到 1s 内返回。因为向量检索对速度的要求比拟高，同时服务部署的机器内存又有肯定的限度，咱们选用了 IVF_PQ 作为向量索引。
IVF_PQ 是一种有损压缩的向量索引，它将所有向量分解成 m 段，每一小段别离进行聚类，每小段由所属的聚类核心来示意，称为索引值，用 Codebook（码表）来示意。举例说明这种压缩形式：一个 D=128 维的原始向量被切分成了 M=8 个 D=16 维的短向量，同时每个 16 维短向量都对应一个量化的索引值，索引值即该短向量间隔最近的聚类核心的编号，每一个原始向量就能够压缩成 8 个索引值形成的压缩向量，即每个向量都用这 8 个索引值来示意，绝对于原始值有肯定的误差。
在理论应用的时候，IVF_PQ 这种索引办法事后计算好的各个聚类核心间的间隔，通过查找表得出两个向量索引值的间隔，来近似代替两个向量的实在间隔，这种办法放慢了计算速度；在应用中能够通过参数 m 的设置，使得向量压缩成很小的比例，也大量缩小了内存占用（约为向量原始空间大小的 5%~10%）。下图为 IVF_PQ 索引压缩示例：
依据 Milvus 官网提供的公式：
单个数据段计算量可估算为：指标向量数量 × (nlist+（段内向量数 ÷nlist）× nprobe)
数据段的数量可估算为：汇合数据总量 ÷ index_file_size
对汇合查问所需的计算总量则为：单个数据段计算量 × 数据段数量
咱们计算得出适合的索引参数是 nlist=1024，m=8。
应用分区进步速度：
目前素材中，图片总量靠近 4kw，视频总量大概 1kw，文本总量大概 3kw，为了进步检索速度，分区变得十分必要。咱们通过一些业务属性，依据属性值做笛卡尔积操作来建设分区：
例如，咱们向量对应的 Item 有两个属性：
- 对于属性 A，取值 1，2，3，4
- 对于属性 B，取值 1，2，3
建设分区 A1_B1，A1_B2，A1_B3，A2_B1，A2_B2，A2_B3，……，A4_B3，一共 12 个。通过分区操作，咱们将每个分区的向量规模管制在 500w 以下，进一步提高了检索速度。
须要留神的是，用来建设分区的属性应该是不会变动的根本属性。因为如果产生变动，从新建设分区、导入数据和建设索引将是十分漫长的过程，所以分区确定之后不要轻易扭转。另外，分区及属性值不能太多，否则各个属性值相乘（笛卡儿积）会让数量变得十分宏大，使程序变得过于简单。如果要实现更多的素材属性检索或筛选，咱们在 Milvus 向量搜寻的后果上另外封装一层业务接口来实现。
零碎成果
向量检索服务以 REST 接口的模式对外提供，前端团队调用接口，将后果展现在界面上。（请自行脑补一下谷歌的以图搜图，百度的以影搜影等等……）
性能指标
目前咱们的图片总量大概在 3kw+，视频总量大概在 1kw，向量维数为 2048 维，文本总量为 3kw 左右，向量维数为 768 维。图片检索耗时 0.2s 左右；视频检索耗时 0.1s 左右；文本向量检索耗时 <0.1s。
对于 Milvus 的一些教训与总结
Milvus 集成各种常见向量索引，能满足工程中大部分的需要，存储操作和检索速度都达到了工业级的水准，提供服务化的接口，基本上做到了开箱即用。不过 Milvus 目前还不反对其余类型（字符型、整型）的属性检索，官网示意新版本目前正在研发当中，期待早日上线。
总体来说，对于须要疾速构建向量检索服务、又不想花太大老本结构的轻量级我的项目来说，Milvus 是一个很好的抉择。
参考文献
[1] Product quantization for nearest neighbor search. Hervé Jégou, Matthijs Douze, Cordelia Schmid
[2] https://Milvus.io/cn/docs/v1….
Arch Meetup 深圳站开始报名啦，点击查看流动议程！
GitHub @Milvus-io|CSDN @Zilliz Planet|Bilibili @Zilliz-Planet
Zilliz 以从新定义数据迷信为愿景，致力于打造一家寰球当先的开源技术创新公司，并通过开源和云原生解决方案为企业解锁非结构化数据的暗藏价值。
Zilliz 构建了 Milvus 向量数据库，以放慢下一代数据平台的倒退。Milvus 数据库是 LF AI & Data 基金会的毕业我的项目，可能治理大量非结构化数据集，在新药发现、举荐零碎、聊天机器人等方面具备宽泛的利用。