A method for processing a multi-intent question and answer request and an electronic device

Abstract

This application relates to the field of question-and-answer request technology, and discloses a method and electronic device for processing multi-intent question-and-answer requests. The method includes: acquiring a question-and-answer request input by a user; identifying the question-and-answer request to obtain multiple intents and the confidence level of each intent, wherein the confidence level is used to characterize the credibility of the corresponding intent; determining the intents among the multiple intents whose confidence level is greater than or equal to a preset confidence threshold as intents to be executed, thus obtaining multiple intents to be executed; marking the execution order of the multiple intents to be executed; and processing the question-and-answer request according to the execution order and the multiple intents to be executed. Through the above method, this application not only avoids the loss of secondary intents, but also avoids misjudgment of execution order and logical confusion caused by the lack of sequential semantics between intents, thereby improving the response quality to multi-intent question-and-answer requests.

Description

Technical Field

[0001] This application relates to the field of question-and-answer request technology, specifically to a method and electronic device for processing multi-intent question-and-answer requests. Background Technology

[0002] With the development of artificial intelligence technology, natural language understanding is increasingly widely used in intelligent dialogue systems. In real-world interaction scenarios (such as automotive diagnostics), due to the limitations of colloquial expression and the coherence of operations, a single user input request usually contains multiple independent operational intentions, such as "check the fault tree and then open the engine data stream".

[0003] Existing technologies often only support the recognition and output of a single intent when processing user-inputted question-and-answer requests. They are difficult to effectively handle requests involving multiple steps, which can easily lead to the loss of secondary intents and force users to perform repeated interactions.

[0004] However, even if some technologies support the recognition of multiple intents, they ignore the sequential semantics between multiple intents during processing, which leads to misjudgment of the execution order in downstream task planning, resulting in low response quality when responding to user input question-and-answer requests.

[0005] Therefore, improving the response quality to multi-intent question-answering requests has become an urgent technical problem to be solved. Summary of the Invention

[0006] In view of the above problems, embodiments of this application provide a method for processing multi-intent question-and-answer requests and an electronic device to solve the problem that the response quality of responding to question-and-answer requests in the prior art needs to be improved.

[0007] According to one aspect of the embodiments of this application, a method for processing multi-intent question-and-answer requests is provided. The method includes: obtaining a question-and-answer request input by a user; identifying the question-and-answer request to obtain multiple intents and the confidence level of each intent, wherein the confidence level is used to characterize the credibility of the corresponding intent; determining the intents among the multiple intents whose confidence level is greater than or equal to a preset confidence threshold as intents to be executed, thereby obtaining multiple intents to be executed; marking the execution order of the multiple intents to be executed; and processing the question-and-answer request according to the execution order and the multiple intents to be executed.

[0008] In one optional approach, the execution order of multiple intents to be executed is marked, including: analyzing the semantic features and business dependencies of the multiple intents to be executed in the question-and-answer request according to their natural order of expression; if the analysis reveals that two intents to be executed have a sequential indication in their semantic features, or that the latter intent depends on the execution result of the former intent in terms of business, then the two intents are marked as sequentially executed; if the analysis reveals that two intents have an indicator word indicating simultaneous execution in their semantic features, or that there is no sequential dependency in terms of business, then the two intents are marked as parallelly executed; and the execution order of the multiple intents to be executed is marked according to the execution order of the two intents.

[0009] In one alternative approach, the question-and-answer request is identified to obtain multiple intents and the confidence level of each intent, including: performing intent boundary detection on the question-and-answer request based on a preset feature set; if a feature from the preset feature set is detected in the question-and-answer request, the question-and-answer request is segmented into multiple sub-segments based on the detected feature; and performing intent identification on each segmented sub-segment to obtain the intent corresponding to each segment and the confidence level of the intent.

[0010] In an alternative approach, before processing the question-and-answer request according to the execution order and multiple pending intents, the method further includes: determining a slot pattern for each pending intent; filling slot parameters in the slot pattern according to the question-and-answer request; and processing the question-and-answer request according to the execution order and multiple pending intents, including: processing the question-and-answer request according to the slot parameters and the execution order.

[0011] In one optional approach, the slot parameters in the slot mode include at least one of the following: fault code list, vehicle information sub-item slot, and operation information sub-item slot; the vehicle information sub-item slot includes at least one of the following: brand slot, model slot, year slot, and vehicle identification number slot; the operation information sub-item slot includes at least one of the following: action type slot and target function module identifier slot; the parameters of the action type slot include at least one of the following: read code, clear code, open, or jump; and the parameters of the target function module identifier slot include at least one of the following: fault code reading module and data stream module.

[0012] In one alternative approach, the slot parameter type includes required slots; after determining the slot pattern for each intent to be executed, and before filling the slot parameters in the slot pattern according to the question-and-answer request, the method further includes: comparing the slot pattern of the current intent to be executed with the determined slot patterns; if there is a slot parameter in the determined slot pattern that matches the slot parameter of the current intent to be executed, then filling the slot parameter of the current intent to be executed based on the field of the slot parameter that matches the slot parameter of the current intent to be executed; filling the slot parameters in the slot pattern according to the question-and-answer request includes: if there is no slot parameter in the determined slot pattern that matches the slot parameter of the current intent to be executed. If the slot parameters of the intents are consistent, the slot parameters in the slot pattern are filled according to the question-and-answer request. After filling the slot parameters in the slot pattern according to the question-and-answer request, and before processing the question-and-answer request according to the slot parameters and execution order, the method further includes: identifying the required slots with missing parameters in multiple intents to be executed as slots to be filled; obtaining diagnostic scenario context information and / or historical session information corresponding to the question-and-answer request, wherein the diagnostic scenario context information is collected from the target vehicle; and filling the slots to be filled according to the slot parameter values ​​contained in the diagnostic scenario context information and / or the historical session information.

[0013] In one alternative approach, after filling the slot to be filled based on the slot parameter values ​​contained in the diagnostic scenario context information and / or historical session information, and before processing the question-and-answer request based on the slot parameters and execution order, the method further includes: if the slot parameter values ​​contained in the diagnostic scenario context information and / or historical session information cannot fill the slot to be filled, generating completion prompt information corresponding to the slot to be filled; marking the state of the pending execution intent with missing required slot parameters as an incomplete state; outputting the completion prompt information; obtaining first feedback information corresponding to the completion prompt information; filling the slot to be filled for the pending execution intent in the incomplete state based on the first feedback information; and processing the question-and-answer request based on the completed slot parameters, execution order, and multiple pending execution intents.

