手q游戏中心是什么，腾讯游戏为什么不能用q q登录

来源：头条浏览：0 2022-12-24 08:02:01

手机q游戏厅V6.0更新后，产品形态发生了很大的变化。不仅仅是用APP的列表分发游戏，而是用内容拿着游戏进行分发。新的产品形态给推荐算法带来了很多挑战。到4月初，算法一期的工作已接近尾声。利用这个机会写总结。另一方面，梳理整个游戏中心的推荐逻辑，沉淀总结其中的一些经验，便于回溯。另一方面，在整理过程中，尝试整理出面临的一些挑战，使算法二期的迭代思路更加清晰。

背景

手q游戏厅作为腾讯手游的重要分发渠道之一，在为用户发现感兴趣游戏的关键点入口的同时，也提供了各手游的平台运营能力。游戏中心新版新增了一系列内容(攻略、视频、直播、礼包等)下载、活跃的场景，如图1所示，而不是单纯以传统的APP列表分发游戏。为了更好地提升用户进入游戏中心的体验，满足平台精细化运营(新进入、直播、付费发布等)的需求，通过海量的用户行为挖掘用户的游戏偏好，挖掘用户感兴趣的内容为此，我们设计了新的个性化推荐框架，为业务带来了显著的转换率提升。

图1 :游戏中心个性化推荐场景

为了更好地制定算法二期的迭代规划，本文主要是对算法一期的工作进行简单的再现，一方面总结和沉淀项目开展过程中的一些经验，另一方面梳理游戏中心推荐场景中比较具有挑战性的问题，从而实现算法二期的

总体推荐框架

本节结合了主要由游戏中心个性化推荐的算法框架(如图2所示)和工程框架(如图3所示)，总结了项目中遇到的一些问题。游戏中心采用的推荐框架是offline—nearline—online这一行业常见的三段式推荐逻辑。离线层主要负责游戏厅存储用户流水数据、计算用户长期行为属性、训练用户的游戏偏好模型等的近线层主要为了解决离线层计算周期长、响应速度慢的缺点，实时实现用户短期通过在线反馈，可以实时反馈用户在游戏中心的行为；在线层可以理解为推荐引擎，主要是对业务请求通过一系列计算，返回最终的推荐结果列表。在线层可以细分为召回层-精加工层-再配置层结构。

图2 :游戏中心个性化推荐算法体系结构图

图3 :游戏中心个性化推荐的工程架构图

离线层主要用于HDFS Spark的工程实现(批量)，因为离线层适合于用户长期感兴趣的计算、离线模型训练、模型参数实验以及其他对时效性要求较低的任务业务数据通过DC或TD库进行报告，累计一定的数据量(游戏中心为每小时的周期)，周期性地落地到HDFS或TDW上，以数据库表的形式存在，以Spark为计算引擎，对数据库表的数据进行一系列的处理在游戏中心这个场景中，离线层的工作流程可以分为六个步骤。推荐材料的准备、数据处理、样品设计、特征提取、模型训练、数据在线化。

1、推荐材料的准备

对于推荐系统来说，首先要确定的是推荐材料(也就是推荐池)。游戏中心推荐的道具主要有两种。第一个类别是游戏APP。目前游戏厅访问算法的游戏APP主要包括精品游戏、单机游戏，基本每天变化不大。因此，这种材料从业务中每天定期报告更新，推送至在线存储即可。第二类是游戏内容，主要包括攻略、视频、直播等，这类材料相对实时性要求会高一 ( )新游上线当天需要内容同步更新)。目前游戏中心的内容源数据链接如图4所示，主要来源是一些上游PGC内容的购买，经过自动Tag提取进入标签图库，算法方直接从标签图库中获取推荐材料，目前按小时

图4 :内容源数据链接

2、数据处理

