一种拼车上车点的推荐方法和系统与流程

本申请涉及网约车领域，特别涉及一种拼车上车点的推荐方法和系统。

背景技术：

拼车业务与快车、顺风车等其他网约车业务不同，往往一个订单中存在多个上车点，司机需要一趟行程中到达多个地点去接载用户，以满足多个用户的需求。难免会出现有的拼车上车点可能在小区内，或是在胡同内，需要司机多次折返才能接载所有的用户，使得司机和用户都需要花费较多的时间和成本，极大的影响了拼车的效率，导致拼车的成功率降低。

因此，拼车业务更需要对上车点的选取进一步优化，以提高拼车业务的效率。

技术实现要素：

本申请实施例之一提供一种拼车上车点的推荐方法。所述拼车上车点的推荐方法包括：获取第一上车点集合，所述第一上车点集合包括多个上车点，提取所述多个上车点中每个上车点的至少一个特征信息；基于所述多个上车点中每个上车点的至少一个特征信息，从第一上车点集合中确定出候选上车点作为拼车上车点集合；获取当前订单的至少一个位置信息；基于所述当前订单的至少一个位置信息与所述拼车上车点集合，推荐与当前订单相关的拼车上车点。

在一些实施例中，所述特征信息至少包括：上车点热度、上车点位置属性和上车点步行成本；所述上车点热度为历史订单中所述上车点出现的频次；所述上车点位置属性为所述上车点所在的位置是否为兴趣区内，或者所述上车点所在的道路是否为不通道路；所述上车点步行成本为用户前往所述上车点需要的时间或距离。

在一些实施例中，所述基于所述多个上车点中每个上车点的至少一个特征信息，从第一上车点集合中确定出候选上车点作为拼车上车点集合，包括：确定所述特征信息对应的阈值；将所述特征信息与所述对应的阈值进行比较，确定所述上车点是否为候选上车点。

在一些实施例中，当所述上车点位置属性为所述上车点所在的位置在某兴趣区内，确定所述兴趣区的面积；将所述兴趣区面积大于面积阈值的上车点确定为候选上车点。

在一些实施例中，当所述上车点位置属性为所述上车点所在的道路为不通道路；将所述上车点确定为非候选上车点。

在一些实施例中，所述基于所述多个上车点中每个上车点的至少一个特征信息，从第一上车点集合中确定出候选上车点作为拼车上车点集合，包括：确定所述上车点的各个特征信息的分值和权重；基于所述特征信息的分值和权重确定所述上车点的有效值；基于所述有效值确定候选上车点。

在一些实施例中，所述基于所述多个上车点中每个上车点的至少一个特征信息，从第一上车点集合中确定出候选上车点作为拼车上车点集合，包括：获取上车点确定模型；基于所述上车点确定模型确定候选上车点。

在一些实施例中，所述获取上车点确定模型，包括：获取一定时间内的历史订单，提取所述历史订单中的上车点的特征信息；将历史订单中上车点适合做拼车上车点的训练样本标记为正样本，将历史订单中上车点不适合做拼车上车点的训练样本标记为负样本；基于所述特征信息和标记的结果训练得到所述上车点确定模型。

在一些实施例中，所述上车点确定模型为分类模型。

本申请实施例之一提供一种拼车上车点的推荐系统，包括：获取模块，用于获取第一上车点集合，所述第一上车点集合包括多个上车点，提取所述多个上车点中每个上车点的至少一个特征信息；候选上车点确定模块，用于基于所述多个上车点中每个上车点的至少一个特征信息，从第一上车点集合中确定出候选上车点作为拼车上车点集合；推荐模块，用于获取当前订单的至少一个位置信息，基于所述当前订单的至少一个位置信息与所述拼车上车点集合，推荐与当前订单相关的拼车上车点。

本申请实施例之一提供一种拼车上车点推荐装置，包括至少一个存储介质及至少一个处理器；所述至少一个存储介质用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令，以实现如前所述的拼车上车点的推荐方法。

本申请实施例之一提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行拼车上车点的推荐方法。

本申请实施例之一提供一种拼车上车点显示方法，包括：获取当前订单中的至少一个位置信息，并将所述至少一个位置信息发送至服务器；获取所述服务器推荐的与所述至少一个位置信息相关的拼车上车点；输出所述拼车上车点；所述拼车上车点的由以下步骤确定：获取第一上车点集合，所述第一上车点集合包括多个上车点，提取所述多个上车点中每个上车点的至少一个特征信息；基于所述多个上车点中每个上车点的至少一个特征信息，从第一上车点集合中确定出候选上车点作为拼车上车点集合；获取当前订单的至少一个位置信息；基于所述当前订单的至少一个位置信息与所述拼车上车点集合，推荐与当前订单相关的拼车上车点。

