CN114240563A - 一种出行订单处理方法、电子设备及计算机存储介质 - Google Patents

Abstract

本申请实施例提供了一种出行订单处理方法、电子设备及计算机存储介质。其中，出行订单处理方法包括：通过第一出行平台接收出行对象发送的出行订单；将出行订单发送至多个第二出行平台，并接收多个第二出行平台反馈的应答通知，应答通知中携带有可针对出行订单提供出行服务的多个候选出行服务提供者的信息；确定部分或全部所述多个候选出行服务提供者的订单取消率；根据所述订单取消率，确定目标出行服务提供者。

Description

一种出行订单处理方法、电子设备及计算机存储介质

技术领域

本申请实施例涉及数据处理技术领域，尤其涉及一种出行订单处理方法、电子设备及计算机存储介质。

背景技术

随着网络出行服务的不断普及，越来越多的出行对象选择通过出行平台预约车辆出行。使用网络出行服务的出行对象在出行平台上输入出行信息，如：出行时间、目的地等之后，便可发送出行订单，以便出行服务提供者接单并提供出行服务。

随着网络出行服务的发展，出行服务提供者的种类和数量也越来越多。在此情况下，针对出行对象发送的出行订单，可能存在多个可接单的出行服务提供者。因此，如何确定合适的出行服务提供者，以保障出行订单被接单并完成，提高出行体验，成为一个亟需解决的问题。

发明内容

有鉴于此，本申请实施例提供一种出行订单处理方案，以至少部分解决上述问题。

根据本申请实施例的第一方面，提供了一种出行订单处理方法，包括：通过第一出行平台接收出行对象发送的出行订单，其中，所述第一出行平台为聚合有多个第二出行平台的聚合平台；将所述出行订单发送至所述多个第二出行平台，并接收所述多个第二出行平台反馈的应答通知，所述应答通知中携带有可针对所述出行订单提供出行服务的多个候选出行服务提供者的信息；确定部分或全部所述多个候选出行服务提供者的订单取消率；根据所述订单取消率，确定出目标出行服务提供者。

根据本申请实施例的第二方面，提供了另一种出行订单处理方法，包括：接收出行对象输入的出行信息，并根据所述出行信息生成出行订单；将所述出行订单发送至第一出行平台，以使所述第一出行平台将所述出行订单发送给聚合至所述第一出行平台的多个第二出行平台，并且，基于所述多个第二出行平台针对所述出行订单反馈的多个候选出行服务提供者的信息，确定部分或全部所述多个候选出行服务提供者的订单取消率；接收所述第一出行平台根据所述订单取消率反馈的目标出行服务提供者的信息。

根据本申请实施例的第三方面，提供了再一种出行订单处理方法，包括：接收第二出行平台发送来的出行订单，其中，所述出行订单为所述第二出行平台从第一出行平台接收，所述第一出行平台中聚合有多个第二出行平台；根据出行服务提供者对所述出行订单的接收操作，生成响应消息，其中，所述响应消息中携带有所述出行服务提供者的信息；向所述第二出行平台反馈所述响应消息，以使所述第二出行平台根据所述响应消息向所述第一出行平台反馈所述出行服务提供者的信息，并通过所述第一出行平台确定所述出行服务提供者的订单取消率。

根据本申请实施例的第四方面，提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如第一方面或第二方面或第三方面所述的出行订单处理方法对应的操作。

根据本申请实施例的第三方面，提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面或第二方面或第三方面所述的出行订单处理方法。

根据本申请实施例提供的出行订单处理方案，第一出行平台中聚合有多个其它出行平台即多个第二出行平台，在出行对象需要出行时，向第一出行平台发出出行订单，该出行订单将由第一出行平台发送给多个第二出行平台，以获得更多的可提供服务的候选出行服务提供者的信息，为出行对象提供更快更好的出行服务。具体地，在第一出行平台接收到多个第二出行平台反馈的多个候选出行服务提供者的信息后，会对多个候选出行服务提供者中的部分或全部确定订单取消率，进而确定出目标出行服务提供者，通过这种方式，对出行服务提供者进行筛选，在提高出行服务质量的同时，还能够有效避免出行服务提供者在接单后又拒单的情况，进一步提高了针对出行对象的出行服务质量，提升了出行对象的出行体验。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1a为根据本申请实施例的一种出行订单处理系统的架构示意图；

图1b为基于图1a所示架构的一种出行订单处理方法的步骤流程图；

图2a为根据本申请实施例的另一种出行订单处理方法的步骤流程图；

图2b为图2a所示实施例中的一种场景示例的示意图；

图3a为根据本申请实施例的又一种出行订单处理方法的步骤流程图；

图3b为图3a所示实施例中提供的出行订单处理流程的示意图；

图4为根据本申请实施例的再一种出行订单处理方法的步骤流程图；

图5a为根据本申请实施例的又一种出行订单处理方法的步骤流程图；

图5b为图5a所示实施例中的一种场景示例的示意图；

图6为根据本申请实施例的一种电子设备的结构示意图。

具体实施方式

为了使本领域的人员更好地理解本申请实施例中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请实施例一部分实施例，而不是全部的实施例。基于本申请实施例中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请实施例保护的范围。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面结合本申请实施例附图进一步说明本申请实施例具体实现。

为便于对本申请实施例提供的出行订单处理方案进行说明，以下首先对可适用该方案的系统架构进行示例性说明，如图1a所示。

图1a中，第一出行平台为一个聚合平台，其接入了多个第二出行平台(图中示意为第二出行平台1、2……N)，可以认为其中的每一个第二出行平台都是第一出行平台的子平台。对于每一个第二出行平台，其可能接入一个或多个(两个及两个以上)出行服务提供商(图中均以三个为示例)，每个出行服务提供商签约有一定数量的出行服务提供者(司机)(图中均示意为n个)，由此，第一出行平台可将更多的出行服务提供者聚合起来，一方面为出行对象(出行用户)提供更快速更好的服务，另一方面为出行服务提供者(司机)也提供更多的服务机会。并且，可以有效降低第二出行平台的实现成本，第二出行平台无需具有复杂的功能如订单取消率确定功能，即可对外提供有质量保障的出行服务。

对于出行对象来说，其在需要出行时，可通过出行终端操作第一出行平台提供的接口(如应用界面等)发送出行订单；第一出行平台在接收到该出行订单后，会将该出行订单向其聚合的多个第二出行平台发放。每个第二出行平台在接收到该出行订单后，再向与其签约的出行服务提供商发送，最终由每个出行服务提供商将该出行订单发送至与各自签约的出行服务提供者。进而，根据出行服务提供者对该出行订单的应答，经由出行服务提供者-→出行服务提供商-→第二出行平台-→第一出行平台-→出行对象，也即，经由上述路径逐级反馈至第一出行平台，并最终由第一出行平台从中挑选出最合适的目标出行服务提供者，并向出行对象反馈。

需要说明的是，在实际应用中，上述第一出行平台可以部署在服务器或服务器集群上，此种情况下，也可以认为该服务器或该服务器集群即为第一出行平台。但不限于此，第一出行平台也可部署于云端，此种情况下，具有上述第一出行平台所实现的功能的云端软硬件设置也可被认为是第一出行平台。

