Task processing method and device, equipment, vehicle and storage medium

Abstract

The application provides a task processing method and device, equipment, a vehicle and a storage medium, and relates to the technical field of vehicle control. The method comprises the following steps: performing task analysis on a received user request to obtain at least one subtask; performing complexity classification on the user request to obtain a complexity classification result; determining a target execution path according to the complexity classification result; and executing the at least one subtask based on the target execution path. In the manner described above, the complexity of the user request can be classified, and the target execution path can be determined according to the classification result, so that the subtasks can be executed according to a path matched with the complexity of the request, thereby improving the reliability of task processing.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and in particular to a task processing method, apparatus, equipment, vehicle, and storage medium. Background Technology

[0002] The intelligent cockpit voice interaction system is one of the core functions of modern automotive intelligence. Users can make requests through voice or text input, asking the system to complete tasks such as vehicle control, navigation, media playback, and service recommendations.

[0003] In related technologies, natural language understanding schemes based on intent recognition are commonly used to map user requests into structured instructions and break them down into multiple atomic tasks for execution. However, the above approach is prone to confusing chained tasks with step dependencies with independent parallel tasks, causing chained tasks to fail due to being incorrectly broken down, or parallel tasks to suffer unnecessary processing delays due to being misjudged as complex tasks, resulting in low reliability of task processing. Summary of the Invention

[0004] This application provides a task processing method, apparatus, equipment, vehicle, and storage medium to improve the reliability of task processing.

[0005] Firstly, this application provides a task processing method, including:

[0006] The received user request is parsed to obtain at least one subtask;

[0007] The user requests are classified by complexity to obtain the complexity classification results;

[0008] Based on the complexity classification results, the target execution path is determined;

[0009] Based on the target execution path, execute the at least one sub-task.

[0010] In one possible implementation, classifying the user request by complexity to obtain a complexity classification result includes:

[0011] The user request and context information are input into the complexity classification model for semantic analysis to obtain the complexity classification result; the complexity classification result includes task complexity type and interruption type.

[0012] In one possible implementation, the task complexity type includes a first type, a second type, and a third type, wherein the first type indicates that there is no task dependency between the at least one subtask, the second type indicates that there is a task dependency between the at least one subtask, and the third type indicates that the user request does not contain an executable intent;

[0013] The interruption types include no interruption, valid interruption, and invalid interruption.

[0014] In one possible implementation, determining the target execution path based on the complexity classification result includes:

[0015] If the interruption type is no interruption, then the target execution path is determined according to the task complexity type;

[0016] If the interruption type is a valid interruption, then the currently executing task is canceled or suspended, and the target execution path is determined according to the task complexity type.

[0017] In one possible implementation, determining the target execution path based on the task complexity type includes:

[0018] If the task complexity type is the first type, then the target execution path is determined to be the first execution path;

[0019] If the task complexity type is the second type, then the target execution path is determined to be the second execution path.

[0020] In one possible implementation, executing the at least one subtask based on the target execution path includes:

[0021] If the target execution path is the first execution path, then the at least one subtask is executed in parallel;

[0022] If the target execution path is the second execution path, then the at least one subtask is executed step by step according to the dependency relationship between the at least one subtask.

[0023] In one possible implementation, the step-by-step execution of the at least one subtask according to the dependencies between the at least one subtask includes:

[0024] After the currently executing subtask is completed, obtain the execution result of the currently executing subtask;

[0025] Based on the execution result, determine the input parameters for the next subtask to be executed;

[0026] Based on the input parameters, the next subtask to be executed is rewritten, and the rewritten subtask is executed.

[0027] In one possible implementation, the method further includes:

[0028] If the interruption type is the invalid interruption, or the task complexity type is the third type and there is currently an executing task, then the current task state remains unchanged.

[0029] If the task complexity type is the third type and there is currently no task being executed, then the user request will be rejected.

[0030] In one possible implementation, the method further includes:

[0031] If the complexity classification model malfunctions, a rule classifier is invoked to replace the complexity classification model and output the complexity classification result.

[0032] In one possible implementation, the step of parsing the received user request to obtain at least one subtask includes:

[0033] The task planning unit parses the user request to obtain at least one sub-task.

[0034] The router intercepts and temporarily stores the at least one subtask; the router is pre-configured on the output side of the task planning unit to suppress the downstream distribution of the at least one subtask before the target execution path is determined.

[0035] In one possible implementation, the method further includes:

[0036] Record task processing log information corresponding to the user request; the task processing log information includes at least one of the at least one subtask, the complexity classification result, and the target execution path;

[0037] The task processing log information is stored locally on the vehicle or on a cloud server.

[0038] Secondly, this application provides a task processing apparatus, comprising:

[0039] The task parsing module is used to parse the received user requests to obtain at least one subtask.

[0040] The complexity classification module is used to classify the complexity of the user request and obtain the complexity classification result;

[0041] The path determination module is used to determine the target execution path based on the complexity classification results;

[0042] The task execution module is used to execute the at least one sub-task based on the target execution path.

[0043] Thirdly, this application provides an electronic device, including: a memory and a processor;

[0044] The memory stores computer-executed instructions;

