本篇论文来自Booking，介绍了它们实际应用机器学习模型的一些经验。这家公司是全球最大的OTA，市值大约是携程的四五倍。自己对论文做了一些整理。
1 OTA场景的特点
OTA跟常见的电商场景不太一样，有自己的一些特点，使得机器学习应用起来更加困难；
高风险：跟推荐电影、歌曲、书籍不同，OTA场景下都是比较大的决策，容错率太低；一旦客户在行程中体验差，对用户本身的损失是比较大的，反过来用户对平台的印象也会极大降低；
用户输入的查询信息过少：一般用户搜索时只输入目的地、日期、人数等，如何从这种少量的查询信息下给用户带来购买、住宿等多方面的满意体验是一个问题；
用户决策复杂：出行确定需要目的地、日期、人数、酒店、花费、路线等很多选项的组合，是一个复杂的决策空间；并不是所有组合都有对应的产品，要给用户一些合适的决策组合的引导；
动态的供应信息：OTA这种代理产品是供应商提供的。供应商提供有限并且动态变化的产品。在此基础上，价格因素会影响用户的偏好，也会影响供应商的行为。这个也是无法忽视的；
持续的冷启动状态：大部分人一年只旅行一两次，随着时间推移，他们的偏好可能已经完全改变了。用户长期的行为历史通常是不相关的。产品角度，每天也有很多新产品上线，这些产品也缺少很多相关信息（点评等）；
内容过载：出行产品有非常丰富的内容维度，描述、图片、评论、评分等；目的地也有用户上传的照片、攻略、向导等等信息；这些营销手段很有效，但是用户消化起来过于复杂，如何合理地把这些展示给用户也很关键；
2 开端：机器学习是产品进化的瑞士军刀
（小标题这个比喻我喜欢）
在实际探索中发现，机器学习可以广泛应用于各个不同的场景；在特定场景提供个性化推荐、优化用户界面某个元素的尺寸（这也可以。。。），这些都是比较窄口径的特定场景下的建模；此外，还可以做一些比较通用的semantic layer，这些模型是用来建模一些意义概念等，模型的输出可以在各个场景应用。比如用户对目的地选择的灵活程度建模。发现这些semantic layer的应用场景更加广泛，比特定场景下的建模更有效率。（个人感觉跟公共用户画像类似，就是各个部门都可以用这个特征，当然这个特征是建模得到的，是一些比较有意义的、模型挖掘出来的特征）；
2.1 模型族
列举不同用途的模型
旅行者偏好模型：旅行者可能有目的地、酒店价格位置质量、日期、设施等方面偏好，构建了几个机器学习模型，它们结合起来构造了一个用户偏好配置文件，来预测用户在每个方面的选择灵活性水平；举个例子：如果用户日期选择灵活度高，那么日期推荐可能是有用的；如果用户日期选择灵活度低的话，日期推荐会让用户分心困惑，就不会显示日期推荐（也是个性化推荐的一个方面，这个刻画还是比较细致的），对于这部分用户可以选择强化选定日期的价格趋势与是否可用。
旅行者上下文模型：旅行者以夫妻、家人、朋友或单独的身份旅行（出行结构），休闲还是商务旅行（出行目的）。他们可以坐车去一个近在咫尺的城市，也可以坐飞机去世界的另一边，在一个城市停留很长时间，或者在几个城市相继停留很短时间。（交通工具、行程安排）所有这些都是我们称之为Traveller Context的例子，它代表旅行主题的一些约束或者需求。这些上下文大多没有在我们的平台中明确说明（出行结构目的不算是产品信息，肯定是没有的），有些可以指定的上下文信息也通常被大多数用户忽略。（大部分用户在选品时可能看不到或者不使用 特定的交通工具、行程筛选项 这些信息）因此，在购物体验中尽早预测或猜测当前用户的上下文是非常有价值的。这也属于上面说的semantic layer。例子：比如出行结构预测模型，有些家庭出行往往会忘记填孩子的信息，对于这部分用户提前做一个提醒。（感觉这个好细致，用户体验应该不错）
产品导航模型：大多数浏览我们库存的用户都会浏览一些补充和补充的选项和项目，例如日期、属性、策略、位置等。为了做出选择，他们需要跟踪看到的选项，同时探索邻近的选项并尝试做出购买决定。我们的产品导航模型都来自这个过程，并试图引导这个过程。它们将滚动、单击、排序、筛选等不同的操作视为用户偏好的隐式反馈。然后，这些信号可用于方便访问用户历史中最相关的项目，以及显示我们库存中的其他相关项目。（其实就是以产品的属性为前提，使用用户的行为信息做一些排序与推荐，去引导用户的选择）
用户界面优化模型：字体大小，数量，列表中的产品、背景色或图像、视觉元素的存在或不存在等等（即UI），都会对用户行为产生很大的影响，这是由业务指标衡量的。这个系列中的模型直接针对特定的目标业务度量优化这些参数。我们发现一个特定的值很难是全局最优的，所以我们的模型考虑了上下文和用户信息来决定最佳的用户界面。（UI有些少量元素做个性化的展示，应该是有操作空间的，但应该也不会过于个性化考虑吧）
内容管理。描述目的地、地标、住宿等的内容有不同的格式，如自由文本数据、结构化数据和照片等；这些内容来自不同的来源，如住宿经理、客人和公共数据库。它具有巨大的潜力，可以用来吸引和宣传客人到特定的城市、日期甚至房产，但它也非常复杂、嘈杂和广阔，很难被用户消费。内容管理是使内容可供人类访问的过程。例如，我们在超过150万个酒店中收集了超过1.71亿条评论，其中包含有关特定住宿提供的服务的非常有价值的信息，以及非常丰富的卖点来源。一个机器学习模型“策划”评论，构建一个住宿的突出方面的简短和有代表性的总结（即评论中抽取推荐理由，目前应用很广泛了）。
内容扩充。用户浏览、选择、预订和查看住宿的整个过程，使我们能够处理隐含的信号，使我们能够对特定酒店或目的地能够提供的服务和质量有更深入的了解。这个系列中的模型派生属性、目的地甚至特定日期，从而增加显式服务提供。内容扩充不同于内容管理，因为内容管理是关于已经存在的内容容易被用户访问，而内容扩充则是使用来自许多其他的数据来丰富现有实体。为了说明这个想法，我们举了两个例子：（也就是说，上面的相当于一个内容整理与抽取，这里做的是一个内容挖掘，利用挖掘到的信息帮助用户做决策）
物超所值：Booking.com提供多种选择，以便利设施、位置、服务质量和设施、政策和许多其他方面的形式提供不同级别的价值。用户需要评估一个房间的价格与他们将获得的价值之间的关系。”“今日超值”图标与其他可用选项相比，通过突出显示为其要价提供卓越价值的属性，简化了此过程。一个机器学习模型分析数以百万计的财产的价值主张和数以百万计的用户的交易和评级，并选择具有“巨大价值”的财产子集。（这个就是分析一下价格与同期往期相比，标明现在是超低价，特价）;
价格走势：根据预定的预期、具体出行日期和目的地等方面，价格表现出不同的动态。由于我们每天都能在每个城市预订成千上万的房间，所以我们可以建立一个精确的模型来预测给定时间和旅行日期的城市价格趋势。当模型发现一个特定的趋势时，我们会通知用户帮助他们做出更好的决定，要么鼓励他们选择一个看起来像机会的目的地和日期，要么劝阻一些有利于他人的特定选择。注意，在这种情况下，扩充的项目不是一个住宿而是一个目的地。
这节主要是列举了一些模型的应用场景，可以借鉴，大部分场景其实大家都有在用了。
2.2 所有模型族都可以提供价值
每个机器学习模型系列都提供了商业价值。这反映在下图中，其中每个条表示模型族对我们的一个核心指标的中值改进与基线之间的关系，基线计算为在可比期间内所有成功项目（基于或不基于机器学习）的相同指标的中值改进。大多数模型族的贡献都高于基准，一个低于基准，但都做出了重大贡献，集体效应明显是积极的。
可以看出上下文信息跟内容补充是提升明显的，内容抽取效果比较差。
上面提到的图表显示了基于机器学习的项目的直接影响，这些项目在引入时或者改进他们背后的模式。我们还观察到模型成为新产品的基础，通过其他产品开发学科实现价值创造。这种间接影响很难量化，但其倍增效应很明显，这是产品团队开发的一个概念。作为一个例子，图3说明了目的地推荐系统开发的迭代过程。每个栏代表一个成功的迭代，从顶部开始，专注于产品的一个方面：用户界面、目标受众、副本（标题、描述、消息等）或算法本身。条形图的长度表示相对于第一次迭代的相对（所有统计显著）影响。所有这些改进都是由第一个算法实现的，说明了机器学习项目通过其他学科的间接影响
3 模型：离线模型性能只是一个健康测试而已
量化模型质量的一种常用方法是估计或预测模型在暴露于它从未见过的数据时的性能。不同类型的交叉验证用于估计特定度量的值，该度量取决于任务（分类、回归、排名）。在Booking.com中，我们非常关注模型给我们的客户和业务带来的价值。这些价值是通过随机对照试验（RCT）和特定的业务指标（如转化率、订单或取消率）来估计的。一个非常有趣的发现是，提高模型的性能并不一定意味着价值的增加。
上图说明了这种学习。每一点代表一个成功的模型的比较，这个模型通过以前的RCT证明了它的价值，而不是一个新的模型。根据模型性能的离线估计，新模型与当前基线之间的相对差给出水平坐标。这些数据只涉及分类器和排序，分别用ROC-AUC和平均倒数秩进行评价。垂直坐标由在RCT中观察到的相关业务度量中的相对差给出，在RCT中比较两个模型（所有模型都针对相同的业务度量）。我们总共包括23个比较（46个模型）。目视检查已经显示出缺乏相关性，更深入的分析表明，90%置信区间（-0.45，0.27）的皮尔逊相关性为-0.1，90%置信区间（-0.5，0.19）的斯皮尔曼相关性为-0.18。我们强调，这种缺乏相关性并不是离线和在线性能之间的关系，而是离线性能增益和业务价值增益之间的关系。同时，我们不想夸大这个结果的普遍性，外部有效性很容易受到挑战，因为我们注意到这些模型是在特定的环境中工作的，对于特定的系统来说，它们是以特定的方式构建的，它们都以相同的业务度量为目标，而且它们都试图在以前的模型之后改进它已经做到了。然而，我们仍然发现缺乏相关性是一个显著的发现。事实上，这样的发现让我们调查了Booking.com的其他领域，并始终发现了相同的模式。例如[8]强调了机器翻译的标准性能度量（BLEU）与人类度量之间的关系“相当脆弱”。只有当离线指标几乎完全是业务指标时，才能观察到相关性。（这里强调了这里参与比较的相关性是不是离线指标与在线指标，而是离线指标与业务指标。一般来说，业务指标很难找到一个绝对合适的离线度量指标）
这种现象可以用不同的因素来解释，我们列出了我们发现最相关的因素：
业务价值-模型性能饱和：很明显，存在一些业务问题，不可能无限期地从模型性能增益中驱动价值，在某个点上，价值-性能曲线饱和，模型性能增益不会产生价值增益，或收益太小，无法在合理时间内在RCT中检测到。（业务指标是有上限的，模型的提升是有限的）；
实验对比饱和：当根据基线测试一个新模型时，我们应用触发分析来确保我们只考虑暴露在变化中的用户，即模型不一致的用户。随着模型之间的相互改进，这种不一致率会降低，从而减少实际接触治疗的用户数量，但这些用户数量才是检测价值增值的能力。（这里实际上是说，在做实验的时候，两个模型的对照组不可能是完全独立的；个人举个例子，比如有AB两个模型，A是旧模型，B是新模型，B的挖掘能力更强，把一些用户更喜欢的产品挖掘出来；但是这些在订单上也会有影响，订单变化被A模型检测到，A模型的表现也变好了；这样B模型实际观测到的收益就会被减弱）；
恐怖谷效应：随着模型越来越好，它们似乎越来越了解我们的用户，或者可以很好地预测用户将要做什么。这可能会让我们的一些客户感到不安，这可能会对价值产生负面影响。（这个现在经常在网络发言中有体现，用户对大数据的担忧，不喜欢被过度预测）；
对离线指标的过度优化：通常，我们的机器学习模型是监督模型，使某些观察到的变量最大化，但不一定是特定的客观业务度量。例如，我们可以建立一个基于点击率的推荐系统，因为我们知道CTR与转换率有很强的相关性甚至因果关系，这是我们在本例中真正关心的业务度量。但是随着模型越来越好，它们最终可能“只是驱动点击”，而不会对转换产生任何实际影响。这方面的一个例子是一个模型，该模型学会了向用户推荐与之非常相似的酒店，鼓励用户点击（大概是比较所有非常相似的酒店），最终将用户淹没在选择困难症中，并损害转换率。通常，过度优化代理会分散用户的注意力。（这里还是如何构造合适的离线度量，这个确实极重要）
独自解决每一个问题都很有挑战性。我们的方法依赖于一个快速的假设开发周期，建立最小模型在实验中测试它们，并使用结果不断迭代。离线模型性能指标只是一个健康检查，以确保算法执行我们想要的操作。这个周期驱使我们关注产品开发过程的许多方面，除了离线模型的性能，将迭代过程在许多维度上倍增。其中包括以下部分描述的问题构建过程、模型的定性方面（如多样性、透明度、适应性等）、实验设计和延迟。作为一个例子，考虑一个推荐系统，它可以预测用户对一个住宿的评价。最小化RMSE看起来是一种合理的方法。在几次成功的迭代之后，我们假设模型缺乏多样性，因此我们创建了一个挑战者模型，尽管仍然最小化RMSE，但不知何故产生了更高的多样性。这种新模型很可能具有更高的RMSE，但只要它能成功地增加多样性，并给出一个合理的RMSE，就可以用来检验“多样性问题”的假设。不确定的结果可能指向模型或实验设计的调整，以确保我们给假设一个公平的机会。负面的结果可能会否定这个概念。另一方面，积极的结果将鼓励与多样性相关的变化，不仅在模型中，而且在用户界面中，甚至在整个产品中。（这里就是说，还是要多做AB实验，快速迭代；不要只关心单一指标，多样性这种弱相关指标或许也是很有价值的；到底有没有，有多大，还是要做AB实验）
4 建模：在解决问题之前，先设计好它
建模阶段包括构建一个机器学习模型，该模型有助于解决手头的业务案例。一个基本的第一步是“建立”一个机器学习问题，我们了解到专注于这一步是关键。问题构建过程将一个业务案例或概念作为输入，并输出一个定义良好的建模问题（通常是一个有监督的机器学习问题），这样一个好的解决方案可以有效地对给定的业务案例建模。
通常给出了需要进行预测的任务，确定了特征空间，但目标变量和观测空间并不总是给出的，需要仔细构造。作为一个例子，考虑前面提到的日期灵活性模型，在这里我们希望在每次提交搜索请求时知道用户的日期灵活性。灵活性意味着什么：它是否意味着用户正在考虑比典型用户更多的替代日期？或者他们最终预定的日期和他们现在看到的不一样？或者，这可能意味着访问者愿意改变日期，但只是为了更划算的交易等。对于这些灵活性的定义，可以使用不同的学习设置。例如，我们可以学习预测用户将考虑将回归应用于由用户组成的特定数据集作为观察的不同日期的数量，或者通过解决分类问题（观察是在哪里搜索）来估计更改日期的概率，等等。这些都是需要设计的机器学习问题，当这些问题解决时，输出一个用户的日期灵活度模型。（这里其实是说建模的时候重要的是两个部分：目标与样本，如何设置模型的损失或者说学习目标；采用哪些样本作为训练集与测试集合适。这个其实一般是最关键的问题，做特征跟做模型之类的都是建立在目标与样本选择合理的情况下，否则模型效果再好也是与预期要达到的效果不符的）
为了比较其他问题，我们遵循简单的启发式方法，其中考虑了以下几个方面：
学习困难：当对这些非常主观的概念建模时，目标变量不是作为基本事实给出的，而是被构造出来的。因此，从学习的角度来看，有些设置比其他设置更难。量化可学性并非易事。对于分类问题，Bayes误差是一个很好的估计，因为它只依赖于数据集，我们采用Tumer&Ghosh[12]的工作方法。另一种很好地解决排序问题的流行方法是将简单模型的性能与随机性和流行性等琐碎基线进行比较。首选可以比做得更好的普通模型做得更好的简单模型。(这里指的是衡量这个问题是否容易解决（用机器学习的途径），先用简单模型做一个估计）；
数据与模型意图的匹配：有些设置使用的数据更接近我们要建模的概念。例如，对于日期灵活的情况，我们可以创建一个数据集，询问用户自己是否知道他们要访问的日期，然后建立一个模型来预测答案。这将给出一个非常简单的分类问题，与其他选项相比，它更接近日期灵活性的概念。另一方面，由于标签只提供给受访者，因此数据会受到严重的选择偏差。（这里指的是如何合理选取数据集，这个例子是很不错的，如果选择不当很容易造成偏差）；
选择偏差：如前所述，构建标签和观察空间可以很容易地引入选择偏差。一个无偏的问题将基于将1到1映射到服务时所做的预测的观察，但这并不总是可能的或最优的。诊断选择偏倚很简单：考虑自然观察空间的样本（日期或灵活性中的用户或会话），然后我们可以构造一个分类问题，将每个观测分为可计算目标变量的观测类和不能计算目标变量的观测类。如果这个分类问题很简单（简单算法的性能明显优于随机算法），那么这种偏差就很严重，必须加以解决。纠正这种偏见并不明显。逆倾向加权[11]和双稳健[4]等技术在某些情况下是有用的，但它们需要至少一个额外的模型来构建（倾向模型）。已成功应用但尚未系统化的其他方法是来自PU学习[9]和半监督学习领域的方法。（给出了一个判断选择的样本集是否存在偏差的方法，那就是看这些被选择的样本是否可以被分类模型预测出来，如果很容易预测的话说明是存在偏差的；这让我想起来看到的一种探索训练集&测试集分布方法：将一个分布的问题变成一个二分类问题,如果AUC低于0.6,则我们可以认为训练集和测试集是分布平衡的,反之我们则可以认为训练集和测试集是分布不一致的。是差不多的道理）
问题构建过程打开了一个迭代维度。对于给定的业务案例和选定的问题设置，改进模型是产生价值的最明显方式，但我们也可以更改设置本身。一个简单的例子是回归预测入住时间，然后转入多类分类问题（这个可以看出来用户的入住晚数并不应该是一个连续值预测问题，而是分类问题）；一个更复杂的例子是基于点击数据的用户偏好模型，然后切换到针对客人评论数据的自然语言处理问题（这个就是数据的选取，评论比点击可能更有说服力）。
总的来说，我们发现，通常最好的问题并不是立即浮现在脑海中的问题，而改变设置是开启价值的一个非常有效的方法。
5 模型部署：时间就是金钱
在信息检索和推荐系统中，众所周知，高延迟对用户行为有负面影响[1]。我们通过运行一个多臂RCT来量化延迟对我们平台的业务影响，其中分配给每个arm的用户都暴露在合成延迟中。结果如图6所示（右下象限）。每个点是实验的一个手臂，水平坐标是手臂和对照组之间观察到的（平均）潜伏期的相对差，垂直坐标是转换率的相对差。十字架对应的是没有统计意义的手臂，圆圈对应的是没有统计意义的手臂。这是一个4个手臂的单一实验（加上一个对照组），所以我们使用了什维克修正来解释多重测试。目视检查显示出一个明显的趋势，即延迟成本增加约30%，转换率增加超过0.5%（这是我们业务的相关成本）。这一发现使我们假设，减少延迟可以产生转换增益。在图6的左上象限中，我们可以看到在4个不同设备和网站不同页面上的单独实验中降低延迟的效果。所有的结果都有统计学意义，支持这一假设。这与机器学习模型尤其相关，因为它们在进行预测时需要大量的计算资源。即使是数学上简单的模型也有可能引入相关的延迟。例如，一个线性模型可能需要计算许多（成百上千）复杂的特征，或者需要对数千个适应点进行评估。我们网站中的许多页面包含几个机器学习模型，其中一些模型是在用户级别计算的，其他的是在项目级别（目的地、住宿、吸引力等）甚至是在UI小部件级别计算的。即使每一个模型足够快，也必须仔细考虑整体效果。
数据与模型的实时性确实是重要的，有多重要呢（这里给出了一个参考评估，看来还是比较重要）
6 模型监督：值得注意的监督盲区
当模型为请求提供服务时，监视其输出的质量至关重要，但这至少带来了两个挑战：
不完全反馈：在许多情况下，无法观察到真正的标签。例如，考虑一个预测客户是否会要求“特殊请求”的模型。它的预测在用户购物时使用（搜索结果页面和酒店页面），但我们只能为实际预订的用户所做的预测分配一个真正的标签，因为在预订时可以填写特殊请求。为未预订的用户所做的预测将没有关联的真标签。
延迟反馈：在其他情况下，真正的标签只在预测后的几天甚至几周才被观察到。考虑一个预测用户是否提交评论的模型。我们可能会在购物时使用这种模式，但真正的标签只有在客人完成入住（可以在几个月后）后才能看到；
因此，在这些情况下，标记依赖性度量（如精确性、召回率等）是不合适的，这导致我们产生了以下问题：仅通过查看模型在服务时所做的预测，我们可以对模型的质量说些什么？为了回答二元分类器的问题，我们应用了我们称之为响应分布分析的方法，这是一组指向模型中潜在病态的启发式方法。该方法基于响应分布图（RDC），它只是模型输出的直方图。一个理想模型的RDC应该在0处有一个峰值，在1处有一个峰值（高度由类比例给出），这一简单的观察使我们能够描述典型的模式，这些模式代表了模型中潜在的问题，下面是几个例子：
具有中心模式的平滑单峰分布可能表示模型中的高偏差或数据中的高Bayes误差
•极端高频模式可能表示特征层中的缺陷，如训练数据中的错误缩放或假异常值
•非平滑，非常嘈杂的分布指向过于稀疏的模型
•训练和服务数据之间的分布差异可能表示概念漂移、特征漂移、训练集中的偏差或其他形式的训练服务偏差。
•具有一个清晰稳定点的平滑双峰分布是成功区分两类的模型的标志
这些启发式方法的基本原理是，如果一个模型不能给不同的类分配不同的分数，那么它很可能无法区分不同的类，分数的微小变化不应该改变预测的类。稳定点在哪里并不重要（这可能表明校准问题），重要的是只有一个，因为目标是明确地将两个类别分开，一个接受治疗，另一个不接受治疗。这种方法具有以下优点：
它可以应用于任何评分分类器应用数据科学跟踪文件
•它对类分布是稳健的。在极端情况下，使用RDC中频率的对数使提示更加明显
•它解决了提供全局反馈的不完全反馈问题，因为RDC是在考虑所有预测的情况下计算的
•它解决了提供即时反馈的延迟反馈问题，因为RDC可以在几个进行预测
•它对类别分布和特征空间变化都很敏感，因为它只需要很少的数据点就可以被构造出来•当类的数量很小时，它可以被用于多类分类，只需为每个类构造一个二值分类器来区分一个类和其他类（一个对全部或一个对其余的）
•它提供了一个无标签的标准来选择一个阈值来转换得分进入二进制输出。标准是在两个类代表模式之间简单地使用RDC的最小值。如果该区域较大，则可以选择使用该区域的下限和上限来最大化召回率或精度。当同一个模型用于系统的不同点（如酒店页面或搜索结果页面）时，这非常有用，因为它们具有不同的类别分布的不同人群。(这个也有点trick的意思了）
主要缺点是：
•这是一种启发式方法，它不能证明或反驳一个模型具有高质量
•它在实践中不适用于估计器或ranker，响应分布分析已被证明是一个非常有用的工具，使我们能够很早地发现模型中的缺陷。
（机翻有点过分了；这里的意思其实是对于难以观测到结果的分类模型（目前只有分类模型），可以观测其已有结果的分布，用分布直方图来判定问题，便于及时调整）
7 模型评估：实验设计
这一节主要是AB实验分流的问题了，略过
8 自己的总结
感觉还是一篇不错的paper，说了很多机器学习模型在互联网2c市场应用的真实探索经验，主要是以下几点：
如何将模型与业务应用相结合（文中提到的应用例子在真正优化用户体验方面都比较有参考价值）；
用自己的实践经验表明了机器学习可以在多方面带来改进，提升价值；表明了实时模型的重要性；
分析了离线模型效果与线上模型业务价值的不一致性原因（解决办法：构造合适的离线度量；不要过分优化单一指标；多做AB实验进行探索分析）；
设计模型最为重要，尤其是target构建与样本的选取；（结合业务构建合适的target；样本选择是否存在偏差）；
对于部分标签难以及时观测的模型，建立分布直方图来观测模型效果，便于及时改进（只适用于分类问题）；