效果广告点击率预估近期实践：在线学习

作者简介： 薛伟， 腾讯专家工程师。

1. 引言

距离笔者上次发文章[1]已经过去两年多的时间了，两年的时间对于一个团队和一个产品来说确实不算短了。在过去的数年中，团队一直聚焦在精准推荐，特别是效果广告推荐上，持续耕耘技术，和产品一同成长。在2013年和2014年两次作为项目联合团队成员获得了公司年度大奖（2013年广点通项目团队，2014年社交效果广告项目团队），在2014年作为联合团队成员获得了公司级的技术突破金奖（效果广告实践中的全流程实时计算框架体系）。

技术钻研如逆水行舟，不进则退。公司的广告业务发展非常迅猛，有目共睹，激烈的外部竞争和客户越来越高的期望，都要求我们的技术不断进步；与此同时，我们也的确在生产实践中遇到了不少的技术问题和挑战，这些都促使我们在技术上不断的尝试突破。经过两年多时间的技术钻研和应用实践，同发表上一篇KM文章时的技术状态相比，团队和项目在技术架构和一些关键技术点上都向前迈进了一大步。我们打算通过几篇文章做一个简单的经验分享，这些文章会按照在线学习和深度学习两个技术方向做一个大致的划分。笔者会以两篇文章作为整个系列的开头，团队的同学会陆续有文章发表来不断充实这个系列。作为开篇，笔者的文章会更偏向于问题分析和技术思路阐述，主要是文字内容，更多的技术细节会放在后续的文章中来介绍。

2. 从模型快速更新到在线学习

从某种意义上来说，本文是笔者前文[1]的后继。在前文中，我们已经分析了类似效果广告点击率预估这种场景下的模型快速更新的需求，给出了在当时看来比较稳妥的一套技术方案。这套方案本质上仍然是离线训练，其中训练数据是流式生成的，以分钟级延迟落地HDFS上；模型训练的算法跑在Spark上，利用Spark的内存计算能力使离线模型训练的速度提升一个数量级；待模型训练结束后，立即将得到的模型推送到实时推荐引擎上，完成模型的部署。

如今，模型快速更新的需求仍在，这已经成为广告精准推荐领域内的一个共识，感兴趣的同学应该能够在KM上找到不少推荐方面的文章或多或少的共享这一个观点。在过去两年中，我们从数据，算法和系统三个方面对上面这套方案做了持续的改进，在架构不变的情况下挖掘其潜力，持续地支持了产品效果的提升。但是我们也越来越深刻地感受到这套方案的局限性，简单列举如下：

1. 数据先落地HDFS，然后再从HDFS加载，存储开销较大且随着训练数据量的增加而增加。
2. 训练数据需要加载到Spark集群各节点的内存中供模型训练迭代使用，内存需求量大，且随着训练数据量的增加而增加。这不仅对集群机器型号的要求高，也在一定程度上限制了方案的伸缩性。
3. 随着训练数据量和特征的增加，模型尺寸会越来越大，训练过程中的通信开销和计算开销都会增加，这也限制了方案的伸缩性，使得模型的更新速度变得不那么迅速了。

上述局限性已经严重制约了点击率预估模型的进一步优化，要求我们在技术上做出突破。

随着人类积累的数据量越来越大，种类越来越多，蕴含的商业价值越来越高，大数据成为了一个很热的技术和商业话题。大数据分析和挖掘是大数据变现的核心环节，因此也受到了很多的关注。若从大数据的视角来看，效果广告是公认的典型的大数据应用之一，而效果广告点击率预估则是典型的大数据分析和挖掘，我们需要在遇到瓶颈时升级我们的方案来持续释放大数据中蕴含的效果提升潜力。

近年来离线大规模机器学习技术在大模型训练方面进展颇多。出现了像DistBelief[2]和Petuum[3]这样的系统和平台，支持超大规模训练数据集和超大模型训练，它们部分地解决了上面提到的一些局限性。但是从使用角度来看，它们毕竟还都是离线训练，如何在数据量持续增加的情况下做到快速乃至实时的模型更新，这并非它们的首要技术目标，因此也就无法完全解决我们面对的挑战。