[0045] The processor executes computer execution instructions stored in the memory to implement the method as described in any of the first aspects.

[0046] Fourthly, this application provides a vehicle, including a vehicle body and electronic equipment as described in the third aspect.

[0047] Fifthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects above.

[0048] In a sixth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0049] This application provides a task processing method, apparatus, device, vehicle, and storage medium. It parses received user requests to obtain at least one subtask, classifies the complexity of the user requests to obtain a complexity classification result, and then determines a target execution path based on the complexity classification result, executing at least one subtask based on the target execution path. This method enables accurate identification of user request complexity and dynamic matching of task execution paths, thereby avoiding execution failures due to incorrect splitting of chained tasks or delays in parallel tasks due to misjudgment, thus improving the reliability and execution efficiency of task processing. Attached Figure Description

[0050] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0051] Figure 1 A schematic diagram illustrating the application scenarios provided in the embodiments of this application;

[0052] Figure 2 A flowchart illustrating an embodiment of the task processing method provided in this application;

[0053] Figure 3 A flowchart illustrating Embodiment 2 of the task processing method provided in this application;

[0054] Figure 4 A flowchart illustrating Embodiment 3 of the task processing method provided in this application;

[0055] Figure 5 A flowchart illustrating Embodiment 4 of the task processing method provided in this application;

[0056] Figure 6 A flowchart illustrating an example of a task processing method provided in this application embodiment;

[0057] Figure 7 This is a schematic diagram of the structure of the task processing device provided in the embodiments of this application;

[0058] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0059] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0060] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0061] With the rapid development of intelligent connected vehicle technology, the intelligence level of cockpit systems continues to improve. Users can issue various commands to the cockpit system through voice or text interaction, requesting it to complete diverse tasks such as vehicle control, route planning, media resource playback, and nearby service query and recommendation. These tasks differ significantly in structure: some tasks contain only a single operation command, some tasks consist of multiple independent operation commands in parallel, and some tasks contain multiple operation commands that need to be executed in a specific order and have data transfer relationships between them.

[0062] In related technologies, cockpit systems typically employ natural language understanding schemes based on intent recognition, mapping user requests into structured instructions and breaking them down into multiple basic operational units for execution. However, this approach lacks the ability to recognize differences in task structure, easily confusing chained tasks with step dependencies with independent parallel tasks. This can lead to chained tasks failing due to incorrect breakup, or parallel tasks experiencing unnecessary processing delays due to misjudging them as complex tasks, resulting in low reliability of task processing.

[0063] To address the aforementioned problems, the inventors considered classifying user requests by complexity to identify task types and matching corresponding execution paths based on the classification results. Based on this, after numerous experiments, the inventors discovered that the cockpit system can parse received user requests to obtain at least one subtask, classify the user requests by complexity to obtain a complexity classification result, determine the target execution path based on the complexity classification result, and execute at least one subtask based on the target execution path. Through this method, accurate identification of user request complexity and dynamic matching of task execution paths can be achieved, thereby avoiding execution failures due to incorrect chaining of tasks or delays caused by misjudgments in parallel tasks, improving the reliability and execution efficiency of task processing. Based on this, this application provides a task processing method to improve the reliability of task processing.

[0064] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 In the vehicle, the received user request can be processed to obtain the target execution path and at least one subtask; then, based on the target execution path, the at least one subtask can be executed to complete the processing of the user request.

[0065] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0066] Figure 2 This is a flowchart illustrating an embodiment of the task processing method provided in this application. Please refer to [link / reference]. Figure 2 The method includes:

[0067] S201. Perform task parsing on the received user request to obtain at least one subtask.

[0068] The execution subject of this application embodiment can be an electronic device or a task processing device disposed in an electronic device. The task processing device can be implemented by software or by a combination of software and hardware. The task processing device can be a processor in the electronic device. For ease of understanding, the technical solution of this application will be described below using an electronic device as an example.

[0069] In this step, after receiving a user request, the electronic device can parse the user request through an internally pre-configured task planning unit to obtain at least one sub-task. The user request may include instructions input by the user via voice, touch, or gesture.

[0070] Optionally, the task planning unit can use Natural Language Processing (NLP) technology or a pre-defined intent recognition rule base to semantically decompose and parse user requests, breaking down a user request into one or more specific, executable, and logically independent subtasks. For example, if the user request is "turn on the air conditioner and play music," the task planning unit can break it down into an air conditioner control task and a multimedia playback task.

[0071] In some embodiments, when parsing a user request, the task planning unit can also read the vehicle's current context information (such as historical dialogues, the vehicle's current scene, and the speaker's location) and adjust the generation of subtasks based on this context information. For example, if it is determined that the vehicle's current battery level is low, an additional subtask of "finding charging stations along the way" can be automatically added when generating the subtask of "planning a navigation route". By dynamically parsing the context, the matching degree between the task processing results and the vehicle's actual environment can be effectively improved.

[0072] S202. Classify the complexity of user requests and obtain the complexity classification results.

[0073] In this step, after obtaining the user request, the electronic device can also evaluate the complexity of the user request and the execution environment of the current task, thereby obtaining a complexity classification result.