熟悉推荐过程的学生可能知道数据处理过程繁琐、枯燥、耗时，占整个算法开发周期的60%以上，并且涵盖了整个开发过程。进洞之前，可能有人以为推荐算法工程师是一个很高的职位，每天舒服地看着帕珠，研究算法，做实验，很酷。一进洞，你就会发现每天最多的工作是处理数据。但是，这充分说明了数据处理的重要性。最终，只有充分了解数据，才能更好地理解业务，更合理地设计推荐战略。这里的数据处理主要包括数据验证、脏数据滤波、数据转换等。我们来总结一下在数据处理中踩出的洞。

)1)做好数据上报的准确性验证)前端的同学可能不太了解算法同学对上报数据的诉求，因此上报时目标可能不一致。常见的情况是上报逻辑错误(寻呼feeds曝光只上报了最初的feeds数据)、id偏差上报了)、曝光的operid报告了下载的数据)、id缺失验证数据上报正确性的正常操作是打开游戏中心，对每个场景中可能使用的用户行为进行一次操作，记录操作时间，1小时后从流水中取出数据，逐一验证是否合理。

)2)推荐逻辑有问题时，优先考虑数据的正确性)推荐结果出现问题或出现错误时，优先检查数据的正确性。模型的鲁棒性和容错性一般较高，最可能出现问题的是数据环节。通常沿数据链路向上游逐步进行故障排除，以确定问题。

)3)在开发业务流水数据生成数据中间表、解耦)算法过程中，最好不要直接操作operid相关逻辑。遇到业务变更报告id时(例如，产品改版变更为新的operid集时)，代码变更的你很头疼。

)4)访问算法后，务必与产品和前端学生再三确认算法ID上报的正确性。业务在调用推荐引擎时获取算法ID，算法ID上报的准确性直接影响效果监测报告的可靠性。大多数情况下，乘坐算法策略后，发现在线效果突然下降，经过半天排查，缺少原部分转换行为的算法ID报告，在此需要仔细验证。

)5)脏数据过滤是玄学(脏数据的定义一般需要根据业务场景来确定，有信心过滤完所有脏数据后，在线效果反而会下降，所以过滤数据时肮脏的数据一定没用吗？当然，用网络效果说话吧！请参阅。

(6)建立完善的报告监控系统)推荐的关键环节是报告监控，不仅包括效果监控，还包括水池监控、核心用户监控、item场景表达监控等。只有建立完善的监控系统，才能在推荐结果受到挑战时快速识别问题。

图5 :游戏中心报告监控系统

3、样品设计

一般来说，推荐问题会转换为二分类问题。也就是说，它确定用户是否对某个项目执行操作。通常，U-I对是一个样本。那么，要训练能够期待合理在线效果的二分类模型，正负样本的设计是极其重要的。以下是游戏中心在设计不同场景范例时的经验总结。

)1)如何正确定义正负样本？纯icon推荐的场景，乍一看可以理解为用户下载了该APP后为正的样本，不下载则为负的样本。但是，仔细想想就会产生两个问题。第一个问题是正负样本极不均衡。 (机器学习中的经典问题之一)。因为即使用户浏览几十个APP也可能下载一个APP。当然，机器学习对正负样本的不平衡问题有很多解决方法，在此不再赘述。第二个问题是，用户没有下载并不意味着不喜欢。这里有几个值得推敲的地方。 1 )用户已被曝光，但从未有过下载行为。恐怕是无效的曝光，所以无法判断用户关注的不是这里，而是用户喜欢还是不喜欢。 2 )用户在游戏icon上曝光的场景中没有发生下载行为，但用户会发生点击行为，从而在进入游戏详细页面后发生下载行为。由此，用户实际上很喜欢，发生也可以认为是正面的样品吧。举这样的例子主要是为了说明，对于每个推荐场景，正负样本的设计都要充分结合业务特性。否则，容易产生偏差样品。

)2)为了平衡每个用户的样本数而设计样本)在APP发布和内容发布场景中，容易存在被上传的用户；由于该组用户频繁进入游戏厅，会发生多次操作行为，在设计样品时多次操作对应的U-I样品对变重，保证了每个用户样品数量的平衡，模型偏向少数用户

)3)样本权重的设计问题)在feeds推荐的场景中，根据推荐插槽产生的样本权重应该不同；例如，在首页的feeds场景中，用户刚进入场景时，注意力会集中，生成的负采样应该可靠，权重也应该很高，如果用户落到后面的feeds上，可能会对feeds的内容感到无聊。生成的正采样的可靠性也很高，权重也应该设定得很高。

