[LBS]地图Map-Matching流行算法及应用

14年之前一直都在做推荐和变现相关的工作,甚至14年入职高德负责高德变现系统时候也是推荐&变现的延伸,但那时已经开始涉及LBS相关的领域,所以可以认为从工作到现在,自己在做的事就是两个方向: 推荐&变现(推荐和变现很多技术比较类似,所以暂且放到一起),以及LBS。今年初入职滴滴负责滴滴地图的部分AI业务后,主要的精力反倒是转到了地图行业,也算是重新回归LBS这个领域,这个过程中也在寻找地图和传统互联网技术(e.g. 推荐&变现)的结合点和爆发点。虽然目前还没找到,但总感觉是可以有明显的创新和爆发点的,原因如下:

  1. 推荐&变现,变现的主要技术还是纯线上,但现在纯线上流量似乎已经趋于垄断,想玩出花的机会正在变少(当然还还是有很多优秀的公司不断有新的突破,例如今日头条)
  2. 出行领域市场非常巨大,但涉及面比较广,而且这个行业现在似乎还处于传统行业向互联网转的过程中;相当于人们的刚需,现在并没有得到很好的满足
  3. 地图更偏传统行业,数据采集,清洗加工流程都比较重工艺和经验流程,中间很多环节还需要人工参与,成本较高,可改造潜力较大

所以想要找到创新的结合点和爆发点,就需要深入了解地图行业的细节。而如上提到:地图行业更偏传统行业,有很多自有的业务和技术需要学习,内容实在很多[4]。正好近期在整理地图行业的一个基本topic:Map-Matching(中文应该翻译为路网匹配,或者简称‘绑路’),所以就在此记录下这个方向的技术供自己备忘,也有利于同行参考。

Map-Matching背景介绍

一般LBS场景,最基础的数据有三种类型:路网数据, 用户(司机 or乘客)GSP数据,以及用户在产品中的交互数据。其中路网数据包括道路,POI点以及挖掘出来的描述静态物理世界的数据,用户在产品中的交互数据此处比较笼统,可以包含用户的静态Demographic和用户在产品中的使用习惯数据,而本文的重点相关的是第三类数据,即用户的GPS数据。

目前智能手机都集成有GPS芯片,能够间隔一定时间(例如1s)采集一次GPS定位信息, 该信息包括GPS横纵坐标,精度,速度,在各方向加速度等信息,因为采集周期较短,持续时间较长,故在用户量较大的应用中,该数据的规模会非常大,但也是最丰富的采集数据之一。而且该数据是对用户在物理世界时间空间最直接的描述,所以能够挖掘的信息非常丰富。

但问题来了,GPS点采集的时候因为卫星信号的强弱,或是设备周围信号受到干扰(例如有高楼),特别是民用GPS本来就会有误差,导致最后这些数据的漂移在几米到几十米不等,这样就会导致我们采集到的点都是有随机漂移的点,并不能完全反应用户真实的位置。而对于类似于高德,百度,滴滴的地图场景,我们需要知道车辆到底是以怎样的轨迹行驶,在什么时候行驶在什么路上。此时Map-Matching就是LBS服务较为基础的技术,因为它将不精确的用户轨迹点序列映射到确定的路网上。如下图示例:

图:MM示意,其中绿色点为GPS点,蓝色线为map-matching结果,可见GPS点存在飘逸,特别是道路比较密集的场景

虽然理论上GSP点的漂移为10米以内,但在实际应用场景中因为天气,周围环境(高楼,树木,卫星数量等)可能导致的GPS点偏移最高可达数十米,而对于城市中密集的路网来说, 数十米的漂移将会导致map-matching的错误概率大大增加。

而同时map-matching又是很多GPS/Trajectorys挖掘的基础(例如如何挖掘用户出行模型,如何对人流,交通进行建模等),所以map-matching是一个即基础,又重要,且具有较大挑战的基础研究应用方向[1][4]

图:Map-Matching在用户GSP/Trajectory Mining体系中的位置[1]

下文就对当前常用的map-matching算进行介绍,并对后续可能的研究方向进行分析阐述。

Map-Matching算法及挑战

那Map-Matching具体是什么,通俗来讲就是绑路(或者路网匹路),就是将收集到的同一用户(例如高德,百度地图或者滴滴地图司机)在时间空间维度的一系列存在精度损失的GPS点,匹配到最有可能的地图路网具体道路上。

但这个过程存在以下难点及挑战:

  1. GPS点存在精度损失(或漂移),精度损失在十米~数十米不等
  2. 城市道路密集,在小范围内可能存在较多道路
  3. 很多道路间距较小且平行(例如主辅路),或者主路出辅路的交叉口, 这些路上的GPS点甚至从统计的角度都看不出明显规律;或者存在垂直空间重合的路(例如路面和地下隧道平行)

以上都是map-matching在实际计算过程中的挑战,而且很多到现在都没有解决好,也没有很好的思路。

同时学术界和企业的研究关注点是不一样的,学术界主要基于公布的开源数据进行研究,这些数据有以下几个特点:

  1. 数据量较小
  2. 数据单一,一般除了GPS点外,没有其他数据可用
  3. 路线相对单一
  4. 对结果的精度要求相对不高(部分场景)

Map-Matching在滴滴的挑战

但企业就不一样,例如滴滴,和学术界研究的Map-Matching比起来,以下是主要的区别:

  1. 数据量非常大,每天几千万订单,汽车行驶过程中每秒或者每3秒一个GPS点,同时还有合作伙伴的数据;数据量大就会对实时处理性能,以及离线挖掘的数据处理能力提出挑战
  2. 大城市中路线比较复杂,道路比较密集
  3. 对精度要求非常高,甚至需要根据map-matching结果按照里程决定司机的收入,如果map-matching错误,不仅仅会影响到用户体验,还会导致司机或者滴滴平台的损失。例如绑路错误会直接导致平台判定司机行驶路线错误,导致计费错误。涉及到钱的,大家都异常关注和敏感

Map-Matching常用算法

Nearest Neighbor

该方法只是理论般的存在,在现实中根本无法使用, 因为精度太低。思路比较直观:直接计算对应GPS点和候选道路的投影距离,将GPS点匹配到最近的候选道路上。理论上可行,但具体应用的时候,因为城市道路比较密集,且GPS点存在较多漂移,故该方法不可用。一般甚至不会将该方法作为baseline。

图:nearest-neighbor方法,GPS点直接绑到投影距离最近的道路上

HMM

地图匹配中比较经典的方法是使用隐马尔科夫模型(HMM)来实现,该方法的使用方式主要来自于论文[2]。该论文2009年公开发表。目前国内几个互联网地图公司的map-matching算法实现的基本思路基本上都来源于该论文。该论文使用HMM对地图匹配过程进行建模,将匹配的概率分解为观察概率及转移概率的综合结果。

图:有r1,r2,r3三条候选link,两个gps点zt,zt+1,假设zt在r1,r3上的投影分别为xt,1,xt,3,zt+1在r2上的投影为xt+1,2,则该方法的核心思想为:route距离和greate circle距离越小,则可能性越大。此处greate circle为zt到zt+1的球面距离,route距离为假设汽车在某条route上行驶所产生的距离,例如途中的|xt,1-xt+1,2|_route和|xt,3-xt+1,2|_route

在此思路框架下,对观察概率(或叫Measurement probabilities,或emission probabilities),以及转移概率(transition probabilities)进行建模,建模方式如下:

 

观察概率:可以将观察概率建建模成mean为0的高斯分布

图:观察概率建模

其中gc表示为great circle的缩写,表示两点球面上的最短‘直线’距离。其内在含义就是, 如果点zt离ri的球面‘直线’距离越近, 则从观察的角度我们认为zt更有可能在ri上

转移概率:我们假设两个gps点zt,zt+1的距离和对应在道路上的投影点间的路径规划距离(route plan distance)的偏差越小,则说明汽车更有可能在沿ri,到rj的route上行驶(试验也证明这个假设是正确的)

图:转移概率:great cicle距离和route距离差值较小的绑路结果更有可能为真实的绑路结果

有了观察概率和转移概率后,使用维特比算法进行求解

具体涉及到观察概率中高斯分布中的方差,可以使用真值ri和zt的投影距离的Mean Absolute Deviation(MAD)进行参数估计

另外在线上系统使用中,为了保证算法的效果,一般会对数据进行预处理,包括但不限于:

  1. 寻找候选道路时,会仅将观察gps点zt一定半径范围内的link作为潜在的可能link,该半径以外的link将直接将观察概率设置为0。论文[2]中建议的半径范围为200M,但在实际使用中(例如滴滴的使用场景),该半径值会小很多, 因为滴滴的场景更偏城市,路网更加密集,且每秒需要并行处理的量比学术界高很多量级,故候选link搜索半径更小
  2. Route Plan距离和Greater Circle距离差超过阈值的后续link也会被直接置为概率为0, 其中的思想是我们认为这两个值比较相关, 偏差不可能太大
  3. 使用Route Plan距离,以及两个观察点zt+1, zt的时时间差计算出来的行驶速度大于阈值的route,也认为不可能成为候选link,例如计算出的行车速度超过150km/h

在该HMM算法框架下,能够衍生出很多的变种,它们中大部分都是围绕着如何引入更多的信息来对转移概率进行更精准的建模展开了,例如可以在转移概率中不仅考虑greate circle 和route plan distance的差值,还引入转弯次数作为影响因子[3]提升整体算法的效果

HMM+Shallow Model

从数据特征

HMM虽然是经典的map-matching算法,并且和其他算法相比效果上也有优势,但该算法框架下很难引入更多维度的丰富特征提高地图匹配的准确性。例如GPS点其实有很丰富的数据,例如点速度,点方向, gps点的精度;点和候选道路也有较多可以提取的信息, 例如投影距离,是否超速,是否逆行; 另外还可以加入路网特征,包括道路等级, 限速, 车道数等;最后也可以引入HMM中使用的转移概率等信息。以上信息均可以作为模型的输入。

