微信扫描登录

机器学习在OTA酒店服务的应用

本篇文章整理自潘鹏举4月23日在『1024大数据技术峰会』上的分享实录:机器学习在OTA酒店服务的应用。

enter image description here

大家好!我来自携程,我们不是卖鞋的,我们是OTA,主要卖酒店、机票和度假产品。

我来自携程酒店研发部 BI。携程的BI跟其它公司BI不太一样,其它公司的BI就是做ETL、报表、数据产品展示,这边只做预测,主要负责服务相关业务模型的预测,我主要关注在酒店服务行业的一些应用。

enter image description here

分享的目录分为四块:

第一,先介绍一下酒店OTA行业,及其面对的服务KPI和挑战。
第二,我们在提升服务上有哪些模型实践,尽量提升客人感受。
第三,机器学习算法的一些经验分享。
最后,我们怎么上线这些算法,以及我们在上线过程中踩了哪些坑,希望对各位有些帮助。

enter image description here

首先:OTA行业和其它行业区别。

这里两张图,左边是京东上搜的产品“树莓派”,右边在携程搜了北京的一个酒店。

OTA行业和其它行业最大的区别:

第一,限时限购。限购指每个酒店房间数量是固定的,你只能卖这些数量,你不能超出这个数量。

第二,现付。指的是酒店前台付钱,还有一种是预付,指的是先付钱给我们,再付给酒店。现付和预付比较大的区别是,客人在我这里订产品,钱直接付给了酒店,酒店再付钱给携程。这样的话酒店可能会赖账,说客人没来过,我们也不知道客人是真的没去,还是假的没去。酒店也可以告诉客人说你直接在我这里订就好了,把携程上的订单取消掉,这里面有很大的风险。

第三, “立即确认”。酒店的数量是固定,还有一个隐含条件,携程手上是没有库存的,这个立即确认,就是说携程跟酒店谈合作,比如说你房间有50个,那你每天给我保留10个,我跟他谈的10个就是保留房,针对这些保留房,我们可以立即确认订单给客人,因为我跟酒店有协定,酒店会保证可以可以正常入住。

第四,“代理”。理指跟其他的代理商合作,这些代理商跟酒店直接谈合作。对于这部分业务,客人提交完订单,携程会问代理商,代理商再问酒店,流程很长。酒店先返回给代理确认信息,代理商再返回给携程说客人可以入住。携程有些订单不是客人提交完后就可以入住的,提交完后携程要发客人信息凭证给酒店,酒店回复相应的入住凭证后,客人才能入住。以上就是列出来的主要区别。

enter image description here

酒店服务行业的挑战:

手上无实际库存。 合作方式各种各样。 有些人觉得我们直接连酒店预订系统就好了,还要打电话问,这么落后。实际上有些酒店没有库存管理系统或者房价定价系统,如果他们没有能力,我们会给他开发EBK系统,但是有些酒店连电脑也没有,所以我们跟他们的联络只能通过电话进行联系。 天生限购、带过期时间。 同质产品、排他性。 长尾属性。长尾客户多、消费频次低,周期性高。长尾酒店多,酒店服务水准参差不齐。长尾客户的意思,我们这周期性很强,消费频次低,不同酒店服务参差不齐,有一些酒店服务好,比如大集团或者连锁酒店,有些服务很差,比如低星酒店。

针对上面的问题,我们设定了对应的服务KPI,简单的说就是好、快、准。

enter image description here

每一个维度有如上图所示的KPI。

好,是携程最看重的,携程说放心的服务放心价格,我们对这一块的投入非常大。

解释一下什么叫到店无房率:客人提交完订单,到了酒店前台,酒店说没有房间了,客人入住不了,这就叫到店无房,这种情况发生责任是酒店,酒店会超售。超售对它是有好处的,同样一个订单,卖给我要付佣金费,卖另一个人可以额外涨价,中间赚的钱会远远超过付给我们佣金率,所以酒店有利可图。

还有到店无预定率,这是流程上的问题,这两个指标,客人比较少碰到,我们会长期监控这两个指标。

快,主要从客人感受上来说,我们希望客人提交订单就能直接确认给你信息,让客人可以入住,客人也肯定希望尽快确认,这样客人就可以及时入住了。

