Software defect repairing method and device based on large model analysis and medium

Abstract

The invention discloses a software defect repairing method and device based on large model analysis and a medium, and relates to the technical field of software development. The method comprises the following steps: generating intermediate representation data comprising an abstract syntax tree, a control flow chart and a dependency graph by obtaining and analyzing a source code; performing multi-dimensional defect detection to generate a defect report; performing cross-context semantic association analysis on the defect by utilizing the pre-training model, positioning a source and generating an enhanced semantic feature; constructing a reinforcement learning environment on the basis, and generating a plurality of candidate restoration schemes under the drive of a scenarized reward function; responding to user selection to execute repair, and performing full-dimension quality evaluation on the repaired software; and finally, carrying out iterative optimization on the detection model, the analysis model and the reward function according to an evaluation result and software operation data to realize closed-loop self-evolution.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a method, device and medium for repairing software defects based on large model analysis. Background Technology

[0002] In the intersection of software engineering and artificial intelligence, intelligent code defect detection and repair technology has become a key research direction for improving software development efficiency and quality. Currently, with the increasing complexity of software systems, traditional code review and repair methods relying on manual or semi-automatic tools are struggling to cope with large-scale, multi-scenario code quality issues. Therefore, automated defect handling solutions based on a combination of static analysis, dynamic testing, and machine learning are gradually becoming the industry mainstream.

[0003] However, existing technical solutions have significant limitations in terms of the comprehensiveness of defect detection. Most methods focus on identifying superficial issues such as syntax errors and coding style violations, or rely on limited rule bases to detect known types of logical defects. They are insufficient in their ability to discover deep-seated, hidden defects such as runtime performance bottlenecks, memory leaks, security vulnerabilities, and cross-platform compatibility issues. Furthermore, these solutions typically lack a deep understanding of the semantic context of the code, making it difficult to parse complex dependencies and implicit relationships across modules and files, resulting in inaccurate defect localization, especially with weak adaptability in emerging programming languages ​​or specific business scenarios.

[0004] Furthermore, in the defect remediation phase, existing methods often use fixed rules or simple pattern matching to generate patch code, lacking comprehensive evaluation and scenario-specific adaptation of the remediation solution. The remediation process often focuses on a single dimension of code correctness, failing to comprehensively consider the differentiated requirements for security, performance, and maintainability under different application scenarios. In addition, remediation operations often lack reliable verification and rollback mechanisms, easily introducing secondary defects, and the remediation effect lacks long-term tracking and systematic evaluation, making it difficult to form a closed loop of continuous optimization.

[0005] Therefore, how to achieve an intelligent code defect repair method that can deeply integrate code semantic understanding, support multi-dimensional defect detection, generate scenario-adaptive repair solutions, and ensure repair security and long-term stability has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] This application provides a software defect repair method, device, and medium based on large model analysis to solve the following technical problem: how to achieve an intelligent code defect repair method that can deeply integrate code semantic understanding, support multi-dimensional defect detection, generate scenario-adaptive repair solutions, and ensure repair security and long-term stability.

[0007] In a first aspect, embodiments of this application provide a software defect repair method based on large model analysis. The method includes: acquiring source code data of the target software and performing structured parsing on the source code data to generate intermediate representation data; wherein, the intermediate representation data includes an abstract syntax tree, a control flow graph, and a dependency graph; performing multi-dimensional defect detection on the target software based on the intermediate representation data to generate defect report data containing defect type, location, and severity; performing cross-context semantic association analysis processing using a pre-trained semantic association analysis model based on the defect report data and the intermediate representation data to obtain enhanced semantic feature data for characterizing the root cause of defects; constructing a reinforcement learning environment with repair operations as the action space based on the enhanced semantic feature data, and simulating execution according to a preset scenario-based reward function to generate multiple candidate repair scheme data; responding to a user's selection instruction for the target repair scheme data, executing the corresponding repair operation to obtain the target repair software, and performing a full-dimensional quality assessment on the target repair software to generate comprehensive quality assessment data; and iteratively optimizing the detection model, semantic association analysis model, and scenario-based reward function for multi-dimensional defect detection based on the comprehensive quality assessment data and the running data of the target repair software.

[0008] In one embodiment of this application, the source code data is structured and parsed to generate intermediate representation data. Specifically, this includes: using a syntax parser to perform lexical and syntactic analysis on the source code data to generate an abstract syntax tree; traversing the abstract syntax tree to analyze the control flow jump relationships in the code and generate a control flow graph; and analyzing the code element reference relationships across files or modules in the abstract syntax tree data to generate a dependency graph.

[0009] In one embodiment of this application, multi-dimensional defect detection is performed on the target software based on intermediate representation data to generate defect report data containing defect type, location, and severity. Specifically, this includes: performing pattern matching processing on the intermediate representation data based on a preset static analysis rule base to identify a first type of defect data; wherein the first type of defect data includes syntax errors, coding style violations, and excessive code complexity; constructing a dynamic simulation execution environment for the target software and performing simulation operation based on the intermediate representation data to monitor the simulation operation status and identify a second type of defect data; wherein the second type of defect data includes runtime memory leaks, performance bottlenecks, and boundary condition anomalies; inputting the intermediate representation data and source code data into a pre-trained deep learning defect detection model to identify a third type of defect set; wherein the third type of defect set includes security vulnerabilities and cross-platform compatibility defects; and performing deduplication, fusion, and priority sorting processing on the first, second, and third types of defect data to generate defect report data.

[0010] In one embodiment of this application, based on defect report data and intermediate representation data, a pre-trained semantic association analysis model is used to perform cross-context semantic association analysis to obtain enhanced semantic feature data for characterizing the root cause of defects. Specifically, this includes: determining the defect location in the source code data corresponding to the defect information contained in the defect report data, and encoding the code context associated with the defect location to generate a preliminary semantic embedding vector; using a graph attention network to analyze the code element dependencies of the defect information in the intermediate representation data, modeling explicit call associations and implicit data flow associations across files and modules to generate a context association feature vector; fusing the preliminary semantic embedding vector and the context association feature vector, and based on the fused feature vector, analyzing the root cause category of the defect through a classification model to generate an enhanced semantic feature vector; wherein, the enhanced semantic feature vector contains semantic information, structural association information, and defect root cause category information of the defect code.

[0011] In one embodiment of this application, a reinforcement learning environment with repair operations as the action space is constructed based on enhanced semantic feature data. The environment is then simulated and executed according to a preset scenario-based reward function to generate multiple candidate repair scheme data. Specifically, this includes: using enhanced semantic feature data as the state input of the reinforcement learning environment, and defining a set of basic operations including code replacement, code insertion, code deletion, and code refactoring as the action space; configuring a multi-dimensional reward function that integrates defect repair rate, code readability, performance loss, and maintenance cost evaluation results, and configuring weight parameters for each dimension under different application scenarios to form a scenario-based reward function; in the reinforcement learning environment, performing multiple rounds of strategy exploration and evaluation based on the scenario-based reward function to plan and output multiple repair path sequence data; and performing automated unit testing, integration testing, and static security scanning on the code modification schemes corresponding to each repair path sequence data to select schemes that do not introduce new defects and meet scenario priority requirements as candidate repair scheme data.

