CN111582962B - 一种服务状态识别方法及装置 - Google Patents

Abstract

本申请提供了一种服务状态识别方法及装置，其中，该方法包括：将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段，确定目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率；确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列；针对每种服务状态序列，基于目标服务提供端每个轨迹子段的服务状态预测概率、参考服务提供端的总数量、符合该服务状态序列的参考服务提供端的数量，确定目标服务提供端的行驶轨迹与该服务状态序列的匹配概率；选取匹配概率符合预设条件的目标服务状态序列，并基于目标服务状态序列中各轨迹子段的服务状态，确定目标服务提供端行驶轨迹匹配的服务状态，以便准确识别目标服务提供端的服务状态。

Description

一种服务状态识别方法及装置

技术领域

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

背景技术

随着互联网的快速发展和普及，各类互联网服务产品也层出不穷，例如打车平台等。目前，打车平台成为了公众出行的重要方式，乘客端经常通过打车平台预约出租汽车进行打车。

对于打车平台来说，打车平台的服务器可以接收乘客端的乘车请求，进而生成乘车订单，并将乘车订单派发至司机端。但是，司机端在执行乘车订单的过程中可能会出现一些异常服务状态：一种是跳单状态，即司机端提前结束乘车订单，但之后仍继续提供乘车服务，此段乘车服务的费用是乘客端与司机端私下结算的，跳单行为表面上看是司机与乘客之间的交易行为，但实际上跳单后打车平台无法对司机与乘客的后续行为进行监控，将带来巨大的安全隐患；另一种是刷单状态，乘客端发送乘车请求、服务器派发乘车订单以及司机端执行乘车订单的过程都是正常的，但是实际上司机端的使用者和乘客端的使用者为同一个人或相关人员，导致司机并没有真正为乘客端提供乘车服务，这会降低车辆与乘客之间的资源配置效率。然而，目前服务器无法针对以上异常服务状态进行有效识别。

发明内容

有鉴于此，本申请实施例的目的在于提供一种服务状态识别方法及装置，以使服务器能够对跳单、刷单等异常服务状态进行有效识别，进一步提高安全性及资源配置效率。

第一方面，本申请提供一种服务状态识别方法，包括：

将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段，并确定所述目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率；

确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列；

针对每种服务状态序列，基于所述目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率；

从多种服务状态序列中选取出所述匹配概率符合预设条件的目标服务状态序列，并基于所述目标服务状态序列中各轨迹子段对应的服务状态，确定所述目标服务提供端的行驶轨迹匹配的服务状态。

一种可能的实施方式中，所述方法还包括：

获取所述目标提供端的订单信息；

所述将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段，包括：

将所述目标服务提供端的行驶轨迹与所述订单信息中每个服务订单对应的行驶轨迹进行匹配，确定所述目标服务提供端的行驶轨迹中的跑单轨迹段和巡游轨迹段；

将每个跑单轨迹段划分为多个轨迹子段，以及，将每个巡游轨迹段划分为多个轨迹段。

一种可能的实施方式中，在将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段之后，还包括：

确定每个轨迹子段对应的轨迹信息，以及，确定每个轨迹子段对应的订单信息；

所述确定所述目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率，包括：

针对每个轨迹子段，基于该轨迹子段对应的所述目标服务提供端的轨迹信息和订单信息、该轨迹子段对应的参考服务提供端的参考轨迹信息和参考订单信息、以及预先训练的服务状态预测模型，确定所述目标服务提供端的该轨迹子段被标记为每种服务状态的预测概率。

一种可能的实施方式中，所述轨迹信息包括以下信息中的至少一种：

每个轨迹点的位置坐标；驶过每个轨迹点的时间点；行驶速度；

所述订单信息包括以下信息中的至少一种：

服务提供端信息；服务请求端信息；订单起始时间；订单持续时间；订单行程路线；订单起始地点和目的地点。

一种可能的实施方式中，所述确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列，包括：

从每个轨迹子段对应的多种服务状态中任意选择一种服务状态，将选择出的各轨迹子段分别对应的服务状态构成一种服务状态序列。

一种可能的实施方式中，所述基于所述目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率，包括：

基于参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定该服务状态序列的状态转移概率；

将每个轨迹子段对应的服务状态的预测概率和所述状态转移概率进行相乘，得到所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率。

一种可能的实施方式中，所述基于参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定该服务状态序列的状态转移概率，包括：

将历史时间段内符合该服务状态序列的参考服务提供端的数量与所述参考服务提供端的总数量之间的比值，确定为该服务状态序列的状态转移概率。

一种可能的实施方式中，所述从多种服务状态序列中选取出所述匹配概率符合预设条件的目标服务状态序列，包括：

从多种服务状态序列中选取出所述匹配概率最高的目标服务状态序列。

一种可能的实施方式中，所述服务状态包括异常服务状态和正常服务状态，所述异常服务状态为刷单状态或跳单状态；

所述基于所述目标服务状态序列中各轨迹子段对应的服务状态，确定所述目标服务提供端的行驶轨迹匹配的服务状态，包括：

基于所述目标服务状态序列中包括的服务状态的总数量、和异常服务状态的数量，确定所述目标服务提供端的行驶轨迹被标记为异常服务状态的发生概率；

若所述发生概率大于设定阈值，则确定所述目标服务提供端的行驶轨迹匹配的服务状态为异常服务状态。

一种可能的实施方式中，若确定所述目标服务提供端的行驶轨迹匹配的服务状态为异常服务状态，则所述方法还包括：

向所述目标服务提供端发送用于提示出现异常服务状态的提示信息。

第二方面，本申请提供一种服务状态识别装置，包括：

获取模块，用于获取目标服务提供端的行驶轨迹，并将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段；

预测概率确定模块，用于确定所述目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率；

服务状态序列确定模块，用于确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列；

匹配概率确定模块，用于针对每种服务状态序列，基于所述目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率；

服务状态确定模块，用于从多种服务状态序列中选取出所述匹配概率符合预设条件的目标服务状态序列，并基于所述目标服务状态序列中各轨迹子段对应的服务状态，确定所述目标服务提供端的行驶轨迹匹配的服务状态。

一种可能的设计中，所述获取模块，还用于：

获取所述目标提供端的订单信息；

所述获取模块，在将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段时，具体用于：

将所述目标服务提供端的行驶轨迹与所述订单信息中每个服务订单对应的行驶轨迹进行匹配，确定所述目标服务提供端的行驶轨迹中的跑单轨迹段和巡游轨迹段；

将每个跑单轨迹段划分为多个轨迹子段，以及，将每个巡游轨迹段划分为多个轨迹段。

一种可能的设计中，所述获取模块，还用于：确定每个轨迹子段对应的轨迹信息，以及，确定每个轨迹子段对应的订单信息；

所述预测概率确定模块，在确定所述目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率时，具体用于：

