编者注：别想歪了！我们说的是“机器学习”~
大家好，我叫潘鹏举，人称PPJ，来自携程酒店研发BI。上图是我的自我介绍，简单做了一下标签，做了词云可视化。
首先简单介绍一下OTA酒店行业有哪些我们关心的KPI及其面对的挑战，让大家有个简单概念；
接着重点介绍一下算法在酒店行业是怎么用的，看一下我们的经验对各位有没有启发，也想借此机会和大家交流一下怎么才能让算法创造出更大的价值；
最后分别简单介绍一下使用算法的经验和算法的上线架构等；
一、OTA酒店行业
1、OTA酒店行业和其他行业的区别和挑战
首先我们先说第一块，OTA酒店行业；
我截取了某一个酒店的详情页，即我们的产品。在上面我也罗列出了OTA酒店行业和其他行业的最主要的区别。
首先最大的区分就是：我们的房型是限时限购的，从图上可以看到，我们只能5.11号入住，过时不候。另外每个酒店的房间数量是相对固定的，所以如果酒店超卖的话，那么就不好意思，酒店没有办法一天内加盖房型，只能协调客人到其他酒店去入住了。
然后是第二部分，代理（供应商）房型，这部分就是二房东，它从酒店拿到库存，然后放到携程售卖。，这样有个什么问题呢？我没办法从酒店打听到任何库存信息、订单信息，所以我们在管理代理方面就很谨慎，因为不好的代理会拉低携程的服务水平，如果订单出了问题，只能找二房东去协调，速度慢不说，还有可能解决不了问题。
第三部分，自营：指的是携程和酒店直接谈合作的房型，这些房型中有保留房、直连、直签，自营的房型是靠谱的房型，我们直接跟酒店要库存，知道房价、房态信息，出了问题也可以跟酒店直接协商，自营房源是我们服务标杆，各项服务指标都很好。
说完了行业区别，我们看看我们面对哪些挑战；
因为我们的商业模式，所以第一点挑战对我们影响很大，我们很依赖酒店行为；有些酒店虽然在我们这里售卖，但是比较无赖，会出现不付佣金、前台切客等行为，造成业务损失，当然我们对各种行为有相应的识别方法和会有相应的惩罚措施，另外酒店服务水平参差不齐，管理起来比较困难。
第二点提一下，有些低星酒店很落后，我们跟它联系只能用小灵通，导致我们管理一些酒店比较困难。其他的挑战都比较好理解，简单的说就是低频、长尾、季节性。
2、酒店OTA的服务KPI
说完了挑战，我们看看我们有哪些关心的服务KPI。
服务KPI就是好、快、准。
稍微解释一些KPI，到店无房指的是酒店发给了客人入住凭证，但是因为超卖导致客人无法入住，这种情况主要是酒店的违约行为，正常情况下携程会帮忙协调入住其他酒店并赔偿相应的损失，在旺季的时候会有所升高。然后是到店无预定率，跟到店无房的区别是：客人到了酒店，酒店说没有相应的订单信息，出现这个问题主要是携程和酒店传真客人入住信息的过程中有问题，出现这种情况携程会立即帮忙解决客人的入住问题。
目前来说，基于我们强大的客服力量和优质的6sigma管理体系，这两个指标都控制在极低的水准上。剩下的指标就不一一解释了。
我们现在面对的一个挑战是，业务量持续的增长，我们没办法持续性的增加客服人员来维持一个高标准的服务水准，因此需要借助于算法来实现智能化、自动化。
说完了KPI，我再接着介绍一下我们是如何评估项目收益的。
3、项目收益评估
这里重点说一下客户价值，这个是我觉得值得说的地方，其他的收益和成本类，大家都拎得清。
我举了一个例子：比如一个客人出现了到店无房，除了要直接赔款损失外，我们还要额外计算间接损失，那么我们在做到店无房项目的时候，如果间接收益+直接收益超过了成本，那么我们就值得投入人力去做优化。
对于有些公司来说，单纯提升客人感受认为价值不大，但是我们把客人感受货币化了，那么这个价值就提高了。
行业背景就告一段落，我接着说重点，算法应用实践。
二、算法应用实践
在正式说应用实践之前，我们先简要看看携程的数据量。2亿PV，10TB/日，数量还是蛮大的。我们用到的数据大体分成四块：业务数据、网站性能数据、用户行为数据和爬虫数据，其中我们的应用实践主要会用到业务数据和用户行为数据。
1、关于数据的一些概念和观点
接着说说数据在哪块会产生比较大的价值。
我按照数据的冷热区分了一下数据价值，一般性数据时效性越高，数据价值越大。我划分了一下，如果只用冷数据，那么可以挖到银矿，用好了热数据，你就挖到了金矿，如果你都直接预测了未来，那么你就挖到了钻石。最下面我列了一个公式，未来的人工智能就是基于过去和当前的状态来预测未来，这样的一个组合是未来应用的一个趋势。按照冷热的分类，我们看看数据是怎么应用的。
从这个ppt可以看到，越冷的数据，越不能影响到线上的实时业务，起的作用也越小。如何利用好当前的数据，对于应用，效果会更好。看最下面的备注，特意说一下，这样区分确实不严谨，但是从实践的角度看，越是过去的东西对未来的指导意义是越差的。接着我说说我们在实际应用中的一些观点和想法；
右边的图主要是从数据应用的层面上说的，里面没有提到DW层，但是DW层是地基，没有一个好的地基是没有办法说数据应用的。但是从价值上看，越往上，数据价值越大。
最后提一下，我们可能会有一个误区，我要追求100%准确的数据，实际上，我们的数据很难100%准确，特别是像用户行为数据，任何一种采集方式都会有PV漏记、错记的情况。我们要能容忍一定的数据采集偏差，在现有的数据中看一下怎么利用数据创造价值。反过来说，如果数据一直都存在这个偏差，那么对你未来的应用影响就小，数据已经适应了你的偏差。说了模型这么多好话，我们看看一个算法应用的完整闭环是怎么样的。
这里提一下标红色部分，人工和风控。在算法应用到线上的过程中，人工经验、人工过滤以及风控会起到很关键的作用。如果没有做到这点，那么在实际应用中会大打折扣。
就像我左下角写的那样，人是商业的CPU，决策过程中要依赖人来调整方向。而风控是决定应用快慢的GPU，如果没有做好风控措施，不仅可能会导致业务损失也有可能让算法没有发挥出作用，后面的实例中我会提到一些。
2、模型评估
说了一些概念后，我先说说我们怎么评估模型，然后就讲讲我们的实践实例。
这里列出了三种常用的模型评估方法，第一种A/BTest，用的最多，几乎所有的项目如果没有ABTest是不能拿出来讲的。第二种是为了替代A/BTest想到的简单办法，针对有些情况下面很难做AB实验。最后一种情况是我们评估+风控的方式，先上线模型，但是业务不采纳模型结果，然后我们用log来解析模型是否运转正确，效果好不好。
说完了评估，我们说说酒店服务用到了哪些模型；
按照预定流程，区分了预订前、中、后流程，主要目的是为了提升客户体验和提高服务效率。预订前的主要目的是为了让信息更加准确、预订中主要是为了提升预订效率和速度，预订后就是为了订单风控、酒店风控和客人风控。左下还罗列了一些常见的算法应用，排序、推荐和画像，这里就不细说了。这边说了一个整体的应用的架构，接下来我举一些具体的例子。首先看第一个；
3、具体案例
订单量预测的作用，我们一个应用是用来做业务监控，做到了准实时，延迟一分钟预测。右边写了应用的大致流程，跟我之前写的算法应用闭环是同步的，从预测到应用，接下来我们看看用了什么算法。
其实就是简单的ARIMA+季节系数+一些人工调整，把模型做了出来，没有用很复杂的算法。最后的效果是平均误差~5%。评估指标我也列了一下，主要是看漏报率，不同阶段重点不同，在稳定期间，我们比较关心误报率，因为系统稳定了，我们就要尽量减少人力损失。关于预测误差，我这里也提到，预测总是有误差的，不可能100%，我们可以根据我们的预测的精准度来进行一些规则的设定，看最下面的规则，这个规则让你有些弹性空间来防止预测错误导致的误报。
在时效性上，我们以前是吃过亏的，最老的版本我们上线过T+1预测，就是预测昨天的结果，看昨天是否异常，我们发现这个对业务一点帮助也没有，你的业务损失已经产生了，再去看异常没有特别大的作用，后面我们就慢慢的提高了时效性并做了可视化，目前这块的监控效果和可视化都很好，也监控了各关键KPI的异常情况。
第一个例子说完了，接着看第二个例子。
可能有人觉得，怎么会有怎么长的确认时长，我在右边的解释了一下，并且罗列了相应的挑战，针对这些挑战，我们是怎么做的呢，继续接着看。
我们看一下旧流程和新流程的差别，最大的差别就是我们在新流程中植入了一个预测模型，根据模型的预测结果来调整业务流程。这样做的好处就是，以前回复慢的订单要白白等待X分钟，通过模型预测之后，我们就调整了顺序，把原来确认慢的订单提早确认了，可以提高确认速度。
这个应用点是个很好的一个案例，它让我们来思考那些流程有同样的问题，促进我们进行相应的优化。这个模型准确率为93%，召回率53%，取得了一个不错的效果。这是第二个案例，接着看第三个案例。
我们的解决方案见右边的流程图，核心是两个模型和IVR自动化工具。
我稍微简单的描述一下，简单的说，针对关掉的房型，我们会用自动开房模型预测出当前状态下每个房型的可定的概率score，我们统计出score的准确率，在可接受的准确率下，把高于这个分数的房型全部自动打开，然后让客人在网站上可以进行预订。针对那些不能自动打开的房型，我们会把这些房型放在询房看板上去。
另外一边，针对现在可订的房型，我们去预测房型无房的概率，然后把这些数据放在询房看板上。
这样我们的询房看板上就有两部分的得分结果，开房分数和关满房分数，针对这些房型，我们有个IVR自动外呼工具把概率高的房型优先外呼到酒店，如果酒店告知房态有变化，我们会做对应的房态变更。
通过这一整套流程，我们完全实现的开房和关房的自动化，针对高准确率的房型，系统自动操作。对准确率不高的房型，我们采用酒店介入（即人工介入）的方式来平摊风险，把损失降到最低。
所以决策过程中，会有很多人工的接入，然后针对风险的高低，我们会有不同的风控和措施，这样的结合才能让算法的作用最大化。这个案例针对那些数据量大，花费人力多，重复性工作多的事情具有很大的启发意义。
案例三说完了，接着说第四个案例吧。
用户价格偏好，是用户画像的一个很小的子集。为什么会单独拎出来说，我等会讲。
我们先看看我们碰到了什么问题，一个用户根据不同场景，价格是一直在波动的，我提供了一个例子，某个客人在历史上的消费价格。我们后面用了一个算法来进行预测，没有用简单的规则来刻画用户价格偏好，花这么多力气做这个预测是因为猜中了客人的价格偏好，对产品和推荐都很有帮助。
看一下我们是怎么做的，图里面罗列了相应的思考维度，用了xgboost来进行预测。我们考虑了很多的实时场景，包括了客人的入住天距离节假日的天数，区域、星级紧张度等，这都是为了刻画客人在当前状态中会变成什么样。
最后这个模型的效果还可以，77%的用户预测价格和实际价格偏差在50元以内。模型说完了，看看这个应用给我们的启示。
这上面说了一件事情，画像不是一成不变的，一直在变，要场景化。所以如果只是为了画像而画像的话，意义不大，我们会根据应用场景的不同进行调整。
这个是我们实验下来比较好的模型项目流程，给大家参考一下，其中标黄色字体是我们比较关心的，数据校验是为了让模型产生效果，因为俗话说的好：垃圾进，垃圾出。接着说一下FeatureEngineering的事情；
这个没有特别好说的，跟其他人的做法雷同。
提一下缺失值预测。如果我们觉得某些变量对业务帮助很大，但是有一定量的缺失值，那么我们就会用另一个模型来预测缺失值，做法就是取出关键变量不存在缺失值的样本来进行训练，然后再对有缺失值的变量进行预测。
然后说一下归一化，我们这里没有罗列，因为我们现在用的常用的机器学习方法gbm，xgboost对量纲不敏感，所以我们为了减少数据分布的损失较少做归一化。你们在实际应用中，有些模型是一定要求你归一化的，所以还是需要进行归一化处理。
类别变量处理方法罗列了一些，大家可以找资料看一下。
这里说一下模型融合方法，我们常用这两种，有对应的链接，大家看看资料，这里不细说。
对整个模型的总结见图。特意提一下倒数第二点，线下模型上线，根据线上数据进行调优。主要是担心线上上线过程中有人为失误导致数据计算有偏差，所以可以直接根据线上模型来进行模型优化来适应线上的开发错误，并且能够快速的定位出开发中的数据错误。
四、模型上线架构
大家看一下模型API架构简图，我们的开发语言是Java，我们会用Java封装模型的所有输入参数，然后把模型训练的结果存储成文件xx.Rdata或者xx.Py文件，最后Java把模型结果常驻内存，最后去调用Rserver和Pyserver来进行预测。整个过程涉及的角色比较多。