An automobile software development requirement document management system and method

Abstract

The application provides a kind of automobile software development demand document management system and method, the system includes: preprocessing module, for receiving software development demand related multi-source raw data, data is preprocessed, and through sliding window, raw data is divided into text block;Atlas construction module, for extracting structured knowledge in each text block by fine-tuning after big language model, and constructing knowledge graph, indexing knowledge graph into database;Retrieval reasoning module, for receiving user input query request, query request is parsed, and based on vector retrieval and graph enhanced retrieval, retrieval result and original query request input generative big language model, obtain query result.Parameter optimization module, for periodically evaluating query result by optimizer, and optimizing the parameter configuration of text block, extraction retrieval strategy.By the scheme, the efficiency of knowledge graph construction can be improved, and the adaptability of document retrieval under multi-hop query is enhanced.

Description

Technical Field

[0001] This invention belongs to the field of software development technology, and in particular relates to an automotive software development requirements document management system and method. Background Technology

[0002] In automotive software development, requirement documents are typically in natural language or semi-structured form, which makes requirement tracking, change management, and consistency verification difficult. Existing management tools, such as DOORS and Jama, mainly rely on relational databases or document management systems, lacking semantic understanding and reasoning capabilities, resulting in deficiencies in the accuracy and reliability of document retrieval.

[0003] In recent years, knowledge graph technology has been gradually applied to the software development field. For example, the GraphRAG framework proposed by Microsoft Research enhances retrieval capabilities by constructing knowledge graphs. This framework uses LLMs to extract entities and relations from documents and utilizes community detection algorithms to partition the graph. However, this framework has certain limitations. It relies on predefined fixed patterns in the knowledge extraction process and is mainly based on graph structure similarity retrieval, making it less adaptable to the multi-hop complex query requests common in automotive software development.

[0004] Another related approach, such as "Knowledge Graph Prompting for Multi-Document Question Answering" (Wang et al.), proposes the application of knowledge graphs in complex question answering. This method performs multi-document reasoning through graph traversal, which can achieve multi-hop question answering. However, when dealing with multi-source heterogeneous data such as automotive software requirement documents, the graph construction process usually requires manual intervention, resulting in low data processing efficiency. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide an automotive software development requirements document management system and method to solve the problems of poor adaptability of current document retrieval and low efficiency of map construction.

[0006] In a first aspect of the present invention, an automotive software development requirements document management system is provided, comprising: The preprocessing module is used to receive multi-source raw data related to software development requirements, preprocess the multi-source raw data, and divide the raw data into text blocks through a sliding window of a predetermined size. The knowledge graph construction module is used to extract structured knowledge from each text block through a fine-tuned large language model, construct a knowledge graph, and index the knowledge graph into a database, which includes at least a graph database, a vector database, and a relational database. The retrieval and reasoning module receives user-input query requests, parses the query requests, and, based on vector retrieval and graph augmentation retrieval, inputs triples retrieved from the knowledge graph, text fragments, and the original query request into the generative large language model to obtain query results.

[0007] The parameter optimization module is used to periodically evaluate query results through the optimizer and optimize the parameter configurations of text block size, knowledge extraction strategy, and retrieval strategy.

[0008] In a second aspect of the present invention, a method for managing automotive software development requirements documents is provided, comprising: Receive multi-source raw data related to software development requirements, preprocess the multi-source raw data, and divide the raw data into text blocks through a sliding window of a predetermined size; Structured knowledge is extracted from each text block using a fine-tuned large language model, and a knowledge graph is constructed. The knowledge graph is then indexed into a database, which includes at least a graph database, a vector database, and a relational database. The system receives query requests from users, parses the query requests, and, based on vector retrieval and graph augmentation retrieval, inputs triples retrieved from the knowledge graph, text fragments, and the original query request into the generative large language model to obtain query results.

[0009] The optimizer periodically evaluates query results and optimizes the parameter configurations for text block size, knowledge extraction strategy, and retrieval strategy.

[0010] In a third aspect of the present invention, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the steps of the method as described in the first aspect of the present invention.

[0011] In a fourth aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method provided in the first aspect of the present invention.

