A vehicle failure processing method, device, server and program product

Abstract

The application is suitable for the technical field of vehicle maintenance, and provides a vehicle fault processing method, device, server and program product.The method comprises the following steps: in response to a vehicle fault query request of a user terminal, acquiring a fault query text carried in the vehicle fault query request, and acquiring a vehicle candidate fault vector set, wherein the vehicle candidate fault vector set comprises a plurality of candidate fault vectors, and the candidate fault vectors are constructed in advance based on vehicle fault codes and vehicle maintenance case information; determining a target fault vector matched with the fault query text according to the vehicle candidate fault vector set; generating maintenance guidance data corresponding to the vehicle fault query request based on the fault query text and the target fault vector; and returning the maintenance guidance data to the user terminal.The method can make the generated maintenance guidance content better adapt to the fault processing scene of vehicle maintenance, and improve the reliability and safety of the user when executing a maintenance decision for the vehicle.

Description

Technical Field

[0001] This application belongs to the field of vehicle maintenance technology, and in particular relates to a vehicle fault handling method, device, server and program product. Background Technology

[0002] With the rapid development of the intelligent vehicle industry, artificial intelligence is gradually and deeply integrated into the automotive repair process service system, becoming a core driving force for the digital, precise, and efficient transformation of the automotive repair industry. Relying on technologies such as big data analysis, intelligent image recognition, fault algorithms, and data linkage with in-vehicle terminals, artificial intelligence can replace the traditional manual experience-based troubleshooting mode, significantly shortening the fault diagnosis time.

[0003] However, existing vehicle fault handling methods mainly use general large language models for fault analysis. With insufficient coverage of structured knowledge bases, they cannot generate effective maintenance guidance content, resulting in low accuracy in fault handling for vehicle maintenance scenarios, which affects the reliability and safety of maintenance decisions. Summary of the Invention

[0004] This application provides a vehicle fault handling method, device, server, and program product, which enables the generated maintenance guidance content to be better adapted to vehicle maintenance fault handling scenarios, and improves the reliability and safety of users when making vehicle maintenance decisions.

[0005] In a first aspect, embodiments of this application provide a vehicle fault handling method, applied on a server side, the method comprising: In response to a vehicle fault query request from a user, the system retrieves the fault query text carried in the vehicle fault query request and obtains a set of candidate vehicle fault vectors. The set of candidate vehicle fault vectors includes multiple candidate fault vectors, which are pre-constructed based on vehicle fault codes and vehicle repair case information. Based on the vehicle candidate fault vector set, the target fault vector that matches the fault query text is determined. The target fault vector is the candidate fault vector in the vehicle candidate fault vector set whose similarity with the fault query text meets the set conditions. Based on the fault query text and the target fault vector, generate maintenance guidance data corresponding to the vehicle fault query request; The system returns maintenance guidance data to the user's device, which is also used to instruct the user to perform vehicle maintenance based on the maintenance guidance data.

[0006] In one possible implementation of the first aspect, determining the target fault vector matching the fault query text based on the vehicle candidate fault vector set includes: Perform vector transformation on the fault query text to obtain the fault query vector corresponding to the fault query text; The similarity between the fault query vector and each candidate fault vector in the vehicle candidate fault vector set is calculated to obtain the similarity corresponding to each candidate fault vector. Among all candidate fault vectors, the candidate fault vectors whose similarity meets the set conditions are determined as the target fault vectors.

[0007] In one possible implementation of the first aspect, obtaining the vehicle candidate fault vector set includes: Obtain vehicle fault code collections and vehicle repair case information; The fault codes in the vehicle fault code set and the vehicle repair cases in the vehicle repair case information are structured to obtain candidate fault entries corresponding to each fault code. The structured processing includes at least association processing and scenario labeling processing. Each candidate fault entry corresponding to each fault code includes at least the fault code, fault name, root cause analysis, repair steps, applicable vehicle model and scenario label. Perform vector transformation on the candidate fault entries corresponding to each fault code to obtain the candidate fault vector corresponding to each fault code; The candidate fault vectors corresponding to all fault codes are determined as the vehicle candidate fault vector set.

[0008] In one possible implementation of the first aspect, maintenance guidance data corresponding to the vehicle fault query request is generated based on the fault query text and the target fault vector, including: Identify candidate fault entries associated with the target fault vector; The candidate fault entries associated with the fault query text and the target fault vector are input into the pre-trained language model to obtain the maintenance guidance data corresponding to the vehicle fault query request. The pre-trained language model is a model obtained after model compression and knowledge distillation of the large language model. The maintenance guidance data includes at least one of the fault conclusion, maintenance suggestions and case references.

[0009] In one possible implementation of the first aspect, after returning maintenance guidance data to the user terminal, the method further includes: Obtain log data and lexical consumption data. Log data is used to represent the logs of maintenance guidance data generated by the pre-trained language model, and lexical consumption data is used to represent the number of lexical units consumed when the large language model processes fault query text. Based on log data and lexical consumption data, output consumption optimization information and / or consumption cost information corresponding to the maintenance guidance data.

[0010] In one possible implementation of the first aspect, based on log data and lexical consumption data, consumption optimization information or consumption cost information corresponding to the maintenance guidance data is output, including: Calculate the first lexical consumption of the pre-trained language model based on log data; Calculate the second lexical consumption of the large language model based on lexical consumption data; Detect whether the consumption of the first word element is greater than the consumption of the second word element; If the consumption of the first word element is detected to be greater than the consumption of the second word element, the consumption optimization information corresponding to the maintenance guidance data will be output. If the consumption of the first word element is less than or equal to the consumption of the second word element, the consumption cost information corresponding to the maintenance guidance data will be output.

