CN110750709A - 一种服务推荐方法及装置 - Google Patents

Abstract

本申请提供了一种服务推荐方法及装置，其中，该方法包括：在接收到来自服务请求端的服务请求后，基于所述服务请求，确定至少一个备选服务；基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务；指示所述服务请求端与所述服务请求端匹配的备选服务的信息。采用上述方式，可以结合每个备选服务的特征信息以及用户对每个备选服务的历史操作信息来个性化地为用户推荐匹配的备选服务，因此能够更贴合不同用户的服务请求，使得推荐的备选服务更容易被用户接受。

Description

一种服务推荐方法及装置

技术领域

本申请涉及互联网技术领域，具体而言，涉及一种服务推荐方法及装置。

背景技术

随着互联网的快速发展和普及，各类互联网产品也层出不穷，例如购物应用、打车应用等。以打车应用为例，打车应用提供的乘车服务有多种，例如按照车型的不同，可以分为出租车、快车、优享车等，按照服务类型的不同，还可以分为单独约车、以及与其它乘客拼车等。

目前，当用户使用终端中安装的打车应用时，可以选择一种乘车服务并发起服务请求，之后，服务器在分配能够应答该服务请求的司机的过程中，如果等待应答的时间较长，服务器可以向终端推荐可供用户选择的其它乘车服务，以使用户通过改变或转换乘车服务来更快地得到应答。但是，由于乘车服务分为很多种，服务器将这些乘车服务都推荐给用户时，用户还需从众多乘车服务中去筛选符合当前乘车需求的一项乘车服务，一方面选择过程会花费较多时间成本，另一方面对于用户之前不了解的一些乘车服务，用户也很难准确地选择出符合当前需求的乘车服务，使得推荐效果较差。

发明内容

有鉴于此，本申请实施例的目的在于提供一种服务推荐方法及装置，以更好地适应不同用户实际的服务需求，优化推荐效果。

第一方面，本申请提供一种服务推荐方法，包括：

在接收到来自服务请求端的服务请求后，基于所述服务请求，确定至少一个备选服务；

基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务；

指示所述服务请求端与所述服务请求端匹配的备选服务的信息。

本申请的一实施例中，所述基于所述服务请求，确定至少一个备选服务，包括：

确定应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数；

当所述第一预估等待时长超出第一设定时长，和/或，所述第一预估等待人数超出第一设定人数时，确定所述至少一个备选服务。

本申请的一实施例中，所述基于所述服务请求，确定至少一个备选服务，包括：

确定应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数；以及，

确定预设服务集合中应答每一种服务对应的第二预估等待时长和/或第二预估等待人数；

将所述预设服务集合中所述第二预估等待时长低于所述第一预估等待时长的服务确定为所述至少一个备选服务，或者，将所述预设服务集合中所述第二预估等待人数低于所述第一预估等待人数的服务确定为所述至少一个备选服务。

本申请的一实施例中，每个备选服务的特征信息包括以下信息中的至少一种：

应答每个备选服务的预估等待时长和/或预估等待人数；

每个备选服务在单位时间段内被不同服务提供端应答的整体应答率；

每个备选服务在第一预设历史时间段内被不同服务请求端接受的整体接受率；

每个备选服务的支付费用；

每个备选服务与所述服务请求所请求的服务之间的支付费用差额；

每个备选服务所花费的会员积分；

每个备选服务与所述服务请求所请求的服务之间的服务体验分数差额。

本申请的一实施例中，每个备选服务的历史操作信息包括以下信息中的至少一种：

所述服务请求端在第二预设历史时间段内选择每个备选服务的历史次数；

所述服务请求端在所述第二预设历史时间段内接受推荐的每个备选服务的历史接受率。

本申请的一实施例中，所述基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务，包括：

基于所述每个备选服务的特征信息、以及所述每个备选服务的历史操作信息，对所述至少一个备选服务进行排序；

基于得到的排序结果，确定所述与所述服务请求端匹配的备选服务。

本申请的一实施例中，所述基于所述每个备选服务的特征信息、以及所述每个备选服务的历史操作信息，对所述至少一个备选服务进行排序，包括：

为所述每个备选服务的特征信息中每种特征信息设置第一评价分数以及第一权重，以及，为所述每个备选服务的历史操作信息中每种历史操作信息设置第二评价分数以及第二权重；

针对所述每个备选服务，基于所述每种特征信息对应的第一评价分数和第一权重、以及每种历史操作信息对应的第二评价分数和第二权重，计算每个备选服务的评价分数总和；

按照所述每个备选服务的评价分数总和由大到小的顺序，对所述至少一个备选服务进行排序。

本申请的一实施例中，所述基于得到的排序结果，确定与所述服务请求端匹配的备选服务，包括：

将排列在前N位的备选服务，确定为所述与所述服务请求端匹配的备选服务，其中，N为正整数。

本申请的一实施例中，所述指示所述服务请求端与所述服务请求端匹配的备选服务的信息，包括：

指示所述服务请求端按照所述排序结果展示所述与所述服务请求端匹配的备选服务的信息。

本申请的一实施例中，在指示所述服务请求端与所述服务请求端匹配的备选服务的信息之后，所述方法还包括：

基于应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数，指示所述服务请求端更改所述与所述服务请求端匹配的备选服务的信息的展示方式。

本申请的一实施例中，所述基于应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数，指示所述服务请求端更改所述与所述服务请求端匹配的备选服务的信息的展示方式，包括：

当所述第一预估等待时长超出第二设定时长，和/或，所述第一预估等待人数超出第二设定次数时，指示所述服务请求端高亮展示所述与所述服务请求端匹配的备选服务的信息。

本申请的一实施例中，在指示所述服务请求端所述与所述服务请求端匹配的备选服务的信息之后，所述方法还包括：

当检测到所述与所述服务请求端匹配的备选服务发生更新后，每隔预设时长，指示所述服务请求端对展示的与所述服务请求端匹配的备选服务的信息进行更新。

第二方面，本申请提供一种服务推荐装置，包括：

接收模块，用于接收来自服务请求端的服务请求；

第一确定模块，用于基于所述服务请求，确定至少一个备选服务；

第二确定模块，用于基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务；

指示模块，用于指示所述服务请求端与所述服务请求端匹配的备选服务的信息。

本申请的一实施例中，所述第一确定模块，在基于所述服务请求，确定至少一个备选服务时，具体用于：

确定应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数；

当所述第一预估等待时长超出第一设定时长，和/或，所述第一预估等待人数超出第一设定人数时，确定所述至少一个备选服务。

本申请的一实施例中，所述第一确定模块，在基于所述服务请求，确定至少一个备选服务时，具体用于：

确定应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数；以及，

确定预设服务集合中应答每一种服务对应的第二预估等待时长和/或第二预估等待人数；

将所述预设服务集合中所述第二预估等待时长低于所述第一预估等待时长的服务确定为所述至少一个备选服务，或者，将所述预设服务集合中所述第二预估等待人数低于所述第一预估等待人数的服务确定为所述至少一个备选服务。

本申请的一实施例中，每个备选服务的特征信息包括以下信息中的至少一种：

应答每个备选服务的预估等待时长和/或预估等待人数；

每个备选服务在单位时间段内被不同服务提供端应答的整体应答率；

每个备选服务在第一预设历史时间段内被不同服务请求端接受的整体接受率；

每个备选服务的支付费用；

每个备选服务与所述服务请求所请求的服务之间的支付费用差额；

每个备选服务所花费的会员积分；

每个备选服务与所述服务请求所请求的服务之间的服务体验分数差额。