[0012] In one embodiment of this application, in response to a user's selection instruction for target repair scheme data, a corresponding repair operation is executed to obtain the target repair software. Specifically, this includes: parsing the selection instruction to determine the specific repair scheme data selected by the user from multiple candidate repair scheme data, and extracting the repair operation sequence and corresponding code modification content data contained in the specific repair scheme data; automatically executing code addition, deletion, and modification operations on a copy of the source code data according to the repair operation sequence, applying the code modification content data to the corresponding defect location, and generating preliminary repaired code version data; automatically compiling and building the preliminary repaired code version data, verifying its syntax correctness, and generating change comment document data containing detailed descriptions of all changes, reasons for modification, and associated defect numbers; packaging the preliminary repaired code version data, change comment document data, and the source code backup data before repair to form deliverable data of the target repair software, and recording complete log data of this repair operation for auditing and potential rollback operations.

[0013] In one embodiment of this application, a comprehensive quality assessment of the target remediation software is performed to generate integrated quality assessment data. Specifically, this includes: executing a pre-defined automated test case set to verify the target remediation software and obtain functional correctness assessment data; and calling a security scanning tool to perform vulnerability scanning and assessment of the target remediation software and obtain security compliance assessment data; running the target remediation software under simulated and / or real load conditions and collecting runtime indicator data to generate runtime performance and resource consumption assessment data; wherein the runtime indicator data includes response time, throughput, memory usage, and CPU utilization; analyzing the structured intermediate representation data of the target remediation software to calculate cyclomatic complexity, annotation coverage, and inter-module coupling indicators based on the structured intermediate representation data to generate code readability and maintenance cost assessment data; and performing weighted calculations on the functional correctness assessment data, runtime performance and resource consumption assessment data, security compliance assessment data, and code readability and maintenance cost assessment data to generate integrated quality assessment data.

[0014] In one embodiment of this application, based on comprehensive quality assessment data and the operational data of the target repair software, the detection model, semantic association analysis model, and scenario-based reward function for multi-dimensional defect detection are iteratively optimized. Specifically, this includes: deploying the target repair software to a pre-production or production environment, and continuously collecting operational status data and performance index data of the target repair software in real business scenarios through a data collection and log acquisition system to generate a long-term operational monitoring dataset; based on the long-term operational monitoring dataset, analyzing the recurrence of repaired defects in defect report data and whether related new defects have appeared, and combining the repair effect evaluation data submitted by users through the interactive interface to generate a model optimization dataset containing positive and negative feedback labels; using the model optimization dataset to incrementally train and optimize the deep learning defect detection model, and using the annotation information on the correctness of defect root cause analysis in the model optimization dataset to fine-tune the semantic association analysis model; and dynamically adjusting the weight parameters of each evaluation dimension in the scenario-based reward function according to the actual effectiveness evaluation of repair solutions in different application scenarios in the model optimization dataset.

[0015] Secondly, embodiments of this application also provide a software defect repair device based on large model analysis. The device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a software defect repair method based on large model analysis as described above.

[0016] Thirdly, embodiments of this application also provide a computer storage medium storing computer-executable instructions, which, when executed, implement a method as described above.

[0017] This application provides a software defect repair method, device, and medium based on large model analysis, which has the following beneficial effects: By integrating multi-dimensional defect detection, deep semantic association analysis, and scenario-based reinforcement learning, it achieves intelligent processing of the entire software defect process from discovery to repair. It significantly improves the coverage and accuracy of defect detection, not only identifying explicit syntax errors but also effectively discovering deep-seated hidden dangers such as performance bottlenecks and security vulnerabilities; it accurately locates the root cause of defects through cross-context semantic analysis, providing a reliable basis for repair; the repair scheme generated based on reinforcement learning has scenario adaptability, taking into account security, performance, and maintainability, and ensures repair quality through automated testing and quality assessment; finally, the system utilizes feedback data to achieve self-optimization, forming a closed loop of continuous improvement, significantly improving software quality and development and maintenance efficiency. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating a software defect repair method based on large model analysis, provided for embodiments of this application; Figure 2 This is a schematic diagram of the internal structure of a software defect repair device based on large model analysis, provided as an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] With the continuous growth in the scale and complexity of software systems, intelligent detection and repair of software defects has become a key technical challenge for ensuring software quality and improving development efficiency. Existing technical solutions are mainly divided into two categories: one is the traditional hybrid detection and repair solution represented by patent CN118656107B, which adopts a three-stage architecture combining static analysis, machine learning, and automated repair. Although it can handle common syntax errors, it lacks sufficient depth in identifying hidden defects such as runtime performance bottlenecks and security vulnerabilities, and its repair strategies are relatively rigid. The other is the large model-driven solution represented by patent CN119690512B, which generates repair code based on pre-trained language models and reinforcement learning. It has made progress in semantic understanding, but still lacks deep modeling of cross-file and cross-module relationships in the code. Moreover, the generation of repair solutions often ignores the differentiated requirements of actual business scenarios (such as financial security and high concurrency in the Internet), resulting in insufficient adaptability, security, and long-term stability of the repair results.

[0021] Specifically, existing technologies face the following prominent technical shortcomings: First, defect detection has a single dimension, making it difficult to comprehensively cover the full spectrum of defects, from explicit syntax errors to implicit memory leaks and security risks; second, semantic analysis is limited to local code contexts and cannot accurately analyze the root causes of defects caused by complex dependencies and data flows; third, remediation strategies lack scenario awareness, and the generated solutions often do not comprehensively consider the trade-offs between multiple objectives such as performance, security, and maintainability; fourth, quality assessment focuses on static indicators and lacks a long-term effect tracking and closed-loop optimization mechanism for the remediated code in a real-world operating environment. This application provides a software defect remediation method, device, and medium based on large-scale model analysis.

[0022] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0023] Figure 1 This document provides a flowchart of a software defect repair method based on large model analysis, as illustrated in an embodiment of this application. Figure 1 As shown in the figure, the software defect repair method based on large model analysis provided in this application embodiment specifically includes the following steps: Step 101: Obtain the source code data of the target software and perform structured parsing on the source code data to generate intermediate representation data; wherein, the intermediate representation data includes an abstract syntax tree, a control flow graph, and a dependency graph.

[0024] In this embodiment, "acquiring the source code data of the target software" is the initial operation to initiate the entire defect repair process. The target software can refer to any program project to be analyzed, and its "source code data" is the collection of all human-readable programming language text files that constitute the software. It is understood that the acquisition channels for this data are flexible and geared towards modern development processes. For example, the system can capture code opened or modified by the developer in the editor in real time through a dedicated plugin for an integrated development environment (such as VS Code or IntelliJ IDEA); it can also allow users to upload ZIP-formatted code archives through a web management portal; or, more automatically, it can integrate with version control systems such as Git and SVN or code hosting platforms such as GitLab and GitHub through the provided application programming interface, automatically pulling the complete code repository of the corresponding version based on the user-configured repository address, branch, and commit hash information. This design ensures that this method can be seamlessly integrated into various scenarios from local development to team collaboration.