[0011] In one possible implementation of the first aspect, after returning maintenance guidance data to the user terminal, the method further includes: Obtain user feedback data regarding the repair guidance data; Based on the feedback data, determine whether to update the vehicle candidate fault vector set.

[0012] Secondly, embodiments of this application provide a vehicle fault handling device configured on a server, the device comprising: The first acquisition module is used to respond to the vehicle fault query request from the user terminal, acquire the fault query text carried in the vehicle fault query request, and acquire the vehicle candidate fault vector set, wherein the vehicle candidate fault vector set includes multiple candidate fault vectors, which are pre-constructed based on vehicle fault codes and vehicle repair case information. The first determining module is used to determine the target fault vector that matches the fault query text based on the vehicle candidate fault vector set. The target fault vector is the candidate fault vector in the vehicle candidate fault vector set whose similarity with the fault query text meets the set conditions. The generation module is used to generate maintenance guidance data corresponding to vehicle fault query requests based on fault query text and target fault vector; The return module is used to return maintenance guidance data to the user terminal, which is also used to instruct the user to perform vehicle maintenance based on the maintenance guidance data.

[0013] Thirdly, embodiments of this application provide a server, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any of the first aspects.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any of the first aspects.

[0015] Fifthly, embodiments of this application provide a computer program product that, when run on a server, causes the server to execute any of the methods described in the first aspect above.

[0016] This application provides a vehicle fault handling method, apparatus, server, and program product. The method is applied to the server side and includes: responding to a vehicle fault query request from a user terminal, obtaining fault query text carried in the vehicle fault query request, and obtaining a vehicle candidate fault vector set, wherein the vehicle candidate fault vector set includes multiple candidate fault vectors, which are pre-constructed based on vehicle fault codes and vehicle repair case information; determining a target fault vector matching the fault query text based on the vehicle candidate fault vector set, wherein the target fault vector is a candidate fault vector in the vehicle candidate fault vector set whose similarity to the fault query text meets a set condition; generating repair guidance data corresponding to the vehicle fault query request based on the fault query text and the target fault vector; and returning the repair guidance data to the user terminal, wherein the user terminal is also used to instruct the user to repair the vehicle based on the repair guidance data. Using the above technical solution, the target fault vector that matches the fault query text is determined based on the obtained vehicle candidate fault vector set. The candidate fault vectors in the vehicle candidate fault vector set are pre-constructed based on vehicle fault codes and vehicle repair case information, which enables the generated repair guidance content to better adapt to the fault handling scenario of vehicle repair and improve the reliability and safety of users when making vehicle repair decisions. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic flowchart of a vehicle fault handling method provided in an embodiment of this application; Figure 2 This is a schematic flowchart of a vehicle fault handling method provided in another embodiment of this application; Figure 3 This is an overall flowchart of a vehicle fault handling method provided in one embodiment of this application; Figure 4 This is a structural block diagram of a vehicle fault handling device provided in one embodiment of this application; Figure 5 This is a schematic diagram of the structure of a server provided in one embodiment of this application. Detailed Implementation

[0019] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0020] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0021] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0023] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0025] It can be argued that existing vehicle fault diagnosis methods have significant limitations. On one hand, using general-purpose large-scale language models for fault analysis results in enormous computational resource consumption, particularly in token usage, due to the need for the model to call all parameters to process user queries. This not only increases the hardware costs and operational complexity of local server deployments but also leads to significant system response delays, making it difficult to meet the timeliness requirements of real-time fault handling and exhibiting poor scenario adaptability. On the other hand, solutions relying solely on structured knowledge bases cannot generate effective repair guidance when data coverage is insufficient. This results in users frequently encountering missing or blank outputs when using artificial intelligence (AI) functions, severely degrading the user experience. Furthermore, general-purpose large models lack specialized structured knowledge specific to the automotive diagnostics field. For example, their ability to accurately analyze fault codes is insufficient, and their accuracy in matching repair cases to specific scenarios is low, easily generating unprofessional or misleading content, thus affecting the reliability and safety of repair decisions. These problems collectively lead to the poor performance of existing vehicle fault handling methods in terms of efficiency, accuracy, and scenario adaptability, failing to effectively support rapid vehicle fault diagnosis and repair guidance.

[0026] Based on this, this application provides a vehicle fault handling method, which pre-builds a dedicated AI knowledge base for vehicle diagnosis, matches professional knowledge fragments through vector retrieval, and generates accurate answers by combining a lightweight fine-tuning model. At the same time, it introduces a token consumption statistics and dynamic knowledge base update mechanism to achieve vehicle diagnosis AI question-answering capabilities with low token consumption, high professional accuracy, and real-time response.

[0027] Figure 1 This is a schematic flowchart of a vehicle fault handling method provided in one embodiment of this application. It is intended as an example and not a limitation. This method can be applied to a server, such as... Figure 1 As shown, the method includes: S101. In response to the vehicle fault query request from the user, obtain the fault query text carried in the vehicle fault query request, and obtain the vehicle candidate fault vector set.

[0028] In this embodiment, the server can refer to a computer system that provides computing services, data storage, or applications in a network environment. It is responsible for receiving and processing vehicle fault query requests from the user terminal and generating corresponding repair guidance data. The user terminal can refer to a terminal device, application, or web page that interacts with the server. It is used to send vehicle fault query requests to the server, receive repair guidance data returned by the server, and then display and instruct the user to perform vehicle repairs.

[0029] A vehicle fault query request can be understood as a request to query information related to vehicle faults. This request usually includes fault query text entered by the user. The fault query text is natural language text used to describe the vehicle fault phenomenon or problem. This text is the basis for the server to perform fault analysis and matching.