针对每个轨迹子段，基于该轨迹子段对应的所述目标服务提供端的轨迹信息和订单信息、该轨迹子段对应的参考服务提供端的参考轨迹信息和参考订单信息、以及预先训练的服务状态预测模型，确定所述目标服务提供端的该轨迹子段被标记为每种服务状态的预测概率。

一种可能的设计中，所述轨迹信息包括以下信息中的至少一种：

每个轨迹点的位置坐标；驶过每个轨迹点的时间点；行驶速度；

所述订单信息包括以下信息中的至少一种：

服务提供端信息；服务请求端信息；订单起始时间；订单持续时间；订单行程路线；订单起始地点和目的地点。

一种可能的设计中，所述服务状态序列确定模块，在确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列时，具体用于：

从每个轨迹子段对应的多种服务状态中任意选择一种服务状态，将选择出的各轨迹子段分别对应的服务状态构成一种服务状态序列。

一种可能的设计中，所述匹配概率确定模块，在基于所述目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率时，具体用于：

基于参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定该服务状态序列的状态转移概率；

将每个轨迹子段对应的服务状态的预测概率和所述状态转移概率进行相乘，得到所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率。

一种可能的设计中，所述匹配概率确定模块，在基于参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定该服务状态序列的状态转移概率时，具体用于：

将历史时间段内符合该服务状态序列的参考服务提供端的数量与所述参考服务提供端的总数量之间的比值，确定为该服务状态序列的状态转移概率。

一种可能的设计中，所述服务状态确定模块，在从多种服务状态序列中选取出所述匹配概率符合预设条件的目标服务状态序列时，具体用于：

从多种服务状态序列中选取出所述匹配概率最高的目标服务状态序列。

一种可能的设计中，所述服务状态包括异常服务状态和正常服务状态，所述异常服务状态为刷单状态或跳单状态；

所述服务状态确定模块，在基于所述目标服务状态序列中各轨迹子段对应的服务状态，确定所述目标服务提供端的行驶轨迹匹配的服务状态时，具体用于：

基于所述目标服务状态序列中包括的服务状态的总数量、和异常服务状态的数量，确定所述目标服务提供端的行驶轨迹被标记为异常服务状态的发生概率；

若所述发生概率大于设定阈值，则确定所述目标服务提供端的行驶轨迹匹配的服务状态为异常服务状态。

一种可能的设计中，所述装置还包括：

发送模块，用于在确定所述目标服务提供端的行驶轨迹匹配的服务状态为异常服务状态之后，向所述目标服务提供端发送用于提示出现异常服务状态的提示信息。

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

第四方面，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面或上述第一方面任一种可能的实施方式中所述的服务状态识别方法的步骤。

本申请实施例中，通过目标服务提供端每个轨迹子段对应的服务状态预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，来确定出目标服务提供端的行驶轨迹与该服务状态序列的匹配概率，再根据匹配概率筛选出目标服务状态序列，进而可以根据目标服务状态序列中各轨迹子段的服务状态，确定出整段行驶轨迹的服务状态。采用上述方式，结合了目标服务提供端在各个轨迹子段预测出的服务状态，以及其它参考服务提供端在整段行驶轨迹中的服务状态的整体情况，相比现有技术，不仅仅是针对目标服务提供端服务状态的局部情况，还考虑到了其它参考服务提供端在这段行驶轨迹所处服务状态的整体情况，以此使目标服务提供端服务状态的识别过程考虑到更加全面的因素，由此可以准确识别出目标服务提供端在整段行驶轨迹中的服务状态，以便有效识别出目标服务提供端的异常服务状态，从而提高服务过程中的安全性及服务资源配置效率。

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

附图说明

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

图1是本申请一些实施例提供的服务***的框图；

图2示出了本申请实施例所提供的一种服务状态识别方法的流程图；

图3示出了本申请实施例所提供的一种服务状态识别方法的另一流程图；

图4示出了本申请实施例所提供的一种服务状态识别方法中预处理具体过程的流程图；

图5示出了本申请实施例所提供的一种服务状态识别方法中匹配概率确定方法的具体执行过程流程图；

图6示出了本申请实施例所提供的一种服务状态识别装置的结构示意图；

图7示出了本申请实施例所提供的一种电子设备的结构示意图。

具体实施方式

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

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

为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“网上打车场景”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其它实施例和应用场景。虽然本申请主要围绕网上打车场景进行描述，但是应该理解，这仅是一个示例性实施例。本申请可以应用于任何其它交通运输类型，或者其它服务场景，例如网上订餐场景等。

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

值得注意的是，在本申请提出申请之前，目前服务***很难对目标服务提供端的服务状态进行识别，故无法有效识别出目标服务提供端可能出现的异常服务状态，进而导致服务过程中的安全性很难保障、或者导致服务资源配置不合理的问题。针对这一问题，本实施例中，通过目标服务提供端每个轨迹子段对应的服务状态预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，来确定出目标服务提供端的行驶轨迹与该服务状态序列的匹配概率，再根据匹配概率筛选出目标服务状态序列，进而可以根据目标服务状态序列中各轨迹子段的服务状态，确定出整段行驶轨迹的服务状态。

采用上述方式，结合了目标服务提供端在各个轨迹子段预测出的服务状态，以及其它参考服务提供端在整段行驶轨迹中的服务状态的整体情况，因此，不仅是针对目标服务提供端服务状态的局部情况，还考虑到了其它参考服务提供端在这段行驶轨迹所处服务状态的整体情况，以此使目标服务提供端服务状态的识别过程考虑到更加全面的因素，由此可以准确识别出目标服务提供端在整段行驶轨迹中的服务状态，以便有效识别出目标服务提供端的异常服务状态，从而提高服务过程中的安全性及服务资源配置效率。

在介绍本申请提供的服务状态识别方法之前，首先对本申请可适用的服务***进行示例性说明。参照图1所示，为本申请一些实施例提供的服务***的框图。例如，服务***可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。服务***可以包括服务器110、网络120、服务请求方终端130、服务提供方终端140和数据库150中的一种或多种，服务器110中可以包括执行指令操作的处理器。

在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式***)。在一些实施例中，服务器110相对于终端，可以是本地的、也可以是远程的。例如，服务器110可以经由网络120访问存储在服务请求方终端130、服务提供方终端140、或数据库150、或其任意组合中的信息和/或数据。作为另一示例，服务器110可以直接连接到服务请求方终端130、服务提供方终端140和数据库150中至少一个，以访问存储的信息和/或数据。

在一些实施例中，服务器110可以包括处理器。处理器可以处理与服务请求有关的信息和/或数据，以执行本申请中描述的一个或多个功能。例如，处理器可以基于从服务提供方终端140获取的行驶轨迹以及订单信息等来预测服务提供方终端140的服务状态等。

网络120可以用于信息和/或数据的交换。在一些实施例中，服务***100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140和数据库150)可以通过网络120向其它组件发送信息和/或数据。例如，服务器110可以经由网络120从服务提供方终端140获取行驶轨迹或订单信息等。在一些实施例中，网络120可以是任何类型的有线或者无线网络，或者是他们的结合。