[0012] In this embodiment of the invention, based on multi-source raw preprocessing and segmentation, structured knowledge is automatically extracted using a large language model to generate a knowledge graph. Query results are then obtained through vector retrieval and graph augmentation retrieval. Furthermore, an optimizer provides feedback optimization to the segmentation, knowledge extraction, and retrieval processes. This not only improves the efficiency of processing requirement document data, avoids manual intervention, and ensures multimodal data processing capabilities, but also effectively enhances adaptability to complex multi-hop query requests based on hybrid retrieval. Simultaneously, through continuous optimization by the optimizer, the system achieves adaptive optimization and improves accuracy and reliability under complex query requests. Attached Figure Description

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

[0014] Figure 1 This is a schematic diagram of the structure of an automotive software development requirements document management system according to an embodiment of the present invention; Figure 2 An interactive timing diagram of an automotive software development requirements document management system provided in one embodiment of the present invention; Figure 3 A flowchart illustrating a method for managing automotive software development requirements documents, provided as an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present invention. Detailed Implementation

[0015] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0016] It should be understood that the terms "comprising" and other similar expressions in the specification, claims, and accompanying drawings of this invention are intended to cover a non-exclusive inclusion, such as a process, method, system, or apparatus that includes a series of steps or units and is not limited to the listed steps or units. Furthermore, "first" and "second" are used to distinguish different objects and are not intended to describe a specific order.

[0017] In one embodiment, the core hardware architecture of the automotive software development requirements document management system may include: The computing server is used to perform core computing tasks such as preprocessing of multi-source data, knowledge graph construction, large-scale model training, intelligent retrieval, and query result generation. This server can be configured with high-performance multi-core CPUs (such as Intel Xeon series), large-capacity memory (no less than 64GB), and GPU accelerator cards (such as NVIDIA Tesla series) to support the inference and training processes of large-scale language models (LLMs).

[0018] Data storage systems include graph database servers, vector database servers, and relational database servers; The graph database server uses graph databases such as Neo4j to store and manage the nodes (entities), edges (relationships) and their attributes of the knowledge graph, providing efficient multi-hop query and graph traversal capabilities. Vector database servers are used to store vector representations of document blocks and entities generated by text embedding models, supporting fast retrieval of high-dimensional vector similarity; Relational database servers are used to store system metadata, user information, operation logs, and highly structured requirement entries and version information.

[0019] Network equipment, including switches and routers, ensures high-speed, reliable data transmission between servers and clients, as well as between various storage subsystems.

[0020] Client devices are terminals used by developers or requirements engineers, such as personal computers or workstations, to access the system via a browser or dedicated client software.

[0021] The hardware components are connected and work together via a high-speed local area network or data center internal network. In terms of software architecture, the system adopts a layered design, including a data access layer, a knowledge processing layer, a service layer, and an application layer.

[0022] Please see Figure 1 The present invention provides a schematic diagram of the structure of an automotive software development requirements document management system, comprising: The preprocessing module 110 is used to receive multi-source raw data related to software development requirements, preprocess the multi-source raw data, and divide the raw data into text blocks through a sliding window of a predetermined size. Multi-source raw data refers to raw data related to automotive software development requirements collected from different sources. This may include: unstructured documents, such as Software Requirements Specifications (SRS) in Word or PDF format, AUTOSAR standard documents, design specifications, etc.; semi-structured data, such as SysML or Simulink model files, requirement documents containing tables; and structured data, such as exported files from requirement management tools (such as DOORS), bills of materials in configuration item databases (CMDB), etc.

[0023] Preprocessing can transform multi-source raw data into normalized text data in order to perform data chunking processing.

[0024] Optionally, the plain text content can be extracted from the multi-source raw data, and after data cleaning, word segmentation can be performed.

[0025] Libraries such as Apache POI and PDFBox are used to parse document formats and extract plain text content. For model files, corresponding parsers can be used to extract model elements and relationships. Data cleaning is used to remove meaningless special characters and stop words. Word segmentation is the process of dividing a continuous text sequence into semantically independent lexical units.

[0026] Using the sliding window algorithm, long documents can be segmented into semantically relatively complete text blocks based on a preset block size (e.g., 512 tokens) to balance the efficiency of subsequent processing and information integrity. The block size is an adjustable hyperparameter, typically ranging from 200 to 2000 tokens.

[0027] In some embodiments, the preprocessing module 110 may include a data interface adapter, a file parser, and a data cleaning engine.