[0025] It's important to note that the original source code obtained is essentially plain text, lacking a deep semantic structure that machines can directly understand. Therefore, the core step lies in the subsequent "structured parsing." This process aims to transform the linear, character-sequence-based code into various intermediate representations rich in hierarchy, relationships, and semantics, providing a unified and accurate data foundation for all subsequent advanced analyses.

[0026] In one embodiment of this application, the source code data is structured and parsed to generate intermediate representation data. Specifically, this includes: using a syntax parser to perform lexical and syntactic analysis on the source code data to generate an abstract syntax tree; traversing the abstract syntax tree to analyze the control flow jump relationships in the code and generate a control flow graph; and analyzing the code element reference relationships across files or modules in the abstract syntax tree data to generate a dependency graph.

[0027] Based on the above parsing process, it can be understood that the structured parsing of source code data is primarily manifested in "using a syntax parser to perform lexical and syntactic analysis on the source code data to generate an abstract syntax tree".

[0028] In this embodiment, the system calls or instantiates the corresponding parser based on the programming language type of the source code (such as Java, Python, C++). For example, the JavaParser library can be used for Java; for support of multiple languages, general-purpose parser generation tools like ANTLR can be used. The parsing process is hierarchical: first, "lexical analysis" is performed, where the parser scans and segments the source code character stream into a series of meaningful "lexical units" (Tokens), such as keywords like `if` and `while`, the identifier `variableName`, operators `+` and `==`, and separators `{` and `;`. Next, "syntax analysis" is performed, where the parser checks whether the order of these lexical units conforms to the grammatical rules predefined by the programming language, and constructs an "abstract syntax tree" in the process. This tree structure accurately reflects the syntactic composition of the source code, omitting non-essential details such as whitespace and comments, but fully preserving the program's structural skeleton. For example, a for loop statement will be represented in the AST as a node of type `ForStatement`, which may link to child nodes such as initialization expressions, loop conditions, update expressions, and loop body statements. AST is the cornerstone for understanding the static structure of code.

[0029] Subsequently, based on the generated abstract syntax tree, the system further performs the process of "traversing the abstract syntax tree, analyzing the control flow jump relationships in the code, and generating a control flow graph." A control flow graph is a graphical model used to represent all possible execution paths of a program.

[0030] In this embodiment, the system traverses the Abstract Syntax Tree (AST) to identify all "control flow nodes" that can change the program's execution order, such as conditional statements (if / else), loops (for / while), switch statements, function calls and returns, and exception throwing (throw). The analysis process groups consecutive, sequentially executed statement sequences into "basic blocks," each of which becomes a node in the CFG (Cybernetic Flow Group). Then, based on the logic contained in the control flow nodes, directed edges are added between different basic blocks to indicate that the execution flow can jump from one block to another. For example, an if statement will generate two edges, pointing to the basic blocks to be executed when the condition is true and when the condition is false, respectively. The CFG dynamically depicts the logical execution path of the program, which is crucial for understanding runtime code behavior, especially for path coverage analysis and dynamic defect detection.

[0031] Simultaneously, the system performs parallel operations to "analyze the code element reference relationships across files or modules in the abstract syntax tree data and generate a dependency graph." The dependency graph aims to reveal the static reference and referenced relationships between elements in the code (such as variables, functions, methods, classes, and modules).

[0032] In this embodiment, the system performs a depth-first search of the Abstract Syntax Tree (AST), extracting all identifier definition points (such as variable declarations and function definitions) and usage points (such as variables being read and functions being called). Crucially, this analysis is "cross-file or cross-module." For example, the system might trace a public class `ClassA` defined in `FileA.java`, imported by an `import` statement in `FileB.java`, and instantiated and called in its method `methodB`; or a function exported in module `moduleX` might be imported and used in module `moduleY`. All these definition-usage relationships, call relationships, inheritance relationships, import relationships, etc., are systematically collected, abstracted, and constructed into a large graph structure, where nodes represent code elements and edges represent dependencies between elements. The dependency graph provides a macroscopic view of the coupling between code modules and is a core basis for conducting impact scope analysis, understanding architectural flaws, and ensuring the safety of refactoring.

[0033] Step 102: Based on the intermediate representation data, perform multi-dimensional defect detection on the target software to generate defect report data that includes defect type, location and severity.

[0034] In this embodiment, multi-dimensional defect detection is performed on the target software. The purpose is to utilize various complementary analysis techniques to conduct in-depth investigations of intermediate representation data from different dimensions, aiming to discover all kinds of problems existing in the software without omission. It is understood that a single detection technique often has blind spots. For example, static analysis is difficult to discover defects triggered by specific inputs at runtime, while dynamic testing is difficult to cover all possible execution paths.

[0035] In one embodiment of this application, multi-dimensional defect detection is performed on the target software based on intermediate representation data to generate defect report data containing defect type, location, and severity. Specifically, this includes: performing pattern matching processing on the intermediate representation data based on a preset static analysis rule base to identify a first type of defect data; wherein the first type of defect data includes syntax errors, coding style violations, and excessive code complexity; constructing a dynamic simulation execution environment for the target software and performing simulation operation based on the intermediate representation data to monitor the simulation operation status and identify a second type of defect data; wherein the second type of defect data includes runtime memory leaks, performance bottlenecks, and boundary condition anomalies; inputting the intermediate representation data and source code data into a pre-trained deep learning defect detection model to identify a third type of defect set; wherein the third type of defect set includes security vulnerabilities and cross-platform compatibility defects; and performing deduplication, fusion, and priority sorting processing on the first, second, and third types of defect data to generate defect report data.

[0036] In this embodiment, the system "performs pattern matching processing on the intermediate representation data based on a preset static analysis rule base." It should be noted that this "static analysis rule base" is an extensible collection containing a large number of programming language-specific rules and general good practices. These rules can be built-in, such as those from the core rule sets of mature tools like SonarQube and ESLint, or they can be user-imported team-defined coding standards. The system uses these rules to scan and match intermediate representations such as Abstract Syntax Trees (ASTs). For example, a rule might be defined as "string concatenation is prohibited within loops (StringBuilder should be used)." When traversing the AST, if the system finds a code structure matching this anti-pattern, it will identify it as a defect. In this way, the system can effectively identify "first-type defect data," which mainly includes "syntax errors" (such as missing semicolons), violations of "coding standards" (such as non-compliant naming), and "excessive code complexity" (such as excessively high cyclomatic complexity of functions)—problems that can usually be discovered during the code writing stage. For example, the system might flag a private variable that has never been used (dead code) or an if-else statement block that is too deeply nested.

[0037] However, many defects, especially those related to resource management and program state, only become apparent during program runtime. Therefore, this method introduces a second detection dimension: "constructing a dynamic simulation execution environment for the target software and performing simulated execution based on the intermediate representation data." It's important to note that this dynamic simulation does not involve running the software completely on a real operating system. Instead, it utilizes advanced program analysis techniques such as symbolic execution, abstract interpretation, or taint propagation to execute the code's logic in a controlled, virtualized environment. The system simulates various possible input values ​​(including boundary and outlier values) and execution contexts, continuously "monitoring the simulation's runtime state" throughout the process. For example, the system can simulate memory allocation and deallocation operations, tracking the lifecycle of each memory block. Through this simulation, the system can accurately identify "second-type defect data," such as "runtime memory leaks" (memory remains unreleased after the simulation ends), "performance bottlenecks" (the simulation reveals a code path with excessive repetitive calculations or inefficient algorithms), and "boundary condition anomaly defects" (such as out-of-bounds access occurring when the simulated input is an array length value). For example, when simulating a file reading function, the system may detect a potential null pointer reference risk by finding that subsequent code attempts to use the file without checking the state when the file fails to open and returns null.

