CN107622335A - 任务的处理方法、装置和系统 - Google Patents

Abstract

本申请公开了一种任务的处理方法、装置和系统。其中，该系统包括：服务器，用于提供多个任务，其中，多个任务中的每个任务包括一个或多个接收输入的输入接口；客户端，用于展示服务器提供的多个任务，并接收通过任务的输入接口输入的输入信息，并将接收到的输入信息发送至服务器；服务器还用于根据输入的信息，确定完成的任务以及完成任务的时长，服务器接收到通过任务的输入接口反馈的输入信息表示任务的完成；并根据完成任务的时长确定预定时间段内任务完成的速度；调整单元，用于至少根据任务完成的速度对提供的任务数量进行调整。本申请解决了由于只投放固定数量的任务，如果任务被处理完，而任务时间未到，浪费客户端流量的技术问题。

Description

任务的处理方法、装置和系统

技术领域

本申请涉及互联网领域，具体而言，涉及一种任务的处理方法、装置和系统。

背景技术

现有技术中，在投放数据标注任务之前，任务发布方收集需要进行标注的数据标注任务，设置每个数据标注任务的回收量，并设置任务投放的开始时间和结束时间，在任务投放开始之后，投放数据标注任务，并收集在用户的执行任务的执行结果，在数据标注任务的回收量达到设置的回收量之后，停止该数据标注任务的投放，并统计该数据标注任务的执行结果，基于该执行结果可以确定数据标注任务的标注是“是”还是“否”。

例如，任务发布方收集需要进行标注的m道问题，对每一个需要标注的问题设置一个不小于1的n个回收量，将这些题目(总数m*n)推送给客户端来填答，并收集客户端的标注结果。

采用上述方案，设置了任务投放的时间有限，投放的任务数量很大，很难在短时间内完成；如果题目被做完，而任务结束时间未到，如果有客户端送了任务执行请求，但是没有任务可以发送至客户端，也就是说，会造成有人无题的尴尬局面，浪费客户端资源；并且，在上述方案中，在有限的时间和客户端资源限制下，投放任务时，不考虑任务的难度或者关注度，无法对标注问题中较难的一部分题目进行重点解决。

针对上述只投放固定数量的任务，如果任务被处理完，而任务时间未到，浪费客户端流量的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种任务的处理方法、装置和系统，以至少解决由于只投放固定数量的任务，如果任务被处理完，而任务时间未到，浪费客户端流量的技术问题。

根据本申请实施例的一个方面，提供了一种任务的处理系统，该系统包括：服务器，用于提供多个任务，其中，多个任务中的每个任务包括一个或多个接收输入的输入接口；客户端，用于展示服务器提供的多个任务，并接收通过任务的输入接口输入的输入信息，并将接收到的输入信息发送至服务器；服务器还用于根据输入的信息，确定完成的任务以及完成任务的时长，其中，服务器接收到通过任务的输入接口反馈的输入信息表示任务的完成；并根据完成任务的时长确定预定时间段内任务完成的速度；调整单元，用于至少根据任务完成的速度对提供的任务数量进行调整。

根据本申请实施例的一个方面，提供了一种任务的处理方法，该方法包括：服务器提供多个任务，其中，多个任务能够在客户端上展示，多个任务中的每个任务包括一个或多个接收输入的输入接口；服务器接收至少一个客户端反馈的输入信息，其中，输入信息为客户端通过任务的输入接口输入的信息；服务器根据输入的信息，确定完成的任务以及完成任务的时长，其中，服务器接收到通过任务的输入接口反馈的输入信息表示任务的完成；服务器根据完成任务的时长确定预定时间段内任务完成的速度；服务器至少根据任务完成的速度对提供的任务数量进行调整。

根据本申请实施例的一个方面，提供了一种任务的处理装置，该装置包括：提供单元，用于提供多个任务，其中，多个任务能够在客户端上展示，多个任务中的每个任务包括一个或多个接收输入的输入接口；接收单元，用于接收至少一个客户端反馈的输入信息，其中，输入信息为客户端通过任务的输入接口输入的信息；第一确定单元，用于根据输入的信息，确定完成的任务以及完成任务的时长，其中，服务器接收到通过任务的输入接口反馈的输入信息表示任务的完成；第二确定单元，用于根据完成任务的时长确定预定时间段内任务完成的速度；调整单元，用于至少根据任务完成的速度对提供的任务数量进行调整。

在本申请实施例中，服务器在向客户端提供多个任务之后，接收客户端通过任务的输入接口输入的输入信息，服务器基于该输入信息确定完成的任务和任务完成的时间，并基于任务完成的时间计算预定时间段内任务完成的速度，并至少根据任务完成的速度调整提供的任务的数量，在上述实施例中，可以根据任务完成情况调整提供的任务数量，而不是投放固定数量的任务，可以灵活调整提供的任务数量，从而可以基于任务时间调整任务数量，可以满足客户端的任务请求量，不会浪费客户端的流量，解决了现有技术中只投放固定数量的任务，如果任务被处理完，而任务时间未到，浪费客户端流量的问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1(a)是本申请实施例的一种任务的处理系统的网络架构图；