Lable

地图匹配和路况发布一样,有一个最有挑战的问题就是真值的获取。

现在一般有三种方法来获取真值

  1. 人工标注:如果要使用模型, 那至少需要标注几百万的点(我们真的人工标注了几百万的点, 是不是觉得比较汗。。), 耗时耗人
  2. 规则选取:可以通过对已经发生完整轨迹,使用规则判定轨迹中间的部分的绑路结果,例如轨迹中间某段不能确定是在主路, 还是辅路, 但根据后来的轨迹方向可以确定(比如辅路有右拐但主路执行,且轨迹右拐,则说明之前的行驶点是在辅路上而非主路)
  3. 图像+ gps: 使用行车记录仪的图像,确定该图像对应的GPS点所属的道路

模型

使用一般的分类模型即可进行学习, 例如FM或者FFM

因为引入了更丰富的特征,故HMM+Shallow Model的方式效果一般都比HMM要好。我们的试验中,绑路准确性能够提升3.5%

近些年深度学习是模型算法的趋势,但该处我们并没有使用深度学习来解决该问题,主要的原因还是因为真值label获取相对困难,量级没上去,后续随着规则选取及图像的自动化label获取流程打通,成本降低后,会使用LSTM等时间序列模型来提升效果

IRL Map-Matching

学术界还有一类算法来提升Map-Matching ,就是使用强化学习[3]。其思路还是将Map-Matching问题建模为HMM,仍然是将最终的概率分解为观察概率(Measurement Probability)及转移概率(Transition Probability),只是具体操作的时候有以下两个变化:

  1. 计算转移概率的时候,不仅仅使用greate circle 距离和route plan距离的差值计算转移概率,同时引入转弯的信息计算转移概率
  2. 计算转弯概率权重的时候, 使用max entropy IRL进行参数估计。

作者号称该方法能够将error rate降低40%(impressive,但是我没尝试过)

Map-Matching后续研究方案

滴滴每天有接近3KW个订单,每个订单都能产生较多GPS数据,故在滴滴,Map-Matching的挑战主要有以下几个:

  1. 数据量巨大,需要在效果和性能间做tradeoff,甚至考虑到map-matching性能,我们会在客户端上使用简单算法进行地图匹配,只有等到客户端地图匹配置信度较低的时候,才请求后台服务
  2. 真值数据的缺失:人工标注始终成本比较高,而且准确性没有保障,故,如何使用多元数据获取map-matching的ground-truth也是一个挑战。 例如使用行车记录仪图像作为map-matching的真值标注

另外地图匹配处理的数据天然就是一序列的GPS点信息,故从处理算法的角度,比较适合使用时间序列模型来进行处理。目前我们也准备将底层的处理逻辑由原有HMM+Shallow模式向时间序列模型进行迁移。

Reference

  1. Zheng Y. Trajectory Data Mining: An Overview[M]. ACM, 2015.
  2. Newson P, Krumm J. Hidden Markov map matching through noise and sparseness[C]// ACM Sigspatial International Conference on Advances in Geographic Information Systems. ACM, 2009:336-343.
  3. Osogami T, Raymond R. Map matching with inverse reinforcement learning[C]// International Joint Conference on Artificial Intelligence. 2013:2547-2553.
  4. eta技术:http://www.semocean.com/lbs%E5%B7%A5%E4%B8%9A%E7%95%8Ceta%E5%BA%94%E7%94%A8%E5%8F%8A%E6%BB%B4%E6%BB%B4wdr%E6%8A%80%E6%9C%AF/

更多内容也可参见: http://www.semocean.com

[LBS]工业界ETA应用及滴滴WDR技术

介绍

最近几年共享经济比较火,也出现了很多成功的共享经济企业,而共享经济中比较成功的模式大部分都围绕着共享出行展开业务,例如Uber,Lyft, 中国的滴滴,以及近两年遍地开花的共享单车公司(虽然现在部分共享单车的业务已经在停滞或萎缩)

与此同时,很多关键技术也随着共享经济的发展而被重视起来。像MM(Map Matching)[10],RP(Route Plan),Navi(Navigation)以及ETA(Estimation Time of Arrival),这些都是LBS中比较基础同时比较重要的关键技术,无论是共享单车,出租,快车,顺风车等在进行调度,收费定价的时候,都会涉及这些关键技术。

本文就向大家专门介绍其中的一个关键技术:ETA,内容包括: ETA是什么? 为什么重要? 常用ETA技术有哪些,有哪些优缺点,以及现在up-to-date的ETA技术实现细节及效果。特别会重点介绍目前滴滴已经公开发表的WDR模型在ETA上取得的成果

P.S. 本文不会透露滴滴出行内部仍在进行的项目及对应数据,涉及到的技术细节及数据均已通过论文,或者PR文对外公开发表

图:滴滴ETA(接驾ETA以及送驾ETA)

ETA是什么

从业务的角度讲,ETA就是预估一个行程中,从出发时间到到达时间的时间差,例如滴滴快车中预估到达时间,或者高德导航中规划路线行驶所花的时间

图:高德ETA(2:整体路径规划时间预估)

从技术上,我们可以将ETA的一次调用,看成是一次query,每个query的内容为:<o_i,d_i,s_i>,表示第i个请求o,d,s分别表示起点位置(original),终点位置(destination),起点时刻,ETA需要给出的就是t_i  = e_i – s_i,其中e_i为行驶到终点的时刻

ETA问题看似很直接,但现实中需要准确预估ETA却非常有挑战。挑战主要来自于以下几方面:

  1. 时空维度上数据较为稀疏:因为需要预估的物理世界的数据,在时空维度上非常稀疏,虽然滴滴对外宣称每天有近3KW单的订单,但这些订单所产生的轨迹,也不足于充分覆盖时间+空间的路网数据。例如光北京的路网link数就有超过1Million,而从时间的维度,每2分钟发布一次路网交通状况,全天时间维度上有720的时间切片,故时空维度仅北京市共需发布约2亿个发布值,轨迹数据覆盖会非常稀疏。
  2. 存在较多突发局部事件:且很多时候还存在较多不确定性,例如突发性的车祸,或者交通灯损坏,修路,交通管制,等都会导致路网历史信息失效。

数量较少但影响全局的事件:而碰到节假日或者恶劣天气,整个物理世界的交通也会从系统层面恶化导致预测算法整体失效

为什么重要

但ETA又是一个很基础的关键技术,其应用场景非常广泛, 例如路径规划中用来寻找时间最短的行驶路径,分单,定价,拼单等场景都依赖于ETA。其准确性会直接影响到整个共享出行平台的效率,举几个例子:

  1. 体验:选定一条路线后,起终点的预估时间不准确,会直接影响用户对平台的信任,特别是很多时间敏感场景,例如赶飞机
  2. 计价:很多共享出行平台都会在计费的时候引入行驶时间,ETA不准会导致计价预估不准,如果是事前一口价等策略,则可能导致平台亏钱
  3. 调度:例如拼车场景,ETA不准则会导致拼成率大打折扣,影响用户体验,口碑及平台,司机收益

