CN111882312A - 管理车辆服务行程的方法、装置、电子设备和存储介质 - Google Patents

Abstract

本公开涉及管理车辆服务行程的方法、装置、电子设备和存储介质。在一种方法中，获取与车辆服务行程相关联的、在车辆服务行程的计费时间点的快照数据，车辆服务行程的司机在计费时间点开始对车辆服务行程的计费。基于快照数据，确定表示车辆服务行程的乘客尚未上车的第一概率。响应于确定第一概率表示不能确定乘客尚未上车，获取与车辆服务行程相关联的、计费时间点之后的流式数据。基于流式数据来管理车辆服务行程。进一步，提供了相应的装置、电子设备和存储介质。利用上述实现方式，可以在无需人工干预的情况下，自动分析采集到的快照数据和流式数据，确定乘客是否上车以便管理车辆服务行程。

Description

管理车辆服务行程的方法、装置、电子设备和存储介质

技术领域

本公开的各实现方式涉及车辆管理，更具体地，涉及基于在不同时间点采集的数据来管理车辆服务行程的方法、装置、电子设备和存储介质。

背景技术

随着计算机技术和网络技术的发展，目前已经开发出了用于提供在线车辆服务的应用。乘客可以利用该应用来提交车辆服务请求，并且寻找适合的车辆前往期望的目的地。司机可以对车辆服务行程进行计费，然而某些司机的计费行为可能并不符合计费规范，这将导致较差的乘客体验，并且可能会引发乘客投诉。此时如何以更为有效的方式管理车辆服务行程，成为一个研究热点。

发明内容

期望能够开发并实现一种以更为有效的方式来管理车辆服务行程的技术方案。期望该技术方案能够与现有的车辆服务应用相兼容，从而以更为有效的方式实现车辆服务行程的监控。

根据本公开的第一方面，提供了一种用于管理车辆服务行程的方法。在该方法中，获取与车辆服务行程相关联的、在车辆服务行程的计费时间点的快照数据，车辆服务行程的司机在计费时间点开始对车辆服务行程的计费。基于快照数据，确定表示车辆服务行程的乘客尚未上车的第一概率。响应于确定第一概率表示不能确定乘客尚未上车，获取与车辆服务行程相关联的、计费时间点之后的流式数据。基于流式数据来管理车辆服务行程。

根据本公开的第二方面，提供了一种用于管理车辆服务行程的装置。该装置包括：快照数据获取模块，配置用于获取与车辆服务行程相关联的、在车辆服务行程的计费时间点的快照数据，车辆服务行程的司机在计费时间点开始对车辆服务行程的计费；确定模块，配置用于基于快照数据，确定表示车辆服务行程的乘客尚未上车的第一概率；流式数据获取模块，配置用于响应于确定第一概率表示不能确定乘客尚未上车，获取与车辆服务行程相关联的、计费时间点之后的流式数据；以及管理模块，配置用于基于流式数据来管理车辆服务行程。

根据本公开的第三方面，提供了一种电子设备，包括：存储器和处理器；其中存储器用于存储一条或多条计算机指令，其中一条或多条计算机指令被处理器执行以实现根据本公开的第一方面的方法。

根据本公开的第四方面，提供了一种计算机可读存储介质，其上存储有一条或多条计算机指令，其中一条或多条计算机指令被处理器执行实现根据本公开的第一方面的方法。

附图说明

结合附图并参考以下详细说明，本公开各实现方式的特征、优点及其他方面将变得更加明显，在此以示例性而非限制性的方式示出了本公开的若干实现方式。在附图中：

图1示意性示出了其中可以使用根据本公开的示例性实现方式的车辆服务行程的框图；

图2示意性示出了根据本公开的示例性实现方式的用于管理车辆服务行程的过程的框图；

图3示意性示出了根据本公开的示例性实现方式的用于管理车辆服务行程的方法的流程图；

图4示意性示出了根据本公开的示例性实现方式的快照数据的数据结构的框图；

图5示意性示出了根据本公开的示例性实现方式的用于确定和使用快照数据和未上车概率之间的第一关联关系的过程的框图；

图6示意性示出了根据本公开的示例性实现方式的用于确定是否停止计费的方法的流程图；

图7示意性示出了根据本公开的示例性实现方式的用于确定和使用流式数据和未上车概率之间的第二关联关系的过程的框图；

图8示意性示出了根据本公开的示例性实现方式的用于确定是否停止计费的方法的流程图；以及

图9示意性示出了根据本公开的示例性实现的用于管理车辆服务行程的设备的框图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实现。虽然附图中显示了本公开的优选实现，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实现所限制。相反，提供这些实现是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

