CN109409971A - 异常订单处理方法及装置 - Google Patents

Abstract

本申请实施例提供一种异常订单处理方法及装置，涉及计算机技术领域，该方法包括：获得被取消的目标订单的订单信息；当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任。由此可见，本申请实施例技术方案中，可以根据被取消的订单的订单信息，来判断该订单取消是否为接单用户的责任，由于本申请实施例是依据实际订单信息来进行责任认定的，因此认定结果更为客观、符合实际情况，从而可以减少司机因对服务系统做出的责任认定不满意所产生的投诉，降低服务系统的处理压力，提高服务资源利用率。

Description

异常订单处理方法及装置

技术领域

本申请实施例涉及计算机技术领域，特别涉及一种异常订单处理方法及装置。

背景技术

随着互联网技术的快速发展，基于互联网技术的出行服务，为人们的出行带来了越来越多的便利，例如，用户可以通过“网约车”服务系统，乘车出行。目前使用“网约车”服务系统时，司机的权益与订单成交情况密切相关，现有技术中，无论是乘客取消订单还是司机取消订单，均认定是司机责任，导致司机因对服务系统做出的责任认定不满意而向服务系统投诉，进行增加服务系统的处理压力，占用服务资源，影响服务系统中其他应用的正常工作。

发明内容

为了解决上述问题，本申请实施例提供一种异常订单处理方法及装置。

具体地，本申请实施例是通过如下技术方案实现的：

根据本申请实施例的第一方面，提供一种异常订单处理方法，所述方法包括：

获得被取消的目标订单的订单信息；

当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任。

本申请实施例中，所述当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任，包括：

从所述目标订单的订单信息中提取一个或多个特征信息；

根据提取到的特征信息及预先生成的判责模型，计算所述目标订单对应的概率值；

当所述目标订单对应的概率值达到所述设定的概率阈值时，确定所述目标订单的接单用户无责任。

本申请实施例中，所述判责模型的生成过程包括：

获得被取消的多个历史订单的订单信息；

从所述多个历史订单的订单信息中提取各自的特征信息；

使用逻辑回归LR算法对所述历史订单的特征信息进行训练，得到判责模型。

本申请实施例中，所述特征信息，包括：

接单时间、订单取消时间、订单轨迹的经纬度、接单用户与发单用户的历史订单取消记录、派单的距离、接单用户接到发单用户的时间、订单预计路程长短、订单起始地和目的地地理位置，及订单预计时间长短。

本申请实施例中，所述设定的无责条件，包括：

在接单用户前往目标订单中指定的上车点的过程中发单用户取消目标订单，或接单用户已到达目标订单中指定的上车点后的预设第二时长后该接单用户取消目标订单。

本申请实施例中，在所述当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任之后，还包括：

对所述接单用户的属性进行修正，其中，所述属性包括：服务分和/或订单成交率。

根据本申请实施例的第二方面，提供一种异常订单处理装置，所述装置包括：

第一获得模块，用于获得被取消的目标订单的订单信息；

责任确定模块，用于在所述第一获得模块获得的目标订单的订单信息满足设定的无责条件的情况下，确定所述目标订单的接单用户无责任。

本申请实施例中，所述责任确定模块，包括：

特征信息提取子模块，用于从所述获得模块获得的目标订单的订单信息中提取一个或多个特征信息；

概率值计算子模块，用于根据所述特征信息提取子模块提取到的特征信息及预先生成的判责模型，计算所述目标订单对应的概率值；

责任确定子模块，用于在所述概率值计算子模块计算出的目标订单对应的概率值达到所述设定的概率阈值的情况下，确定所述目标订单的接单用户无责任；

本申请实施例中，所述装置还包括：

第二获得模块，用于获得被取消的多个历史订单的订单信息；

特征信息提取模块，用于从所述多个历史订单的订单信息中提取各自的特征信息；

判责模型训练模块，用于使用逻辑回归LR算法对所述历史订单的特征信息进行训练，得到判责模型。

本申请实施例中，所述特征信息，包括：

接单时间、订单取消时间、订单轨迹的经纬度、接单用户与发单用户的历史订单取消记录、派单的距离、接单用户接到发单用户的时间、订单预计路程长短、订单起始地和目的地地理位置，及订单预计时间长短。