[0028] The knowledge graph construction module 120 is used to extract structured knowledge from each text block through a fine-tuned large language model, construct a knowledge graph, and index the knowledge graph into a database, which includes at least a graph database, a vector database, and a relational database. Fine-tuned large language models (LLMs) can be used for Transformer-based models (such as BERT and ERNIE) and combined with Conditional Random Fields (CRF) or Bidirectional Long Short-Term Memory Networks (Bi-LSTM) for sequence labeling to improve entity recognition accuracy. At the same time, entity-relationship patterns can be predefined within the model for the automotive software domain.

[0029] The structured knowledge mentioned is generally a fixed knowledge structure, which can include entities, attributes, and relationships. A knowledge graph is a semantic network that describes the objective world in a graph structure; its essence is a knowledge base that describes concepts, entities, and their relationships.

[0030] After extracting structured knowledge based on a large language model, the extracted knowledge can be indexed into multiple storage systems, including graph databases (for symbol queries), vector databases (for similarity retrieval), and relational databases (for metadata management). These storage systems work collaboratively and support hybrid query interfaces.

[0031] Specifically, based on entity-relationship schemas and predefined prompt word templates, structured knowledge is extracted from each text block, including entities, attributes, and relationships. Analyze the semantic relationships between entities and extract triples in the form of subject, relation, and object; The identified entities are resolved by dereference and entity disambiguation, and synonymous entities are merged using a similarity calculation algorithm.

[0032] Structured knowledge is extracted from text blocks using a large model based on a predefined pattern (such as an entity-relationship model) and cue word templates. The extraction process is controlled by the configured cue word templates to adjust the output granularity.

[0033] Entity types can include requirements (e.g., "brake response time < 100ms"), software components (e.g., "brake control module"), test cases, standards and regulations (e.g., "ISO 26262 ASIL-D"), hardware components (e.g., "wheel speed sensor"), developers, etc. Relationship types can include refinement to, trace to, depend on, conflict with, verify with, belong to, etc.

[0034] The segmented text is input into a large language model, which identifies and labels entity references in the text based on predefined entity types. For example, from the sentence "ABS control module should receive signals from wheel speed sensors," the model identifies "ABS control module" (software component) and "wheel speed sensor" (hardware component). The model further analyzes the semantic relationships between entities, extracting triples in the form of (subject, relation, object). For example, the extracted triples are (ABS control module, receive signal, wheel speed sensor).

[0035] Identified entities undergo referential resolution (e.g., "ECU" and "electronic control unit" refer to the same entity) and entity disambiguation (distinguishing the meaning of "bus" in different contexts). Synonymous entities are merged using similarity calculation algorithms (such as vector-based algorithms).

[0036] The cleaned and merged triples are imported into the Neo4j graph database and associated with the vector and relational databases. Each entity is treated as a node, and relations as edges. Entity attributes (such as requirement ID, version number, and creation time) are stored as attributes of nodes or edges.

[0037] The retrieval reasoning module 130 is used to receive query requests input by the user, parse the query requests, and input the triples retrieved from the knowledge graph, text fragments, and the original query requests into the generative large language model based on vector retrieval and graph augmentation retrieval to obtain query results.

[0038] Vector retrieval finds semantically similar text content using vectors, while graph-enhanced retrieval finds matching nodes and paths in a knowledge graph based on entities.

[0039] After receiving a user's natural language query, the system parses the query to identify the query intent and key entities. Based on the configured retrieval strategy (e.g., priority graph retrieval), relevant information is retrieved from the knowledge graph and vector library. The retrieved triples, text fragments, and other contextual information are then input along with the original query into a generative large language model. This model can be a component of the system or call an external API to synthesize an easily understandable natural language answer.

[0040] This involves converting the user's query into a vector and then searching the vector database for the text block with the most similar semantics as the context text fragment. The key entities in the user's query request are matched with nodes in the knowledge graph. Through graph traversal algorithms, related nodes and paths are found to obtain triples.

[0041] Vector retrieval strategies retrieve text blocks based on dense vector similarity. Graph-enhanced retrieval strategies combine vector similarity and graph structure traversal to retrieve knowledge graph nodes and their associated triples, formatting the results into structured text. For example, querying "all software components related to Functional Safety Requirement FSR-001" will locate the FSR-001 node and then traverse all software component nodes that trace back to or are refined to that requirement. This strategy emphasizes relational context and supports multi-hop reasoning.