因为上述ETA的基础性&重要性,目前滴滴每天的ETA调用次数超过40 billions次(数据出处:https://outreach.didichuxing.com/tutorial/kdd2018/)

WDR模型

传统方法主要分为两类:

  1. route-based method: 该类方法将route 的ETA问题分解为 subroute+crossing的子eta问题。其中subroute为待预估的<o, d> route的子route, 一般地图行业叫link,为表征地图路网的最小单位,长度为数米到数百米不等,crossing为交叉路口,交叉路口因受到交通灯等的影响,故单独抽离出来。该类方法一般可以作为ETA的baseline,来评估复杂ETA算法的效果。该方法的优点就是计算比较直观,简单,而且具有很强的可解释性,出了问题后容易分析定位。缺点也很明显:时间空间上数据覆盖较低,误差容易积累,因为没有用上道路,时序,个性化等特征,故效果有提升空间。具体参见图:route-base method方法示意
  2. 另一类算法我们称为data-driven method,例如在预估<o, d>的ETA时,可以使使用neighborhood-based的方法找到相似的轨迹时间进行加权来计算ETA[5],类似于推荐问题(具体参见图:neighborhood-based方法),该类问题的缺点仍然是时空上的覆盖较为稀疏,比较适合车流量较大,速度相对均衡的高速或者快速路。例如,在公开的‘Shanghai Taxi Data’上, 虽然后超过3亿个点的记录,但仍然有50%的道路没有被任何轨迹覆盖,且该数据还没考虑时间维度,并且在时间维度上,高峰期和平峰期的数据分布也不一样

图:route-base method方法示意图

图:neighborhood-based方法

在解决ETA问题的同时,也会衍生出来不同分支的子问题,例如比较重要的一类问题是:我们不仅需要预估具体route的eta,同时需要预估对应eta的概率。应为有些场景我们并不需要最短的eta,但需要时间预估最准确的eta,例如赶飞机火车的场景, 一条预估50分钟的路线并不比另一条1小时的route好, 如果后者的预估置信度比前者高很多的话。该类问题可以参考[7]

而比较up-to-date的方法是使用模型来解ETA问题

问题定义

使用传统机器学习的概念, 可以将ETA问题定义为regression问题,即每条sample为给定<o,d,s>以及该sample对应的特征, 将问题建模成回归问题,使用模型来回归具体的ETA值

特征

传统的route-based方法及data-driven方法仅使用计算的路网的traffic特征来计算ETA,该处的traffic仅指具体子route(或称为link)的通行速度(或者对应的通行时间,因确定route后,route长度固定,故通行速度和时间可以相互转换)。

Traffic特征是计算ETA极其重要的特征,但在计算ETA的过程中,我们能够获取到更多更丰富的特征来提升ETA预估的准确性。route-based方法和data-driven方法的问题是很难直接使用这些特征,但复杂模型却能够使用这些特征提升模型的效果。这些特征包括:

  1. 空间特征spatial information:包括<o, d>路线之间经过的link序列,交叉路口序列(intersections),经过的红绿灯信息,走过的(拥堵)POI等
  2. 时间信息(temporal information):例如当前时间的月份,是一年中的第几天,周,小时等;以及根据历史信息计算出来是否为早晚高峰or非早晚高峰,是否节假日等;这些特征可能需要经过预处理才能得到, 甚至需要将时间信息映射到频域,找出频域特征后引入模型(参见后续博文:《LBS时空特征的提取技术》)
  3. 路况信息(traffic information):每两分钟发布一次全网(路网中所有link)的通行速度,该通行速度作为该2分钟时间片内全路网通行能力的重要描述。该路况信息在ETA的计算过程中比较基础也至关重要,发布路况的准确性会直接影响最终ETA的预估准确性,而且根据该路况信息,即可使用route-based方法计算出baseline的ETA。
    另外路况信息发布是否准确也是一大挑战,因为在时空维度下,经过每个 link的轨迹数也比较少
  4. 个性化信息(personalized information) 包括driverid, 乘客id以及汽车相关的属性
  5. 其他特征:例如天气特征等,该类特征对大盘的影响相对较少, 但对用户体验影响非常大,例如下雨天,整体路网的拥堵程度会大幅上升,但下雨天的占比相对较少, 导致模型不一定能学出该规律, 所以最终

优化目标

模型候选的优化目标可以是MAPE,MAE,MSE等,考虑到预估偏差的大小对用户感知体验的影响,与行程本身的时长有关, 故前期在提升模型总体效果的时候,离线模型使用MAPE作为优化目标。在模型基础能力提升到一定程度后, 主要考虑用户体验影响较大的极端CASE时,会同时兼顾异常CASE率,对模型效果进行评估。

其中MAPE定义为:

模型

如,‘问题定义’部分所述,问题一旦定义成regression后, 即可使用传统回归模型进行解决。

近些年深度学习比较火,所以在有足够数据,足够计算资源,对效果又有较高要求的场景, 一般都会使用的深度学习来解决。相较之下,传统的浅模型就没有那么高端了, 但这些模型在特定的场景, 仍然会是比较好的选择。 例如我们在使用模型预估当前的路况状态(行驶道路的状态:畅通,缓行,拥堵)的情况下,使用GBDT仍然会是比较好的选择, 一则我们的Ground Truth较少,目前主要还是通过人工标注获取, 另外则是我们的应用场景需要有较强的可解释性,否则收到用户或者业务方的投诉case时,很难进行分析解释。

在ETA场景中, 浅模型和深度模型的特点如下:

浅模型

传统效果较好浅的模型有gbdt, fm, 这两个模型各有优缺点, gbdt上手比较方便,且能够直接处理连续值,能够自己进行特征选择与组合,但gbdt很难处理特征量较大的场景;fm的效果依赖于特征的表达, 表达能力有限, 对于滴滴的ETA,我们能够获取海量的训练数据,且从加强表达能力的角度考
虑, 深度学习会更胜一筹

图:Wide&Deep模型示意

深度模型

常用的深度模型很多,而且各自有适合自己的优缺点和应用场景,而现在的趋势是构建复杂网络,在复杂网络模型中, 结合浅模型和深度模型的优点,最大化提升预估效果,比较经典且在工业界落地的方法是GooglePlay App推荐场景使用的方法,参见《Wide&Deep Learning for Recommender System》,该方法使用线性模型作为Wide部分进行exploitation,而使用Deep部分进行exploration

Wide&Deep两部分的作用如下:

  1. Wide部分为线性模型,将特征映射到较高维度空间;一般具体的特征会先进行交叉(也相当于在线性模型中引入部分非线性特征);Wide部分主要作用是做memorization,可以充分exploit历史信息,具有较强的可解释性,并且效率较高
  2. Deep部分:将高维特征映射到低维的dense特征(进行embedding),之后进行concate。 Deep部分主要是进行exploration;embedding相当于从已经出现过的数据中学习feature的co-corelation,deep部分更倾向于多样性进行explore

但在滴滴ETA场景,我们引入了世界序列模型LSTM,因为传统W&D方案存在缺点:每个sample的feature必须要对齐,但对于给定<o,d>pair对应的route中,组成route的link数量不一样,一般起终点间距小则link数量会少,反之则link数量会比较多,这些link自身的属性可以作为强特征,对最终ETA的效果影响较大,但传统W&D模型在使用的时候,因为不能处理变长的link序列,故模型很难用到link的local,而只能用到这些link的统计信息,故需要引入额外的网络结构来学习这些local信息;此时时间序列模型能够处理变长输入,故是较好的选择。

所以很自然地在W&D模型基础上增加LSTM结构来adopt local的link序列信息,最终形成滴滴ETA使用的WDR模型

图:WDR模型,其中Wide部分既有dense特征也有sparse特征;而Deep部分的Sparse特征需要首先使用embedding方式转为Dense特征,之后进行Concatenation

 

说到这里简单岔开一下,我们在进行特征设计,或者模型网络结构设计的时候,背后都是有容易理解&解释的Philosopy的:W&D的思路是使用Wide部分进行Memorization,以便对历史信息进行exploitation,使用Deep部分寻找特征之前潜在的Co-Correlation,对特征进行exporation,而R(LSTM)部分则是为了处理W&D处理不好的link边长序列

在具体实现过程中,线性部分一般会先做特征交叉;Deep部分会先将稀疏特征使用embedding方式转成dense特征,lstm部分则在输入link序列后,使用最终的hidden status输入值最后一层,作为最上层regression

评测方法

在评测模型的时候,我们首先对数据进行了预处理,移除了异常的trajectories, 例如travel time < 60s 或者speed>120km/h的trajectories;之后我们使用3个月的数据,并分接驾数据(pick-up)和送驾(trip)数据分别进行模型训练,并将接下来两周的数据按时间维度分为两份,分别作为验证集合(validation)和测试集(test)评估模型效果

指标

离线使用MAPE(之前提总体乘坐时间越长,偏差的容忍就越长)在线则同时使用MAPE, APE20, bad case率对模型效果进行评估,其中: APE20表示absolute error 小于 20%的case的占比,而相反地,bad case 率定位为预估偏差大于50%,或者大于180秒的case,该指标用于衡量bad case出现的概率,控制极端误差case对用户体验的影响

效果

此处仅给出送驾段MAPE衡量的模型效果,现实中送驾段MAPE能从baseline的15.01%降低到WDR的11.66%,而WDR效果可以比GBDT好2.5%.

其中WDR的R部分, 在送驾段能带来1.77%的MAPE收益,可见将local的link信息使用时间序列方法引入模型,能够带来较大的效果提升。

当然,在算法需要上线时,还需要考虑线上服务的性能,故我们还尝试了另外一种更高效的基于Attention机制的深度网络,以后再向大家介绍。

参考文献

  1. 《2017年滴滴出行平台就业研究报告》
  2. Gers, Felix A., Jürgen Schmidhuber, and Fred Cummins. “Learning to forget: Continual prediction with LSTM.” (1999): 850-855.
  3. Cheng, Heng-Tze, et al. “Wide & deep learning for recommender systems.” Proceedings of the 1st Workshop on Deep Learning for Recommender Systems. ACM, 2016.
  4. Wang, Zheng, Kun Fu, and Jieping Ye. “Learning to Estimate the Travel Time.” Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. ACM, 2018.
  5. Wang, Hongjian, et al. “A simple baseline for travel time estimation using large-scale trip data.” Proceedings of the 24th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems. ACM, 2016.
  6. Wang, Yilun, Yu Zheng, and Yexiang Xue. “Travel time estimation of a path using sparse trajectories.” Proceedings of the 20th ACM SIGKDD international conference on Knowledge discovery and data mining. ACM, 2014.
  7. Asghari, Mohammad, et al. “Probabilistic estimation of link travel times in dynamic road networks.” Proceedings of the 23rd SIGSPATIAL International Conference on Advances in Geographic Information Systems. ACM, 2015.
  8. https://outreach.didichuxing.com/tutorial/kdd2018/
  9. google官方wide&deep实现:https://github.com/tensorflow/models/tree/master/official/wide_deep
  10. map-matching:http://www.semocean.com/lbs%E5%9C%B0%E5%9B%BEmap-matching%E6%B5%81%E8%A1%8C%E7%AE%97%E6%B3%95%E5%8F%8A%E5%BA%94%E7%94%A8/

更多内容也可参见: http://www.semocean.com

Mobvista 海外移动变现核心技术

之前受邀在QCON进行了名为海外移动变现核心技术的演讲。正好近期也在总结过去一段时间的工作,所以就直接在这儿总结了。

流量分类

Mobvista的移动变现业务,从流量侧来看,主要分三类流量:

  1. 外部Affliliates的流量,这个就是传统的买量,很多时候我们也不知道流量的来源,仅根据数据表现,以及运营人工经验评判流量渠道的好坏
  2. Mobvista的自有流量,其实也是和开发者谈下来的流量:和开发者签订协议,将Mobvista的SDK达到开发者的app中,之后出Mobvista的广告。一般内部我们就叫该系统为M系统
  3. 程序化买量:Mobvista建立DSP,从各大ADExchange买量

Affiliates买量过程人工运营成分比较多,而DSP可以是一个专门的TOPIC,所以此处就主要介绍Mobvista的自有流量业务的挑战,以及解决方案。

挑战

移动变现,特别是国际化移动变现过程中,面临的挑战非常多,以下是主要的挑战:1,广告样式多样化:banner,appwall, offerwall, native, interstitial, native video, rewarded video。 样式丰富,效果表现不一,导致要进行算法抽象,数据共享的时候存在较大挑战

2,转化路径较长:impression -> click -> install(安装激活) -> 应用内付费。。 甚至impression之前的展示广告是否返回成功,SDK加载是否成功等都是问题

3,流量参差不齐,不同国家间网络基础设施也有较大差异

4,移动广告的归因方式, 决定了产业中出现了较多的黑科技。这个之后值得用大篇幅进行介绍

以上这些问题,都是对算法的较大挑战,也早就叫较多算法优化点以及衍生的创收的黑科技。

技术应对方案

为了应对上述挑战, 我们必须有较为完善的架构, 算法解决这些挑战。 以下为Mobvista变下架构, 主要包含如下及部分,从左至右分别为流量侧到广告主侧

1.SDK:我们会开发SDK对开发者变现流量进行托管, SDK不仅支持IOS系统, 也支持ANDROID系统, 同时支持多种广告形式, 包括native, appwall和video等广告样式, 从功能上SDK主要负责广告分发, 展现控制, 缓存机制及消费空。 其中自创的缓存机制配合算法, 不仅能大幅减少广告请求交互, 提升广告加载, 展现速度,同时还能保证开发这的ECPM

2.Mobvista会对对外的API进行封装, 所以提供直接的OPEN API供开发者调用。 当然, 一般需要配合SDK的控制机制, 才能达到较高的受益

3.Mobvista同时提供完善的广告设置管理portal对广告素材,预算, 展现机制等进行管理控制,方便对广告的金细化运营

4.同时系统中还有完善的实验机制及样式模板管理, 方便整个系统对效果的优化

5.画红线的部分主要包括我们使用大数据平台对ECPM的模型训练及预估机制

对于模型相关的组件, 在省略了工程细节后, 主要是以下算法策略在系统中的重要组件。

与传统变现系统的较大差别, 在于我们为了处理长转化路径问题,对模型进行了拆分, 拆分为CTR预估模型及CVR模型;

同时为了解决多样性问题, 我们设计了定制的优质campaign探索机制, 及Mobvista的Exploration&Exploitation机制;

同时我们使用模型assabling的方法, 对LR, GBDT, FM等模型进行组合,提升预估精度

Ecpm就是我们预估的目标, 以下是我们对ecpm的拆解方法: 其中 ctr及cvr是未知量, 需要模型进行预估。

预估的方法比较直接: 我们寻找优质高效特征对样本进行描述, 同时使用点击和安装作为labels, 之后训练模型对ctr, cvr进行预估, 最后 使用 ecpm = 1000 * ctr * cvr * price 的方式计算ecpm, 并按照计算ecpm进行广告排序推荐

每次模型升级后会使用a/b test机制进行效果测试, 选出效果最好的模型

下图为我们的模型算法框架图。

为了适应我们全球化的变现业务需求, 我们的大数据机器学习平台是给予亚马逊aws云计算搭建的。

平台分为在线预估部分和离线部分,离线部分又分为日志处理及模型训练与配置模块

我们的日志具有较强的多样性及复杂性, 主要体现在两方面:

1.Mobvsita流量覆盖230+个国家, 故我们再多国及地区均有服务器, 数据需要从多地多服务器进行快速收集汇总

2.Mobvista有多条产品线, 不同产品线为适应业需求特性, 会使用不同存储系统对数据进行存储, 故须要从不同系统中对数据进行收集汇总, 包括DynamoDB, MongoDB, 以及内部的多种API接口

数据均使用AWS EMR分布式系统进行汇总, 计算机清洗。 我们会使用azkaban任务调度系统周期性定时启动生成EMR平台, 对数据进行处理, 处理后的日志按照访问实时性要求高低分别存放在 AWS redshift和S3上。 同时我们会根据数据量大小及计算任务复杂度动态调整EMR集群资源, 在保证计算任务实时性要求的同时, 减少计算资源浪费。 并在AWS上搭建机器学习平台进行模型训练。

更多内容可以参见PPT:

更多内容可直接访问: semocean.com

 

 

Mobvista反作弊系统实现

2017 GITC上的分享,做一个简单的记录

  • Adloox estimates advertisers could be wasting $16.4 billion to fraudulent traffic and clicks manufactured by bots in 2017
  • more than double the $7.2 billion the Association of National Advertisers estimated would be lost to ad fraud in 2016.
  • The World Federation of Advertisers, meanwhile, predicted last year that ad fraud will cost advertisers $50 billion by 2025, describing the malpractice as an organized crime “second only to the drugs trade.”

这是沿引adloox的分析, 2017年网络作弊导致的预算损失搞到164亿美金,预计2025年将达到500亿美金,仅次于毒品交易(如果将网络作弊看成是犯罪的话)

回到流量变现, 如果将其看成是一个生意,一个买卖的话,我们可以将流量侧看成是卖方,在卖流量,而广告主侧是买方,而Mobvista类似的广告平台,就是作为中间商负责分发赚差价(暂且抛开中间的定向,投放算法不说)。 而作弊,我们就可以看成是在这个生意中,售卖假冒伪劣商品。

抓反作弊的思路的核心,就是分析中间存在利益作为的环节,或者叫:Follow The Money。我们可以简单的认为,作弊的动机都是从supply流量侧过来的,越接近demand侧,作弊的动机越小。 而作为中间商的Mobvista,收的是demand侧,广告主的钱,所以需要保证demand的质量, 否则广告主就去投其他平台了,这也是为什么各个广告平台现在都比较在意反作弊的原因。相当于Mobvista自己构建了一个质量检测体系。这个体系的价值表现为两方面:

  • 能够保证广告主的质量,保证广告预算不丢失
  • 保证Mobvista品牌形象,做长期生意,将生意做大

作为广告平台,Mobvista的反作弊体系主要有以下四方面构成:

  1. Mobvista自建反作弊体系:主要是我们根据广告主的投诉,或者主动分析流量的特征制定的反作弊策略,目前引入的特征已经有20+维,覆盖点击作弊,安装作弊和安装劫持。目前覆盖了公司revenue的10%,还不包括市场上没有被抓出来的,可见市场上作弊的猖獗
  2. 和广告主合作定制的策略,例如监控event postback
  3. 另外比较重要的一类指标,就是跟进第三方监控平台的策略和指标,在我们自己的系统中实现
  4. 我们也会和一些知名的第三方反作弊服务合作,增强我们的反作弊服务,例如Distil Networks, Fraudlogix

从实现的方式上来看,Mobvista反作弊主要三种方式:

  1. 在线实时反作弊:例如实时的IP黑名单点击过滤,地域异常实时过滤等,直接就将点击过滤掉不发到demand侧。在线实时反作弊的优点是过滤及时,从数据层面广告主并无感知,也不会污染广告主的数据; 缺点是能够实现的策略相对较少
  2. 离线挖掘反作弊:离线周期性按天,或者周运行反作弊逻辑。优点是有大量数据特征可供分析,而且可以做各个特征的交叉。准确性和覆盖率都比较高; 缺点是这是事后的方式,可能损失已经产生无法弥补
  3. 混合方式:主要是引入了算法提供数据和建议+人工决策的方式。例如对于嫌疑比较大的CASE,算法抓出来后,并不会直接做决策,而是交由人工决策是否扣款,或者是否先不付款等

因为反作弊是和人斗的技术方向, 而人有较多的创新,所以反作弊的技术不全都适合机器学习来完成,必须有较多规则。 所以Mobvista的反作弊,可以认为30%模型+70%规则来实现

人与机器的行为区别

在反作弊分析过程中,也需要时刻牢记人的行为和机器行为的区别,虽然反作弊的人就是将机器算法的行为去模拟人的行为,但一般还是会有一些蛛丝马迹

  • 人:行为有共性,符合特殊分布 vs 机器:随机
  • 人:群体量大,个体分散 vs 机器:群体量小,个体集中
  • 人:能力受限 VS 机器:能力不受限

反作弊的思想,就是以下两点:

  • 以人为本
  • 以利益为出发点进行探索,Follow The Money

以下是几个例子:

点击安装时间差异常:

机器自动抢发

ip重复安装

点击安装时间天级别异常

最终涉及到的特征会有20+维,针对不同的作弊方式,都会比较有用,会后会有文章详细介绍

完成PPT参见:《Mobvista 反作弊系统实现

更多内容也可参见: http://semocean.com

 

 

 

 

如何使用机器学习解决实际问题-以关键词相关性模型为例

本文以百度关键词搜索推荐工具字面相关性模型为基础,介绍一个机器学习任务的具体设计实现。包括目标的设定,训练数据准备,特征选择及筛选, 以及模型的训练及优化。该模型可扩展到语意相关性模型,搜索引擎相关性及LTR学习任务的设计实现。该模型的设计调研实现,也可以很容易移植解决其他包括语义相关性的问题

目标设定:提升关键词搜索相关性

作为一个搜索+推荐产品,百度关键词搜索推荐系统的产品形态是向凤巢用户推荐适合他业务的关键词。例如一个卖鲜花的广告主,他想在百度上做关键词搜索推广时,需要提交和他业务相关的关键词,而且提交的关键词需要业务相关,例如他需要提交和卖鲜花业务相关的关键词。例如鲜花快递,鲜花速递等。此时他可以在百度关键词搜索推荐系统中进行搜索查询,选择适合他的关键词。

百度关键词搜索推荐系统query搜索

这是一个典型的搜索问题,具体的从输入query,到触发,到排序等会涉及到很多因素,例如如何查倒排,如果处理地域因素等;要提升搜索的质量,我们首先需要保证输入的query和推荐出来的推荐词的相关性,此处我们要解决的主要问题, 就是如何快速,准确地判断两个关键词(输入query和推荐词)的相关性,需要特别注明的是,我们主要的目标是让用户觉得该产品结果很靠谱, 所以该处我们仅考虑字面相关性,更多的语意扩展该模型并未考虑。

注:该模型的调研实验实现方式, 可以很容易平移到语义相关性。例如加入更多语意特征,例如plsa的bm25特征和word2vec的相似度特征(或者和扩展的相关性校验,例如将待推荐词扩展为baidu搜索结果的摘要扩展)提高语义特征的贡献。

相关性也是所有搜索问题的基石,只不过在不同的系统中使用方式不一样, 在一般的搜索中,相关性占有较大权重, 排序基本就以相关性为依据; 在商业系统中,相关性则经常作为搜索展现的门槛用于控制商业推广结果的质量(如果仅考虑CTR, 用户搜索鲜花快递时,给用户展现艳照门的结果,CTR会更高,但相关性较差)。  当然,判断相关性我们可以简单使用某一种方法进行直接判定,例如直接进行两个关键词的TF-IDF计算,或是进行两个关键词的BM25。但这样的方式效果都不太理想,想要达到更好的效果,就需要使用更多特征,而更多特征很自然地,需要使用模型组合这些特征,达到最终的预期效果。

图:相关性在关键词系统中的位置

此处将会使用机器学习的方法解决该问题。本文以下内容会从数据准备, 特征选择, 模型选择, 模

型调优等步骤介绍百度关键词搜索推荐系统如何解决该问题

数据,特征,模型

说到使用机器学习解决问题,我们经常提到的优化思路就是3方面的优化: 数据,特征,模型。首先找到充足的,准确的label数据(该出仅考虑有监督学习任务,例如相关性,或是LTR),之后提取贡献较大的特征作为input space,以label作为output /ground true label,之后优化模型(Hypothesis) )。下面会分别从这3方面对整个优化过程进行阐述