在一些实施例中，服务请求方终端130可以包括移动设备、平板计算机、膝上型计算机、或机动车辆中的内置设备等，或其任意组合。在一些实施例中，移动设备可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，或其任意组合。

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

数据库150可以存储数据和/或指令。在一些实施例中，数据库150可以存储从服务请求方终端130和/或服务提供方终端140获得的数据。在一些实施例中，数据库150可以存储在本申请中描述的示例性方法的数据和/或指令。

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

结合上述应用背景以及给出的服务***的相关说明，对本申请提供的服务状态识别方法进行详细介绍。

实施例一：

参照图2所示，为本申请实施例提供的一种服务状态识别方法的流程示意图，该服务状态识别方法可以由图1的服务***中的服务器来执行，具体执行过程包括如下步骤：

步骤S201、将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段，并确定目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率。

需要说明的是，这段行驶轨迹可以为目标服务提供端在目标时间段内的行驶轨迹。具体的，服务器获取到目标服务提供端在目标时间段内的行驶轨迹后，将该行驶轨迹划分为多个轨迹子段，然后，确定这些轨迹子段中的各轨迹子段分别被标记为每种服务状态的预测概率。

一示例中，服务状态包括正常服务状态和异常服务状态，异常服务状态例如包括跳单状态、刷单状态等。相应的，确定出的预测概率可以包括目标服务提供端在某个轨迹子段的行驶过程中处于正常服务状态的概率和处于异常服务状态的概率。

本申请实施例中，上述预测概率可以是服务器通过预先训练的服务状态预测模型计算而得到的。服务状态预测模型例如为梯度提升树(Gradient Boosting Decison Tree，GBDT)模型、或其它机器学习模型等。一示例中，服务器可以利用GBDT模型，计算出目标服务提供端在每个轨迹子段中处于正常服务状态的概率和处于异常服务状态的概率。

当然，一个轨迹子段中正常服务状态的预测概率与异常服务状态的预测概率之和不一定为100％，也有可能预测出的结果中还包括了“未完成”、“无法确定”等状态，在这种情况下，服务状态预测模型分别输出的正常服务状态预测概率与异常服务状态预测概率之间并无确定关系。

例如，GBDT模型输出正常服务状态的预测概率为30％，输出异常服务状态的预测概率为60％，其中剩下的10％，即为“未完成”和/或“无法确定”等情况的服务状态。

步骤S202、确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列。

本实施例中，由于每个轨迹子段可以对应正常服务状态或异常服务状态这两种不同的服务状态，而步骤S201中划分出轨迹子段的数量为多个，因此，这些轨迹子段便可以组成多种不同的服务状态序列。

例如，目标服务提供端在目标时间段内的行驶轨迹被划分为了A、B、C这三个轨迹子段，针对A、B、C这三个轨迹子段，多种的服务状态序列包括有：“A正常服务状态—B正常服务状态—C正常服务状态”、“A异常服务状态—B异常服务状态—C异常服务状态”、“A正常服务状态—B正常服务状态—异常服务状态”、“A正常服务状态—B异常服务状态—C异常服务状态”、“A异常服务状态—B正常服务状态—C正常服务状态”、“A异常服务状态—B异常服务状态—C正常服务状态”、“A正常服务状态—B异常服务状态—C正常服务状态”、“A异常服务状态—B正常服务状态—C异常服务状态”，共八种服务状态序列。

步骤S203、针对每种服务状态序列，基于目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定目标服务提供端的行驶轨迹与该服务状态序列的匹配概率。

针对步骤S202中的每种服务状态序列，利用步骤S201中每个轨迹子段对应的两种不同服务状态预测概率、其它也经过了轨迹子段的参考服务提供端的总数量、以及这些参考服务提供端中符合该服务状态序列的参考服务提供端的数量，来确定由多个轨迹子段组成的整段行驶轨迹能够匹配到该服务状态序列的匹配概率。其中，这些参考服务提供端是在目标时间段之前的历史时间段内经过轨迹子段。

当然，这些参考服务提供端中也可以包括有目标服务提供端。可以理解为，若目标服务提供端在目标时间段之前的历史时间段内也经过了轨迹子段，则将该目标服务提供端作为多个参考服务提供端之一。

本步骤也可以理解为，将上述这些概率和数量等数值(即每个轨迹子段对应的服务状态预测概率、其它也经过了轨迹子段的参考服务提供端的总数量、以及这些参考服务提供端中符合该服务状态序列的参考服务提供端的数量)作为确定匹配概率的过程所需考虑的因素。例如，可以按照一定比率提取这些数值，然后通过相乘和/或相加等概率计算方式来进行匹配概率的计算。

例如，目标服务提供端在目标时间段内的行驶轨迹被划分为了A、B、C这三个轨迹子段，即目标服务提供端在目标时间段内经过A、B、C这三个轨迹子段，通过步骤S201可以确定出目标服务提供端在A段的行驶过程中处于正常服务状态的概率值为a1和处于异常服务状态的概率值为a2、目标服务提供端在B段的行驶过程中处于正常服务状态的概率值为b1和处于异常服务状态的概率值为b2、以及目标服务提供端在C段的行驶过程中处于正常服务状态的概率值为c1和处于异常服务状态的概率值为c2，共六种概率。已知在目标时间段之前的历史时间段内，从A子段行驶至B子段的参考服务提供端的总数量为i、其中符合“A异常服务状态—B正常服务状态”的参考服务提供端的数量为j、其中符合“A异常服务状态—B异常服务状态”的参考服务提供端的数量为k、在历史时间段内从B子段行驶至C子段的参考服务提供端的总数量为x、其中符合“B正常服务状态—C异常服务状态”的参考服务提供端的数量为y、以及其中符合“B异常服务状态—C异常服务状态”的参考服务提供端的数量z。

如果针对的某种服务状态序列为“A异常服务状态—B正常服务状态—C异常服务状态”，则利用上述数值中的a2、b1、c2、i、j、x以及y，来确定目标服务提供端在目标时间段内的整体行驶轨迹与“A异常服务状态—B正常服务状态—C异常服务状态”这一服务状态序列的匹配概率，即将数值a2、b1、c2、i、j、x以及y作为确定匹配概率的过程所需的因素。

同样的，如果针对的某种服务状态序列为“A异常服务状态—B异常服务状态—C异常服务状态”，则利用上述数值中的a2、b2、c2、i、k、x以及z，来确定目标服务提供端在目标时间段内的整体行驶轨迹与“A异常服务状态—B异常服务状态—C异常服务状态”这一服务状态序列的匹配概率，即将数值a2、b2、c2、i、k、x以及z作为确定匹配概率的过程所需的因素。

步骤S204、从多种服务状态序列中选取出匹配概率符合预设条件的目标服务状态序列，并基于目标服务状态序列中各轨迹子段对应的服务状态，确定目标服务提供端的行驶轨迹匹配的服务状态。