在本文中使用的术语“包括”及其变形表示开放性包括，即“包括但不限于”。除非特别申明，术语“或”表示“和/或”。术语“基于”表示“至少部分地基于”。术语“一个示例实现”和“一个实现”表示“至少一个示例实现”。术语“另一实现”表示“至少一个另外的实现”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

目前已经开发出了诸如在线车辆服务的应用，乘客可以使用该应用来呼叫车辆。司机在接收到来自乘客的呼叫之后，可以开车前往乘客指定的出发地，并将该乘客运送至指定的目的地。首先参见图1描述本公开的示例性实现方式的应用环境。图1示意性示出了其中可以使用根据本公开的示例性实现方式的车辆服务行程的框图100。该图示出了在车辆服务行程130期间的各个时间点发生的行为。乘客110可以呼叫车辆，并且司机120可以向乘客提供服务。时间轴140表示车辆服务行程130的时间进度。在此，上车时间点112是指乘客110搭乘车辆的时间点，计费时间点122是指司机120开始计费的时间点。

通常而言，计费时间点122应当在上车时间点112之后或者两者几乎同时发生。然而，某些司机可能会在乘客尚未上车的时候开始计费，这将会导致乘客的利益受到损失，由此引发的投诉程序将会导致额外的时间和人力开销。投诉后的补救措施处理时效较差，并且判定责任仅能依赖于车辆服务行程完成后的历史记录，中间过程数据的缺乏可能会导致不能准确地判定责任。此外，车辆服务应用不能及时监测和结束违规计费的行程，这将导致用户在司机结束行程之前不能再次呼叫车辆。

为了至少部分地解决上述问题以及其他潜在问题中的一个或者多个问题，本公开的示例性实现方式提出了一种用于管理车辆服务行程的技术方案。首先参见图2描述本公开的示例性实现方式的概要。图2示意性示出了根据本公开的示例性实现方式的用于管理车辆服务行程的过程的框图200。如图2所示，可以基于与车辆服务行程相关联的数据来确定乘客是否尚未上车。具体地，提供了两阶段的管理过程。在第一阶段，可以获取计费时间点122的快照数据210。如果基于该快照数据210不能确定乘客尚未上车，则在第二阶段可以获取计费时间点122之后的时间段230内的流式数据240。在此的时间段230例如计费时间点122和当前时间点220之间的时间段。

由于流式数据240可以包括在该时间段230内的多个时间点的快照数据，利用本公开的示例性实现方式，可以以更为准确的方式确定乘客是否上车，进而确定司机的计费动作是否符合规定。以此方式，可以在车辆服务行程130的发生期间实时地监视司机的计费动作，由此避免在已经出现乘客投诉之后回头审查司机的计费行为并且向乘客提供补偿的各种开销。

在下文中，将参见图3描述本公开的示意性实现方式的更多细节。图3示意性示出了根据本公开的示例性实现方式的用于管理车辆服务行程的方法300的流程图。在框310处，获取与车辆服务行程130相关联的、在车辆服务行程130的计费时间点122的快照数据210。车辆服务行程130的司机120在计费时间点122开始对车辆服务行程130的计费。快照数据210可以包括多方面的内容，因而获取快照数据210可以包括获取以下中的至少任一项：车辆服务行程的行程数据、司机和乘客的状态数据、司机的历史行为、司机与乘客之间的通信数据以及司机所在的车辆的监视数据。在下文中，将参见图4描述有关快照数据210的更多细节。

图4示意性示出了根据本公开的示例性实现方式的快照数据210的数据结构的框图400。根据本公开的示例性实现方式，快照数据210可以包括行程数据410。在此的行程数据410可以包括车辆服务行程130的基本信息，例如以下中的至少任一项：出发地、目的地、订单预估金额。等等。通过采集行程数据410，可以获得有关车辆服务行程130的各种基本信息，进而有助于确定乘客是否上车。

根据本公开的示例性实现方式，快照数据210可以包括司机的状态数据412。在此，司机的状态数据412可以包括以下中的至少任一项：司机的位置、朝向、速度、加速度、与乘客之间的距离、位置与车辆服务行程的匹配度，等等。司机的状态数据412可以在一定程度上反应乘客是否上车，例如，假设司机的位置远离乘客指定的出发地，则表示乘客很可能尚未上车。又例如，假设司机与乘客之间的距离较大，表示乘客很可能尚未上车。通过采集司机的状态数据412，可以提高确定乘客是否上车的概率的准确性。

根据本公开的示例性实现方式，快照数据210可以包括乘客的状态数据414。在此，乘客的状态数据414可以包括以下中的至少任一项：乘客的位置、朝向、速度、加速度、与司机之间的距离、位置与车辆服务行程的匹配度，等等。将会理解，乘客的状态数据414可以在一定程度上反应乘客是否上车，例如，假设乘客的位置表示该乘客正在出发地并且速度为静止，则表示乘客很可能仍然在等待车辆并且尚未上车。假设乘客与司机之间的距离较大，表示乘客很可能尚未上车。