[0014] In one alternative approach, the question-and-answer request is processed based on slot parameters and execution order, including: forming a slot set from the slot parameters of the intent to be executed in key-value form; and processing the question-and-answer request based on the slot set of each intent to be executed and the execution order.

[0015] In one alternative approach, after identifying the question-and-answer request and obtaining multiple intents and the confidence level of each intent, the method further includes: if the confidence levels of multiple intents are all less than a preset confidence threshold, generating clarification information; outputting the clarification information; obtaining second feedback information corresponding to the clarification information; and updating the question-and-answer request based on the second feedback information to process the updated question-and-answer request.

[0016] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the multi-intent question-answering request processing method as described in any of the preceding claims.

[0017] This application embodiment identifies user-input question-and-answer requests to obtain multiple intents and their confidence levels. Intents with confidence levels greater than or equal to a preset confidence threshold are identified as intents to be executed, thus avoiding the loss of secondary intents. By marking the execution order of the multiple intents to be executed and processing the question-and-answer requests according to the execution order and the multiple intents to be executed, only high-confidence intents to be executed are processed, which avoids ambiguous intents interfering with the execution of downstream tasks. The execution order of the identified multiple intents to be executed is explicitly marked, so that the downstream task planning and processing can be scheduled sequentially or in parallel according to the execution order, avoiding misjudgment of execution order and logical confusion caused by the lack of semantic order between intents, thereby improving the response quality to multi-intent question-and-answer requests.

[0018] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0019] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This illustration shows an application scenario diagram of the multi-intent question-answering request processing method provided in the embodiments of this application; Figure 2 A flowchart illustrating the multi-intent question-answering request processing method provided in an embodiment of this application is shown. Figure 3 A schematic diagram of the structure of a multi-intent question-answering request processing apparatus provided in an embodiment of this application is shown; Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0020] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein.

[0021] The multi-intent question-answering request processing method provided in this application embodiment is applied to electronic devices. Figure 1 This illustration shows an application scenario diagram of the multi-intent question-answering request processing method provided in the embodiments of this application, such as... Figure 1 As shown, in one alternative approach, such as Figure 1 As shown in P1, the electronic device that executes the multi-intent question-answering request processing method is the user's client device. In this case, the client device itself has computing and routing capabilities, and can directly complete semantic parsing, intent processing, and request distribution locally. In another optional approach, such as... Figure 1 As shown in P2, the user's client device interacts with another electronic device via network transmission, sending the natural language query text entered by the user on the client device to the electronic device. At this time, the electronic device acts as an independent server or edge node for centralized scheduling.

[0022] In automotive diagnostics, the user's client device can be a cloud-based diagnostic server, a local diagnostic workstation, an edge computing node, an automotive diagnostic tool, or an in-vehicle terminal. It connects to the vehicle's Electronic Control Unit (ECU) via a vehicle communication interface, reading vehicle status information such as fault codes and data streams in real time and reporting this as the operating environment. Simultaneously, it receives voice or text input from repair personnel. In this scenario, the electronic device can be a local diagnostic workstation or a cloud-based diagnostic server. It receives the query text and operating environment data reported by the client device and schedules different diagnostic agents locally or in the cloud to perform intent recognition and response generation.

[0023] Furthermore, the large model of the intelligent agent can be deployed on electronic devices to reduce network latency; alternatively, it can be deployed on another server. The electronic device sends the natural language query text to the server with the large model deployed, receives the response data returned by the server, and then responds to the user's natural language query text based on the response data to complete the interaction. This deployment method can reduce the computing power pressure on the routing device.

[0024] Figure 2 The diagram shows a flowchart illustrating a method for processing multi-intent question-answering requests provided in an embodiment of this application. Figure 2 The process shown can be derived from Figure 1 The execution is performed by the client device in P1 or the electronic device in P2. The following description refers to the execution by the electronic device in P2. Figure 2 The process shown below will be used as an example for explanation. Figure 2 As shown, the method includes the following steps S110~S150: S110, Obtain the user's input question-and-answer request.

[0025] In automotive diagnostic scenarios, user input is characterized by its conversational style, high concentration of technical terms, and the frequent inclusion of multiple operational requests within a single sentence. This question-and-answer request is typically a natural language query text input by the technician via a client device, or it can be text transcribed from speech. For example, if a technician's hands are occupied in the workshop, they might input a series of short commands, such as "Check the fault tree for P0171, then open the engine data stream." Upon receiving this request, the electronic device uses it as foundational data for subsequent semantic understanding and intent recognition. Furthermore, the electronic device can simultaneously capture a snapshot of the current vehicle's diagnostic scenario, such as the current brand, model, year, vehicle identification number, and the current interface, to provide auxiliary context for subsequent processing, such as intent processing and slot filling.

[0026] S120, Identify the question-and-answer request to obtain multiple intents and the confidence level of each intent, wherein the confidence level is used to characterize the credibility of the corresponding intent.

[0027] Intent refers to the user's expressed purpose for operation, which corresponds to a specific function execution path. In the context of automotive diagnostics, it usually belongs to a specific business domain, such as function jump, fault diagnosis, system application, or knowledge question and answer.

[0028] Multi-intent recognition refers to identifying two or more independent operational intents in a single user question-and-answer request and assigning a label to each intent.

[0029] The probability or score given for each identified intent is the confidence score, which characterizes the credibility of the corresponding intent and is an important basis for quality screening and fast / slow path traffic allocation. Specifically, question-answering requests can be classified into intents using a multi-label classification model, with each label accompanied by a confidence score value.

[0030] Taking "Check the fault tree of P0171 and then open the engine data stream" as an example, the electronic device can identify two intentions through multi-label intent classification: Intention A belongs to the fault diagnosis domain, specifically checking the fault tree, with a confidence level of 0.92; Intention B belongs to the vehicle function domain, specifically jumping to open the function, with a confidence level of 0.88.

[0031] By recognizing and outputting all valid intents in a single round, secondary intents can be avoided from being discarded.

