科技频道-搜狐网站> 科技行业资讯
互联网 | 通信 | IT业界 | 自媒体

云脑刘亚新:DXL在信息流广告点击预测中的实践|AWS技术峰会

来源:搜狐科技
  • 手机看新闻

  8月9日,AWS技术峰会2018(北京站)在北京国家会议中心隆重举行。此次峰会以“所建不凡”为主题,举行了多场主题演讲、9大分论坛和60多个专场会议。峰会为到场的7000+嘉宾分享了人工智能、物联网、大数据、开发运维和安全等方面的创新功能、产品和服务。

  云脑科技首席架构师刘亚新受邀参加此次峰会,并在人工智能分论坛上发表以“DXL在信息流广告点击预测中的实践”主题的精彩演讲。

  在演讲中刘亚新从DXL (Deep and Cross Learning)模型的构建、训练系统、模型的评估、效率与工具几大方面阐述了自己在实战中积累的丰富经验。

  以下是刘亚新的演讲全文:

  大家好,我是刘亚新,在云脑科技担任首席架构师。首先介绍一下云脑科技,这是一家跨越中美两地的人工智能公司。美国区主要做算法实现和研究工作,中国区主要是工程和客户对接。我们和有大量数据的企业客户合作,利用他们提供的数据,用我们的AI技术提升他们的业务,把数据转化为生产力。公司合作的典型企业类型有互联网广告、金融、证券、物流、招聘等等。

  在广告方面,大家最常见的问题就是要预测和提升点击率(CTR)。CTR预测的传统方法有逻辑回归和FM(Factorization Machine)模型。一些以前的深度学习CTR模型包括Deep&Wide,DeepFM等等。我们的工作是在这些模型的基础之上,尤其是Deep and Cross Network为主要基础来实现的,再加上我们自己的推广和细化。我们公司是用广告CTR预测作为一个基本应用来开发这个模型,不过实际上在其它的方面也有应用,比如信息流推荐,可以把它作为类似于广告CTR的模型来实现。基本上很多分类模型都可以使用深度交叉学习的方法。我们还应用到供应链的预测、招聘人才岗位匹配。在这方面的工作集中在自动化特征工程、模型的可解释性、提升训练和推理的性能。我们主要是利用AWS存储和调度功能来优化训练和推理方面的性能。

  我们在做DXL model之前,先用大约几千条数据从客户直接拿来的一些简单feature,做一下比较简单的数据探索。我们有大概60个左右的numerical feature,基本上是dense feature,然后有大概40个categorical feature,还有一些text feature,这个是sparse feature。我们用比较传统的统计方法来做数据探索,就会发现feature之间的相关性,这也是大数据应用的常识。我们用DXL做的一个事情,就是能够自动的发现这些feature之间的correlation,把它们的interaction加到模型里面去。如果用传统机器学习方法找feature的interaction,基本上是一个feature engineering的工作,有很多需要手动的事情在里面。比如常用的FM这种模型,相当于是可以自动的做二阶feature,一阶是原始的feature进来,二阶是两个feature等interaction,FM是自动的做了这一步,然后再加上一些regularization做feature selection的工作,这样来做CTR的model。

  DXL 网络能够自动地形成高阶的interaction。DXL基本上是分成两部分,deep和cross。先从输入开始看,我们的输入有两类,dense feature和categorical feature,包括text feature。Dense feature就直接输入到模型里面了。Categorical feature和text feature输入到模型之前做一个embedding。这个embedding是可以事先单独学习的,也可以和整个模型在一起来学习出来的。从输入进来之后,左边那个叫做Cross network,通过一个递归的特征组合公式:

  每一层的特征都由其上一层的特征进行交叉组合,并把上一层的特征重新加回来。这样既能做自动生成高阶交叉组合特征,又能保留低阶特征,随着cross层的增加,可以生成任意高阶的交叉组合特征。在右边的Deep network就是一个传统的多层结构的网络。L1和L2这两边的层数是可以调的超参数。输出的地方就是把这两部分的结果结合起来,再加一个线性组合和一个 sigmoid,是分类模型常规的做法。我们在输入端还有一些优化好的,或者是一些简单的feature engineering,除了刚才讲过的embedding之外,我们还把一些feature做了二值化,另外还有一些dense feature做了对数变换,这样使得它们的值的范围在神经网里面比较容易处理。

  下面讲一下整个的数据处理流程。原始的数据输入包括日志的输入、用户画像的输入、物料的信息输入和一些交互数据输入。输入可以是通过serving的API,也可以通过一个DataGenerator进来。尤其是在系统启动的时候,需要进行数据的ETL,这个是通过DataGenerator的。数据进来以后统一抽象为Date Source,然后通过FeatureTransformer产生模型输入的feature。从原始数据开始,我们还是要做一定的feature engineering,比如说一定时段的频度的统计等等。我们生成出来的feature存在FeatureStore里面。另外在所有的流水里面,有些数据是代表着实际的label的。比如你有展现,但是没有click,那样的话你要预测的真正的结果就是0。如果是有了click,那这个结果就是1。所以我们也需要有一个LabelStore来存储,哪个impression最后产生了click,哪些没有产生click,需要能够把这些事件串起来。所以我们有两部分的存储,LabelStore和FeatureStore。这一部分相当于是数据采集的过程,包括serving的时候也是经过这个系统。数据采集后面接的是模型training/serving。这个地方我们定义了一些ModelComponent,是可以组合的神经网络的组件,可以比较自由的结合。 DXL是比较模块化的,除了这个deep&cross,还可以加其他的一些连接以及其他的稍微有所不同的一些组件。在训练的过程中,我们可能需要试验多种不同的网络结构和多种不同的超参数,所以我们在训练过程中会把不同performance的model都存下来。MetricStore就是存储model本身的performance。ModelStore和MetricStore会用MongoDB这样的库在AWS上来做。

  我们的训练系统从概念上来讲是比较简单一些的,使用的是AWS提供的Deep Learning Base AMI,用docker和nvidia-docker。nvidia-docker是为了使用它的GPU,我们在上面用cuda。我们也用mkl binding,是为了要保证serving的performance.Serving基本要求是要用cpu,所以我们这个地方在Evaluation的过程中会跑serving的performance,是用mkl来给CPU做一些性能的提升。

  在开始的时候,训练系统是比较简单的,用CloudWatch和Lambda来并行evaluate多种不同的model。开始是在超参数空间里面做一个比较完全的grid search,后来又加上AutoTuner的一些功能。这样可以使得搜索的超参数空间比原始的Grid Search要少很多,大概可以减少搜索一半的模型。

  我们模型搜索包括:模型本身的结构、deep&cross这两部分各自有多少层、有没有进行一些feature engineering、有没有进行二值化的处理和一些输入有没有做对数等。这个quant因为有考虑这个模型会在手机端运,所以考虑是不是要做quantization,用整数运算替代浮点。这里每一个版本基本上是不同的网络结构,每个网络结构里面也都有不同的超参数设置。用grid search 或者AutoTuner来并行搜索、evaluate的这些模型。这里主要看的是training上的一个performance叫做normalize logloss。如果结果和随机猜的一样,那么normalize logloss应该是接近于1的。如果normalized logloss比1小,就证明这个预测模型是有效果。一般对于CTR来说比较正常的模型范围就是在0.7到0.8这个范围之内。为什么要用normalize logloss呢?因为在训练的时候,要查看训练的performance,有一个参数,叫做negative sampling rate。因为正例都是比较少,负例是比较多的。做negative sampling rate的话就把实际运行的数据的数量减少。如果negative sampling rate这个选得非常好,不会影响最后的metric,但是如果是用不同的negative sampling rate,直接训练得到的logloss是不一样的,它们是不可比的。如果用normalize logloss来考察不同的negative sampling rate,就还是一个可比的metric。这个数字是越小越好的。如果我没有记错,我们最好的模型应该是用比较少层的cross,大概1-2层的deep,实际上也不能算是deep。

  我们还要evaluate在serving上面的performance。我们用了一个prebatch,prebatch就是你的请求进来,我是不是要把几个请求放在一起,然后再去做预测。为什么要这样做呢?因为大家应该知道神经网络里面很多是矩阵的操作,矩阵的操作会在合适大小的时候会运行得比较快,这样测了一下,就是1、2、4、8这样子的prebatch哪一个会效果比较好。这里考察的模型,它们的差别应该是cross数目哪一个更多一些,它们本身应该在logloss metric基本上差不多,但是在serving的performance上面差别还是蛮大,纵轴这个地方应该是QPS。

  最后简单讲一下,我们公司本身为了开发模型比较方便,自己开发了一些工具。我们底层用的DeepLearning Engine、TensorFlow、PyTorch、比较传统通用的scikit-learn和处理数据的pandas。这些是在我们底层的一些包来使用,这个上面我们构建的一些中间件,就是Data Adapter、DataPipeline等。这样主要是为了数据的导入、处理和存储这样的一些功能,在这上面构建一个Python的API来支持Feature Transformer,模型的评测,使用这些工具在开发速度上还是有一定的保障。谢谢!

  下面是问答环节:

  问:刚才您讲PPT的时候,就是在模型评估那一部分,有一个名词叫quant,我不太理解那个是指的什么意思?

  答:这个quant是因为我们考虑这个模型会在手机上,大家知道手机上面的浮点运算cpu比较差,大家的一个做法就是quantization,也就是量化的模型,是相当于不用浮点数去计算,而是用整数去运算,实际上比较常用的就是相当于把原本的浮点scale一下,你是变成整数来算完了之后,再重新scale一下,然后来到下一级进行运算,至少这是TensorFlow Lite的做法。

  问:我想问一下,在数据数量不是特别大的情况下,我们怎样去深度学习,来提升这种广告的点击率或者说导流的效果?

  答:这个比较难讲,因为我们公司接触到的数量还算是比较大的,一般日活的用户大概是2000万左右,然后每天的广告还是比较多。

  问:我理解你的意思,但就对单个广告客户而言,比如说你的客户或者说我们的量有2000万点击率,但是对每个细分的客户,他其实每一个客户的量都不是特别大,所以整个在细分市场里,然后让他再深度学习效果更好?

  答:您说的是说只关心这几个客户,比如说广告主的这种广告是这样吗?

  问:对,因为消费者这种消费习惯是变的,比如说现在这样子用这种方式来导流效果是挺好的,或者可能消费者习惯就变了这个定义。第二就是说在用户这一块,在做我们平台公司的话,可能我一个大的数据有各个细分都可以,但是对单个广告客户来说,他也需要提升这种广告效果,咱们怎么去帮这单个广告客户来提升它的导流效果?

  答:说实话我们并没有这方面的经验,因为我们一般考虑是在这个广告市场里面有可能有多个广告主,他们的需求虽然是不一样的,但是我们训练模型的时候基本上所有的广告主都是在一起训练。一个关于用户行为发生变化这个事情,我们基本上都是尽量提升训练的效率,为什么我们要做一个系统从数据进来到feature store到model这样一个pipeline呢?就是要把中间的delay减少,使得你经常有新的数据进来,尽量用新的数据来尽快的重新训,包括一些相当于实时更新模型的一些做法,比如说增量训练这样的一些做法。 这样我们希望能够catch到一个新用户的一些变化,再加上一些跟时间有关的数据作为输入,您说的这种比较小规模的这种数据量,来做一个深度学习的问题,我没有这方面的经验。

  问:你好,我有两个问题,第一个是在这个模型评估当中,你写到的是v1到v7,这个是代表什么意思?

  答:这是我们的不同版本,我们不能把具体的模型的内容拿出来。呈现出来的这个是开发过程中公司内部交流的一个图标,直接拿过来放在这里。基本上就是表达不同的网络结构。

  问:第二个问题是,版本不同,为什么它的性能会有些提升?是说这七个版本出现七个不同的性能吗?

  答:原因主要是网络结构不一样,就像deep&cross这边,你可以把所有的输入都直接放进去,所有的都做deep,所有的都做cross,输入里不做任何区分,然后有一种做法就是,你知道这里面输入的是一些是跟用户相关的,我觉得跟广告本身相关的,你可能想要用户和用户的feature做cross,然后广告和广告也做一下,这样相当于把这个输入做一下划分。

  问:你好,我想了解一下,你们公司的具体算法在GitHub开源社区里有这种信息资料吗?

  答:我们本身的代码并没有在GitHub开源社区里面,相当于借鉴的一些算法,以上的算法都在这里。deep&cross还有相关一些模型在知乎上面都有呈现,如果大家感兴趣去搜一下deep&cross CTR,会有一些非常详细的介绍。

  免责声明:以上内容为本网站转自其它媒体,相关信息仅为传递更多信息之目的,不代表本网观点,亦不代表本网站赞同其观点或证实其内容的真实性。

it.sohu.com true 搜狐科技 http://it.sohu.com/20180927/n550744643.shtml report 7646 8月9日,AWS技术峰会2018(北京站)在北京国家会议中心隆重举行。此次峰会以“所建不凡”为主题,举行了多场主题演讲、9大分论坛和60多个专场会议。峰会为到场
(责任编辑:李俊鹏)

相关新闻

相关推荐

    我要发布

    客服热线:86-10-58511234

    客服邮箱:kf@vip.sohu.com