CN110942220B - 运力调度方法、装置和服务器 - Google Patents

运力调度方法、装置和服务器 Download PDF

Info

Publication number
CN110942220B
CN110942220B CN201811119726.1A CN201811119726A CN110942220B CN 110942220 B CN110942220 B CN 110942220B CN 201811119726 A CN201811119726 A CN 201811119726A CN 110942220 B CN110942220 B CN 110942220B
Authority
CN
China
Prior art keywords
driver
silent
area
data containing
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201811119726.1A
Other languages
English (en)
Other versions
CN110942220A (zh
Inventor
常智华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Didi Infinity Technology and Development Co Ltd
Original Assignee
Beijing Didi Infinity Technology and Development Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Didi Infinity Technology and Development Co Ltd filed Critical Beijing Didi Infinity Technology and Development Co Ltd
Priority to CN201811119726.1A priority Critical patent/CN110942220B/zh
Publication of CN110942220A publication Critical patent/CN110942220A/zh
Application granted granted Critical
Publication of CN110942220B publication Critical patent/CN110942220B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06315—Needs-based resource requirements planning or analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Traffic Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请提供了一种运力调度方法、装置和服务器，涉及互联网技术领域。其中，该方法包括：如果预测指定时段内有运力不足的区域，根据所述区域对应的历史司机数据确定包含沉默司机信息的数据；其中，所述沉默司机包括活跃值在设定活跃值区间内的不在线司机；从所述包含沉默司机信息的数据中筛选包含目标司机信息的数据；向所述目标司机下发在所述指定时段内到达所述区域的调度通知。本申请能够从沉默司机中筛选可调度的目标司机，并调度目标司机前往运力不足区域，较好地缓解乘客用车需求旺盛但司机供给不足的问题，有效提升了用户体验。

Description

运力调度方法、装置和服务器
技术领域
本申请涉及互联网技术领域，尤其涉及一种运力调度方法、装置和服务器。
背景技术
随着打车平台的应用普及，越来越多的用户选择在出行时通过打车平台叫车，司机可以通过打车平台接单，从而为有用车需求的用户提供服务。
在实际打车过程中，由于用户需求的差异性，可能有些区域在某一段时间用车需求较大，在另一段时间用车需求较小，而司机凭借经验选择自己的候车地点，可能该区域在高峰时段内出现司机供不应求(也即，运力不足)的现象，导致用户叫车困难，叫车用时较长，用户体验度不佳。
发明内容
有鉴于此，本申请实施例提供一种运力调度方法、装置和服务器，用以改善现有技术中存在的因司机供不应求而导致乘客叫车困难，体验度不佳的问题。
为了实现上述目的，本发明实施例采用的技术方案如下：
第一方面，本申请实施例提供了一种运力调度方法，所述方法应用于平台服务器，所述方法包括：如果预测指定时段内有运力不足的区域，根据所述区域对应的历史司机数据确定包含沉默司机信息的数据；其中，所述沉默司机包括活跃值在设定活跃值区间内的不在线司机；从所述包含沉默司机信息的数据中筛选包含目标司机信息的数据；向所述目标司机下发在所述指定时段内到达所述区域的调度通知。
结合第一方面，本申请实施例提供了第一方面的第一种可能的实施方式，其中，所述方法还包括：根据历史订单数据预测指定时段内是否存在运力不足的区域。
结合第一方面的第一种可能的实施方式，本申请实施例提供了第一方面的第二种可能的实施方式，其中，所述根据历史订单数据预测指定时段内是否存在运力不足的区域的步骤，包括：查找指定时段对应的热点区域；调取所述热点区域对应所述指定时段的至少一组历史订单数据；
统计调取的各组所述历史订单数据中的未应答订单平均值；如果所述平均值超过设定的第一阈值，将所述热点区域确定为所述指定时段对应的运力不足的区域。
结合第一方面的第二种可能的实施方式，本申请实施例提供了第一方面的第三种可能的实施方式，其中，所述调取所述热点区域对应所述指定时段的至少一组历史订单数据的步骤，包括：以当前时间为基准，调取所述热点区域对应的N个所述指定时段的历史订单数据，得到N组历史订单数据；其中，N为预先设定的自然数。
结合第一方面，本申请实施例提供了第一方面的第四种可能的实施方式，其中，所述根据所述区域对应的历史司机数据确定包含沉默司机信息的数据的步骤，包括：根据历史司机数据查找包含所述区域的候选司机信息的数据；所述历史司机数据包括以下信息中的一种或多种：历史活跃区域、注册的家庭地址、收车地点、出车地点；根据包含所述候选司机信息的数据在所述指定时段内的在线记录，确定包含沉默司机信息的数据。
结合第一方面的第四种可能的实施方式，本申请实施例提供了第一方面的第五种可能的实施方式，其中，所述根据历史司机数据查找包含所述区域的候选司机信息的数据的步骤，包括：按照经纬度坐标对所述区域进行GeoHash编码；根据所述区域对应的GeoHash编码获取所述区域对应的倒排索引值；将倒排索引表中所述倒排索引值对应的包含司机信息的数据，确定为所述区域对应的包含候选司机信息的数据；其中，所述倒排索引表为预先根据历史司机数据建立的倒排索引值与司机信息的对应关系表。
结合第一方面的第四种可能的实施方式，本申请实施例提供了第一方面的第六种可能的实施方式，其中，所述根据包含所述候选司机信息的数据在所述指定时段内的在线记录确定包含沉默司机信息的数据的步骤，包括：查找包含所述候选司机信息的数据在所述指定时段内的在线记录，所述在线记录包括：收车记录和/或出车记录；过滤包含所述候选司机信息的数据中的包含在线司机信息的数据和活跃值低于所述设定活跃值区间下限值的包含不在线司机信息的数据，得到包含沉默司机信息的数据。
结合第一方面，本申请实施例提供了第一方面的第七种可能的实施方式，其中，所述从包含沉默司机信息的数据中筛选包含目标司机信息的数据的步骤，包括：根据所述区域的运力不足程度，从包含沉默司机信息的数据中筛选包含目标司机信息的数据；或者，根据所述沉默司机的唤醒概率，从包含沉默司机信息的数据中筛选包含目标司机信息的数据。
结合第一方面的第七种可能的实施方式，本申请实施例提供了第一方面的第八种可能的实施方式，其中，所述根据所述区域的运力不足程度，从包含沉默司机信息的数据中筛选包含目标司机信息的数据的步骤，包括：根据所述区域在所述指定时段内未应答订单平均值，确定所述区域的运力缺口数；统计所述沉默司机的数量；根据所述沉默司机的数量和所述运力缺口数，确定目标司机的数量；从包含所述沉默司机信息的数据中，选取包含所述数量的司机信息的数据作为包含目标司机信息的数据。
结合第一方面的第七种可能的实施方式，本申请实施例提供了第一方面的第九种可能的实施方式，其中，所述根据所述沉默司机的唤醒概率，从包含沉默司机信息的数据中筛选包含目标司机信息的数据的步骤，包括：基于预先训练的机器学习模型计算所述沉默司机的唤醒概率；将唤醒概率大于设定的第二阈值的包含沉默司机信息的数据，确定为包含目标司机信息的数据。
结合第一方面的第九种可能的实施方式，本申请实施例提供了第一方面的第十种可能的实施方式，其中，所述机器学习模型的训练过程包括：根据沉默司机的历史唤醒数据库训练预设的Xgboost模型；获取训练后的所述Xgboost模型输出的特征数据，将所述特征数据输入至预设的LR模型进行训练；将训练后的LR模型作为所述机器学习模型。
结合第一方面，本申请实施例提供了第一方面的第十一种可能的实施方式，其中，所述向目标司机下发在所述指定时段内到达所述区域的调度通知的步骤，包括：获取所述目标司机的短信联系方式；使用所述短信联系方式向所述目标司机下发在所述指定时段内到达所述区域的调度通知，所述调度通知包括所述区域的标识和所述指定时段的标识。
结合第一方面，本申请实施例提供了第一方面的第十二种可能的实施方式，其中，所述向目标司机下发在所述指定时段内到达所述区域的调度通知的步骤，包括：获取所述区域的奖励机制和调度信息；其中，所述奖励机制包括：应答所述区域的订单的优惠券和/或订单提成比例；所述调度信息包括：所述区域的标识和所述指定时段的标识；向所述目标司机下发在所述指定时段内到达所述区域的调度通知，所述调度通知包括所述奖励机制和所述调度信息。
第二方面，本申请实施例还提供了一种运力调度装置，所述装置应用于平台服务器，所述装置包括：司机确定模块，用于如果预测指定时段内有运力不足的区域，根据所述区域对应的历史司机数据确定包含沉默司机信息的数据；其中，所述沉默司机包括活跃值在设定活跃值区间内的不在线司机；司机筛选模块，用于从所述包含沉默司机信息的数据中筛选包含目标司机信息的数据；司机调度模块，用于向所述目标司机下发在所述指定时段内到达所述区域的调度通知。
结合第二方面，本申请实施例提供了第二方面的第一种可能的实施方式，其中，所述装置还包括：区域预测模块，用于根据历史订单数据预测指定时段内是否存在运力不足的区域。
结合第二方面的第一种可能的实施方式，本申请实施例提供了第二方面的第二种可能的实施方式，其中，所述区域预测模块用于：查找指定时段对应的热点区域；调取所述热点区域对应所述指定时段的至少一组历史订单数据；统计调取的各组所述历史订单数据中的未应答订单平均值；如果所述平均值超过设定的第一阈值，将所述热点区域确定为所述指定时段对应的运力不足的区域。
结合第二方面的第二种可能的实施方式，本申请实施例提供了第二方面的第三种可能的实施方式，其中，所述区域预测模块用于：以当前时间为基准，调取所述热点区域对应的N个所述指定时段的历史订单数据，得到N组历史订单数据；其中，N为预先设定的自然数。
结合第二方面，本申请实施例提供了第二方面的第四种可能的实施方式，其中，所述司机确定模块用于：根据历史司机数据查找包含所述区域的候选司机信息的数据；所述历史司机数据包括以下信息中的一种或多种：历史活跃区域、注册的家庭地址、收车地点、出车地点；根据包含所述候选司机信息的数据在所述指定时段内的在线记录，确定包含沉默司机信息的数据。
结合第二方面的第四种可能的实施方式，本申请实施例提供了第二方面的第五种可能的实施方式，其中，所述司机确定模块用于：按照经纬度坐标对所述区域进行GeoHash编码；根据所述区域对应的GeoHash编码获取所述区域对应的倒排索引值；将倒排索引表中所述倒排索引值对应的包含司机信息的数据，确定为所述区域对应的包含候选司机信息的数据；其中，所述倒排索引表为预先根据历史司机数据建立的倒排索引值与司机信息的对应关系表。
结合第二方面的第四种可能的实施方式，本申请实施例提供了第二方面的第六种可能的实施方式，其中，所述司机确定模块用于：查找包含所述候选司机信息的数据在所述指定时段内的在线记录，所述在线记录包括：收车记录和/或出车记录；过滤包含所述候选司机信息的数据中的包含在线司机信息的数据和活跃值低于所述设定活跃值区间下限值的包含不在线司机信息的数据，得到包含沉默司机信息的数据。
结合第二方面，本申请实施例提供了第二方面的第七种可能的实施方式，其中，所述司机筛选模块用于：根据所述区域的运力不足程度，从包含沉默司机信息的数据中筛选包含目标司机信息的数据；或者，根据所述沉默司机的唤醒概率，从包含沉默司机信息的数据中筛选包含目标司机信息的数据。
结合第二方面的第七种可能的实施方式，本申请实施例提供了第二方面的第八种可能的实施方式，其中，所述司机筛选模块用于：根据所述区域在所述指定时段内未应答订单平均值，确定所述区域的运力缺口数；统计所述沉默司机的数量；根据所述沉默司机的数量和所述运力缺口数，确定目标司机的数量；从包含所述沉默司机信息的数据中，选取包含所述数量的司机信息的数据作为包含目标司机信息的数据。
结合第二方面的第七种可能的实施方式，本申请实施例提供了第二方面的第九种可能的实施方式，其中，所述司机筛选模块用于：基于预先训练的机器学习模型计算所述沉默司机的唤醒概率；将唤醒概率大于设定的第二阈值的包含沉默司机信息的数据，确定为包含目标司机信息的数据。
结合第二方面的第九种可能的实施方式，本申请实施例提供了第二方面的第十种可能的实施方式，其中，所述机器学习模型的训练过程包括：根据沉默司机的历史唤醒数据库训练预设的Xgboost模型；获取训练后的所述Xgboost模型输出的特征数据，将所述特征数据输入至预设的LR模型进行训练；将训练后的LR模型作为所述机器学习模型。
结合第二方面，本申请实施例提供了第二方面的第十一种可能的实施方式，其中，所述司机调度模块用于：获取所述目标司机的短信联系方式；使用所述短信联系方式向所述目标司机下发在所述指定时段内到达所述区域的调度通知，所述调度通知包括所述区域的标识和所述指定时段的标识。
结合第二方面，本申请实施例提供了第二方面的第十二种可能的实施方式，其中，所述司机调度模块用于：获取所述区域的奖励机制和调度信息；其中，所述奖励机制包括：应答所述区域的订单的优惠券和/或订单提成比例；所述调度信息包括：所述区域的标识和所述指定时段的标识；向所述目标司机下发在所述指定时段内到达所述区域的调度通知，所述调度通知包括所述奖励机制和所述调度信息。
第三方面，一种服务器，所述服务器包括存储器以及处理器，所述存储器用于存储支持处理器执行上述第一方面，或者第一方面的第一至十二任一种可能的实施方式中的方法的程序。
第四方面，本申请实施例还提供了一种计算机可读存储介质，用于存储为上述第二方面，或第二方面的第一至十二任一种可能的实施方式中的装置所用的计算机软件指令。
本申请实施例提供的上述运力调度方法、装置和服务器，能够根据运力不足区域对应的历史司机数据确定包含沉默司机信息的数据，并从包含沉默司机信息的数据中筛选包含目标司机信息的数据，进而向目标司机下发在指定时段内到达运力不足的区域的调度通知。这种从沉默司机中筛选可调度的目标司机，并调度目标司机前往运力不足区域的方式，能够较好地缓解乘客用车需求旺盛但司机供给不足的问题，有效提升了用户体验。
为使本申请实施例的上述目的、特征和优点能更明显易懂，下面将结合实施例，并配合所附附图，作详细说明。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例所提供的一种打车平台的应用场景示意图；
图2示出了本申请实施例所提供的一种运力调度方法流程图；
图3a示出了本申请实施例所提供的一种目标司机的筛选示意图；
图3b示出了本申请实施例所提供的另一种目标司机的筛选示意图；
图4示出了本申请实施例所提供的一种查找候选司机的具体方法流程图；
图5示出了本申请实施例所提供的一种区域编码示意图；
图6示出了本申请实施例所提供一种机器学习模型的训练方法流程图；
图7示出了本申请实施例所提供的另一种运力调度方法流程图；
图8示出了本申请实施例所提供的一种运力调度装置的结构框图；
图9示出了本申请实施例所提供的另一种运力调度装置的结构框图；
图10示出了本申请实施例所提供的一种服务器的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。以下对本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请实施例下述方法、装置、电子设备或计算机存储介质可以应用于任何打车平台需要进行运力调度(也即，对司机进行调度)的场景。本申请实施例并不对具体的应用场景作限制，任何使用本申请实施例提供的方法进行运力调度的方案均在本申请保护范围内。
首先，参见图1所示的一种打车平台的应用场景示意图，在图1中示意出平台服务器(具体为打车平台的服务器)，以及与该平台服务器分别通信连接的乘客终端和司机终端。乘客终端具体可以为乘客的手机等移动终端，司机终端具体可以为司机的手机、ipad等移动终端，也可以为司机车辆内安装的车载设备等。
其中，乘客终端和司机终端分别安装有打车平台的乘客客户端(或称为乘客端APP)和司机客户端(或称为司机端APP)。有叫车需求的乘客可以在乘客端APP输入诸如起始地和目的地等信息，由乘客端APP生成订单并发送给平台服务器，该平台服务器可以将乘客订单下发给符合接单条件(诸如距离乘客起始地较近)的司机端APP，由收到订单并确认接单的司机为乘客提供服务。
然而，在打车平台上还有一类司机，尽管是注册司机，这些司机可能较长时间未登录打车平台(也即，处于离线状态)或者司机虽登录打车平台但是接单频率较低，本申请实施方式中将当前不在线的较活跃司机(司机可能会由于其他情况当前并没上线)等具有接单潜力，但目前尚未处于接单状态的司机称为沉默司机。也即，本申请实施方式中所提及的沉默司机，包括活跃值在设定活跃值区间的不在线司机。不在线司机也就是当前未登录打车平台的司机。这类司机通常在打车平台上有一定的活跃程度，但是其活跃程度相对正常接单的司机来说偏低，因此可以根据历史司机数据统计各个司机当前的活跃值，如果活跃值处于设定活跃值区间内、且该司机当前不在线，则该司机可以视为沉默司机。活跃值的统计方式可以从司机的在线时长、已注册时长、接单数量、接单的运行里程等参数中选择一个或多个参数进行统计，统计的历史司机数据也可以是当前时间之前指定时长内的数据，该指定时长可以根据经验设定，例如一星期或者两星期，也可以是一个月或两个月等。上述活跃值具体统计过程可以根据需要灵活制定，本发明实施方式对此不进行限定。
针对乘客在热点区域或高峰时段内叫车困难，司机供不应求的问题，本申请提供了一种运力调度方法、装置和服务器，通过唤醒运力不足区域相关的沉默司机，并调度沉默司机前往运力不足区域接单的方式实现运力调度，缓解乘客叫车困难的问题，提升用户体验。本申请具体通过下述实施例对此作详细说明。
实施例1
参见图2所示的一种运力调度方法流程图，该方法可以应用于平台服务器，包括如下步骤：
步骤S202，如果预测指定时段内有运力不足的区域，根据该区域对应的历史司机数据确定包含沉默司机信息的数据。其中，包含沉默司机信息的数据可简称为沉默司机数据。
在实际应用中，上述指定时段也可以是当前起的未来一段时间，诸如，从当前起的未来1小时或者未来30分钟等；当然，上述指定时段也可以是服务器统计的用车高峰时段，诸如7:00～8:00、11:00～13:00和17:00～20:00等日常上下班时段，或者节假日全天等。在一种实施方式中，可以由服务器根据历史订车需求自动确定指定时段，在另一种实施方式中，可以人工设定指定时段。
上述运力不足的区域也即司机供不应求的区域，诸如，办公楼聚集区域、学校门口、居民区以及商场聚集区等。在这些运力不足的区域，打车平台上可接单的司机数量通常少于乘客的订单数量，难以满足乘客用车需求。
可以理解的是，服务器通常会记录每个司机的历史数据，诸如司机的历史活跃区域、注册的家庭地址、日常收车地点、日常出车地点、日常收车时间、日常出车时间、日常活跃时长等，具体可以参见表1所示的历史司机数据的一种形式，本申请实施例的历史司机数据并不限定为表格形式，也可以是其它数据格式。
表1
Figure BDA0001810481970000111
表1中仅简单示意出了两名司机的历史数据，其中，日常收车地点和日常出车地点、日常收车时间和日常出车时间可以是司机是通过司机端APP自行设定的，也可以是服务器通过对张三的历史行车轨迹进行统计分析后得到的；日常活跃时长可以是司机每天在线时长或者运营时长。诸如，张三是一名代驾司机，张三的日常收出车地点为张三住宅区(X区)和办公楼附近(Y区)，而日常收出车时间为张三的上下班时间(早8:00，晚20:00)。李四是一名专职出租车司机，李四的日常收出车地点统一为出租车公司(Z区)，日常出车时间为下午14:00，日常收车时间为傍晚23:00等。
服务器可以根据运力不足区域以及统计的各司机的历史数据，可确定运力不足的区域对应的包含候选司机信息的数据(可简称为候选司机数据)，进而从候选司机数据中筛选得到包含沉默司机信息的数据。诸如运力不足区域为A区，而张三的收/出车地点包含A区，李四的历史活跃区为A区，则张三和李四均为A区的候选司机。但根据张三和李四的在线时长以及历史接单数据表明：张三基本每天在线并接单，活跃值很高，而李四在线时长较短，接单数量也较少，则服务器将李四认为是A区对应的沉默司机。
步骤S204，从包含沉默司机信息的数据中筛选包含目标司机信息的数据。其中，包含目标司机信息的数据可简称为目标司机数据，目标司机也即可调度的司机。
从沉默司机数据中筛选目标司机数据的实现方式有多种，诸如当查找到的沉默司机数量较大时，可以按照运力不足的程度随机选取一定数量的司机数据，当查找到的沉默司机数据数量较小时，可以将查找到的沉默司机数据都作为目标司机数据，又诸如，无论查找到沉默司机的数量有多少，都可以通过唤醒概率确定目标司机，唤醒概率可以通过活跃值衡量，活跃值越高，唤醒概率越高，因此可以从沉默司机数据中选择活跃值高于某一设定活跃阈值的司机数据作为目标司机数据。另外，服务器可以采用诸如机器学习等方式计算各沉默司机的唤醒概率，将唤醒概率高于预设阈值的沉默司机数据确定为目标司机数据。
为便于理解，参见图3a所示的一种目标司机的筛选示意图，示意出服务器通过历史司机数据确定与运力不足区域相关的多名沉默司机，然后从沉默司机中圈取一定数量的目标司机，圈取范围可以取决于运力不足的程度。圈取方式也有多种，可以是集中圈取，也可以是分散圈取。参见图3b所示的另一种目标司机的筛选示意图，示意出每个沉默司机的唤醒概率，图3b将唤醒概率高于60％的沉默司机确定为目标司机。
步骤S206，向目标司机下发在指定时段内到达上述区域的调度通知。其中，上述区域也即运力不足的区域。在具体实施时，可以获取目标司机的联系方式，具体的，联系方式优选短信联系方式，随着技术的发展，也可以采用类似微信、QQ等第三方联系方式的通信方式，当然，还可以包括语音联系方式。然后使用联系方式向目标司机下发在指定时段内到达运力不足的区域的调度通知，调度通知包括运力不足区域的标识和指定时段的标识。诸如，给目标司机张三发送短信“张三先生您好，预计A区在18:00～20:00期间用车需求量较大，建议您届时前往A区接单”。
为了促使目标司机积极响应平台调度，服务器可以获取运力不足的区域的奖励机制和调度信息；其中，奖励机制可以包括应答区域的订单的优惠券和/或订单提成比例等，调度信息可以包括区域的标识和指定时段的标识等，然后向目标司机下发在指定时段内到达运力不足的区域的调度通知，该调度通知包括奖励机制和调度信息。诸如，给目标司机张三发送短信“张三先生您好，如18:00～20:00在A区接单，每单可享受10元奖金”。通过这种方式，能够有效唤醒沉默司机，鼓励沉默司机配合调度，改善在热点区域的司机供不应求的问题。
本申请实施例提供的上述运力调度方法，能够根据运力不足区域对应的历史司机数据确定包含沉默司机信息的数据，并从包含沉默司机信息的数据中筛选包含目标司机信息的数据，进而向目标司机下发在指定时段内到达运力不足的区域的调度通知。这种从沉默司机中筛选可调度的目标司机，并调度目标司机前往运力不足区域的方式，能够较好地缓解乘客用车需求旺盛但司机供给不足的问题，有效提升了用户体验。
上述运力调度方法在具体实施时，需要首先从打车平台覆盖的区域中判断是否存在运力不足区域。在一种实施方式中，可以根据历史订单数据预测指定时段内是否存在运力不足的区域。平台服务器可以对历史订单进行统计分析，诸如确定各区域对应的订单生成数量以及订单应答数量等，如果某区域的订单应答数量低于订单生成数量，则表明该区域为运力不足的区域，具体可参照如下步骤执行：
(1)查找指定时段对应的热点区域。
可以理解是，不同时间段对应的热点区域不同。例如：如果是上班/上学时段(诸如7:00～9:00)，该热点区域可以为居民区等；如果是下班/放学时段(诸如17:00～20:00)，该热点区域可以为办公楼集中的区域或者学校等；如果非工作时段，热点区域还可能是商场所在区、旅游景点所在区等；此外，无论是何时段，火车站、飞机场、商业区等公共区域均可能是热点区域。在具体实施时，热点区域可以由平台服务器通过以下方式得到：统计目标区域在预设的指定时段内的订单量；将订单量超过设定阈值的目标区域设置为指定时段内的热点区域。或者，指定时段对应的热点区域也可以由人工预先设置，诸如人工根据平台服务器的数据或者第三方数据建立区域对应表，在该区域对应表中存储有各时间段与热点区域的对应关系，平台服务器可以根据该区域对应表查找指定时段对应的热点区域。
(2)调取热点区域对应指定时段的至少一组历史订单数据。
在一种实施方式中，可以以当前时间为基准，调取热点区域对应的N个指定时段的历史订单数据，得到N组历史订单数据；其中，N为预先设定的自然数。诸如热点区域为办公楼集中的A区，该区域对应的指定时段为18:00～21:00，则可以以当前时间为基准，调取前30天中的每天18:00～21:00的历史订单数据，得到30组历史订单数据。每组历史订单数据中均可包括在指定时段内的订单生成数量、订单应答数量和/或订单未应答数量。
(3)统计调取的各组历史订单数据中的未应答订单平均值。通过计算各组历史订单数据的未应答订单平均值，能够有效过滤特殊情况，从而更加客观地体现在指定时段下的热点区域是否出现司机供不应求的现象。
(4)如果平均值超过设定的第一阈值，将热点区域确定为指定时段对应的运力不足的区域。诸如，如果经统计得到A区在指定时段为18:00～21:00的未应答订单平均值为50单，超过设定的30单，则A区为18:00～21:00时段对应的运力不足的区域，如果经统计得到A区在指定时段为18:00～21:00的未应答订单平均值为25单，低于设定的30单，则A区并不属于18:00～21:00时段对应的运力不足的区域。
通过上述方式，可以客观有效地确定指定时段对应的运力不足的区域，有助于进一步提升运力调度的准确性和可靠性。
由于打车平台注册有数量众多的司机，为了能够从中确定沉默司机，在一种实施方式中，可以根据历史司机数据查找包含区域的候选司机信息的数据；然后根据包含候选司机信息的数据在指定时段内的在线记录，确定包含沉默司机信息的数据。其中，历史司机数据可以包括以下信息中的一种或多种：历史活跃区域、注册的家庭地址、收车地点、出车地点等。详见图4所示的一种查找候选司机的具体方法流程图，包括如下步骤：
步骤S402，按照经纬度坐标对上述区域(即上述运力不足的区域)进行GeoHash编码。为便于理解，首先对GeoHash编码详细解释说明：
GeoHash算法是一种地址编码方法，能够把二维的空间经纬度数据编码成一维的字符串，诸如，北海公园的GeoHash编码是wx4g0ec1。其基本原理是将地球理解为一个二维平面，将平面递归分解成更小的子块(也即将平面网格化)，每个子块在一定经纬度范围内拥有相同的编码。参见图5所示的一种区域编码示意图，示意出某城市的9个区域分别对应的GeoHash编码为WX4ER、WX4G2、WX4G3、WX4EP、WX4G0、WX4G1、WX4DZ、WX4FB和WX4FC。可以理解的是，不同区域的GeoHash编码不同。在实际应用中，可以根据需要而划分区域，GeoHash编码越长，表示的区域范围越精确。诸如，5位的编码能表示10平方千米范围的矩形区域，而6位编码能表示更精细的区域(约0.34平方千米)。相似编码表示区域距离相近，诸如WX4G2对应的区域和WX4G3对应的区域为相似区域。
根据运力不足区域对应的经纬度坐标，通过查找预先设置的区域编码表，可以确定该区域对应的GeoHash编码。具体实现时，还可以借助第三方搜索服务器进行搜索，诸如借助搜索引擎ES(Elastic Search，弹性搜索)实现实时、快速和稳定搜索。
步骤S404，根据上述区域对应的GeoHash编码获取该区域对应的倒排索引值，将倒排索引表中该倒排索引值对应的包含司机信息的数据，确定为该区域对应的包含候选司机信息的数据；其中，该倒排索引表为预先根据历史司机数据建立的倒排索引值与司机信息的对应关系表。
该倒排索引表可以根据历史司机数据先获取司机的关联GeoHash编码。具体的，司机的关联GeoHash编码即为司机的关联区域的GeoHash编码。司机的关联区域为与司机有关的区域，诸如司机的日常收车地点、日常出车地点、司机的历史活跃地点、司机注册的家庭地址等都可以认为是司机的关联区域。因而，通过平台服务器统计的历史司机数据可以获取司机的关联区域，进而可以通过区域编码表确定司机的关联区域的GeoHash编码(也即，关联GeoHash编码)，再求该编码对应的倒排索引值，然后将司机信息和倒排索引值的对应关系保存于倒排索引表。
通过上述基于GeoHash编码的候选司机查找方式，能够有效查找到与运力不足的区域有关的司机数据，当确定运力不足的区域的候选司机数据后，可以查找候选司机数据在指定时段内的在线记录，其中该在线记录可以包括：收车记录和/或出车记录；当然也可以包括在线时长、行车记录和接单记录等。然后过滤掉候选司机数据中的在线司机数据，得到不在线司机数据，可以将这些不在线的所有司机视为沉默司机，或者也可以进一步缩小沉默司机的范围，提升调度的有效性，从这些不在线司机数据中过滤掉活跃值低于上述设定活跃值区间下限值的不在线司机数据，剩下的司机数据作为沉默司机数据。诸如，如果确定运力不足区域-A区的候选司机分别为张三和李四，而张三在指定时段18:00～21:00记录有收出车时间，或者具有一定的在线时长；而李四在指定时段18:00～21:00基本没有在线记录，因此可以确定张三为在线司机，李四为沉默司机。
在确定沉默司机数据后，本实施例进一步给出了从沉默司机数据中筛选目标司机数据的以下三种具体实现方式：
方式一：根据区域的运力不足程度从沉默司机数据中筛选目标司机数据。也即，根据司机缺乏程度从沉默司机数据中筛选可调度的目标司机数据。
具体实施时，可以参见如下步骤：
(1)根据区域在指定时段内未应答订单平均值，确定区域的运力缺口数。也即，通过服务器统计运力不足的区域在指定时段内的未应答订单平均值，可预测该区域通常在指定时段内的司机缺失数量。在一种实施方式中，运力缺口数等于未应答订单平均值；在另一种实施方式中，运力缺口数等于未应答平均值与预设系数(小于1)的乘积。
诸如，A区在指定时段18:00～21:00内的未应答订单平均值为50单，则区域的运力缺口数为50名司机；或者，区域的运力缺口数为40＝50*0.8；其中，0.8为预设系数。设定预设系数的原因在于考虑到部分司机在指定时段内可以完成多个订单。司机可能逐一完成多个订单，也可能同时完成多个订单。诸如在打车平台提供的拼车模式下，如果多名选择拼车模式且路线大致相同的乘客虽各自下单，但是司机可以同时接送拼车乘客，实现一次完成多个订单。在实际应用中，可以根据历史订单数量以及历史接单数量确定该系数，然后将该系数乘以未应答订单平均值，即可确定若完成未应答订单平均值所需的司机数量，所需的司机数量也即为区域的运力缺口数。
(2)统计沉默司机的数量。诸如，通过GeoHash编码确定与运力不足的区域相关的候选司机数据，进而根据候选司机数据在指定时段内诸如收出车记录、在线时长和接单记录等在线记录，筛选出沉默司机数据，然后统计沉默司机的数量。
(3)根据沉默司机的数量和运力缺口数，确定目标司机的数量。在一种实施方式中，如果沉默司机的数量少于运力缺口数，确定目标司机的数量即为沉默司机的数量，也即将全部沉默司机都作为目标司机。在另一种实施方式中，如果沉默司机的数量多于运力缺口数，则从沉默司机中确定目标司机的数量等于运力缺口数。
(4)从沉默司机数据中选取上述数量的司机数据作为目标司机数据。在确定了目标司机的数量后，可以从沉默司机中随机选取该数量的司机作为可调度的目标司机，也可以评估每个沉默司机的沉默程度，然后将沉默司机按照沉默程度由轻至重排序，然后选取从前至后的上述数量的司机作为目标司机。
方式二：根据沉默司机的唤醒概率从沉默司机数据中筛选目标司机数据。也即，通过评估各沉默司机的唤醒概率，从沉默司机中筛选唤醒概率较大的司机作为目标司机。其中，唤醒概率是沉默司机愿意接受平台调度的概率。
具体实施时，可以参见如下步骤：
(1)基于预先训练的机器学习模型计算沉默司机的唤醒概率。机器学习模型是现如今人工智能的关键技术，能够对数据进行分析处理，并得到所需结果。诸如，逻辑回归模型，随机森林模型，贝叶斯方法模型，支持向量机模型、神经网络模型等均属于机器学习模型。若要将机器学习模型投入实际应用，需要采用训练数据集对机器学习模型进行训练，使机器学习模型通过有监督式学习或无监督式学习的不断训练而符合要求，准确地输出所需结果。在本实施例中，可以采用神经网络模型作为机器学习模型进行训练，计算沉默司机的唤醒概率。
(2)将唤醒概率大于设定的第二阈值的沉默司机数据确定为目标司机数据。诸如，将唤醒概率大于50％的沉默司机数据确定为目标司机数据。
通过唤醒概率筛选目标司机，能够提升目标司机接受调度的可能性，保障打车平台的运力调度效果。
本实施例进一步给出了一种机器学习模型的训练过程，参见图6所示的一种机器学习模型的训练方法流程图：
步骤S602，根据沉默司机的历史唤醒数据库训练预设的XGboost模型。
XGboost(eXtreme Gradient Boosting，极值梯度提升)模型是一种当前效果较佳的预测模型，在实际应用中，可以从沉默司机的历史唤醒数据库中得到训练数据，然后采用训练数据训练XGboost模型。在历史唤醒数据库中可以存储有沉默司机的相关信息以及对应的唤醒结果；其中，沉默司机的相关信息可以包括沉默司机的离线时长、历史接单量等。唤醒结果可以为该沉默司机是否接受平台调度，或者该唤醒结果可以为该沉默司机在历史调度过程中接受调度的次数等。历史唤醒数据库可以采用表2所示的数据形式；其中，表2中统计有司机在近期1个月的相关信息。
表2
Figure BDA0001810481970000191
由表2中可见，司机张三在一个月内有480h为离线状态，且仅接单10次，但有配合调度的历史记录，在10次接单中是有2次接单属于配合调度接单。配合调度的概率可以是张三配合调度的次数与平台服务器给张三发送的调度通知次数的比值，诸如，张三在一个月内共接收到平台服务器发送的20次调度通知，而张三在一个月内仅响应了2次，因此张三在1个月内配合调度的概率为2/20＝10％。
通过上述历史唤醒数据库中的数据可以训练XGboost模型，以使XGboost模型输出符合本实施例需求的结果。
步骤S604，获取训练后的XGboost模型输出的特征数据，将特征数据输入至预设的LR模型进行训练。具体实施时，可以是将训练数据输入至XGboost模型后得到的叶子节点作为XGboost模型输出的特征数据，然后利用叶子节点(度为0，又称终端节点)训练LR(Logistic Regression,逻辑回归)模型。LR模型主要是在线性回归的基础上套用了逻辑函数，能够较好地兼顾数据的拟合度和模型解释度，而且计算简单便捷，最终可得到较为准确的沉默司机唤醒概率。XGboost模型和LR模型的具体结构可以参照相关技术实现，在此不再赘述。
步骤S606，将训练后的LR模型作为机器学习模型。
本申请实施例采用XGBoost+LR融合的方式得到机器学***台服务器通过借助机器学习模型，能够较为准确可靠地评估每个沉默司机的唤醒概率。
方式三：根据查找到的沉默司机数据的数量筛选目标司机数据。也即，目标司机的筛选过程在较大程度上取决于沉默司机的数量。
具体实施时，可以参见如下步骤：
(1)判断查找到的沉默司机数据的数量是否高于预设数量。这种方式通过预设数量来衡量沉默司机数量的多少。预设数量可以是人工设定，也可以是服务器根据历史经验而自行设定。
(2)如果是，按照运力不足程度随机选取一定数量的目标司机数据。也即，当查找到的沉默司机数量较大时，根据司机缺少的数量而从数量较多的沉默司机中随机选取可调度的目标司机。
(3)如果否，将查找到的沉默司机数据都作为目标司机数据。也即，当查找到的沉默司机数量较小时，将所有沉默司机都作为可调度的目标司机。
在实际应用中，可以根据需求而灵活选取上述方式一至方式三中的任一种，也可以将上述三种方式中的多种方式相结合，诸如根据运力不足程度、司机的唤醒概率以及查找到的沉默司机数量综合筛选目标司机。当然，以上仅为示例性说明，还可以采用其筛选方式，在此不再赘述。
通过本申请实施例提供的上述运力调度方法，能够根据运力不足区域对应的历史司机数据确定沉默司机数据，并从沉默司机数据中筛选目标司机数据，进而调度目标司机。这种方式可以较好地缓解乘客用车需求旺盛但司机供给不足的问题，一方面降低了乘客的打车用时，另一方面也给司机带来收益，综合提升了用户体验。
实施例二
结合前述实施例一，本实施例给出了一种具体的运力调度方法，该方法可以应用于平台服务器，该平台服务器通过本申请实施例提供的运力调度方法能够将沉默司机中可调度的司机派往所需区域接单。参见图7所示的另一种运力调度方法流程图，具体包括如下步骤：
步骤S702，根据历史订单数据预测指定时段内存在的运力不足的区域。
在具体实施时，平台服务器通过对历史订单数据进行统计分析，查找指定时段内(诸如未来1小时)的热点区域，然后根据热点区域的历史订单数据确定热点区域的未应答订单平均值，进而将应答订单平均值高于设定第一阈值的热点区域确定为运力不足的区域。在实际应用中，历史订单数据具体可以包括订单起终点和订单起终时间等，关于乘客的历史订单数据还可以包括乘客的日常上下车时间、日常订单轨迹和乘客的历史订单数量，关于司机的历史订单数据还可以包括司机的日常收车地点、出车地点、收车时间、出车时间、司机的历史接单数量、司机的行车轨迹规律等数据。
步骤S704，根据GeoHash编码确定上述区域的候选司机数据。
在具体实施时，可以通过运力不足区域对应的经纬度坐标，获取运力不足区域的GeoHash编码，根据历史司机数据获取司机的关联GeoHash编码，其中，关联GeoHash编码即为司机的关联区域的GeoHash编码；如果司机的关联GeoHash编码有运力不足的区域的GeoHash编码，则将该司机确定为运力不足的区域的候选司机。通过这种方式，能够有效准确获知与运力不足的区域相关的司机，这些司机都可认为是区域运力。
步骤S706，通过收车记录和/或出车记录过滤候选司机数据中的在线司机数据，得到沉默司机数据和活跃值低于上述设定活跃值区间下限值的不在线司机数据。
在具体实施时，可以根据司机的收出车记录对候选司机进行筛选，过滤掉在线司机和活跃值低于设定活跃值区间下限值的不在线司机，确定沉默司机。具体的，根据司机出车/收车状态，可以判断出司机当前接单情况，从而识别出沉默司机，该沉默司机可以是在指定时段不再接单或者已经下线的司机。
步骤S708，通过预先训练的机器学习模型计算各沉默司机的唤醒概率。
在具体实施时，上述机器学习模型可以是XGBoost+LR融合模型，其结构可参照相关技术实现，在此不再赘述。将沉默司机的历史司机数据输入至预先训练的机器学习模型(又可称为唤醒模型)中，可得到沉默司机的唤醒概率。
步骤S710，根据各沉默司机的唤醒概率确定可调用的目标司机数据。
具体可以将唤醒概率大于设定的第二阈值(诸如，50％)的沉默司机确定为目标司机。在实际应用中，也可以结合区域的运力缺口或者司机需求量，以及各沉默司机的唤醒概率确定可调用的目标司机。
步骤S712，获取目标司机的短信联系方式，通过短信形式向目标司机下发在指定时段内到达上述区域的调度通知。从而以将目标司机派往至运力不足区域。
在调度通知中可以包括运力不足的区域的标识和指定时段的标识，以便于司机清楚地了解调度区域和时间；当然，为了提升司机的积极性，促使司机配合调度，调度通知中还可以包括奖励机制，该奖励机制可以包括应答区域的订单的优惠券和/或订单提成比例等。
通过本实施例提供的上述方式，能够预测运力不足的区域，并找出该区域有关的沉默司机，通过计算得到的各沉默司机的唤醒概率，从沉默司机中筛选出一批目标司机，进而采取向其发短信、给其奖励等方式将其唤醒，引导其前往相应区域接单，有效缓解乘客用车需求旺盛但司机供给不足的问题，不仅降低了乘客的打车用时，而且也给司机带来收益，增加了乘客与司机对于打车平台的粘附度，较好地提升了用户体验。
实施例四
对应于前述运力调度方法，本实施例提供了一种运力调度装置，该装置应用于平台服务器，参见图8所示的一种运力调度装置的结构框图，包括依次连接的司机确定模块82、司机筛选模块84和司机调度模块86，其中：
司机确定模块82，用于如果预测指定时段内有运力不足的区域，根据区域对应的历史司机数据确定包含沉默司机信息的数据，其中，所述沉默司机包括活跃值在设定活跃值区间内的不在线司机；。
在一种实施方式中，司机确定模块用于：根据历史司机数据查找区域的候选司机；历史司机数据包括以下信息中的一种或多种：历史活跃区域、注册的家庭地址、收车地点、出车地点；根据候选司机在指定时段内的在线记录确定沉默司机。
具体实施时，司机确定模块可用于根据以下步骤查找候选司机：按照经纬度坐标对所述区域进行GeoHash编码；根据所述区域对应的GeoHash编码获取所述区域对应的倒排索引值；将倒排索引表中所述倒排索引值对应的包含司机信息的数据，确定为所述区域对应的包含候选司机信息的数据；其中，所述倒排索引表为预先根据历史司机数据建立的倒排索引值与司机信息的对应关系表。
在另一种实施方式中，司机确定模块用于：查找包含候选司机信息的数据在指定时段内的在线记录，在线记录包括：收车记录和/或出车记录；过滤候选司机中的在线司机和活跃值低于所述设定活跃值区间下限值的不在线司机，得到沉默司机。
司机筛选模块84，用于从包含沉默司机信息的数据中筛选包含目标司机信息的数据。
在一种实施方式中，司机筛选模块用于：根据区域的运力不足程度，从包含沉默司机信息的数据中筛选包含目标司机信息的数据；或者，根据沉默司机的唤醒概率，从包含沉默司机信息的数据中筛选包含目标司机信息的数据。
具体实施时，司机筛选模块可用于根据以下步骤确定目标司机：根据区域在指定时段内未应答订单平均值，确定区域的运力缺口数；统计沉默司机的数量；根据沉默司机的数量和运力缺口数，确定目标司机的数量；从包含沉默司机信息的数据中，选取包含上述数量的司机信息的数据作为包含目标司机信息的数据。
在另一种实施方式中，司机筛选模块用于：基于预先训练的机器学习模型计算沉默司机的唤醒概率；将唤醒概率大于设定的第二阈值的包含沉默司机信息的数据，确定为包含目标司机信息的数据。
其中，机器学习模型的训练过程包括：根据沉默司机的历史唤醒数据库训练预设的XGboost模型；获取训练后的XGboost模型输出的特征数据，将特征数据输入至预设的LR模型进行训练；将训练后的LR模型作为机器学习模型。
司机调度模块86，用于向目标司机下发在指定时段内到达上述区域(也即，前述运力不足的区域)的调度通知。
在一种实施方式中，司机调度模块用于：获取目标司机的短信联系方式；使用短信联系方式向目标司机下发在指定时段内到达上述区域的调度通知，调度通知包括区域的标识和指定时段的标识。
在另一种实施方式中，司机调度模块用于：获取区域的奖励机制和调度信息；其中，奖励机制包括：应答区域的订单的优惠券和/或订单提成比例；调度信息包括：区域的标识和指定时段的标识；向目标司机下发在指定时段内到达上述区域的调度通知，调度通知包括奖励机制和调度信息。
本申请实施例提供的上述运力调度装置，能够根据运力不足区域对应的历史司机数据确定包含沉默司机信息的数据，并从包含沉默司机信息的数据中筛选包含目标司机信息的数据，进而向目标司机下发在指定时段内到达运力不足的区域的调度通知。这种从沉默司机中筛选可调度的目标司机，并调度目标司机前往运力不足区域的方式，能够较好地缓解乘客用车需求旺盛但司机供给不足的问题，有效提升了用户体验。
参见图9所示的另一种运力调度装置的结构框图，在图8的基础上，该装置还包括：区域预测模块92，用于根据历史订单数据预测指定时段内是否存在运力不足的区域。
在一种实施方式中，上述区域预测模块用于：查找指定时段对应的热点区域；调取热点区域对应指定时段的至少一组历史订单数据；统计调取的各组历史订单数据中的未应答订单平均值；如果平均值超过设定的第一阈值，将热点区域确定为指定时段对应的运力不足的区域。
进一步，区域预测模块具体用于根据以下步骤得到订单数据：以当前时间为基准，调取热点区域对应的N个指定时段的历史订单数据，得到N组历史订单数据；其中，N为预先设定的自然数。
本实施例所提供的装置，其实现原理及产生的技术效果和前述实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。
实施例五
本申请实施例提供了一种服务器，该服务器包括存储器以及处理器，存储器用于存储支持处理器执行前述任一项运力调度方法的程序，处理器被配置为用于执行存储器中存储的程序。
参见图10所示的一种服务器的结构示意图，具体包括处理器100，存储器101，总线102和通信接口103，处理器100、通信接口103和存储器101通过总线102连接；处理器100用于执行存储器101中存储的可执行模块，例如计算机程序。
其中，存储器101可能包含高速随机存取存储器(RAM，Random Access Memory)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口103(可以是有线或者无线)实现该***网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。
总线102可以是ISA总线、PCI总线或EISA总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
其中，存储器101用于存储程序，处理器100在接收到执行指令后，执行程序，前述本申请实施例任一实施例揭示的流过程定义的装置所执行的方法可以应用于处理器100中，或者由处理器100实现。
处理器100可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器100中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器100可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DigitalSignal Processing，简称DSP)、专用集成电路(Application Specific IntegratedCircuit，简称ASIC)、现成可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器101，处理器100读取存储器101中的信息，结合其硬件完成上述方法的步骤。
本实施例提供的运力调度方法可以由上述服务器执行，亦或，本实施例提供的运力调度方法装置可以设置于上述服务器侧。
进一步，本实施例还提供了一种计算机存储介质，用于储存为前述任一项运力调度装置所用的计算机软件指令。
具体地，上述存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述运力调度方法，从而改善现有技术中存在的因司机供不应求而导致乘客叫车困难的问题，有效提升了用户体验。
功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
在本申请的描述中，需要说明的是，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。
最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (28)

