端智能，顾名思义就是在端上跑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、 运维、产品经理、项目经理以及运营角色，提供一站式整体研发解决方案，助力企业研发模式升级，降低企业研发综合成本。可点击链接进入官网了解更多产品信息。