[0042] In some embodiments, vector retrieval is used to find relevant text blocks first, and then graph retrieval is used to expand the associated knowledge, which can provide a more comprehensive context.

[0043] The number of search contexts can be controlled by the top-k parameter (range 1-20) to adjust search coverage and generation quality.

[0044] The parameter optimization module 140 is used to periodically evaluate the query results through the optimizer and optimize the parameter configuration of text block size, knowledge extraction strategy and retrieval strategy.

[0045] The optimizer can collect query results and their corresponding parameter configurations for evaluation. By continuously updating the parameter configurations, it optimizes the preprocessing module, graph construction module, and retrieval inference module. The parameters for the knowledge extraction strategy can be the prompt word template type, while the parameters for the retrieval strategy can be the retrieval strategy type (e.g., the order of graph retrieval and vector retrieval), top-k value, etc.

[0046] In some embodiments, optimization target parameters may include text block size, retrieval strategy type, top-k value, prompt word template type, and task processing method. These parameters affect the entire process of knowledge extraction, retrieval, and generation.

[0047] Preferably, the optimizer is a tree-structured Parzen estimator, which constructs a probability density model for each parameter to be optimized.

[0048] The tree-structured Parzen estimator (TPE) is used for efficient search, and the algorithm is applicable to mixed-type (categorical and numerical) parameter spaces.

[0049] Understandably, the optimizer employs the Tree-structured Parzen Estimator (TPE) as its core algorithm, which is based on Bayesian optimization principles. The TPE algorithm models the relationship between parameters and the objective function by establishing a probability density function, creating probability distribution models for both high-performing and low-performing parameter configurations. The optimization process is based on the Expected Improvement (EI) criterion, which balances exploration and exploitation. The EI function tends to select parameter regions that may significantly improve performance while avoiding excessive local searches. For mixed-type parameter spaces (including continuous, discrete, and categorical parameters), the optimizer uses a hierarchical modeling approach, allowing different types of parameters to be modeled using different probability distributions, ensuring the efficiency of the search process.

[0050] In this embodiment, the TPE algorithm effectively handles the search problem in a complex multi-parameter space. Compared to traditional grid search and random search, the TPE algorithm achieves superior performance with the same number of trials. Furthermore, through an intelligent sampling strategy, the TPE algorithm finds a near-optimal configuration with the fewest trials, significantly reducing the time cost and computational resource consumption of the optimization process.

[0051] The optimization process uses overall system performance as the objective function and seeks the optimal configuration through multiple independent trials. Each trial corresponds to a complete pipeline run, from data intake to answer generation, and is evaluated using multi-hop question-answering benchmarks (such as HotPotQA and MuSiQue). Scoring metrics may include exact match (EM), token-level F1, and correctness scores based on large language models.

[0052] Filtered multi-hop question-answering instances (e.g., 24 training samples and 12 test samples) are used to ensure data quality and avoid bias. Scoring tools based on large language models (such as DeepEval) are introduced to perform semantic-level evaluation of the generated answers. Performance confidence intervals are calculated through bootstrap resampling, and a confidence-based report is output. Evaluation results are used to feed back into the optimization process, forming a closed-loop tuning.

[0053] After a user inputs a query, knowledge retrieval and generation are performed based on the current configuration. The parameter optimization module periodically re-evaluates the parameter configuration to adapt to task changes. This embodiment reduces the need for manual intervention and improves the system's robustness in complex tasks through modular design and automated optimization.

[0054] In one embodiment, the parameter optimization module 140 includes: The parameter definition unit is used to define the adjustable parameter configuration space; The data collection unit is used to collect historical query requests and query results, as well as corresponding parameter configurations; The probability density calculation unit is used to construct two probability density functions. By calculating and comparing the ratio of these two density functions, the next sampling direction for the parameter configuration of the historical query request is determined. The candidate configuration generation unit is used to generate new candidate parameter configurations based on the calculation results of the probability density function. The execution evaluation unit is used to configure each candidate parameter as an independent experiment, perform knowledge graph construction, indexing, retrieval and query result generation, and evaluate the query results using multi-dimensional metrics. The iterative update module is used to recalculate the density function based on the evaluation results, adjust the sampling direction of the parameter space, and update the weight coefficients until the performance evaluation results converge. The parameter definition unit first defines the complete adjustable parameter space, including block size, retrieval strategy parameters, context quantity parameters (top-k values), cue template parameters, and task processing parameters (variants of different preprocessing methods). In the initial phase, a set of initial configurations, typically 20-30 test cases, is generated through random sampling to establish the basic probabilistic model. Then, the data collection unit collects historical experimental data, and the probability density calculation unit constructs a probability density function and calculates its proportion. Two probability density functions are constructed based on the historical experimental results: The optimal configuration density function l(x) is based on the experimental configurations that rank in the top 25% in terms of performance. Poor configuration density function g(x): based on the experimental configurations ranked in the bottom 75% for performance.

