CN111881368A - 一种确定推荐上车点的方法和系统 - Google Patents

Abstract

本申请实施例公开了一种确定推荐上车点的方法。该方法包括：可以从用户终端接收服务请求。可以基于所述服务请求确定请求上车区域。可以判断所述请求上车区域的面状大小是否大于预设阈值；若是，则利用预设的上车点推荐模型，基于所述请求上车区域的特征数据，确定多个推荐上车点。可以向所述用户终端发送所述多个推荐上车点。本申请实施例公开的确定推荐上车点的方法可以基于用户输入的请求上车区域，根据该请求上车区域的面状大小，结合上车点推荐模型，为用户准确的推荐上车位置，引导乘客选择合适的上车点，提高司机接驾效率和乘客的出行体验。

Description

一种确定推荐上车点的方法和系统

技术领域

本申请涉及网约车领域，特别涉及一种确定推荐上车点的方法、系统、装置以及可读存储介质。

背景技术

近年来，随着移动通信技术的快速发展，大量基于智能终端的应用软件涌现了出来。叫车类应用是其中很受大众欢迎的一类。乘客通过客户端输入起始地和目的地信息，发送用车请求，司机根据乘客的起始地信息前去接驾。然而实际中，存在乘客定位点或者下单的地点有可能并不在起始地点附近，但是需要在起始地所在区域附近上车的情况，现有的向乘客推荐上车点的方式无法满足乘客的需求。因此，有必要提供一种确定推荐上车点的方法，以更好的引导乘客选择合适的上车点，提高乘客和司机的出行体验。

发明内容

本申请实施例的一个方面提供一种确定推荐上车点的方法。所述确定推荐上车点的方法包括：可以从用户终端接收服务请求。可以基于所述服务请求确定请求上车区域。可以判断所述请求上车区域的面状大小是否大于预设阈值；若是，则利用预设的上车点推荐模型，基于所述请求上车区域的特征数据，确定多个推荐上车点。可以向所述用户终端发送所述多个推荐上车点。

本申请实施例的另一个方面提供一种确定推荐上车点的系统，包括：获取模块，可以用于从用户终端接收服务请求。请求上车区域确定模块，可以用于基于所述服务请求确定请求上车区域。判断模块，可以用于判断所述请求上车区域的面状大小是否大于预设阈值。上车点确定模块，可以用于响应于所述请求上车区域的面状大小大于所述预设阈值，利用预设的上车点推荐模型，基于所述请求上车区域的特征数据，确定多个推荐上车点。发送模块，可以用于向所述用户终端发送所述多个推荐上车点。

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

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

附图说明

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

图1是根据本申请一些实施例所示的确定推荐上车点的系统的应用场景示意图；

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

图3是根据本申请一些实施例所示的训练上车点推荐模型的示例性流程图；

图4根据本申请一些实施例所示的确定推荐上车点的系统的模块图。

具体实施方式

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

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

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

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

本申请的实施例可以应用于不同的运输系统，例如，出租车、专车、顺风车、巴士、代驾等。本申请描述的“乘客”、“乘客端”、“乘客终端”、“顾客”、“需求者”、“服务需求者”、“服务请求者”、“消费者”、“消费方”、“使用需求者”等是可以互换的，是指需要或者订购服务的一方，可以是个人，也可以是工具。同样地，本申请描述的“司机”、“司机端”、“司机终端”、“提供者”、“供应者”、“服务提供者”、“服务者”、“服务方”等也是可以互换的，是指提供服务或者协助提供服务的个人、工具或者其他实体等。另外，本申请描述的“用户”可以是需要或者订购服务的一方，也可以是提供服务或者协助提供服务的一方。

本申请中的术语“上车点”可以指服务提供者开始提供服务请求者发起服务的位置。例如，在在线打车服务中，服务提供者可以接载发起服务的服务请求者，并且将服务请求者送到该服务请求者的目的地。本申请中的术语“真实上车点”可以指服务提供者接载到服务请求者并开始提供服务的位置，“推荐上车点”可以指服务平台推荐给服务请求者的上车点，“候选上车点”可以指可能用来提供给服务请求者的潜在上车点。

网约车服务已经成为人们交通出行的重要一部分，用户在使用网约车服务时，通常需要在乘客端输入上车点位置、目的地位置、以及上车时间，然后接单司机到达上车点接载乘客。为了使网约车司机能够以最短的时间接到用户，网约车平台会为用户推荐最佳的上车地点。相关技术中，打车系统可以基于用户输入的兴趣点(POI，Point of Interest)，并以在终端的页面前端透传出的排序top3上车点作为推荐上车点，且地图标记会自动吸附到排序top1的上车点上。当POI面状区域(表面形状区域)较大时，基于该POI召回的候选上车点集中可能会有多个上车点(例如，100个)，然而用户可能并不该POI区域附近，例如，用户当前定位位置为区域A，要为定位在区域B的朋友下订单叫车，此时位于区域A的用户的定位位置不可信，相关的上车点推荐系统会选取区域B周围热度最高的1个候选上车点作为推荐上车点，另外2个候选上车点透传到前端作为推荐展示。

