CN111832852A - 一种订单信息处理方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请实施例提供了一种订单信息处理方法、装置、计算机设备及存储介质，所述方法包括：在接收到服务请求端针对已完成订单的负向反馈信息后，确定已完成订单对应的服务行为；获取最近预设时间段内已完成订单对应的服务提供端在上述服务行为下得到负向反馈信息的总订单个数和得到正向反馈信息的总订单个数；根据负向反馈信息对应的总订单个数和正向反馈信息对应的总订单个数，确定已完成订单对应的服务提供端的服务质量信息；根据服务质量信息生成针对已完成订单的服务质量测评结果并反馈给服务提供端。这样，提高了服务质量测评结果的准确度，节省了服务器的处理资源。

Description

一种订单信息处理方法、装置、计算机设备及存储介质

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种订单信息处理方法、装置、计算机设备及存储介质。

背景技术

随着用户的出行需求增加，网约车平台越来越多的被用户使用，网约车平台能够为用户提供出行服务，在订单执行完成后，用户端可以向平台服务器发送服务提供端的服务反馈信息。相应的，平台服务器基于来自用户端的服务反馈信息确认相应的服务提供端的服务质量，以提升网约车的整体服务水平。

平台服务器在接收到用户端针对某一订单的服务反馈信息后，会将该服务反馈信息作为生成服务提供端针对该订单的服务质量信息的依据，针对非事实类服务反馈信息，即平台服务器无法通过语音、导航、行驶路径等事实查证的服务反馈信息，由于平台服务器存在错判、误判等情况，导致针对一些订单的服务质量测评结果不准确，从而浪费了平台服务器中的处理资源。

发明内容

有鉴于此，本申请实施例的目的在于提供一种订单信息处理方法、装置、计算机设备及存储介质，能够提高服务质量测评结果的准确度，节省服务器的处理资源。

第一方面，本申请实施例提供了一种订单信息处理方法，包括：

在接收到服务请求端针对已完成订单的负向反馈信息后，确定所述已完成订单对应的服务行为；

获取最近预设时间段内所述已完成订单对应的服务提供端在所述服务行为下得到负向反馈信息的总订单个数和得到正向反馈信息的总订单个数；

根据所述负向反馈信息对应的总订单个数和所述正向反馈信息对应的总订单个数，确定所述已完成订单对应的服务提供端的服务质量信息；

根据所述服务质量信息生成针对所述已完成订单的服务质量测评结果，并将所述服务质量测评结果反馈给所述服务提供端。

结合第一方面，本申请实施例提供了第一方面的第一种可能的实施方式，其中，所述在接收到服务请求端针对已完成订单的负向反馈信息后，确定所述已完成订单对应的服务行为，具体包括：

在接收到服务请求端针对已完成订单的负向反馈信息后，获取所述负向反馈信息中的服务内容；

根据预设的服务行为与服务内容的映射关系，确定获取的所述服务内容对应的服务行为。

结合第一方面，本申请实施例提供了第一方面的第二种可能的实施方式，其中，所述根据所述负向反馈信息对应的总订单个数和所述正向反馈信息对应的总订单个数，确定所述已完成订单对应的服务提供端的服务质量信息，具体包括：

确定所述负向反馈信息对应的总订单个数与所述正向反馈信息对应的总订单个数的和值；

将所述负向反馈信息对应的总订单个数与所述和值的比值，作为所述已完成订单对应的服务提供端的服务质量信息。

结合第一方面，本申请实施例提供了第一方面的第三种可能的实施方式，其中，所述根据所述服务质量信息生成针对所述已完成订单的服务质量测评结果，具体包括：

根据所述服务提供端的服务质量信息和预设服务质量信息，确定所述服务提供端是否有责的验证目标；

根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述服务提供端的总订单个数，确定所述验证目标对应的目标统计分值；

根据预设的统计分值与置信度的对照关系表，确定所述目标统计分值对应的目标置信度；

根据所述目标置信度与预设置信度阈值的比较结果，生成针对所述已完成订单的服务质量测评结果。

结合第一方面的第三种可能的实施方式，本申请实施例提供了第一方面的第四种可能的实施方式，其中，所述根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述服务提供端的总订单个数，确定所述验证目标对应的目标统计分值，具体包括：

确定所述服务质量信息与所述预设服务质量信息的差值；

根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述已完成订单对应的服务提供端的总订单个数，确定所述验证目标的平均值对应的标准差；

将所述差值与所述标准差的比值，作为所述目标统计分值。

结合第一方面的第三种可能的实施方式，本申请实施例提供了第一方面的第五种可能的实施方式，其中，确定所述预设服务质量信息和所述预设置信度阈值，包括：

获取第二预设历史时间段内具有服务质量测评结果的历史订单以及第一目标历史订单；其中，所述历史订单中包括有责历史订单；所述第一目标历史订单为：在对应目标服务行为的有责历史订单之后完成的预设数量的已完成订单中，存在针对该目标服务行为的负向反馈信息的有责历史订单；

根据所述历史订单以及所述第一目标历史订单，确定服务质量测评信息和服务提供端召回信息；

确定使得所述服务质量测评信息和服务提供端召回信息最大时的所述预设服务质量信息和所述预设置信度阈值。

结合第一方面的第五种可能的实施方式，本申请实施例提供了第一方面的第六种可能的实施方式，其中，根据所述历史订单以及所述第一目标历史订单，确定所述服务质量测评信息，具体包括：

统计所述有责历史订单对应的订单总个数以及所述第一目标历史订单对应的订单总个数；

将所述第一目标历史订单对应的订单总个数与所述有责历史订单对应的订单总个数的比值，作为所述服务质量测评信息。