本申请的一实施例中，每个备选服务的历史操作信息包括以下信息中的至少一种：

所述服务请求端在第二预设历史时间段内选择每个备选服务的历史次数；

所述服务请求端在所述第二预设历史时间段内接受推荐的每个备选服务的历史接受率。

本申请的一实施例中，所述第二确定模块，在基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务时，具体用于：

基于所述每个备选服务的特征信息、以及所述每个备选服务的历史操作信息，对所述至少一个备选服务进行排序；

基于得到的排序结果，确定所述与所述服务请求端匹配的备选服务。

本申请的一实施例中，所述第二确定模块，在基于所述每个备选服务的特征信息、以及所述每个备选服务的历史操作信息，对所述至少一个备选服务进行排序时，具体用于：

为所述每个备选服务的特征信息中每种特征信息设置第一评价分数以及第一权重，以及，为所述每个备选服务的历史操作信息中每种历史操作信息设置第二评价分数以及第二权重；

针对所述每个备选服务，基于所述每种特征信息对应的第一评价分数和第一权重、以及每种历史操作信息对应的第二评价分数和第二权重，计算每个备选服务的评价分数总和；

按照所述每个备选服务的评价分数总和由大到小的顺序，对所述至少一个备选服务进行排序。

本申请的一实施例中，所述第二确定模块，在基于得到的排序结果，确定与所述服务请求端匹配的备选服务时，具体用于：

将排列在前N位的备选服务，确定为所述与所述服务请求端匹配的备选服务，其中，N为正整数。

本申请的一实施例中，所述指示模块，在指示所述服务请求端与所述服务请求端匹配的备选服务的信息时，具体用于：

指示所述服务请求端按照所述排序结果展示所述与所述服务请求端匹配的备选服务的信息。

本申请的一实施例中，所述指示模块，还用于：

在指示所述服务请求端与所述服务请求端匹配的备选服务的信息之后，基于应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数，指示所述服务请求端更改所述与所述服务请求端匹配的备选服务的信息的展示方式。

本申请的一实施例中，所述指示模块，在指示所述服务请求端更改所述与所述服务请求端匹配的备选服务的信息的展示方式时，具体用于：

当所述第一预估等待时长超出第二设定时长，和/或，所述第一预估等待人数超出第二设定次数时，指示所述服务请求端高亮展示所述与所述服务请求端匹配的备选服务的信息。

本申请的一实施例中，所述指示模块，还用于：

在指示所述服务请求端所述与所述服务请求端匹配的备选服务的信息之后，当检测到所述与所述服务请求端匹配的备选服务发生更新后，每隔预设时长，指示所述服务请求端对展示的与所述服务请求端匹配的备选服务的信息进行更新。

其中，上述各模块的功能可以参照上述第一方面中所涉及的说明，这里不再展开说明。

第三方面，本申请还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面所述的服务推荐方法的步骤。

第四方面，本申请还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面所述的服务推荐方法的步骤。

本申请实施例中，在接收到来自服务请求端的服务请求后，可以基于服务请求，确定至少一个备选服务，在为服务请求端推荐备选服务时，可以结合每个备选服务的特征信息以及服务请求端对每个备选服务的历史操作信息来个性化地为服务请求端推荐相匹配的备选服务。通过上述推荐方式能够更贴合不同服务请求端的服务请求，一方面节省时间成本，另一方面也使得推荐给服务请求端的备选服务更容易被服务请求端接受，达到优化推荐效果的目的。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请的一些实施例的服务系统100的框图；

图2示出了本申请的一些实施例的电子设备200的示例性硬件和软件组件的示意图；

图3示出了本申请实施例提供的一种服务推荐方法的流程示意图；

图4示出了本申请实施例提供的另一种服务推荐方法的流程示意图；

图5示出了本申请实施例提供的对至少一个备选服务进行排序的流程示意图；

图6示出了本申请实施例提供的服务请求端的展示效果图一；

图7示出了本申请实施例提供的服务请求端的展示效果图二；

图8示出了本申请实施例提供的一种服务推荐装置的结构示意图；

图9示出了本申请实施例提供的计算机设备90的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“用户请求某种服务时服务器向用户推荐备选服务”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕打车服务系统进行描述，但是应该理解，这仅是一个示例性实施例。本申请可以应用于任何其他交通运输类型的服务系统。例如，本申请可以应用于不同的运输系统环境，包括陆地，海洋，或航空等，或其任意组合。运输系统的交通工具可以包括出租车、私家车、顺风车、公共汽车、火车、子弹头列车、高速铁路、地铁、船只、飞机、宇宙飞船、热气球、或无人驾驶车辆等，或其任意组合。本申请还可以包括能够在用户请求某种服务时向用户推荐备选服务的任何服务系统，例如，网上购物平台中向用户推荐备选服务的系统、网上订餐平台中向用户推荐备选服务的系统等。本申请的系统或方法的应用可以包括网页、浏览器的插件、客户端、定制系统、内部分析系统、或人工智能机器人等，或其任意组合。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

本申请中的术语“乘客”、“请求方”、“服务请求方”可互换使用，以指代可以请求或订购服务的个人、实体或工具。本申请中的术语“司机”、“提供方”、“服务提供方”可互换使用，以指代可以提供服务的个人、实体或工具。本申请中的术语“用户”可以指代请求服务、订购服务、提供服务或促成服务的提供的个人、实体或工具。例如，用户可以是乘客、司机、操作员等，或其任意组合。在本申请的一些实施例中，“服务请求端”和“服务请求方终端”可以互换使用，“服务提供端”和“服务提供方终端”可以互换使用。

本申请的一个方面涉及一种服务系统。该系统在接收到来自用户的服务请求后，在为用户推荐备选服务时，可以基于每个备选服务的特征信息以及服务请求端对每个备选服务的历史操作信息，来个性化地为每个用户推荐匹配的备选服务。

值得注意的是，在本申请提出之前，目前服务系统在为用户推荐备选服务的过程中，一般都是采用预先配置的方式，将预先配置的能够供用户选择的备选服务推荐给用户，但是，由于备选服务一般有很多种，服务系统将这些备选服务都推荐给用户时，用户还需从众多备选服务中去筛选符合当前服务需求的一项备选服务，一方面选择过程会花费较多时间成本，另一方面对于用户之前不了解的一些备选服务，用户也很难准确地选择出符合当前需求的备选服务。因此，这种推荐方式很难适应不同用户实际的服务需求，使得推荐效果较差。

而本申请中，可以结合每个备选服务的特征信息以及用户对每个备选服务的历史操作信息来个性化地为用户推荐匹配的备选服务，因此本申请提供的推荐方式能够更贴合不同用户的服务请求，推荐的备选服务更容易被用户接受。

图1是本申请一些实施例的服务系统100的框图。例如，服务系统100可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。服务系统100可以包括服务器110、网络120、服务请求方终端130、服务提供方终端140和数据库150中的一种或多种，服务器110中可以包括执行指令操作的处理器。

在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式系统)。在一些实施例中，服务器110相对于终端，可以是本地的、也可以是远程的。例如，服务器110可以经由网络120访问存储在服务请求方终端130、服务提供方终端140、或数据库150、或其任意组合中的信息和/或数据。作为另一示例，服务器110可以直接连接到服务请求方终端130、服务提供方终端140和数据库150中至少一个，以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实现；仅作为示例，云平台可以包括私有云、公有云、混合云、社区云(community cloud)、分布式云、跨云(inter-cloud)、多云(multi-cloud)等，或者它们的任意组合。在一些实施例中，服务器110可以在具有本申请中图2所示的一个或多个组件的电子设备200上实现。