根据本公开的示例性实现方式，可以比较司机和乘客之间的距离，并且可以比较两者的速度、行驶方向、加速度，如果距离过远、速度相差大、在行驶方向不同，则表示乘客很可能尚未上车。通过采集乘客的状态数据412，可以直接和/或间接地基于乘客的状态来确定乘客是否上车，进而提高处理过程的准确性。

根据本公开的示例性实现方式，快照数据210可以包括司机与乘客之间的通信数据416。该通信数据416可以包括以下中的至少任一项：司机和乘客之间是否进行了通信、成功通信次数、通信时间长度、当前是否正在通信、失败通信次数、失败通信原因、通信的发起者以及接受者，等等。通常而言，在乘客上车之前，乘客可能会联系司机并告知具体等待位置，司机也可能会联系乘客并询问具体等待位置。当乘客已经上车之后，两者不会继续通信。

将会理解，在此的通信数据可以涉及经由多种方式的通信：语音通信、短消息通信、以及经由车辆服务应用提供的聊天窗口进行的通信，等等。例如，假设通信数据416表示在计费时间点122处，司机和乘客正在通话，则表示乘客很可能仍然在等待车辆并且尚未上车。通过采集通信数据416，可以基于司机与乘客之间的通信状态来确定乘客是否上车，进而提高处理过程的准确性。

根据本公开的示例性实现方式，快照数据210可以包括司机的历史数据418。在此的历史数据可以包括司机提供服务的历史统计，例如，司机被投诉的投诉率、成功完成订单的比率、乘客对于司机的服务的满意率、差评率，等等。将会理解，司机的历史数据418可以在一定程度上反应司机的诚信程度。假设司机的投诉率较高，则在其他情况均相同时，认为该司机在乘客上车前开始计费的可能性较高。通过采集司机的历史数据418，可以基于司机历史行为来估计司机本次服务的诚信程度，进而提高处理过程的准确性。

根据本公开的示例性实现方式，快照数据210可以包括车辆的监视数据420。在此的监视数据可以是由安装在车辆内部的采集设备所采集的视频、图像、和/或音频，等等。通过采集车辆的监视数据420，可以直接基于监视数据来确定乘客是否上车，进而提高处理过程的准确性。在监视数据为视频或者图像的情况下，可以直接从监视数据中识别车辆中的乘客的数量。在监视数据为音频的情况下，可以识别是否存在司机和乘客之间的对话，进而确定乘客是否上车。

将会理解，图4仅仅示意性示出了快照数据210的数据结构的示例，根据本公开的示例性实现方式，快照数据210可以包括更多或者更少的数据。在一个示例中，快照数据210可以仅包括司机的状态数据412和乘客的状态数据414。在另一示例中，快照数据210可以包括司机的状态数据412、乘客的状态数据414、以及通信数据416。

根据本公开的示例性实现方式，可以进一步处理快照数据210以便获得可以用于判断乘客是否上车的其他信息。例如，可以确定计费时间点和接单时间点之间的时间差。如果该时间差远小于预估接驾距离所需时间，则可以确定乘客尚未上车。

上文已经参见图4描述快照数据210的内容，在下文中，将返回图3描述如何处理快照数据。在图3的框320处，基于快照数据210，确定表示车辆服务行程130的乘客尚未上车的第一概率。将会理解，尽管在此的第一概率表示乘客“尚未上车”，根据本公开的示例性实现方式，还可以确定表示乘客“已经上车”的概率。

根据本公开的示例性实现方式，可以基于机器学习技术来确定第一概率。可以首先获取车辆服务行程130在参考时间点的特征与乘客的上车概率之间的第一关联关系。在下文中，将参见图5描述有关获取第一关联关系510的更多细节。图5示意性示出了根据本公开的示例性实现方式的用于确定和使用快照数据和未上车概率之间的第一关联关系510的过程的框图500。在图5中，以实线示出的部分表示用于确定第一关联关系510的过程。

可以基于过去的样本数据来训练第一关联关系510。在此的样本数据可以是在过去使用车辆服务应用期间采集到的数据。例如，样本数据520可以包括样本快照特征522，该样本快照特征522是基于在某个历史车辆服务行程的计费时间点采集的样本快照数据而获得的。例如，样本快照特征522可以包括多个方面，例如上文参见图4所示。假设以包括n个维度的向量来表示样本快照特征522，则特征中的各个维度可以分别对应于样本快照中的各个方面。例如，第一个维度可以表示行程的出发地、第二个维度可以表示目的地，等等。

