Airbnb深度学习搜索引擎实践-模型发展历程

Applying Deep Learning for Airbnb Search engine

该文章是KDD 2019上发表的Airbnb的搜索引擎主要算法的文章,主要介绍了Airbnb算法的演进历程。还是Airbnb一贯的朴实无华的风格:不在乎有多少创新,更多是工业界结合业务上的算法工程,该文章很难的是文章中不仅介绍了Airbnb的算法,以及使用该算法的出发点和考虑,同时还记录了中间的各种坑,甚至一些失败的实验,真的是经验的无私分享,写作手法更像各大厂内网的技术总结分享文章。对于广大研发有较强的借鉴作用。
再具体到技术细节,Airbnb的场景是低频,且作为平台需要同时考虑需求侧(用户/网民)同时还要考虑供给侧(Airbnb中是民宿),另外民宿预订有很强的地理位置属性,所以文中的算法对于低频场景,LBS场景的搜索推荐都有较强的借鉴意义。低频场景例如飞猪,携程,马蜂窝的酒店,旅游预订;LBS属性例如Google Map,百度地图,高德地图等场景。

Abstract

搜索引擎一直都是airbnb成功的重要的因素,之前的实现主要是使用树模型来实现核心的算法,但是出现了瓶颈,所以后来airbnb就使用深度学习来优化其搜索引擎。
本文不会针对深度学习的算法进行创新,更多的是在使用深度学习的构建核心引擎中的一些细节的探讨。bon voyage

Introduction

搜索场景是airbnb的重要的场景,最开始系统使用的是人工的打分函数。之后使用gbdt进行特征的组合,这是一个比较大的进步,并且经过了比较多的迭代。现在开始转移到深度学习。

图:搜索session示例
典型的搜索引擎,在用户看了一系列的listing(相当于其它文章中的item)之后,完成了booked的工作。
系统运行中间的日志都被记录下来,之后使用离线的方式训练新的模型模型,尽量的将booked的listing的排序排到最靠前。之后在线上使用ab test的方式进行验证。
本文叙述的方式是从feature engineering和system engineering的方式进行的介绍。最后再对内容进行回顾。

Model Evolution

模型的迭代也是一步接一步的。深度学习是顶峰的表现,是最终逐步迭代后的结果,过程中也走了很多弯路。
图:展示了在各个模型迭代上离线ndcg的提升幅度:

图:展示了各个模型在线转化的相对提升幅度:

Dustinsea: 可以看到,在全面DeepNN前,就已经拿到了比较多的受益,DeepNN让效果更上一层楼

第一阶段:simple NN

论文12提到don’t be a hero,但是我们一开始就从复杂的nn模型出发,到最后只是得到了复杂结构,还有花时间的循环。
在nn上也也花了比较多的时间,gbdt模型输出作为nn模型的输入。该过程最重要的贡献,就是把特征的pipeline给建立起来。

第二阶段:lambdarank nn

使用lambda rank,直接对离线的ndcg进行优化。

第三阶段:gbdt/fm nn

gbdt作为另外一条线,在进行优化中间发现一个有意思的现象:从指标上gbdt的效果和nn的效果比较类似,但是他们排序出来的结果是不一样的。受这一现象的启发,将gbdt/fm和nn的架构进行了融合,FM的最终输出直接作为nn的特征,同时树模型的节点index作为nn的特征输入(和2014年facebook发表论文中gbdt+lr的思路异曲同工)。模型结构图如下:

图:NN和GBDT模型融合方法示例

第四阶段:DEEP NN

模型
最终使用具有两个隐藏层的nn。配置如下:

特征
大部分的特征都直接进行输入,没有进行太多的feature enginering,少部分的特征作为其他模型的输出,会进行特殊的处理。
price特征:使用模型进行处理。
similarity features:使用功现的embedding进行处理。
使用17亿样本进行训练,以ndcg作为评估指标的情况下,能够达到收敛的效果。

在评估过程中一个非常困难的点就是我们如何评判模型的结果和人的认知评判的结果的效果的对比。在图像中人是可以作为一个评判标准的绝对增值进行评价的,但是在我们的数据里边却看不出来绝对的增值,因为这些绝对的因素都是隐藏的比较深的。这和video或者audio领域不一样。

失败的模型

一般大家在叙事的时候都是在讲成功的案例,但这其实只是整个过程的很少的一部分,下面就向大家介绍一下失败的尝试,因为失败的尝试比较多,所以这个地方挑了两个模型。