[0038] To further address increasingly complex and subtle defects, especially those involving semantic context, security strategies, or domain-specific knowledge, this method integrates a third AI-based detection dimension: "inputting the intermediate representation data and the source code data into a pre-trained deep learning defect detection model." This model is a neural network model (such as a variant based on the Transformer architecture) pre-trained on massive amounts of multilingual code data (including normal code and known defective code) and potentially fine-tuned on domain-specific datasets. It can simultaneously handle text sequences and graphical structures (such as ASTs and CFGs) of code. Through end-to-end learning, the model can capture complex defect patterns that are difficult for humans to define explicitly, thereby identifying a "third set of defects," primarily including "security vulnerabilities" (such as potential SQL injection, cross-site scripting attack points, and insecure deserialization) and "cross-platform compatibility defects" (such as the use of Windows-specific path separators or Linux-specific system calls). For example, by analyzing the code pattern of a string concatenated and directly passed to a database execution function, the model may classify it as a high-risk security defect.

[0039] Finally, to ensure the completeness, accuracy, and operability of the detection results, the system enters the defect information integration stage: "Deduplication, fusion, and priority ranking are performed on the first type of defect data, the second type of defect data, and the third type of defect data." It is understandable that the same code defect may be reported in different forms by different detection methods. For example, an error that might cause a division-by-zero anomaly might be captured by both static analysis rules (detecting division-by-zero constants) and dynamic simulation (simulating paths where division by zero occurs under specific inputs). "Deduplication" means merging these duplicate reports into a single defect entry by comparing the location, type, and root cause of the defects. "Fusion" integrates evidence, confidence levels, and other information from different detection sources to form a more comprehensive and reliable description of the defect. Afterward, the system performs "priority ranking" according to preset or configurable strategies. The ranking criteria typically include the severity of the defect (e.g., safety-critical defects have the highest priority), the urgency of remediation, the scope of impact, and the likelihood of being triggered.

[0040] For example, a memory leak defect that is dynamically simulated and confirmed to cause service crashes will have a much higher priority than a naming defect that only violates coding style guidelines. After this series of processes, the system ultimately generates a structured "defect report data." Each record in this report clearly includes the defect type (to guide subsequent analysis), its precise location in the source code (file path and line number for location), and its assessed severity (to guide the allocation of remediation resources), providing a clear and reliable list of input targets for subsequent deep semantic analysis and intelligent remediation.

[0041] Step 103: Based on the defect report data and intermediate representation data, perform cross-context semantic association analysis using a pre-trained semantic association analysis model to obtain enhanced semantic feature data for characterizing the root cause of defects.

[0042] In this embodiment, step 103 follows the defect report data generated in step 102. Its core task is to go beyond the superficial identification of the defect phenomenon (what it is and where it is) and delve into the underlying logic and root cause of the defect (why it occurs), thereby providing a deep semantic understanding foundation for generating accurate and fundamental remediation solutions. It is understandable that the occurrence of a defect, especially a complex logical or security defect, is often not an isolated line of code error, but rather stems from inappropriate module interactions, incorrect data flow assumptions, or missing constraints. This step, by integrating deep semantic encoding and graph structure association analysis, constructs a comprehensive defect root cause analysis framework.

[0043] In one embodiment of this application, based on defect report data and intermediate representation data, a pre-trained semantic association analysis model is used to perform cross-context semantic association analysis to obtain enhanced semantic feature data for characterizing the root cause of defects. Specifically, this includes: determining the defect location in the source code data corresponding to the defect information contained in the defect report data, and encoding the code context associated with the defect location to generate a preliminary semantic embedding vector; using a graph attention network to analyze the code element dependencies of the defect information in the intermediate representation data, modeling explicit call associations and implicit data flow associations across files and modules to generate a context association feature vector; fusing the preliminary semantic embedding vector and the context association feature vector, and based on the fused feature vector, analyzing the root cause category of the defect through a classification model to generate an enhanced semantic feature vector; wherein, the enhanced semantic feature vector contains semantic information, structural association information, and defect root cause category information of the defect code.

[0044] Based on the above processing, it can be understood that the system first "determines the location of the defect information contained in the defect report data corresponding to the defect in the source code data." For example, the report indicates a "null pointer dereference" defect in line 105 of File.java, where the variable `user` may be null. Subsequently, the system extracts the associated "code context" centered on this defect location. This includes not only the lines of code before and after the defect (local context window), but also extends to all semantic fragments related to the defective variable `user`, such as its declaration, possible assignment points (e.g., the return value from a `getUser(id)` method), and other locations used in the same function or related conditional branches. These related code texts are collected and "encoded using a pre-trained semantic association analysis model."

[0045] In this embodiment, the model is typically a Transformer-based model pre-trained on a large-scale code corpus (such as CodeBERT or an improved version). The model maps code text sequences to a high-dimensional "preliminary semantic embedding vector," which contains a distributed representation of the code in a general programming semantic space, capturing its syntactic structure, keyword information, and underlying semantic intent.

[0046] However, semantic embedding of local text alone is often insufficient to reveal the root causes of defects arising from complex dependencies across file or module boundaries. Therefore, this method introduces a more robust structural association analysis. It should be noted that the system "utilizes a graph attention network to analyze the code element dependencies of the defect information in the intermediate representation data." Here, "intermediate representation data" mainly refers to the abstract syntax tree and dependency graph generated in step 101. The system focuses on the code elements related to the defect points (such as the variable `user` and its source function `getUser` in the previous example) and runs a graph attention network on the global code element relationship graph. The GAT mechanism allows the model to assign different attention weights to the neighboring nodes of each node (code element) in the graph, thereby dynamically learning and "modeling explicit call associations and implicit data flow associations across files and modules." "Explicit call associations" are direct and easy to trace; for example, function `a()` in FileA calls function `b()` in FileB. "Implicit data flow associations" are even more subtle. For example, an object might be created in FileC and stored in the global cache, then retrieved and used in FileD without being passed directly as a function parameter. Through this deep analysis of graph neural networks, the system can generate a "contextual association feature vector," which encodes the complex network location of the defect within the overall code structure and its interaction patterns with distant related elements.

[0047] Next, the system needs to fuse local semantics with global structural information. Specifically, through a well-designed fusion layer (such as a fully connected network after concatenation), the preliminary semantic embedding vector and the context-related feature vector are fused to obtain a more comprehensive and representative "fused feature vector". This fused vector contains both the meaning of the defect code itself and its relationship within the project architecture.