样本数据520可以包括样本概率524，在此的样本概率524是指在该历史车辆服务行程中，当司机开始计费时乘客尚未上车的概率。由于此处的行程是过去已经发生的行程，可以知晓乘客当时是否上车。例如，可以以数值“1”表示乘客尚未上车，可以以数值“0”表示乘客已经上车。

根据本公开的示例性实现方式，可以从历史服务行程中选择样本数据520。例如，可以从被投诉的车辆服务行程中选择司机在乘客上车之前开始计费的车辆服务行程。可以将选择的多个车辆服务行程作为“正样本”，即样本概率524为“1”。又例如，可以从正常车辆服务行程中选择正常计费的车辆服务行程。可以将这些车辆服务行程作为“负样本”，即样本概率524为“0”。

可以基于上述方式获取多个样本数据，并且基于多个样本数据来训练第一关联关系510。根据本公开的示例性实现方式，可以基于目前已经开发或者将在未来开发的多种技术来训练第一关联关系510，将不再赘述。将会理解，第一关联关系510是基于历史样本数据来确定的，因而可以准确地反应与过去的车辆服务行程相关的历史经验。以此方式，可以有助于利用历史经验来确定当前的车辆服务行程中的乘客状态。

在下文中，参见图5中的虚线框示出的部分来描述如何使用第一关联关系510。可以基于快照数据210来确定与计费时间点122相关联的快照特征530。确定快照特征530的方式与确定样本快照特征522的方式相同，并且两个特征具有相同的数据结构。继而，可以将快照特征530输入至第一关联关系510，以便确定第一概率540。根据本公开的示例性实现方式，第一概率540可以以[0，1]之间的数值来表示。数值越大则表示乘客尚未上车的概率越高。

继而，可以基于第一概率540来确定后续的操作步骤。根据本公开的示例性实现方式，可以设置预定的概率阈值用于区分乘客是否上车。根据本公开的示例性实现方式，可以在区间[0，1]中分别设置概率阈值α和β(α＜β)。如果第一概率540大于β，则表示乘客尚未上车；如果第一概率540位于α和β之间，则表示不能确定乘客尚未上车；如果第一概率540小于α，则表示乘客已经上车。将会理解，在此的概率阈值是基于历史经验而设置的，根据本公开的示例性实现方式，可以将α和β分别设置为0.4和0.8的数值。根据本公开的其他示例性实现方式，可以将α和β设置为其他数值。

图6示意性示出了根据本公开的示例性实现方式的用于确定是否停止计费的方法600的流程图。如图6所示，在框610处，可以基于第一概率确定乘客是否上车。如果第一概率540大于β，则可以确定用户没有上车。此时，方法600前进至框620，以便向乘客提供用于确认乘客是否已经上车的查询。将会理解，在此的第一概率540表示基于历史经验确定的乘客尚未上车的概率。如果基于历史经验认为乘客没有上车的概率较高，则可以直接向乘客询问自身的乘车状况。以此方式，可以在尽量不干扰用户乘车体验的情况下，监视司机提前计费的违规操作。

具体地，可以在车辆服务应用中向乘客发出通知，以询问乘客此时是否已经上车。例如，可以提供“已经上车”和“尚未上车”的按钮供用户选择。备选地和/或附加地，可以经由短消息和/或电话来询问乘客是否上车。在框630处，可以接收来自用户的查询结果630。如果用户选择“已经上车”，则此时在框640处的查询结果为“已经上车”，方法600将前进至框650处。这表示司机的计费行为是正常行为，并且允许计费。如果用户选择“尚未上车”，则此时在框640处的查询结果为“尚未上车”，方法600将前进至框660处。这表示司机在乘客上车之前开始计费，并且该计费行为是违规行为，因而应当停止计费。根据本公开的示例性实现方式，用户可能并未立刻看到通知，此时可以等待用户的反馈。可以指定等待时间长度，如果等待查询结果的等待时间超过预定时间长度，则停止计费。

将会理解，上文描述的操作并不会干扰司机的正常计费。假设司机在乘客上车之后开始计费，此时即使第一概率540指示乘客尚未上车并且向乘客发送了查询，司机可以提醒乘客在车辆服务应用中回复查询。当乘客回复“已经上车”之后，则计费可以继续进行。假设司机在乘客上车之前开始计费，乘客将会收到查询。乘客在看到查询时，将会回复“尚未上车”，此时将会停止计费。如果乘客长时间没有看到查询，也将会停止计费以避免乘客的经济损失。利用本公开的示例性实现方式，可以以更加准确的方式确定乘客是否上车，进而管理司机的服务行为。

