Task distribution method, task execution method and device

Abstract

The application provides a task distribution method and device and a task execution method and device, and relates to the technical field of Internet. The task distribution method comprises the following steps: obtaining a task initiation request triggered by a first object; in response to the task initiation request, obtaining a waiting time length corresponding to a target retention probability; wherein the waiting time length is obtained according to the probability that the current task corresponding to the task initiation request is not cancelled by the first object at different times; and according to the waiting time length, selecting a second object for executing the current task at a target time, and returning the information of the second object. The application can determine the corresponding waiting time interval for each task from the perspective of the task.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a task distribution method, a task execution method, and an apparatus. Background Technology

[0002] An aggregation service platform refers to a business model that integrates product or service information from different merchants, providing consumers with diversified choices. Aggregation service platforms not only integrate product information but also optimize consumer experience and marketing efficiency. After receiving a user's task request, an aggregation service platform can distribute the task within a suitable waiting time interval and acquire suppliers to perform the task. For example, after receiving a passenger's ride request, a ride-hailing aggregation platform needs to dispatch the most suitable driver to provide the service. This dispatching process corresponds to the passenger's waiting time, i.e., the aforementioned waiting time interval.

[0003] Waiting time interval is a crucial evaluation metric for aggregation service platforms. Related solutions all use reducing the average waiting time interval as a basic standard or optimization goal. However, a shorter waiting time interval is not always better. Delayed matching strategies have been widely applied in the online matching field. For example, in the ride-hailing "passenger-driver" matching field, passengers are allowed to wait for a period of time before being matched with a driver. Increasing the waiting window when market supply and demand are tight can improve carpooling rates and reduce driver idle time and total passenger waiting time. Therefore, there is a trade-off in choosing the waiting time interval. On the one hand, intentionally extending this interval can expand the potential matching candidate set and improve operational efficiency. More suitable "passenger-driver" matching allows drivers to pick up their respective passengers faster; on the other hand, excessively long waiting times may increase the driver's empty-run costs, and in the worst case, may cause passengers to abandon the service. Research shows that optimizing the waiting time interval can achieve better overall results.

[0004] How to further optimize the waiting time interval during the transaction matching process of the aggregation service platform is an urgent issue to be addressed. Summary of the Invention

[0005] This application provides a task distribution method, a task execution method, and an apparatus, which can determine the corresponding waiting time interval for each task from the perspective of the task.

[0006] In a first aspect, embodiments of this application provide a task distribution method, including:

[0007] The task triggered by the first object initiates a request;

[0008] In response to the task initiation request, the waiting time corresponding to the target retention probability is obtained; wherein, the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times;

[0009] Based on the waiting time, select a second object to execute the current task at the target time and return information about the second object.

[0010] Secondly, embodiments of this application provide a task execution method, including:

[0011] In response to the triggering operation of the first object, a task initiation request is sent to the server;

[0012] Obtain the target time from the server, the target time being determined based on the waiting time corresponding to the target retention probability; wherein, the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times;

[0013] Display the target time.

[0014] Thirdly, a task distribution device is provided, comprising:

[0015] The first acquisition unit is used to acquire the task initiation request triggered by the first object;

[0016] The second acquisition unit is used to acquire the waiting time corresponding to the target retention probability in response to the task initiation request; wherein the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times;

[0017] The selection unit is used to select a second object to execute the current task at a target time based on the waiting time.

[0018] The return unit is used to return information about the second object.

[0019] Fourthly, a task execution device is provided, comprising:

[0020] The sending unit is where the user responds to the triggering operation of the first object by sending a task initiation request to the server;

[0021] A receiving unit is configured to acquire a target time from a server, wherein the target time is determined based on a waiting time corresponding to the target retention probability; wherein the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times;

[0022] The display unit is used to display the target time.

[0023] Fifthly, embodiments of this application provide an electronic device, including: a processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to perform the method as described in the first aspect, or the method as described in the second aspect.

[0024] In a sixth aspect, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method as described in the first aspect or the method as described in the second aspect.

[0025] In a seventh aspect, embodiments of this application provide a computer program product including computer program instructions that cause a computer to perform the method as described in the first aspect or the method as described in the second aspect.

[0026] Eighthly, embodiments of this application provide a computer program that causes a computer to perform the method as described in the first aspect or the method as described in the second aspect.

[0027] The above technical solution obtains the waiting time corresponding to the target retention probability in response to the task initiation request triggered by the first object. Since the waiting time is obtained based on the probability that the current task will not be canceled by the first object at different times, the probability of the task being canceled under different time conditions can be considered to determine the corresponding task waiting time for the current task. This allows for the calculation of different waiting times for different tasks, thereby determining the corresponding waiting time interval for each task from the task perspective and optimizing the waiting time interval of the aggregation service platform during the transaction matching process. Attached Figure Description

[0028] Figure 1A A flowchart illustrating the process of providing ride-hailing services to a ride-hailing aggregation service platform;

[0029] Figure 1B Provide a timeline diagram of the ride-hailing service process for ride-hailing aggregation service platforms;

[0030] Figure 2 This is a schematic diagram illustrating an application scenario of an embodiment of this application;

[0031] Figure 3 This is a schematic flowchart illustrating a task distribution method according to an embodiment of this application;

[0032] Figure 4 This is a schematic flowchart illustrating another task distribution method according to an embodiment of this application;

[0033] Figure 5 This is a schematic flowchart illustrating another task distribution method according to an embodiment of this application;

[0034] Figure 6 This is a schematic flowchart of a menu selection method according to an embodiment of this application;

[0035] Figure 7A An illustration of the page where users select their preferred transportation providers;

[0036] Figure 7B A diagram illustrating the page where the aggregation service platform determines the menu selection time;

[0037] Figure 8 This is a schematic diagram of a system architecture according to an embodiment of this application;

[0038] Figure 9 This is a schematic flowchart illustrating a risk prediction model training method according to an embodiment of this application;

[0039] Figure 10 This is a schematic flowchart illustrating a task execution method according to an embodiment of this application;

[0040] Figure 11 This is a schematic flowchart of a task distribution device according to an embodiment of this application;

[0041] Figure 12 This is a schematic block diagram of a risk prediction model training device according to an embodiment of this application;

[0042] Figure 13 This is a schematic flowchart of a task execution device according to an embodiment of this application;

[0043] Figure 14 This is a schematic block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0044] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0045] It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A. In one implementation, B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0046] In the description of this application, unless otherwise stated, "at least one" means one or more, and "multiple" means two or more. Additionally, "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0047] It should also be understood that the descriptions of "first", "second", etc. appearing in the embodiments of this application are only for illustration and to distinguish the objects being described, and there is no order to them. They do not indicate any special limitation on the number of devices in the embodiments of this application, and cannot constitute any limitation on the embodiments of this application.

[0048] It should also be understood that specific features, structures, or characteristics relating to embodiments in the specification are included in at least one embodiment of this application. Furthermore, these specific features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0049] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such processes, methods, products, or devices.

[0050] First, let me introduce the relevant terminology used in this application.

[0051] Ride-hailing service providers: Ride-hailing service providers, upon receiving a passenger's request for a ride, can dispatch the most suitable driver to provide ride-hailing services.

[0052] Ride-hailing aggregation service platform: By aggregating multiple ride-hailing service providers through a unified platform, passengers can request services from multiple ride-hailing service providers at the same time.

[0053] Order dispatch: The act of an aggregation service platform notifying ride-hailing service providers to provide services after receiving a passenger's request.

[0054] Order acceptance by ride-hailing service providers: After receiving order assignment information from the aggregation service platform, ride-hailing service providers proactively provide ride-hailing services.

[0055] After receiving a passenger's ride request, ride-hailing aggregation platforms need to dispatch the most suitable driver to provide the service. Passenger waiting time is a crucial evaluation metric in this process. Related solutions all aim to reduce the average passenger waiting time as a basic standard or optimization goal, and different ride-hailing matching mechanisms have been studied.

[0056] However, shorter waiting times are not always better. Delayed matching strategies have been widely applied in online matching, such as dating apps and organ donation systems. In the ride-hailing "passenger-driver" matching field, related solutions introduce Dynamic Waiting (DW), allowing passengers to wait for a period of time after a request before being matched with a driver. Increasing the waiting window when market supply and demand are tight can improve carpooling rates and reduce driver idle time and total passenger waiting time. Related solutions also propose a two-stage ACER (Actor critic with experience replay) model: dividing the time into discrete time steps and spatial ranges, within each time step, based on the system state matrix, using the negative value of the waiting cost increment in that time step as the reward function, determining whether bipartite graph matching needs to be performed in the next time step, and using reinforcement learning methods to optimize the time interval.