[0048] Finally, based on this rich fusion feature, the system performs root cause diagnosis. "Based on the fused feature vector, a classification model is used to analyze the root cause category of the defect." Here, the "classification model" can be a shallow machine learning classifier (such as a support vector machine or multilayer perceptron), whose task is to attribute the defect to a predefined set of root cause categories based on the fused features. For example, these categories might include: "logical design flaws" (such as incomplete consideration of algorithm boundary conditions), "violations or omissions in coding standards" (such as failure to perform necessary null value checks), "incorrect dependencies" (such as using incompatible API versions), and "concurrency security issues" (such as shared data access lacking synchronization protection). Diagnosing the root cause category is a crucial step in understanding the nature of the defect. Ultimately, the system outputs "enhanced semantic feature data," a comprehensive representation that "contains semantic information, structural association information, and root cause category information of the defect code." This data no longer merely describes the "symptoms" of the defect but deeply elucidates its "pathology," providing crucial decision-making basis for developing targeted "treatment plans" (repair plans) in subsequent steps.

[0049] Step 104: Based on the enhanced semantic feature data, construct a reinforcement learning environment with the repair operation as the action space, and simulate execution according to the preset scenario-based reward function to generate multiple candidate repair scheme data.

[0050] In this embodiment, generating multiple candidate repair scheme data is the core step in realizing intelligent and adaptive defect repair. Its purpose is to formalize the complex code generation and decision-making problem of defect repair into a sequential decision-making process that can be explored and optimized by reinforcement learning algorithms.

[0051] Understandably, traditional automated repair tools often rely on predefined templates or simple rule replacements, lacking an assessment of the long-term impact and overall benefits of repair actions, and are even less adaptable to diverse business scenarios. This step aims to generate high-quality repair solutions that not only eliminate defects but also balance code quality, performance, and long-term maintainability by constructing a simulated code repair environment and introducing a scenario-based multi-objective optimization mechanism.

[0052] In one embodiment of this application, a reinforcement learning environment with repair operations as the action space is constructed based on enhanced semantic feature data. The environment is then simulated and executed according to a preset scenario-based reward function to generate multiple candidate repair scheme data. Specifically, this includes: using enhanced semantic feature data as the state input of the reinforcement learning environment, and defining a set of basic operations including code replacement, code insertion, code deletion, and code refactoring as the action space; configuring a multi-dimensional reward function that integrates defect repair rate, code readability, performance loss, and maintenance cost evaluation results, and configuring weight parameters for each dimension under different application scenarios to form a scenario-based reward function; in the reinforcement learning environment, performing multiple rounds of strategy exploration and evaluation based on the scenario-based reward function to plan and output multiple repair path sequence data; and performing automated unit testing, integration testing, and static security scanning on the code modification schemes corresponding to each repair path sequence data to select schemes that do not introduce new defects and meet scenario priority requirements as candidate repair scheme data.

[0053] Based on the above simulation logic, it can be understood that the system first needs to construct the basic framework of the reinforcement learning environment. Its state space is defined by the "enhanced semantic feature data" output in step 103. This data is a comprehensive digital representation of the root cause, semantic context, and structural relationships of the defect to be repaired, providing the agent with the information foundation needed for decision-making. Simultaneously, the system "defines a set of basic operations including code replacement, code insertion, code deletion, and code refactoring as the action space." It should be noted that the "actions" here are designed as atomic code editing operations. For example, "code replacement" could be replacing a potentially empty variable with a safe default value or an empty object; "code insertion" could be inserting parameter validity checks before a function call; and "code refactoring" could involve more complex structural transformations, such as extracting a piece of repetitive code into an independent function. The combination of these atomic actions can express complex repair logic.

[0054] However, guiding the agent to learn to make correct action sequence choices depends on the precise design of the reward function. One of the core innovations of this method lies in "configuring a multi-dimensional reward function that integrates the evaluation results of defect repair rate, code readability, performance loss, and maintenance cost." Understandably, an ideal repair should not solely aim to eliminate defects. For example, one repair might avoid crashes by adding numerous redundant checks, but severely compromise code readability and performance; another repair might cleverly adjust the algorithm logic, solving the problem while improving performance. Therefore, this reward function aims to provide a comprehensive and balanced evaluation of the repair results. More importantly, this function is "scenario-based," and the system supports "configuring weight parameters for each dimension under different application scenarios." For example, in a "security and compliance first" scenario for financial payment systems, the reward function assigns a very high weight to "defect repair rate" (ensuring complete vulnerability closure) and may implicitly include security scan results in the evaluation, while tolerating "performance degradation" relatively more. Conversely, in a "performance-first" scenario for high-frequency trading systems, the weight of "performance degradation" is significantly increased, guiding the agent to find the repair solution with the least impact on the execution path. This design allows this method to flexibly adapt to various differentiated needs, from IoT embedded devices to large-scale internet services.

[0055] Under the aforementioned environment and reward function settings, the agent (typically employing deep reinforcement learning algorithms such as PPO or DQN) begins its learning and exploration process. It observes the current defect state, selects a repair action from the action space, and applies it to a simulated copy of the code. The environment then calculates a reward signal based on the immediate changes in the code. Through "multiple rounds of policy exploration and evaluation processing based on the contextualized reward function within the reinforcement learning environment," the agent gradually learns to predict the long-term cumulative rewards of different action sequences, thereby "planning and outputting multiple repair path sequence data." Each path sequence represents a series of specific code modification steps, ultimately leading to a complete, executable version of the changed code.

[0056] It should be noted that since reinforcement learning environments are essentially simulations and simplifications of real development environments, their internal evaluators (used for rapid reward calculation) may contain biases. Therefore, directly adopting the path planned by the agent may be risky. To ensure the realism, reliability, and security of the generated solutions, this method sets up a rigorous verification process: "Automated unit testing, integration testing, and static security scanning are performed on the code modification solutions corresponding to each repair path sequence data." This means that the system will realistically apply each path sequence to the source code, generate specific patches, and then run the project's complete test suite in an isolated test environment, performing a new round of security scanning. Only those solutions that "pass all automated tests (i.e., without introducing functional regressions)," "pass static security scans (i.e., without introducing new security vulnerabilities)," and "meet the scenario priority requirements" in multi-dimensional evaluation (e.g., in performance-priority scenarios, performance regression tests must pass), will be ultimately "selected" and output as safe, effective, and scenario-appropriate "candidate repair solution data." This mechanism ensures that the automated repair suggestions provided by this method are reliable results rigorously tested in engineering practice, rather than mere theoretical deductions.

[0057] Step 105: In response to the user's selection instruction for the target repair solution data, execute the corresponding repair operation to obtain the target repair software, and perform a full-dimensional quality assessment of the target repair software to generate comprehensive quality assessment data.

[0058] In this embodiment, step 105 marks the formal transition of the invention from the intelligent analysis and solution generation stage to the code modification and practical verification stage. The core objective of this step is to securely apply the user-selected optimal repair solution to the source code while ensuring process safety, controllability, and traceability. Subsequently, rigorous, multi-dimensional quality checks are conducted on the repair results, thereby producing final software assets that can withstand the test of engineering practice. It is understood that automated repair must balance efficiency and reliability, minimizing human intervention while providing sufficient auditing, verification, and rollback guarantees.

