推荐对象获取方法、装置及存储介质与流程

本申请涉及数据处理技术领域，具体涉及一种推荐对象获取方法、装置及存储介质。

背景技术：

目前，随着互联网技术的迅猛发展，在新闻、商务、娱乐等很多领域，提出利用推荐系统，来预测用户的喜好，从而筛选出用户可能感兴趣的对象(如新闻信息、产品信息、音视频等)推送给用户，极大减少了用户查找所需对象的工作量，为用户的工作、生活带来了很大便利。

其中，推荐系统通常是按照预设召回逻辑，从大量数据中召回一定数量的数据作为召回对象，之后，从这些召回对象中筛选用户最可能点击的一些对象，作为推荐对象推送至用户客户端。

基于这种推荐方式，按照预设的召回逻辑筛选出的召回对象往往是相同的，导致召回对象中一些用户最不可能点击的对象每次都会占用推荐资源，并反复对其进行无意义的点击率预估，降低了召回对象的准确率，进而影响了推荐准确性。

技术实现要素：

有鉴于此，本申请实施例提供一种推荐对象获取方法，依据上一次获取推荐对象期间筛选出的未推荐对象，获取本次召回对象，提高了召回对象的准确率，防止了质量差的对象持续占用资源，进而提高了推荐准确性。

为实现上述目的，本申请实施例提供如下技术方案：

本申请实施例提供了一种推荐对象获取方法，所述方法包括：

获取上一次的未推荐对象，所述上一次的未推荐对象是上一次获取推荐对象期间，筛选出的未被推送至用户客户端的召回对象；

依据第一召回逻辑及所述上一次的未推荐对象，得到本次召回对象；

获取所述本次召回对象各自的预测点击率；

按照所述预测点击率大小，从所述本次召回对象中筛选出推送至所述用户客户端的推荐对象。

本申请实施例还提供了一种推荐对象获取装置，所述装置包括：

未推荐对象获取模块，用于获取上一次的未推荐对象，所述上一次的未推荐对象是上一次获取推荐对象期间，筛选出的未被推送至用户客户端的召回对象；

召回对象获取模块，用于依据第一召回逻辑及所述上一次的未推荐对象，得到本次召回对象；

预测点击率获取模块，用于获取所述本次召回对象各自的预测点击率；

推荐对象筛选模块，用于按照所述预测点击率大小，从所述本次召回对象中筛选出推送至所述用户客户端的推荐对象。

本申请实施例还提供了一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行，实现如上所述的推荐对象获取方法的各步骤。

基于上述技术方案，本申请实施例提供的一种推荐对象获取方法、装置及存储介质，在推荐系统的召回阶段，获取本次召回对象期间，本申请将获取上一次获取推荐对象期间，筛选出的未被推送至用户客户端的召回对象，即上一次的未推荐对象，进而依据第一召回逻辑及该上一次的未推荐对象，得到本次召回对象，而不再直接利用第一召回逻辑，得到本次召回对象，以使得到的本次召回对象中，不再包含与未推荐对象相匹配的召回对象，避免了这类召回对象对推荐资源的占用，提高了召回准确率，同时，还避免了对不会向用户客户端推送的召回对象的预测点击率计算步骤，减轻了推荐系统的排序模块的压力，节省了计算资源。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为现有的一种推荐系统的工作原理示意图；

图2为本申请实施例提供的一种推荐系统的工作原理示意图；

图3为本申请实施例提供的一种推荐对象获取系统的结构示意图；

图4为本申请实施例提供的一种推荐对象获取方法的流程示意图；

图5为本申请实施例提供的另一种推荐对象获取方法的流程示意图；

图6为本申请实施例提供的另一种推荐对象获取方法的流程示意图；

图7为本申请实施例提供的又一种推荐对象获取方法的流程示意图；

图8为本申请实施例提供的一种推荐新闻获取方法的流程示意图；

图9为本申请实施例提供的另一种推荐新闻获取方法的流程示意图；

图10为本申请实施例提供的一种推荐对象获取装置的结构示意图；

图11为本申请实施例提供的另一种推荐对象获取装置的结构示意图；

图12为本申请实施例提供的又一种推荐对象获取装置的结构示意图；

图13为本申请实施例提供的一种应用服务器的硬件结构示意图。

具体实施方式

现有的推荐系统中，参照图1所示的推荐系统的结构示意图，召回模块与排序模块之间的数据是单向传输的，即召回模块从大量数据中粗选出n个召回对象作为候选推荐对象，由排序模块对其进行精排，筛选出排序靠前的k个推荐对象(即用户最可能感兴趣的推荐对象)推送给用户客户端。

其中，召回模块采用的召回逻辑往往是固定的，这就导致召回模块每次召回的n个召回对象的重复度较高，且每次召回的n个召回对象中会存在一些质量较差的召回对象，即排序模块得到的排序靠后的若干个召回对象，并不断发送至排序模块进行排序处理，不仅增大了排序模块的计算压力，且由于这类召回对象在反复召回后，排序仍然是比较靠后，不会被推送给用户客户端，使得这类召回对象会持续占用资源，导致大量数据中的其他对象不能得到推送机会。