[0032] S130, among multiple intents, the intents with a confidence level greater than or equal to a preset confidence threshold are identified as intents to be executed, thus obtaining multiple intents to be executed.

[0033] The preset confidence threshold is a parameter used to distinguish between highly certain intentions and ambiguous intentions. Because colloquial expressions may contain colloquial words or irrelevant information, some identified intentions have low confidence and are considered noisy intentions.

[0034] Directly processing low-confidence intents could interfere with downstream task execution. Therefore, the electronic device compares the confidence levels of multiple identified intents with a preset confidence threshold. For example, if the preset confidence threshold is set to 0.5, and intents A and B both have confidence levels greater than 0.5, they are both identified as intents to be executed. If the confidence level of an intent is lower than 0.5, it is considered noise and discarded separately, not proceeding to the next step. In this way, the electronic device retains only highly deterministic intents, avoiding interference from ambiguous intents with downstream task execution.

[0035] S140 marks the execution order for multiple pending intents.

[0036] In existing technologies, even if some solutions can identify multiple intents, they often overlook the sequential semantics between these intents, leading to misjudgments of execution order in downstream task planning and consequently causing logical confusion. Execution order reflects user word order or business dependencies, including information such as sequential execution, parallel execution, and specific sequence numbers. Electronic devices can assign incremental sequence numbers or explicitly label parallel relationships to each intent to be executed based on the order of conjunctions, verbs, or business dependencies in the question-and-answer request. In the example above, the user used the phrase "Check... then open...", where the word "then" clearly indicates the order. Therefore, the electronic device will label the execution order of intent A as 1 and the sequence type as sequential; and label the execution order of intent B as 2 and the sequence type as sequential.

[0037] S150, process the question and answer request according to the execution order and multiple pending intents.

[0038] After completing intent filtering and sequence labeling, the electronic device assembles this information into a structured semantic understanding result, typically represented as an intent list, where each element includes the domain, intent, confidence level, and execution order. This structured result is then provided to the downstream task orchestration and planning service. Upon receiving this structured result, the downstream task planning service can schedule the corresponding diagnostic agents or toolchains sequentially or in parallel according to the execution order. In the aforementioned example, the task planning service first schedules the fault diagnosis agent to perform the fault tree lookup operation. After its completion, it then schedules the function jump agent to open the engine data stream interface. By processing according to the explicitly labeled execution order, the risk of guessing based solely on word order is avoided, ensuring the logical coherence of multi-step requests during execution.

[0039] By acquiring question-and-answer requests containing multiple operational purposes and identifying all intents and their confidence levels, the loss of secondary intents can be effectively avoided. By setting a confidence threshold to filter out ambiguous intents with low confidence, high-quality intents to be executed are retained. Furthermore, by marking the execution order of intents to be executed, downstream task planning and processing can be scheduled sequentially or in parallel according to this execution order, effectively avoiding misjudgment of execution order and logical confusion caused by the lack of semantic order between intents, thereby improving the response quality and task completion rate for multi-intent question-and-answer requests.

[0040] In real-world automotive diagnostic scenarios, a single user-inputted question-and-answer request often contains multiple operational intents that are sequential or parallel. To ensure the accuracy of downstream task planning, the electronic device needs to analyze adjacent intents one by one and mark their execution order according to the natural order of the intents in the question-and-answer request. Specifically, S140 includes sub-steps S141~S144: S141, according to the natural order of multiple execution intents in the question-and-answer request, analyze the semantic features and business dependencies of multiple execution intents in the question-and-answer request.

[0041] Among them, natural word order refers to the order of sentences when a user enters a question-and-answer request; semantic features mainly refer to grammatical or lexical indicators such as conjunctions and time adverbs contained in the sentences, such as words like "then", "again", and "at the same time"; business dependency relationship refers to the pre- and post-requirement relationship between two operational intentions in the automotive diagnostic business logic, that is, whether the execution of the latter intention requires the execution result of the former intention as an input condition.

[0042] Electronic devices extract these semantic features from question-and-answer requests and combine them with diagnostic business logic to determine whether and what kind of relationship exists between intents.

[0043] S142. If it is found that two intentions to be executed have a sequential indication in terms of semantic features, or the latter intention depends on the execution result of the former intention in terms of business, then the two intentions are marked as sequential execution.

[0044] Sequence indicators are typically found in conjunctions such as "then," "again," and "following" in user statements. For example, in the question-and-answer request "Check the fault tree for P0171, then open the engine data stream," the electronic device recognizes the sequence indicator "again," thus determining that there is a clear sequential order between the two adjacent intentions: checking the fault tree and opening the data stream. On the other hand, business dependencies are also an important basis for determining sequential execution. For example, if a user inputs "Read the current fault codes, then clear them," although there is a semantic indication, from a business logic perspective, the intention to clear fault codes depends on the fault code list obtained by the intention to read fault codes as a parameter input. In this case, the electronic device will mark these two intentions as sequential execution and assign them incremental sequence numbers to reflect this irreversible execution logic.

[0045] S143. If the analysis reveals that two intentions have semantic features indicating simultaneous execution, or have no sequential dependency in terms of business logic, then the two intentions are marked as being executed in parallel.

[0046] Indicators indicating simultaneous execution typically include words like "simultaneously," "while...while...", or "together." For example, if a user inputs "simultaneously open the data stream and read the fault code," the electronic device recognizes the instruction "simultaneously" and determines that these two intentions can be processed concurrently. Furthermore, even without explicit instructions, if two intentions are completely independent in terms of business logic, do not interfere with each other, and have no dependency, such as "open the maintenance manual and modify system settings," the electronic device will also determine that they have no sequential dependency. In such cases, the electronic device will mark the two intentions as being executed in parallel. In practical implementation, parallel intentions can be assigned the same sequence number, or an explicit parallel type flag can be added to instruct downstream task planning services to schedule these intentions concurrently, thereby improving processing efficiency.

[0047] S144: Mark the execution order of multiple pending intents according to the execution order of two intents.