结合第一方面的第五种可能的实施方式，本申请实施例提供了第一方面的第七种可能的实施方式，其中，根据所述历史订单以及所述第一目标历史订单，确定所述服务提供端召回信息，具体包括：

统计第一目标历史订单的订单总个数以及第二目标历史订单对应的订单总个数；其中，所述历史订单还包括无责历史订单；所述第二目标历史订单为：在所述历史订单之后完成的预设数量的已完成订单中，存在针对所述有责历史订单对应的有责服务行为的负向反馈信息，或者，存在针对所述无责历史订单对应的目标服务行为的负向反馈信息的历史订单；

将所述第一目标历史订单对应的订单总个数与所述第二目标历史订单对应的订单总个数的比值，作为所述服务提供端召回信息。

第二方面，本申请实施例还提供了一种订单信息处理装置，包括：

第一确定模块，用于在接收到服务请求端针对已完成订单的负向反馈信息后，确定所述已完成订单对应的服务行为；

第一获取模块，用于获取最近预设时间段内所述已完成订单对应的服务提供端在所述服务行为下得到负向反馈信息的总订单个数和得到正向反馈信息的总订单个数；

第二确定模块，用于根据所述负向反馈信息对应的总订单个数和所述正向反馈信息对应的总订单个数，确定所述已完成订单对应的服务提供端的服务质量信息；

生成模块，用于根据所述服务质量信息生成针对所述已完成订单的服务质量测评结果；

发送模块，用于将所述服务质量测评结果反馈给所述服务提供端。

结合第二方面，本申请实施例提供了第二方面的第一种可能的实施方式，其中，所述第一确定模块，具体用于：

在接收到服务请求端针对已完成订单的负向反馈信息后，获取所述负向反馈信息中的服务内容；

根据预设的服务行为与服务内容的映射关系，确定获取的所述服务内容对应的服务行为。

结合第二方面，本申请实施例提供了第二方面的第二种可能的实施方式，其中，所述第二确定模块，具体用于：

确定所述负向反馈信息对应的总订单个数与所述正向反馈信息对应的总订单个数的和值；

将所述负向反馈信息对应的总订单个数与所述和值的比值，作为所述已完成订单对应的服务提供端的服务质量信息。

结合第二方面，本申请实施例提供了第二方面的第三种可能的实施方式，其中，所述生成模块，具体用于：

根据所述服务提供端的服务质量信息和预设服务质量信息，确定所述服务提供端是否有责的验证目标；

根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述服务提供端的总订单个数，确定所述验证目标对应的目标统计分值；

根据预设的统计分值与置信度的对照关系表，确定所述目标统计分值对应的目标置信度；

根据所述目标置信度与预设置信度阈值的比较结果，生成针对所述已完成订单的服务质量测评结果。

结合第二方面的第三种可能的实施方式，本申请实施例提供了第二方面的第四种可能的实施方式，其中，所述生成模块，具体用于：

确定所述服务质量信息与所述预设服务质量信息的差值；

根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述已完成订单对应的服务提供端的总订单个数，确定所述验证目标的平均值对应的标准差；

将所述差值与所述标准差的比值，作为所述目标统计分值。

结合第二方面的第三种可能的实施方式，本申请实施例提供了第二方面的第五种可能的实施方式，其中，所述的订单信息处理装置，还包括：

第二获取模块，用于获取第二预设历史时间段内具有服务质量测评结果的历史订单以及第一目标历史订单；其中，所述历史订单中包括有责历史订单；所述第一目标历史订单为：在对应目标服务行为的有责历史订单之后完成的预设数量的已完成订单中，存在针对该目标服务行为的负向反馈信息的有责历史订单；

第三确定模块，用于根据所述历史订单以及所述第一目标历史订单，确定服务质量测评信息和服务提供端召回信息；

第四确定模块，用于确定使得所述服务质量测评信息和服务提供端召回信息最大时的所述预设服务质量信息和所述预设置信度阈值。

结合第二方面的第五种可能的实施方式，本申请实施例提供了第二方面的第六种可能的实施方式，其中，所述第三确定模块，具体用于：

统计所述有责历史订单对应的订单总个数以及所述第一目标历史订单对应的订单总个数；

将所述第一目标历史订单对应的订单总个数与所述有责历史订单对应的订单总个数的比值，作为所述服务质量测评信息。

结合第二方面的第五种可能的实施方式，本申请实施例提供了第二方面的第七种可能的实施方式，其中，所述第三确定模块，具体用于：

统计第一目标历史订单的订单总个数以及第二目标历史订单对应的订单总个数；其中，所述历史订单还包括无责历史订单；所述第二目标历史订单为：在所述历史订单之后完成的预设数量的已完成订单中，存在针对所述有责历史订单对应的有责服务行为的负向反馈信息，或者，存在针对所述无责历史订单对应的目标服务行为的负向反馈信息的历史订单；

将所述第一目标历史订单对应的订单总个数与所述第二目标历史订单对应的订单总个数的比值，作为所述服务提供端召回信息。

第三方面，本申请实施例还提供了一种计算机设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述处理器执行所述机器可读指令，以执行如第一方面任一项所述的订单信息处理方法的步骤。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如第一方面任一项所述的订单信息处理方法的步骤。

