Vehicle fault processing method based on AI voice and related device
By using an AI-based voice-based vehicle fault handling method, which leverages voice recognition and AI diagnostic models to achieve intelligent analysis and personalized services, the problem of insufficient manual operation and in-depth analysis by car owners in existing technologies is solved, thus improving the user's fault handling experience.
Patent Information
- Application Number
- CN202511278768.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-09
- Publication Date
- 2025-12-23
AI Technical Summary
Existing automotive diagnostic technologies require manual operation by car owners, which is distracting and makes it difficult to provide intelligent analysis and personalized services. In-vehicle voice interaction systems also lack in-depth analytical capabilities.
By using an AI-based voice-based vehicle fault handling method, voice recognition and AI diagnostic models are employed to obtain user intent information and vehicle information, perform intelligent analysis, and generate maintenance prompts to guide users in performing maintenance operations.
The diagnostic equipment can be operated without manual intervention while the vehicle is in motion, enabling in-depth analysis and personalized services, thus enhancing the user experience when dealing with faults.
Smart Images

Figure CN121191501A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of intelligent vehicle technology, and in particular to a vehicle fault handling method and related device based on AI voice. Background Technology
[0002] As car designs become increasingly complex, the malfunctions they cause also become more complex. Currently, most automotive diagnostic technologies require manual operation by the driver, which is extremely inconvenient while driving, potentially distracting the driver and posing safety hazards. Furthermore, some diagnostic devices only provide simple fault codes and text descriptions, making it difficult for non-professionals to perform appropriate actions based on the diagnostic results. In addition, the application of voice interaction in diagnostic devices is relatively limited; in-vehicle voice interaction systems can only complete the actions contained in the voice commands, lacking in-depth analysis, intelligent analysis, and the provision of personalized services.
[0003] Therefore, improving the owner's experience when dealing with vehicle malfunctions is an urgent issue that needs to be addressed. Summary of the Invention
[0004] This application provides a vehicle fault handling method and related device based on AI voice. When a vehicle malfunctions and is being diagnosed, it provides intelligent analysis and personalized services, thereby improving the user experience when handling the fault.
[0005] In a first aspect, embodiments of this application provide a vehicle fault handling method based on AI voice, applied to diagnostic equipment, the method comprising:
[0006] Obtain the target user's voice recordings and the target vehicle's information;
[0007] The user's voice is input into a preset speech recognition model to obtain user intent information; the user intent information is used to characterize the diagnostic direction of the target user for the target vehicle;
[0008] The vehicle information is input into a preset AI diagnostic model to obtain a first diagnostic result;
[0009] The target diagnostic result of the target vehicle is determined based on the first diagnostic result and the user intent information;
[0010] Based on the preset maintenance guidance model and the target diagnostic results, the target maintenance prompt information corresponding to the target vehicle is determined; the target maintenance prompt information is used to guide the target user to perform maintenance operations on the target vehicle via voice.
[0011] Secondly, embodiments of this application provide an AI-based voice-based vehicle fault handling device, applied to diagnostic equipment, the device comprising:
[0012] The acquisition module is used to acquire the user's voice and the vehicle information of the target vehicle;
[0013] The calculation module is used to input the user's voice into a preset speech recognition model to obtain user intent information; the user intent information is used to characterize the diagnostic direction of the target user for the target vehicle; and input the vehicle information into a preset AI diagnostic model to obtain a first diagnostic result.
[0014] The determination module is used to determine the target diagnostic result of the target vehicle based on the first diagnostic result and the user intent information;
[0015] The control module is used to determine the target maintenance prompt information corresponding to the target vehicle based on the preset maintenance guidance model and the target diagnostic results; the target maintenance prompt information is used to guide the target user to perform maintenance operations on the target vehicle via voice.
[0016] Thirdly, embodiments of this application provide a diagnostic device, including a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing steps in any method of the first aspect of this application.
[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in any method of the first aspect of this application.
[0018] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in any method of the first aspect of this application. The computer program product may be a software installation package.
[0019] By implementing the embodiments of this application, the following beneficial effects can be achieved:
[0020] This application describes an AI-based voice-based vehicle fault handling method and related apparatus, applied to diagnostic equipment. The method acquires the user's voice and the vehicle information of the target vehicle. The user's voice is input into a preset voice recognition model to obtain user intent information, which represents the user's diagnostic direction for the target vehicle. The vehicle information is input into a preset AI diagnostic model to obtain a first diagnostic result. Based on the first diagnostic result and the user intent information, a target diagnostic result for the target vehicle is determined. Based on a preset maintenance guidance model and the target diagnostic result, corresponding target maintenance prompt information for the target vehicle is determined. This target maintenance prompt information is used to guide the user to perform maintenance operations on the target vehicle via voice. Thus, during vehicle operation, the diagnostic equipment receives the user's voice commands, performs AI analysis and diagnosis based on these commands, and uses AI to infer the user's intent from the voice commands for in-depth analysis, obtaining an AI diagnostic result. This eliminates the need for manual operation of the diagnostic equipment by the user, thereby improving the user experience when handling faults. Attached Figure Description
[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0022] Figure 1 This is a system architecture diagram of a vehicle fault handling method based on AI voice provided in an embodiment of this application;
[0023] Figure 2 This is a schematic diagram of the structure of a diagnostic device provided in an embodiment of this application;
[0024] Figure 3 This is a schematic flowchart of a vehicle fault handling method based on AI voice provided in an embodiment of this application;
[0025] Figure 4 This is a schematic diagram of a dialogue scenario based on an AI speech recognition model provided in an embodiment of this application;
[0026] Figure 5 This is an architecture diagram of a speech recognition model provided in an embodiment of this application;
[0027] Figure 6 This is a schematic diagram of the interface interaction for a vehicle fault handling scenario based on AI voice, provided in an embodiment of this application.
[0028] Figure 7This is a flowchart illustrating another vehicle fault handling method based on AI voice provided in an embodiment of this application;
[0029] Figure 8 This is a functional module block diagram of a vehicle fault handling device based on AI voice provided in an embodiment of this application. Detailed Implementation
[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0031] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.
[0032] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, "multiple" refers to two or more.
[0033] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.
[0034] In this application, the term "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. This application does not impose any limitations on this.
[0035] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.
[0036] The following is an explanation of the relevant terms used in this application:
[0037] Intent recognition: Intent recognition is an important component of conversational voice AI. It refers to recognizing the intent or intent category expressed by the user in the conversation. Through intent recognition, AI can understand the user's intent in the conversation and take corresponding actions or provide corresponding responses based on their intent.
[0038] Slot: In speech recognition, a slot refers to a specific information unit in a user query or command that requires special attention. It is usually directly related to the user's intent. In addition, it identifies and extracts key information from the data and responds to the needs accurately based on the key information.
[0039] Most current automotive diagnostic technologies require manual operation of the diagnostic equipment by the driver, which is extremely inconvenient while driving, may distract the driver, and poses safety hazards. Furthermore, some diagnostic equipment only provides simple fault codes and text descriptions, making it difficult for non-professionals to perform corresponding operations based on the diagnostic results. In addition, the application of voice interaction in diagnostic equipment is relatively limited; in-vehicle voice interaction systems can only complete the operations contained in the voice commands, lacking in-depth analysis, intelligent analysis, and the provision of personalized services.
[0040] To address the aforementioned issues, this application provides an AI-based voice-based vehicle fault handling method and related apparatus, applied to diagnostic equipment. By acquiring the user's voice and the vehicle information of the target vehicle, the user's voice is input into a preset voice recognition model to obtain user intent information. This user intent information represents the user's diagnostic direction for the target vehicle. The vehicle information is then input into a preset AI diagnostic model to obtain a first diagnostic result. Based on the first diagnostic result and the user intent information, a target diagnostic result for the target vehicle is determined. Finally, based on a preset maintenance guidance model and the target diagnostic result, corresponding target maintenance prompt information for the target vehicle is determined. This target maintenance prompt information is used to voice-guide the user to perform maintenance operations on the target vehicle. Thus, during vehicle operation, the diagnostic equipment receives the user's voice commands, performs AI analysis and diagnosis based on these commands, and uses AI to infer the user's intent from the voice commands for in-depth analysis, obtaining an AI diagnostic result. This eliminates the need for manual operation of the diagnostic equipment by the user, thereby improving the user's experience when handling faults.
[0041] The following is combined Figure 1 The system architecture of a vehicle fault handling method based on AI voice in the embodiments of this application is described. Figure 1 This is a system architecture diagram of a vehicle fault handling method based on AI voice provided in an embodiment of this application. The vehicle fault handling system 100 based on AI voice includes a user 110, a voice recognition model 120, an AI diagnostic model 130, and a vehicle 140.
[0042] In this system, user 110, acting as the initiator of a vehicle malfunction request, inputs a voice request related to the vehicle malfunction into the AI-based voice vehicle malfunction handling system 100 and receives diagnostic results and voice repair guidance from the system. User 110 can be either a user or the owner of the vehicle. When the vehicle 140 experiences abnormal conditions (such as unusual noises or malfunction lights illuminating), user 110 can input a description of the malfunction and repair requests into the AI-based voice vehicle malfunction handling system 100 via natural language voice interaction, triggering the vehicle malfunction handling process. Simultaneously, after the AI-based voice vehicle malfunction handling system 100 completes the diagnosis, user 110 receives voice prompts to guide vehicle repair operations, allowing them to perform self-repair or seek professional repair advice based on this information.
[0043] In one possible embodiment, when user 110 inputs voice information, the voice content is preprocessed and converted into a text sequence. This text sequence contains various types of information, such as a description of the fault scenario, the duration of the fault, and the user's desired handling method. This information constitutes the initial input conditions for system diagnosis, providing guidance for the subsequent collaborative work of the voice recognition model 120 and the AI diagnostic model 130. User 110 can flexibly adjust the level of detail in the voice input based on their understanding of the vehicle. The AI voice-based vehicle fault handling system 100 has the ability to adaptively parse information of different granularities. In cases of missing or ambiguous information, the system can guide the user to supplement key content through preset interactive utterances, ensuring the completeness and accuracy of the diagnostic requirements.
[0044] Among them, the speech recognition model 120 is used to recognize and parse the speech information input by the user 110, and convert it into user intent and diagnostic needs text that the AI speech-based vehicle fault handling system 100 can understand, providing input basis for the subsequent AI diagnostic model 130. This model is built based on deep learning technology and adopts an end-to-end speech recognition framework, such as a Transformer-based speech recognition architecture. Through training on a large-scale speech dataset, it learns the mapping relationship between speech signals and text semantics.
[0045] In one possible embodiment, the speech recognition model 120's workflow includes two stages: front-end signal processing and back-end recognition and decoding. In the front-end signal processing stage, the acquired user speech signal undergoes pre-emphasis, framing, and windowing operations to enhance the robustness of speech features and suppress environmental noise interference. In the back-end recognition and decoding stage, a trained deep neural network is used to convert the processed speech feature sequence into a text sequence. An attention mechanism is used to focus on key speech segments, accurately identifying user intents such as "fault type inquiry" and "repair procedure requirements." Simultaneously, the speech recognition model 120 possesses domain-adaptive capabilities. For vehicle fault diagnosis-specific vocabulary (such as specific fault code descriptions and vehicle component names), a domain dictionary is constructed and customized training is performed to improve the recognition accuracy of such vocabulary, ensuring that the output user intent and diagnostic requirement text are accurate and relevant to the vehicle fault handling scenario.
[0046] The AI diagnostic model 130 receives user intent and diagnostic requests output by the speech recognition model 120, combines them with the operational and attribute information provided by the vehicle 140, performs vehicle fault diagnosis, and generates target repair prompts to guide repair operations. The AI diagnostic model 130 integrates a vehicle fault knowledge graph with a deep diagnostic algorithm. The knowledge graph covers knowledge nodes and relationships such as vehicle component structure, fault mode associations, and repair process specifications. The deep diagnostic algorithm uses technologies such as convolutional neural networks and expert system reasoning to achieve accurate fault location and repair solution derivation.
[0047] In a specific process, the AI diagnostic model 130 first performs semantic understanding of the input user intent and diagnostic needs, mapping them to the fault demand node in the knowledge graph. Then, it obtains the vehicle 140's operating information (such as real-time vehicle speed, engine speed, and values of various sensors) and attribute information (such as vehicle model, production batch, and configuration parameters), converting them into feature vectors. These vectors are then matched and associated with the vehicle attribute nodes in the knowledge graph. Through the collaborative work of path reasoning in the knowledge graph and numerical analysis in the deep diagnostic algorithm, the cause of the fault is uncovered. Subsequently, based on preset maintenance guidance rules and maintenance process knowledge in the knowledge graph, target maintenance prompts are generated, including explanations of the fault cause, maintenance operation steps (such as "Step 1: Turn off the vehicle power and open the engine hood; Step 2: Remove the spark plugs to check electrode wear"), tool usage specifications (such as "A socket wrench is required"), and safety precautions (such as "Discharge static electricity from the vehicle before operation"). These prompts are output in structured text form, providing a foundation for subsequent voice guidance.
[0048] Vehicle 140 serves as the object of fault diagnosis, continuously outputting vehicle operation and attribute information to the AI voice-based vehicle fault handling system 100, providing real-time and accurate diagnostic basis for the AI diagnostic model 130. The on-board diagnostic system (OBD) and various sensors (such as engine speed sensor, vehicle speed sensor, oil temperature sensor, pressure sensor, etc.) equipped in vehicle 140 collect dynamic data during vehicle operation in real time, including but not limited to vehicle identification number, real-time fault codes, real-time engine operating parameters (such as intake air volume, fuel injection volume, etc.), and vehicle driving status parameters (such as driving speed, acceleration, mileage, etc.). Simultaneously, the attribute information of vehicle 140 (such as vehicle brand, model, production year, configuration version, factory settings parameters) is stored in the on-board control system and can be uploaded to the system as needed via the on-board communication module (such as CAN bus).
[0049] As can be seen, the system architecture of the above-mentioned AI voice-based vehicle fault handling method can realize intelligent voice interaction throughout the entire process of vehicle fault handling. This not only improves the accuracy of fault diagnosis and the quality of repair guidance, but also provides a systematic solution for efficient handling of vehicle faults and user self-repair support, while enhancing the user experience.
[0050] The following is combined Figure 2 The diagnostic device in the embodiments of this application will be described. Figure 2 This is a schematic diagram of the structure of a diagnostic device provided in an embodiment of this application, such as... Figure 2As shown, the diagnostic device 200 includes one or more processors 210, a memory 220, a communication interface 230, and one or more programs 221. The processor 210 is communicatively connected to the memory 220 and the communication interface 230 via an internal communication bus.
[0051] The processor 210 can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, cells, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication unit can be a communication interface, a transceiver, a transceiver circuit, etc., and the storage unit can be a memory.
[0052] The memory 220 can be volatile memory or non-volatile memory, or it can include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).
[0053] The one or more programs 221 are stored in the memory 220 and configured to be executed by the processor 210. The one or more programs 221 include instructions for performing any step in the embodiments of the AI voice-based vehicle fault handling method described below.
[0054] It is understood that the diagnostic device 200 may include more or fewer structural elements than those shown in the block diagram above, such as a power module, physical buttons, a Wi-Fi module, a speaker, a Bluetooth module, sensors, a display module, etc., without limitation. It is understood that the diagnostic device may be equipped with... Figure 1 The system architecture of a vehicle fault handling method based on AI voice is described above.
[0055] After understanding the software and hardware architecture of this application, the following will be combined with... Figure 3 This application describes a vehicle fault handling method based on AI voice in an embodiment of the present application. Figure 3 This is a flowchart illustrating a vehicle fault handling method based on AI voice, provided in an embodiment of this application. The method is applied to diagnostic equipment and specifically includes the following steps:
[0056] Step S310: Obtain the user's voice and the vehicle information of the target vehicle.
[0057] User voice refers to the raw audio data provided by the target user through voice input. It typically expresses the user's description of vehicle malfunctions, requested service types, current problem scenarios, or desired auxiliary information in the form of voice commands. This user voice data can be acquired through the in-vehicle voice interaction system. The voice input scenario can be while the vehicle is in motion, parked, or a remote request initiated by the user independently of the vehicle; there are no limitations on this. Vehicle information refers to the collection of current or historical operating parameters, technical specifications, and unique identification information of the target vehicle. This includes static attribute information such as vehicle brand, model, Vehicle Identification Number (VIN), vehicle manufacturing year, engine type, battery model, and on-board controller version number; as well as dynamic operating information such as engine speed, battery voltage, fault codes (DTC), vehicle location information, speed information, and energy consumption data; there are no limitations on this. Vehicle information can be obtained through communication between diagnostic equipment and the in-vehicle CAN bus, or it can be synchronized in real time using an OBD diagnostic module or a remote data acquisition platform.
[0058] Specifically, the system first acquires user voice data through a voice acquisition module, which can be embedded in the in-vehicle voice recognition system or a smart terminal app. When a user initiates an interaction, such as the driver saying, "I feel the car is accelerating slowly and lacks power," the voice acquisition module automatically converts the data into an audio stream and sends it to the voice recognition model. Furthermore, after receiving the voice stream, preprocessing operations are performed, such as voice segmentation, noise reduction, and waveform normalization, to enhance the accuracy of voice recognition. Simultaneously, a vehicle information channel is established, mapping the vehicle identifier to the backend data platform using the vehicle's unique identification number (VIN), accessing the corresponding device information table, and collecting vehicle operating status information based on a real-time data interface. Through diagnostic interfaces such as the UDS (Unified Diagnostic Services) protocol or the ISO 14229 protocol, stored fault codes (DTCs) can be read, and sensor information from key subsystems such as the engine, transmission, and battery management system can be collected.
[0059] It's worth noting that multimodal intelligent voice wake-up technology can be employed. Besides traditional voice keyword wake-up, it can also incorporate biometric recognition technologies such as facial recognition and fingerprint recognition. For example, when a user sits in the driver's seat, after facial recognition confirms their identity, the voice interaction function is automatically activated. Simultaneously, a personalized voice prompt greets the user based on their individual habits, such as, "Welcome, [owner's name], what car problem do you need my help with?" To ensure the smoothness of user voice interaction and multi-turn semantic understanding, voice information is not only processed as single-turn input but also supports dynamic caching and tracking of the dialogue context. For example, a user might sequentially utter three voice messages: "Can't start today," "Added gas yesterday," and "Maybe it's a battery problem." The system can automatically cluster these consecutive voice messages into topics and chain instructions to construct a complete user intent chain, thereby avoiding diagnostic bias caused by incomplete one-time expressions. Furthermore, user voice may contain colloquial expressions, dialect interference, or ambiguous expressions. To improve the robustness of voice information and the accuracy of intent recognition, a multimodal recognition model and a contextual semantic decoding module are introduced to deeply process the original voice and extract more stable semantic features.
[0060] Step S320: Input the user's voice into a preset speech recognition model to obtain user intent information; the user intent information is used to characterize the diagnostic direction of the target user for the target vehicle.
[0061] The speech recognition model is a deep neural network model trained on a large-scale speech corpus and vehicle fault expression samples. It typically employs an end-to-end speech recognition structure, such as acoustic modeling based on CTC (Connectionist Temporal Classification) combined with a language modeling module using a Transformer or RNN structure. This model converts the target user's natural speech signal into standardized text information, i.e., "first speech information," so that subsequent processing modules can extract semantics and instructions. The speech recognition model possesses strong robustness and multi-scenario adaptability, supporting recognition under various Chinese accents, speech rates, and noise interference environments. It can also enhance recognition accuracy through contextual reasoning for non-standard expressions and ambiguous statements.
[0062] User intent information refers to the set of target task instructions and contextual semantic information extracted through semantic analysis of the natural language content in the target user's speech. It reflects the vehicle fault that the target user is currently concerned about and the diagnostic direction they hope the system will perform. User intent information typically includes multiple elements such as intent type (e.g., "What should I do if the battery is dead?", "Help me determine if the brakes are abnormal"), fault keywords (e.g., "battery", "brakes", "cannot start"), main complaint (e.g., "engine stalled", "abnormal noise", "fault light on"), and vehicle-related scenario descriptions (e.g., "just drove 100 kilometers", "problem occurred after rain yesterday"), which are the key semantic entry points for the subsequent AI diagnostic model to select the inference path.
[0063] Specifically, upon receiving a user's voice, the audio is input into a pre-defined speech recognition model for processing. The speech recognition model first preprocesses the audio data, including signal-to-noise ratio enhancement, silence filtering, and audio frame normalization. It then maps the processed audio signal to a phoneme sequence, which is decoded by an acoustic and language model to output standardized text information corresponding to the speech. Next, this text information serves as input to the semantic analysis module, undergoing word segmentation, part-of-speech tagging, named entity recognition, and semantic dependency analysis to identify keywords and commands. The intent analysis model outputs multiple candidate user intent information and their confidence scores. Based on the scores, the intent information with the highest confidence is selected as the final user intent information, used by the subsequent AI diagnostic model to match fault categories and infer diagnostic results.
[0064] For easier understanding, please refer to Figure 4 , Figure 4This is a schematic diagram of a dialogue scenario based on an AI speech recognition model provided in an embodiment of this application. As can be seen, firstly, a deep neural network model is trained based on a large-scale speech corpus and vehicle fault expression samples, using an end-to-end structure to process the user's natural speech signal. Facing diverse scenarios, preprocessing such as signal-to-noise ratio enhancement and silence filtering optimizes audio quality. Then, phoneme sequences are mapped using an acoustic model, and standardized text is decoded using a language model to obtain the user's speech content. Next, operations such as word segmentation, part-of-speech tagging, named entity recognition, and semantic dependency analysis are used to mine the intent type, main complaint, and vehicle context in the text, constructing a user intent information set. Finally, the semantic representation and contextual information output by natural language understanding enable dynamic control of the dialogue logic. It maintains the dialogue state, determines the direction of dialogue flow based on user intent and system historical interaction records, and judges whether it is necessary to clarify user needs, supplement information, or directly trigger the diagnostic process, ensuring the continuity and goal orientation of the dialogue. For example, when the user's intent is identified as ambiguous, it automatically generates follow-up questions to guide the user to supplement key information and constructs response text, generating replies containing diagnostic suggestions, repair instructions, and information confirmation, ensuring semantic accuracy and clear expression. Finally, it converts the text generated from natural language into speech signals through text-to-speech (TTS) technology, combined with the voice style requirements of the vehicle fault scenario (such as clear, professional, and reassuring tone), to synthesize an adapted voice output, ensuring that the voice received by the user is clear and understandable and fits the interaction scenario, achieving a natural conversion from text to speech.
[0065] In one possible embodiment, inputting the user's voice into a preset speech recognition model to obtain user intent information specifically includes the following steps:
[0066] 321. Based on a preset semantic recognition model, the first speech information is parsed to obtain the first semantic information;
[0067] 322. Using a preset entity recognition model, identify from the first semantic information to obtain multiple keywords and multiple instructions;
[0068] 323. Input the multiple keywords and multiple instructions into a preset semantic analysis model to obtain multiple slots and multiple instruction tags;
[0069] 324. Input the multiple slots and the multiple instruction tags into a preset intent analysis model to obtain multiple first user intent information;
[0070] 325. Determine the similarity score between each of the plurality of first user intent information and each of the plurality of first semantic information to obtain a plurality of similarity scores;
[0071] 326. Determine the highest similarity score among the plurality of similarity scores, and set the first user intent information corresponding to the highest similarity score as the user intent information.
[0072] Semantic recognition models, specifically deep learning-based Natural Language Understanding (NLU) models, primarily perform syntactic structure analysis, syntactic dependency parsing, and contextual modeling on the text after speech recognition (i.e., the first speech information) to extract semantic components and sentence meaning information. These models can be Bidirectional Encoder Representation (BERT) or pre-trained language models such as ALBERT; no specific limitation is made here. For example, given a user input "The accelerator pedal isn't responding, is something wrong?", the core intent can be identified as "Requesting system diagnostics to speed things up." Entity recognition models are mainly used to identify key semantic entities in text, including faulty objects, operational behaviors, descriptive features, and state qualifiers. Recognition accuracy can be improved through Named Entity Recognition (NER) algorithms and joint modeling using label rule sets and context.
[0073] For easier understanding, please refer to Figure 5 , Figure 5This is an architecture diagram of a speech recognition model provided in an embodiment of this application. As can be seen, the speech recognition model 500 includes: a semantic recognition model 510, an entity recognition model 520, a semantic analysis model 530, and an intent analysis model 540. Specifically, the semantic recognition model 510 is used for the key task of deep semantic parsing of input speech text. It can be based on the BERT algorithm or an ALBERT algorithm architecture; no limitation is made here. Through learning from large-scale text corpora, it acquires rich language representation capabilities. The entity recognition model 520 is used to extract key semantic entities from the text processed by the semantic recognition model 510. These entities include fault objects, operational behaviors, descriptive features, and state qualifiers. The entity recognition model 520 is built based on the Named Entity Recognition (NER) algorithm. By constructing a label rule set, it associates various entities with preset labels (such as [fault object], [operation behavior]), and combines a context-based joint modeling strategy to improve the accuracy and robustness of entity recognition. After receiving multiple keywords (entities) and instruction information output by entity recognition model 520, semantic analysis model 530 further conducts deep semantic analysis and mining. Based on preset semantic association rules and knowledge graphs, it analyzes the relationships between entities, constructs semantic slots, and assigns labels to instructions. Semantic slots clarify the role of each entity in the fault scenario, such as "[fault location: engine]" or "[fault phenomenon: shaking]". Instruction labels categorize the user's operational intent and demand type in their voice, such as "[diagnostic request]" or "[maintenance guidance request]". Intent analysis model 540 receives multiple slots and instruction label information from semantic analysis model 530 and performs comprehensive inference of user intent. Intent analysis model 540 integrates deep learning and rule-based reasoning mechanisms. On the one hand, it utilizes deep neural networks to learn the complex mapping relationship between slots, labels, and intent categories; on the other hand, it uses preset intent reasoning rules to fuse and judge multi-dimensional semantic information. During runtime, it performs association analysis on the input slots and labels, calculates the probability values of different intent hypotheses, and finally outputs multiple first user intent information. Subsequently, to ensure the accuracy of intent recognition, the similarity score between each first user intent information and the original semantic information will be calculated, and the intent corresponding to the highest similarity score will be selected as the final user intent information. This ensures that the identified user intent accurately matches their real needs, providing clear directional guidance for subsequent vehicle fault diagnosis and service recommendation, and realizing a complete transformation from voice input to intent understanding.
[0074] Specifically, the keywords and commands obtained from the aforementioned speech recognition are used as input and fed into the semantic analysis model. The semantic analysis model is used to establish the matching relationship between semantic slots and tags, realizing a structured representation of intent components. A slot refers to a set of predefined semantic fields in the dialogue system, such as "fault type," "part name," "operation verb," and "time limit," used to represent key parameters carried in the user's expression. For example, for the sentence "There was an abnormal noise from the brakes last night," the semantic analysis model can generate the slots: "time = last night," "part = brakes," and "abnormal state = abnormal noise." Command tags represent the user's pragmatic goals, such as "requesting inspection," "requesting explanation," and "requesting recommendation." Next, the slots and command tags are input into the intent analysis model, which further infers and generates multiple candidate first-user intent information. This intent analysis model is built based on multi-turn dialogue understanding and multimodal attention mechanisms, and can integrate the semantic correlation between slots and historical dialogue context information to construct multiple user intent candidate results, each assigned a confidence score. Then, the optimal intent result is determined by calculating the semantic similarity between the first user intent information and the semantic information. Based on the vector semantic space, all candidate intent information and the semantic parsing results are encoded, and matching scores are obtained using methods such as cosine similarity, Euclidean distance, or KL divergence. Multiple similarity scores are obtained. By quantifying semantic consistency, the problems of polysemy and ambiguity in natural language expression can be effectively solved, improving the system's robust recognition ability of user intent. Finally, the candidate with the highest score is selected from the multiple similarity scores, and its corresponding user intent information is output as the final diagnostic direction. This output result will be directly used for subsequent processing in the AI diagnostic module to guide the system to narrow the diagnostic scope, focus on specific fault types, and optimize the inference path.
[0075] Step S330: Input the vehicle information into the preset AI diagnostic model to obtain the first diagnostic result.
[0076] Vehicle information includes vehicle attribute information and vehicle operating information. Vehicle attribute information mainly refers to static parameter data, such as vehicle brand, model, year of manufacture, powertrain type (gasoline / hybrid / pure electric), transmission type, VIN code, engine number, etc. Vehicle operating information consists of dynamically collected vehicle status data, typically from on-board diagnostics (OBD), sensor networks, or on-board control units (ECUs), including fault codes (DTCs), sensor readings (such as coolant temperature, voltage, and RPM), runtime, and number of starts, reflecting the vehicle's current fault performance or historical operating trends. The AI diagnostic model is an intelligent decision-making model built using a deep learning-based fault diagnosis framework. This model integrates vehicle knowledge graphs, sample learning mechanisms, and multi-source data feature extraction capabilities, aiming to perform feature modeling and semantic association analysis on the input multi-dimensional vehicle information to output reliable preliminary diagnostic results.
[0077] In one possible embodiment, the vehicle information includes: vehicle operating information and vehicle attribute information. The step of inputting the vehicle information into a preset AI diagnostic model to obtain a first diagnostic result specifically includes the following steps:
[0078] 331. Determine the vehicle model in the vehicle attribute information;
[0079] 332. Obtain the vehicle maintenance information corresponding to the vehicle model;
[0080] 333. Input the vehicle operation information and the vehicle maintenance information into the AI diagnostic model to obtain the first diagnostic information of the target vehicle; the first diagnostic information includes a first fault type;
[0081] 334. Search the preset fault diagnosis database for the diagnostic results corresponding to the vehicle model and the first fault type to obtain reference diagnostic information;
[0082] 335. Analyze the first diagnostic information and the reference diagnostic information to obtain the first diagnostic result.
[0083] Vehicle maintenance information refers to a collection of relevant information accumulated based on the vehicle model from manufacturer technical documents, maintenance case databases, and third-party maintenance data platforms. This includes: common fault types and their distribution frequency, component life parameters, fault repair records, maintenance recommendations, and component repair sequence. This information can be structured using knowledge graphs or dynamically retrieved through associative searches. Vehicle operation information refers to dynamic operational data collected in real-time or near real-time from the vehicle controller, sensor system, and communication bus. This includes: engine speed, throttle opening, battery voltage, motor temperature, transmission output, cooling system pressure, DTC fault codes, odometer readings, driving mode records, and energy recovery status. The AI diagnostic model integrates the above operational data with vehicle maintenance information, employs a multimodal feature fusion mechanism to construct a high-dimensional feature vector, and inputs it into a deep neural network structure (such as a multilayer perceptron, convolutional neural network, or Transformer). The final output is structured first diagnostic information. This diagnostic information mainly includes: the current suspected fault type, possible fault location, parameter anomalies, suggested analysis path, and relevant confidence scores, which are not limited here.
[0084] The fault diagnosis database is a pre-built high-value knowledge base that integrates self-developed databases, data from cooperative repair platforms, manufacturer technical materials, and historical case samples. It constructs a query system indexed by "vehicle model + fault type," outputting corresponding fault feature sets, typical case descriptions, recommended diagnostic procedures, and fault feature thresholds. The reference diagnostic information not only provides reliable contextual supplementation to the initial diagnostic information but also offers decision support in subsequent comparative analysis. Furthermore, the reference diagnostic information includes standard fault parameter ranges, typical component damage modes, repair time requirements, and replacement material types.
[0085] The analysis process is based on a multi-layer feature alignment and parameter matching mechanism. First, the semantic consistency between the fault type in the first diagnostic information and the reference diagnostic information is checked to confirm whether there is a common-reference match. Next, numerical domain matching is performed on key parameters (such as temperature, voltage, current, and speed), and fuzzy logic or range threshold models are used for precision alignment. Finally, a similarity score is calculated based on the degree of matching. If the similarity score is higher than a set threshold, the first diagnostic result consistent with the reference diagnosis is output; if it is lower than the threshold, dynamic correction is performed by automatically calling historical diagnostic samples or requesting subsequent steps to intervene in the analysis, such as loading the historical operating trajectory and maintenance records of the target vehicle.
[0086] In one possible embodiment, analyzing the first diagnostic information and the reference diagnostic information to obtain the first diagnostic result specifically includes the following steps:
[0087] 3351. Extract the first fault location and the first fault parameter set corresponding to the first fault type from the first diagnostic information;
[0088] 3352. Determine the reference fault location and reference fault parameter set in the reference diagnostic information;
[0089] 3353. When the first fault location is the same as the reference fault location, obtain the range of the reference fault parameter set;
[0090] 3354. Compare each parameter in the first fault parameter set with each reference fault parameter range in the reference fault parameter set range to obtain a first comparison result set;
[0091] 3555. Count the number of the first fault parameters in the first comparison result set that fall within the range of the reference fault parameters to obtain n valid comparison parameters; the first fault parameter is any one of the first fault parameter sets; the reference fault parameter is any one of the reference fault sets; n is a positive integer greater than 1.
[0092] 3356. Determine the ratio between the n valid comparison parameters and the total number of all parameters in the first fault parameter set to obtain the first matching ratio;
[0093] 3357. When the first matching ratio is greater than or equal to a preset first threshold, the first diagnostic result is generated based on the first diagnostic information.
[0094] The first fault parameter set refers to a set of key operational indicator parameters related to a specific fault type and its location, output by the AI diagnostic model based on the analysis of vehicle operation and maintenance information. These parameters include sensor data such as voltage, current, temperature, pressure, displacement, and speed, without limitation, reflecting the current state and evolution trend of the target fault. The reference fault parameter set range is a range of typical fault characteristic values related to the fault type and location, retrieved from a preset fault diagnosis database. It is usually in the form of parameter intervals, such as "normal voltage range is 11.8V to 13.2V". Its purpose is to provide a standardized comparison template for measuring whether the current fault conforms to historical fault characteristics.
[0095] The first comparison result set refers to a set of comparison judgment results obtained by comparing each parameter in the first fault parameter set with the corresponding parameter range in the reference fault parameter set. Each comparison judgment result is a Boolean value, indicating whether the target parameter falls within the corresponding reference range, i.e., whether it "matches". Firstly, a soft matching is achieved by setting a deviation tolerance δ, allowing the target parameter to fluctuate by a certain proportion based on the reference range to enhance the robustness of the comparison. Furthermore, to avoid misjudgment, an outlier detection mechanism can be introduced to remove parameters that exceed a reasonable range, ensuring the stability and reliability of the comparison data. By statistically analyzing the number of parameters n that fall within the range and calculating the ratio with the total number of parameters, the first matching ratio is obtained, thereby quantitatively evaluating the reliability of the AI diagnostic model's output results.
[0096] Specifically, when the first matching ratio is greater than or equal to a preset first threshold (e.g., 80%), it indicates that the output of the current AI diagnostic model is highly consistent with the distribution of typical fault parameters in the reference diagnostic database, possessing high diagnostic accuracy. At this point, the AI diagnostic model can directly output the first diagnostic result and proceed to subsequent processing steps, such as repair plan generation and voice feedback. If the first matching ratio is lower than this threshold, it may indicate that the current fault exhibits atypical manifestations or new fault modes, requiring further retrieval of historical vehicle information or request for multi-model collaborative analysis for supplementary diagnosis.
[0097] In one possible embodiment, after determining the ratio between the n valid comparison parameters and the total number of all parameters in the first fault parameter set to obtain the first matching ratio, the following step is further included:
[0098] A1. If the first matching ratio is less than the first threshold, obtain the historical vehicle information of the target vehicle;
[0099] A2. Input the historical vehicle information into the AI diagnostic model to obtain the second diagnostic information;
[0100] Extract the second fault parameter set corresponding to the first fault location from the second diagnostic information;
[0101] A3. Select the first fault parameters that are not in the reference fault range set from the first fault parameter set to obtain m first fault parameters; m is an integer greater than or equal to 1;
[0102] A4. Extract the second fault parameters corresponding to the m first fault parameters from the second fault parameter set to obtain m second fault parameters;
[0103] A5. Replace the m first fault parameters in the first fault parameter set with the m second fault parameters to obtain a third fault parameter set;
[0104] A6. Determine the first diagnostic result based on the third fault parameter set and the first fault location.
[0105] Historical vehicle information refers to a collection of multi-dimensional structured and semi-structured information accumulated during the target vehicle's historical maintenance processes, including vehicle operation records, repair records, fault code logs, and sensor data archives. This information includes: vehicle operating status parameters under different operating conditions, previously identified fault types and repair locations, information on replaced or adjusted parts, and the time and frequency characteristics between multiple repairs. Historical vehicle information is jointly constructed from data uploaded by the vehicle's local recording system (such as an in-vehicle terminal), cloud service platform, or authorized repair stations. Secondary diagnostic information refers to the multi-dimensional fault parameter prediction results output after processing the historical vehicle information using an AI diagnostic model. Its structure is consistent with the primary diagnostic information, facilitating subsequent comparison of differences and parameter correction operations. The second diagnostic information includes a set of predicted sensor parameters (i.e., the second fault parameter set) output for the target fault location that may lead to the fault at that location. These parameters integrate the vehicle's historical operating characteristics and the long-term learning results of the model knowledge base, and have a certain degree of robustness and representativeness. Among them, the deviation between the first fault parameters and the reference parameter range often stems from extreme operating conditions, sensor anomalies, or one-time misjudgments by the model. Therefore, the system uses the second diagnostic information to replace and correct some abnormal parameters in order to enhance the generalization ability and accuracy of the diagnostic model.
[0106] Specifically, when the first matching ratio is lower than a first threshold (e.g., set to 80%), firstly, second diagnostic information is generated by calling historical vehicle information, and m abnormal parameters in the first fault parameter set that do not fall within the reference range are identified. These parameters may be caused by noise interference or model offset. Next, substitute values corresponding to these m abnormal parameters are found in the second fault parameter set, and these substitute values replace the abnormal parameters in the first diagnostic information, forming a third fault parameter set. This replacement operation is completed based on parameter semantic labels, physical quantity units, and diagnostic semantic mapping relationships, ensuring that the new parameters can establish a logically consistent causal relationship with the original location and original fault type. Finally, the first diagnostic result is regenerated based on the third fault parameter set and the first fault location. This correction mechanism improves the adaptability of the AI diagnostic model in the face of atypical faults or insufficient data for cold-start vehicles, avoiding overall diagnostic misjudgment due to a small number of abnormal parameters. In addition, this mechanism also supports strategies such as threshold adaptive adjustment, parameter confidence weighted fusion, and multi-model diagnostic collaboration to enhance the system's fault tolerance and reliability in complex vehicle fault scenarios. Meanwhile, the correction path and replacement basis can be recorded in the system log and displayed to the operations and maintenance engineers, realizing the traceability and reliability of the diagnostic process.
[0107] In one possible embodiment, generating the first diagnostic result based on the first diagnostic information specifically includes the following steps:
[0108] 33571. Extract the first fault cause corresponding to the first fault type from the first diagnostic information;
[0109] 33572. Determine the first fault result corresponding to the first fault type based on the preset fault result set;
[0110] 33573. Determine the first diagnostic result based on the first fault cause and the first fault result.
[0111] The first fault cause refers to the direct or indirect cause of the current first fault type, determined by the AI diagnostic model based on changes in the target vehicle's operating parameters, abnormal state characteristics, or historical experience. This fault cause is usually represented in a structured form, such as "high temperature leads to battery capacity degradation" or "sensor drift causes control system malfunctions," and can also be mapped to standardized labels (e.g., electrical aging, structural damage, communication anomalies). The first fault result refers to the standardized maintenance consequences, system state changes, or potential risk assessment results that match the current first fault type. The fault result set is a structured knowledge base built based on a large amount of historical maintenance records, engineering experience, and expert rules. Its content includes the final manifestations and impacts of various common and typical faults.
[0112] Specifically, the AI diagnostic model extracts parameter change features that have a significant causal relationship with the first fault type from the first diagnostic information and outputs the first fault cause based on the model's inference path. The AI diagnostic model can use graph neural networks (GNNs) or causal inference networks to trace the source signals or behavioral patterns that cause the fault. For example, when detecting a fault type of "slow braking response," it identifies "reduced brake fluid pressure" and "brake pad wear exceeding 80%" as possible first fault causes, and extracts one or more of the most likely causes as the final output after ranking them by confidence score. Next, it calls up entries in the fault result set that match "braking system related" or "slow response type fault" to find the corresponding standard fault result. For example, according to preset rules, this type of fault can be output as the first fault result along with "recommend replacing brake pads and checking the hydraulic system," and a confidence label and subsequent processing suggestions can be attached to the result. Then, by comprehensively considering factors such as the fault impact path, actual feasibility, and maintenance priority, a structured first diagnostic result is output. The initial diagnostic results include: suggested repair locations, expected fault level, recommended repair actions, estimated work hours, and risk warning information, serving as an important basis for subsequent repair plan recommendations or voice feedback.
[0113] Step S340: Determine the target diagnostic result of the target vehicle based on the first diagnostic result and the user intent information.
[0114] The first diagnostic result is a standardized diagnostic conclusion output by the AI diagnostic model based on the target vehicle's operation, historical data, and model reasoning path. It represents the most likely fault type, fault location, and cause inference derived by the system based on objective data. The first diagnostic result may include: main fault location, suspected faulty components, repair suggestions, fault level, confidence score, etc., without limitation. This result often has the characteristics of being data-driven, traceable, and standardized, which facilitates subsequent interaction with maintenance knowledge graphs or maintenance rule systems.
[0115] The user intent information is derived from the user's natural language input (speech or text) through semantic and intent recognition models. It reveals the user's concerns about the fault, their subjective judgment, or the direction they hope the system will focus on analyzing. This reflects the user's preferred expression or concern regarding the current fault phenomenon. This user intent information may include explicit goals and implicit tendencies, which will be embedded into a multi-dimensional semantic vector. This vector will be semantically fused with the diagnostic results and its relevance will be calculated to enhance the human-machine matching degree of the diagnostic results.
[0116] In one possible embodiment, determining the target diagnostic result of the target vehicle based on the first diagnostic result and the user intent information specifically includes the following steps:
[0117] 341. Extract the second fault type corresponding to the voice command based on the user intent information;
[0118] 342. Determine the target fault type in the first diagnostic result;
[0119] 343. Determine the target matching degree between the target fault type and the second fault type based on a preset matching algorithm;
[0120] 344. When the target matching degree is greater than or equal to a preset first matching threshold, filter the second fault cause and the second fault location corresponding to the second fault type from the first diagnostic results;
[0121] 345. Determine the target diagnostic result based on the second fault cause and the second fault location.
[0122] The user intent information is a set of semantic tags generated from the user's natural language input. It contains the user's subjective description and focus on the fault phenomenon. After semantic recognition, keyword extraction, and intent analysis, it can be mapped to a predefined set of standard fault types to form a second fault type. This second fault type serves as a suspected problem classification label from the user's cognitive perspective, and is an important bridge for interactive collaborative diagnosis between the user and the AI system. The target fault type in the first diagnostic result is derived by the AI diagnostic model through comprehensive reasoning based on the target vehicle's operating data, vehicle attribute information, and historical diagnostic data. It usually has a high degree of objective data confidence and is used to identify the most likely fault category determined by the system, such as: powertrain fault, battery management system fault, braking system anomaly, etc.
[0123] Specifically, firstly, the semantic information in the user's voice input is classified and processed by the voice intent recognition module to extract implicit fault keywords and behavioral verbs (such as "brakes become soft," "weak start," "rapid battery drain"), and the corresponding standard fault types are identified based on semantic matching algorithms or pre-trained language models (such as BERT, ERNIE, etc.) to obtain the second fault type. Next, the target fault type is obtained from the first diagnostic result and matched with the second fault type. To quantify the semantic similarity or logical consistency between the two, a multi-dimensional matching algorithm can be used, such as word vector cosine similarity calculation, fault tree structure alignment algorithm, or concept distance evaluation based on diagnostic knowledge graph, etc., without limitation, to obtain a target matching degree representing the correlation between the two types of faults. When the target matching degree is greater than or equal to a preset first matching threshold (e.g., 0.7), it is considered that the user's subjective judgment and the AI diagnostic model result are highly consistent. To avoid redundant and repetitive reasoning, the specific content corresponding to the second fault type, including the cause and location of the second fault, is directly selected from the first diagnostic result of the AI model. Finally, the target diagnostic result is formed by combining the second fault cause and the second fault location. The target diagnostic result not only retains the objective information extracted by the AI system based on data analysis, but also enhances the consistency with the user's subjective description, thus having a stronger user understanding and willingness to adopt in information presentation, maintenance suggestion generation, or service recommendation. In addition, the matching algorithm can also introduce an adjustable weight matching mechanism, that is, set different matching thresholds or algorithm parameters according to user type (professional user, ordinary car owner), historical diagnostic preferences, and accuracy of intent expression, so as to adapt to diagnostic collaboration strategies under different usage scenarios. At the same time, in order to improve the interpretability and user trust of the target diagnostic result, the matching reason explanation can also be output, such as "This result is highly correlated with your description of 'slow vehicle start-up,' mainly caused by insufficient battery voltage. It is recommended to check the battery status and investigate whether there is a short-term high load abnormality."
[0124] Step S350: Determine the target maintenance prompt information corresponding to the target vehicle based on the preset maintenance guidance model and the target diagnostic results; the target maintenance prompt information is used to guide the target user to perform maintenance operations on the target vehicle via voice.
[0125] The maintenance guidance model is an intelligent system that integrates various advanced technologies and most automotive maintenance data available on the market. Its aim is to accurately generate maintenance tips based on vehicle diagnostic results. The target diagnostic result is a precise fault judgment obtained by comprehensively analyzing various sensor data, fault codes, and vehicle operating status information after inspecting the target vehicle. During vehicle fault diagnosis, various sensors first collect real-time operating parameters of various vehicle systems and components, such as engine speed, vehicle speed, oil temperature, oil pressure, and exhaust emission indicators. Simultaneously, the OBD monitors and records fault codes generated by the vehicle's electronic control system. The diagnostic equipment summarizes this raw data and analyzes it using specific diagnostic algorithms and logical rules. For example, when the engine malfunction indicator lamp is detected, the diagnostic equipment reads the corresponding fault code and further analyzes multiple sensor data associated with that fault code. Combining the parameter range during normal vehicle operation with experiential knowledge from the fault case library, it determines the specific location and cause of the fault, ultimately forming the target diagnostic result. This target diagnostic result serves as the key input to the maintenance guidance model, guiding the model to generate corresponding target maintenance tips. The target repair prompts cover a wide range of topics, from fault cause analysis and a list of required repair tools to demonstrations of specific repair steps and emphasis on repair precautions. They are presented to the target user in a clear and easy-to-understand voice format, helping the user to successfully complete the repair operation of the target vehicle.
[0126] In one possible embodiment, determining the target repair prompt information corresponding to the target vehicle based on the preset repair guidance model and the target diagnostic results specifically includes the following steps:
[0127] 351. Determine the target diagnosis description in the target diagnosis results;
[0128] 352. Obtain the driving information of the target user; the driving information includes the vehicle usage scenario;
[0129] 353. Determine the first fault risk score of the target vehicle based on the target diagnostic description;
[0130] 354. Determine the first fault risk weight corresponding to the vehicle usage scenario based on the preset mapping relationship between vehicle usage scenarios and fault risk weights.
[0131] 355. Determine the target fault risk score based on the first fault risk weight and the first fault risk score;
[0132] 356. When the target fault risk score is greater than the preset first fault risk threshold, the target diagnostic result and the vehicle information are input into the maintenance guidance model to obtain the target maintenance case;
[0133] 357. Search the database of preset repair cases and repair guidance information for the target repair case and the corresponding target repair prompt information.
[0134] The target diagnostic description is a structured text transformation of the target diagnostic results, including: fault location, fault characteristic parameters, and abnormal behavior description. The fault location is generated based on the fault code parsing of the vehicle's electronic control system, such as "P0300 random / multi-cylinder misfire" corresponding to "engine ignition system". Fault characteristic parameters are extracted from the OBD real-time data stream, including abnormal parameter values and normal threshold ranges, such as "engine idle speed fluctuation range is 800±50r / min, current measured value is 650-950r / min". The abnormal behavior description uses a natural language processing model to semantically transform user voice feedback, transforming "the car jerks when accelerating" into "intermittent interruption of power output under rapid acceleration". The vehicle usage scenario is determined through multi-source data fusion, including three sub-dimensions: driving conditions, usage frequency, and load characteristics. Driving conditions are divided into urban congested conditions, highway conditions, and rural unpaved road conditions; usage frequency is statistically analyzed through vehicle system login logs, with weekly average number of starts and single driving duration as quantitative indicators; load characteristics are determined by combining vehicle weight sensor data and seat occupancy status.
[0135] Specifically, the first fault risk score employs an analytic hierarchy process (AHP) to construct a multi-level evaluation system. First-level indicators include the fault's impact range, frequency of occurrence, and development trend. Second-level indicators are further subdivided for each system; for example, the engine system includes sub-items such as ignition efficiency and fuel injection accuracy. The weights of each indicator are determined using expert scoring combined with fault tree analysis (FTA), with a fault weight of 0.4 for core engine components and 0.2 for electronic auxiliary system faults. The score calculation uses a weighted sum of "indicator value × weight," ultimately outputting a score from 0 to 100, with 60 points serving as the baseline risk threshold. The mapping relationship between vehicle usage scenarios and fault risk weights is generated through a backpropagation (BP) neural network model. The network input layer is a scenario feature vector (quantified values of road condition type, usage frequency, and load characteristics), the hidden layer uses the ReLU activation function for nonlinear transformation, and the output layer consists of three weight coefficients (i.e., timeliness weight, severity weight, and diffusion weight). The target fault risk score is calculated as "first fault risk score × first fault risk weight + dynamic correction value". The dynamic correction value is generated based on the user's historical fault handling records. If the user delays handling the same type of fault more than 3 times in the past six months, the correction value is increased by 5 points. If the user has professional repair qualifications (verified through driver's license supplementary information), the correction value is decreased by 3 points. The first fault risk threshold adopts an adaptive adjustment mechanism with a default value of 70 points. When the vehicle is detected to be in mountainous areas, deserts or other areas with difficult rescue, the threshold is automatically reduced to 60 points, triggering the early warning mechanism in advance.
[0136] Specifically, the repair guidance model includes a case retrieval module and a knowledge reasoning module. Case retrieval uses the k-nearest neighbor (k-NN) algorithm, based on the feature vector of the target diagnostic result (fault location, parameter deviation, scene features), and matches the top 5 cases with a similarity of ≥85% from the case library. The knowledge reasoning module is built based on a rule engine and a semantic network, with the semantic network storing component relationships. Both modules collaboratively output target repair cases, which include standardized repair steps, a list of required tools (matching the user's vehicle tool kit configuration), and safety precautions (such as "disconnect the battery negative terminal before repair"). Furthermore, the repair case and repair guidance information database adopts a distributed storage architecture, divided into a text library, a voice library, and a video library. The text library stores structured descriptions of repair steps; the voice library contains step-by-step voice commands recorded by professional technicians, supporting adjustable speech rate and dialect versions; the video library stores high-definition repair operation videos, categorized by fault type, with AR annotations added to key steps (such as component highlighting and operation trajectory animation). When multiple matching cases are retrieved, they are automatically sorted according to the user's historical preferences (such as prioritizing video guidance or voice guidance), with the highest matching result displayed at the top.
[0137] For easier understanding, please refer to Figure 6 , Figure 6This is a schematic diagram of an interface interaction for a vehicle fault handling scenario based on AI voice, provided in the application embodiment. As can be seen, the interface constructs a system based on user voice request cards and core voice acquisition controls, covering diverse vehicle usage scenarios such as navigation, entertainment, and vehicle diagnostics, establishing a front-end entry point for user-vehicle intelligent system voice interaction. Specifically, the interfaces display requests such as "Navigate to Wanda," "I want to listen to music," "Check why the vehicle is shaking," and "Why is my speed slowing down?" corresponding to the request categories of travel navigation, entertainment services, fault diagnosis, and performance inquiries, respectively. When performing vehicle diagnostics, simply saying a sentence, such as "Check why the vehicle is shaking," accurately identifies the vehicle's abnormal driving diagnostic scenario and deeply integrates it with the vehicle fault handling system. When the user triggers this request, it drives the system to call the AI diagnostic model, combining vehicle operating data and historical fault databases to perform diagnostic reasoning. The voice acquisition controls (…) Figure 6 The microphone icon (in the center) serves as the core of the interaction trigger, possessing multimodal interaction adaptation capabilities. At the hardware level, it is compatible with multiple terminal inputs, including in-vehicle microphone arrays and mobile phone Bluetooth microphones, ensuring voice acquisition quality in different driving scenarios (while driving, after parking). At the software level, it integrates noise suppression and echo cancellation algorithms to dynamically filter interference from road noise, wind noise, and environmental noise such as music playing from the in-car audio system, improving the purity of the voice signal and providing high-quality input for subsequent voice recognition models. When the user clicks on a request card or directly wakes up the system with voice, the interface triggers the voice acquisition and recognition process. Taking "Check why the vehicle is shaking" as an example, the user's voice is acquired and transmitted to the voice recognition model. This model, trained on a large-scale vehicle fault voice corpus, accurately identifies the core semantics of "vehicle shaking" and transforms it into a standardized text input AI diagnostic model. The AI diagnostic model calls upon vehicle operating data (such as engine speed, tire pressure, and suspension system sensor data) and combines it with a fault knowledge graph (fault codes associated with "vehicle vibration," component failure modes, and repair cases) to deduce the cause of the fault, such as identifying potential fault points like "spark plug wear" or "abnormal tire dynamic balance." The diagnostic results are then output through a natural language generation module and fed back to the user via text-to-speech. This interface interaction method constructs an intuitive dialogue window between the user and the vehicle's intelligent system, breaking through the traditional reliance on physical buttons and touchscreen menus for vehicle interaction, and upgrading voice interaction from "command-based wake-up" to "scenario-based guidance + free interaction." In vehicle fault handling scenarios, the accurate transmission of diagnostic needs through demand cards, combined with the efficient input of voice acquisition controls, improves the user's driving experience and vehicle fault handling efficiency, thereby enhancing the user's overall experience.
[0138] For easier understanding, please refer to Figure 7 , Figure 7This is a flowchart illustrating another AI-based voice-based vehicle fault handling method provided in the application embodiment. First, multimodal intelligent voice wake-up technology is employed, combining traditional voice keyword wake-up with biometric recognition technologies such as facial recognition and fingerprint recognition. For example, when a user sits in the driver's seat, the system automatically activates the voice interaction function after confirming the user's identity through facial recognition. Simultaneously, a personalized voice prompt is used to greet the user based on their personal habits, such as, "Welcome, [owner's name], what car problem do you need my help with?" Next, a deep learning-based natural language processing model (i.e., a speech recognition model) is constructed, enabling it to understand the semantics and context of natural language. Users can describe car problems using everyday colloquial expressions, such as "I feel the car is accelerating a bit slowly, lacking power." The speech recognition model receives the user's voice, allowing the system to accurately identify and analyze the problem. Then, AI intelligent diagnostic analysis is performed. The AI intelligent diagnostic unit integrates the vehicle's OBD data, sensor data, maintenance history data, and cloud-based big data. After a user describes a problem, the system first retrieves real-time vehicle operating data from the OBD interface, such as engine speed, vehicle speed, and oil pressure. Simultaneously, it combines data from sensors installed in various parts of the car, such as temperature and pressure sensors, to comprehensively monitor the vehicle's status. Furthermore, it retrieves the vehicle's maintenance history data to see if similar problems have occurred previously. Finally, this data is compared and analyzed with big data in the cloud, which contains numerous diagnostic cases and solutions for the same vehicle model and fault type. Then, machine learning algorithms are used to analyze the vehicle's operating data in real time to predict potential faults. For example, through long-term monitoring and analysis of engine oil pressure sensor data, when a gradual decrease in oil pressure is detected, the system will issue an early warning, prompting the user to check the oil system promptly to prevent engine damage due to insufficient oil. Once the system diagnoses a fault, it provides detailed repair guidance to the user via voice. The repair guidance uses a step-by-step approach, guiding the user through the repair operations step by step. For example, the system might guide you with instructions like, "First, open the hood; second, locate the air filter on the left side of the engine; third, check if the air filter is clogged. If it is, clean it following these steps..." In addition to voice guidance, the system will also push relevant repair videos to the user's in-car display or mobile app based on the type of fault. These repair videos, recorded by professional automotive technicians, clearly demonstrate the repair process and key operational points, making it easier for users to learn and operate intuitively. Finally, the system will provide personalized diagnostic solutions based on the user's driving habits and vehicle usage scenarios. For example, for users who frequently drive in congested urban traffic, the system will focus on engine carbon buildup and transmission wear; for users who frequently drive long distances, the system will focus more on tire wear and braking system performance.In addition, a user feedback mechanism has been established, allowing users to provide feedback on diagnostic results and repair instructions via voice or text during use. Based on user feedback, the system will continuously optimize its diagnostic algorithms and repair instructions, improving the system's accuracy and usability.
[0139] As can be seen, by implementing the AI-based voice-based vehicle fault handling method provided in this application embodiment, the user's voice and the vehicle information of the target vehicle are acquired. The user's voice is input into a preset voice recognition model to obtain user intent information, which represents the target user's diagnostic direction for the target vehicle. The vehicle information is input into a preset AI diagnostic model to obtain a first diagnostic result. Based on the first diagnostic result and the user intent information, a target diagnostic result for the target vehicle is determined. Based on a preset maintenance guidance model and the target diagnostic result, target maintenance prompt information corresponding to the target vehicle is determined. The target maintenance prompt information is used to guide the target user to perform maintenance operations on the target vehicle via voice. Thus, during vehicle operation, the diagnostic device receives the user's voice command, performs AI analysis and diagnosis based on the voice command, and infers the user's intent through AI for in-depth analysis to obtain an AI diagnostic result. This eliminates the need for the user to manually operate the diagnostic device, thereby improving the user's experience when handling faults.
[0140] The above primarily describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the diagnostic device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0141] This application embodiment can divide the diagnostic device into functional units according to the above method example. For example, each function can be divided into separate functional units, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.
[0142] When dividing each function into modules according to its corresponding function. Figure 8This is a functional module block diagram of a vehicle fault handling device based on AI voice provided in an embodiment of this application. The vehicle fault handling device 800 based on AI voice includes:
[0143] The acquisition module 810 is used to acquire the user's voice and the vehicle information of the target vehicle;
[0144] The calculation module 820 is used to input the user's voice into a preset speech recognition model to obtain user intent information; the user intent information is used to characterize the diagnostic direction of the target user for the target vehicle; and input the vehicle information into a preset AI diagnostic model to obtain a first diagnostic result.
[0145] The determination module 830 is used to determine the target diagnostic result of the target vehicle based on the first diagnostic result and the user intent information;
[0146] The control module 840 is used to determine the target maintenance prompt information corresponding to the target vehicle based on the preset maintenance guidance model and the target diagnostic results; the target maintenance prompt information is used to guide the target user to perform maintenance operations on the target vehicle via voice.
[0147] In one possible embodiment, the computing module 820, in terms of inputting the user's voice into a preset speech recognition model to obtain user intent information, is specifically used for:
[0148] The first speech information is parsed based on a preset semantic recognition model to obtain the first semantic information;
[0149] A preset entity recognition model is used to identify multiple keywords and multiple instructions from the first semantic information;
[0150] The multiple keywords and multiple instructions are input into a preset semantic analysis model to obtain multiple slots and multiple instruction tags;
[0151] The multiple slots and multiple instruction tags are input into a preset intent analysis model to obtain multiple first user intent information;
[0152] A similarity score is determined between each of the plurality of first user intent information and each of the plurality of first semantic information to obtain a plurality of similarity scores;
[0153] The highest similarity score among the plurality of similarity scores is determined, and the first user intent information corresponding to the highest similarity score is taken as the user intent information.
[0154] In one possible embodiment, the vehicle information includes: vehicle operating information and vehicle attribute information. Specifically, the calculation module 820, in inputting the vehicle information into a preset AI diagnostic model to obtain a first diagnostic result, is used for:
[0155] Determine the vehicle model from the vehicle attribute information;
[0156] Obtain the vehicle maintenance information corresponding to the vehicle model;
[0157] The vehicle operation information and the vehicle maintenance information are input into the AI diagnostic model to obtain the first diagnostic information of the target vehicle; the first diagnostic information includes a first fault type.
[0158] The system retrieves the diagnostic results corresponding to the vehicle model and the first fault type from a preset fault diagnosis database to obtain reference diagnostic information.
[0159] The first diagnostic information and the reference diagnostic information are analyzed to obtain the first diagnostic result.
[0160] In one possible embodiment, the calculation module 820, in analyzing the first diagnostic information and the reference diagnostic information to obtain the first diagnostic result, is specifically configured to:
[0161] Extract the first fault location and the first fault parameter set corresponding to the first fault type from the first diagnostic information;
[0162] Determine the reference fault location and reference fault parameter set in the reference diagnostic information;
[0163] When the first fault location is the same as the reference fault location, the range of the reference fault parameter set is obtained;
[0164] Each parameter in the first fault parameter set is compared with each reference fault parameter range in the reference fault parameter set range to obtain a first comparison result set.
[0165] The number of first fault parameters in the first comparison result set that fall within the range of the reference fault parameters is counted to obtain n valid comparison parameters; the first fault parameter is any one of the first fault parameter sets; the reference fault parameter is any one of the reference fault sets; n is a positive integer greater than 1;
[0166] The ratio between the n valid comparison parameters and the total number of all parameters in the first fault parameter set is determined to obtain the first matching ratio.
[0167] When the first matching ratio is greater than or equal to a preset first threshold, the first diagnostic result is generated based on the first diagnostic information.
[0168] In one possible embodiment, after determining the ratio between the n valid comparison parameters and the total number of all parameters in the first fault parameter set to obtain the first matching ratio, the calculation module 820 is further configured to:
[0169] If the first matching ratio is less than the first threshold, obtain the historical vehicle information of the target vehicle;
[0170] The historical vehicle information is input into the AI diagnostic model to obtain the second diagnostic information;
[0171] Extract the second fault parameter set corresponding to the first fault location from the second diagnostic information;
[0172] First fault parameters that are not in the reference fault range set are selected from the first fault parameter set to obtain m first fault parameters; m is an integer greater than or equal to 1.
[0173] Extract the second fault parameters corresponding to the m first fault parameters from the second fault parameter set to obtain m second fault parameters;
[0174] The m second fault parameters replace the m first fault parameters in the first fault parameter set to obtain the third fault parameter set;
[0175] The first diagnostic result is determined based on the third fault parameter set and the first fault location.
[0176] In one possible embodiment, the calculation module 820, in generating the first diagnostic result based on the first diagnostic information, is specifically configured to:
[0177] Extract the first fault cause corresponding to the first fault type from the first diagnostic information;
[0178] The first fault result corresponding to the first fault type is determined based on a preset fault result set;
[0179] The first diagnostic result is determined based on the first fault cause and the first fault result.
[0180] In one possible embodiment, the determining module 830, in determining the target diagnostic result of the target vehicle based on the first diagnostic result and the user intent information, is specifically configured to:
[0181] Extract the second fault type corresponding to the voice command based on the user intent information;
[0182] Determine the target fault type in the first diagnostic result;
[0183] The target matching degree between the target fault type and the second fault type is determined based on a preset matching algorithm;
[0184] When the target matching degree is greater than or equal to a preset first matching threshold, the second fault cause and the second fault location corresponding to the second fault type are filtered from the first diagnostic results.
[0185] The target diagnostic result is determined based on the second fault cause and the second fault location.
[0186] In one possible embodiment, the control module 840, in determining the target maintenance prompt information corresponding to the target vehicle based on the preset maintenance guidance model and the target diagnostic results, is specifically used for:
[0187] Determine the target diagnostic description in the target diagnostic results;
[0188] Obtain the target user's driving information; the driving information includes the vehicle usage scenario.
[0189] A first fault risk score for the target vehicle is determined based on the target diagnostic description.
[0190] The first fault risk weight corresponding to the vehicle usage scenario is determined based on the preset mapping relationship between vehicle usage scenarios and fault risk weights.
[0191] The target fault risk score is determined based on the first fault risk weight and the first fault risk score.
[0192] When the target fault risk score is greater than a preset first fault risk threshold, the target diagnostic result and the vehicle information are input into the maintenance guidance model to obtain a target maintenance case;
[0193] The system searches for the target repair case and the corresponding target repair prompt information in a pre-set database of repair cases and repair guidance information.
[0194] As can be seen, by implementing the AI-based voice-based vehicle fault handling device described in the embodiments of this application, applied to a diagnostic device, the device acquires the user's voice and the vehicle information of the target vehicle, inputs the user's voice into a preset voice recognition model to obtain user intent information, wherein the user intent information is used to characterize the target user's diagnostic direction for the target vehicle. Next, the vehicle information is input into a preset AI diagnostic model to obtain a first diagnostic result. Then, based on the first diagnostic result and the user intent information, a target diagnostic result for the target vehicle is determined. Finally, based on a preset maintenance guidance model and the target diagnostic result, a target maintenance prompt information corresponding to the target vehicle is determined, wherein the target maintenance prompt information is used to voice guide the target user to perform maintenance operations on the target vehicle. Thus, during vehicle operation, by receiving the user's voice commands, performing AI analysis and diagnosis based on the voice commands, and inferring the user's intent through AI for in-depth analysis, an AI diagnostic result is obtained. This eliminates the need for the user to manually operate the diagnostic device, improving user safety while driving and enhancing the user's experience when handling vehicle malfunctions.
[0195] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, the computer program causing a computer to perform some or all of the steps of any of the methods described in the above method embodiments, the computer including a diagnostic device.
[0196] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include diagnostic devices.
[0197] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.
[0198] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0199] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.
[0200] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.
[0201] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).
[0202] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on a processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented using a software program that runs on a processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.
[0203] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.
Claims
1. A vehicle fault handling method based on AI voice, characterized in that, Applied to diagnostic devices, the method includes: Obtain the target user's voice recordings and the target vehicle's information; The user's voice is input into a preset speech recognition model to obtain user intent information; the user intent information is used to characterize the diagnostic direction of the target user for the target vehicle; The vehicle information is input into a preset AI diagnostic model to obtain a first diagnostic result; The target diagnostic result of the target vehicle is determined based on the first diagnostic result and the user intent information; Based on the preset maintenance guidance model and the target diagnostic results, the target maintenance prompt information corresponding to the target vehicle is determined; the target maintenance prompt information is used to guide the target user to perform maintenance operations on the target vehicle via voice.
2. The method as described in claim 1, characterized in that, The step of inputting the user's voice into a preset speech recognition model to obtain user intent information includes: The first speech information is parsed based on a preset semantic recognition model to obtain the first semantic information; A preset entity recognition model is used to identify multiple keywords and multiple instructions from the first semantic information; The multiple keywords and multiple instructions are input into a preset semantic analysis model to obtain multiple slots and multiple instruction tags; The multiple slots and multiple instruction tags are input into a preset intent analysis model to obtain multiple first user intent information; A similarity score is determined between each of the plurality of first user intent information and each of the plurality of first semantic information to obtain a plurality of similarity scores; The highest similarity score among the plurality of similarity scores is determined, and the first user intent information corresponding to the highest similarity score is taken as the user intent information.
3. The method as described in claim 1, characterized in that, The vehicle information includes: vehicle operation information and vehicle attribute information. The step of inputting the vehicle information into a preset AI diagnostic model to obtain a first diagnostic result includes: Determine the vehicle model from the vehicle attribute information; Obtain the vehicle maintenance information corresponding to the vehicle model; The vehicle operation information and the vehicle maintenance information are input into the AI diagnostic model to obtain the first diagnostic information of the target vehicle; the first diagnostic information includes a first fault type. The system retrieves the diagnostic results corresponding to the vehicle model and the first fault type from a preset fault diagnosis database to obtain reference diagnostic information. The first diagnostic information and the reference diagnostic information are analyzed to obtain the first diagnostic result.
4. The method as described in claim 3, characterized in that, The step of analyzing the first diagnostic information and the reference diagnostic information to obtain the first diagnostic result includes: Extract the first fault location and the first fault parameter set corresponding to the first fault type from the first diagnostic information; Determine the reference fault location and reference fault parameter set in the reference diagnostic information; When the first fault location is the same as the reference fault location, the range of the reference fault parameter set is obtained; Each parameter in the first fault parameter set is compared with each reference fault parameter range in the reference fault parameter set range to obtain a first comparison result set. The number of first fault parameters in the first comparison result set that fall within the range of the reference fault parameters is counted to obtain n valid comparison parameters; the first fault parameter is any one of the first fault parameter sets; the reference fault parameter is any one of the reference fault sets; n is a positive integer greater than 1; The ratio between the n valid comparison parameters and the total number of all parameters in the first fault parameter set is determined to obtain the first matching ratio. When the first matching ratio is greater than or equal to a preset first threshold, the first diagnostic result is generated based on the first diagnostic information.
5. The method as described in claim 4, characterized in that, After determining the ratio between the n valid comparison parameters and the total number of all parameters in the first fault parameter set to obtain the first matching ratio, the method further includes: If the first matching ratio is less than the first threshold, obtain the historical vehicle information of the target vehicle; The historical vehicle information is input into the AI diagnostic model to obtain the second diagnostic information; Extract the second fault parameter set corresponding to the first fault location from the second diagnostic information; First fault parameters that are not in the reference fault range set are selected from the first fault parameter set to obtain m first fault parameters; m is an integer greater than or equal to 1. Extract the second fault parameters corresponding to the m first fault parameters from the second fault parameter set to obtain m second fault parameters; The m second fault parameters replace the m first fault parameters in the first fault parameter set to obtain the third fault parameter set; The first diagnostic result is determined based on the third fault parameter set and the first fault location.
6. The method as described in claim 4, characterized in that, The step of generating the first diagnostic result based on the first diagnostic information includes: Extract the first fault cause corresponding to the first fault type from the first diagnostic information; The first fault result corresponding to the first fault type is determined based on a preset fault result set; The first diagnostic result is determined based on the first fault cause and the first fault result.
7. The method according to any one of claims 1-6, characterized in that, Determining the target diagnostic result of the target vehicle based on the first diagnostic result and the user intent information includes: Extract the second fault type corresponding to the voice command based on the user intent information; Determine the target fault type in the first diagnostic result; The target matching degree between the target fault type and the second fault type is determined based on a preset matching algorithm; When the target matching degree is greater than or equal to a preset first matching threshold, the second fault cause and the second fault location corresponding to the second fault type are filtered from the first diagnostic results. The target diagnostic result is determined based on the second fault cause and the second fault location.
8. The method according to any one of claims 1-6, characterized in that, The step of determining the target repair prompt information corresponding to the target vehicle based on the preset repair guidance model and the target diagnostic results includes: Determine the target diagnostic description in the target diagnostic results; Obtain the target user's driving information; the driving information includes the vehicle usage scenario. A first fault risk score for the target vehicle is determined based on the target diagnostic description. The first fault risk weight corresponding to the vehicle usage scenario is determined based on the preset mapping relationship between vehicle usage scenarios and fault risk weights. The target fault risk score is determined based on the first fault risk weight and the first fault risk score. When the target fault risk score is greater than a preset first fault risk threshold, the target diagnostic result and the vehicle information are input into the maintenance guidance model to obtain a target maintenance case; The system searches for the target repair case and the corresponding target repair prompt information in a pre-set database of repair cases and repair guidance information.
9. A vehicle fault handling device based on AI voice, characterized in that, Applied to diagnostic equipment, the device includes: The acquisition module is used to acquire the user's voice and the vehicle information of the target vehicle; The calculation module is used to input the user's voice into a preset speech recognition model to obtain user intent information; the user intent information is used to characterize the diagnostic direction of the target user for the target vehicle; and input the vehicle information into a preset AI diagnostic model to obtain a first diagnostic result. The determination module is used to determine the target diagnostic result of the target vehicle based on the first diagnostic result and the user intent information; The control module is used to determine the target maintenance prompt information corresponding to the target vehicle based on the preset maintenance guidance model and the target diagnostic results; the target maintenance prompt information is used to guide the target user to perform maintenance operations on the target vehicle via voice.
10. A diagnostic device, characterized in that, include: Processor, memory, communication interface, and one or more programs; The one or more programs are stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps of the method as described in any one of claims 1-8.