共计 5610 个字符,预计需要花费 15 分钟才能阅读完成。
作者:字节终端技术——覃量
前言
端智能,顾名思义就是在端上跑 AI 模型。端智能作为目前炽热的一个新方向,在业界曾经开始锋芒毕露。阿里、谷歌、快手等大企业都在踊跃布局端智能,用端上 AI 来优化各种业务场景并获得了十分突出的成果。
字节 Client AI 团队深耕端智能畛域,并在往年早些时候与西瓜视频单干落地了端智能视频预加载计划,获得了不错的后果。本篇咱们通过这个案例,带大家一起来揭开端智能的面纱,看看端上 AI 在理论中是如何利用进步业务成果的。
一、场景
1.0 场景介绍
西瓜视频预加载这个场景非常简单:在播放以后视频时,客户端会对后续 3 个视频,每个视频预加载固定 800K 的缓存。让用户在播放到后续的视频时能够疾速起播,取得更为晦涩的播放体验。
但这样一个固定的策略也有一些非常明显的问题:
- 用户大部分状况下不会看完 800K 的 buffer,而是简略浏览内容后就划到下一个视频,造成带宽的节约
- 在用户认真浏览视频内容时,如果没有足够的 buffer,容易造成起播失败或者卡顿,影响用户体验
最现实的预加载策略其实是使『预加载大小和播放大小尽量匹配,用户在起播阶段会看多少,咱们就提前加载多少,即不会造成节约,又不会影响用户体验』。
1.1 深刻解析
但理论状况变幻无穷,想要用户看多少咱们就提前加载多少是一件根本不可能做到的事件。这时咱们有了一个想法,如果咱们能够预测用户接下来的行为模式, 比方 晓得他接下来会 『 快 速切换视频』 还是 『慢速生产视频』 的话, 是不是 就能够辅助优化咱们的预加载策略了 ?
事实上用户在一段时间内的行为模式是具备肯定法则的:这个用户的『手速快慢』、对『互动的倾向性』、是不是在『碎片化工夫』、是否是『工作日』等等。咱们能够通过这些法则来预测用户的行为模式,进而失去一个更佳的预加载策略。比方咱们预测用户接下来很大概率会进行『疾速浏览视频』这种模式,此时更合乎用户须要的预加载策略可能就是『缩小预加载的缓存大小 & 减少预加载的视频个数』,反之亦然。
1.2 冲破方向
这时咱们会发现优化这个场景的要害能够被转换成这样一个问题:如何预测端上用户的行为模式?
其中又有这么几个子问题:
应用『规定』还是『模型』来进行预测?
规定
- 长处:简略、开发成本低、能够疾速验证计划成果
- 毛病:只能应答简略场景,场景复杂度越高,规定会变得愈发的简单,导致开发和保护老本变高
模型
- 长处:能够应答简单场景、做更为精细化的策略
- 毛病:开发成本较高、周期也更长
一般来说:
- 在 后期筹备阶段 能够应用规定来疾速验证计划的成果,预估策略大抵的收益
- 在 计划落地阶段 会应用模型的学习预测能力,来制订高可用、高扩大的精细化策略,最初达到最大化的成果
<!—->
这个模型预测应该在『云端』上做还是在『客户端』上做?
- 因场景而异,并没有一个固定通用的做法
以目前这个场景为例,预加载场景具备这样的特点:
- 须要预测用户在页面的行为模式,和用户的滑动行为强相干
- 滑动行为在 短时间周期(秒级、分钟级)具备肯定法则,长时间周期(天级、月级)规律性较弱
- 预加载触发频率高,工夫短,对实时性要求很高(否则容易造成用户卡顿)
- 端上一些特色因为 隐衷以及量级 的关系,不适宜进行上报
- 对于这样实时性要求高、特色数据工夫周期短的场景,比起申请云端的长响应链路,在『客户端』上间接跑模型来进行预测会是一个更好的计划。
最初用一个表格来小结一下『端智能』与『云智能』的个性:
决策老本 | 响应提早 | 数据维度 | 计算规模 | |
---|---|---|---|---|
云智能 | 网络连接 + Native 迭代 | 分级:埋点提早 + 近线提早 | 长期 + 全用户 + 统计特色 | 大数据 + 大模型 |
端智能 | 数据触发 + 动静脚本 | 秒级:端侧计算提早 | 短期 + 单用户 + 时序特色 | 小数据 + 小模型 |
1.3 优化思路
通过下面的几个拆解和剖析,整个场景的优化思路曾经缓缓浮出水面了:
咱们能够利用『端上的实时处理能力』+『AI 的简单场景抽象化能力』来间接在客户端上『预测用户的行为模式』,进而依据预测后果来『优化视频预加载策略』。
二、端智能预加载计划
2.0 端智能计划
有了思路当前,剩下的就是怎么把咱们的思路落地了。
通常来说,端智能计划会包含以下几个阶段:
- 端上 AI 开发
- 客户端开发
- 算法包开发
这几个阶段是相互独立、能够并行推动的,上面会以这个『视频预加载』场景为例来介绍一下上述的各个阶段。
2.1 端上 AI 开发
2.1.0 特色开掘
从这个场景的优化思路中咱们曾经明确了预测的指标是「用户的行为模型」,剩下的问题就是:用什么来预测?
思考全屏内流场景下,什么特色会影响或者反映用户会「疾速滑动短暂浏览 or 迟缓滑动仔细观看」?
- 构想一个用户正在一直滑动观看视频,如果间断几个视频都是他不怎么感兴趣的内容,被一下滑过,那么用户对下一个视频的冀望 or 急躁会一直减小,如果还是不感兴趣的内容可能会只浏览完题目就滑走,均匀下来以后整体观看时长也就较短。
- 相同,如果前几个视频用户都比拟感兴趣,看得很开心,那么对于下一个视频的冀望 or 急躁也会随之回升,均匀下来以后整体观看时长也就较长。
- 用户在滑动浏览视频时,对不同类型、甚至不同起源的视频会不会有所偏差,导致观看时长也因而不同?比方用户以后想看一个比拟短的视频,那么对于长视频就会间接滑过。
从这样对场景的思考中,咱们能够得出十分多的用户行为特色:
有了用户行为特色概念上的思考当前,咱们就能够 进行数据收集和剖析, 把「概念」转化为「数据」。这须要咱们对这个场景相干的端上埋点进行一次梳理。梳理埋点的益处有这么几个:
- 在梳理埋点的过程可能让咱们以一个全面和直观的视角来看咱们的场景。
- 启发特色开掘的思路
- 对现有数据查缺补漏
2.1.1 特色解决
有了从埋点及其他起源的原始数据后,咱们须要 将原始数据进行解决,转化成特色数据。特色解决的思路有十分多,能够通过不同维度来提取特色,比方分为历史特色和实时特色。其中还能够通过不同维度、粒度,或者将多个特色进行有条件的组合来进行不同的尝试,比方:
- 过来 x 条的样本数据
- 过来 x 个视频的相干样本数据
- 过来 x 小时的样本数据
2.1.2 特征分析
通过特色解决失去了一系列咱们认为对以后的问题有意义的特色后,还须要 进一步剖析每个特色的价值大小。这里的价值指的是这些特色对模型的价值,进而咱们才可能在获取这些特色的老本以及成果的收益上来做一个衡量。
剖析特色对模型的价值也有几个罕用的办法,比方:
- pearson、spearman、cohen’s kappa 等相关性系数办法
- Lasso、Ridge 等正则化办法
- 间隔相关系数办法
- 决策树特色排序办法
这些办法各自有本人的实用场景,这里就不再赘述。特征分析除了对模型成果进行先验预估外,还能够帮忙咱们筛选出对以后场景最有价值的特色。因为减少特色通常来说是有附带老本的,比如说:
- 可能减少数据采集的耗时
- 可能减少特色解决的耗时
- 可能减少模型的复杂度,从而减少模型的体积和推理耗时
作为在客户端上运行的模型,为了更好的实时响应能力,尽可能地升高整个链路的耗时以及模型大小也能更好的保障端上智能的成果。
有了端上 AI 模型当前,咱们还须要做一些客户端和算法包对应的开发工作。
2.2 算法包开发
算法包开发次要做的事件有两件。
2.2.0 端上特色工程
端上特色工程就是将端上原始数据处理为特色数据。在字节内有 pitaya 端智能框架,为端上特色工程的各项能力进行了反对。
一般来说,咱们须要在端上提供这样的特色工程能力:
- 反对不同的触发形式来反对不同场景的须要
- 从不同的数据起源(埋点、用户画像数据、设施特色等 …)来获取端上特色的能力
- 对数据有不同维度和不同层级的治理
有了这样的能力后,咱们就能够在端上将特色实时处理为模型所需的输出数据,来进行后续的推理预测。
2.2.1 端上模型推理
除了特色解决外,咱们还须要在端上建设一个模型推理的链路,这部分在字节内同样是由 pitaya 框架来反对的。这个链路次要分为三个局部:
环境部署
顾名思义,就是在端上提供能够在实时部署的推理引擎,以及对应虚拟机环境。
动态化能力
因为端上场景十分多、迭代也会十分的快。策略、模型、甚至场景都可能随着客户端更新或者时间推移来进行一直疾速的迭代。所以对于端智能来说,最重要的能力之一就是 动态化能力。也就是动静地将算法包、模型和运行环境下拉到端上,并进行部署和治理的能力。通过动静更新能力,能够在不依赖客户端发版的状况下就动静地更新咱们的策略,用十分低成本的形式就能够实现策略的迭代。
实时成果监控
除此之外,还须要有一套实时成果监控零碎。用来实时观测模型的成果、性能和稳定性等要害指标,并在将来模型因为用户群体扭转或场景扭转成果下降时来进行及时报警。
2.3 客户端开发
对于客户端来说,须要依据不同场景来决定不同算法包的触发机会,以及对应算法包后果的解析逻辑,从而执行相应的业务逻辑。在视频预加载场景下是这样的:
触发算法包执行
- 横屏内流场景实现首帧渲染后,被动触发算法包执行。
解析算法包后果
- 业务增加预加载工作的逻辑,由之前的固定策略,改为依据算法包返回的执行后果,解析后增加预加工作。
在视频预加载这个场景中,咱们在后期利用动静更新的能力疾速试验了预加载极其值和不同加载个数给播放体验会带来的影响,确定了适宜视频预加载的最佳组合区间。同时也利用实时成果监控,在试验中发现出模型以后的各种问题,从而一直进行修改和迭代,晋升模型的成果
三、计划成果评估
客户端业务代码调整实现,模型和算法包也开发实现之后,就能够通过 AB 试验来验证咱们计划的成果了。AB 试验大家都很相熟,端智能的试验实质上并没有不同,但也有几点须要咱们特地关注一下。
3.0 疾速迭代算法包
端智能在提供了灵便计划的同时,也为试验带来了更多能够验证的维度。咱们能够尝试应用不同模型、组合上不同的策略、甚至不同的触发机会。因为能够尝试的组合太多,在试验中很容易碰到流量以及实验组不够用的问题。
这个问题字节 Pitaya 平台是通过提供算法包部署和分流能力来解决的。反对在算法包公布时建设子公布,每一个子公布都能够当作咱们的一个策略组,来验证咱们对一个策略方向的想法。同时每个策略组还能够与 AB 的实验组一一绑定,在试验过程中迭代更新咱们的策略,以达到试验不关停,疾速验证不同策略的目标。
在视频预加载场景中,咱们能够这样设计咱们的试验:
实验组 | 策略组 |
---|---|
线上组 | |
实验组一 | 扭转预加载个数 (1,3,5,7, ..) |
实验组二 | 扭转预加载 size (500, 700, 900, ..) |
实验组三 | 扭转预加载调度形式 (并行, 串行, ..) |
每一个策略组对应一个优化方向,具体优化细节在策略组内通过算法包迭代来调整。这使得咱们能在短周期内疾速察看各方向的成果,并寻找出各策略组内体现最好的策略。
这样的设计还有一个益处:算法包的公布大部分状况下不依赖于客户端版本,算法包的迭代能够依据试验反馈的状况进行更疾速的调整,达到一周一次,甚至一周两次的频率。
3.1 算法包监控
端智能的试验相比于个别的试验,除了 AB 试验中的业务成果指标外,咱们还须要关注一下算法包自身的指标,来保障模型成果也合乎咱们的预期。这些指标通常包含:
- 性能指标:执行成功率、执行耗时、PV、UV,…
- 成果指标:accuracy、precision、recall、TP、FP、TN、FN、…
有了这样的实时监控咱们就能够随时把握算法包的运行状况以及模型的成果,在算法包出现异常导致成果下降时及时发现定位,并进行优化和迭代。
3.2 计划优化
在试验过程中,咱们依据试验数据反映进去的问题,一直对计划进行了很屡次优化。
比方在 review 模型成果和试验数据时,发现 FN 的影响在咱们这个场景会比 FP 大很多。于是尝试通过调整阈值来升高 FN 比例,并在试验中疾速迭代验证了一下成果,后果播放卡顿率 / 启播失败率等指标都有比拟显著的优化。
再比方咱们在分析模型预测后果时,发现用户的行为模式在短时间段内具备肯定的法则,并针对不同的时间段来优化咱们的模型策略,进一步晋升了业务成果。
在算法包动静更新能力的加持下,咱们能够疾速地迭代咱们的策略。从启动时的简略粗略,一直优化到模型能力越来越弱小,算法策略越来越精密。最终可能通过端上智能找到最合乎以后业务场景的精细化策略。
3.3 收益后果
通过一系列的试验,咱们在西瓜视频的视频预加载策略也胜利落地上线,并在各项视频播放指标以及带宽老本指标上获得了可观的收益:
- 从播放指标上看:端智能预加载策略比起固定的预加载策略:失败率上缩小了 3.372%,未起播失败率缩小了 3.892%,卡顿率缩小了 2.031%,百秒卡顿次数缩小了 1.536%,卡顿渗透率缩小了 0.541%
- 从老本指标上看:端智能预加载策略比起固定的预加载策略,在总带宽老本上缩小了 1.11%,为公司节俭上千万的老本。
四、总结
线上测验时咱们会发现很多之前阶段暗藏的问题,比方特色选获得不好须要增加新特色,推理耗时比拟高须要优化模型和算法包,模型与策略联合得不好导致总体成果没有达到预期等等 …
每个新的问题都会反过来帮忙咱们优化之前的某个阶段,迭代咱们的策略,而后再一次承受线上的测验。整个阶段能够被看成一个环:
AI 和业务相结合的场景往往须要在这个环内通过若干的周期的优化和提炼,一直达到更好的成果,能力最初迭代出一个成熟无效的计划,最终晋升业务成果。
字节端智能平台 Pitaya,是字节跳动 Client Infra 团队和 Data-MLX 团队独特打造的一套端 + 云的基础设施,旨在帮忙终端业务高效利用 AI 能力进步业务成果,拓展业务场景。目前次要建设有端上智能业务,端上特色工程,端上推理引擎,端上训练等框架,在抖音,西瓜视频,今日头条,教育等多个业务单干落地,帮忙业务晋升成果。
火山引擎利用开发套件 MARS 是字节跳动终端技术团队过来九年在抖音、今日头条、西瓜视频、飞书、懂车帝等 App 的研发实际成绩,面向挪动研发、前端开发、QA、运维、产品经理、项目经理以及经营角色,提供一站式整体研发解决方案,助力企业研发模式降级,升高企业研发综合老本。可点击链接进入官网理解更多产品信息。