图1(b)是本申请实施例的一种任务的处理方法的计算机终端的硬件结构框图；

图2是根据本申请实施例的一种可选的任务的处理方法的流程图；

图3是根据本申请实施例的另一种可选的任务的处理方法的流程图；

图4是根据本申请实施例的再一种可选的任务的处理方法的流程图；

图5是根据本申请实施例的一种可选的任务的处理方法的时序流程图；

图6是根据本申请实施例的一种可选的任务的处理装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先将本申请实施例涉及的术语解释如下：

众包任务：可以是将大量的任务分配给不同的客户端处理的一种任务处理方法。该任务可以是指一个公司或机构把由员工执行的工作任务，例如，产品的开发需求调研。具体地，可以将大量的任务分配给不同的客户端，并收集客户端处理任务的结果，统计客户端处理任务的结果，并将统计结果作为众包任务的结果。

数据标注任务：众包任务的一种，数据标注任务可以是通过计算机算法无法判断、但是需标注结果的任务，如，1)淘宝和阿里巴巴什么关系？2)天猫和阿里巴巴什么关系？假如算法无法判断1)和2)是否可以用同一个答案来解答，则可以借助数据标注任务实现，例如将这两句话给100个网民，让其标注“同义”或“不同义”，收集这100人的答案，分析出这两句话是否同义，给客服机器人提供答案。

雷，是指已知正确处理结果的任务。

埋雷，是众包任务常用的反作弊手法，将一些有明显已知答案的题目(如雷)安插在题目集(如任务集)中，用户做任务的时候，如果连这些已知正确处理结果的任务也回答错误，则说明用户的答案不可信。

回收量：执行每个任务的次数，如，对每一个需要数据标注任务设置一个不小于1的用户可回答数(该用户可回答数即为回收量)。比如，数据标注任务a，回收量为11，则任务a发放给不同用户来回答，每个用户的回答数为1，问题a答满11，就不可再答。总回收量就为所有任务的回收量之和。

准确率：每个数据标注任务都有回收量，准确率为数量较多的结果(如答案)个数在所有结果个数中的占比。比如，任务a，回收量是11，处理结果中回答“是”的为9个，回答“否”为2个，那么准备率为9/11*100％＝81.8％。可选地，每个数据标注任务的回收量可以设置为奇数。

任务结束时间：数据标注任务的结束时间，结束后，任务中止，用户将不可再执行任务。

本申请实施例提供了一种的系统实施例，该系统实施例可以应用在移动终端、计算机终端或者类似的运算装置中。可选地，该系统包括服务器和客户端，该实施例中的服务器和客户端可以应用于如图1(a)所示的网络环境中，该网络环境中的客户端用于执行任务，服务器用于为客户端提供任务，并调度客户端的任务，其中，该客户端可以为一个或多个，而该服务器可以调度该一个或多个客户端执行的任务。这里的调度主要涉及服务器提供的任务数量的增加、减少或不变。