[0030] The vehicle candidate fault vector set includes multiple candidate fault vectors, which are pre-constructed based on vehicle fault codes and vehicle repair case information. These vectors represent various possible vehicle faults and their related information for matching with fault query text. Vehicle fault codes are standardized codes generated by the vehicle's on-board diagnostics (OBD) system to indicate specific faults or anomalies in the vehicle system. Vehicle repair case information can refer to a dataset recording vehicle fault diagnosis, repair processes, solutions, and related experience. This case information provides rich context and practical experience for generating candidate fault vectors.

[0031] Specifically, the server can be configured to continuously monitor network connections from the user's end. Once a data packet is received, its header information is parsed to identify whether it is a vehicle fault query request. If the identification is successful, the fault description information entered by the user is extracted from the request body as the fault query text. Simultaneously, the server can load a pre-built set of candidate vehicle fault vectors from local storage or a remote database. For example, this set of candidate vehicle fault vectors can be stored in a file and loaded once at startup, or queried from the database on demand for each request.

[0032] In some embodiments, obtaining a vehicle candidate fault vector set includes: obtaining a vehicle fault code set and vehicle repair case information; performing structured processing on the fault codes in the vehicle fault code set and the vehicle repair cases in the vehicle repair case information to obtain candidate fault entries corresponding to each fault code, wherein the structured processing includes at least association processing and scene labeling processing, and each candidate fault entry corresponding to each fault code includes at least the fault code, fault name, root cause analysis, repair steps, compatible vehicle model, and scene label; performing vector transformation processing on each candidate fault entry corresponding to each fault code to obtain a candidate fault vector corresponding to each fault code; and determining the candidate fault vectors corresponding to all fault codes as the vehicle candidate fault vector set.

[0033] The vehicle fault code set typically refers to Diagnostic Trouble Codes (DTCs) defined by the vehicle manufacturer or industry standards to indicate specific anomalies in the vehicle system. Vehicle repair case information encompasses experiential data accumulated during actual repair processes, such as fault symptoms, diagnostic procedures, repair solutions, and replaced parts. This information can be obtained through batch import or real-time synchronization from vehicle diagnostic systems, On-Board Diagnostic Interface (OBD-II), vehicle manufacturer databases, or third-party repair data platforms. Additionally, vehicle repair case information can be obtained from repair work order systems, technician experience summaries, repair manuals, forum data, or extracted from unstructured text using natural language processing techniques.

[0034] This paper describes a method for structuring fault codes and repair cases from a vehicle fault code set and vehicle repair case information. The aim is to transform the raw, potentially unstructured fault code and repair case data into unified, standardized, and easily processed structured data, forming candidate fault entries containing multi-dimensional information. This facilitates subsequent vectorization and matching. The association processing aims to establish logical connections between fault codes and specific repair cases, ensuring that each fault code corresponds to relevant repair experience. For example, by matching fault code text, fault description, vehicle model, etc., fault codes can be associated with repair cases in a one-to-one or one-to-many manner. Scenario annotation processing adds contextual information to fault entries, making the fault description more specific and closer to actual application scenarios, helping to distinguish the manifestation and repair solutions of similar faults in different contexts. For example, this embodiment can directly generate structured automotive diagnostic knowledge entries by inputting the OBD-II fault code library, automotive repair case dataset, and diagnostic industry standard documents into a large model.

[0035] Finally, by performing vector transformation on the candidate fault entries corresponding to each fault code, a candidate fault vector for each fault code can be obtained. All candidate fault vectors corresponding to all fault codes are then used to determine the vehicle candidate fault vector set. This set can be stored in a vector database (such as Faiss or Milvus) or in memory for rapid similarity searching. Based on this, the constructed vehicle candidate fault vector set not only contains basic fault information but also incorporates rich repair experience and scenario context. This allows for more accurate and representative vector matching when responding to user requests for vehicle fault information, significantly improving the accuracy of target fault vector determination and the effectiveness of the final repair guidance data.

[0036] S102. Based on the vehicle candidate fault vector set, determine the target fault vector that matches the fault query text.

[0037] Here, the target fault vector is a candidate fault vector in the vehicle candidate fault vector set whose similarity to the fault query text meets a set condition. In other words, the target fault vector can be considered as one or more candidate fault vectors selected from the vehicle candidate fault vector set that have a high degree of matching with the fault query text, representing the vehicle faults most relevant to the user's query.

[0038] This embodiment does not limit the specific process of determining the target fault vector. In one implementation, the server can use keyword matching. Specifically, the server can extract keywords from the fault query text, then traverse each candidate fault vector in the vehicle candidate fault vector set, checking whether it contains these keywords. If the number of keywords contained in a candidate fault vector reaches a preset threshold, it is determined as the target fault vector. For example, if the user inputs "engine abnormal noise," the server extracts "engine" and "abnormal noise" as keywords, and then searches for candidate fault vectors containing these keywords.

[0039] S103. Based on the fault query text and the target fault vector, generate maintenance guidance data corresponding to the vehicle fault query request.

[0040] Repair guidance data can be generated by the server based on fault query text and target fault vectors, aiming to provide users with specific vehicle fault diagnosis and repair suggestions. This data may include information such as fault conclusions, repair steps, or case references.

[0041] This embodiment can generate corresponding maintenance guidance data based on the target fault vector determined in the above steps. The specific method of generating maintenance guidance data is not limited. For example, it can rely on a large language model to directly output the maintenance guidance data.

