CN110110871B

CN110110871B - 一种订单分配的方法和系统

Info

Publication number: CN110110871B
Application number: CN201810103468.1A
Authority: CN
Inventors: 徐哲; 李智欣; 管清文
Original assignee: Beijing Didi Infinity Technology and Development Co Ltd
Current assignee: Beijing Didi Infinity Technology and Development Co Ltd
Priority date: 2018-02-01
Filing date: 2018-02-01
Publication date: 2022-08-19
Anticipated expiration: 2038-02-01
Also published as: CN110110871A

Abstract

本申请实施例公开了一种订单分配方法和系统。所述订单分配方法包括：基于订单分配策略确定多个订单司机匹配对；根据所述多个订单司机匹配对进行订单分配；其中，所述订单分配策略包括：基于多个未出行订单信息和多个待接单司机信息，获取多个订单司机对；根据估值模型确定每个订单司机对的匹配值；基于所述每个订单司机对的匹配值，根据优化匹配算法确定所述多个订单司机匹配对。本申请基于优化匹配算法对订单进行分配，可以实现全局最优；同时，本申请提供了一种订单分配策略的更新方法，通过不断更新订单分配策略，使订单分配更加合理。

Description

一种订单分配的方法和系统

技术领域

本申请涉及互联网领域，特别涉及一种订单分配的方法和系统。

背景技术

随着互联网经济的不断发展，目前网约车服务变得越来越普遍。在网约车服务中，通常由服务平台将订单按照一定的分配策略分配给接单司机。不同的订单分配方式将影响乘客的用户体验、司机的效益和平台的收益等。有必要确定一种较优的订单分配方法和系统，使服务平台可以更好的进行订单分配。

发明内容

本发明实施例之一提供一种订单分配方法。所述订单分配方法包括：基于订单分配策略确定多个订单司机匹配对；根据所述多个订单司机匹配对进行订单分配。其中，所述订单分配策略包括：基于多个未出行订单信息和多个待接单司机信息，获取多个订单司机对；根据估值模型确定每个订单司机对的匹配值；基于所述每个订单司机对的匹配值，根据优化匹配算法确定所述多个订单司机匹配对。

在一些实施例中，所述多个订单司机对包括每个未出行订单和每个待接单司机组成的订单司机对。

在一些实施例中，所述根据估值模型确定每个订单司机对的匹配值包括：获取区域时空价值；根据所述区域时空价值确定每个订单司机对的匹配值。

在一些实施例中，所述获取区域时空价值包括：基于马尔可夫决策过程时空价值模型确定区域时空价值。

在一些实施例中，所述优化匹配算法包括二分图最优匹配算法。

本发明实施例之一提供一种订单分配策略更新方法，其特征在于，包括：获取历史订单数据；根据所述历史订单数据更新估值模型；根据所述更新的估值模型更新订单分配策略。其中，所述估值模型用于确定订单司机对的匹配值。

在一些实施例中，所述获取历史订单数据包括：在第一时间段基于订单分配策略进行订单分配；获取与所述第一时间段相关的订单数据为所述历史订单数据。

在一些实施例中，所述根据所述历史订单数据更新估值模型包括：根据所述历史订单数据确定时空价值函数；根据所述时空价值函数更新所述估值模型。

本发明实施例之一提供一种订单分配系统，包括获取模块、估值模块、匹配模块和分配模块。所述获取模块用于基于多个未出行订单信息和多个待接单司机信息，获取多个订单司机对。所述估值模块用于根据估值模型确定每个订单司机对的匹配值。所述匹配模块用于基于所述每个订单司机对的匹配值，根据优化匹配算法确定多个订单司机匹配对。所述分配模块用于根据所述多个订单司机匹配对进行订单分配。

在一些实施例中，所述估值模块进一步用于：获取区域时空价值；根据所述区域时空价值确定每个订单司机对的匹配值。

在一些实施例中，所述估值模块还用于基于马尔可夫决策过程时空价值模型确定区域时空价值。

本发明实施例之一提供一种订单分配策略更新系统，包括获取模块、估值更新模块和分配策略更新模块。所述获取模块用于获取历史订单数据。所述估值更新模块用于根据所述历史订单数据更新估值模型。所述分配策略更新模块用于根据所述更新的估值模型更新订单分配策略。其中，所述估值模型用于确定订单司机对的匹配值。

在一些实施例中，所述获取模块进一步用于获取与第一时间段相关的订单数据为所述历史订单数据；所述第一时间段为基于订单分配策略进行订单分配的一段时间。

在一些实施例中，所述估值更新模块进一步用于：根据所述历史订单数据确定区域时空价值；根据所述区域时空价值更新所述估值模型。

本发明实施例之一提供一种订单分配装置，包括处理器，所述处理器用于执行订单分配方法。

本发明实施例之一提供一种订单分配策略更新装置，包括处理器，所述处理器用于执行订单分配策略更新方法。

本发明实施例之一提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行订单分配方法。

本发明实施例之一提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行订单分配策略更新方法。

附图说明

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

图1是根据本申请一些实施例所示的订单分配系统的应用场景示意图；

图2是根据本申请一些实施例所示的订单分配系统的模块图；

图3是根据本申请一些实施例所示的订单分配策略的示例性流程图；

图4是根据本申请一些实施例所示的订单分配策略更新方法的示例性流程图；

图5是根据本申请一些实施例所示的估值模型更新方法的示例性流程图；

图6是根据本申请一些实施例所示的示例性二分图示意图；

图7是根据本申请一些实施例所示的状态转移示意图。

具体实施方式

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

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

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

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

本申请的实施例可以应用于不同的交通服务系统，不同的交通服务系统包括但不限于陆地、水面航行、航空、航天等中的一种或几种的组合。例如，人力车、代步工具、汽车(例如，小型车、巴士、大型运输车等)、轨道交通(例如，火车、动车、高铁、地铁等)、船舶、飞机、飞船、卫星、热气球、无人驾驶的交通工具等。本申请的不同实施例应用场景包括但不限于运输业、仓储物流业、农业作业系统、城市公交系统、商业运营车辆等中的一种或几种的组合。应当理解的是，本申请的系统及方法的应用场景仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。例如，其他类似的有轨迹的行驶系统。