[0059] In one embodiment of this application, in response to a user's selection instruction for target repair scheme data, a corresponding repair operation is executed to obtain the target repair software. Specifically, this includes: parsing the selection instruction to determine the specific repair scheme data selected by the user from multiple candidate repair scheme data, and extracting the repair operation sequence and corresponding code modification content data contained in the specific repair scheme data; automatically executing code addition, deletion, and modification operations on a copy of the source code data according to the repair operation sequence, applying the code modification content data to the corresponding defect location, and generating preliminary repaired code version data; automatically compiling and building the preliminary repaired code version data, verifying its syntax correctness, and generating change comment document data containing detailed descriptions of all changes, reasons for modification, and associated defect numbers; packaging the preliminary repaired code version data, change comment document data, and the source code backup data before repair to form deliverable data of the target repair software, and recording complete log data of this repair operation for auditing and potential rollback operations.

[0060] Based on the above repair process, it is understood that after reviewing the multiple candidate repair schemes generated in step 104 and their comparative analysis in the interactive interface, the user can make a final selection. The system then "parses the selection instruction to determine the specific repair scheme data selected by the user from the multiple candidate repair scheme data." Following this, the system precisely "extracts the repair operation sequence and corresponding code modification content data contained in the specific repair scheme data" from the specific scheme data. This operation sequence is a series of explicit, executable instructions, such as: "In line 58 of the file Service.java, replace the expression result.getData() with Objects.requireNonNull(result.getData(), "Data must not be null")".

[0061] Subsequently, the system performs automated modifications while ensuring the safety of the original code. Specifically, it does not operate directly on the original source code file, but rather "automatically performs code addition, deletion, and modification operations on a copy of the source code data according to the repair operation sequence." This design principle is crucial, as it guarantees the integrity of the original code and provides a baseline for any possible rollback. The system precisely applies the code modifications to the corresponding defect locations in the copy, thereby "generating preliminary repaired code version data." To ensure that this automated modification is effective at the foundational level, the system immediately "automatically compiles and builds the preliminary repaired code version data, verifying its syntax correctness," ensuring that the repair does not introduce low-level compilation errors.

[0062] It's important to note that a remediation that conforms to engineering standards and facilitates collaboration involves not only the code itself but also a clear change log. Therefore, the system will simultaneously generate change comment documentation data containing detailed descriptions of all changes, reasons for modifications, and associated defect numbers. For example, this documentation might record: "Added a null check at Service.java:58, fixing defect ID #D-2023-001 (null pointer dereference), root cause being missing input validation." Finally, the system packages and integrates all relevant assets, "packaging the initially repaired code version data, change comment documentation data, and the original source code backup data to form the deliverable data of the target repaired software." The entire remediation operation's complete log data (including timestamps, executor / system, and specific operation sequence) is recorded in detail. This log is crucial for auditing, knowledge transfer, and supporting "one-click rollback" when the remediation effect is unsatisfactory.

[0063] Understandably, the success of a fix cannot be judged solely by whether the defect disappears from the static report. Therefore, after obtaining the target fix software, the system initiates a comprehensive and in-depth quality assessment phase. This phase aims to verify the overall effectiveness of the fix from multiple core dimensions.

[0064] In one embodiment of this application, a comprehensive quality assessment of the target remediation software is performed to generate integrated quality assessment data. Specifically, this includes: executing a pre-defined automated test case set to verify the target remediation software and obtain functional correctness assessment data; and calling a security scanning tool to perform vulnerability scanning and assessment of the target remediation software and obtain security compliance assessment data; running the target remediation software under simulated and / or real load conditions and collecting runtime indicator data to generate runtime performance and resource consumption assessment data; wherein the runtime indicator data includes response time, throughput, memory usage, and CPU utilization; analyzing the structured intermediate representation data of the target remediation software to calculate cyclomatic complexity, annotation coverage, and inter-module coupling indicators based on the structured intermediate representation data to generate code readability and maintenance cost assessment data; and performing weighted calculations on the functional correctness assessment data, runtime performance and resource consumption assessment data, security compliance assessment data, and code readability and maintenance cost assessment data to generate integrated quality assessment data.

[0065] Based on the above evaluation process, it is understandable that the evaluation first focuses on basic functionality: "Executing a pre-defined set of automated test cases to verify the target software being patched, in order to obtain functional correctness evaluation data." This means that the patched code must pass all unit tests and integration tests to prove that it has not broken any of the original intended functions of the software. Simultaneously, security must be re-verified: "Using security scanning tools to perform vulnerability scanning and evaluation on the target software being patched, in order to obtain security compliance evaluation data," to ensure that the patch itself does not introduce new security vulnerabilities.

[0066] Building upon this, the evaluation delves deeper into the software's runtime performance. The system "runs the target repair software under simulated and / or real loads and collects runtime metric data." These metrics include, but are not limited to, "response time, throughput, memory usage, and CPU utilization," used to "generate runtime performance and resource consumption assessment data." For example, if a repair solution avoids redundant computations by increasing caching, it may result in a significant reduction in response time in the performance evaluation; conversely, adding complex validation logic may lead to a slight decrease in throughput. This part of the evaluation reveals the impact of the repair on the software's dynamic behavior.

[0067] At the same time, the internal structure quality of the code is also rigorously examined. The system again "analyzes the structured intermediate representation data of the target repair software" and calculates a series of software metrics based on this, such as "cyclomatic complexity, comment coverage, and inter-module coupling metrics." These metrics are used to "generate code readability and maintenance cost assessment data." Understandably, a good repair should avoid making the code structure more cluttered, difficult to understand, and harder to maintain.

[0068] Finally, the system needs to comprehensively quantify the aforementioned scattered evaluation results. This involves "weighting the functional correctness evaluation data, runtime performance and resource consumption evaluation data, security compliance evaluation data, and code readability and maintenance cost evaluation data." The weights of each dimension can be configured according to project stage or scenario preferences (for example, in the pre-release stage, functional correctness and security compliance may have the highest weights). Through weighted calculation, the system ultimately "generates the comprehensive quality evaluation data." This data is typically a quantified score (e.g., 85 / 100) accompanied by itemized comments.

[0069] Step 106: Based on the comprehensive quality assessment data and the running data of the target repair software, iteratively optimize the detection model, semantic association analysis model and scenario-based reward function of the multi-dimensional defect detection.

[0070] Understandably, the technology stack, business scenarios, and defect patterns of software are constantly evolving, and the effectiveness of a static defect repair system will gradually decline over time. This step systematically collects feedback on the actual effects of repairs and transforms it into training signals for optimizing the core components of the system, thereby driving the entire system to continuously evolve and become more intelligent with use.

[0071] In one embodiment of this application, based on comprehensive quality assessment data and the operational data of the target repair software, the detection model, semantic association analysis model, and scenario-based reward function for multi-dimensional defect detection are iteratively optimized. Specifically, this includes: deploying the target repair software to a pre-production or production environment, and continuously collecting operational status data and performance index data of the target repair software in real business scenarios through a data collection and log acquisition system to generate a long-term operational monitoring dataset; based on the long-term operational monitoring dataset, analyzing the recurrence of repaired defects in defect report data and whether related new defects have appeared, and combining the repair effect evaluation data submitted by users through the interactive interface to generate a model optimization dataset containing positive and negative feedback labels; using the model optimization dataset to incrementally train and optimize the deep learning defect detection model, and using the annotation information on the correctness of defect root cause analysis in the model optimization dataset to fine-tune the semantic association analysis model; and dynamically adjusting the weight parameters of each evaluation dimension in the scenario-based reward function according to the actual effectiveness evaluation of repair solutions in different application scenarios in the model optimization dataset.