[0042] As a feasible implementation method, maintenance guidance data corresponding to a vehicle fault query request is generated based on the fault query text and the target fault vector. This includes: determining candidate fault entries associated with the target fault vector; inputting the candidate fault entries associated with the fault query text and the target fault vector into a pre-trained language model to obtain maintenance guidance data corresponding to the vehicle fault query request. The pre-trained language model is a model obtained by performing model compression and knowledge distillation on a large language model. The maintenance guidance data includes at least one of fault conclusions, maintenance suggestions, and case references.

[0043] The pre-trained language model can be understood as a lightweight question-answering generation model module. This embodiment can fine-tune the DistilBERT lightweight model for the automotive diagnostics domain, using vector retrieval and matching knowledge fragments as context to generate accurate answers that conform to automotive diagnostics professional standards, avoiding the full-scale use of general-purpose large models. Specifically, after determining the target fault vector, associated candidate fault entries (such as Top-N knowledge fragments) can be quickly retrieved from the database or storage medium. By inputting the user's question text and the Top-N knowledge fragments into the pre-trained language model, structured hierarchical answer content is obtained.

[0044] Based on this, by using a pre-trained language model to generate maintenance guidance data instead of directly using the original large language model which consumes a lot of computational resources, it is possible to maintain a deep understanding and generation capability of knowledge in the vehicle fault domain while significantly improving operational efficiency and response speed. It efficiently generates comprehensive, accurate and easy-to-understand maintenance guidance data, effectively solving the technical problem of how to transform discrete information into coherent and practical guidance, and greatly improving the level of intelligence in fault diagnosis and maintenance support.

[0045] S104. Return maintenance guidance data to the user terminal. The user terminal is also used to instruct the user to perform vehicle maintenance based on the maintenance guidance data.

[0046] This embodiment provides a vehicle fault handling method that determines the target fault vector that matches the fault query text based on the acquired vehicle candidate fault vector set. The candidate fault vectors in the vehicle candidate fault vector set are pre-constructed based on vehicle fault codes and vehicle repair case information, which enables the generated repair guidance content to better adapt to the vehicle repair fault handling scenario and improve the reliability and safety of users when making vehicle repair decisions.

[0047] In some embodiments, after returning maintenance guidance data to the user's device, the method further includes: Obtain log data and lexical consumption data. Log data is used to represent the logs of maintenance guidance data generated by the pre-trained language model, and lexical consumption data is used to represent the number of lexical units consumed when the large language model processes fault query text. Based on log data and lexical consumption data, output consumption optimization information and / or consumption cost information corresponding to the maintenance guidance data.

[0048] Log data refers to the information recorded by the pre-trained language model during the generation of maintenance guidance data. These records may include model inference time, memory usage, API call details, error messages, and input / output text length. For example, log data can be automatically recorded by the model inference engine, obtained by inserting timestamps and resource monitoring code before and after model calls, or collected and stored in real time by a dedicated monitoring service or platform.

[0049] Lexical consumption data refers to the number of lexical units consumed by a large language model when processing faulty query text, along with related information. It reflects the computational load and potential cost required for the model to process a specific input. For example, lexical consumption data can be directly returned by the large language model's API interface, or estimated by counting the number of lexical units after lexicalizing the input text.

[0050] In specific implementations, log data and lexical consumption data can be compared and analyzed to gain insights into the resource consumption performance of the pre-trained language model (i.e., the lightweight model) compared to the large language model (i.e., the general-purpose large model). This allows for the output of valuable decision support information. For example, the token consumption of the lightweight model can be compared with the token cost of the general-purpose large model's full token consumption. Based on different comparison results, consumption optimization information or consumption cost information can be generated. Consumption optimization information refers to suggestions or guidance based on data analysis results to improve model efficiency and reduce resource consumption, such as adjusting the number of Top-N matches or simplifying the length of knowledge fragments. Consumption cost information quantifies the economic cost incurred by the model's operation. For example, the direct cost of generating maintenance guidance data each time can be calculated based on the API call fee standard of the large language model and the actual lexical consumption.

[0051] For example, comparative calculations can be performed using a large model. For instance, lightweight model call logs and general large model token consumption benchmark data can be input into the large model to output a token consumption comparison report or knowledge base knowledge fragment simplification suggestions.

[0052] In some embodiments, based on log data and lexical consumption data, the consumption optimization information or consumption cost information corresponding to the maintenance guidance data is output, including: calculating the first lexical consumption corresponding to the pre-trained language model based on log data; calculating the second lexical consumption corresponding to the large language model based on lexical consumption data; detecting whether the first lexical consumption is greater than the second lexical consumption; if the first lexical consumption is detected to be greater than the second lexical consumption, the consumption optimization information corresponding to the maintenance guidance data is output; if the first lexical consumption is detected to be less than or equal to the second lexical consumption, the consumption cost information corresponding to the maintenance guidance data is output.

[0053] Specifically, if the consumption of the first lexical unit is detected to be greater than that of the second lexical unit, it indicates that the actual consumption of the pre-trained model is higher than that of the large language model. In this case, further optimization of the model structure or inference strategy is needed, and consumption optimization information corresponding to the maintenance guidance data can be output. Conversely, if the consumption of the first lexical unit is detected to be less than or equal to that of the second lexical unit, it indicates that the consumption of the pre-trained model has been significantly reduced. In this case, corresponding consumption cost information can be output, providing a quantitative economic basis for operational decisions. Based on this, comparative analysis can identify potential optimization space, effectively solving the problem of lacking effective evaluation and optimization of model resource consumption after generating maintenance guidance data, thus ensuring the economic efficiency and sustainability of the technical solution.

[0054] In some embodiments, after returning maintenance guidance data to the user's device, the method further includes: Obtain user feedback data regarding the repair guidance data; Based on the feedback data, determine whether to update the vehicle candidate fault vector set.