在一些实施例中，电子设备200可以包括处理器220。处理器220可以处理与服务请求有关的信息和/或数据，以执行本申请中描述的一个或多个功能。例如，处理器220可以基于从服务请求方终端130获得的会话请求，与服务请求方终端130建立会话连接等。在一些实施例中，处理器220可以包括一个或多个处理核(例如，单核处理器(S)或多核处理器(S))。仅作为举例，处理器220可以包括中央处理单元(Central Processing Unit,CPU)、专用集成电路(Application Specific Integrated Circuit,ASIC)、专用指令集处理器(Application Specific Instruction-set Processor,ASIP)、图形处理单元(GraphicsProcessing Unit,GPU)、物理处理单元(Physics Processing Unit,PPU)、数字信号处理器(Digital Signal Processor,DSP)、现场可编程门阵列(Field Programmable GateArray,FPGA)、可编程逻辑器件(Programmable Logic Device,PLD)、控制器、微控制器单元、简化指令集计算机(Reduced Instruction Set Computing,RISC)、或微处理器等，或其任意组合。

网络120可以用于信息和/或数据的交换。在一些实施例中，服务系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140和数据库150)可以向其他组件发送信息和/或数据。例如，服务器110可以经由网络120从服务请求方终端130获取服务请求。在一些实施例中，网络120可以是任何类型的有线或者无线网络，或者是他们的结合。仅作为示例，网络130可以包括有线网络、无线网络、光纤网络、远程通信网络、内联网、因特网、局域网(Local Area Network，LAN)、广域网(Wide Area Network，WAN)、无线局域网(Wireless Local Area Networks，WLAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、公共电话交换网(Public Switched TelephoneNetwork，PSTN)、蓝牙网络、ZigBee网络、或近场通信(Near Field Communication，NFC)网络等，或其任意组合。在一些实施例中，网络120可以包括一个或多个网络接入点。例如，网络120可以包括有线或无线网络接入点，例如基站和/或网络交换节点，服务系统100的一个或多个组件可以通过该接入点连接到网络120以交换数据和/或信息。

在一些实施例中，服务请求方终端130的用户可以是服务实际需求者，也可以是除服务实际需求者之外的其他人。例如，服务请求方终端130的用户A可以使用服务请求方终端130来为服务实际需求者B发起服务请求(比如，用户A可以为自己的朋友B叫车)，或者从服务器110接收服务信息或指令等。在一些实施例中，服务提供方终端140的用户可以是服务实际提供者，也可以是除服务实际提供者之外的其他人。例如，服务提供方终端140的用户C可以使用服务提供方终端140接收由服务实际提供者D提供服务的服务请求(比如用户C可以为自己雇用的司机D接单)，和/或来自服务器110的信息或指令。

在一些实施例中，服务请求方终端130可以包括移动设备、平板计算机、膝上型计算机、或机动车辆中的内置设备等，或其任意组合。在一些实施例中，移动设备可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器设备的控制设备、智能监控设备、智能电视、智能摄像机、或对讲机等，或其任意组合。在一些实施例中，可穿戴设备可包括智能手环、智能鞋带、智能玻璃、智能头盔、智能手表、智能服装、智能背包、智能配件等、或其任何组合。在一些实施例中，智能移动设备可以包括智能手机、个人数字助理(Personal Digital Assistant，PDA)、游戏设备、导航设备、或销售点(point of sale，POS)设备等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实玻璃、虚拟现实贴片、增强现实头盔、增强现实玻璃、或增强现实贴片等，或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括各种虚拟现实产品等。在一些实施例中，机动车辆中的内置设备可以包括车载计算机、车载电视等。在一些实施例中，服务请求方终端130可以是具有用于定位服务请求方和/或服务请求方终端的位置的定位技术的设备。

在一些实施例中，服务提供方终端140可以是与服务请求方终端130类似或相同的设备。在一些实施例中，服务提供方终端140可以是具有定位技术的设备，用于定位服务提供方和/或服务提供方终端的位置。在一些实施例中，服务请求方终端130和/或服务提供方终端140可以与其他定位设备通信以确定服务请求方、服务请求方终端130、服务提供方、或服务提供方终端140、或其任意组合的位置。在一些实施例中，服务请求方终端130和/或服务提供方终端140可以将定位信息发送给服务器110。

数据库150可以存储数据和/或指令。在一些实施例中，数据库150可以存储从服务请求方终端130和/或服务提供方终端140获得的数据。在一些实施例中，数据库150可以存储在本申请中描述的示例性方法的数据和/或指令。在一些实施例中，数据库150可以包括大容量存储器、可移动存储器、易失性读写存储器、或只读存储器(Read-Only Memory,ROM)等，或其任意组合。作为举例，大容量存储器可以包括磁盘、光盘、固态驱动器等；可移动存储器可包括闪存驱动器、软盘、光盘、存储卡、zip磁盘、磁带等；易失性读写存储器可以包括随机存取存储器(Random Access Memory,RAM)；RAM可以包括动态RAM(Dynamic RandomAccess Memory,DRAM)，双倍数据速率同步动态RAM(Double Date-Rate Synchronous RAM,DDR SDRAM)；静态RAM(Static Random-Access Memory,SRAM)，晶闸管RAM(Thyristor-Based Random Access Memory,T-RAM)和零电容器RAM(Zero-RAM)等。作为举例，ROM可以包括掩模ROM(Mask Read-Only Memory,MROM)、可编程ROM(Programmable Read-OnlyMemory,PROM)、可擦除可编程ROM(Programmable Erasable Read-only Memory,PEROM)、电可擦除可编程ROM(Electrically Erasable Programmable read only memory,EEPROM)、光盘ROM(CD-ROM)、以及数字通用磁盘ROM等。在一些实施例中，数据库150可以在云平台上实现。仅作为示例，云平台可以包括私有云、公有云、混合云、社区云、分布式云、跨云、多云或者其它类似的等，或其任意组合。

在一些实施例中，数据库150可以连接到网络120以与服务系统100(例如，服务器110，服务请求方终端130，服务提供方终端140等)中的一个或多个组件通信。服务系统100中的一个或多个组件可以经由网络120访问存储在数据库150中的数据或指令。在一些实施例中，数据库150可以直接连接到服务系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140等)；或者，在一些实施例中，数据库150也可以是服务器110的一部分。

在一些实施例中，服务系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140等)可以具有访问数据库150的权限。在一些实施例中，当满足一定条件时，服务系统100中的一个或多个组件可以读取和/或修改与服务请求方、服务提供方、或公众、或其任意组合有关的信息。例如，服务器110可以在接收服务请求之后读取和/或修改一个或多个用户的信息。作为另一示例，服务提供方终端140可以在从服务请求方终端130接收服务请求时访问与服务请求方有关的信息，但是服务提供方终端140可以不修改服务请求方的相关信息。