本申请实施例提供的一种订单信息处理方法、装置、计算机设备及存储介质，在接收到服务请求端针对已完成订单的负向反馈信息后，确定该负向反馈信息对应的服务行为；通过获取最近预设时间段内已完成订单对应的服务提供端、在上述服务行为信息下的负向反馈信息的总订单个数和正向反馈信息的总订单个数，生成上述服务提供端的服务质量信息并反馈给上述服务提供端。本申请实施例中，在获取到针对某个已完成订单的负向反馈信息后，结合服务提供端在相应服务行为下得到的各个已完成订单对应的负向反馈信息和正向反馈信息，来确定该服务提供端的服务质量信息，并进一步基于该服务质量信息生成针对当前已完成订单的服务质量测评结果，这种方式提高了生成服务质量测评结果的准确度，减少了接收服务提供端的异议反馈信息的数量，从而进一步节省了服务器的处理资源。

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

附图说明

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

图1示出了本申请实施例所提供的一种订单信息处理方法的流程图。

图2示出了本申请实施例所提供的另一种订单信息处理方法的流程图。

图3示出了本申请实施例所提供的另一种订单信息处理方法的流程图。

图4示出了本申请实施例所提供的另一种订单信息处理方法的流程图。

图5示出了本申请实施例所提供的另一种订单信息处理方法的流程图。

图6示出了本申请实施例所提供的另一种订单信息处理方法的流程图。

图7示出了本申请实施例所提供的另一种订单信息处理方法的流程图。

图8示出了本申请实施例所提供的另一种订单信息处理方法的流程图。

图9示出了本申请实施例所提供的一种订单信息处理装置的结构示意图。

图10示出了本申请实施例所提供的一种计算机设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

在网约车出行领域，用户可以通过用户端安装的网约车应用程序(Application，APP)向平台服务器发起出行请求，相应的，平台服务器基于来自用户端的出行请求生成出行订单，并为该出行订单分配相应的服务提供端执行上述出行订单，当上述出行订单完成后，用户还可以通过用户端向平台服务器发送该服务提供端的服务反馈信息。

平台服务器能够基于上述服务反馈信息，确认服务提供端针对上述已完成订单的服务质量。当服务质量较差时，平台服务器会对已完成订单对应的服务提供端进行判责。实际中，针对非事实类负向服务反馈信息，即平台服务器无法通过语音、导航、行驶路径等事实查证的负向服务反馈信息。由于平台服务器存在错判、误判的情况，一直存在服务质量测评结果不被司机认可、判责不准的问题。这样，使得司机在平台上对服务质量测评结果的异议较多，这就需要平台服务器增加对上述异议进行处理的指标进线，从而浪费了平台服务器中的处理资源；并且，司机的服务质量不会得到明显好转，进而无法提升网约车的整体服务水平。

基于此，本申请实施例提供了一种订单信息处理方法、装置、计算机设备及存储介质，能够提高服务质量测评结果的准确度，减少平台服务器中用于处理异议的指标进线，从而节省了服务器的处理资源。

本申请实施例主要应用于针对已完成订单的非事实类服务反馈信息，上述非事实类反馈信息即平台服务器无法通过语音、导航、行驶路径等事实查证的服务反馈信息。比如，针对某一订单，乘客投诉司机绕路，平台服务器可以基于该订单对应的出行时间、起点到终点路况以及司机的行驶路径等事实，确定司机的服务质量信息，该种情况下的投诉即事实类服务反馈信息；而针对某一订单，乘客投诉司机车内脏乱，平台服务器无法获取到有关对应于上述订单的司机车内是否脏乱的事实信息，该种情况下的投诉即非事实类服务反馈信息。

如图1所示，为本申请实施例提供了一种订单信息处理方法，所述方法可以应用于平台服务器，所述方法具体包括：

S101、在接收到服务请求端针对已完成订单的负向反馈信息后，确定所述已完成订单对应的服务行为。

本申请实施例中，服务请求端也即用户端或者乘客端。当订单完成后，用户(也即乘客)可通过乘客端向平台服务器发送对应于该已完成订单的服务反馈信息。其中，上述服务反馈信息可以是评价信息，也可以是投诉信息。作为一种实施方式，评价信息包括以下评价信息中的一种或多种：星级评价信息，问答式评价信息、标签评价信息、文字评价信息。本申请实施例中，负向反馈信息指的是差评信息或者投诉信息。作为一种实施方式，差评信息可以是：三星及三星以下的星级评价信息、差评的标签评价信息、差评的文字评价信息等。

其中，上述负向反馈信息包括负向服务内容，平台服务器在收到上述负向反馈信息后，获取该负向反馈信息中的服务内容，并将获取的服务内容映射到对应的服务行为上。

作为一种实施方式，当乘客对已完成订单对应的服务不满意时，可以通过乘客端向平台服务器发送对应于该已完成订单的差评信息或者投诉信息。其中，上述差评信息中的服务内容包括但不限于：车辆脏乱、车内有异味、危险驾驶等；上述投诉信息中的服务内容包括但不限于：车辆脏乱、车内有异味、危险驾驶等。本申请实施例中，服务行为是从不同的维度来衡量司机的服务，比如，整洁度、服务态度、安全性等。

作为一种实施方式，负向反馈信息中的服务内容为“危险驾驶”，平台服务器在接收到针对具有“危险驾驶”的差评信息时，将该“危险驾驶”映射到“安全性”这一服务行为上。

S102、获取最近预设时间段内所述已完成订单对应的服务提供端在所述服务行为下得到负向反馈信息的总订单个数和得到正向反馈信息的总订单个数。

本申请实施例中，已完成订单中包括如下信息：服务请求端信息(也即乘客信息)、服务提供端信息(也即司机信息)、服务反馈信息(该服务反馈信息可以是负向反馈信息，也可以是正向反馈信息)、以及，服务反馈信息对应的服务行为。平台服务器在接收到针对已完成订单的负向反馈信息后，还能够获知该已完成订单对应的服务提供端信息。