[0055] The acquisition of user feedback data regarding repair guidance refers to the server-side collection of user evaluations or related information about the repair guidance data after the user receives it and performs actual repair operations. This feedback data can include user satisfaction ratings, error correction feedback, confirmation of actual repair verification results (e.g., whether the fault is resolved), or user behavior data after following the guidance. For example, users can provide feedback by selecting "helpful" or "useless" buttons on the user interface, or by entering specific text descriptions to point out shortcomings in the guidance. Furthermore, the server can also indirectly obtain feedback data by analyzing user operation logs after receiving guidance, such as whether they resubmitted similar fault queries or contacted customer service.

[0056] Therefore, the server can evaluate the effectiveness and accuracy of the current vehicle candidate fault vector set based on the collected user feedback data, and decide whether to modify, supplement, or optimize the vector set accordingly. For example, when a large number of users report that a certain repair guide is inaccurate or cannot solve the problem, the server can determine that the corresponding candidate fault vector may have biases or missing information, thus triggering an update process. The update process may include reconstructing some or all of the candidate fault vectors, introducing new fault codes or repair case information, or adjusting the weights and relationships of existing vectors. Based on this, by automatically triggering knowledge base updates based on user interaction data and retraining the vector library, continuous optimization of question-answering accuracy is achieved, ensuring that the vehicle candidate fault vector set can continuously keep pace with actual vehicle fault conditions and repair practices, thereby continuously improving the accuracy and practicality of subsequently generated repair guide data.

[0057] Figure 2 This is a flowchart illustrating a vehicle fault handling method according to another embodiment of this application. In this embodiment, the determination of the target fault vector matching the fault query text based on the vehicle candidate fault vector set is further optimized as follows: The fault query text is transformed into a vector to obtain the fault query vector corresponding to the fault query text; the similarity between the fault query vector and each candidate fault vector in the vehicle candidate fault vector set is calculated to obtain the similarity corresponding to each candidate fault vector; and the candidate fault vector whose similarity meets the set conditions is determined as the target fault vector. For example... Figure 2 As shown, the method includes: S201. In response to the vehicle fault query request from the user, obtain the fault query text carried in the vehicle fault query request, and obtain the vehicle candidate fault vector set.

[0058] S202. Perform vector transformation on the fault query text to obtain the fault query vector corresponding to the fault query text.

[0059] The vector transformation processing of fault query text aims to convert unstructured natural language text into numerical vectors that are understandable and processable by machines. This transformation is the foundation for quantitative comparison between the text and pre-constructed candidate fault vectors. Specific vector transformation processing can be implemented using various techniques. For example, word embedding models (such as Word2Vec and GloVe) can be used to map each word in the text to a fixed-dimensional vector, which is then aggregated into a vector for the entire text through averaging or weighted averaging. Alternatively, more advanced pre-trained language models (such as BERT and GPT series) can be used to encode the text and extract its context-dependent semantic vector representation.

[0060] S203. Calculate the similarity between the fault query vector and each candidate fault vector in the vehicle candidate fault vector set to obtain the similarity corresponding to each candidate fault vector.

[0061] S204. Among all candidate fault vectors, the candidate fault vectors whose similarity meets the set conditions are determined as the target fault vectors.

[0062] This embodiment calculates the similarity between the fault query vector and each candidate fault vector, which quantifies the semantic association between the fault query text and each potential fault, and intuitively reflects the degree of matching between the two. The similarity calculation method can include, but is not limited to, cosine similarity, which measures the directional consistency by calculating the cosine of the angle between two vectors; or Euclidean distance, which measures the proximity of two vectors by calculating the straight-line distance in multidimensional space, with a smaller distance indicating higher similarity.

[0063] Finally, candidate fault vectors whose similarity meets a set condition are selected as target fault vectors. This condition can be a preset fixed threshold, such as selecting only candidate fault vectors with similarity higher than a certain value; or it can be a dynamically determined condition based on statistical methods, such as selecting the top N candidate fault vectors in terms of similarity, or selecting candidate fault vectors with significantly higher-than-average similarity. This process ensures that only candidate fault vectors highly relevant to the fault query text are further processed, thereby improving the accuracy of subsequent maintenance guidance.

[0064] S205. Based on the fault query text and the target fault vector, generate maintenance guidance data corresponding to the vehicle fault query request.

[0065] S206. Return maintenance guidance data to the user terminal.

[0066] This embodiment provides a vehicle fault handling method that filters out candidate fault vectors that meet the similarity criteria from all candidate fault vectors with calculated similarity. This ensures that the fault information most relevant to the user's query intent is accurately and efficiently identified from a massive amount of candidate fault information, laying a solid foundation for generating accurate maintenance guidance data in the future.

[0067] Figure 3This application provides an embodiment of a vehicle fault handling method, which first involves knowledge base construction and vector storage. This includes: inputting automotive diagnostic professional data such as vehicle fault code parsing rules, repair case library, and standardized diagnostic procedures into the server; performing structured processing, case scenario labeling, and entity alignment on fault codes and repair cases to generate domain-standardized knowledge entries. For example, 1500+ fault codes in the OBD-II fault code library can be associated and labeled with corresponding repair solutions and root cause analysis, and scenario labels (such as "engine cooling system" and "chassis abnormal noise") can be added to each fault code; and each standardized knowledge entry is converted into a 768-dimensional vector (which can be adjusted as needed) using a pre-trained automotive domain language model (such as AutoBERT-V) and stored in a vector database (such as Milvus).