[0057] Therefore, there are certain trade-offs in choosing the time interval. On the one hand, intentionally extending the time interval can expand the potential matching candidate set and improve operational efficiency. A more suitable "passenger-driver" match allows drivers to pick up their respective passengers more quickly. On the other hand, excessively long waiting times may increase the driver's empty-running costs, and in the worst case, may cause passengers to choose not to go. Existing research has shown that optimizing the time interval can achieve better results globally.

[0058] The aggregation service platform brings together multiple ride-hailing providers through a unified platform. Passengers can request services from multiple providers simultaneously. The platform dispatches orders to these providers, who may or may not accept the order. The platform then selects from the accepting providers, and the passenger ultimately decides whether to accept the service. A general overview of the process is shown below. Figure 1A As shown, it includes steps S1 to S5.

[0059] Before passenger demand is met, each transportation provider can accept orders at any time, that is, provide the aggregation service platform with the information of a driver. For a single passenger demand, each transportation provider can accept an order at most once. The aggregation service platform is responsible for selecting the most suitable transportation for the passenger; this step is called order selection. Since each order acceptance has a timeout limit, the platform must complete the process before the timeout expires. The timeline is illustrated below. Figure 1B As shown. In Figure 1BIn the process, requests were made to four freight providers. Until the order was executed, two freight providers (Provider 1 and 3) accepted the order, so the aggregation service platform will choose between these two providers. It should be noted that Freight Provider 4 closed its order after the order selection time and will no longer be selected.

[0060] Aggregator service platforms do not directly dispatch drivers: Suppose that a transportation provider 1 assigns a driver to passenger A, then the aggregation service platform cannot assign that driver to another passenger B. Therefore, its matching process cannot be modeled as a bipartite graph matching problem, but a similar time interval trade-off still exists—after a passenger initiates a ride request, a longer waiting time interval can expand the potential set of transportation candidates, allowing for the selection of more suitable transportation, but it may also cause passengers to lose patience and give up waiting.

[0061] Most existing solutions adopt a systemic perspective, focusing on optimizing global metrics. They determine whether a matching process is needed at the next moment from the system perspective of the aggregation service platform, matching a group of customers with needs with suppliers to perform the tasks. However, these solutions rely on simulation environments or ride-sharing simulators. Current simulation environments often oversimplify the consideration of complex real-world factors. For example, they assume the driver remains stationary or that users have unlimited patience. Therefore, further optimizing the waiting time of the aggregation service platform during the transaction matching process is a pressing issue.

[0062] In view of this, embodiments of this application provide a task distribution method, apparatus, device, and storage medium, applied to a server, such as an aggregation service platform, which can determine the corresponding waiting time interval for each task from the perspective of the task.

[0063] Specifically, it can obtain the task initiation request triggered by the first object; in response to the task initiation request, obtain the waiting time corresponding to the target retention probability; wherein, the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times; based on the waiting time, select the second object to execute the current task at the target time, and return the information of the second object.

[0064] Therefore, in this embodiment of the application, by responding to the task initiation request triggered by the first object, the waiting time corresponding to the target retention probability is obtained. Since the waiting time is obtained based on the probability that the current task is not canceled by the first object at different times, the probability of the task being canceled under different time conditions can be considered to determine the corresponding task waiting time for the current task. Thus, different waiting times are calculated for different tasks, thereby realizing the determination of the corresponding waiting time interval for each task from the perspective of the task, and realizing the optimization of the waiting time interval of the aggregation service platform in the process of matching transactions.

[0065] Furthermore, embodiments of this application can also acquire the characteristics of the current task, input these characteristics into a risk prediction model, and utilize the risk prediction model to consider complex factors to obtain the probability that the current task will not be canceled at different times. Based on this, the waiting time corresponding to a given target retention probability is obtained. Since the risk prediction model can be based on the task's characteristic input rather than relying on a simplified simulation environment, the obtained probability of the task being canceled at different times can make full use of real-world data, considering not only whether the task will be canceled, but also the probability of canceling the task under different time conditions, thereby improving the accuracy of the waiting time interval.

[0066] This application also provides a method, apparatus, device, and storage medium for task execution, applied to a client, which enables the client to display the waiting time corresponding to the task.

[0067] Specifically, in response to the triggering operation of the first object, a task initiation request can be sent to the server; the target time can be obtained from the server, which is determined based on the waiting time corresponding to the target retention probability; wherein, the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times; and the target time can be displayed.

[0068] Therefore, in this embodiment of the application, a task sending request is sent to the server in response to the triggering operation of the first object, and a target time is obtained. This target time is determined based on the waiting time corresponding to the target retention probability, and then the target time is displayed. Since the waiting time is obtained based on the probability that the current task will not be canceled by the first object at different times, the probability of task cancellation under different time conditions can be considered to determine the corresponding task waiting time for the current task, and then the target time determined based on the waiting time is displayed, so that the user can perceive the waiting time of the corresponding task and improve the user experience.

[0069] Furthermore, in this task execution method, information about the second object executing the current task can be obtained, and the information about the second object can be displayed after the target time is reached.

[0070] The embodiments of this application can be applied to various aggregation service platforms, such as various task distribution platforms. For example, for a ride-hailing aggregation service platform, for each passenger request, the platform needs to wait for ride-hailing service providers to accept the order, and then select the best service for the passenger. This involves the issue of balancing the waiting time interval.

[0071] Specifically, the system can obtain an order request triggered by a first object (such as a passenger), and in response to the order request, obtain the waiting time corresponding to the target retention probability. The waiting time is obtained based on the probability that the current order is not canceled by the passenger at different times. Then, based on the waiting time, the system selects a second object (such as a transportation provider) to execute the current order at the target time and returns the information of the transportation provider.

[0072] Optionally, in response to a passenger-triggered order request, the characteristics of the current order can be obtained, and these characteristics can be input into a risk prediction model to obtain the probability that the current order will not be canceled by the first object at different times. Then, based on the probability that the current order will not be canceled at different times, the waiting time corresponding to the target retention probability can be obtained, and based on the waiting time, the transportation provider for the order can be selected at the target time (i.e., order selection). This application embodiment can use a risk prediction model to examine complex real-world factors, rather than relying on a simplified simulation environment, to obtain the probability that the current order will not be canceled at different times. Based on this probability, the waiting time corresponding to a given target retention probability can be obtained, thereby considering the probability of order cancellation under different time conditions to determine the waiting time of the order. This allows different waiting times to be calculated for different orders, enabling the ride-hailing aggregation service platform to determine a corresponding waiting time interval for each order (passenger) from the perspective of the order (or passenger), without being bound by a fixed waiting time interval, thus achieving a personalized experience for each individual.

[0073] In some embodiments, by determining the optimal waiting time interval for each order, it is possible to determine the optimal waiting time interval for each aggregated service demand from the passenger's perspective, thereby reserving a larger set of capacity candidates for passengers while minimizing passenger loss and providing passengers with the best choice.

[0074] In real-world datasets, the proportion of passengers canceling orders due to impatience is relatively small, posing a challenge for modeling. Modeling it as a binary classification problem of "whether to cancel" results in an extremely imbalanced classification problem with limited accuracy. However, this application's embodiment, through a risk prediction model, fully utilizes real-world data, considering not only whether passengers will cancel orders but also the probability of cancellation under different time durations, thereby improving the accuracy of waiting time intervals.

[0075] Additionally, on the client side, in response to a passenger's triggering action, an order request can be sent to the server, thereby obtaining a target time from the server. This target time is determined based on the waiting time corresponding to the target retention probability, which is obtained based on the probability that the current order will not be canceled by the passenger at different times. The target time is then displayed. Optionally, after the target time, the client can also display information about a second object. Therefore, this embodiment of the application can determine the optimal waiting time for each passenger's service request from the passenger's perspective and display the waiting time determined based on this waiting time to the passenger, thereby reducing passenger churn.

[0076] Figure 2 A schematic diagram illustrating an application scenario of an embodiment of this application is shown.

[0077] like Figure 2 As shown, this application scenario involves server 101, terminal devices 102 and 103, and terminal devices 102 and 103 can communicate with server 101 via a communication network. Server 101 can be a backend server for terminal devices 102 or 103.

[0078] For example, a terminal device can refer to a type of device that has rich human-computer interaction methods, internet access capabilities, typically runs various operating systems, and has strong processing capabilities. Terminal devices can be smartphones, tablets, laptops, desktop computers, wearable devices, in-vehicle devices, etc., but are not limited to these.

[0079] A server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. A server can also be a node in a blockchain.

[0080] There may be one or more servers. When there are multiple servers, at least two servers are used to provide different services, and / or at least two servers are used to provide the same service, such as providing the same service in a load-balanced manner. This application does not limit this.