本申请实施例之一提供一种拼车上车点显示系统，包括：获取当前订单中的至少一个位置信息，并将所述至少一个位置信息发送至服务器；获取所述服务器推荐的与所述至少一个位置信息相关的拼车上车点；输出所述拼车上车点；所述拼车上车点的由以下步骤确定：获取第一上车点集合，所述第一上车点集合包括多个上车点，提取所述多个上车点中每个上车点的至少一个特征信息；基于所述多个上车点中每个上车点的至少一个特征信息，从第一上车点集合中确定出候选上车点作为拼车上车点集合；获取当前订单的至少一个位置信息；基于所述当前订单的至少一个位置信息与所述拼车上车点集合，推荐与当前订单相关的拼车上车点。

本申请实施例之一提供一种拼车上车点显示装置，包括至少一个存储介质及至少一个处理器；所述至少一个存储介质用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令，以实现如前所述的拼车上车点显示方法。

本申请实施例之一提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行拼车上车点显示方法。

附图说明

本申请将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：

图1是根据本申请一些实施例所示的一种按需服务系统的应用场景示意图；

图2是根据本申请一些实施例所示的一种示例性计算设备的示意图；

图3是根据本申请一些实施例所示的拼车上车点推荐系统的模块图；

图4是根据本申请一些实施例所示的拼车上车点推荐方法的示例性流程图；

图5是根据本申请一些实施例所示的另一种拼车上车点推荐方法的示例性流程图；

图6是根据本申请一些实施例所示的上车点确定模型训练方法的示例性流程图；

图7是根据本申请一些实施例所示的一种拼车上车点推荐方法的示例性流程图。

具体实施方式

为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

应当理解，本文使用的“系统”、“装置”、“单元”和/或“模组”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

本申请的实施例可以应用于不同的运输系统，不同的运输系统包括但不限于陆地、海洋、航空、航天等中的一种或几种的组合。例如，出租车、专车、顺风车、巴士、代驾、火车、动车、高铁、船舶、飞机、热气球、无人驾驶的交通工具、收/送快递等应用了管理和/或分配的运输系统。本申请的不同实施例应用场景包括但不限于网页、浏览器插件、客户端、定制系统、企业内部分析系统、人工智能机器人等中的一种或几种的组合。应当理解的是，本申请的系统及方法的应用场景仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其它类似情景。例如，其他类似的引导用户停车系统。

本申请描述的“乘客”、“乘客端”、“用户终端”、“顾客”、“需求者”、“服务需求者”、“消费者”、“消费方”、“使用需求者”等是可以互换的，是指需要或者订购服务的一方，可以是个人，也可以是工具。同样地，本申请描述的“司机”、“司机端”、“提供者”、“供应者”、“服务提供者”、“服务者”、“服务方”等也是可以互换的，是指提供服务或者协助提供服务的个人、工具或者其他实体等。另外，本申请描述的“用户”可以是需要或者订购服务的一方，也可以是提供服务或者协助提供服务的一方。

图1是根据本申请的一些实施例所示的一种按需服务系统100的示意图。例如，按需服务系统100可以是一个为交通运输服务提供服务的平台。按需服务系统100可以包括服务器110、一个或一个以上用户终端120、存储设备130、网络150和信息源140。服务器110可以包括一个处理引擎112。

在一些实施例中，服务器110可以是一个单个的服务器或者一个服务器群组。所述服务器群可以是集中式的或分布式的(例如，服务器110可以是一个分布式的系统)。在一些实施例中，服务器110可以是本地的或远程的。例如，服务器110可以通过网络150访问存储在存储设备130、用户终端120中的信息和/或数据。再例如，服务器110可以直接连接到存储设备130、用户终端120以访问存储的信息和/或数据。在一些实施例中，服务器110可以在一个云平台上实现。仅仅举个例子，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、云之间、多重云等或上述举例的任意组合。在一些实施例中，服务器110可以在与本申请图2所示的计算设备上实现。例如，服务器110可以在如图2所示的一个计算设备200上实现，包括计算设备200中的一个或多个部件。

在一些实施例中，服务器110可以包括一个处理引擎112。处理引擎112可以处理与服务请求相关的信息和/或数据以执行本申请描述的一个或多个功能。例如，处理引擎112可以根据上车点的特征信息确定候选上车点，还可以根据候选上车点确定推荐拼车上车点。在一些实施例中，处理引擎112可以包括一个或多个处理器(例如，单核处理器或多核处理器)。仅仅举个例子，处理引擎112可以包括一个或多个硬件处理器，例如中央处理器(cpu)、专用集成电路(asic)、专用指令集处理器(asip)、图像处理器(gpu)、物理运算处理器(ppu)、数字信号处理器(dsp)、现场可编辑门阵列(fpga)、可编辑逻辑器件(pld)、控制器、微控制器单元、精简指令集计算机(risc)、微处理器等或上述举例的任意组合。

