Knowledge base updating method and device, equipment and storage medium

Abstract

The invention discloses a knowledge base updating method and device, equipment and a storage medium, and relates to the technical field of data processing, and the method comprises the steps: receiving a query request which is a request reported by a fault vehicle and contains fault data corresponding to the fault vehicle, and / or a request reported by the fault vehicle and containing fault data corresponding to the fault vehicle; the query request is a request which is sent by a client and contains an identifier of a queried vehicle; when it is determined that the query request triggers updating of the vehicle fault knowledge base, determining a target fault tag corresponding to the query request and a corresponding target solution; and updating the vehicle fault knowledge base based on the target fault label and the target solution. Therefore, the vehicle fault knowledge base is updated in real time through two dimensions of vehicle active triggering and client passive triggering, the updating timeliness of the vehicle fault knowledge base is improved, and meanwhile, the vehicle fault knowledge base can cover the vehicle faults more comprehensively.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to methods, apparatus, devices and storage media for updating knowledge bases. Background Technology

[0002] The fault scenarios of intelligent connected vehicles are becoming increasingly diverse, sophisticated, and dynamic due to model iterations, software version updates, and vehicle system upgrades. To quickly respond to vehicle fault resolution needs, a vehicle fault knowledge base can be used as a fault matching solution.

[0003] However, updating the knowledge base mostly relies on engineers manually entering new faults and solutions, or on periodic batch updates of the knowledge base, which results in low update efficiency and affects the timeliness and accuracy of vehicle fault handling. Summary of the Invention

[0004] The main objective of this application is to provide a knowledge base updating method, apparatus, device, and storage medium, aiming to solve the technical problem of low update timeliness of vehicle fault knowledge base, which affects the timeliness and accuracy of vehicle fault handling.

[0005] To achieve the above objectives, this application proposes a knowledge base updating method, which includes: Receive a query request, wherein the query request is a request reported by a faulty vehicle and contains fault data corresponding to the faulty vehicle, and / or the query request is a request sent by a client and contains the identifier of the vehicle being queried. If it is determined that the query request triggers an update of the vehicle fault knowledge base, the target fault tag and the corresponding target solution for the query request shall be determined. The vehicle fault knowledge base is updated based on the target fault label and the target solution.

[0006] In some embodiments, the query request is a request reported by a faulty vehicle and contains fault data corresponding to the faulty vehicle. Determining that the query request triggers an update to the vehicle fault knowledge base includes: Based on the fault data corresponding to the faulty vehicle, determine the first fault label corresponding to the faulty vehicle; If the first fault tag does not exist in the vehicle fault knowledge base, determine the historical fault tag corresponding to the historical fault vehicle that reported the query request within a preset time period before the current time. Determine the total number of historical fault tags that are identical to the first fault tag; If the total number exceeds the quantity threshold, the query request is determined to trigger an update of the vehicle fault knowledge base.

[0007] In some embodiments, the query request is a request sent by a client that includes the identifier of the vehicle being queried, and determining that the query request triggers an update to the vehicle fault knowledge base includes: Based on the identifier of the queried vehicle, obtain the real-time data corresponding to the queried vehicle; Based on the real-time data, determine the second fault label corresponding to the queried vehicle; If the second fault tag does not exist in the vehicle fault knowledge base, it is determined that the query request triggers an update of the vehicle fault knowledge base.

[0008] In some embodiments, after updating the vehicle fault knowledge base based on the target fault label and the target solution, the method further includes: Determine the target score for each solution in the updated vehicle fault knowledge base; If the target score for any solution is less than the preset score, then that solution is updated.

[0009] In some embodiments, determining the target score for each solution in the updated vehicle fault knowledge base includes: Determine the historical retrieval count corresponding to the vehicle fault tag for each solution, and the number of times each solution successfully resolves the fault; The ratio of the number of successful searches to the number of historical searches for each solution is used to determine the matching success rate for each solution. The target score for each solution is determined based on at least one of the following: the matching success rate, the engineer feedback score, and the user feedback score.

[0010] In some embodiments, after updating the vehicle fault knowledge base based on the target fault label and the target solution, the method further includes: Determine the historical retrieval count for each vehicle fault tag in the updated vehicle fault knowledge base; Based on the historical search count, the search priority corresponding to each vehicle fault tag is determined, wherein the historical search count is positively correlated with the search priority.