第一种失败尝试:直接使用listing ids embedding

在nlp中或者电商视频推荐中,对于item的embedding使用是比较成熟的,并且证明效果比较好。但在airbnb的环境中,因为数据量比较稀少,就算最火的民宿一年也只能有365个预定,更多的民宿数据都是非常少的,所以很难学出稳定的embedding,基本上都是Over fitting,所以listing ids使用会失败。
Dustinsea:所以Airbnb进行embedding的时候,更多是对人群/POI群进行embedding,而非用户/单个POI进行embedding.

图:增加listing id embedding后,over fitting问题明显严重

第二种:multi-task learning

多任务是现在很多推荐搜索场景中常用的技术,多任务是现在比较fancy的技术,听起来也是make sense的。Airbnb也进行了尝试。
进一步讲,在文中尝试的方向:是认为浏览时间比较长的listing应该会和booked行为有比较强的相关性。所以进行了多任务的学习,在学习的过程当中有两个子任务,一个是booked的子任务,另外一个是预估用户浏览时长的子任务。
多任务模型在低层共用embedding,在上层分成两个任务,并且在loss function中将booked的样本进行加权。线上使用的时候只使用booked子任务进行预估。
但最终线上的结果是用户的浏览是浏览市场的确变长,但是预定基本上没有什么变化,经过分析可能的原因如下
第一是推荐出来的内容描述会比较长,或者描述中带有一些比较独特的东西,或者甚至是比较搞笑,这样用户浏览的时间就变成了,但是并不会影响到对应的预定。
第2个可能的原因,是模型倾向于推荐价格比较高的listing,这样用户会进行浏览,但是最后也没有预定。所以多任务是一个比较有挑战的方向,需要继续进行研究。
Dustinsea: multi-task learning是大趋势,从理论上也是符合逻辑的,但真正应用的时候,需要的投入也比较多,包括对于问题的细致分析,所以可以作为系统成熟阶段需要突破的手段,但在系统的拓荒阶段,不一定是很好的选择。

图:下单率分布
特征工程
传统的feature engineering需要很多的时间以及经验,并且中间有很多的tricks才能提升目前的效果,但是这些经验和方法不一定还适用于最新的变化的数据(因为用户的行为是动态变化的,之前人工feature engineering的人工经验知识可能已经迁移)
nn的一个优势就是它能对特征进行自由的组合,不过我们还是需要一部分的特征工程,只是我们的特种工程不再聚焦在我们选择以及如何进行特征变化,更多的是对数据进行统一的预处理,这样nn能够更正确的对特征进行转换和组合。
feature nomalization
gbdt值和特征的相对顺序有关,但是nn会和特征的值有关,所以进行特征的规范化。

图:特征归一化方法
第1种相对进行z score的处理
第2种,如果分布符合指数分布,则进行log的处理
feature distribution

从特征的角度保证特征是平滑的,是比较重要的。因为如果一般特征不平衡,都是存在问题。检查特征是否平滑,有以下好处:
检查数据种是否有bugs
检查如何进行特征变换,例如文中将lng/lat转变为用户和listing的distance

图:经纬度特征分布

超参数

dropout: 一般dropout在nn中都是防止过你和的标配,但在该场景中效果不佳,文中给出的解释是dropout比较像数据增强,相当于引入噪音。文中后续引入了人工构造的噪音, 线下ndcg有1%提升,但线上无变化
initialization:使用xavier initialization方法,比参数默认置0好
Optimizer:文中最后使用的是LazyAdamOptimizer,因为实验中使用Adam发现效果很难再优化
文中最后还是推荐dnn是一个方向,因为能够让大家很大程度上摆脱特征工程,而站到更高的角度上去考虑优化目标的问题。但是整个过程也是比较耗时的,作者认为他们DNN的工作也才刚刚开始。

图:发展历程

reference

原论文参见:https://pan.baidu.com/s/1C0I6AhEWB9h3PV5ZmSPcbQ 提取码:56l4
更多内容参见: www.semocean.com
P.S. 急招推荐,搜索,语音算法人才,阿里P6~P8,欢迎推荐和自荐,简历请发至 haibo.lihaibo@alibaba-inc.com

Airbnb深度学习搜索引擎实践-Embedding使用

real-time personalization using embeddings for search ranking at airbnb

内容简介

