一种更新订单处理模型的方法、装置、设备及存储介质与流程

1.本技术涉及互联网通信技术领域，尤其涉及一种更新订单处理模型的方法、装置、设备及存储介质。


背景技术：

2.随着互联网通信技术的发展，智能终端设备更加普及。移动互联网时代的到来，智能终端设备覆盖的用户数量越来越多，用户可以利用运行于智能终端设备上的应用体验用车服务，比如为用户提供由a地到b地的用车服务。
3.乘客可以利用乘客端发出用车订单，司机可以利用司机端响应该用车订单从而为乘客提供相应的用车服务。相关技术中，在用车出行场景中用车订单常常不能被及时有效的响应，因此仍然存在大量因司机端和乘客端无法进行有效匹配而导致的问题，比如乘客端发出的用车订单的等待响应时间长、待接单的候选司机端对应较长的到达起始点(对应用车订单)的距离等。因此，需要提供对用车订单更及时有效的响应方案。


技术实现要素：

4.为了解决现有技术应用在处理用车订单时，响应不及时等问题，本技术提供了一种更新订单处理模型的方法、装置、设备及存储介质：
5.一方面，本技术提供了一种更新订单处理模型的方法，其特征在于，所述方法包括：
6.响应于接收到的用车订单，确定所述用车订单指示的用车地理位置；
7.确定所述用车地理位置所属的地理位置区域；
8.获取车辆状态信息集；其中，所述车辆状态信息集由候选车辆集合中每个候选车辆对应的车辆状态信息构成，所述候选车辆集合为当前位于所述地理位置区域内的至少一个车辆；
9.以所述用车地理位置、所述车辆状态信息集以及所述地理位置区域对应的当前用车需求信息为输入，利用当前的订单处理模型确定对应的订单响应；其中，所述订单响应为生成针对目标车辆对应的客户端的派单请求，所述目标车辆是从所述候选车辆集合中确定的；
10.获取所述订单响应的反馈信息；
11.基于所述反馈信息，调整所述当前的订单处理模型的模型参数以更新所述当前的订单处理模型。
12.另一方面提供了一种更新订单处理模型的装置，其特征在于，所述装置包括：
13.位置确定模块：用于响应于接收到的用车订单，确定所述用车订单指示的用车地理位置；
14.区域确定模块：用于确定所述用车地理位置所属的地理位置区域；
15.信息获取模块：用于获取车辆状态信息集；其中，所述车辆状态信息集由候选车辆
集合中每个候选车辆对应的车辆状态信息构成，所述候选车辆集合为当前位于所述地理位置区域内的至少一个车辆；
16.响应确定模块：用于以所述用车地理位置、所述车辆状态信息集以及所述地理位置区域对应的当前用车需求信息为输入，利用当前的订单处理模型确定对应的订单响应；其中，所述订单响应为生成针对目标车辆对应的客户端的派单请求，所述目标车辆是从所述候选车辆集合中确定的；
17.反馈获取模块：用于获取所述订单响应的反馈信息；
18.模型更新模块：用于基于所述反馈信息，调整所述当前的订单处理模型的模型参数以更新所述当前的订单处理模型。
19.另一方面提供了一种电子设备，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如上述的更新订单处理模型的方法。
20.另一方面提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如上述的更新订单处理模型的方法。
21.本技术提供的一种更新订单处理模型的方法、装置、设备及存储介质，具有如下技术效果：
22.本技术通过确定用车订单指示的用车地理位置及其所属的地理位置区域，然后获取车辆状态信息集，再结合地理位置区域对应的当前用车需求信息并利用当前的订单处理模型确定对应的订单响应。其中，车辆状态信息集由候选车辆集合中每个候选车辆对应的车辆状态信息构成，候选车辆集合为当前位于地理位置区域内的至少一个车辆；订单响应为生成针对目标车辆对应的客户端的派单请求，目标车辆是从候选车辆集合中确定的。引入具有高泛化能力的订单处理模型，并将用车地理位置、车辆状态信息集以及地理位置区域对应的当前用车需求信息作为输入数据，可以提高确定订单响应的效率和有效性。同时，获取订单响应的反馈信息，从而基于反馈信息，调整当前的订单处理模型的模型参数以更新当前的订单处理模型。这样可以利用针对实时的用车订单的响应及反馈对订单处理模型进行实时更新，提高模型进行订单响应确定的准确性和适应性。
附图说明
23.为了更清楚地说明本技术实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。
24.图1是本技术实施例提供的一种应用环境的示意图；
25.图2是本技术实施例提供的一种更新订单处理模型的方法的流程示意图；
26.图3是本技术实施例提供的确定地理位置区域对应的当前用车需求信息的一种流程示意图；
27.图4是本技术实施例提供的针对用车出行的资源调度系统的组成框图；
28.图5、6是本技术实施例提供的两个智能体的在线学习示意图；
29.图7是本技术实施例提供的一种一种更新订单处理模型的装置的组成框图；
30.图8是本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
31.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
32.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
33.请参阅图1，图1是本发明实施例提供的一种应用环境的示意图，如图1所示，该应用环境中包括第一客户端110a、第一客户端对应的用户(比如司机)110b、第二客户端120a、第二客户端对应的用户(比如乘客)120b、网络130及服务端140。第一客户端110a、第二客户端120a通过网络130与服务端140通信连接。乘客可以利用第二客户端向服务器发送用车订单。服务器确定用车订单指示的用车地理位置及其所属的地理位置区域，然后获取候选车辆集合(当前位于地理位置区域内的至少一个车辆)中每个候选车辆对应的车辆状态信息，再结合地理位置区域对应的当前用车需求信息并利用当前的订单处理模型确定对应的订单响应。该订单响应为生成针对目标车辆对应的第一客户端的派单请求，其中目标车辆是从候选车辆集合中确定的。相应的，目标司机通过对应的第一客户端接收到派单请求。对于该派单请求，目标司机可以同意，也可以拒绝。服务器获取订单响应的反馈信息，从而基于反馈信息，调整当前的订单处理模型的模型参数以更新当前的订单处理模型。需要说明的是，图1仅仅是一种示例。
34.其中，第一客户端110a和第二客户端120a可以是智能手机、台式电脑、平板电脑、笔记本电脑、数字助理、智能可穿戴设备等实体设备，也可以是运行于实体设备中的软体，例如计算机程序。服务端140可以包括一个独立运行的服务器，或者分布式服务器，或者由多个服务器组成的服务器集群。服务器可以包括有网络通信单元、处理器和存储器等。
35.以下介绍本技术一种更新订单处理模型的方法的具体实施例，图2是本技术实施例提供的一种更新订单处理模型的方法的流程示意图，本技术提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图2所示，所述方法可以包括：
36.s201：响应于接收到的用车订单，确定所述用车订单指示的用车地理位置；
37.在本技术实施例中，乘客端发送用车订单至服务器，服务器接收该用车订单，服务器确定该用车订单指示的用车地理位置。该用车地理位置为起始点位置。该用车订单所携带的信息除了该用车地理位置，还可以有目的地位置、用车服务类型信息(比如乘用出行服务类型、代驾服务类型、运货服务类型等)、车型信息(比如豪华车型、普通车型)、偏好信息
(比如红绿灯少、不走高速等)等。在实际应用中，该用车地理位置可以是乘客端的实时定位坐标。
38.s202：确定所述用车地理位置所属的地理位置区域；
39.在本技术实施例中，服务器确定用车地理位置所属的地理位置区域。地理位置区域的维度可以是预设设置的，比如地级市维度、县级市维度等。示例性的，用车地理位置可以是乘客端的实时定位坐标，其所属的地理位置区域可以是其所属的城市：a市。
40.s203：获取车辆状态信息集；其中，所述车辆状态信息集由候选车辆集合中每个候选车辆对应的车辆状态信息构成，所述候选车辆集合为当前位于所述地理位置区域内的至少一个车辆；
41.在本技术实施例中，服务器获取车辆状态信息集，该车辆状态信息集由候选车辆集合中每个候选车辆对应的车辆状态信息构成，该候选车辆集合为当前位于地理位置区域内的至少一个车辆。可以理解，一个司机端对应一个车辆，司机端的当前地理位置也即对应车辆的当前地理位置。服务器根据各司机端的当前地理位置确定当前位于地理位置区域内的至少一个车辆，这里的“各司机端”可以是服务器为其提供后台服务的所有司机端，也可以是其中注册信息指示该地理位置区域的司机端。服务器根据当前地理位置从“各司机端”中确定出落入地理位置区域的候选司机端，也即确定出了候选车辆集合。这些候选车辆的车辆状态信息构成了车辆状态信息集，车辆状态信息用于描述对应车辆的当前状态，比如车辆状态信息包括以下至少一个：接单状态信息、当前地理位置、续航里程。该接单状态信息可以指示车辆(司机端)是否处于接单状态，该当前地理位置可以是车辆(司机端)的实时定位坐标。在实际应用中，候选车辆还需要满足未处于接单状态的条件。车辆状态信息集还包括地理位置区域内这些候选车辆的分布密度。该分布密度可以是服务器通过这些候选车辆的当前地理位置得到的。
42.s204：以所述用车地理位置、所述车辆状态信息集以及所述地理位置区域对应的当前用车需求信息为输入，利用当前的订单处理模型确定对应的订单响应；其中，所述订单响应为生成针对目标车辆对应的客户端的派单请求，所述目标车辆是从所述候选车辆集合中确定的；
43.在本技术实施例中，服务器将用车地理位置、车辆状态信息集以及地理位置区域对应的当前用车需求信息输入当前的订单处理模型，得到对应的订单响应。订单响应是针对前述用车订单的。订单响应可以是生成针对目标车辆对应的客户端(司机端)的派单请求，目标车辆是从候选车辆集合中确定的。订单响应也可以是为候选车辆集合中每个候选车辆确定对应的推荐位置，从而等待候选车辆对应的客户端(司机端)针对用车订单进行抢单。
44.下面将介绍地理位置区域对应的当前用车需求信息，如图3所述，可以通过下述步骤确定：
45.s301：获取用户状态信息集；其中，所述用户状态信息集由参考用户集合中每个参考用户对应的用户状态信息构成，所述参考用户集合为注册信息中地理位置属于所述地理位置区域内的至少一个用户对象，所述用户状态信息包括以下至少一个：在线状态信息、当前地理位置、历史打车习惯；
46.s302：获取所述地理位置区域对应的天气信息；
47.s303：以所述用户状态信息集、所述天气信息为输入，利用当前的用车需求预测模型确定所述地理位置区域对应的当前用车需求信息。
48.用于训练得到当前的用车需求预测模型的初始模型可以是一智能体(agent)。智能体可以是能够思想并与环境进行交互的实体。当前的用车需求预测模型可以是对智能体进行(深度)强化学习训练得到的，其中智能体以“试错”的方式进行学习，通过动作(action)与环境进行交互获得的奖励(reward)指导行为，目标是使智能体获得最大的奖励。智能体的输入为环境(environment)状态(state)，输出为动作。训练过程大致如下：通过智能体与环境进行多次交互，获得每次交互的动作、状态、奖励；将这多组(动作，状态，奖励)作为训练数据，对智能体进行一次训练。这里用到的当前的用车需求预测模型可以是经至少一次训练的智能体。
49.本次输入的状态为用户状态信息集合和地理位置区域对应的天气信息，输出的动作为地理位置区域对应的当前用车需求信息。本次输出的动作为地理位置区域对应的当前用车需求信息。在确定地理位置区域对应的当前用车需求信息时，本技术实施例用到了当前的用车需求预测模型，可以提高对于不同环境状态进行相关动作输出的适应能力，进而可以大大提高用车需求预测的可靠性和有效性。
50.该用户状态信息集由参考用户集合中每个参考用户对应的用户状态信息构成，该参考用户集合为注册信息中地理位置属于地理位置区域内的至少一个用户对象。可以理解，一个乘客端对应一个用户对象，司机端的注册信息也即对应用户对象的注册信息。服务器根据各乘客端的注册信息确定其中地理位置属于地理位置区域的至少一个用户对象，这里的“各乘客端”可以是服务器为其提供后台服务的所有乘客端。服务器根据注册信息中的地理位置从“各乘客端”中确定出落入地理位置区域的参考用户，也即确定出了参考用户集合。这些参考用户的用户状态信息构成了用户状态信息集，车辆状态信息用于描述对应用户的当前状态，比如用户状态信息包括以下至少一个：在线状态信息、当前地理位置、历史打车习惯。该在线状态信息可以指示用户(乘客端)是否处于在线状态，该当前地理位置可以是用户(乘客端)的实时定位坐标，该历史打车习惯可以是用户(乘客端)的历史打车偏好。地理位置区域对应的天气信息可以包括当前天气和未来天气。
51.在实际应用中，可以在地理位置区域的基础上进行子区域的设置。比如，作为地理位置区域的a市可以包括子区域a
‑
d。上述输入的状态中地理位置区域对应的天气信息，可以细化至每个参考用户的当前地理位置所属的子区域的天气信息。上述输出的动作也可以是每个子区域的当前用车需求信息，可以将各个子区域的当前用车需求信息一并作为地理位置区域对应的当前用车需求信息。此外，输入的状态还可以包括当天的日期特征，比如是否为节假日、是否为出行高峰期。
52.考虑到当前的用车需求预测模型所进行的强化学习训练，可以在利用其输出作为动作的地理位置区域对应的当前用车需求信息之后，关注该动作与环境进行的交互，从而继续优化模型以提高模型的预测能力。在一个可选的实施例中，可以获取所述地理位置区域对应的实际用车订单信息；然后基于所述实际用车订单信息，调整所述当前的用车需求预测模型的模型参数以更新所述当前的用车需求预测模型。可以将地理位置区域对应的实际用车订单信息作为奖励，从而利用本次的状态、动作、奖励继续训练智能体。
53.进一步的，所述获取所述地理位置区域对应的实际用车订单信息，包括下述步骤：
首先，获取第三加权系数和第四加权系数；然后，确定所述地理位置区域对应的实际用车订单数量和实际成单订单数量；再者，采用所述第三加权系数对所述实际用车订单数量进行加权处理得到第三加权结果，以及采用所述第四加权系数对所述实际成单订单数量进行加权处理得到第四加权结果；最后，将所述第四加权结果和所述第三加权结果相除得到所述实际用车订单信息。
54.地理位置区域对应的当前用车需求信息可以指示由参考用户集合发出的用车订单的理想数量，那么实际用车订单数量可以看作由参考用户集合实际发出的用车订单的数量，相应的，实际成单订单数量为上述实际发出的用车订单中与司机端建立关联关系的数量、被司机端承接的用车订单的数量。当然，相对于利用当前的用车需求预测模型确定地理位置区域对应的当前用车需求信息，地理位置区域对应的当前用车需求信息可以指示下一时刻发出的用车订单中起始点位置落入地理位置区域的理想数量，那么实际用车订单可以是下一时刻实际发出的用车订单中起始点位置落入地理位置区域的数量。利用对应的加权系数分别对实际用车订单数量和实际成单订单数量进行加权处理，从而将实际成单订单数量的加权结果和实际用车订单数量的加权结果相除得到实际用车订单信息。作为奖励的实际用车订单信息，为智能体捕捉好评价或者坏评价提供了参考，可以帮助当前的用车需求预测模型更好的通过真实数据实现有效学习。
55.s205：获取所述订单响应的反馈信息；
56.在本技术实施例中，服务器获取订单响应的反馈信息。
57.当订单响应是生成针对目标车辆对应的客户端(司机端)的派单请求时，订单响应的反馈信息为同意或者拒绝该派单请求。当订单响应是为候选车辆集合中每个候选车辆确定对应的推荐位置时，订单响应的反馈信息可以为是否存在候选车辆对应的客户端(司机端)针对用车订单抢单成功。当然，不论是上述哪种订单响应，订单响应的反馈信息都可以是目标(或者候选)车辆对应的客户端所同意的派单请求情况、所成功抢得的用车订单情况。需要说明的是，“所同意的派单请求”针对的用车订单不局限于前述步骤s201中的用车订单，“所成功抢得的用车订单”中的用车订单也不局限于前述步骤s201中的用车订单。
58.考虑到当前的订单处理模型所进行的强化学习训练，可以在利用其输出作为动作的订单响应之后，关注该动作与环境进行的交互，从而继续优化模型以提高模型的预测能力。在一个可选的实施例中，在所述获取针对所述订单响应的反馈信息之前，所述方法还包括：发送所述派单请求至所述目标车辆对应的客户端。相应的，确定所述目标车辆对应的客户端的实际接单信息，将所述实际接单信息作为所述反馈信息。实际接单信息指示目标车辆对应的客户端(司机端)所同意的派单请求、所成功抢得的用车订单。
59.进一步的，所述确定所述目标车辆对应的客户端的实际接单信息，包括下述步骤：首先，获取第一加权系数和第二加权系数；然后，确定所述目标车辆对应的客户端的实际接单数量以及实际接单费用；再者，采用所述第一加权系数对所述实际接单数量进行加权处理得到第一加权结果，以及采用所述第二加权系数对所述实际接单费用进行加权处理得到第二加权结果；最后，将所述第一加权结果和所述第二加权结果相加得到所述实际接单信息。
60.相对于利用当前的订单处理模型确定订单响应，实际接单数量可以是下一时刻目标车辆对应的客户端(司机端)实际同意的派单请求、实际成功抢得的用车订单的数量，实
际接单费用则是“实际同意的派单请求、实际成功抢得的用车订单”对应的费用。当然，这里的费用可以是完成用车订单前的预估费用。利用对应的加权系数分别对实际接单数量和实际接单费用进行加权处理，从而将实际接单数量的加权结果和实际接单费用的加权结果相加得到实际接单信息。作为反馈信息的实际接单信息，为后续智能体捕捉好评价或者坏评价提供了参考，可以帮助当前的订单处理模型更好的通过真实数据实现有效学习。
61.s206：基于所述反馈信息，调整所述当前的订单处理模型的模型参数以更新所述当前的订单处理模型。
62.在本技术实施例中，服务器基于反馈信息，调整当前的订单处理模型的模型参数以更新当前的订单处理模型。将反馈信息作为奖励，从而利用本次的状态、动作、奖励继续训练智能体。
63.在实际应用中，可以通过下述步骤执行针对用车出行的资源调度方案：1)获取用户状态信息集；其中，所述用户状态信息集由参考用户集合中每个参考用户对应的用户状态信息构成，所述参考用户集合为注册信息中地理位置属于所述地理位置区域内的至少一个用户对象，所述用户状态信息包括以下至少一个：在线状态信息、当前地理位置、当前地理位置所属的子区域的天气信息、历史打车习惯；2)以所述用户状态信息集为输入，利用当前的用车需求预测模型确定所述地理位置区域中每个子区域的当前用车需求信息；3)获取车辆状态信息集；其中，所述车辆状态信息集由候选车辆集合中每个候选车辆对应的车辆状态信息构成，所述候选车辆集合为当前位于所述地理位置区域内的至少一个车辆，所述车辆状态信息包括以下至少一个：接单状态信息、当前地理位置、续航里程；4)以所述车辆状态信息集以及所述地理位置区域中每个子区域的当前用车需求信息为输入，利用当前的订单处理模型确定针对每个候选车辆的推荐位置。
64.参见图4，本技术实施例可用于针对用车出行的资源调度系统，该系统主要包括执行下述步骤的相关模块：实时用户画像收集、用户特征提取、用户打车概率在线学习、用户打车预测特征提取、车辆特征提取、特征融合、调度策略在线学习、调度结果预测。本技术实施例涉及到的在线学习主要用到两个深度强化学习的智能体。第一个智能体主要通过从用户画像中获取的实时的用户状态去在线学习和预测城市各区块(子区域)间的用户打车平均期望特征。第二个智能体主要通过将第一个智能体预测的结果与从用户画像中获得的城市各区块的网约车状态特征融合，去在线学习和预测城市各区块内车辆的调度目的地(调度到最佳的城市区块)。下面将介绍相关模块涉及的内容：
65.1)用户画像，构建关于每个乘客用户和司机用户的埋点特征数据。另外，可以再附加所在城市各个区块(可以认为将城市版图进行区块划分)的天气数据、当天的日期特征(是否节假日、是否为出行高峰期)等，这些为后期智能体在线学习准备。
66.2)第一个智能体的在线学习，需要获取当前城市每个区块内全部乘客用户的实时特征作为输入的状态state_1，智能体需要预测的动作值为该区块内用户平均的打车数值期望activate_1，对应的奖励值reward_1由下一时刻该区块真实的用户预约订单数量reward_11和实际成单数量reward_12加权组成，这样形成了一个完整的在线深度强化学习系统，可以通过在线真实数据去学习实时的动作值，可参见图5。
67.3)第二个智能体的在线学习，需要的输入状态值state_2由当前城市每个区块内全部司机用户的状态state_21和第一个智能体预测的动作值activate_1联合构成，所预测
的动作值activate_2为司机应该前往的调度目的地(对应的城市区块)的序号，奖励值reward_2为下一时刻被调动司机产生的实际接单数reward_21和实际接单费用reward_22的加权和。如此可以通过第二个智能体完成在线深度强化学习系统，可以通过在线真实数据去学习实时的动作值，可参见图6。
68.其中，可替换的部分主要为数据特征可以是来自于互联网的埋点数据，也可以来自整个城市的当前用户和司机的图像分布特征，训练网络可以是bp神经网络也可以是深度神经网络(可以处理图像特征)。
69.由此可以对城市内营运车辆资源进行合理且智能的实时调度，本技术实施例基于打车市场和用户市场的复杂性而提供了一基于智能体深度强化学习的智能资源调度方案。通过对当前的营运车辆在某个城市中的分布状态和用户需求分布位置等状态进行在线学习和实时调度，从而给当前未接单的营运车辆提供建议，促使车辆资源的分布更符合用户对车辆资源的需求预期，达到理想的资源调度。解决了“如何对未来一个时刻状态下乘客需求分布进行预判”以及“如何合理的给每个未接单的车辆资源安排调度的目标区域”的问题。相较于相关技术，具有下述优势1)针对的场景更加复杂，针对的场景不是单纯的一个用户，而是城市内全部未接单的营运车辆；2)使用的是两个智能体的深度强化学习算法，更适合应对复杂场景下多种不确定那个因素的的模拟和预测；3)应用在线学习的强化学习方法，预测结果更贴近真实的用车场景。
70.由以上本技术实施例提供的技术方案可见，本技术实施例通过确定用车订单指示的用车地理位置及其所属的地理位置区域，然后获取车辆状态信息集，再结合地理位置区域对应的当前用车需求信息并利用当前的订单处理模型确定对应的订单响应。其中，车辆状态信息集由候选车辆集合中每个候选车辆对应的车辆状态信息构成，候选车辆集合为当前位于地理位置区域内的至少一个车辆；订单响应为生成针对目标车辆对应的客户端的派单请求，目标车辆是从候选车辆集合中确定的。引入具有高泛化能力的订单处理模型，并将用车地理位置、车辆状态信息集以及地理位置区域对应的当前用车需求信息作为输入数据，可以提高确定订单响应的效率和有效性。同时，获取订单响应的反馈信息，从而基于反馈信息，调整当前的订单处理模型的模型参数以更新当前的订单处理模型。这样可以利用针对实时的用车订单的响应及反馈对订单处理模型进行实时更新，提高模型进行订单响应确定的准确性和适应性。
71.本技术实施例还提供了一种更新订单处理模型的装置，如图7所示，所述装置包括：
72.位置确定模块701：用于响应于接收到的用车订单，确定所述用车订单指示的用车地理位置；
73.区域确定模块702：用于确定所述用车地理位置所属的地理位置区域；
74.信息获取模块703：用于获取车辆状态信息集；其中，所述车辆状态信息集由候选车辆集合中每个候选车辆对应的车辆状态信息构成，所述候选车辆集合为当前位于所述地理位置区域内的至少一个车辆；
75.响应确定模块704：用于以所述用车地理位置、所述车辆状态信息集以及所述地理位置区域对应的当前用车需求信息为输入，利用当前的订单处理模型确定对应的订单响应；其中，所述订单响应为生成针对目标车辆对应的客户端的派单请求，所述目标车辆是从
所述候选车辆集合中确定的；
76.反馈获取模块705：用于获取所述订单响应的反馈信息；
77.模型更新模块706：用于基于所述反馈信息，调整所述当前的订单处理模型的模型参数以更新所述当前的订单处理模型。
78.需要说明的，所述装置实施例中的装置与方法实施例基于同样的发明构思。
79.本技术实施例提供了一种电子设备，该电子设备包括处理器和存储器，该存储器中存储有至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现如上述方法实施例所提供的更新订单处理模型的方法。
80.进一步地，图8示出了一种用于实现本技术实施例所提供的更新订单处理模型的方法的电子设备的硬件结构示意图，所述电子设备可以参与构成或包含本技术实施例所提供的更新订单处理模型的装置。如图8所示，电子设备80可以包括一个或多个(图中采用802a、802b，
……
，802n来示出)处理器802(处理器802可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器804、以及用于通信功能的传输装置806。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图8所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，电子设备80还可包括比图8中所示更多或者更少的组件，或者具有与图8所示不同的配置。
81.应当注意到的是上述一个或多个处理器802和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到电子设备80(或移动设备)中的其他元件中的任意一个内。如本技术实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
82.存储器804可用于存储应用软件的软件程序以及模块，如本技术实施例中所述的方法对应的程序指令/数据存储装置，处理器802通过运行存储在存储器84内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种更新订单处理模型的方法。存储器804可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器804可进一步包括相对于处理器802远程设置的存储器，这些远程存储器可以通过网络连接至电子设备80。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
83.传输装置806用于经由一个网络接收或者发送数据。上述的网络具体实例可包括电子设备80的通信供应商提供的无线网络。在一个实例中，传输装置806包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实施例中，传输装置806可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。
84.显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与电子设备80(或移动设备)的用户界面进行交互。
85.本技术的实施例还提供了一种存储介质，所述存储介质可设置于电子设备之中以保存用于实现方法实施例中一种更新订单处理模型的方法相关的至少一条指令或至少一
段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述方法实施例提供的更新订单处理模型的方法。
86.可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
87.需要说明的是：上述本技术实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本技术特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
88.本技术中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和电子设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
89.本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
90.以上所述仅为本技术的较佳实施例，并不用以限制本技术，凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。