为了改善上述问题，参照图2所示的推荐系统的结构示意图，本申请将排序模块的排序结果反馈至召回模块，实现了召回模块与排序模块之间的双向交互，即召回模块不仅能够将得到的召回结果发送至排序模块，还能够获得排序模块对召回对象的排序结果，并结合排序结果，调整发送至排序模块的n个召回对象，来提高召回质量，避免质量差的召回对象占用资源，以及增大排序模块不必要的计算压力，还提高了推荐准确率及推荐对象的覆盖率。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参照图2，为实现本申请提供的推荐对象获取方法的一种系统结构示意图，该系统可以包括应用服务器11、客户端12及存储服务器13，其中：

应用服务器11可以是为用户提供服务的服务设备，其可以是与客户端相匹配的应用服务器，如客户端是购物软件，应用服务器可以是提供购物服务的应用服务器，客户端是新闻浏览软件，应用服务器可以是提供新闻服务的应用服务器等等。

在本实施例中，应用服务器11可以执行本申请下文提供的推荐对象获取方法，为使用客户端12的用户推送其可能感兴趣的推荐对象，以辅助用户快速且准确选择需要的对象，或方便用户了解与当前浏览对象相关的其他信息，提高业务服务效率。

其中，应用服务器11可以是一个独立的应用服务设备，也可以是由多个应用服务器构成的服务集群，本实施例对该应用服务器的结构不作限定。

客户端12可以是安装在如手机、笔记本电脑、ipad、工控机等电子设备上的应用程序，其具体可以是独立的应用程序，如从应用商店下载安装的软件，也可以是网页应用程序，即无需下载，通过浏览器等应用程序直接启动客户端，建立与相应应用服务器的通信连接。

存储服务器13可以是用来存储数据的存储设备，即下文实施例描述的数据块，本实施例中，其可以用来存储每次筛选出的质量较差的未推荐对象，本申请对该存储服务器13的类型不作限定，如键值数据库等，对于不同类型的存储服务器13，可以采用相应的数据存储方式，实现对获取的未推荐对象的存储，本申请对此不作详述。

可选的，该存储服务器13可以与应用服务器11集成在一起，也可以作为独立的两个服务器，具体可以根据所适用于的应用平台的系统结构确定。

需要说明，在本实施例提供的系统中，并不局限于上文列举的应用服务器、客户端、存储服务器等，还可以包括多媒体服务器、会话服务器等其他计算机设备，可以根据实际需要选定系统组成，本实施例在此不再一一详述。

结合上图2所示的系统结构示意图，参照图4，为本申请实施例提供了一种推荐对象获取方法的流程示意图，本实施提供的方法可以由应用服务器执行，如图4所示，该方法可以包括但并不局限于以下步骤：

步骤s11，确定至少一个应用平台中的待召回对象；

本实施例中，该至少一个应用平台可以包括上述应用服务器所在的第一应用平台，此外，还可以包括与该第一应用平台关联的其他第二应用平台，本申请对该至少一个应用平台的类型不做限定。

以新闻推荐场景为例，第一应用平台可以是某新闻浏览平台，如某头条新闻应用平台，第二应用平台可以包括其他新闻平台等，也就是说，各应用平台能够输出同一类数据，通过该类数据实现各应用平台之间的关联，当然，也可以基于用户在各应用平台上的账户信息，实现各应用平台之间的关联，本申请对此不做限定。

对于应用平台中的待召回对象，可以包括用户在该应用平台上的历史行为数据，也可以包括该应用平台输出的与用户当前浏览对象关联的对象，还可以包括基于其他因素确定的该应用平台输出的对象，本申请对确定的待召回对象的内容不作限定。

可选的，本申请可以基于推荐系统采用的召回方法，来确定从哪里召回用来进行推荐的召回对象，也就是说，基于推荐系统的召回模块所采用的召回逻辑，来确定从哪些应用平台的待召回对象中，获取一定数量的召回对象。

仍以上文的新闻推荐场景为例，对于热点召回逻辑，可以将各应用平台的热点新闻作为待召回对象，但对于如何确定热点新闻的方法本申请不做限定，可以由其所在应用平台的控制逻辑确定；对于地域召回逻辑，可以将与用户所在地域或关注地域相关的新闻作为待召回对象等；对于兴趣召回逻辑，可以基于用户的历史行为数据，分析确定出用户感兴趣的新闻作为待召回对象等等。

可见，对于不同召回逻辑，所确定的待召回对象可能不同，并不局限于本文描述的内容，且推荐系统所采用的召回逻辑，也并不局限于上文描述的几种方式，还可以包括协同过滤召回、媒体召回等各种召回逻辑，可以根据开发者及用户需求调整，且在本申请实际应用中，可以根据推荐需求，可以选择一种或多种召回逻辑，确定待召回对象，并从中获取一定数据的召回对象，也就是说，本申请推荐系统所采用的召回逻辑可以是一种召回逻辑，也可以是多种召回逻辑的组合。

步骤s12，基于第一召回逻辑，从确定的待召回对象中获取召回对象；

结合上文分析，第一召回逻辑可以包括兴趣召回、协同过滤、特点召回、地域召回、媒体召回等多种召回逻辑中的一种或多种，本申请对该第一召回逻辑的内容不做限定。

