腾讯手Q游戏中心个性化推荐实践

背景

作为腾讯手游的重要发行渠道之一，手Q游戏中心不仅是用户发现感兴趣游戏的重要入口，同时也提供了运营各类手游平台的能力。新版游戏中心不再单纯通过传统的应用列表分发游戏，而是增加了一系列新场景，通过内容（攻略、视频、直播、礼包等）吸引下载和活跃（如图1）。为了更好地提升用户进入游戏中心的体验，满足平台精细化运营的需求（吸引新用户、吸引用户、吸引付费等），通过挖掘用户游戏偏好成为了一种方式。海量用户行为，精准推荐用户感兴趣的内容，是必然趋势。为此，我们设计了全新的个性化推荐框架，为业务带来了显着的转化率提升。

图1：Game Center个性化推荐场景

整体推荐框架

本节主要结合游戏中心个性化推荐的算法框架（如图2）和工程框架（如图3）来总结项目过程中遇到的一些问题。 Game Center采用的推荐框架是业界常见的三阶段推荐逻辑：离线——近线——在线。离线层主要负责存储游戏中心所有用户的流数据，计算用户的长期行为属性，训练用户的游戏偏好模型。近线层主要负责解决离线层计算周期长、响应速度慢的缺点。通过实时计算用户的短期兴趣并在线反馈，从而实时反馈用户在游戏中心的行为；在线层可以理解为推荐引擎，主要对业务请求进行一系列计算，返回最终的推荐结果列表。在线层可以细分为召回层-精细排序层-重排序层结构。

图2：游戏中心个性化推荐算法架构图

图3：游戏中心个性化推荐项目架构图

线下层1.推荐材料准备

图4：内容源数据链接

2. 数据处理

熟悉推荐流程的同学可能知道，数据处理过程繁琐、耗时，占据整个算法开发周期的60%以上，贯穿整个开发流程。在陷入陷阱之前，有些人可能会认为推荐算法工程师是一个高级职位。每天看论文、研究算法、做实验，很爽。一旦入坑你就会发现你每天做的最重要的工作就是处理数据。但这也充分说明了数据处理的重要性。毕竟，只有充分了解数据，才能更好地理解业务，更合理地设计自己的推荐策略。这里所说的数据处理主要包括数据校验、脏数据过滤和数据转换。下面主要总结一下数据处理过程中遇到的坑：

（1）一定要验证数据上报的准确性：有时候前端同学可能不是特别了解算法同学对上报数据的诉求，所以上报时可能会出现目标不一致的情况。常见情况包括：上报逻辑错误（分页feed 暴露时只上报第一个feed 的数据）、上报id 错位（暴露的operid 上报下载的数据）、上报id 缺失等。数据上报的准确性就是打开游戏中心，操作每个场景下可能用到的用户行为，记下操作时间，一小时后从流水里捞出你的数据，逐一验证。是否合理（噩梦）。

（2）当推荐逻辑出现问题时，优先检查数据的准确性：当推荐结果出现问题或bug时，应优先检查数据的准确性。模型的鲁棒性和容错性普遍较高，最容易出现问题的往往是在数据链路上。通常，问题是沿着数据链路上游逐步定位的。

（3）创建一层数据中间表，用于业务流数据解耦：算法开发过程中，最好不要直接操作operid相关逻辑。当业务改变上报的id（比如产品改版，一套新的operid）时，改变代码就会让人头疼。

（4）算法对接后，一定要和产品及前端同学确认算法ID上报的准确性：业务在调用推荐引擎时会获取一个算法ID，算法ID上报的准确性直接影响效果监测报告的可信度。很多时候，我们应用算法策略后，发现线上效果突然下降。经过长时间排查，我们发现一些原始转换行为的算法ID报告缺失，所以这里必须仔细验证。

（5）脏数据过滤是一门玄学：脏数据的定义通常需要根据业务场景来确定。有时候信心十足地过滤完所有脏数据后，线上效果就降低了，所以过滤数据的时候一定要小心（什么是脏数据？脏数据就一定没用吗？别想当然，我们来说说线上效果吧！ ）。

（6）建立完善的报表监控体系：推荐的重要一环就是报表监控，不仅包括效果的监控，还包括矿池、核心用户、物品场景表现等的监控。只有建立完善的监控体系当推荐结果受到质疑时能否快速定位问题。

图5：游戏中心报表监控系统

3. 样品设计