类似地，每个第二出行平台也可部署在服务器或服务器集群或云端，相应的软硬件设置可被认为是第二出行平台。

以下，通过多个实施例对基于上述架构的出行订单处理方案进行说明。

实施例一、

参照图1b，示出了根据本申请实施例的一种出行订单处理方法的步骤流程图。

本实施例的出行订单处理方法包括以下步骤：

步骤100：通过第一出行平台接收出行对象发送的出行订单。

其中，如前所述，第一出行平台为聚合有多个第二出行平台的聚合平台。出行对象发送的出行订单中至少包含有：出行出发地、出行目的地、出行时间、出行对象标识等基本的出行信息。

需要说明的是，本申请实施例中，若无特殊说明，“多个”、“多种”等与“多”有关的数量，均意指两个及两个以上。

步骤200：将出行订单发送至多个第二出行平台，并接收多个第二出行平台反馈的应答通知。

其中，应答通知中携带有可针对出行订单提供出行服务的多个候选出行服务提供者的信息。

可针对出行订单提供出行服务的出行服务提供者的信息，会通过出行服务提供商反馈至第二出行平台，第二出行平台再通过应答通知的形式反馈给第一出行平台。

步骤300：确定部分或全部多个候选出行服务提供者的订单取消率。

在获得了多个候选出行服务提供者的信息后，可通过多种方式确定其中的部分或全部候选出行服务提供者的订单取消率。例如，通过预设的计算公式或神经网络模型的形式等。在采用计算公式时，可在候选出行服务提供者许可的情况下，基于其历史出行服务数据确定其对应的订单取消率。这种方法实现简单，但为了使得订单取消率的确定更为精准，本申请实施例采用了较为优选的神经网络模型方式，也即使用取消率预估模型的方式。

此种方式下，确定部分或全部多个候选出行服务提供者的订单取消率可以实现为：获得每个候选出行服务提供者对应的多维度特征信息；将每个候选出行服务提供者的多维度特征信息分别输入预先训练完成的取消率预估模型，得到取消率预估模型输出的候选出行服务提供者的订单取消率。其中，多维度特征信息用于从不同维度反映候选出行服务提供者针对当前出行订单的服务特征，包括但不限于：候选出行服务提供者的特征信息、出行订单的特征信息、出行对象的特征信息，等等。

预先训练完成的取消率预估模型具有以上述多维度特征信息为输入，并输出对应的订单取消率的功能，但本申请实施例中，对取消率预估模型的具体实现形式及其处理过程不作限制，只需能够根据输入的多维度特征信息，输出对应于当前出行服务提供者的订单取消率即可。在实际应用中，诸如卷积神经网络模型CNN、决策树模型等均可适用。基于多维度特征信息得到的订单取消率能够更准确地表征候选出行服务提供者接单后又取消所述出行订单的可能性。

基于此，在本申请实施例的一种可行方式中，还可以基于出行订单和多个候选出行服务提供者的信息，生成多维度特征信息，以从多个不同方面反映此次出行的服务特征，以利于更准确地确定特征与订单取消率的关系，进而提高订单取消率确定的准确度。

在一种可行方式中，基于出行订单和多个候选出行服务提供者的信息，生成多维度特征信息可以实现为：根据出行订单，确定出行场景信息、与出行对象相关的出行行为信息，并预估出行订单的完成信息；根据多个候选出行服务提供者的信息，确定服务提供表现信息；根据出行场景信息、与出行对象相关的出行行为信息、出行订单的完成信息和服务提供表现信息，生成多维度特征信息。

其中，出行场景信息用于反映该次出行交易的服务场景，该服务场景可从多个角度进行分类和设定。示例性地，如下表一所示：

具体地，例如，从订单费用角度出发，可以将订单分为“优惠订单”和“非优惠订单”两种类型，相对应地，出行场景信息包括优惠出行场景和非优惠出行场景。例如，为了提高被出行对象选择的概率，一些出行服务提供商可能会提供费用较为优惠的特价车型服务，若出行对象仅选择上述特价车型服务发送出行订单，则本次出行场景可以为优惠出行场景；若出行对象仅选择上述非特价车型服务发送出行订单，则本次出行场景可以为非优惠出行场景。

再例如，也可以从服务车辆的类型角度出发，将出行订单分为“出租车订单”和“其它网约车订单”，当出行对象仅选择出租车这一个类型的车型服务时，本次出行场景为出租车场景；当出行对象仅选择其它网约车这一个类型的车型服务时，本次出行场景为其它网约车场景。

又例如，还可以从出行对象发送出行订单时所使用的发单模式角度出发，将订单分为“助老模式订单”、“他人代叫模式订单”等，当出行对象以“助老模式”进行出行订单发送时，可以确定出行场景为助老模式场景，或者，当出行对象以“他人代叫模式”进行出行订单发送时，可以确定出行场景为他人代叫模式场景，等等。

而对于与出行对象相关的出行行为信息用于反映出行对象的出行行为特征，可基于其历史出行数据获得。

例如，该出行行为信息可以包括：在某个预设历史时间段(如历史30天)内，出行对象的出行订单取消情况(出行订单的取消率、出行订单的完成率等)。

也可以包括：出行当天，出行对象的出行订单取消情况，或者，本次出行前20分钟内，出行对象是否发送了出行订单并取消了订单。

或者，还可以包括：在某个预设历史时间段(如历史30天)内，出行对象对各出行服务提供商或各车型服务的接受程度等等，以车型服务为例，出行对象对某个车型服务的接受程度可以表征为：出行对象发送出行订单时选择该车型服务的次数和发送出行订单总次数的比值等。

对出行订单的完成信息的预估用于反映该次出行订单的可能完成情况，可基于出行订单本身的信息进行预估。例如，预估该出行订单的订单里程(出行距离)、完成该出行订单所需要的时长、可能需要的费用等中的部分或全部。

而服务提供表现信息用于反映出行服务提供者的服务特征，例如，历史服务表现信息(可通过出行对象的评价、订单取消率等确定)、接驾时长信息(表示到达出行对象乘车位置所需的时间)、服务费用信息等中的部分或全部。

其中，历史服务表现信息，例如：可以包括以下信息中的一种或多种组合：

在某个预设历史时间段(如历史30天)内，该出行服务提供者的出行订单取消情况(出行订单的取消率、出行订单的完成率等)；

出行当天，该出行服务提供者的出行订单取消情况；

在某个预设历史时间段(如历史30天)内，该出行服务提供者的接单偏好情况，例如，偏好接里程较长的出行订单，还是偏好接里程较短的出行订单等等。

上述信息均可在出行对象或出行服务提供者许可的情况下，基于基础的订单信息、出行行为信息等等，通过算法或神经网络模型得到。本申请实施例中，对具体的算法方式或神经网络模型方式的具体实现不作限制。

通过上述出行场景信息、与出行对象相关的出行行为信息、出行订单的完成信息和服务提供表现信息，即可生成从多个方面反映出行特点的多维度特征信息。但本领域技术人员应当明了的是，在实际应用中，也可以根据实际需求选择上述多维度特征信息中的部分使用，或者，增加其它维度的特征信息。