搜索排序和推荐系统在类似于网页搜索内容发布等场景都是比较重要的技术,但是很难有统一的技术能够适用于所有的场景。
在爱彼迎的场景中,需要同时满足商家和用户的偏好需求。而且在特定的时间,一个民宿只能接待一位客人。
文中使用embedding技术对list和用户进行建模,以便用在搜索和推荐中。这两个频道带来的转化占了99%以上。并且能做到实时的个性化。从离线和在线的ab test效果都验证比较好。

intoduction

随着数据的增长继续学习,在搜索和推荐中的个性化应用都比较成熟,有很多的发展。有些集中在engagement的优化,有些集中在购买的优化,有些则集中在双边的优化。例如像租房行业中的airbnb打车行业中的uber,都会涉及到供需双方的满足。
airbnb需要满足双边的供应和需求双方包括说客人的预计定酒店地点,日期以及说酒店的一些要求,比如容忍的客户数,是否有宠物,要把不匹配的酒店放在比较低的排序位置。
最后使用的方法是将问题建模成pairwise排的问题,并使用lambda rank方式实现。
在爱彼迎的场景中,一般用户有需求的时候都会在同session中搜索多次,所以我们可以个性化的向用户推荐同一session中用户可能喜欢的item,以及将排序比较高的推荐出来,但没有被点击的item作为负例。
方法:
在具体实现的时候,使用用户有过交互的item作为trigger,使用搜索session的数据训练word representation,并计算与trigger item的相似度,以便在搜索和推荐中作为排序similarity的度量。
兴趣建模方式

  1. 使用用户近期点击行为作为用户短期的兴趣偏好
  2. 使用用户预定的行为作为用户长期的偏好
  3. 因为用户预定的行为会比较稀疏,所以将用户映射到群体使用规则的方式
  4. User和item都映射到同样一个向量空间,以便计算其相似度

文章的贡献

  1. 实时个性化:传统的方法是离线计算好user 2 item或者说item 2 item的内容,之后在线去拉倒排,本文使用的方法是将用户即时的交互item embedding化,然后再去查相似的item。做到实时个性化
  2. 适应具有聚集性的数据的训练模式:在短租市场中,用户一般是在特定的时间,只针对特定的区域有需求,故在训练的时数据的负样本选择需要具有区域性聚集
  3. 将转化作为全局的内容
  4. 用户类别embedding:很多文章对每一个用户进行一个embedding,但是在短租市场,用户行为非常稀疏,故将用户的类别进行embedding
  5. 将用户拒绝作为负例

方法

文中将embedding分成两种,一种是用户实时短期item的embedding,另一种是user type和item的embedding,表征长期实时兴趣。

相当于优化每个session中每一个item对应的上下文的概率最大化。

此处的概率是用softmax来表示。
note:以上公式中,m为前后上下文的窗口长度,V为字典大小。使用以上方式,得到的li的representation,在session中越相似,则距离约近。
此处V表示id数量较大,所以使用随机负采样方式来降低数量提升计算的速度。
负采样
负采样的方法为,使用click和对应session中的上下文作为positive pairs(c,l),以及click和随机采样的上下文作为negative pairs(c,l)进行模型训练。以下为对应的优化目标,其中Dp为positive pairs集合,Dn为negative pairs集合。

将session分为两种

  1. 第1种是以完成订单预定的session, booked session
  2. 第2种是有点击,但没有预定的session,exploratory session
    为了让预定作为一个全局的上下文,在每一个booked session中的样本,都强制将预定的item作为结束的item。

对于exploratory session,则优化目标仍然为公式(3)
Adapting training for congregated search:
以上公式的random sampling会导致random sampling出来的负样本都是和本次搜索地域不一致的结果,最终导致模型学习出来的是区域之间的相关性,为了解决该问题,增加对同区域结果的sampling

上式中Dmn为在l的同区域中sampling出来的结果

冷启动

新加入的店面没有embedding,此时我们会用距离内的相似民宿的中心点来进行表示,比如说找到半径10英里内,相同price以及相同房型等其他属性相同的三个embedding,然后做一个平均,来表示新的民宿的embedding作为冷启动。用该方法能够覆盖98%的new item。

embedding效果的检验

使用围围度为32的embedding进行表征,发现地理位置的聚类关系的确编码进去了,同时房型价格的信息也编码进去了。

user-type & listing-type embeddings