本步骤中，从上述这些服务状态序列(例如步骤S202中的八种服务状态序列)中，选取出匹配概率符合预设条件的目标服务状态序列。示例性的，预设条件可以预设条件可以为其匹配概率的值最大的目标服务状态序列、其匹配概率的值大于预设值的目标服务状态序列等多种预设条件。相应地，可以从这些服务状态序列中选取出匹配概率最大的作为目标服务状态序列，也可以从这些服务状态序列中选取出匹配概率大于一定预设值的作为目标服务状态序列。

在一种实施方式中，匹配概率为数值的形式，则可以直接将多种服务状态序列的匹配概率之间进行对比，确定匹配概率值最大的服务状态序列为目标服务状态序列，即整体的待识别轨迹段的目标服务状态序列。

在另一种实施方式中，匹配概率表示为图形的形式，例如折线图，则可以通过折线图查找出匹配概率值最大的服务状态序列，确定匹配概率值最大的服务状态序列为目标服务状态序列，即整体的待识别轨迹段的目标服务状态序列。

然后，根据该目标服务状态序列中各轨迹子段对应的服务状态是异常或正常，来确定步骤S201中划分轨迹子段之前整体的行驶轨迹所匹配的服务状态。

例如，在各轨迹子段对应的服务状态中，可以在异常服务状态的数量大于正常服务状态的数量时，确定由各轨迹子段组成的整体行驶轨迹所匹配的整体服务状态为异常服务状态。举个例子，假设目标服务状态序列为“A正常服务状态—B异常服务状态—C异常服务状态—D正常服务状态—E异常服务状态—F异常服务状态”，其中，正常服务状态的数量为2个，异常服务状态的数量为4个，因此异常服务状态的数量大于正常服务状态的数量，则确定由各轨迹子段组成的整体行驶轨迹所匹配的整体服务状态为异常服务状态。

当然，也可以在各轨迹子段对应的服务状态中的异常服务状态数量所占比率超出一定的预设范围时，确定由各轨迹子段组成的整体行驶轨迹所匹配的整体服务状态为异常服务状态。例如，假设异常服务状态数量所占比率的预设范围为80％-100％，目标服务状态序列为“A正常服务状态—B异常服务状态—C异常服务状态—D正常服务状态—E异常服务状态”，其中，正常服务状态的数量为2个，异常服务状态的数量为3个，因此异常服务状态的数量所占比率为60％，而60％不在80％-100％的预设范围内，则确定由各轨迹子段组成的整体行驶轨迹所匹配的整体服务状态为正常服务状态。

并且，本申请实施例中，若确定目标司机的行驶轨迹匹配的服务状态为异常服务状态，则向目标司机发送用于提示出现异常服务状态的提示信息。具体的，服务器可以对异常服务状态的目标司机端发送提示信息。例如，当服务器识别出目标司机处于异常服务状态或之前的某段时间内处于异常服务状态，则服务器推送消息至该目标司机端，以提示该目标司机停止异常服务状态或避免以后再进入异常服务状态。又例如，当服务器识别出目标司机处于异常服务状态的时间段大于预设时间段(例如1个月内有1周时间处于异常服务状态)，则可以减少对该目标司机的订单派发量等。

本实施例中，步骤S201中得出的预测概率仅仅为最开始的局部预测值，是作为后续步骤S203中确定最终整体概率的多种考虑因素之一。因此，通过目标服务提供端每个轨迹子段对应的服务状态预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，来确定出目标服务提供端的行驶轨迹与该服务状态序列的匹配概率，再根据匹配概率筛选出目标服务状态序列，进而可以根据目标服务状态序列中各轨迹子段的服务状态，确定出整段行驶轨迹的服务状态。采用上述方式，结合了目标服务提供端在各个轨迹子段预测出的服务状态，以及其它参考服务提供端在整段行驶轨迹中的服务状态的整体情况，相比现有技术，不仅仅是针对目标服务提供端服务状态的局部情况，还考虑到了其它参考服务提供端在这段行驶轨迹所处服务状态的整体情况，以此使目标服务提供端服务状态的识别过程考虑到更加全面的因素，由此可以准确识别出目标服务提供端在整段行驶轨迹中的服务状态，以便有效识别出目标服务提供端的跳单、刷单等异常服务状态，从而提高服务过程中的安全性及服务资源配置效率。

实施例二：

本实施例二中，主要对服务状态识别的具体过程进行详细说明。本实施例以目标服务提供端为目标司机、参考服务提供端为参考司机为例进行说明。参照图3所示，服务状态识别方法的具体执行过程包括如下步骤：

步骤S301、服务器获取目标司机在目标时间段内行驶过的轨迹信息和目标司机在目标时间段内的订单信息。

其中的目标时间段可以为当前的时间段，也可以为之前的时间段中任意选取出的某个时间段。因此，目标时间段内的轨迹信息及订单信息可以为当前轨迹信息及订单信息、也可以为历史某个时间段内的轨迹信息及订单信息等。例如，目标时间段可以为从当前时刻算起至当前时刻之前的5个小时内，或者可以为上个月的某一天24小时内，或也可以为当前本周的一周内等多种情况的目标时间段。

其中，订单信息可以包括司机信息、乘客信息、订单起始时间、订单持续时间、订单路线、订单起始地点等等。这些订单信息可以直接从上述图1所述的服务***的数据库中获取。

需要说明的是，轨迹信息可以包括定位数据、时间数据、行驶路线、行驶速度、行驶轨迹、停留点信息等等。这些轨迹信息的获取过程可以通过定位***(如全球定位***(Global Positioning System，GPS)、北斗卫星导航***、基站、卫星等)、各种传感器(如三轴陀螺仪、四轴陀螺仪等)以及上述图1所述的服务***的数据库中等获取。

步骤S302、服务器将目标司机轨迹信息中的行驶轨迹与订单信息中每个服务订单对应的行驶轨迹进行匹配，以确定目标司机的行驶轨迹中的跑单轨迹段和巡游轨迹段。

该步骤的过程也可以理解为服务器对目标司机轨迹信息中的行驶轨迹进行预处理的过程，参照图4所示，预处理的具体过程可以包括如下步骤：

步骤S401、服务器对行驶轨迹中定位到的轨迹数据进行过滤，以清理轨迹中明显有误的轨迹数据。

例如，较短时间内定位到的距离较远的两段轨迹数据、偏离整体轨迹路线的定位数据等都可以为明显有误的轨迹数据。

步骤S402、服务器对过滤后的行驶轨迹进行停留段识别。

本步骤可以理解为，服务器根据目标司机的行驶速度对过滤后的行驶轨迹进行停留区域检测，得到若干个停留段。例如在目标司机的行驶速度低于每小时120m的情况下确定目标司机处于停留段，该停留段(包括停留点)的信息可以包括停留段周围环境信息、兴趣点(Point of Interest，POI)(如学校、小区、加油站、餐馆、公交站及地铁站等)、停留段的位置，该位置可以是一个经纬度数据，也可以是由多个经纬度数据围成的区域。