平台服务器在确定了上述已完成订单对应的服务行为和上述已完成订单对应的服务提供端信息后，获取该服务提供端信息在最近预设时间段的历史已完成订单，并从上述历史已完成订单中选取具有针对上述服务行为的负向反馈信息的第一历史已完成订单，并统计第一历史已完成订单的总订单个数；以及，平台服务器从上述历史已完成订单中选取具有针对上述服务行为的正向反馈信息的第二历史已完成订单，并统计第二历史已完成订单的总订单个数。作为一种可选的实施方式，上述最近预设时间段为当前时间之前的过去7天。

本申请实施例中，基于服务提供端在最近时间段内的已完成订单的相关信息，能够更准确的表征司机的行为习惯。同时，考虑到一个司机在7天内完成100单收到4单差评和该司机在7天内完成50单收到4单差评代表的信息量的不同，本申请实施例中，平台服务器综合服务提供端在相应服务行为下的负向反馈信息以及正向反馈信息(也即负向反馈信息的累积的速度)共同作为依据，来确定该服务提供端的服务质量信息，并基于该服务质量信息生生成上述已完成订单的服务质量测评结果，能够进一步提高服务质量测评结果的准确度。

S103、根据所述负向反馈信息对应的总订单个数和所述正向反馈信息对应的总订单个数，确定所述已完成订单对应的服务提供端的服务质量信息。

本申请实施例中，平台服务器基于负向反馈信息对应的总订单个数和正向反馈信息对应的总订单个数，在该已完成订单对应的服务行为下，将相应司机实际中对应于负向反馈信息的订单的密集程度转化为服务质量信息。

这样，平台服务器通过服务质量信息来代表司机服务质量差的程度，来衡量司机在某一服务行为上整体的服务水平，并基于该服务质量信息生成服务质量测评结果，能够提高服务质量测评结果的准确度。

S104、根据所述服务质量信息生成针对所述已完成订单的服务质量测评结果，并将所述服务质量测评结果反馈给所述服务提供端。

作为一种实施方式，平台服务器将服务质量信息输入到预设的判责模型中，该判责模型输出服务质量测评结果，平台服务器将判责模型输出的服务质量测评结果发送给已完成订单对应的服务提供端。

上述订单信息处理方法中，针对每个新增的具有负向反馈信息的已完成订单，平台服务器均可以根据该已完成订单对应的司机服务的实际情况，生成针对上述已完成订单的服务质量测评结果，保证了一反馈一测评，进一步提高了服务质量测评结果的准确度。

本申请实施例提供的一种订单信息处理方法，在接收到服务请求端针对已完成订单的负向反馈信息后，确定该负向反馈信息对应的服务行为；通过获取最近预设时间段内已完成订单对应的服务提供端、在上述服务行为信息下的负向反馈信息的总订单个数和正向反馈信息的总订单个数，生成上述服务提供端的服务质量信息并反馈给上述服务提供端。本申请实施例中，在获取到针对某个已完成订单的负向反馈信息后，结合服务提供端在相应服务行为下得到的各个已完成订单对应的负向反馈信息和正向反馈信息，来确定该服务提供端的服务质量信息，并进一步基于该服务质量信息生成针对当前已完成订单的服务质量测评结果，这种方式提高了生成服务质量测评结果的准确度，减少了接收服务提供端的异议反馈信息的数量，从而进一步节省了服务器的处理资源。

进一步的，如图2所示，本申请实施例提供的订单信息处理方法中，在接收到服务请求端针对已完成订单的负向反馈信息后，确定所述已完成订单对应的服务行为，具体包括：

S201、在接收到服务请求端针对已完成订单的负向反馈信息后，获取所述负向反馈信息中的服务内容。

本申请实施例中，上述负向反馈信息包括以下信息中的一种或多种：差评信息和投诉信息。当乘客对已完成订单对应的服务不满意时，可以通过乘客端向平台服务器发送对应于该已完成订单的差评信息或者投诉信息。其中，上述差评信息中的服务内容包括但不限于：车辆脏乱、车内有异味、危险驾驶等；上述投诉信息中的服务内容包括但不限于：车辆脏乱、车内有异味、危险驾驶等。

S202、根据预设的服务行为与服务内容的映射关系，确定获取的所述服务内容对应的服务行为。

本申请实施例中，服务行为是从不同的维度来衡量司机的服务，比如，整洁度、服务态度、安全性等。平台服务器中预先存储有服务行为与服务内容的映射关系表，平台服务器在获取到负向反馈信息中的服务内容后，从上述服务行为与服务内容的映射关系表中查找上述服务内容对应的服务行为，作为该已完成订单对应的服务行为。

比如，映射关系中服务内容“危险驾驶”对应“安全性”这一服务行为，相应的，平台服务器在确定负向反馈信息中的服务内容为“危险驾驶”时，可以基于上述映射关系表，查找“危险驾驶”对应的“安全性”这一服务行为，。

本申请实施例中，通过将负向反馈信息的负向服务内容映射到相应的服务行为上，能够准确的定位已完成订单的服务问题，进而能够提高针对已完成订单的服务质量测评结果，同时，也便于相应的司机进行服务改进，以提升网约车的整体服务水平。

进一步的，如图3所示，本申请实施例提供的订单信息处理方法中，所述根据所述负向反馈信息对应的总订单个数和所述正向反馈信息对应的总订单个数，确定所述已完成订单对应的服务提供端的服务质量信息，具体包括：

S301、确定所述负向反馈信息对应的总订单个数与所述正向反馈信息对应的总订单个数的和值。