[0074] Optionally, the electronic device can input the user request and current context information into a pre-trained complexity classification model for semantic analysis, and the model will output a complexity classification result. This complexity classification result includes the task complexity type and the interruption type.

[0075] Specifically, the task complexity type can include a first type, a second type, and a third type. The first type indicates that at least one subtask obtained after parsing has no task dependency relationship, and the subtasks can be executed independently and in parallel. For example, the air conditioning control task and the multimedia playback task mentioned above have no dependency relationship, and both can be triggered and executed simultaneously inside the vehicle.

[0076] The second type indicates that there is a task dependency between at least one subtask, meaning that the result of the previous subtask needs to be used as the input parameter for the next subtask. For example, in a navigation scenario, the subtask of planning the navigation route must be executed first before the subsequent navigation broadcast subtask can be executed based on the path information output by that route.

[0077] The third type indicates that the user request does not contain an executable intent. For example, if the user inputs semantically ambiguous words or issues instructions that exceed the vehicle's current functional permissions, it can be determined as the third type.

[0078] Interruption types can include no interruption, valid interruption, and invalid interruption. No interruption means the current user request does not involve changing, canceling, or replacing the target of an existing running task, and there is no need to suspend the current execution process. Valid interruption means the current user request changes, cancels, replaces, or supplements the target, constraints, or execution path of the currently executing task. Invalid interruption means the current user request is invalid noise within a running task, or does not constitute a modification to the current task.

[0079] S203. Determine the target execution path based on the complexity classification results.

[0080] In this step, the electronic device can determine the target execution path based on the determined complexity classification results and the current task status through a preset merging decision-making mechanism.

[0081] In practice, if the interruption type is "no interruption," the electronic device can directly determine the target execution path based on the task complexity type. If the interruption type is "valid interruption," the electronic device first cancels or suspends the currently executing task, and then determines the target execution path based on the task complexity type requested by the current user.

[0082] In one specific embodiment, when the task complexity type is a first type, the target execution path determined by the electronic device is a first execution path. When the task complexity type is a second type, the target execution path determined by the electronic device is a second execution path.

[0083] Optionally, the first execution path is a fast execution channel, which is used to execute subtasks that do not have dependencies on each other in parallel in a low-latency manner. The second execution path is a recoverable multi-step execution channel, which is used to chain subtasks with pre-dependent relationships and can record and suspend the current execution state of the tasks so as to facilitate task recovery or modification in the event of a valid interruption.

[0084] Furthermore, if the interruption type is invalid, or the task complexity type is type three and there is a task currently being executed in the vehicle system, the electronic device will maintain the current task state and ignore the user request. If the task complexity type is type three and the current system is idle, the electronic device will refuse to recognize the user request.

[0085] It should be noted that if the above complexity classification model encounters an abnormal situation during operation and fails to output classification results normally, the electronic device can call the rule classifier to replace the above complexity classification model to output complexity classification results, so as to ensure that the vehicle can still handle user requests in abnormal conditions.

[0086] S204. Execute at least one subtask based on the target execution path.

[0087] In this step, after determining the target execution path, the electronic device can execute at least one parsed subtask according to the execution logic defined by the target execution path.

[0088] If the determined target execution path is the first execution path, the electronic device can send at least one subtask to the first execution path and run these subtasks simultaneously in a parallel execution manner.

[0089] If the determined target execution path is the second execution path, the electronic device can send at least one subtask to the second execution path and execute these subtasks step by step according to the dependencies between the at least one subtask.

[0090] In this embodiment, the electronic device can parse the received user request to obtain at least one subtask; classify the user request by complexity to obtain a complexity classification result; determine the target execution path based on the complexity classification result; and finally, execute at least one subtask based on the target execution path. In the above process, by parsing and classifying the user request by complexity, and determining the appropriate target execution path based on the complexity classification result, matching execution strategies can be adopted for user requests of different complexity levels, thereby avoiding processing anomalies caused by misjudgment of task complexity and effectively improving the reliability of task processing.

[0091] exist Figure 2 Based on the illustrated embodiment, the following, in conjunction with Figure 4 The above task processing methods will be further explained in detail.

[0092] Figure 3 This is a flowchart illustrating Embodiment Two of the task processing method provided in this application. Please refer to [link / reference]. Figure 3 The method includes:

[0093] S301. The task planning unit parses the user request to obtain at least one subtask.

[0094] In this step, the electronic device can parse the user request through an internally pre-set task planning unit to obtain at least one sub-task corresponding to the user request.

[0095] For example, if a user says "turn on the air conditioner and play a song", the task planning unit can parse it as "air conditioner control task" and "multimedia playback task" based on a preset intent recognition rule base.

[0096] For example, if a user says, "Find me the highest-rated and open charging station nearby, and then navigate there," the task planning unit can initially parse it into a "location search task" and a "navigation task" based on a preset intent recognition rule base. The destination parameter of the navigation task needs to be determined by the execution result of the location search task.

[0097] S302. Intercept and temporarily store at least one subtask through the router.

[0098] In this step, the electronic device can intercept and temporarily store at least one subtask parsed above through a router set on the output side of the task planning unit, and suppress the at least one subtask from being sent downstream by blocking signals before determining the target execution path.