用户终端120可以是直接与服务订单相关联的个人、工具或其他实体，例如服务订单的请求者与提供服务者。用户终端120可以是乘客。在本申请中，“乘客”和“服务请求端”可以互换使用。在一些实施例中，用户终端120可以包括但不限于台式电脑120-1、笔记本电脑120-2，车载内置设备120-3、移动设备120-4等或其任意组合。用户终端120可以在线发送服务请求。例如，用户终端120可以基于当前所在位置及目的地发送网约车订单。在一些实施例中，车载内置设备120-3可以包括但不限于个车载电脑、车载抬头显示(hud)、车载自动诊断系统(obd)等或其任意组合。在一些实施例中，移动设备120-4可以包括但不限于智能手机、个人数码助理(personaldigitalassistance，pda)、平板电脑、掌上游戏机、智能眼镜、智能手表、可穿戴设备、虚拟显示设备、显示增强设备等或其任意组合。在一些实施例中，用户终端120可以将服务订单信息发送至按需服务系统100中的一个或多个设备中。例如，用户终端120可以将服务订单信息发送至服务器110进行处理。用户终端120也可以包括上述类似的设备中的一种或多种。

存储设备130可以存储数据和/或指令。在一些实施例中，存储设备130可以存储从用户终端120获得的数据。在一些实施例中，存储设备130可以存储供服务器110执行或使用的数据和/或指令，服务器110可以通过执行或使用所述数据和/或指令以实现本申请描述的示例性方法。在一些实施例中，存储设备130可以包括大容量存储器、可移动存储器、挥发性读写存储器、只读存储器(rom)等或上述举例的任意组合。示例性的大容量存储器可以包括磁盘、光盘、固态硬盘等。示例性的可移动存储器可以包括闪存盘、软盘、光盘、记忆卡、压缩硬盘、磁带等。示例性的挥发性只读存储器可以包括随机存储器(ram)。示例性的随机存储器可以包括动态随机存储器(dram)、双数据率同步动态随机存储器(ddrsdram)、静态随机存储器(sram)、可控硅随机存储器(t-ram)和零电容存储器(z-ram)等。示例性的只读存储器可以包括掩蔽型只读存储器(mrom)、可编程只读存储器(prom)、可擦除可编程只读存储器(eprom)、电可擦除可编程只读存储器(eeprom)、压缩硬盘只读存储器(cd-rom)和数字多功能硬盘只读存储器等。在一些实施例中，存储设备130可以在一个云平台上实现。仅仅举个例子，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、云之间、多重云等或上述举例的任意组合。

在一些实施例中，存储设备130可以与网络150连接以实现与按需服务系统100中的一个或多个部件(例如，服务器110、用户终端120等)之间的通信。按需服务系统100的一个或多个部件可以通过网络150访问存储在存储设备130中的数据或指令。在一些实施例中，存储设备130可以直接与按需服务系统100的一个或多个部件(例如，服务器110、用户终端120等)连接或通信。在一些实施例中，存储设备130可以是服务器110的一部分。

网络150可以促进信息和/或数据的交换。在一些实施例中，按需服务系统100中的一个或多个部件(例如，服务器110、存储设备130、用户终端120等)可以通过网络150向按需服务系统100中的其他部件发送信息和/或数据。例如，服务器110可以通过网络150从用户终端120获取/得到请求。在一些实施例中，网络150可以是有线网络或无线网络中的任意一种，或其组合。例如，网络150可以包括电缆网络、有线网络、光纤网络、远程通信网络、内联网、互联网、局域网(lan)、广域网(wan)、无线局域网(wlan)、城域网(man)、公共开关电话网络(pstn)、蓝牙网络、zigbee网络、近场通讯(nfc)网络等或上述举例的任意组合。在一些实施例中，网络150可以包括一个或多个网络接入点。例如，网络150可能包括有线或无线网络接入点，如基站和/或互联网交换点150-1、150-2等等。通过接入点，按需服务系统100的一个或多个部件可能连接到网络150以交换数据和/或信息。

信息源140是为按需服务系统100提供其他信息的一个源。信息源160可以用于为系统提供与服务相关的信息，例如，天气情况、交通信息、法律法规信息、新闻信息、生活资讯、生活指南信息等。信息源140可以是一个单独的中央服务器的形式存在，也可以是以多个通过网络连接的服务器的形式存在，还可以是以大量的个人设备形式存在。当信息源140以大量个人设备形式存在时，这些设备可以通过一种用户生成内容(user-generatedcontents)的方式，例如向云端服务器上传文字、语音、图像、视频等，从而是云端服务器连通与其连接的众多个人设备一起组成信息源140。

图2是根据本申请的一些实施例所示的一种示例性计算设备200的示意图。服务器110、用户终端120和存储设备130可以在计算设备200上实现。例如，处理引擎112可以在计算设备200上实现并被配置为实现本申请中所披露的功能。

计算设备200可以包括用来实现本申请所描述的系统的任意部件。例如，处理引擎112可以在计算设备200上通过其硬件、软件程序、固件或其组合实现。为了方便起见图中仅绘制了一台计算机，但是本申请所描述的与按需服务系统100相关的计算功能可以以分布的方式、由一组相似的平台所实施，以分散系统的处理负荷。

计算设备200可以包括与网络连接的通信端口250，用于实现数据通信。计算设备200可以包括一个处理器(例如，cpu)220，可以以一个或多个处理器的形式执行程序指令。示例性的电脑平台可以包括一个内部总线210、不同形式的程序存储器和数据存储器包括，例如，硬盘270、和只读存储器(rom)230或随机存储器(ram)240，用于存储由计算机处理和/或传输的各种各样的数据文件。示例性的计算设备可以包括存储在只读存储器230、随机存储器240和/或其他类型的非暂时性存储介质中的由处理器220执行的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。计算设备200也包括输入/输出部件260，用于支持电脑与其他部件之间的输入/输出。计算设备200也可以通过网络通讯接收本披露中的程序和数据。

