A software repair method based on large model and iterative tree search

Abstract

The application discloses a software repair method based on a large model and an iterative tree search, which fuses a Monte Carlo tree search, screens the most potential patches from a patch tree according to UCT values, then generates new candidate patches based on the selected patches in combination with thought chain reasoning and self-reflection, then executes test cases to verify patch correctness, and if the test passes, marks the patch as reasonable, and if the test fails, adds the patch to the patch tree, in order to evaluate patch quality, when test cases are sufficient, scores by Test-as-Judge according to test pass rate, and when test coverage is limited, scores by LLM-as-Judge in combination with semantics and context, and finally updates the patch tree by reverse propagation from the selected patch to the root. After the complete iterative search process, all reasonable patches can be obtained. The application solves the local optimal trap and search redundancy problem existing in the existing automatic program repair method based on a large model, and further realizes efficient and low-cost repair of program bugs.

Description

Technical Field

[0001] This invention belongs to the field of software engineering technology, and in particular relates to a software repair method based on large models and iterative tree search, which is especially suitable for the field of software maintenance and defect repair, and is used to efficiently and automatically repair program vulnerabilities. Background Technology

[0002] In software development and maintenance, locating and fixing program vulnerabilities consumes significant human and time resources. Automated Program Remediation (APR) technology, by automatically generating patches to fix vulnerabilities, has become a key technology for reducing development and maintenance costs and ensuring software reliability. Existing APR technologies can be broadly categorized into traditional methods and modern learning-based methods. Each approach has significant limitations and struggles to meet the demands for efficient and high-quality patching in complex scenarios.

[0003] Traditional APR techniques are mainly divided into three categories: heuristic-based methods, constraint-based methods, and template-based methods. Among them, template-based APR techniques, because they match vulnerability code patterns using predefined templates, have shown some effectiveness in specific scenarios and are widely regarded as the mainstream technique at this stage. However, this type of technique inherently relies on predefined remediation templates and has significant limitations in generalization ability, making it difficult to adapt to the diversity and complexity of software vulnerabilities.

[0004] With the development of deep learning technology, learning-based APR methods are gradually replacing traditional techniques. By extracting vulnerability repair patterns from large-scale codebases, these methods effectively improve generalization ability and can handle vulnerabilities not present in the training data. However, this method has a key drawback: it is highly sensitive to noise in the training data. If the training data contains bug repair patterns or low-quality code, the model's repair performance will significantly decrease. Furthermore, these methods still rely on large-scale, high-quality labeled training data, making them unsuitable for data-scarce scenarios and limiting their practical application.

[0005] In recent years, breakthroughs in large language models (MLMs) for code understanding and generation tasks have driven the development of LLM-based Approval Processing (APR) techniques. While LLMs leverage their general code processing capabilities to support zero-shot or few-shot patching, significantly reducing reliance on large-scale labeled training data, they are prone to local optima and redundant exploration problems. To address this, this paper employs a search-based approach, combining large language models with the Monte Carlo Tree Search (MCTS) algorithm. Monte Carlo Tree Search is an iterative search algorithm suitable for complex decision-making scenarios. Through iterative cycles of selection, expansion, evaluation, and backpropagation, it dynamically balances exploring unknown regions with utilizing known high-quality regions within a vast search space. This method enables large language models to iteratively select, search, and evaluate patches, generating more correct patches at a lower cost. Summary of the Invention

[0006] The purpose of this invention is to address the problems mentioned in the background art by proposing a software repair method based on large models and iterative tree search. This method effectively solves the core problems of limited patch effectiveness due to local exploration and excessively high costs caused by redundant searches during the automated repair of large language models, thereby improving patch quality and search efficiency.

[0007] To achieve the objectives of this invention, a software remediation method based on a large model and iterative tree search is disclosed. Monte Carlo Tree Search (MCTS) is integrated into the patch search process, and the explored patches are globally evaluated. The most promising patch is selected for further optimization and generation using a large language model. Through multiple iterations, the vulnerability is finally remediated. Specifically, the method includes the following steps:

[0008] Step 1, Patch Selection: Based on the UCT strategy, select the highest-scoring node from the patch tree that balances average quality and exploration level as the basis for subsequent optimization;

[0009] Step 2, Patch Generation: Using Large Language Model (LLM) combined with CoT reasoning and self-reflection mechanisms, higher quality candidate patches are generated for selected nodes;

[0010] Step 3, Patch Evaluation: Quality rewards are given to candidate patches based on test case validation and LLM scoring. Calculate and add it as a new node to the tree;