[0099] In one specific implementation, after receiving at least one subtask from the task planning unit, the router can cache the at least one subtask in its local cache and maintain a blocking state until the target execution path is determined. This blocking state is only lifted after the target execution path is subsequently determined based on the complexity classification results.

[0100] S303. Input the user request and context information into the complexity classification model, perform semantic analysis, and obtain the complexity classification result. The complexity classification result includes task complexity type and interruption type.

[0101] In this step, the electronic device can input the user request and current context information into a pre-trained complexity classification model for semantic analysis, and the model will output a complexity classification result. This complexity classification result includes the task complexity type and the interruption type. The context information can include historical dialogue, the vehicle's location, the speaker's position, and the current task state of the session.

[0102] This complexity classification model is pre-trained based on sample data. In terms of model construction, it can include a feature input layer, a semantic encoding layer, and a classification output layer. The feature input layer receives the current user request text, as well as contextual information such as historical dialogue, speaker location, vehicle scene values, and task state. The semantic encoding layer extracts semantic features and represents intent from the input feature data. The classification output layer outputs the task complexity type and interruption type based on the output of the semantic encoding layer. During the training phase, the model learns and iterates on a large number of samples to establish a mapping relationship between user input features and complexity classification results.

[0103] During real-time operation, to ensure that the electronic device can accurately parse the model's output, the output of the complexity classification model is constrained to a fixed structured format. If the complexity classification model experiences an anomaly during operation, such as timeout, missing output fields, or output judgment values ​​outside the preset enumeration range, the electronic device enters a fallback process, calling a pre-set rule classifier to replace the complexity classification model's output of the corresponding complexity classification result. This ensures that the electronic device still possesses the basic processing capability for user requests even in abnormal situations.

[0104] This rule classifier is built upon pre-defined decision rules. Internally, it stores multiple conditional decision branches pre-defined by experience or business logic, each corresponding to a complexity classification result. When invoked, the rule classifier, based on the text features of the user request, task status, and context information, matches the decision branch and directly outputs the corresponding task complexity type and interruption type. Compared to complexity classification models, the rule classifier has a relatively fixed decision dimension and weaker generalization ability, but it possesses a definite logical path and a shorter response time. It can serve as an effective backup solution when complexity classification models malfunction, ensuring that electronic devices can still complete basic routing decisions for user requests even in extreme situations.

[0105] For example, the rule classifier can have pre-defined conditional branches. For instance, when a user request contains keywords such as "open" or "play" and the task status is idle, it can be directly determined as the first type; when a user request contains keywords such as "search" or "then navigate", it can be directly determined as the second type.

[0106] Task complexity types can include a first type indicating that there is no task dependency between at least one of the parsed subtasks, a second type indicating that there is a task dependency between at least one of the parsed subtasks, and a third type indicating that the user request does not contain an executable intent. Interruption types can include no interruption indicating that it does not involve changing, canceling, or replacing the target of an existing running task, a valid interruption indicating that it changes, cancels, replaces, or supplements the target, constraints, or execution path of the currently executing task, and an invalid interruption indicating invalid noise within a running task or that does not constitute a modification to the current task.

[0107] For example, when a user requests "turn on the air conditioner and play a song," there is no dependency between the two subtasks, which can be classified as Type 1. When a user requests "find the highest-rated charging station nearby and then navigate there," there is a dependency between the location search task and the navigation task, which can be classified as Type 2. When the user inputs semantically ambiguous words, it can be classified as Type 3. If, during task execution, the user says "change to a nearby coffee shop," and this input changes the current task's execution goal, the interruption type can be classified as valid. If the input is a meaningless interjection, the interruption type can be classified as invalid.

[0108] S304. If the interruption type is no interruption, then determine the target execution path based on the task complexity type.

[0109] In this step, after obtaining the complexity classification result, the electronic device can first determine the interruption type. If it is determined that there is no interruption, it indicates that there is no conflict between the current user request and the existing tasks in the electronic device, and the current execution environment is relatively stable.

[0110] In this case, the electronic device can directly enter the process of determining the target execution path. If the previously output task complexity type is type 1, the target execution path determined by the electronic device is the first execution path; if the task complexity type is type 2, the target execution path determined by the electronic device is the second execution path.

[0111] Optionally, the first execution path is a fast execution channel, which is suitable for handling scenarios where there is no dependency between subtasks and can achieve parallel execution of tasks with low scheduling overhead; the second execution path is a recoverable multi-step execution channel, which is specifically used to handle chained tasks with pre-sequence dependencies and can manage tasks in an orderly manner while ensuring the execution order.

[0112] S305. If the interruption type is valid interruption, cancel or suspend the currently executing task and determine the target execution path based on the task complexity type.

[0113] In this step, if the interruption type in the complexity classification result is a valid interruption, it indicates that there is a conflict between the current user request and the task being executed, and the new request has a higher priority, requiring the electronic device to make adjustments.

[0114] In practice, the electronic device can invoke a task scheduling mechanism to cancel or suspend the currently executing task. Optionally, in the case of suspension, the electronic device can save the execution context of the current task, including the task progress and the intermediate data already acquired, so that execution can be resumed when subsequent conditions are met.