[0081] Optionally, in this embodiment, terminal devices 102 and 103 are equipped with applications (APPs), including but not limited to various service APPs, such as ride-hailing service APPs, errand-running service APPs, etc. Terminal device 102 can be the requester of a service or task, and terminal device 103 can be the provider of a service or task.

[0082] Server 101 can provide aggregation services, such as a ride-hailing aggregation service platform or a task distribution service platform. For example, after receiving a task request from terminal device 102, server 101 can distribute the task within a suitable waiting time interval, such as distributing the task to at least one of terminal devices 103, and obtaining the supplier to perform the task from terminal device 103.

[0083] Terminal devices and servers can be connected directly or indirectly via wired or wireless communication, and this application does not limit this. This application does not limit the number of servers or terminal devices. The solution provided in this application can be implemented independently by the terminal device, independently by the server, or jointly by the terminal device and the server; this application does not limit this.

[0084] It should be understood that Figure 2 This is merely an illustrative example and does not specifically limit the application scenarios of the embodiments in this application. For example, Figure 2 Four terminal devices and one server are shown as an example, but other numbers of terminal devices and servers may be included in practice, and this application does not limit this.

[0085] In some embodiments, the first object can log in to the client on terminal device 102 and trigger a task initiation request. The client obtains the task initiation request and sends it to server 101. The aggregation service platform on server 101 can obtain the task initiation request and, in response, obtain the waiting time corresponding to the target retention probability, wherein the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times. Server 101 can also select a second object to execute the current task at a target time based on the waiting time and return the information of the second object. Server 101 can also return the target time to the client. Accordingly, the client page can display the information of the second object after the target time. The client page can also display the target time. Optionally, the second object can log in to the client on terminal device 103 and execute the current task in response to the task initiation request.

[0086] Therefore, this embodiment of the application obtains the waiting time corresponding to the target retention probability in response to a task initiation request triggered by a first object. Since the waiting time is obtained based on the probability that the current task will not be canceled by the first object at different times, the probability of task cancellation under different time conditions can be considered to determine the corresponding task waiting time for the current task. This allows for the calculation of different waiting times for different tasks, thereby determining the corresponding waiting time interval for each task from the task's perspective and optimizing the waiting time interval during the transaction matching process of the aggregation service platform. Furthermore, this embodiment of the application can display the target time determined based on the waiting time on the client, improving the user experience.

[0087] The technical solutions of the embodiments of this application will be described in detail below through some examples. The following embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0088] Figure 3 This is a schematic flowchart illustrating a task distribution method 300 according to an embodiment of this application. The method 300 can be executed by any electronic device with data processing capabilities; for example, the electronic device can be implemented as... Figure 2 The server in the application can further be an aggregation service platform within the server; this application does not limit this to such a case. Figure 3 As shown, the task distribution method 300 includes steps 310 to 330.

[0089] Step 310: Obtain the task initiation request triggered by the first object.

[0090] For example, the first object can log in to the client on a terminal device and trigger a task initiation request by performing input operations on the client. Correspondingly, the server-side aggregation service platform can obtain this task initiation request.

[0091] For example, the current task may include a ride-hailing order task. Correspondingly, the first object can be a passenger, the task initiation request can be a ride request, and the aggregation service platform can be a ride-hailing aggregation service platform. The second object can be a ride-hailing service provider. In this embodiment, multiple ride-hailing service providers are aggregated through a unified platform, allowing passengers to request services from multiple ride-hailing service providers simultaneously.

[0092] Optionally, the aggregation service platform can also respond to the task initiation request and obtain the characteristics of the current task.

[0093] Optionally, the features of the current task may include at least one of the following: task features, the selection features of the first object for the current task, and object features. The features of the current task can characterize the complex real-world factors corresponding to the current task.

[0094] Taking the current task as a ride-hailing order as an example, task characteristics are order characteristics, including but not limited to trip distance, the hour of the day in which the order is placed, and the week of the week in which the order is placed. Selectable characteristics include but are not limited to selecting the capacity quotient, whether to select carpooling, whether to select taxi, whether to select comfort (premium) mode, whether to reduce or increase the selection, etc. Object characteristics are the characteristics of the first object requesting the task, including but not limited to ride-hailing frequency, such as high, low, medium, none, etc.

[0095] Optionally, the features of the current task may also include other features, such as the city features where the task is located, including but not limited to city codes.

[0096] Step 320: In response to the task initiation request, obtain the waiting time corresponding to the target retention probability; wherein, the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times.

[0097] Specifically, after receiving a task initiation request, the aggregation service platform can respond by obtaining the waiting time corresponding to a given target retention probability. The target retention probability is the probability that the task will remain in an uncancelled state within a specific time period. For example, if the target retention probability for each task is 97%, it means that the probability of the task remaining uncancelled within a specific time period is 97%, or the probability of the task remaining uncancelled within the time period corresponding to the waiting time is 97%.

[0098] Optionally, in step 320, the specific time corresponding to the given target retention probability, i.e., the corresponding waiting time, can be calculated based on the probability that the current task is not canceled by the first object at different times. Optionally, the probability that the current task is not canceled by the first object at different times includes the probability that the current task is not canceled by the first object at time t, or the probability that the current task is not canceled by the first object from time 0 to time t, or the change of the probability that the current task is not canceled by the first object over time, where t is a time variable. Specifically, the probability that the current task is canceled by the first object gradually increases with time.

[0099] In some embodiments, features can be input into a risk prediction model to obtain the probability that the current task will not be canceled by the first object at different times, and then the waiting time can be determined based on the probability that the current task will not be canceled at different times.

[0100] Specifically, the risk prediction model is used to determine the probability that the current task will not be canceled by the first object at different times, based on input characteristics, i.e., complex real-world factors.

[0101] Optionally, risk prediction models can employ survival analysis to determine the relationship between event occurrence and time. In medicine, survival analysis is a very common and important analytical method. For example, studying the mortality probability of a certain type of cancer patient involves collecting patient data, including whether the patient died within a certain timeframe and the time of death (i.e., survival time). Survival analysis studies the relationship between event occurrence and time under different conditions, considering not only whether the event occurred but also the duration of its occurrence. It is a statistical method that combines the outcome of an event with the time elapsed to achieve that outcome. It is suitable for scenarios where censored data exists, i.e., not every record shows the occurrence of the event.

[0102] In this embodiment, "the user loses patience and cancels the task" is the event that needs to be considered. Not every task can reach the limit of the user's patience; most tasks are successfully assigned and proceed to the next stage. Furthermore, this embodiment not only needs to consider whether this event will occur, but also when it will occur, or the probability of the event occurring at different times.

[0103] In some embodiments, risk prediction models are derived from risk regression models, such as the Cox proportional hazards regression model. Risk regression models utilize statistical inference methods that assume a linear combination of covariates with respect to the logarithmic risk of an event. This assumption is known as the linear proportional hazards condition. Therefore, risk regression models may fail to capture complex nonlinear relationships. Based on this, neural network models can be introduced to capture complex nonlinear relationships.

[0104] See below. Figure 4 Taking a risk prediction model, including a neural network model, as an example, the training process of the risk prediction model, 321 to 324, is described below. It should be understood that the following model training processes 321 to 324 are merely examples, and the embodiments of this application do not limit the method of training the risk prediction model.

[0105] Step 321: Obtain the training sample set, which includes the task features and task labels of the task samples; wherein, the task labels include the final time of the task sample and whether it is ultimately canceled.

[0106] For example, the training sample set may include multiple task samples, and each task sample may include task features and task labels. The task features can be found in the description of features above.

[0107] Taking a ride-hailing order task as an example, for each online order, various features can be extracted, including but not limited to order features, selection features, object features, and city features. Here, x can be used to represent the extracted features. Then, for each online order, the time t when the object initiates the request can be recorded.request The final time T and the category E indicating whether the order is ultimately cancelled. At the final time T, there are only two possibilities: (1) the object loses patience and cancels the order; (2) the order is successfully selected, and the object enters the decision-making environment. For example, if the first scenario applies, then E = 1; otherwise, E = 0.

[0108] Step 322: Input the task features into the initial risk prediction model to obtain the probability that the task sample will be canceled at each event time.

[0109] For example, the task feature x extracted in step 321 can be input into the initial risk prediction model for risk assessment to obtain the probability that the task sample will be canceled at each event time.

[0110] In some feasible approaches, taking a risk prediction model based on a risk regression model as an example, the model assumes that the risk function λ(t) is related to the baseline risk function λ0(t) and is determined by the task feature x. For example, the risk function can be expressed as the following formula (1):

[0111] λ(t|x)=λ0(t)e h(x) (1)

[0112] Where λ(t|x) represents the risk function at time t when the input feature is x, e h(x) This is the risk score. Where r(x) = e h(x) This refers to the risk score.