一般来说，推荐问题会转化为二分类问题，即判断用户是否会对某个item进行操作（通常是U-I对作为样本），那么就需要训练一个在线算法看上去比较合理，线上效果也很理想。对于二分类模型来说，正负样本的设计极其重要。下面总结了Game Center针对不同场景设计样本的一些经验：

（1）如何正确定义正样本和负样本？在纯图标推荐场景下，乍一看可以理解为，如果用户下载了应用，就是正样本，如果用户没有下载应用，就是负样本。但仔细想一想，就会发现两个问题。第一个问题是正负样本极度不平衡（机器学*中的经典问题之一），因为用户可能在浏览数十个应用后只下载一个应用。当然，机器学*对于正负样本不平衡的问题有很多解决方案，这里不再赘述。第二个问题是，如果用户不下载，并不代表他不喜欢。这里有几点值得考虑： 1）用户被暴露，但没有发生下载行为。可能是因为这是一次无效曝光，用户的注意力焦点不在这里，所以无法判断用户是否喜欢； 2）用户接触到游戏图标的场景并没有产生下载行为，而是用户进入游戏详情页后点击然后下载。是否可以认为用户确实喜欢，结果就是正样本？这个例子主要是为了说明，对于每一个不同的推荐场景，正负样本的设计要充分结合业务特点，否则很容易出现样本偏差。

（2）设计样本时，每个用户的样本数量要均衡：在app分发或者内容分发场景中，很可能存在一些刷用户；这组用户频繁进入游戏中心，产生多次操作，因此在设计样本时，应对多次操作的U-I样本对进行去重，并平衡每个用户的样本数量，避免模型出现偏差。用户数量少。

(3)样本权重的设计问题：在Feed推荐场景中，不同推荐槽位生成的样本权重应该不同；例如，在首页feed 场景中，当用户第一次进入场景时，注意力会更加集中，导致Negative 样本应该具有更高的置信度和更高的权重；当用户向下滚动到后面的提要时，提要的内容可能会变得无聊，并且生成的正样本也应该具有更高的置信度和权重。

4. 特征提取

特征决定了机器学*的上限，而模型只是逼近这个上限。可想而知功能设计有多么重要。特征设计的方法有很多种，这里不再详细讨论。这里主要介绍游戏中心各场景特征设计的总体思路以及用于解决首页Feed特征空间不一致问题的多模态嵌入特征。

（1）总体特征设计思路：如图6所示。这里需要提到的是，Game Center的推荐场景涉及到平台利益，所以一般来说，在设计特征时需要考虑特征的可解释性。

图6：功能设计思路

(2)多模态嵌入特征向量：主页Feed分发场景是一个具有挑战性的场景。比较有趣的问题之一是，有很多类型的内容需要推荐。传统的推流推荐场景要么是纯视频流，要么是纯文本推流等，而游戏中心首页推荐的内容类型包括攻略、视频、直播、活动、礼包等，每种内容类型都有其次托管页面的产品形式也不一致，这会导致可提取的特征空间维度不一致。例如，视频托管页面的观看时间与图文托管页面的观看时间不一致。视频托管页面有图标点击等操作，图文托管页面没有。特征空间的不一致会导致模型在评分时出现偏差。线下实验中发现，由于该视频的特征维度较为完整，因此整体评分结果较高。因此，为了缓解特征空间维数不一致的问题，游戏中心主页Feed流引入了多模态嵌入特征向量。该方法在企鹅电竞视频推荐场景中取得了不错的效果（如图7）。多模态嵌入特征向量的设计主要参考YouTube论文，从而得到每个用户和物品的低维特征向量。一方面解决了物品原始特征空间维度不一致的问题，另一方面也基于用户的历史行为进行学*。用户和物品的潜在语义特征维度起到补充信息的作用。

图7：多模态嵌入网络

5.模型训练

好的，我们终于达到了其他人认为的高级步骤。 ——模型训练其实水平根本不高，尤其是深圳推荐平台。目前SHIELD推荐离线算法平台已经集成了最常见的推荐算法，包括LR、Xgboost、FM、CF等，因此离线训练只需要准备样本和特征，配置参数，点击run就可以喝咖啡了一键点击。 （开玩笑，我正在继续下一块砖）。傻瓜式模型训练（跳包侠）其实并没有太多的陷阱，但我在这里写下一些经验：

（1）注意调整参数的正确姿势：目前SHIELD默认将数据集分为train和test。如果针对测试数据集的指标来调整参数，很可能会出现离线高、在线低的情况。因为着眼于测试指标调整参数时很容易添加个人先验，这本身就是一种过拟合操作。正式的操作应该是把数据集分为train-test-validation。