然而，针对POI面状区域(例如，大型商场、学校、医院、小区等)较大，目前的上车点推荐方式单一无法满足用户的需求，且推荐上车点服务不够精确和稳定。在帮别人叫车的情况下，由于无法获取实际乘车人的位置，推荐给用户的上车点很可能无法让实际乘车人方便到达。因此，本申请提出一种确定推荐上车点的方法，基于用户输入的POI，根据该POI的面状大小，结合上车点推荐模型，为用户准确的推荐上车位置，引导乘客选择合适的上车点，提高司机接驾效率和乘客的出行体验。以下通过对附图的描述阐述本申请披露的技术方案。

图1是根据本申请一些实施例所示的确定推荐上车点的系统的应用场景示意图。

确定推荐上车点的系统100可以向乘客推荐上车点，引导乘客选择合适的上车点。确定推荐上车点的系统100可以是用于互联网或者其它网络的服务平台。例如，确定推荐上车点的系统100可以是为交通运输提供服务的线上服务平台。在一些实施例中，确定推荐上车点的系统100可以应用于网约车服务，例如出租车呼叫、快车呼叫、专车呼叫、小巴呼叫、拼车、公交服务、司机雇佣和接送服务等。在一些实施例中，确定推荐上车点的系统100还可以应用于代驾、快递、外卖等。在另一些实施例中，确定推荐上车点的系统100还可以应用于出行(如旅游)服务领域。确定推荐上车点的系统100可以包括服务器110、用户终端120、存储设备130、网络140和信息源150。

在一些实施例中，服务器110可以用于处理与服务请求有关的信息和/或数据，例如，用于处理在线打车的服务请求。具体的，服务器可以从用户终端120接收服务请求，并处理该服务请求以向用户终端120推荐上车点。在一些实施例中，服务器110可以是单个的服务器或者服务器群组。所述服务器群可以是集中式的或分布式的(例如，服务器110可以是分布式的系统)。在一些实施例中，服务器110可以是本地的或远程的。例如，服务器110可以通过网络140访问存储在存储设备130、用户终端120中的信息和/或数据。再例如，服务器110可以直接连接到存储设备130、用户终端120以访问存储的信息和/或数据。在一些实施例中，服务器110可以在一个云平台上实现。仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、云之间、多重云等或上述举例的任意组合。

