干货 | 机器学习模型在携程海外酒店推荐场景中的应用

作者简介

 

Louisa，携程算法工程师，热爱前沿算法和技术在个性化推荐和广告建模等业务的性能优化和落地。

导读

互联网企业的核心需求是“增长”，移动互联时代下的在线旅游业也不例外。随着大数据、云计算和人工智能等技术的不断进步，通过算法和模型来实现增长已成为核心。

近年来推荐系统迅速崛起，主要解决在信息过载的情况下，帮助用户高效获取感兴趣的信息，同时帮助企业最大限度的吸引用户、留存用户、增加用户黏性、提高用户转化率。因此个性化的推荐服务对于在线旅游业也变得非常重要，通过推荐能够将用户从众多的旅行选择中解放出来，指导用户快速找到感兴趣的项目，大大简化用户的旅行计划和购买。

在线旅游服务商 (OTA)提供的应用中包含酒店、航班、旅游产品、攻略等各个环节和产品。其中酒店涉及到的推荐场景较多，例如城市热门酒店推荐、附近同类型酒店推荐、机票页酒店交叉推荐、Meta着陆页相似酒店推荐、信息流推荐等。大部分场景都实现了个性化的推荐服务，其核心就是一组酒店与一组用户相匹配的挑战。

推荐准确性取决于如何利用可用信息，这些信息主要包括物品信息(I)、用户信息(U)及上下文信息(C)等，例如给定的酒店特征、酒店的位置吸引力、用户的购买历史等。将这些信息构建一个函数 f(U,I,C)，预测用户对特定候选酒店的喜好程序，再根据喜好程度对所有候选酒店进行排序，生成推荐列表。见图1推荐系统逻辑框架。

推荐系统排序模型在推荐系统中占据绝对核心的地位，很多公司也都在提出并尝试一些前沿的算法和推荐模型。而机器学习和深度学习模型正在变得越来越复杂，将这种复杂模型推上线，模型响应速度就可能变得很慢，因此对推荐系统的数据流和工程实现产生新的挑战。

如何做到海量数据的实时处理、特征的实时提取、线上模型服务过程的数据实时获取以及工程能力与技术方案的平衡等，成为模型上线的重要挑战。本文主要探讨OTA酒店推荐方面常用的在线部署模型以及技术架构，并从核心之外的角度审视推荐系统的不同技术模块及优化思路。

图1 推荐系统逻辑框架

一、酒店推荐系统的技术架构

实际推荐系统中主要解决的问题可以分为两类，数据部分以及算法模型部分。其中数据部分融合了数据离线批处理、实时流处理的数据流框架。算法模型部分则是集训练 (training)、评估 (evaluation)、部署 (deployment)、线上推断 (online inference) 为一体的模型框架。目前通用的推荐系统技术架构如图2所示。

图2 推荐系统的技术架构示意图

1.1 数据部分

推荐系统的数据部分主要负责用户、物品、上下文的信息收集与处理。并且按实时性强弱，分别在三种平台上进行处理。客户端是最接近用户的环节，也是能够实时收集用户会话内行为及上下文特征的地方，这些特征随http请求一起到达服务器端是常用的请求推荐结果的方式。

随着Storm、Spark Streaming、Flink等流计算平台的日益成熟，利用流计算平台进行准实时的特征处理已经成为当前推荐系统的主要模式。流计算平台并非完全实时的平台，每次需要等待并处理一小批日志，以流的形式进行微批处理（mini batch），系统可能无法在3分钟内把session内部的行为历史存储到特征数据库（如Redis）中。但它的优势是能够进行一些简单的特征统计的计算，比如一个物品在该时间窗口内的曝光次数，点击次数、一个用户的页面浏览时长等。

大数据离线数据处理主要是利用Spark等分布式批处理计算平台对全量特征进行计算和抽取。主要用于模型训练和离线评估，以及将特征保存入特征数据库，供之后的线上推荐模型使用。