根据本公开的示例性实现方式，如果第一概率540的数值小于α，则表示乘客已经上车并且司机的计费行为符合规定。此时，可以允许计费，并且车辆服务行程130可以正常进行。

上文已经描述了第一概率540表示乘客尚未上车和已经上车的情况，在下文中，将返回图3描述第一概率540具有其他数值的情况。在图3的框330处，响应于确定第一概率540表示不能确定乘客尚未上车，获取与车辆服务行程130相关联的、计费时间点122之后的流式数据240。将会理解，在此的流式数据240是指在计费时间点122之后的时间段内230的多个时间点采集到的数据。在每个时间点采集到的数据的格式可以与快照数据210的格式相同。流式数据240可以包括以下中的至少任一项：司机和乘客的状态数据流、司机和乘客之间的通信数据流、以及司机所在的车辆的监视数据流。利用本公开的示例性实现方式，可以基于流式数据处理技术，来实时确定乘客是否已经上车，进而基于乘客的乘车状态来进一步管理车辆服务行程。

根据本公开的示例性实现方式，仅以司机的状态数据流为示例描述流式数据240的细节。可以指定流式数据240的采样频率为2次每秒(或者其他频率)，假设计费时间点122与当前时间点220之间的时间长度为10秒，则可以获得在20个时间点采集到的数据。在每个时间点采集到的数据与上文参见图4描述的司机的状态数据412相同，因而不再赘述。类似地，可以获得乘客的状态数据流、司机和乘客之间的通信数据流、以及司机所在的车辆的监视数据流。根据本公开的示例性实现方式，还可以指定时间段的长度，例如，可以指定在计费时间点122之后30秒(或者其他时间间隔)时获取流式数据240。

继续参见图3，在框340处，基于流式数据240来管理车辆服务行程130。具体地，可以基于流式数据240来确定表示乘客尚未上车的第二概率。将会理解，上文中的第一概率540是基于计费时间点122的快照数据210来确定乘客是否上车的概率。如果第一概率540不足以确定乘客的状态，则将启动第二阶段。在第二阶段中，将基于在连续时间段采集的流式数据240进行判断，以更高的精度确定乘客是否上车。

在下文中，将参见图7描述如何确定第二概率。图7示意性示出了根据本公开的示例性实现方式的用于确定和使用流式数据和未上车概率之间的第二关联关系710的过程700的框图。图7与图6的内容相类似，不同之处在于图7中的第二关联关系710表示车辆服务行程的在参考时间段期间的流式特征与乘客的上车概率之间的关联关系，并且该第二关联关系710是基于样本数据720中的样本流式特征722和样本概率724来训练的。

可以基于与图5中类似的方式来训练第二关联关系710。图7中以实线框示出的部分表示确定第二关联关系710的过程。具体地，可以从历史数据中获得多个样本数据，每个样本数据720可以包括样本流式特征722和样本概率724。该样本流式特征722是基于在某个历史车辆服务行程的计费时间点之后的时间段采集的样本流式数据而获得的。具体地，可以在该历史车辆服务行程的计费时间点之后的一个时间段内采集样本流式数据，并且从该样本流式数据生成样本流式特征722。根据本公开的示例性实现方式，样本流式特征722可以是包括多个快照特征的序列，并且可以按照上文描述的方式来确定各个快照特征。根据本公开的示例性实现方式，可以将该序列作为样本流式特征722；备选地和/或附加地，可以将该序列映射至较低的维度，以便作为样本流式特征722。

在本公开的上下文中，可以基于目前已经开发和/或将在未来开发的多种技术来生成特征以及执行训练，以便获得第二关联关系710。继而，可以基于第二关联关系710来确定第二概率740。具体地，如图7中的虚线框部分所示，可以从流式数据240提取流式特征730，并且将流式特征730输入至第二关联关系710，以便获得第二概率740。

利用本公开的示例性实现方式，第二关联关系710是基于历史样本数据来确定的，因而可以准确地反应与过去的车辆服务行程相关的历史经验。由于流式数据240包括在一个时间段期间的更为丰富的数据，可以有助于以更高的精度确定当前的车辆服务行程中的乘客状态。

进一步，可以基于第二概率740来管理车辆服务行程130。根据本公开的示例性实现方式，第二概率740可以以[0，1]之间的数值来表示。数值越大则表示乘客尚未上车的概率越高。继而，可以基于第二概率740来确定后续的操作步骤。根据本公开的示例性实现方式，可以设置预定的概率阈值，以便表示乘客是否上车。