本申请实施例中，所述设定的无责条件，包括：

在接单用户前往目标订单中指定的上车点的过程中发单用户取消目标订单，或接单用户已到达目标订单中指定的上车点后的预设第二时长后该接单用户取消目标订单。

本申请实施例中，所述装置还包括：

修正模块，用于在所述确定模块确定所述目标订单的接单用户无责任的情况下，对所述接单用户的属性进行修正，其中，所述属性包括：服务分和/或订单成交率。

根据本申请实施例的第三方面，提供一种计算机存储介质，所述存储介质中存储有程序指令，所述程序指令包括：

获得被取消的目标订单的订单信息；

当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任。

本申请实施例中，可以根据被取消的订单的订单信息，来判断该订单取消是否为接单用户的责任，由于本申请实施例是依据实际订单信息来进行责任认定的，因此认定结果更为客观、符合实际情况，从而可以减少司机因对服务系统做出的责任认定不满意所产生的投诉，降低服务系统的处理压力，提高服务资源利用率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请实施例。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请实施例，并与说明书一起用于解释本发明的原理。

图1是本申请实施例根据一示例性实施例示出的一种异常订单处理方法的流程图；

图2是本申请实施例根据一示例性实施例示出的另一种异常订单处理方法的流程图；

图3是本申请实施例根据一示例性实施例示出的另一种异常订单处理方法的流程图；

图4是本申请实施例根据一示例性实施例示出的一种异常订单处理装置的框图；

图5是本申请实施例根据一示例性实施例示出的另一种异常订单处理装置的框图；

图6是本申请实施例根据一示例性实施例示出的另一种异常订单处理装置的框图；

图7是本申请实施例根据一示例性实施例示出的另一种异常订单处理装置的框图；

图8是本申请实施例根据一示例性实施例示出的一种用于异常订单处理装置的一结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请实施例的一些方面相一致的装置和方法的例子。

在本申请实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请实施例。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

随着互联网技术的快速发展，基于互联网技术的出行服务，为人们的出行带来了越来越多的便利，例如，用户可以通过“网约车”服务系统，乘车出行。目前使用“网约车”服务系统时，司机的权益与订单成交情况密切相关，现有技术中，无论是乘客取消订单还是司机取消订单，均认定是司机责任，导致司机因对服务系统做出的责任认定不满意而向服务系统投诉，进行增加服务系统的处理压力，占用服务资源，影响服务系统中其他应用的正常工作。为了解决上述问题，本申请实施例提供了一种异常订单处理方法及装置。

下面首先对本申请实施例提供的一种异常订单处理方法进行介绍。

如图1所示，图1是本申请实施例根据一示例性实施例示出的一种异常订单处理方法的流程图，该方法可以包括以下步骤：

在步骤101中，获得被取消的目标订单的订单信息。

在使用“网约车”出行的场景下，乘客可以通过终端设备中安装的网约车软件乘客端发布出行需求，终端设备将乘客的出行需求发送给服务器，服务器在接收到终端设备发送的出行需求后，基于该出行需求中描述的行程起点和行程终点生成出行订单，并发布，司机通过终端设备中安装的网约车软件司机端接单，当司机接单成功后，司机与乘客建立承运关系，司机驾车去接乘客，其中，网约车辆指的是网络预约汽车，包括：出租车、专车、快车、顺风车及大巴车等等。

本申请实施例中，被取消的目标订单指的是被取消的出行订单，在实际应用中，目标订单可以是由接单用户取消的，也可以是由发单用户取消的，其中，接单用户指的是司机，发单用户指的是乘客。

本申请实施例中，订单信息可以包括乘客发布的出行需求信息、订单发布后司机和乘客的行为信息及司机和乘客的历史出行行为信息，具体的可以包括：接单时间、订单取消时间、订单轨迹的经纬度、接单用户与发单用户的历史订单取消记录、派单的距离、接单用户接到发单用户的时间、订单预计路程长短、订单起始地和目的地地理位置，及订单预计时间长短等等。