在一些实施例中，可以通过请求服务来实现服务系统100中的一个或多个组件的信息交换。服务请求的对象可以是任何产品。在一些实施方案中，产品可以是有形产品或非物质产品。有形产品可包括食品、药品、商品、化学产品、电器、服装、汽车、房屋、或奢侈品等，或其任意组合。非物质产品可以包括服务产品、金融产品、知识产品、或互联网产品等，或其任意组合。互联网产品可以包括单独的主机产品、网络产品、移动互联网产品、商业主机产品、或嵌入式产品等，或其任意组合。互联网产品可以用在移动终端的软件、程序、或系统等，或者它们的任意组合中。移动终端可以包括平板电脑、笔记本电脑、移动电话、个人数字助理(Personal Digital Assistant，PDA)、智能手表、销售点(Point of sales，POS)设备、车载电脑、车载电视、或可穿戴设备等，或其任意组合。例如，互联网产品可以是计算机或移动电话中使用的任何软件和/或应用程序。软件和/或应用程序可以涉及社交、购物、运输、娱乐时间、学习、或投资等，或其任意组合。在一些实施例中，与运输有关的软件和/或应用程序可以包括旅行软件和/或应用程序、车辆调度软件和/或应用程序、绘图软件和/或应用程序等。在车辆调度软件和/或应用程序中，车辆可包括马、马车、人力车(例如，独轮车、自行车、三轮车等)、汽车(例如，出租车、公共汽车、私家车等)、火车、地铁、船只、飞机(例如，飞机、直升机、航天飞机、火箭、热气球等)等，或其任意组合。

图2示出根据本申请的一些实施例的可以实现本申请思想的服务器110、服务请求方终端130、服务提供方终端140的电子设备200的示例性硬件和软件组件的示意图。例如，处理器220可以用于电子设备200上，并且用于执行本申请中的功能。

电子设备200可以是通用计算机或特殊用途的计算机，两者都可以用于实现本申请的服务推荐方法。本申请尽管仅示出了一个计算机，但是为了方便起见，可以在多个类似平台上以分布式方式实现本申请描述的功能，以均衡处理负载。

例如，电子设备200可以包括连接到网络的网络端口210、用于执行程序指令的一个或多个处理器220、通信总线230、和不同形式的存储介质240，例如，磁盘、ROM、或RAM，或其任意组合。示例性地，计算机平台还可以包括存储在ROM、RAM、或其他类型的非暂时性存储介质、或其任意组合中的程序指令。根据这些程序指令可以实现本申请的方法。电子设备200还包括计算机与其他输入输出设备(例如键盘、显示屏)之间的输入/输出(Input/Output，I/O)接口250。

为了便于说明，在电子设备200中仅描述了一个处理器。然而，应当注意，本申请中的电子设备200还可以包括多个处理器，因此本申请中描述的一个处理器执行的步骤也可以由多个处理器联合执行或单独执行。例如，若电子设备200的处理器执行步骤A和步骤B，则应该理解，步骤A和步骤B也可以由两个不同的处理器共同执行或者在一个处理器中单独执行。例如，第一处理器执行步骤A，第二处理器执行步骤B，或者第一处理器和第二处理器共同执行步骤A和B。

结合上述对服务系统以及服务系统中各电子设备的描述，下面结合具体实施例，对本申请提供的服务推荐方法进行详细说明。

参照图3所示，为本申请实施例提供的一种服务推荐方法的流程示意图，该服务推荐方法可以由图1所述的服务系统中的服务器来执行，具体执行过程包括如下步骤：

步骤301、接收来自服务请求端的服务请求。

其中，在不同的应用场景下，服务请求端发送的服务请求有所区别，例如，在打车服务系统中，服务请求端为乘客使用的终端，服务提供端为司机使用的终端，那么，服务请求端的服务请求例如为请求某一种乘车服务的乘车订单请求等。

本申请的一些实施例中，服务器在接收到服务请求端的服务请求之后，可以为服务请求端分配能够应答上述服务请求的服务提供端。但是，考虑到有时候可能会因为供需关系比较紧张，使得服务器无法立即将服务请求分配到对应的服务提供端。例如，对于打车服务系统来说，在服务请求端发送服务请求，以请求某一种乘车服务之后，若服务器确定出能够应答该乘车服务的服务提供端目前都处于订单处理中，无法接受新的乘车订单，或者，当前区域在当前时间段内暂时没有能够应答该乘车服务的服务提供端，那么服务器可以向服务请求端指示在分配乘车订单的过程中需要等待的时间，以及需要等待的人数等。

步骤302、基于服务请求，确定至少一个备选服务。

本申请实施例中，服务器在确定出无法立即将服务请求分配到对应的服务提供端时，可以执行备选服务推荐流程，基于服务请求来确定至少一个可供服务请求端选择的备选服务，以便尽可能缩短服务请求端的等待时间，达到尽快响应服务需求的目的。

一种可能的实施方式中，服务器可以基于服务请求，首先确定应答服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数。

例如，以打车服务系统为例，若服务请求端发送的服务请求用于请求某一种乘车服务，例如乘坐出租车服务，那么服务器可以基于当前服务系统中能够应答该乘车服务的服务提供端的订单处理状态、服务提供端所处的地理位置、以及在服务器接收到服务请求之前已经等待应答同一乘车服务的服务请求端的个数，预估出应答上述服务请求所请求的服务的第一预估等待时长，也可以预估出应答上述服务请求所请求的服务的第一预估等待人数。

进一步地，当第一预估等待时长超出第一设定时长，和/或，第一预估等待人数超出第一设定人数时，服务器可以启动备选服务推荐流程，确定至少一个备选服务。

本申请实施例中，服务器在确定至少一个备选服务时，可以将预设备选服务集合中记录的每一种服务都作为备选服务，也可以基于一些筛选规则来从预设备选服务集合中筛选出符合筛选规则的服务，将这些符合筛选规则的服务作为备选服务。

这里，预设备选服务集合中记录的每一种服务的信息可以存储在图1所述服务系统中的数据库，预设备选集合中记录的每一种服务可以用一个服务标识来标识，并且可以对应记录每一种服务的描述信息、以及特征信息等。应理解，在不同的应用场景下，预设备选服务集合中记录的备选服务有所区别，关于记录的备选服务的具体示例将在后文中进行示例性说明，这里暂不介绍。

具体实施中，服务器可以按照以下方式中的一种或者多种，从预设备选服务集合中筛选出至少一个备选服务：

方式一、确定应答上述服务请求所请求的服务的第一预估等待时长，以及，确定预设服务集合中应答每一种服务对应的第二预估等待时长；从预设服务集合中选择第二预估等待时长低于第一预估等待时长的服务，将选择出的这些服务作为至少一个备选服务。

方式二、确定应答上述服务请求所请求的服务的第一预估等待人数，以及，确定预设服务集合中应答每一种服务对应的第二预估等待人数；从预设服务集合中选择第二预估等待人数低于第一预估等待人数的服务，将选择出的这些服务作为至少一个备选服务。

其中，预设服务集合中应答每一种服务对应的第二预估等待时长以及第二预估等待人数，可以基于服务系统中每一种服务的当前供需状况来确定，这里不再展示说明。本申请实施例中，通过选取第二预估等待时长低于第一预估等待时长的服务和/或第二预估等待人数低于第一预估等待人数的服务，作为备选服务，这样向服务请求端推荐的备选服务，可以有利于尽快响应服务请求端的服务请求。

步骤303、基于至少一个备选服务中每个备选服务的特征信息、以及服务请求端对每个备选服务的历史操作信息，确定与服务请求端匹配的备选服务。

本申请实施例中，在确定好至少一个备选服务之后，可以从图1所示的服务系统的数据库中获取每个备选服务的特征信息、以及服务请求端对每个备选服务的历史操作信息，然后再进一步分析哪些备选服务与服务请求端相匹配，其中，与服务请求端相匹配的备选服务推荐给服务请求端时，能够被服务请求端接受的可能性较大。

一种可能的实施方式中，服务器在确定与服务请求端匹配的备选服务的过程中，可以基于每个备选服务的特征信息、以及每个备选服务的历史操作信息，对至少一个备选服务进行排序，进而基于得到的排序结果确定与服务请求端匹配的备选服务。一示例中，可以将排列在前N位的备选服务确定为与服务请求端匹配的备选服务。