该实施例中的客户端或服务器均可以包括的一个或多个(图中仅示出一个)处理器(处理器可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器、以及用于通信功能的传输模块。具体地，图1(b)示出的服务器的处理器可以包括任务调度单元和任务提供单元，客户端包括任务执行单元和任务展示单元

本领域普通技术人员可以理解，图1(b)所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端10还可以包括比图1(b)中所示更多或者更少的组件，或者具有与图1(b)所示不同的配置。

其中的存储器可用于存储应用软件的软件程序以及模块，如本申请实施例中的任务的处理方法对应的程序指令/模块，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的任务的处理方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端的通信供应商提供的无线网络。

具体地，服务器的处理器可以包括任务调度单元和任务提供单元，客户端包括任务执行单元和任务展示单元，其中：

服务器的任务提供单元用于提供多个任务，其中，多个任务中的每个任务包括一个或多个接收输入的输入接口；

客户端的任务展示单元用于展示服务器提供的多个任务；任务执行单元接收通过任务的输入接口输入的输入信息，并将接收到的输入信息发送至服务器。

服务器的任务调度单元还用于根据输入的信息，确定完成的任务以及完成任务的时长，其中，服务器接收到通过任务的输入接口反馈的输入信息表示任务的完成；并根据完成任务的时长确定预定时间段内任务完成的速度；调整单元，用于至少根据任务完成的速度对提供的任务数量进行调整。

其中，这里的预定时间段可以为单位时间，如1s。该速度可以表示为每5秒完成的任务数量。

通过上述实施例，服务器在向客户端提供多个任务之后，接收客户端通过任务的输入接口输入的输入信息，服务器基于该输入信息确定完成的任务和任务完成的时间，并基于任务完成的时间计算预定时间段内任务完成的速度，并至少根据任务完成的速度调整提供的任务的数量，在上述实施例中，可以根据任务完成情况调整提供的任务数量，而不是投放固定数量的任务，可以灵活调整提供的任务数量，从而可以基于任务时间调整任务数量，可以满足客户端的任务请求量，不会浪费客户端的流量，解决了现有技术中只投放固定数量的任务，如果任务被处理完，而任务时间未到，浪费客户端流量的问题。

本申请上述方案可以应用于众包任务的投放中，具体地，客户端可以通过登录众包任务客户端、或者通过网页进行众包任务请求页面，在客户端进入众包任务请求页面之后，可以生成众包任务请求，将该众包任务请求发送至服务器之后，服务器投放任务至客户端，客户端执行众包任务，将执行结果发送至服务器，服务器收集各个客户端返回的执行结果(如上述的输入信息)，并对输入信息进行统计，得到任务的处理结果。

可选地，上述任务可以为数据标注任务，如，天猫与淘宝一样吗？对于此类任务，服务器返回给客户端的任务的信息中，具有用于提示客户端输入“是”或者“否”的输入接口，该输入接口用选择框、和/或文字描述的形式表现出来，本申请对此不做限定。

根据本申请实施例，还提供了一种任务的处理方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

该任务的处理方法可以包括如图2所示的步骤：

步骤S202：服务器提供多个任务，其中，多个任务能够在客户端上展示，多个任务中的每个任务包括一个或多个接收输入的输入接口；

步骤S204：服务器接收至少一个客户端反馈的输入信息，其中，输入信息为客户端通过任务的输入接口输入的信息；

步骤S206：服务器根据输入的信息，确定完成的任务以及完成任务的时长，其中，服务器接收到通过任务的输入接口反馈的输入信息表示任务的完成；

步骤S208：服务器根据完成任务的时长确定预定时间段内任务完成的速度；

步骤S210：服务器至少根据任务完成的速度对提供的任务数量进行调整。

该实施例中的任务与上述系统实施例中的任务相同，在此不再赘述。

其中，上述的步骤S210，服务器至少根据任务完成的速度对提供的任务数量进行调整可以包括：

步骤S2101：服务器根据任务完成的速度确定至少一个客户端在调整周期内完成任务的预估数量。

具体地，服务器将任务完成的速度和调整周期的时长的乘积，作为预估数量。

具体地，可以计算在每个监控采样时间点内的平均答题速度(即上述的执行速度)；在报警模块，一旦剩余总题目数(即剩余总次数)<采样时长*动态平均答题速度，就会报警通知，根据动态平均答题速度，来自动补充回收量，并关闭达到准确率的题目。

其中，预估数量即为采样时长(即当前调度时长)*动态平均答题速度。

在上述实施例中，服务器可以预先收集N个任务，在历史的调度时长内，已经向客户端投放一些，获取在该历史的调度时长内已经投放至客户端、并被客户端执行任务的执行总次数，实质上，在每次投放的时候，可能不是将N个任务一并投放，而是投放了一部分，因此，可以基于上述的执行总次数判断已经被执行过的任务的数量，如，已经答题的题目数量，在补充回收量时，对已经执行过的任务进行回收量的补充，可以优先覆盖这些题目，从而可以在一个时间段内集中投放任务(如题目)。

由于在服务器收集到任务之后，为每个任务设置了固有的回收量，即设置了执行每个任务的总的完成数量，可以基于该设置的固有的回收量和已经执行任务的执行总次数(即历史时长内执行任务的总回收量)，将这些已经被执行过的任务确定为待增加回收量的任务。

需要进一步说明的是，初始数量为预先设置的允许执行每个任务的数量，该初始数量可以为奇数，增加M个任务的回收量时，可以分别为每个任务增加偶数个回收量(即增加的执行次数为偶数)，若对于每个回收量的总数都是奇数，便于统计每个任务执行的准确率。

例如，已答过题的总答题次数(即总回收量)为P，M＝P/q，其中，q为每个任务的预设的回收量，对已答过的题目中的M道题(M个任务)，增加回收量q+o，其中，o为增加的回收量。这里的P＝v*t，v为答题速度，t为总的答题时长。

通过上述实施例，增加任务的数量之后，每个数据标注任务的统计结果会发生变化，通过增加任务的回收量可以提高任务的执行准确率。

例如，一个任务的任务数量可以为25次，若已经完成25次，20次的答案是“是”，5次的答案是“否”，则统计的正确率为80％，且统计出的任务的执行结果为“是”。增加剩余次数之后，可以增加该任务的回收量，若增加次数为10次，回收所有的结果之后，答“是”的结果数量可能还维持在20次，答“否”的次数可以变为15次，这时，统计的正确率变为57％，统计的任务的执行结果为“是”，虽然结果没有发生变化，但是正确率发生了变化。

若增加的数量为30次，回收所有的结果之后，答“是”的结果数量可能还维持在20个，答“否”的数量可以变为35次，这时，统计的正确率变为63％，统计的任务的执行结果为“否”，这时结果发生了变化，正确率也发生了变化。本申请的次数均等同于数量。

由上述分析可知，随着数回收量的增加，可以使得任务的回收量覆盖率和正确率发生变化，这对于任务发布方来讲，提高了任务的标注正确率。

需要进一步说明的是，上述实施例中，在增加任务的数量之前，在任务结束时间未到的情下，若判断出所有任务的准确率已经达到预期准确率、且完成任务的数量已到达预期数量，也可以增加任务的数量。

由上述分析，增加任务的任务数量，可以提高任务的最终准确率，所以即便是所有任务的回收量和准确率均已达到预期，也可以增加回收量，以进一步提高准确率和覆盖率。

步骤S2103：服务器获取服务器提供的任务中尚未完成的任务数量。

步骤S2105：服务器检测尚未完成的任务数量是否小于预估数量。

步骤S2107：若检测出尚未完成的任务数量小于预估数量，则服务器对提供的任务数量进行调整。

具体地，在检测出尚未完成的任务数量小于预估数量的情况下，增加服务器提供的任务数量；在检测出尚未完成的任务数量不小于预估数量的情况下，则保持当前的调整周期内的任务数量。需要说明的是，这里的保持的任务数量有可能是暂时的，如果在下一个调度周期内，检测出尚未完成的任务数量小于预估数量，则仍需增加提供的任务的数量。

可选地，在检测出尚未完成的任务数量小于预估数量的情况下，生成报警通知，该报警通知用于通知尚未完成任务的任务数量不足，需要补充回收量。

可选地，可以通过服务器上的任务调度模块获取在预定时间段内完成任务的速度；并通过任务调度模块中的报警模块，预估当前的调整周期内可以完成的任务的预估数量，并在检测出尚未完成的任务数量小于预估数量的情况下，生成上述的报警通知，该任务调度模块接收到报警通知，增加任务的数量。

需要说明的是，在当前调整周期的结束时刻为整个任务的结束时刻时，若当前调整周期中的剩余总次数已经为零，也需要增加任务的回收量。

在上述实施例中，服务器可以预先提供N个任务，在历史的调度时长内，已经向客户端投放一些，获取在该历史的调度时长内已经投放至客户端、并被客户端执行任务的完成的任务的数量，实质上，在每次投放的时候，可能不是将N个任务一并投放，而是投放了一部分，因此，可以基于上述的执行总次数判断已经被执行过的任务的数量，如，已经答题的题目数量，在补充回收量时，对已经执行过的任务进行回收量的补充，可以优先覆盖这些题目，从而可以在一个时间段内集中投放任务(如题目)。

具体地，服务器对尚未完成的任务数量进行调整可以包括：服务器获取完成的任务的完成数量；服务器基于完成数量，确定待调整数量的任务个数M，其中，M为自然数；服务器增加多个任务中M个任务的任务数量。

由于在服务器为每个任务设置了固有的回收量(即初始投放的任务数量)，可以基于该设置的固有的回收量和完成数量，将已经被执行过的任务中的部分或全部确定为待增加回收量的任务。

进一步地，服务器基于完成数量，确定待调整数量的任务个数M可以包括：计算完成数量与初始数量的比值，得到待调整数量的任务个数M，其中，初始数量为服务器初始提供的每个任务的任务数量。

可选地，初始数量可以为奇数，增加M个任务的回收量时，可以分别为每个任务增加偶数个回收量，若对于每个回收量的总数都是奇数，便于统计每个任务执行的准确率。

例如，已答过题的总答题次数(即总回收量)为P，M＝P/q，其中，q为每个任务的预设的回收量，对已答过的题目中的M道题(M个任务)，增加回收量q+o，其中，o为增加的回收量。这里的P＝v*t，v为答题速度，t为总的答题时长。

通过上述实施例，增加剩余总次数之后，每个数据标注任务的统计结果会发生变化，通过增加任务的回收量可以提高任务的执行准确率。

例如，一个任务的预定执行次数可以为25次，若已经完成25次，20次的答案是“是”，5次的答案是“否”，则统计的正确率为80％，且统计出的任务的执行结果为“是”。增加剩余次数之后，可以增加该任务的回收量，若增加次数为10次，回收所有的结果之后，答“是”的结果数量可能还维持在20次，答“否”的次数可以变为15次，这时，统计的正确率变为57％，统计的任务的执行结果为“是”，虽然结果没有发生变化，但是正确率发生了变化。

若增加次数为30次，回收所有的结果之后，答“是”的结果数量可能还维持在20次，答“否”的次数可以变为35次，这时，统计的正确率变为63％，统计的任务的执行结果为“否”，这时结果发生了变化，正确率也发生了变化。

由上述分析可知，随着数回收量的增加，可以使得任务的回收量覆盖率和正确率发生变化，这对于任务发布方来讲，提高了任务的标注正确率。

在上述实施例中，客户端可以为多个，服务器可以获取多个客户端完成的任务的平均速度，该平均速度可以为上述的任务完成的速度，其中，服务器可以将以一个预定的调整周期为单位，监控每个调整周期内的任务完成情况，通过比较每个调整周期的尚未完成的任务数量和预估数量，可以确定监控每个调度时长内，尚未完成的任务的任务数量是否充足，若不充足，则可以补充尚未完成的任务的数量，以满足用户做任务的需求。

由上述分析，增加任务的数量，可以提高任务的最终准确率，所以即便是所有任务的回收量和准确率均已达到预期，也可以增加回收量，以进一步提高准确率和覆盖率。

根据本申请的上述实施例，步骤S208，服务器根据完成任务的时长确定预定时间段内任务完成的速度可以包括：服务器获取完成的任务的完成数量；计算完成数量与完成时长的比值，得到任务完成的速度。

利用历史执行任务的历史总次数(即上述的完成数量)和历史时长(即上述的完成时长)的比值，确定客户端执行任务的历史执行速度。上述的执行速度也可以是多个调度时长内执行任务的执行速度的平均值，如，每个监控采样时间点内的总答题数/采样时间。

下面详述上述实施例，如图3所示，该实施例可以通过如下步骤实现：

步骤S301：获取各个调整周期的任务完成的完成数量。

步骤S302：获取各个调整周期的完成的任务的完成时长。

可以将每个历史调度时长(即上述的调整周期)内的完成数量与每个历史调度时长的比值作为每个历史调度时长内执行任务的速度。

步骤S303：计算所有历史调度时长内执行任务的速度的平均值，得到上述的平均速度。

步骤S304：根据任务完成的速度，预估当前调度时长内执行任务的预估数量。

本申请上述各个实施例中的调度时长等同于调度周期。

步骤S305：在尚未执行的任务的数量未超过预估数量的情况下，增加任务的数量。

该两个步骤的实现方式与上述实施例中的实现方式一致，在此不再赘述。

具体地，在增加任务的数量之前，可以确定增加的数量，可选地，该增加的数量可以为预先设置的值，也可以计算得到，例如，可以计算尚未完成的任务的数量与预估数量的差值，并获取待增加执行次数的M个任务，将差值与M个任务的比值确定为增加的数量Q，将该M个任务中每个任务的数量增加该增加的数量Q。

在上述实施例中，只要是任务结束时间未到，均可以增加。

在服务器至少根据任务完成的速度对提供的任务数量进行调整之后，方法还可以包括：服务器获取完成的任务的完成准确率；在完成准确率达到预期准确率的情况下，服务器停止提供任务。

如图4所示，该实施例可以通过如下步骤实现：

步骤S401：获取在预定时间段内任务完成的速度。

步骤S402：根据预定时间段内任务完成的速度，预估当前调度时长内完成任务的预估数量。

具体地，可以将速度v和当前调度时长t做乘积，得到当前调度时长内执行任务的预估总次数。

步骤S403：获取尚未执行任务的数量。

步骤S404：比较尚未执行任务的数量与预估数量。

其中，在比较出尚未执行任务的数量小于预估数量的情况下，执行步骤S406；在比较出尚未执行任务的数量不小于预估数量的情况下，执行步骤S405。

步骤S405：保持任务的数量不变。

步骤S406：增加提供的任务的数量。

步骤S407：停止提供达到预期准确率的任务。

停止提供达到预期准确率的任务可以通过不在向客户端发送该任务来实现，也可以在该任务上加上已达预期准确率的标签。

在上述实施例中，关闭已达预期准确率的任务，可以将尚未达到准确率的任务发放给客户端，以使得提高更多的任务的准确率和覆盖率。

根据本申请的上述实施例，获取完成的任务的完成准确率包括：服务器获取完成的任务的完成信息，其中，完成信息中包含完成任务的客户端信息和输入信息，客户端信息中包括客户端完成任务的完成准确率；若客户端的完成准确率小于预定准确率，则服务器丢弃完成信息中客户端的输入信息，得到更新后的完成信息；基于更新后的完成信息计算完成的任务的准确率。

通过上述实施例，可以将准确率较低的客户端做的任务从完成信息中剔除，保留一些准确率较高的客户端执行任务的结果(即上述的输入信息)，从而可以提高统计任务的准确率。

具体地，服务器在收集到至少一个客户端完成的任务的完成信息之后，统计完成信息中的客户端的完成准确率，将完成准确率低于预定准确率的客户端的输入信息从完成信息中剔除，得到更新后的完成信息，并基于更新后的完成信息计算完成的任务的准确率。

在一个可选的实施例中，服务器提供多个任务可以包括：服务器将所有待提供的任务分成多个任务集；服务器依次提供任务集中的任务。

通过上述实施例，将大量的任务分解成若干区块(即上述的任务集)，对每个区块中任务执行上述的处理方案，可以提高优先准确率，再提升覆盖率的方式，减少整个标注任务的时间和人力成本，提高整体任务的标注效率。

下面以标注任务为例结合图5详述本申请实施例，如图5所示，该实施例可以通过如下步骤实现，该实施例中，该实施例中的可以通过监控模块51、报警模块53和调度模块55完成，该实施例中的答题是指通过任务的输入接口输入信息，对于客户端来讲，是指接收通过任务的输入接口输入的信息。具体地：

步骤S501：采集调度时长内答题数。

步骤S502：获取每个调度时长。

步骤S503：计算每个调度时长内的答题速度。

将每个调度时长内的答题数量比上调度时长得到答题速度。

步骤S504：计算历史调度时长内的平均答题速度。

计算所有答题速度的平均值，得到平均答题速度v(即上述的执行速度)。

在该实施例中，假设有N个题目需要标注，首先确定每个题目需要的回收量(奇数)，例如回收量为q，则总回收量为N*q。确定一个监控采样时间t，比如5s，每5秒监控下答题速度。先投放N*q/s个题，小体量试探用户答题速度。把所有的题数切分成s份。计算每个监控采样时间点内的动态答题速度(每个监控采样时间点内的总答题数/采样时间)。在每个监控采样时间点，计算截止上一个监控采样时间点的动态平均答题速度v。

步骤S505：判断目前剩余题目数是否小于预估题目数。

若是，则执行步骤S506；若否，则返回步骤S504。

步骤S506：生成报警通知。

根据上述步骤可以得到上个监控采样时长的动态平均答题速度v，如果目前剩余的题目数<v*t(此处的t为当前调度时长)，说明在下个监控采样时间点，题目数即将不足，需要立即调度新的题目，且立即报警。

步骤S507：增加已答题的回收量。

步骤S508：关闭达到预期准确率的题目。

步骤S509：判断是否所有题目已经达到预期准确率。

若是，则执行步骤S510；若否，则返回步骤S507。

步骤S510：补充题目。

步骤S511：判断是否所有题目的回收量已满。

若是，则执行步骤S512；若否，则返回步骤S507。

步骤S512：增加已答题目的回收量。

步骤S513：关闭达到预期准确率的题目。

步骤S514：判断是否达到任务结束时间。

若是，则执行步骤S515，结束任务。若否，则返回步骤S512。

在上述实施例中，可以增加回(偶数)o，确保增加后的回收量也是个奇数。增加已答过题的回收量，M＝v*t/q，对已答过的题目(至少有一个回收量)中的M道题，增加回收量q+o，并关闭达到预期准确率的题目。然后，循环a)、b)步骤，直到所有的题目都达到预期准确率(先做完所有该区块的题目)，补充题目时，可以补充P*n/s(开始做下一区块的题目)。这里的v为答题速度，t为已经答题的时长。