根据本公开的示例性实现方式，可以在区间[0，1]中分别设置概率阈值γ和δ(γ＜δ)。如果第二概率740大于δ，则表示乘客尚未上车；如果第二概率740位于γ和δ之间，则表示不能确定乘客尚未上车；如果第二概率740小于γ，则表示乘客已经上车。将会理解，在此的概率阈值是基于历史经验而设置的，根据本公开的示例性实现方式，可以将γ和δ分别设置为0.4和0.8的数值。根据本公开的其他示例性实现方式，可以将γ和δ设置为其他数值。将会理解，在此第二概率740的概率阈值和第一概率540的概率阈值可以具有相同或者不同的数值。

下文中，将参见图8来描述更多细节。图8示意性示出了根据本公开的示例性实现方式的用于确定是否停止计费的方法800的流程图。如图8所示，在框810处，可以基于第二概率740确定乘客是否上车。如果第二概率740大于δ，则表示乘客尚未上车。此时，方法800前进至框840，以便停止计费。将会理解，在此的第二概率740是基于在连续时间段内监视车辆服务行程130来确定的，因而该第二概率740具有较高的准确性。此时，可以直接停止计费，以避免乘客的经济损失。

利用本公开的示例性实现方式，可以实时地监视司机的计费行为是否违规，并且在发现违规行为时立刻纠正司机的操作。相对于已有技术方案中乘客投诉之后的补救方案而言，本公开的示例性实现方式可以提供更为实时的监控，并且达到出现错误立即纠正的效果。

在框810处，如果第二概率740位于γ和δ之间，则表示不能确定乘客尚未上车。此时，方法800将前进至框820处，以便向司机提供警告。将会理解，在此的警告表示车辆服务应用已经检测到了司机提前计费的潜在违规行为。当司机收到警告时，将会认识到自己的错误，并且向车辆服务应用提供“取消计费”的反馈。进而，在框830处，可以接收来自司机的反馈，并且在框840处停止计费。利用本公开的示例性实现方式，可以利用警告信息对于违规司机的威慑力，来使得司机主动取消计费。以此方式，可以促使司机改正错误。

根据本公开的示例性实现方式，可以向司机提供“申诉通道”。如果此时乘客确实已经上车，司机可以通过“申诉通道”来表明当前车辆服务行程的状态，以便继续服务和计费。利用本公开的示例性实现方式，可以允许司机执行更多的操作，以便改正误判导致的不能继续车辆服务行程的错误。

在上文中已经参见图2至图8详细描述了根据本公开的方法的示例，在下文中将描述相应的装置的实现。根据本公开的示例性实现方式，提供了一种用于管理车辆服务行程的装置，包括：快照数据获取模块，配置用于获取与车辆服务行程相关联的、在车辆服务行程的计费时间点的快照数据，车辆服务行程的司机在计费时间点开始对车辆服务行程的计费；确定模块，配置用于基于快照数据，确定表示车辆服务行程的乘客尚未上车的第一概率；流式数据获取模块，配置用于响应于确定第一概率表示不能确定乘客尚未上车，获取与车辆服务行程相关联的、计费时间点之后的流式数据；以及管理模块，配置用于基于流式数据来管理车辆服务行程。

根据本公开的示例性实现方式，确定模块包括：快照特征确定模块，配置用于基于快照数据确定与计费时间点相关联的快照特征；以及第一概率确定模块，配置用于基于快照特征以及第一关联关系来确定第一概率，第一关联关系表示车辆服务行程在参考时间点的特征与乘客的上车概率之间的关联关系。

根据本公开的示例性实现方式，快照数据获取模块进一步被配置用于获取以下中的至少任一项：车辆服务行程的行程数据、司机和乘客的状态数据、司机的历史数据、司机与乘客之间的通信数据以及司机所在的车辆的监视数据。

根据本公开的示例性实现方式，司机的状态数据包括以下中的至少任一项：司机的位置、朝向、速度、加速度、与乘客之间的距离、位置与车辆服务行程的匹配度。

根据本公开的示例性实现方式，通信数据包括以下中的至少任一项：司机和乘客之间是否进行了通信、成功通信次数、通信时间长度、当前是否正在通信、失败通信次数、失败通信原因、通信的发起者以及接受者。

根据本公开的示例性实现方式，快照数据获取模块进一步被配置用于从监视数据中识别车辆中的乘客的数量。

根据本公开的示例性实现方式，流式数据获取模块被配置用于获取计费时间点之后的时间段内的以下中的至少任一项：司机和乘客的状态数据流、司机和乘客之间的通信数据流、以及司机所在的车辆的监视数据流。

根据本公开的示例性实现方式，管理模块包括：流式数据处理模块，配置用于基于流式数据来确定表示乘客尚未上车的第二概率；以及管理模块进一步被配置用于基于第二概率来管理车辆服务行程。