在步骤102中，当该目标订单的订单信息满足设定的无责条件时，确定该目标订单的接单用户无责任。

本申请实施例中，设定的无责条件指的是系统预先设定的接单用户无责任的条件，如果目标订单的订单信息满足系统预先设定的接单用户无责任的条件，则确定目标订单的接单用户无责任。

由上述实施例可见，该实施例可以根据被取消的订单的订单信息，来判断该订单取消是否为接单用户的责任，由于本申请实施例是依据实际订单信息来进行责任认定的，因此认定结果更为客观、符合实际情况，从而可以减少司机因对服务系统做出的责任认定不满意所产生的投诉，降低服务系统的处理压力，提高服务资源利用率。

如图2所示，图2是本申请实施例根据一示例性实施例示出的另一种异常订单处理方法的流程图，本申请实施例中，可以根据预先生成的判责模型来判断目标订单的接单用户是否有责任，此时，该方法可以包括以下步骤：

在步骤201中，获得被取消的目标订单的订单信息。

本申请实施例中的步骤201与图1所示实施例中的步骤101类似，本申请实施例对此不再赘述，详情请见图1所示实施例中的内容。

在步骤202中，从该目标订单的订单信息中提取一个或多个特征信息。

本申请实施例中，订单的特征信息可以包括：接单时间、订单取消时间、订单轨迹的经纬度、接单用户与发单用户的历史订单取消记录、派单的距离、接单用户接到发单用户的时间、订单预计路程长短、订单起始地和目的地地理位置，及订单预计时间长短等等。

在步骤203中，根据提取到的特征信息及预先生成的判责模型，计算该目标订单对应的概率值。

本申请实施例中，可以利用基于LR(Logistic Regression，逻辑回归)的判责模型，判断目标订单的接单用户是否有责任。

具体的，判责模型的生成过程包括以下步骤：S20、S21和S22，其中：

在S20中，获得被取消的多个历史订单的订单信息；

本申请实施例中，被取消的历史订单指的是已完成正确地责任认定的、被取消的出行订单。

在S21中，从多个历史订单的订单信息中提取各自的特征信息；

本申请实施例中，订单的特征信息包括但不限于以下信息：接单时间、订单取消时间、订单轨迹的经纬度、接单用户与发单用户的历史订单取消记录、派单的距离、接单用户接到发单用户的时间、订单预计路程长短、订单起始地和目的地地理位置，及订单预计时间长短等等。

在S22中，使用逻辑回归LR算法对历史订单的特征信息进行训练，得到判责模型。

本申请实施例中，逻辑回归是一种分类方法，主要用于解决两分类问题(即输出只有两种，分别代表两个分类)，逻辑回归算法利用Logistic函数(或称为Sigmoid函数)，该函数的曲线形式为S型曲线，函数形式为：

对于线性边界的情况，边界形式如下：

利用公式(1)和公式(2)构造预测函数：

其中，θ_i为权重值，x_i为特征信息i对应的特征值，通常情况下对于一个订单来说，如果该订单中存在特征信息i，则x_i取值为1，否则取值为0，θ^T＝[θ₁,θ₂,...,θ_n]，x＝[x₁,x₂,...,x_n]。

本申请实施例中，针对每个被取消且责任认定明确的历史订单，将该订单的特征信息进行向量化表示，并将向量化表示的结果，带入公式(3)中。对大量的被取消且责任认定明确的历史订单均进行如上处理，可以得到大量函数，之后对前述大量函数进行迭代求解，计算得到θ^T＝[θ₁,θ₂,...,θ_n]，从而获得判责模型，即一个由多个特征信息对应的特征值及各特征值对应的权重值构成的概率函数：

需要说明的是，本申请实施例中，判责模型的输入是目标订单的订单信息，判责模型的输出是一个概率值，该概率值的取值范围为0～1，在实际应用中，概率值的取值越接近于0，目标订单的取消行为越有可能是司机的责任，概率值的取值越接近于1，目标订单的取消行为越有可能是乘客的责任。

具体的，对于目标订单，在对该目标订单进行责任认定时，首先提取该目标订单的特征信息，之后将目标订单的特征信息进行向量化表示，最后将向量化表示结果带入到判责模型的函数中，得到一个函数值，即一个概率值。

