本申请涉及计算机信息技术领域，具体而言，涉及一种信息处理方法及装置。
背景技术：
随着互联网和移动终端的发展，人们能够通过移动终端和互联网来完成各自的出行，方便了人们的出行。
由于人们生活环境、职业以及习惯等方面的不同，每个人都有各自的打车需求。现有技术中，在用户存在出行需求时，会临时进行服务资源调度，为用户提供出行服务。在这种情况下，由于无法预先预测用户的出行需求，经常导致对于某些订单类型，服务资源不够分配，导致用户无法出行或出行不便利的问题。
技术实现要素：
有鉴于此，本申请实施例的目的在于提供一种信息处理方法及装置，能够确定用户端在至少一种服务订单属性下发起服务订单的偏好信息，可以为用户端提前合理配置服务资源，提高服务效率。。
第一方面，本申请实施例提供的一种信息处理方法，包括：
获取用户端在预设历史时间段内的历史服务订单信息；
根据所述历史服务订单信息，确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量；
根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一种实施方式中，所述历史服务订单为出行订单，所述服务订单属性用于表征出行订单对应的出行距离。
在一种实施方式中，所述根据所述历史服务订单信息，确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量，包括：
根据所述历史服务订单信息，确定所述用户端在多个预设时间区间中的每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量；
所述根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息，包括：
根据在每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量，确定在该预设时间区间内，每种服务订单属性对应的服务订单占比；
根据所述多个预设时间区间的数量，以及在每个预设时间区间内，每种服务订单属性对应的服务订单占比，确定每种服务订单属性在各预设时间区间的服务订单平均占比；
根据每种服务订单属性在各预设时间区间的服务订单平均占比、在每个预设时间区间内，每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在每个预设时间区间内每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一种实施方式中，任一种服务订单属性在各预设时间区间的服务订单平均占比score满足下述公式：
其中，pctt表示在第t个预设时间区间内，任一种服务订单属性对应的服务订单占比，t表示预设时间区间的数量。
在一种实施方式中，所述根据每种服务订单属性在各预设时间区间的服务订单平均占比、在每个预设时间区间内，每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在每个预设时间区间内每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息，包括：
根据所述多个预设时间区间的数量、以及在每个预设时间区间内每种服务订单属性对应的服务订单数量，确定在每种服务订单属性下发起服务订单的偏好稳定性；
根据在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在所述每个预设时间区间内，每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一种实施方式中，在任一种服务订单属性下发起服务订单的偏好稳定性score稳满足下述公式：
其中，cntt表示第t个预设时间区间内，每种服务订单属性对应的服务订单数量，t表示预设时间区间的数量。
在一种实施方式中，所述确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息，包括：
根据每种服务订单属性对应的服务订单占比、所述用户端发起的服务订单所覆盖的时间区间的数量、所述多个预设时间区间的数量，确定所述用户端在该服务订单属性下发起服务订单的服务订单频次；
根据所述在该服务订单属性下发起服务订单的服务订单频次、所述在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一种实施方式中，所述在任一服务订单属性下发起服务订单的服务订单频次score频次满足下述公式：
其中，talive表示用户端发起的服务订单所覆盖的时间区间的数量，pctt表示第t个预设时间区间内，每种服务订单属性对应的服务订单占比，1if(pctt>0.65)else0)表示当第t个预设时间区间内，每种服务订单属性对应的服务订单占比大于预设阈值时则取值为1，否则取值为0，t表示预设时间区间的数量。
在一种实施方式中，所述偏好信息包括偏好度，所述用户端在任一种服务订单属性下发起服务订单的偏好度y满足下述公式：
y＝score×score稳×score频次；
其中，score表示任一种服务订单属性在各预设时间区间的服务订单平均占比，score稳表示在任一种服务订单属性下发起服务订单的偏好稳定性，score频次表示在该服务订单属性下发起服务订单的服务订单频次。
在一种实施方式中，所述根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息，包括：
针对任一种服务订单属性，根据所述每个预设时间区间内该服务订单属性对应的服务订单数量，构建该服务订单属性下发起的服务订单的服务订单特征向量；
将所述服务订单特征向量输入至预先训练的偏好信息检测模型中，确定所述用户端在所述任一种服务属性下发起服务订单的偏好信息。
在一种实施方式中，通过下述方式训练得到所述偏好信息检测模型：
获取多个样本用户端中每个样本用户端在多个预设时间区间中的每个预设时间区间内，分别在不同服务属性下发起的服务订单数量，以及该样本用户端对应的实际偏好信息；
根据该样本用户端在多个预设时间区间中的每个预设时间区间内，在不同服务属性下发起的服务订单数量，构建该样本用户端的特征向量；将所述特征向量输入至基础检测模型中，获得该样本用户端的偏好信息检测结果；
根据所述偏好信息检测结果以及所述实际偏好信息，对所述基础检测模型进行训练，得到所述偏好信息检测模型。
在一种实施方式中，所述根据所述偏好信息检测结果以及所述实际偏好信息，对所述基础检测模型进行训练，得到所述偏好信息检测模型包括：
根据各个样本用户端的偏好信息检测结果，以及对应的实际偏好信息，对所述基础检测模型进行一轮训练后，调整所述基础检测模型的训练参数并进入下一轮训练，将经过多轮训练后的基础检测模型确定为所述偏好信息检测模型。
在一种实施方式中，采用下述步骤对所述基础检测模型进行每一轮训练：
将本轮还未完成训练的样本用户端中的任意一个样本用户端确定为目标样本用户端，根据该目标样本用户端的偏好信息检测结果，以及对应的实际偏好信息，确定所述目标样本用户端在本轮的交叉熵损失；
根据所述目标样本用户端在本轮的交叉熵损失，调整所述基础检测模型的训练参数；
将所述目标样本用户端作为本轮完成训练的样本用户端，并将本轮还未完成训练的样本用户端中任意一个样本用户端确定为新的目标样本用户；
使用调整了参数后的所述基础检测模型，获取该新的目标样本用户端的偏好信息检测结果，并重新返回根据该目标样本用户的偏好信息检测结果，以及对应的实际偏好信息，确定所述目标样本用户端本轮的交叉熵损失的步骤；
直至所有样本用户端都完成本轮的训练，完成对所述基础检测模型的本轮训练。
第二方面，本申请实施例提供的一种信息处理装置，包括：
获取模块，用于获取用户端在预设历史时间段内的历史服务订单信息；
数量确定模块，用于根据所述历史服务订单信息，确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量；
信息确定模块，用于根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一种实施方式中，所述历史服务订单为出行订单，所述服务订单属性用于表征出行订单对应的出行距离。
在一种实施方式中，所述数量确定模块，用于采用下述方式确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量：
根据所述历史服务订单信息，确定所述用户端在多个预设时间区间中的每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量；
所述信息确定模块，用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
根据在每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量，确定在该预设时间区间内，每种服务订单属性对应的服务订单占比；
根据所述多个预设时间区间的数量，以及在每个预设时间区间内，每种服务订单属性对应的服务订单占比，确定每种服务订单属性在各预设时间区间的服务订单平均占比；
根据每种服务订单属性在各预设时间区间的服务订单平均占比、在每个预设时间区间内，每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在每个预设时间区间内每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一种实施方式中，任一种服务订单属性在各预设时间区间的服务订单平均占比score满足下述公式：
其中，pctt表示在第t个预设时间区间内，任一种服务订单属性对应的服务订单占比，t表示预设时间区间的数量。
在一种实施方式中，所述信息确定模块，具体用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
根据所述多个预设时间区间的数量、以及在每个预设时间区间内每种服务订单属性对应的服务订单数量，确定在每种服务订单属性下发起服务订单的偏好稳定性；
根据在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在所述每个预设时间区间内，每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一种实施方式中，在任一种服务订单属性下发起服务订单的偏好稳定性score稳满足下述公式：
其中，cntt表示第t个预设时间区间内，每种服务订单属性对应的服务订单数量，t表示预设时间区间的数量。
在一种实施方式中，所述信息确定模块，具体用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
根据每种服务订单属性对应的服务订单占比、所述用户端发起的服务订单所覆盖的时间区间的数量、所述多个预设时间区间的数量，确定所述用户端在该服务订单属性下发起服务订单的服务订单频次；
根据所述在该服务订单属性下发起服务订单的服务订单频次、所述在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一种实施方式中，所述在任一服务订单属性下发起服务订单的服务订单频次score频次满足下述公式：
其中，talive表示用户端发起的服务订单所覆盖的时间区间的数量，pctt表示第t个预设时间区间内，每种服务订单属性对应的服务订单占比，1if(pctt>0.65)else0)表示当第t个预设时间区间内，每种服务订单属性对应的服务订单占比大于预设阈值时则取值为1，否则取值为0，t表示预设时间区间的数量。
在一种实施方式中，所述偏好信息包括偏好度，所述用户端在任一种服务订单属性下发起服务订单的偏好度y满足下述公式：
y＝score×score稳×score频次；
其中，score表示任一种服务订单属性在各预设时间区间的服务订单平均占比，score稳表示在任一种服务订单属性下发起服务订单的偏好稳定性，score频次表示所述在任一服务订单属性下发起服务订单的服务订单频次。
在一种实施方式中，所述信息取定模块，还用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
针对任一种服务订单属性，根据所述每个预设时间区间内该服务订单属性对应的服务订单数量，构建该服务订单属性下发起的服务订单的服务订单特征向量；
将所述服务订单特征向量输入至预先训练的偏好信息检测模型中，确定所述用户端在所述任一种服务属性下发起服务订单的偏好信息。
在一种实施方式中，所述装置还包括训练模块；
所述训练模块，用于通过下述方式训练得到所述偏好信息检测模型：
获取多个样本用户端中每个样本用户端在多个预设时间区间中的每个预设时间区间内，分别在不同服务属性下发起的服务订单数量，以及该样本用户端对应的实际偏好信息；
根据该样本用户端在多个预设时间区间中的每个预设时间区间内，在不同服务属性下发起的服务订单数量，构建该样本用户端的特征向量；将所述特征向量输入至基础检测模型中，获得该样本用户端的偏好信息检测结果；
根据所述偏好信息检测结果以及所述实际偏好信息，对所述基础检测模型进行训练，得到所述偏好信息检测模型。
在一种实施方式中，所述训练模块，具体用于采用下述方式对所述基础检测模型进行训练：
根据各个样本用户端的偏好信息检测结果，以及对应的实际偏好信息，对所述基础检测模型进行一轮训练后，调整所述基础检测模型的训练参数并进入下一轮训练，将经过多轮训练后的基础检测模型确定为所述偏好信息检测模型。
在一种实施方式中，所述训练模块，具体用于采用下述步骤对所述基础检测模型进行每一轮训练：
将本轮还未完成训练的样本用户端中的任意一个样本用户端确定为目标样本用户端，根据该目标样本用户端的偏好信息检测结果，以及对应的实际偏好信息，确定所述目标样本用户端在本轮的交叉熵损失；
根据所述目标样本用户端在本轮的交叉熵损失，调整所述基础检测模型的训练参数；
将所述目标样本用户端作为本轮完成训练的样本用户端，并将本轮还未完成训练的样本用户端中任意一个样本用户端确定为新的目标样本用户；
使用调整了参数后的所述基础检测模型，获取该新的目标样本用户端的偏好信息检测结果，并重新返回根据该目标样本用户的偏好信息检测结果，以及对应的实际偏好信息，确定所述目标样本用户端本轮的交叉熵损失的步骤；
直至所有样本用户端都完成本轮的训练，完成对所述基础检测模型的本轮训练。
第三方面，本申请实施例提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行第一方面，或第一方面任一可能的实施方式中所述的信息处理方法的步骤。
第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行第一方面，或第一方面任一可能的实施方式中所述的信息处理方法的步骤。
本申请实施例提供的一种信息处理方法及装置中，首先获取用户端在预设历史时间段内的历史服务订单信息，然后根据获取的历史服务订单信息，能够得到用户端在预设历史时间段内，发起的服务订单属性以及服务订单数量，根据服务订单属性以及服务订单数量，得到用户端在至少一种服务订单属性下发起服务订单的偏好信息。基于该偏好信息，可以优化资源配置，提高服务效率。比如通过预先预测出的用户针对特定服务订单类型的出行需求，可以为用户端提前合理配置服务资源(比如车辆)，提高服务效率。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例所提供的一种应用场景的系统100结构图；
图2示出了本申请实施例所提供的一种信息处理方法的流程图；
图3示出了本申请实施例所提供的信息处理方法中，一种确定用户端在至少一种服务订单属性下发起服务订单的偏好信息具体方法的流程图；
图4示出了本申请实施例所提供的信息处理方法中，另一种确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息的具体方法的流程图；
图5示出了本申请实施例所提供的信息处理方法中，训练偏好信息检测模型的具体方法的流程图；
图6示出了本申请实施例所提供的一种信息处理装置的结构示意图；
图7示出了本申请实施例所提供的一种电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。
另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请实施例下述方法或装置可以应用于任何需要生成偏好信息的场景，比如，可以应用于手机应用软件、网页设计平台等。本申请实施例并不对具体的应用场景作限制，任何使用本申请实施例提供的方法生成偏好信息的方案均在本申请保护范围内。
需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。
本申请中的术语“用户端”可以指代请求服务、订购服务、提供服务或促成服务的提供的个人、实体或工具。例如，用户端可以是乘客、驾驶员、操作员等，或其任意组合。
本申请中的术语“服务订单”和“服务请求”可互换使用，以指代由乘客、服务请求方、司机、服务提供方、或供应商等、或其任意组合发起的订单。接受该“服务订单”或“请求”的可以是乘客、服务请求方、司机、服务提供方、或供应商等、或其任意组合。服务订单可以是收费的或免费的。
本申请实施例中，首先获取用户端在预设历史时间段内的历史服务订单信息，然后根据获取的历史服务订单信息，能够得到用户端在预设历史时间段内，发起的服务订单属性以及服务订单数量，根据该服务订单属性以及服务订单数量，得到用户端在至少一种服务订单属性下发起服务订单的偏好信息，这样，一方面，在为用户提供一些出行服务的优惠资源信息时，可以根据预测的用户对于特定服务订单属性(比如长距离订单)的偏好信息，有针对性地为用户提供优惠资源，有效、合理利用资源；另一方面，通过预先预测出的用户针对特定服务订单类型的出行需求，可以为用户端提前合理配置服务资源(比如车辆)，提高服务效率。
图1是本申请实施例的一种应用场景的系统100结构图。例如，系统100可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。系统100可以包括服务器110、网络120、用户端130和数据库140中的一种或多种，服务器110中可以包括执行指令操作的处理器。
在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式系统)。在一些实施例中，服务器110相对于终端，可以是本地的、也可以是远程的。例如，服务器110可以经由网络120访问存储在用户端130、或数据库140、或其任意组合中的信息和/或数据。作为另一示例，服务器110可以直接连接到用户端130和数据库140中至少一个，以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实现；仅作为示例，云平台可以包括私有云、公有云、混合云、社区云(communitycloud)、分布式云、跨云(inter-cloud)、多云(multi-cloud)等，或者它们的任意组合。在一些实施例中，服务器110可以在具有一个或多个组件的电子设备上实现。
在一些实施例中，处理器可以包括一个或多个处理核(例如，单核处理器或多核处理器)。仅作为举例，处理器可以包括中央处理单元(centralprocessingunit，cpu)、专用集成电路(applicationspecificintegratedcircuit，asic)、专用指令集处理器(applicationspecificinstruction-setprocessor，asip)、图形处理单元(graphicsprocessingunit,gpu)、物理处理单元(physicsprocessingunit，ppu)、数字信号处理器(digitalsignalprocessor，dsp)、现场可编程门阵列(fieldprogrammablegatearray，fpga)、可编程逻辑器件(programmablelogicdevice，pld)、控制器、微控制器单元、简化指令集计算机(reducedinstructionsetcomputing，risc)、或微处理器等，或其任意组合。
网络120可以用于信息和/或数据的交换。在一些实施例中，系统100中的一个或多个组件(例如，服务器110，用户端130和数据库140)可以向其他组件发送信息和/或数据。例如，服务器110可以经由网络120从用户端130获取服务请求。在一些实施例中，网络120可以是任何类型的有线或者无线网络，或者是他们的结合。在一些实施例中，用户端130的用户可以是除服务实际需求者之外的其他人。例如，用户端130的用户a可以使用用户端130来为服务实际需求者b发起服务请求(比如，用户a可以为自己的朋友b叫车)，或者从服务器110接收服务信息或指令等。
在一些实施例中，用户端130可以包括移动设备、平板计算机、膝上型计算机、或机动车辆中的内置设备等，或其任意组合。在一些实施例中，移动设备可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器设备的控制设备、智能监控设备、智能电视、智能摄像机、或对讲机等，或其任意组合。在一些实施例中，可穿戴设备可包括智能手环、智能鞋带、智能玻璃、智能头盔、智能手表、智能服装、智能背包、智能配件等、或其任何组合。在一些实施例中，智能移动设备可以包括智能手机、个人数字助理(personaldigitalassistant，pda)、游戏设备、导航设备、或销售点(pointofsale，pos)设备等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实玻璃、虚拟现实贴片、增强现实头盔、增强现实玻璃、或增强现实贴片等，或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括各种虚拟现实产品等。在一些实施例中，机动车辆中的内置设备可以包括车载计算机、车载电视等。在一些实施例中，用户端130可以是具有用于定位服务请求方和/或用户端的位置的定位技术的设备。
数据库140可以存储数据和/或指令。在一些实施例中，数据库140可以存储从用户端130和/或获得的数据。在一些实施例中，数据库140可以存储在本申请中描述的示例性方法的数据和/或指令。在一些实施例中，数据库140可以包括大容量存储器、可移动存储器、易失性读写存储器、或只读存储器(read-onlymemory，rom)等，或其任意组合。作为举例，大容量存储器可以包括磁盘、光盘、固态驱动器等；可移动存储器可包括闪存驱动器、软盘、光盘、存储卡、zip磁盘、磁带等；易失性读写存储器可以包括随机存取存储器(randomaccessmemory，ram)；ram可以包括动态ram(dynamicrandomaccessmemory，dram)，双倍数据速率同步动态ram(doubledate-ratesynchronousram，ddrsdram)；静态ram(staticrandom-accessmemory，sram)，晶闸管ram(thyristor-basedrandomaccessmemory，t-ram)和零电容器ram(zero-ram)等。作为举例，rom可以包括掩模rom(maskread-onlymemory，mrom)、可编程rom(programmableread-onlymemory，prom)、可擦除可编程rom(programmableerasableread-onlymemory，perom)、电可擦除可编程rom(electricallyerasableprogrammablereadonlymemory，eeprom)、光盘rom(cd-rom)、以及数字通用磁盘rom等。在一些实施例中，数据库140可以在云平台上实现。仅作为示例，云平台可以包括私有云、公有云、混合云、社区云、分布式云、跨云、多云或者其它类似的等，或其任意组合。
在一些实施例中，数据库140可以连接到网络120以与系统100(例如，服务器110，用户端130等)中的一个或多个组件通信。系统100中的一个或多个组件可以经由网络120访问存储在数据库140中的数据或指令。在一些实施例中，数据库140可以直接连接到系统100中的一个或多个组件(例如，服务器110，用户端130等)；或者，在一些实施例中，数据库140也可以是服务器110的一部分。
在一些实施例中，系统100中的一个或多个组件(例如，服务器110，用户端130，等)可以具有访问数据库140的权限。
下述实施例将会对信息处理过程作详细说明。下述信息处理方法可以应用于上述服务器110中实施，具体可以由服务器110中的处理器执行相关方法指令。
参见图2所示，为本申请实施例提供的一种信息处理方法的基本流程，包括：
s201：获取用户端在预设历史时间段内的历史服务订单信息。
在具体实施的时候，预设历史时间段可以是从历史某个时间点开始到获取用户端的历史服务订单信息的时刻的时间长度，例如，在2018年3月9日需要获取用户端的历史服务订单信息，预设历史时间段为一年，则获取的历史服务订单信息是从2017年3月9日至2018年3月9日；预设历史时间段也可以是以任何时间为起点或终点的时间长度，例如，预设历史时间段为一年，在2018年3月9日需要获取用户端的历史服务订单信息，获取的历史服务订单信息是从2017年1月9日至2018年1月9日。
在一些实施例中，服务器可以在数据库中获取用户端在预设历史时间段内的历史服务订单信息，例如，将用户端每次发起服务订单的数据作为历史服务订单信息保存至数据库中，当服务器需要获取用户端的历史服务订单信息的时候，可以从数据库中调取历史服务订单信息。历史服务订单信息可以包括服务订单内容、用户信息、发起服务订单的时间、订单对应的服务时间等，例如，服务订单为出行订单，则历史服务订单信息可以包括出行时间、出行地点、出行距离等，出行地点可以包括出行起点和出行终点。
在这里，获取用户端的历史服务订单信息时，可以基于该用户端登录的用户账号，获取对应的历史服务订单信息。
s202：根据所述历史服务订单信息，确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量。
在具体实施的时候，历史服务订单可以是出行订单，服务订单属性可以包括长距离订单和短距离订单，还可以包括长距离订单、短距离订单和中距离订单等，例如：出行订单的出行距离在10公里以内为短距离订单，则此时的出行订单的服务订单属性为短距离订单，出行订单的出行距离在10公里至30公里为中距离订单，则此时出行订单的服务订单属性为中距离订单，出行订单的出行距离在30公里以上为长距离订单，则出行订单的服务订单属性为长距离订单。
获取到预设历史时间段内历史服务订单信息后，可以根据历史服务订单信息中的出行距离，依据于预先设定的各个服务订单属性对应的距离范围，确定各个历史服务订单所属的服务订单属性，并根据历史服务订单信息，确定服务订单数量，在这里，在确定服务订单数量的时候，不仅确定服务订单的总数量，还会确定各个服务订单属性下，发起的服务订单数量，例如，预设历史时间段为一年，获取历史服务订单信息为2017年11月1日至2018年11月1日用户端a发起的服务订单对应的出行订单，根据用户端a的出行订单对应的出行距离、出行时间等信息，得到用户端a在一年中出行订单的总数量为126单，其中，服务订单属性为长距离订单的出行订单有84单，服务订单属性为中距离订单的出行订单有7单，服务订单属性为短距离订单的出行订单有35单。
在一些实施例中，根据所述历史服务订单信息，确定用户端在预设历史时间段内，发起的服务订单属性以及服务订单数量，还包括：根据历史服务订单信息，确定用户端在多个预设时间区间中的每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量。
在具体实施的时候，预设时间区间是指将预设历史时间段按照一定的时间长度进行划分得到的时间区间，例如，预设历史时间段为2018年1月1日至2018年12月31日这一整年，那么预设时间区间可以是一个月、一个季度或者15天。根据历史服务订单信息，能够确定用户端在预设历史时间段内预设时间区间中每个预设时间区间内，发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量。
s203：根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在具体实施的时候，偏好信息用于反映用户端偏向发起的服务订单的服务订单属性，可以是一个概率值，也可以是指示是否偏好这种服务订单属性的字符信息。根据用户端发起的服务订单属性以及服务订单数量，能够确定用户端在至少一种服务订单属性下发起服务订单的偏好信息。根据得到的用户端的偏好信息，为用户端匹配对应的服务资源，例如，对于服务订单为出行订单的情况下，可以向用户端推送与偏好信息对应的优惠资源，比如针对长距离订单，推送订单折扣信息、抵扣信息等。另外，根据用户端偏好的服务订单属性，可以为用户端预先匹配对应的服务资源，比如为用户提前预备车辆等服务资源，以避免用户无法出行或出行不便利的情况。
在一些实施例中，步骤s203包括：根据在每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量，确定在该预设时间区间内，每种服务订单属性对应的服务订单占比；
根据所述多个预设时间区间的数量，以及在每个预设时间区间内，每种服务订单属性对应的服务订单占比，确定每种服务订单属性在各预设时间区间的服务订单平均占比；
根据每种服务订单属性在各预设时间区间的服务订单平均占比、在每个预设时间区间内，每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在每个预设时间区间内每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在具体实施的时候，根据每个预设时间区间内至少一种服务订单属性以及每种服务订单属性对应的服务订单数量，能够确定用户端在各个预设时间区间每种服务订单属性对应的服务订单占比。此外，在将预设历史时间段划分预设时间区间的时候，还需要获取划分的预设时间区间的数量，根据预设时间区间的数量，以及在每个预设时间区间内，每种服务订单属性对应的服务订单占比，能够得到用户端在每种服务订单属性在各预设时间区间的服务订单平均占比，其中，任一种服务订单属性在各预设时间区间的服务订单平均占比score满足下述公式：
其中，pctt表示在第t个预设时间区间内，任一种服务订单属性对应的服务订单占比，t表示预设时间区间的数量。
确定服务订单平均占比后，根据每种服务订单属性在各预设时间区间的服务订单平均占比、在每个预设时间区间内，每种服务订单属性对应的服务订单占比、多个预设时间区间的数量、在每个预设时间区间内每种服务订单属性对应的服务订单数量、以及用户端发起的服务订单所覆盖的时间区间的数量，确定用户端在至少一种服务订单属性下发起服务订单的偏好信息。
具体地，根据多个预设时间区间的数量、以及在以及在每个预设时间区间内每种服务订单属性对应的服务订单数量，能够得到在每种服务订单属性下发起服务订单的偏好稳定性，偏好稳定性能够表示发起任意一种服务订单属性的服务订单的的稳定状态，其中，在任一种服务订单属性下发起服务订单的偏好稳定性score稳满足下述公式：
其中，cntt表示第t个预设时间区间内，每种服务订单属性对应的服务订单数量，t表示预设时间区间的数量。
确定用户端在每种服务订单属性下发起服务订单的偏好稳定性后，根据在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、每种服务订单属性对应的服务订单占比、多个预设时间区间的数量、在每个预设时间区间内，每种服务订单属性对应的服务订单数量、以及用户端发起的服务订单所覆盖的时间区间的数量，确定用户端在至少一种服务订单属性下发起服务订单的偏好信息。
具体地，参见图3所示，为本申请实施例提供了确定用户端在至少一种服务订单属性下发起服务订单的偏好信息具体方法的流程图，包括：
s301：根据每种服务订单属性对应的服务订单占比、所述用户端发起的服务订单所覆盖的时间区间的数量、所述多个预设时间区间的数量，确定所述用户端在该服务订单属性下发起服务订单的服务订单频次。
在具体实施的时候，根据每种服务订单属性对应的服务订单占比、用户端发起的服务订单所覆盖的时间区间的数量、多个预设时间区间的数量，能够得到用户端该服务订单属性下发起服务订单的服务订单频次，服务订单平次能够衡量用户端的发起每种服务订单属性的出行订单的频次，其中，服务订单频次score频次满足下述公式：
其中，talive表示用户端发起的服务订单所覆盖的时间区间的数量，pctt表示第t个预设时间区间内，每种服务订单属性对应的服务订单占比，1if(pctt>0.65)else0)表示当第t个预设时间区间内，每种服务订单属性对应的服务订单占比大于预设阈值时则取值为1，否则取值为0，t表示预设时间区间的数量。
s302：根据所述在该服务订单属性下发起的服务订单频次、所述在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在具体实施的时候，在确定一种服务订单属性下发起服务订单的偏好信息的时候，需要根据在该服务订单属性下发起的服务订单频次、在该服务订单属性下发起服务订单的偏好稳定性、该服务订单属性下在各个预设时间区间的服务订单平均占比、以及用户端在预设历史时间段内发起服务订单所覆盖的时间区间的数量。
在一些实施例中，偏好信息中包括偏好度，偏好度用于表示用户端在任一种服务订单属性下发起服务订单的偏好程度，在确定用户端任一服务订单属性下发起的服务订单频次、该服务订单属性下发起服务订单的偏好稳定性、该服务订单属性下在各个预设时间区间的服务订单平均占比、以及用户端在预设历史时间段内发起服务订单所覆盖的时间区间的数量，计算在该服务订单属性下发起服务订单的偏好度，其中偏好度y满足下述公式：
y＝score×score稳×score频次；
其中，score表示任一种服务订单属性在各预设时间区间的服务订单平均占比，score稳表示在任一种服务订单属性下发起服务订单的偏好稳定性，score频次表示在该服务订单属性下发起服务订单的服务订单频次。
参见图4所示，本申请另一实施例还提供了另外一种根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息的具体方法，包括：
s401：针对任一种服务订单属性，根据所述每个预设时间区间内该服务订单属性对应的服务订单数量，构建该服务订单属性下发起的服务订单的服务订单特征向量。
在具体实施的时候，对于每一种服务订单属性，将用户端在每个预设时间区间内该服务订单属性对应的服务订单数量，构建该服务订单属性下发起的服务订单的服务订单特征向量，例如，服务订单属性为长距离服务订单，预设历史时间段为2017年6月份至2017年12月份，预设时间区间为一个月，用户端在各个预设时间区间发起的长距离服务订单的单数量分别为3、3、5、6、4、2，则服务订单特征向量为[3，3，5，6，4，2]。
在这里值得注意的是，本申请实施例中的服务订单属性仅包括两种，长距离服务订单以及非常距离服务订单，其中，长距离服务订单以及非长距离服务订单可以通过预设的距离阈值确定，例如，用户端的出行距离大于30公里则为长距离服务订单，若用户端的出行距离小于或等于30公里则为非长距离服务订单。
s402：将所述服务订单特征向量输入至预先训练的偏好信息检测模型中，确定所述用户端在所述任一种服务属性下发起服务订单的偏好信息。
在具体实施的时候，将构建好的服务订单特征向量输入至预先训练好的偏好信息检测模型中，进而确定用户端在任一种服务订单属性下发起服务订单的偏好信息，例如，用户端在发起的长距离服务订单对应的服务订单特征向量为[3，3，5，6，4，2]，则将其输入至预先训练好的偏好信息检测模型中，就能够得到用户端发起长距离服务订单的偏好信息。
具体地，参见图5所示，本申请实施例还提供了训练偏好信息检测模型的具体方法，包括：
s501：获取多个样本用户端中每个样本用户端在多个预设时间区间中的每个预设时间区间内，分别在不同服务属性下发起的服务订单数量，以及该样本用户端对应的实际偏好信息。
在具体实施时候，在具体实施中，样本用户端包括正样本用户端以及负样本用户端，例如，服务订单属性包括长距离服务订单以及非长距离服务订单的时候，预设历史时间段为一年，正样本用户端可以是在这一年中样本用户端发起长距离服务订单的数量占发起服务订单总数量的98％，发起非长距离服务订单的数量占发起服务订单总数量的2％作为正样本用户端。负样本用户端可以是这一年中样本用户端发起长距离服务订单的数量占发起服务订单总数量的2％，发起非长距离服务订单的数量占发起服务订单总数量的98％。
确定样本用户端后，根据样本用户端的历史服务订单信息，确定每个样本用户端在每一个预设时间区间内，分别发起各个服务订单属性的服务订单数量，并获取到每一个样本用户端对应的实际偏好信息，实际偏好信息可以是一个标签，也可以是一个数值，例如，正样本用户端的实际偏好信息可以是1，负样本用户端的实际偏好信息可以是0。
s502：根据该样本用户端在多个预设时间区间中的每个预设时间区间内，在不同服务属性下发起的服务订单数量，构建该样本用户端的特征向量；将所述特征向量输入至基础检测模型中，获得该样本用户端的偏好信息检测结果。
在构建样本用户端的特征向量的时候，与上述步骤s401相同，详细阐述可见步骤s401。
在一些实施例中，基础检测模型可以是由神经网络和分类器构成，如，循环神经网络。神经网络包括多层特征提取层，多层特征提取层能够对构建测特征向量进行特征提取，并将特征提取后的结果输入至分类器中，得到偏好信息检测结果。
s503：根据所述偏好信息检测结果以及所述实际偏好信息，对所述基础检测模型进行训练，得到所述偏好信息检测模型。
在具体实施的时候，得到偏好信息检测结果后，根据偏好信息检测结果以及实际偏好信息对基础检测模型进行训练，在训练的过程中，是根据偏好信息检测结果以及实际偏好信息对基础检测模型的参数进行调整，进而得到偏好信息检测模型，在对基础检测模型进行训练是多次的。
在一些实施例中，在对基础检测模型进行每一轮训练的时候，是将本轮还未完成训练的样本用户端中人一个样本用户端作为目标用户端，根据该样本用户端的偏好信息检测结果以及实际偏好信息，能够确定目标样本用户端在本轮偏好信息检测结果与实际偏好信息之间测交叉熵损失，根据样本用户端在本轮的交叉熵损失来调整基础检测模型的训练参数，将目标样本用户端作为本轮完成训练的样本用户端，并将本轮还未完成训练的样本用户端中任意一个样本用户端确定为新的目标样本用户，使用调整了参数后的基础检测模型，获取该新的目标样本用户端的偏好信息检测结果，计算该新的目标样本用户的偏好信息检测结果与对应的实际偏好信息交叉熵损失，如此反复，直至所有样本用户端都完成本轮的训练，完成对基础检测模型的本轮训练。
本申请实施例提供的一种信息处理方法中，首先获取用户端在预设历史时间段内的历史服务订单信息，然后根据获取的历史服务订单信息，能够得到用户端在预设历史时间段内，发起的服务订单属性以及服务订单数量，根据服务订单属性以及服务订单数量，得到用户端在至少一种服务订单属性下发起服务订单的偏好信息。与现有技术中存在服务资源配置的不精准的问题相比，本申请实施例能够确定用户端在至少一种服务订单属性下发起服务订单的偏好信息，进而根据用户的偏好信息，更有针对性的对用户进行服务资源的配置，提高服务资源的利用率。
基于上述信息处理方法，参见图6所示，本申请实施例还提供了一种信息处理装置600，包括：获取模块610、数量确定模块620、信息确定模块630；其中，
获取模块610，用于获取用户端在预设历史时间段内的历史服务订单信息；
数量确定模块620，用于根据所述历史服务订单信息，确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量；
信息确定模块630，用于根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一些实施方式中，所述历史服务订单为出行订单，所述服务订单属性用于表征出行订单对应的出行距离。
在一些实施方式中，所述数量确定模块620，用于采用下述方式确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量：
根据所述历史服务订单信息，确定所述用户端在多个预设时间区间中的每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量；
所述信息确定模块630，用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
根据在每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量，确定在该预设时间区间内，每种服务订单属性对应的服务订单占比；
根据所述多个预设时间区间的数量，以及在每个预设时间区间内，每种服务订单属性对应的服务订单占比，确定每种服务订单属性在各预设时间区间的服务订单平均占比；
根据每种服务订单属性在各预设时间区间的服务订单平均占比、在每个预设时间区间内，每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在每个预设时间区间内每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一些实施方式中，任一种服务订单属性在各预设时间区间的服务订单平均占比score满足下述公式：
其中，pctt表示在第t个预设时间区间内，任一种服务订单属性对应的服务订单占比，t表示预设时间区间的数量。
在一些实施方式中，所述信息确定模块630，具体用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
根据所述多个预设时间区间的数量、以及在每个预设时间区间内每种服务订单属性对应的服务订单数量，确定在每种服务订单属性下发起服务订单的偏好稳定性；
根据在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在所述每个预设时间区间内，每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一些实施方式中，在任一种服务订单属性下发起服务订单的偏好稳定性score稳满足下述公式：
其中，cntt表示第t个预设时间区间内，每种服务订单属性对应的服务订单数量，t表示预设时间区间的数量。
在一些实施方式中，信息确定模块630，具体用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
根据每种服务订单属性对应的服务订单占比、所述用户端发起的服务订单所覆盖的时间区间的数量、所述多个预设时间区间的数量，确定所述用户端在该服务订单属性下发起服务订单的服务订单频次；
根据所述在该服务订单属性下发起服务订单的服务订单频次、所述在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
在一些实施方式中，所述在任一服务订单属性下发起服务订单的服务订单频次score频次满足下述公式：
其中，talive表示用户端发起的服务订单所覆盖的时间区间的数量，pctt表示第t个预设时间区间内，每种服务订单属性对应的服务订单占比，1if(pctt>0.65)else0)表示当第t个预设时间区间内，每种服务订单属性对应的服务订单占比大于预设阈值时则取值为1，否则取值为0，t表示预设时间区间的数量。
在一些实施方式中，所述偏好信息包括偏好度，所述用户端在任一种服务订单属性下发起服务订单的偏好度y满足下述公式：
y＝score×score稳×score频次；
其中，score表示任一种服务订单属性在各预设时间区间的服务订单平均占比，score稳表示在任一种服务订单属性下发起服务订单的偏好稳定性，score频次表示在该服务订单属性下发起服务订单的服务订单频次。
在一些实施方式中，所述信息取定模块630，还用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
针对任一种服务订单属性，根据所述每个预设时间区间内该服务订单属性对应的服务订单数量，构建该服务订单属性下发起的服务订单的服务订单特征向量；
将所述服务订单特征向量输入至预先训练的偏好信息检测模型中，确定所述用户端在所述任一种服务属性下发起服务订单的偏好信息。
在一些实施方式中，所述装置还包括训练模块640；
所述训练模块640，用于通过下述方式训练得到所述偏好信息检测模型：
获取多个样本用户端中每个样本用户端在多个预设时间区间中的每个预设时间区间内，分别在不同服务属性下发起的服务订单数量，以及该样本用户端对应的实际偏好信息；
根据该样本用户端在多个预设时间区间中的每个预设时间区间内，在不同服务属性下发起的服务订单数量，构建该样本用户端的特征向量；将所述特征向量输入至基础检测模型中，获得该样本用户端的偏好信息检测结果；
根据所述偏好信息检测结果以及所述实际偏好信息，对所述基础检测模型进行训练，得到所述偏好信息检测模型。
在一些实施方式中，所述训练模块640，具体用于采用下述方式对所述基础检测模型进行训练：
根据各个样本用户端的偏好信息检测结果，以及对应的实际偏好信息，对所述基础检测模型进行一轮训练后，调整所述基础检测模型的训练参数并进入下一轮训练，将经过多轮训练后的基础检测模型确定为所述偏好信息检测模型。
在一些实施方式中，所述训练模块640，具体用于采用下述步骤对所述基础检测模型进行每一轮训练：
将本轮还未完成训练的样本用户端中的任意一个样本用户端确定为目标样本用户端，根据该目标样本用户端的偏好信息检测结果，以及对应的实际偏好信息，确定所述目标样本用户端在本轮的交叉熵损失；
根据所述目标样本用户端在本轮的交叉熵损失，调整所述基础检测模型的训练参数；
将所述目标样本用户端作为本轮完成训练的样本用户端，并将本轮还未完成训练的样本用户端中任意一个样本用户端确定为新的目标样本用户；
使用调整了参数后的所述基础检测模型，获取该新的目标样本用户端的偏好信息检测结果，并重新返回根据该目标样本用户的偏好信息检测结果，以及对应的实际偏好信息，确定所述目标样本用户端本轮的交叉熵损失的步骤；
直至所有样本用户端都完成本轮的训练，完成对所述基础检测模型的本轮训练。
上述模块可以经由有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合线缆等，或其任意组合。无线连接可以包括通过lan、wan、蓝牙、zigbee、或nfc等形式的连接，或其任意组合。两个或更多个模块可以组合为单个模块，并且任何一个模块可以分成两个或更多个单元。
参见图7所示，本申请实施例还提供了可以实现本申请思想的电子设备700的示例性硬件和软件组件的示意图。处理器720可以用于电子设备700上，并且用于执行上述本申请中的功能。
电子设备700可以是通用计算机或特殊用途的计算机，两者都可以用于实现本申请的信息推送方法。本申请尽管仅示出了一个计算机，但是为了方便起见，可以在多个类似平台上以分布式方式实现本申请描述的功能，以均衡处理负载。
例如，电子设备700可以包括连接到网络的网络端口710、用于执行程序指令的一个或多个处理器720、通信总线730和不同形式的存储介质740，例如，磁盘、rom、或ram，或其任意组合。示例性地，计算机平台还可以包括存储在rom、ram、或其他类型的非暂时性存储介质或其任意组合中的程序指令。根据这些程序指令可以实现本申请的方法。电子设备700还包括计算机与其他输入输出设备(例如键盘、显示屏)之间的输入/输出(input/output，i/o)接口750。
为了便于说明，在电子设备700中仅描述了一个处理器。然而，应当注意，本申请中的电子设备700还可以包括多个处理器，因此本申请中描述的一个处理器执行的步骤也可以由多个处理器联合执行或单独执行。例如，若电子设备700的处理器执行步骤a和步骤b，则应该理解，步骤a和步骤b也可以由两个不同的处理器共同执行或者在一个处理器中单独执行。例如，第一处理器执行步骤a，第二处理器执行步骤b，或者第一处理器和第二处理器共同执行步骤a和b。
在具体实施的时候，存储介质740存储有所述处理器720可执行的机器可读指令，当电子设备运行时，所述处理器720与所述存储介质740之间通过通信总线730通信，所述机器可读指令被所述处理器720执行时执行上述信息处理方法，从而解决现有技术中服务资源不够分配，导致用户无法出行或出行不便利的问题，实现为用户端提前合理配置服务资源，提高服务效率的效果。
本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述信息处理方法的步骤。
具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述信息处理方法，从而解决现有技术中服务资源不够分配，导致用户无法出行或出行不便利的问题，实现为用户端提前合理配置服务资源，提高服务效率的效果。
本申请实施例所提供的一种信息处理方法及装置的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。
1.一种信息处理方法，其特征在于，包括：
获取用户端在预设历史时间段内的历史服务订单信息；
根据所述历史服务订单信息，确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量；
根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
2.根据权利要求1所述的方法，其特征在于，所述历史服务订单为出行订单，所述服务订单属性用于表征出行订单对应的出行距离。
3.根据权利要求1所述的方法，其特征在于，所述根据所述历史服务订单信息，确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量，包括：
根据所述历史服务订单信息，确定所述用户端在多个预设时间区间中的每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量；
所述根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息，包括：
根据在每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量，确定在该预设时间区间内，每种服务订单属性对应的服务订单占比；
根据所述多个预设时间区间的数量，以及在每个预设时间区间内，每种服务订单属性对应的服务订单占比，确定每种服务订单属性在各预设时间区间的服务订单平均占比；
根据每种服务订单属性在各预设时间区间的服务订单平均占比、在每个预设时间区间内，每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在每个预设时间区间内每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
4.根据权利要求3所述的方法，其特征在于，任一种服务订单属性在各预设时间区间的服务订单平均占比score满足下述公式：
其中，pctt表示在第t个预设时间区间内，任一种服务订单属性对应的服务订单占比，t表示预设时间区间的数量。
5.根据权利要求4所述的方法，其特征在于，所述根据每种服务订单属性在各预设时间区间的服务订单平均占比、在每个预设时间区间内，每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在每个预设时间区间内每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息，包括：
根据所述多个预设时间区间的数量、以及在每个预设时间区间内每种服务订单属性对应的服务订单数量，确定在每种服务订单属性下发起服务订单的偏好稳定性；
根据在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在所述每个预设时间区间内，每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
6.根据权利要5所述的方法，其特征在于，在任一种服务订单属性下发起服务订单的偏好稳定性score稳满足下述公式：
其中，cntt表示第t个预设时间区间内，每种服务订单属性对应的服务订单数量，t表示预设时间区间的数量。
7.根据权利要求5所述的方法，其特征在于，所述确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息，包括：
根据每种服务订单属性对应的服务订单占比、所述用户端发起的服务订单所覆盖的时间区间的数量、所述多个预设时间区间的数量，确定所述用户端在该服务订单属性下发起服务订单的服务订单频次；
根据所述在该服务订单属性下发起服务订单的服务订单频次、所述在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
8.根据权利要求7所述的方法，其特征在于，所述在任一服务订单属性下发起服务订单的服务订单频次score频次满足下述公式：
其中，talive表示用户端发起的服务订单所覆盖的时间区间的数量，pctt表示第t个预设时间区间内，每种服务订单属性对应的服务订单占比，1if(pctt>0.65)else0)表示当第t个预设时间区间内，每种服务订单属性对应的服务订单占比大于预设阈值时则取值为1，否则取值为0，t表示预设时间区间的数量。
9.根据权利要求7所述的方法，其特征在于，所述偏好信息包括偏好度，所述用户端在任一种服务订单属性下发起服务订单的偏好度y满足下述公式：
y＝score×score稳×score频次；
其中，score表示任一种服务订单属性在各预设时间区间的服务订单平均占比，score稳表示在任一种服务订单属性下发起服务订单的偏好稳定性，score频次表示在该服务订单属性下发起服务订单的服务订单频次。
10.根据权利要求3所述的方法，其特征在于，所述根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息，包括：
针对任一种服务订单属性，根据所述每个预设时间区间内该服务订单属性对应的服务订单数量，构建该服务订单属性下发起的服务订单的服务订单特征向量；
将所述服务订单特征向量输入至预先训练的偏好信息检测模型中，确定所述用户端在所述任一种服务属性下发起服务订单的偏好信息。
11.根据权利要求10所述的方法，其特征在于，通过下述方式训练得到所述偏好信息检测模型：
获取多个样本用户端中每个样本用户端在多个预设时间区间中的每个预设时间区间内，分别在不同服务属性下发起的服务订单数量，以及该样本用户端对应的实际偏好信息；
根据该样本用户端在多个预设时间区间中的每个预设时间区间内，在不同服务属性下发起的服务订单数量，构建该样本用户端的特征向量；将所述特征向量输入至基础检测模型中，获得该样本用户端的偏好信息检测结果；
根据所述偏好信息检测结果以及所述实际偏好信息，对所述基础检测模型进行训练，得到所述偏好信息检测模型。
12.根据权利要求11所述的方法，其特征在于，所述根据所述偏好信息检测结果以及所述实际偏好信息，对所述基础检测模型进行训练，得到所述偏好信息检测模型包括：
根据各个样本用户端的偏好信息检测结果，以及对应的实际偏好信息，对所述基础检测模型进行一轮训练后，调整所述基础检测模型的训练参数并进入下一轮训练，将经过多轮训练后的基础检测模型确定为所述偏好信息检测模型。
13.根据权利要求12所述的方法，其特征在于，采用下述步骤对所述基础检测模型进行每一轮训练：
将本轮还未完成训练的样本用户端中的任意一个样本用户端确定为目标样本用户端，根据该目标样本用户端的偏好信息检测结果，以及对应的实际偏好信息，确定所述目标样本用户端在本轮的交叉熵损失；
根据所述目标样本用户端在本轮的交叉熵损失，调整所述基础检测模型的训练参数；
将所述目标样本用户端作为本轮完成训练的样本用户端，并将本轮还未完成训练的样本用户端中任意一个样本用户端确定为新的目标样本用户；
使用调整了参数后的所述基础检测模型，获取该新的目标样本用户端的偏好信息检测结果，并重新返回根据该目标样本用户的偏好信息检测结果，以及对应的实际偏好信息，确定所述目标样本用户端本轮的交叉熵损失的步骤；
直至所有样本用户端都完成本轮的训练，完成对所述基础检测模型的本轮训练。
14.一种信息处理装置，其特征在于，包括：
获取模块，用于获取用户端在预设历史时间段内的历史服务订单信息；
数量确定模块，用于根据所述历史服务订单信息，确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量；
信息确定模块，用于根据所述服务订单属性以及所述服务订单数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
15.根据权利要求14所述的装置，其特征在于，所述历史服务订单为出行订单，所述服务订单属性用于表征出行订单对应的出行距离。
16.根据权利要求15所述的装置，其特征在于，所述数量确定模块，用于采用下述方式确定所述用户端在所述预设历史时间段内，发起的服务订单属性以及服务订单数量：
根据所述历史服务订单信息，确定所述用户端在多个预设时间区间中的每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量；
所述信息确定模块，用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
根据在每个预设时间区间内发起的至少一种服务订单属性以及每种服务订单属性对应的服务订单数量，确定在该预设时间区间内，每种服务订单属性对应的服务订单占比；
根据所述多个预设时间区间的数量，以及在每个预设时间区间内，每种服务订单属性对应的服务订单占比，确定每种服务订单属性在各预设时间区间的服务订单平均占比；
根据每种服务订单属性在各预设时间区间的服务订单平均占比、在每个预设时间区间内，每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在每个预设时间区间内每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
17.根据权利要求16所述的装置，其特征在于，任一种服务订单属性在各预设时间区间的服务订单平均占比score满足下述公式：
其中，pctt表示在第t个预设时间区间内，任一种服务订单属性对应的服务订单占比，t表示预设时间区间的数量。
18.根据权利要求16所述的装置，其特征在于，所述信息确定模块，具体用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息，包括：
根据所述多个预设时间区间的数量、以及在每个预设时间区间内每种服务订单属性对应的服务订单数量，确定在每种服务订单属性下发起服务订单的偏好稳定性；
根据在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、每种服务订单属性对应的服务订单占比、所述多个预设时间区间的数量、在所述每个预设时间区间内，每种服务订单属性对应的服务订单数量、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
19.根据权利要18所述的装置，其特征在于，在任一种服务订单属性下发起服务订单的偏好稳定性score稳满足下述公式：
其中，cntt表示第t个预设时间区间内，每种服务订单属性对应的服务订单数量，t表示预设时间区间的数量。
20.根据权利要求18所述的装置，其特征在于，所述信息确定模块，具体用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
根据每种服务订单属性对应的服务订单占比、所述用户端发起的服务订单所覆盖的时间区间的数量、所述多个预设时间区间的数量，确定所述用户端在该服务订单属性下发起服务订单的服务订单频次；
根据所述在该服务订单属性下发起服务订单的服务订单频次、所述在每种服务订单属性下发起服务订单的偏好稳定性、每种服务订单属性在各预设时间区间的服务订单平均占比、以及所述用户端发起的服务订单所覆盖的时间区间的数量，确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息。
21.根据权利要求20所述的装置，其特征在于，所述在任一服务订单属性下发起服务订单的服务订单频次score频次满足下述公式：
其中，talive表示用户端发起的服务订单所覆盖的时间区间的数量，pctt表示第t个预设时间区间内，每种服务订单属性对应的服务订单占比，1if(pctt>0.65)else0)表示当第t个预设时间区间内，每种服务订单属性对应的服务订单占比大于预设阈值时则取值为1，否则取值为0，t表示预设时间区间的数量。
22.根据权利要求20所述的装置，其特征在于，所述偏好信息包括偏好度，所述用户端在任一种服务订单属性下发起服务订单的偏好度y满足下述公式：
y＝score×score稳×score频次；
其中，score表示任一种服务订单属性在各预设时间区间的服务订单平均占比，score稳表示在任一种服务订单属性下发起服务订单的偏好稳定性，score频次表示在该服务订单属性下发起服务订单的服务订单频次。
23.根据权利要求16所述的装置，其特征在于，所述信息取定模块，还用于采用下述方式确定所述用户端在至少一种服务订单属性下发起服务订单的偏好信息：
针对任一种服务订单属性，根据所述每个预设时间区间内该服务订单属性对应的服务订单数量，构建该服务订单属性下发起的服务订单的服务订单特征向量；
将所述服务订单特征向量输入至预先训练的偏好信息检测模型中，确定所述用户端在所述任一种服务属性下发起服务订单的偏好信息。
24.根据权利要求23所述的装置，其特征在于，所述装置还包括训练模块；
所述训练模块，用于通过下述方式训练得到所述偏好信息检测模型：
获取多个样本用户端中每个样本用户端在多个预设时间区间中的每个预设时间区间内，分别在不同服务属性下发起的服务订单数量，以及该样本用户端对应的实际偏好信息；
根据该样本用户端在多个预设时间区间中的每个预设时间区间内，在不同服务属性下发起的服务订单数量，构建该样本用户端的特征向量；将所述特征向量输入至基础检测模型中，获得该样本用户端的偏好信息检测结果；
根据所述偏好信息检测结果以及所述实际偏好信息，对所述基础检测模型进行训练，得到所述偏好信息检测模型。
25.根据权利要求24所述的装置，其特征在于，所述训练模块，具体用于：
根据各个样本用户端的偏好信息检测结果，以及对应的实际偏好信息，对所述基础检测模型进行一轮训练后，调整所述基础检测模型的训练参数并进入下一轮训练，将经过多轮训练后的基础检测模型确定为所述偏好信息检测模型。
26.根据权利要求25所述的装置，其特征在于，所述训练模块，具体用于采用下述步骤对所述基础检测模型进行每一轮训练：
将本轮还未完成训练的样本用户端中的任意一个样本用户端确定为目标样本用户端，根据该目标样本用户端的偏好信息检测结果，以及对应的实际偏好信息，确定所述目标样本用户端在本轮的交叉熵损失；
根据所述目标样本用户端在本轮的交叉熵损失，调整所述基础检测模型的训练参数；
将所述目标样本用户端作为本轮完成训练的样本用户端，并将本轮还未完成训练的样本用户端中任意一个样本用户端确定为新的目标样本用户；
使用调整了参数后的所述基础检测模型，获取该新的目标样本用户端的偏好信息检测结果，并重新返回根据该目标样本用户的偏好信息检测结果，以及对应的实际偏好信息，确定所述目标样本用户端本轮的交叉熵损失的步骤；
直至所有样本用户端都完成本轮的训练，完成对所述基础检测模型的本轮训练。
27.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至13任一所述的信息处理方法的步骤。
28.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至13任一所述的信息处理方法的步骤。
技术总结