目的是捕捉用户的长期兴趣。但是存在以下几方面的挑战:

  1. 数据较为稀疏。
  2. 很多预定的session长度为1,没法学习。一般出现5~10次才能学习出来。
  3. 用户预定的间隔很长,可能偏好已经改变了。

具体的实现方式为将用户按照meta信息进行聚类分为人群,将listing/item按照meta信息进行聚类,按照聚类后的群体构建预定session进行训练。相当于学习的对象由原来的list_id,变为list_type
用户的长期兴趣可能会改变,故在具体学习操作的时候,将user和listing映射到同一vector space中进行学习。

构造(u_type1,l_type1)的用户群体,listing群体的点击session,之后进行训练,即可将user和listing映射到相同vector space中

模型训练

以30分钟作为一个session进行模型训练
去除无效的点击,例如点击后在页面时间较短的点击
将session处理为同时包含booking&EXPLORATION的session形式

评估方式

给定用户最近的点击,以及待排序的candidate, 看最终被预定的item是否能够被排上来

线上使用的方式,为使用GBDT模型进行特征组合, 使用user, listing embedding构建各种特征进行模型训练

reference

原论文参见:

https://pan.baidu.com/s/1R8xeb0iRq089myl3oXJlZA 提取码:1j9n
更多内容参见: www.semocean.com
P.S. 急招推荐,搜索,语音算法人才,阿里P6~P8,欢迎推荐和自荐,简历请发至 haibo.lihaibo@alibaba-inc.com

亚马逊semantic product search

亚马逊semantic product search

网上一直有一种说法,就是在Google的工程师非常鄙视亚马逊的工程师,觉得他们技术不行,Google的技术比较牛叉,但是很多业务场景Google就是做不过亚马逊,最典型的就是云计算市场,Google的市场份额还不如阿里,更别说亚马逊的老本行电商。而亚马逊也一直奉行简单有效为客户服务的原则推进业务。 例如这篇论文中描述的亚马逊电商product search,技术比较简单,没有很高端复杂的模型,但大家在工业界的实践中是可以作为参考的,是一种简单有效的语义搜索方法。该论文发表于2019年KDD大会,下边的内容更多是一个论文的笔记,作为一个备忘,大家最好参考原论文一起阅读。

基于字面匹配的缺点

  1. 第一上下位同意反义处理不好,例如语义的泛化(hypermyms),同义词(synonyms),反义词(antonyms)
  2. 第二形态学变换处理不好,比如说woman and women
  3. 第三拼写错误处理不好。

本文提出的语义方法解决问题的思路:

  1. 第一是loss function处理正负样本
  2. 第二是针对average pooling和ngram捕捉语法的pattern
  3. 第三是使用哈希处理字典中不存在的单词的问题OOV,应对0次学习问题
  4. 第四是进行了并行优化。

本文面临的场景是用户的行为数据量非常多,但是有噪音,同时用户在搜索的时候,是针对某一个比较窄的领域进行搜索,在这个过程当中还需要兼顾发现性。

模型

本文使用的模型的主要特点

  1. 第一是使用embedding方式将query,product映射到相同的空间
  2. 第二是生成embedding之后,使用average pooling的方式将embedding压缩到相同的维度。之所以能够用average pooling主要的考虑有两点(没有使用RNN的原因)
    第一是query和product都比较短,没有太强的持续依赖的关系
    第二是query一般都包含在product之中。同时因为quarry比较短,所以将query和product映射到同一空间中,无需额外参数

图:模型示意图

Loss function

使用pointwise 3阶段hingle loss作为lose function

相当于综合考虑了样本的三种情况:

  1. 第一正样本为用户购买的product
  2. 第二就是用户看到了(impressed),但是没有购买的结果
  3. 第3种是随机采样出来的结果作为副样本

相当于将label分成三种,三种有不同的域值,使用hingle loss方式进行建模

tokenization methods

本文使用不同维度的力度的embedding对query, product进行表达.主要分为以下几种:

  1. word unigram:基于单词的unigram
  2. word n-gram:用来捕捉PHRASE信息,以及对应的附属信息,例如用户如果买的是iPhone手机壳跟iPhone手机其实是不一样的,使用n-gram可以捕捉该类信息
  3. character trigram:用来捕捉拼写错误信息或者像size型号之类似的信息