[0048] Since a question-and-answer request may contain three or more intents, the electronic device needs to analyze each pair of adjacent intents according to the aforementioned judgment rules to obtain the order or parallel relationship of locally adjacent intents before performing a global comprehensive deduction. For example, if intent A and intent B are executed sequentially, and intent B and intent C are executed sequentially, then during global annotation, intents A, B, and C will receive incrementing sequence numbers 1, 2, and 3, all with the order type being sequential. If intent A and intent B are executed in parallel, and intent B and intent C are executed sequentially, then intents A and B can share sequence number 1 and be marked as parallel, while intent C receives sequence number 2 and is marked as sequential, and depends on intent B. The electronic device ultimately generates a global execution order annotation containing sequence numbers and order types for all intents to be executed, forming a structured list of intents.

[0049] Through S141~S144, the sequential and parallel relationships between intents to be executed can be accurately distinguished based on the user's natural language word order and the actual dependency logic of the vehicle diagnostic business. This explicit annotation of sequential semantics enables the downstream task planning service to execute dependent intents step by step and merge independent intents into a single step for concurrent processing when generating the execution plan. This avoids the risk of guessing the execution order based solely on spoken word order and ensures the logical rigor and scheduling efficiency of multi-step requests during task execution.

[0050] In real-world automotive diagnostic scenarios, users' colloquial expressions often combine multiple operational intentions into a short sentence. If the entire sentence is directly classified using multi-labels, the model may miss secondary intentions due to the complexity of the sentence structure. Therefore, in one alternative approach, S120 includes sub-steps S121~S123: S121, perform intent boundary detection on the question-answering request based on the preset feature set.

[0051] The preset feature set includes preset conjunction features, verb parallel features, and explicit dot features. Conjunction features, such as words like "then," "again," and "simultaneously," are commonly used connectives when users express multi-step operations. Verb parallel features refer to the consecutive appearance of multiple action verbs in a sentence, such as "read and clear fault codes." Explicit dot features are when users use numbers or punctuation marks to explicitly list operations, such as "first...second...". After receiving a question-and-answer request, the electronic device scans the text content and matches it with features from the preset feature set to determine whether there are multiple intent boundaries in the sentence.

[0052] S122, if a feature from a preset feature set is detected in the question-and-answer request, the question-and-answer request is divided into multiple sub-segments based on the detected feature.

[0053] After detecting boundary features, the electronic device uses the locations of these features as segmentation points to break down the entire question-and-answer request into multiple relatively independent sub-segments. For example, for the user input "Check the fault tree of P0171, then open the engine data stream," the electronic device detects the conjunction "then" and uses "then" as the boundary to divide the request into two sub-segments: "Check the fault tree of P0171" and "Open the engine data stream." If no preset features are detected, it indicates that the request is a single-intent request, and the electronic device will treat it as a single segment and proceed directly to subsequent processing.

[0054] By segmenting, complex compound requests are simplified into multiple semantically simple fragments, reducing the difficulty for the model to directly process long sentences.

[0055] S123, perform intent recognition on each segment obtained from the segmentation to obtain the intent and confidence level of each segment.

[0056] After obtaining multiple sub-segments, the electronic device independently classifies the intent of each sub-segment using a multi-label classification model or a generative model. Each sub-segment, after model processing, outputs one or more intent labels along with corresponding confidence scores. The confidence score characterizes the reliability of the model's judgment of that intent. For example, identifying the sub-segment "Check the fault tree for P0171" results in the intent "Check the fault tree" in the fault diagnosis domain, with a confidence score of 0.92; identifying the sub-segment "Open the engine data stream" results in the intent "Jump to open the function" in the vehicle function domain, with a confidence score of 0.88.

[0057] By identifying each sub-segment separately, it can be ensured that the purpose of each operation in a single sentence with multiple requests is parsed independently, avoiding the neglect of secondary intentions in the overall processing.

[0058] By accurately extracting multiple intentions and their confidence levels from complex and coherent natural language, intention recognition can be made more focused and accurate.

[0059] In automotive diagnostics, simply identifying that the user wants to check the fault tree or open a data stream is insufficient; it is also necessary to know which vehicle and which fault code the operation is for. Therefore, in one optional approach, prior to S150, the method further includes sub-steps S131-S132: S131, determine the slot pattern for each intent to be executed.

[0060] Among them, a slot refers to a structured parameter corresponding to an intent, which is used to carry information such as vehicle identification, fault code, and target interface required to complete the intent; the slot pattern is a set of parameters required for a specific intent that is predefined according to the diagnostic business, including mandatory slots and optional slots.

[0061] After determining the intent to be executed, the electronic device will look up the corresponding slot pattern from the preset rules or configuration table according to the domain and specific tag of the intent. For example, for the intent to query the fault tree, the corresponding slot pattern usually includes the fault code list slot and the vehicle information related slot; for the intent to jump to open function, the slot pattern includes the target function module identifier slot and the action type slot.

[0062] S132, Fill in the slot parameters in the slot mode according to the question and answer request.

[0063] After determining the slot pattern, the electronic device will analyze the question-and-answer request text or the segmented sub-segments again, and extract parameter values ​​that conform to the slot semantics using methods such as sequence labeling, rule matching, or large model structured output. For example, for the sub-segment "Check the fault tree of P0171", the electronic device will extract the string "P0171" and fill it into the fault code list slot; for the sub-segment "Open engine data stream", the electronic device will extract "open" as the parameter of the action type slot and extract "engine data stream" as the parameter of the target function module identifier slot.

[0064] By filling in the slot parameters, the original intent, which only contained semantic labels, is enriched into a structured instruction that includes specific operation objects and execution actions.

[0065] Accordingly, S150 includes the sub-step: S151, which processes the question and answer request according to the slot parameters and execution order.

[0066] Since the slot parameters are a structured form of the intent to be executed, the question and answer requests can be processed directly based on the slot parameters and the execution order.

[0067] Optionally, S151 includes sub-step S151a: forming a slot set in key-value form for each slot parameter of the intent to be executed; and processing the question and answer request according to the slot set of each intent to be executed and the execution order.

[0068] At this point, the electronic device not only understands the intents contained in the user's request, the credibility of each intent, and their execution order, but also acquires the specific parameters required to execute these intents. The electronic device assembles information such as domain, intent, confidence level, slot parameters, and execution order into a structured semantic understanding result list and provides it to downstream task orchestration and planning services. Upon receiving this structured result, downstream services can directly invoke the corresponding diagnostic tools or agents based on the slot parameters and execute them sequentially or in parallel according to the execution order. Since the parameters have already been extracted at the granularity of the diagnostic business, downstream services do not need to perform secondary parsing of natural language, thereby improving processing efficiency and accuracy.