在步骤204中，当该目标订单对应的概率值达到设定的概率阈值时，确定该目标订单的接单用户无责任。

本申请实施例中，设定的概率阈值可以取值为0.7，也可以根据实际需求进行设置，本申请实施例对此不作限定。

由上述实施例可见，该实施例中可以基于大量的被取消的历史订单生成判责模型，并使用该判责模型对目标订单的取消行为进行责任认定，因此认定结果更为客观、符合实际情况，从而可以减少司机因对服务系统做出的责任认定不满意所产生的投诉，降低服务系统的处理压力，提高服务资源利用率。

如图3所示，图3是本申请实施例根据一示例性实施例示出的另一种异常订单处理方法的流程图，本申请实施例中，可以依据实际的出行场景经验，设定一些具体的无责条件来判断目标订单的接单用户是否有责任，此时，该方法可以包括以下步骤：

在步骤301中，获得被取消的目标订单的订单信息。

本申请实施例中的步骤301与图1所示实施例中的步骤101类似，本申请实施例对此不再赘述，详情请见图1所示实施例中的内容。

在步骤302中，当该目标订单的订单信息满足设定的无责条件时，确定该目标订单的接单用户无责任，其中，该设定的无责条件，包括：在接单用户前往目标订单中指定的上车点的过程中发单用户取消目标订单，或接单用户已到达目标订单中指定的上车点后的预设第二时长后该接单用户取消目标订单。

考虑到实际应用中，司机正在去接乘客的路上时乘客取消订单，司机已经到达或者将要到达上车点时乘客取消订单，及司机已经达到上车点后一直联系不上乘客等情况，订单的取消行为通常不是司机的责任，因此在本申请实施例中可以设定相应的无责条件，只要目标订单的订单信息满足该无责条件中的一条，就认定目标订单的订单取消行为不是司机的责任。

需要说明的是，可以根据实际需求对本申请实施例中的第一时长和第二时长的取值进行设置，本申请实施例对此不作限定。

由上述实施例可见，该实施例中可以依据实际约车场景来设定无责条件，并使用该无责条件对目标订单的取消行为进行责任认定，因此认定结果更为客观、符合实际情况，从而可以减少司机因对服务系统做出的责任认定不满意所产生的投诉，降低服务系统的处理压力，提高服务资源利用率。

考虑到在实际的网约车服务系统中，订单被取消会引起成交率下降，影响到司机后续的奖励发放，因此为了维护司机的权益，在本申请实施例提供的另一种实施例中，该实施例可以在图1～图3所示任一方法实施例的基础上，在确定目标订单的接单用户无责任的步骤之后，增加以下步骤：

对接单用户的属性进行修正，其中，该属性包括：服务分和/或订单成交率。

在本申请实施例中，司机的订单成交率发生降低时返回原成交率，服务分降低时返回原服务分等，从而维护正当司机的正当权益。

应当注意，尽管在附图中以特定顺序描述了本申请实施例方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

与前述异常订单处理方法的实施例对应，本申请实施例还提供了异常订单处理装置的实施例。

如图4所示，图4是本申请实施例根据一示例性实施例示出的一种异常订单处理装置的框图，所述装置还可以包括：

第一获得模块410，用于获得被取消的目标订单的订单信息；

在使用“网约车”出行的场景下，乘客可以通过终端设备中安装的网约车软件乘客端发布出行需求，终端设备将乘客的出行需求发送给服务器，服务器在接收到终端设备发送的出行需求后，基于该出行需求中描述的行程起点和行程终点生成出行订单，并发布，司机通过终端设备中安装的网约车软件司机端接单，当司机接单成功后，司机与乘客建立承运关系，司机驾车去接乘客，其中，网约车辆指的是网络预约汽车，包括：出租车、专车、快车、顺风车及大巴车等等。

本申请实施例中，被取消的目标订单指的是被取消的出行订单，在实际应用中，目标订单可以是由接单用户取消的，也可以是由发单用户取消的，其中，接单用户指的是司机，发单用户指的是乘客。