作为一种实施方式，平台服务器从司机过去7天内的历史已完成订单中，统计的第一历史已完成订单的总订单个数为n1，平台服务器从司机过去7天内的历史已完成订单中，统计的第二历史已完成订单的总订单个数为n2，计算上述第一历史已完成订单的总订单个数和第二历史已完成订单的总订单个数的和值为：n1+n2。

S302、将所述负向反馈信息对应的总订单个数与所述和值的比值，作为所述已完成订单对应的服务提供端的服务质量信息。

本申请实施例中，平台服务器按照计算第一历史已完成订单的总订单个数与上述和值的比值，作为已完成订单对应的服务提供端的服务质量信息。

具体实施方式中，平台服务器基于如下公式计算服务质量信息：

其中，neg_rate表示已完成订单对应的服务提供端的服务质量信息，n1表示第一历史已完成订单的总订单个数；n2表示第二历史已完成订单的总订单个数。

进一步的，如图4所示，本申请实施例提供的订单信息处理方法中，平台服务器在确定了服务提供端的服务质量信息后，将该服务质量信息输入到预设的判责模型中，判责模型对所述服务质量信息进行处理，输出针对所述已完成订单的服务质量测评结果的过程，具体包括：

S401、根据所述服务提供端的服务质量信息和预设服务质量信息，确定所述服务提供端是否有责的验证目标。

本申请实施例中，判责模型将服务质量信息与预设服务质量信息进行比较，遵从疑罪从无的规则，得到两个假设目标；

目标H0：服务质量信息(即neg_rate)<预设服务质量信息(即neg_bar)，对应的服务质量测评结果：司机无责；

目标H1：服务质量信息(即neg_rate)>预设服务质量信息(即neg_bar)，对应的服务质量测评结果：司机有责。

作为一种实施方式，本申请实施例中选取“目标H0”作为验证目标，验证“服务质量测评结果为司机有责”的置信度。

S402、根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述服务提供端的总订单个数，确定所述验证目标对应的目标统计分值。

本申请实施例中，在“目标H0”的情况下，其统计量服从一个给定的概率分布，而这在“目标H1”下不会服从上述给定的概率分布。当确定的目标统计分值落在上述给定的概率分布的临界值之外，则验证“目标H0”的置信度较低。因此，上述目标统计分值为用于检验“目标H0”是否可信。

S403、根据预设的统计分值与置信度的对照关系表，确定所述目标统计分值对应的目标置信度。

本申请实施例中，平台服务器中预先存储有预设显著性水平下α下，统计分值与置信度(即概率P)的对照关系表，平台服务器在确定了目标统计分值后，从上述对照关系表中查找上述预设显著性水平下，该目标统计分值对应的目标置信度。

其中，目标置信度也即“服务质量测评结果为司机有责”的置信度，该目标置信度作为生成服务质量测评结果的依据。

S404、根据所述目标置信度与预设置信度阈值的比较结果，生成针对所述已完成订单的服务质量测评结果。

本申请实施例中，判责模型将目标置信度与预设置信度阈值(即sig_level)进行比较，生成针对已完成订单的服务质量测评结果。其中，若目标置信度大于预设置信度阈值，则确定“目标H0”可信，此时，服务质量测评结果为司机无责；若目标置信度小于预设置信度阈值，则确定“目标H0”不可信，相应的，“目标H1”可信，此时，服务质量测评结果为司机有责。

本申请实施例中，通过确定验证目标并确定验证目标的置信度的方式来生成已完成订单的服务质量测评结果，进一步提高了服务质量测评结果的准确性。

进一步的，如图5所示，本申请实施例提供的订单信息处理方法中，所述根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述服务提供端的总订单个数，确定所述验证目标对应的目标统计分值，具体包括：

S501、确定所述服务质量信息与所述预设服务质量信息的差值。

S502、根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述已完成订单对应的服务提供端的总订单个数，确定所述验证目标的平均值对应的标准差。

S503、将所述差值与所述标准差的比值，作为所述目标统计分值。

结合步骤501至步骤503，判责模块通过如下公式计算目标统计分值：

其中，t_score表示目标统计分值，neg_rate表示已完成订单对应的服务提供端的服务质量信息，neg_bar表示预设服务质量信息，neg_bar表示预设服务质量信息，σ表示验证目标的平均值对应的标准差，n表示第一预设历史时间段内已完成订单对应的服务提供端的总订单个数。

本申请实施例中，判责模型是基于预设服务质量信息和预设置信度阈值对已完成订单对应的服务提供端的服务质量信息进行处理，输出针对上述已完成订单的服务质量测评结果，如图6所示，上述预设服务质量信息和上述预设置信度阈值是通过如下方法确定的：

S601、获取第二预设历史时间段内具有服务质量测评结果的历史订单以及第一目标历史订单；其中，所述历史订单中包括有责历史订单；所述第一目标历史订单为：在对应目标服务行为的有责历史订单之后完成的预设数量的已完成订单中，存在针对该目标服务行为的负向反馈信息的有责历史订单。

具体实施方式中，平台服务器预先确定有上述预设服务质量信息对应的第一范围和上述预设置信度阈值对应的第二范围。平台服务器从预设服务质量信息对应有第一范围中选取任一数值作为初始服务质量信息，以及，从预设置信度阈值预先对应有第二范围中选取任一数值作为初始置信度阈值。然后，平台服务器基于初始服务质量信息和初始置信度阈值，对已完成订单进行服务质量测评处理。