[0011] In some embodiments, before updating the vehicle fault knowledge base based on the target fault label and the target solution, the method further includes: The vehicle after-sales data is structured to determine the fault solution, the corresponding vehicle model, vehicle system type, software version, and fault type. The vehicle model, vehicle system type, software version, and fault type are determined as the vehicle fault labels corresponding to the fault solution. The fault solutions and vehicle fault tags are stored in the vehicle fault knowledge base.

[0012] Furthermore, to achieve the above objectives, this application also proposes a knowledge base updating device, which includes: A receiving module is used to receive a query request, wherein the query request is a request reported by a faulty vehicle and contains fault data corresponding to the faulty vehicle, and / or the query request is a request sent by a client and contains the identifier of the queried vehicle. The determination module is used to determine the target fault tag and the corresponding target solution corresponding to the query request when it is determined that the query request triggers an update of the vehicle fault knowledge base; The update module is used to update the vehicle fault knowledge base based on the target fault label and the target solution.

[0013] In some embodiments, the determining module is configured to: Based on the fault data corresponding to the faulty vehicle, determine the first fault label corresponding to the faulty vehicle; If the first fault tag does not exist in the vehicle fault knowledge base, determine the historical fault tag corresponding to the historical fault vehicle that reported the query request within a preset time period before the current time. Determine the total number of historical fault tags that are identical to the first fault tag; If the total number exceeds the quantity threshold, the query request is determined to trigger an update of the vehicle fault knowledge base.

[0014] In some embodiments, the determining module is configured to: Based on the identifier of the queried vehicle, obtain the real-time data corresponding to the queried vehicle; Based on the real-time data, determine the second fault label corresponding to the queried vehicle; If the second fault tag does not exist in the vehicle fault knowledge base, it is determined that the query request triggers an update of the vehicle fault knowledge base.

[0015] In some embodiments, a first processing module is further included, configured to: Determine the target score for each solution in the updated vehicle fault knowledge base; If the target score for any solution is less than the preset score, then that solution is updated.

[0016] In some embodiments, the first processing module is configured to: Determine the historical retrieval count corresponding to the vehicle fault tag for each solution, and the number of times each solution successfully resolves the fault; The ratio of the number of successful searches to the number of historical searches for each solution is used to determine the matching success rate for each solution. The target score for each solution is determined based on at least one of the following: the matching success rate, the engineer feedback score, and the user feedback score.

[0017] In some embodiments, a second processing module is further included, for: Determine the historical retrieval count for each vehicle fault tag in the updated vehicle fault knowledge base; Based on the historical search count, the search priority corresponding to each vehicle fault tag is determined, wherein the historical search count is positively correlated with the search priority.

[0018] In some embodiments, a generation module is further included, for: The vehicle after-sales data is structured to determine the fault solution, the corresponding vehicle model, vehicle system type, software version, and fault type. The vehicle model, vehicle system type, software version, and fault type are determined as the vehicle fault labels corresponding to the fault solution. The fault solutions and vehicle fault tags are stored in the vehicle fault knowledge base.

[0019] In addition, to achieve the above objectives, this application also proposes a knowledge base updating device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the knowledge base updating method as described above.

[0020] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the knowledge base update method described above.

[0021] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the knowledge base update method described above.

[0022] One or more technical solutions proposed in this application have at least the following technical effects: The application process, by receiving query requests containing fault data reported by faulty vehicles, can capture the vehicle's native fault needs in real time. When a vehicle encounters a new fault not yet recorded in the knowledge base, an update process can be directly triggered. Furthermore, by receiving query requests from clients containing the identifier of the queried vehicle, the vehicle fault knowledge base can be updated, covering fault scenarios not actively reported by the vehicle. Thus, by updating the vehicle fault knowledge base in real time through both vehicle-initiated and client-initiated mechanisms, the timeliness of updates is improved, and the knowledge base can more comprehensively cover vehicle faults. Attached Figure Description

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

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

[0025] Figure 1 This is a flowchart illustrating an embodiment of the knowledge base update method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the knowledge base update method of this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the knowledge base update method of this application; Figure 4 This is a schematic diagram of the module structure of the knowledge base updating device according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the knowledge base update method in this application embodiment.

[0026] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0027] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0028] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0029] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or knowledge base update device capable of performing the above functions. The following description uses a knowledge base update device as an example to illustrate this embodiment and the subsequent embodiments.

[0030] Based on this, embodiments of this application provide a knowledge base updating method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the knowledge base update method of this application. Figure 1 As shown, the knowledge base update method includes steps S10 to S30: Step S10: Receive a query request, wherein the query request is a request reported by the faulty vehicle and contains fault data corresponding to the faulty vehicle, and / or the query request is a request sent by the client and contains the identifier of the vehicle being queried.

[0031] The fault data corresponding to the faulty vehicle may include vehicle model, vehicle system type, software version, fault type, vehicle identification, sensor status, network connection type, and most recent upgrade time. This application does not limit this.

[0032] Among them, the vehicle system type can be the vehicle intelligent driving system type.

[0033] The vehicle identifier can be a Vehicle Identification Number (VIN). In some embodiments, fault data can be received using the Kafka streaming framework and parsed into a JSON format of "data type-vehicle identifier-value-timestamp". The value contains all fault data, and the timestamp is the timestamp when the fault data was received.

[0034] In some embodiments, after-sales engineers or users send a query request containing the identifier of the vehicle being queried via a client interface such as a computer or mobile phone. The identifier of the vehicle being queried can be the VIN code of the vehicle being queried. The vehicle being queried can be a vehicle that the after-sales engineer or user knows has experienced a malfunction.

[0035] Step S20: If it is determined that the query request triggers an update of the vehicle fault knowledge base, determine the target fault tag and the corresponding target solution for the query request.

[0036] In one possible implementation, if the query request is a request reported by a faulty vehicle and contains fault data corresponding to the faulty vehicle, step S20 includes steps A21 to A24: Step A21: Determine the first fault label corresponding to the faulty vehicle based on the fault data corresponding to the faulty vehicle.

[0037] The first fault label includes the vehicle model, vehicle system type, software version, and fault type corresponding to the faulty vehicle. In some embodiments, entity extraction can be performed on the fault data to obtain the vehicle model, vehicle system type, software version, and fault type corresponding to the faulty vehicle.

[0038] Step A22: If the first fault tag does not exist in the vehicle fault knowledge base, determine the historical fault tags corresponding to the historical fault vehicles that were reported in the query request within the preset time period before the current time.

[0039] It should be noted that if the first fault tag exists in the knowledge base, it means that this type of fault has been included in the knowledge base, and the current query request does not need to trigger a knowledge base update; if the first fault tag does not exist in the knowledge base, it means that the fault may be a new type of fault, and it is necessary to further determine whether the fault is a high-frequency fault, so as to avoid invalid updates to the knowledge base due to the special faults of individual vehicles.

[0040] The preset time period can be flexibly set according to the actual application scenario. For example, it can be set to 1 day or 1 month. The setting basis mainly includes the frequency of vehicle failures and the knowledge base update cycle requirements.

[0041] Among them, the historical fault label is the fault label corresponding to the vehicle with historical faults, and its generation rule is the same as that of the first fault label.

[0042] In some embodiments, the hash value corresponding to the first fault label can be calculated, and the hash value corresponding to the first fault label can be matched with the hash value corresponding to each vehicle fault label in the vehicle fault knowledge base to determine that the first fault label does not exist in the vehicle fault knowledge base.

[0043] Step A23: Determine the total number of historical fault tags that are the same as the first fault tag.

[0044] The total number reflects the number of vehicles with this type of potential new fault within a preset time period, i.e., the prevalence of the fault.

[0045] Step A24: If the total number is greater than the number threshold, determine that the query request triggers an update to the vehicle fault knowledge base.

[0046] The quantity threshold is the critical value for determining whether a new fault needs to be included in the knowledge base. Its setting can be based on factors such as vehicle ownership, fault diagnosis needs, and knowledge base maintenance costs. For example, for models with a large number of vehicles in use, the quantity threshold can be set higher to avoid excessive redundancy in the knowledge base; for fault types with a significant impact, the quantity threshold can be set lower to facilitate rapid inclusion and solution provision.

[0047] It should be noted that if the total number exceeds the threshold, it indicates that the new type of fault has become quite common and needs to be included in the vehicle fault knowledge base. Therefore, the current query request will trigger an update to the vehicle fault knowledge base. If the total number is less than or equal to the threshold, it indicates that the fault is still a specific fault of individual vehicles and does not need to be included in the knowledge base at this time. Therefore, no update will be triggered.

[0048] In some embodiments, after determining that a query request triggers an update to the vehicle fault knowledge base, the first fault label can be used as the target fault label.

[0049] In one possible implementation, the first fault label can be sent to an expert terminal, where a professional engineer can formulate a corresponding target solution based on the first fault label. In another possible implementation, solutions corresponding to fault labels similar to the first fault label can be retrieved from a knowledge base or open-source data, and then adjusted and optimized based on the current fault data to generate the target solution.

[0050] The above implementation method, in response to query requests for fault data reported by faulty vehicles, accurately processes and tags the fault data, and combines statistical analysis and quantity threshold judgment of historical fault tags within a preset time period to achieve accurate screening of the prevalence of new faults. This ensures that only faults with a certain degree of prevalence trigger knowledge base updates, avoiding invalid updates and redundant storage caused by individual special faults, while also ensuring the timely inclusion of new common faults.

[0051] In one possible implementation, if the query request is sent by the client and contains the identifier of the vehicle being queried, step S20 includes steps B21 to B23: Step B21: Based on the identifier of the queried vehicle, obtain the real-time data corresponding to the queried vehicle.

[0052] In some embodiments, after receiving a query request from the client containing the identifier of the vehicle to be queried, the identifier of the vehicle to be queried is first verified to determine whether the identifier is valid (e.g., whether there is corresponding vehicle information, whether it is the identifier of a deregistered vehicle, etc.). If the identifier is invalid, an error message is returned to the client.

[0053] In some embodiments, based on the identifier of the queried vehicle, a standardized API adaptation layer is used to connect to the vehicle manufacturer's cloud platform to obtain real-time data of the queried vehicle. This real-time data may include the vehicle model, vehicle system type, software version, fault type, vehicle identifier, sensor status, network connection type, and most recent upgrade time.

[0054] Step B22: Based on real-time data, determine the second fault label corresponding to the queried vehicle.

[0055] The second fault label includes the vehicle model, vehicle system type, software version, and fault type corresponding to the queried vehicle. In some embodiments, entity extraction can be performed on real-time data to obtain the vehicle model, vehicle system type, software version, and fault type corresponding to the queried vehicle.

[0056] Step B23: If the second fault tag does not exist in the vehicle fault knowledge base, determine that the query request triggers an update of the vehicle fault knowledge base.

[0057] It should be noted that if the first fault tag exists in the knowledge base, it means that this type of fault has been included in the knowledge base, and the current query request does not need to trigger a knowledge base update; if the first fault tag does not exist in the knowledge base, it means that the fault may be a new fault, triggering an update to the vehicle fault knowledge base.

[0058] Once the update is triggered, the second fault label will be used as the target fault label.

[0059] In one possible implementation, the second fault label can be sent to an expert terminal, where a professional engineer can formulate a corresponding target solution based on the second fault label. In another possible implementation, solutions corresponding to fault labels similar to the second fault label can be retrieved from a knowledge base or open-source data, and then adjusted and optimized based on the current fault data to generate the target solution.

[0060] In this implementation, for a client sending a query request containing the identifier of the vehicle being queried, real-time data is obtained based on the identifier of the vehicle being queried. A second fault tag is generated based on the real-time data and directly compared with the knowledge base to determine whether an update is triggered. The logic is simple and efficient, and it can quickly capture new faults discovered during the client query process and include them in the knowledge base. This supplements the update triggering scenarios beyond the proactive reporting of faulty vehicles, further improving the comprehensiveness and timeliness of knowledge base updates. At the same time, it meets the needs of maintenance personnel, vehicle owners and other users to drive the improvement of the knowledge base through client queries.

[0061] Step S30: Update the vehicle fault knowledge base based on the target fault labels and target solutions.

[0062] Specifically, the target fault labels and target solutions are associated and stored in the vehicle fault knowledge base.

[0063] In this embodiment, by receiving query requests containing fault data reported by faulty vehicles, the system can capture the vehicle's native fault needs in real time. When a vehicle encounters a new fault not yet recorded in the knowledge base, the update process can be directly triggered. Furthermore, by receiving query requests from clients containing the identifier of the queried vehicle, the system can trigger updates to the vehicle fault knowledge base, covering fault scenarios not actively reported by the vehicle. Therefore, by updating the vehicle fault knowledge base in real time through both vehicle-initiated and client-initiated methods, the system improves the timeliness of updates and allows for more comprehensive coverage of vehicle faults.

[0064] In some embodiments, before updating the vehicle fault knowledge base based on the target fault label and the target solution, a vehicle fault knowledge base may be pre-generated. The steps for generating the vehicle fault knowledge base include steps S31 to S33: Step S31: Perform structured processing on the vehicle after-sales data to determine the fault solution, the vehicle model corresponding to the fault solution, the vehicle system type, the software version and the fault type. In some embodiments, vehicle after-sales data may include structured data, semi-structured data, and unstructured data.

[0065] The structured data may include intelligent driving system parameter tables (such as sensor calibration parameters) and fault code-solution mapping tables (such as "P1008 Radar Communication Interruption - Fault Solution") in the automaker's R&D database.

[0066] Semi-structured data may include intelligent driving software update logs (including new features / known issues in the version) and standard procedures for parts replacement (a mix of tables and text, such as "calibration steps after LiDAR replacement").

[0067] Unstructured data may include intelligent driving maintenance manuals (e.g., PDF format, including operation diagrams) and after-sales fault handling cases (e.g., text format, including engineer operation records).

[0068] In some embodiments, a pre-trained bidirectional encoder representation of a Transformer model (BERT) adapted to intelligent driving terminology can be used to extract entities (such as millimeter-wave radar, V2.5 version, navigation lag, etc.) and entity relationships (such as "clear cache - solve navigation lag", "calibrate - eliminate radar faults", etc.) from unstructured documents to obtain entities such as vehicle model, vehicle system type, software version and fault type.

[0069] In some embodiments, fault solutions in vehicle after-sales data can be converted into a "operation node-precautions-verification standard" triple, and the fault solutions can be stored in the form of triples. For example, the operation node is restarting the vehicle system; the precaution is that version V2.5 requires exiting the intelligent driving mode first; and the verification standard is that the vehicle system reconnects to the radar signal.

[0070] Finally, a one-to-one mapping relationship can be established between the vehicle model, vehicle system type, software version, and fault type and the fault solution.

[0071] Step S32: Determine the vehicle model, vehicle system type, software version, and fault type as the vehicle fault label corresponding to the fault solution.

[0072] In some embodiments, after a vehicle fault label is generated, it can be uniquely identified by a hash algorithm to facilitate rapid comparison later.

[0073] Step S33: Store the fault solution and vehicle fault label in the vehicle fault knowledge base.

[0074] In some embodiments, a hierarchical navigable small world (HNSW) algorithm can be used to construct a vector index, associate fault solutions and vehicle fault labels with the original vehicle after-sales data source (such as repair manual page numbers), and store the fault solutions, vehicle fault labels, and data sources together in the vector database.

[0075] Therefore, when building a vehicle fault knowledge base, a unique vehicle fault tag is generated for each fault solution based on the vehicle model, vehicle system type, software version, and fault type. This provides a clear basis for accurate fault retrieval and improves the efficiency of vehicle fault matching and the accuracy of fault resolution.

[0076] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 . Figure 2 This is a flowchart illustrating the second embodiment of the knowledge base update method of this application, as shown below. Figure 2 As shown, steps S40 to S50 are included after step S30: Step S40: Determine the target score for each solution in the updated vehicle fault knowledge base.

[0077] Among them, the target score is an indicator used to quantitatively evaluate the effectiveness of each solution in the knowledge base. This score can intuitively determine the quality of the solution.

[0078] In one possible implementation, step S40 includes steps S41 to S43: Step S41: Determine the historical search count corresponding to the vehicle fault tag for each solution, and the number of times each solution has successfully resolved the fault.

[0079] Among them, the number of historical searches refers to the total number of times the fault tag corresponding to the solution has been queried, reflecting the commonness of the fault and the demand for the solution.

[0080] The success rate refers to the number of times the solution has successfully resolved the corresponding fault.

[0081] In some embodiments, after repairing a vehicle malfunction using this solution, the number of successful repairs (success or failure) is counted based on the feedback results. Simultaneously, subsequent vehicle operating data can be used for auxiliary verification. If the vehicle does not report the same type of malfunction again within a preset time after repair using this solution, the repair is considered successful, further supplementing the statistics on the number of successful repairs and improving the accuracy of the statistical results.

[0082] Step S42: Determine the matching success rate for each solution by the ratio of the number of successful searches to the number of historical searches.

[0083] The matching success rate reflects the degree of matching and effectiveness between the solution and the corresponding fault. The higher the matching success rate, the more effectively the solution can resolve the corresponding fault. For example, if a solution has been searched 100 times and has been successful 85 times, then its matching success rate is 85%.

[0084] Step S43: Determine the target score for each solution based on at least one of the following: matching success rate, engineer feedback score, and user feedback score.

[0085] Among them, the engineer feedback score refers to the score given by professional after-sales engineers for evaluating the rationality, feasibility, and completeness of the solution.

[0086] In some embodiments, after-sales engineers can assign a score to the solution via an interactive interface, which is called the engineer feedback score. For example, an accurate solution receives a score of 1 point, an outdated solution receives a score of -1 point, and a solution missing a critical step receives a score of 0 points. In some embodiments, multiple engineers can assign scores to the same solution, and the average score is taken as the final engineer feedback score.

[0087] The user feedback score is a rating given by car owners to the repair effectiveness, cost, and time after adopting the solution.

[0088] In some embodiments, user feedback scores can be determined by collecting user ratings of the solution's effectiveness through post-sales questionnaires. For example, if a user's rating ranges from 1 to 5, it can be normalized to the 0-1 range as the user feedback score. For instance, a user's rating of 4.8 corresponds to a user feedback score of 0.96.

[0089] In some embodiments, a first weight corresponding to the matching success rate, a second weight corresponding to the engineer feedback score, and a third weight corresponding to the user feedback score can be determined. Then, based on the first weight, the second weight, and the third weight, the matching success rate, engineer feedback score, and user feedback score corresponding to each solution are weighted and summed to determine the target score corresponding to each solution.

[0090] In some embodiments, the first weight is greater than the second weight, and the second weight is greater than the third weight. The sum of the weights of the first, second, and third weights is 1. It should be noted that professional after-sales engineers can more accurately determine the accuracy of the solution; therefore, the first weight corresponding to the engineer's feedback score can be greater than the second weight corresponding to the matching success rate. Since the matching success rate reflects the actual effectiveness of the solution, and the user feedback score reflects the user experience, the second weight corresponding to the matching success rate can be greater than the third weight corresponding to the user feedback score.

[0091] For example, the target score = 0.5 × A + 0.3 × B + 0.2 × C. Where A is the engineer's feedback score, B is the matching success rate, and C is the user's feedback score.

[0092] The above implementation method integrates multiple indicators such as matching success rate, engineer feedback and user feedback, and combines them with weight allocation to achieve a comprehensive evaluation of the solution quality, avoiding the one-sidedness of evaluation by a single indicator.

[0093] In another possible implementation, the matching success rate can be used as the target score; the engineer feedback score can be used as the target score; the user feedback score can be used as the target score; or, the matching success rate and the engineer feedback score can be weighted together to determine the target score; or, the matching success rate and the user feedback score can be weighted together to determine the target score.

[0094] Step S50: If the target score for any solution is less than the preset score, update any solution.

[0095] The preset score serves as a critical threshold for determining whether a solution needs optimization. Its setting is based on factors such as reliability requirements for fault diagnosis and user experience needs. For example, the preset score can be set to 0.3. If the target score for a solution is below 0.3, it indicates that the solution is of poor quality and cannot effectively meet the fault resolution requirements.

[0096] In some embodiments, any solution may be updated based on feedback data from engineers and / or users (such as "missing calibration steps" suggested by engineers, or "abstract operating instructions" reported by users).

[0097] For example, the solution before the update was "restart the vehicle system", while the solution after the update is "V2.5 users need to clear the intelligent driving cache first, and then restart the vehicle system".

[0098] In this embodiment, by updating and optimizing low-scoring solutions, inefficient and invalid solutions in the knowledge base can be eliminated or corrected, thereby improving the overall quality and reliability of the solutions in the knowledge base. The dynamic optimization mechanism enables the knowledge base to adapt to the upgrading of vehicle technology and changes in fault types, ensuring the timeliness and practicality of the knowledge base.

[0099] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the third embodiment of the knowledge base update method of this application, as shown below. Figure 3 As shown, after step S30, steps S60 to S70 may also be included: Step S60: Determine the historical retrieval count for each vehicle fault tag in the updated vehicle fault knowledge base.

[0100] The number of historical searches reflects the frequency of the fault corresponding to the fault tag. The more historical searches, the more common the fault is and the higher the user's search demand for the fault tag.

[0101] In some embodiments, the retrieval logs of the knowledge base can be queried to count the total number of times each vehicle fault tag in the updated vehicle fault knowledge base has been retrieved.

[0102] The historical search count can be the number of searches within a time period (e.g., one month or two months) from the current moment. This can increase the priority of frequently searched vehicle fault tags and improve search efficiency.

[0103] Step S70: Based on the number of historical searches, determine the search priority corresponding to each vehicle fault tag, wherein the number of historical searches is positively correlated with the search priority.

[0104] Among them, the number of historical searches is positively correlated with the search priority, that is, the more historical searches a fault tag has, the higher its search priority.

[0105] In this embodiment, a step for determining the retrieval priority of fault tags is added. By statistically analyzing the historical retrieval count of each fault tag, a positive correlation is established between the historical retrieval count and the retrieval priority, thereby achieving priority ranking of retrieval results. This embodiment can specifically improve the retrieval efficiency of fault tags, enabling users to see tags and solutions corresponding to common faults first during the search, reducing search time, quickly locating target faults, and improving fault diagnosis efficiency.

[0106] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the knowledge base update method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0107] This application also provides a knowledge base updating device; please refer to [reference needed]. Figure 4 The knowledge base update device includes: The receiving module 401 is used to receive a query request, wherein the query request is a request reported by the faulty vehicle and contains fault data corresponding to the faulty vehicle, and / or the query request is a request sent by the client and contains the identifier of the queried vehicle. The determination module 402 is used to determine the target fault label and the corresponding target solution corresponding to the query request when the query request triggers an update of the vehicle fault knowledge base. Update module 403 is used to update the vehicle fault knowledge base based on target fault labels and target solutions.

[0108] In some embodiments, the determining module 402 is configured to: Based on the fault data corresponding to the faulty vehicle, determine the first fault label corresponding to the faulty vehicle. If the first fault tag does not exist in the vehicle fault knowledge base, determine the historical fault tag corresponding to the historical fault vehicle that was reported in the query request within a preset time period before the current time. Determine the total number of historical fault tags that are identical to the first fault tag; If the total number exceeds the threshold, the query request will trigger an update to the vehicle fault knowledge base.

[0109] In some embodiments, the determining module 402 is configured to: Based on the identifier of the queried vehicle, obtain the real-time data corresponding to the queried vehicle; Based on real-time data, determine the second fault label corresponding to the queried vehicle; If the second fault tag does not exist in the vehicle fault knowledge base, the query request will trigger an update of the vehicle fault knowledge base.

[0110] In some embodiments, a first processing module is further included, configured to: Determine the target score for each solution in the updated vehicle fault knowledge base; If the target score for any solution is lower than the preset score, then update that solution.

[0111] In some embodiments, the first processing module is configured to: Determine the historical search count corresponding to the vehicle fault tag for each solution, and the number of times each solution has successfully resolved the fault; The ratio of the number of successful searches for each solution to the number of historical searches is used to determine the matching success rate for each solution. The target score for each solution is determined based on at least one of the following: matching success rate, engineer feedback score, and user feedback score.

[0112] In some embodiments, a second processing module is further included, for: Determine the historical search count for each vehicle fault tag in the updated vehicle fault knowledge base; Based on the number of historical searches, the search priority for each vehicle fault tag is determined, and the number of historical searches is positively correlated with the search priority.

[0113] In some embodiments, a generation module is further included, for: Structure the vehicle after-sales data to determine the fault solutions, the corresponding vehicle models, vehicle system types, software versions, and fault types. The vehicle model, vehicle system type, software version, and fault type are identified as the vehicle fault labels corresponding to the fault solutions. The fault solutions and vehicle fault tags are stored in the vehicle fault knowledge base.

[0114] The knowledge base updating device provided in this application, employing the knowledge base updating method described in the above embodiments, can solve the technical problem of low update timeliness of the vehicle fault knowledge base, which affects the timeliness and accuracy of vehicle fault handling. Compared with the prior art, the beneficial effects of the knowledge base updating device provided in this application are the same as those of the knowledge base updating method described in the above embodiments, and other technical features in the knowledge base updating device are the same as those disclosed in the methods described in the above embodiments, and will not be repeated here.

[0115] This application provides a knowledge base updating device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the knowledge base updating method in Embodiment 1 above.

[0116] The following is for reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing a knowledge base update device according to embodiments of this application. The knowledge base update device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The knowledge base update device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0117] like Figure 5As shown, the knowledge base update device may include a processing unit 501 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from storage device 503 into random access memory (RAM) 504. RAM 504 also stores various programs and data required for the operation of the knowledge base update device. The processing unit 501, ROM 502, and RAM 504 are interconnected via bus 505. Input / output (I / O) interface 506 is also connected to the bus. Typically, the following systems can be connected to I / O interface 506: input devices 507 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 508 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 503 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows the knowledge base update device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows knowledge base update devices with various systems, it should be understood that implementing or having all of the systems shown is not required. More or fewer systems may be implemented alternatively.

[0118] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 503, or installed from ROM 502. When the computer program is executed by processing device 501, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0119] The knowledge base updating device provided in this application, employing the knowledge base updating method described in the above embodiments, can solve the technical problem of low update timeliness of the vehicle fault knowledge base, which affects the timeliness and accuracy of vehicle fault handling. Compared with the prior art, the beneficial effects of the knowledge base updating device provided in this application are the same as those of the knowledge base updating method provided in the above embodiments, and other technical features in this knowledge base updating device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0120] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0122] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the knowledge base update method in the above embodiments.

[0123] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0124] The aforementioned computer-readable storage medium may be included in the knowledge base update device; or it may exist independently and not be assembled into the knowledge base update device.

[0125] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the knowledge base update device, enable the knowledge base update device to implement the knowledge base update method.

[0126] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0127] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0128] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0129] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described knowledge base update method. This solves the technical problem of low update timeliness of the vehicle fault knowledge base, which affects the timeliness and accuracy of vehicle fault handling. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the knowledge base update method provided in the above embodiments, and will not be repeated here.

[0130] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the knowledge base update method described above.

[0131] The computer program product provided in this application can solve the technical problem of low update timeliness of vehicle fault knowledge base, which affects the timeliness and accuracy of vehicle fault handling. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the knowledge base update method provided in the above embodiments, and will not be repeated here.

[0132] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A knowledge base update method, characterized in that, The method includes: Receive a query request, wherein the query request is a request reported by a faulty vehicle and contains fault data corresponding to the faulty vehicle, and / or the query request is a request sent by a client and contains the identifier of the vehicle being queried. If it is determined that the query request triggers an update of the vehicle fault knowledge base, the target fault tag and the corresponding target solution for the query request shall be determined. The vehicle fault knowledge base is updated based on the target fault label and the target solution.

2. The method according to claim 1, characterized in that, The query request is a request reported by a faulty vehicle and contains fault data corresponding to the faulty vehicle. Determining that the query request triggers an update to the vehicle fault knowledge base includes: Based on the fault data corresponding to the faulty vehicle, determine the first fault label corresponding to the faulty vehicle; If the first fault tag does not exist in the vehicle fault knowledge base, determine the historical fault tag corresponding to the historical fault vehicle that reported the query request within a preset time period before the current time. Determine the total number of historical fault tags that are identical to the first fault tag; If the total number exceeds the quantity threshold, the query request is determined to trigger an update of the vehicle fault knowledge base.

3. The method according to claim 1, characterized in that, The query request is a request sent by the client that contains the identifier of the vehicle being queried. Determining that the query request triggers an update to the vehicle fault knowledge base includes: Based on the identifier of the queried vehicle, obtain the real-time data corresponding to the queried vehicle; Based on the real-time data, determine the second fault label corresponding to the queried vehicle; If the second fault tag does not exist in the vehicle fault knowledge base, it is determined that the query request triggers an update of the vehicle fault knowledge base.

4. The method according to claim 1, characterized in that, After updating the vehicle fault knowledge base based on the target fault label and the target solution, the method further includes: Determine the target score for each solution in the updated vehicle fault knowledge base; If the target score for any solution is less than the preset score, then that solution is updated.

5. The method according to claim 4, characterized in that, The determination of the target score for each solution in the updated vehicle fault knowledge base includes: Determine the historical retrieval count corresponding to the vehicle fault tag for each solution, and the number of times each solution successfully resolves the fault; The ratio of the number of successful searches to the number of historical searches for each solution is used to determine the matching success rate for each solution. The target score for each solution is determined based on at least one of the following: the matching success rate, the engineer feedback score, and the user feedback score.

6. The method according to any one of claims 1-5, characterized in that, After updating the vehicle fault knowledge base based on the target fault label and the target solution, the method further includes: Determine the historical retrieval count for each vehicle fault tag in the updated vehicle fault knowledge base; Based on the historical search count, the search priority corresponding to each vehicle fault tag is determined, wherein the historical search count is positively correlated with the search priority.

7. The method according to any one of claims 1-5, characterized in that, Before updating the vehicle fault knowledge base based on the target fault label and the target solution, the method further includes: The vehicle after-sales data is structured to determine the fault solution, the corresponding vehicle model, vehicle system type, software version, and fault type. The vehicle model, vehicle system type, software version, and fault type are determined as the vehicle fault labels corresponding to the fault solution. The fault solutions and vehicle fault tags are stored in the vehicle fault knowledge base.

8. A knowledge base updating device, characterized in that, The knowledge base updating device includes: A receiving module is used to receive a query request, wherein the query request is a request reported by a faulty vehicle and contains fault data corresponding to the faulty vehicle, and / or the query request is a request sent by a client and contains the identifier of the queried vehicle. The determination module is used to determine the target fault tag and the corresponding target solution corresponding to the query request when it is determined that the query request triggers an update of the vehicle fault knowledge base; The update module is used to update the vehicle fault knowledge base based on the target fault label and the target solution.

9. A knowledge base updating device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the knowledge base update method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the knowledge base update method as described in any one of claims 1 to 7.

Images