其中，对于本文列举的几种召回逻辑，大致可以分为基于内容的召回(如兴趣、媒体、地域、热点等召回逻辑)和基于用户行为的召回(如协同过滤)两大类，基于内容的召回，可以是使用应用平台中的内容信息，而不依赖用用户行为数据，不存在新内容的冷启动问题，且这种召回方式很容易在降维阶段引入用户行为，可以吸收一部分协同过滤的优点，但这种方式需要实时分析用户意图，通过分析内容，推荐与用户浏览历史相似的内容作为召回对象。

而基于用户行为的召回方式，是通过用户行为向量，使用item-base和user-base等算法，向用户推荐相似内容或者相似人群喜欢的内容。对于这种方法，对于用户行为数据丰富的用户，能够快速且高效向用户推送高质量的推荐对象，但存在新内容的冷启动问题。

基于上述分析，本申请可以根据实际需要，合理且灵活选择所使用的第一召回逻辑，以保证后续所得推荐对象的准确性及可靠性，本申请在此不做详述。

其中，上述召回逻辑实际可以理解为，按照一定方法，从大量数据(即待召回对象)中为用户粗选出一定数量的召回对象，相对于粗排序，之后，粗选出的召回对象，可以由ctr(clickthroughrate，点击通过率)预估的rank模块(排序模块)进行精排序，以得到向用户客户端推送的推荐对象。因此，对于不同的召回逻辑，所采用的数据筛选算法可以不同，本申请对此不作详述。

步骤s13，对获取的召回对象进行点击率预估，得到各召回对象的预测点击率；

本实施例中，可以利用ctr点击率预估方式，来预测各召回对象将会被用户点击的概率，即得到各召回对象的预测点击率，通常情况下，预测点击率越大的召回对象，其被用户点击的概率越大，本申请对ctr点击率预估方式的具体实现过程不做详述。

可选的，本申请可以预先训练得到ctr预估模型，这样，在获取召回对象后，可以直接将其输入该ctr预估模型，预测用户点击该召回对象的概率，即得到召回对象的预测点击率，本申请对该ctr预估模型的训练过程不做限定，如基于神经网络算法对样本数据进行训练得到，但并不局限于这种算法。

其中，用于训练得到ctr预估模型的样本数据可以是上述待召回对象，且对于不同的第一召回逻辑，本申请可以预先配置对应的ctr预估模型，用来训练该ctr预估模型的算法可以相同，也可以不同，具体可以依据所选定的样本数据及其预测要求确定，本申请对此不做一一详述。

可选的，对于输入该ctr预估模型的待召回对象，可以生成对应的特征向量，如利用待召回对象的属性信息，生成该待召回对象的特征向量，但并不局限于这种生成方式。这样，在确定待召回对象，可以将对应的特征向量依次输入ctr预测模型，得到该待召回对象的ctr值即预测点击率，用来进行后续精排。

步骤s14，筛选预测点击率较大的第一数量个召回对象，将该第一数量个召回对象作为推送至用户客户端的推荐对象；

可选的，本申请可以按照得到的各召回对象的预测点击率大小，对相应的各召回对象进行排序，进而选择预测点击率较大的第一数量个召回对象，确定为推送至用户客户端推荐对象。其中，对于排序后选择的第一数量个预测点击率较大的召回对象，本申请还可以根据实际需要，按照这些召回对象的属性信息进行打散后展示，以提高展示效果，本申请对得到的推荐对象的打散方法不作限定。

需要说明，关于步骤s14的实现方法并不局限于上段描述的先排序后筛选第一数量个召回对象的方式，也可以直接通过两两比较，确定出预测点击率较大的第一数量个召回对象等等。

步骤s15，筛选预测点击率较小的第二数量个召回对象，将该第二数量个召回对象作为未推荐对象；

步骤s16，将筛选出的未推荐对象存储至键值数据库。

需要说明，步骤s15可以与步骤s14同时执行，并不限定于本实施例描述的这种步骤排序，且对预测点击率较小的第二数量个召回对象的筛选方式，可以采用步骤s14对预测点击率较大的第一数量个召回对象的筛选方式，即按照预测点击率大小，对各召回对象进行排序后，选择出预测点击率较小的第二数量个召回对象，如对各召回对象的排序是按照预测点击率从大到小的顺序实现，之后，可以选择排序靠前的第一数量个召回对象为推荐对象，以及排序靠后的第二数量个召回对象为未推荐对象，即从排序后的最大预测点击率对应的召回对象开始，选择第一数量个召回对象为推荐对象，并从排序后的最小预测点击率对应的召回对象开始，从排序末端向前选择第二数量个召回对象为未推荐对象)；当然，若按照其他方式对获得的各召回对象进行排序，确定推荐对象和未推荐对象的方式也会相应调整，本申请不再一一详述。

在现有的推荐系统，仅关心筛选出的推荐对象，而对于本申请按照上述方式筛选出的未推荐对象并不会关注，结合上文对现有推荐系统存在的问题的分析，每次召回得到的召回对象基本相同，导致推荐系统中的排序模块会反复对质量不高的召回对象(如上述未推荐对象)进行无意义地排序，增大排序模块的计算压力。

为了改善上述问题，本申请提供出在排序模块从召回的各召回对象中，筛选出向用户客户端推送的推荐对象的同时，也筛选出未被推送至用户客户端的未推荐对象，尤其是预测点击率较小的一些召回对象，将其存储到数据库中，用来在下一次向该用户客户端推送推荐对象的情况下，推荐系统的召回模块从待召回对象中得到一定数量的召回对象中，读取数据库存储的未推荐对象，并将召回的各召回对象中与该未推荐对象相匹配的召回对象剔除，保留与该推荐对象不匹配的召回对象为候选推荐对象。