同时文中使用harsh trick来解决embedding没有表达到生僻词的情况。
最后在应用的时候,作者将所有的tokens组成一个bag of tokens,之所以能够那么做而没有考虑持续的原因,是因为query和product的title一般都相对较短,用这样的方式其实也能表达序列的关系,而不用用到rnn这样的模型。实验证明不用rn效果的影响也不大。

note:对于OOV的部分(word, n-gram, char-trigram)则使用hash trick的方式进行处理,将query, product中相同的部分映射到相同的bin中(参见图5)
该方法的好处,一方面能够保证高频的元素都能够找到,另一方面,query和product中OOV的元素都能够映射到相同的部分。

data

使用11months的search logs作为训练数据, 使用1month作为evaluation。
文中使用用户数据来进行模型的训练使用和query和products的counts作为权重。
在构造样本的时候,一个query之下有6个impression的product和7个random的products和一个有购买的products。

实验指标

matching:抽取20k个query,看从100万的语料库里边能召回多少购买的products。
ranking:主要看NDCG,mrr。

Result

设置:文中固定dimension为256,batch size=8192,adam作为优化算法。。。
结论:

  1. L2比L1正则更好,原因可能是L2对于cosine计算相似度的情况下,对于outlier更加泛化
  2. 效果 3 part > 2 part loss
  3. average pooling效果优于gru/lstm,猜测可能是因为该场景中序列长度较短,RNN的效果没有发挥出来
  4. tokenization算法中,unigrams+bigrams+char trigrams算法效果最好; 增加OOV在保证参数不变的情况下效果更好

后续:借鉴意义

在后续推荐业务中存在的借鉴意义如下:
poi2poi embedding表示:计算可以使用该方法对搜索业务中 query-点击poi数据进行embedding,获取poi embedding,计算i2i
tag2tag embedding表示:将tag作为token,使用搜索数据进行训练,得到tag和poi在同一空间中的embedding表示
poi属性2poi的embedding表示

reference

原论文参见:
复制这段内容后打开百度网盘手机App,操作更方便哦 链接:https://pan.baidu.com/s/1VITC73pw9fURLJ-K_7Kb3g 提取码:4h43
更多内容参见: www.semocean.com
P.S. 急招推荐,搜索,语音算法人才,阿里P6~P8,欢迎推荐和自荐,简历请发至 haibo.lihaibo@alibaba-inc.com

 

增加User Memory Embedding的深度点击率预估模型

这次参加了KDD 2019的大规模稀疏特征模型workshop,其中有比较多的论文是关于如何改进推荐,变现场景CTR预估模型的效果提升的。感觉今年很多的论文改进方向都集中在了如何更好地引入用户历史行为特征及兴趣。 无论是引入RNN, transformer,或者其他的weighted pooling,都基本是是类似的思路。

以下就简单介绍下这次KDD收录的文章《Click-Through Rate Prediction with the User Memory Network》的思路,细节就不展开了,具体可以参见附件。

在按照CPC收费的广告业务中,Revenue=bid*ctr,故ctr预估的准确性一直是广告业务中的核心技术问题。现在深度学习已经成为ctr预估的标配,但传统DNN的深度ctr模型未考虑用户的点击历史行为,效果有待提升。而另一方面,RNN类的序列模型能够刻画用户的历史行为序列提升预估准确性,单RNN类的模型存在两个缺点:1是模型会比较复杂,2是数据的准备也会既复杂又冗余。

本文为了解决该问题,引入了用户唯独的like and dislike history的vector描述,两个vector作为用户feature和广告的其他feature进行concat作为input进行模型训练和预测。该方式既引入了用户的history信息,又避免了使用RNN类的模型带来的复杂性。需要注意的是,like/dislike的向量为user-wise的,故每个user都会有两个用来表示这两个历史信息的向量。

p.s. 其实这样的思路在很多场景中军可以使用,例如在地图领域,理论上引入了RNN的ETA效果也会更好, 因为用于表示道路的link客观上就是呈现出序列的特性,但ETA作为基础设施访问量非常大,实效性要求又会比较高,故线上几乎不可能使用RNN作为实现方案,所以可以使用固定长度的vector对序列的link进行表示,以便使用定长的向量,一定程度上就可以表示出序列的特性,相当于是序列信息的一种折中方案。

文中提到的CTR模型如下:

图:memory network for ctr prediction

该方法在传统的DNN基础上,在将特征进行embedding的时候,引入额外的两个用户级别用于表示like&dislike的vector作为history memory信息,一定程度上引入了历史序列信息。