另一种可能的实施方式中，服务器在确定与服务请求端匹配的备选服务的过程中，也可以基于每个备选服务的特征信息、以及每个备选服务的历史操作信息，确定至少一个备选服务中每个备选服务被服务请求端接受的预估接受概率，进而基于得到的每个备选服务对应的预估接受概率，确定与服务请求端匹配的备选服务。一示例中，可以选择预估接受概率大于设定值的备选服务确定为与服务请求端匹配的备选服务。

上述两个实施方式中，确定与服务请求端匹配的备选服务的具体实施过程将在下文中进行详细说明。这里暂不详述。

步骤304、指示服务请求端与服务请求端匹配的备选服务的信息。

本申请实施例中，服务器指示给服务请求端的备选服务的信息例如包括以下信息中的一种或多种：备选服务的标识、备选服务的描述信息、备选服务的特征信息的全部特征信息或部分特征信息。通过将上述信息指示给服务请求端，使得服务请求端可以将备选服务的相关信息展示给乘客，以便乘客更好地了解每个备选服务的情况，有利于选择更符合服务需求的备选服务。

一种可能的实施方式中，服务器如果在检测到当前服务系统的供需状态发生变化时，还可以指示服务请求端改变备选服务的信息的展示方式。

本申请的一示例中，服务器可以基于应答服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数，指示服务请求端更改与服务请求端匹配的备选服务的信息的展示方式。例如，当第一预估等待时长超出第二设定时长，和/或，第一预估等待人数超出第二设定次数时，可以说明目前服务请求所请求的服务在当前状态下供需严重失衡，故服务器可以指示服务请求端高亮展示与服务请求端匹配的备选服务的信息，以提示服务请求端可以着重考虑下选择备选服务。其中，第二设定时长可以大于上述第一设定时长，第二设定次数可以大于上述第一设定次数。

另一种可能的实施方式中，由于备选服务集合中每一种服务对应的特征信息，以及服务请求端对每一种服务的历史操作信息可能会发生更新，故服务器也可以每隔一段时间判断下服务请求端匹配的备选服务是否需要更新。基于此，服务器在指示服务请求端与服务请求端匹配的备选服务的信息之后，当检测到与服务请求端匹配的备选服务发生更新后，还可以每隔预设时长，指示服务请求端对展示的与服务请求端匹配的备选服务的信息进行更新。

其中，需要说明的是，如果预设时长过短的话，可能使得服务请求端展示的备选服务的信息在展示时频繁切换，不太稳定，影响服务请求端选择备选服务。如果预设时长过长的话，可能会造成备选服务的信息的实时性较差，不能准确反映出当前每种备选服务的供需状态，同样也不利于服务请求端选择合适的备选服务。针对上述问题，在设定上述预设时长时可以综合考虑上述问题，选择一个恰当的时长。

上述实施例中，通过结合每个备选服务的特征信息以及服务请求端对每个备选服务的历史操作信息来个性化地为服务请求端推荐匹配的备选服务，能够更贴合不同服务请求端的服务请求，一方面节省时间成本，另一方面也使得推荐给服务请求端的备选服务更容易被服务请求端接受，优化推荐效果。

为便于对本申请上述实施例的理解，下面结合具体应用场景，对本申请实施例提供的上述服务推荐方法所涉及的内容进行说明。

参照图4所示，为本申请实施例提供的服务推荐方法的流程示意图。其中，以打车服务系统为应用场景、服务请求端为乘客使用的终端、服务请求为请求某种乘车服务、服务提供端为司机使用的终端为例，对服务推荐方法的交互流程进行介绍。

步骤401、接收来自服务请求端的服务请求，服务请求用于请求乘车服务。

步骤402、当应答该乘车服务的第一预估等待时长超出第一设定时长，和/或，应答该乘车服务的第一预估等待人数超出第一设定人数时，确定至少一个备选服务。

步骤403、基于每个备选服务的特征信息、以及每个备选服务的历史操作信息，对至少一个备选服务进行排序，基于得到的排序结果，确定与服务请求端匹配的备选服务。

步骤404、指示服务请求端按照排序结果展示与服务请求端匹配的备选服务的信息。

步骤405、当第一预估等待时长超出第二设定时长，和/或，第一预估等待人数超出第二设定次数时，指示服务请求端更改与服务请求端匹配的备选服务的信息的展示方式。

下面，对图4所示的交互流程中各步骤进行详细说明。

针对步骤402，在确定至少一个备选服务时，服务器可以从数据库中存储的预设备选服务集合中确定至少一个备选服务，具体确定方式可以参见图3所示的实施例中所涉及的内容。

一示例中，预设备选服务集合中记录的服务例如可以包括：同时呼叫更多车型的服务、司机打表来接驾的服务、优先分配订单的服务、自主加价的服务等。

其中，同时呼叫更多车型的服务，可以理解为在服务请求端请求了某种车型的乘车服务之后，还可以同时呼叫其它车型的乘车服务。例如，假设服务请求端请求了出租车服务之后，如果选择了同时呼叫更多车型的服务，那么可以同时呼叫出租车服务、以及除了出租车服务之外的其它车型的乘车服务，如快车服务、优享服务、以及拼车服务等。通过这种同时呼叫更多车型的服务，可以调用整个打车平台中的运力资源，以便更快地响应服务请求端所请求的服务。

司机打表来接驾的服务，也即加价调度远处车辆的服务，可以理解为在服务请求端请求了某种乘车服务之后，乘客需要有偿支付司机由当前所在位置驾驶到乘客所在位置这段路程的车费。通过这种司机打表来接的服务，可以扩大订单分配范围，进而可以调度距离乘客所在位置较远的司机来响应乘客的服务请求。

优先分配订单的服务，也即快速通道的服务，可以理解为在服务请求端请求了某种乘车服务之后，可以优先为该服务请求端分配能够应答乘车服务的服务提供端。这种优先分配订单的服务可以向核心乘客提供，核心乘客例如为已经在服务系统上注册会员的乘客，或者购买了优先分配订单的服务的乘客等。

自主加价的服务，可以理解为在服务请求端请求了某种乘车服务之后，除了支付该乘车服务对应的费用之外，还可以支付额外的费用，以促进司机尽快响应服务请求。

以上为对预设备选服务集合中记录的服务的示例性说明，实际应用中，可以根据实际需求来配置各类型的服务，本申请对此并不限定。

针对步骤403，服务器在对至少一个备选服务进行排序并确定与服务请求端匹配的备选服务时，可以基于图5所示的排序方式得到与服务请求端匹配的备选服务，具体参见以下流程：

步骤501、为每个备选服务的特征信息中每种特征信息设置第一评价分数以及第一权重，以及，为每个备选服务的历史操作信息中每种历史操作信息设置第二评价分数以及第二权重；

步骤502、针对每个备选服务，基于每种特征信息对应的第一评价分数和第一权重、以及每种历史操作信息对应的第二评价分数和第二权重，计算每个备选服务的评价分数总和；

步骤503、按照每个备选服务的评价分数总和由大到小的顺序，对至少一个备选服务进行排序。

步骤504、将排列在前N位的备选服务确定为与服务请求端匹配的备选服务，其中，N为正整数。

当然，实际应用中，也可以通过计算每个备选服务的预估接受概率，来确定与服务请求端匹配的备选服务。其中，可以采用与上述计算评价分数总和的方式相同的技术构思来计算预估接受概率，另外，实际应用时也可以根据机器学习的方式来确定预估接受概率，这里不再展开说明。