[0115] Furthermore, after suspending or canceling the current task, the electronic device can determine the target execution path based on the task complexity type requested by the current user. If the task complexity type is type one, the target execution path is the first execution path; if the task complexity type is type two, the target execution path is the second execution path.

[0116] S306. Execute at least one subtask based on the target execution path.

[0117] In this step, after determining the target execution path, the electronic device releases the router's blocking status for at least one subtask, releases the subtasks that were previously intercepted and temporarily stored by the router, and executes these subtasks according to the determined target execution path.

[0118] If the determined target execution path is the first execution path, the electronic device will send at least one subtask to the first execution path and run these subtasks simultaneously in a parallel execution manner to improve the overall efficiency of task response.

[0119] If the determined target execution path is the second execution path, the electronic device will send at least one subtask to the second execution path. Through this second execution path, these subtasks will be executed step-by-step according to their dependencies. During the step-by-step execution, after the currently executing subtask is completed, the electronic device can obtain the execution result of that subtask, determine the input parameters for the next subtask to be executed based on the result, rewrite the parameters of the next subtask based on the input parameters, and then execute the rewritten subtask.

[0120] Because the second execution path has the ability to record and suspend the current task execution state, even if the chained task execution is interrupted or effectively broken, the electronic device can resume execution from the breakpoint based on the stored execution context, avoiding the repeated execution of completed preceding subtasks, thereby effectively improving the fault tolerance and recovery efficiency of chained task execution.

[0121] In an optional implementation, for the second execution path, the electronic device may not directly issue the at least one subtask output by the task planning unit and currently temporarily stored, but instead construct and issue a composite planning result message. This composite planning result message includes a classification identifier and route extension information. The classification identifier is set to the second execution path. The route extension information records the semantic classification result, route decision, original planning result, and target execution path identifier. The semantic classification result includes the task complexity type and interruption type requested by the user; the route decision includes the currently determined target execution path and the reason for the route decision. The electronic device can issue this composite planning result message to the second execution path, which then executes the corresponding at least one subtask according to the route extension information in the composite planning result message.

[0122] In some embodiments, the synthetic planning result message may also include a business domain identifier and a domain classification identifier, wherein both the business domain identifier and the domain classification identifier are set as a second execution path to further clarify the message receiving channel and flow direction.

[0123] Optionally, during the step-by-step execution of the second execution path, the electronic device can assign a corresponding execution deadline and timeout threshold to each subtask according to the execution order of each subtask. If the execution time of a certain subtask exceeds the preset timeout threshold, the electronic device can mark the subtask as an execution exception and trigger the exception recovery process.

[0124] Furthermore, when executing chained tasks in the second execution path, the electronic device can locally cache the execution results of each completed subtask. If a subsequent subtask fails, the electronic device does not need to re-execute from the starting point, but instead directly resumes from the result state of the most recently successfully executed subtask.

[0125] In this embodiment, the electronic device can parse user requests using a task planning unit to obtain at least one subtask. This subtask is then intercepted and temporarily stored by a router to prevent premature delivery. Simultaneously, the user request and context information can be input into a complexity classification model for semantic analysis, yielding a complexity classification result including task complexity type and interruption type. A target execution path is then determined based on the interruption type and task complexity type, and the at least one subtask is executed based on this path. In this process, by parsing and classifying tasks, and determining the target execution path based on the interruption type and task complexity type, corresponding processing strategies can be adopted for user requests in different states, reducing execution anomalies caused by misjudgments of task complexity. Furthermore, by intercepting and temporarily storing subtasks before determining the target execution path, the difficulty of rollback caused by premature triggering of downstream execution by the task planning unit's output can be avoided.

[0126] Figure 4 This is a flowchart illustrating Embodiment 3 of the task processing method provided in this application. Please refer to [link / reference]. Figure 4 ,exist Figure 3 Based on the illustrated embodiment, the method further includes:

[0127] S401. If the interruption type is invalid interruption, or the task complexity type is type 3 and there is currently an execution task, then the current task state remains unchanged.

[0128] In this step, after obtaining the complexity classification result, the electronic device can determine the processing strategy for the current user request based on the combination of interruption type and task complexity type. Specifically, when the interruption type is invalid interruption, or the task complexity type is the third type and there is a currently executing task, the electronic device maintains the current task state and ignores the user request.

[0129] When the interruption type is invalid interruption, it indicates that the current user request is invalid noise within a running task and does not constitute a change or supplement to the existing task objective, constraints, or execution path. In this case, the electronic device may not trigger any task scheduling operation or send any execution instructions downstream, maintaining the original state of the current task and continuing execution.

[0130] When the task complexity type is type 3 and there is a currently executing task, it indicates that the user request does not contain an executable intent, but a task is currently being executed in the system. In this case, the electronic device will not interrupt the execution flow of the current task, but will simply discard the user request and maintain the current task state.

[0131] For example, if a user is currently performing a "navigate to destination" task, and then says "haha," this input is neither a clear instruction nor does it change or supplement the current navigation task's goal or route. Therefore, the interruption type can be determined as invalid. The electronic device can then maintain the current task state and continue performing the navigation task, ignoring the interjection.

[0132] S402. If the task complexity type is type 3 and there is currently no task being executed, then the user request will be rejected.