步骤S403、服务器基于若干个停留段的信息，通过将订单信息中每个服务订单对应的行驶轨迹与过滤后的行驶轨迹进行匹配，来对过滤后的行驶轨迹进行分段，得到停留段、跑单轨迹段和巡游轨迹段。

本步骤中，在对行驶轨迹进行匹配时，可以进行轨迹点的匹配，既可以包括位置坐标点的匹配，也可以包括时间点的匹配。需要说明的是，在时间点的匹配过程中，订单信息中包括有每个服务订单的执行时间段，进而才能将服务订单的执行时间段中各个时间点与行驶轨迹中经过各个轨迹点的时间点之间进行匹配。

步骤S404、服务器从分出的若干个跑单轨迹段和若干个巡游轨迹段中确定待识别轨迹段。

即本实施例主要针对该待识别轨迹段进行服务状态的识别。当然，也可以针对分出的所有的跑单轨迹段和所有的巡游轨迹段进行服务状态识别，即将分出的所有的跑单轨迹段和所有的巡游轨迹段作为待识别轨迹段。

步骤S405、服务器基于路况信息和/或道路网信息，将该待识别轨迹段与道路网进行道路匹配，以将该待识别轨迹段匹配至最合理的道路上。

通过本步骤可以将这段待识别轨迹段匹配至最合理最有可能行驶的道路上，其中道路匹配的方法可以包括基于地理位置的道路匹配方法、基于拓扑结构的道路匹配方法、基于概率的道路匹配方法以及将上述这些方法结合使用的道路匹配方法等。一种可能的实施方式中作为一个优选方案，在上述步骤中，先从分段出的跑单轨迹段、巡游轨迹段中选出待识别轨迹段，之后只需针对该待识别轨迹段进行道路匹配以及后续的处理过程，从而节省不必要的计算处理过程。

需要说明的是，跑单轨迹段和巡游轨迹段的内容不同，即跑单轨迹段为目标司机执行订单的过程，巡游轨迹段为目标司机没有在执行订单的过程，例如边行驶边寻找订单的过程、或结束订单执行过程后前往目标司机私人目的地的过程。而刷单状态是指乘客端发送乘车请求、服务器派发乘车订单以及司机端执行乘车订单的过程都是正常的，但是实际上司机端的使用者和乘客端的使用者为同一个人或相关人员，导致司机并没有真正为乘客端提供乘车服务；跳单状态是指司机端提前结束乘车订单，但之后仍继续提供乘车服务，此段乘车服务的费用是乘客端与司机端私下结算的，例如，目标车司机同时注册两个或以上打车平台，在这两个或以上打车平台上同时听单，然后在这些平台推送的订单中选择其中一个订单，这不仅浪费了打车平台的资源，也使打车平台的服务效率降低。

因此，异常服务状态中的刷单状态针对跑单轨迹段而进行，而异常服务状态中的跳单状态针对巡游轨迹段而进行。跑单轨迹段和巡游轨迹段会由于行驶目的、服务内容的不同而需要做出区分。通过区分出行驶轨迹中的跑单轨迹段和巡游轨迹段，使之后的具体识别过程是分为跑单、巡游这两种不同前提情况的，以便后续对待识别轨迹段的概率预测、概率匹配等过程更加具有针对性以及更加精确。

在上述步骤S302中的预处理过程完成后，参照图3所示，继续执行如下步骤：

步骤S303、服务器便将匹配后的每个跑单轨迹段划分为多个轨迹子段，以及，将匹配后的每个巡游轨迹段划分为多个轨迹段。

若分出的所有的跑单轨迹段和所有的巡游轨迹段全部为待识别轨迹段，则服务器便将匹配后的每个跑单轨迹段划分为多个轨迹子段，以及，将匹配后的每个巡游轨迹段划分为多个轨迹段。

当然，若待识别轨迹段仅为分出的所有跑单轨迹段和所有巡游轨迹段中的某部分行驶轨迹或某一个行驶轨迹，则服务器仅针对待识别轨迹段进行划分，将其划分为多个轨迹子段。

对于划分轨迹子段的具体过程，可以采用距离等分、时间等分的方式，也可以采用路网信息匹配等方式。具体的，服务器可以根据道路网信息中的道路名称、道路分布情况以及区域划分情况，对匹配后的待识别轨迹段进行划分，从而得到多个轨迹子段。服务器也可以按照时间等分或距离等分的方式，将匹配后的待识别轨迹段划分为多个轨迹子段。当然，服务器也可以按照随机划分或等分划分的方式将匹配后的待识别轨迹段划分为多个轨迹子段。

步骤S304、服务器确定出每个轨迹子段对应的轨迹信息，以及，确定出每个轨迹子段对应的订单信息。

其中，订单信息包括以下信息中的至少一种：司机信息、服务请求端信息、订单起始时间、订单持续时间、订单行程路线、订单起始地点和目的地点。轨迹信息包括以下信息中的至少一种：每个轨迹点的位置坐标、驶过每个轨迹点的时间点、行驶速度。其中的行驶速度可以是驶过轨迹点的瞬时速度，也可以是驶过轨迹子段的平均速度。

步骤S305、针对每个轨迹子段，服务器基于该轨迹子段对应的目标司机的轨迹信息和订单信息、该轨迹子段对应的参考司机的参考轨迹信息和参考订单信息、以及预先训练的服务状态预测模型，确定目标司机的该轨迹子段被标记为每种服务状态的预测概率。

本步骤中，服务器可以利用预先训练好的服务状态预测模型对每个轨迹子段对应的目标司机行驶过程的异常服务状态概率进行预测，得到每个轨迹子段的预测概率。

步骤S306、确定目标服务提供端的行驶轨迹与该服务状态序列的匹配概率。

一种可能的实施方式中，参照图5所示，为本申请实施例提供的匹配概率确定方法的具体流程示意图，该匹配概率确定方法的具体执行过程包括如下步骤：

步骤S501、从每个轨迹子段对应的多种服务状态中任意选择一种服务状态，将选择出的各轨迹子段分别对应的服务状态构成一种服务状态序列。

例如，多个轨迹子段为A、B、C这三个轨迹子段，则多种的服务状态序列包括有：“A正常服务状态—B正常服务状态—C正常服务状态”、“A异常服务状态—B异常服务状态—C异常服务状态”、“A正常服务状态—B正常服务状态—异常服务状态”、“A正常服务状态—B异常服务状态—C异常服务状态”、“A异常服务状态—B正常服务状态—C正常服务状态”、“A异常服务状态—B异常服务状态—C正常服务状态”、“A正常服务状态—B异常服务状态—C正常服务状态”、“A异常服务状态—B正常服务状态—C异常服务状态”，共八种服务状态序列。