[0055] By comparing the ratio of these two density functions, the direction of the next sampling step can be determined.

[0056] The candidate configuration generation unit is used to generate and select appropriate candidate configurations. Based on the probability density function, the optimizer generates new candidate configurations: sampling from the good density function l(x), prioritizing parameter regions with good historical performance; and sampling from the bad density function g(x), moderately exploring new regions to avoid local optima. Furthermore, parameter correlation analysis is performed to identify the interactions between parameters.

[0057] The execution evaluation unit is used to execute experiments in parallel and evaluate the experimental results. Each candidate configuration executes a complete pipeline as an independent experiment: knowledge graph construction and indexing, retrieval and generation processes, and multi-metric performance evaluation.

[0058] The iterative update module is used to iteratively update the model and output the optimal parameter configuration. It updates the probabilistic model based on new experimental results: recalculates the density functions l(x) and g(x); adjusts the exploration strategy of the parameter space; and updates the weight coefficients of the desired improvement function.

[0059] In some embodiments, the optimizer integrates a convergence detection mechanism, which automatically adjusts the search strategy or terminates the optimization process when the performance improvement in multiple consecutive iterations is less than a threshold (e.g., 1%). For multiple evaluation metrics, the optimizer supports weighted combination or Pareto optimal search to ensure a balance between the requirements of different metrics. After finding the optimal configuration on the training set, the optimizer automatically validates it on the reserved test set to evaluate the generalization ability of the configuration, which can prevent overfitting.

[0060] The optimizer employs incremental model updates, avoiding the need to recalculate all historical data in each iteration. It supports asynchronous parallel experiment execution, improving hardware utilization. An early stopping mechanism terminates poorly performing experiments, optimizing computational efficiency. Experimental data is stored in a compressed format, and low-value historical data is periodically cleaned up. Checkpoint saving and recovery are supported. The optimizer architecture supports adding new parameter types and evaluation metrics, ensuring the system can adapt to future changes in requirements.

[0061] In one embodiment, the interaction sequence of the automotive software development requirements document management system is as follows: Figure 2 As shown in the figure, it includes a front-end interface, a retrieval and reasoning module, a graph database, a vector database, and an optimization module.

[0062] The front-end interface is used to receive and forward user query requests, and to return query results; The retrieval reasoning module is used to parse user query requests and, based on vector retrieval and graph augmentation retrieval, inputs the retrieval results and the original query request into a generative large language model to generate query results. The optimization module is used to analyze performance metrics based on historical query results and query performance data, and provide feedback on parameter optimization suggestions.

[0063] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0064] Figure 3 This invention provides a flowchart illustrating a method for managing automotive software development requirements documents, comprising: S301. Receive multi-source raw data related to software development requirements, preprocess the multi-source raw data, and divide the raw data into text blocks through a sliding window of a predetermined size. Optionally, the plain text content can be extracted from the multi-source raw data, and after data cleaning, word segmentation can be performed.

[0065] S302. Extract structured knowledge from each text block using the fine-tuned large language model, construct a knowledge graph, and index the knowledge graph into a database, wherein the database includes at least a graph database, a vector database, and a relational database. Specifically, based on entity-relationship schemas and predefined prompt word templates, structured knowledge is extracted from each text block, including entities, attributes, and relationships. Analyze the semantic relationships between entities and extract triples in the form of subject, relation, and object; The identified entities are resolved by dereference and entity disambiguation, and synonymous entities are merged using a similarity calculation algorithm.

[0066] S303. Receive the query request input by the user, parse the query request, and based on vector retrieval and graph augmentation retrieval, input the triples retrieved from the knowledge graph, text fragments, and the original query request into the generative large language model to obtain the query results.