[0113] Optionally, when the risk prediction model includes a neural network model, e h(x) The output of the aforementioned neural network model can be used to capture complex nonlinear relationships.

[0114] Optionally, the probability of a task sample being canceled at each event time can be determined based on the risk score.

[0115] Step 323: Based on the probability of task samples being canceled at each event time and the task label, obtain the loss function.

[0116] Specifically, the loss function can be calculated as the optimization objective of the risk prediction model based on the probability of the task sample being canceled at each event time, the category of whether the task sample is ultimately canceled, and the final time.

[0117] It should be understood that the embodiments of this application do not limit the method of determining the loss function based on the probability of the task sample being canceled at each event time and the task label.

[0118] In some feasible implementations, the loss function can be derived based on the probability of canceling a task sample that is ultimately canceled at each event time and the probability of canceling a task sample in the risk set at each event time. Here, the risk set refers to the set of samples that are still at risk (not yet at the final event time).

[0119] Specifically, the loss function can be a partial likelihood function. The partial likelihood function is a variation of the likelihood function under specific conditions, such as censored data. For example, while the likelihood function represents the probability of observing data given parameters, the partial likelihood function is the likelihood function for the sample data consisting of the observable data, given censored data.

[0120] In one possible implementation, the product of the probabilities of a first task sample being cancelled on a given risk set at each event time can be determined; the probability of the first task sample being cancelled is the ratio of the probability of the first task sample being cancelled to the sum of the probabilities of the second task sample being cancelled in the risk set; and the loss function is obtained by taking the logarithm of the product and taking its negative value.

[0121] For example, let the first task sample be sample i, the second task sample be sample j, and the event time be T. i Given a set of risks For example, the loss function can be defined for each event time T. i Above, given a set of risks E is the product of the probabilities of event i occurring, where sample i is the sample of event i occurring, i.e., task cancellation. i =1, as shown in formula (2) below:

[0122]

[0123] in, The risk score of sample i is the output of the risk prediction model. Let be the risk set, referring to the set of samples that are still at risk at time t, and let sample j be a sample in the risk set. This is the risk score for sample j output by the risk prediction model. The physical meaning of each term in the product symbol is the probability of sample i experiencing the final event at that moment, that is, the ratio of the probability of sample i being canceled at that moment to the sum of the probabilities of all samples j in the risk set being canceled.

[0124] Optionally, since a neural network model is introduced to capture complex linear relationships, the logarithm of formula (2) can be further taken and the negative value can be obtained as the following formula (3) as the loss function.

[0125]

[0126] Where l(θ) represents the loss function, N E＝1 This represents the number of samples in the sample set where E = 1, since r(x) = e h(x) therefore Taking the logarithm yields θ represents the parameters that need to be optimized in the neural network model. This represents a neural network model.

[0127] Optionally, the loss function can further include a regularization term to prevent overfitting during training, thereby improving the model's generalization ability. Simultaneously, the regularization term can also limit the range or magnitude of model parameters, simplifying the model. For example, a regularization term can be added to formula (3) above. The loss function is obtained as shown in formula (4) below:

[0128]

[0129] Optionally, the risk prediction model includes at least one of a feedforward neural network, a fully connected network, an attention mechanism, a recurrent neural network, and a Transformer. For example, the neural network model in the risk prediction model may include, but is not limited to, feedforward neural networks, fully connected networks, attention mechanisms, recurrent neural networks, and Transformers.

[0130] As an example, when the neural network model includes a feedforward neural network, the neural network model h θ It can be a set containing four hidden layers, with dimensions of 132, 124, 16, and 1 respectively.

[0131] Step 324: Update the parameters of the initial risk prediction model according to the loss function to obtain the risk prediction model.

[0132] For example, during model training, using formula (3) or (4) as the loss function and the features extracted in step 321 as input, a risk prediction model is constructed and trained, which can obtain a series of neural network parameter values ​​θ, i.e., the trained risk prediction model. Therefore, by providing hyperparameter θ, this embodiment of the application can control the patience level of the object, thereby enabling overall adjustment of the waiting time and providing flexibility for practical engineering applications.

[0133] Therefore, this application embodiment introduces a neural network model into the risk prediction model, taking into account complex real-world factors, such as ride-hailing order characteristics, passenger selection characteristics, passenger profiles, and city characteristics for ride-hailing aggregation service platforms, rather than relying on a simplified simulation environment, thereby improving the accuracy of risk prediction.

[0134] Furthermore, in this embodiment, an object patience estimation model is also constructed through the risk prediction model. In real-world datasets, the proportion of objects canceling tasks due to loss of patience is relatively small, which poses a challenge for modeling. If modeled as a binary classification problem of "whether to cancel," it would be an extremely imbalanced classification problem with limited accuracy. However, this embodiment, by constructing a partial likelihood loss function, can fully utilize real-world data, considering not only whether an object cancels an order but also the probability of an object canceling a task under different duration conditions, thereby improving the accuracy of risk prediction.

[0135] In summary, after obtaining the trained risk prediction model through the model training process, for each task request, the risk prediction model can be invoked to calculate the probability that the current task will not be canceled by the first object at different times.

[0136] It should be understood that the embodiments of this application do not limit the calculation method of the probability that the current task is not canceled by the first object at different times based on the input characteristics of the risk prediction model.

[0137] In some embodiments, features can be input into the risk prediction model to obtain a risk score for the current task, the risk score being used to represent the degree of influence of the features on the probability that the current task is not canceled by the first object at different times; and the probability that the current task is not canceled by the first object at different times can be determined based on the baseline cumulative risk function and risk score of the risk prediction model.

[0138] For example, S(t) can be used to represent the probability that the current task is not canceled by the first object at time t, then we have the following formula (5):

[0139] S(t)=Pr(T>t) (5)

[0140] Where T is the time when the current task is canceled, and Pr(T>t) represents the probability that the task will be canceled at time T after time t.

[0141] The risk function refers to the probability of canceling an order within the time range [t, t+δ], assuming the task has not been canceled up to time t. For example, when Δt is very small, the risk function λ(t) can be approximated by the following formula (6):

[0142]

[0143] Therefore, based on formula (6), we can further obtain the following formula (7):

[0144]

[0145] Furthermore, the following derivation of formula (8) is performed:

[0146]

[0147] Where C is a constant.

[0148] Since the probability that the task is not canceled is S(t) = 1 at t = 0, the integral -lnS(t) in formula (8) has the same upper and lower limits and a value of 0, so the constant C is 0. Therefore, there is a relationship between S(t) and λ(t) as shown in formula (9):

[0149]

[0150] Where Λ(t) is the Cumulative Hazard Function.

[0151] For the current task i, its input feature is x. i The probability S(t|x) that the device is not canceled at time t. i The derivation can be made based on formula (10):

[0152]

[0153] Where Λ0(t) is the baseline risk accumulation function, Assign a risk score.

[0154] For a trained risk prediction model, its baseline risk accumulation function Λ0(t) is fixed. Optionally, as the risk prediction model is updated, the corresponding baseline risk accumulation function Λ0(t) is also updated accordingly.

[0155] In some embodiments, the training sample set at each time t can be... i The baseline cumulative risk function is obtained by summing the ratio of the number of cancelled events to the sum of the risk scores of the samples in the corresponding risk set; where the risk set includes the sample set of tasks that have not been cancelled at the corresponding time.

[0156] For example, time t i It can be [t0, t1, ..., t m The various moments in ] .

[0157] One possible approach is to estimate the baseline cumulative risk function using the Breslow estimation method. For example, the baseline cumulative risk function Λ0(t) can be obtained according to the following formula (11):

[0158]

[0159] Where, d i At time t iThe number of events in which a task was cancelled. Let be the risk set, referring to the set of samples that are still at risk at time t, and let sample j be a sample in the risk set. For risk set Risk score h(x) of sample j j The sum of the ratios of the sums of ( ).

[0160] In some embodiments, see Figure 5 The waiting time corresponding to the target retention probability can be determined according to steps 325 to 327 below.

[0161] Step 325: Based on the probability that the current task is not canceled by the first object at different times, obtain a set of probabilities that the current task is not canceled at each time; wherein, the probability values ​​of not being canceled at each time in the probability set decrease sequentially.

[0162] For example, the above formulas (10) and (11) are functions of the probability that the current task is not canceled by the first object at time t. According to the above formulas (10) and (11), the probability of the current task at each time [t0, t1, ..., t] can be obtained. m The set of probabilities that were not cancelled [S0, S1, ..., S] m ]. Among them, t0 <t1<…<t m S0>S1>…>S m That is, the probability set [S0,S1,…,S] m The probability of something not being cancelled decreases over time.

[0163] Step 326: Determine the target probability in the probability set, which is greater than or equal to the target retention probability, and the next probability of the target probability in the probability set is less than the target retention probability.