(4)适当丰富样本来源多样性)一般样本是基于当前场景产生的用户行为选择的，但当前场景的用户行为在一定程度上受到推荐结果的影响(“如果你推荐王者荣耀，那么只有王者才会喜欢我可能更喜欢吃你不推荐的鸡”)算法的迭代，越往后，算法其实就在迭代本身，学习就越窄。这也是推荐系统的经典youtube采用的缓解措施之一是从没有算法干扰的其他场景中选择一部分样本来避免这个问题。游戏中心的样例设计单独开设了无算法干扰的小流量作为清洁样例的补充。

4、特征提取

特征决定机器学习的上限，但模型只是接近这个上限。可见特色设计的重要性有多么高。关于特色设计的方法论有很多，这里不具体讨论。这里主要介绍了游戏厅各场景在设计特征时的一般思路，以及为了解决首页feeds特征空间的不一致而采用的多模态嵌入式特征。

)1)共同特征设计思路：如图6所示。应该提到的是，由于游戏中心推荐场景涉及平台利益，一般需要在设计时考虑特征的可描述性。

图6 :特色设计思路

2 )多模态嵌入式特征向量：首页的feeds流分发场景是一个具有挑战性的场景，一个有趣的课题是需要推荐的内容类型很多。传统的feeds推荐场景都是纯视频流、纯文本feeds等，而游戏厅首页推荐的内容类型有攻略、视频、直播、活动、礼包等，每个内容例如，视频载波中的页面的观看时间与图像载波中的页面的观看时间的等级不一致。视频载体的页面上有icon点击等操作，但图像载体的页面上没有。由于特征空间的不一致，模型在评分时存在偏差，但离线实验表明视频特征维数较齐，评分结果总体较高。因此，为了缓解特征空间维度的不一致，在游戏中心首页的feeds流中引入了多模态嵌入式特征向量。该方法在企鹅电竞视频推荐场景中取得了较好的效果(如图7所示)。多模态嵌入式特征向量的设计主要参考youtube论文，获得每个user、item的低维特征向量，一方面解决了item原特征空间维度的不一致问题，另一方面基于用户的历史行为，给出了user、item的隐藏

图7 :多模式嵌入式网络

5、模特训练

那么，终于到了别人想的高步骤——模型训练，其实一点也不贵。特别是有神盾的话推荐这个平台。目前神盾推荐离线算法平台已经集成了LR、Xgboost、FM、CF等大部分常用推荐算法，离线训练只需准备样本和特征，配置参数，一键即可瓜瓜式的模型训练(包机)其实没有太大的漏洞，但我有一些经验，在这里也写一下。

(1)注意调参的正确姿态)目前神盾默认将数据集分为train和test。盯着test数据集的指标进行参考的话，很有可能是在线上线行。因为盯着test指标参赛的话，个人事前很容易进入，本身就是过拟合的操作。我认为正规的操作是将数据集分成train-test-validation。

)2)在同一业务场景下，建议共享大模式。新的游戏中心目前有9个场景需要访问算法。对每个场景分别建模会增加维护成本并浪费人力。恰当地总结场景问题，训练通用模型可以有效地节约开发时间。例如首页分类列表推荐、游戏标签热锁列表推荐等，其实纯粹的icon推荐，可以用统一的大模型进行模型化。通用模型首先要考虑的问题是样本、特征的选择。样品可能很容易设计。收集所有场景的样本就可以了。最多就是根据场景的特性设计不同的权重；特征是按场景提取特征，还是汇总提取，如果不同场景的特征维度不一致怎么办等，都需要仔细考虑。

)3)选择合适的机器学习方案：目前首页的feeds将排序问题转化为二分类问题，由于评价指标选择的是auc，优化的重点是尽量区分正负样本(正样本在负样本之前) 屏蔽最近支持pari-wise的LTR算法，可以解决任意两个样本之间的可靠性问题。然后在首页的feeds场景中试试。