1.一种运力调度方法，其特征在于，所述方法应用于平台服务器，所述方法包括：
如果预测指定时段内有运力不足的区域，根据所述区域对应的历史司机数据确定包含沉默司机信息的数据；其中，所述沉默司机包括活跃值在设定活跃值区间内的不在线司机；
从所述包含沉默司机信息的数据中筛选包含目标司机信息的数据；
向所述目标司机下发在所述指定时段内到达所述区域的调度通知。
2.如权利要求1所述的方法，其特征在于，所述方法还包括：
根据历史订单数据预测指定时段内是否存在运力不足的区域。
3.如权利要求2所述的方法，其特征在于，所述根据历史订单数据预测指定时段内是否存在运力不足的区域的步骤，包括：
查找指定时段对应的热点区域；
调取所述热点区域对应所述指定时段的至少一组历史订单数据；
统计调取的各组所述历史订单数据中的未应答订单平均值；
如果所述平均值超过设定的第一阈值，将所述热点区域确定为所述指定时段对应的运力不足的区域。
4.如权利要求3所述的方法，其特征在于，所述调取所述热点区域对应所述指定时段的至少一组历史订单数据的步骤，包括：
以当前时间为基准，调取所述热点区域对应的N个所述指定时段的历史订单数据，得到N组历史订单数据；其中，N为预先设定的自然数。
5.如权利要求1所述的方法，其特征在于，所述根据所述区域对应的历史司机数据确定包含沉默司机信息的数据的步骤，包括：
根据历史司机数据查找包含所述区域的候选司机信息的数据；所述历史司机数据包括以下信息中的一种或多种：历史活跃区域、注册的家庭地址、收车地点、出车地点；
根据包含所述候选司机信息的数据在所述指定时段内的在线记录，确定包含沉默司机信息的数据。
6.如权利要求5所述的方法，其特征在于，所述根据历史司机数据查找包含所述区域的候选司机信息的数据的步骤，包括：
按照经纬度坐标对所述区域进行GeoHash编码；
根据所述区域对应的GeoHash编码获取所述区域对应的倒排索引值；
将倒排索引表中所述倒排索引值对应的包含司机信息的数据，确定为所述区域对应的包含候选司机信息的数据；其中，所述倒排索引表为预先根据历史司机数据建立的倒排索引值与司机信息的对应关系表。
7.如权利要求5所述的方法，其特征在于，所述根据包含所述候选司机信息的数据在所述指定时段内的在线记录确定包含沉默司机信息的数据的步骤，包括：
查找包含所述候选司机信息的数据在所述指定时段内的在线记录，所述在线记录包括：收车记录和/或出车记录；
过滤包含所述候选司机信息的数据中的包含在线司机信息的数据和活跃值低于所述设定活跃值区间下限值的包含不在线司机信息的数据，得到包含沉默司机信息的数据。
8.如权利要求1所述的方法，其特征在于，所述从包含沉默司机信息的数据中筛选包含目标司机信息的数据的步骤，包括：
根据所述区域的运力不足程度，从包含沉默司机信息的数据中筛选包含目标司机信息的数据；或者，
根据所述沉默司机的唤醒概率，从包含沉默司机信息的数据中筛选包含目标司机信息的数据。
9.如权利要求8所述的方法，其特征在于，所述根据所述区域的运力不足程度，从包含沉默司机信息的数据中筛选包含目标司机信息的数据的步骤，包括：
根据所述区域在所述指定时段内未应答订单平均值，确定所述区域的运力缺口数；
统计所述沉默司机的数量；
根据所述沉默司机的数量和所述运力缺口数，确定目标司机的数量；
从包含所述沉默司机信息的数据中，选取包含所述数量的司机信息的数据作为包含目标司机信息的数据。
10.如权利要求8所述的方法，其特征在于，所述根据所述沉默司机的唤醒概率，从包含沉默司机信息的数据中筛选包含目标司机信息的数据的步骤，包括：
基于预先训练的机器学习模型计算所述沉默司机的唤醒概率；
将唤醒概率大于设定的第二阈值的包含沉默司机信息的数据，确定为包含目标司机信息的数据。
11.如权利要求10所述的方法，其特征在于，所述机器学习模型的训练过程包括：
根据沉默司机的历史唤醒数据库训练预设的Xgboost模型；
获取训练后的所述Xgboost模型输出的特征数据，将所述特征数据输入至预设的LR模型进行训练；
将训练后的LR模型作为所述机器学习模型。
12.如权利要求1所述的方法，其特征在于，所述向所述目标司机下发在所述指定时段内到达所述区域的调度通知的步骤，包括：
获取所述目标司机的短信联系方式；
使用所述短信联系方式向所述目标司机下发在所述指定时段内到达所述区域的调度通知，所述调度通知包括所述区域的标识和所述指定时段的标识。
13.如权利要求1所述的方法，其特征在于，所述向所述目标司机下发在所述指定时段内到达所述区域的调度通知的步骤，包括：
获取所述区域的奖励机制和调度信息；其中，所述奖励机制包括：应答所述区域的订单的优惠券和/或订单提成比例；所述调度信息包括：所述区域的标识和所述指定时段的标识；
向所述目标司机下发在所述指定时段内到达所述区域的调度通知，所述调度通知包括所述奖励机制和所述调度信息。
14.一种运力调度装置，其特征在于，所述装置应用于平台服务器，所述装置包括：
司机确定模块，用于如果预测指定时段内有运力不足的区域，根据所述区域对应的历史司机数据确定包含沉默司机信息的数据；其中，所述沉默司机包括活跃值在设定活跃值区间内的不在线司机；
司机筛选模块，用于从所述包含沉默司机信息的数据中筛选包含目标司机信息的数据；
司机调度模块，用于向所述目标司机下发在所述指定时段内到达所述区域的调度通知。
15.如权利要求14所述的装置，其特征在于，所述装置还包括：
区域预测模块，用于根据历史订单数据预测指定时段内是否存在运力不足的区域。
16.如权利要求15所述的装置，其特征在于，所述区域预测模块用于：
查找指定时段对应的热点区域；
调取所述热点区域对应所述指定时段的至少一组历史订单数据；
统计调取的各组所述历史订单数据中的未应答订单平均值；
如果所述平均值超过设定的第一阈值，将所述热点区域确定为所述指定时段对应的运力不足的区域。
17.如权利要求16所述的装置，其特征在于，所述区域预测模块用于：
以当前时间为基准，调取所述热点区域对应的N个所述指定时段的历史订单数据，得到N组历史订单数据；其中，N为预先设定的自然数。
18.如权利要求14所述的装置，其特征在于，所述司机确定模块用于：
根据历史司机数据查找包含所述区域的候选司机信息的数据；所述历史司机数据包括以下信息中的一种或多种：历史活跃区域、注册的家庭地址、收车地点、出车地点；
根据包含所述候选司机信息的数据在所述指定时段内的在线记录，确定包含沉默司机信息的数据。
19.如权利要求18所述的装置，其特征在于，所述司机确定模块用于：
按照经纬度坐标对所述区域进行GeoHash编码；
根据所述区域对应的GeoHash编码获取所述区域对应的倒排索引值；
将倒排索引表中所述倒排索引值对应的包含司机信息的数据，确定为所述区域对应的包含候选司机信息的数据；其中，所述倒排索引表为预先根据历史司机数据建立的倒排索引值与司机信息的对应关系表。
20.如权利要求18所述的装置，其特征在于，所述司机确定模块用于：
查找包含所述候选司机信息的数据在所述指定时段内的在线记录，所述在线记录包括：收车记录和/或出车记录；
过滤包含所述候选司机信息的数据中的包含在线司机信息的数据和活跃值低于所述设定活跃值区间下限值的包含不在线司机信息的数据，得到包含沉默司机信息的数据。
21.如权利要求14所述的装置，其特征在于，所述司机筛选模块用于：
根据所述区域的运力不足程度，从包含沉默司机信息的数据中筛选包含目标司机信息的数据；或者，
根据所述沉默司机的唤醒概率，从包含沉默司机信息的数据中筛选包含目标司机信息的数据。
22.如权利要求21所述的装置，其特征在于，所述司机筛选模块用于：
根据所述区域在所述指定时段内未应答订单平均值，确定所述区域的运力缺口数；
统计所述沉默司机的数量；
根据所述沉默司机的数量和所述运力缺口数，确定目标司机的数量；
从包含所述沉默司机信息的数据中，选取包含所述数量的司机信息的数据作为包含目标司机信息的数据。
23.如权利要求21所述的装置，其特征在于，所述司机筛选模块用于：
基于预先训练的机器学习模型计算所述沉默司机的唤醒概率；
将唤醒概率大于设定的第二阈值的包含沉默司机信息的数据，确定为包含目标司机信息的数据。
24.如权利要求23所述的装置，其特征在于，所述机器学习模型的训练过程包括：
根据沉默司机的历史唤醒数据库训练预设的Xgboost模型；
获取训练后的所述Xgboost模型输出的特征数据，将所述特征数据输入至预设的LR模型进行训练；
将训练后的LR模型作为所述机器学习模型。
25.如权利要求14所述的装置，其特征在于，所述司机调度模块用于：
获取所述目标司机的短信联系方式；
使用所述短信联系方式向所述目标司机下发在所述指定时段内到达所述区域的调度通知，所述调度通知包括所述区域的标识和所述指定时段的标识。
26.如权利要求14所述的装置，其特征在于，所述司机调度模块用于：
获取所述区域的奖励机制和调度信息；其中，所述奖励机制包括：应答所述区域的订单的优惠券和/或订单提成比例；所述调度信息包括：所述区域的标识和所述指定时段的标识；
向所述目标司机下发在所述指定时段内到达所述区域的调度通知，所述调度通知包括所述奖励机制和所述调度信息。
27.一种服务器，其特征在于，所述服务器包括存储器以及处理器，所述存储器用于存储支持处理器执行权利要求1至13任一项所述方法的程序，所述处理器被配置为用于执行所述存储器中存储的程序。
28.一种计算机存储介质，其特征在于，用于储存为权利要求14至26任一项所述装置所用的计算机软件指令。
CN201811119726.1A 2018-09-25 2018-09-25 运力调度方法、装置和服务器 Active CN110942220B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811119726.1A CN110942220B (zh) 2018-09-25 2018-09-25 运力调度方法、装置和服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811119726.1A CN110942220B (zh) 2018-09-25 2018-09-25 运力调度方法、装置和服务器

