从 2019年开始，淘系技术部内容社交互动团队和北京邮电大学周安福教授一起着手研究更好的基于机器学习的智能拥塞控制算法。在实验室环境完成原型验证后在淘宝直播的生产环境做实际效果对比，从实际数据来看效果明显。我们将其中的技术要点和数据做了总结，并投稿MobiCom2020，非常幸运地被这家全球最顶级的计算机刊物录用。以下是这篇Paper的中译本。

摘要

---

机器学习模型，尤其是强化学习(RL)，在优化视频流应用方面已显示出巨大的潜力。然而，目前的解决方案局限于“离线学习”模式，即 RL 模型在仿真器/模拟器中进行训练，然后 在真实网络中部署。因此，上述方案不可避免地会遇到’仿真-现实’环境之间的差异(gap)，在真实网络中的性能远远不如仿真环境下的性能。

在本文中，我们提出了 OnRL，一个实时移动视频通话的在线 RL 框架。OnRL 将单独的 RL agent 直接部署到每个视频通话系统中。这些系统依据 RL 算法，实时地做出视频比特率决策，并随时间实时演化其 RL agent。OnRL 继而聚合这些 agent，形成一个具有高层次信息的 RL 模型，从而使得每个视频通话都能应 对不确定的动态网络条件。

此外，OnRL 还设计融合了新的机制来处理视频特性所带来的系列挑战，并消除由 RL 算法本身的强探索性导致的服务质量下降的风险。我们将 OnRL 应用到主流的视频直播系统——阿里巴巴淘宝直播 APP。通过近一个月对 151 名真实移动用户的 543 小时视频直播实验评估，OnRL 的性能明显优于之前的算法，在保持相似视频质量的同时，视频卡顿率减少了 14.22%。

引言

---

实时交互式视频应用占据了当今互联网的大部分流量，这主要是由于许多新兴的主流视频通话应用的带动，如 Facetime、Skype、谷歌 Hangouts、淘宝直播、微信等。

随着 LTE-Advanced 和 5G 等网络基础设施的升级，新的应用场景也在迅速涌现，如实时超清视 频/VR 广播、云游戏、手术机器人或车辆的远程视频操作。这种交互式 视频应用程序在带宽和延迟方面对网络提出了最苛刻的要求。尽管通信基础设施正在努力 满足其这些应用需求，但它只承诺提供力所能及的最佳服务(best-effort service)。应用必须 依赖其本身的调节算法来适应高度动态的网络条件。

为了保持高质量的用户体验(QoE)，传统的交互式视频应用程序采用基于规则(rule- based)的协议，如传输层的拥塞控制和应用程序的视频比特率自适应。然而，预定制规则 无法适应高度异构的现代互联网，包括蜂窝/WiFi 无线链接、跨大陆光纤链接、基于云的数 据中心链接等，所有这些都具有不同的带宽、延迟和缓冲能力。

近年来，数据驱动的机器学习算法被提出用来改进视频 QoE。例如，Pensieve在视频流系统中使 用了强化学习(RL)来调节视频比特率，目的是在最大限度利用带宽的同时降低视频卡顿的风 险。Concerto设计了模仿学习算法以协调传输层和视频编解码器间的不协调性，从而降 低移动视频通话的卡顿率。

在展示潜力的同时，现有的解决方案通常采用“离线学习，在线运行”的策略，即机器学 习模型在仿真器或仿真器中进行训练，然后在实际应用中进行部署和测试。不幸的是，这样 的离线学习模型在现实世界中的性能较差。此外，它们甚至可能表现出与在模拟环境中相 反的性能特征。其根本原因在于两个相互关联的因素: 

• 在模拟器中 忠实地模拟复杂的真实世界的互联网动态是非常具有挑战的开放问题。一条网络路径的 单个路由器可以有各种各样的功能和状态，例如多流竞争、丢包策略、负载引起的质量波动， 更不用说终端设备上的多个协议层之间复杂的交互了。

• 从本质上说，机器学习算法是数据 驱动的，算法的能力严格地受到其学习环境(及数据产生环境)的限制。它通过在模拟器中 反复试验获得的经验可能在处理真实的 Internet 时变得过时的(无法正确做出决策)。

在本文中，我们提出一种基于在线强化学习的移动视频通话自适应框架 OnRL 来弥补 ‘模拟-现实’的差距。OnRL 直接在真实视频通话系统(即，阿里巴巴淘宝直播) 中运行并持续训练，从而学习和响应真实的网络动态性。OnRL 不仅仅是一个简单的学习环境的转变。相反，它发现并解决了三个独特的设计挑战:

• 从大量并发的视频通话中学习。在传统的离线学习中，可以收集和连接(concat) 来自每个用户的网络 trace，并将其输入模拟器/仿真器来训练 RL 模型。基于此，RL 模型可以探索不同的环境来丰富它的经验，并收敛到一个具有从所有用户那里学习到的群 体智能的通用模型。然而，对于在线学习，大量的视频通话会话同时运行。在此过程中，学 习算法需要随着每个个体的实时变化而演化。因此，关键的挑战在于如何在利用群体智能的 同时，实现从串行离线学习到并行在线学习的转变。为了应对这一挑战，我们提出了两阶段 (two-stage)在线学习架构。首先，基于最先进的 PPO 算法设计了一个新的深度强化 学习模型，并将一个个性化的 RL 模型实例与每个用户关联起来。通过这种方式，每个用户 都可以使用自己的学习经验得到不同的 RL 模型。其次，我们将所有用户的经验按照联邦学 习的原则进行聚合，从而形成一个能够对任何网络名称做出反应的高级模型。这两个阶段是 迭代耦合的，从而在个性化体验和群体智能之间取得平衡。

• 在实时视频的动态性下执行 RL 算法。有效强化学习的一个基本要求是学习算法 的动作必须严格的被环境执行。在我们的视频通话算法中，一旦 RL 算法决定发送一个比特 率 x，视频编码器应该理想地以完全相同的速率 x 产生视频流。虽然这对于离线模拟或 VoD 流很简单，但实时通话中的视频编解码器在短时间尺度中不能生成严格的 x 粒度的比特 率。相反,视频编解码器有自己的控制逻辑，其比特率依赖于图像场景动态压缩策略,甚至设 备计算能力, 这导致了大幅度的视频比特率波动，以及 RL 的比特率决策与实际发送视频流 量之间的差距(第 3 章节)。为了处理上述问题,我们对 OnRL 学习算法进行了自适应优化， 将上述差距输入给 RL 神经网络模型。通过这种方式，OnRL 可以理解这一差距的动态性， 然后通过自动调整其奖励操作来弥补其负面影响。例如，OnRL 一旦检测到一个较大的差距， 就会将之前的 RL 行为视为‘被污染’的，并且在计算相应的 reward 时，通过施加一个较 低的权重因子来降低该行为的影响。