根据本公开的示例性实现方式，流式数据处理模块包括：流式特征提取模块，配置用于基于流式数据提取与时间段相关联的流式特征；以及第二概率确定模块，配置用于基于流式特征以及第二关联关系来确定第二概率，第二关联关系表示车辆服务行程的在参考时间段期间的流式特征与乘客的上车概率之间的关联关系。

根据本公开的示例性实现方式，管理模块包括以下中的至少任一项：结束模块，配置用于响应于确定第二概率表示乘客尚未上车，结束计费；以及警告模块，配置用于响应于确定第二概率表示不能确定用户尚未上车，向司机提供停止计费的警告数据。

根据本公开的示例性实现方式，管理模块进一步包括：查询模块，配置用于响应于确定第一概率表示用户没有上车，向乘客提供用于确定乘客是否已经上车的查询；允许模块，配置用于响应于接收到来自乘客的查询结果为“已经上车”，允许计费；以及结束模块，配置用于响应于接收到来自乘客的查询结果为“尚未上车”，结束计费。

根据本公开的示例性实现方式，管理模块进一步包括：超时模块，配置用于响应于等待来自于乘客的查询结果的等待时间超过预定时间长度，结束计费。

根据本公开的示例性实现方式，提供了一种电子设备，包括：存储器和处理器；其中存储器用于存储一条或多条计算机指令，其中一条或多条计算机指令被处理器执行以实现上文描述的方法。

图9示出了其中可以实施本公开的一个或多个实施例的计算设备/服务器900的框图。应当理解，图9所示出的计算设备/服务器900仅仅是示例性的，而不应当构成对本文所描述的实施例的功能和范围的任何限制。

如图9所示，计算设备/服务器900是通用计算设备的形式。计算设备/服务器900的组件可以包括但不限于一个或多个处理器或处理单元910、存储器920、存储设备930、一个或多个通信单元940、一个或多个输入设备950以及一个或多个输出设备960。处理单元910可以是实际或虚拟处理器并且能够根据存储器920中存储的程序来执行各种处理。在多处理器系统中，多个处理单元并行执行计算机可执行指令，以提高计算设备/服务器900的并行处理能力。

计算设备/服务器900通常包括多个计算机存储介质。这样的介质可以是计算设备/服务器900可访问的任何可以获得的介质，包括但不限于易失性和非易失性介质、可拆卸和不可拆卸介质。存储器920可以是易失性存储器(例如寄存器、高速缓存、随机访问存储器(RAM))、非易失性存储器(例如，只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、闪存)或它们的某种组合。存储设备930可以是可拆卸或不可拆卸的介质，并且可以包括机器可读介质，诸如闪存驱动、磁盘或者任何其他介质，其可以能够用于存储信息和/或数据(例如用于训练的训练数据)并且可以在计算设备/服务器900内被访问。

计算设备/服务器900可以进一步包括另外的可拆卸/不可拆卸、易失性/非易失性存储介质。尽管未在图9中示出，可以提供用于从可拆卸、非易失性磁盘(例如“软盘”)进行读取或写入的磁盘驱动和用于从可拆卸、非易失性光盘进行读取或写入的光盘驱动。在这些情况中，每个驱动可以由一个或多个数据介质接口被连接至总线(未示出)。存储器920可以包括计算机程序产品925，其具有一个或多个程序模块，这些程序模块被配置为执行本公开的各种实施例的各种方法或动作。

通信单元940实现通过通信介质与其他计算设备进行通信。附加地，计算设备/服务器900的组件的功能可以以单个计算集群或多个计算机器来实现，这些计算机器能够通过通信连接进行通信。因此，计算设备/服务器900可以使用与一个或多个其他服务器、网络个人计算机(PC)或者另一个网络节点的逻辑连接来在联网环境中进行操作。

输入设备950可以是一个或多个输入设备，例如鼠标、键盘、追踪球等。输出设备960可以是一个或多个输出设备，例如显示器、扬声器、打印机等。计算设备/服务器900还可以根据需要通过通信单元940与一个或多个外部设备(未示出)进行通信，外部设备诸如存储设备、显示设备等，与一个或多个使得用户与计算设备/服务器900交互的设备进行通信，或者与使得计算设备/服务器900与一个或多个其他计算设备通信的任何设备(例如，网卡、调制解调器等)进行通信。这样的通信可以经由输入/输出(I/O)接口(未示出)来执行。

根据本公开的示例性实现方式，提供了一种计算机可读存储介质，其上存储有一条或多条计算机指令，其中一条或多条计算机指令被处理器执行以实现上文描述的方法。

这里参照根据本公开实现的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其他可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其他可编程数据处理装置、或其他设备上，使得在计算机、其他可编程数据处理装置或其他设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其他可编程数据处理装置、或其他设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实现的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本公开的各实现，上述说明是示例性的，并非穷尽性的，并且也不限于所公开的各实现。在不偏离所说明的各实现的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实现的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文公开的各实现。