也就是说，本申请可以在排序模块下一次从得到的各召回对象中筛选推荐对象之前，可以利用上一次排序结果，对得到的召回结果进行预处理，剔除其中质量较差的召回对象，即上一次排序结果表明被用户点击概率很低的召回对象，从而避免这类召回对象再次参与排序，对排序模块造成不必要的计算压力，具体实现过程可以参照下文相应实施例的描述。

需要说明，本实施例描述的推荐对象获取方法的各步骤，可以是当前应用平台首次向用户推送推荐对象所采用的方法，在按照上述方法得到该用户的未推荐对象后，可以采用下文实施例描述的方法，即基于未推荐对象和召回对象，得到向用户客户端推送的推荐对象的方法。所以说，对于首次向用户推送推荐对象所采用的推荐对象获取方法，本申请不做限定，可以采用上文实施例描述的方法，也可以采用其他推荐系统实现的推荐对象获取方法，只需要在获取向用户推送的推荐对象的同时，获取不会向用户推送或未来推送概率极低的本次未推荐对象。

结合上文描述的推荐系统的推荐对象获取方法，以及图3所示的本申请推荐系统的结构示意图，参照图5，为本申请实施例提供的另一种推荐对象获取方法的流程示意图，该方法可以应用于应用平台的应用服务器，如图5所示，该方法可以包括但并不局限于以下步骤：

步骤s21，获取上一次的未推荐对象；

结合上述实施例对未推荐对象的获取过程的描述，该上一次的未推荐对象是上一次获取推荐对象期间，筛选出的未被推送至用户客户端的召回对象，具体可以包括上一次基于召回逻辑得到的召回对象中，预测点击率较小，未被推送至用户客户端的召回对象，也可以包括本次获取推荐对象之前的多次推荐对象获取过程中，得到的未推荐对象等，本申请对该数据库存储的未推荐对象的内容不做限定，通常依据具体应用场景确定。

本实施例中，用来存储未推荐对象的数据库可以是键值数据库，如redis数据库等，本申请对未推荐对象的具体存储方式不做限定。

因此，在利用推荐系统获取向用户推送的推荐对象的过程中，主要是在整个推荐过程中的召回阶段，可以读取数据库存储的未推荐对象，并将该未推荐对象应用到召回阶段，即本实施例能够利用待召回对象和未推荐对象，确定本次召回对象，提高了召回准确率。基于此，上述步骤s21可以是在推荐系统的召回阶段执行，具体实现方法可以依据未推荐对象在数据库中的存储方式确定，本实施例在此不做详述。

步骤s22，依据第一召回逻辑及该上一次的未推荐对象，得到本次召回对象；

结合上述实施例的步骤s11和步骤s12相应部分的描述，传统推荐系统中，是直接依据召回逻辑，从待召回对象中获取召回对象，而本实施例，在此基础上，获取了在此之前得到的未被推送至用户客户端的召回对象，即上述上一次的未推荐对象，这样，在确定本次召回对象阶段，即确定发送至推荐系统的排序模块的召回对象阶段，能够利用上一次的未推荐对象，避免质量较低、不会被推送至用户客户端的对象再次被召回，占用资源，且会因发送至排序模块再次进行无意义处理，而增大排序模块的计算压力。

需要说明，本申请对步骤s22的具体实现方法不做限定，如直接利用获取的上一次的未推荐对象，调整本次召回模块所采用的召回逻辑，再利用调整后的召回逻辑，从大量待召回对象中，获取本次召回对象；也可以在利用召回逻辑得到候选召回对象后，从该候选召回对象中剔除与上一次的未推荐对象相匹配的对象，之后，利用剔除剩余的候选召回对象确定本次召回对象，再对本次召回对象进行后续处理等等，并不局限于本申请列举的两种实现方式。

可选的，本实施例召回阶段所采用的第一召回逻辑，可以是上文列举的一种或多种召回逻辑，但并不局限于本文列举的召回逻辑。通常情况下，为了提高对象推荐准确性及丰富性，本申请推荐系统可以采用多路召回方式，获得候选召回对象，一种召回逻辑可以对应一路召回，也可以对应多路召回，本申请对召回逻辑的内容及其召回方式不做限定。

作为本申请另一可选实施例，为了实现对用户个性化推荐，在执行步骤s22的过程中，可以结合该用户的用户画像信息，从大量待召回对象中，筛选出与用户画像相匹配的召回对象，本申请对用户画像信息的获取方法不做限定。

步骤s23，获取本次召回对象各自的预测点击率；

关于召回对象的预测点击率的获取方法，可以参照上述实施例步骤s13相应部分的描述，但并不局限于上文实施例描述的获取方式。

需要说明，结合上文各步骤的分析，本实施例得到的本次召回对象是确定发送至推荐系统下一处理阶段，即发送至排序模块(rank模块)进行下一步处理的目标对象，由于本实施例利用之前得到的未推荐对象，调整了召回阶段的召回策略，使得到的本次召回对象不会包含已经确认为质量较差的对象，即不会向用户推送的对象，从而避免了质量较差的对象对资源的占用，且不需要对质量较差的召回对象重复进行点击率预估，再次确定其是质量较差的对象，减少了排序模块所要执行的点击率计算量，降低了排序模块的计算压力。