为理解方便，图2中仅示例性绘制了一个处理器。然而，需要注意的是，本申请中的计算设备200可以包括多个处理器，因此本申请中描述的由一个处理器实现的操作和/或方法也可以共同地或独立地由多个处理器实现。例如，如果在本申请中，计算设备200的处理器执行步骤1和步骤2，应当理解的是，步骤1和步骤2也可以由计算设备200的两个不同的处理器共同地或独立地执行(例如，第一处理器执行步骤1，第二处理器执行步骤2，或者第一和第二处理器共同地执行步骤1和步骤2)。

图3是根据本申请一些实施例所示的拼车上车点推荐系统的模块图。如图3所示，该拼车上车点推荐系统可以包括获取模块310、候选上车点确定模块320、推荐模块330和训练模块340。

获取模块310可以用于获取第一上车点集合，所述第一上车点集合包括多个上车点，提取所述多个上车点中每个上车点的至少一个特征信息。在一些实施例中，所述特征信息至少包括上车点热度、上车点位置属性和上车点步行成本中的一种或几种的组合。在一些实施例中，所述上车点热度为历史订单中所述上车点出现的频次。上车点位置属性为所述上车点所在的位置是否为兴趣区内，或者所述上车点所在的道路是否为不通道路。所述上车点步行成本为用户前往所述上车点需要的时间或距离。在一些实施例中，第一上车点集合可以包括拼车订单、专车订单、快车订单、顺风车订单、出租车订单等订单中的上车点。

候选上车点确定模块320可以用于基于所述多个上车点中每个上车点的至少一个特征信息，从第一上车点集合中确定出候选上车点作为拼车上车点集合。在一些实施例中，候选上车点确定模块320可以用于确定所述特征信息对应的阈值，将所述特征信息与所述对应的阈值进行比较，确定所述上车点是否为候选上车点。例如，可以设置热度阈值，将上车点的热度与热度阈值进行比较，将大于热度阈值的上车点确定为候选上车点。又例如，可以设置面积阈值，将上车点位置属性为上车点所在的位置在某兴趣区内的上车点，根据该兴趣区的边界信息计算该兴趣区的面积，当兴趣区面积大于面积阈值，可以增加该上车点拼车成功的概率，将该上车点确定为候选上车点。又例如，当所述上车点位置属性为所述上车点所在的位置为某道路上，可以将通畅道路属性设置为数值“1”，将不通道路属性设置为数值“0”，当道路属性阈值大于“0”时，该上车点拼车成功概率较大，将该上车点确定为候选上车点。再例如，可以设置时间成本阈值或距离成本阈值，将用户从起点到上车点的时间成本与时间成本阈值进行比较，将时间成本小于时间成本阈值的上车点确定为候选上车点，或是将用户从起点到上车点的步行距离成本与距离阈值进行比较，将步行距离成本小于距离阈值的上车点确定为候选上车点。在一些实施例中，可以获取该上车点的至少一个特征信息，将该特征信息与阈值进行比较，确定该上车点是否是候选上车点。例如，可以只获取该上车点步行成本作为特征信息，判断步行成本是否小于时间成本阈值或距离成本阈值，将小于阈值的上车点确定为候选上车点。又例如，可以获取全部的特征信息，并要求全部的特征信息都满足阈值范围时，才将该上车点确定为候选上车点。又例如，可以获取全部的特征信息，但只要有两个特征信息满足阈值范围，就可以将该上车点确定为候选上车点。在一些实施例中，可以确定所述上车点的各个特征信息的分值和权重，基于所述特征信息的分值和权重确定所述上车点的有效值，基于所述有效值确定候选上车点。在一些实施例中，候选上车点确定模块320可以获取上车点确定模型，基于所述上车点确定模型确定候选上车点。在一些实施例中，可以获取第一上车点集合中的每一个上车点的特征信息，将上车点的特征信息输入上车点确定模型中，经过上车点确定模型输出该上车点是否是候选上车点的结果。

推荐模块330可以用于获取当前订单的至少一个位置信息，基于所述当前订单的至少一个位置信息与所述拼车上车点集合，推荐与当前订单相关的拼车上车点。

训练模块340可以用于获取一定时间内的历史订单，提取所述历史订单中的上车点的特征信息，将历史订单中上车点适合做拼车上车点的训练样本标记为正样本，将历史订单中上车点不适合做拼车上车点的训练样本标记为负样本，基于所述特征信息和标记的结果训练得到所述上车点确定模型。在一些实施例中，上车点确定模型可以为分类模型。具体训练方法在流程600中有详细描述，请参见流程600。

应当理解，图3所示的系统及其模块可以利用各种方式来实现。例如，在一些实施例中，系统及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、cd或dvd-rom的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的系统及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。