[0069] By introducing the determination of slot patterns and parameter filling before marking the execution order, the processing of multi-intent question-and-answer requests can go beyond the intent classification level and delve into the specific business execution level. This ensures that each intent to be executed has a clear operation object and execution method, providing a data foundation for the automated execution of complex multi-step operations in automotive diagnostic scenarios.

[0070] After determining the slot pattern for each execution intent, to ensure that the extracted parameters directly meet the requirements of downstream diagnostic toolchains or intelligent agents for sub-parameters, the slot parameters in the slot pattern must include at least one of the following: fault code list, vehicle information sub-slot, and operation information sub-slot. Existing technologies often merge vehicle or operation information into a few fields; such coarse-grained parameters cannot be accurately accessed directly by the device or cloud. Therefore, more specifically, the vehicle information sub-slot must include at least one of the following: brand slot, model slot, year slot, and vehicle identification number slot; the operation information sub-slot must include at least one of the following: action type slot and target function module identifier slot; the action type slot parameters must include at least one of the following: read code, clear code, open, or jump; and the target function module identifier slot parameters must include at least one of the following: fault code reading module and data stream module.

[0071] A fault code list is a text list containing one or more diagnostic fault codes obtained from diagnosing a vehicle.

[0072] The vehicle information sub-slots are used to hold the various independent data required to locate the vehicle model and identity. This slot includes at least one of the following: brand, model, year, or vehicle identification number (VIN). Brand, model, and year are common terms used in the automotive repair industry to locate vehicle models; they are collectively referred to as Make, Model, and Year. In automotive diagnostics, vehicles of different brands, models, and years have different electronic control unit configurations and diagnostic protocols, thus requiring them to be separated into independent sub-slots. For example, the brand slot parameter could be "Brand A," the model slot parameter could be "Model B," and the year slot parameter could be "2022." Furthermore, the VIN is the unique identifier of a vehicle, and the parameters of the VIN slot are directly associated with the specific physical vehicle. By setting these sub-slots, the diagnostic database and communication protocols of the target vehicle can be accurately located during diagnosis, avoiding diagnostic errors caused by confusion of vehicle information.

[0073] The operation information slot is used to carry the execution actions and target object information required to complete a specific diagnostic intent. This slot must include at least one of an action type slot and a target function module identifier slot. The action type slot defines the specific operation the system needs to perform, and its parameters must include at least one of read code, clear code, open, or jump. For example, when a user requests to clear the current fault, the action type slot parameter will be filled with clear code; when a user requests to enter a certain interface, the action type slot parameter will be filled with open or jump. The target function module identifier slot defines the specific business module or interface to which the action acts, and its parameters must include at least one of a fault code reading module and a data flow module. Taking the fault code reading module as an example, it is usually associated with the logic for parsing diagnostic fault codes; the data flow module is associated with the function of collecting real-time vehicle operating data. By clearly defining the action type and target module, the electronic device can directly route instructions to the correct function execution path.

[0074] By refining slot parameters into vehicle information sub-slots and operation information sub-slots, and further subdividing them into specific independent fields such as brand, model, action type, and target module, the structured data output by electronic devices can maintain a high degree of consistency with typical diagnostic action parameters such as code reading, code clearing, and data flow. Downstream task planning and orchestration services can directly call the corresponding toolchain without having to perform secondary decomposition of coarse-grained strings, reducing integration complexity and improving the processing efficiency and accuracy of multi-intent question-and-answer requests.

[0075] After filling in the slot parameters in the slot pattern according to the question-and-answer request, since users' colloquial expressions often omit known vehicle information or operational prerequisites, if the electronic device asks the user every time a missing parameter is encountered, it will cause a serious interaction burden. In order to reduce repetitive input and improve the success rate of task execution, the slot parameter type further includes mandatory slots, that is, parameters that are indispensable when performing a specific intent, such as the fault code list slot in the intent of querying the meaning of fault codes. When a mandatory slot is missing in the current question-and-answer request, the electronic device will attempt to complete it from the diagnostic scenario context information and historical session information. Specifically, after S132 and before S151, the method also includes steps S133~S135: S133, identify the required slots with missing parameters in multiple pending intents as slots to be filled.

[0076] After filling in the slot parameters, the electronic device checks the slot pattern for each intent to be executed, comparing the filled parameters with the set of required slots for that intent. If it finds that some required slots have not had their parameter values ​​extracted from the current question-and-answer request, the electronic device marks these empty required slots as slots to be filled. For example, if a user enters "open engine data stream," the question-and-answer request may not contain vehicle information, but for the intent to execute the jump-open function, brand, model, year, and vehicle identification number (VIN) might be required slots. In this case, these vehicle information slots for which no parameters have been obtained are identified as slots to be filled, awaiting subsequent strategies to fill them.

[0077] S134, obtain diagnostic scenario context information and / or historical session information corresponding to the question-and-answer request, wherein the diagnostic scenario context information is collected from the target vehicle.

[0078] Diagnostic scenario context information refers to real-time status data such as the current vehicle and interface reported by client devices or diagnostic applications, such as automotive diagnostic tools and on-board diagnostic terminals. In automotive repair scenarios, the equipment is usually connected to the target vehicle and can obtain real-time status information such as the current brand, model, year, vehicle identification number, current interface, and list of read fault codes.

[0079] After identifying the slot to be filled, the electronic device queries the diagnostic scenario context information. In the example of opening the engine data stream, if the diagnostic device is currently connected to the vehicle, the electronic device can directly extract parameter values ​​such as "Brand A," "Model B," and "2022" from the reported scenario context and fill them into the corresponding slots to be filled. By utilizing the real-time operating environment on the device side, the electronic device can quickly and automatically complete key vehicle information, avoiding repeated queries to the user.