重复循环a)、b)、c)、d)，直到所有的回收量已满(所有的区块题目都做完了，没有题了)。

然后，重复循环a)、b)，直到任务结束为止(没题之后就一直继续增加回收量，直到任务结束)。

通过上述实施例，可以将大体量题目被分解成若干区块，每个区块有一套智能的监控调度体系；每个区块根据动态的速度增加回收量；关闭已达预期准确率的题目；直到满足预期覆盖率；循环执行调度策略，直到所有区块的题目都满足预期覆盖率后。再继续动态回收量，直到任务结束；本申请可使大量用户能集中的覆盖题目，促使快速达到准确率，然后再换一批新的题目。优先准确率，再提升覆盖率的方式，减少整个标注任务的时间和人力成本，提高整体任务的标注效率。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

根据本申请的上述实施例，提供了一种任务的处理装置，该装置包括如图6所示的：提供单元61，用于提供多个任务，其中，多个任务能够在客户端上展示，多个任务中的每个任务包括一个或多个接收输入的输入接口；接收单元63，用于接收至少一个客户端反馈的输入信息，其中，输入信息为客户端通过任务的输入接口输入的信息；第一确定单元65，用于根据输入的信息，确定完成的任务以及完成任务的时长，其中，服务器接收到通过任务的输入接口反馈的输入信息表示任务的完成；第二确定单元67，用于根据完成任务的时长确定预定时间段内任务完成的速度；调整单元69，用于至少根据任务完成的速度对提供的任务数量进行调整。