所以会有两个指标,一个叫订单确认时长,确认时长:指的是从客人提交订单开始到收到确认短信的时间。立即确认率指的是要求业务跟酒店签更多的保留房,让客人基本上一提交订单就能得到确认信息。

准,分了三类,信息、价格和房态。

信息,指酒店描述、点评方面的内容。

价格,价格准,我们有时候也会碰到变价问题,一开始你搜索的时候看到价格500块,最后你下订单发现,变成了550,这就算价格不准了。

房态准,我们会看房态覆盖率,看区域覆盖的酒店数量。

确认前后推翻率,你下完订单告诉你,我现在房态紧张,不能确认订单,这个叫推翻。这里区分确认前和确认后,搜索的时候有房,客人提交订单后说订单无法确认就是确认前推翻。

还有一种确认后推翻,这个是最严重的,如果出现这种情况,服务条款也会说,如果我会跟你协商改订其它房型或者退单,中间的差价和之前预定的钱都会赔给客人,这是服务承诺。

enter image description here

接着分享一下携程在这方面做的一些实践,分成预订前、中、后,主要目的提升客人体验。

enter image description here

预订前,做了自动询房模型,图像去重,变价预警等等。

预订中,会预测酒店回复时长,传真识别,有房模型,信用住模型。我们推出了闪住业务。现在到酒店CheckIn是需要付押金的,闪住不需要押金可以直接入住,你把卡还给酒店就走,也不需要查房,直接离店。

预订后,针对有可能出现到店无房的订单会做重点的审查,还有noshow的预测,noshow指客人提交订单,没有按照约定入住酒店,但是也不取消订单。

有一些酒店刷点评分,故意把这个点评分刷高,我们做了点评防刷。

下面具体说一下预订前相关应用。

大家一说机器学习,都会说要做个性化推荐,个性化搜索,其实也在做。用户画像,别人问,你们是不是也做用户画像。但是其实用户画像本身它的目的就是为了识别用户,在这边,很多用户的属性是一直在变,画像是可以做的,但实际用户属性一直在变。

也就是说在做的时候,可能会先生成一个固定客人画像,但是在实时交互会变,画像需要修正。

enter image description here

一个询房的应用。以前靠业务,专门有一个组做询房。他们会筛选出一堆酒店列表,打电话逐个问酒店,你现在这个房型是否有变化?那是以前的做法。

现在用模型做了一下优化,直接从数据库读取所有的房态信息,对不同的房型+入住天,用两个模型做预测,左边叫开房模型,会预测这个房型在这个点上是否可以打开,可以打开就会自动打开,不需要人工干预。往右走,针对那些可订的房型走关房模型,模型预测出来关房概率,大户室人员根据得分从高到底进行询房。

enter image description here

这是最后的效果,相比传统的人工的经验,算法提升比较明显,大概提升一倍多。另外自动开房额外产生订单量,增加了业务收入。

enter image description here

这是预订中的算法应用,主要目的是提升客人的感受,缩短时长,尽量提高客人从提交到最后确认的时间,我们做了一些优化。

客人提交完订单,针对那部分不能立即确认订单,会走一个有房预测模型,预测这个订单确认概率有多少,如果概率非常高,99%+,直接确认给客人,不能立即确认给客人,会走酒店回复时长预测模型。

以前没有回传预测模型的时候,对订单的处理基本上是先进先出,打电话到酒店询问未确认的订单是否可以确认。这样做有效率问题,主要问题是有一些订单本来一分钟或两分钟就可以确认,但也打电话出去了。有了这个模型,我们会对订单的回复时长重排序。

优先把那些酒店回传比较慢的订单先打电话催酒店确认,这样把原来一些可能要等半个小时的订单提前到5分钟之内或者一两分钟之内给你确认,做这一个流程优化对整个确认速度提高是很有帮助的。

enter image description here

这是效果,有房预测准确率是99%,不到1%被推翻到。 回传时长预测准确率93%,召回率53%。

enter image description here

接下来分享一下在算法的经验。

enter image description here

这是一直在现在比较固定的做算法的流程。首先最上面确定模型目标,这肯定是第一步。接下来是变量设计评审。