之后，平台服务器收集第二预设历史时间段内已完成服务质量测评的历史订单，上述历史订单包括：有责历史订单和无责历史订单；其中，上述有责历史订单即服务质量测评结果为有责的历史订单；上述无责历史订单即服务质量测评结果为无责的历史订单。

同时，平台服务器选择上述历史订单中的有责历史订单，比如，有责历史订单对应“安全性”这一目标服务行为。针对每一个有责历史订单，平台服务器确定该有责历史订单之后完成的20个已完成订单中，是否存在针对“安全性”这一目标服务行为的差评或者投诉，若是，则确定该有责历史订单作为第一目标历史订单。基于上述方式，平台服务器从有责历史订单中，确定上述第一目标历史订单的订单总个数。这里，上述第一目标历史订单也即司机有责且该司机再犯对应的历史订单。

作为一种实施方式，上述第二预设历史时间段可以预先进行设置，比如，设置为半年或者设置为一年。

S602、根据所述历史订单以及所述第一目标历史订单，确定服务质量测评信息和服务提供端召回信息。

具体实施方式中，平台服务器基于第一目标历史订单的订单总个数和有责历史订单的订单总个数，确定已完成订单对应的服务质量测评信息；

平台服务器从历史订单中确定机司机再犯对应的第二目标历史订单的订单总个数，平台服务器基于第一目标历史订单的订单总个数以及上述第二目标历史订单的订单总个数，确定服务提供端对应的服务提供端召回信息。

S603、确定使得所述务质量测评信息和服务提供端召回信息最大时的所述预设服务质量信息和所述预设置信度阈值。

本申请实施例中，平台服务器基于预设服务质量信息对应的第一范围和上述预设置信度阈值对应的第二范围，调整初始服务质量信息和初始置信度阈值，确定使服务质量测评信息和服务提供端召回信息最大时服务质量信息作为预设服务质量信息，确定使服务质量测评信息和服务提供端召回信息最大时的置信度阈值作为预设置信度阈值。

进一步的，如图7所示，本申请实施例提供的订单信息处理方法中，根据所述历史订单以及所述第一目标历史订单，确定所述服务质量测评信息，具体包括：

S701、统计所述有责历史订单对应的订单总个数以及所述第一目标历史订单对应的订单总个数。

本申请实施例中，以第二预设历史时间段为一年为例，平台服务器统计一年内的历史订单中，有责历史订单对应的订单总个数n3，以及，第一目标历史订单对应的订单总个数n4。

S702、将所述第一目标历史订单对应的订单总个数与所述有责历史订单对应的订单总个数的比值，作为所述服务质量测评信息。

具体实施方式中，平台服务器基于如下公式计算服务质量测评信息：

其中，n3表示第二预设历史时间段内有责历史订单对应的订单总个数n3，n4表示第二预设历史时间段内第一目标历史订单对应的订单总个数。

进一步的，如图8所示，本申请实施例提供的订单信息处理方法中，所述历史订单还包括无责历史订单；根据所述历史订单以及所述第一目标历史订单，确定所述服务提供端召回信息，具体包括：

S801、统计第一目标历史订单的订单总个数以及第二目标历史订单对应的订单总个数；其中，所述第二目标历史订单为：在所述历史订单之后完成的预设数量的已完成订单中，存在针对所述有责历史订单对应的有责服务行为的负向反馈信息，或者，存在针对所述无责历史订单对应的目标服务行为的负向反馈信息的历史订单。

本申请实施例中，针对上述历史订单中的有责历史订单，比如，有责历史订单对应的目标服务行为为“安全性”。针对每一个有责历史订单，平台服务器确定该有责历史订单之后完成的20个已完成订单中，是否存在针对“安全性”的差评或者投诉，若是，则确定该有责历史订单作为第二目标历史订单；针对上述历史订单中的无责历史订单，比如，无责历史订单被投诉的目标服务行为为“整洁性”。针对每一个无责历史订单，平台服务器确定该无责历史订单之后完成的20个已完成订单中，是否存在针对“整洁性”的差评或者投诉，若是，则确定该无责历史订单作为第二目标历史订单；基于上述方式，平台服务器从第二预设历史时间段内的历史订单中，确定上述第二目标历史订单的订单总个数n5。

上述第二目标历史订单既包括：司机有责且该司机再犯对应的历史订单，还包括司机无责且该司机再犯对应的历史订单。

S802、将所述第一目标历史订单对应的订单总个数与所述第二目标历史订单对应的订单总个数的比值，作为所述服务提供端召回信息。

具体实施方式中，平台服务器基于如下公式计算服务提供端召回信息：

其中，n4表示第二预设历史时间段内第一目标历史订单对应的订单总个数；n5表示第二预设历史时间段内第二目标历史订单对应的订单总个数。

本申请实施例提供的一种订单信息处理方法，在接收到服务请求端针对已完成订单的负向反馈信息后，确定该负向反馈信息对应的服务行为；通过获取最近预设时间段内已完成订单对应的服务提供端、在上述服务行为信息下的负向反馈信息的总订单个数和正向反馈信息的总订单个数，生成上述服务提供端的服务质量信息并反馈给上述服务提供端。本申请实施例中，在获取到针对某个已完成订单的负向反馈信息后，结合服务提供端在相应服务行为下得到的各个已完成订单对应的负向反馈信息和正向反馈信息，来确定该服务提供端的服务质量信息，并进一步基于该服务质量信息生成针对当前已完成订单的服务质量测评结果，这种方式提高了生成服务质量测评结果的准确度，减少了接收服务提供端的异议反馈信息的数量，从而进一步节省了服务器的处理资源。