在获得了上述多维度特征信息的情况下，一种可行方式中，可以将针对每个候选出行服务提供者的多维度特征信息分别输入预先训练完成的取消率预估模型，得到取消率预估模型输出的候选出行服务提供者的订单取消率。

此外，在另一可行方式中，在确定部分或全部多个候选出行服务提供者的订单取消率之前，还可以根据预设的平台准入规则，对多个候选出行服务提供者进行筛选，获得筛选后的多个候选出行服务提供者的信息。

此种方式中，在对出行服务提供者进行筛选之前，会先根据预设的平台准入规则，对第二出行平台进行筛选，以保证提供候选出行服务提供者的信息的第二出行平台的质量。从而，从平台层面即杜绝服务质量差的平台提供的出行服务提供者的准入，提高向出行对象提供的服务提供者的整体质量。

可选地，根据预设的平台准入规则，对多个候选出行服务提供者进行筛选，获得筛选后的多个候选出行服务提供者的信息可以实现为：获取多个第二出行平台分别对应的出行服务平台质量信息；根据出行服务平台质量信息，选择针对出行订单的第二出行平台，筛选出被选择的第二出行平台反馈的候选出行服务提供者的信息。

其中，第二出行平台的出行服务平台质量信息用于反映第二出行平台的综合质量。该质量信息可基于大量出行对象对该第二出行平台的历史出行服务评价、第二出行平台历史反馈的出行服务提供者的服务质量评价、第二出行平台可反馈的出行服务提供者的信息的数量、第二出行平台针对出行订单的应答速度等确定。具体的确定手段可由本领域技术人员根据实际需求采用算法方式(如为上述不同评价参数设置权重进而加和等)或神经网络模型方式(如以上述不同评价参数为输入，输出为质量评分的模型)等实现，本申请实施例对此不作限制。

通过平台准入规则，可将出行订单发送至具有更好质量的第二出行平台，既可为出行对象提供高质量的出行服务，又可促进第二出行平台提升服务质量。相应地，这些被筛选出来的质量较高的第二出行平台反馈的候选出行服务提供者的信息也将被筛选出来。在此情况下，前述确定部分或全部多个候选出行服务提供者的订单取消率可针对被筛选出来的候选出行服务提供者进行。类似地，在生成多维度特征信息时，也可基于出行订单和筛选出的这些候选出行服务提供者的信息，来生成对应的多维度特征信息。

步骤400：根据订单取消率，确定目标出行服务提供者。

每个候选出行服务提供者都可对应于一个订单取消率，基于此，可从中选择出目标出行服务提供者。若该目标出行服务提供者包括多个，则还可根据实际需要进行进一步选择处理，如结合服务质量、距离出行对象远近、历史服务评价等等，从而筛选出最终的目标出行服务提供者。

可见，通过本实施例，第一出行平台中聚合有多个其它出行平台即多个第二出行平台，在出行对象需要出行时，向第一出行平台发出出行订单，该出行订单将由第一出行平台发送给多个第二出行平台，以获得更多的可提供服务的候选出行服务提供者的信息，为出行对象提供更快更好的出行服务。具体地，在第一出行平台接收到多个第二出行平台反馈的多个候选出行服务提供者的信息后，一方面，会基于平台准入规则，对这些候选出行服务提供者进行筛选，从平台层面即杜绝服务质量差的平台提供的出行服务提供者的准入，提高向出行对象提供的服务提供者的整体质量；另一方面，会基于出行订单和筛选后的多个候选出行服务提供者的信息，生成多维度特征信息，并基于多维度特征信息确定多个候选出行服务提供者的订单取消率，从中选出最终的目标出行服务提供者，通过这种方式，对出行服务提供者进行再次筛选，在进一步提高出行服务质量的同时，又因基于多维度特征信息得到的订单取消率能更准确地表征候选出行服务提供者接单后又取消所述出行订单的可能性，从而能够有效避免出行服务提供者在接单后又拒单的情况，进一步提高了针对出行对象的出行服务质量，提升了出行对象的出行体验。

实施例二、

参照图2a，图2a为根据本申请实施例二的一种出行订单处理方法的步骤流程图。

本实施例中，以使用取消率预估模型确定订单取消率为示例，对本申请实施例的出行订单处理方法进行说明。为便于说明，先对该取消率预估模型的训练进行说明。

具体地，本实施例提供的订单处理方法包括以下步骤：

步骤101，对预设的取消率预估模型进行训练，获得可输出订单取消率的取消率预估模型。

包括：获取样本出行订单、样本出行订单对应的样本出行服务提供者及样本出行服务提供者的标签；基于样本出行订单和样本出行服务提供者的信息，生成多维度样本特征信息；使用多维度样本特征信息和样本出行服务提供者的标签，对预设的取消率预估模型进行训练。

其中，样本出行服务提供者的标签用于表征样本出行服务提供者是否完成了样本出行订单。例如，若样本出行服务提供者最终完成了上述样本出行订单，则可以将标签设置为0，否则，可以将样本出行服务提供者的标签设定为1，等。

基于样本出行订单和样本出行服务提供者的信息，生成多维度样本特征信息的具体实现可参照前述实施例一中的、基于出行订单和出行服务提供者的信息生成多维度特征信息的具体实现，在此不再详述。

以取消率预估模型为CNN模型为示例，在将上述多个维度的特征，例如，样本出行场景信息、与样本出行对象相关的样本出行行为信息、样本出行订单的完成信息和样本服务提供表现信息统一至同一特征空间，并进行融合生成所述多维度样本特征信息后，将该多维度样本特征信息输入CNN模型，通过CNN模型的隐藏层进行订单取消率估计预测，获得预测值；通过预先设置的模型损失函数(如距离损失函数或交叉熵损失函数等)，基于该预测值和样本出行服务提供者的标签，获得损失值；再根据该损失值对该CNN模型进行训练，直到达到训练终止条件，如训练次数达到预设次数或者损失值达到预设的阈值等。

通过对模型进行不断的迭代训练，最终训练完成的模型将能够基于输入的多维度特征信息，输出较为准确的订单取消率，如订单取消概率或分值等。

训练完成的取消率预估模型可在后续一段时间内长期使用，无需每次确定订单取消率均进行优化训练。

该训练完成的取消预估模型可部署于第一出行平台上，进行后续的出行订单处理操作，如下步骤102-108所述。

步骤102，通过第一出行平台接收出行对象发送的出行订单。

其中，第一出行平台为聚合有多个第二出行平台的聚合平台。

步骤104，将出行订单发送至多个第二出行平台，并接收多个第二出行平台反馈的应答通知。

其中，应答通知中携带有可针对出行订单提供出行服务的多个候选出行服务提供者的信息。

步骤106，通过取消率预估模型确定部分或全部多个候选出行服务提供者的订单取消率。

步骤108，根据订单取消率，确定目标出行服务提供者。

上述步骤102-108的具体实现可参照前述实施例一及上述步骤101中的相关描述，在此不再赘述。

参见图2b，图2b为图2a所示实施例中的一种场景示例的示意图，以下，将参考图2b所示的示意图，以一个具体场景示例，对上述过程进行示例性说明。