[0072] Based on the optimization process described above, it's understandable that the foundation of optimization is obtaining feedback data from the real world. Therefore, the target repair software, verified and evaluated as qualified in step 105, will be "deployed to a pre-production or production environment." In this real or near-real business scenario, the system continuously collects operational status data and performance metrics data of the target repair software under real business conditions through an integrated "logging and data collection system." This data far exceeds the scope of laboratory testing, including, for example, queries per second under real user load, end-to-end latency of specific business processes, the actual growth curve of container memory, and error rates under abnormal traffic surges. These real-time, objective metrics are aggregated to form a valuable "long-term operational monitoring dataset."

[0073] It's important to note that this operational data must be analyzed in conjunction with the initial defect remediation context to generate valuable insights. Therefore, the system performs correlation analysis, "analyzing the recurrence of remediated defects in the defect report data and whether any related new defects have appeared, based on the long-term operational monitoring dataset." For example, a "database connection leak" defect considered remediated, if long-term monitoring reveals a still slow upward trend in connection counts, may indicate that the remediation solution has not completely eradicated the problem or has triggered a new hidden leak point. Simultaneously, subjective user feedback is equally important; the system "combines remediation effectiveness evaluation data submitted by users through the interactive interface." For instance, development and operations personnel might report, "After this remediation, the system's stability during peak hours has significantly improved," or "The remediation caused a minor function to become less responsive." By combining objective monitoring data with subjective evaluations, the system generates a "model optimization dataset containing positive and negative feedback labels," where each data point is associated with a specific remediation attempt and its final actual effect.

[0074] Subsequently, this information-rich dataset was used to drive iterative updates to the core components of the system. First, at the defect detection level, the system "uses the model optimization dataset to incrementally train and optimize the deep learning defect detection model." Specifically, defect judgments proven effective in real-world operation (true positives) and undetected defects (false negatives, i.e., newly emerging online problems whose patterns were not captured by the original model) become valuable training samples, used for incremental learning or fine-tuning of the model, making its perception of similar defects in the future more sensitive and accurate. Second, at the semantic understanding level, the system "uses the annotation information regarding the correctness of defect root cause analysis in the model optimization dataset to fine-tune the semantic association analysis model." For example, if later analysis confirms that the root cause of a defect was misclassified by the initial analysis model (e.g., mistakenly classifying "concurrency security issues" as "logic design defects"), this corrective information will be used to adjust model parameters, improving the accuracy of its root cause diagnosis. Finally, and crucially, the system "dynamically adjusts the weight parameters of each evaluation dimension in the scenario-based reward function based on the actual effectiveness evaluation of repair solutions under different application scenarios in the model optimization dataset." It is understandable that the pre-set scenario-based weights may not fully reflect reality.

[0075] For example, in a "mobile power saving priority" scenario, if the system repeatedly finds that the repair solutions generated according to the current weights still cause excessive power consumption when running on actual devices, it can automatically increase the penalty weight of the "performance loss" dimension (represented as power consumption) in the reward function, or decrease the weight of other secondary dimensions, making subsequent repair solutions more "sensitive" and "conservative" regarding power consumption issues. This dynamic adjustment allows the system's repair strategy to truly "learn from practice" and continuously approach the optimal trade-off point in real-world scenarios.

[0076] Through continuous optimization using the above multi-pronged approach, the intelligent repair system constituted by this invention is no longer a one-time deployment tool, but a dynamic ecosystem that can grow and continuously improve itself along with the organization's software assets and development practices, ensuring its long-term effectiveness and technological vitality.

[0077] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide a software defect repair device based on large model analysis, the structure of which is as follows: Figure 2 As shown.

[0078] Figure 2 This is a schematic diagram of the internal structure of a software defect repair device based on large model analysis, provided as an embodiment of this application. Figure 2 As shown, the device includes: At least one processor 201; And a memory 202 that is communicatively connected to at least one processor; The memory 202 stores instructions executable by at least one processor, which are executed by at least one processor 201 to enable at least one processor 201 to: The source code data of the target software is obtained and structured parsing is performed on the source code data to generate intermediate representation data; the intermediate representation data includes abstract syntax tree, control flow graph and dependency graph. Based on intermediate representation data, multi-dimensional defect detection is performed on the target software to generate defect report data containing defect type, location, and severity. Based on defect report data and intermediate representation data, a pre-trained semantic association analysis model is used to perform cross-context semantic association analysis to obtain enhanced semantic feature data for characterizing the root causes of defects. Based on enhanced semantic feature data, a reinforcement learning environment with repair operation as the action space is constructed, and the operation is simulated according to the preset scenario-based reward function to generate multiple candidate repair scheme data. In response to the user's selection command for the target repair solution data, the corresponding repair operation is executed to obtain the target repair software, and a comprehensive quality assessment of the target repair software is performed to generate comprehensive quality assessment data. Based on comprehensive quality assessment data and operational data from the target repair software, the detection model, semantic association analysis model, and scenario-based reward function for multi-dimensional defect detection are iteratively optimized.

[0079] Some embodiments of this application provide corresponding to Figure 1 A computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows: The source code data of the target software is obtained and structured parsing is performed on the source code data to generate intermediate representation data; the intermediate representation data includes abstract syntax tree, control flow graph and dependency graph. Based on intermediate representation data, multi-dimensional defect detection is performed on the target software to generate defect report data containing defect type, location, and severity. Based on defect report data and intermediate representation data, a pre-trained semantic association analysis model is used to perform cross-context semantic association analysis to obtain enhanced semantic feature data for characterizing the root causes of defects. Based on enhanced semantic feature data, a reinforcement learning environment with repair operation as the action space is constructed, and the operation is simulated according to the preset scenario-based reward function to generate multiple candidate repair scheme data. In response to the user's selection command for the target repair solution data, the corresponding repair operation is executed to obtain the target repair software, and a comprehensive quality assessment of the target repair software is performed to generate comprehensive quality assessment data. Based on comprehensive quality assessment data and operational data from the target repair software, the detection model, semantic association analysis model, and scenario-based reward function for multi-dimensional defect detection are iteratively optimized.

[0080] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for IoT devices and media are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0081] The systems, media, and methods provided in this application are one-to-one correspondences. Therefore, the systems and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the systems and media will not be repeated here.