基于与上述订单信息处理方法同样的发明构思，如图9所示，本申请实施例还提供了一种订单信息处理装置，所述订单信息处理装置包括：

第一确定模块901，用于在接收到服务请求端针对已完成订单的负向反馈信息后，确定所述已完成订单对应的服务行为；

第一获取模块902，用于获取最近预设时间段内所述已完成订单对应的服务提供端在所述服务行为下得到负向反馈信息的总订单个数和得到正向反馈信息的总订单个数；

第二确定模块903，用于根据所述负向反馈信息对应的总订单个数和所述正向反馈信息对应的总订单个数，确定所述已完成订单对应的服务提供端的服务质量信息；

生成模块904，用于根据所述服务质量信息生成针对所述已完成订单的服务质量测评结果；

发送模块905，用于将所述服务质量测评结果反馈给所述服务提供端。

进一步的，如图9所示，本申请实施例提供的订单信息处理装置中，第一确定模块901，具体用于：

在接收到服务请求端针对已完成订单的负向反馈信息后，获取所述负向反馈信息中的服务内容；

根据预设的服务行为与服务内容的映射关系，确定获取的所述服务内容对应的服务行为。

进一步的，如图9所示，本申请实施例提供的订单信息处理装置中，第二确定模块903，具体用于：

确定所述负向反馈信息对应的总订单个数与所述正向反馈信息对应的总订单个数的和值；

将所述负向反馈信息对应的总订单个数与所述和值的比值，作为所述已完成订单对应的服务提供端的服务质量信息。

进一步的，如图9所示，本申请实施例提供的订单信息处理装置中，生成模块904，具体用于：

根据所述服务提供端的服务质量信息和预设服务质量信息，确定所述服务提供端是否有责的验证目标；

根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述服务提供端的总订单个数，确定所述验证目标对应的目标统计分值；

根据预设的统计分值与置信度的对照关系表，确定所述目标统计分值对应的目标置信度；

根据所述目标置信度与预设置信度阈值的比较结果，生成针对所述已完成订单的服务质量测评结果。

进一步的，如图9所示，本申请实施例提供的订单信息处理装置中，生成模块904，具体用于：

确定所述服务质量信息与所述预设服务质量信息的差值；

根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述已完成订单对应的服务提供端的总订单个数，确定所述验证目标的平均值对应的标准差；

将所述差值与所述标准差的比值，作为所述目标统计分值。

进一步的，本申请实施例提供的订单信息处理装置还包括：

第二获取模块，用于获取第二预设历史时间段内具有服务质量测评结果的历史订单以及第一目标历史订单；其中，所述历史订单中包括有责历史订单；所述第一目标历史订单为：在对应目标服务行为的有责历史订单之后完成的预设数量的已完成订单中，存在针对该目标服务行为的负向反馈信息的有责历史订单；

第三确定模块，用于根据所述历史订单以及所述第一目标历史订单，确定服务质量测评信息和服务提供端召回信息；

第四确定模块，用于确定使得所述服务质量测评信息和服务提供端召回信息最大时的所述预设服务质量信息和所述预设置信度阈值。

进一步的，本申请实施例提供的订单信息处理装置中，第三确定模块，具体用于：

统计所述有责历史订单对应的订单总个数以及所述第一目标历史订单对应的订单总个数；

将所述第一目标历史订单对应的订单总个数与所述有责历史订单对应的订单总个数的比值，作为所述服务质量测评信息。

进一步的，本申请实施例提供的订单信息处理装置中，第三确定模块，第三确定模块，具体用于：

统计第一目标历史订单的订单总个数以及第二目标历史订单对应的订单总个数；其中，所述历史订单还包括无责历史订单；所述第二目标历史订单为：在所述历史订单之后完成的预设数量的已完成订单中，存在针对所述有责历史订单对应的有责服务行为的负向反馈信息，或者，存在针对所述无责历史订单对应的目标服务行为的负向反馈信息的历史订单；

将所述第一目标历史订单对应的订单总个数与所述第二目标历史订单对应的订单总个数的比值，作为所述服务提供端召回信息。

本申请实施例提供的一种订单信息处理装置，在接收到服务请求端针对已完成订单的负向反馈信息后，确定该负向反馈信息对应的服务行为；通过获取最近预设时间段内已完成订单对应的服务提供端、在上述服务行为信息下的负向反馈信息的总订单个数和正向反馈信息的总订单个数，生成上述服务提供端的服务质量信息并反馈给上述服务提供端。本申请实施例中，在获取到针对某个已完成订单的负向反馈信息后，结合服务提供端在相应服务行为下得到的各个已完成订单对应的负向反馈信息和正向反馈信息，来确定该服务提供端的服务质量信息，并进一步基于该服务质量信息生成针对当前已完成订单的服务质量测评结果，这种方式提高了生成服务质量测评结果的准确度，减少了接收服务提供端的异议反馈信息的数量，从而进一步节省了服务器的处理资源。

如图10所示，本申请实施例提供的一种计算机设备100，包括：处理器1001、存储器1002和总线，所述存储器1002存储有所述处理器1001可执行的机器可读指令，当计算机设备运行时，所述处理器1001与所述存储器1002之间通过总线通信，所述处理器1001执行所述机器可读指令，以执行如上述订单信息处理方法的步骤。

具体地，上述存储器1002和处理器1001能够为通用的存储器和处理器，这里不做具体限定，当处理器1001运行存储器1002存储的计算机程序时，能够执行上述订单信息处理方法。

对应于上述订单信息处理方法，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述订单信息处理方法的步骤。

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