出行对象通过出行终端在第一出行平台提供的出行应用的界面上输入出行信息，如出行时间、目的地等信息之后，出行应用根据该出行信息生成出行订单，并在向第一出行平台发送后，由第一出行平台向多个第二出行平台发送上述出行订单，本示例中，假设第一出行平台聚合有三个第二出行平台，分别为第二出行平台1、2和3。第二出行平台1、2和3在分别接收到该出行订单后，再向各自的出行服务提供商发送，以通过出行服务提供商获得针对该出行订单的、可提供出行服务的出行服务提供者的信息。为简单示例，假设上述出行订单发出后，第二出行平台1、2和3根据出行服务提供商反馈的信息，共获得六个候选出行服务提供者，本示例中，示意为：司机A、司机B、司机C、司机D、司机E和司机F(示例性地，司机A和B由第二出行平台1获得；司机C和D由第二出行平台2获得；司机E和F由第二出行平台3获得)。进而，第二出行平台1、2和3均向第一出行平台反馈，第一出行平台获得上述六位司机的信息。

接着，第一出行平台会根据出行订单及各位司机的信息生成与六位司机对应的六个多维度特征信息。本示例中，这六个多维度特征信息将分别被输入取消率预估模型，由模型输出对应的订单取消率。

假设，司机A的订单取消率为55％、司机B的订单取消率为70％、司机C的订单取消率为5％、司机D的订单取消率为20％、司机E的订单取消率为10％、司机F的订单取消率为30％。

再假设，本示例中的取消率阈值为10％，因此，司机C和司机E均符合要求。本示例中，为简单起见，将订单取消率最低的确定为最终的服务司机，即将司机C确定为完成上述出行订单的目标司机。进而，第一出行平台向出行终端反馈该目标司机的信息。但在实际应用中，还可以有更多的对司机进行筛选和确定的方式，将在下文中进行说明。

可见，通过本实施例，借助于取消率预估模型，可以较为准确地为应答了出行订单的出行服务提供者确定出订单取消率，进而能够有效避免出行服务提供者在接单后又拒单的情况，进一步提高了针对出行对象的出行服务质量，提升了出行对象的出行体验。

实施例三、

参照图3a，图3a为根据本申请实施例三的一种出行订单处理方法的步骤流程图。

本实施例中，以根据订单取消率确定目标出行服务提供者为侧重点，对本申请实施例提供的出行订单处理方法进行说明。

具体地，本实施例提供的订单处理方法包括以下步骤：

步骤202，通过第一出行平台接收出行对象发送的出行订单。

其中，第一出行平台为聚合有多个第二出行平台的聚合平台。

步骤204，将出行订单发送至所述多个第二出行平台，并接收多个第二出行平台反馈的应答通知。

其中，应答通知中携带有可针对出行订单提供出行服务的多个候选出行服务提供者的信息。

步骤206，确定部分或全部多个候选出行服务提供者的订单取消率。

上述步骤202-206的具体实现可参照前述实施例一相关部分的描述，在此不再详述。

步骤208，根据订单取消率，确定目标出行服务提供者。

本步骤在具体实现时，在第一种可行方式中，设定了一个较小的预设取消率阈值，即第一预设取消率阈值。基于此，若候选出行服务提供者的订单取消率小于第一预设取消率阈值，则将该候选出行服务提供者确定为用于完成出行订单的目标出行服务提供者。其中，该第一预设取消率阈值可由本领域技术人员根据实际需求设置，如为10％等。

示例性地，假设多个候选出行服务提供者分别为司机A、B、C，设定第一预设取消率阈值为10％，则从三者中确定出目标出行服务提供者可简单示意为下表二：

由上表可见，因司机A的订单取消率小于第一预设取消率阈值10％，可将其直接确定为目标出行服务提供者。可见，通过这种方式，实现简单，订单响应速度也较快。

但是，虽然可以直接将订单取消率最低的候选出行服务提供者确定为目标出行服务提供者，但为了保证确定结果的客观和更为准确，本实施例中，还进一步提供了下述多个更为优选的方式。

在第二种可行方式中，还设置了第二预设取消率阈值，该第二预设取消率阈值设定为一较大值，远大于第一预设取消率阈值，以在确定候选出行服务提供者的订单取消率大于该第二预设取消率阈值时，对其进行滤除或者进行重点考查。本示例中，考虑到出行服务提供者的可选择范围，以进行重点考查为示例。

具体地，若候选出行服务提供者的订单取消率大于或等于第二预设取消率阈值，判断拒单操作的总次数是否大于预设拒单次数阈值；若大于或等于预设拒单次数阈值，则将该候选出行服务提供者确定为用于完成出行订单的目标出行服务提供者；若小于预设拒单次数阈值，则对该候选出行服务提供者执行拒单操作。其中，第二预设取消率阈值可由本领域技术人员根据实际情况设定，如为63％等；预设拒单次数阈值用于表征第一出行平台针对候选出行服务对象拒绝使其接受订单的次数阈值，同样可由本领域技术人员根据实际情况设定，本申请实施例对此均不作限制。

本方式中，若候选出行服务提供者的订单取消率大于或等于第二预设取消率阈值，则表明该候选出行服务提供者接受该出行订单后又取消的可能性较大。但此时，并非直接对其进行滤除操作，而是会进一步判断第一出行平台在一定时间段内(如一个自然日或内个小时内)拒单操作的总次数，若总次数较多(如，大于预设拒单次数阈值，如3次)，虽然当前候选出行服务提供者的订单取消率较高，但为避免因多次拒单而导致出行订单最终无法被接单，则可以将该候选出行服务提供者确定为用于完成出行订单的目标出行服务提供者。反之，若拒单的总次数较少(如，不大于预设拒单次数阈值)，则为了提高出行订单被接单并完成的可能性，可以对该候选出行服务提供者执行拒单操作，而等待其它候选出行服务提供者或获取新的候选出行服务提供者，并基于这些候选出行服务提供者的订单取消率，确定用于完成出行订单的目标出行服务提供者。

示例性地，假设多个候选出行服务提供者分别为司机A、B、C，设定第二预设取消率阈值为63％，预设拒单次数阈值为3，目前拒单操作的总次数为3，则从三者中确定出目标出行服务提供者可简单示意为下表三：

可见，通过这种方式，可以从一定程度上避免出行订单无人接单的情况发生。

与上述第二种可行方式类似的，在第三种可行方式中，若候选出行服务提供者的订单取消率大于或等于第二预设取消率阈值，判断接收应答通知的时刻与发送出行订单的时刻之间的间隔时长是否超过预设间隔时长；若超过预设间隔时长，则将候选出行服务提供者确定为用于完成出行订单的出行服务提供者；若未超过预设间隔时长，则对候选出行服务提供者执行拒单操作。其中，本方式中的第二预设取消率阈值的含义及其设置与上述第二种可行方式中相同。此外，本方式中，预设间隔时长可由本领域技术人员根据实际情况设定，本申请实施例对此不作限制。