准备训练数据

训练数据的获取一般有几种方式:

  1. 人工标注: 优点是质量较高,噪音较少;缺点是标注结果和标注者本身的认识相关,例如在搜索引擎中,判定苹果和手机的相关性,对于年轻人,一般都认为相关;但对于比较多的老人,可能认为不相关;另外一个缺点就是人工获取标注的成本较高
  2. 从日志中进行挖掘:优点是数据量相对更大,获取成本较低(编写几个hadoop脚本对日志进行统计);缺点是噪音较多,例如搜索引擎中的恶意抓取访问导致的噪音数据

在相关性模型中,一开始我们使用百度关键词搜索推荐系统的人工反馈数据作为label对模型进行训练,分别提取1.5W query-推荐词pair作为正负例进行特征提取,模型训练。

 

如图所示,在交互上,当用户喜欢该关键词时,就会点击‘大拇指’表示该结果符合用户需求(正反馈,该query-推荐词 pair可作为正例);如用户认为该关键词不符合需求,就会点击‘垃圾桶’,将该关键词扔入回收站(负反馈,该query-推荐词 pair 可作为负例)

在实验中,我们发现正例没有问题, 不过负例中会存在较多这样的情形: query-推荐词是相关的, 但该用户不做该业务,所以被定义为负例,所以负例个性化较强。所以后来我们让产品经理同学又对负例子进行筛选,重新标注1.5W负例,进行后续特征提取, 模型训练。