[0080] Meanwhile, if certain operational parameters cannot be obtained from the current device connection status, but the user has just mentioned and confirmed them in recent conversations, the electronic device will inherit these slot parameter values ​​from historical session information, provided that the number of sessions or time limits are not exceeded. For example, if a user asked for repair advice for a certain vehicle model in a previous conversation, and the current session requires opening the corresponding module, if the device is not connected to the vehicle but the relevant parameters for that vehicle model exist in the historical sessions, they can be directly inherited and used. Through cross-session slot inheritance, the rate of repeated queries for vehicle identification numbers or vehicle models within the same session can be further reduced.

[0081] S135, fill the slot to be filled based on the slot parameter values ​​contained in the diagnostic scenario context information and / or historical session information.

[0082] By fully utilizing the real-time scene status and multi-turn dialogue history of diagnostic equipment, missing required parameters can be automatically filled in to the greatest extent possible, thereby reducing the burden on maintenance personnel to frequently input parameters in noisy workshop environments where both hands are occupied.

[0083] Furthermore, when a user's question-and-answer request contains multiple intents, these intents often share certain basic vehicle information parameters, such as brand, model, year, and vehicle identification number (VIN). Therefore, after S131 and before S132, the method further includes steps S131a to S131b: S131a: Compare the slot pattern of the current intent to be executed with the already determined slot patterns.

[0084] The slot pattern of the current intent to be executed is compared with the slot parameters required for each item in the determined slot pattern. If the fields of a certain slot parameter are consistent, the slot parameter to be filled in the slot pattern of the current intent to be executed can be reused from the determined slot parameters in the determined slot pattern to avoid the repeated extraction of this slot parameter.

[0085] S131b: If there is a slot parameter in the determined slot pattern that is consistent with the slot parameter of the current intent to be executed, then the slot parameter of the current intent to be executed is filled based on the field of the slot parameter that is consistent with the slot parameter of the current intent to be executed.

[0086] Accordingly, S132 includes sub-step S132a: if there is no slot parameter in the determined slot pattern that matches the slot parameter of the current intent to be executed, then fill the slot parameter in the slot pattern according to the question and answer request.

[0087] In real-world automotive diagnostic scenarios, when a user inputs "Check the fault tree for P0171 and then open the engine data stream," both intents require information such as the vehicle's brand, model, and year. If the electronic device were to repeatedly extract parameters from each intent independently when filling in slot parameters based on the question-and-answer request, it would waste computational resources and increase processing latency. Therefore, in a single parsing iteration, once the electronic device extracts a slot parameter from the question-and-answer request or context, it reuses it across multiple intents sharing that slot. The electronic device only needs to identify and extract the same parameter once to synchronously fill it into the slot patterns of all related intents, thereby improving the efficiency and data consistency of multi-intent parsing.

[0088] Furthermore, there are cases where it is impossible to complete the required slots based on diagnostic scenario context information and historical session information. Therefore, in an optional approach, after S135 and before S151, the method further includes S138a~S138f: S138a, if the slot parameter values ​​contained in the diagnostic scenario context information and / or historical session information cannot complete the slot to be completed, then generate completion prompt information corresponding to the slot to be completed.

[0089] If, after querying both diagnostic scenario context information and historical session information, the electronic device still cannot obtain the parameter values ​​required to complete the slot, it indicates that the current information is insufficient to support the safe execution of the intent. In this case, the electronic device will generate corresponding completion prompts based on the semantics of the missing slot, such as: "Which vehicle model's fault tree are you looking for?" or "Please provide the specific fault code." This completion prompt will be sent to the upstream preprocessing service or directly returned to the user client to trigger a clarification process.

[0090] Furthermore, if all slots corresponding to multiple intents are complete slots, then the subsequent step S151 can be executed. To enable the downstream task planning service to accurately parse and consume this information, the electronic device assembles the above processing results into a structured semantic understanding result list for output. Each result in this list contains at least the core fields such as domain, intent, confidence level, slot set, execution order, and sequence type. The domain field indicates the major business category to which the intent belongs, such as fault diagnosis or vehicle function; the intent field records the specific operational purpose; the confidence level field provides a confidence score for the intent; the slot set field contains all filled or inherited fine-grained parameters and their sources in key-value pairs; and the execution order and sequence type fields reflect the execution position and parallel relationship of the intent in multi-step operations. Through this standardized, structured list output, the electronic device provides machine-readable complete constraints for downstream task orchestration, allowing the task planning service to generate an accurate execution plan directly based on this list without needing to perform secondary guessing of natural language.

[0091] S138b marks the state of an intent to be executed that has missing required slot parameters as incomplete.

[0092] When the aforementioned diagnostic context information and historical session information fail to complete the missing slots for a given intent, the electronic device does not discard the intent directly. Instead, it marks the execution status of that specific intent as incomplete. This status marking allows the electronic device to distinguish which intents are ready and which require user-provided information in subsequent processing. For example, in a question-and-answer request to check the fault tree for P0171 and then open the engine data stream, if there is no vehicle information in either the history or the scenario, the intent to check the fault tree is marked as incomplete, while opening the engine data stream, which already contains acquired parameters, remains in a normal state.

[0093] S138c outputs the completion prompt information.

[0094] The electronic device generates corresponding natural language prompts based on the semantics of the missing slots to be filled, and sends them to the client device for display or voice broadcast. For example, for a missing vehicle identification number (VIN) slot or vehicle model slot, it can generate a prompt to complete the fault tree for the vehicle model you are looking for. This output process can be presented to maintenance personnel through screen pop-ups, speech bubbles, or speech synthesis, guiding them to provide the necessary information during their current work breaks without having to re-enter the entire question-and-answer request from scratch.

[0095] S138d, obtain the first feedback information corresponding to the completion prompt information.

[0096] The first feedback information refers to the user's response to the completion prompt, such as a brief voice command or text input. Since the preceding prompt is generated for a specific slot, the user's feedback at this moment is usually highly focused on the missing parameter. For example, after hearing the prompt, the user might directly answer "Model B 2022". The electronic device receives this segment of natural language text or speech-to-text through the client device, preparing it as the first feedback information for parsing.

[0097] S138e, based on the first feedback information, complete the slots to be completed for the incomplete state of the intended execution.

[0098] After receiving the first feedback information, the electronic device matches it with the slot pattern of the intent previously marked as incomplete. Since the specific missing slot semantics are known at this point, the electronic device can use rule matching or a lightweight semantic extraction model to directly extract the target parameter value from the first feedback information and fill it into the slot to be filled.