[0133] In this step, if the task complexity type is type 3 and there is no task currently being executed, the electronic device may refuse to recognize the user request.

[0134] Specifically, when the task complexity type is type three, it indicates that the user request does not contain an executable intent. If there is no task being executed on the electronic device at this time, the user request cannot be associated with any task context, nor does it meet the conditions for triggering the execution of a new task. In this case, the electronic device can trigger a rejection mechanism, outputting a rejection result or a clarification result to inform the user that the current input cannot be recognized.

[0135] Optionally, when outputting a rejection or clarification result, the electronic device can provide feedback to the user through the vehicle's infotainment interface or voice broadcast. The electronic device can display relevant prompts on the central control screen indicating that the input could not be recognized, or broadcast guidance information through the vehicle's speakers to prompt the user to re-enter or supplement key information.

[0136] For example, if the vehicle is currently in an idle state with no task to execute, and the user says "haha," the task complexity type is determined to be type three because this input does not contain an executable intent. Furthermore, since there is no currently executing task in the electronic device, the user request cannot be associated with any task context and does not meet the conditions to trigger the execution of a new task. The electronic device can therefore refuse to recognize the user request and output the rejection result through the vehicle's interface or voice announcement, guiding the user to re-enter a valid command.

[0137] In this embodiment, after obtaining the complexity classification result, the electronic device can determine the corresponding processing strategy based on the combination of interruption type and task complexity type. When the interruption type is invalid interruption, or the task complexity type is type three and there is currently an executing task, the electronic device maintains the current task state; when the task complexity type is type three and there is currently no executing task, the electronic device refuses to recognize the user request. In the above process, through this processing strategy, corresponding processing methods can be adopted for invalid or non-executable requests under different task states, thereby avoiding invalid requests from interfering with running tasks or occupying system resources in idle states, and improving the rationality and efficiency of task processing flow.

[0138] Figure 5 This is a flowchart illustrating Embodiment 4 of the task processing method provided in this application. Please refer to [link / reference]. Figure 5 In addition to any of the above embodiments, the method further includes:

[0139] S501. Record the task processing log information corresponding to the user request.

[0140] In this step, the electronic device can record task processing log information corresponding to the user request. This task processing log information is used to record key processing results generated during this task processing, so as to facilitate subsequent task execution tracing, problem localization, and model optimization.

[0141] In one specific implementation, the task processing log information may include at least one of the following: at least one subtask determined in the above steps, a complexity classification result, and a target execution path. Specifically, the at least one subtask is the execution object output by the task planning unit after parsing the user request; the complexity classification result is the judgment result output by the complexity classification model or rule classifier after performing semantic analysis on the user request; and the target execution path is a first execution path or a second execution path determined by the electronic device based on the interruption type and the task complexity type.

[0142] In some embodiments, the task processing log information may further include at least one of the following: the basis for determining the target execution path, the confidence level of the routing decision, and the processing time of this task. The basis for determining the target execution path records the specific reasons for doing so; the confidence level reflects the reliability of the complexity classification result or routing decision; and the processing time reflects the execution efficiency from receiving the user request to determining the target execution path. By recording the above information, the decision-making process and operational efficiency of this task processing can be more comprehensively reconstructed, providing a more sufficient basis for subsequent anomaly investigation, model iteration, and system optimization.

[0143] Optionally, electronic devices can record one or more of the above information as needed to balance the level of detail in the log with storage overhead.

[0144] S502. Store the task processing log information to the vehicle's local machine or cloud server.

[0145] In this step, after recording the task processing log information corresponding to the user request, the electronic device can store the task processing log information in the vehicle's local storage space or upload the task processing log information to the cloud server for storage.

[0146] Optionally, electronic devices can choose the storage method based on the actual application scenario. When there is sufficient local storage space on the vehicle, the electronic device can prioritize storing task processing log information locally on the vehicle so that logs can still be accessed and checked offline. When data aggregation or model optimization is required across vehicles, the electronic device can upload task processing log information to the cloud server through vehicle networking to achieve broader data analysis and strategy tuning.

[0147] In this embodiment, the electronic device can record task processing log information corresponding to user requests and store the task processing log information on the vehicle's local machine or a cloud server. By recording task processing log information, a queryable basis can be provided for subsequent task execution traceability, problem localization, and model optimization. By storing task processing log information on the vehicle's local machine or a cloud server, an appropriate storage method can be selected according to the actual application scenario, thereby ensuring the accessibility of log data while taking into account the rational use of storage space and network resources.

[0148] Figure 6 This is a flowchart illustrating an example of a task processing method provided in this application. Please refer to [link / reference]. Figure 6 The method includes:

[0149] S601, Obtain user request.

[0150] For example, electronic devices can receive user requests via voice input within the cabin, such as "turn on the air conditioning and play a song."

[0151] S602, Read the current task status.

[0152] For example, an electronic device can read the task status of the current session and determine that the current task status is idle, meaning that there is no task currently being executed.

[0153] S603. The task planning unit parses the user request to obtain at least one subtask.

[0154] For example, an electronic device can parse the user request through an internally pre-set task planning unit. Based on a pre-defined intent recognition rule base, the task planning unit parses the user request into two sub-tasks: "air conditioning control task" and "multimedia playback task".