该方式中，若候选出行服务提供者的订单取消率大于或等于第二预设阈值，则表明该候选出行服务提供者接受该出行订单后又取消的可能性较大，但此时，并非直接对其进行滤除操作，而是会进一步确定第一出行平台接收应答通知的时刻与发送出行订单的时刻之间的时间间隔，若间隔时长较长(例如：间隔时长大于20s)，则表明可接受该出行订单的候选出行服务提供者较少，为避免出行对象等待较长时间后，最终出行订单无法被接单，此时，虽该候选出行服务提供者的订单取消率较高，但仍可以直接将其确定为用于完成出行订单的目标出行服务提供者。反之，若间隔时长较短，则有可能接收到更多的应答通知，获得更多的候选出行服务提供者，此种情况下，为了提高出行订单被接单并完成的可能性，可以对该候选出行服务提供者执行拒单操作，而等待其它候选出行服务提供者或者获取新的候选出行服务提供者，并基于这些候选出行服务提供者的订单取消率，确定用于完成出行订单的目标出行服务提供者。

示例性地，假设多个候选出行服务提供者分别为司机A、B、C，设定第二预设取消率阈值为63％，预设间隔时长为20s，目前间隔时长为10s，则从三者中确定出目标出行服务提供者可简单示意为下表四：

可见，通过这种方式，可以从一定程度上避免出行订单无人接单的情况发生。

在第四种可行方式中，若候选出行服务提供者的订单取消率大于或等于第一预设取消率阈值，且小于第二预设取消率阈值，则从多个第二出行平台再次获取新的候选出行服务提供者的信息；基于出行订单和新的候选出行服务提供者的信息，生成新的多维度特征信息，并基于新的多维度特征信息确定新的候选出行服务提供者的订单取消率；基于原候选出行服务提供者的订单取消率和新的候选出行服务提供者的订单取消率，确定用于完成出行订单的目标出行服务提供者。

其中，第一预设取消率阈值和第二预设取消率阈值的含义及具体设定均与前述方式相同，在此不再赘述。

该种方式中，若候选出行服务提供者的订单取消率介于第一预设阈值和第二预设阈值之间，则表明若将候选出行服务提供者确定为用于完成出行订单的目标出行服务提供者，则出行订单最终被取消的可能性仍较大，此时，为了进一步提高出行订单被接单并完成的可能性，进而提高出行对象的出行体验，可以适当地等待一定时长(第一预设时长)，从而在候选出行服务提供者和第一预设时长内的新增候选出行服务提供者(为便于与后续区分，将此处的新增候选出行服务提供者在后文中称为第一新增候选出行服务提供者)中，选择订单取消率更低的候选出行服务提供者作为用于完成出行订单的目标出行服务提供者。

例如：第一出行平台发出出行订单之后，第4s接收到了第一个应答通知，并确定出第一个应答通知对应的候选出行服务提供者为司机A，确定出司机A的订单取消率为25％(大于第一预设取消率阈值10％，且小于第二预设取消率阈值63％)，此时，则可以再次等待第一预设时长(如3s)，若在这3s时长(即从发出出行订单之后的第4s到第7s)内，接收到了一个新的应答通知，并确定出该新的应答通知对应的候选出行服务提供者为司机B，则司机B即为第一新增候选出行服务提供者。

在上述示例中，第一新增候选出行服务提供者的数量为1个，本领域技术人员可以理解：第一新增候选出行服务提供者的数量也可以为多个，例如：若在上述3s时长内，共接收到了2个新的应答通知，并确定出上述两个新的应答通知对应的候选出行服务提供者分别为司机B和司机C，则司机B和司机C均为第一新增候选出行服务提供者。

可选地，在其中一些实施例中，可以基于候选出行服务提供者的订单取消率，得到候选出行服务提供者的接单倾向信息；基于第一新增候选出行服务提供者的订单取消率，得到第一新增候选出行服务提供者的接单倾向信息；其中，接单倾向信息用于表征候选出行服务提供者被确定为用于完成出行订单的目标出行服务提供者的可能性；基于候选出行服务提供者的接单倾向信息和第一新增候选出行服务提供者的接单倾向信息，确定用于完成出行订单的目标出行服务提供者。

可选地，在其中一些实施例中，候选出行服务提供者的接单倾向信息可以通过如下方式得到：基于候选出行服务提供者的订单取消率，得到候选出行服务提供者的基础接单倾向信息；基于候选出行服务提供者的基础接单倾向信息和与候选出行服务提供者对应的信息权重，得到候选出行服务提供者的接单倾向信息。

其中，接单倾向信息可表示为多个分级的形式，示例性地如表五所示：

上表中，基础接单倾向信息示例性地用接单倾向分值来表示，接单倾向分值越高，则被确定为用于完成出行订单的目标出行服务提供者的可能性越高。

可选地，在其中一些实施例中，第一新增候选出行服务提供者的接单倾向信息可以通过如下方式得到：基于第一新增候选出行服务提供者的订单取消率，得到第一新增候选出行服务提供者的基础接单倾向信息；基于第一新增候选出行服务提供者的基础接单倾向信息和与第一新增候选出行服务提供者对应的信息权重，得到第一新增候选出行服务提供者的接单倾向信息。

上述信息权重均可以根据实际场景和需要进行设定，例如：为了均衡司机(出行服务提供者)的接单量，可以根据司机所在区域内可接单司机数量与出行订单数量之间的大小关系，设定上述信息权重：当可接单司机数量远大于出行订单数量时，则为该司机设定较大的信息权重，反之，设定较小的信息权重。

例如：假设对于基础接单倾向信息相同的两个司机：司机A和司机B，司机A所在区域内可接单司机数量远大于出行订单数量，而司机B所在区域内可接单司机数量远小于出行订单数量(上述情况表明：若未将该出行订单分配给A，则后续A还能接到出行订单的可能性较低，而对于司机B而言，即使未接到该出行订单，后续B能接到出行订单的可能性也较大)，此时，按照上述信息权重设定方法，由于司机A的信息权重大于司机B的信息权重，因此，最终司机A的接单倾向分值高于司机B的接单倾向分值，这样可以均衡司机A和司机B的接单量。

示例性地，上述权重设定可简单示意为下表六：

由上表可见，经权重调整后，司机A的接单倾向分值调整为7*1.3＝9.1，而司机B仍为7。由此，该出行订单分派给司机A的概率大大增加了。

该方式中，接单倾向信息是对基于订单取消率得到的基础接单倾向信息进行权重修正之后得到的，而上述信息权重则可以根据实际场景和需要来设定，因此，针对不同的场景，通过该方式均可以确定出合适的出行服务提供者，泛化能力较强。

可选地，在其中一些实施例中，基于原候选出行服务提供者的订单取消率和新的候选出行服务提供者的订单取消率，确定用于完成出行订单的目标出行服务提供者可以实现为：基于原候选出行服务提供者的订单取消率和新的候选出行服务提供者的订单取消率，确定优选候选出行服务提供者；若优选候选出行服务提供者的订单取消率小于第三预设取消率阈值，则将优选候选出行服务提供者确定为用于完成出行订单的目标出行服务提供者。其中，第三预设取消率阈值大于第一预设取消率阈值且小于第二预设取消率阈值。通过设定第三预设取消率阈值，可以在获得的候选出行服务提供者的订单取消率均在中间范围(大于第一预设取消率阈值且小于第二预设取消率阈值)时，从中筛选出相对较优质的出行服务提供者。

示例性地，假设多个候选出行服务提供者分别为司机A、B、C，设定第一预设取消率阈值为10％、第二预设取消率阈值为63％、第三预设取消率阈值为30％，则从三者中确定出目标出行服务提供者可简单示意为下表七：