步骤S502、针对每种服务状态序列，基于参考司机的总数量、以及历史时间段内符合该服务状态序列的参考司机的数量，确定该服务状态序列的状态转移概率。

一些实施例中，将历史时间段内符合该服务状态序列的参考司机的数量与参考司机的总数量之间的比值，确定为该服务状态序列的状态转移概率。

例如，还是A、B、C这三个轨迹子段，已知从A子段行驶至B子段的参考司机的总数量为i、其中符合“A异常服务状态—B正常服务状态”的参考司机的数量为j、其中符合“A异常服务状态—B异常服务状态”的参考司机的数量为k、在历史时间段内从B子段行驶至C子段的参考司机的总数量为x、其中符合“B正常服务状态—C异常服务状态”的参考司机的数量为y、以及其中符合“B异常服务状态—C异常服务状态”的参考司机的数量z。

如果针对的服务状态序列为“A异常服务状态—B正常服务状态—C异常服务状态”，则该服务状态序列的状态转移概率包括有：j/i和y/x；如果针对的服务状态序列为“A异常服务状态—B异常服务状态—C异常服务状态”，则该服务状态序列的状态转移概率包括有：k/i和z/x。

步骤S503、将每个轨迹子段对应的服务状态的预测概率和状态转移概率进行相乘，得到目标司机的行驶轨迹与该服务状态序列的匹配概率。

具体的，针对每个状态序列，将该状态序列中每个轨迹子段对应的服务状态预测概率与上述状态转移概率进行相乘，得到目标司机的行驶轨迹与该服务状态序列的匹配概率，即目标司机在整个待识别轨迹段中的服务状态符合该状态序列的最终整体概率。

例如，还是A、B、C这三个轨迹子段，通过上述步骤确定出目标司机在A段中的服务状态为正常服务状态的概率为10％和为异常服务状态的概率为20％、目标司机在B段中的服务状态为正常服务状态的概率为30％和为异常服务状态的概率为40％、以及目标司机在C段中的服务状态为正常服务状态的概率为50％和为异常服务状态的概率为60％，共六种概率。针对某一种服务状态序列如“A异常服务状态—B正常服务状态—C异常服务状态”，假设在历史时间段内从A子段驾驶至B子段的参考司机的总数量为10个，且其中符合“A异常服务状态—B正常服务状态”的参考司机的数量为7个，假设在历史时间段内从B子段驾驶至C子段的参考司机的总数量为11个，且其中符合“B正常服务状态—C异常服务状态”的参考司机的数量为8个。则目标司机在目标时间段内的行驶轨迹与“A异常服务状态—B正常服务状态—C异常服务状态”这一服务状态序列的匹配概率为：10％×20％×30％×7/10×8/11。

在执行完成上述步骤S306之后，参照图3所示，继续进行如下步骤：

步骤S307、从多种服务状态序列中选取出匹配概率最高的目标服务状态序列。

一种可能的实施方式中，在得到目标司机的行驶轨迹与该服务状态序列的匹配概率之后，从多种服务状态序列中选取出匹配概率最高的目标服务状态序列。

步骤S308、基于目标服务状态序列中包括的服务状态的总数量、和异常服务状态的数量，确定目标司机的行驶轨迹被标记为异常服务状态的发生概率。

一些实施例中，在目标服务状态序列中，计算异常服务状态的数量在服务状态的总数量中所占比率，即为目标司机的待识别轨迹段被标记为异常服务状态的发生概率。

步骤S309、将该发生概率与设定阈值进行比较，判断发生概率是否大于设定阈值。若是，则进行步骤S310；若否，则进行步骤S311。

步骤S310、确定目标司机的行驶轨迹匹配的服务状态为异常服务状态。

步骤S311、确定目标司机的行驶轨迹匹配的服务状态为正常服务状态。

在实际应用中，针对目标司机的待识别轨迹段，若待识别轨迹段为巡游轨迹段，则异常服务状态为跳单状态，即目标司机上报至服务器的运行状态为巡游状态，而目标司机的实际运行状态为跑单状态；若待识别轨迹段为跑单轨迹段，则异常服务状态为刷单状态，即目标司机上报至服务器的运行状态为跑单状态，而目标司机的实际运行状态为巡游状态。

实施例三：

本实施例三中，主要对预先训练好的服务状态预测模型及其训练过程进行详细说明。

一些实施例中，该预先训练好的服务状态预测模型为二分类模型，可以为任意的二分类模型，例如GBDT模型。具体的，服务器可以向预先训练好的GBDT模型输入每个轨迹子段对应的目标司机订单信息及轨迹信息、该轨迹子段对应的参考司机的参考轨迹信息和参考订单信息、路况信息以及道路网信息，得到GBDT模型输出的每个轨迹子段对应的目标司机行驶过程为异常服务状态的预测概率以及为正常服务状态的预测概率。

其中，参考司机的参考轨迹信息和参考订单信息可以是目标时间段(例如当前时间段)内的行驶轨迹，还可以是目标时间段之前的历史时间段内的行驶轨迹，当然也可以同时包括上述两种时间段的情况。

本实施例中，轨迹子段对应的参考司机的参考轨迹信息和参考订单信息可以通过打车平台数据库中累积的所有司机历史轨迹信息和/或当前轨迹信息而获取到。

对于上述预先训练好的服务状态预测模型的训练方式，可以通过以下方式执行训练过程：

首先，获取训练样本集合，训练样本集合包括不同轨迹子段分别对应的训练样本信息和服务状态标签，其中，训练样本信息中包括样本司机的样本轨迹信息和样本订单信息、以及样本参考司机的样本参考轨迹信息和样本参考订单信息。

然后，从训练样本集合中选取多个轨迹子段对应的训练样本信息，之后提取每个轨迹子段对应的训练样本信息的特征信息，并将提取出的特征信息输入至待训练的服务状态预测模型中，输出每个轨迹子段被标记为每种服务状态的预测概率。

然后，基于输出的预测概率，确定每个轨迹子段对应的预测服务状态，并基于每个轨迹子段对应的预测服务状态和服务状态标签，计算本轮训练过程的损失值。

若计算出的损失值大于设定阈值，则调整待训练的服务状态预测模型的模型参数，重新从训练样本集合中选取多个轨迹子段对应的训练样本信息并执行训练过程，直至计算出的损失值不大于设定阈值；若计算出的损失值不大于设定阈值，则确定待训练的服务状态预测模型训练完成。

实施例四：

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

参照图6所示，为本申请实施例提供的一种服务状态识别装置的结构示意图，服务状态识别装置60包括：获取模块61、预测概率确定模块62、服务状态序列确定模块63、匹配概率确定模块64以及服务状态确定模块65。

其中，获取模块61用于获取目标服务提供端的行驶轨迹，并将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段。预测概率确定模块62用于确定目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率。服务状态序列确定模块63用于确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列。