思虑至此，我们很自然地就会选择走另一个方向——在线学习（online learning）。实际上，正如[1]末尾提到的那样，我们在研发上一代方案之初便认识到，线上模型更新（online model update）是未来很有前途的模型快速更新方案，这方面的尝试我们也一直在做，并在15年成功应用于线上生产系统，带来了显著的效果提升。

在线学习并不是一个新概念，相对于有限的存储和计算资源来说，数据量太大的问题其实一直都存在，人们很早就在思考在线算法（Online Algorithms）和机器学习的结合[4]，也就是在线学习。同传统的离线批处理式的机器学习相比，在线学习的最大特点在于数据的到来和用于模型训练都是在线进行的，模型训练程序无法一次性拿到和存储所有的训练数据，对训练数据的访问只能是顺序的。因此，在线训练是一种流水线的处理方式，也就无需使用巨大的存储空间，而且计算的延迟和通信的延迟可以彼此有效的掩盖，天生具有良好的伸缩性，可以支持超大的数据量和模型。从某种意义上来说，如果我们可以用在线学习的方法来解一个机器学习问题，我们就大大抬高了处理问题规模的天花板，而这种天花板的升高带来的好处是显而易见的。

在线学习的理念虽然出现的较早，但是其受到广泛关注并在较多的领域取得成功应用还是最近十年的事情，这其实也是得益于数据量和模型规模的增长，或者说，大数据的发展。一方面，面对前面列出的那些问题，大家不约而同地选择了在线学习[5][6][7]的方案来应对，另一方面，大数据的无处不在也使得在线学习的优势可以得到充分的发挥。

值得指出的是，在线学习只是一个机器学习的范式（paradigm），并不局限于特定的问题，模型或者算法。因为有实际的工业需求在，这个领域的研究发展很快，不断有新的模型和算法被提出。对在线学习做完整的综述显然超出了本文乃至本系列文章的范围。本文要分享的是我们在解决生产问题过程中所做的一些思考和经验摘要。感兴趣的同学可以继续看我们的后续文章和参考文献。

3. 技术方案和应用效果

图1 在线学习技术方案架构简图

3.1 架构

读到这里，其实在线学习的整个方案架构已经比较明确了，如图1所示，类似的图很多见[5]。流式训练数据生成的环节还会继续保留，原有的流式训练数据生成拓扑后面会直接接一个流式模型更新的拓扑，训练数据不是先落地HDFS然后再从HDFS加载，而是直接用于模型更新。架构中会有一个逻辑上的参数服务器用来存放模型，不同的在线学习模型和算法需要在参数服务器和流式训练拓扑中编写代码来实现特定于该模型和算法的更新方法。随着训练数据生成拓扑和模型更新拓扑的运行，参数服务器中存放的模型会得到持续不断的更新。与此同时，这样的更新也会同步给实时推荐引擎，从而立即用于线上的推荐。

可以看到，从事件（点击/曝光/转化等等）发生，到形成一条日志，再到形成一条训练数据，再到模型更新，再到用于线上推荐，整个过程都是流式的，从头到尾的平均延迟可以做到秒级。与此同时，无论是训练数据生成和模型更新两个拓扑，还是参数服务器，都具有良好的伸缩性，可以支持大规模的模型和大数据流。

3.2 模型和算法考量

正如前面提到的，可以划到在线学习这个范式里面的模型和算法有很多，而且还在不断增加。比较著名的有FTRL-Proximal[5]和AdPredictor[6]，这两个都是工业界有过大规模应用的，自然是被竞相效仿的对象。关于它们的原理和实现的细节可以阅读原始文献，本系列的后续文章也会有介绍。

依个人浅见（仅供参考），这两个模型和算法代表了两大类实现在线学习的思路，这里我们粗糙地借用一下wikipedia的分类法[8]。一类是所谓的对抗学习模型（adversarial model），FTRL-Proximal可归入此类，这类模型和算法的目标是在在线的场景下最小化“后悔（regret）”。这个思路也常被称作是在线（随机）优化（online stochastic optimization）。另一类是所谓的统计学习模型（statistical learning model），按照wikipedia的说法，这类模型和算法的目标是最小化期望“风险（risk）”。然而，个人认为这个思路放到贝叶斯推理（bayesian inference)的框架下才能释放其最大价值。实际上，适用于各类概率图模型（probabilistic graph model）的贝叶斯推理算法有很多，其中不乏适用于在线学习场景的，AdPredictor就是一个例子。无论是在线（随机）优化，还是贝叶斯推理，背后都有比较完善的理论支持，且有大量的文献。作为初窥门径的实用主义者，笔者在这里斗胆提到它们，只是为了分享寻找，设计和选择在线学习模型和算法时的一点思路。