通过这种方式，在能够保障将订单取消率控制在一个较低程度的同时，提高了出行订单响应速度。

可选地，在其中一些实施例中，在确定出优选候选出行服务提供者之后，若优选候选出行服务提供者的订单取消率大于或等于第三预设阈值，则再次从所述多个第二出行平台获取新的候选出行服务提供者的信息；基于出行订单和再次获取的新的候选出行服务提供者(为便于描述，后文中将此再次获取的新的候选出行服务提供者称为第二新增候选出行服务提供者)的信息，再次生成新的多维度特征信息，并基于再次生成的新的多维度特征信息确定再次获取的新的候选出行服务提供者的订单取消率；基于再次获取的新的候选出行服务提供者的订单取消率和优选候选出行服务提供者的订单取消率，确定用于完成出行订单的目标出行服务提供者。

若优选出行服务提供者的订单取消率较大(大于或等于第三预设阈值，例如：30％)，则表明若将优选出行服务提供者确定为用于完成出行订单的出行服务提供者，则出行订单最终被取消的可能性仍然偏大，此时，为了进一步提高出行订单被接单并完成的可能性，进而提高出行对象的出行体验，可以适当地再次等待一定时长(第二预设时长)，从而基于订单取消率，在优选出行服务提供者和第二预设时长内的新增候选出行服务提供者中再次进行选择，从而确定用于完成出行订单的目标出行服务提供者。

可选地，可以基于第二新增候选出行服务提供者的订单取消率，得到第二新增候选出行服务提供者的接单倾向信息；基于优选出行服务提供者的接单倾向信息和第二新增候选出行服务提供者的接单倾向信息，确定用于完成出行订单的目标出行服务提供者。

步骤210，将确定的目标出行服务提供者的信息反馈给出行对象。

具体地，可反馈至出行对象发送出行订单的出行终端中。

通过本实施例，由于确定订单取消率时，同时考虑了由多维度特征信息表征的多方面的因素，因此，得到的订单取消率能更准确地表征候选出行服务提供者接单后又取消出行订单的可能性，进而根据上述订单取消率确定用于完成出行订单的目标出行服务提供者，可以提高出行订单被接单并完成的可能性，提高用户的出行体验。

确定订单取消率时，考虑了候选出行服务提供者的订单取消率可能存在的多种不同情况，并分别针对每种情况，设定了对应的处理方案,从而在提高出行订单被接单并完成的可能性的前提下，降低了出行对象的等待时间，进一步提高了出行对象的出行体验。

参照图3b，图3b为根据本申请实施例二提供的出行订单处理流程的示意图。以下结合图3b对本申请实施例二提供的数据处理流程进行简要说明，主要包括：

第一步，第一出行平台提供的出行应用接收出行对象通过应用界面输入出行信息。

第二步，根据出行信息生成出行订单，并向第一出行平台发送出行订单。

实现应用中，每个出行平台均可能存在多种运力，简单示意如下表八所示。

上表示出了几中运力示例，但本领域技术人员应当明了的是，在实际应用中，还可以有其它不同的运力情况，均可适用本申请实施例的方案。

上述运力及出行服务提供商均可通过应用界面展示给出行对象，由出行对象自行选择。出行应用在获取到出行对象输入的出行信息之后，可以先根据出行信息和出行对象的相关信息等，为出行对象推荐预设数量的运力，由出行对象自行选择。进而，出行应用将基于出行对象输入的出行信息及选择的运力的信息，生成并向第一出行平台发送出行订单。

第三步，第一平台将出行订单发送给具有相应运力的第二出行平台，并接收第二出行平台反馈的应答通知。

每个应答通知中都有相应的候选出行服务提供者的信息，则第一出行平台可基于出行订单及候选出行服务提供提供者的信息生成多维度特征信息，通过取消率预估模型获得候选出行服务提供者的订单取消率。

本示例中，设定若某个候选出行服务提供者的订单取消率小于第一预设取消率阈值(如10％)，则直接将该候选出行服务提供者确定为用于完成出行订单的目标出行服务提供者；而若某个候选出行服务提供者的订单取消率大于或等于第二预设取消率阈值(如63％)，则对该候选出行服务提供者执行拒单操作。

另外，若在某个预设时间段(如10s)内，未接收到第二出行平台反馈的应答通知，说明出行对象选择的运力不足，此时，备选方案可以为：为提高出行订单被应答的概率，针对出行对象未选择的其他运力也发送出行订单，若收到其他运力对应的应答通知，则提示出行对象存在其他可用运力，由出行对象决定是否选用其他出行运力。

第四步，若多个第二出行平台反馈回来的候选出行服务提供者中不存在订单取消率小于第一预设取消率阈值的服务提供者，则进行接单倾向信息比较。

例如，若所有候选出行服务提供者的订单取消率均大于第一预设阈值且小于第二预设阈值，则可以继续获取新的候选出行服务提供者作为第一新增候选出行服务提供者，对候选出行服务提供者和第一新增候选出行服务提供者的接单倾向信息进行比较，并确定优选出行服务提供者。之后，可以基于比较结果确定目标出行服务提供者。

进一步地，还可以对优选出行服务提供者进行进一步的细化处理，例如，若优选出行服务提供者的订单取消率小于第三预设取消率阈值(如30％)，则将优选出行服务提供者确定为用于完成出行订单的目标出行服务提供者。

否则，可以继续获取新的候选出行服务提供者作为第二新增候选出行服务提供者，对优选出行服务提供者和第二新增候选出行服务提供者的接单倾向信息进行比较，基于优选出行服务提供者和第二新增候选出行服务提供者的接单倾向信息，确定用于完成出行订单的目标出行服务提供者。

由此，可以最大程度地提供服务质量较优的出行服务提供者，提升出行对象的出行体验。

实施例四、

参照图4，示出了根据本申请实施例的再一种出行订单处理方法的步骤流程图。

本实施例从出行对象的出行终端的角度，对本申请实施例提供的出行订单处理方法进行说明。本实施例的出行订单处理方法包括以下步骤：

步骤402，接收出行对象输入的出行信息，并根据出行信息生成出行订单。

其中，出行对象输入的出行信息包括本次出行的基本信息，这些基本信息包括但不限于：出行出发地、出行目的地、出行时间、出行对象标识等信息。

基于接收到的出行信息，出行终端可以生成出行订单，在该出行订单中除携带有上述出行信息外，还携带有该出行终端的标识。

步骤404，将出行订单发送至第一出行平台，以使第一出行平台将出行订单发送给聚合至第一出行平台的多个第二出行平台，并且，基于多个第二出行平台针对出行订单反馈的多个候选出行服务提供者的信息，确定部分或全部多个候选出行服务提供者的订单取消率。

如前所述，第一出行平台为聚合平台，其中聚合有多个第二出行平台。第一出行平台在接收到出行终端发送来的出行订单后，会分发至多个第二出行平台，以通过每个第二出行平台及与每个第二出行平台签约的出行服务提供商、及与每个出行服务提供商签约的出行服务提供者，确定可服务于当前出行订单的候选出行服务提供者，并逐级反馈直至第一出行平台。进一步地，第一出行平台会确定候选出行服务提供者的订单取消率，并根据订单取消率确定最终的目标出行服务者，以向出行终端反馈该目标出行服务者的信息。