References:

  1. Ouyang W, Zhang X, Ren S, et al. Click-Through Rate Prediction with the User Memory Network[J]. arXiv: Information Retrieval, 2019
  2. 论文下载:复制这段内容后打开百度网盘手机App,操作更方便哦 链接:https://pan.baidu.com/s/1gFsuIIFzuKQROFLotfZldg 提取码:181v

 

 

ID+图像特征联合训练CTR模型

CTR预估一致都是广告系统,推荐系统中的核心组件,对于简单的应用场景,LR,或者GBDT等传统浅模型就已经能在有限的代价下很好地解决该问题。但对于一些影响面比较大的场景,例如BAT中核心推荐,变现场景中的CTR,每一个点的提升都非常重要,此时就需要使用技术手段对CTR预估模型进行极致优化。此时模型的选择,以及根据具体业务的模型设计创新就会比较关键。而另一条思路,则是引入多模态的特征。

LR,GBDT在极致优化的情况下可能就可以解决80%的问题;如果还需要提升,则是近年来比较流行的深度深度模型,例如Wide&Deep,DeepFM,各种FM思想的深度话;甚至还需要根据具体业务场景中提炼出来的业务特性对网络进行定制, 例如阿里妈妈设计的DIN对用户历史兴趣item的weighted pooling思想。

另外一条对效果进行提升的道路就是引入多模态的信息,结合传统的id特征对模型进行训练提升效果。e.g. 引入推荐item的图片信息

下面就简单介绍一下最近读的阿里妈妈关于如何使用用户历史兴趣item图片提升模型效果的文章《Image Matters: Visually modeling user behaviors using
Advanced Model Server》。该论文是阿里妈妈广告CTR预估团队的论文。核心思想,是使用能够代表用户行为的图像(例如用户点击,购买过的商品的图像)来学习用户的兴趣。
传统的使用ID特征更多是偏记忆性质的,就是用户有没有点过这个广告,是不是对该广告感兴趣,这样的方式有两个缺点:1是在预估的时候如果出现新的未见过的ID,则模型无法处理;2是如果数据不充分,则训练效果也不会好。所以文章假设能够使用能代表用户行为的图像,来表征用户的兴趣:将图像的高维特征抽取出来后,具有较好的泛化性。

具体的做法是使用pre-training的模型获取表征用户行为的image的低维度向量表示,文中使用VGG16 FC6输出的4096维度的vector表征图像,之后对这些vector进行aggregation。之后得到的image特征表示和id features进行concat后进行CTR模型训练。
论文的创新点如下:

  1. 使用Behavioral images的抽象特征对用户行为兴趣进行刻画,而传统的方式要么只用id feature, 就算用image feature,也仅仅用ad的feature
  2. 新的基于attention的aggregation方法,该处的pooling方法不是简单的sum或者max,而是基于query的attentive的aggregation,类似于DIN中的方法
  3. 新的训练框架

当然,该论文中使用的是类似于DIN中,使用了用户历史item序列的图片来泛化用户兴趣,使用的是一序列图的聚合,而非一张图所以感觉该算法还是太重了,一般的场景感觉有点杀鸡用牛刀。另外一种折中的方案是就使用一张图,就是待推荐商品的图作为特征引入模型进行联合训练,这样的方法在很多场景中也已经在使用并得到了较好的效果验证。

参考文献:

Zhou G, Song C, Zhu X, et al. Deep Interest Network for Click-Through Rate Prediction[J]. 2017.

Ge T , Zhao L , Zhou G , et al. Image Matters: Visually modeling user behaviors using Advanced Model Server[J]. 2017.

 

 

图像质量打分算法-NIMA

业务背景
随着手机性能提升,网络速度改善流量资费下降,原有网络上消费的内容很大程度上都被图片,视频所取代。此时很多应用中就会碰到一个技术问题,如何评价图像,甚至视频的质量。而这里边一个比较重要的场景,就是如何选择内容的头图。例如大众点评UGC评价推荐的首图,爱奇艺、优酷视频的头图。好的头图能够提升内容的表达能力,提升用户体验,从业务指标上也能从内容的点击率体现出来,所以,需要一种可靠的图像质量打分算法,该算法不仅需要能够识别技术上质量差的图片(例如清晰度差,饱和度,噪音点多等),还要根据具体的业务场景,判断该图片适用于该业务场景的程度,例如美团点评的头图如果是菜品时,显示已经就餐完毕的残羹冷炙就不合适,而爱奇艺,优酷等视频网站,则不适合出色情的头图。