[0067] This involves converting the user's query into a vector and then searching the vector database for the text block with the most similar semantics as the context text fragment. The key entities in the user's query request are matched with nodes in the knowledge graph. Through graph traversal algorithms, related nodes and paths are found to obtain triples.

[0068] S304. The optimizer periodically evaluates the query results and optimizes the parameter configurations of text block size, knowledge extraction strategy, and retrieval strategy.

[0069] Preferably, the optimizer is a tree-structured Parzen estimator, which constructs a probability density model for each parameter to be optimized.

[0070] Optionally, the step of periodically evaluating the query results through the optimizer and optimizing the parameter configurations of text block size, knowledge extraction strategy, and retrieval strategy includes: Define the adjustable parameter configuration space; Collect historical query requests and query results, along with corresponding parameter configurations; Two probability density functions are constructed, and the next sampling direction for the parameter configuration of historical query requests is determined by calculating and comparing the ratio of these two density functions. Based on the probability density function calculation results, new candidate parameter configurations are generated. Each candidate configuration is treated as an independent experiment, executing the knowledge graph construction, indexing, retrieval, and query result generation processes, and evaluating the query results using multi-dimensional metrics. Based on the evaluation results, the density function is recalculated, the sampling direction of the parameter space is adjusted, and the weight coefficients are updated until the performance evaluation results converge. The objective function for parameter optimization (such as the F1 score of a demand query) is constructed. The optimizer conducts multiple rounds of trials within a specified parameter space, running the system in each round using a set of parameter configurations. The system performance under this set of parameters is evaluated on a reserved validation set. Based on historical trial results, the optimizer generates the next set of parameter configurations that are more likely to improve performance using a probabilistic model. This process is iterated until a predetermined number of trials is reached or performance convergence occurs. Finally, the optimal parameter configuration is applied to the production system.

[0071] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the system and modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0072] Figure 4 This is a schematic diagram of an electronic device according to an embodiment of the present invention. The electronic device is used for managing requirements documents for automotive software. Figure 4 As shown, the electronic device 40 of this embodiment includes a memory 410, a processor 420, and a system bus 430. The memory 410 includes an executable program 4101 stored thereon. As those skilled in the art will understand, Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0073] The following is combined Figure 4A detailed introduction to each component of the electronic device: The memory 410 can be used to store software programs and modules. The processor 420 executes various functional applications and data processing of the electronic device by running the software programs and modules stored in the memory 410. The memory 410 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device (such as cached data), etc. In addition, the memory 410 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0074] The memory 410 contains an executable program 4101 for a requirements document management method. This executable program 4101 can be divided into one or more modules / units, which are stored in the memory 410 and executed by the processor 420 to perform tasks such as knowledge graph construction and document retrieval. Each module / unit can be a series of computer program instruction segments capable of performing a specific function, describing the execution process of the computer program 4101 in the electronic device 40. For example, the computer program 4101 can be divided into functional modules such as a preprocessing module, a knowledge graph construction module, a retrieval reasoning module, and a parameter optimization module.

[0075] Processor 420 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 410, and by calling data stored in memory 410, it performs various functions and processes data, thereby monitoring the overall status of the electronic device. Optionally, processor 420 may include one or more processing units; preferably, processor 420 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, application programs, etc., and the modem processor mainly handles wireless communication. It is understood that the aforementioned modem processor may not be integrated into processor 420.

[0076] The system bus 430 is used to connect various functional components inside the computer, transmitting data, address, and control information. Its type can be, for example, a PCI bus, an ISA bus, or a CAN bus. Instructions from the processor 420 are transmitted to the memory 410 via the bus, and the memory 410 sends data back to the processor 420. The system bus 430 is responsible for data and instruction exchange between the processor 420 and the memory 410. Of course, the system bus 430 can also connect to other devices, such as network interfaces and display devices.

[0077] In this embodiment of the invention, the executable program executed by the processor 420 included in the electronic device includes: Receive multi-source raw data related to software development requirements, preprocess the multi-source raw data, and divide the raw data into text blocks through a sliding window of a predetermined size; Structured knowledge is extracted from each text block using a fine-tuned large language model, and a knowledge graph is constructed. The knowledge graph is then indexed into a database, which includes at least a graph database, a vector database, and a relational database. The system receives query requests from users, parses the query requests, and, based on vector retrieval and graph augmentation retrieval, inputs triples retrieved from the knowledge graph, text fragments, and the original query request into the generative large language model to obtain query results.