需要注意的是，以上对于候选项显示、确定系统及其模块的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。例如，在一些实施例中，例如，图3中披露的获取模块310、候选上车点确定模块320、推荐模块330和训练模块340可以是一个系统中的不同模块，也可以是一个模块实现上述的两个或两个以上模块的功能。例如，候选上车点确定模块320、推荐模块330可以是两个模块，也可以是一个模块同时具有发送和接收功能。例如，各个模块可以共用一个存储模块，各个模块也可以分别具有各自的存储模块。诸如此类的变形，均在本申请的保护范围之内。

图4所示为根据本申请一些实施例所示的拼车上车点推荐方法的示例性流程图。如图4所示，该拼车上车点推荐方法400可以包括：

步骤410，可以获取第一上车点集合。具体的，该步骤410可以由获取模块310执行。在一些实施例中，第一上车点集合可以从历史订单中获取。第一上车点集合可以是历史订单中的所有历史上车点的集合。在一些实施例中，历史订单可以是一段时间内的历史订单，例如，半年内的历史订单、一年内的历史订单或三年内的历史订单等。在一些实施例中，第一上车点集合可以直接从系统100的后台数据中获取。第一上车点集合可以是与系统后台中的订单相关的上车点的集合。系统后台中的订单可以包括正在运行的订单、刚完结的订单、已提交订单、暂存订单等系统内已生成已保存的订单。在一些实施例中，第一上车点集合可以是某一区域内的多个上车点的集合。例如，可以是北京市内的多个上车点的集合，或是北京市海淀区内的多个上车点的集合，还可以是北京市海淀区人民大学方圆1公里区域内的上车点的集合。在一些实施例中，第一上车点集合可以包括拼车订单、专车订单、快车订单、顺风车订单、出租车订单等订单中的上车点。

在一些实施例中，可以提取多个上车点中每个上车点的至少一个特征信息。在一些实施例中，特征信息可以包括上车点热度、上车点位置属性和上车点步行成本。在一些实施例中，上车点热度可以为历史订单中所述上车点出现的频次。例如，上车点热度可以是某个上车点在半年内作为上车点出现的次数。在一些实施例中，上车点热度可以是历史订单中该上车点作为拼车上车点的次数。例如，在拼车订单中，某一上车点拼车成功的次数。在一些实施例中，上车点热度可以是与某起点相关的作为上车点出现的次数。例如，可以是起点为人民大学东门的历史订单中，某上车点出现的次数。

在一些实施例中，上车点位置属性可以为所述上车点所在的位置是否为兴趣区(areaofinterest，aoi)内。在一些实施例中，兴趣区一般指学校、小区、商场、公园等具有一定面积的建筑的边界信息。例如可以获取上车点的经纬度等位置信息，判断上车点是否位于某小区内。如果上车点位于某小区内，可能不方便开车进入，降低拼车成功的概率。在一些实施例中，上车点位置属性可以为所述上车点所在的道路是否为不通道路。例如，因修路而无法通行的道路、尚未通车需折返的道路、前方为胡同不能通行的道路、前方为小区或步行街进行机动车通行的道路等不通道路。当上车点位于不通道路上时，会影响司机的接车效率，降低拼车成功的概率。

在一些实施例中，上车点步行成本可以为用户前往所述上车点需要的时间。例如，可以获取历史订单数据中，用户从某起点到该上车点的步行的平均时间。或者，可以从地图上计算出用户从某起点到该上车点的球面距离，根据球面距离估算出用户的步行时间。还可以根据用户从某起点到该上车点的步行时间、步行距离和球面距离等数据信息，综合估算用户的步行时间。在一些实施例中，上车点步行成本可以为用户前往所述上车点需要的距离。例如，可以根据历史订单数据中，用户从某起点到该上车点的步行的平均距离确定。或者可以根据用户的步行时间估算用户的步行距离。对于步行时间或步行距离等步行成本较高的上车点，会影响司机的接车效率，降低拼车成功的概率。

在步骤420中，可以基于所述多个上车点中每个上车点的至少一个特征信息，从第一上车点集合中确定出候选上车点作为拼车上车点集合。在一些实施例中，步骤420可以由候选上车点确定模块320执行。在一些实施例中，可以确定每个特征信息对应的阈值，将所述特征信息与所述对应的阈值进行比较，确定所述上车点是否为候选上车点。例如，可以设置热度阈值，将上车点的热度与热度阈值进行比较，将大于热度阈值的上车点确定为候选上车点。又例如，可以设置面积阈值，将上车点位置属性为上车点所在的位置在某兴趣区内的上车点，根据该兴趣区的边界信息计算该兴趣区的面积，当兴趣区面积大于面积阈值，可以增加该上车点拼车成功的概率，将该上车点确定为候选上车点。又例如，当所述上车点位置属性为所述上车点所在的位置为某道路上，可以将通畅道路属性设置为数值“1”，将不通道路属性设置为数值“0”，当道路属性阈值大于“0”时，该上车点拼车成功概率较大，将该上车点确定为候选上车点。再例如，可以设置时间成本阈值或距离成本阈值，将用户从起点到上车点的时间成本与时间成本阈值进行比较，将时间成本小于时间成本阈值的上车点确定为候选上车点，或是将用户从起点到上车点的步行距离成本与距离阈值进行比较，将步行距离成本小于距离阈值的上车点确定为候选上车点。