[0011] Step 4, Patch Tree Update: The reward value of the current node is propagated back to the parent node, dynamically updating the reward value of each path. This value is used to optimize the selection decision for the next iteration.

[0012] Furthermore, in step 1, the globally optimal node is selected using the UCT strategy. This stage aims to select the most promising patch from the patch tree as the starting point for exploration, avoiding single-path local exploration. For vulnerable programs, the patching process first treats the original vulnerable code as a special form of patch and initializes it as the root node of the patch tree. After the patch tree is initialized, each round of patch selection uses the upper confidence bound (UCT) of the tree as the selection criterion. UCT considers both the average quality of sub-patches and the degree of exploration, thus providing a more comprehensive evaluation of the potential correctness of the patch. The higher the UCT value, the more likely it is to find a reasonable patch by starting the search from the corresponding patch.

[0013] Furthermore, in the standard Monte Carlo Tree Search (MCTS) process, the UCT is defined as follows:

[0014]

[0015] in, It is the average reward of all possible operations. It is the total number of visits to the parent node. It is a child node Number of visits, It is a constant that balances utilization and exploration; during the patch selection phase, the UCT value of each patch is calculated, and the patch with the highest UCT value is selected from the existing patch tree.

[0016] Furthermore, in step 2, based on the selected base patch, candidate patches that conform to the vulnerability repair logic are generated through LLM. To avoid blind trial and error, an optimization strategy of CoT reasoning and self-reflection is adopted to improve the quality of the model output.

[0017] Furthermore, the current state of the vulnerability is interpreted from the selected patches, and a comprehensive analysis is performed on the lines of code with vulnerabilities and errors reported by test cases. Based on this analysis, some patches are modified and optimized to generate new candidate patches. The newly generated patches may repeat the errors of the previously explored patches or fall into new errors, thus updating the vulnerability state. Before generating new patches, a CoT inference step is introduced, guiding the LLM to generate a remediation inference trajectory through prompts. This process promotes transparency and structured thinking, enabling the model to identify and formulate remediation actions based on the interpretation of vulnerability behavior. In addition, by incorporating feedback from failed test cases into the inference process, the model can modify or adjust its remediation strategy accordingly. After generating new patches, the model is further prompted to reflect on its output through a self-reflection mechanism. This process encourages the model to critically evaluate the generated patches, identify potential errors, and modify its solutions accordingly. By enabling this self-correction step, the model can generate higher-quality and more reliable patches.

[0018] Further, in step 3, patch evaluation aims to assess the correctness and quality of the patches returned from the previous stage, thereby guiding the LLM to identify potentially correct patches. After the patch generation stage, test cases are executed to verify the correctness of the generated patches. If a patch passes all test cases, it is marked as a valid patch and retained for further manual inspection. If a patch fails some test cases, it is considered a patch that needs further optimization and is added as a new patch node to the existing patch tree for continued exploration. Subsequently, for patches that fail some test cases, two evaluation strategies are used to evaluate the quality of the generated patches based on the sufficiency of the test cases, with the LLM and the test serving as the evaluators.

[0019] Furthermore, in scenarios with limited test coverage, LLM is used as an evaluator to score the quality of generated patches, evaluating patch quality based on semantic and contextual information rather than solely on test results. The input to the evaluation model includes test cases, test results, vulnerable code, candidate patches, surrounding code context, CoT inference trails, and reflective outputs. The raw scores generated by the LLM are further normalized under defined constraints to ensure consistency and fairness in reward calculation. The final reward... The definition is as follows:

[0020]

[0021] For patches that cannot be compiled, the reward is set to -1; for patches identical to their parent patches, a penalty coefficient of 0.5 is applied to the original reward; since the scores provided by the LLM fluctuate, the expected value of R also needs to be calculated; the expected value of R is obtained by sampling the reward R 5 times and calculating the average value, which helps to balance the worst-case and average results; then the patch is encapsulated as a tree node and added to the patch tree; in addition, a self-evaluation strategy is adopted, using the same LLM for patch generation and evaluation, a design choice that reduces the computational overhead in the tree search process;

[0022] In scenarios with ample test cases, tests are used as the evaluator, where each vulnerability is associated with more than ten test cases covering a wide range of scenarios and boundary conditions; the reward R is defined as the proportion of test cases that pass, representing the pass rate of the candidate patch, as detailed below:

[0023]

[0024] in, This indicates the number of test cases that passed the patch. This indicates the total number of test cases.

