共计 5556 个字符，预计需要花费 14 分钟才能阅读完成。
Shopee 是一家全球性的电商平台，业务范围辐射东南亚、拉美等多个地区。多媒体了解（Multimedia Understanding，下文简称 MMU）团队是 Shopee 内专一于提供多媒体内容了解服务的团队，为电商、直播、短视频等业务提供反对。
MMU 团队须要反对公司不同业务场景对多媒体了解的需要。以向量检索为例，可能会有如下业务场景：
- 实时举荐，如视频召回零碎
- 视频供应，如视频原创零碎
- 视频去重，如视频指纹零碎
因而在 MMU 团队的向量检索场景下，须要同时具备向量召回根底引擎能力以及不同业务场景下的业务架构能力。因为不同业务场景对根底引擎和业务架构的需要不同，并且在业务落地时还须要联合人力、工夫等各类因素综合思考，这给团队实现相应零碎建设带来了多方面挑战。
本文内容将基于以上背景，分享 Shopee MMU 团队基于 Milvus 引擎在检索业务零碎以及平台化建设的相干实际。
01.Milvus 实际
1.1 向量检索引擎
随着越来越多的向量检索需要呈现，例如基于视频内容的召回、去重等，团队须要一种通用向量检索引擎计划，来保障团队效率及零碎稳定性，从而为业务提供更好反对。
依据对业界开源向量检索引擎的调研论断，Milvus 引擎具备的劣势比拟切合团队的须要。其中 Milvus 的云原生架构较为符合 Shopee 外部云原生生态，可能疾速撑持检索系统从 0 到 1 的搭建；另外 Milvus 具备丰盛个性，包含分布式、GPU、增量更新、标量等，都能对业务场景的高效落地提供无效帮忙。
综合考量后，团队抉择了 Milvus 作为从头搭建检索业务零碎的底层检索引擎。本章将整体介绍向量检索引擎的落地实际。
- Milvus 1.x
第一个需要产生在 Milvus 2.x 公布前。因为数据曾经具备肯定规模，单节点的 Milvus 无奈满足需要，因而采纳了 Milvus 1.1 + Mishards 的分布式解决方案。
图 1：Milvus 1.x + Mishards 架构
然而在理论业务场景中，随着数据规模和申请量的减少，检索性能和吞吐达到了肯定瓶颈，无奈随着 readonly 节点的增多而扩大。
MMU 团队剖析后发现以下两点起因：
- Mishards 默认的分片策略在某些状况下会导致 readonly 节点分到的 segment 数量不平衡。
- 随着 readonly 节点的增多，每个节点都须要检索出 Top K，Mishards 在进行 Reduce 时的数据量会急剧增多，导致时延变得较高。
缓解计划是部署多套 Mishards 集群，共用雷同的数据库和 S3 bucket，但这种计划的部署和保护老本都较大，长期还须要寻找更适合的部署计划。
图 2：Mishards 多集群计划
- Milvus 2.x
Milvus 2.x 公布后，各业务场景逐渐对 Milvus 引擎进行了降级。从实际效果看，Milvus 2.x 的稳定性和可扩展性相比 Mishards 集群都有了极高的晋升。尤其在 Milvus 2.1 公布后，其多正本能力进一步提高了集群整体的性能，根本能满足各类业务场景。另外，基于 Milvus 2.x 的云原生架构，其日志和监控的引入老本很低，也更加敌对和欠缺。
图 3：Milvus 2.x 架构
图 4：Milvus 2.x 监控 (局部指标)
1.2 Milvus 部署计划
- GitOps
早前，Milvus 集群的部署通过手动应用 helm 命令实现 (https://milvus.io/docs/v2.2.x/install_cluster-helm.md)。为了满足资源的隔离性，不同业务须要部署独立的 Milvus 集群。随着业务一直减少，部署集群的保护成了新的挑战。
为了解决这个问题，MMU 团队把每个业务的 Chart 目录都存储在同一个 Git 上，应用 Jenkins/ArgoCD 等工具公布到线上 K8S 集群。
图 5：Milvus 2.x GitOps
目前，Milvus Operator（Install Milvus Cluster with Milvus Operator）已公布，能够进一步缩小 Git 中存储的文件内容并精简配置，缩小配置老本。
- 负载平衡
Milvus 集群部署实现后，集群对外的流量入口是 Milvus Proxy 节点。如果间接拜访 Proxy，会呈现 Proxy 单点问题，须要在后面减少一个反对 GRPC 协定的七层负载平衡组件，比方 Nginx 等（Milvus SDK 应用单长连贯计划，所以不能应用四层负载平衡）。
图 6：Milvus 2.x 架构（援用自 Milvus 官网文档）
以上是 MMU 团队在 Milvus 利用实际的局部介绍，仅供大家参考，本文接下来将简要介绍团队基于 Milvus 引擎搭建的业务架构。
02. 业务架构
2.1 实时检索业务
实时检索业务服务于实时在线申请，零碎实时返回检索后果，如举荐召回零碎。其次要特点是对可用率和时延要求高。
2.1.1 视频召回
视频召回零碎是 MMU 团队为业务提供的基于视频内容的召回能力，作为视频举荐零碎的其中一路召回。业务申请通过检索 Milvus 获取 Top K 候选，通过精排逻辑之后返回召回后果。
- 基于 Milvus 1.x 架构
因为 Milvus 1.x 次要面向数据分析场景，未针对低提早的实时召回做针对性优化，所以在向量库和申请量达到肯定规模之后，提早会有肯定降落。因而在 Milvus 1.x 架构下的某些场景采纳了缓存 TopK+ 后盾更新的形式：通过缓存提供实时查问接口，并在后盾的更新数据流中实现 TopK 的更新。
图 7：类似视频召回零碎（Milvus 1.x 架构）
基于 Milvus 1.x 架构的外围流程如下：
- 预处理模块
○ 监听视频数据库，过滤出零碎须要的视频增量数据交给增量入库模块
- 增量入库模块
○ 对增量视频提取特色，将特色退出 KV 数据库和向量检索数据库
○ 用增量视频查问向量数据库，将检索出的 Top N List，发送给后果更新模块（Top N List 在后续流程中将更新各自的 TopK 后果缓存）
- 后果更新模块
○ 对 Top N List 中的每个视频执行残缺召回逻辑（特征提取、向量检索、精排），将后果输入至 TopK 缓存
- 基于 Milvus 2.x 的架构
Milvus 2.x 公布后，因为其弱小的分布式能力和零碎性能，零碎得以通过 Milvus 2.x 的查问接口间接提供 TopK 召回能力。
图 8：类似视频召回零碎（Milvus 2.x 架构）
2.2 离线检索业务
离线检索业务基于旁路流量进行检索，将最终后果作为特色写入存储，不便不同业务依据各自场景应用，如视频指纹零碎和视频原创零碎。
2.2.1 视频原创
为了构建良好的内容生态，平台心愿通过肯定机制激励用户产出原创内容。为了让这些机制更好运行，零碎须要对视频内容进行辨认，判断其是否属于原创作品。
视频原创零碎为以上需要而设计。零碎通过肯定的解决流程辨认视频的原创性，提供给业务方进行后续解决。
- 零碎架构
图 9：视频原创零碎架构
- 外围流程
- 预处理模块
○ 筛选出零碎所需视频，拼接外围视频信息并输入给特征提取模块
- 特征提取模块
○ 为视频提取特色并输入给业务逻辑模块
- 业务逻辑模块
○ 为视频执行 TopK 检索和原创逻辑
○ 后果入库并输入给业务
- 回扫模块
○ 旁路流程，为各环节解决失败的数据执行兜底策略
2.2.2 视频指纹
类似视频不足新鲜感，无奈给用户带来有价值的生产体验，由此催生了对视频的去重需要，即须要辨认视频是否为反复视频，从而为各业务场景提供去重能力。
视频指纹零碎为以上需要而设计。指纹零碎为每个视频调配一个指纹 ID（指纹 ID 作为该视频的标识，ID 雷同的视频视作反复视频）并输入，供各业务方应用。
- 零碎架构
图 10：视频指纹零碎架构
- 外围流程
指纹零碎的外围流程与原创零碎相似，区别次要在于业务逻辑模块。
- 业务逻辑模块
○ 批量解决视频，执行 TopK 检索、精排、聚类并调配指纹 ID
○ 将后果入库并输入给业务
2.2.3 整体设计
- 对立数据流
- 对立接入协定 – 汇总各方数据源输出，提供对立的数据流
- 对立预处理 – 聚合并保护视频可用状态，升高后续零碎解决复杂度
- 构建增删改语义 – 满足不同业务场景的精细化需要
- 柔性事务
- 重试 + 幂等更新机制，保障输入数据合乎业务预期
- 分区路由 + 本地锁，晋升并发效率，保证数据准确性
- 兜底策略
- 本地重试策略配置
- 失败数据定期回扫
- 逻辑编排引擎
开发通用的逻辑编排引擎，标准化输入输出、中间件调用、AI 服务调用等组件，晋升策略逻辑开发效率
以上是 Shopee MMU 团队在向量检索系统方面的一些工程实际介绍。随着业务一直倒退，团队对研发效率、零碎品质和开发者体验的要求更加强烈。为了晋升这些方面，团队发动了相应的平台建设项目。本文接下来将简要介绍团队在倒退过程中的平台化实际。
03. 平台化实际
3.1 晚期研发模式
在业务和团队倒退初期，以检索场景为例，整体的研发流程如下：
图 11：晚期研发模式
- 算法研发职责
- 联合业务特点训练模型
- 输入算法 SDK 作为交付
- 工程研发职责
- 部署 Milvus 集群
- 依据算法 SDK，开发和部署 AI 在线服务（如特征提取、精排、聚类等）
- 依据业务须要，开发和部署若干相干微服务（如特色存储、缓存服务等）
- 联合业务需要实现编排服务，串接整个业务流程
- 与业务方对接，如提供 API、联调、测试、接入等服务
随着业务疾速倒退，团队对迭代效率和品质要求一直减少，对传统模式发动了挑战。在晚期的研发模式中，存在一些可优化的环节，如模型在线服务、业务逻辑编排、业务接入等。
3.2 模型服务平台
向量提取、精排、聚类等模式固定的 AI 模型原子服务，基于 MMU 场景的对立模型引擎和协定进行了标准化，在进行逻辑编排时，可联合业务特点抉择所需的原子服务。
为了进一步晋升原子服务的研发效率和开发者体验，模型服务研发平台建设应运而生。模型服务研发平台基于模型引擎和对立协定进行搭建，标准化了开发、部署、测试、经营等环节，为模型服务的整个研发周期提供了一站式、全流程的自服务性能。
在开发环节，平台以自服务的形式提供 SDK 开发能力，算法开发人员基于 MMU 场景的对立协定实现模型 SDK 的对接即可，屏蔽模型引擎的工程细节，升高了交互老本和认知负荷。
图 12：模型服务平台 (开发)
在部署环节，平台对接底层依赖的各项基础设施，屏蔽平台应用细节和依赖关系，对立 CPU 和 GPU 的部署平台差别，为用户提供对立的、一键式的部署性能和应用体验。
图 13：模型服务平台 (部署)
在测试环节，平台基于模型引擎和对立协定，提供通用版 SDK 自测、功能测试、性能测试、服务调试等测试方面的性能。通过自动化、一键式的形式，可高效实现原子服务的各项测试。
图 14：模型服务平台 (测试)
在经营环节，平台提供对立的日志、监控、告警机制，以无感形式将新增的原子服务纳入线上经营监控体系。
3.3 逻辑编排平台
MMU 团队对接业务场景较多，不同业务场景存在各自定制化业务逻辑。比方离线检索业务须要定制化精排策略，整个流程须要调用较多内部接口来实现业务逻辑。此外在输入输出方面，一些零碎和业务数据耦合严密，数据输入输出模式比拟多样化。
为防止在每个场景都须要编写定制化代码，MMU 团队开发了逻辑编排引擎，抽象化了业务逻辑的通用步骤，比方向量数据库、模型原子服务、中间件、错误处理、输入输出等。
逻辑编排引擎应用若干个 yaml 文件形容整个业务流程：
kind: workflow
nodes:
- name: mq_datasource
node: {"ref": { "file": "datasource.yaml"} }
nexts:
- external_name: video_embedding
- name: video_embedding
nexts:
- external_name: milvus_search
value:
mms_vid: $.mq_datasource.video_id
node: {"ref": {"file": "video_emb.yaml"}}
- name: milvus_search
nexts:
- external_name: save_milvus_result
errorHandle: retry图 15：业务编排示例
- 从 MQ 数据源中接管 video 数据
- 对 video 数据进行 embedding
- 进行 Milvus 检索
- 将检索构造进行存储
为了进一步晋升逻辑编排效率，团队将编排引擎进行简略平台化，通过 UI 拖拽的形式，对立治理各业务的编排逻辑。
图 16：逻辑编排平台
3.4 业务接入平台
业务接入平台次要定位是为业务方提供自助接入 MMU 服务的性能，包含浏览、体验、接入、经营等全流程，从而晋升业务方接入效率和应用体验。
业务方可通过以上流程自助应用相干能力，确定满足业务需要后，可在平台上申请正式接入。
图 17：能力体验
图 18：自助调试
图 19：接入申请
3.5. 平台化总结
通过对模型在线服务研发、业务逻辑研发、业务接入等三个关键环节的标准化和平台化，团队从能力研发到业务接入整个流程效率失去了较大晋升，各角色也能专一于各自外围工作，晋升整个大团队的综合人效。
图 20：平台化总结
将来，MMU 团队打算持续欠缺现有平台，同时摸索一些垂直场景。
04. 总结
感激 Milvus 向量数据库整体团队，其提供的稳固向量检索能力、多样化性能个性，为 MMU 团队在向量检索场景搭建业务零碎时提供极大的便当，其牢靠的分布式扩大能力无效撑持了日益增长的数据规模。
撰写本文期间，ChatGPT 引发了 AIGC 热潮，而 Milvus 所代表的向量数据库是 AIGC 十分重要的基础设施之一。OpenAI 对于 ChatGPT Retrieval Plugin 的介绍以及 NVIDIA 的发布会中都明确提到了 Milvus 向量数据库及其意义。期待 Milvus 在将来一直给用户提供更加多样化的性能，比方 GPU 反对、资源隔离等，也期待 Milvus 在 AI 时代散发更大光辉。
- 如果在应用 Milvus 或 Zilliz 产品有任何问题，可增加小助手微信“zilliz-tech”退出交换群。
- 欢送关注微信公众号“Zilliz”，理解最新资讯。
本文由 mdnice 多平台公布