• 鲁棒的混合学习。本质上，RL 算法通过遵循 trial-and-error 原则进行学习，如果直接应用于在线学习，会存在系统性能下降的风险。具体来说，该算法可能会采取不正确的“探 索”操作 (例如，在较差的网络条件下选择非常高的视频比特率)，从而导致灾难性的后果 (例如，严重的拥塞，从而导致较低的 QoE)，特别是在 RL 模型尚未得到良好训练的早期学 习阶段。为了解决这一问题，我们设计了一种混合学习机制，当 RL 算法被认为处于异常状 态(如连续经历高丢包率和高延迟)时，OnRL 将返回到传统的基于规则的视频比特率算法。为了实现这种切换，我们设计了一种自适应的趋势滤波算法来检测 RL 运行状态。此外， 我们通过将每一次这样的切换事件(RL 切换到基于规则的算法)作为惩罚，映射到 RL 的 奖励函数来增强 RL 的学习过程。通过这种方式，RL 算法将认识到它应该尽可能避免调用 传统基于规则的算法，并演变成一个独立的、健壮的视频比特率自适应算法。

我们已经在阿里巴巴旗下的主流视频通话系统淘宝直播上实现并部署了 OnRL。我们用 543 小时的淘宝实时会话来评估 OnRL——在一个月的测试中，我们测试了全球 151 个测 试版用户。结果证实了在线学习的优势，带来了显著的 QoE 改善，即减少了 14.22%的视 频卡顿率，同时保持了几乎相同的视频比特率(吞吐量)。此外，我们的控制实验验证了 OnRL 中的每个设计模块，并通过基准实验解释了它们的有效性。

本文贡献:据我们所知，OnRL 是第一个部署在实际运营系统中的基于在线学习的视频 通话解决方案。OnRL 解决了当 RL 在高度动态和异构的移动互联网上满足实时应用时出现 的一般问题。OnRL 的具体贡献包括:

• 我们提出了一个 two-stage 迭代的 RL 算法，与传统的基于模拟/仿真的离线学习不 同，该算法使在线学习能够直接从大量并发视频通话会话学习，并获得视频调整能力。(第 2 章节)。

• 我们设计了新的机制，以减少 RL 应用于实时视频应用时，由于编码器不能合格执行 RL 确定的视频速率(第 3 章节)所带来的负面效果，从而提高在线学习的鲁棒性(第 4 章节)。

• 我们在主流商业视频通话平台上实现和部署了 OnRL(第 5 章节)，并验证了其显著的性能提升(第 6 章节)。

并行在线学习:架构和算法

---

▐  迭代性的 two-stage 架构

现有的机器学习驱动的视频传输系统都采用“离线学习”方法，如图 1(a) 所示。这样的系统首先需要从不同的用户那里收集大量的模拟或真实的网络trace。然后，将这些 trace序列化，即不管其固有的个性化/时间特性进行连接，然 后在定制的模拟器/仿真器中，训练神经网络模型(通常是 RL 模型)。最后，将训练后的模 型分发给每个用户，用户在运行时利用此固有模型执行所学习的比特率自适应策略。

然而，这种离线学习无法提供预期的性能提升，主要是由于‘模 拟-现实’的差距所造成。而且，串行化学习加剧了这一差距:

• trace串行化模糊了用户的个体特征，即每个用户将获得相同的训练体验，从而失 去了个性化优化的可能性。

• 一旦 RL 模型离线训练，它就会固化并停止在现实世界中的 学习。因此，它无法处理以前没经历过的新的网络状况。