之后我们将正负例打散后(直接使用python random.shuffle)分成10份,进行cross-validation

模型训练前,先定标准和样本

注: 训练样本的挑选完全决定了我们的问题目标,所以在一开始就需要准确选择,如果可能,所有的case都最好人工来搞,或者至少需要人工review。 确定没有问题后,再开展后续工作。特别是相关性类似的问题,比较主观,例如PM和RD在该问题的判断上就可能存在一定差异。

确定完训练样本, 评估标准,之后再小布快跑, 优化模型。

特征提取

一般特征的选择及处理会极大地影响学习任务的效果,而进行特征选择的时候,一般是先增加特征,并实验效果。 对于相关性模型, 我们可以先将传统的信息检索的特征加上,这些特征一般分为以下几类:

  1. query/候选词的一般结构特征: 例如query/候选词长度,term数等
  2. query-候选词的相关性度量:例如TF-IDF, bm25, LMIR及多重变种, plsa相似度度量,word2vec语意向量相似度等; 很多时候,关键词自身信息较少,还可以使用关键词在搜索引擎上的摘要扩展进行相似度度量
  3. 关键词自身在信息检索维度的重要性度量,例如关键词idf, 从语言模型方面的重要度等

在一开始的时候,我们可以先将能够想到,构造出来的特征均加入特征向量进行实验,而且每加一类特征,都可以看下该类特征对整体目标的提升程度。以便对该特征的贡献度有一个直观的感受。

以下数据可以简单看出随着特征的增加,效果的提升,其中的特征仅加不减(模型使用random forest   进行二分类):

等到特征加得差不多,模型准确性已经提升不多的时候, 可以考虑砍特征,有一种比较简单粗暴有效的砍特征的方法,就是使用树模型,就是直接砍掉特征贡献程度及特征重要性较低的特征,例如直砍掉特征贡献度为0的特征,对相关性模型的准确性几乎没有影响

特征贡献度

当增加特征已经很难提升效果, 考虑到为了防止过拟合,同时考虑到模型online预测,需要对特征进行挑选。在使用树模型时,可以直接使用数节点特征贡献度和节点使用次数,判断是否需要去除该特征,以下为使用树模型进行选择特征的例子:

对于特征贡献度和分裂特征使用次数为0的特征,在调研时,直接去除对模型效果几乎没有影响,而且能提升预测的效率。

在选择特征的时候, 有一些经验值得分享:

  1. bm25特征及term weight特征对分类任务有极大贡献
  2. 一些单独的比值类特征并没有太大贡献,例如query,推荐词共同term与query term数,推荐词term数的比值,这些特征并没有太大贡献,但是这些特征与query,推荐词的term数结合到一起,贡献就非常多;所以有些特征需要联合在一起,才有较大作用。
  3. 特征选择需要和目标一致:例如word2vec是非常高大上,且非常靠谱的技术,但用在字面相关性,对目标并没有太大贡献(如果目标是语意相关,那么类似于PLSA,word2vec将会有很大贡献)
  4. 有些特征就就是用来解决特殊case的,虽然贡献不大,但需要保留(当然也可以直接设置为强规则与模型配合),例如query与推荐词拼音一致

模型选择

经典模型

最开始我们尝试了最大熵,SVM和adaboost模型, 考虑到online使用的效率,最终我们选择了adaboost模型作为线上使用的模型,虽然效果不是最好的,但使用简单的weak learner构建的模型的确比较快(参见博文:《adaboost》),并且使用adaboost进行上线并取得较好效果:上线后不仅召回增加,准确性上90%的case相关性高于等于原有结果(采用非模型的版本)

评估结果分布图(2到-2分别代表扩召回结果相关性高于、略高于、等于、略低于、低于线上策略)

集成树模型

现在特别喜欢使用树模型,因为使用的时候,连特征归一化都省了: 如果使用SVM类似的模型,还需要对特征进行归一化等处理, 但使用树模型,直接将特征向量及label扔给模型, 模型自己会根据信息增益,或是基尼系数等标准选择最合适的拆分点进行树节点的拆分(具体的拆分标准可参见博文:《使用impurity选择树模型拆分节点》),开源的树模型,例如大名鼎鼎的Quinlan的C4.5或是C5.0都在调研时都可以拿来试试作为特征选择的依据。

特别是集成树模型的出现,更是极大地提升了树模型效果。所以现在的项目中,我比较喜欢在增加特征的时候就使用集成树模型进行效果实验。 具体树模型使用参见《集成树类模型及其在搜索推荐系统中的应用

集成树模型配置选择

此处的配置选择和传统的模型参数稍有区别,该出的树模型配置主要指集成树模型中树的数量,每棵树的特征选择因子和样本使用因子等。在项目中,考虑到准确率和速度,最终确定的参数是树的数量是20, 特征选择因子和样本选择因子均为0.65(每棵树随机选择0.65的样本和特征进行训练)

具体产品效果可参见www2.baidu.com中百度关键词搜索推荐系统的排序结果:

如何个性化

首要需要考虑的是我们的数据样本,是否本身就是包含个性化的case(此处的答案是否定的); 假设我们的标注case是个性化的,也就是case中本身就包含了个性化结果时,在模型训练流程上其实并没有太大区别, 主要的区别就在于我们选取哪些能够区分这些个性化的特征, 例如百度凤巢中账户(单元)的plsa模型产出的pzd向量与query的相似度等

登录www2.baidu.com->关键词工具->搜索query->查看结果 即可。

更多内容也可参见: http://semocean.com

百度搜索引擎变现策略指标体系

下文就百度商业变现的指标体系进行概要描述,并针对一个类似于百度LBS系统的变现思路,阐述一个商业系统变现策略指标体系的建立过程。

为什么需要商业变现策略指标体系

一般情况下,一个互联网产品,或是一个移动端产品在发展前期,主要会关注流量及用户量的增长。当流量,用户量做到一定程度时,就会考虑商业变现。例如今日头条,美丽说,高德地图这样的产品现在都开始商业化变现。而要从变现效果,效率衡量整个系统,以及监控技术策略对系统变现的贡献时,就需要建立一套完善的策略指标体系监控系统当前的状况, 发现系统策略效果瓶颈并有的放矢地去提升。
之前在百度,在和一位高级技术经理聊天时,他就说过, 之所以百度内部一位从Google过来的VP很受老板的重视,一个非常大的贡献,就是他推动百度凤巢指标体系建立,保证公司收入灵活可控,保证每次百度都能在华尔街交出漂亮的财报
指标体系包含的内容