一示例中，假设某一备选服务中包括三种特征信息A、B、C，还对应有两种历史操作信息D、E。那么，进一步假设特征信息A对应的第一评价分数为70分、权重为0.1，特征信息B对应的第一评价分数为80分、权重为0.1，特征信息C对应的第一评价分数为90分、权重为0.2，历史操作信息D对应的第二评价分数为85分、权重为0.3，历史操作信息E对应的第二评价分数为90分、权重为0.3，那么可以计算出该备选服务的评价分数总和的计算方式为：70×0.1+80×0.1+90×0.2+85×0.3+90×0.3＝85.5。

其中，需要说明的是，在为每一种特征信息或每一种历史操作信息设定评价分数和权重时，可以将更符合服务请求端的服务需求或更容易被服务请求端接受的特征信息或历史操作信息对应的评价分数和权重设置的高一些，另外，由于服务请求端的历史操作信息更能反映出服务请求端的使用习惯，为了更贴合服务请求端的个性化需求，也可以将历史操作信息对应的评价分数和/或权重设置的高一些。当然，关于评价分数和权重的设定方式，也可以根据实际应用场景以及需求来适当的调整，本申请对此并不限定。

其中，针对打车服务系统来说，上述每个备选服务的特征信息例如包括以下信息中的至少一种：

(1)应答每个备选服务的预估等待时长和/或预估等待人数。

由于在同一时段内服务器可以接收到来自不同服务请求端发送的服务请求，可能存在不同服务请求端选择同一备选服务的情况，故为了能够让服务请求端选择更适合的备选服务，可以统计每个备选服务的供需状态，例如预估等待时长、预估等待人数等。例如，以同时呼叫更多车型的服务为例，可以预估出每一种车型的服务对应的预估等待时长和/或预估等待人数。

(2)每个备选服务在单位时间段内被不同服务提供端应答的整体应答率。

其中，单位时间段可以根据实际情况设定，例如每隔十分钟统计下每个备选服务被不同服务提供端应答的整体应答率。一示例中，整体应答率可以针对打车服务系统中全部服务提供端应答的备选服务的情况而统计出的，例如，可以根据十分钟内打车服务系统中全部服务提供端的应答总次数、以及应答每一种备选服务的总次数，来计算每个备选服务对应的整体应答率，根据计算出的每个备选服务对应的整体应答率，可以反映出每个备选服务的应答速度，整体应答率较高的，相对来说应答速度较高。

(3)每个备选服务在第一预设历史时间段内被不同服务请求端接受的整体接受率。

其中，第一预设历史时间段也可以根据实际情况设定，例如，统计每个备选服务在之前一个月内被不同服务请求端接收的整体接受率。一示例中，整体接受率也可以针对打车服务系统中全部服务请求端选择的备选服务的情况而统计出的，例如，可以根据一个月内打车服务系统中全部服务请求端的选择备选服务的总次数、以及每一种备选服务被选择的总次数，来计算每个备选服务对应的整体接受率，根据计算出的每个备选服务对应的整体接受率，可以反映出每个备选服务被服务请求端接受的可能性，整体接受率较高的，相对来说更容易被服务请求端接受。

(4)每个备选服务的支付费用。

对于一些需要支付费用的备选服务，可以记录这些备选服务需要服务请求端支付的支付费用。例如，以同时呼叫更多车型的服务为例，可以记录每一种车型的服务对应的支付费用。

(5)每个备选服务与服务请求所请求的服务之间的支付费用差额。

对于一些需要支付费用的备选服务，还可以记录这些备选服务与服务请求所请求的服务之间的支付费用差额。例如，以同时呼叫更多车型的服务为例，如果服务请求所请求的出租车服务对应的支付费用为20元，备选服务中呼叫快车的服务对应的支付费用为25元，呼叫优享汽车的服务对应的支付费用为30元，拼车服务对应的支付费用是15元，那么可以分别记录上述三种备选服务与出租车服务之间的支付费用差额为+5元、+10元、-5元。

(6)每个备选服务所花费的会员积分。

对于一些需要花费会员积分的备选服务，可以记录这些备选服务需要服务请求端花费的会员积分。例如，以优先分配订单的服务为例，可以记录优先分配订单的服务对应的会员积分为5积分。

(7)每个备选服务与服务请求所请求的服务之间的服务体验分数差额。

针对每个备选服务可以预先配置一个服务体验分数，例如，拼车服务的服务体验分数为70分、优享汽车的服务体验分数为90分、快车的服务体验分数为80分，而服务请求端所请求的出租车服务的服务体验分数为75分，那么可以以出租车服务的服务体验分数为基准，计算出上述三种备选服务与出租车服务之间服务体验分数差额分别为-5分、+25分、+5分。

其中，针对打车服务系统来说，上述每个备选服务的历史操作信息例如包括以下信息中的至少一种：

(1)服务请求端在第二预设历史时间段内选择每个备选服务的历史次数。

其中，第二预设历史时间段也可以根据实际情况设定，例如，统计服务请求端在在之前一个月内选择的每个备选服务的历史次数。通过统计每个备选服务的历史次数，可以推断出乘客对每一种备选服务的喜好程度，通过考虑喜好程度来推荐备选服务，可以使得推荐的备选服务能够更贴合用户需求。一示例中，服务请求端在之前一个月内选择了同时呼叫更多车型的服务的次数为10次，选择司机打表来接驾的服务的次数为5次，选择优先分配订单的服务的次数为5次，那么可以看出乘客更喜欢同时呼叫更多车型的服务，所以可以考虑优先推荐同时呼叫更多车型的服务。

(2)服务请求端在第二预设历史时间段内接受推荐的每个备选服务的历史接受率。

一示例中，每个备选服务的历史接受率可以根据在第二预设历史时间段内服务请求端选择各备选服务的历史总次数、以及选择每个备选服务的历史次数，来计算得到每个备选服务的历史接受率。当然，实际应用中还可以利用其它计算方式，这里不再展开说明。

针对步骤404，服务器在指示服务请求端按照排序结果展示与服务请求端匹配的备选服务的信息时，例如可以指示服务请求端以弹窗形式显示按照排序结果排列的备选服务的信息，或者，也可以指示服务请求端在当前显示的服务请求的派单状态的界面中，也显示出按照排序结果排列的备选服务的信息。可参照图6所示的服务请求端的展示效果图一，按照排序结果排列显示的备选服务的信息依次为“同时呼叫更多车型”、“加价调度远处车辆”、“快速通道”。其中，“同时呼叫更多车型”的显示框中还可以显示对应的描述信息(例如“可选拼车/优享/出租车等”)、对应的特征信息(例如“约等2分钟”)，“加价调度远处车辆”的显示框中也可以显示对应的描述信息(例如“最多10元/6.5公里内”)、对应的特征信息(例如“约等3分钟”)，“快速通道”的显示框中还可以显示对应的描述信息(“1888滴币兑换1次/当前账户共3000滴币”)、对应的特征信息(例如“约等5分钟”)。

针对步骤405，一示例中，当第一预估等待时长超出第二设定时长，和/或，第一预估等待人数超出第二设定次数时，服务器可以指示服务请求端更改与服务请求端匹配的备选服务的信息的展示方式。可参照图7所示的服务请求端的展示效果图二，可以指示服务请求端将“同时呼叫更多车型”的显示框高亮显示(如图7所示的阴影部分)，以提示乘客可以优先选择“同时呼叫更多车型”的服务。

通过上述实施例来个性化地为服务请求端推荐匹配的备选服务，能够更贴合不同服务请求端的服务请求，一方面节省时间成本，另一方面也使得推荐给服务请求端的备选服务更容易被服务请求端接受，优化推荐效果。