相比之下，On-RL 采用了一种完全不同的在线学习设计原则。为了实现这一原则，我们 设计了一个迭代的two-stage学习架构(图 1(b)，其操作如下:

阶段 1:个性化学习。每个用户在运行时分别学习自己的 RL 模型，该模型基于最先进的 PPO 算法，具有针对 实时视频传输的定制设计。这样，每个用户都拥有一个个性化的模型，其中包含 了其个性化的学习体验。

阶段 2:学习聚合。然后，将个性化模型反馈到后端服务器， 并聚合以生成一个通用模型。根据联邦学习的原理，聚合模型对每个模型的神经模型参数采 用加权平均。从较高的层次上讲，聚合模型经历了来自不同用户 的足够多的网络变体，从而获得了所需的应对网络动态的能力。

上述两个阶段是迭代进行的。具体来说，聚合模型将分发给所有用户;每个用户在新的 可视频通话会话中，将从最新的聚合模型开始，并继续从新会话中学习。该过程产生了一个 新的个体模型，该模型融合在后端服务器上，用于新一轮的学习聚合。我们将这种持续迭代 视为一种“终身学习”，它在每个用户的个性化体验和所有用户的群体验之间取得了平 衡。值得注意的是，一个成熟的聚合模型可以立即应用到一个新的客户机用户，从而消除在 初始化阶段低 QoE 的风险。

我们现在分别对个体学习算法和学习聚合进行阐述。

▐  个性化在线学习

我们为个性化在线学习设计了一个基于 PPO 的 RL 算法，如图 2 所示。具体地说，RL Agent在任意时刻 t保持观察瞬时网络状态 St(丢包、延迟、延迟间隔和吞吐量)，并决定动 作 At(比特率)，该动作预期与当前可用的网络带宽匹配。然后在视频编解码器和传输层协议 上执行At操作，传输层协议分别以At的速率生成和消耗视频流量。流量经过网络路径后，将 产生新的状态 St+1，从而启动新一轮 RL 操作。

RL Agent的关键功能 St→ At的映射是由 RL 的控制策略 πst,at决定的。直观地说，如果 RL 代理产生的比特率超过可用带宽，它将导致网络拥塞。其结果将反映在下一状态 St+1，最 有可能是高丢包率或大延迟。通过观察从 St到 St+1 的变化，RL 代理可以意识到它做了不恰当的操作，因此在下次观察 St或类似状态时需要更新策略 πst,at以生成更保守的比特率。在上述工作流程的基础上，我们确定了两个需求:

• RL Agent应该非常灵活，即在视频帧 级别的粒度上响应网络动态，对应于几十毫秒的时间粒度。

• RL Agent应避免降低视频感 知质量和 QoE。为了满足需求，On-RL 首先采用在后台运行的秒级别粒度 的批量级策略更新，同时使用ms级粒度的最新模型执行敏捷响应。其次，On-RL 通过使用 相对稳定的策略调整机制来保证平滑的比特率自适应。我们现在介绍 RL 模型和训练方法。
  

OnRL 的 PPO 模型

图 3 描绘了 On-RL 的 RL 模型，包括状态、动作和神经网络结 构。

状态:也是 RL Agent在任意时刻t 的输入，用 St=(Lt,Dt,It,Tt)表示，它表示丢包、延迟、 延迟间隔(即连续到达的组包的到达时间间隔和发送时间间隔之间的差)和接收端吞 吐量。基于 WebRTC中的周期性 RTCP ACK 消息(主流交互视频服务中使用的传输/应用 层协议栈)，这些输入可以在发送方以大约 50ms的细粒度时间粒度轻松输出。

行为:在每个 RTCP 间隔中，On-RL 将 St映射到压缩动作空间 A:{0.1M，0.2M，···， 2.5M}，表示视频编解码器的目标输出比特率。视频流通过网络传输后，On-RL 将立即转 换为新的状态 St+1，并生成新的动作。通过这样连续的迭代，On-RL 将学会处理网络动态性 继而提升视频服务质量。

奖励:为了确保 On-RL 能够从过去的经验中学习，每一个动作都与一个奖励相关联，奖 励是上一个时间间隔的视频 QoE，定义如下:

其中 Qn表示应用层的视频质量，Ln和 Dn表示传输层的丢包率和延迟。最后一项是通过惩 罚较大的比特率波动来增强视频的平滑性。这些指标由不同的影响因素 α、β、η、φ 加权， 然后相加。

神经网络结构。On-RL 使用一个神经网络结构(用一组参数 θ)来表示策略。它采用简 单的全连接(FC)结构提取隐藏在不同输入元素中的隐含特征。更具体地说，On-RL 首先平 铺(flatten)序列(Lt,Dt,It,Tt)，然后将其馈送到两个 FC 层，分别包含 64 和 32 个神经元。每 一层采用tanh激活函数，它显示出比传统 Relu 或 Softmax 激活函数更精确的带宽预测能力。除 FC 外，我们还尝试了 CNN 和长短时记忆(LSTM)进行特征提取，但它们的性能 不如 FC。进一步分析表明，CNN 体系结构专门用于提取包含复杂空间信息的图像特征，而 这些信息不存在于 On-RL 的状态空间中。对于 LSTM，考虑长期历史影响的时间序列数据推 理更为有用，但视频通话的性能更多地依赖于瞬时网络条件。

训练策略，训练的目标是最大化总的累积回报

 其中 γ 作为 折扣因子，通常定制为 0.99 或 0.9。Rτ 最大化的梯度策略更新可表述如下:

式中，表示优势函数，表示状态和行动决定的预期报酬与策略 θ 的平均预期报酬之间的差异。直观地说，优势函数可以显示某个动作相对于平均动作的额外效益。回想一下，由于学习率值的不确定性，传统的策略梯度可以在相邻策略之间进行大的或 小的调整。这种不确定性会给实时视频带来灾难性的 QoE 和难以收敛的问题，特别是对于 On-RL 的实时学习。为了避免这种情况，我们设计了两个自定义模块来维护在线学习性能:

批量级更新，而不是实例级(单个输入)更新。如前所述，On-RL 需要响应每个输入实 例以适应实时带宽变化。通常，响应也会导致神经网络参数的更新。然而，这样的实例级更 新将大大增加学习时间，并反过来降低响应速度。因此，我们设计了一个批量更新策略。特 别是，学习 Agent在缓冲区存储了最近的状态、动作、奖励记录。只有当缓冲区大于批处理大小时，Agent才会将缓冲区馈到策略网络以更新神经网络参数。这样，Agent可以实时执行细粒度的响应，同时运行在线学习。

平滑级别更新。On-RL 使用关 于梯度更新的损失函数，如下所示：

其中，我们通过考虑它们的概率比来限制当前策略和旧策略之间的差异。具体来说，当 超过区间（1-ε，1+ε） (这里 ε 是一个设置为 0.2 的超参数)时，我们截取 比率，从而从损失函数L(θ)中移除对应激励。通过这种方式，On-RL 将顺利地更新学习策 略，从而避免过于抖动的比特率决策，从而提高比特率平滑度以获得更好的 QoE。

神经网络参数的选择。我们使用 TensorFlow来实现训练 On-RL 整个工作流，使用 TFLearn来构建神经网络体系结构。On-RL 采用 RTCP 级的细粒度迭代，在我们的设计中， 批量训练的批大小为 32。我们使用 Adam优化器来更新随机梯度下降。关于奖励的超参 数 α，β，η，φ 分别被经验地设为 50，50，10，30。

▐  学习聚合

学习聚合的灵感来自于我们对淘宝网直播Trace的分析中的两个关键观察:

• 不同的 用户表现出不同程度的网络动态性。例如，一些用户通常在家里进行视频会话(例如，化妆 师或店内购物指南)，并有稳定的 WiFi连接。相应地，PPO 学习算法倾向于生成稳定的视频 比特率决策。相反，由于移动性或切换，其他客户端用户(例如户外旅行者)通常会经历波 动的蜂窝网络条件。因此，该学习算法将学习频繁地改变其视频比特率以匹配瞬时网络变化。

• 当用户通常具有相对一致的网络状况时，她可能会改变日常程序，从而遇到新的网络 动态。在这种情况下，一个纯粹从她自己以前的网络条件训练的 RL 模型将作出不恰当的反 应。

为了平衡个体和群体的经验，我们提出了一种加权模型聚合方法。最近的工作已经表明，在许多神经网络模型中平均加权多种神经元的参数，可以达到聚集这些模型经验 的类似效果。因此，我们利用神经网络参数的强大特征表示能力来实现模型聚合，如图 4 所示。具体地说，假设我们有 K 个用户，每个用户 K 的神经模型可以用一个矩阵 Wk,i,j表示， 其中 Wk,i,j的每个元素是神经模型中一个神经元的参数(i表示神经网络的第 i层，j是每层的第j个神经元)。注意，所有矩阵(Wk,i,j∈[1，k])的维数是相同的，因为所有用户的神经网络结构是相同的。为了融合各个模型，我们按照联邦学习的原则执行加权平均操作:

其中 表示聚合模型，λk是用户k模型的权重。我们在图 5 中提供了一个示例来说明模型平均化过程。特别是，暗神经元的权重 W2,2 是根据两个单独模型(模型 1 和模型 2) 对应的神经元位置计算出来的。我们有两种方法来确定每个 λk的值:

• 平均聚集。对于一个新加入的用户(即一个没有任何经验的用户)，我们生成并应 用一个具有所有用户平均经验的模型，即，我们让k的 λk=1/k∈[1,k]。

• 个性化聚合。对于其他用户，我们优先考虑用户自身的权重，以便在其典型网络 条件下获得最佳性能，同时在遇到异常情况时做出恰当的反应。具体地说，对于每个用户k， 我们让 λk=c(c∈[0，1])，和 λm=1-c/k-1，对于任意m≠k.以秒为单位。在 Sec.6 中的实验评价了 权重参数c的影响。

在实时视频的动态性下执行 RL 算法

---

▐  理解行为偏差

在实际的视频通话系统，如 WebRTC 中，一个视频帧通常会突发地进 入网络。为了避免短暂的拥塞，其引入了一种Pacer机制，即将视频数据均匀地分布在连续 的时间片上，如图 6 所示，当产生视频帧时，它们会被送入Pacer队列。Pacer将视频帧分 成多组数据包，以∆为间隔(通常为 5ms)发送至网络。Pacer 有自己的控制逻辑(例如，预 算和补包)根据拥塞控制算法(例如，WebRTC 中的 GCC)生成的瞬时目标比特率(表示为x),发送这些数据包。令人感到奇怪的是，通过对淘宝直播中默认 WebRTC Pacer 的行为分 析，我们发现Pacer的实际发送速率p与目标x仍有较大的偏差。我们的分析揭示了导致差 距的两个不可避免的原因。

• pacer 有时需要增加发送比特率以加速缓冲区的清空。Pacer 队列有自己的控制逻辑， 它依赖于图像场景的动态性、压缩策略甚至终端设备的计算能力，另一方面，视频流量是相 当大的，例如，当视频场景快速变化时，一个关键帧可能包含过多的数据，在这种情况下， 如果Pacer严格执行 X，这将导致Pacer 队列中产生较大延迟，这可能会对实时视频造成不 利的冻结影响。因此，我们将通过乘以一个参数(在 WebRTC 中约为 2.5)来重新计算Pacing速率，以加速缓冲区清空。这意味着交互视频系统无法严格执行 RL 的动作(X)，这将损害 它的有效性，并可能最终误导它的策略更新。

• pacer有时没有足够的视频数据来满足目标比特率 x，例如，相对静态的视频场景。Pacer内部的填充逻辑可以人为地添加一些虚拟数据包，但我们发现这种机制几乎不适用于 实时视频，其根本原因是虚拟数据包带来了更多的流量占用，加剧了带宽成本，而且填充数 据往往会增加实际视频数据包的延迟，从而降低 QoE。因此，像淘宝直播这样的运营视频通话服务通常不愿意使用填充，因此 RL 模型所要求的目标比特率也无法准确执行。
  

  在图 7 中，我们通过记录和绘制从视频会话采集的目标比特率、Pacing 速率和 Pacer缓
  冲区中的队列大小来展示行为偏差。我们可以发现，当Pacer队列累积了很多数据包(例如， 每当出现关键帧超过 1000 字节)时，Pacer 将执行比目标比特率 x高的发送比特率p以加 速缓冲区清空，而当队列几乎为空时，由于没有填充，实际发送速率通常降到零。

▐  学习容忍行为偏差

为了克服上述问题，我们进一步定制了 OnRL 的 RL 模型来隐式地 学习目标比特率和实际视频流量之间的差距，我们通过将差距输入 RL 神经模型来实现这一 点，特别地，我们将这个差距定义为:Gt=Xt−Pt，其中 Xt 表示 On-RL 在t时刻 RL 动作的目 标速率，Pt是 Pacing速率，然后第 2.2 节中的状态/输入被更新为通过这种方式，On-RL 可以学习差距的动态性，然后通过自动调整其 奖励操作来补救影响，一旦检测到较大的间隙(例如，|Gt| >0.5Mbps)，On-RL 将认为先前 的 RL 行为为异常，并通过在累积奖励(第 2.2.2 节)中施加低权重因子(在我们的设计中， 默认值为 0.5)来减少行为的影响。第 6.4 节与差距不敏感的 RL 模型相比，验证了该机制的 有效性。

鲁棒的混合学习

---

在这一部分中，我们阐述了混合学习策略，以确保 RL在实际网络动态条件下在线训练 时的可靠性。典型的 RL 模型是以trail-and-error的方式学习的，而实际运行中，任何错误 的行为都可能导致交互视频 QOE 的严重下降。在图 8 中我们展示了这一点。视频比特率、 包延迟和groud truth网络带宽是从本地testbed上的受控实验中获取的(testbed的实现将在第 5 节中介绍)。在 10分钟的时间内，出现了8 次RL生成的比特率超出可用带宽的现象，导致延迟急剧上升。理想情况下，RL 算法应该从这些错误中吸取教训，但与基于模拟 的训练不同，通过失败积累经验对于实时视频是不可接受的，尤其是在视频会话开始时，RL 可能需要不断地利用和失败，以实现其策略。

另一方面，传统的基于规则的视频传输控制算法，如 GCC，往往会做出保守的决策， 因此，将基于规则的算法和 RL 算法相结合，即一旦 RL 的决策变得过于激进，就切换到保守 的算法，但这会影响 RL 的学习能力，即 RL 的学习被中断，并且在其不存在的期间不会注意 网络状态的变化，因此 RL 在未来无法做出恰当的反应，关键问题是:如何在保持学习能力 的同时抑制 RL算法的灾难性探索行为?

为了应对这一挑战，我们设计了一种混合学习机制，将 RL 算法和保守算法集成在一个 耦合的闭环系统中，直观地说，我们不时仅仅把基于规则的算法(在我们的设计中是 GCC) 当作一个保护备份，而是把它当作 RL 算法的“老师”，并提供有用的反馈以防止不恰当的行为。

图 9 展示出了该方案的工作流程，具有以下关键要素:

• 不同于纯 RL 学习(第 2.2 节)，我们引入了一个安全状态检测器，通过检查当前输入状态来评估 RL 算法是否正常工作。

• 如果是，则输入状态将转到 RL Agent，该Agent将负责按照第 2.2 节中的过程进行 比特率分配。

• 否则，GCC 将接管比特率选择算法。值得注意的是，每当调用 GCC 时都 会有一个惩罚，它被合并到 RL 的奖励函数中。这样，即使在 GCC 运行时 On-RL 仍然可以隐式地学习。

• 一旦检测器确定 RL 导致 QoE 收到损害的可能性很低，On-RL 将回滚到 RL。我们现在开始详细地介绍在混合学习框架中安全情况探测器和惩罚反馈的设计。

▐  安全情况检测器

由于网络条件的不确定性，检测Agent是否做出了不准确的行为是非 常重要的。为了能够及时的检测即将发生错误控制的行为，受到基于延迟的拥塞控 制机制的启发，我们设计了一个基于延迟的滤波器来预测视频的 QoE 损失。其基本思想是 检测最近接收到的延迟序列是否呈现上升趋势，如果是，检测器将命令 On-RL 从 RL 切换到 GCC，具体地说，我们使用包间间隔∆d(ti)序列来估计网络路径上的排队累积趋势，定义如下:

其中，si 和ai表示第i分组的发送和接收时间戳。在时间 T，近期内 QOE 下降的可能性 可以用历史序列来表示:∆d(t0)，∆d(t1),..., ∆d(tT)。我们用指数加权平均值 D(ti)定义可能性 度量，如下所示：

其中，延迟记录的时间越近，它在 D(ti)中的权重就越重要。注意，检测器使用沿t的滑动窗口计算 D(t)，并且一旦 D(ti)超过阈值 γ(t), filter会预测QOE有降低的高风险，于是会切换到 GCC。由于 GCC 对延迟敏感，其控制策略会立即降低当前发送的比特率，从而降低风 险;另一方面，一旦条件恢复到安全状态(即，没有延迟增长的趋势)，RL 策略将重新进行控制。

这里的一个挑战是确定阈值γ(t)。我们注意到恒定阈值不能处理固有的网络多样性和动 态性。因此我们设计了一个随延迟序列变化的自适应阈值 γ(t):

▐  RL 的切换惩罚

我们利用 RL 和 GCC 之间的切换作为反馈来扩充 RL 模型。每个切换事 件都被配置为对代理的奖励功能的额外惩罚，这样，它将学会恰当地操作，从而在将来尽可 能少地切换到 GCC。具体来说，我们设计了一个自适应惩罚参数 η′，以替换公式(1)中标 准 RL 奖励中默认的 η:

在这个η′调节下，RL 动作触发的延迟越大，在整个过程中受到的惩罚就越大。我们将在 第 6 章验证整个混合学习方案的设计。

Taobao-Live app 实现

---

我们基于运营中的 Taobao-Live视频通话系统实现 On-RL，并将其作为测试版应用程序发布给用户。Taobao-Live 基于 WebRTC构建，WebRTC是一个实时视频通信框架，内置视频编解码和传输层协议(即 GCC)支持。WebRTC 允许灵活地重 新实现视频控制算法，并已被用于最先进的传输和视频应用研究，如 BBR、Salsify和 Concerto等。

我们的On-RL 实现本质上替代了Taobao-Live中现有的比特率控制模块。理想情况下， On-RL 的组件应该在Taobao-Live应用程序中实现。但是，由于在移动设备上缺乏训练 RL 神经网络的 API 支持，我们通过云辅助框架实现了 On-RL，如图 10 所示。除了视频通话 的发送方和接收方，我们还引入了一个 RL 服务器，在这个服务器上我们基于TensorFlow 实现了 On-RL 的三个设计组件(即两阶段迭代学习、协调学习和鲁棒学习)。在每个通话会话 期间，发送方维护一个连接并与 RL 服务器交换信息。它从接受方收集 RTCP 反馈(比如丢包、 延迟、吞吐量等)，并将它们作为 On-RL 的输入发送到 RL 服务器。然后 On-RL 处理输入并返 回一个动作(即目标视频比特率)给发送方，然后由TensorFlow执行。同时，服务器上的 On-RL模块定期更新其控制策略来实现在线学习。我们发现，从发送方到服务器的信息交换延迟在 大多数情况下只有 10 毫秒左右，这对视频通话的影响可以忽略不计，Sec.6.3 将对此进行验 证。

为了处理发送方和 RL 服务器之间可能的连接失败，我们还在发送方上实现了回滚机制，即如果连接失败，发送方自动降级到默认的 WebRTC 控制器。此外，RL 服务器大约每天在 轻载时间(通常在早上)执行一次模型聚合。

▐  RL 服务器

每个 RL 服务器是一个配备 32 内核，2.5-GHz CPU 和 65-GB 内存并且运行 Red-Hat Linux4.8.5-11 的 COTS PC，我们采用 TensorFlow1.15.2 版本来支持 On-RL 的神经网 络，由于 On-RL 高效的神经网络结构，每个服务器至少可以容纳 50 个并发用户，模型大小 为32KB，运行时内存需求为 0.5GB。目前，我们已经部署了 5 台 RL 服务器进行beta测试， 但是 On-RL 的高可扩展性是通过阿里巴巴云管理系统 Apsara来保证的，Apsara具有高 效的资源调度能力和在数百万台服务器上的负载平衡能力。

▐  仿真器和本地 testbed

除了可运行的app外，我们还开发了一个与现有工作中使用的 类似的trace驱动的仿真器。我们还构建了一个由客户机和服务器组成的本地视 频通话测试平台，其端到端网络带宽遵循我们从Taobao-Live会话中收集的Trace，并由 Linux TC执行。与操作应用程序不同，这些平台允许在已知带宽的基础上进行受控实验，这有 助于对结果进行更深入的诊断。

实验

---

在本节中，我们从三个方面评估 On-RL:

• 通过比较相同模型在不同操作环境(包括 仿真，测试平台和实际网络)下的性能来验证在线学习的必要性。

• 我们使用真实的用户群在运营的淘宝直播中部署和评估 On-RL。。

• 我们分别评估 On-RL 中的每个设计模块，以获得对在线训练的深入微观理解。
  

▐  评估方法

评估指标我们采用应用层和传输层指标进行综合评估，包括:

• 视频吞吐量和峰值信噪比(PSRN)，它们表征了视频帧的感知质量。

• 卡顿率，用于衡量视频通话Session的流畅程度。在淘宝直播系统中，每当数据包 RTT 超过 300 毫秒时就会发生停顿。但是， 在仿真/测试平台的实验室环境中，RTT 几乎不会上升到该水平，因此，我们采用 Taobao-Live的工程师所建议的，当瞬时视频帧速率降至 12fps以下时，就认为发生了卡顿事件。

• 我们还记录了传输层指标，包括视频通话期间的丢包率和 RTT，这有助于深入了解 On-RL 的行为并解释应用层的性能。

对比方法

我们将 On-RL 与以下代表视频通话技术的算法进行了比较:

• Concert ，它利用深度模仿学习优化了视频 QoE。作为一种半监督算法，Concert在具有真实网络 带宽的模拟器中进行训练。在这项工作中，除非另有说明，否则我们将使用其原始模型来运行 Concert，该模型经过了超过 100 万次的现实世界视频通话会议的训练。

• WebRTC ，这是最流行的基于规则的视频通话框架。WebRTC 已被整合到 Google Chrom和主流实时视频应用中，包括 Google Hangout，Facebook Messager，Amazon Chime和 Taobao-Live。

▐  验证在线学习的必要性

仿真器和测试平台之间的差距

我们首先比较了仿真训练的模型，即 Concert模型和2.2 节中描述的基本 PPO 模型的性能。为了确保公平性，我们在两个不同的测试环境模拟器 和本地测试床中使用相同的 3 小时的Trace。得到的视频比特率和卡顿率如图 11(a)所示，图 11(a)证实当测试在与训练相同的环境(即，Concerto-S-S 和 PPO-S-S)中进行时 Concerto和 PPO 工作良好。然而，当在测试平台(即 Concert-S-T 和 PPO-S-T)中进行测试时，性能会 显著下降。具体来说，它们的卡顿率分别提高了 64.9%和 51.2%，同时视频码率的偏差较小 (在 0.02 Mbps 到 0.1 Mbps之间)。
为了理解性能下降，我们绘制了一段 300 秒的模型操作(即视频比特率)与图 11(b)中的groud-truth带宽的对比。我们观察到，在仿真环境中，Concerto和 PPO 在高波动的情况下 都能非常紧密地跟踪带宽，平均偏差分别只有 17.4%和 13.6%。相比之下，在试验台环境中处 理相同的Trace时，偏差分别增加到 30.3%和 37.12%。综上所述，一旦部署环境与培训环境 不同，离线 RL 模型的体验就会变得陈旧，导致性能不能令人满意。

仿真/测试平台与真实网络条件之间的差距

我们进一步研究了真实网络动态下“离线 学习”的局限性。除了 On-RL 之外，我们有意将三个离线训练的模型集成到 Taobao-Live系 统中，包括在模拟器中训练的 Concerto 和 PPO 模型(称为 PPOt)以及在测试平台中训练 的 PPO 模型(称为 PPOs)。然后，我们随机选择Taobao-Live应用用户运行模型。请注意， 就如上文所述，经过离线训练的模型都在自己的训练环境中显示出令人满意的视频 QoE。我 们在总共持续 10 小时的随机视频Session集中绘制了图 12 中的平均视频吞吐量，卡顿率,数据包延迟和丢包率。我们发现 On-RL 实现了效果最佳的视频 QOE。尤其是，它在视频吞吐 量方面比最适合的 ML 方案“Concerto”好 31.9%，在卡顿率方面降低了 78.3%。另一方 面，PPOt和 PPOs在两个指标上都表现出较大的 QOE 差距。同时，On-RL还有最小的数据 包延迟和丢失率，这证实了其应对网络动态的能力。结果进一步验证了在线学习对在实际网 络条件下优化实时交互式视频应用程序的必要性。

▐  真实直播环境中的系统级评估

我们向真实用户分发了配备 On-RL 的 Taobao-Live Beta版，以进行大规模的系统级评 估。我们从 30 个城市(国外 3 个，国内 27 个)招募了 151 个用户，并从中收集了 543 小时的视频通话会议。在每个Session的Trace中，我们以秒粒度记录网络/应用程序性能指标 (第 6.1 节)，这些指标总共形成了 4.55 GB 的数据集。当前，On-RL 仅支持iOS，最终用户 设备的范围从IPhone7 到 Iphone11 Pro。为了公平起见，我们让每个在前 10 分钟使用默 认的 WebRTC，然后再切换到 On-RL。这样，我们可以粗略地认为这两种算法都经历了几乎 相同的网络条件。

整体表现。

表 1 总结了所有Session的平均 QoE 指标。我们观察到:

• On-RL 在传输层 指标方面取得了显着改善:数据包丢失减少了 23.5%，往返时延减少了 9.92%。

• 传输层 的优势转化为应用层的性能提升，即在保持几乎相同的视频吞吐量的同时，将卡顿率降低了14.22%。值得注意的是，此处的卡顿率与 Concerto中的停顿时间度量标准不同，用户 群也有所不同(151 VS. 6)。因此，真实世界的评估结果不能直接比较(在第 6.2 节中已经给 出了在相同条件下的直接比较)。此外，与由仿真器/仿真器驱动的基于 RL 的 VoD 系统相比，性能提升似乎不大，这主要是因为可操作的视频通话系统涉及具有更多异构网络条 件的实际用户。下面我们对结果进行更深入的分析。
  

细粒度性能细分

我们根据不同的会话属性对用户进行分组，并在图 13 中重新标注评 估结果。 这里，每个图例标签后面的数字代表性能指标的平均值。

(1) 4G VS. WiFi。对于 4G 而言 On-RL 显著降低了 68.7% 的卡顿率，并略微增加了视频吞 吐量，而在 WiFi网络上有非常接近的性能(差异在 3% 以内)。相应地，在 4G 网络中，丢包 率和 RTT 的减少更加显著。对于淘宝直播 用例，大多数 WiFi用户都呆在相对固定的室内 环境中，而 4G 则倾向于提供更多动态的室外场景。 因此，实验表明，在处理动态网络条 件时，On-RL 的优势更加突出。

(2) 动态与稳定网络。 根据视频吞吐量的变化情况，将所有Session分为稳定 / 动态两 类(用 0.197 Mbps的吞吐量标准差均值作为分隔动态和稳定的阈值)。我们发现，On-RL 在 动态网络上显著地提高了 QoE，而在稳定网络上则不那么好(有时稍微差一点)。 例如，动态 网络的平均视频往返时延从 171.77ms 降低到 80.34ms，而稳定网络的平均视频往返时延从 42.75ms增加到 48.89ms。 其他指标也有类似的趋势。对于以上情况，我们推测主要原因 在于 On-RL 有在网络动态的情况下探索和密切跟踪可用带宽的能力。 如果网络带宽是稳定 的，On-RL 的探测机制可能会导致过载，从而导致相对较低的视频质量。

(3) 高质量与低质量的网络。 我们进一步分类的视频会议根据经验观察的网络条件。 如果一个Session的吞吐量大于所有Session的平均吞吐量，我们将相应的网络质量视为高，否则视为低。 我们发现 On-RL 在低质量的网络条件下表现得更好。

▐  OnRL 的各个模块详细分析

我们现在分别研究 On-RL 内部各个设计模块的影响。在这里，我们在我们的测试平台上 进行受控实验。这主要是因为:

• 正在运行的淘宝直播不允许对最终用户进行单独的模块测 试。

• 我们需要真实的带宽来深入了解每个模块的行为，这是在现实网络中运行淘宝直播时 所没有的。
  

从聚合学习中获得的收益

我们首先通过比较聚合模型(Agg-Mode)和从头开始的模型 (Src-Mode)的性能来演示利用先前学习经验的收益。更具体地说，我们从随机选择的淘宝直播Session的Trace中训练了 8 个不同的模型，每个持续时间超过 2 个小时。然后，我们按 照 2.3 节中的规定，通过求平均值将它们聚合在一起。图 14(a)绘制了在持续 1 小时的同一 组Trace上运行Agg-Mode和Src-Mode时的视频吞吐量、PSNR 和 fps。我们发现,Agg-Mode在所有与 QoE 相关的重要指标上都优于Src-Mode:吞吐量、PSNR 和fps增益分别 为 18.2%、41.1%和 47.6%。此外，我们还可以观察到，Src-Mode下的 PSNR 较低(<15dB)， 表明图像质量在开始阶段非常低，这说明了在没有任何经验的情况下开始的成本。

为了进一步理解上述结果，我们在图中分析了这两个模型的行为(即视频发送比特率)。在图 14(b)中我们看到 Src-Mode通常发送比可用带宽更多的流量，这会导致拥塞，从而降 低 QoE。此外，Src-Mode的行为表现出比Agg-Mode高 47.62%的方差，这表明Src-Mode以Overshoot/Underuse为代价来努力探索可用带宽。

聚合中涉及的模型数量的影响

我们随机使用 10 小时Trace训练 15 个不同的模型，并 从其中选择 0 个(即从头开始)、5 个、10 个和 15 个用于聚合。我们在相同的 1 小时测试Trace上检查了所得 4 个聚合模型的性能，如图 15 所示。我们观察到:

• 与 0 聚合的情况相比， 5、10、15 个模型的聚合分别降低了 77.1%、80.7%、83.7%的卡顿率。

• 虽然模型聚合也提高 了视频吞吐量，但增益相对较低，分别为 10.8%、21.27%和 21.3%。

总体而言，参与聚合的模 型越多，聚合模型拥有的群体智能就越多，就越能更好地应对复杂的网络动态。

加权聚合的效果

我们以 3 种方式聚合了 7 个随机模型:平均模型、不进行平均的单个模型(命名为 Model-1)和加权模型(将最大权重 1/2 分配给 Model-1，将 1/12 的最大权重分 配给其余模型)。在这里，我们有意从 Model-1 的用户中选择一个Trace，三个模型在该Trace上运行。从图 16 我们观察到，当吞吐量相似(0.75、0.79 和 0.78 Mbps)时，加权模型和 Model-1 的卡顿率分别比平均模型低 76.8%和 68.5%。结果表明，对于已有训练模型的现有用户，在 对其自学习模型进行优先级排序的同时，聚合大量模型将获得最优的 QOE。

处理 RL 动作偏差的效果

我们比较了有和没有处理动作偏差的两种模型，分别在相同 的随机选择的持续 2 小时的网络Trace下运行。从表 2 中的结果我们发现，通过将偏差作为 RL 的额外输入，卡顿率显著降低了 55.4%，丢包率降低了 10.3%，吞吐量(0.02 Mbps)和 PSNR(1.68dB)略有下降。因此，在线训练的性能得益于对动作偏差的显式学习，因此即使动 作没有严格执行，该模型也可以获得较高的性能。

鲁棒混合学习的效果

现在我们运行带有或不带有鲁棒混合学习机制的 On-RL，分别标 记为 RL-only 和 Robust-RL。表 3 总结了两种方案在相同的 1 小时Trace上运行时的性能。 我们观察到 Robust-RL 可以显着提高鲁棒性:卡顿率和丢包率分别降低了 56.9%和 63.5%。 从视频清晰度的角度来看，Robust-RL 保持几乎相同的吞吐量，同时将 PSNR 提高了 3.57dB。 为了更直观地了解 Robust-RL 的效果，图 17 展示了 150s的实验Trace片段。我们发现，当 RL 性能不佳时(例如，在 100s 至 150s之间)，损耗和延迟性能会急剧下降。Robust-RL 会 设法迅速切换到保守的 GCC 算法，以避免 QoE 降低。

相关工作

---

▐  低延迟视频传输(Low-latency video transport )

实时互联网视频应用对数据传输协议 提出了最严格的要求。虽然传输层相关协议已经研究了几十年，但新的网络特性和应 用不断出现，继而不断生成新的算法设计。与传统拥塞控制协议中常用的数据包丢失度量相比，许多新兴系统以低延迟为目标，并利用数据包延迟作为拥塞控制的 早期指示器。虽然这些方法可以更好地平衡延迟与接收端吞吐量之间的权衡，但它们依赖于 一组手工控制的规则，无法处理不断增加的网络异构性和动态性，特别是对于移动网络。

从 Remy开始，利用机器学习模型，特别是 RL，自动生成比手工规则更强的自适应控制规则。Remy探索了一个马尔科夫模型(即，一种列表式的 RL)来优化拥塞控制算法。Pensieve采用 A3C RL 算法预测最优 VoD 比特率，满足瞬时变化的网络条件。Indigo提出了一种基于模仿学习(IL, RL 的一种子类型)的算法来改进 VoD QoE。最近的一个系统 Concerto也设计了一个 IL 算法来更好地协调视频通话的编解码器和传输层。在取得显著 进展的同时，这些模型都在离线的模拟器或仿真器上进行了训练。根据报告和我们的实验所证实的‘仿真-现实’之间的差距，这些方法在实际网络条件下进行大规模测试时，通常可以获得微小的性能增益。

最近的研究工作在现实世界环境中对基于机器学习(ML)的视频流算法进行了 改进和评价。特别地，ABRL对 Pensieve 算法进行了多种定制设计，以适应运行 Facebook VoD 系统时的独特挑战。Puffer]构建并运行了一个 VoD 开放平台，并在真实 环境训练了一个监督学习模型，即，使用从实际部署中收集的跟踪。与这些系统相比，OnRL 具有两个不同之处: 