[0025] Furthermore, in step 4, the evaluation results are fed back to the patch tree to update node attributes, providing a global decision-making basis for the next iteration. In addition to using R to evaluate patch quality, the idea of ​​MCTS is also adopted, using Q-values ​​to evaluate the quality of patches throughout the search process. The Q-value depends not only on the quality R of the patch itself but also on the quality of its child patches. After calculating the reward R for generating a patch, the Q-value of its parent patch is used as follows:

[0026]

[0027] in, For nodes After the update value, The forgetting factor (set to 0.8 in this invention to reduce the interference of old data on new decisions) is used. The current child node j value, child node Number of visits, For nodes Before the update value;

[0028] When the number of iterations reaches a preset threshold (16 or 32 in this invention, which can be adjusted according to the complexity of the vulnerability), the iteration is terminated, and all reasonable patches are output for final manual verification.

[0029] Compared with existing technologies, the significant advancements of this invention are as follows: This invention is not bound to a specific LLM and can seamlessly integrate with GPT series (such as GPT-3.5, GPT-4o-mini) and open-source large models (such as Yi-Coder-9B, Qwen2.5-Coder-7B, etc.). Only the LLM calling interface and prompt word template need to be adjusted to adapt to different resource scenarios; it can also support vulnerability repair for mainstream programming languages ​​such as Java and Python; through Monte Carlo tree search, global evaluation is performed in iteration, and low-quality patches are actively eliminated, achieving controllable patch size. Only 16-32 patches need to be generated to cover the efficient repair space, significantly reducing computational and time costs.

[0030] To more clearly illustrate the functional characteristics and structural parameters of the present invention, further explanation is provided below in conjunction with the accompanying drawings and specific embodiments. Attached Figure Description

[0031] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0032] Figure 1 This is a schematic diagram of the overall invention;

[0033] Figure 2 This is a schematic diagram showing the comparison results between the present invention and other methods;

[0034] Figure 3 This is a schematic diagram showing the comparison results between the present invention and the original LLM. Detailed Implementation

[0035] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0036] This invention proposes a method to improve automated patching techniques for large language models through iterative tree search. Monte Carlo Tree Search (MCTS) is integrated into the patch search process, performing a global evaluation of explored patches and selecting the most promising patches for subsequent optimization and generation. This effectively solves the problem of getting trapped in local optima, thereby improving the efficiency of patch search. The core of this invention includes four stages: patch selection, patch generation, patch evaluation, and patch tree update, completing vulnerability patching through multiple iterations. The specific steps are as follows:

[0037] 1) Patch selection: A UCT (Unified Confidence Bound) strategy is used to filter globally optimal nodes. This stage aims to select the most promising patch from the patch tree as the starting point for exploration, avoiding single-path local exploration. For a vulnerable program, the patching process first treats the original vulnerable code as a special form of patch and initializes it as the root node of the patch tree. After initializing the patch tree, each round of patch selection uses the upper confidence bound (UCT) of the tree as the selection criterion. UCT considers both the average quality of sub-patches and the degree of exploration, thus providing a more comprehensive evaluation of the patch's potential correctness. A higher UCT value indicates a greater likelihood of finding a reasonable patch by starting the search from the corresponding patch. In the standard Monte Carlo Tree Search (MCTS) process, UCT is defined as follows:

[0038]

[0039] in, It is the average reward of all possible operations. It is the total number of visits to the parent node. It is a child node Number of visits, It is a constant that balances utilization and exploration. During the patch selection phase, the UCT value of each patch is calculated, and the patch with the highest UCT value is selected from the existing patch tree.

[0040] 2) Patch Generation: This stage aims to generate candidate patches that conform to vulnerability remediation logic based on the selected base patches using LLM, avoiding blind trial and error. To this end, a Chain of Thought (CoT) reasoning and self-reflection optimization strategy is employed to improve the quality of the model output. Specifically, this stage interprets the current state of the vulnerability from selected patches and conducts a comprehensive analysis of errors reported in the vulnerability code and test cases. Based on this analysis, some patches are modified and optimized to generate new candidate patches. These newly generated patches may repeat the errors of previously explored patches or fall into new errors, thus updating the vulnerability state. Before generating new patches, an additional CoT reasoning step is introduced, guiding the LLM to generate a remediation reasoning trajectory through prompts. This process promotes transparency and structured thinking, enabling the model to identify and formulate remediation actions based on its interpretation of vulnerability behavior. Furthermore, by incorporating feedback from failed test cases into the reasoning process, the model can modify or adjust its remediation strategy accordingly. After generating new patches, the model is further prompted to reflect on its output through a self-reflection mechanism. This process encourages the model to critically evaluate the generated patches, identify potential errors, and modify its solutions accordingly. By enabling this self-correction step, the model can generate higher quality and more reliable patches.