[0078] The optimizer periodically evaluates query results and optimizes the parameter configurations for text block size, knowledge extraction strategy, and retrieval strategy.

[0079] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

Claims

1. A vehicle software development requirements document management system, characterized in that, include: The preprocessing module is used to receive multi-source raw data related to software development requirements, preprocess the multi-source raw data, and divide the raw data into text blocks through a sliding window of a predetermined size. The knowledge graph construction module is used to extract structured knowledge from each text block through a fine-tuned large language model, construct a knowledge graph, and index the knowledge graph into a database, which includes at least a graph database, a vector database, and a relational database. The retrieval and reasoning module receives user-input query requests, parses the query requests, and, based on vector retrieval and graph augmentation retrieval, inputs triples retrieved from the knowledge graph, text fragments, and the original query request into the generative large language model to obtain query results.

2. Parameter optimization module, which is used to periodically evaluate query results through the optimizer and optimize the parameter configuration of text block size, knowledge extraction strategy and retrieval strategy.

3. The system according to claim 1, characterized in that, The preprocessing of the multi-source raw data includes: The system parses raw data from multiple sources to extract plain text content, cleans the text content, and then performs word segmentation.

4. The system according to claim 1, characterized in that, The step of extracting structured knowledge from each text block using a fine-tuned large language model and constructing a knowledge graph includes: Based on entity-relationship schemas and predefined prompt word templates, structured knowledge is extracted from each text block, including entities, attributes, and relationships. Analyze the semantic relationships between entities and extract triples in the form of subject, relation, and object; The identified entities are resolved by dereference and entity disambiguation, and synonymous entities are merged using a similarity calculation algorithm.

5. The system according to claim 1, characterized in that, The process of parsing the query request and, based on vector retrieval and graph augmentation retrieval, inputting the triples retrieved from the knowledge graph, text fragments, and the original query request into the generative large language model includes: The user's query is converted into a vector, and the most semantically similar text block is retrieved from the vector database as the context text fragment. The key entities in the user's query request are matched with nodes in the knowledge graph. Through graph traversal algorithms, related nodes and paths are found to obtain triples.

6. The system according to claim 1, characterized in that, The optimizer is a tree-structured Parzen estimator, which constructs a probability density model for each parameter to be optimized.

7. The system according to claim 1, characterized in that, The parameter optimization module includes: The parameter definition unit is used to define the adjustable parameter configuration space; The data collection unit is used to collect historical query requests and query results, as well as corresponding parameter configurations; The probability density calculation unit is used to construct two probability density functions. By calculating and comparing the ratio of these two density functions, the next sampling direction for the parameter configuration of the historical query request is determined. The candidate configuration generation unit is used to generate new candidate parameter configurations based on the calculation results of the probability density function. The execution evaluation unit is used to configure each candidate parameter as an independent experiment, perform knowledge graph construction, indexing, retrieval and query result generation, and evaluate the query results using multi-dimensional metrics. The iterative update module is used to recalculate the density function based on the evaluation results, adjust the sampling direction of the parameter space, and update the weight coefficients until the performance evaluation results converge.

8. A method for managing automotive software development requirements documents, characterized in that, include: Receive multi-source raw data related to software development requirements, preprocess the multi-source raw data, and divide the raw data into text blocks through a sliding window of a predetermined size; Structured knowledge is extracted from each text block using a fine-tuned large language model, and a knowledge graph is constructed. The knowledge graph is then indexed into a database, which includes at least a graph database, a vector database, and a relational database. The system receives query requests from users, parses the query requests, and, based on vector retrieval and graph augmentation retrieval, inputs triples retrieved from the knowledge graph, text fragments, and the original query request into the generative large language model to obtain query results.

9. The optimizer periodically evaluates the query results and optimizes the parameter configurations for text block size, knowledge extraction strategy, and retrieval strategy.

10. The method according to claim 7, characterized in that, The optimizer is a tree-structured Parzen estimator, which constructs a probability density model for each parameter to be optimized.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the automotive software development requirements document management method as described in any one of claims 7 to 8.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed, it implements the steps of the automotive software development requirements document management method as described in any one of claims 7 to 8.

Images