其中，第一出行平台获得针对出行订单的候选出行服务提供者的具体实现及确定目标出行服务者的具体实现均可参照前述多个实施例中相应部分的描述，在此不再赘述。

步骤406，接收第一出行平台根据订单取消率反馈的目标出行服务提供者的信息。

如前所述，第一出行平台会针对第二出行平台反馈的候选出行服务提供者中的部分或全部，确定对应的订单取消率，并基于此确定目标出行服务者。然后，将目标出行服务提供者的信息反馈至出行终端。进而，该出行终端可向出行对象展示该目标出行服务提供者的信息。

上述过程的一种示例性场景如图2b所示，在此不再赘述。

通过本实施例，出行终端可以通过第一出行平台获得具有较高服务质量的出行服务提供者的信息，获得较好的出行体验。

实施例五、

参照图5a，示出了根据本申请实施例的又一种出行订单处理方法的步骤流程图。

本实施例从出行服务提供者的出行终端的角度，对本申请实施例提供的出行订单处理方法进行说明。本实施例的出行订单处理方法包括以下步骤：

步骤502，接收第二出行平台发送来的出行订单。

其中，出行订单为第二出行平台从第一出行平台接收，第一出行平台中聚合有多个第二出行平台，包括该发送出行订单的第二出行平台。

第一出行平台或第二出行平台向出行服务提供者的出行终端提供有相应的接口，如相应的应用程序。因此，该出行终端可以通过该应用程序接收出行订单，并通过该应用程序的界面展示该出行订单的信息。

需要说明的是，在实际应用中，与第二出行平台签约的可能为出行服务提供商，因此，本步骤也可以认为是接收第二出行平台通过出行服务提供商发送来的出行订单，但上述接口仍可由第一出行平台或第二出行平台提供。当然，也可以由出行服务提供商提供。但不管由哪方提供，可实现上述多方之间的及时交互即可。

本实施例中，出行订单中携带的信息包括但不限于：出行出发地、出行目的地、出行时间、出行对象标识等。

步骤504，根据出行服务提供者对出行订单的接受操作，生成响应消息。

如前所述，应用程序的界面中会展示相应的出行订单的信息，若出行服务提供者愿意为该出行订单提供出行服务，则可通过界面中的相应选项，如“确定”选项或“抢单”选项等，进行接受操作。本实施例中的出行终端在接收到该接受操作后，会生成相应的响应消息，该响应消息中携带有该出行服务提供者的信息。

步骤506，向第二出行平台反馈响应消息，以使第二出行平台根据响应消息向第一出行平台反馈出行服务提供者的信息，并通过第一出行平台确定出行服务提供者的订单取消率。

第二出行平台在接收到响应消息后，从中获取出行服务提供者的信息，并将其反馈给第一出行平台。则第一出行平台可基于该出行服务提供者的信息，确定其对应的订单取消率。进而，基于该订单取消率确定为出行订单提供服务的目标出行服务提供者，并向出行对象反馈。该第一出行平台的上述处理的具体实现可参见前述实施例一至三中相应部分的描述，在此不再赘述。

可选地，若该出行服务提供者被确定为目标出行服务提供者，则该出行终端还会接收到第一出行平台通过第二出行平台及出行服务提供商反馈的被选中的消息并展示。

以下，以一个场景示例，对上述过程进行示例性说明，如图5b所示。

本示例中，以出行服务提供者为司机A为例，司机A通过其出行终端展示其签约的第二出行平台1提供的应用程序的界面，通过该界面展示相应的出行信息，包括但不限于当前道路信息、当前位置信息、司机A在该应用程序中的账号信息等。并且，可通过该应用程序接收第二出行平台1通过出行服务提供商X发送来的出行订单M的信息并展示。本示例中，如图5b所示，在接收到该出行订单M的信息后，通过该应用程序的界面进行展示。相对应于展示的该出行订单M的信息，还设置有相应的操作按钮，本示例中示意为“拒绝”和“接受”按钮。若司机A不愿意为该出行订单M提供服务，则点击“拒绝”按钮后，该出行订单M的信息将不再展示。而如果司机A愿意为该出行订单M提供服务，则可以点击“接受”按钮(本示例中以“接受”为例)，应用程序在接收到该操作后，将生成相应的响应消息，在该响应消息中携带司机A的信息以及出行订单M的信息。然后，将该响应消息通过出行服务提供商，示例为出行服务提供商11，反馈给第二出行平台1。第二出行平台1在接收到该响应消息后，从中获取司机A的信息以及出行订单M的信息生成应答通知，向第一出行平台反馈。第一出行平台在接收到该应答通知后，基于其中携带的信息，确定司机A为针对出行订单M的候选司机，为其确定相对应的订单取消率，并基于司机A的订单取消率与其它可为出行订单M提供服务的候选司机的订单取消率，确定出最终的目标司机。本示例中，假设司机A被确定为目标司机，则第一出行平台一方面会向乘客(出行对象)的出行终端反馈司机A的信息；另一方面，会通过第二出行平台和出行服务提供商向司机A反馈其被选中的消息。司机A的出行终端收到该消息后在应用程序界面中展示，在司机A点击“确定”后，即可基于司机A的当前位置和出行订单M对应的乘客的位置，生成导航路线，供司机A参考，以及时到达乘客的出行位置，为乘客提供出行服务。

可见，通过本实施例，出行服务提供者可通过第一出行平台获得更多的出行订单的资源，又因第一出行平台基于订单取消率筛选目标出行服务提供者，从而可以有效促进出行服务提供者提升服务质量，进而达到整体出行服务质量的提升，也提升了出行对象的出行体验。

实施例六

参照图6，示出了根据本申请实施例的一种电子设备的结构示意图，本申请具体实施例并不对电子设备的具体实现做限定。

如图6所示，该电子设备可以包括：处理器(processor)602、通信接口(Communications Interface)604、存储器(memory)606、以及通信总线608。

其中：

处理器602、通信接口604、以及存储器606通过通信总线608完成相互间的通信。

通信接口604，用于与其它电子设备或服务器进行通信。

处理器602，用于执行程序610，具体可以执行上述多个出行订单处理方法实施例中任一所描述的相关步骤。

具体地，程序610可以包括程序代码，该程序代码包括计算机操作指令。