本申请实施例中，订单信息可以包括乘客发布的出行需求信息、订单发布后司机和乘客的行为信息及司机和乘客的历史出行行为信息，具体的可以包括：接单时间、订单取消时间、订单轨迹的经纬度、接单用户与发单用户的历史订单取消记录、派单的距离、接单用户接到发单用户的时间、订单预计路程长短、订单起始地和目的地地理位置，及订单预计时间长短等等。

责任确定模块420，用于在所述第一获得模块410获得的目标订单的订单信息满足设定的无责条件的情况下，确定所述目标订单的接单用户无责任。

本申请实施例中，设定的无责条件指的是系统预先设定的接单用户无责任的条件，如果目标订单的订单信息满足系统预先设定的接单用户无责任的条件，则确定目标订单的接单用户无责任。

由上述实施例可见，该实施例可以根据被取消的订单的订单信息，来判断该订单取消是否为接单用户的责任，由于本申请实施例是依据实际订单信息来进行责任认定的，因此认定结果更为客观、符合实际情况，从而可以减少司机因对服务系统做出的责任认定不满意所产生的投诉，降低服务系统的处理压力，提高服务资源利用率。

如图5所示，图5是本申请实施例根据一示例性实施例示出的另一种异常订单处理装置的框图，该实施例可以在图4所示实施例的基础上，可以根据预先生成的判责模型来判断目标订单的接单用户是否有责任，所述责任确定模块420，可以包括：

特征信息提取子模块421，用于从所述获得模块获得的目标订单的订单信息中提取一个或多个特征信息；

本申请实施例中，订单的特征信息可以包括：接单时间、订单取消时间、订单轨迹的经纬度、接单用户与发单用户的历史订单取消记录、派单的距离、接单用户接到发单用户的时间、订单预计路程长短、订单起始地和目的地地理位置，及订单预计时间长短等等。

概率值计算子模块422，用于根据所述特征信息提取子模块421提取到的特征信息及预先生成的判责模型，计算所述目标订单对应的概率值；

本申请实施例中，可以利用基于LR(Logistic Regression，逻辑回归)的判责模型，判断目标订单的接单用户是否有责任。

责任确定子模块423，用于在所述概率值计算子模块422计算出的目标订单对应的概率值达到所述设定的概率阈值的情况下，确定所述目标订单的接单用户无责任。

如图6所示，图6是本申请实施例根据一示例性实施例示出的另一种异常订单处理装置的框图，该实施例可以在图5所示实施例的基础上，所述装置还包括：

第二获得模块610，用于获得被取消的多个历史订单的订单信息；

本申请实施例中，被取消的历史订单指的是已完成正确地责任认定的、被取消的出行订单。

特征信息提取模块620，用于从所述多个历史订单的订单信息中提取各自的特征信息；

本申请实施例中，订单的特征信息包括但不限于以下信息：接单时间、订单取消时间、订单轨迹的经纬度、接单用户与发单用户的历史订单取消记录、派单的距离、接单用户接到发单用户的时间、订单预计路程长短、订单起始地和目的地地理位置，及订单预计时间长短等等。

判责模型训练模块630，用于使用逻辑回归LR算法对所述历史订单的特征信息进行训练，得到判责模型。

本申请实施例中，逻辑回归是一种分类方法，主要用于解决两分类问题(即输出只有两种，分别代表两个分类)，逻辑回归算法利用Logistic函数(或称为Sigmoid函数)，该函数的曲线形式为S型曲线，函数形式为：

对于线性边界的情况，边界形式如下：

利用公式(1)和公式(2)构造预测函数：

其中，θ_i为权重值，x_i为特征信息i对应的特征值，通常情况下对于一个订单来说，如果该订单中存在特征信息i，则x_i取值为1，否则取值为0，θ^T＝[θ₁,θ₂,...,θ_n]，x＝[x₁,x₂,...,x_n]。

本申请实施例中，针对每个被取消且责任认定明确的历史订单，将该订单的特征信息进行向量化表示，并将向量化表示的结果，带入公式(3)中。对大量的被取消且责任认定明确的历史订单均进行如上处理，可以得到大量函数，之后对前述大量函数进行迭代求解，计算得到θ^T＝[θ₁,θ₂,...,θ_n]，从而获得判责模型，即一个由多个特征信息对应的特征值及各特征值对应的权重值构成的概率函数：