Claims (15)

1.一种用于管理车辆服务行程的方法，包括：

获取与所述车辆服务行程相关联的、在所述车辆服务行程的计费时间点的快照数据，所述车辆服务行程的司机在所述计费时间点开始对所述车辆服务行程的计费；

基于所述快照数据，确定表示所述车辆服务行程的乘客尚未上车的第一概率；

响应于确定所述第一概率表示不能确定所述乘客尚未上车，获取与所述车辆服务行程相关联的、所述计费时间点之后的流式数据；以及

基于所述流式数据来管理所述车辆服务行程。

2.根据权利要求1所述的方法，其中基于所述快照数据确定所述第一概率包括：

基于所述快照数据确定与所述计费时间点相关联的快照特征；以及

基于所述快照特征以及第一关联关系来确定所述第一概率，所述第一关联关系表示车辆服务行程在参考时间点的特征与乘客的上车概率之间的关联关系。

3.根据权利要求1所述的方法，其中获取所述快照数据包括获取以下中的至少任一项：所述车辆服务行程的行程数据、所述司机和乘客的状态数据、所述司机的历史数据、所述司机与所述乘客之间的通信数据以及所述司机所在的车辆的监视数据。

4.根据权利要求3所述的方法，其中所述司机的所述状态数据包括以下中的至少任一项：所述司机的位置、朝向、速度、加速度、与所述乘客之间的距离、所述位置与所述车辆服务行程的匹配度。

5.根据权利要求3所述的方法，其中所述通信数据包括以下中的至少任一项：所述司机和所述乘客之间是否进行了通信、成功通信次数、通信时间长度、当前是否正在通信、失败通信次数、失败通信原因、通信的发起者以及接受者。

6.根据权利要求3所述的方法，其中获取所述快照数据进一步包括：从所述监视数据中识别所述车辆中的乘客的数量。

7.根据权利要求1所述的方法，其中获取所述流式数据包括获取所述计费时间点之后的时间段内的以下中的至少任一项：所述司机和所述乘客的状态数据流、所述司机和所述乘客之间的通信数据流、以及所述司机所在的车辆的监视数据流。

8.根据权利要求1所述的方法，其中基于所述流式数据来管理所述车辆服务行程包括：

基于所述流式数据来确定表示所述乘客尚未上车的第二概率；以及

基于所述第二概率来管理所述车辆服务行程。

9.根据权利要求8所述的方法，其中基于所述流式数据确定所述第二概率包括：

基于所述流式数据提取与所述时间段相关联的流式特征；以及

基于所述流式特征以及第二关联关系来确定所述第二概率，所述第二关联关系表示车辆服务行程的在参考时间段期间的流式特征与乘客的上车概率之间的关联关系。

10.根据权利要求8所述的方法，其中基于所述第二概率来管理所述车辆服务行程包括以下中的至少任一项：

响应于确定所述第二概率表示所述乘客尚未上车，结束所述计费；以及

响应于确定所述第二概率表示不能确定所述用户尚未上车，向所述司机提供停止所述计费的警告数据。

11.根据权利要求1所述的方法，进一步包括：

响应于确定所述第一概率表示所述用户没有上车，向所述乘客提供用于确定所述乘客是否已经上车的查询；

响应于接收到来自所述乘客的查询结果为“已经上车”，允许所述计费；以及

响应于接收到来自所述乘客的查询结果为“尚未上车”，结束所述计费。

12.根据权利要求11所述的方法，进一步包括：响应于等待来自于所述乘客的查询结果的等待时间超过预定时间长度，结束所述计费。

13.一种用于管理车辆服务行程的装置，包括：

快照数据获取模块，配置用于获取与所述车辆服务行程相关联的、在所述车辆服务行程的计费时间点的快照数据，所述车辆服务行程的司机在所述计费时间点开始对所述车辆服务行程的计费；

确定模块，配置用于基于所述快照数据，确定表示所述车辆服务行程的乘客尚未上车的第一概率；

流式数据获取模块，配置用于响应于确定所述第一概率表示不能确定所述乘客尚未上车，获取与所述车辆服务行程相关联的、所述计费时间点之后的流式数据；以及

管理模块，配置用于基于所述流式数据来管理所述车辆服务行程。

14.一种电子设备，包括：

存储器和处理器；

其中所述存储器用于存储一条或多条计算机指令，其中所述一条或多条计算机指令被所述处理器执行以实现根据权利要求1至12中任一项所述的方法。

15.一种计算机可读存储介质，其上存储有一条或多条计算机指令，其中所述一条或多条计算机指令被处理器执行以实现根据权利要求1至12中任一项所述的方法。

Images