[0164] For example, for a given target retention probability S * It is possible to apply this to the probability set [S0,S1,…,S…]. m Using the binary search method, find a position p, and let S p ≥S * ,S p+1 * Among them, S p This is the target probability, which is greater than or equal to the target retention probability S. * And the probability set [S0,S1,…,S] m [S in the middle] p The next probability value is less than S p+1 Less than the target retention probability S * .

[0165] ​Step 327: Determine the waiting time based on the time corresponding to the target probability.

[0166] Specifically, the time corresponding to the target probability can be determined based on the probability that the current task is not canceled by the first object at different times, that is, the time when the probability of the current task being canceled is the target probability, i.e., the waiting time. One possible way is to determine the target probability S according to formulas (10) and (11). p The time t corresponding to the position p As the target retention probability S * The corresponding waiting time t * .

[0167] It should be understood that the waiting time t * This refers to the waiting time relative to the moment the first object initiates its task request. Optionally, the waiting time t can also be called the patience time of the first object, or the waiting time interval.

[0168] It is understandable that when obtaining the waiting time corresponding to the target retention probability based on the characteristics of the current task of the object and the risk prediction model, the characteristics of the input risk prediction model are not the same for the current task of different objects. Therefore, the waiting time obtained based on the input characteristics is also different. Based on this, different waiting times can be obtained for different tasks of different objects, so that the aggregation service platform can determine different waiting times for each task (or object) from the perspective of task (or object).

[0169] For example, embodiments of this application can calculate different waiting times for different passengers and different order types under different supply and demand conditions, thereby better meeting user needs.

[0170] Step 330: Based on the waiting time, select the second object to execute the current task at the target time and return the information of the second object.

[0171] Specifically, based on the waiting time, the time for selecting a second object to execute the current task from at least one object can be determined, i.e., the target time. Then, at the target time, the second object to execute the current task is selected, and information about that second object is returned to the client. For example, for a ride-hailing aggregation service platform, the time for selecting the second object to execute the current task is the selection time, and the selected transportation provider information is returned to the client.

[0172] Optionally, a target time can also be returned. Specifically, the aggregation service platform can return the target time to the client.

[0173] In some embodiments, a second object for executing the current task can be selected at the target based on the smaller of the earliest first expiration time and the second expiration time among at least one object that has accepted the task. The second expiration time is the sum of the time the task was requested and the waiting time.

[0174] Specifically, the aggregation service platform can also consider the expiration time of each object's accepted task when selecting the second object. To prevent any object from expiring, a target time can be determined based on the smaller of the earliest first expiration time and the second expiration time among at least one object that has accepted the current task. The second object for executing the current task can then be selected at the target time. The second expiration time is determined based on the waiting time, for example, the sum of the time the current task's request was initiated and the waiting time.

[0175] For example, taking a ride-hailing aggregation service platform as an example, the selection of the order selection time can take into account the expiration time of each capacity provider's order acceptance. In order to avoid any capacity provider's order expiring, the order selection time can be determined based on the minimum sum of the earliest expiration time among the capacity providers that have accepted orders, the time when the order request was initiated, and the waiting time.

[0176] One possible approach is to determine the time t for selecting the second object to execute the current task based on the following formula (12). s :

[0177] t s =min{t expire , t request +t *} (12)

[0178] Among them, t expire t represents the earliest expiration time of all objects that have accepted tasks. request Indicates the time when the first object initiates the task request, t * This is the waiting time.

[0179] It should be understood that the embodiments of this application employ a given target retention probability S. * Waiting time t for prediction * The timing for selecting the second object to execute the current task is determined by considering the different characteristics of each object, resulting in varying waiting times. Therefore, embodiments of this application facilitate determining the optimal waiting time for each task from the perspective of the object or task.

[0180] This application embodiment does not use a fixed value Δt to determine the moment of selecting the second object of the current task. Formula (13) shows the calculation formula for the moment of selecting the second object using a fixed value Δt:

[0181] ts =min{t expire , t request +Δt} (13)

[0182] It is evident that when a fixed value Δt is used to determine the moment of selecting the second object, the waiting time determined for all objects is the same. Therefore, related solutions use a system perspective to determine whether to perform matching, rather than considering the object or task perspective to determine the optimal waiting time for each task. The embodiments of this application, however, are not limited to a fixed value and are more in line with user needs.

[0183] Therefore, in response to the task initiation request triggered by the first object, this embodiment of the application obtains the waiting time corresponding to the target retention probability. Since the waiting time is obtained based on the probability that the current task is not canceled by the first object at different times, the probability of the task being canceled under different time conditions can be considered to determine the corresponding task waiting time for the current task. This allows for the calculation of different waiting times for different tasks, thereby realizing the determination of the corresponding waiting time interval for each task from the perspective of the task and optimizing the waiting time interval of the aggregation service platform in the process of matching transactions.

[0184] Furthermore, embodiments of this application can also acquire the characteristics of the current task, input these characteristics into a risk prediction model, and utilize the risk prediction model to consider complex factors to obtain the probability that the current task will not be canceled at different times. Based on this, the waiting time corresponding to a given target retention probability is obtained. Since the risk prediction model can be based on the task's characteristic input rather than relying on a simplified simulation environment, the obtained probability of the task being canceled at different times can make full use of real-world data, considering not only whether the task will be canceled, but also the probability of canceling the task under different time conditions, thereby improving the accuracy of the waiting time interval.

[0185] Figure 6 This is a schematic flowchart illustrating a menu selection method according to an embodiment of this application. The menu selection method is described using a ride-hailing aggregation service platform as an example. It should be understood that... Figure 6 The steps or operations of the menu method are illustrated, but these steps or operations are merely examples, and other operations can be performed in the embodiments of this application. Figure 6 Variations of various operations within it. Furthermore... Figure 6 The various steps in can be followed according to... Figure 6 The different orders in which they are presented are executed, and it is possible that they are not intended to be executed. Figure 6 All operations.

[0186] Step 601: Place the order.

[0187] For example, such as Figure 7AUsers can use the ride-hailing aggregation service platform to obtain information about the services offered by all transportation providers for their current trip, including but not limited to estimated fares and vehicle types. Optionally, users can select their preferred operator on the order page. The ride-hailing aggregation service platform then dispatches orders to various transportation providers. Since transportation providers accept orders in a sequential manner, the aggregation service platform needs to determine when to end the waiting period and execute the order selection for the user. Figure 7B As shown.

[0188] Step 602: Determine the waiting time.

[0189] Specifically, the aggregation service platform can acquire order characteristics and input these characteristics into a risk prediction function to obtain the probability that the current order will not be canceled at different times. Based on this probability, it can then determine the waiting time corresponding to the target retention probability. This waiting time is determined for different customer orders, reflecting their patience. For example, customers with greater patience may have a longer waiting time, while those with less patience may have a shorter waiting time, thus meeting the needs of different customers. The target retention probability can be a pre-set retention probability by the aggregation service platform. For details on how to determine the waiting time, please refer to the relevant description above.

[0190] Step 603: Wait for the transportation provider to accept the order.

[0191] Step 604: Determine the order selection time based on the overtime of the transport provider and the waiting time of the target.

[0192] Specifically, the selection time can be determined based on the overtime time of the transport provider and the waiting time determined in step 602. The aggregation service platform can obtain the overtime times of transport providers from various platforms. Specifically, the selection time is an example of the target time mentioned above. For details, please refer to the relevant descriptions above.

[0193] Step 605: Has the waiting time exceeded the limit?

[0194] In some cases, with limited supply, there may be a prolonged period after an order is placed without a carrier accepting it. In such cases, it's necessary to determine if the current timeframe has exceeded the waiting period. If it has, proceed to step 606. If the waiting period has not exceeded, continue waiting for a carrier to accept the order.

[0195] Step 606: Add dispatch option, quick ride-hailing option.

[0196] For example, when the user's waiting time is reached, a pop-up page can appear to allow more transportation providers to participate, increasing the probability of successfully hailing a ride. Optionally, a quick ride-hailing option can also appear, allowing the user to choose whether to use quick ride-hailing.

[0197] In this context, "fast ride-hailing" means that as soon as one ride-hailing provider accepts the order, the platform returns the order to the user without waiting for other providers to participate, thus bypassing the order selection phase. Optionally, the platform can also explain the advantages and disadvantages of the fast ride-hailing option to the user, for example, by displaying these advantages and disadvantages on the page.

[0198] Step 607: Wait for the transportation provider to accept the order.

[0199] Step 608: Do you want to call a car quickly?

[0200] If the user allows express ride booking, proceed to step 612. If the user does not agree to express ride booking, calculate the selection time based on the overdue time of the transportation provider.