[0099] In the example above, the electronic device extracts the vehicle model as "Model B" and the model year as "2022" from "Model B 2022". If the user provides the complete code, the corresponding vehicle identification number is extracted. With these parameters filled in, the state of the intent, which was originally incomplete, will change to executable.

[0100] S138f processes the question-and-answer request based on the completed slot parameters, execution order, and multiple pending execution intents.

[0101] Once the incomplete intent is completed with the necessary parameters, the electronic device re-aggregates it with the previously completed intent, combining this with the labeled execution order to form a complete list of structured semantic understanding results. This list is then sent to the downstream task orchestration and planning service to execute step S151. The downstream service schedules the corresponding diagnostic agents sequentially or in parallel according to their sequence number and order type.

[0102] By providing prompts and feedback, the robustness and task completion rate of electronic devices are improved when faced with incomplete, conversational instructions.

[0103] Furthermore, in actual repair and diagnostic operations, clearly identifying the source of a parameter value is crucial for subsequent auditing, troubleshooting, and responsibility allocation. Therefore, when electronic devices fill in the slots to be completed based on diagnostic scenario context information or historical session information, they also simultaneously record the source of that parameter value. For example, when the parameter "Brand A" in the brand slot is obtained from the current vehicle status reported by the diagnostic device, the electronic device will attach a source tag to the slot data, marking it as "from the current scenario"; if it is extracted from historical conversations, it will be marked as "from session history." By explicitly recording the slot source in structured data, downstream task planning services or maintenance personnel can clearly trace the basis of each execution parameter, avoiding cross-vehicle diagnostic errors caused by misusing historical vehicle contexts, and improving the security and traceability of electronic devices.

[0104] After obtaining multiple intents and their confidence levels, besides filtering low-scoring intents and retaining high-scoring intents using a confidence threshold, there exists an extremely ambiguous situation where the confidence levels of all identified intents fail to meet the executable standard. In this case, forcibly selecting the highest-scoring intent for execution can easily lead to erroneous operations or invalid responses. Therefore, in an optional approach, after S120, the method further includes steps S161-S164: S161, if the confidence levels of multiple intentions are all less than the preset confidence threshold, then clarification information is generated.

[0105] In automotive diagnostics, users may mispronounce questions due to accents, incorrect terminology, or fragmented sentences, causing the electronic device to output candidate intent scores below a preset reliability threshold after recognizing the request. This indicates that the current request does not contain any sufficiently clear operational instructions. In this case, the electronic device determines that the request cannot be directly executed and therefore does not proceed to the subsequent fine-grained slot extraction and sequential labeling process. To resolve this ambiguity, the electronic device generates a clarification message based on the characteristics of the current request or a preset script template, such as "Unable to understand your request; do you want to read the fault code or view the data stream?", thus guiding the user to provide clearer information.

[0106] S162 outputs the clarification information.

[0107] After generating clarification information, the electronic equipment will display it as a text bubble on the client device's screen or broadcast it to the maintenance personnel via speech synthesis technology. In the noisy environment of the workshop, this clear voice or visual cues can quickly attract the technician's attention, informing them that the previous instruction was not successfully parsed and further explanation is needed.

[0108] S163, Obtain the second feedback information corresponding to the clarification information.

[0109] The second feedback message refers to the further response from the repair personnel after receiving the clarification message. The user may re-enter the command using more standard terminology or clearer wording. For example, after hearing the clarification message, the user might voice-input "Reread the current vehicle's fault codes." The client device captures this voice message, transcribes it into text, and transmits it to the electronic device. The electronic device then receives this text as the second feedback message, thus obtaining data with more explicit semantics than the original question-and-answer request.

[0110] S164, Update the question-and-answer request based on the second feedback information, and process the updated question-and-answer request.

[0111] After receiving the second feedback information, the electronic device does not process it in isolation, but rather merges it with or directly replaces the original question-and-answer request to form an updated question-and-answer request. Subsequently, the electronic device re-inputs the updated question-and-answer request into the multi-intent recognition process and executes steps S120 to S150 again.

[0112] Through S161~S164, the electronic device can promptly resolve parsing failures caused by colloquialisms or unclear expressions, ensuring the robustness of multi-intent question-answering request processing and improving the response quality for responding to multi-intent question-answering requests.

[0113] This application embodiment identifies user-input question-and-answer requests to obtain multiple intents and their confidence levels. Intents with confidence levels greater than or equal to a preset confidence threshold are identified as intents to be executed, thus avoiding the loss of secondary intents. By marking the execution order of the multiple intents to be executed and processing the question-and-answer requests according to the execution order and the multiple intents to be executed, only high-confidence intents to be executed are processed, which avoids ambiguous intents interfering with the execution of downstream tasks. The execution order of the identified multiple intents to be executed is explicitly marked, so that the downstream task planning and processing can be scheduled sequentially or in parallel according to the execution order, avoiding misjudgment of execution order and logical confusion caused by the lack of semantic order between intents, thereby improving the response quality to multi-intent question-and-answer requests.

[0114] Figure 3A schematic diagram of the structure of a multi-intent question-answering request processing apparatus provided in an embodiment of this application is shown. Figure 3 As shown, the multi-intent question-and-answer request processing device 200 includes: an acquisition module 210, an identification module 220, a determination module 230, an annotation module 240, and a processing module 250.

[0115] The acquisition module 210 is used to acquire the user's input question and answer request.

[0116] The identification module 220 is used to identify the question-and-answer request and obtain multiple intents and the confidence level of each intent, wherein the confidence level is used to characterize the credibility of the corresponding intent.

[0117] The determination module 230 is used to determine the intents with a confidence level greater than or equal to a preset confidence threshold from among multiple intents as intents to be executed, thereby obtaining multiple intents to be executed.

[0118] The annotation module 240 is used to annotate the execution order of multiple intents to be executed.

[0119] The processing module 250 is used to process question and answer requests according to the execution order and multiple pending intentions.

[0120] The multi-intent question-and-answer request processing apparatus 200 provided in this application embodiment further includes multiple modules for executing the various steps of the above-described multi-intent question-and-answer request processing method, which will not be described in detail here.