图1所示为根据本申请一些实施例所示的订单分配系统的应用场景示意图。该订单分配系统100可以是用于运输服务的线上运输服务平台。在一些实施例中，该订单分配系统100可以提供网约车服务，例如出租车呼叫、快车呼叫、专车呼叫、小巴呼叫、拼车、公交服务、司机雇佣和接送服务等。在一些实施例中，该订单分配系统100还可以提供代驾服务、快递、外卖等。该订单分配系统100可以是一个线上服务平台，包含服务器110、网络120、请求者终端130、提供者终端140以及数据库150。该服务器110可包含处理设备112。

在一些实施例中，服务器110可以用于处理与网约车订单相关的信息和/或数据。服务器110可以是独立的服务器或者服务器组。该服务器组可以是集中式的或者分布式的(如：服务器110可以是分布系统)。在一些实施例中该服务器110可以是区域的或者远程的。例如，服务器110可通过网络120访问存储于请求者终端130、提供者终端140和/或数据库150的信息和/或资料。在一些实施例中，服务器110可直接与请求者终端130、提供者终端140和/或数据库150连接以访问存储于其中的信息和/或资料。在一些实施例中，服务器110可在云平台上执行。例如，该云平台可包括私有云、公共云、混合云、社区云、分散式云、内部云等中的一种或其任意组合。