[0201] Step 609: Determine the order selection time based on the overtime period of the transportation provider.

[0202] Specifically, since the waiting time has already been exceeded in step 605, it is not necessary to calculate the menu time based on the waiting time.

[0203] Step 610: Wait until the menu selection time.

[0204] Step 611, execute the menu.

[0205] Step 612: Proceed to the object decision-making stage.

[0206] Therefore, this application embodiment, by designing a waiting time interval optimization strategy suitable for the aggregation service platform, can retain a larger set of capacity candidates for passengers while minimizing passenger churn, thus providing passengers with the optimal choice. For example, for passengers with sufficient patience, the waiting time can be increased, thereby retaining a larger set of capacity candidates and providing passengers with the optimal choice; for passengers lacking patience, the waiting time can be shortened, which helps to reduce user cancellation rates.

[0207] Figure 8This is a schematic diagram of a system architecture according to an embodiment of this application. The system architecture includes a training module and a prediction module. The feature management platform facilitates feature management, including feature names, categories, and the relationship between models and features. A feature service is used for feature acquisition. A time callback is executed in both cases when an object loses patience and cancels an order or completes the order selection. The sample reporting service acquires features through the feature service, concatenates samples, and generates and reports training samples. Training samples can be stored in a database for offline model training. The model is then deployed online after training. Optionally, the training module can update the model daily to ensure its performance reflects the latest information. In the real-time process, when an object places an order, it calls the prediction service to acquire features through the feature service. After acquiring the features, it calls the prediction interface to perform model prediction and obtain the object's patience, i.e., the waiting time.

[0208] This application embodiment was also tested on a real travel platform over a period of time. The control group used a fixed time interval, Δt = 15s, and calculated the menu selection time with reference to formula (13); the experimental group used the target retention probability S for each order. * =Waiting time t at 97% * The selection time is calculated using formula (12). Among them, the hyperparameter Δt = 15s of the control group is the optimal parameter obtained by the current system in the A / B experiment, and it is also the hyperparameter used in the current system operation.

[0209] The measured indicators are shown in Table 1. The average waiting time in the experimental group increased by 0.75%, while the user cancellation rate decreased, indicating that the solution provided in this embodiment of the application meets the needs of different users to some extent. Although it increased the average waiting time, it still shortened the waiting time for impatient users, thus slightly reducing the user cancellation rate. In addition, the average number of transport capacities participating in the order selection for each order increased by 6.54%, providing more flexibility in the capacity selection process. Its advantage is also reflected in a slight decrease in the user cancellation rate after order acceptance. The experimental data shows that the solution provided in this embodiment of the application has the expected practical effect.

[0210] It is worth noting that in practical applications, aggregation service platforms cannot control whether or not transport providers accept orders, or when they do so. Therefore, the user order acceptance rate and the algorithm's hyperparameter target retention probability S are directly related. * There are some differences. Because actual travel service platforms serve a large number of users, factors such as the differences between the experimental and control groups, and the number of people in the experimental group, are controlled to some extent. In practical applications, the target retention probability S can be controlled. * Reduce user cancellations. For example, target retention probability S. * The larger the value, the shorter the user wait time and the fewer user cancellations.

[0211] Figure 9 This is a schematic flowchart illustrating a risk prediction model training method 900 according to an embodiment of this application. The method 900 can be executed by any electronic device with data processing capabilities; for example, the electronic device can be implemented as a server or a terminal device. As another example, the electronic device can be implemented as... Figure 2 The server in this application is not limited in this respect. Figure 9 As shown, the risk prediction model training method 900 includes steps 910 to 940.

[0212] Step 910: Obtain a training sample set, which includes task features and task labels for task samples; wherein, the task labels include the final time of the task sample and whether it was ultimately canceled.

[0213] Step 920: Input the task characteristics into the initial risk prediction model to obtain the probability that the task sample will be canceled at each event time.

[0214] Step 930: Obtain the loss function based on the probability of the task sample being canceled at each event time and the task label.

[0215] Step 940: Update the parameters of the initial risk prediction model according to the loss function to obtain the risk prediction model.

[0216] Optionally, the step of obtaining the loss function based on the probability of the task sample being canceled at each event time and the task label includes:

[0217] The loss function is obtained based on the probability of the ultimately canceled task sample in the task sample being canceled at each event time and the probability of the task sample in the risk set being canceled at each event time.

[0218] Optionally, the step of obtaining the loss function based on the probability of the first task sample that is ultimately canceled in the task sample being canceled at each event time and the probability of the second task sample in the risk set being canceled at each event time includes:

[0219] Determine the product of the probabilities of the first task sample being cancelled at each event time given the risk set; the probability of the first task sample being cancelled is the ratio of the probability of the first task sample being cancelled to the sum of the probabilities of the second task samples in the risk set being cancelled.

[0220] The loss function is obtained by taking the logarithm of the product and then taking its negative value.

[0221] For details on the model training process, please refer to [link / reference]. Figure 4The relevant description in the document.

[0222] Optionally, the feature includes at least one of the following: task feature, the checkmark feature of the first object for the current task, and object feature.

[0223] Optionally, the risk prediction model includes at least one of the following: feedforward neural network, fully connected network, attention mechanism, recurrent neural network, and Transformer.

[0224] Optionally, the task sample includes ride-hailing order tasks.

[0225] This application embodiment provides hyperparameters for a risk prediction model, which can control the patience level of the object, thereby enabling a holistic adjustment of the waiting time and providing flexibility for practical engineering applications.

[0226] Therefore, this application embodiment introduces a neural network model into the risk prediction model, taking into account complex real-world factors, such as ride-hailing order characteristics, passenger selection characteristics, passenger profiles, and city characteristics for ride-hailing aggregation service platforms, rather than relying on a simplified simulation environment, thereby improving the accuracy of risk prediction.

[0227] Furthermore, in this embodiment, an object patience estimation model is also constructed through the risk prediction model. In real-world datasets, the proportion of objects canceling tasks due to loss of patience is relatively small, which poses a challenge for modeling. If modeled as a binary classification problem of "whether to cancel," it would be an extremely imbalanced classification problem with limited accuracy. However, this embodiment, by constructing a partial likelihood loss function, can fully utilize real-world data, considering not only whether an object cancels an order but also the probability of an object canceling a task under different duration conditions, thereby improving the accuracy of risk prediction.

[0228] Figure 10 This is a schematic flowchart illustrating a task execution method 1000 according to an embodiment of this application. The method 1000 can be executed by any electronic device with data processing capabilities; for example, the electronic device can be implemented as... Figure 2 The terminal device in the application can further be a client device within the terminal device; this application does not limit this to specific applications. Figure 10 As shown, the task execution method 1000 includes steps 1010 to 1030.

[0229] Step 1010: In response to the triggering operation of the first object, send a task initiation request to the server.

[0230] For example, the first object can log in to the client on a terminal device and perform input operations on the client to trigger the client to send a task initiation request to the server. Specifically, the task initiation request can be found in [reference needed]. Figure 3 The relevant description in method 300.

[0231] Step 1020: Obtain the target time from the server. The target time is determined based on the waiting time corresponding to the target retention probability. The waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times.

[0232] Specifically, the target time and waiting time can be referenced. Figure 3 The relevant description in Method 300.

[0233] Step 1030: Display the target time.

[0234] As one possible implementation, the client can directly display the target time. As another possible implementation, the client can also display the time difference between the target time and the current time; for example, it can display the difference between the target time and the current time as a countdown, such as... Figure 7B In this way.

[0235] Optionally, when displaying the target time, the client can also add a certain time margin to the target time. For example, 1 second can be added to the target time. As a specific example, when the time difference between the target time and the current time is 4 seconds, a 5-second waiting time can be displayed on the page. Since the aggregation service platform performs the operation of selecting the second object when the target time arrives, it may take some time for the information of the second object to be returned to the client. Therefore, adding a certain time margin to the target time can help avoid the situation where the information of the second object has not been received by the time the target time arrives.

[0236] Understandably, the target time is obtained from the server, so it cannot be displayed until the server returns it. One possible scenario is that when the target time is determined based on the minimum of the earliest first and second expiration times among at least one object that has accepted the task, the target time can only be determined after an object has raised its hand (indicating agreement to accept the task). Therefore, the client can only display the target time at least after an object has raised its hand.

[0237] Therefore, in this embodiment of the application, a task sending request is sent to the server in response to the triggering operation of the first object, and a target time is obtained. This target time is determined based on the waiting time corresponding to the target retention probability, and then the target time is displayed. Since the waiting time is obtained based on the probability that the current task will not be canceled by the first object at different times, the probability of task cancellation under different time conditions can be considered to determine the corresponding task waiting time for the current task, and then the target time determined based on the waiting time is displayed, so that the user can perceive the waiting time of the corresponding task and improve the user experience.