• 大部分情况下，这些工作中的 ML 模型仍然是离线训练的(虽然使用了真实世界的 trace)，因此需要避开在线训练带来的独特挑战，例如并行学习和鲁棒学习。

• 他们专注于 VoD 应用，这不同于交互式视频通话，即对当今的互联网服务提出了更苛刻的 时延及视频质量要求。

▐  在线学习(Online Learning)

经典的在线学习提倡使用动态的数据流进行训练， 也称为终身学习或连续学习。其显著特点是在新环境下不断完善预测模型，而不是 使用事后更新的训练模型。从最早的在线梯度更新到最近的元学习，人工 智能社区在在线学习的理论方面做了大量的研究工作。在线学习很少被用于网络优化算法 中。PCC和 PCC-Vivace是最近提出的共享一个在线学习协议的拥塞控制协议。它们 利用探测机制来不断优化网络效用目标函数。Park提出了一个开放的平台，以方便在 RL 的传统应用领域之外，进行在线 RL 解决计算机系统问题的实验。据我们所 知，OnRL 是第一个适应在线学习以解决实时视频通话的独特挑战的算法。

▐  联邦学习(Federated Learning)

联邦学习是一种分布式机器学习体系结构，其中数据存储在 分布式本地设备上，而不是存储在中央服务器上。通常，联邦学习的目的是在保护隐私 的同时聚合多个用户的体验，并减少过度的交流。OnRL 的学习聚合组件受到联邦学 习概念的启发。但是 OnRL 在解决视频通话优化的实际问题方面走得更远，包括设计特定 的适合视频通话的 RL 网络结构，在视频流量动态的情况下执行 RL 的动作，并通过设计混 合学习机制来增强视频的鲁棒性。