现在做业务模型居多,哪些变量跟业务目标有关系,肯定是先想变量。这一块需要算法工程师深入去了解一些业务,如果不了解业务,他设定的变量跟业务关系不大。

变量评审做完之后是数据准备。在我们这儿花的时间是挺多的。

接下来线下数据校验。对数据质量的重视程度非常高,会在每一步确认你的数据是不是对的,如果你不对,训练的模型是有问题。对各种校验非常重视,校验完之后做正常的模型优化,这跟你的目标直接相关,不同的目标会有不同的一些模型训练方法,目前常用的模型主要以分类为主。

如果你的模型已经通过了初步的目标,可能会开始开发上线的流程,会开发API,开发完之后校验数据对不对,然后再放在线上空跑,空跑是指模型已经在线上嵌入了,会配置一个开关,开关开启控制模型对现有流程不影响,记log,通过log分析这个模型在线上的真实效果,主要目的是做风控。空跑之后上线,做模型监控,这是一整套的流程。

对于工具,主要是用R和python,会有好几个部署有R和Python的服务器,在这上面训练模型。

enter image description here

这是Feature设计的例子,有房预测分不同的维度,其实主要是加了不同维度的先验概率,不同时刻预订可确认率是不一样的,白天可确认是比较高的,到了晚上确认就比较差。

酒店维度。

紧张度维度,紧张度的定义是,酒店有50个房子,有40个关闭掉了,只剩下20%的房间,那么这个房间的紧张度是80%。

房型维度跟酒店维度差不多,颗粒度不一样,房型维度主要刻画库存的实际消耗情况。

enter image description here

模型训练的经验总结。

在模型训练里面特征工程、准备数据花很多时间。这列了一些常用的方法:

缺失值预测,对缺失值用一个模型进行预测,填补缺失值。对重要变量的缺失值做预测,它可以提升模型的效果。 百分比变换,规避分母出现0的影响。这边列了一个小技巧,A除以B,B是0,就会出现NA、NAN异常值,会在分母里加一个很小的数字,比如加0.000几,这样就不会出现NA、NAN等异常数值,训练模型会比较方便。对于类别变量列了三种常用处理方法。

OneHotEncode。 WOE在风控上用得比较多,可以训练处目标变量和预测变量之间的权重是多少。相比较OneHotEncode,WOE只有一个变量结果。 Impactcoding,跟WOE思路是一样的,只是变换公式不太一样。

enter image description here

数据挖掘、机器学习都会提到归一化。

在这边的业务模型中比较少用到归一化,归一化就是把量当作了一些scale,会用最大最小值,如果放在线上,需要把最大最小值存储下来。最主要的问题,可能线下训练数据最大最小值差距是比较明显,会导致出现预测偏差。另外目前使用的集成机器学习对量纲不敏感。

enter image description here

衍生新变量。

Entropy转换,用了它对模型的效果进行提升。思路针对room对多个变量的不确定性进行衡量。 GBDT衍生新变量。思路,在每个观察值在节点上的结果作feature。 SVD++衍生新变量,用这个方式发现featuer,隐含的因子用它来学习,有一个模型里面用到。

enter image description here

把训练是分为两倍,50%做第一层,就是T1,左边叫第一层模型。把这个东西feature训练出第二层模型,用最终的模型预测test结果。

有些人训练很少自己分training和test,把它的结果直接提交,看提交结果后的如何。

训练模型,一般都会留一个test集合,在线下训练模型的时候,可能会尝试很多种模型,要对比出模型是否有差异,就可以用同一个test去预测一下,这样就比较方便对比出不同模型之间的差异。

enter image description here

关于业务逻辑和数据表现不一致的时候,模型怎么处理。这个时候可以对参数进行调整,GBM可以设置一个参数,变量的作用方向:正相关、负相关、无法确定。在一个项目上用过,会有效果,如果你不是很确定,谨慎设置这个参数。

enter image description here

融合方法,常用两个:stacking和blending。

enter image description here

看一些模型的对比结果。

横轴是Recall纵轴是precision,有好几个模型进行对比看哪个是最好的。里面有个单变量模型,拿出很简单的规则试验一下,看看用单一变量的效果,模型做的太复杂,做到最后如果连单变量都不如那就是建模失败了。