[0041] 3) Patch Evaluation: This stage aims to evaluate the correctness and quality of the patches returned from the previous stage, thereby guiding the LLM to identify potentially correct patches. After the patch generation stage, test cases are executed to verify the correctness of the generated patches. If a patch passes all test cases, it is marked as a valid patch and retained for further manual review. If it fails some test cases, it is considered a patch requiring further optimization and added as a new patch node to the existing patch tree for continued exploration. Subsequently, depending on the situation, the generated patches are evaluated for quality using two evaluation strategies: LLM as the evaluator and testing as the evaluator.

[0042] In scenarios with limited test coverage, LLM is used as an evaluator to score the quality of generated patches, evaluating patch quality based on semantic and contextual information rather than solely on test results. The evaluation model's input includes test cases, test results, vulnerable code, candidate patches, surrounding code context, CoT inference trails, and reflective output. The raw scores generated by LLM are further normalized under defined constraints to ensure consistency and fairness in reward calculation. Final reward... The definition is as follows:

[0043]

[0044] For patches that cannot be compiled, the reward is set to -1. For patches identical to their parent patches, a penalty coefficient of 0.5 is applied to the original reward. Since the scores provided by the LLM fluctuate, the expected value of R also needs to be calculated. The expected value of R is obtained by sampling the reward R five times and calculating the average, which helps balance the worst-case and average results. The patch is then encapsulated as a tree node and added to the patch tree. Furthermore, a self-evaluation strategy is employed, using the same LLM for patch generation and evaluation; this design choice reduces the computational overhead during the tree search process.

[0045] In scenarios with ample test cases, tests are used as the evaluator, where each vulnerability is associated with more than ten test cases covering a wide range of scenarios and boundary conditions. The reward R is defined as the percentage of test cases that pass, representing the pass rate of the candidate patch, as shown below:

[0046]

[0047] 4) Patch Tree Update: In this stage, the evaluation results are fed back to the patch tree, updating node attributes to provide a global decision-making basis for the next iteration. Besides using R to evaluate patch quality, the idea of ​​MCTS is also adopted, using Q-values ​​to evaluate the quality of patches throughout the search process. The Q-value depends not only on the quality R of the patch itself but also on the quality of its child patches. After calculating the reward R for generating a patch, the Q-value of its parent patch is updated as follows:

[0048]

[0049] in, For nodes After the update value, The forgetting factor (set to 0.8 in this invention to reduce the interference of old data on new decisions) is used. The current child node j value, child node Number of visits, For nodes Before the update value.

[0050] When the number of iterations reaches a preset threshold (16 or 32 in this invention, which can be adjusted according to the complexity of the vulnerability), the iteration is terminated, and all reasonable patches are output for final manual verification.

[0051] Example

[0052] This embodiment uses an Ubuntu 20.04 server equipped with two NVIDIA Tesla V100 GPUs (for open-source LLM inference; if using API models such as GPT-3.5 / GPT-4o-mini, a regular CPU server is sufficient, but network connectivity must be guaranteed). The core logic is implemented using PyTorch and Transformers; tiktoken is used to track LLM token consumption (for cost calculation); and the JUnit testing framework is integrated for executing test cases and evaluating patches.

[0053] Two datasets were used: QuixBugs (Java only) and Defects4J (both versions, Defects4J-v1.2 and Defects4J-v2). Each vulnerability in the input data must contain three types of information: the vulnerability code, a set of test cases, and a developer reference patch (used to ultimately verify the effectiveness of the patch).

[0054] Figure 1 This diagram illustrates a software repair method based on a large model and iterative tree search, as implemented in this invention. The specific implementation steps are as follows:

[0055] 1) Patch selection: Initialize the patch tree by using the original vulnerability in each input data as the root node. Each node contains patch content, access count, Q-value (cumulative quality score), and a list of child nodes. Starting from the root node, recursively calculate the UCT value of all child nodes; select the node with the highest UCT value; if a node has no unexpanded child nodes, then that node is the currently selected patch; if it has been expanded, continue to calculate the UCT of the child nodes until the target node is found.