步骤s24，按照预测点击率大小，从本次召回对象中筛选出推送至用户客户端的推荐对象，以及未被推送至该用户客户端的未推荐对象；

关于步骤s24的实现过程，可以参照上述实施例步骤s14和步骤s15相应部分的描述，但并不局限于上文实施例描述的筛选方式。

需要说明，步骤s24筛选出的未推荐对象可以是本次召回对象中，未被推送至用户客户端的部分召回对象，具体筛选方法可以参照上述实施例相应部分的描述。

步骤s25，利用本次筛选出的未推荐对象，更新上一次筛选出的未推荐对象。

本实施例中，推荐系统中的排序模块每次对得到的召回对象进行点击率预估，得到推荐对象的同时获取未推荐对象后，可以利用本次获取的未推荐对象，更新数据库中已存储的未推荐对象，以保证数据库存储的未推荐对象是当前阶段，最可能不会被用户点击的对象，进而提高推荐准确率及召回率，本申请对如何更新数据库存储的未推荐对象的方法不做限定。

比如，直接用本次获取的未推荐对象，替换上一次筛选出的未推荐对象；或采用差异替换方式，如将本次筛选出的未推荐对象与上一次筛选出的未推荐对象进行比对，将本次筛选出的但数据库已存储的未推荐对象中不具有的未推荐对象，补充到数据库中，对于连续两次筛选出的相同的未推荐对象，可以不用重复写入数据，减小了工作量。

在此基础上，本申请可以认为数据库中存储的，但本次未筛选出的未推荐对象质量得到提高，即这类未推荐对象向用户推送的概率提高，本申请可以删除数据库已存储的但本次未筛选出的未推荐对象，这样，在下一次进行对象召回时，不会再剔除该未推荐对象及其相似对象，提高了推荐准确率。

需要说明，本申请对数据库存储的未推荐对象的更新方式不做限定，不局限于上文列举的几种实现方式。通常情况下，经过对未推荐对象的更新，可以使得数据库中更新后的未推荐对象至少包含本次筛选出的未推荐对象，也就是说，数据库中包含了当前阶段用户最不可能会点击的对象。

综上，本申请在得到召回对象的预测点击率后，会获取预测点击率较小的一定数量的召回对象作为未推荐对象，并将其存储到数据库中，用来进行下一次召回期间，对召回的候选召回对象作进一步筛选，剔除下一次召回的不会被推送至用户客户端的候选召回对象，避免其对推荐资源的占用，提高召回准确率，且还能够适当减少进行预测点击率进行的数量，即减少召回模块到排序模块的输出总量，减轻排序模块的压力，节省了更多的计算资源。

参照图6，为本申请提供的又一种推荐对象获取方法的流程示意图，该方法可以是上文实施例获取推荐对象的一种细化实现方式，并不局限于本文描述的这种实现方式，如图6所示，该方法可以包括但并不局限于以下步骤：

步骤s31，依据第一召回逻辑，从至少一个应用平台中的待召回对象中，获取候选召回对象；

本实施例中，步骤s31的实现过程可以参照上文实施例相应部分的描述，可见，本申请可以采用一路召回或多路召回方式，从大量待召回对象中，粗略筛选出一定数量的候选召回对象。

步骤s32，读取数据库存储的用户客户端关联的上一次的未推荐对象；

关于未推荐对象的获取过程，以及将其写入数据库存储的过程，可以参照上文实施例相应部分的描述，本实施例不再赘述。

需要说明的是，该上一次的未推荐对象可以是在此之前向该用户客户端推送推荐对象过程中，由推荐系统的排序模块筛选得到的质量较差的对象，对于不同的用户客户端，对应的未推荐对象可能不同，因此，本申请可以在数据库中存储当前应用平台注册或登录过的各用户分别具有的未推荐对象，如建立各用户客户端(可以由用户的账号等属性信息表示)与上一次的未推荐对象之间的关联关系，以便用户使用客户端访问当前应用平台，当前应用平台的应用服务器向该用户客户端推送推荐对象过程中，能够读取与该用户客户端关联的上一次的未推荐对象，来优化召回策略。

当然，本申请还可以依据各用户的属性信息，对各用户进行分类，对每一类用户的用户客户端，存储对应的未推荐对象，也就是说，属于同一类用户，推荐系统向其推送推荐对象过程中，可以利用相同的未推荐对象，来快速且准确获取推荐对象等。

在实际应用中，应用服务器确定推送推荐对象的用户客户端后，可以获取该用户客户端的属性信息，如用户账号等，从数据库中读取对应的未推荐对象，但步骤s32的实现方法并不局限于此。

步骤s33，获取候选召回对象与上一次的未推荐对象的相似度；

为了避免对召回的质量较差的召回对象重复排序，增大排序模块的计算压力，阻挡其他待召回对象的曝光机会，本实施例在获得候选召回对象之后，且在对其进行精筛选，得到推荐对象之前，可以利用在此之前得到的未推荐对象，对本次得到的候选召回对象做进一步筛选，即剔除本次召回的候选召回对象中，质量较差的候选召回对象，也就是剔除与数据库存储的未推荐对象相匹配的召回对象，筛选出与未推荐对象不匹配的召回对象确定为本次召回对象，筛选出质量较高的候选召回对象进行后续精筛选，以得到推荐对象，这样就避免了对质量较差的对象进行无意义的精筛选，以减少工作量。