主要目的是设定不同的基准值,有一些基准值,才会有模型优化方向。再看其他的,好几层嵌套的模式,第二层模型,第三层模型,最右边就是效果最佳的,最后直接上线的会用效果最佳的模型。

enter image description here

另一个对比结果,看一下用GMB+SVD++衍生新变量产生的一些效果。横轴是各个模型,纵轴是准确率,它有一个隐含条件,Recall都等于20%。

从左到右,左边是传统的一些模型,比如说LASSO,KNN,LR,越往中间用的是比较常用的集成方法,再往下就是随机森林,GBDT。再往右边可能会更复杂,不同的模型组合训练出来的结果。

效果最好的是GBM+SVD++。

enter image description here

SVD++,起的这个作用。学习出时间和房型,不同的房型根据他历史的满房的走势可以学习出来哪些房型走势很相同的,所以用了这种LatentFactor挖掘方法,去发现哪类房型它的走势是属于这里面哪种情况。

enter image description here

再看Entropy转换的效果。横轴是recall,纵轴是Precision,往下看recall越高,Precision越低,效果不是很明显。

在实际应用过程中,比如分类模型,只会关心预测为1的precision的 recall。

enter image description here

经验总结。

之前碰到的一个比较有趣的问题。首先训练出来一个模型,这个模型线下准确性比较好。

到了线上,当时有一些系统架构的问题,它对有些变量时效性做了阉割,延迟两个小时。在线上测试发现recall下降非常明显,接着做了二次的改造,把当初阉割的变量从延迟2小时变成实时,模型效果又提升上去。

现在不管什么模型,用xgboost或者GBDT训练处一个基准值,以这个基准值做后续优化。有时候有可能你持续优化后的模型比这单一模型的提升幅度不明显。

一直强调数据校验,数据校验真的非常重要,在Feature上要花很多的时间,像现在有些比赛,开放性的比赛,会用十到二十个或者一百个模型做一些融合,这个复杂度非常高,在实际应用上,其实是不怎么会用这种方法。

模型上线的问题,如果线下模型基本上各个变量已经准备得差不多或者说也已经知道变量比较重要,建议是,直接快速上线,根据上线结果做模型二次调优,直接拿线上数据做模型,对模型效果进度是最直接,增加任何一个变量,线上线下都是不太一样,所以这一块也是会比较注重,而且这个迭代速度变得很快。

enter image description here

这是大概一个初步的模型上线架构。

其实这是很简单的图,学习的出来的模型,模型结构存储成一个文件,会写一些文档,比如模型用到了哪些变量,会有工程师把我们的变量算出来,然后有专门开发API接口的工程师进行上线。数据主要基于HBase,读文件,把常用的一些变量读取到Redis,SOA1直接调用,然后预测结果。

enter image description here

模型上线顺序。

先通过空跑实验,后校验通过,最后监控。监控非常重要。

enter image description here

再一个灰度上线。会布置两套SOA,一个是线上,一个是线下,如果做了新模型,同样复制一份跟线上完全一样,只是模型结果不太一样,模型调用一个是左边线上的结果,右边是线下的结果,根据log分析,新的模型效果跟现在线上比是好还是差的,如果是好的就可以直接上线。

数据校验,花的时间挺多。

enter image description here

会有一些报表平台持续监控效果模型怎么样,每天都会去看这个模型是否有问题,变好变坏。左边有两个tag,有实时监控和T+1监控,实时监控为了可视化,实时监控放在代码里面直接坐到。

enter image description here

会设一些简单规则,比如说我的数据质量变得非常差,如果它没有通过校验规则,模型会自我关闭。因为很多模型都是线上的应用,如果调用或者结果不太好,对业务影响是比较大的,所以做很多的一些控制。

T+1监控每一天模型效果怎么样。

enter image description here

以后的尝试方向。

enter image description here

现在花很多时间在FeatureEngineering上,会想办法优化。加入OnlineLearning,主要是解决模型更新问题。

现在模型训练好之后直接放在线上预测,需要定期更新,花的成本也不少。在线学习能减少人工更新模型这一件事情,让线上自动更新模型。深度学习,现在图像方面已经用到了一些深度学习的技术。