[0056] 2) Patch generation: Based on the selected patch, combined with defect code, test code, and test errors, a thought chain (CoT) for defect cause analysis and repair step planning is generated. Candidate patches are generated based on the thought chain, and the rationality of the patches is verified through the self-reflection module. Reflection content is generated, and logically consistent reasonable patches are initially screened.

[0057] 3) Patch evaluation quantifies the quality of candidate patches, providing reward signals for patch tree updates and distinguishing between reasonable patches, patches requiring further optimization, and buggy patches. If a patch passes all test cases, it is marked as a reasonable patch. If a patch fails to compile, it is directly marked as a buggy patch, with a reward R of -1. If a patch is completely identical to its parent patch, the reward R is the parent patch's reward × 0.5. If a patch fails some test cases, it is marked as a partial patch and its quality is evaluated. For vulnerabilities with few test cases, LLM-as-Judge is used as the evaluation strategy. LLM is combined with semantics and context for scoring, and a 5-times average is calculated. The reward is calculated as follows:

[0058]

[0059] For vulnerabilities with sufficient test cases, Test-as-Judge is used as the evaluation strategy. Test cases are executed in a sandbox environment, the pass rate is calculated, and the reward is calculated as follows:

[0060]

[0061] 4) Patch tree update: Integrate the new patch and evaluation results into the patch tree to provide updated node information for the next iteration. Starting from the parent node of the new node, backtrack upwards to the root node and update the Q-values ​​of all ancestor nodes:

[0062]

[0063] When the number of iterations reaches a preset threshold (16 or 32 in this invention, which can be adjusted according to the complexity of the vulnerability), the iteration is terminated, and all reasonable patches for the vulnerability are output for final manual verification.

[0064] Figure 2 The comparison results of this invention with other common methods on the Defects4J and QuixBugs datasets are shown. On the Defects4J dataset, APRMCTS achieved the highest number of vulnerability fixes (201), fixing 37 more vulnerabilities than the second-ranked RepairAgent. Specifically, this invention fixed 108 and 93 vulnerabilities on Defects4J-v1.2 and Defects4J-v2, respectively, ranking second and first. Furthermore, APRMCTS provides more valid fixes than previous studies: specifically, this invention obtained 280 valid fixes, 94 more than RepairAgent.

[0065] Figure 3This document presents the comparison results of this invention with the original LLM on the Defects4J and QuixBugs datasets. The results show that adding Monte Carlo tree search improves the remediation capabilities of all seven LLMs, with Yi-Coder-9B, Qwen2.5-Coder-7B, GPT-4o-mini, and GPT-3.5 showing the most significant improvements, fixing 37, 28, 30, and 27 more vulnerabilities, respectively. Furthermore, when the patch size is set to 32, GPT-3.5 with Monte Carlo tree search can fix 201 vulnerabilities, 69 more than the original GPT-3.5. Llama-3.1-8B and Qwen2.5-Coder-3B also show some improvement, each fixing 9 more vulnerabilities. Regarding vulnerability types, the success rate of fixing single-line (SL) and single-block (SH) vulnerabilities is significantly higher than that of single-function (SF) vulnerabilities. Compared to the original LLM, this invention significantly enhances the effectiveness of LLM in fixing SF vulnerabilities, demonstrating its unique advantage in fixing complex vulnerabilities.

[0066] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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.

[0067] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A software repair method based on a large model and iterative tree search, characterized in that, The Monte Carlo Tree Search (MCTS) is integrated into the patch search process. Explored patches are comprehensively evaluated, and the most promising patches are selected for further optimization and generation using a large language model. Through multiple iterations, the vulnerability is ultimately fixed. The specific steps include: Step 1: Patch selection; Based on the UCT strategy, select the highest-scoring node from the patch tree that balances average quality and exploration level as the basis for subsequent optimization; Step 2, Patch Generation: Using the Large Language Model (LLM) combined with the CoT reasoning and self-reflection mechanism, higher quality candidate patches are generated for selected nodes. Step 3: Patch evaluation; quality rewards are given to candidate patches based on test case verification and LLM scoring. Calculate the value and add it as a new node to the tree; Step 4: Patch tree update; propagate the reward value of the current node back to the parent node, dynamically updating the reward value of each path. This value is used to optimize the selection decision for the next iteration.