进一步地，调整单元可以包括：第一确定模块，用于根据任务完成的速度确定至少一个客户端在预定时间段内完成任务的预估数量；第一获取模块，用于获取服务器提供的任务中尚未完成的任务数量；第一检测模块，用于检测尚未完成的任务数量是否小于预估数量；调整模块，用于若检测出尚未完成的任务数量小于预估数量，则对提供的任务数量进行调整。

具体地，调整模块包括：获取子模块，用于获取完成的任务的完成数量；确定子模块，用于基于完成数量，确定待调整数量的任务个数M，其中，M为自然数；增加子模块，用于增加多个任务中M个任务的任务数量。

根据本申请的上述实施例，确定子模块具体用于：计算完成数量与初始数量的比值，得到待调整数量的任务个数M，其中，初始数量为服务器初始提供的每个任务的任务数量。

可选地，第一确定模块具体用于：将任务完成的速度和预定时间段的时长的乘积，作为预估数量。

根据本申请的上述实施例，第二确定单元可以包括：第二获取模块，用于服务器获取完成的任务的完成数量；第一计算模块，用于计算完成数量与完成时长的比值，得到任务完成的速度。

在一个可选的实施例中，装置还可以包括：第一获取单元，用于在服务器至少根据任务完成的速度对提供的任务数量进行调整之后，服务器获取完成的任务的完成准确率；停止单元，用于在完成准确率达到预期准确率的情况下，服务器停止提供任务。