[0121] Figure 4 The diagram shows a schematic of the structure of an electronic device provided in an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the electronic device 300.

[0122] like Figure 4 As shown, the electronic device 300 may include a processor 302 and a memory 304.

[0123] The memory 304 is used to store the computer program 306. The memory 304 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device. The computer program 306 may include computer-executable instructions.

[0124] The processor 302 is used to execute the computer program 306 to implement the above-described embodiment of the multi-intent question-answering request processing method.

[0125] Processor 302 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Electronic device 300 may include one or more processors of the same type, such as one or more CPUs; or it may include processors of different types, such as one or more CPUs and one or more ASICs.

[0126] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described embodiment of the multi-intent question-answering request processing method.

[0127] This application provides a computer program that can be executed by a processor to implement the above-described method for processing multi-intent question-answering requests.

[0128] This application provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described embodiment of the multi-intent question-and-answer request processing method.

[0129] In the several embodiments provided in this application, any function, if implemented as a software functional module / unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, part or all of the technical solutions of this application 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 other electronic device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0130] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0131] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In claims enumerating several means, several units or modules of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

[0132] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for processing multi-intent question-answering requests, characterized in that, The method includes: Obtain the user's input for the question-and-answer request; The question-and-answer request is identified to obtain multiple intents and the confidence level of each intent, wherein the confidence level is used to characterize the credibility of the corresponding intent; Among the multiple intents, those with a confidence level greater than or equal to a preset confidence threshold are identified as intents to be executed, thus obtaining multiple intents to be executed; Mark the execution order of the multiple intents to be executed; The question-and-answer request is processed according to the execution order and the multiple pending intents.

2. The method according to claim 1, characterized in that, The step of marking the execution order of the multiple intents to be executed includes: Based on the natural order of the multiple execution intentions in the question-and-answer request, analyze the semantic features and business dependencies of the multiple execution intentions in the question-and-answer request; If analysis reveals that two of the multiple intents to be executed have a semantic sequence indication, or that the latter intent depends on the execution result of the former intent in terms of business logic, then the two intents are marked as to be executed sequentially. If the analysis reveals that the two intentions have semantic features indicating simultaneous execution, or that there is no sequential dependency in terms of business logic, then the two intentions are marked as being executed in parallel. The execution order of the multiple intents to be executed is marked according to the execution order of the two intents.

3. The method according to claim 1, characterized in that, The process of identifying the question-and-answer request yields multiple intents and the confidence level of each intent, including: The intent boundary of the question-and-answer request is detected based on a preset feature set; If a feature from the preset feature set is detected in the question-and-answer request, the question-and-answer request is divided into multiple sub-segments based on the detected feature; Intent recognition is performed on each segment obtained from the segmentation to obtain the intent corresponding to each segment and the confidence level of the intent.

4. The method according to claim 1, characterized in that, Before processing the question-and-answer request according to the execution order and the plurality of pending intents, the method further includes: Determine the slot pattern for each of the stated intentions to be executed; Fill the slot parameters in the slot pattern according to the question and answer request; The process of handling the question-and-answer request according to the execution order and the plurality of pending intents includes: The question-and-answer request is processed according to the slot parameters and the execution order.

5. The method according to claim 4, characterized in that, The slot parameters in the slot mode include at least one of the following: fault code list, vehicle information sub-slot, and operation information sub-slot; The vehicle information sub-item slots include at least one of the following: brand slot, model slot, year slot, and vehicle identification number slot; The operation information sub-item slots include at least one of the action type slot and the target function module identifier slot; The parameters of the action type slot include at least one of reading code, clearing code, opening, or jumping, and the parameters of the target function module identifier slot include at least one of the fault code reading module and the data stream module.

6. The method according to claim 4, characterized in that, The slot parameter type includes required slots; after determining the slot pattern of each of the intents to be executed, and before filling the slot parameters in the slot pattern according to the question-and-answer request, the method further includes: Compare the slot pattern of the current intent to be executed with the already determined slot patterns; If there is a slot parameter in the determined slot pattern that is consistent with the slot parameter of the current intent to be executed, then the slot parameter of the current intent to be executed will be filled based on the field of the slot parameter that is consistent with the slot parameter of the current intent to be executed. The step of filling the slot parameters in the slot pattern according to the question and answer request includes: If there is no slot parameter in the determined slot pattern that matches the slot parameter of the current intent to be executed, then fill the slot parameter in the slot pattern according to the question and answer request; After filling the slot parameters in the slot pattern according to the question-and-answer request, and before processing the question-and-answer request according to the slot parameters and the execution order, the method further includes: The required slots with missing parameters in the multiple intents to be executed are identified as slots to be filled. Obtain diagnostic scenario context information and / or historical session information corresponding to the question-and-answer request, wherein the diagnostic scenario context information is collected from the target vehicle; The slots to be filled are filled based on the diagnostic scenario context information and / or the slot parameter values ​​contained in the historical session information.

7. The method according to claim 6, characterized in that, After filling the slot to be completed based on the diagnostic scenario context information and / or the slot parameter values ​​contained in the historical session information, and before processing the question-and-answer request based on the slot parameters and the execution order, the method further includes: If the slot parameter value contained in the diagnostic scenario context information and / or the historical session information cannot complete the slot to be completed, then a completion prompt message corresponding to the slot to be completed is generated; Mark the state of the pending intent that has missing required slot parameters as incomplete; Output the completion prompt information; Obtain the first feedback information corresponding to the completion prompt information; Based on the first feedback information, the missing slots for the incomplete execution intent are filled in.

8. The method according to claim 4, characterized in that, The step of processing the question-and-answer request according to the slot parameters and the execution order includes: The slot parameters of the intent to be executed are set into a slot set in key-value format; The question-and-answer request is processed according to the set of slots for each intent to be executed and the execution order.

9. The method according to claim 1, characterized in that, After identifying the question-and-answer request and obtaining multiple intents and the confidence level of each intent, the method further includes: If the confidence levels of all the aforementioned intentions are less than the preset confidence threshold, then clarification information is generated. Output the clarification information; Obtain the second feedback information corresponding to the clarification information; The question-and-answer request is updated based on the second feedback information in order to process the updated question-and-answer request.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the multi-intent question-answering request processing method according to any one of claims 1 to 9.

Images