在一些实施例中，可以获取该上车点的至少一个特征信息，将该特征信息与阈值进行比较，确定该上车点是否是候选上车点。例如，可以只获取该上车点步行成本作为特征信息，判断步行成本是否小于时间成本阈值或距离成本阈值，将小于阈值的上车点确定为候选上车点。又例如，可以获取全部的特征信息，并要求全部的特征信息都满足阈值范围时，才将该上车点确定为候选上车点。又例如，可以获取全部的特征信息，但只要有两个特征信息满足阈值范围，就可以将该上车点确定为候选上车点。

在一些实施例中，可以确定所述上车点的各个特征信息的分值和权重，基于所述特征信息的分值和权重确定所述上车点的有效值，基于所述有效值确定候选上车点。例如，可以将上车点出现的次数值作为上车点热度的分值，将上车点所在的位置为通畅道路的属性设置为分值“1”，将上车点所在的位置为不通道路的属性设置为分值“0”，将上车点所在的兴趣区的面积作为分值，将用户从某起点到该上车点的步行成本作为分值。再将各个特征信息的分值进行加法运算得到该上车点的有效值。在一些实施例中，可以设置每个特征信息的权重，根据各个特征信息的分值和权重计算该上车点的有效值。例如，可以设置上车点步行成本的权重设置为最高，上车点位置属性的权重设置为次之，将上车点热度的权重设置最低，将各个特征信息的分值与对应的权重乘法运算，在将各个特征信息与权重相乘的结果进行加法运算得到该上车点的有效值。在一些实施例中，可以根据该上车点的有效值是否大于某预设值，确定该上车点是否为候选上车点。在一些实施例中，可以根据上车点的有效值对多个上车点进行排序，将排序靠前的多个上车点确定为候选上车点以构成拼车上车点集合。

步骤430，可以获取当前订单的至少一个位置信息，基于所述当前订单的至少一个位置信息与所述拼车上车点集合，推荐与当前订单相关的拼车上车点。在一些实施例中，步骤430可以由推荐模块330执行。在一些实施例中，可以获取当前订单的至少一个上车点的定位信息。或者，可以获取当前订单的至少一个当前用户的定位信息。在一些实施例中，可以根据候选上车点集合确定与上车点或用户定位的位置信息相关的推荐上车点。例如，可以基于候选上车点集合找出与用户定位和上车点相关联的多个候选上车点，按照能够提高拼车成功率的条件将候选上车点进行排序，将拼车成功可能性最高的候选上车点确定为推荐上车点，并将推荐上车点向用户和司机输出。基于候选上车点确定推荐上车点可以提高用户拼车成功的概率，并提高司机接送用户的效率，提高拼车订单的整体效率。

应当注意的是，上述有关流程400的描述仅仅是为了示例和说明，而不限定本申请的适用范围。对于本领域技术人员来说，在本申请的指导下可以对流程400进行各种修正和改变。然而，这些修正和改变仍在本申请的范围之内。

图5所示为根据本申请一些实施例所示的另一种拼车上车点推荐方法的示例性流程图。如图5所示，另一种拼车上车点推荐方法500可以包括：

步骤510，可以获取第一上车点集合，所述第一上车点集合包括多个上车点，提取所述多个上车点中每个上车点的至少一个特征信息。在一些实施例中，步骤510可以由获取模块310执行。该步骤与前述步骤410相同，具体说明可参见步骤410。

步骤520，获取上车点确定模型。在一些实施例中，步骤520可以由候选上车点确定模块320执行。在一些实施例中，上车点确定模型可以是机器学习模型中的分类模型。例如，可以是分类及回归树(classificationandregressiontree，cart)、迭代二叉树三代(iterativedichotomiser3，id3)、c4.5算法、随机森林(randomforest)、卡方自动交互检测(chisquaredautomaticinteractiondetection，chaid)、多元自适应回归样条(multivariateadaptiveregressionsplines，mars)、梯度推进机(gradientboostingmachine，gbm)以及梯度提升决策树(gradientboostingdecisiontree，gbdt)中的一种或其任意组合。在一些实施例中，可以通过模型训练得到上车点确定模型中的分类阈值，确定最终的模型结构。具体训练方法在流程600中有详细描述，请参见流程600。

步骤530，基于所述上车点确定模型确定候选上车点。在一些实施例中，步骤530可以由候选上车点确定模块320执行。在一些实施例中，可以获取第一上车点集合中的每一个上车点的特征信息，将上车点的特征信息输入上车点确定模型中，经过上车点确定模型输出该上车点是否是候选上车点的结果。在一些实施例中，上车点的特征信息包括上车点热度、上车点位置属性和上车点步行成本中的一种或几种的组合。在一些实施例中，可以将第一上车点集合中的每一个上车点一一经过上车点确定模型，判断每一个上车点是否是候选上车点，将所有的候选上车点组成拼车上车点集合。在一些实施例中，得到拼车上车点集合后，可以基于拼车上车点集合确定当前订单的至少一个位置信息的推荐上车点。以达到过滤低效拼车上车点，提高拼车成功率的目的。