[0155] S604. Intercept and temporarily store at least one subtask through the router.

[0156] For example, electronic devices can intercept and temporarily store the aforementioned "air conditioning control task" and "multimedia playback task" through a router set on the output side of the task planning unit, and suppress the downstream transmission of at least one subtask before determining the target execution path.

[0157] S605. Input the user request and context information into the complexity classification model, perform semantic analysis, and obtain the complexity classification result.

[0158] For example, electronic devices can input user requests and contextual information into a complexity classification model for semantic analysis. Since the current task state is idle, and there is no task dependency between the two operations "turn on the air conditioner" and "play a song" in the user request, the complexity classification model outputs the following complexity classification result: the task complexity type is type 1, and the interruption type is no interruption.

[0159] S606. Determine the target execution path based on the complexity classification results.

[0160] For example, an electronic device can determine the target execution path based on the interruption type and task complexity type in the complexity classification results. Since the interruption type is "no interruption" and the task complexity type is "Type 1," the target execution path determined by the electronic device is the "First Execution Path." The First Execution Path is a fast execution channel used to process subtasks that do not have dependencies on each other in a parallel manner.

[0161] S607. Execute at least one subtask based on the target execution path.

[0162] For example, after determining that the target execution path is the first execution path, the electronic device can remove the router's blocking status for at least one subtask and distribute the previously temporarily stored "air conditioning control task" and "multimedia playback task" to the first execution path. Since the target execution path is the first execution path (i.e., the fast execution channel), the electronic device can use a parallel execution method to simultaneously distribute the air conditioning control task and the multimedia playback task to the corresponding downstream execution modules.

[0163] S608, Perform air conditioning control.

[0164] For example, electronic devices can send air conditioning control tasks to the air conditioning controller through the first execution path, and the air conditioning controller can then perform the corresponding temperature or airflow adjustment operations.

[0165] S609, Perform multimedia playback.

[0166] For example, an electronic device can send a multimedia playback task to a multimedia controller via a first execution path, and the multimedia controller can then perform the song playback operation.

[0167] The task processing example provided in this application allows an electronic device to parse user requests using a task planning unit, obtaining at least one subtask. This subtask is then intercepted and temporarily stored via a router to prevent premature delivery. Simultaneously, the electronic device reads the current task status and inputs the user request and context information into a complexity classification model for semantic analysis, obtaining a complexity classification result. The target execution path is then determined based on the interruption type and task complexity type. This process avoids the difficulty of rollback due to premature task delivery while quickly routing parallel subtasks to the first execution path for parallel execution, improving task processing response efficiency.

[0168] Figure 7 This is a schematic diagram of the task processing device provided in an embodiment of this application. Please refer to... Figure 7 The task processing device 10 includes:

[0169] Task parsing module 11 is used to parse the received user request into a task and obtain at least one subtask.

[0170] Complexity classification module 12 is used to classify the complexity of user requests and obtain the complexity classification results;

[0171] The path determination module 13 is used to determine the target execution path based on the complexity classification results;

[0172] Task execution module 14 is used to execute at least one subtask based on the target execution path.

[0173] The task processing device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0174] In one possible implementation, the complexity classification module 12 is specifically used for:

[0175] The user request and context information are input into the complexity classification model for semantic analysis to obtain the complexity classification results. The complexity classification results include task complexity type and interruption type.

[0176] In one possible implementation, the task complexity type includes a first type, a second type, and a third type. The first type indicates that there is no task dependency between at least one subtask, the second type indicates that there is a task dependency between at least one subtask, and the third type indicates that the user request does not contain an executable intent.

[0177] Interruption types include no interruption, valid interruption, and invalid interruption.

[0178] In one possible implementation, the path determination module 13 is specifically used for:

[0179] If the interruption type is no interruption, then the target execution path is determined based on the task complexity type;

[0180] If the interruption type is valid interruption, the currently executing task is canceled or suspended, and the target execution path is determined based on the task complexity type.

[0181] In one possible implementation, the path determination module 13 is specifically used for:

[0182] If the task complexity type is the first type, then the target execution path is determined to be the first execution path;

[0183] If the task complexity type is type 2, then the target execution path is determined to be the second execution path.

[0184] In one possible implementation, task execution module 14 is specifically used for:

[0185] If the target execution path is the first execution path, then at least one subtask will be executed in parallel.

[0186] If the target execution path is the second execution path, then at least one subtask will be executed step by step according to the dependency relationship between at least one subtask.

[0187] In one possible implementation, task execution module 14 is specifically used for:

[0188] After the currently executing subtask is completed, obtain the execution result of the currently executing subtask;

[0189] Based on the execution results, determine the input parameters for the next subtask to be executed;

[0190] Based on the input parameters, the next subtask to be executed is rewritten, and the rewritten subtask is then executed.

[0191] In one possible implementation, the path determination module 13 is specifically used for:

[0192] If the interruption type is invalid interruption, or the task complexity type is type 3 and there is currently an executing task, then the current task state remains unchanged;

[0193] If the task complexity type is type 3 and there is currently no task being executed, then the user request will be rejected.