基于此，在得到候选召回对象后，本实施例可以直接从候选召回对象中，筛选与未推荐对象不匹配的召回对象确定为本次召回对象，同时，筛选出与未推荐对象匹配的召回对象确定为未推荐对象。

其中，关于候选召回对象是否与未推荐对象相匹配，可以通过计算候选召回对象与未推荐对象之间的相似度实现，具体的，对于与任一未推荐对象的相似度大于相似阈值的召回对象，可以认为该召回对象与该上一次的未推荐对象相匹配，本申请可以将该召回对象剔除；反之，可以认为该召回对象与未推荐对象不匹配，本实施例主要采用这种相似度计算方式，来确定候选召回对象与未推荐对象是否匹配，但并不局限于这种方式，且本申请对候选召回对象与未推荐对象之间的相似度计算方法不做限定。

步骤s34，剔除与任一上一次的未推荐对象的相似度达到相似阈值的候选召回对象，并记录被剔除的候选召回对象的剔除数量；

其中，相似阈值可以通过经验或大量试验确定，本申请对其具体数值不做限定。

可选的，本申请也可以基于步骤s33的相似度计算结果，直接选择相似度未达到相似阈值的候选召回对象，并计算选择出的候选召回对象与获取的候选召回对象的差值，即剔除掉的候选召回对象的剔除数量，由此得知需要补充的召回对象数量。

步骤s35，基于第二召回逻辑，从至少一个应用平台中的待召回对象中，获取相同剔除数量的新的候选召回对象；

本申请实际应用中，每一次执行推荐对象获取方法，获取候选召回对象所采用的召回逻辑可以相同，也可以不同，本申请为了方便描述，将本次获取候选召回对象所采用的召回逻辑记为第一召回逻辑，并将补充获取新的候选召回对象所采用的召回逻辑记为第二召回逻辑。所以说，该第二召回逻辑与第一召回逻辑可以相同，也可以不同。

其中，若第二召回逻辑与第一召回逻辑不同，该第二召回逻辑也可以包括上文列举的其他一种或多种召回逻辑，基于该第二召回逻辑，从大量待召回对象中，获取新的候选召回对象的过程与上述步骤s31类似，本申请不做详述。

步骤s36，将剔除剩余的候选召回对象及该新的候选召回对象作为本次召回对象；

结合上文实施例的描述，本实施例从大量待召回对象中，粗略筛选出候选召回对象后，剔除了该候选召回对象中与数据库存储的上一次的未推荐对象相匹配的候选召回对象，即剔除了候选召回对象中质量较差的对象，此时，本实施例又召回了一些新的候选召回对象进行补充，使得更多的长尾对象能够得到召回的机会，防止质量差的对象持续占用资源，提高了各路召回的召回质量，且提高了召回对象的准确率和覆盖率。

步骤s37，获取本次召回对象各自的预测点击率；

步骤s38，按照预测点击率从大到小的顺序，对相应的本次召回对象进行排序；

步骤s39，基于排序结果，筛选预测点击率较大的第一数量个本次召回对象确定为推荐对象，并筛选预测点击率较小的第二数量个本次召回对象确定为未推荐对象；

关于步骤s37～步骤s39的实现过程，可以参照上述步骤s13～步骤s15相应部分的描述，本实施例不再赘述。

需要说明，本申请对第一数量和第二数量的具体数值不做限定，可以根据推荐效果进行灵活调整。

步骤s310，利用本次筛选出的未推荐对象，更新数据库存储的未推荐对象。

关于对数据库存储的未推荐对象的更新方式，可以参照上文实施例相应部分的描述。

综上，在本实施例中，对于推荐系统中的召回阶段和排序阶段实现了双向交互，也就是说，召回阶段得到的召回对象发送至排序模块进行精排序，筛选出预测点击率较大的第一数量个推荐对象的同时，可以筛选出预测点击率较小的第二数量个未推荐对象，并将该未推荐对象用于后续推荐对象的获取流程，即在下一次获取推荐过程中，从大量待召回对象中筛选出候选召回对象后，可以将其中与该未推荐对象相似的候选召回对象剔除，并重新召回一些新的候选召回对象，经过这样处理，推荐系统能够及时察觉质量较差的候选召回对象，并将这些质量较差的候选召回对象剔除，不会持续占用资源，也给了其他待召回对象更多被召回的机会，减少了长尾对象的数量，提高了下一次召回的准确率和覆盖率。

作为本申请又一实施例，参照图7所示的又一种推荐对象获取方法的流程示意图，该方法可以是另一种细化实现方法，本实施例主要描述获取本次召回对象的过程，关于其他步骤，可以参照上述实施例相应步骤的描述，如图7所示，该方法可以包括：

步骤s41，读取数据库存储的上一次的未推荐对象；

步骤s42，利用读取的上一次的未推荐对象，调整第一召回逻辑；

本申请对步骤s42的实现方式不做限定，对于不同内容的第一召回逻辑，所采用的调整方式可以不同，本实施例不作详述。