讨论

---

▐  On-device 在线学习

我们目前部署的 OnRL 采用了云辅助(cloud-assisted )架构。关 键的设计模块位于远程云服务器，而不是移动设备，以适应缺乏移动平台的 RL 训练。我们 注意到主流的 Tensorflow-Lite和 Core-ML只允许执行预先训练好的 RL 模型，即它们只支持推理，但不支持训练。据我们所知，在最近的工作中，其支持移动端神经网 络训练的平台是用 Java 开发的，很难与 Taobao-live app 在线集成。然而，随着神经处理 单元(NPUs)在移动设备上的快速发展及可用性，在移动设备上进行神经网络训练将是可行 的。且基于设备的训练将消除部署 RL 服务器的开销和成本，这将促进 OnRL 等在线学习算 法的广泛使用。

▐  自适应聚合学习

在本文中，通过设计加权线性集合，已验证了学习集合的重要性。我 们推测，根据不同的 session 进行更细粒度的聚合，例如根据 session 场景(室内、户外步 行或驾驶)或网络类型(WiFi、4G)对用户进行分组，可能会进一步改进视频 QoE。我们计划 在 OnRL 的下一阶段尝试这种自适应聚合方法。

▐  将 RL 与基于规则的算法更紧密地集成

第 6.3 节中的评估表明，RL 在处理网络动态 方面表现出显著的优势，但有时在稳定的网络条件下，RL 的性能低于基于规则的协议(如 WebRTC)。根据网络的动态级别，可以将 OnRL 和基于规则的算法集成在一起，就像混合 学习方案中所做的那样。我们把这部分作为下一步工作。