进一步地，第一获取单元具体用于：服务器获取完成的任务的完成信息，其中，完成信息中包含完成任务的客户端信息和输入信息，客户端信息中包括客户端完成任务的完成准确率；若客户端的完成准确率小于预定准确率，则服务器丢弃完成信息中客户端的输入信息，得到更新后的完成信息；基于更新后的完成信息计算完成的任务的准确率。

需要进一步说明的是，提供单元具体用于：服务器将所有待提供的任务分成多个任务集；服务器依次提供任务集中的任务。

本实施例中所提供的各个模块与方法实施例对应步骤所提供的使用方法相同、应用场景也可以相同。当然，需要注意的是，上述模块涉及的方案可以不限于上述实施例中的内容和场景，且上述模块可以运行在计算机终端或移动终端，可以通过软件或硬件实现。

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于保存上述实施例一所提供的任务的处理方法所执行的程序代码。

可选地，在本实施例中，上述存储介质可以位于计算机网络中计算机终端群中的任意一个计算机终端中，或者位于移动终端群中的任意一个移动终端中。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

服务器提供多个任务，其中，多个任务能够在客户端上展示，多个任务中的每个任务包括一个或多个接收输入的输入接口；服务器接收至少一个客户端反馈的输入信息，其中，输入信息为客户端通过任务的输入接口输入的信息；服务器根据输入的信息，确定完成的任务以及完成任务的时长，其中，服务器接收到通过任务的输入接口反馈的输入信息表示任务的完成；服务器根据完成任务的时长确定预定时间段内任务完成的速度；服务器至少根据任务完成的速度对提供的任务数量进行调整。