（2）相同业务场景建议共享大模型：新版Game Center目前有9个场景需要算法接入。如果每个场景单独建模，维护成本会很高，而且会浪费人力。正确总结场景问题并训练通用模型可以有效节省开发时间。比如首页的品类列表推荐、游戏选项卡的热门游戏列表推荐等，其实都是纯粹的图标推荐，可以使用统一的大模型来建模。对于通用模型首先要考虑的是样本和特征的选择。通过总结所有场景的样本可以更好地设计样本。最多的是根据场景特点设计不同的权重。需要仔细考虑特征，根据场景提取特征。或者聚合后提取，不同场景下特征维度不一致如何处理等。

（3）选择合适的机器学*方案：目前首页feeds将排序问题转化为二分类问题，评价指标为AUC，因此优化的重点是尽可能分离正样本和负样本（正样本）样本排在负样本的旁边）样本在前面），但是正样本中谁更“正”并不是二分类模型的重点。 Aegis最近支持了pari-wise LTR算法，可以解决任意两个样本之间的置信度问题。以后可以在首页feeds场景中尝试。

（4）选择合适的优化指标：对于视频瀑布流场景，优化目标可以有很多，比如人均播放次数、播放速率、人均播放时长等。具体需要和产品同学沟通清楚。

（5）避免分类问题的过拟合：前面提到，在推荐场景中，推荐问题往往会转化为分类问题。但需要注意的是，推荐问题不仅仅是分类问题。分类问题是基于历史行为进行预测，但推荐问题有时需要考虑跳出用户历史行为的限制，推荐一些用户意想不到的物品。因此，推荐是一个系统性问题，应避免过度拟合分类问题。

6. 数据在线

数据在线可以说是推荐系统中的核心环节，它会面临很多问题。这里的数据主要指离线计算的物质数据、特征数据（用户、物品）、模型数据等。目前SHIELD会定期将需要在线的数据导出到HDFS，通过数据导入服务推送到在线存储，主要是杂货（用户特征）和共享内存SSM（物品特征和池数据）等经常查询的数据。 ）。目前这里有一些小问题：

(1)数据一致性问题：离线模型训练时，样本数据和特征数据是拼接的。通常，将当前时期的样本与前一时期的特征进行拼接。以天为例，即今天的样本将与昨天的特征数据进行拼接。但离线数据尤其是特征数据的计算和上线会存在时间延迟。有可能今天0:00到5:00上线拉取的特征数据实际上是前天的特征数据。 5:00后，昨天的特征数据在线计算更新。也就是说，凌晨5点之前，生成的推荐结果实际上是使用前天的特征数据计算的，因此在离线训练时，拼接后的特征数据会与实际数据不一致。

（2）数据的实时性：如前所述，业务数据一般会以数据库表的形式定期（按小时）传输到HDFS或TDW。数据经过Spark处理后推送到在线存储。这种复杂性由于数据处理环节较差，数据时效性无法保证（数据落地、数据上线频繁造成）。因此，离线层只适合数据不及时的任务，比如长期利息的计算。

前面提到近线层，离线层在数据时效性和数据一致性方面面临着更大的挑战。本质上是由于频繁的数据登陆和上线造成的延迟，给游戏中心推荐带来了很大的麻烦。企鹅电竞也面临同样的问题，因此两家业务共同设计了近线层（如图8所示）。目前，整个数据链路已打通，并在企鹅电竞业务试点成功。整个框架是基于kafka+spark Streaming构建的。目前主要实现两个功能点：实时特征的提取和实时样本特征的拼接。由于近线层不需要落地和线上数据服务，而是直接操作业务管道然后写入线上存储，所以耗时较少，基本可以实现秒级特征反馈，解决了线下层计算的问题。周期长的缺点是适合捕捉用户的短期利益。

实时样本特征的拼接主要是为了解决数据一致性问题。离线层拼接样本和特征时，一般默认将当前周期的样本与上一周期的特征进行拼接。由于特征上线的延迟，部分当前周期样本的生成实际上是由t-2周期的特征造成的。因此，为了保证训练数据的准确性，我们在近线层设计了实时样本特征拼接。当用户请求时，会将读取到的特征数据带过来，拼接到用户的操作流程数据上，形成离线层的训练数据。

图8：近线层功能逻辑

