RAG retrieval method and system oriented to software V-shaped development process
By constructing a knowledge graph and vector database, and combining it with a rule-guided joint embedding learning model, the problem of insufficient accuracy and consistency of RAG retrieval in the software V-shaped development process was solved, achieving high-precision retrieval results and process consistency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- WUHAN KOTEI INFORMATICS
- Filing Date
- 2026-03-13
- Publication Date
- 2026-05-08
AI Technical Summary
Existing RAG retrieval methods suffer from poor accuracy and consistency in the software V-shaped development process, especially in scenarios involving long documents, cross-files, and multiple stages, which can easily lead to factual discrepancies, evidence mismatches, and semantic drift.
By constructing a knowledge graph and vector database of document fragments, and combining it with a rule-guided joint embedding learning model, software engineering entities and attributes are extracted from technical documents. Based on the semantics of the query request, neighborhood expansion and alignment are performed to generate search results, and a large language model is used for accurate retrieval.
It improves the accuracy and consistency of RAG retrieval, ensures traceability and reliability at each stage of the software development process, and avoids the illusion of large language model generation.
Smart Images
Figure CN121996618A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of software engineering technology, and in particular relates to a RAG retrieval method and system for software V-shaped development processes. Background Technology
[0002] The development of automotive electronic control units (ECUs) commonly adopts the V-model, requiring traceability and consistency across all stages, including requirements, system / software design, implementation, verification, and validation. Relevant industry standards also specify clear requirements for the development lifecycle, verification activities, and traceability chains between artifacts. For example, ISO 26262 incorporates functional safety activities for road vehicle safety-related E / E systems into a framework; ASPICE provides process reference and evaluation models, emphasizing process capability and measurement oriented towards the V-model. As Retrieval Augmentation (RAG) becomes the mainstream approach to mitigate the "closed-book" limitations and illusion risks of Large Language Models (LLMs), using RAG to retrieve relevant development requirements within the V-model has become more common. However, because LLM illusions have systemic causes, simple vector similarity retrieval and context splicing can still lead to problems such as factual inconsistencies, evidence mismatches, and semantic drift, especially in long documents, cross-document, and multi-stage scenarios.
[0003] Currently, various representative methods have been proposed by academia and industry to improve RAG. For example, Self-RAG-based retrieval methods use a "self-retrieval-self-reflection-self-correction" strategy to adaptively decide whether to retrieve and how to utilize retrieval fragments, thereby improving the factual accuracy and citation accuracy of long texts. CRAG (Corrective RAG)-based retrieval methods enhance robustness against "erroneous retrievals" by adding a retrieval quality evaluator and error correction strategies after retrieval. GraphRAG-based retrieval methods utilize private corpora to construct knowledge graphs and combine graph and graph learning for enhanced prompts during queries, showing a significant improvement over pure text RAG for narrative / complex questions. While these methods can improve retrieval reliability to some extent, the accuracy of retrieval content and the consistency of each stage in the V-shaped development process remain relatively poor. Summary of the Invention
[0004] In view of this, embodiments of the present invention provide a RAG retrieval method and system for software V-shaped development processes, which is used to solve the problems of poor accuracy and consistency of current RAG retrieval.
[0005] In a first aspect of the present invention, a RAG retrieval method for a software V-shaped development process is provided, comprising: Receive technical documents related to software requirements, design, and testing; perform structured segmentation and layout semantic recognition on the technical documents; and generate a set of document fragments. The rule-guided joint embedding learning model extracts software engineering entities, entity identifiers, and attributes from technical documents and constructs the binding relationship between document fragments and entities. Based on the binding relationship, the software requirements, design and verification stages are respectively treated as nodes in the graph database or triples to construct a knowledge graph containing nodes and node relationships. Construct multidimensional vector representations of document fragments and write the vectors into a vector database; Upon receiving a user's query request, the semantics of the user's query request are parsed. Based on the semantics of the query request, matching candidate document fragments are retrieved from the vector database. Based on the target entity in the semantics of the query request, the neighborhood of the target entity is expanded in the knowledge graph to obtain a candidate graph set. By aligning candidate document fragments with candidate graphs, the fragments associated with the target entity are weighted and sorted, a predetermined number of the top-ranked fragments are selected, and the fragments are aggregated into an evidence package according to the relationship between the target entity and the fragments. The evidence package and the task generation instructions are input into the large language model, and the search results are generated based on industry-specific prompt templates and predefined constraint decoding strategies.
[0006] In a second aspect of the present invention, a RAG retrieval system for software V-shaped development processes is provided, comprising: The document parsing module is used to receive technical documents related to software requirements, design, and testing, perform structured segmentation and layout semantic recognition on the technical documents, and generate a set of document fragments. The entity extraction module is used to extract software engineering entities, entity identifiers, and attributes from technical documents based on a rule-guided joint embedding learning model, and to build a binding relationship between document fragments and entities. The graph construction module is used to construct a knowledge graph containing nodes and node relationships by taking the software requirements, design and verification stages as nodes in a graph database or triple based on the binding relationship. The vector construction module is used to build multidimensional vector representations of document fragments and write the vectors into the vector database. The semantic retrieval module is used to parse the semantics of the user's query request after receiving the query request, retrieve matching candidate document fragments in the vector database based on the query request semantics, and expand the neighborhood of the target entity in the knowledge graph according to the target entity in the query request semantics to obtain a candidate graph set. The alignment and sorting module is used to perform weighted sorting of the fragments associated with the target entity by aligning the candidate document fragments with the candidate graph. The evidence construction module is used to select a predetermined number of top-ranked fragments and aggregate them into evidence packages according to the relationship between the target entity and the fragments. The results generation module is used to input the evidence package and generation task instructions into the large language model, and generate search results based on industry-specific prompt templates and predefined constraint decoding strategies.
[0007] 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.
[0008] 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.
[0009] In this embodiment of the invention, by constructing a knowledge graph and a vector database corresponding to document fragments respectively, vector matching and graph expansion are performed on the user-input query request. Candidate document fragments are aligned with candidate graphs, fragments are selected to construct evidence packages, and based on the evidence packages and constraint decoding strategies, the large language model generates search results. This not only ensures the consistency of the three stages of the V-shaped development process in RAG retrieval but also improves content retrieval accuracy, avoiding bias caused by relying solely on semantic similarity. Simultaneously, the guidance based on evidence packages reduces the generation of illusions by the large language model, ensuring that the search results are consistent with the original documents. Attached Figure Description
[0010] 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.
[0011] Figure 1 A flowchart illustrating a RAG retrieval method for a software V-shaped development process, provided as an embodiment of the present invention; Figure 2 Another flowchart illustrating a RAG retrieval method for a software V-shaped development process, provided as an embodiment of the present invention; Figure 3 A schematic diagram of the structure of a RAG retrieval system for a software V-shaped development process provided in 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
[0012] 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.
[0013] 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.
[0014] Please see Figure 1 The present invention provides a flowchart illustrating a RAG retrieval method for a software V-shaped development process, comprising: S101. Receive technical documents related to software requirements, design, and testing; perform structured segmentation and layout semantic recognition on the technical documents; and generate a set of document fragments. The technical documents mentioned are those generated during the software requirements analysis, software design, and software testing phases. The system receives requirement documents, design documents, and test / verification documents generated during software development. It can also receive model artifacts, which are files generated and captured during a project or experiment, typically used to record model configurations, parameters, etc. In this embodiment, multiple input formats are supported, including PDF, DOCX, Markdown, and model exports (such as ReqIF and XMI).
[0015] It performs structured segmentation and layout semantic recognition of technical documents, locates title levels, numbering, tables and step lists, generates a set of document fragments, and can calculate the content hash of each fragment and add source path, page number and version timestamp.
[0016] S102. The rule-guided joint embedding learning model extracts software engineering entities, entity identifiers, and attributes from technical documents and constructs the binding relationship between document fragments and entities. Rule-guided joint embedding learning models are embedding representation learning methods that combine knowledge graph structural information, contextual information, and textual information. They enhance the model's ability to understand complex relationships and semantics by introducing rule constraints. Models that combine rules and learning extract engineering entities, identifiers, and attribute information from technical documents. Combining named entity recognition with regular templates can improve the accuracy and robustness of entity ID recognition.
[0017] Entities can be categorized into requirement entities, design entities, and verification entities. Entity identifiers can be RQ, D, and V, respectively, and corresponding attributes can include title, summary, status, version, responsible department, etc. After extracting software engineering entities, document fragments can establish one-to-many binding relationships with the entities they cover.
[0018] S103. Based on the binding relationship, software requirements, design and verification stages are respectively used as nodes in the graph database or triples to construct a knowledge graph containing nodes and node relationships. Based on the relationship between entities and document fragments, a knowledge graph containing three types of nodes (requirements / design / verification) and their relationships can be built in a graph database / triple storage.
[0019] The node relationships include at least design implementation requirement relationships, verification coverage requirement relationships, and design / verification derived dependencies; each node contains at least document version, baseline tags, and change records, and supports incremental updates and historical tracing of node information.
[0020] Node relationships include those such as `implements` (design implementation requirements), `validated_by` (validation coverage requirements), and `derives_from` (design / validation derived dependencies). Each node carries a document version, baseline tag, and change history, supporting incremental updates and historical tracing. Baseline tags are typically used to mark the state of a specific version of the codebase, facilitating backtracking or deployment. Change history is a historical record of code changes, which can include time, personnel, and modifications.
[0021] S104. Construct a multidimensional vector representation of the document fragment and write the vector into the vector database; Specifically, paragraph semantic vectors, fragment structure vectors, and entity vectors are constructed and written into a vector database; each vector entry contains filterable metadata.
[0022] The multidimensional vector representation of a fragment includes semantic vectors (paragraph semantics), structural vectors (heading levels, numbering patterns), and entity vectors (types and IDs of bound entities), and is written to a vector database. Vector entries contain filterable metadata, including entity type (requirement, design, or validation), version, source document, page number, and responsibility domain, for subsequent restricted retrieval.
[0023] S105. Upon receiving a user's query request, the semantics of the user's query request are parsed. Based on the semantics of the query request, matching candidate document fragments are retrieved from the vector database. Based on the target entity in the semantics of the query request, the neighborhood of the target entity is expanded in the knowledge graph to obtain a candidate graph set. Receive user query requests, parse the request semantics to obtain the target entity and target task. For example, if the request is "Give the verification test case for RQ-001", the parsing result is: target entity = RQ-001, target task = verification test case retrieval.
[0024] Optionally, when the query request does not contain the target entity ID, a candidate entity set is generated by enumeration matching and graph fuzzy search.
[0025] Based on the target entity and target task in the request semantics, candidate document fragments are retrieved and matched in the vector database, and a candidate graph set is obtained by neighborhood expansion in the knowledge graph.
[0026] Top-k candidate fragments are obtained based on semantic vector retrieval, and the target entity's neighborhood is expanded in the knowledge graph, for example, jumping from RQ node 1 to 2 to D / V, resulting in a candidate graph set. Based on the obtained candidate fragments and candidate graphs, the fragments can be aligned with the graph.
[0027] S106. By aligning candidate document fragments with candidate graphs, the fragments associated with the target entity are weighted and sorted, a predetermined number of the top-ranked fragments are selected, and the fragments are aggregated into an evidence package according to the relationship between the target entity and the fragments. Candidate document fragments are aligned to the candidate graph, achieving strict alignment between the retrieved fragments and engineering entities and their links (requirements → design → verification). During the alignment process, fragments can be scored and ranked based on an interpretable scoring function.
[0028] A certain number of aligned segments are selected from the top of the sorting, and entities and their segment relationships are aggregated into an evidence package for input into the large language model.
[0029] The evidence package includes at least entity ID, relationship chain, original text excerpt, source document location, document version and content hash; the evidence package is stored in JSON format or tabular format.
[0030] Each piece of evidence includes an entity ID, relationship chain, original text excerpt, source document location (file, page number, paragraph number), document version, and hash. The evidence package is cached in structured JSON / table format for reuse during the generation and auditing phases.
[0031] S107. Input the evidence package and the generation task instructions into the large language model, and generate search results based on industry-specific prompt templates and predetermined constraint decoding strategies.
[0032] A large language model is a deep learning model trained on massive amounts of text data. This model can understand the meaning of linguistic text and generate corresponding natural language text. Based on the large language model, answers to user queries can be generated. The generation instructions are the instructions that the large language model needs to generate, such as generating test cases, generating design specifications, and requirements explanations.
[0033] The industry-standard prompt template refers to a standardized prompt template in the field of automotive ECU software development, and large language models can generate content based on this template.
[0034] The predetermined constraint decoding strategy includes: Allow citation of fact fields and excerpts from the evidence package; Output in a structured format, such as "use case number, preconditions, steps, expected result, corresponding requirement ID"; Each key statement should be marked with a source identifier, such as evidence number or page number.
[0035] Based on industry-standard templates and constraint decoding strategies, retrieval results are generated and output by generating a large language model.
[0036] Optionally, entities and relationships can be extracted from the search results text, and the entities and relationships in the text can be compared with the evidence package for consistency. If there are missing or unauthorized references, a second search and reordering process can be triggered.
[0037] In this embodiment, based on vector matching and knowledge graph retrieval, candidate fragments are aligned with candidate graphs, and fragments are selected to construct evidence packages. Then, based on the evidence packages and constraint decoding strategies, retrieval results are generated. This solves the problems of inaccurate retrieval, lack of consistency, and generation illusions in existing solutions. Using RAG retrieval alignment ensures consistency and traceability among the requirements, design, and verification stages in the V-shaped development process of automotive software, improves the accuracy of retrieval results, and avoids the illusion problem of large language models. Furthermore, it has strong applicability and can be directly used for requirements analysis and verification in the ECU development process.
[0038] In one embodiment, the process of aligning candidate document fragments with candidate maps in step S106 is as follows: Figure 2 As shown, including, S201. Through entity alignment, retain fragments that can be mapped to the target entity or entities directly related to the target entity, and reduce the weight or remove fragments that cannot locate the entity ID. S202. By link alignment, check whether there are paths in the graph that meet the constraints of the V-shaped development process. If so, score the graph paths according to path length, relationship type and coverage. S203. Through consistency alignment, fragments of the same entity from different versions and sources are deduplicated and merged, and checked according to the principle of version priority and content hash consistency to reduce the confidence of conflicting fragments.
[0039] Entity alignment retains only fragments that can be clearly mapped to the target entity or its directly related entities, such as the target RQ (requirement entity) and its corresponding V (validation entity) with validated_by. Link alignment is used to check whether there are paths in the graph that satisfy the V-shaped flow constraints, such as RQ→V and RQ→D→V, and scores and penalizes the path length, relationship type, and coverage. Generally, the shorter the path and the stronger the relationship, the higher the score. Consistency alignment deduplicates and merges fragments of the same entity from different versions / sources, using version priority (latest baseline on top) and content hash consistency checks. Conflicting fragments have their confidence reduced.
[0040] For example, when a user enters "What is the verification test case corresponding to RQ-001?"; By using vector retrieval to the Top-k, 40 "seemingly relevant" segments were obtained, of which 20 were unrelated to RQ-001 (they were just similar words). Entity alignment retains only those that can be mapped to (RQ-001 or V-201), leaving 12 fragments. By checking the link alignment, we found that there was no downweighting of the path, leaving 8 segments. By merging different versions of the same use case through consistency alignment, the latest version is retained, leaving 3 fragments; Then, a context is constructed, and the remaining 3 fragments are combined with their source IDs. Finally, the LLM outputs the steps of "V-201".
[0041] In this embodiment, by aligning candidate document fragments with candidate graphs and selecting corresponding fragments to construct evidence packages, the consistency of fragments in the three stages of software development requirements, design, and verification can be ensured, the retrieval accuracy can be improved, the bias caused by relying solely on semantic similarity can be avoided, and the consistency of the results with the original documents can be guaranteed.
[0042] 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.
[0043] Figure 3 A schematic diagram of a RAG retrieval system for a software V-shaped development process provided in this embodiment of the invention. The system includes: The document parsing module 310 is used to receive technical documents related to software requirements, design and testing, perform structured segmentation and layout semantic recognition on the technical documents, and generate a set of document fragments. The entity extraction module 320 is used to extract software engineering entities, entity identifiers and attributes from technical documents based on a rule-guided joint embedding learning model, and to build a binding relationship between document fragments and entities. The graph construction module 330 is used to construct a knowledge graph containing nodes and node relationships by taking the software requirements, design and verification stages as nodes in a graph database or triple based on the binding relationship. The node relationships include at least design implementation requirement relationships, verification coverage requirement relationships, and design / verification derived dependencies; each node contains at least a document version, baseline tag, and change record, and supports incremental updates and historical tracing of node information.
[0044] Vector construction module 340 is used to construct multidimensional vector representations of document fragments and write the vectors into a vector database; Optionally, paragraph semantic vectors, fragment structure vectors, and entity vectors are constructed separately, and the vectors are written to a vector database; each vector entry contains filterable metadata.
[0045] The semantic retrieval module 350 is used to parse the semantics of the user's query request after receiving the user's query request, retrieve matching candidate document fragments in the vector database based on the semantics of the query request, and expand the neighborhood of the target entity in the knowledge graph according to the target entity in the semantics of the query request to obtain a candidate graph set. Optionally, the semantic retrieval module 350 includes: The candidate entity generation unit is used to generate a set of candidate entities by enumeration matching and graph fuzzy search when the query request does not contain the target entity ID.
[0046] The alignment and sorting module 360 is used to perform weighted sorting of target entity associated fragments by aligning candidate document fragments with candidate graphs; Optionally, the alignment and sorting module 360 includes: The entity alignment unit is used to retain fragments that can be mapped to the target entity or entities directly related to the target entity through entity alignment, and to de-weight or remove fragments that cannot locate the entity ID. The link alignment unit is used to check whether there are paths in the graph that meet the constraints of the V-shaped development process through link alignment. If they do, the graph paths are scored according to path length, relationship type and coverage. The consistency alignment unit is used to deduplicate and merge fragments of the same entity from different versions and sources through consistency alignment. It checks the fragments according to the principle of version priority and content hash consistency, thereby reducing the confidence of conflicting fragments.
[0047] The evidence construction module 370 is used to select a predetermined number of top-ranked fragments and aggregate them into an evidence package according to the relationship between the target entity and the fragments; The evidence package includes at least an entity ID, relationship chain, original text excerpt, source document location, document version, and content hash; the evidence package is stored in JSON or tabular format.
[0048] The result generation module 380 is used to input the evidence package and generation task instructions into the large language model, and generate search results based on industry-specific prompt templates and predetermined constraint decoding strategies.
[0049] Preferably, the result generation module 380 further includes: The consistency comparison unit is used to extract entities and relationships from the search results text, compare the entities and relationships in the text with the evidence package, and trigger a second search and reordering if there are missing or unauthorized references.
[0050] 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.
[0051] 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 document retrieval. For example... Figure 4 As shown, the electronic device 4 in 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.
[0052] The following is combined with Figure 4 A 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.
[0053] The memory 410 contains an executable program 4101 for a retrieval 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 RAG retrieval, etc. 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 4. For example, the computer program 4101 can be divided into functional modules such as a document parsing module, an entity extraction module, a graph construction module, a vector construction module, a semantic retrieval module, an alignment and sorting module, an evidence construction module, and a result generation module.
[0054] The 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 the memory 410, and by calling data stored in the memory 410, it performs various functions and processes data, thereby monitoring the overall status of the electronic device. Optionally, the processor 420 may include one or more processing units; preferably, the 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 modem processor may also not be integrated into the processor 420.
[0055] 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.
[0056] In this embodiment of the invention, the executable program executed by the processor 420 included in the electronic device includes: Receive technical documents related to software requirements, design, and testing; perform structured segmentation and layout semantic recognition on the technical documents; and generate a set of document fragments. The rule-guided joint embedding learning model extracts software engineering entities, entity identifiers, and attributes from technical documents and constructs the binding relationship between document fragments and entities. Based on the binding relationship, the software requirements, design and verification stages are respectively treated as nodes in the graph database or triples to construct a knowledge graph containing nodes and node relationships. Construct multidimensional vector representations of document fragments and write the vectors into a vector database; Upon receiving a user's query request, the semantics of the user's query request are parsed. Based on the semantics of the query request, matching candidate document fragments are retrieved from the vector database. Based on the target entity in the semantics of the query request, the neighborhood of the target entity is expanded in the knowledge graph to obtain a candidate graph set. By aligning candidate document fragments with candidate graphs, the fragments associated with the target entity are weighted and sorted, a predetermined number of the top-ranked fragments are selected, and the fragments are aggregated into an evidence package according to the relationship between the target entity and the fragments. The evidence package and the task generation instructions are input into the large language model, and the search results are generated based on industry-specific prompt templates and predefined constraint decoding strategies.
[0057] Those skilled in the art will clearly 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.
[0058] 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.
[0059] 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 RAG retrieval method for software V-shaped development processes, characterized in that, include: Receive technical documents related to software requirements, design, and testing; perform structured segmentation and layout semantic recognition on the technical documents; and generate a set of document fragments. The rule-guided joint embedding learning model extracts software engineering entities, entity identifiers, and attributes from technical documents and constructs the binding relationship between document fragments and entities. Based on the binding relationship, the software requirements, design and verification stages are respectively treated as nodes in the graph database or triples to construct a knowledge graph containing nodes and node relationships. Construct multidimensional vector representations of document fragments and write the vectors into a vector database; Upon receiving a user's query request, the semantics of the user's query request are parsed. Based on the semantics of the query request, matching candidate document fragments are retrieved from the vector database. Based on the target entity in the semantics of the query request, the neighborhood of the target entity is expanded in the knowledge graph to obtain a candidate graph set. By aligning candidate document fragments with candidate graphs, the fragments associated with the target entity are weighted and sorted, a predetermined number of the top-ranked fragments are selected, and the fragments are aggregated into an evidence package according to the relationship between the target entity and the fragments. The evidence package and the task generation instructions are input into the large language model, and the search results are generated based on industry-specific prompt templates and predefined constraint decoding strategies.
2. The method according to claim 1, characterized in that, The node relationships include at least design implementation requirement relationships, verification coverage requirement relationships, and design / verification derived dependencies; Each node contains at least the document version, baseline tags, and change history, and supports incremental updates and historical tracing of node information.
3. The method according to claim 1, characterized in that, The process of constructing a multidimensional vector representation of a document fragment and writing the vector into a vector database includes: Construct paragraph semantic vectors, fragment structure vectors, and entity vectors respectively, and write the vectors into a vector database; each vector entry contains filterable metadata.
4. The method according to claim 1, characterized in that, Upon receiving a user's query request, parsing the semantics of the user's query request includes: When the query request does not contain the target entity ID, a candidate entity set is generated through enumeration matching and graph fuzzy search.
5. The method according to claim 1, characterized in that, The step of aligning candidate document fragments with candidate graphs and then weighting and sorting the target entity-related fragments includes: By entity alignment, fragments that can be mapped to the target entity or entities directly related to the target entity are retained, while fragments that cannot locate the entity ID are downweighted or removed. By link alignment, we check whether there are paths in the graph that meet the constraints of the V-shaped development process. If they do, we score the graph paths based on path length, relationship type, and coverage. Consistent alignment deduplicates and merges fragments of the same entity from different versions and sources, and checks are performed according to the principle of version priority and content hash consistency to reduce the confidence of conflicting fragments.
6. The method according to claim 1, characterized in that, The evidence package includes at least entity ID, relationship chain, original text excerpt, source document location, document version, and content hash; the evidence package is stored in JSON or tabular format.
7. The method according to claim 1, characterized in that, The method for generating search results based on industry-specific prompt templates and predefined constraint decoding strategies also includes: Entities and relationships are extracted from the search results text. The entities and relationships in the text are compared with the evidence package for consistency. If there are missing or unauthorized references, a second search and reordering process is triggered.
8. A RAG retrieval system for software V-shaped development processes, characterized in that, include: The document parsing module is used to receive technical documents related to software requirements, design, and testing, perform structured segmentation and layout semantic recognition on the technical documents, and generate a set of document fragments. The entity extraction module is used to extract software engineering entities, entity identifiers, and attributes from technical documents based on a rule-guided joint embedding learning model, and to build a binding relationship between document fragments and entities. The graph construction module is used to construct a knowledge graph containing nodes and node relationships by taking the software requirements, design and verification stages as nodes in a graph database or triple based on the binding relationship. The vector construction module is used to build multidimensional vector representations of document fragments and write the vectors into the vector database. The semantic retrieval module is used to parse the semantics of the user's query request after receiving the query request, retrieve matching candidate document fragments in the vector database based on the query request semantics, and expand the neighborhood of the target entity in the knowledge graph according to the target entity in the query request semantics to obtain a candidate graph set. The alignment and sorting module is used to perform weighted sorting of the fragments associated with the target entity by aligning the candidate document fragments with the candidate graph. The evidence construction module is used to select a predetermined number of top-ranked fragments and aggregate them into evidence packages according to the relationship between the target entity and the fragments. The results generation module is used to input the evidence package and generation task instructions into the large language model, and generate search results based on industry-specific prompt templates and predefined constraint decoding strategies.
9. 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 a RAG retrieval method for a software V-shaped development process as described in any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed, it implements the steps of a RAG retrieval method for a software V-shaped development process as described in any one of claims 1 to 7.