在上述实施例中，当前调度时长为当前时刻所在的时间段或者下一个调度时间段，本申请实施例，对此不做限定。

具体地，在比较出剩余总次数未超过预估总次数的情况下，增加剩余总次数；在比较出剩余总次数大于预估总次数的情况下，则维持剩余总次数不变。

可选地，可以在比较出剩余总次数未超过预估总次数的情况下，生成报警通知，该报警通知用于通知任务的剩余总次数不足，补充回收量。

可选地，可以通过服务器上的监控模块获取客户端执行任务的执行速度；并通过报警模块，预估当前调度时长内执行任务的预估总次数，并在执行任务的剩余总次数未超过预估总次数的情况下，生成上述的报警通知，该报警通知发送至调度模块，调度模块接收到该报警通知，增加剩余总次数。

需要说明的是，只要剩余总次数未超过预估总次数，就可以增加该剩余总次数，如在当前调度时长的结束时刻为整个任务的结束时刻时，若当前调度时长中的剩余总次数已经为零，也需要增加任务的回收量。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (12)

1.一种任务的处理系统，其特征在于，包括：

服务器，用于提供多个任务，其中，所述多个任务中的每个任务包括一个或多个接收输入的输入接口；

客户端，用于展示所述服务器提供的多个任务，并接收通过任务的输入接口输入的输入信息，并将接收到的输入信息发送至服务器；