需要说明的是，本申请实施例中，判责模型的输入是目标订单的订单信息，判责模型的输出是一个概率值，该概率值的取值范围为0～1，在实际应用中，概率值的取值越接近于0，目标订单的取消行为越有可能是司机的责任，概率值的取值越接近于1，目标订单的取消行为越有可能是乘客的责任。

具体的，对于目标订单，在对该目标订单进行责任认定时，首先提取该目标订单的特征信息，之后将目标订单的特征信息进行向量化表示，最后将向量化表示结果带入到判责模型的函数中，得到一个函数值，即一个概率值。

本申请实施例中，设定的概率阈值可以取值为0.7，也可以根据实际需求进行设置，本申请实施例对此不作限定。

由上述实施例可见，该实施例中可以基于大量的被取消的历史订单生成判责模型，并使用该判责模型对目标订单的取消行为进行责任认定，因此认定结果更为客观、符合实际情况，从而可以减少司机因对服务系统做出的责任认定不满意所产生的投诉，降低服务系统的处理压力，提高服务资源利用率。

本申请实施例提供的另一种实施例中，该实施例可以在图4所示实施例的基础上，本申请实施例中，可以依据实际的出行场景经验，设定一些具体的无责条件来判断目标订单的接单用户是否有责任，所述设定的无责条件，可以包括：

在接单用户前往目标订单中指定的上车点的过程中发单用户取消目标订单，或接单用户已到达目标订单中指定的上车点后的预设第二时长后该接单用户取消目标订单。

考虑到实际应用中，司机正在去接乘客的路上时乘客取消订单，司机已经到达或者将要到达上车点时乘客取消订单，及司机已经达到上车点后一直联系不上乘客等情况，订单的取消行为通常不是司机的责任，因此在本申请实施例中可以设定相应的无责条件，只要目标订单的订单信息满足该无责条件中的一条，就认定目标订单的订单取消行为不是司机的责任。

需要说明的是，可以根据实际需求对本申请实施例中的第一时长和第二时长的取值进行设置，本申请实施例对此不作限定。

由上述实施例可见，该实施例中可以依据实际约车场景来设定无责条件，并使用该无责条件对目标订单的取消行为进行责任认定，因此认定结果更为客观、符合实际情况，从而可以减少司机因对服务系统做出的责任认定不满意所产生的投诉，降低服务系统的处理压力，提高服务资源利用率。

考虑到在实际的网约车服务系统中，订单被取消会引起成交率下降，影响到司机后续的奖励发放，因此为了维护司机的权益，此时，如图7所示，图7是本申请实施例根据一示例性实施例示出的另一种异常订单处理装置的框图，该实施例可以在上述任一装置实施例的基础上，所述装置还可以包括：

修正模块710，用于在所述责任确定模块420确定所述目标订单的接单用户无责任的情况下，对所述接单用户的属性进行修正，其中，所述属性包括：服务分和/或订单成交率。

在本申请实施例中，司机的订单成交率发生降低时返回原成交率，服务分降低时返回原服务分等，从而维护正当司机的正当权益。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请实施例还提供了一种计算机存储介质，所述存储介质中存储有程序指令，所述程序指令包括：获得被取消的目标订单的订单信息；当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任。

本申请实施例可采用在一个或多个其中包含有程序代码的存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。计算机可用存储介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于：相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

如图8所示，图8是本申请实施例根据一示例性实施例示出的一种用于异常订单处理装置800的一结构示意图。例如，装置800可以被提供为一服务器。参照图8，装置800包括处理组件822，其进一步包括一个或多个处理器，以及由存储器832所代表的存储器资源，用于存储可由处理部件822的执行的指令，例如应用程序。存储器832中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件822被配置为执行指令，以执行本申请实施例提供的异常订单处理方法，该方法包括：获得被取消的目标订单的订单信息；当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任。