[0068] Then, user query vector matching is performed, including: receiving user-initiated car diagnostic questions, converting the question text into query vectors, and performing cosine similarity retrieval on the query vectors in a vector database to obtain the top 3 knowledge fragment vectors with the highest similarity; and identifying standardized knowledge entries (i.e., Top-3 similar fragments) associated with the top 3 similar knowledge fragment vectors. For example, if a user asks "How to handle the P0128 fault code?", the server can convert the question text into a query vector and retrieve the top 3 relevant knowledge fragments (including the root cause of the P0128 fault code, repair solutions, and cases of the same vehicle model).

[0069] The lightweight DistilBERT model then generates the answer, including: The lightweight question-answering generation model inputs the question text and the Top-3 similar fragments into the lightweight DistilBERT model, and outputs a structured hierarchical answer, such as the first-level conclusion: Cooling system thermostat failure (fault code P0128 parsing result); the second-level suggestion: It is recommended to check the thermostat opening, and if it is stuck, replace it. The repair time is about 25 minutes; Reference case: 85% of P0128 faults in the same model are caused by thermostat sticking, and the fault elimination rate is 98% after replacement.

[0070] In addition, token consumption statistics optimization can be performed: the token consumption statistics module can calculate the token consumption for this question-and-answer session and check if the token consumption exceeds the threshold of 1000. If the token consumption exceeds the threshold of 1000, the optimization strategy mentioned above is triggered, such as outputting suggestions to adjust N in Top-N to 2, or to compress knowledge fragments. If the token consumption does not exceed the threshold of 1000, a token cost report is output. For example, in this question-and-answer session, the lightweight model used 850 tokens, compared to 2200 tokens used by the general large model, the consumption was reduced by 61.4%.

[0071] Furthermore, user satisfaction ratings or error correction feedback for structured, layered answers can be collected. The system uses this feedback to determine whether to trigger an update to the vector library. For example, it checks if the satisfaction rating is less than or equal to 2, if the cumulative error correction feedback exceeds 100, or if there are external data update instructions. If these conditions are met, the rule engine verifies the validity of the feedback. If verification is successful, it iteratively updates the standardized knowledge entries and the vector library, completing a self-optimization loop. If verification fails, the feedback is considered invalid, and the operation ends. For instance, if a user reports "the actual fault is a cooling pump malfunction, the thermostat is normal," the server, after verifying the validity of the feedback, can trigger a knowledge base update, adding "cooling pump malfunction" as a supplementary root cause for fault code P0128 and updating the corresponding vector in the vector library.

[0072] As described above, the vehicle fault handling method provided in this embodiment is designed with a structured knowledge base and hierarchical question-and-answer generation logic for automotive diagnostic scenarios. It adapts to specific needs such as fault analysis and repair case matching, significantly improving the accuracy of professional diagnosis. Specifically, it proposes a combined architecture of "domain knowledge base vector retrieval + lightweight model generation" through constraints of a dedicated automotive diagnostic knowledge base, replacing the full-scale call mode of the general large model. This solves the pain points of the general large model, such as "unprofessional answers and high error rate", and significantly improves the accuracy of professional diagnosis. For example, the answer accuracy of the vehicle fault handling method in this embodiment reaches 93.2%, which is 14.7 percentage points higher than that of the general large model (78.5%). It can accurately match the answers of different vehicle models and different system faults with repair cases of the same vehicle model, and the root cause judgment accuracy reaches more than 98%, enhancing the scenario adaptability of the method.

[0073] Secondly, the vehicle fault handling method provided in this embodiment can achieve dual optimization of token cost and response efficiency. Specifically, the average token consumption of this solution is 850, which is 61.4% lower than that of the general large model (2200). Based on the current large model call price, it can save about 600 yuan per 10,000 questions and answers, which greatly reduces the token cost. The lightweight model has an inference speed of 85ms / time, which is 5.3 times faster than that of the general large model (450ms). It can adapt to low-latency demand scenarios such as vehicle terminals and maintenance sites, and improve the real-time response capability of the system.

[0074] Furthermore, the vehicle fault handling method provided in this embodiment has strong self-optimization and scalability, continuously reducing calling costs and improving answer accuracy. For example, it can trigger the autonomous iteration of the knowledge base and model through user feedback, achieving a 1%-2% monthly improvement in answer accuracy without manual intervention. It can support the connection to external data such as OEM new model repair manuals and industry standard updates, and the knowledge base can be dynamically expanded to 500,000+ entries, adapting to the diagnostic needs of future new energy vehicles and intelligent connected vehicles.

[0075] Finally, the vehicle fault handling method provided in this embodiment has outstanding compliance and applicability. The knowledge base integrates industry standards such as GB / T 32960-2016, and the answer content meets the compliance requirements of automobile repair and complies with automobile diagnostic industry standards. Furthermore, the lightweight model has a memory footprint of ≤1.2GB and can be deployed on edge hardware such as on-board diagnostic terminals and portable repair equipment. It is adaptable to edge deployment and does not need to rely on high computing power support from the cloud.

[0076] In summary, the vehicle fault handling method provided in this embodiment constructs a dedicated AI knowledge base for vehicle diagnosis, matches professional knowledge fragments based on vector retrieval, and generates accurate answers by combining a lightweight fine-tuning model. At the same time, by introducing token consumption statistics and a dynamic knowledge base update mechanism, it achieves vehicle diagnosis AI question-answering capabilities with low token consumption, high professional accuracy, and real-time response.