所述服务器还用于根据所述输入的信息，确定完成的任务以及完成任务的时长，其中，所述服务器接收到通过任务的输入接口反馈的输入信息表示所述任务的完成；并根据完成任务的时长确定预定时间段内任务完成的速度；调整单元，用于至少根据所述任务完成的速度对提供的任务数量进行调整。

2.一种任务的处理方法，其特征在于，包括：

服务器提供多个任务，其中，所述多个任务能够在客户端上展示，所述多个任务中的每个任务包括一个或多个接收输入的输入接口；

所述服务器接收至少一个客户端反馈的输入信息，其中，所述输入信息为所述客户端通过任务的输入接口输入的信息；

所述服务器根据所述输入的信息，确定完成的任务以及完成任务的时长，其中，所述服务器接收到通过任务的输入接口反馈的输入信息表示所述任务的完成；

所述服务器根据完成任务的时长确定预定时间段内任务完成的速度；

所述服务器至少根据所述任务完成的速度对提供的任务数量进行调整。

3.根据权利要求1所述的方法，其特征在于，所述服务器至少根据所述任务完成的速度对提供的任务数量进行调整包括：

所述服务器根据所述任务完成的速度确定至少一个客户端在调整周期内完成任务的预估数量；

所述服务器获取所述服务器提供的任务中尚未完成的任务数量；

所述服务器检测尚未完成的任务数量是否小于所述预估数量；

若检测出所述尚未完成的任务数量小于所述预估数量，则所述服务器对提供的任务数量进行调整。

4.根据权利要求3所述的方法，其特征在于，所述服务器对所述尚未完成的任务数量进行调整包括：

所述服务器获取所述完成的任务的完成数量；

所述服务器基于所述完成数量，确定待调整数量的任务个数M，其中，M为自然数；

所述服务器增加所述多个任务中M个任务的任务数量。

5.根据权利要求4所述的方法，其特征在于，所述服务器基于所述完成数量，确定待调整数量的任务个数M包括：

计算所述完成数量与初始数量的比值，得到所述待调整数量的任务个数M，

其中，所述初始数量为所述服务器初始提供的每个任务的任务数量。

6.根据权利要求3所述的方法，其特征在于，所述服务器根据所述任务完成的速度确定至少一个客户端在调整周期内完成任务的预估数量包括：

将所述任务完成的速度和所述调整周期的时长的乘积，作为所述预估数量。

7.根据权利要求2所述的方法，其特征在于，所述服务器根据完成任务的时长确定预定时间段内任务完成的速度包括：

所述服务器获取所述完成的任务的完成数量；

计算所述完成数量与所述完成时长的比值，得到所述任务完成的速度。

8.根据权利要求2所述的方法，其特征在于，在所述服务器至少根据所述任务完成的速度对提供的任务数量进行调整之后，所述方法还包括：

所述服务器获取完成的任务的完成准确率；

在所述完成准确率达到预期准确率的情况下，所述服务器停止提供所述任务。

9.根据权利要求8所述的方法，其特征在于，获取完成的任务的完成准确率包括：

所述服务器获取完成的任务的完成信息，其中，所述完成信息中包含完成所述任务的客户端信息和输入信息，所述客户端信息中包括客户端完成任务的完成准确率；

若所述客户端的完成准确率小于预定准确率，则所述服务器丢弃所述完成信息中所述客户端的输入信息，得到更新后的完成信息；

基于更新后的完成信息计算完成的任务的准确率。

10.根据权利要求2至9中任意一项所述的方法，其特征在于，服务器提供多个任务包括：

所述服务器将所有待提供的任务分成多个任务集；

所述服务器依次提供任务集中的任务。

11.一种任务的处理装置，其特征在于，包括：

提供单元，用于提供多个任务，其中，所述多个任务能够在客户端上展示，所述多个任务中的每个任务包括一个或多个接收输入的输入接口；

接收单元，用于接收至少一个客户端反馈的输入信息，其中，所述输入信息为所述客户端通过任务的输入接口输入的信息；

第一确定单元，用于根据所述输入的信息，确定完成的任务以及完成任务的时长，其中，所述服务器接收到通过任务的输入接口反馈的输入信息表示所述任务的完成；

第二确定单元，用于根据完成任务的时长确定预定时间段内任务完成的速度；

调整单元，用于至少根据所述任务完成的速度对提供的任务数量进行调整。

12.根据权利要求11所述的装置，其特征在于，所述调整单元包括：

第一确定模块，用于根据所述任务完成的速度确定至少一个客户端在调整周期内完成任务的预估数量；

第一获取模块，用于获取所述服务器提供的任务中尚未完成的任务数量；

第一检测模块，用于检测尚未完成的任务数量是否小于所述预估数量；

调整模块，用于若检测出所述尚未完成的任务数量小于所述预估数量，则对提供的任务数量进行调整。