装置800还可以包括一个电源组件826被配置为执行装置800的电源管理，一个有线或无线网络接口850被配置为将装置800连接到网络，和一个输入输出(I/O)接口858。装置800可以操作基于存储在存储器832的操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM或类似。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器832，上述指令可由装置800的处理组件822执行以完成本申请实施例提供的上述异常订单处理方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本申请实施例的其它实施方案。本申请实施例旨在涵盖本申请实施例的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请实施例未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请实施例的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请实施例并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请实施例的范围仅由所附的权利要求来限制。

Claims (13)

1.一种异常订单处理方法，其特征在于，所述方法包括：

获得被取消的目标订单的订单信息；

当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任。

2.根据权利要求1所述的方法，其特征在于，所述当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任，包括：

从所述目标订单的订单信息中提取一个或多个特征信息；

根据提取到的特征信息及预先生成的判责模型，计算所述目标订单对应的概率值；

当所述目标订单对应的概率值达到所述设定的概率阈值时，确定所述目标订单的接单用户无责任。

3.根据权利要求2所述的方法，其特征在于，所述判责模型的生成过程包括：

获得被取消的多个历史订单的订单信息；

从所述多个历史订单的订单信息中提取各自的特征信息；

使用逻辑回归LR算法对所述历史订单的特征信息进行训练，得到判责模型。

4.根据权利要求3所述的方法，其特征在于，所述特征信息，包括：

接单时间、订单取消时间、订单轨迹的经纬度、接单用户与发单用户的历史订单取消记录、派单的距离、接单用户接到发单用户的时间、订单预计路程长短、订单起始地和目的地地理位置，及订单预计时间长短。

5.根据权利要求1所述的方法，其特征在于，所述设定的无责条件，包括：

在接单用户前往目标订单中指定的上车点的过程中发单用户取消目标订单，或接单用户已到达目标订单中指定的上车点后的预设第二时长后该接单用户取消目标订单。

6.根据权利要求1所述的方法，其特征在于，在所述当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任之后，还包括：

对所述接单用户的属性进行修正，其中，所述属性包括：服务分和/或订单成交率。

7.一种异常订单处理装置，其特征在于，所述装置包括：

第一获得模块，用于获得被取消的目标订单的订单信息；

责任确定模块，用于在所述第一获得模块获得的目标订单的订单信息满足设定的无责条件的情况下，确定所述目标订单的接单用户无责任。

8.根据权利要求7所述的装置，其特征在于，所述责任确定模块，包括：

特征信息提取子模块，用于从所述获得模块获得的目标订单的订单信息中提取一个或多个特征信息；

概率值计算子模块，用于根据所述特征信息提取子模块提取到的特征信息及预先生成的判责模型，计算所述目标订单对应的概率值；

责任确定子模块，用于在所述概率值计算子模块计算出的目标订单对应的概率值达到所述设定的概率阈值的情况下，确定所述目标订单的接单用户无责任。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

第二获得模块，用于获得被取消的多个历史订单的订单信息；

特征信息提取模块，用于从所述多个历史订单的订单信息中提取各自的特征信息；

判责模型训练模块，用于使用逻辑回归LR算法对所述历史订单的特征信息进行训练，得到判责模型。

10.根据权利要求9所述的装置，其特征在于，所述特征信息，包括：

接单时间、订单取消时间、订单轨迹的经纬度、接单用户与发单用户的历史订单取消记录、派单的距离、接单用户接到发单用户的时间、订单预计路程长短、订单起始地和目的地地理位置，及订单预计时间长短。

11.根据权利要求7所述的装置，其特征在于，所述设定的无责条件，包括：

在接单用户前往目标订单中指定的上车点的过程中发单用户取消目标订单，或接单用户已到达目标订单中指定的上车点后的预设第二时长后该接单用户取消目标订单。

12.根据权利要求7所述的装置，其特征在于，所述装置还包括：

修正模块，用于在所述确定模块确定所述目标订单的接单用户无责任的情况下，对所述接单用户的属性进行修正，其中，所述属性包括：服务分和/或订单成交率。

13.一种计算机存储介质，其特征在于，所述存储介质中存储有程序指令，所述程序指令包括：

获得被取消的目标订单的订单信息；

当所述目标订单的订单信息满足设定的无责条件时，确定所述目标订单的接单用户无责任。