[0077] Corresponding to the vehicle fault handling method in the above embodiments, Figure 4 This is a structural block diagram of a vehicle fault handling device provided in one embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0078] Reference Figure 4 The device includes: The first acquisition module 301 is used to respond to the vehicle fault query request from the user terminal, acquire the fault query text carried in the vehicle fault query request, and acquire the vehicle candidate fault vector set, wherein the vehicle candidate fault vector set includes multiple candidate fault vectors, and the candidate fault vectors are pre-constructed based on vehicle fault codes and vehicle repair case information. The first determining module 302 is used to determine the target fault vector that matches the fault query text based on the vehicle candidate fault vector set. The target fault vector is a candidate fault vector in the vehicle candidate fault vector set whose similarity with the fault query text meets the set conditions. The generation module 303 is used to generate maintenance guidance data corresponding to the vehicle fault query request based on the fault query text and the target fault vector. The return module 304 is used to return maintenance guidance data to the user terminal, whereby the user terminal is also used to instruct the user to perform maintenance on the vehicle based on the maintenance guidance data.

[0079] This embodiment provides a vehicle fault handling device. A first acquisition module responds to a user's vehicle fault query request by acquiring the fault query text carried in the request and a set of candidate fault vectors, wherein the set includes multiple candidate fault vectors pre-constructed based on vehicle fault codes and vehicle repair case information. A first determination module determines a target fault vector matching the fault query text based on the set of candidate fault vectors. The target fault vector is a candidate fault vector in the set whose similarity to the fault query text meets a set condition. A generation module generates repair guidance data corresponding to the vehicle fault query request based on the fault query text and the target fault vector. A return module returns the repair guidance data to the user, whereby the user is also instructed to perform vehicle repairs based on the repair guidance data. Using this device, the target fault vector that matches the fault query text is determined based on the acquired vehicle candidate fault vector set. The candidate fault vectors in the vehicle candidate fault vector set are pre-constructed based on vehicle fault codes and vehicle repair case information, which enables the generated repair guidance content to better adapt to the fault handling scenario of vehicle repair and improve the reliability and safety of users when making vehicle repair decisions.

[0080] Optionally, the first determining module is specifically used for: Perform vector transformation on the fault query text to obtain the fault query vector corresponding to the fault query text; The similarity between the fault query vector and each candidate fault vector in the vehicle candidate fault vector set is calculated to obtain the similarity corresponding to each candidate fault vector. Among all candidate fault vectors, the candidate fault vectors whose similarity meets the set conditions are determined as the target fault vectors.

[0081] Optionally, the first acquisition module is specifically used for: Obtain vehicle fault code collections and vehicle repair case information; The fault codes in the vehicle fault code set and the vehicle repair cases in the vehicle repair case information are structured to obtain candidate fault entries corresponding to each fault code. The structured processing includes at least association processing and scenario labeling processing. Each candidate fault entry corresponding to each fault code includes at least the fault code, fault name, root cause analysis, repair steps, applicable vehicle model and scenario label. Perform vector transformation on the candidate fault entries corresponding to each fault code to obtain the candidate fault vector corresponding to each fault code; The candidate fault vectors corresponding to all fault codes are determined as the vehicle candidate fault vector set.

[0082] Optionally, the generation module is specifically used for: Identify candidate fault entries associated with the target fault vector; The candidate fault entries associated with the fault query text and the target fault vector are input into the pre-trained language model to obtain the maintenance guidance data corresponding to the vehicle fault query request. The pre-trained language model is a model obtained after model compression and knowledge distillation of the large language model. The maintenance guidance data includes at least one of the fault conclusion, maintenance suggestions and case references.

[0083] Optionally, the vehicle fault handling device provided in this embodiment further includes: The second acquisition module is used to acquire log data and lexical consumption data after returning maintenance guidance data to the user. The log data is used to represent the log of the maintenance guidance data generated by the pre-trained language model, and the lexical consumption data is used to represent the number of lexical units consumed by the large language model when processing the fault query text. The output module is used to output consumption optimization information and / or consumption cost information corresponding to the maintenance guidance data based on log data and lexical consumption data.

[0084] Optionally, the output module is specifically used for: Calculate the first lexical consumption of the pre-trained language model based on log data; Calculate the second lexical consumption of the large language model based on lexical consumption data; Detect whether the consumption of the first word element is greater than the consumption of the second word element; If the consumption of the first word element is detected to be greater than the consumption of the second word element, the consumption optimization information corresponding to the maintenance guidance data will be output. If the consumption of the first word element is less than or equal to the consumption of the second word element, the consumption cost information corresponding to the maintenance guidance data will be output.

[0085] Optionally, the vehicle fault handling device provided in this embodiment further includes: The third acquisition module is used to acquire feedback data from the user terminal regarding the maintenance guidance data after the maintenance guidance data is returned to the user terminal. The second determining module is used to determine whether to update the vehicle candidate fault vector set based on the feedback data.

[0086] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0087] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0088] Figure 5 This is a schematic diagram of the structure of a server provided in one embodiment of this application, as shown below. Figure 5 As shown, the server 500 in this embodiment includes: at least one processor 502 ( Figure 5 (Only one is shown in the diagram) a processor, a memory 501, and a computer program 503 stored in the memory 501 and executable on at least one processor 502. When the processor 502 executes the computer program 503, it implements the steps in the control method embodiments of any of the above-described application programs.

[0089] Server 500 can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. This server may include, but is not limited to, a processor 502 and a memory 501. Those skilled in the art will understand that... Figure 5 This is merely an example of server 500 and does not constitute a limitation on server 500. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0090] The processor 502 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0091] In some embodiments, memory 501 may be an internal storage unit of server 500, such as a hard disk or memory of server 500. In other embodiments, memory 501 may be an external storage device of server 500, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD) card, flash card, etc., equipped on server 500. Furthermore, memory 501 may include both internal and external storage units of server 500. Memory 501 is used to store operating systems, applications, boot loaders, data, and other programs, such as program code for computer programs. Memory 501 can also be used to temporarily store data that has been output or will be output.