2. The software repair method based on large model and iterative tree search according to claim 1, characterized in that, In step 1, the optimal global node is selected using the UCT strategy. For vulnerable programs, the patching process first treats the original vulnerable code as a special form of patch and initializes it as the root node of the patch tree. After the patch tree is initialized, each round of patch selection uses the upper confidence bound UCT of the tree as the selection criterion. UCT considers both the average quality of sub-patches and the degree of exploration, thus providing a more comprehensive evaluation of the potential correctness of the patch. The higher the UCT value, the more likely it is to find a reasonable patch by starting the search from the corresponding patch.

3. The software repair method based on large model and iterative tree search according to claim 2, characterized in that, In the standard Monte Carlo Tree Search (MCTS) process, the UCT is defined as follows: in, It is the average reward of all possible operations. It is the total number of visits to the parent node. It is a child node Number of visits, It is a constant that balances utilization and exploration; during the patch selection phase, the UCT value of each patch is calculated, and the patch with the highest UCT value is selected from the existing patch tree.

4. The software repair method based on large model and iterative tree search according to claim 1, characterized in that, In step 2, based on the selected base patch, candidate patches that conform to the vulnerability repair logic are generated through LLM. To avoid blind trial and error, an optimization strategy of CoT reasoning and self-reflection is adopted to improve the quality of model output.

5. The software repair method based on large model and iterative tree search according to claim 4, characterized in that, The current state of the vulnerability is interpreted from the selected patches, and a comprehensive analysis is performed on the lines of code with vulnerabilities and errors reported by test cases. Based on this analysis, some patches are modified and optimized to generate new candidate patches. The newly generated patches may repeat the errors of the previously explored patches or fall into new errors, thus updating the vulnerability state. Before generating new patches, a CoT inference step is introduced to guide the LLM in generating a remediation inference trajectory through prompts. In addition, by incorporating feedback from failed test cases into the inference process, the model can modify or adjust its remediation strategy accordingly. After generating new patches, the model is further prompted to reflect on its output through a self-reflection mechanism. This process encourages the model to critically evaluate the generated patches, identify potential errors, and modify its solutions accordingly.

6. The software repair method based on large model and iterative tree search according to claim 1, characterized in that, In step 3, after the patch generation phase, test cases are executed to verify the correctness of the generated patch; if the patch passes all test cases, it is marked as a valid patch and retained for further manual inspection; if the patch fails some test cases, it is considered as a patch that needs further optimization and is added as a new patch node to the existing patch tree for continued exploration. Subsequently, for patches that failed some test cases, two evaluation strategies were used to assess the quality of the generated patches based on the sufficiency of the test cases, with LLM as the evaluator and the test as the evaluator.

7. The software repair method based on large model and iterative tree search according to claim 6, characterized in that, In scenarios with limited test coverage, LLM is used as an evaluator to score the quality of generated patches, evaluating patch quality based on semantic and contextual information rather than solely on test results. The evaluation model's input includes test cases, test results, vulnerable code, candidate patches, surrounding code context, CoT inference trails, and reflection outputs. The raw scores generated by the LLM are further normalized under defined constraints to ensure consistency and fairness in reward calculation. The final reward... The definition is as follows: For patches that cannot be compiled, the reward is set to -1; for patches identical to their parent patches, a penalty coefficient of 0.5 is applied to the original reward; since the scores provided by the LLM fluctuate, the expected value of R also needs to be calculated; the expected value of R is obtained by sampling the reward R 5 times and calculating the average value; then the patch is encapsulated as a tree node and added to the patch tree; in addition, a self-evaluation strategy is adopted, using the same LLM for patch generation and evaluation, a design choice that reduces the computational overhead in the tree search process; In scenarios with ample test cases, tests are used as the evaluator, where each vulnerability is associated with more than ten test cases covering a wide range of scenarios and boundary conditions; the reward R is defined as the proportion of test cases that pass, representing the pass rate of the candidate patch, as detailed below: in, This indicates the number of test cases that passed the patch. This indicates the total number of test cases.

8. The software repair method based on large model and iterative tree search according to claim 1, characterized in that, In step 4, the evaluation results are fed back to the patch tree to update node attributes, providing a global decision-making basis for the next iteration. Besides using R to evaluate patch quality, the idea of ​​MCTS is also adopted, using Q-values ​​to evaluate the quality of patches throughout the search process. The Q-value depends not only on the quality R of the patch itself but also on the quality of its child patches. After calculating the reward R for generating a patch, the Q-value of its parent patch is used as follows: in, For nodes After the update value, Forgetting factor, The current child node j value, child node Number of visits, For nodes Before the update value; When the number of iterations reaches a preset threshold, the iteration is terminated, and all reasonable patches are output for final manual verification.

Images