A task processing method, apparatus, medium, and device
By creating storage space and processes for subtasks in the large model call process, the system blocking caused by synchronous calls and the load pressure of asynchronous calls are solved, thus achieving efficient task processing.
Patent Information
- Application Number
- CN202510260064.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-06
- Publication Date
- 2025-11-18
- Estimated Expiration
- 2045-03-06
AI Technical Summary
During large-scale model calls, synchronous calls cause third-party systems to become blocked, affecting user experience and system performance, while asynchronous calls increase the load on third-party systems, resulting in lower task processing efficiency.
By receiving task processing requests, subtasks are identified and subprocesses are created. Storage space is configured for each subprocess. Subtask data is processed using a predefined model server, and the processing results are stored in the predefined storage space until all subtasks are completed. Finally, the target processing result is sent.
There is no need to feed intermediate results back to third-party systems, which reduces system load, improves task processing efficiency, simplifies interface configuration, and ensures fast task processing.
Smart Images

Figure CN119759589B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to a task processing method, apparatus, medium, and device. Background Technology
[0002] With the continuous advancement of artificial intelligence technology, large-scale models are gradually becoming a key force driving the intelligent transformation of various industries. These large-scale models, with their powerful data processing capabilities, complex pattern recognition capabilities, and high level of intelligence, have demonstrated enormous application potential in multiple fields such as text analysis, image recognition, speech recognition, and risk assessment.
[0003] As large-scale models continue to evolve, an increasing number of third-party systems and target devices are leveraging them to enhance their intelligence. These systems span various fields, including finance, healthcare, education, and e-commerce. By utilizing large-scale models, these systems can achieve more accurate data analysis and prediction, providing users with more personalized services and experiences. In the process of integrating large-scale models with third-party systems, interfaces become crucial. Through clearly defined interface protocols, third-party systems can conveniently access the various functions provided by large-scale models, enabling data input and output. Currently, third-party systems primarily utilize large-scale models through synchronous and asynchronous methods.
[0004] Synchronous invocation refers to a process where, after a third-party system sends a request, it waits for the large model to complete processing and return a result before proceeding with subsequent operations. However, synchronous invocation has limitations. When processing large models takes a long time, synchronous invocation can cause the third-party system to become blocked, impacting user experience and system performance. To address the problems of synchronous invocation, asynchronous invocation has emerged.
[0005] In asynchronous calls, after a third-party system sends a request, it doesn't need to wait for the large model to finish processing; instead, it immediately returns to continue executing other tasks. Once the large model has finished processing in the background, it notifies the third-party system of the execution / processing results each time through a pre-configured interface. The third-party system, through complex callback mechanisms and state management, ensures that it can correctly perform subsequent operations upon receiving the large model's processing results. This can lead to a high load on the third-party system, impacting its performance and resulting in low task processing efficiency. Summary of the Invention
[0006] In view of this, the present invention provides a task processing method, apparatus, medium and device, the main purpose of which is to solve the problem of low task processing efficiency in current model calling tasks.
[0007] To address the above problems, this application provides a task processing method, comprising:
[0008] Receive task processing requests sent by the target device;
[0009] Based on the task processing request, determine the subtasks corresponding to the target task, and create corresponding subprocesses for each subtask;
[0010] Configure a corresponding storage space for each of the subprocesses, the storage space being used to store subtask data and the subtask processing results of the pre-defined subtasks that have been executed in each of the subprocesses;
[0011] For the first subtask to be processed, based on the first subprocess of the first subtask, a target large model is called from a predetermined model server. Based on the target large model, the subtask data in the first storage space and the subtask processing results of the predetermined subtasks that have been executed are processed to obtain the first processing result of the first subtask. The first processing result is then stored in the second storage space of the predetermined second subtask. This process continues until the processing of each subtask is completed, the target processing result is obtained, and the target processing result is sent to the target device.
[0012] Optionally, creating a corresponding subprocess for each of the subtasks specifically includes:
[0013] Create the main process;
[0014] The main process creates corresponding subprocesses for each of the subtasks.
[0015] Optionally, determining the subtasks corresponding to the target task based on the task processing request specifically includes:
[0016] Based on the task processing request, obtain the task data of the target task;
[0017] A task splitting request is sent to the model server based on the task data;
[0018] The system receives a task splitting scheme generated by a predetermined large model in response to the task splitting request, which is fed back by the model server. The task splitting scheme includes at least: several sub-tasks and sub-task data corresponding to each sub-task.
[0019] Optionally, before sending the task splitting request to the model server based on the task data, the method further includes: generating the task splitting request, specifically including:
[0020] Based on the task data and the predetermined task processing time, the task splitting request is generated.
[0021] Optionally, storing the first processing result in the second storage space of the predetermined second subtask specifically includes:
[0022] Based on the first subprocess, the first processing result is stored in the second storage space of the predetermined second subtask through the target email protocol.
[0023] Optionally, the first storage space stores the task identifier of a predetermined second subtask;
[0024] Before storing the first processing result to the second storage space of the predetermined second subtask, the method further includes:
[0025] Based on the task identifier of the second subtask, determine the second storage space corresponding to the second subtask.
[0026] Optionally, the storage space may also store model identifiers for determining the target large model.
[0027] To address the above problems, this application provides a task processing apparatus, comprising:
[0028] The receiving module is used to receive task processing requests sent by the target device;
[0029] A creation module is used to determine each subtask corresponding to the target task based on the task processing request, and to create a corresponding subprocess for each subtask;
[0030] A configuration module is used to configure a corresponding storage space for each of the subprocesses. The storage space is used to store subtask data and the subtask processing results of the pre-defined subtasks that have been executed in each of the subprocesses.
[0031] The processing module is used to, for the first subtask to be processed, call the target large model from the predetermined model server based on the first subprocess of the first subtask, process the subtask data in the first storage space and the subtask processing results of the predetermined subtasks already executed based on the target large model, obtain the first processing result of the first subtask, and store the first processing result in the second storage space of the predetermined second subtask, until the processing of each subtask is completed, obtain the target processing result, and send the target processing result to the target device.
[0032] To address the aforementioned problems, this application provides a storage medium storing a computer program that, when executed by a processor, implements the steps of any of the aforementioned task processing methods.
[0033] To address the aforementioned problems, this application provides an electronic device, comprising at least a memory and a processor, wherein the memory stores a computer program, and the processor, when executing the computer program in the memory, implements the steps of any of the aforementioned task processing methods.
[0034] This application discloses a task processing method, apparatus, medium, and device that, during the processing of a target task, eliminates the need to feed back intermediate results (i.e., the processing results of each subtask) to a third-party system / target device. Instead, it stores the processing results of each subtask in a pre-allocated storage space. This ensures that the processing of the target task is not affected by the operating status of the third-party system / target device, guaranteeing rapid processing of the target task and reducing the load on the third-party system / target device. Furthermore, since there is no need to feed back intermediate results to the third-party system / target device, the third-party system / target device does not need additional interface configuration. It only needs to configure a unified interface to send the target task and receive the target processing results, improving interface configuration efficiency and further enhancing task processing efficiency.
[0035] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description
[0036] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:
[0037] Figure 1 This is a flowchart illustrating a task processing method according to an embodiment of this application;
[0038] Figure 2 This is a flowchart of a task processing method according to another embodiment of this application;
[0039] Figure 3 This is a structural block diagram of a task processing device according to another embodiment of this application;
[0040] Figure 4 This is a structural block diagram of an electronic device according to another embodiment of this application. Detailed Implementation
[0041] Various embodiments and features of this application are described herein with reference to the accompanying drawings.
[0042] It should be understood that various modifications can be made to the embodiments described herein. Therefore, the above description should not be considered as limiting, but merely as an example of embodiments. Other modifications within the scope and spirit of this application will be apparent to those skilled in the art.
[0043] The accompanying drawings, which are included in and form part of this specification, illustrate embodiments of the present application and, together with the general description of the present application given above and the detailed description of the embodiments given below, serve to explain the principles of the present application.
[0044] These and other features of this application will become apparent from the following description of preferred forms of embodiments given as non-limiting examples, with reference to the accompanying drawings.
[0045] It should also be understood that although this application has been described with reference to some specific examples, those skilled in the art can certainly implement many other equivalent forms of this application.
[0046] The above and other aspects, features and advantages of this application will become more apparent when taken in conjunction with the accompanying drawings and in view of the following detailed description.
[0047] Specific embodiments of this application are described thereafter with reference to the accompanying drawings; however, it should be understood that the claimed embodiments are merely examples of this application, which can be implemented in various ways. Well-known and / or repeated functions and structures are not described in detail to avoid unnecessary or redundant details that could obscure the application. Therefore, the specific structural and functional details claimed herein are not intended to be limiting, but merely serve as the basis and representative basis for the claims to teach those skilled in the art to use this application in a variety of substantially any suitable detailed structures.
[0048] This specification may use the phrases “in one embodiment,” “in another embodiment,” “in yet another embodiment,” or “in other embodiments,” all of which may refer to one or more of the same or different embodiments according to this application.
[0049] This application provides a task processing method, which can be applied to electronic devices such as terminals and servers. Specifically, taking its application to a server as an example, ... Figure 1 As shown, a task processing method in this embodiment includes the following steps:
[0050] Step S101: Receive a task processing request sent by the target device;
[0051] In this step, the task processing request can be understood as a model invocation request, which uses a large model to process the target task. The target device can be a third-party system that invokes the large model to implement task processing, or it can be a front-end device / interface that invokes the large model to implement task processing. In other words, the back-end server receives the task processing request / model invocation request sent by the front-end.
[0052] Step S102: Based on the task processing request, determine each subtask corresponding to the target task, and create a corresponding subprocess for each subtask;
[0053] In this step, the backend server can first create a main process, and then use the main process to create corresponding subprocesses for each subtask.
[0054] Step S103: Configure a corresponding storage space for each of the sub-processes. The storage space is used to store sub-task data and the sub-task processing results of the pre-defined sub-tasks that have been executed in each of the sub-tasks.
[0055] In this step, storage space can be understood as a predetermined storage location on the backend server, such as a folder under a directory on the backend server. Specifically, it can include a task receiving folder and a task sending folder. Child processes pass messages and handle task flow by retrieving and writing files in these folders, thus eliminating the need to send the results of each subtask processing back to the target device / third-party system / frontend.
[0056] Step S104: For the first subtask to be processed, based on the first subprocess of the first subtask, call the target large model from the predetermined model server, process the subtask data in the first storage space and the subtask processing results of the executed predetermined subtasks based on the target large model, obtain the first processing result of the first subtask, and store the first processing result in the second storage space of the predetermined second subtask, until the processing of each subtask is completed, obtain the target processing result, and send the target processing result to the target device.
[0057] In this step, during task execution, each subprocess can retrieve task information (the subtask data corresponding to the subtask) and the next subprocess ID from its own storage space. After parsing, it interacts with the large model server to process the subtask. After the subtask is processed, the subprocess can write the result to the storage space of the next subprocess based on the ID of the next subprocess in its storage space. This process continues until the entire task is completed. Finally, the final execution result is returned to the target device according to the user-specified return method, thus completing the processing of the target task.
[0058] The task processing method in this embodiment eliminates the need to feed back intermediate results (i.e., the processing results of each subtask) to a third-party system / target device during the target task processing. Instead, it stores the processing results of each subtask in a pre-allocated storage space. This ensures that the target task processing is not affected by the operating status of the third-party system / target device, guaranteeing rapid target task processing and reducing the load on the third-party system / target device. Furthermore, since there is no need to feed back intermediate results to the third-party system / target device, the third-party system / target device does not need additional interface configuration. It only needs to configure a unified interface to send the target task and receive the target processing results, improving interface configuration efficiency and further enhancing task processing efficiency.
[0059] Another embodiment of this application provides a task processing method, in which the execution entity is a backend server. The method in this embodiment includes the following steps:
[0060] Step S201: Create the main process;
[0061] In this step, the backend server can pre-create a main process to communicate with the target device and perform subsequent child process creation operations.
[0062] Step S202: Receive a task processing request sent by the target device;
[0063] In this step, the backend server can receive task processing requests sent by the target device / frontend based on the main process.
[0064] In this step, the user can enter / submit a prompt template (Prompt) in a predefined input box on the target device and select the method for returning the final result (such as returning the target task's processing result via email notification or local storage). The target device can then encapsulate the user-input Prompt into an HTTP request, generating a task processing request / model invocation request, and send this request / model invocation request / HTTP request to the backend server. The server can then receive the HTTP request / task processing request from the target device through its main process. The Prompt contains the task data for the target task, which could be email data requiring a large model for response, text data requiring translation / recognition using a large model, or financial data requiring risk assessment using a large model, etc.
[0065] Step S203: Based on the task processing request, obtain the task data of the target task;
[0066] In this step, after receiving the task processing request / HTTP request, the backend server can parse the task processing request / HTTP request and obtain the task data of the target task from it.
[0067] Step S204: Send a task splitting request to the model server based on the task data;
[0068] In this step, after obtaining the task data, a task splitting request can be generated based on the task data and the predetermined task processing time; then, the task splitting request can be sent to the model server to request the model server to generate a task splitting scheme.
[0069] In the specific implementation process of this step, the backend server can send task splitting requests to the model server through a predefined API interface based on the main process.
[0070] Step S205: Receive the task splitting scheme generated by the model server in response to the task splitting request using a predetermined large model. The task splitting scheme includes at least: several sub-tasks and sub-task data corresponding to each sub-task.
[0071] In this step, after receiving the task splitting request from the backend server, the model server can use a pre-defined large model to split the task data, thereby obtaining a task splitting scheme containing several subtasks and data for each subtask. The pre-defined large model can be a pre-defined large task splitting model.
[0072] Step S206: Create corresponding subprocesses for each of the subtasks based on the main process;
[0073] In this step, after receiving the task splitting scheme from the model server, the backend server can create corresponding subprocesses for each subtask based on the main process and the subtasks in the task splitting scheme.
[0074] Step S207: Configure a corresponding storage space for each of the sub-processes. The storage space is used to store sub-task data and the sub-task processing results of the pre-defined sub-tasks that have been executed in each of the sub-tasks.
[0075] In this step, the main process configures the corresponding storage space for each child process.
[0076] Step S208: For the first subtask to be processed, based on the first subprocess of the first subtask, call the target large model from the predetermined model server, process the subtask data in the first storage space and the subtask processing results of the predetermined subtasks that have been executed based on the target large model, obtain the first processing result of the first subtask, and store the first processing result in the second storage space of the predetermined second subtask, until the processing of each subtask is completed, obtain the target processing result, and send the target processing result to the target device.
[0077] In this step, after configuring the storage space, the backend server can further execute the subtasks. Specifically, the subtasks can be executed according to their execution order and / or dependencies in the task allocation scheme. The execution order includes parallel execution and serial execution. Dependencies refer to the fact that the execution of subtask B requires the result of subtask A.
[0078] In other words, when executing the currently pending subtask B, the subprocess b corresponding to subtask B will call the target large model from the predetermined model server. Then, based on the target large model, it will process the subtask data of subtask B and the processing result of subtask A stored in storage space 1 corresponding to subtask B, thereby obtaining the execution result of subtask B. Then, subprocess b can store the execution result of subtask B in storage space 2 of subtask C according to the dependency relationship (task identifier of subtask C) stored in storage space 1, until the processing of each subtask is completed, the target processing result is obtained, and the target processing result is sent to the target device.
[0079] In this embodiment, the first storage space stores the task identifier of a predetermined second subtask. Before storing the first processing result in the second storage space of the predetermined second subtask, the method further includes: determining the second storage space corresponding to the second subtask based on the task identifier of the second subtask.
[0080] In other words, the storage space corresponding to each subtask not only stores the subtask data, but also the task identifier of the subtask used to determine the subtask dependency relationship. For example, if subtask B depends on subtask A (that is, subtask B can only be executed after subtask A is completed), then the storage space of subtask A will store the task identifier of subtask B, so that subprocess a of subtask A can store the execution result of subtask A into the storage space corresponding to subtask B based on the task identifier of subtask B stored in the storage space of subtask A.
[0081] In this embodiment, the storage space also stores model identifiers used to determine the target large model. By storing the model identifiers in the storage space, the subprocess can accurately retrieve the corresponding target large model from the model server based on the model identifiers, thus laying the foundation for the rapid execution of subtasks.
[0082] In this embodiment, storing the first processing result in the second storage space of the predetermined second subtask specifically includes: based on the first subprocess, storing the first processing result in the second storage space of the predetermined second subtask via the target email protocol. That is, the subprocess stores the processing result of the subtask in the storage space of the next subtask via the target email protocol.
[0083] The task processing method in this embodiment eliminates the need to feed back intermediate results (i.e., the processing results of each subtask) to a third-party system / target device during the target task processing. Instead, it stores the processing results of each subtask in a pre-allocated storage space. This ensures that the target task processing is not affected by the operating status of the third-party system / target device, guaranteeing rapid target task processing and reducing the load on the third-party system / target device. Furthermore, since there is no need to feed back intermediate results to the third-party system / target device, the third-party system / target device does not need additional interface configuration. It only needs to configure a unified interface to send the target task and receive the target processing results, improving interface configuration efficiency and further enhancing task processing efficiency.
[0084] Based on the above embodiments, the task processing method in this application will be explained and described below in conjunction with specific application scenarios, as follows: Figure 2 As shown.
[0085] Taking the development of a large-scale model-based email text analysis system with the IT department of a large enterprise as an example, the system aims to automatically classify, tag, and reply to emails from customers. These emails cover a wide range of topics, including technical support, product inquiries, complaints, and suggestions. Due to the large volume of emails and the need for in-depth text analysis for each email, traditional synchronous processing methods would lead to system resource constraints, slower processing speeds, and a degraded user experience. Therefore, this system (i.e., the third-party system) needs to call upon the large-scale model to analyze, classify, and reply to the email text. Specifically, the model invocation process / target task processing involves three parts: the front-end / target device / email text analysis system, the back-end server, and the large-scale model server / model server. The interaction process and processing flow of each part are as follows:
[0086] Step 1: Front-end user interface (email text analysis system / third-party system / target device);
[0087] Step 1: After logging into the system, users will see an "Upload Email File" button and a drop-down menu for selecting the return method (such as "Email Notification", "System Message", "Automatic Local Storage" etc.) on the front-end interface.
[0088] Step 2: The user selects a compressed file (e.g., .zip format) containing multiple emails (three types: technical support, product consultation, and complaints / suggestions), chooses "email notification" as the result return method, and then clicks the "upload" button;
[0089] Step 3: The front-end encapsulates the file selected by the user into an HTTP POST request, which generates a task processing request. The request body contains the compressed file and the return method information selected by the user, and sends it to the back-end server.
[0090] Step 4: The backend server pre-creates a main process. Upon receiving a task processing request from the frontend, the main process parses the request body to extract the compressed file and return method information. Simultaneously, the backend server generates the task splitting request / task allocation request based on the compressed file and the estimated processing time.
[0091] Step 5: The main process of the backend server sends a task splitting request / task allocation request to the large model server through the API interface to request the generation of a task splitting scheme / task allocation scheme; the task splitting request includes information such as email file size and estimated processing time;
[0092] Step 6: The large model server calls the pre-defined large model according to the task splitting request, processes task splitting / task allocation to generate a task splitting scheme / task allocation scheme. The task splitting scheme includes at least: several sub-tasks and the sub-task data corresponding to each sub-task.
[0093] For example, this task splitting / assignment scheme contains 4 sub-tasks, which means that 4 sub-processes need to be created to handle this batch of emails (for example, based on the number and complexity of emails). The sub-tasks of each sub-process are described in detail (for example, sub-process 1 handles technical support emails, sub-process 2 handles product consultation emails, and sub-process 3 handles complaint and suggestion emails).
[0094] Step 7: The main process of the backend server dynamically creates subprocesses for each subtask according to the task splitting scheme, and allocates a dedicated storage space for each subprocess.
[0095] The storage space can be understood as an "email space," such as a folder under a specific directory on a backend server. This storage space can store subtask data, the execution order of each subtask, the task identifier of the next subtask, and model identifiers, etc. In other words,
[0096] Step 8: Each subprocess retrieves subtask data from its own storage space / task receiving folder according to the execution order, calls the target large model process task processing from the large model server according to the model identifier, obtains the subtask processing result, and stores the task processing result in the storage space of the next subtask according to the task identifier of the next subtask in the storage space / task receiving folder, until the processing of each subtask is completed, the target processing result is obtained, and the target processing result is sent to the target device.
[0097] In other words, subtask A is executed first. Therefore, subprocess 1 of subtask A retrieves the list of technical support emails from its own task receiving folder, as well as the ID of the next subprocess (e.g., subprocess 4, responsible for summarizing all processing results). Then, it calls the target large model from the large model server, processes each email in the technical support email list one by one, uses the large model for text analysis, determines the email category, extracts key information, and generates a draft reply, thus obtaining the processing result. This processing result (including email ID, analysis result, and draft reply) is then written to the task receiving folder of the next subprocess / subtask (e.g., subprocess 4 / task A) according to the ID of the next subprocess. Specifically, subprocess 1 can use the target email protocol to write the processing result to the task receiving folder of subprocess 4 / task D.
[0098] Similarly, subtask B is executed second; therefore, subprocess 2 of subtask B retrieves the list of product consultation emails from the task receiving folder, calls the large model for text analysis, and generates a draft reply. The processing result is then written to the task receiving folder of subprocess 4 via the target email protocol.
[0099] Similarly, subtask C is executed third in the order of execution; therefore, subprocess 3 of subtask C can retrieve complaint and suggestion emails from the task receiving folder, and also call the large model to perform text analysis, generating a draft reply or processing suggestions. The processing results are then written to the task receiving folder of subprocess 4 via the target email protocol.
[0100] Similarly, subtask D is executed fourth in the order of execution; therefore, subprocess 4 of subtask D collects the processing results from subprocesses 1, 2, and 3 from its own task receiving folder. All processing results are summarized and organized to form a final report. Subprocess 4 then sends the final report to the front end / target device / third-party system according to the user-selected return method (email notification).
[0101] In this embodiment, there is no dependency between the subtasks (i.e., subtask A, subtask B, and subtask C), meaning that the execution of subtask A, subtask B, and subtask C is independent. However, in practice, the execution of each subtask can also be non-independent, meaning that subtask B and subtask C depend on subtask A. In this case, after subtask A completes its processing, subprocess 1 of subtask A will use the target mail protocol to store the processing result of subtask A in the storage space of subtask B and the storage space of subtask C, respectively.
[0102] In this embodiment, the user-input prompt is received through the front-end user interface, and this information is encapsulated into an HTTP request and sent to the back-end server. The back-end server, acting as the central hub for task scheduling, has its main process responsible for parsing the request and communicating with the large model server to obtain an optimized task allocation scheme. Based on this scheme, the back-end server dynamically creates multiple child processes and uses an innovative "mailbox space" mechanism to achieve asynchronous message passing and task flow between these child processes. This mechanism avoids the blocking problems caused by direct interface calls, significantly improving the system's concurrent processing capabilities and response speed. Simultaneously, it supports interaction between child processes and the large model server, ensuring that tasks can be executed efficiently in sequence and ultimately returning results according to the user-specified method.
[0103] Another embodiment of this application provides a task processing method, such as... Figure 3 As shown, it includes:
[0104] Receiving module 11 is used to receive task processing requests sent by the target device;
[0105] The creation module 12 is used to determine each subtask corresponding to the target task based on the task processing request, and to create a corresponding subprocess for each subtask;
[0106] Configuration module 13 is used to configure corresponding storage space for each of the subprocesses, wherein the storage space is used to store subtask data and subtask processing results of the pre-defined subtasks that have been executed in each of the subprocesses;
[0107] Processing module 14 is configured to, for the currently pending first subtask, based on the first subprocess of the first subtask, call a target large model from a predetermined model server, process the subtask data in the first storage space and the subtask processing results of the already executed predetermined subtasks based on the target large model, obtain a first processing result of the first subtask, and store the first processing result in the second storage space of a predetermined second subtask, until the processing of each subtask is completed, obtain a target processing result, and send the target processing result to the target device.
[0108] In this embodiment, the creation module specifically includes a process creation unit, which is used to: create a main process; and create corresponding sub-processes for each sub-task based on the main process.
[0109] In this embodiment, the creation module further includes a determining unit, which is specifically used to: obtain task data of the target task based on the task processing request; and send a task splitting request to the model server based on the task data.
[0110] The system receives a task splitting scheme generated by a predetermined large model in response to the task splitting request, which is fed back from the model server. The task splitting scheme includes at least: several sub-tasks and sub-task data corresponding to each sub-task.
[0111] In this embodiment, the task processing device further includes a generation module, which is used to generate the task splitting request based on the task data and a predetermined task processing time before sending the task splitting request to the model server based on the task data.
[0112] In this embodiment, the processing module is specifically used to: based on the first subprocess, store the first processing result in the second storage space of the predetermined second subtask through the target email protocol.
[0113] In this embodiment, the processing module is further configured to: before storing the first processing result in the second storage space of the predetermined second subtask, determine the second storage space corresponding to the second subtask based on the task identifier of the second subtask.
[0114] In this embodiment, the storage space also stores model identifiers used to determine the target large model.
[0115] In this embodiment, the task processing device does not need to feed back the intermediate results of the target task (i.e., the processing results of each subtask) to a third-party system / target device during the target task processing. Instead, it stores the processing results of each subtask in a pre-allocated storage space. This ensures that the processing of the target task is not affected by the operating status of the third-party system / target device, providing a guarantee for the rapid processing of the target task and reducing the load pressure on the third-party system / target device. Furthermore, since there is no need to feed back the intermediate results to the third-party system / target device, the third-party system / target device does not need to perform additional interface configuration. It only needs to configure a unified interface to realize the sending of the target task and the receiving of the target processing results, improving the interface configuration efficiency and further improving the task processing efficiency.
[0116] Another embodiment of this application provides a storage medium storing a computer program, which, when executed by a processor, implements the following method steps:
[0117] Step 1: Receive the task processing request sent by the target device;
[0118] Step 2: Based on the task processing request, determine the sub-tasks corresponding to the target task, and create corresponding sub-processes for each sub-task;
[0119] Step 3: Configure corresponding storage space for each of the sub-processes. The storage space is used to store sub-task data and the sub-task processing results of the pre-defined sub-tasks that have been executed in each of the sub-tasks.
[0120] Step 4: For the first subtask to be processed, based on the first subprocess of the first subtask, call the target large model from the predetermined model server, process the subtask data in the first storage space and the subtask processing results of the predetermined subtasks that have been executed based on the target large model, obtain the first processing result of the first subtask, and store the first processing result in the second storage space of the predetermined second subtask, until the processing of each subtask is completed, obtain the target processing result, and send the target processing result to the target device.
[0121] The specific implementation process of the above method steps can be found in the embodiments of the above task processing methods, and will not be repeated here.
[0122] The storage medium in this application eliminates the need to feed back intermediate results (i.e., the processing results of each subtask) to a third-party system / target device during the target task processing. Instead, it stores the processing results of each subtask in a pre-allocated storage space. This ensures that the target task processing is not affected by the operating status of the third-party system / target device, guaranteeing rapid target task processing and reducing the load on the third-party system / target device. Furthermore, since there is no need to feed back intermediate results to the third-party system / target device, the third-party system / target device does not need additional interface configuration. It only needs to configure a unified interface to send the target task and receive the target processing results, improving interface configuration efficiency and further enhancing task processing efficiency.
[0123] Another embodiment of this application provides an electronic device, such as... Figure 4 As shown, it includes at least a memory 1 and a processor 2. The memory 1 stores a computer program, and the processor 2 performs the following method steps when executing the computer program in the memory 1:
[0124] Step 1: Receive the task processing request sent by the target device;
[0125] Step 2: Based on the task processing request, determine the sub-tasks corresponding to the target task, and create corresponding sub-processes for each sub-task;
[0126] Step 3: Configure corresponding storage space for each of the sub-processes. The storage space is used to store sub-task data and the sub-task processing results of the pre-defined sub-tasks that have been executed in each of the sub-tasks.
[0127] Step 4: For the first subtask to be processed, based on the first subprocess of the first subtask, call the target large model from the predetermined model server, process the subtask data in the first storage space and the subtask processing results of the predetermined subtasks that have been executed based on the target large model, obtain the first processing result of the first subtask, and store the first processing result in the second storage space of the predetermined second subtask, until the processing of each subtask is completed, obtain the target processing result, and send the target processing result to the target device.
[0128] The specific implementation process of the above method steps can be found in the embodiments of the above task processing methods, and will not be repeated here.
[0129] In this application, the electronic device, during the processing of the target task, does not need to feed back the intermediate results of the target task (i.e., the processing results of each subtask) to a third-party system / target device. Instead, it stores the processing results of each subtask in a pre-allocated storage space. This ensures that the processing of the target task is not affected by the operating status of the third-party system / target device, providing a guarantee for the rapid processing of the target task and reducing the load pressure on the third-party system / target device. Furthermore, since there is no need to feed back the intermediate results to the third-party system / target device, the third-party system / target device does not need to perform additional interface configuration. It only needs to configure a unified interface to realize the sending of the target task and the receiving of the target processing results, improving the interface configuration efficiency and further improving the task processing efficiency.
[0130] The above embodiments are merely exemplary embodiments of this application and are not intended to limit this application. The scope of protection of this application is defined by the claims. Those skilled in the art can make various modifications or equivalent substitutions to this application within its substance and scope of protection, and such modifications or equivalent substitutions should also be considered to fall within the scope of protection of this application.
Claims
1. A task processing method characterized by, The method comprises: receiving a task processing request sent by a target device; determining each subtask corresponding to a target task based on the task processing request, and creating a corresponding sub-process for each subtask; configuring a corresponding storage space for each sub-process, the storage space being used to store subtask data and subtask processing results of a predetermined subtask that has been executed in each subtask; for a first subtask to be processed currently, calling a target large model from a predetermined model server based on a first sub-process of the first subtask, processing the subtask data in the first storage space and the subtask processing results of the predetermined subtask that has been executed based on the target large model, obtaining a first processing result of the first subtask, and storing the first processing result to a second storage space of a predetermined second subtask until the processing of each subtask is completed, a target processing result is obtained, and the target processing result is sent to the target device; storing the first processing result to the second storage space of the predetermined second subtask specifically comprises: storing the first processing result to the second storage space of the predetermined second subtask through a target mail protocol based on the first sub-process.
2. The method of claim 1, wherein, The method specifically comprises: creating a main process; creating a corresponding sub-process for each subtask based on the main process.
3. The method of claim 1, wherein, The method specifically comprises: based on the task processing request, obtaining task data of the target task; sending a task splitting request to the model server based on the task data; receiving a task splitting scheme generated by a predetermined large model in response to the task splitting request and fed back by the model server, the task splitting scheme at least including a plurality of subtasks and subtask data corresponding to each subtask.
4. The method of claim 3, wherein, Before sending the task splitting request to the model server based on the task data, the method further comprises: generating the task splitting request based on the task data and a predetermined task processing time.
5. The method of claim 1, wherein, The first storage space stores a task identifier of a predetermined second subtask; before storing the first processing result to the second storage space of the predetermined second subtask, the method further comprises: determining the second storage space corresponding to the second subtask based on the task identifier of the second subtask.
6. The method of claim 1, wherein, The storage space further stores a model identifier used to determine a target large model.
7. A task processing apparatus characterized by comprising: The method comprises: a receiving module configured to receive a task processing request sent by a target device; a creating module configured to determine each subtask corresponding to a target task based on the task processing request, and create a corresponding sub-process for each subtask; a configuring module configured to configure a corresponding storage space for each sub-process, the storage space being used to store subtask data and subtask processing results of a predetermined subtask that has been executed in each subtask; The processing module is configured to, for a first subtask to be processed currently, invoke a target large model from a predetermined model server based on a first sub-process of the first subtask, process subtask data in a first storage space and a subtask processing result of a predetermined subtask that has been executed based on the target large model, obtain a first processing result of the first subtask, and store the first processing result to a second storage space of a predetermined second subtask until processing of each subtask is completed, a target processing result is obtained, and the target processing result is sent to the target device. The processing module is specifically configured to: based on the first sub-process, store the first processing result to the second storage space of the predetermined second subtask through a target mail protocol.
8. A storage medium, characterized by The storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the task processing method in any one of claims 1-6.
9. An electronic device, comprising: At least comprising a memory and a processor, the memory stores a computer program, and the processor implements the steps of the task processing method in any one of claims 1-6 when executing the computer program on the memory.
Citation Information
Patent Citations
Task data construction method and device, computing equipment and readable storage medium
CN117951723A
Asynchronous task processing method and device and storage medium
CN118051316A