在一些实施例中，服务器110可包含处理设备112。该处理设备112可处理与服务请求有关的数据和/或信息以执行一个或多个本申请中描述的功能。例如处理设备112可基于从请求者终端130获取的网约车订单请求，为该网约车订单匹配一个服务车辆。在一些实施例中，处理设备112可包含一个或多个子处理设备(如：单芯处理设备或多核多芯处理设备)。仅仅作为范例，处理设备112可包含中央处理器(CPU)、专用集成电路(ASIC)、专用指令处理器(ASIP)、图形处理器(GPU)、物理处理器(PPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编辑逻辑电路(PLD)、控制器、微控制器单元、精简指令集电脑(RISC)、微处理器等或以上任意组合。

网络120可促进数据和/或信息的交换。在一些实施例中，订单分配系统100中的一个或多个组件(如：服务器110、请求者终端130、提供者终端140和数据库150)可通过网络120发送数据和/或信息给订单分配系统100中的其他组件。例如，服务器110可通过网络120从请求者终端130获取/获得网约车请求或需求信息。在一些实施例中，网络120可是任意类型的有线或无线网络。例如，网络120可包括一缆线网络、有线网络、光纤网络、电信网络、内部网络、网际网络、区域网络(LAN)、广域网络(WAN)、无线区域网络(WLAN)、都会区域网络(MAN)、公共电话交换网络(PSTN)、蓝芽网络、ZigBee网络、近场通讯(NFC)网络等或以上任意组合。在一些实施例中，网络120可包括一个或多个网络进出点。例如，网络120可包含有线或无线网络进出点，如基站和/或网际网络交换点120-1、120-2、…，通过这些进出点，订单分配系统100的一个或多个组件可连接到网络120上以交换数据和/或信息。

在一些实施例中，请求者可以是请求者终端130的用户。在一些实施例中，请求者终端130的用户可以是除请求者以外的其他人。例如，请求者终端130的用户A可使用请求者终端130为用户B发送服务请求或从服务器110接收服务和/或信息或指令。在一些实施例中，请求者终端可以是乘客终端，例如请求者可以是乘客本人。

在一些实施例中，提供者可以是提供者终端140的用户。在一些实施例中，提供者终端140的用户可以是除提供者以外的其他人。例如，提供者终端140的用户C可使用该提供者终端140来为用户D接收来自于服务器110的服务请求，和/或信息或指令。在一些实施例中，提供者终端140可以是司机终端，例如，提供者可以是司机本人。

在一些实施例中，请求者终端130可包括移动装置130-1、平板电脑130-2、膝上型电脑130-3、机动车内建装置130-4等中的一种或其任意组合。在一些实施例中，移动装置130-1可包括智能家居装置、可穿戴装置、智能行动装置、虚拟实境装置、增强实境装置等或其任意组合。在一些实施例中，智能家具装置可包括智能照明装置、智能电器的控制装置、智能监测装置、智能电视、智能摄像机、对讲机等或其任意组合。在一些实施例中，可穿戴装置可包括智能手环、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣物、智能背包、智能配饰等或其任意组合。在一些实施例中，智能行动装置可包括智能电话、个人数位助理(PDA)、游戏装置、导航装置、POS装置等或其任意组合。在一些实施例中，虚拟实境装置和/或增强实境装置可包括虚拟实境头盔、虚拟实境眼镜、虚拟实境眼罩、增强实境头盔、增强实境眼镜、增强实境眼罩等或上述举例的任意组合。在一些实施例中，请求者终端130可包括具有定位功能的装置，以确定请求者和/或请求者终端130的位置。

在一些实施例中，提供者终端140可以是与请求者终端130类似或相同的装置。在一些实施例中，提供者终端140可以是一带有定位技术的装置，以确定提供者和/或提供者终端140的位置。在一些实施例中，请求者终端130和/或提供者终端140可与其他定位装置通讯以确定请求者、请求者终端130、提供者、或提供者终端140的位置。在一些实施例中，请求者终端130和/或提供者终端140可将定位信息发送至服务器110。

数据库150可存储资料和/或指令。在一些实施例中，数据库150可存储从请求者终端130和/或提供者终端140获取的资料。在一些实施例中，数据库150可存储供服务器110执行或使用的信息和/或指令，以执行本申请中描述的示例性方法。在一些实施例中，数据库150可包括大容量存储器、可移动存储器、挥发性读写存储器(例如随机存取存储器RAM)、只读存储器(ROM)等或以上任意组合。在一些实施例中，数据库150可在云平台上实现。例如，该云平台可包括私有云、公共云、混合云、社区云、社区云、分散式云、内部云等或以上任意组合。

在一些实施例中，数据库150可与网络120连接以与订单分配系统100的一个或多个部件(如，服务器110、请求者终端130、提供者终端140等)通讯。订单分配系统100的一个或多个组件可通过网络120访问存储于数据库150中的资料或指令。在一些实施例中，数据库150可直接与订单分配系统100中的一个或多个组件(如，服务器110、请求者终端130、提供者终端140等)连接或通讯。在一些实施例中，数据库150可以是服务器110的一部分。

在一些实施例中，订单分配系统100中的一个或多个组件(如，服务器110、请求者终端130、提供者终端140等)可具有访问数据库150的权限。在一些实施例中，当满足一个或多个条件时，订单分配系统100中的一个或多个组件(如，服务器110、请求者终端130、提供者终端140等)可读取和/或修改与请求者、提供者和/或公知常识相关的信息。例如，在拼车服务结束后，服务器110可读取和/或修改一个或多个用户的信息。再例如，当从请求者终端130收到服务请求时，提供者终端140可访问与请求者相关的信息，但提供者终端不能修改请求者的相关信息。

在一些实施例中，订单分配系统100中一个或多个组件间信息的交换可通过请求一个服务的方式实现。该服务请求的对象可以是任何产品。在一些实施例中，该产品可以是有形产品或者无形产品。有形产品可包括食物、药品、商品、化学产品、电器、衣物、车、房屋、奢侈品等或其任意组合。无形产品可包括服务产品、金融产品、知识产品、互联网产品等中的一种或其任意组合。例如，该产品可以是用于电脑或移动手机中的任意软件和/或应用程序。该软件和/或应用程序可与社交、购物、运输、娱乐、学习、投资等或其任意组合相关。在一些实施例中，与运输相关的软件和/或应用程序可包括出行软件和/或应用软件、交通工具调度软件和/或应用程序、地图软件和/或应用程序。在交通工具调度软件和/或应用程序中，交通工具可包括马车、人力车(例如：自行车、三轮车等)、汽车(例如：出租车、公交车、专车等)、列车、地铁、船舶、航空器(例如：飞机、直升机、航天飞机、火箭、热气球等)等中的一种或以上任意组合。

图2所示为根据本申请一些实施例所示的订单分配系统的模块图。如图2所示，该订单分配系统可以包括获取模块210、估值模块220、匹配模块230、分配模块240、估值更新模块250和分配策略更新模块260。在一些实施例中，该获取模块210、估值模块220、匹配模块230、分配模块240、估值更新模块250和分配策略更新模块260可以包含在图1所示的处理设备112中。

获取模块210可以用于获取与订单分配过程相关的信息和/或数据。例如，获取模块210可以获取多个订单(如未出行订单)信息。例如，获取模块210可以获取多个待接单司机信息。又例如，获取模块210可以基于多个未出行订单信息和多个待接单司机信息，获取多个订单司机对。在一些实施例中，获取模块210可以用于获取历史订单数据。

估值模块220可以用于确定区域时空价值和订单司机对的匹配值。例如，估值模块220可以根据估值模型确定每个订单司机对的匹配值。又例如，估值模块220可以根据历史订单数据确定区域时空价值。

匹配模块230可以用于确定订单司机匹配对。例如，匹配模块230可以基于每个订单司机对的匹配值，根据优化匹配算法确定多个订单司机匹配对。在一些实施例中，匹配模块230可以基于二分图确定多个订单司机匹配对。

分配模块240可以用于订单分配。在一些实施例中，分配模块240可以根据多个订单司机匹配对将每个订单(如未出行订单)分配给对应的司机。

估值更新模块250可以用于更新估值模型。在一些实施例中，估值更新模块250可以根据历史订单数据更新估值模型。在一些实施例中，估值更新模块250可以根据区域时空价值更新估值模型。

分配策略更新模块260可以用于更新(或确定)订单分配策略。在一些实施例中，分配策略更新模块260可以根据更新的估值模型更新订单分配策略。

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

需要注意的是，以上对于订单分配系统及其模块的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。例如，在一些实施例中，获取模块210、估值模块220、匹配模块230、分配模块240、估值更新模块250和分配策略更新模块260可以是一个系统中的不同模块，也可以是一个模块实现上述的两个或两个以上模块的功能。例如，匹配模块230和分配模块240可以是两个模块，也可以是一个模块同时具有匹配和分配功能。例如，各个模块可以共用一个存储模块，各个模块也可以分别具有各自的存储模块。诸如此类的变形，均在本申请的保护范围之内。

图3所示为根据本申请一些实施例所示的订单分配策略的示例性流程图。如图3所示，该分配策略可以包括：

步骤310，基于多个未出行订单信息和多个待接单司机信息，获取多个订单司机对。具体的，步骤310可以由获取模块210执行。

在一些实施例中，该多个未出行订单可以由请求者终端130(例如乘客)发起，并通过网络120发送给服务器110(或网约车平台)。在一些实施例中，该多个未出行订单可以表示乘客发送了网约车服务请求，但并未获得司机分配的订单。在一些实施例中，该多个未出行订单可以是实时订单。例如，该多个未出行订单可以是在某一时刻或者在某一小段时间内(例如1秒、2秒、5秒、10秒等)订单分配系统100接收到的订单。在一些实施例中，该多个未出行订单可以是位于某一区域内的订单，例如，该多个订单的起点(如乘客上车的地点)可以在某一区域内。该区域可以包括某个城市、某个地区、某个街道或是某个预先设定的区域等。在一些实施例中，该区域可以是矩形、六边形等规则或不规则的形状，或者多个形状的组合。每个区域之间的大小可以相同也可以不同。在特定实施例中，每个区域的订单数量和/或司机数量可以大致相等。

在一些实施例中，每个订单(如未出行订单)的信息可以包括订单编号、订单的起始地点(如乘客上车的地点)、目的地(如乘客下车的地点)、订单预计行驶距离、订单发起时间(乘客发起订单的时间)、订单预计行驶时间、订单的价格(如预估价格)、发起订单的乘客信息(例如，乘客用户信息等)、订单出发时间等信息中的一种或任意几种的组合。对于实时订单，订单的发起时间即可以被认为是订单出发时间。在一些实施例中，当乘客输入起始地点和目的地后，向打车平台发送网约车请求之前，网约车平台可以根据起始地点和目的地向乘客发送该订单的预估价格。

在一些实施例中，该多个待接单司机可以是通过提供者终端140在该打车平台注册的，接受打车平台派遣用于提供服务的车辆的司机。在一些实施例中，待接单司机的车辆状态可以是实时空闲车辆、载有乘客但未满载的车辆等。在一些情况下，待接单司机的车辆状态还可以是预计空闲车辆(即该车辆当前非空闲，预计在一定时间之后会成为空闲状态)。在一些实施例中，该多个待接单司机可以是位于某一区域内的待接单司机，例如，该多个待接单司机的位置在某一区域内。该区域可以包括某个城市、某个地区、某个街道或是某个预先设定的区域等。该多个待接单司机的所在区域可以与该多个订单的所在区域相同。在一些实施例中，该多个待接单司机可以是与至少一个订单的距离小于某阈值(如3km，5km等)的司机。在一些实施例中，该多个待接单司机可以是与至少一个订单的预计接单时间小于某时间阈值(如5分钟，8分钟，10分钟等)的司机。

在一些实施例中，该多个待接单司机中的每个待接单司机的信息可以包括车辆(即司机)的当前位置、车辆的行程(例如，未完成订单的起始地和目的地等)、车辆的最大容量(例如，4座、7座等)、司机信息(例如，司机的姓名、性别、职业、驾龄、年龄、服务分等)、车辆信息(例如，车辆的型号、等级、车牌号等)等信息中的一种或任意几种的组合。其中，车辆的行程可以是该车辆正在行驶的路线，例如，该车辆正在送乘客A去往乘客A的目的地的路上。

在一些实施例中，基于该多个未出行订单信息和多个待接单司机信息，可以获得多个订单司机对。每个订单司机对表示该未出行订单有可能与该司机(待接单司机)匹配。在一些实施例中，该多个订单司机对可以包括每个未出行订单和每个待接单司机组成的订单司机对。例如，有10个未出行订单和10个待接单司机，则可以组成100个订单司机对。在一些替代性实施例中，该多个订单司机对的数量可以少于未出行订单数量和待接单司机数量的乘积。例如，根据某些限制条件，该多个未出行订单中部分订单只能被分配给该多个待接单司机中的部分司机。具体的，限制条件可以是距离限制(如限定乘客和司机之间的距离小于某阈值)、容量限制(如某车辆只能再乘坐2人)、车辆状态限制(如车辆目前是否载有乘客)等，或以上的任意组合。例如，有100个未出行订单和100个待接单司机，根据限制，平均每个未出行订单可以和10个待接单司机匹配，则可以组成1000个订单司机对。在一些实施例中，该多个未出行订单的数量和该多个司机的数量可以一致或不一致。

步骤320，根据估值模型确定每个订单司机对的匹配值。具体的，步骤320可以由估值模块220执行。

在一些实施例中，订单司机对的匹配值表示司机在完成此订单后可以获得的价值。在一些实施例中，每个订单司机对的匹配值可以包括订单固有价值、司机的接单成本以及订单长期价值。根据估值模型确定每个订单司机对的匹配值可以如公式(1)所示：

v(d,o)＝v(o)-p(d,o)+(v_d(finish)-v_d(start)) (1)

其中，v(d,o)表示订单司机对的匹配值；v(o)表示订单的固有价值；p(d,o)表示司机的接单成本；v_d(finish)-v_d(start)表示订单的长期价值，具体的，表示目的地的预估价值与起始地的预估价值之差；其中，v_d(·)为预估价值函数(具体的，可以是时空价值函数)，v_d(finish)表示司机在目的地时的预估价值(具体的，可以是指时空价值)，v_d(start)表示司机在起始地的预估价值(具体的，可以是指时空价值)。

在一些实施例中，该订单的固有价值可以为该订单的价格。该订单的价格可以根据乘客起始位置(订单出发地)、目的地、出发时间、预计到达时间、订单行驶里程、天气情况、交通情况、司机和订单(如未出行订单)的供需关系等一种或多种因素决定。在一些实施例中，该订单的固有价值还可以包括动态调价、行程补贴、乘客小费等一种或多种形式的组合。在一些实施例中，该动态调价可以根据不同情况进行相应调整。例如，若在某一时间段某个区域内的待接单司机数量少于订单数量，则可以根据待接单司机数量和订单数量的比例确定动态调价，并可以将该动态调价计入该订单的价格。在一些实施例中，可以根据具体情况确定行程补贴。例如，若该订单的起点在热区(即订单密度较大的地区)而目的地在比较偏僻的地区，司机在将乘客送达目的地后很可能需要空车返回，这种情况下，可以根据目的地的偏僻情况确定合适的行程补贴。在一些实施例中，乘客小费可以由乘客自行确定。例如，乘客可以通过请求者终端130支付小费，该小费可以被计入该订单的价格中。

在一些实施例中，司机的接单成本可以包括司机在接到乘客前所需花费的成本。例如，司机在接到订单后，需要行驶一段距离和/或等待一段时间才可以接到乘客，这段距离和/或时间即为司机的接单成本。在一些实施例中，司机的接单成本还可以包括司机在完成订单过程中，车辆的油耗成本、磨损成本等。具体的，司机的接单成本可以基于司机位置、乘客位置、订单时间、预计行驶距离、预计等待时间、交通状况、天气状况、车型、油价、耗油量等一种或多种因素确定。

在一些实施例中，订单的长期价值可以表示为目的地的预估价值(如时空价值)与起始地的预估价值(如时空价值)之差。其中，时空价值可以综合考虑某时刻在某区域接单的可能性、订单的可能金额，以及从该时刻的状态起，在后续一段时间可能获得的累计总收益等。在一些情况下，若司机所在位置是高订单需求区域(例如，市中心)，而订单目的地是低订单需求区域(例如，郊区)，则即使算上该订单的固有价值，该司机在未来一段时间(如一小时、几小时、一天等)的总收益也可能由于接了该订单而降低。在一些实施例中，订单的长期价值(如各区域的时空价值)可以基于历史订单数据确定。具体的，各区域的时空价值可以根据算法(如马尔可夫决策过程(Markov Decision Process，MDP))确定。关于区域时空价值的确定的具体细节，可以参见图5、图7及相应描述。

在一些替代性实施例中，订单的长期价值可以根据订单计费时长(如后续一段时间可能获得的累计计费时长)、计费里程(如后续一段时间可能获得的累计计费里程)等一种或多种的组合进行确定。在一些替代性实施例中，订单司机对的匹配值可以基于司机自身的价值(如司机长期留存收益)、乘客自身的价值(如乘客长期留存收益)以及司乘匹配价值(如司机回家的顺路程度)等一种或多种参数进行确定。

步骤330，基于每个订单司机对的匹配值，根据优化匹配算法确定多个订单司机匹配对。具体的，步骤330可以匹配模块230执行。

在一些实施例中，该优化匹配算法可以是二分图最优匹配算法。二分图最优匹配算法可以包括匈牙利算法、Kuhn-Munkres算法(KM算法)、Hopcroft-Karp算法等一种或多种的任意组合。

在一些实施例中，可以建立二分图，该二分图的两个顶点集分别对应多个订单(如未出行订单)和多个司机(如待接单司机)，二分图中的每条边分别对应一个订单司机对，每条边的权值即为该订单司机对匹配值。系统100(如匹配模块230)可以基于该二分图确定多个订单司机匹配对。例如，可以基于KM算法确定总匹配值最大的多个订单司机匹配对。其中，每个订单司机匹配对包括一个待分配订单和一个相匹配的司机。每个订单司机匹配对之间相互独立。

如图6所示为根据本申请一些实施例所示的示例性二分图示意图。如图6所示，该二分图的右侧顶点集对应多个订单(如未出行订单)，在本实施例中，包括3个订单，分别是订单1、订单2和订单3。该二分图的左侧顶点集对应多个司机，在本实施例中，包括5个司机，分别是司机A、司机B、司机C、司机D和司机E。在一些实施例中，每个司机和每个订单都可以组成一个订单司机对。例如，在本实施例中，5个司机和3个订单一共可以组成15个订单司机对(对应图中的15条边)。每个订单司机对的匹配值对应每条边的权值。例如，在本实施例中，每个订单司机对的匹配值分别是a1、a2、a3、b1、b2、b3、c1、c2、c3、d1、d2、d3、e1、e2和e3。二分图建立后，可以基于二分图最优匹配算法(如KM算法)确定总匹配值最大的三个订单司机对，分别对应3个订单(订单1、2、3)和3个司机(5个司机中的三个)。在一些实施例中，每个订单只可以被分配给一个司机，且每个司机只可以接一个订单。在一些替代性实施例中，一个司机可以接多个订单(如拼车订单)。

在一些实施例中，在根据上述订单分配策略(如步骤310、320和330)确定多个订单司机匹配对后，订单分配系统100(如分配模块240)可以根据该多个订单司机匹配将每个订单分配给对应的司机。例如，系统100可以将订单信息发送给对应的司机(如提供者终端140)，将司机信息发送给对应的乘客(如请求者终端130)。在一段时间内(如6小时、12小时、1天、3天、7天等)，该订单分配策略可以保持不变。在一些实施例中，可以每隔一个单位时间(如1秒、2秒、5秒、10秒、30秒、1分钟、3分钟等)执行一次订单分配策略，将该单位时间内产生的订单(或者加上之前未被分配的订单)根据策略进行分配。在一些实施例中，该单位时间的长度根据具体情况进行相应调整。例如，订单密度较大的区域的单位时间可以比订单密度较小的区域的单位时间更短。又例如，高峰期的单位时间可以比非高峰期的单位时间更短。

图4所示为根据本申请一些实施例所示的订单分配策略更新方法的示例性流程图。如图4所示，该订单分配策略更新方法可以包括：

步骤410，获取历史订单数据。具体的，该步骤410可以由获取模块210执行。

在一些实施例中，该历史订单可以包括在网约车平台上，曾经由某服务请求者(乘客)发出订单请求，并由某服务提供者(司机)完成的订单。该历史订单数据可以包括一个或多个历史订单相关的信息和/或特征。例如，历史订单数据可以包括历史订单编号、历史订单始发地、历史订单目的地、历史订单开始时间、历史订单结束时间、发起历史订单的乘客、完成历史订单的司机(包括司机信息、车辆信息等)、历史订单的类型、历史订单的固有价值、历史订单的接单成本等一种或多种的任意组合。

在一些实施例中，一旦某个订单完成，该订单即可以被视为历史订单。请求者终端130(如乘客)和提供者终端140(如司机)可以通过网络120将相关的历史订单数据传输到系统100的存储媒介(例如，数据库150)中。服务器110(例如，处理设备112、获取模块210)可以从该系统100的存储媒介中获得历史订单数据。

在一些实施例中，该历史订单数据可以包括过去一段时间(如6小时、12小时、1天、2天、3天、5天、7天、14天、1个月、3个月等等)的历史订单。在一些实施例中，该历史订单数据可以包括最近完成的一定数量(如10个、50个、100个、500个、1000个，1万个等)的历史订单。在一些实施例中，该历史订单可以为某一区域内的订单。例如，所有历史订单的起点可以在某一区域内；或者所有历史订单的终点可以在某一区域内；或者所有历史订单的轨迹均在某一区域内；或者所有历史订单的轨迹均有部分在某一区域内，等等。该区域可以包括某个城市、某个地区、某个街道或是某个预先设定的区域等。

在一些实施例中，可以在某时间段(如6小时、12小时、1天、2天、3天、5天、7天、14天、1个月、3个月等)基于某订单分配策略进行订单分配。其中，该订单分配策略可以是本申请涉及的任何一种订单分配策略。在一些情况下，该订单分配策略还可以是就近派单策略、随机派单策略、目标匹配派单策略等一种或多种的任意组合。在本实施例中，可以获取与该时间段相关(如在该时间段内发起和/或完成)的订单数据作为历史订单数据。例如，可以获取在该时间段内完成的所有订单数据作为历史订单数据。例如，可以获取在该时间段内发起的所有订单数据作为历史订单数据。在一些实施例中，可以获取该时间段内的部分订单数据作为历史订单数据。例如，可以获取该时间段内完成的最近1000个(或500个，5000个等)订单数据作为历史订单数据。

步骤420，根据历史订单数据更新估值模型。具体的，步骤420可以由估值更新模块250执行。

在一些实施例中，估值模型可以为：根据订单固有价值、司机的接单成本以及订单长期价值确定订单司机对的匹配值。订单长期价值可以由区域时空价值确定(具体可以参见步骤320及相应描述)。在本实施例中，根据历史订单数据更新估值模型可以包括：根据历史订单数据确定区域时空价值和根据区域时空价值更新估值模型两步骤。关于更新估值模型的更多细节可以参见图5及相应描述。

步骤430，根据更新的估值模型更新订单分配策略。具体的，步骤430可以由分配策略更新模块260执行。

在一些实施例中，估值模型可以根据历史订单数据进行更新。在如图3所示的订单分配策略中，每个订单司机对的匹配价值可以根据该估值模型获得。当估值模型更新时，根据估值模型获得的每个订单司机对的匹配价值相应更新，优化匹配算法将根据新的估值模型获得的每个订单司机对的匹配价值确定订单司机匹配对，由此该订单分配策略也获得更新。

在一些实施例中，可以定期(如1天、3天、7天、14天等)根据历史订单数据更新估值模型，从而更新订单分配策略。例如，可以根据第一订单分配策略在第1天进行订单分配；根据第1天产生的历史订单数据对估值模型进行更新，从而更新订单分配策略(如将第一订单分配策略更新为第二订单分配策略)；根据第二订单分配策略在第2天进行订单分配；再根据第2天产生的订单数据更新估值模型，获得第三订单分配策略(用于第3天的订单分配)，如此实现不断迭代更新。

图5所示为根据本申请一些实施例所示的估值模型更新方法的示例性流程图。如图5所示，该估值模型的更新方法可以包括：

步骤510，根据历史订单数据确定时空价值函数。具体的，该步骤510可以由估值模块220执行。

在一些实施例中，该历史订单可以包括在网约车平台上，曾经由某服务请求者(乘客)发出订单请求，并由某服务提供者(司机)完成的订单。关于获取历史订单数据的更多细节可以参见步骤410及相关描述。

在一些实施例中，区域时空价值可以根据马尔可夫决策过程(MDP)时空价值模型确定。该MDP时空价值模型可以定量地计算司机在某时刻到达某地点(后某区域)后，其一段时间(如2小时、3小时、6小时、12小时、1天、3天、7天等)内剩余时间能获得的预期价值。例如，MDP时空价值模型可以综合考虑某时刻在某区域接单的可能性、订单的可能金额，以及从该时刻的状态起，在后续一段时间可能获得的累计总收益等。

在一些实施例中，MDP时空价值模型可以将订单司机对的司机设为一个智能体(Agent)。每个订单司机对可以包括司机的时空状态(S)、司机的动作(A)、司机的收益(R)和司机的状态转移(P)。其中，司机可以通过执行相应的动作(如接单、空闲等)获得相应的收益，并由某一时空状态转移到另一时空状态。

在一些实施例中，司机的时空状态(S)可以表示司机所处的时间和空间。其中，司机所处的时间可以是时间点或时间段(例如，5分钟、10分钟、30分钟等)。司机所处的空间可以是在该时间点或时间段司机所在的位置或区域。例如，可以以10分钟为一个时间段，以1km*1km的矩形区域为一个空间。又例如，司机的时空状态(S)可以是：08:00-08:10，五道口区域。

在一些实施例中，司机的动作(A)可以表示司机在某时空状态下所做的行为。例如，司机的动作可以包括接收订单和空闲。在一些替代性实施例中，司机的动作还可以包括拒绝订单、正在执行订单、完成订单、下线、上线等一种或多种的组合。

在一些实施例中，司机的收益(R)可以表示司机动作所带来的相应收入。例如，司机的收益可以是完成订单之后获得的该订单的报酬(金额)。又例如，若司机在某段时间一直空闲，则该司机在该段时间的收益为0。在一些替代性实施例中，司机的收益还可以是订单数量(如完成订单量+1)，或者是订单报酬和订单数量的加权和。

在一些实施例中，司机的状态转移(P)可以表示司机从一个时空状态转移(如S)到另一个时空状态(如S’)。例如，当司机完成一个订单时，该司机的时空状态从接单时的时空状态(如出发时间、起始位置)转移到完单时的时空状态(如完单时间、目的地)。又例如，当司机在某段时间一直空闲时，该司机的时空状态中的空间状态可能并没有发生转移，而只有时间状态发生了转移。

在一些实施例中，可以将历史订单数据中司机的时空状态(S)、司机的动作(A)、司机的收益(R)和司机的状态转移(P)作为MDP时空价值模型的输入。MDP时空价值模型的输出可以是价值函数V(S)。该价值函数V(S)可以表示司机在S时空状态下的时空价值。该S时空状态下的时空价值可以表示从该时间状态开始到一段时间周期(例如，一天)结束的预期累积收益值。例如，可以定义一天的开始和结束均为凌晨04:00，即04:00-04:00(+1)的24个小时为一个时间周期(episode)，累计收益值即为司机在某时刻(例如18:20)后，直到下一个04:00(episode结束)为止的总累计收益。

在一些实施例中，时空价值可以根据增强学习(reinforcement learning)算法确定。增强学习算法可以包括时序差分(temporal-difference，TD)学习算法、动态规划(dynamic programming)算法、蒙特卡罗(Monte Carlo)学习算法、SARSA算法、Q-learning算法等其中的一种或多种的任意组合。以下以时序差分学习算法和动态规划算法为例描述确定时空价值的具体过程。

在一些实施例中，时序差分学习算法可以通过模拟(或者经历)一段序列中的每一步(或者几步)行动，根据其中获得的收益和新时空状态的价值，估计出执行前时空状态的价值。例如，可以将历史订单数据(例如，<S,A,R,P>)输入下式(2)中：

V(S_t)←V(S_t)+α[R_t+1+γV(S_t+1)-V(S_t)] (2)

其中，t表示执行动作的时刻，t+1表示t时刻的下一时刻，S_t表示执行该动作前的状态，R_t+1表示t+1时刻获得的收益，V(S_t)和V(S_t+1)分别表示S_t和S_t+1状态的时空价值，γ为衰减因子(一般取值在0和1之间)，α表示学习率(learning rate)。在一些实施例中，通过重复采样并执行式(2)至收敛即可获得所有经过状态S的价值函数V(S)。需要说明的是，以上公式(2)为仅考虑一步的时序差分学习算法的情况，也可以采用其他公式并利用多步确定时空价值。

在一些实施例中，式(2)的计算需要执行采样过程，即从历史订单数据中采样获得<S_t,A,S_t+1,R>的状态转移记录，并依此更新价值函数V(S)。为此，可以将订单和司机的相关记录转化为时序差分学习的输入格式。具体的方法可以为：

针对每一个订单，定义一条状态转移记录，其起始状态为司机响应订单时的时间、位置(经过量化处理，如10分钟、矩形格子粒度)，终点状态为司机完成订单时的时间和位置(同样经过量化)，收益为订单金额R。针对司机空闲的情况，可以每10分钟建立一个状态转移记录，起终点状态为司机位置和10分钟前后的两个时间点。例如，司机在8:00-8:20在位置A空闲，在8:23分接到订单，则会生成两条记录，记录1：从时间点8:00-8:10，A位置出发，到8:10-8:20，A位置结束，收益为0；记录2：从时间点8:10-8:20，A位置出发，到8:20-8:30，A位置结束，收益为0。

如图7所示为根据本申请一些实施例所示的状态转移示意图。如图7中上图所示，司机在T₀时刻位于位置X(如图中状态S₀，其中T可以表示10分钟的时间段，X可以表示1km*1km的矩形区域)，处于空闲状态，在T₁时刻同样位于位置X(如图中状态S₁)，则可以据此添加一条状态转移记录，即从状态S₀转移到状态S₁，经过一个时间段，位置未改动，收益(R)等于0。在此情况下，可以将该记录输入公式(2)，并根据下式(3)确定状态S₀的时空价值：

V(S₀)←V(S_t)+α[0+γV(S₁)-V(S₀)] (3)

其中，司机在t+1时刻获得的收益R_t+1为0。

如图7中下图所示，司机在T₀时刻位于位置X(如图中状态S₀)接到了订单，在T₂时刻位于位置Y(如图中状态S₂)完成了该订单，在此情况下，可以将相关记录输入公式(2)，并根据下式(4)确定状态S₀的时空价值：

V(S₀)←V(S₀)+α[R+γ³V(S₂)-V(S₀)] (4)

其中，司机在t+3时刻获得的收益为R，R可以为该订单的金额。

在一些实施例中，动态规划算法可以通过将多阶段过程转化为一系列单阶段问题，利用各阶段之间的关系，逐个求解，进而达到快速最优化目标的效果。在获取历史数据(如历史1-3个月的数据)的基础上，动态规划算法通过采样历史数据模拟状态转移概率，时间轴上从后向前依次推出每个时间点上所有空间位置的时空价值V(S)。具体公式可以如下式(5)所示：

V_k+1(S)＝E_π[R_t+1+γV_k(S_t+1)|S_t＝S] (5)

其中，k表示迭代轮数，t表示执行动作的时刻，t+1表示t时刻的下一时刻，S_t表示执行该动作前的状态，R_t+1表示t+1时刻获得的收益，V(S_t)和V(S_t+1)分别表示S_t和S_t+1状态的时空价值，γ为衰减因子，一般取值在0和1之间，E_π表示数学期望。其计算过程与上文中时序差分学习算法的计算过程类似，在此不再赘述。

步骤520，根据时空价值函数更新估值模型。具体的，该步骤520可以由估值更新模块250执行。

在一些实施例中，订单长期价值可以由区域时空价值确定。具体的，订单长期价值可以表示为v_d(finish)-v_d(start)，即司机在订单目的地的时空价值与起始地的时空价值之差。在本实施例中，基于订单历史数据可以确定(更新)区域时空价值(如目的地的时空价值、起始地的时空价值等)，根据区域时空价值可以更新订单的长期价值计算函数，从而更新估值模型。在一些实施例中，每隔一定周期(如1天、3天、1周等)便可以根据该周期内的历史订单数据重新确定区域时空价值，进而更新估值模型。进一步，根据更新的估值模型便可以更新相应的订单分配策略。

本申请实施例可能带来的有益效果包括但不限于：(1)定期根据不同区域的时空价值情况调整订单分配策略，使订单分配更加合理；(2)通过调整的订单分配策略，促进区域时空价值分布更加稳定(如使热区、冷区长期维持相似状态)；(3)提高乘客满意度；(4)提升司机效益，如使司机的长期效益更高；(5)提高网约车平台总体收益。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。

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

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

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

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

本申请各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、Visual Basic、Fortran 2003、Perl、COBOL 2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。

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

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

Claims

1.一种订单分配方法，其特征在于，包括：

基于订单分配策略确定多个订单司机匹配对；

根据所述多个订单司机匹配对进行订单分配；

其中，所述订单分配策略包括：

基于多个未出行订单信息和多个待接单司机信息，获取多个订单司机对；

根据估值模型确定每个订单司机对的匹配值，其中，所述订单司机对的匹配值表示司机在完成此订单后能获得的价值，每个订单司机对的匹配值包括订单固有价值、司机的接单成本以及订单长期价值；

所述订单长期价值为订单目的地的时空价值与起始地的时空价值之差，所述时空价值反映司机在到达某地点后在预设时间内能获得的预期价值，所述时空价值基于机器学习算法定量地计算获得；

基于所述每个订单司机对的匹配值，根据优化匹配算法确定总匹配值最大的所述多个订单司机匹配对。

2.如权利要求1所述的订单分配方法，其特征在于，所述多个订单司机对包括每个未出行订单和每个待接单司机组成的订单司机对。

3.如权利要求1所述的订单分配方法，其特征在于，所述根据估值模型确定每个订单司机对的匹配值包括：

获取区域时空价值；

根据所述区域时空价值确定每个订单司机对的匹配值。

4.如权利要求3所述的订单分配方法，其特征在于，所述获取区域时空价值包括：

基于马尔可夫决策过程时空价值模型确定区域时空价值。

5.如权利要求1所述的订单分配方法，其特征在于，所述优化匹配算法包括二分图最优匹配算法。

6.一种订单分配方法，其特征在于，包括：

基于订单分配策略进行订单分配，其中，所述订单分配策略的更新方法包括：

获取历史订单数据；

根据所述历史订单数据更新估值模型；

根据所述更新的估值模型更新订单分配策略；

其中，所述估值模型用于确定订单司机对的匹配值；其中，所述订单司机对的匹配值表示司机在完成此订单后能获得的价值，每个订单司机对的匹配值包括订单固有价值、司机的接单成本以及订单长期价值；所述订单长期价值为订单目的地的时空价值与起始地的时空价值之差，所述时空价值反映司机在到达某地点后在预设时间内能获得的预期价值，所述时空价值基于机器学习算法定量地计算获得。

7.如权利要求6所述的订单分配方法，其特征在于，所述获取历史订单数据包括：

在第一时间段基于订单分配策略进行订单分配；

获取与所述第一时间段相关的订单数据为所述历史订单数据。

8.如权利要求6所述的订单分配方法，其特征在于，所述根据所述历史订单数据更新估值模型包括：

根据所述历史订单数据确定时空价值函数；

根据所述时空价值函数更新所述估值模型。

9.一种订单分配系统，其特征在于，包括获取模块、估值模块、匹配模块和分配模块；

所述获取模块用于基于多个未出行订单信息和多个待接单司机信息，获取多个订单司机对；

所述估值模块用于根据估值模型确定每个订单司机对的匹配值；其中，所述订单司机对的匹配值表示司机在完成此订单后能获得的价值，每个订单司机对的匹配值包括订单固有价值、司机的接单成本以及订单长期价值；所述订单长期价值为订单目的地的时空价值与起始地的时空价值之差，所述时空价值反映司机在到达某地点后在预设时间内能获得的预期价值，所述时空价值基于机器学习算法定量地计算获得；

所述匹配模块用于基于所述每个订单司机对的匹配值，根据优化匹配算法确定总匹配值最大的多个订单司机匹配对；

所述分配模块用于根据所述多个订单司机匹配对进行订单分配。

10.如权利要求9所述的订单分配系统，其特征在于，所述多个订单司机对包括每个未出行订单和每个待接单司机组成的订单司机对。

11.如权利要求9所述的订单分配系统，其特征在于，所述估值模块进一步用于：

获取区域时空价值；

根据所述区域时空价值确定每个订单司机对的匹配值。

12.如权利要求11所述的订单分配系统，其特征在于，

所述估值模块还用于基于马尔可夫决策过程时空价值模型确定区域时空价值。

13.如权利要求9所述的订单分配系统，其特征在于，所述优化匹配算法包括二分图最优匹配算法。

14.一种订单分配系统，其特征在于，所述订单分配系统用于根据订单分配策略更新系统生成的订单分配策略进行订单分配，所述订单分配策略的更新系统包括获取模块、估值更新模块和分配策略更新模块；

所述获取模块用于获取历史订单数据；

所述估值更新模块用于根据所述历史订单数据更新估值模型；

所述分配策略更新模块用于根据所述更新的估值模型更新订单分配策略；

15.如权利要求14所述的订单分配系统，其特征在于，所述获取模块进一步用于获取与第一时间段相关的订单数据为所述历史订单数据；所述第一时间段为基于订单分配策略进行订单分配的一段时间。

16.如权利要求14所述的订单分配系统，其特征在于，所述估值更新模块进一步用于：

根据所述历史订单数据确定区域时空价值；

根据所述区域时空价值更新所述估值模型。

17.一种订单分配装置，包括处理器，其特征在于，所述处理器用于执行如权利要求1～5任一项所述的方法。

18.一种订单分配装置，包括处理器，其特征在于，所述处理器用于执行权利要求6～8中任一项所述的方法。

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

20.一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行如权利要求6～8任一项所述的订单分配方法。