[0238] In some embodiments, method 1000 may further include the following steps 1040 and 1050:

[0239] Step 1040: Obtain information about the second object that performs the current task, wherein the information about the second object is selected at the target time.

[0240] Step 1050: Display the information of the second object after the target time.

[0241] Specifically, the aggregation service platform can display the information of the second object after the target time arrives, and the optional first object can decide whether to agree to the second object performing the current task after the information of the second object is displayed.

[0242] The specific embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this application, various simple modifications can be made to the technical solutions of this application, and these simple modifications all fall within the protection scope of this application. For example, the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this application will not describe the various possible combinations separately. Furthermore, various different embodiments of this application can also be arbitrarily combined, as long as they do not violate the spirit of this application, they should also be considered as the content disclosed in this application.

[0243] It should also be understood that, in the various method embodiments of this application, the sequence numbers of the above processes do not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. It should be understood that these sequence numbers can be interchanged where appropriate so that the embodiments of this application described can be implemented in a sequence other than those illustrated or described.

[0244] The method embodiments of this application have been described in detail above. The following description, in conjunction with... Figures 11 to 14 The following describes in detail the device embodiments of this application.

[0245] Figure 11 This is a schematic block diagram of the task distribution device 10 according to an embodiment of this application. Figure 11 As shown, the device 10 may include a first acquisition unit 11, a second acquisition unit 12, a selection unit 13, and a return unit 14.

[0246] The first acquisition unit 11 is used to acquire the task initiation request triggered by the first object;

[0247] The second acquisition unit 12 is used to acquire the waiting time corresponding to the target retention probability in response to the task initiation request; wherein the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times;

[0248] Selection unit 13 is used to select a second object to execute the current task at a target time based on the waiting time;

[0249] The return unit 14 is used to return information about the second object.

[0250] Optionally, the second acquisition unit 12 is specifically used for:

[0251] In response to the task initiation request, the characteristics of the current task are obtained;

[0252] The features are input into the risk prediction model to obtain the probability that the current task is not canceled by the first object at different times;

[0253] The waiting time is obtained based on the probability that the current task is not canceled by the first object at different times.

[0254] Optionally, the second acquisition unit 12 is specifically used for:

[0255] The feature is input into the risk prediction model to obtain the risk score of the current task. The risk score is used to represent the degree of influence of the feature on the probability that the current task is not canceled by the first object at different times.

[0256] Based on the baseline cumulative risk function of the risk prediction model and the risk score, the probability that the current task will not be canceled by the first object at different times is determined.

[0257] Optionally, the second acquisition unit 12 is also used for:

[0258] For the training sample set at each time t i The baseline cumulative risk function is obtained by summing the ratio of the number of cancelled events to the sum of the risk scores of the samples in the corresponding risk set; wherein, the risk set includes the sample set of tasks that have not been cancelled at the corresponding time.

[0259] Optionally, the device 10 also includes a model training unit for:

[0260] Obtain a training sample set, which includes task features and task labels for task samples; wherein, the task labels include the final time of the task sample and whether it is ultimately canceled.

[0261] Input the task characteristics into the initial risk prediction model to obtain the probability that the task sample will be canceled at each event time.

[0262] The loss function is obtained based on the probability of the task sample being canceled at each event time and the task label;

[0263] The initial risk prediction model is updated with parameters based on the loss function to obtain the risk prediction model.

[0264] Optionally, the model training unit is specifically used for:

[0265] The loss function is obtained based on the probability of the ultimately canceled task sample in the task sample being canceled at each event time and the probability of the task sample in the risk set being canceled at each event time.

[0266] Optionally, the model training unit is specifically used for:

[0267] Determine the product of the probabilities of the first task sample being cancelled at each event time given the risk set; the probability of the first task sample being cancelled is the ratio of the probability of the first task sample being cancelled to the sum of the probabilities of the second task samples in the risk set being cancelled.

[0268] The loss function is obtained by taking the logarithm of the product and then taking its negative value.

[0269] Optionally, the second acquisition unit 12 is specifically used for:

[0270] Based on the probability that the current task is not canceled by the first object at different times, a set of probabilities that the current task is not canceled at each time is obtained; wherein, the probability values ​​of not being canceled at each time in the probability set decrease sequentially.

[0271] A target probability is determined in the probability set, the target probability being greater than or equal to the target retention probability, and the next probability in the probability set is less than the target retention probability;

[0272] The waiting time is determined based on the time corresponding to the target probability.

[0273] Optionally, selection unit 13 is specifically used for:

[0274] Based on the smaller of the earliest first expiration time and the second expiration time among at least one object that has accepted the task, a second object is selected to execute the current task at the target time; wherein the second expiration time is the sum of the time when the task was initiated and the waiting time.

[0275] Optionally, the feature includes at least one of the following: task feature, the checkmark feature of the first object for the current task, and object feature.

[0276] Optionally, the risk prediction model includes at least one of the following: feedforward neural network, fully connected network, attention mechanism, recurrent neural network, and Transformer.

[0277] Optionally, the current task includes ride-hailing order tasks.

[0278] In response to the task initiation request triggered by the first object, the waiting time corresponding to the target retention probability is obtained. Since the waiting time is obtained based on the probability that the current task is not canceled by the first object at different times, the probability of the task being canceled under different time conditions can be considered to determine the corresponding task waiting time for the current task. Thus, different waiting times are calculated for different tasks, and the corresponding waiting time interval is determined for each task from the perspective of the task.

[0279] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details will not be provided here. Specifically, Figure 11 The task distribution device 10 shown can execute the above method embodiments, and the aforementioned and other operations and / or functions of each module in the device 10 are respectively for implementing the corresponding process in the above method 300. For the sake of brevity, they will not be described in detail here.

[0280] Figure 12 This is a schematic block diagram of the risk prediction model training device 20 according to an embodiment of this application. Figure 12 As shown, the device 20 may include an acquisition unit 21, an input unit 22, a training unit 23, and a parameter update unit 24.

[0281] The acquisition unit 21 is used to acquire a training sample set, which includes task features and task labels of task samples; wherein, the task label includes the final time of the task sample and whether it is ultimately canceled.

[0282] Input unit 22 is used to input the task features into the initial risk prediction model to obtain the probability that the task sample will be canceled at each event time.

[0283] Training unit 23 is used to obtain a loss function based on the probability of the task sample being canceled at each event time and the task label;

[0284] The parameter update unit 24 is used to update the parameters of the initial risk prediction model according to the loss function to obtain the risk prediction model.

[0285] In some embodiments, the training unit 23 is specifically used for:

[0286] The loss function is obtained based on the probability of the ultimately canceled task sample in the task sample being canceled at each event time and the probability of the task sample in the risk set being canceled at each event time.

[0287] In some embodiments, the training unit 23 is specifically used for:

[0288] Determine the product of the probabilities of the first task sample being cancelled at each event time given the risk set; the probability of the first task sample being cancelled is the ratio of the probability of the first task sample being cancelled to the sum of the probabilities of the second task samples in the risk set being cancelled.

[0289] The loss function is obtained by taking the logarithm of the product and then taking its negative value.

[0290] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details will not be provided here. Specifically, Figure 12 The risk prediction model training device 20 shown can execute the above method embodiments, and the aforementioned and other operations and / or functions of each module in the device 20 are respectively to implement the corresponding process in the above method 900. For the sake of brevity, they will not be described in detail here.

[0291] Figure 13 This is a schematic block diagram of the task execution device 30 according to an embodiment of this application. Figure 13 As shown, the device 30 may include a transmitting unit 31, a receiving unit 32, and a display unit 33.

[0292] Sending unit 31: In response to the triggering operation of the first object, the user sends a task initiation request to the server;

[0293] The receiving unit 32 is used to obtain a target time from the server, wherein the target time is determined based on the waiting time corresponding to the target retention probability; wherein the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times;

[0294] Display unit 33 is used to display the target time.

[0295] Optionally, the target time is determined based on the minimum of the earliest first expiration time and the second expiration time among at least one object that has accepted the task; wherein the second expiration time is the sum of the time when the task was initiated and the waiting time.

[0296] Optionally, the receiving unit 32 is also used for:

[0297] Obtain information about a second object that performs the current task, wherein the information about the second object is selected at the target time;

[0298] The display unit 33 is also used to display information about the second object after the target time.

[0299] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details will not be provided here. Specifically, Figure 13 The task execution device 30 shown can execute the above method embodiments, and the aforementioned and other operations and / or functions of each module in the device 30 are respectively for implementing the corresponding process in the above method 1000. For the sake of brevity, they will not be described in detail here.