[0092] This application also provides a computer-readable storage medium storing a computer program, which, when executed by processor 502, can implement the steps in the above-described method embodiments.

[0093] This application provides a computer program product that, when run on a server, enables the server to implement the steps described in the various method embodiments above.

[0094] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by the processor 502, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium can include at least: any entity or device capable of carrying computer program code to a device / server, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0095] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

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

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

[0099] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A vehicle fault handling method, characterized in that, Applied to the server side, the method includes: In response to a vehicle fault query request from a user, the system obtains the fault query text carried in the vehicle fault query request and obtains a set of candidate vehicle fault vectors, wherein the set of candidate vehicle fault vectors includes multiple candidate fault vectors, which are pre-constructed based on vehicle fault codes and vehicle repair case information. Based on the vehicle candidate fault vector set, a target fault vector that matches the fault query text is determined. The target fault vector is a candidate fault vector in the vehicle candidate fault vector set whose similarity to the fault query text meets a set condition. Based on the fault query text and the target fault vector, maintenance guidance data corresponding to the vehicle fault query request is generated; The maintenance guidance data is returned to the user terminal, which is also used to instruct the user to perform vehicle maintenance based on the maintenance guidance data.

2. The vehicle fault handling method as described in claim 1, characterized in that, The step of determining the target fault vector matching the fault query text based on the vehicle candidate fault vector set includes: The fault query text is transformed into a vector to obtain the fault query vector corresponding to the fault query text. The similarity between the fault query vector and each of the candidate fault vectors in the vehicle candidate fault vector set is calculated to obtain the similarity corresponding to each candidate fault vector. The candidate fault vectors whose similarity meets the set conditions are determined as the target fault vectors.

3. The vehicle fault handling method as described in claim 1, characterized in that, The process of obtaining the vehicle candidate fault vector set includes: Obtain vehicle fault code collections and vehicle repair case information; The fault codes in the vehicle fault code set and the vehicle repair cases in the vehicle repair case information are subjected to structured processing to obtain candidate fault entries corresponding to each fault code. The structured processing includes at least association processing and scene labeling processing. Each candidate fault entry corresponding to each fault code includes at least the fault code, fault name, root cause analysis, repair steps, compatible vehicle model and scene label. Perform vector transformation processing on the candidate fault entries corresponding to each fault code to obtain the candidate fault vector corresponding to each fault code; The candidate fault vectors corresponding to all fault codes are determined as the vehicle candidate fault vector set.

4. The vehicle fault handling method as described in claim 3, characterized in that, The step of generating repair guidance data corresponding to the vehicle fault query request based on the fault query text and the target fault vector includes: Identify candidate fault entries associated with the target fault vector; The candidate fault entries associated with the fault query text and the target fault vector are input into a pre-trained language model to obtain the maintenance guidance data corresponding to the vehicle fault query request. The pre-trained language model is a model obtained by performing model compression and knowledge distillation on a large language model. The maintenance guidance data includes at least one of fault conclusions, maintenance suggestions, and case references.

5. The vehicle fault handling method as described in claim 4, characterized in that, After returning the maintenance guidance data to the user terminal, the method further includes: Obtain log data and lexical consumption data. The log data is used to characterize the log of the maintenance guidance data generated by the pre-trained language model, and the lexical consumption data is used to characterize the number of lexical units consumed by the large language model when processing the fault query text. Based on the log data and the term consumption data, output the consumption optimization information and / or consumption cost information corresponding to the maintenance guidance data.

6. The vehicle fault handling method as described in claim 5, characterized in that, Based on the log data and the lexical consumption data, output the consumption optimization information or consumption cost information corresponding to the maintenance guidance data, including: Calculate the first lexical consumption of the pre-trained language model based on the log data; Calculate the second lexical consumption amount corresponding to the large language model based on the lexical consumption data; Detect whether the consumption of the first word element is greater than the consumption of the second word element; If the consumption of the first word element is detected to be greater than the consumption of the second word element, then the consumption optimization information corresponding to the maintenance guidance data is output. If the consumption of the first word element is detected to be less than or equal to the consumption of the second word element, the consumption cost information corresponding to the maintenance guidance data is output.

7. The vehicle fault handling method according to any one of claims 1-6, characterized in that, After returning the maintenance guidance data to the user terminal, the method further includes: Obtain feedback data from the user terminal regarding the maintenance guidance data; Based on the feedback data, determine whether to update the vehicle candidate fault vector set.

8. A vehicle fault handling device, characterized in that, Configured on the server side, the device includes: The first acquisition module is used to respond to a vehicle fault query request from a user terminal, acquire the fault query text carried in the vehicle fault query request, and acquire a vehicle candidate fault vector set, wherein the vehicle candidate fault vector set includes multiple candidate fault vectors, and the candidate fault vectors are pre-constructed based on vehicle fault codes and vehicle repair case information. The first determining module is used to determine a target fault vector that matches the fault query text based on the vehicle candidate fault vector set. The target fault vector is a candidate fault vector in the vehicle candidate fault vector set whose similarity to the fault query text meets a set condition. The generation module is used to generate maintenance guidance data corresponding to the vehicle fault query request based on the fault query text and the target fault vector. The return module is used to return the maintenance guidance data to the user terminal, wherein the user terminal is also used to instruct the user to perform maintenance on the vehicle based on the maintenance guidance data.

9. A server, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it causes the server to implement the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the server, it causes the server to perform the method as described in any one of claims 1-7.

Images