匹配概率确定模块64用于针对每种服务状态序列，基于目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定目标服务提供端的行驶轨迹与该服务状态序列的匹配概率。

服务状态确定模块65用于从多种服务状态序列中选取出匹配概率符合预设条件的目标服务状态序列，并基于目标服务状态序列中各轨迹子段对应的服务状态，确定目标服务提供端的行驶轨迹匹配的服务状态。

一些实施例中，获取模块61还用于：获取目标提供端的订单信息。获取模块61在将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段时，具体用于：将目标服务提供端的行驶轨迹与订单信息中每个服务订单对应的行驶轨迹进行匹配，确定目标服务提供端的行驶轨迹中的跑单轨迹段和巡游轨迹段；将每个跑单轨迹段划分为多个轨迹子段，以及，将每个巡游轨迹段划分为多个轨迹段。

此外，获取模块61还用于：确定每个轨迹子段对应的轨迹信息，以及，确定每个轨迹子段对应的订单信息。预测概率确定模块62在确定目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率时，具体用于：针对每个轨迹子段，基于该轨迹子段对应的目标服务提供端的轨迹信息和订单信息、该轨迹子段对应的参考服务提供端的参考轨迹信息和参考订单信息、以及预先训练的服务状态预测模型，确定目标服务提供端的该轨迹子段被标记为每种服务状态的预测概率。

其中，轨迹信息包括以下信息中的至少一种：每个轨迹点的位置坐标、驶过每个轨迹点的时间点、行驶速度。订单信息包括以下信息中的至少一种：服务提供端信息、服务请求端信息、订单起始时间、订单持续时间、订单行程路线、订单起始地点和目的地点。

服务状态序列确定模块63在确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列时，具体用于：从每个轨迹子段对应的多种服务状态中任意选择一种服务状态，将选择出的各轨迹子段分别对应的服务状态构成一种服务状态序列。

匹配概率确定模块64在基于目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定目标服务提供端的行驶轨迹与该服务状态序列的匹配概率时，具体用于：基于参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定该服务状态序列的状态转移概率。将每个轨迹子段对应的服务状态的预测概率和状态转移概率进行相乘，得到目标服务提供端的行驶轨迹与该服务状态序列的匹配概率。

匹配概率确定模块64在基于参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定该服务状态序列的状态转移概率时，具体用于：将历史时间段内符合该服务状态序列的参考服务提供端的数量与参考服务提供端的总数量之间的比值，确定为该服务状态序列的状态转移概率。

服务状态确定模块65在从多种服务状态序列中选取出匹配概率符合预设条件的目标服务状态序列时，具体用于：从多种服务状态序列中选取出匹配概率最高的目标服务状态序列。

服务状态包括异常服务状态和正常服务状态，异常服务状态为刷单状态或跳单状态。服务状态确定模块65在基于目标服务状态序列中各轨迹子段对应的服务状态，确定目标服务提供端的行驶轨迹匹配的服务状态时，具体用于：基于目标服务状态序列中包括的服务状态的总数量、和异常服务状态的数量，确定目标服务提供端的行驶轨迹被标记为异常服务状态的发生概率。若发生概率大于设定阈值，则确定目标服务提供端的行驶轨迹匹配的服务状态为异常服务状态。

服务状态识别装置60还包括：发送模块66，用于在确定目标服务提供端的行驶轨迹匹配的服务状态为异常服务状态之后，向目标服务提供端发送用于提示出现异常服务状态的提示信息。

实施例五：

本申请实施例还提供了一种电子设备。参照图7所示，为本申请实施例提供的电子设备70的结构示意图，包括处理器71、存储器72、和总线73。其中，存储器72用于存储执行指令，包括内存721和外部存储器722；这里的内存721也称内存储器，用于暂时存放处理器71中的运算数据，以及与硬盘等外部存储器722交换的数据，处理器71通过内存721与外部存储器722进行数据交换，当电子设备70运行时，处理器71与存储器72之间通过总线73通信，使得处理器71在执行以下指令：

将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段，并确定所述目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率；

确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列；

针对每种服务状态序列，基于所述目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、参考服务提供端的总数量、以及历史时间段内符合该服务状态序列的参考服务提供端的数量，确定所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率；

从多种服务状态序列中选取出所述匹配概率符合预设条件的目标服务状态序列，并基于所述目标服务状态序列中各轨迹子段对应的服务状态，确定所述目标服务提供端的行驶轨迹匹配的服务状态。

其中，处理器71的具体处理流程可以参照图2至图5对应的实施例的记载，这里不再赘述。

本申请提供的上述电子设备，可以结合目标服务提供端在各个轨迹子段预测出的服务状态，以及其它参考服务提供端在整段行驶轨迹中的服务状态的整体情况，相比现有技术，不仅仅是针对目标服务提供端服务状态的局部情况，还考虑到了其它参考服务提供端在这段行驶轨迹所处服务状态的整体情况，以此使目标服务提供端服务状态的识别过程考虑到更加全面的因素，由此可以准确识别出目标服务提供端在整段行驶轨迹中的服务状态，以便有效识别出目标服务提供端的跳单、刷单等异常服务状态，从而提高服务过程中的安全性及服务资源配置效率。

实施例六：

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述服务状态识别方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述服务状态识别方法，以更准确的识别出目标服务提供端在整段行驶轨迹中的服务状态，以便有效识别出目标服务提供端的跳单、刷单等异常服务状态，从而提高服务过程中的安全性及服务资源配置效率。

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

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

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

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

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

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

Claims (20)

1.一种服务状态识别方法，其特征在于，包括：

将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段，并确定所述目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率；

确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列；

针对每种服务状态序列，基于所述目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、历史时间段内符合该服务状态序列的参考服务提供端的数量与参考服务提供端的总数量的比值，确定所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率；所述参考服务提供端为历史时间段内经过所述轨迹子段的服务提供端；

从多种服务状态序列中选取出所述匹配概率符合预设条件的目标服务状态序列，并基于所述目标服务状态序列中各轨迹子段对应的服务状态，确定所述目标服务提供端的行驶轨迹匹配的服务状态。

2.如权利要求1所述的方法，其特征在于，还包括：

获取所述目标服务提供端的订单信息；

所述将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段，包括：

将所述目标服务提供端的行驶轨迹与所述订单信息中每个服务订单对应的行驶轨迹进行匹配，确定所述目标服务提供端的行驶轨迹中的跑单轨迹段和巡游轨迹段；

将每个跑单轨迹段划分为多个轨迹子段，以及，将每个巡游轨迹段划分为多个轨迹段。

3.如权利要求2所述的方法，其特征在于，在将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段之后，还包括：

确定每个轨迹子段对应的轨迹信息，以及，确定每个轨迹子段对应的订单信息；

所述确定所述目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率，包括：