[0300] The apparatus of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly embodied as being executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0301] Figure 14 This is a schematic block diagram of the electronic device provided in the embodiments of this application.

[0302] like Figure 14 As shown, the electronic device 40 may include:

[0303] The system includes a memory 43 for storing a computer program 44 and a processor 42 for transferring the program code 44 to the processor 42. In other words, the processor 42 can retrieve and run the computer program 44 from the memory 43 to implement the method provided in the embodiments of this application.

[0304] In some embodiments, the processor 42 may retrieve and run the computer program 34 from the memory 43 to implement the task distribution method provided in the embodiments of this application, including:

[0305] The task triggered by the first object initiates a request;

[0306] In response to the task initiation request, the waiting time corresponding to the target retention probability is obtained; wherein, the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times;

[0307] Based on the waiting time, select a second object to execute the current task at the target time and return information about the second object.

[0308] For example, the processor 42 can be used to execute the steps in the method 300 described above according to the instructions in the computer program 44.

[0309] In some embodiments, the processor 42 may call and run the computer program 34 from the memory 43 to implement the risk prediction model training method in this application embodiment, including:

[0310] Obtain a training sample set, which includes task features and task labels for task samples; wherein, the task labels include the final time of the task sample and whether it is ultimately canceled.

[0311] Input the task characteristics into the initial risk prediction model to obtain the probability that the task sample will be canceled at each event time.

[0312] The loss function is obtained based on the probability of the task sample being canceled at each event time and the task label;

[0313] The initial risk prediction model is updated with parameters based on the loss function to obtain the risk prediction model.

[0314] For example, the processor 42 can be used to execute the steps in the method 900 described above according to the instructions in the computer program 44.

[0315] In some embodiments, the processor 42 may retrieve and run the computer program 34 from the memory 43 to implement the task execution method provided in the embodiments of this application, including:

[0316] In response to the triggering operation of the first object, a task initiation request is sent to the server;

[0317] Obtain the target time from the server, the target time being determined based on the waiting time corresponding to the target retention probability; wherein, the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times;

[0318] Display the target time.

[0319] For example, the processor 42 can be used to execute the steps in the method 1000 described above according to the instructions in the computer program 44.

[0320] In some embodiments of this application, the processor 42 may include, but is not limited to:

[0321] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0322] In some embodiments of this application, the memory 43 includes, but is not limited to:

[0323] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0324] In some embodiments of this application, the computer program 44 may be divided into one or more units, which are stored in the memory 43 and executed by the processor 42 to perform the method provided in this application. The one or more units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program 44 in the electronic device 40.

[0325] Optional, such as Figure 14 As shown, the electronic device 40 may further include:

[0326] Transceiver 43, which can be connected to processor 42 or memory 43.

[0327] The processor 42 can control the transceiver 43 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 43 may include a transmitter and a receiver. The transceiver 43 may further include antennas, and the number of antennas may be one or more. It should be understood that the various components in this electronic device are connected through a bus system, which includes, in addition to a data bus, a power bus, a control bus, and a status signal bus.

[0328] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0329] When implemented using software, it can be implemented entirely or partially as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0330] It is understood that in the specific implementation of this application, when the above embodiments of this application are applied to specific products or technologies and involve user information and other related data, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0331] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0332] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0333] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0334] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A task distribution method, characterized in that, include: The task triggered by the first object initiates a request; In response to the task initiation request, the waiting time corresponding to the target retention probability is obtained; wherein, the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times; Based on the waiting time, select a second object to execute the current task at the target time and return information about the second object.

2. The method according to claim 1, characterized in that, The step of responding to the task initiation request and obtaining the waiting time corresponding to the target retention probability includes: In response to the task initiation request, the characteristics of the current task are obtained; The features are input into the risk prediction model to obtain the probability that the current task is not canceled by the first object at different times; The waiting time is obtained based on the probability that the current task is not canceled by the first object at different times.

3. The method according to claim 2, characterized in that, The step of inputting the features into the risk prediction model to obtain the probability that the current task is not canceled by the first object at different times includes: The feature is input into the risk prediction model to obtain the risk score of the current task. The risk score is used to represent the degree of influence of the feature on the probability that the current task is not canceled by the first object at different times. Based on the baseline cumulative risk function of the risk prediction model and the risk score, the probability that the current task will not be canceled by the first object at different times is determined.

4. The method according to claim 3, characterized in that, Also includes: For the training sample set at each time t i The baseline cumulative risk function is obtained by summing the ratio of the number of cancelled events to the sum of the risk scores of the samples in the corresponding risk set; wherein, the risk set includes the sample set of tasks that have not been cancelled at the corresponding time.

5. The method according to any one of claims 2-4, characterized in that, Also includes: Obtain a training sample set, which includes task features and task labels for task samples; wherein, the task labels include the final time of the task sample and whether it is ultimately canceled. Input the task characteristics into the initial risk prediction model to obtain the probability that the task sample will be canceled at each event time. The loss function is obtained based on the probability of the task sample being canceled at each event time and the task label; The initial risk prediction model is updated with parameters based on the loss function to obtain the risk prediction model.

6. The method according to claim 5, characterized in that, The loss function is derived based on the probability of the task sample being canceled at each event time and the task label, including: The loss function is obtained based on the probability of the ultimately canceled task sample in the task sample being canceled at each event time and the probability of the task sample in the risk set being canceled at each event time.

7. The method according to claim 6, characterized in that, The loss function is obtained based on the probability of the first task sample that is ultimately canceled in the task sample being canceled at each event time and the probability of the second task sample in the risk set being canceled at each event time, including: Determine the product of the probabilities of the first task sample being cancelled at each event time given the risk set; the probability of the first task sample being cancelled is the ratio of the probability of the first task sample being cancelled to the sum of the probabilities of the second task samples in the risk set being cancelled. The loss function is obtained by taking the logarithm of the product and then taking its negative value.

8. The method according to any one of claims 1-4, characterized in that, The waiting time for obtaining the target retention probability includes: Based on the probability that the current task is not canceled by the first object at different times, a set of probabilities that the current task is not canceled at each time is obtained; wherein, the probability values ​​of not canceling at each time in the probability set decrease sequentially. A target probability is determined in the probability set, the target probability being greater than or equal to the target retention probability, and the next probability in the probability set that is the target probability is less than the target retention probability; The waiting time is determined based on the time corresponding to the target probability.

9. The method according to any one of claims 1-4, characterized in that, The step of selecting a second object to execute the current task at a target time based on the waiting time includes: Based on the smaller of the earliest first expiration time and the second expiration time among at least one object that has accepted the task, a second object is selected to execute the current task at the target time; wherein the second expiration time is the sum of the time when the task was initiated and the waiting time.

10. The method according to any one of claims 1-4, characterized in that, The features include at least one of the following: task features, the selection feature of the first object for the current task, and object features.

11. The method according to any one of claims 1-4, characterized in that, The current task includes ride-hailing order tasks.

12. A task execution method, characterized in that, include: In response to the triggering operation of the first object, a task initiation request is sent to the server; Obtain the target time from the server, the target time being determined based on the waiting time corresponding to the target retention probability; wherein, the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times; Display the target time.

13. The method according to claim 12, characterized in that, The target time is determined based on the minimum of the earliest first expiration time and the second expiration time among at least one object that has accepted the task; wherein the second expiration time is the sum of the time when the task was initiated and the waiting time.

14. The method according to claim 12, characterized in that, Also includes: Obtain information about a second object that performs the current task, wherein the information about the second object is selected at the target time; Information about the second object is displayed after the target time.

15. A task distribution device, characterized in that, include: The first acquisition unit is used to acquire the task initiation request triggered by the first object; The second acquisition unit is used to acquire the waiting time corresponding to the target retention probability in response to the task initiation request; wherein the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times; The selection unit is used to select a second object to execute the current task at a target time based on the waiting time. The return unit is used to return information about the second object.

16. A task execution device, characterized in that, include: The sending unit is where the user responds to the triggering operation of the first object by sending a task initiation request to the server; A receiving unit is configured to acquire a target time from a server, wherein the target time is determined based on a waiting time corresponding to the target retention probability; wherein the waiting time is obtained based on the probability that the current task corresponding to the task initiation request is not canceled by the first object at different times; The display unit is used to display the target time.

17. An electronic device, characterized in that, It includes a processor and a memory, the memory storing instructions, which, when executed by the processor, cause the processor to perform the method according to any one of claims 1-11, or the method according to any one of claims 12-14.

18. A computer storage medium, characterized in that, Used to store a computer program, the computer program comprising a method for performing any one of claims 1-11, or any one of claims 12-14.

19. A computer program product, characterized in that, Includes computer program code, which, when executed by an electronic device, causes the electronic device to perform the method of any one of claims 1-11, or the method of any one of claims 12-14.

Images