处理器602可能是CPU，或者是特定集成电路ASIC(Application SpecificIntegrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。智能设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器606，用于存放程序610。存储器606可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序610具体可以用于使得处理器602执行上述多个出行订单处理方法实施例中任一所描述的操作。

程序610中各步骤的具体实现可以参见上述出行订单处理方法实施例中的相应步骤和单元中对应的描述，并具有相应的有益效果，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

需要指出，根据实施的需要，可将本申请实施例中描述的每个部件/步骤拆分为更多部件/步骤，也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的出行订单处理方法。此外，当通用计算机访问用于实现在此示出的出行订单处理方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的出行订单处理方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

以上实施方式仅用于说明本申请实施例，而并非对本申请实施例的限制，有关技术领域的普通技术人员，在不脱离本申请实施例的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本申请实施例的范畴，本申请实施例的专利保护范围应由权利要求限定。

Claims (17)

1.一种出行订单处理方法，包括：

通过第一出行平台接收出行对象发送的出行订单，其中，所述第一出行平台为聚合有多个第二出行平台的聚合平台；

将所述出行订单发送至所述多个第二出行平台，并接收所述多个第二出行平台反馈的应答通知，所述应答通知中携带有可针对所述出行订单提供出行服务的多个候选出行服务提供者的信息；

确定部分或全部所述多个候选出行服务提供者的订单取消率；

根据所述订单取消率，确定目标出行服务提供者。

2.根据权利要求1所述的方法，在确定部分或全部所述多个候选出行服务提供者的订单取消率之前，还包括：

根据预设的平台准入规则，对所述多个候选出行服务提供者进行筛选，获得筛选后的多个候选出行服务提供者的信息。

3.根据权利要求2所述的方法，其中，根据预设的平台准入规则，对所述多个候选出行服务提供者进行筛选，获得筛选后的多个候选出行服务提供者的信息，包括：

获取所述多个第二出行平台分别对应的出行服务平台质量信息；

根据所述出行服务平台质量信息，选择针对所述出行订单的第二出行平台，筛选出被选择的第二出行平台反馈的候选出行服务提供者的信息。

4.根据权利要求1所述的方法，还包括，基于所述出行订单和所述多个候选出行服务提供者的信息，生成多维度特征信息。

5.根据权利要求4所述的方法，其中，所述基于所述出行订单和所述多个候选出行服务提供者的信息，生成多维度特征信息，包括：

根据所述出行订单，确定出行场景信息、与出行对象相关的出行行为信息，并预估所述出行订单的完成信息；

根据所述多个候选出行服务提供者的信息，确定服务提供表现信息；

根据所述出行场景信息、所述与出行对象相关的出行行为信息、所述出行订单的完成信息和所述服务提供表现信息，生成多维度特征信息。

6.根据权利要求1-5任一项所述的方法，其中，所述确定部分或全部所述多个候选出行服务提供者的订单取消率，包括：

获得每个候选出行服务提供者对应的多维度特征信息；

将每个候选出行服务提供者的多维度特征信息分别输入预先训练完成的取消率预估模型，得到所述取消率预估模型输出的候选出行服务提供者的订单取消率。

7.根据权利要求6所述的方法，其中，所述取消率预估模型通过以下方式训练获得：

获取样本出行订单、所述样本出行订单对应的样本出行服务提供者及所述样本出行服务提供者的标签，其中，所述样本出行服务提供者的标签用于表征样本出行服务提供者是否完成了所述样本出行订单；

基于所述样本出行订单和所述样本出行服务提供者的信息，生成多维度样本特征信息；

使用所述多维度样本特征信息和所述样本出行服务提供者的标签，对预设的取消率预估模型进行训练。

8.根据权利要求1-5任一项所述的方法，其中，所述根据所述订单取消率，确定目标出行服务提供者，包括：

若候选出行服务提供者的订单取消率小于第一预设取消率阈值，则将该候选出行服务提供者确定为用于完成所述出行订单的目标出行服务提供者。

9.根据权利要求8所述的方法，其中，所述方法还包括：

若候选出行服务提供者的订单取消率大于或等于第二预设取消率阈值，判断拒单操作的总次数是否大于预设拒单次数阈值；其中，所述第二预设取消率阈值大于所述第一预设取消率阈值；

若大于或等于所述预设拒单次数阈值，则将该候选出行服务提供者确定为用于完成所述出行订单的目标出行服务提供者；

若小于所述预设拒单次数阈值，则对该候选出行服务提供者执行拒单操作。

10.根据权利要求8所述的方法，其中，所述方法还包括：

若候选出行服务提供者的订单取消率大于或等于第二预设取消率阈值，判断接收所述应答通知的时刻与发送所述出行订单的时刻之间的间隔时长是否超过预设间隔时长；其中，所述第二预设取消率阈值大于所述第一预设取消率阈值；

若超过预设间隔时长，则将该候选出行服务提供者确定为用于完成所述出行订单的目标出行服务提供者；

若未超过预设间隔时长，则对该候选出行服务提供者执行拒单操作。

11.根据权利要求9所述的方法，其中，所述方法还包括：

若候选出行服务提供者的订单取消率大于或等于所述第一预设取消率阈值，且小于所述第二预设取消率阈值，则从所述多个第二出行平台再次获取新的候选出行服务提供者的信息；

基于所述出行订单和新的候选出行服务提供者的信息，生成新的多维度特征信息，并基于新的多维度特征信息确定所述新的候选出行服务提供者的订单取消率；

基于原候选出行服务提供者的订单取消率和新的候选出行服务提供者的订单取消率，确定用于完成所述出行订单的目标出行服务提供者。

12.根据权利要求11所述的方法，其中，所述基于原候选出行服务提供者的订单取消率和新的候选出行服务提供者的订单取消率，确定用于完成所述出行订单的目标出行服务提供者，包括：

基于原候选出行服务提供者的订单取消率和新的候选出行服务提供者的订单取消率，确定优选候选出行服务提供者；

若所述优选候选出行服务提供者的订单取消率小于第三预设取消率阈值，则将所述优选候选出行服务提供者确定为用于完成所述出行订单的目标出行服务提供者；其中，所述第三预设取消率阈值大于所述第一预设取消率阈值且小于所述第二预设取消率阈值。

13.根据权利要求12所述的方法，其中，所述方法还包括：

若所述优选候选出行服务提供者的订单取消率大于或等于所述第三预设取消率阈值，则再次从所述多个第二出行平台获取新的候选出行服务提供者的信息；

基于所述出行订单和再次获取的新的候选出行服务提供者的信息，再次生成新的多维度特征信息，并基于再次生成的新的多维度特征信息确定再次获取的新的候选出行服务提供者的订单取消率；

基于再次获取的新的候选出行服务提供者的订单取消率和所述优选候选出行服务提供者的订单取消率，确定用于完成所述出行订单的目标出行服务提供者。

14.一种出行订单处理方法，包括：

接收出行对象输入的出行信息，并根据所述出行信息生成出行订单；

将所述出行订单发送至第一出行平台，以使所述第一出行平台将所述出行订单发送给聚合至所述第一出行平台的多个第二出行平台，并且，基于所述多个第二出行平台针对所述出行订单反馈的多个候选出行服务提供者的信息，确定部分或全部所述多个候选出行服务提供者的订单取消率；

接收所述第一出行平台根据所述订单取消率反馈的目标出行服务提供者的信息。

15.一种出行订单处理方法，包括：

接收第二出行平台发送来的出行订单，其中，所述出行订单为所述第二出行平台从第一出行平台接收，所述第一出行平台中聚合有多个第二出行平台；

根据出行服务提供者对所述出行订单的接受操作，生成响应消息，其中，所述响应消息中携带有所述出行服务提供者的信息；

向所述第二出行平台反馈所述响应消息，以使所述第二出行平台根据所述响应消息向所述第一出行平台反馈所述出行服务提供者的信息，并通过所述第一出行平台确定所述出行服务提供者的订单取消率。

16.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-15中任一所述的出行订单处理方法对应的操作。

17.一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如权利要求1-15中任一所述的出行订单处理方法。

Images