算法
业界有很多算法解决此类问题,例如BDN(Brain-Inspired Deep Networks for Image Aesthetics Assessment)中使用多路人工构建特征进行打分能够在该类问题中取得较好成绩。
比较有名的end2end方法,是2017年Google Research发表的NIMA算法(Neural Image Assessment算法)。正好这几天有时间业看了下论文,感觉Google的论文都是比较接地气的:不复杂,能解决实际问题,甚至拿来修改下就可以在实际场景中使用。
该论文解决Image Assessment的算法的思想主要如下:

  1. 使用预训练的ImageNet网络作为Baseline,该处的Baseline可以是MobileNet,VGG16,Inception等
  2. 在Baseline的基础上,将最后一层替换掉,使用随机初始化的FC进行任务Fine Tuning
  3. 使用的数据集论文中提到3个,AVA,TID2013,LIVE。数据集中对图片的标注,均是同一个Image多个人进行打分,用打分分布进行描述,包含mean,deviation。使用上述数据集进行模型Fine Tuning
  4. 论文中考虑到各个打分等级虽然是离散的,但却是有顺序的(Ordered),所以模型最终的loss并不是使用cross entropy进行衡量,而是使用EMD,这样有助于将各个离散的分档的大小关系考虑到任务重,缓解了cross entropy将各个类别看成相互独立的缺点

图:NIMA算法架构图,使用ImageNet任务网络(MobileNet,VGG16,Inception)移出最后一层,然后新增随机初始化FC。训练loss使用EMD(Earth Mover’s Distance),其度量的是两个分布的距离。 此处的CDF_p(k) 为从1,到k个类别上的概率累加

图:EMD loss

总结
在很多任务重,NIMA都能够表现良好,甚至使用AVA公开数据进行训练后的模型就能够取得较好成绩,但是很多时候,我们还是需要根据具体业务进行定制,特别是加入符合业务场景需求的训练样本,例如电商UGC中不能出现色情内容,单是否出现年轻,二次元的美女可以加分? 另外文中使用EMD来缓解cross entropy不能建模ordered category信息缺点的思路,也可以在很多场景中借鉴,例如地图中,路况状态一般分为:畅通,缓行,拥堵,极度拥堵,如果直接使用cross entropy就将各种状态之间的顺序关系丢弃了,此时使用EMD作为loss,而仍然将问题看成是分类问题会更加合适。

Reference
Zhangyang Wang, Florin Dolcos, Diane Beck, Shiyu Chang, Thomas S. Huang:
Brain-Inspired Deep Networks for Image Aesthetics Assessment. CoRR abs/1601.04155
NIMA: Neural Image Assessment. 原论文下载地址:https://arxiv.org/abs/1709.05424

github Keras实现:https://github.com/titu1994/neural-image-assessment

 

 

 

 

 

《双十一技术-阿里超级工程》文档分享

分享一个巨牛的技术文档集合: 阿里双十一9年算法工程介绍《九年双十一-互联网技术超级工程》,其中介绍了阿里双十一过程中应用到的基础架构,算法,应用策略等,非常系统全面。很多算法细节并未展开,但也是从宏观上了解阿里内部技术栈,以及业务背后使用的技术非常系统的材料。材料可以从引入列表下载,也可关注微信公众号‘‘阿里技术’’下载。

另外最近的感受,就是阿里在技术的投入越来越大,沉淀越来越厚。以前经常说:百度的技术,腾讯的产品,阿里的运营。但随着阿里经济体越来越庞大,生态越发全面的同时,内部技术建设也越来越领先同行,而且阿里的技术不仅能在工业界落地,同时在学术界也产生更多贡献:现在很多顶会都能看到很多阿里技术成果的身影;同时对开源也有更多的项目贡献。

P.S. 长期招人:搜索,推荐,机器学习,语音,期待你加入阿里经济体,让天下没有难做的生意: )

参考文献:
《九年双11:互联网技术超级工程》:
https://102.alibaba.com/downloadFile.do?file=1516614343703/AliDouble11.pdf

LBS猜你去哪儿功能实现

最近看了一篇比较有意思的文章,关于滴滴’猜你去哪儿’功能的算法实现,在这里记录下。

产品

图:滴滴’猜你去哪儿’产品形态