酒店推荐系统中的实时特征部分主要来源于用户的实时点击行为数据和一些上下文信息（如GPS获得的地点信息等），通过Storm或Flink进行准实时流处理，将用户实时行为数据解析入特征数据库Redis。

离线特征部分主要包含用户和酒店两部分的特征。其中用户离线特征主要由用户画像（CRM）提供，包含数据库中用户的订单和浏览历史信息等，并且严格遵守欧盟通用数据保护条例（GDPR）。酒店离线特征主要包含酒店的基础信息，如星级、评分等。由于特征维度及样本量较大，离线特征数据的清洗与预处理通常在Spark平台上进行，后将处理好的特征数据落入HDFS的Hive表并同步至Redis缓存中。离线特征与实时特征合并供线上模型使用。下面代码展示Hive表数据同步Redis的方法：

1.2 模型部分

模型部分是推荐系统的主体，一般由召回层、排序层、补充策略与算法层组成。召回层一般利用高效的召回规则、算法或者简单的模型，快速从海量的候选集中召回用户可能感兴趣的物品。排序层利用排序模型对筛选的候选集进行精排序。排序层是推荐系统产生效果的重点，后面部分将重点介绍一些主流推荐模型和酒店推荐上的应用。

补充策略与算法层也被称为再排序层，再将推荐列表返回用户之前，根据新鲜度、多样性等指标结合补充策略与算法进行一定调整，最终形成用户可见的推荐列表。从召回所有候选物品集，到最后产生推荐列表，这一过程一般称为模型服务过程。

在线环境进行模型服务之前，需要通过模型训练确定模型结构及参数值，并生成模型文件。另外，为了评估推荐模型的效果，方便模型的迭代优化，推荐模型部分有离线评估和线上A/B测试等多种线上线下评估模式。

 

二、酒店推荐系统的工程实现

如何将离线训练好的模型部署在线上的生成环境，进行线上实时推断，一直是业界难点。目前酒店推荐场景中主要用到两种部署推荐模型的主流方法，一是利用PMML转换并部署模型，二是Tensorflow Serving方式。

2.1 利用PMML转换并部署模型

酒店推荐场景中由于实时数据量较大，通常采用SOA框架实现分布式服务，完成模型服务过程。但绝大部分SOA框架都是Java或C++语言编写，而预测模型大多是基于Python语言。因此常用预测模型标记语言（Predictive ModelMarkup Language，以下简称PMML）重新实现算法模型，然后将模型封装成类，通过JAVA调用这个类来进行预测。由python封装的模型可以通过sklearn中的sklearn2pmml函数实现PMML文件转换。XGBoost模型需要JPMML-XGBoost命令行转换工具，转换命令为：

                           

XGBoost模型需要生成.model模型文件和 .fmap特征映射文件。.model文件可以通过save_model函数生成。

2.2 Tensorflow Serving

上面的方法也适用于Tensorflow生成的模型，但由于Tensorflow模型文件往往较大，且PMML文件无法优化，使用起来比较麻烦。本质上讲，Tensorflow Serving的工作流程和PMML类工具的流程是一致的。不同之处在于，Tensorflow定义了自己的模型序列化标准。

利用Tensorflow自带的模型序列化函数可将训练好的模型参数和结构保存至某文件路径。路径下包括variables文件夹和saved_model.pbtxt文件。variable文件夹下包含各个变量的状态（断点），有*.data和*.index两类文件。*.data记录变量的内容。*.index文件用于将变量名映射到*.data中的变量数据。.pbtxt文件是包含SavedModel、MetaGraphs、Graphs、签名等的二进制protobuf。模型文件通常由自身的Python API生成，然后由Tensorflow的客户端库（如JAVA或C++库）来加载模型并进行在线预测。以下代码展示了使用SavedModelBuilder 构建 SavedModel 的典型方法ÿ