基于同一技术构思，本申请实施例中还提供了与服务推荐方法对应的服务推荐装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述服务推荐方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图8所示，为本申请实施例提供的一种服务推荐装置的结构示意图，所述装置80包括：

接收模块81，用于接收来自服务请求端的服务请求；

第一确定模块82，用于基于所述服务请求，确定至少一个备选服务；

第二确定模块83，用于基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务；

指示模块84，用于指示所述服务请求端与所述服务请求端匹配的备选服务的信息。

本申请的一实施例中，所述第一确定模块82，在基于所述服务请求，确定至少一个备选服务时，具体用于：

确定应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数；

当所述第一预估等待时长超出第一设定时长，和/或，所述第一预估等待人数超出第一设定人数时，确定所述至少一个备选服务。

本申请的一实施例中，所述第一确定模块82，在基于所述服务请求，确定至少一个备选服务时，具体用于：

确定应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数；以及，

确定预设服务集合中应答每一种服务对应的第二预估等待时长和/或第二预估等待人数；

将所述预设服务集合中所述第二预估等待时长低于所述第一预估等待时长的服务确定为所述至少一个备选服务，或者，将所述预设服务集合中所述第二预估等待人数低于所述第一预估等待人数的服务确定为所述至少一个备选服务。

本申请的一实施例中，每个备选服务的特征信息包括以下信息中的至少一种：

应答每个备选服务的预估等待时长和/或预估等待人数；

每个备选服务在单位时间段内被不同服务提供端应答的整体应答率；

每个备选服务在第一预设历史时间段内被不同服务请求端接受的整体接受率；

每个备选服务的支付费用；

每个备选服务与所述服务请求所请求的服务之间的支付费用差额；

每个备选服务所花费的会员积分；

每个备选服务与所述服务请求所请求的服务之间的服务体验分数差额。

本申请的一实施例中，每个备选服务的历史操作信息包括以下信息中的至少一种：

所述服务请求端在第二预设历史时间段内选择每个备选服务的历史次数；

所述服务请求端在所述第二预设历史时间段内接受推荐的每个备选服务的历史接受率。

本申请的一实施例中，所述第二确定模块83，在基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务时，具体用于：

基于所述每个备选服务的特征信息、以及所述每个备选服务的历史操作信息，对所述至少一个备选服务进行排序；

基于得到的排序结果，确定所述与所述服务请求端匹配的备选服务。

本申请的一实施例中，所述第二确定模块83，在基于所述每个备选服务的特征信息、以及所述每个备选服务的历史操作信息，对所述至少一个备选服务进行排序时，具体用于：

为所述每个备选服务的特征信息中每种特征信息设置第一评价分数以及第一权重，以及，为所述每个备选服务的历史操作信息中每种历史操作信息设置第二评价分数以及第二权重；

针对所述每个备选服务，基于所述每种特征信息对应的第一评价分数和第一权重、以及每种历史操作信息对应的第二评价分数和第二权重，计算每个备选服务的评价分数总和；

按照所述每个备选服务的评价分数总和由大到小的顺序，对所述至少一个备选服务进行排序。

本申请的一实施例中，所述第二确定模块83，在基于得到的排序结果，确定与所述服务请求端匹配的备选服务时，具体用于：

将排列在前N位的备选服务，确定为所述与所述服务请求端匹配的备选服务，其中，N为正整数。

本申请的一实施例中，所述指示模块84，在指示所述服务请求端与所述服务请求端匹配的备选服务的信息时，具体用于：

指示所述服务请求端按照所述排序结果展示所述与所述服务请求端匹配的备选服务的信息。

本申请的一实施例中，所述指示模块84，还用于：

在指示所述服务请求端与所述服务请求端匹配的备选服务的信息之后，基于应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数，指示所述服务请求端更改所述与所述服务请求端匹配的备选服务的信息的展示方式。

本申请的一实施例中，所述指示模块84，在指示所述服务请求端更改所述与所述服务请求端匹配的备选服务的信息的展示方式时，具体用于：

当所述第一预估等待时长超出第二设定时长，和/或，所述第一预估等待人数超出第二设定次数时，指示所述服务请求端高亮展示所述与所述服务请求端匹配的备选服务的信息。

本申请的一实施例中，所述指示模块84，还用于：

在指示所述服务请求端所述与所述服务请求端匹配的备选服务的信息之后，当检测到所述与所述服务请求端匹配的备选服务发生更新后，每隔预设时长，指示所述服务请求端对展示的与所述服务请求端匹配的备选服务的信息进行更新。

本申请实施例中，上述各模块的具体功能和交互方式，可参见上述方法实施例的记载，在此不再赘述。

基于相同的技术构思，本申请实施例还提供了一种计算机设备。参照图9所示，为本申请实施例提供的计算机设备90的结构示意图，包括处理器91、存储器92、和总线93。其中，存储器92用于存储执行指令，包括内存921和外部存储器922；这里的内存921也称内存储器，用于暂时存放处理器91中的运算数据，以及与硬盘等外部存储器922交换的数据，处理器91通过内存921与外部存储器922进行数据交换，当计算机设备90运行时，处理器91与存储器92之间通过总线93通信，使得处理器91在执行以下指令：

在接收到来自服务请求端的服务请求后，基于所述服务请求，确定至少一个备选服务；

基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务；

指示所述服务请求端与所述服务请求端匹配的备选服务的信息。

其中，处理器91的具体处理流程可以参照上述方法实施例的记载，这里不再赘述。

基于相同的技术构思，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述服务推荐方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述服务推荐方法，以更好地满足不同服务请求端的服务需求，减少等待时长，优化推荐效果。

基于相同的技术构思，本申请实施例还提供了一种计算机程序产品，包括存储了程序代码的计算机可读存储介质，程序代码包括的指令可用于执行上述服务推荐方法的步骤，具体实现可参见上述方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (26)

1.一种服务推荐方法，其特征在于，包括：

在接收到来自服务请求端的服务请求后，基于所述服务请求，确定至少一个备选服务；

基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务；

指示所述服务请求端与所述服务请求端匹配的备选服务的信息。

2.如权利要求1所述的方法，其特征在于，所述基于所述服务请求，确定至少一个备选服务，包括：

确定应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数；

当所述第一预估等待时长超出第一设定时长，和/或，所述第一预估等待人数超出第一设定人数时，确定所述至少一个备选服务。

3.如权利要求1或2所述的方法，其特征在于，所述基于所述服务请求，确定至少一个备选服务，包括：

确定应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数；以及，

确定预设服务集合中应答每一种服务对应的第二预估等待时长和/或第二预估等待人数；

将所述预设服务集合中所述第二预估等待时长低于所述第一预估等待时长的服务确定为所述至少一个备选服务，或者，将所述预设服务集合中所述第二预估等待人数低于所述第一预估等待人数的服务确定为所述至少一个备选服务。

4.如权利要求1所述的方法，其特征在于，每个备选服务的特征信息包括以下信息中的至少一种：

应答每个备选服务的预估等待时长和/或预估等待人数；

每个备选服务在单位时间段内被不同服务提供端应答的整体应答率；

每个备选服务在第一预设历史时间段内被不同服务请求端接受的整体接受率；

每个备选服务的支付费用；

每个备选服务与所述服务请求所请求的服务之间的支付费用差额；

每个备选服务所花费的会员积分；

每个备选服务与所述服务请求所请求的服务之间的服务体验分数差额。

5.如权利要求1所述的方法，其特征在于，每个备选服务的历史操作信息包括以下信息中的至少一种：