总结

---

在这项工作中，我们设计了一个在线强化学习的实时视频通话系统 OnRL。我们解决了三个 独特的挑战: 从并行视频 session 中学习;考虑视频本身动态性的 RL 动作执行方法;避免减 少 RL 产生灾难性决策所造成的 QoE 损失。对主流业务视频通话系统的实际评估表明， OnRL 的性能优于最先进的解决方案。我们相信 OnRL 暗示了一个新的方向，如将在线学习 纳入更多的视频通信应用，如 VoD、360 全景视频、虚拟现实等。

内容社交互动团队

淘系内容社交互动平台是阿里集团内容与直播的业务高地和人才高地。是淘宝业务增长的发动机和下一代电商模式升级核心推动玩家。在不断的探索中，秉承 "WIN FAST" 理念，我们成功孵化了“淘宝直播”这一创新业务，并在业务中完成了阿里内容平台的升级。我们拥有广阔的空间，诚邀算法、多媒体、数据、服务端、无线端、前端、测试、产品等各产品技术领域人才加盟。

如果您有兴趣可讲简历发至：zhongsheng.cxj@taobao.com，期待您的加入!

淘宝内容社交互动平台近期在北京成立了新的研发中心，对淘宝内容社交互动平台感兴趣的小伙伴，欢迎点击「阅读原文」查看详细岗位信息。

✿  拓展阅读

作者|陈虓将（仲升）

编辑|橙子君

出品|阿里巴巴新零售淘系技术