在线层在线层是推荐系统中的关键环节，直接影响最终的推荐结果。一般分为召回层、精细排名层、重排名层（或称匹配、排名、重排名）。召回层一般起到粗筛的作用。对于内容推荐来说，推荐池一般是几万级。如果直接对模型打分，线上服务压力会更大。因此，通常会采用各种召回方式。粗略筛选候选集的策略。目前游戏中心使用的召回策略主要有标签、流行度、新鲜度、CF等，精细调度层做的事情比较纯粹。它通常涉及模型加载和模型评分，以及对召回项目进行评分和排序。最后是重排层，主要对模型评分结果进行策略调整。游戏中心的重排层主要有以下逻辑： 1）品类分散：首页Feed 推荐时，如果仅通过模型控制进行评分，很容易出现游戏聚集在一起的情况，即几个连续的游戏feeds都是同一个游戏，所以需要重新排列图层来调整显示顺序； 2）流量分配：游戏的分配涉及平台的利益，每款游戏的曝光度都会影响平台的收益，因此需要合理分配每款游戏的展示数量； 3）bandint策略：主要用于兴趣测试。 Feed 场景将涉及多种内容类型。如何在推荐用户历史上喜欢的内容类型和尝试暴露新的内容类型之间取得平衡是推荐系统中典型的EE问题。这里我们设计一个简单的bandint策略，下面会详细讨论。 4）运营策略：一些更加面向业务的运营策略也会在重排层得到体现。

推荐系统中遇到的一个经典问题是Exploitation（开发）VS Exploration（探索）问题。剥削基于最知名的策略，并开发和利用已知更高回报的项目（贪婪的、短期回报）。对于探索，不考虑过去的经验，而是探索具有潜在高回报的项目（非贪婪，长期回报）。最终目标是找到Exploitation Exploration 的权衡，以最大化累积回报。对于游戏中心首页的Feed来说，盲目推荐用户过去喜欢的内容类型或者尝试大量曝光新的内容类型是不可行的；首先，用户的兴趣可能会波动。他们过去可能喜欢视频类型，但下一刻可能就不喜欢了。你可能不再喜欢它了；其次，盲目推荐用户过去喜欢的内容类型可能会让用户感到厌倦。为了平衡两者的关系，我们在重排层设计了一个简单的策略，如图9和图10所示。

图9：Game Center强盗策略算法逻辑

图10：游戏中心强盗策略具体实现

迭代计划

目前Game Center个性化推荐遇到的困难以及下一步迭代计划主要有以下几个：

2.多模态特征提取：游戏中心的推荐内容类型比较丰富，包括视频、图文、活动、礼包等，如何从同一特征向量空间中的每一项中提取信息是当前的研究热点之一问题。现有的解决方案是基于YouTube的嵌入网络来学*用户和项目的嵌入向量。这个网络的输入是无序的，即不考虑用户历史行为的轨迹。那么是否可以用图来表示行为的轨迹，并基于图嵌入方法得到信息量更大的项向量呢？目前业界已经有几个基于图嵌入的推荐案例（手淘宝首页、阿里巴巴订单集）。

3.内容元信息的提取：目前Game Center中物品的特征提取要么是基于统计特征，要么是基于物品的历史行为的嵌入特征或标签提取。内容本体信息的提取还比较薄弱。如何有效提取？有关非结构化内容的信息是下一次迭代中需要考虑的问题。

4、模型快速更新：用户兴趣的实时捕捉不仅依赖于数据的实时更新，更依赖于模型的实时更新。目前，在线模型每天都会定期更新。如何快速训练和部署模型是未来不可避免的问题。

5、优化指标考虑收入相关因素：目前的优化指标基本都是转化率、时长等推荐系统中常见的指标。但游戏中心涉及平台收入，需要综合考虑每款游戏的收入（类似于广告系统中的竞价）。如何设计合理的优化指标（考虑游戏ARPU、LTV等），平衡用户体验与平台收入，也是下一次迭代的关键。

6、流量分配问题：首页Feed场景既涉及游戏流量分配，又涉及内容类型流量分配。如何有效设计流量分配方案，减轻重排逻辑的负担，也是需要考虑的优化点。

7、吸引用户或者吸引新用户：如何根据游戏生命周期的不同阶段为用户推荐合适的内容，是首页Feed场景下需要考虑的问题。

8、新产品测试：目前我们只在内容类型上做了一些简单的策略。未来我们需要研究更成熟的解决方案来解决EE问题。