Publications (2)

Publication Number Publication Date
CN110942220A CN110942220A (zh) 2020-03-31
CN110942220B true CN110942220B (zh) 2022-06-28

Family

ID=69904363

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811119726.1A Active CN110942220B (zh) 2018-09-25 2018-09-25 运力调度方法、装置和服务器

Country Status (1)

Country Link
CN (1) CN110942220B (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111931101B (zh) * 2020-06-30 2024-06-18 汉海信息技术(上海)有限公司 信息推送方法、装置、电子设备及存储介质
CN112529650A (zh) * 2020-11-25 2021-03-19 深圳市元征科技股份有限公司 一种车辆管理方法、***及电子设备
CN112836978B (zh) * 2021-02-08 2024-06-04 北京嘀嘀无限科技发展有限公司 一种数据处理方法、装置、设备、介质和产品
CN112991005A (zh) * 2021-02-08 2021-06-18 同济大学 一种交通需求管理策略下的拼车出行管理方法
CN112990610B (zh) * 2021-05-06 2021-08-20 北京工业大学 一种基于多元线性回归预测火车站出租车运力需求的方法
CN116109349A (zh) * 2023-04-10 2023-05-12 北京白驹易行科技有限公司 网约车运力激励方法、装置、计算机设备和存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8315898B2 (en) * 2002-10-30 2012-11-20 Palo Alto Research Center, Incorporated Planning and scheduling reconfigurable systems around off-line resources
US20080215407A1 (en) * 2007-03-01 2008-09-04 Julian Pachon Resource Scheduling with Rule Violation Feedback
US9514428B2 (en) * 2011-10-28 2016-12-06 Viridity Energy, Inc. Managing energy assets associated with transport operations
CN102789599B (zh) * 2012-07-06 2015-07-01 西北工业大学 一种基于聚类分析和多属性决策的作业车间瓶颈识别方法
CN103218769A (zh) * 2013-03-19 2013-07-24 王兴健 出租车订单分配方法
CN104574939A (zh) * 2013-10-29 2015-04-29 上海沐风数码科技有限公司 基于3g网络的面向特大人口城市的出租车车载终端调控***
US20170227370A1 (en) * 2016-02-08 2017-08-10 Uber Technologies, Inc. Reducing wait time of providers of ride services using zone scoring

Also Published As

Publication number Publication date
CN110942220A (zh) 2020-03-31

Similar Documents

Publication Publication Date Title
CN110942220B (zh) 运力调度方法、装置和服务器
CN108765933B (zh) 一种推荐上车点的方法、装置、设备及存储介质
US11713972B2 (en) System for navigating drivers to passengers based on start times of events
US9488487B2 (en) Route detection in a trip-oriented message data communications system
US8498953B2 (en) Method for allocating trip sharing
US11493347B2 (en) Using historical location data to improve estimates of location
KR101470963B1 (ko) 전력 비용 및 소셜 인자에 기반한 알림의 제어
CN109102135B (zh) 订单分配方法及装置
US20160048777A1 (en) Reservation management method and reservation management apparatus
JP6058139B2 (ja) 公共輸送機関ナビゲータ
US20130166352A1 (en) Mobile categorization
JP5519431B2 (ja) 移動体特徴記述装置、移動体特徴記述方法、移動体特徴記述プログラム及び記録媒体
US8306848B1 (en) Estimation of transit demand models for enhancing ridership
CN107038620B (zh) 基于用户打车偏好的信息推送及装置
US10503724B2 (en) System and method for contact information access
CN110753078B (zh) 提示方法、装置、电子设备及存储介质
CN111582605A (zh) 目的站点的预测方法、装置、电子设备及存储介质
CN104363569A (zh) 一种基于情景感知的向移动用户推荐最优联系方式的方法
JP2017173999A (ja) ユーザの将来期間の生活パターンを予測する生活パターン予測装置、携帯端末、プログラム及び方法
JP2015026311A (ja) 需要予測装置、需要予測方法、および需要予測プログラム
CN111327661A (zh) 推送方法、推送装置、服务器和计算机可读存储介质
Hargunani et al. Integrated bus system using QR code
CN111242711A (zh) 信息提示方法、装置、电子设备和存储介质
CN112052276B (zh) 乘车路线的挖掘方法和装置
CN111833595B (zh) 共享汽车辅助车辆配置方法、电子设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant