Knowledge base construction method, interaction method, device, equipment, medium and product

Abstract

This invention relates to a knowledge base construction method, interaction method, apparatus, device, medium, and product, relating to the field of vehicle-mounted function integration and debugging. The method includes: acquiring original documents and a pre-built ontology model; extracting entities and relationships from the text in the original documents according to core classes and relationships; storing the extracted entities and relationships in a graph database; splitting the text into multiple text blocks; associating images with corresponding text blocks and storing them in a document database; and then constructing a vector index to form a knowledge base. By introducing an ontology model to apply unified semantic constraints to vehicle electronic control units, signals, and fault diagnosis elements, and constructing a multi-level knowledge organization structure based on entity relationship extraction, text splitting, graph-text association, and vector indexing, this method can structurally integrate key information originally scattered across various professional documents, effectively improving the problem of fragmented and complex knowledge structures in the field of vehicle-mounted function integration and debugging.

Description

Technical Field

[0001] This invention relates to the field of vehicle-mounted system integration and testing, specifically to a knowledge base construction method, interaction method, device, equipment, medium, and product. Background Technology

[0002] Vehicle-mounted function integration testing refers to the joint functional debugging and verification of multiple electronic control units and related software during the vehicle development process. During this process, test engineers need to troubleshoot various functional faults in the vehicle. When encountering problems, engineers typically need to consult various professional documents such as operating manuals, diagnostic specifications, and historical fault case libraries to resolve the issue based on the knowledge found. This process is highly dependent on the engineer's personal experience and understanding of various documents; as the volume of documents increases, the search time often becomes lengthy, resulting in low problem-solving efficiency.

[0003] With the rapid development of large language model technology, many problems can be directly solved by large models. However, the knowledge in the field of in-vehicle functional integration is highly specialized, and its knowledge structure is far more complex than that of general domains. General large models struggle to directly understand and accurately utilize this complex and highly coupled professional knowledge, resulting in poor performance when using models to solve problems in the field of in-vehicle functional integration. Therefore, it is necessary to first address the difficulty in utilizing knowledge in the field of in-vehicle functional integration. Thus, a method for the structured integration and efficient utilization of knowledge in the field of in-vehicle functional integration is urgently needed. Summary of the Invention

[0004] One of the objectives of this invention is to provide a knowledge base construction method, interaction method, device, equipment, medium, and product to solve the problem of knowledge being scattered and structurally complex in the field of vehicle function integration and debugging, which makes it difficult to utilize effectively.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] A knowledge base construction method, comprising:

[0007] Obtain the original document and the pre-built ontology model. The ontology model includes core classes and the relationships between core classes. The core classes include the vehicle's electronic control unit, signals, and fault diagnosis elements. The original document contains text and images related to the core classes.

[0008] Based on the core classes and relationships, entity and relationship extraction is performed on the text in the original document, and the extracted entities and relationships are stored in the graph database.

[0009] Based on the extracted entities and relationships, the text is split into multiple text blocks, and the images are associated with the corresponding text blocks. After association, the text blocks and images are stored in the document database.

[0010] For graph databases and document databases, vector indexes are constructed to form a knowledge base that includes graph databases, document databases, and vector indexes.

[0011] Furthermore, the image is associated with the corresponding text block, including:

[0012] Perform semantic recognition on the image to obtain image description text;

[0013] Embed the image description text and the image's reference address into the corresponding text block.

[0014] Furthermore, the reference address is the webpage access address. The image description text and the image's reference address are embedded in the corresponding text block, including:

[0015] Upload the image to the server's object storage system and obtain the image's web page access address;

[0016] Based on the semantic matching degree between the image description text and each text block, and the position of the image in the original document, the text block corresponding to the image is determined among multiple text blocks;

[0017] Embed the image description text and webpage access address into the text block corresponding to the image.

[0018] Furthermore, based on the extracted entities and relationships, the text is split into multiple text blocks, including:

[0019] Identify the set of entities in the text that belong to the same fault diagnosis element chain. The fault diagnosis element chain is formed by linking multiple entities in the fault phenomenon, fault-related signal characteristics, fault causes, solutions and test methods according to their relationships.

[0020] For text content describing the same fault diagnosis element chain, the portion of the text content corresponding to each entity is split into separate text blocks.

[0021] Furthermore, construct the vector index, including:

[0022] Map text blocks in the document database to a high-dimensional vector space to generate a vector set;

[0023] A graph index is constructed based on a set of vectors. The graph index has a multi-level graph structure, with node association vectors and scalar attribute vectors in each level of the graph.

[0024] During retrieval, based on the query vector and filtering conditions, conditional inversion is performed in each level of the graph index traversal to calculate the distance to nodes that meet the filtering conditions and generate a candidate result set.

[0025] Furthermore, it also includes:

[0026] Based on the access frequency of each vector in the vector set, the vectors are divided into high-frequency access vectors and low-frequency access vectors.

[0027] High-frequency access vectors are stored in memory in a compressed format, while low-frequency access vectors are stored in a full-precision format on local persistent storage media.

[0028] During retrieval, the frequently accessed vectors in memory are prioritized for distance calculation.

[0029] Furthermore, it also includes:

[0030] Horizontal sharding of vector data in a vector set is performed based on centroid vectors or metadata fields.

[0031] During retrieval, the distance between the query vector and the centroid of each segment is calculated, and the candidate segment set is selected in ascending order of distance. The number of candidates to be returned is dynamically allocated to each candidate segment, where the number of candidates allocated to each segment is proportional to the probability that the segment is selected as the nearest neighbor region. After each candidate segment performs retrieval independently, the retrieval results are merged and reordered by the coordinating node, and the final result is output.

[0032] An interaction method, comprising:

[0033] The knowledge base is constructed by obtaining user questions and the knowledge retrieval results retrieved from the knowledge base based on the user questions, and the knowledge base is constructed according to any of the above knowledge base construction methods.

[0034] Based on user questions and knowledge retrieval results, generate an analysis framework that matches the fault type of the user questions;

[0035] User questions, knowledge retrieval results, and analysis frameworks are assembled into structured prompts, which are then input into a pre-deployed inference model. This inference model is derived by adjusting the parameters of a large language model.

[0036] The inference model returns the output of the solution to the user's question to the user.

[0037] Furthermore, the inference model is obtained in the following way:

[0038] Select the appropriate large language model based on at least one of the enterprise's local memory resources, computing power resources, accuracy requirements, and latency requirements.

[0039] The selected large language model is subjected to parameter compression processing to obtain the inference model. The parameter compression processing includes model distillation and / or model quantization.

[0040] A knowledge base construction apparatus, comprising:

[0041] The acquisition module is used to acquire the original document and the pre-built ontology model. The ontology model includes core classes and the relationships between core classes. The core classes include the vehicle's electronic control unit, signals and fault diagnosis elements. The original document contains text and images related to the core classes.

[0042] The extraction module is used to extract entities and relationships from the text in the original document according to the core class and relationship, and store the extracted entities and relationships into the graph database.

[0043] The processing module is used to split the text into multiple text blocks according to the extracted entities and relationships, associate the images with the corresponding text blocks, and then store the text blocks and images into the document database.

[0044] The index building module is used to build vector indexes for graph databases and document databases, forming a knowledge base that includes graph databases, document databases, and vector indexes.

[0045] An interactive device, comprising:

[0046] The acquisition module is used to acquire user questions and the knowledge retrieval results retrieved from the knowledge base based on the user questions. The knowledge base is constructed using any of the above knowledge base construction methods.

[0047] The framework generation module is used to generate an analysis framework that matches the fault type of the user's problem based on the user's problem and the knowledge retrieval results.

[0048] The prompt word engineering module is used to assemble user questions, knowledge retrieval results, and analysis frameworks into structured prompt words, and input the prompt words into a pre-deployed inference model, which is obtained by adjusting the parameters based on a large language model;

[0049] The output module is used to return the output results of the inference model to the user's question.

[0050] An electronic device includes: a processor, and a memory communicatively connected to the processor;

[0051] The memory stores the instructions that the computer executes;

[0052] The processor executes computer-executable instructions stored in memory to implement any of the methods described above.

[0053] A computer-readable storage medium includes: computer-executable instructions stored in the computer-readable storage medium, which, when executed by a processor, are used to implement the method as described above.

[0054] A computer program product comprising a computer program that, when executed by a processor, implements the method as described above.

[0055] The beneficial effects of this invention are as follows: By constructing a graph database, a document database, and a vector index, the text, images, and their semantic relationships within the original documents in the field of vehicle function integration can be structurally integrated, improving the ability to associate and retrieve heterogeneous multimodal knowledge and the ability to trace the source of results, thereby improving the accuracy of knowledge retrieval and question answering in the vehicle function integration scenario; In addition, by integrating knowledge such as the company's vehicle manuals and fault cases in this way, the company can provide a path for team knowledge accumulation in the field of vehicle function integration, improve the value of knowledge reuse, simplify the allocation of human resources required for training, and improve overall human efficiency. Attached Figure Description

[0056] Figure 1 A flowchart illustrating a knowledge base construction method provided for an exemplary embodiment of the present invention;

[0057] Figure 2 A flowchart illustrating the parsing of an original document is provided as an exemplary embodiment of the present invention.

[0058] Figure 3 A schematic diagram illustrating the construction process of an in-vehicle function integration and debugging knowledge base, provided as an exemplary embodiment of the present invention;

[0059] Figure 4 A flowchart illustrating an interactive method provided for an exemplary embodiment of the present invention;

[0060] Figure 5 A schematic diagram of a parameter compression processing flow provided for an exemplary embodiment of the present invention;

[0061] Figure 6 A schematic diagram of the structure of an in-vehicle function integration and interaction system provided as an exemplary embodiment of the present invention;

[0062] Figure 7 A schematic diagram of the structure of a knowledge base construction device provided for an exemplary embodiment of the present invention;

[0063] Figure 8 A schematic diagram of the structure of an interactive device provided for an exemplary embodiment of the present invention;

[0064] Figure 9 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of the present invention.

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

[0066] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0067] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

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

[0069] The terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes elements is not excluded. For example, the use of terms such as "first," "second," etc., to indicate names does not imply any particular order.

[0070] Vehicle-mounted function integration testing falls under the technical field of interdisciplinary integration of automotive electronics testing, vehicle network communication analysis, and knowledge retrieval. It can be applied to various business processes such as vehicle R&D, bench testing, and road testing. In such scenarios, engineers typically need to conduct rapid analysis of the vehicle's ECU (Electronic Control Unit), on-board bus signals, and functional faults, and complete problem localization and troubleshooting recommendations within a short period of time.

[0071] Because the data sources involved in vehicle function integration testing are complex, the formats are heterogeneous, and the terminology is dense, and the same fault may be associated with multiple ECUs, multiple signal links, and multiple diagnostic conditions, and this knowledge is scattered in different professional documents, this scenario places high demands on knowledge organization, semantic association, retrieval accuracy, and response efficiency. Currently, it relies heavily on engineers repeatedly consulting various professional documents and comparing the text descriptions and images in the documents. As vehicle functions evolve and the total amount of integration testing knowledge increases, this method of manually consulting original documents to obtain knowledge to solve integration testing problems is becoming increasingly difficult to meet the needs of integration testing scenarios.

[0072] To address the aforementioned issues, a technical concept is proposed. First, the knowledge structure of the vehicle function integration testing domain is modeled to obtain an ontology model containing core classes such as ECUs, signals, and faults. Guided by the core classes and inter-class relationships in the ontology model, entities and relationships are extracted from integration testing-related documents. The extracted entities and relationships can be stored in a graph database, enabling a structured representation of key objects and their connections that were originally scattered across different documents. Simultaneously, based on the extracted entities and relationships, the text content in the documents can be split into several text blocks, and images in the documents can be associated with the text blocks, aligning images and text semantically. The text blocks and images can be stored in a document database. Vector indexes can be constructed for the data in the graph database and document database, supporting the conversion of user queries into query vectors and the retrieval of corresponding data by matching the vectorized indexes.

[0073] By employing the aforementioned technical approach, a unified, interconnected, and searchable knowledge data architecture can be established for heterogeneous documents and image data during in-vehicle function integration testing, thereby improving the efficiency and accuracy of subsequent retrieval. In some potential scenarios, knowledge base retrieval can also be combined with large language models to provide model-based question-answering functionality enhanced by knowledge retrieval, enabling question-and-answer interaction with users during in-vehicle function integration testing.

[0074] The application scenarios described above are only partial examples. Those skilled in the art can expand the applications according to specific needs and scenarios, and the embodiments of the present invention do not impose specific limitations in this regard. The method according to an exemplary embodiment of the present invention will now be described with reference to the accompanying drawings.

[0075] Figure 1This is a flowchart illustrating a knowledge base construction method provided for an exemplary embodiment of the present invention. For example... Figure 1 As shown, the method may include:

[0076] Step S101: Obtain the original document and the pre-built ontology model.

[0077] The ontology model includes core classes and the relationships between them. Core classes include the vehicle's electronic control units, signals, and fault diagnosis elements. Original documents may include vehicle manuals, diagnostic logs, configuration word lists, historical fault records, engineer notes, etc., and contain text and images related to the core classes.

[0078] The entity executing the knowledge base construction method in this embodiment of the invention can be a knowledge base system, which can be deployed on an enterprise server cluster. For example, an enterprise can execute the method on a local server to build a knowledge base. The built knowledge base can be stored on a terminal device used for in-vehicle function integration testing, or it can be stored on a cloud server and return the corresponding knowledge in response to query requests from the in-vehicle function integration testing terminal.

[0079] In this embodiment of the invention, the original document serves as the input carrier for knowledge extraction, containing text and image data related to vehicle domain semantics. The ontology model provides a unified semantic framework for subsequent knowledge extraction, enabling data from different sources and in different formats to be understood and organized within a consistent category system. Core classes are the basic semantic classification units in the ontology model, and in this embodiment, they include at least electronic control units, signal elements, and fault diagnosis elements.

[0080] For example, an ontology model in the field of vehicle function integration and debugging can include the following core classes and their attributes: [ECU]: Electronic Control Unit, with attributes including name, supplier, etc.; [Signal]: Vehicle network signal (CAN / LIN / Ethernet), with attributes including signal name, type, normal range, and cycle; [Fault Phenomenon]: Abnormal behavior observed by engineers, with attributes including description and occurrence conditions; [Fault-Related Signal Characteristics]: Key signal characteristics corresponding to the fault, with attributes including signal name, normal value, and abnormal threshold; [Fault Cause]: The root cause of the fault; [Solution]: Operational steps to repair the fault; [Test Method]: Test procedures to verify whether the fault has been resolved. Among these, [Fault Phenomenon], [Fault-Related Signal Characteristics], [Fault Cause], [Solution], and [Test Method] all belong to fault diagnosis elements. Relationships between these core classes can be defined. For example, [fault phenomenon] - caused by abnormal [key characterization signal], [fault-related signal characteristics] - belong to [signal], [fault-related signal characteristics] - associated with [fault cause], [fault cause] - corresponding to [solution], [solution] - verified by [test method].

[0081] The pre-built ontology model can be pre-established by domain experts in conjunction with the knowledge system of vehicle function integration. The relationships between the core classes in the ontology model can include the sending, receiving, and monitoring relationships between the electronic control unit and signals, the association and response relationships between the ECU and fault diagnosis elements, and the triggering and dependency relationships between signals and fault diagnosis elements.

[0082] By acquiring the original documents and pre-built ontology models, and using the core classes and their relationships in the ontology models to constrain subsequent processing, the content from vehicle manuals, diagnostic logs, and configuration tables can be constrained within a unified semantic boundary. This avoids problems such as mixed object categories and inconsistent relationship expressions during subsequent extraction, thus providing guidance for knowledge structuring in vehicle function integration scenarios.

[0083] Step S102: Based on the core classes and relationships, extract entities and relationships from the text in the original document, and store the extracted entities and relationships into the graph database.

[0084] In this model, the core classes and relation definitions serve as extraction constraints. Entity extraction is used to identify text fragments that correspond to electronic control units, signals, and fault diagnosis elements from the text. Relationship extraction is used to identify semantic associations between different entities. The graph database is used to structure and store the extracted entities and their relationships in the form of nodes and edges, thereby supporting subsequent link queries, source tracing analysis, and knowledge reasoning.

[0085] In this embodiment of the invention, named entity recognition technology based on a pre-trained language model (such as BERT) can be used to extract entities from the text in the original document. The tag set for entity extraction can include: [ECU] (Electronic Control Unit), [SIG] (signal), [PHEN] (fault phenomenon), [CHAR] (fault-related signal feature), [CAUSE] (fault cause), [SOL] (solution), and [TEST] (test method). For numerical parameters (such as voltage threshold and baud rate) and abbreviations (CAN, LIN, DTC) specific to the automotive field, regular expression matching and a domain dictionary can be added to the general NER model as post-processing.

[0086] Relation extraction can be performed based on the entity extraction results. Specifically, a relation classification model (such as a BERT or RoBERTa-based classification model) can be used to extract semantic relations between entities. Entity pairs from the same paragraph or adjacent sentences are input into the model, and the output is the relation category and confidence score. Relations with a confidence score higher than 0.7 can be stored in a graph database along with the entities; relations with a confidence score lower than 0.7 are not stored in the database initially and are reserved for manual review.

[0087] By extracting entities and relationships from text based on the core classes and their relationships defined around the ontology model, and writing the results into a graph database, information such as ECUs, signals, and fault diagnosis elements that were originally scattered across multiple source documents can be transformed into a computable graph structure. This not only solves the problem that key information is difficult to stably associate after traditional keyword segmentation, but also maintains the semantic continuity between entities when fault links are distributed across documents and paragraphs, thereby significantly enhancing knowledge organization capabilities and the traceability of subsequent retrieval.

[0088] Step S103: According to the extracted entities and relationships, the text is split into multiple text blocks, and the image is associated with the corresponding text block. After association, the text block and image are stored in the document database.

[0089] The text blocks are used to organize the content of the original document according to the semantic units of fault diagnosis, so that each text block is formed around a relatively complete combination of entities and relationship expressions; the images are used to carry visual information such as waveform diagrams, fault code screenshots, vehicle electrical connection diagrams and fault phenomenon pictures; the document database is used to store text blocks, images and the relationship between them, thus forming a data foundation suitable for subsequent multimodal retrieval.

[0090] In this embodiment of the invention, semantic-driven text splitting can be performed based on the entity and relation results obtained in step S102, instead of simply splitting according to fixed character length or fixed paragraph boundaries. Specifically, titles, paragraphs, table rows, log records, or title blocks can be used as initial text units, and then the initial text units can be merged or split according to entity density, relational connectivity, semantic integrity, and chapter boundaries.

[0091] For images, image semantics can be identified, and then the image semantics and text block semantics can be transformed into the same vector space. Semantic similarity is determined by calculating distance, and the text block that is closest in semantics to the image is associated with that image. For example, a waveform can be associated with a text block describing the waveform. The association can be done by establishing a mapping relationship between image identifiers and text block identifiers in a document database, or by embedding the image identifier into the metadata of the text block.

[0092] In some possible implementations, if adjacent text units involve the same electronic control unit, the same key signal, and consecutive diagnostic conditions and handling actions, they can be merged into the same text block; if the same paragraph contains multiple independent fault phenomena or multiple controller links, it can be split into multiple text blocks according to entity relationships.

[0093] In some possible implementations, for log-type text, text blocks can be formed by a single fault triggering process, a continuous time window, or a group of records related to the same fault code; for maintenance manual-type text, related content can be generated into a text block by a continuous semantic chain of "fault phenomenon - possible cause - inspection steps - maintenance measures", or each entity such as "fault phenomenon", "fault cause" or "solution" can be exported as a separate text block; for configuration table-type text, text blocks can be formed by a controller, a group of signal mappings, or a diagnostic parameter definition.

[0094] By extracting entities and relationships, the text is decomposed into diagnostic semantics, and then images are further established to establish precise correspondences with text blocks. This transforms unstructured content such as waveform diagrams, fault code screenshots, and electrical connection diagrams from mere document attachments into knowledge units bound to specific fault links, signal anomalies, and controller objects. This effectively avoids the problem of broken causal chains caused by fixed-length segmentation, while enhancing the traceability of multimodal knowledge and the interpretability after retrieval.

[0095] Step S104: For the graph database and document database, construct vector indexes to form a knowledge base containing the graph database, document database and vector indexes.

[0096] The vector index is used to convert structured, semi-structured, and multimodal content in graph databases and document databases into data structures that can be retrieved based on similarity. The knowledge base is used to uniformly carry graph databases, document databases, and vector indexes, so that the subsequent retrieval process can perform both precise entity-based queries and fast retrieval based on semantic similarity.

[0097] In this embodiment of the invention, entity relationship information in the graph database and text blocks and image semantics in the document database can be vectorized respectively.

[0098] For example, for text blocks in a document database, a text embedding model can be used to map the text blocks to a high-dimensional vector space. The vector input can include the text block content and the document source. For images, the OCR (Optical Character Recognition) results, image semantic description, and recognized semantic tags can be jointly encoded into image semantic vectors, and a joint index can be established with the corresponding text block vectors. For entities and relations in a graph database, node names, categories, and adjacency relationships can be encoded into graph node vectors or subgraph vectors, enabling structured knowledge to also have semantic retrieval entry points. After vector generation, a nearest neighbor search index structure can be used to construct a vector index, such as organizing the vector set based on hierarchical graphs or clustering inverted indexes. To ensure index update capability, after importing new documents, merging and updating entities, or revising relations, only the affected text block vectors, image vectors, and entity relation vectors can be incrementally refreshed without rebuilding the entire index.

[0099] In some possible implementations, if the query explicitly includes controller names, signal names, or fault phenomena, a constraint query can be performed first in the graph database, and then the vector index can be used to expand and recall relevant text blocks, achieving a combination of metadata-based structured filtering and semantic recall. To adapt to enterprise edge deployment environments, in some examples, when performing this step, the index file can also be sharded, cached in memory, and managed with hot and cold storage tiers, so that frequently used controller domains, common fault topics, or high-frequency image data reside preferentially in high-speed storage areas.

[0100] By constructing vector indexes for graph databases and document databases and unifying these three into a knowledge base, the knowledge base system possesses the ability to express structured relationships, carry multimodal content, and perform semantic retrieval. This enables a unified query portal for complex and heterogeneous data in vehicle function integration scenarios. When engineers input questions related to communication anomalies in a specific electronic control unit, signal distortion, a constantly lit fault light, or fault code triggering conditions, the knowledge base system can quickly locate relevant entity links based on the graph database and efficiently recall text blocks and image data semantically similar to those links using the vector indexes. This improves the relevance, response efficiency, and knowledge reuse value of the search results. The knowledge base system can adapt to different document types. For knowledge added in specific domains, it can be added / deleted according to user needs. Based on its constructed knowledge base, models can be flexibly configured according to the enterprise's existing hardware conditions to achieve user question-and-answer functionality in the field of vehicle function integration.

[0101] In the above embodiments, the original document and the pre-built ontology model are obtained. Entity and relation extraction can be performed on the text in the original document according to the core classes and relations. The extracted entities and relations are stored in the graph database. Then, the text can be split into multiple text blocks according to the extracted entities and relations, and the images are associated with the corresponding text blocks. After association, the text blocks and images are stored in the document database. Then, a vector index is built for the graph database and the document database to form a knowledge base containing the graph database, the document database and the vector index. By introducing an ontology model to unify semantic constraints on vehicle electronic control units, signals, and fault diagnosis elements, and constructing a multi-level knowledge organization structure based on entity relationship extraction, text splitting, graph-text association, and vector indexing, key information that was originally scattered in professional documents such as vehicle manuals and test logs can be structurally integrated. This effectively improves the problem of scattered and complex knowledge in the field of vehicle function integration and debugging. The graph database can store the relationships between electronic control units, signals, and fault diagnosis elements, the document database can store the multimodal correspondence between text blocks and images, and the vector index can ensure the database's rapid recall capability during retrieval, forming a unified, searchable, and traceable knowledge base, providing data support for answering questions in the process of vehicle function integration and debugging.

[0102] In one embodiment, before extracting text from the original document, the original document can be parsed to obtain structured text and semantically distinguishable images. Then, the structured text is divided into blocks to obtain multiple text blocks.

[0103] Figure 2 This is a schematic diagram illustrating a process for parsing an original document, provided as an exemplary embodiment of the present invention. For example... Figure 2 As shown, the parsing process may include parser type selection, chained parsing, reverse mapping of image data, and text chunking.

[0104] The parser type selection process can automatically identify the document type based on the input document's file extension and match the corresponding parser class from a pre-defined parser mapping table. Specifically, the knowledge base system can maintain a mapping table between file types and parser classes, supporting parsers of various types, including text parsers, table parsers, image parsers, and web page parsers. For the same file type, the knowledge base system can configure multiple candidate parsers and select one based on priority or availability.

[0105] The chained parsing process can employ the chain of responsibility pattern to perform multi-level parsing of documents, specifically including the following two chained strategies:

[0106] FirstParser: This strategy attempts multiple candidate parsers sequentially and returns the first successfully parsed result. It is suitable for scenarios requiring multiple alternatives, such as parsing PDF documents. For example, it prioritizes the high-precision MinerUParser and, if unavailable, uses MarkitdownParser as a fallback, ensuring the robustness of the parsing process.

[0107] Pipeline Parser: This approach chains multiple parsers sequentially, with the output of each parser (including text and image mappings) serving as the input for the next. Image data generated at each stage is accumulated and merged. This strategy is suitable for scenarios requiring multi-stage processing, such as first obtaining the webpage's HTML using StdWebParser and converting it to Markdown, then using MarkdownParser for table formatting and image extraction, ultimately outputting a structured document. MarkdownParser and StdWebParser are different types of document parsers.

[0108] Through the aforementioned chain mechanism, the knowledge base system can flexibly combine different parsing capabilities, ensuring both parsing success rate and progressive processing of complex documents.

[0109] The image data reverse mapping step can be used to process image information embedded in a document, ensuring that image content can be effectively extracted and integrated into the final text. This step specifically includes the following sub-steps:

[0110] Image extraction: During the parsing process, the parser identifies image elements in the document, extracts image binary data or reference paths, and forms image mapping relationships (key-value pairs of image identifiers and binary data or original URLs).

[0111] Multimodal processing: When the system enables multimodal functionality, the extracted images are processed in parallel. Specifically, the OCR engine recognizes textual information in the image, while the Visual Language Model (VLM) is invoked to generate a semantic description of the image. The OCR results and descriptive text are then inserted into the corresponding positions in the document in a specific format.

[0112] Storage Upload: Upload the image binary data to the object storage system through the unified storage interface, obtain a publicly accessible permanent local URL (Uniform Resource Locator), and update the image mapping relationship to correspond to the URL and the original image data.

[0113] Reference replacement: In the final structured text output, the original image references are replaced with Markdown formatting that includes the uploaded URL (e.g., ), ensuring that the images can be correctly referenced in subsequent display and retrieval. Through the above reverse mapping mechanism, the system transforms unstructured image data into referable semantic elements in structured text, providing a rich multimodal context for enhanced retrieval generation.

[0114] The text segmentation stage can divide the structured text processed by the image data reverse mapping stage into blocks. Specifically, a text segmenter can extract features from the structured text and combine them into Chunk objects. Each Chunk object can contain attributes such as seq, start, end, and content. Finally, a Document object is returned and stored in the document database. The Document object can contain content, chunks, and image.

[0115] In one embodiment, associating an image with a corresponding text block may include:

[0116] Perform semantic recognition on the image to obtain the image description text; embed the image description text and the image's reference address into the corresponding text block.

[0117] In this context, an image refers to a visual object to be semantically recognized. Its content can include waveforms, electrical connection diagrams, fault code screenshots, or component status images, etc., used to convert visual information in the image into semantic information suitable for text processing. Image description text is the semantic expression of the image content, used to convey the fault phenomena, component status, or signal characteristics reflected by the image. The image's reference address refers to the identification information used to locate the image's storage or access location, pointing to its specific location in a document database or webpage for subsequent tracing and retrieval.

[0118] In this embodiment of the invention, for the segmented text blocks, semantic recognition can first be performed on the images semantically associated with the text blocks. Semantic recognition can be implemented based on models such as image classification models and object detection models. The model input is the original image or a preprocessed image, and the output is image description text that can summarize the image content. For waveform diagrams in vehicle function integration scenarios, image description text can be used to characterize voltage change trends, signal transition characteristics, or abnormal intervals; for connector schematic diagrams, image description text can be used to characterize terminal numbers, pin positions, or wiring harness connection relationships; for fault code screenshots, image description text can be used to characterize fault code numbers, alarm levels, or message prompt content. After recognition is completed, the generated image description text and the image reference address are jointly written into the metadata area of ​​the corresponding text block, so that the text block retains the original main semantics while carrying the image semantics and its accessible location.

[0119] In some possible implementations, the image reference address can use a Uniform Resource Locator (URL), file path, object storage address, or document page anchor address, and be bound to paragraph identifiers, page number identifiers, or unique block identifiers in the text block to ensure that the text block can accurately locate the corresponding image. After embedding the image description text and reference address into the text block, the retrieval module can either locate relevant content based on the text semantics in the text block, or directly trace back to the original image through the reference address, thus forming an integrated image-text association.

[0120] In the above embodiments, images are associated with corresponding text blocks, so that the text blocks no longer only contain plain text information, but also carry semantic descriptions and access locations corresponding to the image, facilitating the retrieval and location of image content in the knowledge base. Since the image description text is directly embedded in the text block, the image semantics can be incorporated into the same retrieval space during subsequent vector index construction, thereby improving the recall accuracy of content related to fault phenomena, signal characteristics, and component status. Furthermore, the retention of the reference address makes the image traceable; engineers can quickly return to the original image when viewing search results without having to search for the image content based on the image number.

[0121] In one embodiment, the reference address is a webpage access address, and the image description text and the image's reference address are embedded in the corresponding text block, including:

[0122] The image is uploaded to the object storage system of the server to obtain the web page access address of the image; based on the semantic matching degree between the image description text and each text block, and the position of the image in the original document, the text block corresponding to the image is determined from multiple text blocks; the image description text and the web page access address are embedded in the text block corresponding to the image.

[0123] The text block carries localized text content extracted from the original document, and there is a layout or semantic correspondence between the text block and the image. The server's object storage system centrally stores image files and generates an address accessible to web pages after the image is uploaded, allowing the image to be directly referenced and retrieved in subsequent searches. The web page access address is a network identifier for the image's storage location; embedding a text block allows that text block to point to the original image during display.

[0124] In this embodiment of the invention, after receiving the image extracted from the original document, the image can first be written to the server-side object storage space, and a webpage access address can be generated based on the storage identifier and file path. Subsequently, the knowledge base system performs semantic matching calculations on each text block based on the image description text, and combines the page number, paragraph position, or page adjacency relationship of the image in the original document to jointly determine the candidate text blocks to identify the target text block corresponding to the image. After determining the target text block, the knowledge base system writes the image description text and the webpage access address into the associated field or text fragment of the text block, so that the text block simultaneously possesses an image semantic summary and an image access entry. This processing method ensures that the image no longer exists merely as an independent attachment, but is embedded in a text context consistent with its semantics, facilitating unified storage and retrieval of the document library.

[0125] In the above embodiments, after embedding the webpage access address into the target text block, users can directly locate the corresponding image from the text block when searching for relevant fault, signal, or component information, achieving synchronous backtracking of text and image. This improves the accuracy of image association, enhances the traceability of fault knowledge, and improves retrieval efficiency and knowledge reuse capabilities in vehicle function integration scenarios.

[0126] In one embodiment, the text is split into multiple text blocks according to the extracted entities and relationships, including:

[0127] Identify the set of entities in the text that belong to the same fault diagnosis element chain. The fault diagnosis element chain is formed by linking multiple entities in the fault phenomenon, fault-related signal characteristics, fault causes, solutions and test methods according to their relationships. For the text content describing the same fault diagnosis element chain, split the part of the text content corresponding to each entity into a separate text block.

[0128] The fault diagnosis element chain is used to semantically link phenomena, signal manifestations, causes, handling methods, and verification content in the same fault scenario, facilitating the knowledge base system to identify content with common diagnostic orientation in text. Fault phenomena describe the abnormal state of the vehicle; fault-related signal features characterize the signal changes corresponding to this abnormal state; fault causes explain the root cause of the abnormality; solutions represent the handling methods adopted for the abnormality; and testing methods characterize the detection methods used to verify whether the fault has been eliminated or reproduced.

[0129] In this embodiment of the invention, after the knowledge base system performs entity recognition on the original text, it can combine pre-established fault diagnosis relationship constraints to determine whether each entity forms a causal or verification association around the same fault phenomenon, and merge entities that can be connected to form the same diagnostic link into the same entity set. This determination can be completed based on the inter-sentence dependencies of entities, domain dictionary mapping, and relation extraction results, thereby avoiding the erroneous aggregation of similar terms in different fault scenarios. For the merged entity set, the knowledge base system further locates the corresponding expression fragments of each entity in the original text, and divides the original text into multiple text blocks according to the entity boundaries, so that statements describing fault phenomena, statements describing signal characteristics, statements describing causes, statements describing solutions, and statements describing test methods form independent text blocks.

[0130] For example, the text may contain complete failure cases, which can be exported as independent text blocks according to entity relationships (failure phenomenon - failure associated signal characteristics - failure cause - solution - test method).

[0131] In the above embodiments, diagnostic information originally mixed in the same document is organized into text blocks with consistent granularity and single semantics, which can then be used for retrieval recall, vector representation, and image-text association, respectively. This approach reduces the semantic complexity within individual text blocks, improves the traceability of the fault diagnosis element chain, and enhances the accuracy and interpretability of related searches based on fault phenomena. This, in turn, facilitates knowledge accumulation and fault analysis in vehicle function integration scenarios.

[0132] Figure 3 This is a schematic diagram illustrating the construction process of an in-vehicle function integration and debugging knowledge base, provided as an exemplary embodiment of the present invention. For example... Figure 3 As shown, the knowledge sources of the vehicle function integration and debugging knowledge base can include engineers' experience, problem records, and historical fault cases.

[0133] For knowledge sources with a certain knowledge structure, such as automotive manuals, a structured data analysis can be conducted on the signal links, functional performance, and testing methods for vehicle-mounted functions in section 2.1. The recorded content can include the hierarchical division of vehicle functions (first and second-level functional items), specific functional performance, and the interaction logic of cross-regional controller signal links. Specifically: First, divide the vehicle into first and second-level functional items according to the vehicle's functional domains. First-level functional items are the core functional modules of the vehicle, and second-level functional items are their subcategories. For each second-level functional item, describe in detail its functional triggering conditions, execution process state changes, and final response results. Second, based on the electronic and electrical architecture, analyze the cross-regional controller signal links involved in implementing this function, clarifying the source controller, target controller, communication protocol type (such as CAN, Ethernet, LIN, etc.), signal physical meaning, and interaction timing. Finally, based on the above functional performance and signal links, define the preconditions for testing, test steps, expected signal changes, and functional response results, forming complete test cases covering functional logic and signal links. In this way, a traceable relationship is built from the user function end to the signal link end, providing a standardized data foundation for automated testing and problem tracing of vehicle functions.

[0134] To address issues encountered during integration testing, a dynamically updated solution accumulation mechanism is established. This includes: recording problem phenomena, reproduction conditions, and involved functional modules and controllers; conducting root cause analysis to identify the root cause of the problem; developing and validating solutions for different root causes, creating a corresponding entry for problem-root cause-solution; classifying and managing solutions by problem type, functional item, controller, etc., to build a searchable knowledge base; and regularly conducting statistical analysis to extract high-frequency problems and common solutions, which are then fed back into test case design, signal link analysis, and software design specifications, forming a closed-loop optimization process from problem discovery to prevention.

[0135] For typical fault types, the correspondence between signals and faults is accumulated in the knowledge base. For example, if the brake pedal is unresponsive, the corresponding hardware wiring harness inspection and working voltage verification are performed to form a fault feature signal library to support rapid fault location and diagnosis and improve the efficiency of solving engineering problems.

[0136] In one embodiment, constructing a vector index may include:

[0137] The text blocks in the document database are mapped to a high-dimensional vector space to generate a vector set. A graph index is constructed based on the vector set. The graph index is a multi-level graph structure, and the nodes in each level of the graph are associated with vectors and scalar attribute vectors. During retrieval, conditional pushover is performed in each level of the graph index based on the query vector and filtering conditions. Distance calculation is performed on nodes that meet the filtering conditions to generate a candidate result set.

[0138] The high-dimensional vector space is used to carry the semantically encoded vector representation of text blocks, so that the semantic proximity of the texts can be represented by vector distance. The vector set is used to collect the vector representations corresponding to each text block, serving as the basis for subsequent graph index construction and retrieval calculations. The graph index is used to organize the vector set in a graph structure and achieve fast navigation and retrieval through a multi-layered organization. Scalar attribute vectors are used to describe the filtering attributes corresponding to nodes. Filtering attributes can include information such as document type, fault category, vehicle platform, controller name, or time range to support attribute-based filtering.

[0139] In this embodiment of the invention, a pre-trained text encoding model can be used to encode text blocks in the document database into fixed-dimensional vectors. After forming a vector set, a multi-layer graph index is constructed based on the similarity relationships between the vectors. Higher layers are used to store sparser navigation nodes, and lower layers are used to store denser fine-grained nodes, thereby narrowing the search range in large-scale text block scenarios. In addition to the associated vector, each node is also associated with a scalar attribute vector, which can be obtained by encoding discrete attributes and is stored in the same index unit as the node vector. During retrieval, the knowledge base system first parses the user input into a query vector and extracts filtering conditions such as ECU and fault phenomena. Then, during the traversal of each layer of the graph index, condition push-down is performed so that nodes that do not meet the filtering conditions are excluded in the early stages of access. Subsequently, only nodes that meet the conditions are calculated for the distance between the query vector and the node vector. The distance can be cosine distance or Euclidean distance, and finally a candidate result set is formed.

[0140] In some possible implementations, the knowledge base's data storage solution can be based on a relational database, integrating vector retrieval capabilities through an extension mechanism to achieve unified management of structured data and unstructured vectors. Specifically, a custom HNSW (Hierarchical Navigation Small World) index access method can be used to build a hybrid storage engine that supports high-dimensional vector retrieval.

[0141] For example, suppose the set of text blocks output by the document processing pipeline is... Embedded model Each text block in the text block set can be mapped to a high-dimensional vector space to obtain a vector set. Where d is the embedding dimension. Then, the index structure can be defined as a multi-level graph. Let G(l) represent the l-th layer graph, and L be the maximum layer number, satisfying |G(0)|>|G(1)|>⋯>|G(L)|. Each node u∈G has an association vector. and scalar attribute vector , where m is the number of filtering dimensions.

[0142] When querying, a query vector is given. Given the filtering condition F(a), the system performs a filterable approximate nearest neighbor search. The retrieval process can be expressed as the following formula (1):

[0143] (1)

[0144] In the above formula, st represents the constraint condition, and R K (q,F) can represent a query statement constructed based on query vector q and filter condition F(a), and S can represent the candidate result set of graph data determined based on filter condition F(a).

[0145] To achieve efficient filtering, the system introduces a conditional recursive mechanism during the index traversal phase. The candidate node set CC is defined, and the retrieval process satisfies the recursive relationship shown in equation (2):

[0146] (2)

[0147] In the above formula, N(u) represents the set of neighbors of node u, and u* is the optimal node in the current layer. By pushing the filtering conditions to traversal of each layer, the knowledge base system can avoid calculating the distance of nodes that do not meet the conditions, and the theoretical complexity is reduced from O(logn.d) to O(logn.d. ρ), where d is the average degree and ρ is the proportion of nodes that meet the filtering conditions.

[0148] In the above embodiments, by constructing a vector index under a graph index structure, the retrieval conditions can take effect in advance during graph traversal, reducing the number of invalid node visits and lowering distance calculation overhead; the multi-layer graph structure can improve the retrieval and navigation efficiency of large-scale text blocks; nodes simultaneously carry vector information and scalar attribute vectors, enabling semantic retrieval and attribute filtering to be performed in tandem. This can improve the relevance of candidate results, shorten response time, and enhance the ability to locate complex fault data and retrieval usability in vehicle-mounted function integration scenarios.

[0149] In one embodiment, after constructing the vector index, the method may further include: dividing the vectors into high-frequency access vectors and low-frequency access vectors according to the access frequency of each vector in the vector set; storing the high-frequency access vectors in memory in a compressed format and storing the low-frequency access vectors in a full-precision format in a local persistent storage medium; and prioritizing the access of the high-frequency access vectors in memory for distance calculation during retrieval.

[0150] In this embodiment of the invention, the knowledge base system can set an access counter for each vector in the vector index and accumulate the corresponding counter after each successful retrieval, or summarize the number of calls for each vector within a preset statistical period to form an access frequency statistical result. Then, based on a preset threshold or the access frequency sorting result, the knowledge base system classifies vectors with access frequencies higher than the threshold as high-frequency access vectors and the remaining vectors as low-frequency access vectors. For high-frequency access vectors, their original floating-point representation is quantized and compressed. The compression format can adopt fixed-point representation, low-bit-width encoding, or block compression storage to reduce memory usage and improve reading speed. For low-frequency access vectors, their full-precision floating-point representation is retained and written to the local persistent storage medium to maintain the integrity of the vector semantic information and facilitate subsequent recovery.

[0151] For example, a quantization function can be defined. , where Q is the quantization codebook (such as INT8 or INT4). The quantized vector satisfies the following equation (3):

[0152] (3)

[0153] In the above formula, μ and σ are the mean and standard deviation of the component, respectively, and b is the number of quantization bits.

[0154] Full-precision vector v and quantization vector The approximate distance relationship between them can be expressed as the following formula (4):

[0155] (4)

[0156] In the above formula, δ is the upper bound of the quantization error. By estimating the error boundary, the acceptable range of retrieval accuracy can be guaranteed.

[0157] A knowledge base system can implement hot and cold tiered storage based on vector access frequency. Let's define a hot data set. satisfy ,in This is the maximum memory capacity. Hot data resides in memory in a quantized format, while cold data... Stored on disk. During retrieval, the knowledge base system prioritizes accessing the quantized vectors in memory. For cold data in the candidate results, full-precision vectors are loaded from disk as needed for accurate distance verification.

[0158] By performing scalar quantization on frequently accessed vectors, floating-point vectors can be compressed into low-precision representations (such as INT8 or INT4), reducing memory usage and accelerating distance calculation. The quantized vectors reside in memory for fast retrieval; full-precision vectors are stored on disk for accurate distance calculation and result verification. Furthermore, hot and cold data are stratified based on vector access frequency and importance. Hot data (vectors frequently queried recently) resides in memory in compressed format, while cold data (historical archived data) is stored in full precision on persistent storage. The knowledge base system can dynamically adjust data distribution based on query patterns.

[0159] In the above embodiments, after receiving the query vector, the high-frequency access vector can be read from memory first and distance calculation can be performed to prioritize candidate results with higher hit probabilities. When the candidate results in memory are insufficient to meet the return quantity or filtering conditions, the low-frequency access vector in the persistent storage medium is accessed as needed to supplement the calculation. By placing the high-frequency access vector in memory and using compressed storage, the storage access latency in the vehicle environment can be reduced; by storing the low-frequency access vector in full-precision format in the persistent medium, both retrieval accuracy and long-term storage capability can be balanced. This method can shorten the distance calculation waiting time while ensuring the semantic integrity of the vector and reduce the memory pressure on the vehicle, thereby improving the response efficiency and stability of knowledge base retrieval.

[0160] In one embodiment, the method may further include: horizontally sharding the vector data in the vector set based on the centroid vector or metadata field; during retrieval, calculating the distance between the query vector and the centroid of each shard, and selecting the candidate shard set in ascending order of distance; dynamically allocating the number of candidates to be returned to each candidate shard, wherein the number of candidates allocated to each shard is proportional to the probability that the shard is selected as the nearest neighbor region; after each candidate shard performs retrieval independently, the coordinating node merges the retrieval results and reorders them to output the final result.

[0161] The centroid vector represents the center position of each fragment in the vector space, and the metadata field represents the attribute information of the vector data; both can be used as the basis for fragmentation. The candidate fragment set is used to receive the initially selected fragments to narrow the search scope during parallel retrieval. The coordinating node is used to summarize the search results returned by each fragment and output them after global rearrangement.

[0162] In this embodiment of the invention, multiple horizontal partitions can be generated based on the size, distribution density, and metadata attributes of the vector set. Each partition stores the corresponding vector data and its centroid. The centroid can be calculated from the mean vector of the vectors within the partition or determined by clustering results. If metadata field partitioning is used, groups can be formed based on vehicle functional domain, controller type, fault category, or document source field, allowing similar semantic vectors to be stored together. After a retrieval request arrives, the knowledge base system calculates the Euclidean or cosine distance between the query vector and the centroids of each partition, and selects several candidate partitions in ascending order of distance. Subsequently, the coordinating node allocates return slots based on the probability estimate of each partition being selected as the nearest neighbor region. Partitions with higher probabilities receive more candidates to improve the hit rate and reduce invalid returns. Each candidate partition independently performs nearest neighbor retrieval locally and returns local results. The coordinating node merges, deduplicates, and reorders the local results according to similarity to form the final result set.

[0163] For example, suppose vector data is distributed across N shard nodes, and the j-th shard contains a vector subset V(j) with its centroid vector as follows: During a query, the knowledge base system first calculates the distance between the query vector q and the centroids of each partition. Candidate partition sets can be selected in ascending order of distance. And satisfy .

[0164] For each candidate slice, the knowledge base system dynamically allocates the number of candidates to be returned. ,satisfy ,and The probability of a piece being selected as the nearest neighbor region is directly proportional to the probability of that piece being selected as the nearest neighbor region, which can be expressed as the following formula (5):

[0165] (5)

[0166] In the above formula, α is an adjustment parameter. Each segment executes Top-... The search results are merged and reordered by the coordinating node, and the final Top-K results are output. This mechanism significantly reduces cross-node communication overhead while ensuring search quality through a formulaic allocation strategy.

[0167] In a distributed deployment scenario, vector data is horizontally sharded based on centroid vectors or metadata fields, distributing the data across multiple database nodes. During retrieval, the coordinating node pre-selects candidate shards based on the distance between the query vector and the centroids of each shard, dynamically allocates the number of candidates to be returned for each shard, merges them, reorders them, and returns the final result, effectively reducing cross-node communication overhead.

[0168] In the above embodiments, parallel sharding can reduce the retrieval pressure of a single node, distance filtering can reduce the participation of irrelevant shards in the retrieval, probability allocation can balance the recall coverage and return overhead, and unified reordering of coordinated nodes can eliminate local ranking differences, thereby improving retrieval response efficiency and result accuracy.

[0169] Figure 4 This is a flowchart illustrating an interactive method provided as an exemplary embodiment of the present invention. For example... Figure 4 As shown, the process may include:

[0170] Step S401: Obtain the user's question and the knowledge retrieval results retrieved from the knowledge base based on the user's question.

[0171] User issues can be problems encountered by users during the integration and debugging of in-vehicle functions, concerning fault phenomena, troubleshooting methods, or solutions. The knowledge base is constructed according to the knowledge base construction method in the above embodiments.

[0172] The execution subject of the interaction method in this embodiment of the invention can be an in-vehicle function integration and interaction system (hereinafter referred to as the "interaction system"). The interaction system can integrate a pre-deployed local inference model and can retrieve data such as text blocks and images from the knowledge base based on the user's questions, and call the inference model to conduct question and answer with the user based on these data.

[0173] For example, the interactive system can provide an interface to the user through the vehicle's display screen, where the user can input questions, such as "How to troubleshoot communication problems with a certain ECU?". In some possible implementations, the user can also input questions via voice, and the in-vehicle function integration and interaction system can convert the user's voice into text through a voice recognition module.

[0174] After obtaining a user's question, the interactive system can generate a retrieval request based on the question. This retrieval request is used to retrieve relevant knowledge from the knowledge base. For the graph database portion, a graph query can be performed based on entities and relational terms identified in the question. For example, after identifying keywords such as ECU name, fault symptom, communication anomaly, and signal name, the corresponding nodes and edge relationships can be retrieved from the graph database to obtain the fault link, associated controller, associated signal, corresponding fault code, and recommended troubleshooting path. For the document database portion, inverted indexes, field filtering, or full-text search can be used to recall corresponding paragraphs from vehicle manuals, test specifications, log descriptions, and image descriptions. For the vector index portion, the user's question can be encoded into a semantic vector and matched with pre-generated text block vectors in the knowledge base for similarity, in order to recall semantically similar knowledge items.

[0175] In some possible implementations, the interactive system can merge and rank the three types of search results, and the ranking criteria may include keyword matching score, graph relationship path length, vector similarity score, document credibility level, knowledge data update time, etc.

[0176] Step S402: Based on the user's question and the knowledge retrieval results, generate an analysis framework that matches the fault type of the user's question.

[0177] Here, fault type refers to the category identifier after classifying the fault domain involved in the user's problem, such as communication faults, functional logic faults, or power management faults. The analysis framework refers to the reasoning skeleton organized around a certain fault type. It can include key points of examination under multiple analysis dimensions (such as problem objectives, core analysis elements, evidence constraints, and reasoning order), and is used to clarify from which analysis dimensions the subsequent reasoning model should carry out fault judgment, evidence citation, and processing suggestions output.

[0178] In this step, the interactive system can first perform fault type identification on the user's problem. Fault type identification can be completed through rule engines or classification models. The rule engine can classify based on a terminology dictionary, fault description patterns, and domain trigger words. For example, when the problem contains descriptions such as "communication abnormality," "message loss," or "timeout," it is identified as a communication fault; when it contains descriptions such as "no power supply" or "low voltage," it is identified as a power management fault.

[0179] After identifying the fault type, the interactive system constructs a corresponding analysis framework based on the knowledge retrieval results. For example, for communication faults, the analysis framework may include dimensions such as signal transmitter status, signal receiver status, bus load rate, and baud rate consistency; for functional logic faults, the analysis framework may include dimensions such as input conditions, enable conditions, suppression conditions, and output results; and for power management faults, the analysis framework may include dimensions such as supply voltage, quiescent current, and wake-up source.

[0180] In some possible implementations, the analysis framework can be generated by referencing the analysis frameworks used in historical cases that are highly relevant to the user's problem, or by adopting a default general analysis framework and adjusting it in conjunction with the entity relationships in the knowledge base.

[0181] Step S403: Assemble the user question, knowledge retrieval results, and analysis framework into structured prompts, and input the prompts into a pre-deployed inference model.

[0182] The inference model is obtained by adjusting the parameters of an LLM (Large Language Model). Parameter adjustment can refer to methods such as fine-tuning instructions, incremental training in the joint debugging domain, or quantization pruning to match the model parameters with the joint debugging scenario of in-vehicle functions.

[0183] In this embodiment of the invention, the interactive system can construct and guide a large language model to generate professional, comprehensive, and easy-to-understand input prompts through a prompt word engineering module. The prompt word engineering module may include the following units: [Role Setting Unit]: Based on the domain of the user's question, predefine the expert identity "senior domain expert assistant" for the model, giving the answer domain authority and a professional tone; [Core Responsibility Constraint Unit]: Clarify the requirements that the answer must meet, including in-depth analysis of the question, providing evidence based on knowledge base content, weighing multiple perspectives, and explaining professional concepts using plain language; [Knowledge Fusion Unit]: Insert relevant documents, data, or case fragments retrieved from the knowledge base into the prompts as factual basis for the answer, ensuring the answer is grounded in evidence and reducing model illusion; [Output Format Constraint Unit]: Specify the structure of the answer (e.g., point-by-point explanation, analysis before conclusion), language style (avoiding technical terms, using metaphors), length limits, etc., to ensure the output meets user expectations.

[0184] The workflow of the prompt word engineering module can include: receiving user questions and evidence sets returned by knowledge base retrieval, receiving the analysis framework, combining these contents into structured prompt words according to preset templates, and inputting the prompt words into the inference model to obtain the final answer.

[0185] Structured prompts can be organized using a field-based format, including fields such as "Problem Content," "Recall Knowledge Summary," "Key Entities and Relationships," "Fault Type," "Analysis Dimensions," "Answer Constraints," and "Output Format." The "Problem Content" field preserves the user's original focus; the "Recall Knowledge Summary" field lists the most relevant document fragments, graph relationships, and image descriptions in compressed form; the "Key Entities and Relationships" field clarifies the connections between ECUs, signals, fault codes, connectors, and wiring harnesses; the "Fault Type and Analysis Dimensions" field explicitly indicates the professional analysis path to be used for subsequent reasoning; the "Answer Constraints" field requires the model to answer only based on given knowledge, specifies the basis, and avoids fabricating unrecalled information; and the "Output Format" field specifies that the returned results should include cause analysis, troubleshooting steps, verification points, and conclusion recommendations.

[0186] After receiving structured prompts, the inference model can perform constrained inference based on the analytical framework and knowledge evidence provided in the prompts, sequentially completing tasks such as fault type confirmation, key cause summarization, evidence citation, troubleshooting path generation, and risk warning output. This transforms the potentially divergent natural language generation process of large language models into a professional analytical process constrained by knowledge and logic within the vehicle function integration domain. User questions ensure consistency of the output target, knowledge retrieval results guarantee the traceability of factual evidence, the analytical framework ensures the inference path conforms to vehicle fault diagnosis logic, and the parameter-adjusted inference model ensures understanding of domain terminology and efficient local inference.