[0194] In one possible implementation, the complexity classification module 12 is specifically used for:

[0195] If the complexity classification model malfunctions, the rule classifier will be called to replace the complexity classification model and output the complexity classification result.

[0196] In one possible implementation, the task parsing module 11 is specifically used for:

[0197] The task planning unit parses the user request to obtain at least one subtask.

[0198] At least one subtask is intercepted and temporarily stored by the router; the router is pre-configured on the output side of the task planning unit to suppress at least one subtask from being sent downstream before the target execution path is determined.

[0199] In one possible implementation, task execution module 14 is specifically used for:

[0200] Record task processing log information corresponding to user requests; the task processing log information includes at least one of the following: at least one subtask, complexity classification result, and target execution path;

[0201] The task processing log information is stored locally on the vehicle or on a cloud server.

[0202] The task processing device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0203] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Please refer to... Figure 8 The electronic device 20 provided in this embodiment can be an in-vehicle cockpit domain controller, central computing platform, or vehicle main control unit deployed in a vehicle. The electronic device 20 includes at least one processor 21 and a memory 22. Optionally, the electronic device 20 also includes a communication component 24. The processor 21, memory 22, and communication component 24 are connected via a bus 23.

[0204] In the specific implementation process, at least one processor 21 executes computer execution instructions stored in memory 22, causing at least one processor 21 to perform the above-described task processing method.

[0205] The specific implementation process of processor 21 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0206] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0207] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0208] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0209] This application also provides a vehicle, including a vehicle body, and... Figure 8 The electronic device shown is used to implement the task processing method described in the above embodiments.

[0210] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0211] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0212] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0213] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0214] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units 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 indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0215] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0216] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0217] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0218] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0219] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A task processing method, characterized in that, include: The received user request is parsed to obtain at least one subtask; The user requests are classified by complexity to obtain the complexity classification results; Based on the complexity classification results, the target execution path is determined; Based on the target execution path, execute the at least one sub-task.

2. The method according to claim 1, characterized in that, The process of classifying the complexity of the user request to obtain the complexity classification result includes: The user request and context information are input into the complexity classification model for semantic analysis to obtain the complexity classification result; the complexity classification result includes task complexity type and interruption type.

3. The method according to claim 2, characterized in that, The task complexity types include a first type, a second type, and a third type. The first type indicates that there is no task dependency between the at least one subtask. The second type indicates that there is a task dependency between the at least one subtask. The third type indicates that the user request does not contain an executable intent. The interruption types include no interruption, valid interruption, and invalid interruption.

4. The method according to claim 3, characterized in that, Determining the target execution path based on the complexity classification result includes: If the interruption type is no interruption, then the target execution path is determined according to the task complexity type; If the interruption type is a valid interruption, then the currently executing task is canceled or suspended, and the target execution path is determined according to the task complexity type.

5. The method according to claim 4, characterized in that, Determining the target execution path based on the task complexity type includes: If the task complexity type is the first type, then the target execution path is determined to be the first execution path; If the task complexity type is the second type, then the target execution path is determined to be the second execution path.

6. The method according to claim 5, characterized in that, The execution of the at least one sub-task based on the target execution path includes: If the target execution path is the first execution path, then the at least one subtask is executed in parallel; If the target execution path is the second execution path, then the at least one subtask is executed step by step according to the dependency relationship between the at least one subtask.

7. The method according to claim 6, characterized in that, The step-by-step execution of the at least one subtask according to the dependencies between the at least one subtask includes: After the currently executing subtask is completed, obtain the execution result of the currently executing subtask; Based on the execution result, determine the input parameters for the next subtask to be executed; Based on the input parameters, the next subtask to be executed is rewritten, and the rewritten subtask is executed.

8. The method according to claim 3, characterized in that, The method further includes: If the interruption type is the invalid interruption, or the task complexity type is the third type and there is currently an executing task, then the current task state remains unchanged. If the task complexity type is the third type and there is currently no task being executed, then the user request will be rejected.

9. The method according to any one of claims 2-8, characterized in that, The method further includes: If the complexity classification model malfunctions, a rule classifier is invoked to replace the complexity classification model and output the complexity classification result.

10. The method according to any one of claims 1-8, characterized in that, The step of parsing the received user request to obtain at least one subtask includes: The task planning unit parses the user request to obtain at least one sub-task. The router intercepts and temporarily stores the at least one subtask; the router is pre-configured on the output side of the task planning unit to suppress the at least one subtask from being sent downstream before the target execution path is determined.

11. The method according to any one of claims 1-8, characterized in that, The method further includes: Record task processing log information corresponding to the user request; the task processing log information includes at least one of the at least one subtask, the complexity classification result, and the target execution path; The task processing log information is stored locally on the vehicle or on a cloud server.

12. A task processing device, characterized in that, include: The task parsing module is used to parse the received user requests to obtain at least one subtask. The complexity classification module is used to classify the complexity of the user request and obtain the complexity classification result; The path determination module is used to determine the target execution path based on the complexity classification results; The task execution module is used to execute the at least one sub-task based on the target execution path.

13. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-11.

14. A vehicle, characterized in that, It includes the vehicle body and the electronic equipment as described in claim 13.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-11.

Images