短视频如何有效去重(vivo 短视频分享去重实践)
?? 编者按:
对于短视频产品而言,提升视频去重性能、降低误杀率,是提升用户体验的必要环节。在此次 Milvus 社区发起的「Milvus 实战系列直播」中,我们有幸邀请到了 vivo 互联网服务器开发工程师马运杰,与大家分享开源向量数据库 Milvus 在 vivo 视频中的实践。
嘉宾简介:
马运杰,vivo 短视频后端架构师,负责 vivo 短视频服务端以及视频处理平台的系统架构设计,毕业于南京邮电大学,热衷新技术预研与难点攻坚。
文章图片
业务背景
为什么要视频去重?
对于观众来说,良好的观看体验与视频内容有着很大的关系。当前,全网范围内主要精品视频主要来自于 MCN 机构,一些公司为了更快更好地去覆盖全网内容,会选择和内容代理合作,而代理手上会有很多重复的版权内容,导致重复内容出现。另外,搬运类视频也会产生重复内容。如果将重复的内容直接分发给用户,就会造成极差的用户体验,堪称「劝退」。所以,内容进行去重处理是非常有必要的。
目前,视频去重面临哪些痛点?
目前,基础样本数据已达到大几千万,在不久的将来会过亿。目前的难点是,在亿级样本数据的基础上支持百万级别的吞吐量,同时需要兼顾去重的精度以及高召回率。接下来,我将为大家介绍我们是如何应对这几个问题的。
算法流程设计
文章图片
首先,进行视频特征提取,对视频进行抽帧。视频抽帧有多种策略,可以按照固定的时间间隔抽帧,或者抽取视频所有的关键帧等。我们首先对视频进行场景检测,优先抽取出场景切换中具有代表性的一些关键帧,然后利用图像算法提取关键帧的局部特征,之后再把这些局部特征去合并得到全局特征。全局特征是几千维的浮点型的向量,最后我们还会再进行一层哈希压缩,这层哈希压缩其实压缩了很多的数字量,但是也会给我们带来一些问题,后续会提到。除了视频特征之外,我们还会提取视频的音频指纹,作为比对的重要依据。
文章图片
特征提取后,我们进行特征匹配。将历史提取的视频特征放在向量数据库 Milvus 中,经过 Milvus 数据库召回 topK 的向量,然后通过一定的策略进行过滤合并,得到相似的视频的候选集,经过细致的音频指纹的比对,基本可以得到相似视频的集合。最后,根据业务上的其他特征,如时长、标题等等特征的完整比对,最终形成相似视频集合。
识别效果需要同时兼顾召回和精度这两个方面。在视频召回的时候,我们会适当放宽整个限制,尽可能多地召回相似视频;而在音频比对当中,我们会更严格地进行筛选。这种策略有一定缺陷,比如短视频常用的“拍同款”功能中,拍出来的音频十分相似,比对结果可能不是很好。整体来看的话,这样的策略还是能达到 90% 以上的精度和召回率目标。
去重系统设计
文章图片
整体系统架构如上图,分为三个服务、四个步骤。第一个部分是特征提取,主要是负责视音频特征的提取以及特征文件的管理,其中还包括了视频的镜头检测以及抽帧。第二个部分是去重策略,主要包括了业务上的逻辑以及去重的策略控制。第三个部分是特征召回部分,主要是作为 Milvus 数据库的客户端代理工作,工作内容主要是负责创建集合以及索引。第四个部分则是基于 Milvus 数据库搭建的检索集群,里面分为主集群和备集群。
文章图片
在进行系统的详细介绍之前,我们先来看一组压测结果。从结果中可以看到,第一列向量数量、第三列向量维度和最终的 TPS 呈负线性相关。向量数量、向量维度和索引参数,是影响 TPS 的主要因素,也是我们后面去提升这个性能的主要方向。
文章图片
我们所做的第一个工作是集群化部署。
从压测数据可以看出,单实例只能支持几百万的向量检索,也就是几十万的视频样本。虽然这种单机部署也会有它的一些优势,比如说部署起来非常简单,使用方便等等。但是对于全局去重的业务不合适的。我们选择使用 Mishards 插件来搭建分布式集群,通过不断地加入 Milvus 实例,来分担每个实例的查询数量,提升整个集群的吞吐量。Milvus 数据库内部处理请求的时候其实都是单线程的,如果要提升整个系统的并发能力,可以考虑右边这样多集群部署方式,提升我们整体的吞吐量。
文章图片
除了集群化部署之外,创建索引也是提升性能的主要方式。上图左边表示精度,右边表示性能。可以看到,在添加索引之后会导致一些召回率上的损失,nlist 越小,损失越大,所以我们自然想把 nlist 设置得大一些。然而,Milvus 对二值型向量的支持比较弱,在构建索引的时候没有充分利用 CPU 资源,构建时间非常长。比如,nlist 等于 1024 的时候,索引构建时间已经达到一个小时左右。我们就只能妥协地降低 nlist 的大小,给我们带来了召回率上的一些损失。
文章图片
此外,构建索引期间集群里面的数据无法正常写入的,只有等待整个索引构建完成之后后,才能够正常插入请求,这也是为什么我们需要 Milvus 备级群。我们把向量的读写分为三个状态:正常状态(对主集群进行读写)、索引构建时的状态(不能写入主集群,使用备集群,然后同时查询主集群及备集群)索引构建结束状态(主集群已经可以正常读写,需要把备用集群的数据迁移回主集群,迁移完成后,这个状态也就重新变成了正常的状态)。通过这样主备切换,我们解决了索引构建期间无法正常写数据的问题。
文章图片
整个集群的样本数据量越来越大,集群的吞吐量会随着时间的迁移而变小。为了控制整个集群的吞吐量,我们选择通过业务上的一些规则进行了分支。比如,我们发现两个相同或者相似的视频,我们会是根据视频的发布时间以周为单位去进行分区。在召回的时候,选择该视频所在分区相近的几个分区进行查询。通过这样一种方式,我们对整个比对的数量进行了严格控制,从而保证了检索效率。以上就是我们基于 Milvus 数据库所做的系统设计和性能优化。
期待与总结
在识别效果方面,通过视音频特征的结合,采用宽视频阈值、严音频阈值的方式,目前我们去重识别的精度与召回都达到了 90% 以上;在系统性能方面,Milvus 集群的吞吐量和每台机器检索的数据量强相关,我们通过集群化部署、数据分区的方式,限制每台机器检索的向量数量,以此达到我们系统吞吐量 100 W/天的目标;在索引构建方面,我们遇到了比较多的问题,我们暂时以主备集群的方式满足系统可用性的条件,接下来我们会和社区持续沟通,解决二值索引的相关问题。
【短视频如何有效去重(vivo 短视频分享去重实践)】在未来,我们期待 Milvus 数据库对以下方向进行优化:
匹配分级:对匹配结果进行分级,对于低于阈值之下的视频通过视频处理、采集更细致的视频特征,进行二次匹配;
索引构建效率提升:与社区合作,针对二值索引的构建性能进行优化;
集群自动扩缩容:通过 Milvus 服务的自动注册与自动方向,解决集群静态扩缩容的问题;
系统高可用:通过多集群部署等方式,解决 Mishards 以及 Milvus 数据库写节点单点问题。
Zilliz 以重新定义数据科学为愿景,致力于打造一家全球领先的开源技术创新公司,并通过开源和云原生解决方案为企业解锁非结构化数据的隐藏价值。
Zilliz 构建了 Milvus 向量数据库,以加快下一代数据平台的发展。Milvus 数据库是 LF AI & Data 基金会的毕业项目,能够管理大量非结构化数据集,在新药发现、推荐系统、聊天机器人等方面具有广泛的应用。
推荐阅读
- 考研英语阅读终极解决方案——阅读理解如何巧拿高分
- 如何寻找情感问答App的分析切入点
- mybatisplus如何在xml的连表查询中使用queryWrapper
- MybatisPlus使用queryWrapper如何实现复杂查询
- 如何在Mac中的文件选择框中打开系统隐藏文件夹
- 漫画初学者如何学习漫画背景的透视画法(这篇教程请收藏好了!)
- java中如何实现重建二叉树
- Linux下面如何查看tomcat已经使用多少线程
- thinkphp|thinkphp 3.2 如何调用第三方类库
- 两短篇