步骤s43，利用调整后的第一召回逻辑，从至少一个应用平台中的待召回对象中，获取本次召回对象。

在本实施例中，召回逻辑可以是如何从大量数据中筛选少量数据的召回算法，如协同过滤算法、相似度算法等等，可以基于具体召回逻辑类型确定，本申请可以在进行对象召回前，利用数据库存储的未推荐对象，对召回算法进行优化，以使得实际召回的召回对象不会包含质量较差的对象，进而避免质量较差的对象对推荐资源的占用，提高召回的准确率和覆盖率。

基于上文各实施例描述的推荐对象获取方法，本申请以新闻推荐场景为例进行说明，即上述各实施例的对象可以是新闻文章、视频、图片等，现有的新闻推荐系统的结构如1所示，本申请的新闻推荐系统如图2所示的结构，即在现有新闻推荐系统的基础上，增加了排序模块对召回模块的反馈环节，从而更改了该推荐系统所实现的推荐对象获取方法，下面将以推荐新闻获取过程为例进行说明。

参照图8所示的推荐新闻获取方法的流程示意图，用户a通过客户端访问新闻应用服务器过程中，新闻应用服务器的新闻推荐系统，会获取向该用户a推送的推荐新闻，并将该推荐新闻反馈至用户a的客户端进行展示。

在获取推荐新闻过程中，新闻推荐系统可以通过兴趣召回、协同过滤、热点召回、地域召回、媒体召回等多路召回方式，从至少一个新闻应用平台中的大量新闻中，筛选出n个候选召回新闻，同时，新闻推荐系统还可以从redis数据库中读取用户a的未推荐新闻，即上一次向用户a推送推荐新闻过程中，从召回新闻中，筛选出的预测点击率较小的m个召回新闻，之后，可以从n个候选召回新闻中，剔除与未推荐新闻相似的w个候选召回新闻，并利用召回逻辑重新召回w个候选召回新闻进行补充。

经过上述处理，因新闻推荐系统中的排序模块对召回新闻的点击率预估的分数太低，而不会向用户推送的新闻将会及时被察觉，并被剔除掉，不会持续的占用推荐资源，也给其他新闻创造了更多被召回的机会，减少长尾文章的数量，提高了本次召回的准确率和覆盖率。还可以适当减少召回模块到排序模块的输出总量，减轻排序模块的压力，节省更多的计算资源。

本申请将本次召回的n个候选召回新闻中，剔除剩余的(n-w)个候选召回新闻，以及重新召回补充的w个新的候选召回新闻，作为本次召回新闻，发送至新闻推荐系统的排序模块做进一步精筛选，即对本次召回新闻进行ctr预估，得到本次召回新闻各自对应的点击率预测分数，由该点击率预测分数估量对应召回新闻给用户展示后，将会被用户点击的概率，之后，可以根据本次召回新闻各自对应的点击率预测分数进行排序，选择排序靠前的点击率预测分数较大的k篇召回新闻为推荐新闻，并将该推荐新闻发送至打散模块进行排序处理后，推送至用户a的客户端，与此同时，本申请还可以将排序靠后的点击率预测分数较小的m个候选召回新闻(即)写入redis数据库，更新redis数据库已存储的未推荐新闻，m的具体数值可以根据线上的推荐效果进行调整。

这样，新闻推荐系统在下一次召回新闻的过程中，可以按照上文描述的放肆，先从redis数据库读取排名靠后的未推荐新闻，进而利用该未推荐新闻，对下一次召回的候选召回新闻进行筛选，得到下一次召回的目标召回新闻，以进行后续点击率预测分数计算及排名，进而得到下一次向用户推送的推荐新闻。

需要说明，在上文描述的推荐新闻获取过程中，本申请利用候选召回新闻的预测点击率的数值，来表示该候选召回新闻的点击率预测分数，当然，也可以采用其他方式表示，本申请对此不作限定。

另外，关于排序模块筛选出的未推荐新闻，可以采用redis存储方式，将其存储到redis数据库中，也可以采用缓存等其他存储方式，实现对未推荐新闻的存储，并不局限于上文描述的存储方式。

且，关于本申请提出的推荐对象获取方法，并不局限适用于本实施例描述的新闻推荐场景，还可以适用于其他推荐场景，实现过程类似，本申请不再一一详述。

可见，对于redis数据库存储的未推荐新闻，可以随着推荐新闻获取次数的更新而更新，具体更新方法不作限定，

可选的，参照图9所示的推荐新闻获取方法的流程示意图，本申请还可以从数据库中读取到未推荐新闻后，直接利用该未推荐新闻对召回模块的召回逻辑进行调整，之后，利用调整后的召回逻辑，从大量待召回新闻中，筛选出本次召回的召回新闻，使得该召回新闻中不会存在质量较差的新闻，避免了质量较差的召回新闻对推荐资源的占用，关于后续从召回新闻中得到推荐新闻和未推荐新闻的过程，可以参照上文实施例相应部分的描述，本实施例不再赘述。

可见，本实施例提供的这种召回逻辑调整方法，也能够避免质量较差的召回新闻对推荐资源的占用，提高召回的准确性及覆盖性，进而提高推荐准确性。

参照图10，为本申请实施例提供的一种推荐对象获取装置的结构示意图，该装置可以应用于应用服务器，如图10所示，该装置可以包括：