从产品的角度,滴滴’猜你去哪儿’是在用户打开滴滴,用户还未输入的情况下,猜测用户的想去的目的地(POI)并以TIPS的形式直接进行提示,该功能从产品上有两个好处:1是能够减少用户的输入,如果猜测准确,用户直接点击目的地POI即可;2是能够提升用户对滴滴的好感,提升用户体验和粘性,毕竟用户都是感性的,这样一个功能点如果足够准,就能让用户印象深刻

技术

首先分析下该产品的业务场景:用户打开滴滴,绝大部分情况下,都是心中已经有要去的地点了,技术需要做的只是将该POI猜对并提示出来。所以该场景所使用的技术,就和传统的视频,音乐,甚至电商推荐有很大区别:该过程不需要协同,而在乎准确,用户不会因为你打开滴滴的时候推荐的POI和他的兴趣比较相关就会去,在打开滴滴前,用户就已经做了决定。

换句话说,用户要去的地方是极度个性化的,几乎没有泛化,所以在技术上有以下两点设计:1,召回的目的地候选POI就是用户的常去地;2,去什么地方仅取决于用户及他所处的上下文,此处上下文包括位置,时间等。而所有的上下文中,从滴滴的论文中可以看到,最重要的就是3个因素:出发时间,出发地点,是否为工作日

图:最有效的场景上下文

算法

滴滴使用了一个比较简单的算法来解决该问题:针对每个用户的数据,对每一个去过的候选目的地,使用高斯分布来构建基于上下文的条件概率分布。之所以使用,之所以使用高斯分布,是从数据上来看,出发上下文和去的目的地之间,分布的确是一个钟形。

图:特定目的地出发时间分布

如上图,如仅考虑时间一个维度,用户出发去特定目的地的分布,符合高斯分布。

故使用的模型形式如下:

图:贝叶斯模型

其中 X为当前用户所处上下文, Y=yi表示目的地为yi。其模型形式为给定上下文后,计算用户去目的地yi的概率,转化为使用贝叶斯方式计算,此时只要计算用户去各个目的地的先验,以及用户去各目的地的上下文概率即可。

先验计算比较直接,直接统计用户去各目的地的频次即可。

图:特定目的地概率统计

P(X|Y=yi)则将其表示为高斯分布。简单出发,此处 X如果仅包涵时间维度的话,作如下表示:

图:建模为条件概率分布

高斯分布仅需要给出 u 和 variance即可。而两个值通过观测样本即可给出。但此处有个细节,就是时间是以24小时的周期函数,不能直接使用数值方式计算均值u,故文中提出了计算时间维度u的方法。

图:求解u

其思路比较直接,其中有两个关键点:1,时间以24小时作为周期,那么两个时间的差,不能大于12小时;2,u和所有时间点的差值的平方和最小,求解u即可。

图:求解u,时间距离定义

同理可求解variance。

以上方法仅使用了时间一个上下文,在实际中较为重要的上下文为时间,出发位置,是否工作日,以相似的方式,将模型构建为多维高斯分布并使用贝叶斯方式即可计算。

结果透出

使用以上方法,即可计算用户在特定场景上下文情况下去特定POI的概率。当用户使用滴滴时,只需要使用该用户当前的场景上下文,使用以上方法均计算一遍概率,再根据阈值挑出TOP N即可作为’猜你去哪儿’的结果

算法不足

该方法的优点是足够简单,结果容易解释。缺点也很明显,主要包含以下几点:

1,场景上下文使用较少,也不太方便引入更多上下文,例如天气等

2,用户行为使用较少,仅使用上下文信息进行单点预测,没有用到用户的行为轨迹信息

解决第一个问题的思路比较直接:更多的特征,描述能力更强的模型。

第二个问题会比较有挑战,受限于滴滴的产品使用场景,滴滴能拿到的数据仅为用户行前的位置信息,以及用户行中的轨迹订单信息,但对用户行前之前的数据一无所知,所以如果华为,或者小米这样从底层操作系统的角度就能够完整拿到用户轨迹的厂商,就能够使用用户长期行为模式,短期轨迹和即时上下文,更加精准地预估用户行为。当然这样也会面临着更大的用户隐私风险,毕竟用户的轨迹信息基本是用户最私密的数据了。

参考文献

Zhang L, Hu T, Min Y, et al. A Taxi Order Dispatch Model based On Combinatorial Optimization[C]// Acm Sigkdd International Conference on Knowledge Discovery & Data Mining. 2017.