应当注意的是，上述有关流程500的描述仅仅是为了示例和说明，而不限定本申请的适用范围。对于本领域技术人员来说，在本申请的指导下可以对流程500进行各种修正和改变。然而，这些修正和改变仍在本申请的范围之内。

图6所示为根据本申请一些实施例所示的上车点确定模型训练方法的示例性流程图。如图6所示，上车点确定模型训练方法600可以包括：

在步骤610中，可以获取一定时间内的历史订单，提取所述历史订单中的上车点的特征信息。在一些实施例中，步骤610可以由训练模块340执行。在一些实施例中，可以获取一个月内的历史订单、一个季度的历史订单、一年的历史订单、或是三年内的历史订单。在一些实施例中，历史订单可以包括拼车订单、快车订单、顺风车订单、专车订单、出租车订单等约车订单。在一些实施例中，上车点的特征信息可以是上车点热度、上车点位置属性和上车点步行成本中的一种或几种的组合。训练模块340可以从系统100、服务器110、终端120、存储设备130、网络150、信息源140或本申请中公开的能够存储数据的任何设备或组件中的一个或一个以上获取数据。

在步骤620中，可以将历史订单中上车点适合做拼车上车点的训练样本标记为正样本，将历史订单中上车点不适合做拼车上车点的训练样本标记为负样本。在一些实施例中，步骤630可以由训练模块340执行。在一些实施例中，可以结合统计数据，人工对训练样本进行标记。在一些实施例中，适合做拼车上车点的上车点可以上车点的特征信息满足阈值范围的上车点。例如，可以是上车点的上车点热度大于热度阈值的上车点。又例如，可以是上车点步行成本小于时间成本阈值或距离成本阈值的上车点。又例如，可以是上车点的位置属性为上车点不在不通道路的上车点。又例如，可以是上车点的位置属性为上车点在兴趣区内，但是兴趣区的面积大于面积阈值的上车点。在一些实施例中，可以将上车点的特征信息不满足阈值范围的上车点标记为负样本。

在步骤630中，可以基于所述特征信息和标记的结果训练得到所述上车点确定模型。在一些实施例中，步骤630可以由训练模块340执行。在一些实施例中，可以将历史订单中的上车点的特征信息和历史订单的标记结果作为训练样本对上车点确定模型进行训练。例如，输入样本为历史订单中的上车点的特征信息，目标样本为前述标记的正样本和负样本。在一些实施例中，可以一定时间对训练好的上车点确定模型进行更新。例如，可以一个星期或一个月对上车点确定模型进行更新。将最近一个星期或一个月内的历史订单作为训练样本，获取更新样本的上车点的特征信息及标记结果对模型进行更新。

应当注意的是，上述有关流程600的描述仅仅是为了示例和说明，而不限定本申请的适用范围。对于本领域技术人员来说，在本申请的指导下可以对流程600进行各种修正和改变。然而，这些修正和改变仍在本申请的范围之内。

图7所示为根据本申请一些实施例所示的拼车上车点推荐方法的示例性流程图。如图7所示，拼车上车点推荐方法700可以包括：

步骤710，获取当前订单的至少一个位置信息。在一些实施例中，可以根据用户发出的服务请求中的位置信息确定多个上车点。例如，用户可以在约车平台上输入订单的起点位置和终点位置，服务器可以根据起点位置确定多个上车点。又例如，用户可以直接在地图上将出发位置用大头针选中，服务器可以根据地图上大头针指示的位置确定多个候选位置。再例如，用户可以将当前定位信息作为订单的出发位置信息，根据用户的当前定位信息确定多个上车点。在一些实施例中，服务器获取到当前订单的位置信息后，可以根据历史订单数据确定多个相关的上车点。例如，历史订单中与当前位置相关的作为历史上车点的多个上车点。

步骤720，获取第一上车点集合，所述第一上车点集合包括多个上车点，提取所述多个上车点中每个上车点的至少一个特征信息。在一些实施例中，可以将与当前订单相关的多个上车点确定为第一上车点集合。例如，服务器获取到用户的输入的起点位置，根据该起点位置确定了多个相关的上车点，服务器可以将这些相关的上车点确定为第一上车点集合。在一些实施例中，特征信息可以包括上车点热度、上车点位置属性和上车点步行成本中的一种或几种的组合。在一些实施例中，可以获取每个上车点的特征信息，根据每个上车点对应的特征信息确定上车点是否可以作为拼车上车点集合。