本申请实施例中，术语“乘客”、“用户”、“服务请求方”可互换使用，以指代可以请求或订购服务的个人、实体或工具。本申请实施例中，术语“司机”、“服务提供方”可互换使用，以指代可以提供服务的个人、实体或工具。在本申请实施例中，“用户端”、“乘客端”和“服务请求端”可以互换使用，“司机端”和“服务提供端”可以互换使用。

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

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

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

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

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

Claims (11)

1.一种订单信息处理方法，其特征在于，包括：

在接收到服务请求端针对已完成订单的负向反馈信息后，确定所述已完成订单对应的服务行为；

获取最近预设时间段内所述已完成订单对应的服务提供端在所述服务行为下得到负向反馈信息的总订单个数和得到正向反馈信息的总订单个数；

根据所述负向反馈信息对应的总订单个数和所述正向反馈信息对应的总订单个数，确定所述已完成订单对应的服务提供端的服务质量信息；

根据所述服务质量信息生成针对所述已完成订单的服务质量测评结果，并将所述服务质量测评结果反馈给所述服务提供端。

2.根据权利要求1所述的订单信息处理方法，其特征在于，所述在接收到服务请求端针对已完成订单的负向反馈信息后，确定所述已完成订单对应的服务行为，具体包括：

在接收到服务请求端针对已完成订单的负向反馈信息后，获取所述负向反馈信息中的服务内容；

根据预设的服务行为与服务内容的映射关系，确定获取的所述服务内容对应的服务行为。

3.根据权利要求1所述的订单信息处理方法，其特征在于，所述根据所述负向反馈信息对应的总订单个数和所述正向反馈信息对应的总订单个数，确定所述已完成订单对应的服务提供端的服务质量信息，具体包括：

确定所述负向反馈信息对应的总订单个数与所述正向反馈信息对应的总订单个数的和值；

将所述负向反馈信息对应的总订单个数与所述和值的比值，作为所述已完成订单对应的服务提供端的服务质量信息。

4.根据权利要求1所述的订单信息处理方法，其特征在于，所述根据所述服务质量信息生成针对所述已完成订单的服务质量测评结果，具体包括：

根据所述服务提供端的服务质量信息和预设服务质量信息，确定所述服务提供端是否有责的验证目标；

根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述服务提供端的总订单个数，确定所述验证目标对应的目标统计分值；

根据预设的统计分值与置信度的对照关系表，确定所述目标统计分值对应的目标置信度；

根据所述目标置信度与预设置信度阈值的比较结果，生成针对所述已完成订单的服务质量测评结果。

5.根据权利要求4所述的订单信息处理方法，其特征在于，所述根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述服务提供端的总订单个数，确定所述验证目标对应的目标统计分值，具体包括：

确定所述服务质量信息与所述预设服务质量信息的差值；

根据所述服务质量信息、所述预设服务质量信息以及第一预设历史时间段内所述已完成订单对应的服务提供端的总订单个数，确定所述验证目标的平均值对应的标准差；

将所述差值与所述标准差的比值，作为所述目标统计分值。

6.根据权利要求4所述的订单信息处理方法，其特征在于，确定所述预设服务质量信息和所述预设置信度阈值，包括：

获取第二预设历史时间段内具有服务质量测评结果的历史订单以及第一目标历史订单；其中，所述历史订单中包括有责历史订单；所述第一目标历史订单为：在对应目标服务行为的有责历史订单之后完成的预设数量的已完成订单中，存在针对该目标服务行为的负向反馈信息的有责历史订单；

根据所述历史订单以及所述第一目标历史订单，确定服务质量测评信息和服务提供端召回信息；

确定使得所述服务质量测评信息和服务提供端召回信息最大时的所述预设服务质量信息和所述预设置信度阈值。

7.根据权利要求6所述的订单信息处理方法，其特征在于，根据所述历史订单以及所述第一目标历史订单，确定所述服务质量测评信息，具体包括：

统计所述有责历史订单对应的订单总个数以及所述第一目标历史订单对应的订单总个数；

将所述第一目标历史订单对应的订单总个数与所述有责历史订单对应的订单总个数的比值，作为所述服务质量测评信息。

8.根据权利要求6所述的订单信息处理方法，其特征在于，根据所述历史订单以及所述第一目标历史订单，确定所述服务提供端召回信息，具体包括：

统计第一目标历史订单的订单总个数以及第二目标历史订单对应的订单总个数；其中，所述历史订单还包括无责历史订单；所述第二目标历史订单为：在所述历史订单之后完成的预设数量的已完成订单中，存在针对所述有责历史订单对应的有责服务行为的负向反馈信息，或者，存在针对所述无责历史订单对应的目标服务行为的负向反馈信息的历史订单；

将所述第一目标历史订单对应的订单总个数与所述第二目标历史订单对应的订单总个数的比值，作为所述服务提供端召回信息。

9.一种订单信息处理装置，其特征在于，包括：

第一确定模块，用于在接收到服务请求端针对已完成订单的负向反馈信息后，确定所述已完成订单对应的服务行为；

第一获取模块，用于获取最近预设时间段内所述已完成订单对应的服务提供端在所述服务行为下得到负向反馈信息的总订单个数和得到正向反馈信息的总订单个数；

第二确定模块，用于根据所述负向反馈信息对应的总订单个数和所述正向反馈信息对应的总订单个数，确定所述已完成订单对应的服务提供端的服务质量信息；

生成模块，用于根据所述服务质量信息生成针对所述已完成订单的服务质量测评结果；

发送模块，用于将所述服务质量测评结果反馈给所述服务提供端。

10.一种计算机设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1至8任一项所述的订单信息处理方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至8任一项所述的订单信息处理方法的步骤。

Images