[0187] Step S404: Return the output of the inference model to the user's question.

[0188] Ultimately, the interactive system can return the output of the inference model to the user in a manner specified by the user. For example, in a vehicle infotainment screen or diagnostic instrument screen scenario, the inference results can be displayed through a graphical interface, including text descriptions, color-coded markers, and expandable complete knowledge evidence. In a voice interaction scenario, the interactive system can first read out the core conclusions and primary investigation suggestions via voice, and then display the complete text on the screen.

[0189] In the above embodiments, by using the graph database, document database, and vector index built in the vehicle function integration and debugging scenario as the knowledge base, and introducing an analysis framework for fault type matching and a reasoning model optimized for enterprise-side deployment environment in the interaction phase, a collaborative processing mechanism for knowledge retrieval, logical organization, constrained reasoning, and result feedback can be realized. This enables the professional knowledge in heterogeneous multimodal data to form a stable mapping around specific fault problems and be used for question-and-answer analysis, achieving efficient question-and-answer in the vehicle function integration and debugging process and improving the efficiency of users in solving integration and debugging problems.

[0190] For in-vehicle function integration scenarios, if a general large language model is used directly for user interaction and question answering, the problem of the large number of parameters of the general large language model will be faced. On the local side of the enterprise with limited hardware resources, it is often difficult to fully deploy such a large model. On the other hand, if a model with a smaller number of parameters is used, the problem of insufficient accuracy of the model output results or high model inference latency may be faced.

[0191] To address the aforementioned issues, embodiments of the present invention can compress the parameters of a general large language model by combining the hardware resource constraints of an in-vehicle function integration scenario, thereby obtaining an inference model that balances model performance and parameter quantity.

[0192] In one embodiment, the inference model is obtained as follows:

[0193] Based on at least one of the enterprise's local memory resources, computing power resources, accuracy requirements, and latency requirements, a suitable large language model is selected; the selected large language model is then subjected to parameter compression processing to obtain the inference model.

[0194] Parameter compression processing includes model distillation and / or model quantization. The local memory and computing resources available to the enterprise are related to the hardware and software resources provided for in-vehicle function integration testing. For example, how many servers the automaker has allocated for in-vehicle function integration testing, or how much computing power is allocated within its own server cluster for this purpose.

[0195] Large language models are used to provide general language understanding and generation capabilities. They are typically trained on large-scale corpora before being deployed on enterprise local machines, and can serve as the base model for inference models. Parameter compression is used to reduce the size of model parameters, memory usage, and inference computation while maintaining semantic understanding capabilities and text generation quality as much as possible, so as to adapt to the limited hardware conditions of enterprise computing resources.

[0196] Model distillation transfers the expressive power of a large model from the teacher network to a smaller student network, enabling the student network to still output inference results similar to those of the teacher network even with a reduced number of parameters. Model quantization converts model parameters and related calculations from a higher-precision representation to a lower-precision representation, thereby reducing storage bandwidth pressure and computational overhead.

[0197] In this embodiment of the invention, the interactive system can take into account factors such as the local memory capacity, available computing power, target response latency, and question-answering accuracy requirements of the enterprise, select the most suitable large language model from the pre-trained general large language models as the base model, and then perform parameter dimensionality reduction processing on the basis of the base model, so that the processed model has a smaller number of model parameters while meeting the accuracy and latency requirements, and can adapt to the resources of the enterprise's local end.

[0198] Figure 5 This is a schematic diagram of a parameter compression processing flow provided for an exemplary embodiment of the present invention. For example... Figure 5 As shown, the process may include large model selection and quantization, inputting hardware resource constraints such as memory, computing power and latency requirements, calculating the comprehensive score of candidate models during the selection and evaluation process, sorting them from high to low scores, selecting the candidate model with the highest score as the optimal model, and then determining whether the model meets the hardware resource constraints.

[0199] For example, the fit between the large language model and the enterprise's local resources and requirements can be calculated using the following formula:

[0200] (6)

[0201] In the above formula, S(M) represents the overall fitness degree, and R mem (M) represents memory compatibility, R comp (M) represents the computational capability fit, R acc (M) represents the precision fit, R latency (M) represents the inference delay fit, and 𝑤1, 𝑤2, 𝑤3, and 𝑤4 are weight coefficients that sum to 1.

[0202] (7)

[0203] In the above formula, Mem avail Mem indicates the available video memory in the hardware. weight Mem represents the GPU memory used by the model weights. kv Mem represents the video memory used by the KV (Key-Value) cache. others This indicates other video memory overhead.

[0204] (8)

[0205] In the above formula, TFLOP Savail FLOP represents the hardware's floating-point arithmetic capability. Sinference Latency represents the floating-point computational complexity of word reasoning. target This represents the upper limit of the expected inference delay (e.g., 1s).

[0206] (9)

[0207] In the above formula, Acc M Acc represents the model's prediction accuracy. min Acc represents the lowest accuracy of the candidate model. max This indicates the highest accuracy of the candidate model.

[0208] (10)

[0209] In the above formula, t inf t represents the actual inference latency of the model. target This represents the upper limit of the expected inference delay.

[0210] For example, after selecting a suitable large language model, in order to further reduce the consumption of model computing resources, the model weights can be compressed by model quantization. The quantization compression process can be expressed as the following formula (11):

[0211] (11)

[0212] In the above formula, W q W represents the quantized weight parameters. preThis represents the weight parameters before quantization; s>0 represents the quantization step size, z represents the zero offset, and q represents the weight parameters before quantization. min and q max These represent the smallest and largest integers of the quantized value, respectively; ⌊.⌋ represents the floor function, and clamp(⋅) represents the truncation function.

[0213] In the above embodiments, the inference model receives structured prompts on the enterprise's local end, performs inference, and outputs analysis results corresponding to the user's question. Due to parameter compression, the model can complete local inference with lower GPU memory usage, avoiding complete reliance on the external cloud for the question-and-answer process, thus reducing additional latency caused by network transmission and lowering computational resource consumption in the in-vehicle environment. By compressing the pre-trained large language model into an inference model adapted to the enterprise's local resource conditions, the interactive system can maintain a faster response speed in in-vehicle function integration scenarios and maintain relatively stable answer quality under resource constraints.

[0214] Figure 6 This is a schematic diagram of the structure of an in-vehicle function integration and interaction system provided as an exemplary embodiment of the present invention. (See diagram below.) Figure 6 As shown, original documents containing knowledge of in-vehicle function integration can be obtained through web page input or API calls. Then, structured text and images are obtained through chained parsing, followed by segmentation. The segmented text blocks are then vectorized using an embedding model to construct vector indexes, forming a knowledge base. During question-and-answer interactions with users, the knowledge base can be searched based on user questions, and prompts can be constructed using the search results. Finally, an answer is output through a locally deployed inference model.

[0215] Figure 7 This is a schematic diagram of a knowledge base construction apparatus provided as an exemplary embodiment of the present invention. (See diagram below.) Figure 7 As shown, the knowledge base construction device 700 may include:

[0216] The acquisition module 701 is used to acquire the original document and the pre-built ontology model. The ontology model includes core classes and the relationships between core classes. The core classes include the vehicle's electronic control unit, signals and fault diagnosis elements. The original document contains text and images related to the core classes.

[0217] Extraction module 702 is used to extract entities and relationships from the text in the original document according to the core class and relationship, and store the extracted entities and relationships into the graph database.

[0218] The processing module 703 is used to split the text into multiple text blocks according to the extracted entities and relationships, associate the image with the corresponding text block, and store the text block and image into the document database after association.

[0219] The index building module 704 is used to build vector indexes for graph databases and document databases, forming a knowledge base that includes graph databases, document databases, and vector indexes.

[0220] In some possible implementations, the processing module 703 can also be used to: perform semantic recognition on the image to obtain image description text; and embed the image description text and the image reference address into the corresponding text block.

[0221] In some possible implementations, the processing module 703 can also be used to: upload the image to the object storage system of the server to obtain the web page access address of the image; determine the text block corresponding to the image from multiple text blocks based on the semantic matching degree between the image description text and each text block, as well as the position of the image in the original document; and embed the image description text and the web page access address into the text block corresponding to the image.

[0222] In some possible implementations, the processing module 703 can also be used to: identify a set of entities in the text that belong to the same fault diagnosis element chain, wherein the fault diagnosis element chain is formed by linking multiple entities in the fault phenomenon, fault associated signal characteristics, fault cause, solution measures and test methods in a relational manner; and for the text content describing the same fault diagnosis element chain, split the part of the text content corresponding to each entity into a separate text block.

[0223] In some possible implementations, the index building module 704 can also be used to: map text blocks in the document database to a high-dimensional vector space to generate a vector set; build a graph index based on the vector set, wherein the graph index is a multi-level graph structure, and the nodes in each level of the graph are associated with vectors and scalar attribute vectors; and, during retrieval, perform condition pushing in each level of the graph index based on the query vector and filtering conditions, calculate the distance to nodes that meet the filtering conditions, and generate a candidate result set.