3.3 系统考量

架构，模型和算法，最后还是要系统来承载。数据平台部经过多年的技术积累，手边可堪一用的系统颇多，当我们着手实现上述架构的时候，更多的是从现有系统中挑选和改进，而不是从头来。

先来看参数服务器，在线学习需要怎样的参数服务器呢？第一，其存储结构应该可以包容多种算法模型；第二，应该性能优异且支持平行扩展，从而能够容纳大模型并对其计算做负载均衡；第三，应该支持7x24小时不间断运行，高度可靠，有充分的容错机制；第四，应该可以方便地扩展接口，实现特定于算法的逻辑功能。目前开源社区有很多机器学习平台都有自己的参数服务器，然而完全满足上述四条需求的并不多，特别是对高可靠运营的需求，盖因社区的参数服务器大多针对离线模型训练的场景，而非不间断在线学习的场景。数平有一个经过多年大强度运营考验的全内存分布式cache系统——TDE[9]完全满足上面的四个要求，所以我们选择在TDE的基础之上来开发参数服务器，通过扩展TDE的功能来支持各种在线学习的模型和算法。

再来看前端模型更新所用的系统，如图1所示，这是一个流式的处理过程，数平的实时计算平台TRC里面的TDP[9]就是干这个的，此外还有spark streaming可以实现同样的处理功能，它们都是久经考验的可靠系统。在实际生产中我们选择了TDP，道理很简单，因为上游的流式训练数据生成一直用的是TDP，继续使用TDP比较方便。我们在TDP上为每种模型和算法实现了专门的拓扑，支持从零训练一个模型并且一直更新下去的全流程，以及从mini-batch尺寸、预热历史长度、特定于算法的参数，到模型质量实时监控的全套配置，系统的伸缩性和容错也是久经考验的。后续文章会有详述。

最后来看在线学习与实时推荐引擎的对接。此前我们采用的是模型文件推送+模型动态加载的机制来将新训练出来的模型推送到线上。当模型变成在线学习之后，这个推送的频率可以更高。目前线上的生产系统仍然还是走这套机制。然而，最终的方案将是随着模型更新实时地推送模型到推荐引擎，为此我们将引入可靠的消息中间件Hippo[10]来完成这最后一公里的推送，最终贯通全流程。这一实现将在不远的将来用于线上生产系统。

值得在本节末尾再提一句的是，整个系统架构的升级不仅抬高了处理问题规模的天花板，也大大降低了模型训练端到端的资源消耗。在数据量，特征量均有显著增加的情况下，实际使用的机器资源有成倍的减少，省出来的资源可以拿来支持压力越来越大的在线预测，可谓是雪中送炭。

3.4 生产运营考量

从离线模型训练发展到在线学习，这个改变的影响是深远的。天花板抬高了之后，模型会变得越来越复杂，越来越准，反应越来越敏捷，也就会越来越敏感。端到端流式处理的数据流中，任何一个环节的非正常波动或者故障，都有可能给模型训练或模型预测造成干扰，进而导致点击率预估效果的波动，甚至直接影响实时的现网收入。在广告收入快速增长的今天，剧烈的波动是要尽力避免的。面对各种可能的波动原因，我们需要从全流程的各个环节着手应对。

首先来看模型和算法，实际上实用的在线学习模型和算法，不论归属于哪一类，一般都会在原理上提供一些手段来应对训练数据中的波动的。例如，FTRL-Proximal支持自适应学习率和正则化，这都有助于抑制模型的剧烈波动。使用贝叶斯推理的概率模型更是可以利用适当的先验设定和大数据量来抑制模型的剧烈波动。工业界有一些做法是通过引入较粗粒度的历史统计量作为特征，或者直接将其用作平滑手段。这种方法我们使用的不多，一方面是因为我们用的模型的原始特征相对较多，交叉维度更多，计算历史统计量的开销也不低，而且不恰当的设定可能反而不利于发挥模型的拟合能力；另一方面是因为历史统计量本身也面临波动的影响，我们更希望依托模型和算法本身的能力。

