腾讯TRS在线搜参在搜推广业务中的探索和实践
导读 本次分享的主题是腾讯 TRS（Tencent Recommendation System） 的自动调参技术在搜广推业务中的探索与实践。TRS是腾讯的推荐中台，旨在为各推荐业务提供基础工程架构与算法能力支持，自动调参是TRS中台里面的一个核心算法组件，它在腾讯内部的业务场景中有很广泛的应用，也取得不错的业务收益。
今天的介绍会围绕下面五点展开：1. 自动调参背景介绍
2. 自动调参优化技术演进
3. 自动调参系统化方案
4. Reference
5. Q&A
分享嘉宾｜李裕东 腾讯 推荐系统中心Tech Lead&算法专家
编辑整理｜李润顺
内容校对｜李瑶
出品社区｜DataFun
01
自动调参背景介绍
超参数一般是指模型训练中学习不到的，需要预先定义的参数，比如，在机器学习模型里面的超参数包括训练过程中的参数(学习率、batch size)、模型结构（隐层层数、embedding size 等)、多目标多任务学习中的 loss 的超参数等。但今天我们介绍的特指在线超参数。
什么是在线超参数？特指在推荐/搜索/广告系统中的策略里需要人为设定的参数，比如，多目标排序阶段涉及的融合参数，召回、粗排、精排、每个环节涉及到的计算 quota 以及多样性的策略、探索策略、广告 adload 策略、生态流量控制策略等策略中人为设定的参数。这些在线超参在推荐业务里面普遍存在，对它做优化也有很大的业务价值。为了更好理解在线超参数这个概念，下面举三个实际的例子来阐述。
首先是多目标融合排序问题，推荐系统在粗排、精排、混排阶段都涉及对多种业务目标做融合排序。业务目标一般分 4 类：显式正反馈（关注、点赞、分享、收藏等）、隐式正反馈（播放时长、完播率、有效播放等）、显式负反馈（不感兴趣、举报等）、隐式负反馈（快速划走、短播放等）。业界常见做法是使用融合公式将多个目标分数计算出最后排序分数，而融合公式中“超参数”的设置会对最终的排序效果有非常直接的影响。
第二个例子是计算 quota 的分配问题，下图是常见的一个漏斗型结构，召回->粗排是其中一层漏斗的流程，这里的计算 quota 分配问题是指如何分配每一路召回计算候选 item 个数，使得在满足性能约束条件下整体效果最优的问题。粗排->精排也同样涉及计算候选 item 个数的分配问题，quota 数可以视为超参数，实际应用中根据用户以及场景的特征来做个性化、自动化调整，往往会比设置固定值有更好的效果。
第三个是多样性控制问题，比如说在视频场景，一刷有 5 个结果，这 5 个结果的分类一般最要做约束，例如同分类的结果最多出现 n 个。这里的 n 是人为设置的固定参数，其实也可以根据用户和场景的特点做个性化的一个动态调整，实现更好的效果。
最后从数据集分布、评估指标、评估的计算等维度，总结在线超参对比离线调参的特点：第一，在线调参数据集分布会动态的实时变化；第二，评估指标上面会有比较大的噪音，因为在线上小流量信号波动较大；第三，计算的约束上对在线流量资源要求较高，因为我们要在有限的业务流量下进行在线的参数调整，而离线调参涉及大规模数据训练，对计算资源要求较高；第四，对场景化、个性化这种适应能力，在实际的在线业务场景中要求更高。所以在线调参和传统的机器学习超参数调优，其实不是同等的概念，它会有一些新的挑战。接下来我们具体阐述下这里面的技术挑战和技术演进过程。
02
如图所示，在线搜参跟黑盒优化问题非常相似，我们不知道黑盒环境内部是怎么建模的，无法用梯度反向传播的方式求解。黑盒优化的过程一般是先初始化一组在线超参数，然后在黑盒环境里应用并收集反馈，基于反馈持续地更新算法并进行迭代寻优，以获取更优的超参数组合并在环境中生效，整个过程是自动迭代的。
这个问题主要面临 4 个挑战：
空间维度大：当空间维度比较大时，在线样本量在空间里面就会显得比较稀疏，从而造成维度灾难的问题。
回馈信号的计算代价大：系统环境中回馈信号计算成本高/计算时间长，用暴力穷举的解法很难解这个问题。
数据空间分布复杂：非凸函数、非光滑函数
实时系统环境下的新挑战：真实环境下数据实时变化，反馈信号存在比较大的噪音。比较有效的正反馈信息比较稀疏，这是它面临的一个核心挑战。
接下来会分别按贝叶斯优化（BO）、进化策略（ES）、强化学习（RL）介绍自动调参方案演进。
贝叶斯优化的整体流程如上图所示，线上的流量分为两种流量，一种是探索流量，一种是应用流量。探索流量给这个调参算法做探索调参，具体来说，会把这个流量分成很细化的组，不同的组对应不同的参数，然后收集各参数组的实际用户反馈信号，并根据反馈信号自动调整算法，算法会生成新的探索参数组，不断地进行这个探索迭代的过程。在一段时间之内，如果找到了更优的解，会让这个更优解生效到应用流量，应用流量就是大部分用户去体验到的效果，本质上是如何在有限的探索流量约束下，做参数调优的过程。
贝叶斯优化[1]的主要过程分为 3 个部分：
第一步会通过一个代理模型来模拟目标函数 f(x)，x 为待优化超参数，假设 f(x) 的取值符合正态分布。比如上图的紫色线就是真实分布，黑色线是我们所选的代理模型，它的作用是拟合真实分布。
第二步会初始化一些点，即初始化一些超参，然后到实际的环境中去收集反馈，收集到反馈之后，基于贝叶斯公式，根据先验收集到的反馈来更新后验分布。
得到后验分布之后，再用采集函数（acquisition function）来去决定下一步 x 的生成，通过 epsilon 来平衡探索和利用。图中黑色点是一开始初始化的点，红色点是根据本次更新后验分布后，根据采集函数计算所得，这个采集函数取值越高就表示是越想探索的点，用来决定下次迭代的时候，x 往哪个方向探索，不断的循环迭代优化。
通过不断地更新黑色代理模型这条曲线，最终可以拟合得到一个更加贴近真实分布的代理模型。
在优化过程中面临流量有限和收集反馈信号时间长、数据稀疏、噪音大的问题。我们可以对反馈信号采用类似 AB test 里的置信区间或者P值显著性检验的方式来降低噪音。另外因为流量有限，需考虑早停（Early Stop）的策略，如果一组参数效果比较差就提前释放。比如一种常用策略是计算贝叶斯回归曲线拟合预估最终值超越“当前最优解”的概率，如果低于阈值则提前终止。也可以基于中位数来控制早停策略，如果累计 N 天的 reward 低于中位数则提前停止。这些策略在实际场景中至少能够提升一半以上搜索效率。
贝叶斯优化，是非个性化调参算法，虽然会不断地去迭代更新参数，但对不同场景和不同用户它用的是同样的一组参数。然而，由于系统环境和用户偏好都在变化，不同用户采用相同的参数，很容易达到效果瓶颈。相比之下，个性化的调优可以突破这个天花板。另外在传统的多目标建模场景中，往往对单个视频做 pointwise 预估，缺乏“一刷”或“一个 session”粒度的更长期的价值建模。
个性化调优，相比非个性化调优多了一个 Agent模型（即参数预估模型）。Agent 模型的输入是用户和场景状态的特征，输出是当前这次请求所对应的个性化参数。实际应用场景中 Agent 模型的参数量往往都不会很小，当模型参数量增加到千或者万级别以上时，基于贝叶斯优化的方法在效果上会面临瓶颈。
那如何学习 Agent 模型的参数？它跟传统机器学习的模型不一样，没有具体的 label，没有可监督的信号。就是说对于特定场景、特定用户要生成什么参数是最优解，没有对应的 label 信号，用传统的深度学习监督训练的方法没办法解决这个问题。更适合解这类问题的方式是进化策略和强化学习，我们先介绍用进化策略的解决方法。
进化策略的核心思想比较简单，借鉴了自然界物种“进化”的思路。如下图可以看到岩石上面有各种老鼠，空中的老鹰看到后会吃掉一些老鼠，颜色比较鲜艳的和土的颜色不相似的老鼠会被吃得更多，和土地颜色比较像的老鼠会繁衍的更多，是一种物竞天择、适者生存的思想。它的主要流程可以描述为 6 个步骤。
这里可以将老鼠理解为要求解的超参数，也即要找到什么类型的老鼠/超参数是最适合环境的。首先是先生成种群，假设参数的分布满足 p(x|theta)，并随机采样进行猜测；然后在真实环境里面去评估种群的适应度；接下来根据适应度，选取最好的几个种群来作为下一轮繁衍的集合 S；进行繁衍，基于集合 S 更新分布 p(x|theta)；完成更新后，重复生成种群等过程，并不断地循环整个过程。
具体来看 ES 个性化调优，需要有一个 Agent model（参数预估模型），输入用户的状态、场景信息等个性化的特征，输出是要作用到实际环境中的超参数。ES 有很多不同的方法，包括 OPENAI-ES[2](ES 简化版，分布式计算的效率更高)、NES[3]、PEPG[4]、CMA-ES[5](基于斜方差矩阵做探索)等。
我们以 OpenAI 简化版的 ES 来介绍下技术原理，具体推导和执行过程如下图。首先 ES 算法生成种群参数，生效到 n 组探索流量中，每组探索流量对应一个 Agent 模型。每个 Agent 模型利用探索流量收集用户真实反馈，计算环境奖励值，并回馈给 ES 算法更新参数 theta。
那如何更新呢？其实是对reward 函数F(theta)期望进行建模。学习的目标是希望 reward 的期望值越高越好。通过一次性求导推导可得到上述公式，从而计算出梯度更新的变量。其中，参数 theta 服从正态分布，N 是种群数，r 是奖励值，epsilon 是每个种群变异的扰动值。基于梯度更新，我们就训练好 Agent 模型的参数。不需要像传统机器学习一样根据模型结构一层一层反向传播更新，计算复杂度较低。
总的来说，训练 Agent 模型参数主要分三个步骤：
step1：在初始化 theta 参数的基础上加 N 组符合 N（0，I）正态分布的 epsilon 扰动，生效到 N 组探索流量
step2: 在具体环境中收集到 N 组 Agent 模型对应 reward 值，reward 根据具体应用场景来定义。
step3：对 theta 参数做梯度更新，一次更新训练好模型之后，生效到主流量。继续循环 step1->step2->step3。
基于 ES 的个性化调参仍然有 3 方面的局限性：
支持的参数量有限。贝叶斯优化适用于参数量在 1000 以下的问题，ES 可支持的参数量是在千-10 万左右，对于 Agent 模型参数量达到 10 万以上的场景，ES 的优化效果存在很大的局限。
样本利用效率较低。因为 ES 算法的每个种群需要收集到足够的样本数据才能做一次 update，并不是每次用户交互都能 update。当 Agent 模型的参数量变大后，样本效率问题就会直接影响到调参效果。比如 Agent 参数量增加 10 倍，样本量可能要增加 100 倍才能达到更好的效果。
建模的过程中没有直接对每个个体的长期价值做建模。
通过引入强化学习，能解决上面所述的问题。下图给出了强化学习 vs ES 在各个维度上的对比，强化学习样本效率更高，但计算成本会比 ES 更高，因为 RL 要对参数网络做逐层反向传播。强化学习的探索方式是通过 action 扰动，对参数设置会比较敏感，不同设置不一定能复现效果。
下面介绍强化学习做个性化参数调优的具体方案。
强化学习基本概念的定义与调参问题非常 match。Agent 不断生成 action，action 即我们定义的超参数。在线环境就收集到两类信息，一类叫 State/ Obeservation，根据业务场景特征定义，一般包括用户特征+场景特征等。另一类是 Reward，是根据业务价值定义的奖励，比如用户的视频播放时长或完播率等，Reward 的作用是引导算法搜索的方向，也是业务期望提升的量化指标。
强化学习算法分 2 类，online RL 和 offline RL。online 的方式是每次用上一版的 Agent 交互数据更新下一版的 Agent 模型（如 TRPO[6]、PPO[7]、PPG[8]等），它有一个比较核心的问题是只能用到上一个版本的样本，没办法用到历史版本的样本，是增量式的训练方式。推荐系统探索组流量里信号是动态变化且有噪音的，这种方法会有模型不稳定的问题。offline 的方式通过 buffer 收集之前 N 个版本的交互数据样本，然后定期集中一次训练 Agent 模型，并更新到环境里（BCQ[9]、CQL、IOL），相对会更稳定。下面重点介绍 BCQ 算法的应用迭代优化。
BCQ 在线部分不再赘述，重点在离线部分。Replay buffer 是强化学习的样本集合，采用 Actor-Critic 结构（生成-评价两段式结构），Actor 是策略预估网络，输入当前状态 s 输出 action 使得价值预估网络 Critic 的 Q-value（业务价值，含长期价值）最大，两个网络联合学习。学习过程中长期价值的 Q-value 实际上没有真实的 label 值，导致模型无法训练。为了解决这个问题，使用了一个 trick，即接入Target 网络，为 Critic 模型提供 label 值，计算损失并训练模型。
但有个关键的问题，Target 网络需要提供“真实值”，但这个“真实值”是通过预估得到的，往往容易预估错误，我们压根不知道真实值是什么，只知道它越大就表示越好。这个问题叫价值预估误差/OOD actions，是说 Actor` 生成一个 action，在不同版本训练迭代过程中容易发生偏移，可能会出现一些异常的 action，Critic` 预估的时候会给它估出更高的值，这个更高值实际上是跟真实情况是有很大偏差的，会导致主网络训练发生很大的偏差，实际应用效果非常差。
针对由于数据集和当前策略所诱导的真实（s,a）分布之间不匹配的价值估计误差问题，BCQ 引入外推误差，并提出方案消除外推误差。通过 VAE（Variational AutoEncoder） Encode-Decoder 的结构来学习数据集中（s,a）的转移概率P(a|s)，并从中采样 a 输入到 Critic 价值预估网络，以消除外推误差。VAE 可以确保生成的 action 不会偏移太大，同时增加一个 epsilon 网络，避免太过于拟合之前的分布，增加 action 的探索度。
离线训练好模型后，在线推理的过程，唯一的区别是在 Agent 里面做了一个 VAE 的处理。具体来说，对于一个给定的状态 s，会对当前这个状态进行 10 次采样，通过 VAE 可以采样 10 个 action，然后采样的 10 个 action 再输入经过 Actor 网络和 epsilon 扰动网络后，得到待评价的 10 个 action，输入 Critic 价值评价网络选择 Q-value 最大的 action 作为状态 s 的响应（即超参数更新），环境生效后样本上报至 Replay buffer。
贝叶斯优化，适用对个性化没有要求、参数量比较少的场景，比如说 100 个参数量以内。进化策略更适合一些中等参数量的个性化场景，同时模型很轻量，计算成本比较低。强化学习的样本利用效率更高，它能够用到更大量的样本或者是更复杂的模型，效果也会有更好的提升。
但强化学习又存在效果不稳定的问题，那如何做到既保证效果更稳定，同时又能提升样本的利用效率呢？我们有一个探索是 ES 跟强化学习结合。如下图，有 N 个探索流量组，对应 N 个种群参数，抽取 N/2 做 ES，N/2 做强化学习。具体来说，在更新 ES 参数时，选择 N 个种群中表现最好的 1/2 种群参数来更新。强化学习则主要负责提升样本利用效率，探索出更好的 action/参数。
03
最后介绍下 TRS 中台实践中是如何规模化解决各个业务中在线调参问题的。实际涉及在线调参的业务场景非常多，如果每一个场景都是 case by case 解决的话，成本较高且难复用，需要考虑系统化、平台化的支持，且兼顾拓展性。所以我们通过系统化、平台化的方式，在各个业务统一用一套方案去解决问题，提升研发效率。
整套方案系统模块图如下图所示。右边是业务系统，左边是我们的 AutoTuning 系统，我们会提供一个 SDK 到业务系统，业务系统只需要接入这个 SDK 之后，就可以使用刚才介绍的这些调参能力。然后主要挑战在于在线服务压力和自动调参离线训练的组件（BO 算法组件、ES 算法组件、RL 算法组件），需要统一的平台去做管理和监控。
基于这套系统化的解决方案，能够更高效地支撑各个业务，目前已经在十几个业务里面落地，有非常多的正向发布，对业务的商业化和用户体验指标有大幅度的提升。
最后补充讲 2 个应用的例子。一个是多目标融合参数，实际上是采用 ES 调优算法（PEPG）的方案。调参过程中，不同的场景只需要定义好状态、Agent 模型结构、Reward 值就可以了，剩下的训练过程交给 AutoTuning 组件来完成。只需根据每个业务场景特点去适配定义，框架就可以自动完成更新、训练、监控、平台管理。
然后是实际的场景中的召回->粗排->精排 quota 分配的在线调参，调优算法采用的是 OPENAI-ES，应用方式也是类似的，也取得了非常显著的 vv 收益。
04
[1]贝叶斯优化：https://www.cnblogs.com/yangruiGB2312/p/9374377.html
[2]OPENAI-ES：https://zhuanlan.zhihu.com/p/333944376
[3]NES：Natural Evolution Strategies (NES, 2014)
[4]PEPG：Exploring Policy Gradients (PEPG, 2009)
[5] CMA-ES：https://zhuanlan.zhihu.com/p/30981469
[6] TRPO：https://arxiv.org/abs/1502.05477
[7] PPO：https://arxiv.org/abs/1707.06347
[8] PPG：https://arxiv.org/pdf/2009.04416.pdf
[9] Batch-Constrained deep Q- Learning：https://arxiv.org/pdf/1812.02900.pdf
05
Q1：每个 Agent 有多少流量数据能够得到充分的训练？
A1：实际过程中确保这些 Agent 至少要有 1 万样本才能保证反馈的 reward 比较置信，其实和做 AB test 是一样的。AB test 里面根据不同的反馈信号，可以从统计上算出需要多少样本量才比较置信。1 万是我们的一个经验值。至于获取多少流量，实际上需要参考每个业务场景的流量规模和统计意义上置信所需的样本量等维度来决定。
Q2：遇到过调参后时长提升，但是其它关键指标下降的情况，我们如何矫正调参的算法？
A2：主要是在 reward 设计中去平衡这两个目标，需要做一些精细化的设计，比如计算 reward 的函数中加上约束项，把不期望下降的关键指标加进去做约束，还可以重新设计 reward 函数，使得 reward 值越大，能反映到对哪个任务之间的偏好。在多个目标里面，其实需要有个偏好的设置，比如说是收入更大还是时长更大，更优先。
分享嘉宾
INTRODUCTION
李裕东
腾讯
推荐系统中心Tech Lead&算法专家
目前在腾讯负责推荐中台算法相关技术，曾任百度语音搜索技术负责人，主导研发语音搜索、智能助手等产品，其中语音搜索、多轮交互等效果在中文上行业第一。在搜索引擎、推荐系统、语音助手等技术领域有十多年研发经验。
限时免费资料
往期优质文章推荐
往期推荐
点个在看你最好看