(4)选择合适的优化指标)对于视频瀑布场景，优化的目标可以有很多，如人均播放次数、播放率、人均播放时间等，具体有与产品同学清晰沟通

5 )避免对分类问题的过度拟合)如上所述，推荐场景中多将推荐问题转化为分类问题来处理，但需要注意的是推荐问题不仅仅是分类问题。虽然分类问题是基于历史行为进行预测的，但有时推荐问题需要考虑摆脱用户历史行为的限制，部分用户会推荐一些意想不到的item，因此推荐属于系统性问题，不应过于适合分类问题。

6、数据上线

数据在线化可以说是推荐系统的核心部分，但其中也面临许多挑战。这里的数据主要是指离线计算的材料数据、特征数据(用户、项目)、模型数据等。目前，神盾定期将需要在线化的数据签出到hdfs，并通过数据部署服务推送至在线存储。主要是grocery (用户特征)和共享存储器ssm (物品特征和池塘数据等)查询相对频繁的数据。这里有几个小问题。

)1)数据完整性问题)在离线模型中，在训练时，将样本数据和特征数据连接起来。通常，将当前周期的样本根据前一周期的特征进行拼接。以一天为例，也就是说，今天的样本要与昨天的特征数据进行拼接。但是，离线数据的计算和在线化有时间延迟，特别是特征数据。今天凌晨0点到5点，线上的特征数据其实可能是前天的特征数据。 5点以后，昨天的特征数据被计算并更新为在线。也就是说，凌晨5点之前生成的推荐结果，实际上是根据前天的特征数据进行计算的，但是离线训练时，拼接的特征数据与实际数据不一致。

)2)数据的实时性问题)如前所述，业务数据周期性(按时间)落地到hdfs和tdw上作为数据库存在，在基于spark进行数据处理后，推送至在线存储器。如此复杂的数据处理链路不保证数据的时效性) )由于频繁的数据落地和数据的在线化)。因此，离线层仅适用于数据时效性不高的任务，如长期感兴趣的计算。

正如我们已经提到的，离线层在数据时效性和数据完整性问题上面临着巨大的挑战。本质上是由于数据频繁落地和在线化导致的延迟，给游戏中心的推荐带来了很大的麻烦。由于企鹅电竞也面临着同样的问题，所以联合了两个业务设计了近线层(如图8所示)。现在，数据链接已经开通，企鹅的电竞事业也成功地进行了试点。整个框架基于kafka spark streaming构建，目前主要实现了两个功能点：实时特征的提取和实时样本特征的拼接。近线层不需要落地和数据传输服务，直接操作业务流程写入在线存储，省时省力，基本可以秒钟特征反馈，解决了离线层计算周期长的缺点，用户

样本特征的拼接主要是为了解决数据完整性问题。离线层拼接样本、特征时，一般以当前周期样本前一周期的特征为缺省。由于特征上线的延迟，现周期样本的产生部分其实是由于t-2周期的特征，为了保证训练数据的准确性，在近层设计了实时样本特征拼接。用户要求时，自带读取的特征数据，与用户操作流程数据拼接，构成离线层训练数据。

图8 :近线功能逻辑

在线层是推荐系统中的重要环节，直接影响最终的推荐结果。分为召回层、精加工层、位错层或匹配、ranking、rerank。召回层一般起到粗筛的作用，对于内容推荐来说推荐池一般在数万个级别，直接进行模型评分会增加在线服务压力，因此通常采用多种召回策略对候选集进行粗筛。目前游戏厅采用的召回策略主要有标签、热度、新鲜度、CF等。精化层所做的是纯粹的，一般通过模型加载和模型评分，对召回的项目进行评分排序。最后是重定位层，主要是战略调整模型的评分结果。游戏中心的排序排名主要包括以下逻辑： 1 )分类零散。首页的feeds推荐的时候，如果只用模型进行评分控制的话，容易发生游戏凝固的现象。也就是说，由于几个feeds连续是同一个游戏，所以排序层需要调整展示的顺序。 2 )流量分配)游戏分发涉及平台利益，每款游戏的曝光度会影响平台收入，需要合理分配每款游戏的展示量3 ) bandint策略)主要用于探索兴趣。 fEEds场景包含多种内容类型。如何在推荐用户历史偏好的内容类型和尝试曝光新的内容类型之间取得平衡是推荐系统典型的ee问题。在这里，设计了简单的bandint战略。详情在后面叙述。 4 )运营战略)一些偏向业务的运营战略也体现在位错层。