未推荐对象获取模块21，用于获取上一次的未推荐对象，所述上一次的未推荐对象是上一次获取推荐对象期间，筛选出的未被推送至用户客户端的召回对象；

召回对象获取模块22，用于依据第一召回逻辑及所述上一次的未推荐对象，得到本次召回对象；

预测点击率获取模块23，用于获取所述本次召回对象各自的预测点击率；

推荐对象筛选模块24，用于按照所述预测点击率大小，从所述本次召回对象中筛选出推送至所述用户客户端的推荐对象。

可选的，如图11所示，该装置还可以包括：

未推荐对象筛选模块25，用于在推荐对象筛选模块24按照所述预测点击率大小，从所述本次召回对象中筛选出推送至所述用户客户端的推荐对象的同时，从所述本次召回对象中筛选出未推荐对象；

更新模块26，用于利用本次筛选出的未推荐对象，更新上一次筛选出的未推荐对象。

作为本申请另一可选实施例，如图12所示，上述召回对象获取模块22可以包括：

第一召回单元221，用于依据第一召回逻辑，从至少一个应用平台中的待召回对象中，获取候选召回对象；

第一筛选单元222，用于从所述候选召回对象中，筛选与所述上一次的未推荐对象不匹配的召回对象作为本次召回对象；

第一剔除单元223，用于从所述候选召回对象中，剔除与所述上一次的未推荐对象匹配的召回对象。

可选的，该第一筛选单元222具体可以包括：

相似度获取单元，用于获取所述候选召回对象与上一次的未推荐对象的相似度；

第二剔除单元，用于剔除与任一上一次的未推荐对象的相似度达到相似阈值的候选召回对象，并记录被剔除的候选召回对象的剔除数量；

召回补充单元，用于基于第二召回逻辑，从至少一个应用平台中的待召回对象中，获取相同剔除数量的新的候选召回对象；

召回对象确定单元，用于将剔除剩余的候选召回对象及所述新的候选召回对象作为本次召回对象。

作为本申请又一可选实施例，上述召回对象获取模块22也可以包括：

召回逻辑调整单元，用于利用获取的所述上一次的未推荐对象，调整第一召回逻辑；

第二召回单元，用于利用调整后的第一召回逻辑，从至少一个应用平台中的待召回对象中，获取本次召回对象。

需要说明，关于上文实施例描述的对本次召回对象的获取过程，可以参照上述方法实施例相应部分的描述。

在上述各实施例的基础上，上述推荐对象筛选模块24可以包括：

排序单元，用于按照预测点击率从大到小的顺序，对相应的本次召回对象进行排序；

第二筛选单元，用于基于排序结果，筛选预测点击率较大的第一数量个本次召回对象确定为推荐对象，并筛选预测点击率较小的第二数量个本次召回对象确定为未推荐对象。

可选的，该装置还可以包括：

存储模块，用于将筛选出的未推荐对象存储至键值数据库。

在本申请实际应用中，若将推荐系统划分为召回模块、排序模块和打散模块这几大部分，分别表示获取推荐对象的不同处理阶段，那么，上述未推荐对象获取模块21和召回对象获取模块22可以是在召回模块所属的召回阶段执行，预测点击率获取模块23、推荐对象筛选模块24、未推荐对象筛选模块25和更新模块26可以在排序模块对应的精筛选阶段执行，具体执行过程，可以参照上文方法实施例相应部分的描述，本实施例不再赘述。

综上，本申请提出的推荐对象获取方法，通过增加排序模块向召回模块的反馈环节，以使得两者之间能够双向交互，利用上一次得到的质量较差的未推荐对象，来获得本次召回对象，使得本次召回对象不会包含质量较差的召回对象，避免了质量较差的召回对象对推荐资源的占用，影响其他待召回对象的曝光概率，在一定程度上节省了计算资源，提高了推荐准确性。

本申请实施例还提供了一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行，实现上述对象推荐方法的各步骤，该推荐对象获取方法的实现过程可以参照上述方法实施例的描述。

如图13所示，本申请实施例还提供了一种应用服务器的硬件结构示意图，该应用服务器可以是实现上述对象推荐方法的应用服务器，可以包括通信接口31、存储器32和处理器33；

在本申请实施例中，通信接口31、存储器32和处理器33可以通过通信总线实现相互间的通信，且该通信接口31、存储器32、处理器33及通信总线的数量可以为至少一个。

可选的，通信接口31可以为通信模块的接口，如gsm模块的接口等，用来接收客户端发起的访问请求，向用户客户端反馈推荐对象，还可以用来实现内容数据传输等。

处理器33可能是一个中央处理器cpu，或者是特定集成电路asic(applicationspecificintegratedcircuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。

存储器32可能包含高速ram存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

其中，存储器32存储有程序，处理器33调用存储器32所存储的程序，以实现上述应用于计算机设备的推荐对象获取方法的各步骤，具体实现过程可以参照上述方法实施例相应部分的描述，本实施例不再赘述。

本申请实施例还提供了一种推荐对象获取系统，参照上图3所示的系统结构示意图，该系统可以包括应用服务器、存储服务器及客户端，各部分的功能实现过程，可以参照上述系统实施例相应部分的描述，本实施例不再赘述，且该应用服务器的组成结构，可以参照上述应用服务器实施例的描述。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、应用服务器而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的核心思想或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。