步骤730，基于所述多个上车点中每个上车点的至少一个特征信息，判断该特征信息是否符合阈值条件，如果判断为是，则执行步骤740，从第一上车点集合中将该上车点确定为拼车上车点，加入拼车上车点集合。在一些实施例中，每个特征信息有对应的阈值，可以将上车点对应的至少一个特征信息与对应的阈值进行比较，将满足阈值要求的上车点确定为拼车上车点。例如，可以根据用户输入的订单起点位置获取多个相关的上车点，将多个上车点确定为第一上车点集合，将第一上车点集合中的每一个上车点的特征信息与对应的阈值比较，确定该上车点是否是拼车上车，将多个符合阈值条件的上车点确定为拼车上车点集合。在一些实施例中，可以按照能够提高拼车成功率的条件设置特征信息对应的阈值，将多个上车点中的能够提高拼车成功率的候选上车点筛选确定为拼车上车点。例如，服务器根据用户输入的位置确定了10个候选上车点，每个候选上车点的特征信息与对应的阈值比较，最终筛选了其中5个上车点为拼车上车点集合。

步骤750，基于所述拼车上车点集合，推荐与当前订单相关的拼车上车点。在一些实施例中，可以基于训练好的推荐模型确定推荐上车点。例如，可以获取如前所述的推荐模型，将拼车上车点集合中的上车点的特征信息作为模型的输入，通过推荐模型输出最后的推荐上车点。例如，服务器根据用户输入的位置确定了10个候选上车点，每个候选上车点的特征信息与对应的阈值比较，最终筛选了其中5个上车点为拼车上车点集合。服务器基于推荐模型确定出最优的1个上车点作为推荐的拼车上车点，并将该拼车上车点在约车平台中输出给用户。

步骤760，用户确定拼车上车点。在一些实施例中，推荐的拼车上车点可以由服务器确定，用户无需确定拼车上车。在一些实施例中，如果用户自行确定了拼车上车点，可以提示用户有其他更优的拼车上车点可以提高拼车的成功率，建议用户选择服务器确定的拼车上车点。例如，服务器根据用户订单的位置推荐了一个最优的拼车上车点，用户自行输入了一个拼车上车点，服务器推荐的拼车上车点相对可以减少用户的步行距离，服务器可以发送对话框，提示用户，系统确定的拼车上车点可以缩短用户的步行距离，建议用户选择系统的拼车上车点。用户看到提示后，可以重新选择系统推荐的拼车上车点作为拼车上车点。

步骤770，发送接单信息给用户，并引导用户到推荐上车点。在一些实施例中，服务器将订单派发给司机，司机接单后，服务器可以将接单信息发送给拼车的用户。在一些实施例中，接单信息中可以包括司机的信息、接车车辆的车牌号信息、预估到达时间、拼车上车点位置等信息。在一些实施例中，拼车上车点可以是多个，可以是根据每个用户输入的起点位置确定适合多个用户共用的一个或多个拼车上车点。服务器可以将至少一个拼车上车点通过接单信息发送给每个拼车用户。在一些实施例中，接单信息包括预估到达时间，服务器可以根据预估到达时间提醒拼车用户提前到达指定的拼车上车点。在一些实施例中，接车信息中可以显示拼车用户是否已经上车，是否有用户没有上车。例如，拼车订单中有3个用户，已有两名用户已经上车，接单信息中可以显示已上车用户2人，带上车用户1人。在一些实施例中，接单信息中可以显示司机接单的路线、接载用户的次序等信息。在一些实施例中，接单信息中可以包括用户前往拼车上车点的路线。例如，用户根据当前位置发送了服务请求，服务器根据用户的当前位置确定了推荐的拼车上车点，接单信息中可以根据用户的当前位置和拼车上车点确定达到拼车上车点的路线，并在地图上显示该路线以供用户参考。

本申请还包括一种拼车上车点显示方法。该方法包括获取当前订单中的至少一个位置信息，并将所述至少一个位置信息发送至服务器；获取所述服务器推荐的与所述至少一个位置信息相关的拼车上车点；输出所述拼车上车点。在一些实施例中，推荐拼车上车点的方法为如前所述的推荐方法。

本申请实施例可能带来的有益效果包括但不限于：(1)本申请可以对低效的拼车上车点进行过滤，使得推荐上车点能够提高拼车成功的概率；(2)可以根据上车点热度、上车点位置属性和上车点步行成本等特征参数对上车点进行筛选，既可以节约用户的成本，也可以提高司机的接车效率，提高了拼车的整体效率，有利于提高拼车的使用率。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、rf、或类似介质，或任何上述介质的组合。

本申请各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如java、scala、smalltalk、eiffel、jade、emerald、c++、c#、vb.net、python等，常规程序化编程语言如c语言、visualbasic、fortran2003、perl、cobol2002、php、abap，动态编程语言如python、ruby和groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(lan)或广域网(wan)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(saas)。

此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

针对本申请引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本申请作为参考。与本申请内容不一致或产生冲突的申请历史文件除外，对本申请权利要求最广范围有限制的文件(当前或之后附加于本申请中的)也除外。需要说明的是，如果本申请附属材料中的描述、定义、和/或术语的使用与本申请所述内容有不一致或冲突的地方，以本申请的描述、定义和/或术语的使用为准。

最后，应当理解的是，本申请中所述实施例仅用以说明本申请实施例的原则。其他的变形也可能属于本申请的范围。因此，作为示例而非限制，本申请实施例的替代配置可视为与本申请的教导一致。相应地，本申请的实施例不仅限于本申请明确介绍和描述的实施例。