再来看系统，正如前面提到的，无论是参数服务器、TDP还是实时推荐引擎，都提供了久经考验的容错和故障恢复机制。然而对于叠加其上的在线学习逻辑来说，上述机制只是基础保障。我们规划并实现了一些应用层的容错和故障恢复机制作为补充，后续文章会有介绍。

除此之外，我们也在全数据流监控上下了一番功夫。模型、算法和系统的耐受力毕竟是有限的，快速准确的捕捉到波动和故障的源头对于控制和减少损失十分重要。目前，日志数据量、训练数据量、各主要特征的分布指标、模型实时质量指标、线上效果指标等均在监控之列，关键指标还配置有NOC告警。

3.5 应用效果

截止2015年年末，在线学习的模型和算法已经覆盖了广点通超过一半的流量，在年末的pCTR效果放量中取得了CTR+CPM 8%+的提升，部分重点广告位取得了15%以上的提升，有力地证明了在线学习用于效果广告点击率预估的实用价值。

4. 展望

从模型快速更新到模型在线学习，这是一个自然的发展过程。技术天花板抬高了，以前无法处理的大数据量、大特征量和大模型，现在都可以有效处理而不会导致模型更新变慢，这对pCTR效果提升的好处是显而易见的。我们已经实现了这样一套具有良好伸缩性和可靠性的在线学习系统，并且在生产实践中取得成功应用。纵观业界，不少公司也在生产中使用了各种在线学习的模型和算法。同在线学习的广阔空间相比，目前我们的实践还是很初级的，未来我们一方面会去继续发挥在线学习的优势，拥抱更多的数据和特征，另一方面还会尝试更为复杂的模型和算法。

从业务需求和痛点出发寻找技术思路，这是我们一贯的做法。在线学习解决了我们遇到的一些痛点，还有其他的痛点，所以，本系列后续文章除了继续介绍我们在在线学习方面的实践细节之外，还会谈一谈我们把深度学习应用于效果广告点击率预估的工作[11]。

参考文献

[1] 快速模型更新及其在腾讯精准推荐中的应用 [2] Jeffrey Dean and Greg S. Corrado and Rajat Monga and Kai Chen and Matthieu Devin and Quoc V. Le and Mark Z. Mao and Marc’Aurelio Ranzato and Andrew Senior and Paul Tucker and Ke Yang and Andrew Y. Ng, Large Scale Distributed Deep Networks, NIPS 2012. [3] Eric P. Xing, Qirong Ho, Wei Dai, Jin Kyu Kim, Jinliang Wei, Seunghak Lee, Xun Zheng, Pengtao Xie, Abhimanu Kumar, Yaoliang Yu, Petuum: A New Platform for Distributed Machine Learning on Big Data, KDD 2015. [4] Avrim Blum, On-Line Algorithms in Machine Learning, In Proceedings of the Workshop on On-Line Algorithms, Dagstuhl, pages 306-325, 1996. [5] H. Brendan McMahan, Gary Holt, D. Sculley, Michael Young, Dietmar Ebner, Julian Grady, Lan Nie, Todd Phillips, Eugene Davydov, Daniel Golovin, Sharat Chikkerur, Dan Liu, Martin Wattenberg, Arnar Mar Hrafnkelsson, Tom Boulos, Jeremy Kubica, Ad Click Prediction: a View from the Trenches, KDD 2013. [6] Thore Graepel , Joaquin Quiñonero Candela , Thomas Borchert , Ralf Herbrich, Web-Scale Bayesian Click-Through Rate Prediction for Sponsored Search Advertising in Microsoft’s Bing Search Engine, ICML 2010. [7] Cheng Li, Yue Lu, Qiaozhu Mei, Dong Wang and Sandeep Pandey. Click-Through Prediction for Advertising in Twitter Timeline, KDD 2015. [8] Online machine learning [9] 腾讯实时计算平台（TRC）系列之一：初识TRC [10]【Hippo系列-系统介绍】分布式高可靠消息中间件Hippo [11] 效果广告点击率预估近期实践：深度学习