上述局限性已经严重制约了点击率预估模型的进一步优化，要求我们在技术上做出突破。
近年来离线大规模机器学习技术在大模型训练方面进展颇多。出现了像DistBelief[2]和Petuum[3]这样的系统和平台，支持超大规模训练数据集和超大模型训练，它们部分地解决了上面提到的一些局限性。但是从使用角度来看，它们毕竟还都是离线训练，如何在数据量持续增加的情况下做到快速乃至实时的模型更新，这并非它们的首要技术目标，因此也就无法完全解决我们面对的挑战。
思虑至此，我们很自然地就会选择走另一个方向——在线学习（onlinelearning）。实际上，正如[1]末尾提到的那样，我们在研发上一代方案之初便认识到，线上模型更新（onlinemodelupdate）是未来很有前途的模型快速更新方案，这方面的尝试我们也一直在做，并在15年成功应用于线上生产系统，带来了显著的效果提升。
在线学习并不是一个新概念，相对于有限的存储和计算资源来说，数据量太大的问题其实一直都存在，人们很早就在思考在线算法（OnlineAlgorithms）和机器学习的结合[4]，也就是在线学习。同传统的离线批处理式的机器学习相比，在线学习的最大特点在于数据的到来和用于模型训练都是在线进行的，模型训练程序无法一次性拿到和存储所有的训练数据，对训练数据的访问只能是顺序的。因此，在线训练是一种流水线的处理方式，也就无需使用巨大的存储空间，而且计算的延迟和通信的延迟可以彼此有效的掩盖，天生具有良好的伸缩性，可以支持超大的数据量和模型。从某种意义上来说，如果我们可以用在线学习的方法来解一个机器学习问题，我们就大大抬高了处理问题规模的天花板，而这种天花板的升高带来的好处是显而易见的。
图1在线学习技术方案架构简图
读到这里，其实在线学习的整个方案架构已经比较明确了，如图1所示，类似的图很多见[5]。流式训练数据生成的环节还会继续保留，原有的流式训练数据生成拓扑后面会直接接一个流式模型更新的拓扑，训练数据不是先落地HDFS然后再从HDFS加载，而是直接用于模型更新。架构中会有一个逻辑上的参数服务器用来存放模型，不同的在线学习模型和算法需要在参数服务器和流式训练拓扑中编写代码来实现特定于该模型和算法的更新方法。随着训练数据生成拓扑和模型更新拓扑的运行，参数服务器中存放的模型会得到持续不断的更新。与此同时，这样的更新也会同步给实时推荐引擎，从而立即用于线上的推荐。
可以看到，从事件（点击/曝光/转化等等）发生，到形成一条日志，再到形成一条训练数据，再到模型更新，再到用于线上推荐，整个过程都是流式的，从头到尾的平均延迟可以做到秒级。与此同时，无论是训练数据生成和模型更新两个拓扑，还是参数服务器，都具有良好的伸缩性，可以支持大规模的模型和大数据流。
架构，模型和算法，最后还是要系统来承载。数据平台部经过多年的技术积累，手边可堪一用的系统颇多，当我们着手实现上述架构的时候，更多的是从现有系统中挑选和改进，而不是从头来。
先来看参数服务器，在线学习需要怎样的参数服务器呢？第一，其存储结构应该可以包容多种算法模型；第二，应该性能优异且支持平行扩展，从而能够容纳大模型并对其计算做负载均衡；第三，应该支持7x24小时不间断运行，高度可靠，有充分的容错机制；第四，应该可以方便地扩展接口，实现特定于算法的逻辑功能。目前开源社区有很多机器学习平台都有自己的参数服务器，然而完全满足上述四条需求的并不多，特别是对高可靠运营的需求，盖因社区的参数服务器大多针对离线模型训练的场景，而非不间断在线学习的场景。数平有一个经过多年大强度运营考验的全内存分布式cache系统——TDE[9]完全满足上面的四个要求，所以我们选择在TDE的基础之上来开发参数服务器，通过扩展TDE的功能来支持各种在线学习的模型和算法。
最后来看在线学习与实时推荐引擎的对接。此前我们采用的是模型文件推送+模型动态加载的机制来将新训练出来的模型推送到线上。当模型变成在线学习之后，这个推送的频率可以更高。目前线上的生产系统仍然还是走这套机制。然而，最终的方案将是随着模型更新实时地推送模型到推荐引擎，为此我们将引入可靠的消息中间件Hippo[10]来完成这最后一公里的推送，最终贯通全流程。这一实现将在不远的将来用于线上生产系统。
值得在本节末尾再提一句的是，整个系统架构的升级不仅抬高了处理问题规模的天花板，也大大降低了模型训练端到端的资源消耗。在数据量，特征量均有显著增加的情况下，实际使用的机器资源有成倍的减少，省出来的资源可以拿来支持压力越来越大的在线预测，可谓是雪中送炭。
首先来看模型和算法，实际上实用的在线学习模型和算法，不论归属于哪一类，一般都会在原理上提供一些手段来应对训练数据中的波动的。例如，FTRL-Proximal支持自适应学习率和正则化，这都有助于抑制模型的剧烈波动。使用贝叶斯推理的概率模型更是可以利用适当的先验设定和大数据量来抑制模型的剧烈波动。工业界有一些做法是通过引入较粗粒度的历史统计量作为特征，或者直接将其用作平滑手段。这种方法我们使用的不多，一方面是因为我们用的模型的原始特征相对较多，交叉维度更多，计算历史统计量的开销也不低，而且不恰当的设定可能反而不利于发挥模型的拟合能力；另一方面是因为历史统计量本身也面临波动的影响，我们更希望依托模型和算法本身的能力。
除此之外，我们也在全数据流监控上下了一番功夫。模型、算法和系统的耐受力毕竟是有限的，快速准确的捕捉到波动和故障的源头对于控制和减少损失十分重要。目前，日志数据量、训练数据量、各主要特征的分布指标、模型实时质量指标、线上效果指标等均在监控之列，关键指标还配置有NOC告警。
从模型快速更新到模型在线学习，这是一个自然的发展过程。技术天花板抬高了，以前无法处理的大数据量、大特征量和大模型，现在都可以有效处理而不会导致模型更新变慢，这对pCTR效果提升的好处是显而易见的。我们已经实现了这样一套具有良好伸缩性和可靠性的在线学习系统，并且在生产实践中取得成功应用。纵观业界，不少公司也在生产中使用了各种在线学习的模型和算法。同在线学习的广阔空间相比，目前我们的实践还是很初级的，未来我们一方面会去继续发挥在线学习的优势，拥抱更多的数据和特征，另一方面还会尝试更为复杂的模型和算法。
[1]"快速模型更新及其在腾讯精准推荐中的应用"
[2]JeffreyDeanandGregS.CorradoandRajatMongaandKaiChenandMatthieuDevinandQuocV.LeandMarkZ.MaoandMarc’AurelioRanzatoandAndrewSeniorandPaulTuckerandKeYangandAndrewY.Ng,LargeScaleDistributedDeepNetworks,NIPS2012.
[3]EricP.Xing,QirongHo,WeiDai,JinKyuKim,JinliangWei,SeunghakLee,XunZheng,PengtaoXie,AbhimanuKumar,YaoliangYu,Petuum:ANewPlatformforDistributedMachineLearningonBigData,KDD2015.
[4]AvrimBlum,On-LineAlgorithmsinMachineLearning,InProceedingsoftheWorkshoponOn-LineAlgorithms,Dagstuhl,pages306-325,1996.
[5]H.BrendanMcMahan,GaryHolt,D.Sculley,MichaelYoung,DietmarEbner,JulianGrady,LanNie,ToddPhillips,EugeneDavydov,DanielGolovin,SharatChikkerur,DanLiu,MartinWattenberg,ArnarMarHrafnkelsson,TomBoulos,JeremyKubica,AdClickPrediction:aViewfromtheTrenches,KDD2013.
[6]ThoreGraepel,JoaquinQuioneroCandela,ThomasBorchert,RalfHerbrich,Web-ScaleBayesianClick-ThroughRatePredictionforSponsoredSearchAdvertisinginMicrosoft’sBingSearchEngine,ICML2010.
[7]ChengLi,YueLu,QiaozhuMei,DongWangandSandeepPandey.Click-ThroughPredictionforAdvertisinginTwitterTimeline,KDD2015.
[9]"腾讯实时计算平台（TRC）系列之一：初识TRC"
[10]"【Hippo系列-系统介绍】分布式高可靠消息中间件Hippo"