广告主关心的指标

在广告界的人士都知道广告主的这样一句名言:“我知道我投入的广告费用的一半是白费钱财,但问题是,我不知道是哪一半”。而搜索引擎的搜索一大优点,就是能够监控每一次搜索点击的效果。
对百度广告主来说,他们最关心的,和所有的商业投资一样,是:投资回报率 (ROI)。广告主们(商家)想知道在百度体系的广告的投入是否真的有回报,而这个回报是否能够超过投入的资金,超过的比例有多大,这一点上,搜索引擎商业变现系统是做了精心的设计的:
从商家的角度理解ROI,就要了解三个指标:
1.广告展现次数(简称show):当网民提供关键字,使用百度的搜索业务时候,相关的广告也会根据算法出现在页面相应的位置,用户投放的广告的展现次数,每天,每周,每月都会有统计。 当然,相对于传统的广告投放模式,只要展现了就要收费,百度对展现的广告是不收费的,哪怕用户看到了广告主企业的名字和推广口号,广告主已经获得了一定的广告收益,是要用户不点击广告链接,广告主不需要支付任何费用(针对竞价排名高,和右端广告而言)。这在传统的广告界是不可想象的,因为传统媒体,例如电视,包括门户网站上的banner广告,都是按照展现收费的:看到一次收一次的费用。
2.广告点击次数(简称clk) :用户看到广告后,点击了广告主提供的链接。 可以用每千次广告展现的点击率来计算。网民点了推广信息的链接。推广信息被点的次数被称为点击量,即Clicks,产生的费用叫做点击费用,平均到每次点击的费用被称为单次点击价格,即CPC,是Cost Per Click的缩写。推广信息点击量与展现次数之间的比值被称为点击率,即CTR,是Click-Through Rate的缩写,计算公式为:点击率=(点击量/展现量)×100%
3.点击率到商业收益的转换:用户点击了客户的广告,就会看到客户自己的网站页面,如果被客户提供的商业服务或者产品所吸引,而付费的话,那么客户就实现了一次成功的商业收益
因为商业系统必须要保证客户(广告主)的利益,这样才能长久合作,所以商业变现策略指标体系必须包含这些指标。
在类似于百度,360,或是Google这样的搜索引擎, 其能精准监控的,就是1,2, 对于最终的商业转化,因为是在商家的网站上完成的,所以除非网站上内嵌了搜索引擎单独提供的独立工具(例如百度的福尔摩斯),否则搜索引擎无法了解这些信息。
投资人关心的变现策略指标
以上是百度广告主需要关心的指标。对于百度这样的上市公司,每个季度的财报中都需要有公司详细的赚钱相关财报内容及各种指标分解,以便了解当前变现系统的健康程度及瓶颈及后续的突破点。
例如百度的投资人不仅关心这个季度百度多挣了多少钱,还会关心多挣的这些钱是来自于哪个环节的提升,是否可持续, 是否后续还有增长空间。 就和分析公司财务报表,或是分析股权收益率一致。
为了让大家对搜索引擎变现策略指标体系有一个对比了解,以下先用股权收益率说明问题。大家可以不用有较强的金融,财务知识也能看懂这个公式,而搜索引擎变现策略的指标体系,与此公式有异曲同工之处,都是将最终的收益(率),分解为各个相对独立的因素,以便发现系统挣钱效率的优势与瓶颈。
该公式主要的目的是让大家了解如何对最终目标指标进行拆解,如果大家不感兴趣可以跳过该节。
股权收益率
即在股市中,投资人购买的股票收益率, 设想一下,一个精明的投资人, 在购买了某个公司大宗股票后,一方面会关注每年的股票收益,另一方面也会分析股权收益是来自于哪些因素的上涨,这样才能分析公司增长是否健康,例如,股权收益率可以简单地使用以下公式计算ROE=净利润/权益。但如果要对这个公式进行细分,将其中对股权收益率相关的影响因素均拆分出来,那可以得到以下公式:
其中
  1. 税收负担比例:反映公司的税收负担情况,例如有一个季度百度的税率为腾讯的一半,因为百度和国家有什么高新技术的合作所以税收减免(记得百度可能是7%左右,腾讯13%左右,不是精确比例),类似的情况就可以在(1)中反映
  2. 为公司向债权人负担的利息比例, 借的钱越多,这个值越小
  3. 利润率:为每一块钱的销售额所带来的利润。
  4. 资产周转率:为公司资产的使用效率,例如家乐福,沃尔玛虽然利润率很低,但因为出货量大,所以照样赚钱
  5. 杠杆比例:公司资产与公司权益的比例,用于表示用于赚钱的钱中,有多少是自己的,有多少是别人的(例如银行)。例如:北京以前买房的人都发了,因为买的早,一方面房价便宜,一方面使用银行贷款,假设30%首付,那相当于剩下70%银行贷款在房产上的收益,也是自己的。
类似地,如果对百度商业变现体系的收入进行一个拆解,也能将其分解为类似的独立因子,对系统效率进行细化分析。
搜索引擎投资人关心的变现策略指标
从宏观上,我们假设投资人都是唯利是图的,收入是他们最关心的事。当然,很多投资人也会兼顾长远的收益,所以他们会关系收入是如何组成的。我们这里抛开运营,股权收益,利息支付,税收等各种公司的开销,我们仅考虑变现系统的名义收入,即搜索引擎中计费系统的计费和。此时可以将搜索引擎收入分解为以下独立因子:
Revenue =PV * PVR * ASN * CTR2 * ACP
以上公式就是百度,360,Google搜索广告变现收入的拆解。
要弄清楚以上公式的具体含义,需要了解下列指标的定义:
  1. CPM1:cost per thousand1 按每千次检索收费, 百度用户每使用百度一千次做搜索为百度带来的收益。 也就是用户使用了百度服务一千次所带来的百度的收入。这个是衡量百度赚钱能力的重要指标。是百度变现能力的基本衡量标准。是根据每个季度的总收入除以PV(Page View)算出来的。
  2. CPM2:cost per thousand2 按每千次展示收费,广告所在的网页被浏览了一千次,即认为该广告展示了一千次。 这个指标是衡量广告客户的广告展现了一千次的时候,客户交付的费用(注意客户是在用户点击广告后才付费的). 这个指标可以衡量用户对于广告的感兴趣程度。从广告客户的角度讲,也可以衡量在百度投放广告的费用多少,以及投放的有效性。
  3. CPM3:cost per thousand3 表示平均每千次有广告展现的检索请求对应的广告收入,衡量单次有广告展现检索的平均收入贡献。这个指标是衡量当搜索结果的页面有广告展现的时候,每展现一千次,百度能够拿到的收入。有的搜索结果是没有广告展示的(CPM1把这些PV也计算进去了)。
  4. CPC:cost per click 按每次点击收费,是目前最流行的搜索引擎营销的付费方式,即只有当用户点击观看了你的推广链接后,才发生费用。
  5. CPA:cost per action 按每次用户消费行动收费,被认为将是互联网广告未来必然的发展方向,但由于不同产品的广告对action的定义和回报率有太大差异,实现过于复杂,目前在全球范围尚无搜索引擎使用CPA收费的成功先例。
CTR——点击率,在这里特指广告或推广链接出现后被用户点击的机率。CTR还将可以进一步的细分。
  6. CTR1:表示平均每次检索请求对应的广告点击数,衡量单次广告检索的平均点击贡献。理论上 CTR1 可能大于 1。因为每次检索客户可以点击一个广告,看了后,在回去原来的检索页,点击下一个广告。
  7. CTR2:表示平均每次广告展现对应的广告点击数,衡量单次广告展现的平均点击贡献。
  8. CTR3:表示平均每次有广告展现的检索请求对应的广告点击数,衡量单次有广告展现检索的平均点击贡献。理论上 CTR3 可能大于 1。
  9. ARPU:户均消费,影响它的因素包括:点击流量大小、关键词的相关性、同一关键词的竞争度,以及客户在搜索引擎广告上的预算上限等。
  10. PV:检索量,百度搜索框的搜索次数
  11. ADPV:出广告的检索量,即PV中,有广告展现的搜索数量
  12. CLK:click number,广告的总点击次数
  13. CSM: 百度广告主的总广告费支出
  14. ASN:平均展现条数。即:如果展现了搜索推广广告,每次平均展现多少条
  15. ACP:Average Click Price 平均点击价格  总消费/总点击
  16. PVR:Page View Rates, PV比率,出广告的检索量 / 检索量
有了以上这些定义后,我们再来回顾变现系统的计算公式:
Revenue =PV * PVR * ASN * CTR2 * ACP
可以看出以上各因子表明了变现系统不同组成的效率
  1. PV:是百度能够用于变现的流量上限,由用户体验决定,百度越好用,口碑越好, PV越高。该指标在百度类似的搜索引擎公司,主要由搜索部门负责。
  2. PVR:就是PV中被用于变现的比例,PVR越高,说明在百度搜索中,出广告的概率越高,有可能导致用户体验的下降
  3. ASN:单次有广告展现的PV,展现的广告数量,表明单次有广告展现时的变现利用程度。ASN越高表明单次搜索出的广告越多,可能导致用户体验的下降
  4. CTR2:单条广告展现时, 广告北点击的概率。表明广告推的是否精准,是否满足用户需求(至少是感官上是否吸引用户)
  5. ACP:单次点击价格,相当于单价的高低