[0224] In some possible implementations, the index building module 704 can also be used to: divide the vectors into high-frequency access vectors and low-frequency access vectors according to the access frequency of each vector in the vector set; store the high-frequency access vectors in memory in a compressed format and store the low-frequency access vectors in a full-precision format in a local persistent storage medium; and prioritize accessing the high-frequency access vectors in memory for distance calculation during retrieval.

[0225] In some possible implementations, the index building module 704 can also be used to: horizontally shard the vector data in the vector set based on the centroid vector or metadata field; during retrieval, calculate the distance between the query vector and the centroid of each shard, and select the candidate shard set in ascending order of distance; dynamically allocate the number of candidates to be returned for each candidate shard, wherein the number of candidates allocated to each shard is proportional to the probability that the shard is selected as the nearest neighbor region; after each candidate shard performs retrieval independently, the coordinating node merges the retrieval results and reorders them to output the final result.

[0226] Figure 8 This is a schematic diagram of the structure of an interactive device provided for an exemplary embodiment of the present invention. For example... Figure 8 As shown, the interactive device 800 may include:

[0227] The acquisition module 801 is used to acquire user questions and knowledge retrieval results retrieved from the knowledge base based on user questions. The knowledge base is constructed using any of the above knowledge base construction methods.

[0228] The framework generation module 802 is used to generate an analysis framework that matches the fault type of the user's problem based on the user's problem and the knowledge retrieval results.

[0229] The prompt word engineering module 803 is used to assemble user questions, knowledge retrieval results and analysis framework into structured prompt words, and input the prompt words into a pre-deployed inference model, which is obtained by adjusting the parameters based on a large language model;

[0230] Output module 804 is used to return the output results of the inference model to the user in response to the user's question.

[0231] In some possible implementations, the acquisition module 801 can also be used to: select an appropriate large language model based on at least one of the enterprise's local memory resources, computing power resources, accuracy requirements, and latency requirements; perform parameter compression processing on the selected large language model to obtain an inference model, wherein the parameter compression processing includes model distillation and / or model quantization.

[0232] The interactive device provided in this embodiment is used to execute the technical solutions in any of the foregoing method embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0233] It should be understood that the above-described device embodiments are merely illustrative, and the device of the present invention can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0234] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of the present invention can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0235] Figure 9 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of the present invention. For example... Figure 9 As shown, the electronic device 90 includes:

[0236] Processor 91, memory 92, and communication interface 93;

[0237] The memory 92 is used to store the executable instructions of the processor 91; the executable instructions can be instructions that the computer can execute.

[0238] The processor 91 is configured to execute the technical solutions in any of the foregoing method embodiments by executing executable instructions.

[0239] Optionally, the memory 92 can be either standalone or integrated with the processor 91.

[0240] Optionally, when the memory 92 is a device independent of the processor 91, the electronic device 90 may further include:

[0241] Bus 94, memory 92 and communication interface 93 are connected to processor 91 through bus 94 and complete communication with each other. Communication interface 93 is used to communicate with other devices.

[0242] Optionally, the communication interface 93 can be implemented using a transceiver. The communication interface is used to enable communication between the database access device and other devices (e.g., clients, read-write databases, and read-only databases). The memory may include random access memory (RAM) and may also include non-volatile memory, such as at least one disk drive.

[0243] Bus 94 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one line is used in the diagram, but this does not imply that there is only one bus or one type of bus.

[0244] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be 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, or discrete hardware components.

[0245] The electronic device is used to execute the technical solutions in any of the foregoing method embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0246] This invention also provides a readable storage medium, which can be a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the technical solution provided in any of the foregoing method embodiments.

[0247] This invention also provides a computer program product, including a computer program, which, when executed by a processor, is used to implement the technical solutions provided in any of the foregoing method embodiments.

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

[0249] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0250] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the following claims.

[0251] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A method for constructing a knowledge base, characterized in that, include: Obtain the original document and the pre-built ontology model, which includes core classes and the relationships between them. The core classes include the vehicle's electronic control unit, signals, and fault diagnosis elements. The original document contains text and images related to the core classes. Based on the core classes and relationships, entity and relation extraction is performed on the text in the original document, and the extracted entities and relations are stored in the graph database. Based on the extracted entities and relationships, the text is split into multiple text blocks, and the image is associated with the corresponding text block. After association, the text block and the image are stored in the document database. For the graph database and the document database, a vector index is constructed to form a knowledge base containing the graph database, the document database, and the vector index.

2. The method according to claim 1, characterized in that, Associating the image with the corresponding text block includes: Semantic recognition is performed on the image to obtain image description text; The image description text and the image's reference address are embedded in the corresponding text block.

3. The method according to claim 2, characterized in that, The reference address is a webpage access address. Embedding the image description text and the image's reference address into the corresponding text block includes: The image is uploaded to the object storage system of the server to obtain the web page access address of the image; Based on the semantic matching degree between the image description text and each text block, and the position of the image in the original document, the text block corresponding to the image is determined among the plurality of text blocks; The image description text and the webpage access address are embedded in the text block corresponding to the image.

4. The method according to any one of claims 1 to 3, characterized in that, The step of splitting the text into multiple text blocks according to the extracted entities and relationships includes: Identify the set of entities in the text that belong to the same fault diagnosis element chain, which is formed by linking multiple entities in the fault phenomenon, fault-related signal characteristics, fault causes, solutions and testing methods according to their relationships. For text content describing the same fault diagnosis element chain, the portion of the text content corresponding to each entity is split into separate text blocks.

5. The method according to any one of claims 1 to 3, characterized in that, The construction of the vector index includes: Map the text blocks in the document database to a high-dimensional vector space to generate a vector set; A graph index is constructed based on the vector set. The graph index is a multi-layer graph structure, with node association vectors and scalar attribute vectors in each layer of the graph. During retrieval, based on the query vector and filtering conditions, conditional pushdown is performed in each layer traversal of the graph index to calculate the distance to nodes that meet the filtering conditions and generate a candidate result set.

6. The method according to claim 5, characterized in that, Also includes: Based on the access frequency of each vector in the vector set, the vectors are divided into high-frequency access vectors and low-frequency access vectors. The high-frequency access vector is stored in memory in a compressed format, and the low-frequency access vector is stored in a local persistent storage medium in full-precision format. During retrieval, the frequently accessed vectors in memory are prioritized for distance calculation.

7. The method according to claim 5, characterized in that, Also includes: The vector data in the vector set is horizontally partitioned based on the centroid vector or metadata field; During retrieval, the distance between the query vector and the centroid of each segment is calculated, and the candidate segment set is selected in ascending order of distance. The number of candidates to be returned is dynamically allocated to each candidate segment, where the number of candidates allocated to each segment is proportional to the probability that the segment is selected as the nearest neighbor region. After each candidate segment performs retrieval independently, the retrieval results are merged and reordered by the coordinating node, and the final result is output.

8. An interaction method, characterized in that, include: The method involves obtaining user questions and knowledge retrieval results retrieved from a knowledge base based on those user questions, wherein the knowledge base is constructed according to the knowledge base construction method described in any one of claims 1 to 7. Based on the user question and the knowledge retrieval results, an analysis framework matching the fault type of the user question is generated; The user question, the knowledge retrieval result, and the analysis framework are assembled into structured prompt words, and the prompt words are input into a pre-deployed inference model, which is obtained by adjusting the parameters based on a large language model. The inference model returns the output of the inference model to the user's question.

9. The method according to claim 8, characterized in that, The reasoning model is obtained in the following way: Select the appropriate large language model based on at least one of the enterprise's local memory resources, computing power resources, accuracy requirements, and latency requirements. The selected large language model is subjected to parameter compression processing to obtain an inference model. The parameter compression processing includes model distillation and / or model quantization.

10. A knowledge base construction apparatus, characterized in that, include: The acquisition module is used to acquire the original document and the pre-built ontology model. The ontology model includes core classes and the relationships between core classes. The core classes include the vehicle's electronic control unit, signals, and fault diagnosis elements. The original document contains text and images related to the core classes. The extraction module is used to extract entities and relationships from the text in the original document according to the core class and relationship, and store the extracted entities and relationships into the graph database. The processing module is used to split the text into multiple text blocks according to the extracted entities and relationships, associate the image with the corresponding text block, and store the text block and the image into the document database after association. An index building module is used to build vector indexes for the graph database and the document database, forming a knowledge base that includes the graph database, the document database, and the vector indexes.

11. An interactive device, characterized in that, include: The acquisition module is used to acquire user questions and knowledge retrieval results retrieved from a knowledge base based on the user questions, wherein the knowledge base is constructed using the knowledge base construction method as described in any one of claims 1 to 7. The framework generation module is used to generate an analysis framework that matches the fault type of the user problem based on the user problem and the knowledge retrieval result. The prompt word engineering module is used to assemble the user question, the knowledge retrieval result and the analysis framework into structured prompt words, and input the prompt words into a pre-deployed inference model, which is obtained by adjusting the parameters based on a large language model; The output module is used to return the output results of the inference model to the user in response to the user's question.

12. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 9.

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

14. A computer program product, characterized in that, Includes a computer program, which, when executed, implements the method of any one of claims 1 to 9.

Images