针对每个轨迹子段，基于该轨迹子段对应的所述目标服务提供端的轨迹信息和订单信息、该轨迹子段对应的参考服务提供端的参考轨迹信息和参考订单信息、以及预先训练的服务状态预测模型，确定所述目标服务提供端的该轨迹子段被标记为每种服务状态的预测概率。

4.如权利要求3所述的方法，其特征在于，所述轨迹信息包括以下信息中的至少一种：

每个轨迹点的位置坐标；驶过每个轨迹点的时间点；行驶速度；

所述订单信息包括以下信息中的至少一种：

服务提供端信息；服务请求端信息；订单起始时间；订单持续时间；订单行程路线；订单起始地点和目的地点。

5.如权利要求1所述的方法，其特征在于，所述确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列，包括：

从每个轨迹子段对应的多种服务状态中任意选择一种服务状态，将选择出的各轨迹子段分别对应的服务状态构成一种服务状态序列。

6.如权利要求1所述的方法，其特征在于，所述基于所述目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、历史时间段内符合该服务状态序列的参考服务提供端的数量与参考服务提供端的总数量的比值，确定所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率，包括：

将历史时间段内符合该服务状态序列的参考服务提供端的数量与参考服务提供端的总数量的比值，确定为该服务状态序列的状态转移概率；

将每个轨迹子段对应的服务状态的预测概率和所述状态转移概率进行相乘，得到所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率。

7.如权利要求1所述的方法，其特征在于，所述从多种服务状态序列中选取出所述匹配概率符合预设条件的目标服务状态序列，包括：

从多种服务状态序列中选取出所述匹配概率最高的目标服务状态序列。

8.如权利要求1或7所述的方法，其特征在于，所述服务状态包括异常服务状态和正常服务状态，所述异常服务状态为刷单状态或跳单状态；

所述基于所述目标服务状态序列中各轨迹子段对应的服务状态，确定所述目标服务提供端的行驶轨迹匹配的服务状态，包括：

基于所述目标服务状态序列中包括的服务状态的总数量、和异常服务状态的数量，确定所述目标服务提供端的行驶轨迹被标记为异常服务状态的发生概率；

若所述发生概率大于设定阈值，则确定所述目标服务提供端的行驶轨迹匹配的服务状态为异常服务状态。

9.如权利要求8所述的方法，其特征在于，若确定所述目标服务提供端的行驶轨迹匹配的服务状态为异常服务状态，则所述方法还包括：

向所述目标服务提供端发送用于提示出现异常服务状态的提示信息。

10.一种服务状态识别装置，其特征在于，包括：

获取模块，用于获取目标服务提供端的行驶轨迹，并将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段；

预测概率确定模块，用于确定所述目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率；

服务状态序列确定模块，用于确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列；

匹配概率确定模块，用于针对每种服务状态序列，基于所述目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、历史时间段内符合该服务状态序列的参考服务提供端的数量与参考服务提供端的总数量的比值，确定所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率；所述参考服务提供端为历史时间段内经过所述轨迹子段的服务提供端；

服务状态确定模块，用于从多种服务状态序列中选取出所述匹配概率符合预设条件的目标服务状态序列，并基于所述目标服务状态序列中各轨迹子段对应的服务状态，确定所述目标服务提供端的行驶轨迹匹配的服务状态。

11.如权利要求10所述的装置，其特征在于，所述获取模块，还用于：

获取所述目标服务提供端的订单信息；

所述获取模块，在将获取的目标服务提供端的行驶轨迹划分为多个轨迹子段时，具体用于：

将所述目标服务提供端的行驶轨迹与所述订单信息中每个服务订单对应的行驶轨迹进行匹配，确定所述目标服务提供端的行驶轨迹中的跑单轨迹段和巡游轨迹段；

将每个跑单轨迹段划分为多个轨迹子段，以及，将每个巡游轨迹段划分为多个轨迹段。

12.如权利要求11所述的装置，其特征在于，所述获取模块，还用于：

确定每个轨迹子段对应的轨迹信息，以及，确定每个轨迹子段对应的订单信息；

所述预测概率确定模块，在确定所述目标服务提供端的各轨迹子段分别被标记为每种服务状态的预测概率时，具体用于：

针对每个轨迹子段，基于该轨迹子段对应的所述目标服务提供端的轨迹信息和订单信息、该轨迹子段对应的参考服务提供端的参考轨迹信息和参考订单信息、以及预先训练的服务状态预测模型，确定所述目标服务提供端的该轨迹子段被标记为每种服务状态的预测概率。

13.如权利要求12所述的装置，其特征在于，所述轨迹信息包括以下信息中的至少一种：

每个轨迹点的位置坐标；驶过每个轨迹点的时间点；行驶速度；

所述订单信息包括以下信息中的至少一种：

服务提供端信息；服务请求端信息；订单起始时间；订单持续时间；订单行程路线；订单起始地点和目的地点。

14.如权利要求10所述的装置，其特征在于，所述服务状态序列确定模块，在确定由各轨迹子段分别对应的服务状态组成的多种服务状态序列时，具体用于：

从每个轨迹子段对应的多种服务状态中任意选择一种服务状态，将选择出的各轨迹子段分别对应的服务状态构成一种服务状态序列。

15.如权利要求10所述的装置，其特征在于，所述匹配概率确定模块，在基于所述目标服务提供端被标记为该服务状态序列中每个轨迹子段对应的服务状态的预测概率、历史时间段内符合该服务状态序列的参考服务提供端的数量与参考服务提供端的总数量的比值，确定所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率时，具体用于：

将历史时间段内符合该服务状态序列的参考服务提供端的数量与参考服务提供端的总数量的比值，确定为该服务状态序列的状态转移概率；

将每个轨迹子段对应的服务状态的预测概率和所述状态转移概率进行相乘，得到所述目标服务提供端的行驶轨迹与该服务状态序列的匹配概率。

16.如权利要求10所述的装置，其特征在于，所述服务状态确定模块，在从多种服务状态序列中选取出所述匹配概率符合预设条件的目标服务状态序列时，具体用于：

从多种服务状态序列中选取出所述匹配概率最高的目标服务状态序列。

17.如权利要求10或16所述的装置，其特征在于，所述服务状态包括异常服务状态和正常服务状态，所述异常服务状态为刷单状态或跳单状态；

所述服务状态确定模块，在基于所述目标服务状态序列中各轨迹子段对应的服务状态，确定所述目标服务提供端的行驶轨迹匹配的服务状态时，具体用于：

基于所述目标服务状态序列中包括的服务状态的总数量、和异常服务状态的数量，确定所述目标服务提供端的行驶轨迹被标记为异常服务状态的发生概率；

若所述发生概率大于设定阈值，则确定所述目标服务提供端的行驶轨迹匹配的服务状态为异常服务状态。

18.如权利要求17所述的装置，其特征在于，所述装置还包括：

发送模块，用于在确定所述目标服务提供端的行驶轨迹匹配的服务状态为异常服务状态之后，向所述目标服务提供端发送用于提示出现异常服务状态的提示信息。

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

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