这样的指标分解非常有利于指导策略的优化,以下是几个case:
  • PV:搜索部门的重要指标,增加下降,都能立刻看出搜索部门的业绩,或是竞争对手带来的影响,例如,就百度而言,Google退出中国PV上升,360上了搜索, PV下降,都能直接看出来
  • 点击率预估:假设PV,PVR,ASN,ACP都固定,则要增加收入,需要提升用户对广告的点击率,此时可以用模型来对点击率预估,提升CTR2。各大搜索引擎公司,对CTR2的预估,基本上都是商业部门的重要机密,也是最重视的技术之一
  • 增加广告展现:在各上市公司(包括传统行业公司),都会有‘冲业绩’这么一说,就是极度末时,为了达到之前的营收计划,需要使用各种手段增加收入,例如我们经常听说的银行给高利息临时拉存款等,在百度则可以通过调参提升收入,比如增加ASN或是PVR,达到收入符合华尔街预期的效果
  • ASN的变化:如果收入的增长是来自于ASN的增长,则说明百度的点击卖得更贵了,广告主会不乐意。相反,ASN下降,说明点击卖便宜了,百度的收入有可能降低,所以类似于CTR2上升,ASN不变这样的策略,是最好的
有了以上定义即收入的拆解,则收入可以用其他集中形式表示:
Revenue = PV * CPM1
Revenue =PV * PVR * CPM3
Revenue =PV * PVR * ASN * CPM2
Revenue =PV * CTR1 * ACP
Revenue =PV * PVR * CTR3 * ACP
百度商业部门的工作,几乎每天都是在围绕着这些指标来进行的。每一次策略的调整,工作方式的改变,都希望在这些指标上做出正向的贡献,因为这些指标对百度的收入是直接造成影响的。从百度的收入(Revenue)的计算公式上就可以看出(每一种计算方法得到的结果都殊途同归)
如何建设LBS变现策略指标体系
拿百度地图类似的LBS产品为例,假设我们的转化漏斗路径是:推荐&搜索之后展示结果列表也,然后用户点击结果进入店家的表述页面(POI),之后如果用户感兴趣,则点击具体的团购,优惠券进行购买,搜索漏斗如下:
图:搜索漏斗
对应到线上系统,在评估衡量线上系统效果时,我们也需要分为这3阶段进行衡量,以及时发现线上策略效果的瓶颈所在, 快速找到提升重点。在以上3阶段中:
  1. 搜索or推荐:主要表明流量大小
  2. 点击详情页: 表现为用户带来的流量到详情页的浏览情况
  3. 转化:最终转化action
对于商业系统,我们最重要的目标就是保证在既定流量上,转化最高。
以下为我们需要关注的所有指标:
表:策略效果指标
如后续变现系统按转化收费,则整个LBS变现系统收入可定义为:
收入=  pv * pvr * easn * ctr2 * atr2 * aap
在产品的不同阶段,我们需要关注的重点不一样:
  • 在产品上线的阶段,我们需要关注用户体验,所以ctr2和atr2需要重点关注
  • 用户体验提升到一定程度,商户已经认可我们产品效果时,再考虑提升成单的单价(例如佣金等),同事可以考虑对商业POI进行放量,提升pvr和easn
物料召回及检索类指标
该类指标主要用于监控系统的检索量, 以及系统的召回能力。 检索量等指标是系统变现可以使用的所有资源,更多受用户产品影响;而召回能力相关指标则体现出CPR系统对商业物料的召回能力。
以下为重要指标说明:
  • 检索量: 发送到系统的所有请求量;通过统计检索日志条数得到;为能够变现的流量全集。
  • 查询用户数:所有发起请求的用户数;统计检索日志中去重后uid得到,体现参与检索的用户量。
  • 用户平均检索量:平均每个用户发起的请求数量;体现用户检索角度的活跃度。
  • 单次检索返回结果数:平均单次检索返回结果条数; 体现系统的召回能力(准确性参见相关性评估)
  • 商业结果检索量:出现商业结果的检索次数;
  • 商业结果检索用户数:出现商业结果的检索用户数;体现商业结果能够覆盖的客户群体
  • 商业检索占比:出现商业结果检索量占总体检索量占比;可根据改指标分析潜在变现流量。
  • 商业检索用户占比:看到商业结果的用户占所有检索用户占比;可根据该指标分析潜在变现用户。
  • 单次检索商业结果返回条数:一次出现商业结果的检索,返回的结果条数;
点击行为类指标
该类指标主要用于衡量用户浏览搜索/推荐结果后的点击行为。该过程为转化漏斗第二阶段。
以下为具体指标及含义:
  • 点击条数:被点击的POI数量(包括自然POI和商业POI)
  • 有点击检索次数:产生点击行为的检索次数(包括自然POI和商业POI)。
  • 有点击用户数:产生点击的用户数量。
  • 商业POI点击条数:商业POI被点击的数量。
  • 商业POI有点击检索次数:出现商业POI,且产生商业POI点击的次数。
  • 商业POI点击用户数:点击商业POI的去重用户数。
  • 单次检索点击率:平均每次检索点击POI的概率;该值理论上可能大于1
  • 单次检索商业POI点击率:平均每次检索,点击商业POI的概率;该值理论上可以大于1
  • 单条商业POI展现点击率:平均每条商业POI展现的点击概率;用于衡量每条商业POI曝光产生点击的效率。
  • 单次有商业结果展现点击率:平均每次有商业POI展现的检索的点击概率;用于衡量出商业POI的流量产生点击的效率。
效用类指标
该类指标主要用于衡量用户点击进入POI详情页后,根据详情页信息,做出最终决策的阶段(包括点击‘预订’,‘成单’,‘下载’等行为)。该过程处于转化漏斗的第三阶段,也是最终阶段。
以下为具体指标定义:
  • POI展现数:包括自然POI和商业POI的展现次数。
  • POI展现用户数:浏览POI的去重用户数。
  • POI详情页转化数:此处的转化根据每个入口可能有所不同。
  • POI详情页转化率:POI详情页转化数/POI详情页展现数。
  • 单次转化收费: 完成单次转化后,向商户收取的平均费用。
以上密密麻麻的指标,在不同的商业变现系统中会有所差别,但基本上都是按照用户产品形态及转换漏斗进行设定,而每个策略的上线,都会使用类似的指标体系来衡量策略对不同漏斗部分的效率影响。
更多内容也可参见: http://semocean.com

《小米是如何炼成的》-雷军百度讲互联网思维做手机

雷军前些天到百度给百度的员工进行了一次演讲, 演讲的题目是《我和小米这三年》, 主要介绍了小米的铁人三项:软件,硬件和互联网服务; 以及如何用互联网思维做手机。 尽管是非开放性报名, 仅有高T和M序列能报名。虽然讲座在百度大厦最大的五福降中天举行,但现场还是超级爆满,而且很多没报上名的同学很早就在现场门外守候, 期望最后能有机会进场。
黑百度的开场
雷军上台演讲后, 先没干别的, 立马黑了百度一把, 雷军说:‘大家知道, 百度还是一家挺好的公司, 在全国范围内就不说了。。。。’, 此时按照逻辑, 我会以为雷军会说百度在国际上也有一定知名度, 结果雷军顿了顿后,接着说‘在中关村, 百度还是一家不错的公司。。。。’当时立马笑喷了, 觉得雷军带着一种幽默来踢馆。 在后来的演讲中, 一直伴随着类似的幽默, 所以整个演讲下来, 一方面觉得说活颇多, 另一方面也不觉得累, 因为雷军非常风趣。
讲座部分流水账
接下来的演讲, 雷军先介绍了小米的8位co-founder, 听起来背景都挺牛的, 也介绍了小米成立那天几个同事一起喝小米粥的故事, 还有google 全球副总裁的hugo早就谈好来小米, 但重点提到: hugo是来小米, 但一直不来北京: 啧啧, 污染那么严重, 也可以理解。。。
之后就介绍了小米13年的业绩, 当时雷军给了一个截图, 图中列出的是全球最具创新企业50强中的部分企业, 当中惊奇地发现小米居然名列第3, 好像比苹果还要高。 当时觉得老牛了, 后来百度了一下, 360也是最具创新的企业之一, 后来才知道这个奖有两个版本。两个版本的结结论还差了好多。
后来就是介绍小米的一些产品, 功能设计理念的介绍。 雷军主要围绕着设计贴心产品
互联网思维做手机
在整个讲座中, 有两个内容让我印象深刻, 一个是雷军详细介绍如何使用互联网思维做手机的思想;另一个就是就是小米如何考核员工的KPI。
雷军使用了一个图完整地描述了他的思想:
  • 专注地快速做到极致打造口碑
整个过程的中心, 就是如何打造良好的口碑。 可以将图分为两部分: 打造口碑所要做的事, 在上图的左边, 包括专注, 极致, 快等几个因素, 都是小米自己需要做到的: 只有将事非常快地做到极致, 才有可能在用户心中建立良好的口碑, 而要将事做得非常快地做到极致, 就需要专注。
在Q&A环节, 有同学还专门问了雷军:极致和快, 很多时候是相互矛盾的: 做得快, 很可能就很难做到极致, 反之亦然。 我当时也好奇, 雷军如何回答这个问题。  雷军给出的答案是: 需要专注。 他提到小米就只做手机, 虽然很多人提议他做很多东西, 但很多都被他咔嚓了。。。 后来想了一下, 其实很多互联网大佬在实际执行的过程中, 都体现出专注, 例如百度的boss Robin,就一直在提专注, 专注地做搜索(当然, 后来发现, 也不能太专注, 或者说是要有远见地专注,例如作为搜索护城河的输入法, 浏览器, 在早期的百度, 就没有收到太多重视。 要眼观六路, 耳听八方地专注)。在一万小时天才理论中, 也提到专注于某一项即能, 1W小时成为天才的观点。 而在软件工程中, ‘好, 快, 省, 任选其二’ 也作为不变的定律, 这个地方的‘省’, 在这里也可以作为专注理解: 可以做的事太多, 之后专注, 才能快起来, 才能做好(极致)
  • 不将用户做上帝, 将用户当朋友