推荐系统中遇到的一个典型问题是Exploitation (开发) VS Exploration问题。其中的Exploitation基于已知的最佳战略，开发利用了被认为具有高回报的item )，但没有考虑到Exploration曾经的经验。探索有望潜在高回报的item (长期回报，而不是贪婪)的最后一个目标是找到Exploitation Exploration的trade-off以最大化累计回报。在游戏中心的首页feeds上，不可能一味推荐用户历史上喜欢的内容类型，也不可能尝试大量发布新的内容类型。首先用户的兴趣可能会动摇。过去可能喜欢视频类型，但下一瞬间可能会讨厌。其次，如果一味推荐喜欢用户历史的内容类型，用户可能会厌倦。为了平衡两者的关系，对位错层设计了简单的策略。具体如图9、图10所示。

图9 :游戏中心的bandit策略算法逻辑

图10 :游戏中心bandit战略的具体实现

迭代计划

目前，游戏厅的个性化推荐和下一步的迭代计划主要包括：

1、外部数据导入：1)结合第三方数据推荐)目前游戏厅个性化推荐的依据主要是用户的场景表现、游戏内表现以及一些基础的图像数据，数据源比较单一。引入更多的第三方业务数据(如企鹅电竞)，一方面丰富了用户的特色维度，另一方面也能给用户带来体验上的提升(用户刚在企鹅电竞上看到吃鸡直播，在游戏中心2 )丰富的推荐材料)目前游戏厅内容来源部分存在“同质化”现象，素材类型尚不特别丰富，需要引入更多优质外部内容。

2、多模态特征提取：游戏厅推荐内容类型丰富，包括视频、图文、活动、礼包等，如何在同一个特征向量空间中对各个item进行信息提取是当前面临的挑战之一。现有解决方案基于youtube的嵌入式网络进行用户、item的嵌入式向量学习。如果这个网络的输入是无序的，也就是没有考虑用户的历史行为轨迹，那么可以用图表示行为轨迹，基于graph embedding的方法得到信息更丰富的item向量吗？目前，业界也有一些基于graph embedding的推荐事例()通过手动取出主页、蚂蚁聚集单)。

3、内容元信息提取：目前游戏厅item的特征提取是基于统计特征或基于item历史行为的嵌入式特征或tag提取，对于内容主体信息的提取还比较薄弱，如何有效利用非结构化内容的信息

4、模型快速更新：用户兴趣的实时捕获不仅依赖于数据的实时更新，而且依赖于模型的实时更新。目前的在线模型每天都在定期更新，快速训练模型和引入模型是后续不可避免的问题。

5、优化指标考虑收入相关因素。目前的优化指标基本上是转化率、时间长度等推荐系统常见的指标，但游戏中心与平台收入相关，需要综合考虑各游戏的收益。如何设计考虑游戏arpu、ltv等因素的合理优化指标，以及如何平衡用户体验和平台收益也是下一次迭代的关键。

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

7、拉活还是拉新：如何在游戏生命周期的不同阶段为用户推荐合适的内容是首页feeds场景中需要考虑的问题。

8、新产品尝试：目前我们只是对内容类型做了简单的策略，之后需要调查更成熟的解决方案来解决EE问题。

总结

本文主要总结游戏厅在算法一期访问过程中遇到的问题，并整理下一步迭代的计划。由于算法的第一个重点是快速访问算法，涉及整个个性化推荐框架的策略可能有点“着急”，请同行多多包涵。请随时交流游戏中心的推荐问题

原文刊登在微信公众号-腾讯QQ大数据( qq_bigdata )上