所述服务请求端在第二预设历史时间段内选择每个备选服务的历史次数；

所述服务请求端在所述第二预设历史时间段内接受推荐的每个备选服务的历史接受率。

6.如权利要求4或5所述的方法，其特征在于，所述基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务，包括：

基于所述每个备选服务的特征信息、以及所述每个备选服务的历史操作信息，对所述至少一个备选服务进行排序；

基于得到的排序结果，确定所述与所述服务请求端匹配的备选服务。

7.如权利要求6所述的方法，其特征在于，所述基于所述每个备选服务的特征信息、以及所述每个备选服务的历史操作信息，对所述至少一个备选服务进行排序，包括：

为所述每个备选服务的特征信息中每种特征信息设置第一评价分数以及第一权重，以及，为所述每个备选服务的历史操作信息中每种历史操作信息设置第二评价分数以及第二权重；

针对所述每个备选服务，基于所述每种特征信息对应的第一评价分数和第一权重、以及每种历史操作信息对应的第二评价分数和第二权重，计算每个备选服务的评价分数总和；

按照所述每个备选服务的评价分数总和由大到小的顺序，对所述至少一个备选服务进行排序。

8.如权利要求7所述的方法，其特征在于，所述基于得到的排序结果，确定与所述服务请求端匹配的备选服务，包括：

将排列在前N位的备选服务，确定为所述与所述服务请求端匹配的备选服务，其中，N为正整数。

9.如权利要求7或8所述的方法，其特征在于，所述指示所述服务请求端与所述服务请求端匹配的备选服务的信息，包括：

指示所述服务请求端按照所述排序结果展示所述与所述服务请求端匹配的备选服务的信息。

10.如权利要求9所述的方法，其特征在于，在指示所述服务请求端与所述服务请求端匹配的备选服务的信息之后，所述方法还包括：

基于应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数，指示所述服务请求端更改所述与所述服务请求端匹配的备选服务的信息的展示方式。

11.如权利要求10所述的方法，其特征在于，所述基于应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数，指示所述服务请求端更改所述与所述服务请求端匹配的备选服务的信息的展示方式，包括：

当所述第一预估等待时长超出第二设定时长，和/或，所述第一预估等待人数超出第二设定次数时，指示所述服务请求端高亮展示所述与所述服务请求端匹配的备选服务的信息。

12.如权利要求1所述的方法，其特征在于，在指示所述服务请求端所述与所述服务请求端匹配的备选服务的信息之后，所述方法还包括：

当检测到所述与所述服务请求端匹配的备选服务发生更新后，每隔预设时长，指示所述服务请求端对展示的与所述服务请求端匹配的备选服务的信息进行更新。

13.一种服务推荐装置，其特征在于，包括：

接收模块，用于接收来自服务请求端的服务请求；

第一确定模块，用于基于所述服务请求，确定至少一个备选服务；

第二确定模块，用于基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务；

指示模块，用于指示所述服务请求端与所述服务请求端匹配的备选服务的信息。

14.如权利要求13所述的装置，其特征在于，所述第一确定模块，在基于所述服务请求，确定至少一个备选服务时，具体用于：

确定应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数；

当所述第一预估等待时长超出第一设定时长，和/或，所述第一预估等待人数超出第一设定人数时，确定所述至少一个备选服务。

15.如权利要求13或14所述的装置，其特征在于，所述第一确定模块，在基于所述服务请求，确定至少一个备选服务时，具体用于：

确定应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数；以及，

确定预设服务集合中应答每一种服务对应的第二预估等待时长和/或第二预估等待人数；

将所述预设服务集合中所述第二预估等待时长低于所述第一预估等待时长的服务确定为所述至少一个备选服务，或者，将所述预设服务集合中所述第二预估等待人数低于所述第一预估等待人数的服务确定为所述至少一个备选服务。

16.如权利要求13所述的装置，其特征在于，每个备选服务的特征信息包括以下信息中的至少一种：

应答每个备选服务的预估等待时长和/或预估等待人数；

每个备选服务在单位时间段内被不同服务提供端应答的整体应答率；

每个备选服务在第一预设历史时间段内被不同服务请求端接受的整体接受率；

每个备选服务的支付费用；

每个备选服务与所述服务请求所请求的服务之间的支付费用差额；

每个备选服务所花费的会员积分；

每个备选服务与所述服务请求所请求的服务之间的服务体验分数差额。

17.如权利要求13所述的装置，其特征在于，每个备选服务的历史操作信息包括以下信息中的至少一种：

所述服务请求端在第二预设历史时间段内选择每个备选服务的历史次数；

所述服务请求端在所述第二预设历史时间段内接受推荐的每个备选服务的历史接受率。

18.如权利要求16或17所述的装置，其特征在于，所述第二确定模块，在基于所述至少一个备选服务中每个备选服务的特征信息、以及所述服务请求端对每个备选服务的历史操作信息，确定与所述服务请求端匹配的备选服务时，具体用于：

基于所述每个备选服务的特征信息、以及所述每个备选服务的历史操作信息，对所述至少一个备选服务进行排序；

基于得到的排序结果，确定所述与所述服务请求端匹配的备选服务。

19.如权利要求18所述的装置，其特征在于，所述第二确定模块，在基于所述每个备选服务的特征信息、以及所述每个备选服务的历史操作信息，对所述至少一个备选服务进行排序时，具体用于：

为所述每个备选服务的特征信息中每种特征信息设置第一评价分数以及第一权重，以及，为所述每个备选服务的历史操作信息中每种历史操作信息设置第二评价分数以及第二权重；

针对所述每个备选服务，基于所述每种特征信息对应的第一评价分数和第一权重、以及每种历史操作信息对应的第二评价分数和第二权重，计算每个备选服务的评价分数总和；

按照所述每个备选服务的评价分数总和由大到小的顺序，对所述至少一个备选服务进行排序。

20.如权利要求19所述的装置，其特征在于，所述第二确定模块，在基于得到的排序结果，确定与所述服务请求端匹配的备选服务时，具体用于：

将排列在前N位的备选服务，确定为所述与所述服务请求端匹配的备选服务，其中，N为正整数。

21.如权利要求19或20所述的装置，其特征在于，所述指示模块，在指示所述服务请求端与所述服务请求端匹配的备选服务的信息时，具体用于：

指示所述服务请求端按照所述排序结果展示所述与所述服务请求端匹配的备选服务的信息。

22.如权利要求21所述的装置，其特征在于，所述指示模块，还用于：

在指示所述服务请求端与所述服务请求端匹配的备选服务的信息之后，基于应答所述服务请求所请求的服务的第一预估等待时长和/或第一预估等待人数，指示所述服务请求端更改所述与所述服务请求端匹配的备选服务的信息的展示方式。

23.如权利要求22所述的装置，其特征在于，所述指示模块，在指示所述服务请求端更改所述与所述服务请求端匹配的备选服务的信息的展示方式时，具体用于：

当所述第一预估等待时长超出第二设定时长，和/或，所述第一预估等待人数超出第二设定次数时，指示所述服务请求端高亮展示所述与所述服务请求端匹配的备选服务的信息。

24.如权利要求13所述的装置，其特征在于，所述指示模块，还用于：

在指示所述服务请求端所述与所述服务请求端匹配的备选服务的信息之后，当检测到所述与所述服务请求端匹配的备选服务发生更新后，每隔预设时长，指示所述服务请求端对展示的与所述服务请求端匹配的备选服务的信息进行更新。

25.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行时执行如权利要求1至12任一所述的服务推荐方法的步骤。

26.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至12任一所述的服务推荐方法的步骤。

Images