在上图,口碑中心的右边, 雷军提到, 不要把顾客做上帝, 因为大家不信上帝, 要将顾客当朋友, 采纳顾客的意见, 这样顾客会帮忙推销, 同时使用互联网媒体将这种作用无限放大达到营销效果,这个过程中雷军一直说自己没有做太多营销; 需要虚心采纳用户的建议, 用户的建议采纳后, 一方面的确能够改进小米, 另一方面, 用户会非常高兴, 他们会积极地帮小米做宣传, 相当于小米发动了人民战争, 用户都在为小米积极宣传, 用户在帮小米营销。 他还举了一个例子, 说真由用户来北京, 在小米办公楼下苦等几个小时, 就是为了见雷军, 将自己制作的小米台历送给雷军。
雷军还提到, 在做功能的时候,不仅要做得好, 更要超过客户的预期。有时候, 一个东西做得好, 没有超出用户的预期, 用户也不会买账。他举了两个例子: 他去迪拜帆船酒店前, 大家都说这家酒店如何如何高大上, 但去了以后, 发现里边的装修,都是土豪金,导致他期望太高, 失望越大,所以感觉没有达到预期; 但在海里捞, 看到真诚的笑, 感觉非常好。 看来海底捞你还真是学不会。。。
通过自身品质的提升和发动人民战阵做宣传, 才能打造出现在小米的口碑。
小米的去KPI化管理
后来雷军还讲了其他很多内容, 但我都记不清了, 或者说, 内容以前都听过了, 没有超出预期。 不过Q&A环节比较有意思: 在Q&A开始前, 雷军说: 前4个提问的同学有奖品: 两个小米手机和两个小米移动电源, 所以大家提问异常火爆, 一开始我也积极举手, 可以坐在后排加上矮小的我, 虽然每次都举手, 但还是没有提问的机会。  我想问的问题和小米管理过程相关: 雷军讲座中提到小米提倡去KPI化的管理风格,具体衡量方式为:
  1. 做让用户尖叫的产品
  2. 让用户用户愿意分享给朋友
我一直还是觉得大家做事必须要有一个可以衡量的目标, 只是如何找到合适的目标是一个艺术问题。 所以当时我想问的问题就是: 以上两点, 在小米内部如何衡量。 不过幸好有个哥们问了这个问题, 雷军提到在小米内部, 有3个措施来保证以上目标的达成。
  1. 找到对的人, 自我驱动较强的人来做事; 将事做好做到极致;
  2. 充分,足够扁平化, 例如小米仅3层管理结构, 有否问题, 老板很容易知道。相当于去管理化(最大程度去行政化管理, 仅保留技术管理)。 我听360的同学说360也是极其扁平化, 看来异曲同工。相较下百度已经是个大公司了, 各种管理级别。。。
  3. 发动人民群众提问题, 收集反馈(雷军说道自己两周换一次手机, 自己亲自积极体验,回想百度最年轻的副总裁李明远上天天向上的时候, 也是腰间别了N多手机, 自己就天天作为PM琢磨里边的功能与体验; 同时也提到因为经常采纳用户体验, 有一些米粉甚至专程在小米办公楼下等候几小时给他送礼物)
一场风趣的讲座, 看来以后做啥事, 都可以想想如何用互联网思维来做: )

级联二步图关系挖掘关键词推荐系统及实现代码

youtube使用简单的共现思路, 实现视频的高效推荐。 受到该思路的启发, 我们基于百度凤巢广告主在广告库中提交的关键词, 更进一步设计出可级联的二部图关系挖掘算法框架, 实现亿量级关键词, 千万级别用户(单元结构)的高效推荐。 本文即对该算法的实现进行详细介绍,并在最后给出实验结果。
youtube 推荐算法
首先还是简单介绍下youtube使用的推荐算法。 符合google系一贯的风格, 算法很简单, 数据量很大, 效果很明显。
大家都知道youtube上有N多vedio,而且各种各样档次类型。而youtube将用户的需求分为3类:
  1. 查找具体video。直接通过搜索
  2. 查找某一topic的video。基本也可以通过搜索解决
  3. 没有明确目的, 随便看看打发时间娱乐
youtube算法,主要解决第三个需求, 使用top N方式推荐video供访问者浏览。而youtube的问题是视频数量太多,且视频的兴趣点较为分散(相对的amazon和netflix的需求则较为集中),所以google没有选择高大上的svd等复杂方法,而是简单的共现计算。论文中整个数据流的处理方式, 和传统的搜索引擎, 或是搜索推荐系统还是一致的, 基本分为: 候选的选择(检索系统中叫触发逻)找到可能推荐的候选, 排序(ranking过程)给出最终排序结果,并做top N截断
  • 候选vedio选择
youtube 使用关联规则的形式, 在24小时内所有用户session内找到共同访问(co-visitation)的video vi, vj
并计算,r(vi, vj) = cij/f(vi, vj)   vi, vj的关联程度可以使用该公式计算得出,  分母f最简单的方式就是ci*cj, cij为两个item共同出现的次数。之后根据阈值过滤r(vi, vj)即得到与vi关联的vj。 定义S为用户u看过的种子video集合, 则定义Ri为使用符合条件的r(vi, vj)得到的关联电影集合。
其中Ri为与vi关联的video,则C1(S)为使用种子电影S进行一次关联扩展后的电影集合,则可以定义:
则Cn(S)为种子video集合S进行n次扩展后的video集合。
以上思路虽然简单,但其中包含的一个特性是可以在相关性和种子集合数量间做一个权衡: 使用降低相关性的方法, 换取更多结果。
  • ranking
上述步骤为候选电影的挖掘方法, 之后需要对挖掘出来的种子video进行ranking,例如使用pv排序, 使用, 候选电影与user profile 的相关性等进行ranking。 当然此时还需要注意给出推荐理由(例如根据哪个种子电影进行推荐)以提升采纳率。
二部图实现思路简介
受到youtube二部图的启发, 我们设计开发了级联二部图, 基本思路是使用中间节点, 建立二步节点之间的路径(关系)计算左右两节点的相关性。
  • 二步跳转关系介绍
定义unit为一个凤巢中的单元(可理解为一组相关关键词), unit1与关键词‘礼品’相关, 而‘礼品’与‘礼品快递’关联, 此时通过两次二部图的链接, 即能找到unit1和‘礼品快递’的关联关系。
该级联二部图有两个特点:
  1. 二部图可以通过中间的节点建立关系: 只要能各自建立两边的节点(例如unit和关键词)与中间节点的关系,级联二部图两端,可以不是相同类别的item。例如unit1包含关键词‘礼品’, 而礼品与‘礼品快递’字面相关,则即使不包含‘礼品快递’, 算法仍然能够找到unit1与‘礼品快递’的关系。
  2. 可以进行多步扩展: 和youtube电影推荐算法类似, 该算法可以由级联二步扩展为级联多步, 当然, 实在牺牲准确性的前提下。
二步图的基本思想, 就是通过中间节点, 建立左右两特定节点之间的路径, 之后根据这些路径及权重, 算出左右两节点的相关性, 思路和random walk中价值传递的思路较为类似: 一个节点的价值, 最终流到那儿, 就说明这两个节点比较接近。
  • 具体挖掘步骤
步骤一:左右节点权重归一化, 可以使用L1-norm,或是L2-norm进行归一化, 之后得到每个左/右节点到中间节点的路径归一化权重。
步骤二:为了避免’哈利波特‘问题, 或我们经常说的’新华字典‘问题, 避免被多数人采用/提交的中间节点,需要对中间节点进行惩罚,降低部分中间节点的权重。
步骤三:计算左节点到右节点一条路径的权重, 路径的权重 = 左边权重 * 右边权重 * 通过惩罚值; 其中左右边权重通过步骤一计算得到, 通过惩罚值通过步骤二得到。
步骤四:根据连接某对左右节点的所有路径计算该对节点的相关性。
由上述4个步骤大家可以看出, 其实该框架和mahout中hadoop item-based 的计算item相似度的流程极为相似, 具体算法可参见mahout源码:mahout推荐算法;但该算法具有很好的扩展性, 就是前边介绍的: 灵活更换左右节点, 即可实现多步级联的推荐。
核心代码示意
具体实现即根据上文四个步骤进行划分, 四个步骤的实现代码可参见下属配置文件:
通过conf文件,大家即可了解上述4个步骤的实现, 具体该配置可以参见conf/twohop_bipartite.job.conf
实现效果
经过多次优化, 包含基础数据的清洗, 使用该方法, 客户的覆盖率提升至75.6%, 相关性85%。 且针对一些大客户的需求, 可以放松相关性来进行扩词。
工具使用方法
级联二部图工具使用方法如下:
python ${TWOHOP_MINING_HOME}/script/twohop_mining.py
-hadoop hadoop_client_path
-inputA input_A_path
-inputB input_B_path
-output output_path
注: 该框架依赖于我们自行开发的hadoop任务框架, 所以可能无法完整运行, 但使用者可以将上述4个步骤的hadoop脚本单独抽取出来进行单独运行。
工具代码地址
代码可从我的云盘下载:级联二部图框架
参考文献:
mahout推荐算法:http://mahout.apache.org/users/recommender/recommender-documentation.html
youtube video推荐算法:Davidson J, Liebald B, Liu J, et al. The YouTube video recommendation system[C]//Proceedings of the fourth ACM conference on Recommender systems. ACM, 2010: 293-296.
百度关键词工具介绍参见:http://support.baidu.com/product/fc/4.html?castk=24b18bi7062c720d0d596
也可关注我的微博: weibo.com/dustinsea
或是直接访问: http://semocean.com