在一些实施例中，服务器110可以包括处理引擎112。处理引擎112可处理与推荐上车点有关的数据和/或信息以执行一个或多个本申请中描述的功能。例如，处理引擎112可以接收用户终端120发送的用车请求信号，向用户发送推荐上车点。在一些实施例中，处理引擎112可以获取用户的当前位置。在一些实施例中，处理引擎112可以基于用户的当前位置，生成至少一个候选上车点信息。在一些实施例中，处理引擎112可以向用户显示至少一个候选上车点信息。在一些实施例中，处理引擎112可以接收用户选择所述至少一个候选上车点信息中的其中一个候选上车点信息。在一些实施例中，处理引擎112可以基于从候选上车点中确定推荐上车点并向用户推荐，以供用户选择，用户选择的推荐上车点可以有特殊显示标记(例如，大头针)。在一些实施例中，处理引擎112可以包括一个或以上处理引擎(例如，单芯片处理引擎或多芯片处理器)。仅作为示例，处理引擎112可以包括中央处理单元(CPU)、专用集成电路(ASIC)、专用指令集处理器(ASIP)、图像处理单元(GPU)、物理运算处理单元(PPU)、数字信号处理器(DSP)、现场可程序门阵列(FPGA)、可程序逻辑装置(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等或以上任意组合。

在一些实施例中，用户终端120可以是与请求直接相关的个人、工具或其他实体。用户可以是服务请求者。在本申请中，“用户”、“用户终端”可以互换使用。在一些实施例中，用户终端120可以包括移动设备120-1、平板电脑120-2、笔记本电脑120-3、以及机动车辆中的车载设备120-4等或其任意组合。在一些实施例中，移动设备120-1可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、对讲机等或其任意组合。在一些实施例中，可穿戴设备可以包括智能手镯、智能鞋袜、智能眼镜、智能头盔、智能手表、智能穿着、智能背包、智能配件等或其任意组合。在一些实施例中，智能移动设备可以包括智能电话、个人数字助理(PDA)、游戏设备、导航设备、销售点(POS)等或其任意组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强型虚拟现实头盔、增强现实眼镜、增强现实眼罩等或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括GoogleGlass、OculusRift、HoloLens或GearVR等。在一些实施例中，机动车辆中的车载设备120-4可以包括车载计算机、车载电视等。在一些实施例中，用户终端120可以是具有定位技术的设备，用于定位服务请求者和/或用户终端120的位置。

存储设备130可以存储与服务请求相关的数据和/或指令。在一些实施例中，存储设备130可以存储从用户终端120获得/获取的数据。在一些实施例中，存储设备130可以存储服务器110用于执行或使用来完成本申请中描述的示例性方法的数据和/或指令。在一些实施例中，存储设备130可以包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(ROM)等或其任意组合。示例性的大容量储存器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性的挥发性只读存储器可以包括随机存取内存(RAM)。示例性的RAM可包括动态RAM(DRAM)、双倍速率同步动态RAM(DDRSDRAM)、静态RAM(SRAM)、闸流体RAM(T-RAM)和零电容RAM(Z-RAM)等。示例性的ROM可以包括掩模ROM(MROM)、可编程ROM(PROM)、可擦除可编程ROM(PEROM)、电子可擦除可编程ROM(EEPROM)、光盘ROM(CD-ROM)和数字通用磁盘ROM等。在一些实施例中，所述存储设备130可以在云平台上实现。仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。

在一些实施例中，存储设备130可以连接到网络140以与确定推荐上车点的系统100中的一个或以上组件(例如，服务器110、用户终端120)通信。确定推荐上车点的系统100中的一个或以上组件可以通过网络140访问存储设备130中存储的数据或指令。在一些实施例中，存储设备130可以与确定推荐上车点的系统100中的一个或以上组件(例如，用户终端120)直接连接或通信。在一些实施例中，存储设备130可以是服务器110的一部分。

网络140可以促进信息和/或数据的交换。在一些实施例中，确定推荐上车点的系统100中的一个或以上组件(例如，服务器110、用户终端120)可以通过网络140向/从确定推荐上车点的系统100中的其他组件发送和/或接收信息和/或数据。例如，服务器110可以通过网络140从用户终端120获得/获取服务请求。在一些实施例中，网络140可以为任意形式的有线或无线网络或其任意组合。仅作为示例，网络140可以包括缆线网络、有线网络、光纤网络、远程通信网络、内部网络、互联网、局域网(LAN)、广域网(WAN)、无线局域网(WLAN)、城域网(MAN)、广域网(WAN)、公共交换电话网络(PSTN)、蓝牙网络、紫蜂网络、近场通讯(NFC)网络、全球移动通讯系统(GSM)网络、码分多址(CDMA)网络、时分多址(TDMA)网络、通用分组无线服务(GPRS)网络、增强数据速率GSM演进(EDGE)网络、宽带码分多址接入(WCDMA)网络、高速下行分组接入(HSDPA)网络、长期演进(LTE)网络、用户数据报协议(UDP)网络、传输控制协议/互联网协议(TCP/IP)网络、短讯息服务(SMS)网络、无线应用协议(WAP)网络、超宽带(UWB)网络、红外线等或其任意组合。在一些实施例中，确定推荐上车点的系统100可以包括一个或以上网络接入点。例如，确定推荐上车点的系统100可以包括有线或无线网络接入点，例如基站和/或无线接入点140-1、140-2、…，确定推荐上车点的系统100的一个或以上组件可以通过其连接到网络140以交换数据和/或信息。

信息源150是用于为确定推荐上车点的系统100提供其他信息的来源。信息源150可以用于为确定推荐上车点的系统100提供与服务相关的信息，例如，天气情况、交通信息、法律法规信息、新闻事件、生活资讯、生活指南信息等。信息源150可以在单个中央服务器、通过通信链路连接的多个服务器或多个个人设备中实现。当信息源150在多个个人设备中实现时，个人设备可以生成内容(例如，被称为“用户生成内容”)，例如，通过将文本、语音、图像和视频上载到云服务器。信息源可以由多个个人设备和云服务器生成。

图2是根据本申请一些实施例所示的确定推荐上车点的方法的示例性流程图。在一些实施例中，流程200中的一个或以上步骤可以作为指令的形式存储在存储设备(例如，存储设备130)中，并且被处理设备(例如，服务器110中的处理引擎112、确定推荐上车点的系统400)调用和/或执行。如图2所示，流程200可以包括：

步骤202，从用户终端接收服务请求。步骤202可以由服务器110(例如获取模块410)执行。

在一些实施例中，所述服务请求可以与运输服务请求相关，例如，在线打车服务请求、出租车服务请求，专车服务请求等或其任意组合。所述用户终端可以包括用户(例如，乘客、服务请求者)用于发起服务请求的终端(例如，智能手机、平板电脑等)。例如，可以通过启动用户终端的应用程序来实现发起服务请求。

在一些实施例中，服务请求可以包括用户终端的用户标识、请求时间、服务请求起始位置、服务请求终止位置、用户终端发起服务请求时目标终端的位置、请求服务人数(例如，网约车服务中需要几人乘车)、请求服务类型(例如，出租车、拼车、快车、专车等)、是否接受动态价格调整(例如，调整服务价格等)等或其任意组合。其中，服务请求起始位置可以是兴趣点区域，具有一定的面状大小，当其面状大小较大时，较难确定乘车人的真实位置，由此较难确定合理的上车点。

在一些实施例中，服务器110(例如获取模块410)可以通过连接到网络(例如，网络140)从所述用户终端处接收服务请求。

步骤204，基于所述服务请求确定请求上车区域。步骤204可以由服务器110(例如，请求上车区域确定模块420)执行。

如上所述，服务请求中的服务请求起始位置可以是具有一定面状大小的兴趣点区域(也可称作面状POI)，该兴趣点区域即为请求上车区域。请求上车区域可以不同于用户终端发起服务请求时的位置。例如，用户在区域A为在区域B的朋友发起服务请求时，请求上车区域可以是其朋友所在的区域B。又例如，用户现在位于区域A，但希望稍后前往区域C上车，则请求上车区域为区域C。请求上车区域也可以是用户终端发起服务请求时的位置。例如，用户在区域A并希望就近上车，则请求上车区域可以是用户自己所在的区域A。请求上车区域可以由用户在用户终端120上输入，输入方式包括但不限于打字输入、手写输入、选择输入、语音输入、扫描输入等一种或多种的任意组合。可以理解，在以上用户为朋友叫车的情况下，显然无法通过用户(叫车人)的用户终端120获取实际乘车人的位置。在用户为自己叫车的情况下，也有可能因为其用户终端未开启定位功能、用户处于无定位信号的环境中等原因导致无法通过用户终端120定位用户位置。在此类情况下，均需要用户自行输入请求上车区域请求上车区域确定模块420可以从服务请求中提取请求上车区域。

步骤206，判断所述请求上车区域的面状大小是否大于预设阈值。步骤206可以由服务器110(例如判断模块430)执行。

在一些实施例中，所述面状大小可以是指所述请求上车区域的形状的大小，例如，请求上车区域的边界所围绕的区域的面积大小。面状大小可以通过获取模块410与信息源(例如，信息源150)通信获取。信息源可以提供与服务请求的内容相关的信息，例如，天气情况、交通信息、生活指南、城市建筑面积大小、区域面状大小等。在一些实施例中，预设阈值可以是指请求上车区域的面积的最小值，例如，5000平方米、10000平方米、20000平方米等。预设阈值可以是按照需求进行设定，例如，不同的国家、城市、服务区可以设置不同的阈值。又例如，可以根据请求上车区域的类型确定预设阈值，请求上车区域的类型包括但不限于商场、学校、医院、住宅区、办公区、工厂等。比如，对于大型商场，大型商场的出口多，并且出入限制(例如，不需要出入权限)少，可以更加便利地到达各个位置，可以将预设阈值的大小设置为相对较大的值(例如，20000平方米、30000平方米等)；对于学校、小区、医院，交通相对复杂，人员较多，可能具有出入限制(如，门禁)，则可以将预设阈值的大小设置为相对较小的值(例如，4000平方米、5000平方米等)。判断模块430可以将获取得到请求上车区域的面状大小与预设阈值进行比较，以确定请求上车区域的面状大小是否大于预设阈值。

步骤208，若是，则利用预设的上车点推荐模型，基于所述请求上车区域的特征数据，确定多个推荐上车点。步骤208可以由服务器110(如上车点确定模块440)执行。

在一些实施例中，上车点推荐模型可以为机器学习模型。上车点推荐模型可以包括LambdaRank模型、RankNet模型、LambdaMART模型等。上车点推荐模型可以通过历史订单数据预先训练得到。有关上车点推荐模型训练的更多内容可以参见图3及其描述。所述请求上车区域的特征数据可以包括候选上车点与所述请求上车区域的距离特征、候选上车点的属性特征和/或请求上车区域的属性特征。候选上车点与请求上车区域的距离特征可以为候选上车点到请求上车区域的中心的距离。候选上车点的属性特征可以包括候选上车点的全局热度、局部热度等。请求上车区域的属性特征可以包括请求上车区域范围内的候选上车点数量、请求上车区域与历史订单数据中乘客上车点的关联次数(例如，乘客真实上车点在该请求上车区域范围的次数)、请求上车区域的热度、请求上车区域的面状大小等。

在一些实施例中，可以将服务请求中包含的请求上车区域输入上车点推荐模型中，上车点推荐模型根据输入的请求上车区域的特征数据，确定出多个(例如，5-10个)推荐上车点。

在一些实施例中，若在步骤206中判断出请求上车区域的面状大小不大于设定阈值，则可以进行步骤212，采用现有的一些推荐上车点确定方法确定推荐上车点，在此不再赘述。针对本申请，可以理解，对于面积较大的请求上车区域来说，由于其覆盖范围较广，召回的候选上车点可能与乘车人相距较远因而乘车人不方便到达，因此，在一些实施例中，相比于点状请求上车区域或者面积小于设定阈值的面状请求上车区域，针对面状大小大于设定阈值的请求上车区域可以确定更多个推荐上车地点显示给用户，以提供给用户更多选择方便其选到乘车人容易到达的合适上车点，例如，对于点状请求上车区域或者面积小于设定阈值的面状请求上车区域，所确定的推荐上车点的数量为3个，而针对面状大小大于设定阈值的请求上车区域，所确定的推荐上车点的数量可以为5个、6个或10个，从而更好的引导乘客选择合适的上车点，提高司机接驾效率和乘客的出行体验。

作为示例，上车点推荐模型可以采用以下方式确定多个推荐上车点。

在一些实施例中，可以获取所述请求上车区域的特征数据，所述请求上车区域的特征数据包括候选上车点与所述请求上车区域的距离特征、所述候选上车点的属性特征和/或所述请求上车区域的属性特征。候选上车点可以包括所述请求上车区域范围内所有的车辆可停靠地点。候选上车点可以通过获取模块410从信息源处获取，也可以从对应该请求上车区域范围的历史订单数据中获取。

可以将请求上车区域的特征数据输入上车点推荐模型，确定请求上车区域的候选上车点的推荐度。推荐度可以是指将候选上车点确定为推荐上车点的得分。推荐度的高低可以与请求上车区域的特征数据呈正相关性或负相关性，例如，候选上车点与请求上车区域中心点的距离越近，推荐度越高；候选上车点的全局热度(例如，确定为真实上车点的次数)越高，推荐度越高；请求上车区域与乘客上车点的关联次数越多，推荐度越高。

可以基于候选上车点的推荐度，对候选上车点排序后确定多个推荐上车点。候选上车点的推荐度越高，排序越靠前。在确定多个推荐上车点时，可以基于请求上车区域的面状大小确定推荐上车点的数量，例如，面状大小越大，推荐上车点数量可以越多。在一些实施例中，推荐上车点的数量可以大于5个。

步骤210，向所述用户终端发送所述多个推荐上车点。步骤210可以由服务器110(例如发送模块450)执行。

在一些实施例中，发送模块450可以通过网络(例如，网络140)向用户终端发送所述多个推荐上车点。在一些实施例中，发送模块450还可以通过网络将所述多个推荐上车点发送给接受服务请求的司机，以在用户确认上车点以后，司机驾车前往确定的上车点接送乘客。在一些实施例中，发送给用户终端的多个推荐上车点可以按照各个推荐上车点的推荐度进行排序，例如，按照推荐度从高到低的顺序排序后发送给用户终端，也可以按照随机顺序将多个推荐上车点发送给用户终端。

在一些实施例中，在向用户终端发送多个推荐上车点之后，还可以通过获取模块410接收用户终端发送的确定上车点信息。确定上车点信息可以包括确定上车点、确定上车点的位置信息以及用户终端的当前位置信息等。确定上车点可以是用户从多个推荐上车点中选择的待上车地点。在一些实施例中，确定上车点也可以是用户选择的多个推荐上车点之外的上车点，例如，请求上车区域的候选上车点中某一个上车点。在接收到用户终端发送的确定上车点信息之后，可以对确定上车点进行标记，例如，将电子地图中的大头针吸附到确定上车点上、使用红点标记确定上车点等，用户与司机都可以看到确定上车点的标记，进而乘客和司机都可以赶往确定上车点会和以开始服务。用户在接收多个推荐上车点之后，自主对上车地点进行选择后再对地图上的上车点进行标记，可以使得用户选择上车点的流程更加便利，提高用户的打车体验。

应当注意的是，上述有关流程200的描述仅仅是为了示例和说明，而不限定本申请的适用范围。对于本领域技术人员来说，在本申请的指导下可以对流程200进行各种修正和改变。然而，这些修正和改变仍在本申请的范围之内。例如，可以在示例行过程200中的其他地方添加一个或以上其他可选步骤(例如，存储步骤、预处理步骤)。

图3是根据本申请一些实施例所示的训练上车点推荐模型的示例性流程图。在一些实施例中，流程300中的一个或以上步骤可以作为指令的形式存储在存储设备(例如，存储设备130)中，并且被处理设备(例如，服务器110中的处理引擎112、确定推荐上车点的系统400)调用和/或执行。如图3所示，流程300可以包括：

步骤302，获取面状大小大于预设阈值的上车区域的历史订单数据。

在一些实施例中，在进行模型训练之前，可以根据调研或历史订单数据确定面状大小的预设阈值。例如，可以获取较大面状区域的历史订单数据，根据历史订单数据中乘客的真实上车点位置、服务请求的发起地点、订单完成后的乘客评价等信息综合确定预设阈值的大小。在一些实施例中，可以通过获取模块410从存储器(例如，存储设备130)或数据库中获取。

步骤304，基于多个已确定历史真实上车点的所述历史订单数据构建训练样本集。

在一些实施例中，为了训练得到上车点推荐模型，可以利用多个已确定历史真实上车点的历史订单数据构建训练样本集。训练样本集可以用于对上车点推荐模型进行训练。历史真实上车点可以是司机与乘客汇合的上车地点。在一些实施例中，还可以基于多个已确定历史真实上车点的历史订单数据构建测试样本集。测试样本集可以用于对训练后的上车点推荐模型进行性能测试。训练样本集与测试样本集中的历史订单数据可以不同，以获得优良性能的上车点推荐模型。

步骤306，以所述训练样本集中的各所述历史订单数据的特征作为输入，以反映相应历史订单数据中历史真实上车点与历史推荐上车点间距离的标签为正确标准，训练得到所述上车点推荐模型。

在一些实施例中，历史订单数据的特征可以包括历史订单的推荐上车点(也称“历史推荐上车点”)与历史订单的请求上车区域(也称历史请求上车区域)的距离特征、历史推荐上车点的属性特征和/或历史请求上车区域的属性特征。历史推荐上车点可以是指历史订单数据中向用户推荐的上车点。历史推荐上车点与历史请求上车区域的距离特征可以是历史推荐上车点与历史请求上车区域的中心的距离。历史推荐上车点的属性特征可以包括该历史推荐上车点的搜索热度、辨识度等或其组合。例如，搜索热度可以包括用户搜索和/或选择该历史推荐上车点的次数、概率等；辨识度可以包括所述历史推荐上车是否为商圈、是否具有容易辨识的标志(例如，建筑、雕塑、指示牌等)。历史请求上车区域的属性特征可以包括该区域内可召回的候选上车点数量、历史请求上车区域的热度、历史请求上车区域的面状大小等。历史订单数据的特征与请求上车区域的特征数据在本申请中可以包括相同类型的特征，关于历史订单数据的特征的更多描述，可以参考本申请的其他部分，例如，图2的相关说明。

在一些实施例中，可以将历史订单数据的特征输入待训练的上车点推荐模型，以反映历史订单数据中历史推荐上车点与历史真实上车点之间的距离的标签为正确标准，训练得上车点推荐模型。所述标签可以通过比较推荐上车点与历史真实上车点的距离来确定。在一些实施例中，所述历史推荐上车点可以直接从历史订单数据中得到。

在一些实施例中，反映相应历史订单数据中历史真实上车点与历史推荐上车点间距离的标签通过以下方式得到：可以基于历史订单数据，获取对应于所述历史订单数据的历史真实上车点和历史推荐上车点。可以在确定所述历史推荐上车点与所述历史真实上车点之间的距离后，根据所述距离是否满足预设要求确定所述标签。该距离可以是指历史真实上车点与历史推荐上车点之间的球面距离(例如，以地球表面为球面，历史真实上车点与历史推荐上车点之间的距离)、直线距离、最短路线距离等或其组合。

在一些实施例中，所述预设要求可以是小于预设长度，当所述距离小于该预设长度时，确定所述标签为1；当所述距离小于该预设长度时，确定所述标签为0。例如，所述预设长度可以为30m，当所述距离小于30m时，为所述历史推荐上车点添加为1的标签，当所述距离大于30m时，为所述历史推荐上车点添加为0的标签。在一些实施例中，所述预设要求可以是通勤时间小于预设时间，当所述距离的之间的通勤时间小于预设时间时，确定所述标签为1；当所述距离之间的通勤时间大于预设时间时，确定所述标签为0。例如，预设时间可以为5分钟，当通勤时间小于5分钟时，确定标签为1，当通勤时间大于5分钟时，确定标签为0。在添加标签后，可以以历史订单数据的特征为输入，以所述标签为正确标准，对模型进行训练，得到上车点推荐模型。

应当注意的是，上述有关流程300的描述仅仅是为了示例和说明，而不限定本申请的适用范围。对于本领域技术人员来说，在本申请的指导下可以对流程300进行各种修正和改变。然而，这些修正和改变仍在本申请的范围之内。例如，可以在示例行过程200中的其他地方添加一个或以上其他可选步骤(例如，存储步骤、预处理步骤)。

图4是根据本申请一些实施例所示的确定推荐上车点的系统的模块图。如图4所示，所述系统可以包括获取模块410、请求上车区域确定模块420、判断模块430、上车点确定模块440以及发送模块450。

获取模块410可以从用户终端接收服务请求。

在一些实施例中，获取模块410可以通过连接到网络(例如，网络140)从所述用户终端处接收服务请求。在一些实施例中，服务请求可以包括用户终端的用户标识、请求时间、服务请求起始位置、服务请求终止位置、用户终端发起服务请求时目标终端的位置、请求服务人数(例如，网约车服务中需要几人乘车)、请求服务类型(例如，出租车、拼车、快车、专车等)、是否接受动态价格调整(例如，调整服务价格等)等或其任意组合。

请求上车区域确定模块420可以基于所述服务请求确定请求上车区域。

在一些实施例中，请求上车区域确定模块420可以基于服务请求中包含的信息确定请求上车区域。请求上车区域可以是用户通过用户终端输入的兴趣点(POI，Point ofInterest)，即上车点的位置区域。请求上车区域可以包括服务请求的起始位置、用户终端发起服务请求的位置。例如，用户在区域A为在区域B的朋友发起服务请求时，请求上车区域可以是其朋友所在的区域B。服务者在区域A为自己发起服务请求时，请求上车区域可以是用户自己所在的区域A。

判断模块430可以判断所述请求上车区域的面状大小是否大于预设阈值。

在一些实施例中，判断模块430可以将获取得到请求上车区域的面状大小与预设阈值进行比较，以确定请求上车区域的面状大小是否大于预设阈值。预设阈值可以是按照需求进行设定，例如，5000平方米、10000平方米、20000平方米等。

上车点确定模块440可以确定推荐上车点。

在一些实施例中，上车点确定模块440可以利用预设的上车点推荐模块，基于请求上车区域的特征数据，确定多个推荐上车点。上车点确定模块440可以获取请求上车区域的特征数据，请求上车区域的特征数据包括候选上车点与请求上车区域的距离特征、候选上车点的属性特征和/或请求上车区域的属性特征。可以将请求上车区域的特征数据输入上车点推荐模型，确定请求上车区域的候选上车点的推荐度。可以基于候选上车点的推荐度，对候选上车点排序后确定多个推荐上车点。

发送模块450可以向所述用户终端发送所述多个推荐上车点。

在一些实施例中，发送模块450可以通过网络(例如，网络160)向用户终端发送所述多个推荐上车点。在一些实施例中，发送模块450还可以通过网络将所述多个推荐上车点发送给接受服务请求的司机，以在用户确认上车点以后，司机驾车前往确定的上车点接送乘客。在一些实施例中，发送给用户终端的多个推荐上车点可以按照各个推荐上车点的推荐度进行排序，例如，按照推荐度从高到低的顺序排序后发送给用户终端，也可以按照随机顺序将多个推荐上车点发送给用户终端。

关于确定推荐上车点的系统的各模块的具体描述，可以参考本申请流程图部分，例如，图2至图3的相关说明。

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

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

本申请实施例可能带来的有益效果包括但不限于：(1)通过判断请求上车区域的面状大小，基于预设的上车点推荐模型，准确的确定推荐上车点，提升了推荐上车点的准确度，并且可以适用于更多类型的打车服务。(2)对于较大面状的请求上车区域，发送数量更多的推荐上车点，用户可选择上车点更多，增加用户选择到适合的上车点的概率。(3)用户在接收多个推荐上车点之后，自主对上车地点进行选择后再对地图上的上车点进行标记，可以使得用户选择上车点的流程更加便利，提高用户的打车体验。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。

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

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

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

计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、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％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

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

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

Claims (12)

1.一种确定推荐上车点的方法，其特征在于，包括：

从用户终端接收服务请求；

基于所述服务请求确定请求上车区域；

判断所述请求上车区域的面状大小是否大于预设阈值；

若是，则利用预设的上车点推荐模型，基于所述请求上车区域的特征数据，确定多个推荐上车点；

向所述用户终端发送所述多个推荐上车点。

2.根据权利要求1所述的方法，其特征在于，所述利用预设的上车点推荐模型，基于所述请求上车区域的特征数据，确定多个推荐上车点，包括：

获取所述请求上车区域的特征数据，所述请求上车区域的特征数据包括候选上车点与所述请求上车区域的距离特征、所述候选上车点的属性特征和/或所述请求上车区域的属性特征；

将所述请求上车区域的特征数据输入所述上车点推荐模型，确定所述请求上车区域的候选上车点的推荐度；

基于所述候选上车点的推荐度，对所述候选上车点排序后确定所述多个推荐上车点。

3.根据权利要求1所述的方法，其特征在于，所述向所述用户终端发送所述多个推荐上车点之后，所述方法还包括：

从所述用户终端接收确定上车点信息，所述确定上车点信息包括确定上车点的位置信息，所述确定上车点选自所述多个推荐上车点；

对所述确定上车点进行标记。

4.根据权利要求1所述的方法，其特征在于，所述上车点推荐模型通过以下方式得到：

获取面状大小大于预设阈值的上车区域的历史订单数据；

基于多个已确定真实上车点的所述历史订单数据构建训练样本集；

以所述训练样本集中的各所述历史订单数据的特征作为输入，以反映相应历史订单数据中历史真实上车点与历史推荐上车点间距离的标签为正确标准，训练得到所述上车点推荐模型。

5.根据权利要求4所述的方法，其特征在于，所述反映相应历史订单数据中历史真实上车点与历史推荐上车点间距离的标签通过以下方式得到：

基于所述历史订单数据，获取对应于所述历史订单数据的历史真实上车点和历史推荐上车点；

确定所述历史推荐上车点与所述历史真实上车点之间的距离；

根据所述距离是否满足预设要求确定所述标签。

6.一种确定推荐上车点的系统，其特征在于，包括：

获取模块，用于从用户终端接收服务请求；

请求上车区域确定模块，用于基于所述服务请求确定请求上车区域；

判断模块，用于判断所述请求上车区域的面状大小是否大于预设阈值；

上车点确定模块，用于响应于所述请求上车区域的面状大小大于所述预设阈值，利用预设的上车点推荐模型，基于所述请求上车区域的特征数据，确定多个推荐上车点；

发送模块，用于向所述用户终端发送所述多个推荐上车点。

7.根据权利要求6所述的系统，其特征在于，为利用预设的上车点推荐模型，基于所述请求上车区域的特征数据，确定多个推荐上车点，

所述获取模块进一步用于：获取所述请求上车区域的特征数据，所述请求上车区域的特征数据包括候选上车点与所述请求上车区域的距离特征、所述候选上车点的属性特征和/或所述请求上车区域的属性特征；

所述上车点确定模块进一步用于：

将所述请求上车区域的特征数据输入所述上车点推荐模型，确定所述请求上车区域的候选上车点的推荐度；

基于所述候选上车点的推荐度，对所述候选上车点排序后确定所述多个推荐上车点。

8.根据权利要求6所述的系统，其特征在于，所述向所述用户终端发送所述多个推荐上车点之后，所述上车点确定模块进一步用于：

从所述用户终端接收确定上车点信息，所述确定上车点信息包括确定上车点的位置信息，所述确定上车点选自所述多个推荐上车点；

对所述确定上车点进行标记。

9.根据权利要求6所述的系统，其特征在于，所述上车点推荐模型通过以下方式得到：

获取面状大小大于预设阈值的上车区域的历史订单数据；

基于多个已确定真实上车点的所述历史订单数据构建训练样本集；

以所述训练样本集中的各所述历史订单数据的特征作为输入，以反映相应历史订单数据中历史真实上车点与历史推荐上车点间距离的标签为正确标准，训练得到所述上车点推荐模型。

10.根据权利要求9所述的系统，其特征在于，所述反映相应历史订单数据中历史真实上车点与历史推荐上车点间距离的标签通过以下方式得到：

基于所述历史订单数据，获取对应于所述历史订单数据的历史真实上车点和历史推荐上车点；

确定所述历史推荐上车点与所述历史真实上车点之间的距离；

根据所述距离是否满足预设要求确定所述标签。

11.一种确定推荐上车点的装置，包括至少一个存储介质和至少一个处理器，所述至少一个存储介质用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令以实现如权利要求1～5任一项所述的方法。

12.一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行如权利要求1～5任一项所述的方法。

Images