[0082] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0083] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0084] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0085] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0086] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0087] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0088] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0089] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, 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, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0090] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A software defect repair method based on large model analysis, characterized in that, The method includes: The source code data of the target software is obtained, and the source code data is parsed in a structured manner to generate intermediate representation data; wherein, the intermediate representation data includes an abstract syntax tree, a control flow graph, and a dependency graph; Based on the intermediate representation data, multi-dimensional defect detection is performed on the target software to generate defect report data containing defect type, location, and severity. Based on the defect report data and the intermediate representation data, a pre-trained semantic association analysis model is used to perform cross-context semantic association analysis to obtain enhanced semantic feature data for characterizing the root cause of defects. Based on the enhanced semantic feature data, a reinforcement learning environment with repair operation as the action space is constructed, and the operation is simulated according to the preset scenario-based reward function to generate multiple candidate repair scheme data. In response to the user's selection instruction for the target repair solution data, the corresponding repair operation is executed to obtain the target repair software, and the target repair software is subjected to a full-dimensional quality assessment to generate comprehensive quality assessment data; Based on the comprehensive quality assessment data and the operational data of the target repair software, the detection model of the multi-dimensional defect detection, the semantic association analysis model, and the scenario-based reward function are iteratively optimized.

2. The software defect repair method based on large model analysis according to claim 1, characterized in that, The source code data is subjected to structured parsing to generate intermediate representation data, specifically including: The source code data is processed by a syntax parser to perform lexical and syntactic analysis, generating an abstract syntax tree. Traverse the abstract syntax tree, analyze the control flow jump relationships in the code, and generate a control flow diagram; Analyze the code element reference relationships across files or modules in the abstract syntax tree data to generate a dependency graph.

3. The software defect repair method based on large model analysis according to claim 1, characterized in that, Based on the intermediate representation data, multi-dimensional defect detection is performed on the target software to generate defect report data containing defect type, location, and severity, specifically including: The intermediate representation data is subjected to pattern matching based on a preset static analysis rule base to identify the first type of defective data; wherein, the first type of defective data includes syntax errors, coding style violations, and excessive code complexity. A dynamic simulation execution environment for the target software is constructed, and simulation is performed based on the intermediate representation data to monitor the simulation execution status and identify the second type of defect data; wherein, the second type of defect data includes: runtime memory leaks, performance bottlenecks, and boundary condition abnormal defects; The intermediate representation data and the source code data are input into a pre-trained deep learning defect detection model to identify a third type of defect set; wherein, the third type of defect set includes security vulnerabilities and cross-platform compatibility defects. The first type of defect data, the second type of defect data, and the third type of defect data are deduplicated, merged, and prioritized to generate the defect report data.

4. The software defect repair method based on large model analysis according to claim 1, characterized in that, Based on the defect report data and the intermediate representation data, a pre-trained semantic association analysis model is used to perform cross-context semantic association analysis to obtain enhanced semantic feature data for characterizing the root cause of defects, specifically including: The defect information contained in the defect report data is determined to correspond to the defect location in the source code data, and the code context associated with the defect location is encoded to generate a preliminary semantic embedding vector. The graph attention network is used to analyze the code element dependencies of the defect information in the intermediate representation data, and to model the explicit call associations and implicit data flow associations across files and modules to generate context association feature vectors. The preliminary semantic embedding vector and the context-related feature vector are fused together, and based on the fused feature vector, the root cause category of the defect is analyzed through a classification model to generate the enhanced semantic feature vector; wherein, the enhanced semantic feature vector contains semantic information, structural association information and defect root cause category information of the defect code.

5. The software defect repair method based on large model analysis according to claim 1, characterized in that, Based on the enhanced semantic feature data, a reinforcement learning environment with repair operations as the action space is constructed, and execution is simulated according to a preset scenario-based reward function to generate multiple candidate repair scheme data, specifically including: The enhanced semantic feature data is used as the state input of the reinforcement learning environment, and a set of basic operations including code replacement, code insertion, code deletion and code reconstruction is defined as the action space; Configure a multi-dimensional reward function that integrates the evaluation results of defect repair rate, code readability, performance loss and maintenance cost, and configure the weight parameters of each dimension under different application scenarios to form the scenario-based reward function; In the reinforcement learning environment, multiple rounds of policy exploration and evaluation are performed based on the scenario-based reward function to plan and output multiple repair path sequence data. For each repair path sequence, the code modification schemes are subjected to automated unit testing, integration testing, and static security scanning. Schemes that do not introduce new defects and meet the scenario priority requirements are selected as candidate repair scheme data.

6. The software defect repair method based on large model analysis according to claim 1, characterized in that, In response to the user's selection instruction for the target repair solution data, the corresponding repair operation is executed to obtain the target repair software, specifically including: The selection instruction is parsed to determine the specific repair scheme data selected by the user from the multiple candidate repair scheme data, and the repair operation sequence and corresponding code modification content data contained in the specific repair scheme data are extracted. On the copy of the source code data, code addition, deletion and modification operations are automatically executed according to the repair operation sequence, and the code modification data is applied to the corresponding defect location to generate the code version data after preliminary repair. The code version data after the initial repair is automatically compiled and built to verify its syntax correctness and generate change comment document data containing detailed descriptions of all changes, reasons for modification and associated defect numbers; The code version data after the initial repair, the change comment document data, and the source code backup data before the repair are packaged to form the deliverable data of the target repair software, and the complete log data of this repair operation is recorded for auditing and potential rollback operations.

7. The software defect repair method based on large model analysis according to claim 1, characterized in that, A comprehensive quality assessment of the target repair software is performed to generate integrated quality assessment data, specifically including: The target repair software is verified by executing a pre-set set of automated test cases to obtain functional correctness assessment data, and a security scanning tool is invoked to perform vulnerability scanning assessment on the target repair software to obtain security compliance assessment data. The target repair software is run under simulated and / or real load conditions, and runtime performance data is collected to generate runtime performance and resource consumption assessment data; wherein, the runtime performance data includes response time, throughput, memory usage, and CPU utilization. The structured intermediate representation data of the target repair software is analyzed to calculate cyclomatic complexity, annotation coverage, and inter-module coupling indices based on the structured intermediate representation data, so as to generate code readability and maintenance cost evaluation data. The comprehensive quality assessment data is generated by weighting the functional correctness assessment data, the runtime performance and resource consumption assessment data, the security compliance assessment data, and the code readability and maintenance cost assessment data.

8. The software defect repair method based on large model analysis according to claim 1, characterized in that, Based on the comprehensive quality assessment data and the operational data of the target repair software, the detection model for the multi-dimensional defect detection, the semantic association analysis model, and the scenario-based reward function are iteratively optimized, specifically including: Deploy the target repair software to a pre-production or production environment, and continuously collect the running status data and performance index data of the target repair software in real business scenarios through a data collection and log acquisition system to generate a long-term running monitoring dataset. Based on the long-term operation monitoring dataset, the recurrence of fixed defects in the defect report data and whether related new defects have appeared are analyzed. Combined with the repair effect evaluation data submitted by users through the interactive interface, a model optimization dataset containing positive and negative feedback labels is generated. The deep learning defect detection model is incrementally trained and optimized using the model optimization dataset, and the semantic association analysis model is fine-tuned using the annotation information on the correctness of defect root cause analysis in the model optimization dataset; and, Based on the actual effectiveness evaluation of the repair schemes under different application scenarios in the model optimization dataset, the weight parameters of each evaluation dimension in the scenario-based reward function are dynamically adjusted.

9. A software defect repair device based on large model analysis, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform a software defect repair method based on large model analysis as described in any one of claims 1-8.

10. A computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, they implement a software defect repair method based on large model analysis as described in any one of claims 1-8.

Images