Code library increment updating method, system and equipment based on AI programming and medium

Abstract

The invention provides a code library incremental updating method, system and device based on AI programming and a medium, and the method comprises the steps: if the change of a code file is detected, obtaining a changed file, constructing a dependency relationship of the changed file in a dependency graph based on the import or reference grammar of at least two programming languages, and updating the changed file according to the dependency relationship; visited nodes in the updated dependency graph and associated nodes having a dependency relationship with the visited nodes are visited layer by layer along a back propagation path, the associated nodes are forward dependency, reverse dependency or bidirectional dependency of the visited nodes, and all target files possibly affected by file change in the updated code library are determined; according to the method, the semantic vector index of the target file is updated to the vector index library, so that the updating of the local index in the vector index library is ensured, all indexes influenced by the file updating in the code library can be covered, and the updating accuracy of the local index of the changed file is improved; and the efficiency of updating the local index of the changed file is also ensured.

Description

Technical Field

[0001] This application relates to the field of code repository management technology, and in particular to a method, system, device and medium for incremental updating of code repositories based on AI programming. Background Technology

[0002] With the expansion of software development and the popularization of agile development models, modern codebases are constantly evolving at a high frequency. Frequent code commits and merges necessitate that code semantic vector indexing systems be able to update rapidly to ensure that developers can retrieve the latest code content in the shortest possible time.

[0003] Traditional full-scale reconstruction refactoring involves reprocessing the entire codebase after each code change, updating the modified code to the codebase while simultaneously rebuilding the semantic vector index. While this approach maintains index accuracy and consistency, it incurs extremely high computational costs and has a long update cycle, leading to significant resource waste in large projects. Furthermore, in actual development, each code commit involves only a small number of file changes, yet recalculating the vector representations of all files results in extremely low time and computational resource utilization. To address this issue, some systems employ dirty tagging, updating only directly modified files. While dirty tagging speeds up updates, it ignores complex dependencies between code files. For example, when file A depends on file B, changes to file B often affect the semantic understanding of A. Dirty tagging fails to capture these indirect changes, leading to gradual index distortion and a decline in retrieval quality.

[0004] In other words, when submitting code change events, if a full rebuild method is used, the accuracy of the updated index is guaranteed, but the index update efficiency is low and the cost is high. If a dirty marking method is used, the index update efficiency is guaranteed, but the accuracy of the updated index is low. Neither of the above methods can guarantee the accuracy and efficiency of the index update at the same time. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, system, device, and medium for incremental updates of a codebase based on AI programming, in order to at least solve or alleviate the above-mentioned problems.

[0006] According to a first aspect of the embodiments of this application, an incremental update method for a code library based on AI programming is provided, applied to a computer device. The method includes: if a change to a code file is detected, obtaining the changed file; constructing the dependency relationship of the changed file in a dependency graph based on the import syntax or reference syntax of at least two programming languages ​​to obtain an updated dependency graph, wherein the updated dependency graph is a directed graph indicating the forward and reverse dependencies between code files in the code library; visiting dirty nodes and associated nodes with dependencies on the dirty nodes layer by layer along a backpropagation path in the updated dependency graph, determining the code file corresponding to the dirty node and the code file corresponding to the associated node as target files, wherein the dependency relationship between the dirty node and the associated node includes at least one of forward and reverse dependencies; calculating the semantic vector index of the target file using an AI model, and updating the semantic vector index of the target file to a vector index library.

[0007] In some optional implementations, the step of visiting the dirty nodes and associated nodes that have a dependency relationship with the dirty nodes in the updated dependency graph layer by layer along the back propagation path includes: visiting the dirty nodes and associated nodes in the updated dependency graph layer by layer along the back propagation path based on a loop detection mechanism.

[0008] In some optional implementations, the target file includes at least one of the following: the modified file; a first code file that has a direct dependency on the modified file; and a second code file that has a transitive dependency on the modified file; wherein, the direct dependency means that there is a directed path of length 1 between the two nodes, and the transitive dependency means that there is a directed path of length greater than or equal to 2 between the two nodes.

[0009] In some optional implementations, constructing the dependency relationships of the modified files in the dependency graph based on the import or reference syntax of at least two programming languages ​​includes: performing cross-language dependency identification on the modified files based on the import or reference syntax of the at least two programming languages ​​to determine that the modified files have a direct dependency relationship with a first code file in the code library; updating the dependency information of the node corresponding to the modified files and the node corresponding to the first code file in the dependency graph based on the direct dependency relationship between the modified files and the first code file; wherein, the direct dependency relationship refers to the existence of a directed path of length 1 between two nodes.

[0010] In some optional implementations, before calculating the semantic vector index of the target file using an AI model, the method includes: determining the total number of files in the target file; triggering an adaptive index update decision mechanism and performing the following steps to dynamically determine the index update mode of the target file: dynamically calculating a first threshold and a second threshold based on the total number of files and the system load of the operating system running on the computer device, wherein the first threshold is less than the second threshold; if the total number of files is less than the first threshold, determining to update the semantic vector index of the target file in a real-time synchronous update mode; if the total number of files is greater than or equal to the first threshold and less than the second threshold, determining to update the semantic vector index of the target file in a batch asynchronous update mode; if the total number of files is greater than or equal to the second threshold, determining to update the semantic vector index of the target file in a phased update mode, wherein the phased update mode is an index update mode that divides a real-time synchronous update stage into a batch asynchronous update stage, wherein, in the real-time synchronous update stage, a portion of the code files in the target file are updated synchronously in real time, and after the real-time synchronous update is completed, the batch asynchronous update stage is entered to batch asynchronously update the remaining portion of the code files in the target file.

[0011] In some optional implementations, the step of determining to update the semantic vector index of the target file in a phased update mode if the total number of files is greater than or equal to the second threshold includes: if the total number of files is greater than or equal to the second threshold and less than the third threshold, then determining to update the semantic vector index of the target file in the phased update mode; the method further includes: if the total number of files is greater than or equal to the third threshold, then determining to reconstruct the semantic vector index in the vector index library based on the code files in the code library in a full reconstruction mode; wherein, the second threshold is less than the third threshold.

[0012] In some optional implementations, the step of calculating the semantic vector index of the target file using an AI model includes: performing adaptive batch encoding on the target file using an AI model to generate the semantic vector index of the target file.

[0013] In some optional implementations, the method further includes: calculating the semantic vector index of each code file in the code library using the AI ​​model to obtain multiple first vector indices; sampling multiple second vector indices corresponding to multiple third code files from the updated vector index library, wherein the third code files are part or all of the target file; calculating the similarity between the first vector index and the second vector index of the same third code file to obtain multiple similarities; determining the error caused by the partial update of the vector index library based on the multiple similarities; if the error is less than an error threshold, ending the update of the vector index library; if the error is greater than or equal to the error threshold, rolling back the updated vector index library to the vector index library before the update.

[0014] According to a second aspect of the embodiments of this application, an AI-based incremental update system for a codebase is provided. The system includes: a dependency graph management module, configured to, if a change to a code file is detected, obtain the changed file, and construct the dependency relationship of the changed file in the dependency graph based on import syntax or reference syntax of at least two programming languages ​​to obtain an updated dependency graph, wherein the updated dependency graph is a directed graph indicating the forward and reverse dependencies between code files in the codebase; a dependency propagation module, configured to, along the backpropagation path, access dirty nodes and associated nodes with dependencies on the dirty nodes in the updated dependency graph layer by layer, determine the code file corresponding to the dirty node and the code file corresponding to the associated node as target files, wherein the dependency relationship between the dirty node and the associated node includes at least one of forward and reverse dependencies; and an encoding and index update module, configured to, through an AI model, calculate the semantic vector index of the target file, and update the semantic vector index of the target file to a vector index library.

[0015] According to a third aspect of the embodiments of this application, a computer device is provided, the computer device comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, the executable instruction causing the processor to execute the incremental update method of the code library based on AI programming as described in any of the first aspects.

[0016] According to a fourth aspect of the embodiments of this application, a computer storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, it implements the incremental update method of the code library based on AI programming as described in any of the first aspects.

[0017] According to a fifth aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions that instruct a computer device to perform an incremental update method for a codebase based on AI programming as described in any of the first aspects.

[0018] According to the AI-based incremental update method for codebases provided in this application, if a change to a code file is detected, the changed file is obtained. Then, based on the import or reference syntax of at least two programming languages, the dependency relationship of the changed file is constructed in the dependency graph. The dirty nodes in the updated dependency graph and the associated nodes that have a dependency relationship with the dirty nodes are accessed layer by layer along the back propagation path. The associated nodes can be the forward dependency of the dirty node, the reverse dependency of the dirty node, or the bidirectional dependency of the dirty node. This determines all target files in the updated codebase that may be affected by the file change. The semantic vector index of the target file is updated to the vector index library. This ensures that the update of the local index in the vector index library can cover all indexes affected by the file update in this codebase, improving the accuracy of the local index update for the changed file and ensuring the retrieval quality of the index in the updated vector index library. At the same time, the local index update for the changed file also maintains the index update efficiency. Secondly, by constructing the file dependency relationship through the import or reference syntax of two or more programming languages, the integrity and accuracy of dependency propagation can be ensured. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0020] Figure 1 This is a flowchart of an AI-based incremental update method for a codebase provided in an exemplary embodiment of this application; Figure 2 This is a flowchart of an update strategy selection method provided in an exemplary embodiment of this application; Figure 3 This is a flowchart of a dependency graph construction and incremental update method provided in an exemplary embodiment of this application; Figure 4 This is a block diagram of an AI-based incremental codebase update system provided in an exemplary embodiment of this application; Figure 5 This is a flowchart illustrating the system operation during incremental updates, provided in an exemplary embodiment of this application. Figure 6This is a structural diagram of a computer device provided in an exemplary embodiment of this application. Detailed Implementation

[0021] The present application is described below based on embodiments, but it is not limited to these embodiments. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without these details. To avoid obscuring the essence of the present application, well-known methods, processes, and flows are not described in detail. Furthermore, the accompanying drawings are not necessarily drawn to scale.

[0022] With the expansion of software development and the popularization of agile development models, modern codebases are constantly evolving at a high frequency. Frequent code commits and merges necessitate that code semantic vector indexing systems be able to update rapidly to ensure that developers can retrieve the latest code content in the shortest possible time.

[0023] Scheduled full index rebuilding rebuilds the index of all code files via a scheduled task (e.g., executed daily at midnight), ensuring index consistency and accuracy, but failing to meet real-time requirements. Index latency is typically several hours, requiring developers to wait a considerable amount of time after code submission before retrieving the latest content. This approach has extremely low resource utilization, as each rebuild requires repeatedly processing a large number of unchanged files, resulting in significant waste of processor computing and energy costs. As project size increases, index rebuilding time grows linearly or even superlinearly; the rebuilding process for very large projects often exceeds the available maintenance time window, making scalability difficult.

[0024] File-level dirty tagging is used by native editors such as VS Code. This method listens for file change events and only recalculates the embedding vector for modified files, resulting in fast updates. However, it suffers from a continuous degradation in accuracy. Because this method does not consider code dependency propagation, the semantic representation of indirectly dependent files gradually becomes outdated, causing retrieval accuracy to drop by about 13% within six months. This degradation process is slow and difficult to detect, lacks a quantifiable index aging assessment mechanism, and ultimately still requires periodic full rebuilds for repair, thus losing the efficiency advantage of incremental updates.

[0025] Timestamp-based incremental update schemes selectively update files by comparing their modification times, enabling batch processing of recently modified files. However, this scheme inherently inherits the limitations of the dirty marking method. It cannot handle common Git operations such as file renaming, moving, or branch merging, and is prone to index omissions or redundant updates. Furthermore, timestamp mechanisms may exhibit inconsistencies in distributed or network file systems, further impacting index reliability.

[0026] To address the above technical issues, this application provides an incremental update method for a codebase based on AI programming. The implementation of this method can be found in the following embodiments.

[0027] Please refer to Figure 1 This document illustrates a flowchart of an AI-based incremental codebase update method provided in an exemplary embodiment of this application. The method is applied to a computer device and includes: Step 101: If a change to the code file is detected, obtain the changed file.

[0028] When a computer device detects a change to a code file, it retrieves the changed file. For example, if the computer device listens for a code commit event, it retrieves the changed file from the code repository.

[0029] Changes to code files include, but are not limited to: adding code files; deleting code files; replacing code files; modifying code within code files, where code modification includes at least one of adding, deleting, and modifying; merging branches of code files; and renaming code files. Correspondingly, changed files include, but are not limited to: newly added code files, replaced code files, modified code files, deleted code files, code files merged from branches, and renamed code files.

[0030] The changed files can be committed via local Git commands or online via version control platforms, online development platforms, etc. Taking the addition of a code file as an example, assuming the code repository is a Git repository, the computer receives the newly added code file committed via local Git commands, then updates the code repository with the newly added code file and retrieves the newly added code file.

[0031] Optionally, the changed documents include one or more, "multiple" meaning "at least two".

[0032] Step 102: Based on the import or reference syntax of at least two programming languages, construct the dependency relationships of the changed files in the dependency graph to obtain the updated dependency graph.

[0033] Dependencies indicate the association between one code file and another, such as the execution of one code file depending on another. Dependencies include positive dependencies and negative dependencies. Taking a code file as a reference, code files that directly or indirectly depend on the reference are considered to have a positive dependency; code files that directly or indirectly depend on the reference are considered to have a negative dependency. For example, taking code file A as the reference, if code file A directly or indirectly depends on code file B, then code file B is a file that code file A positively depends on; if code file C directly or indirectly depends on code file A, then code file C is a file that code file A negatively depends on.

[0034] If a code file depends on another code file both in a positive direction and in a negative direction, then there is a bidirectional dependency between the two code files.

[0035] The updated dependency graph is a directed graph that indicates the positive and negative dependencies between various code files in the codebase. That is, this dependency graph belongs to the bidirectional dependency graph, which is a directed graph data structure that maintains both positive and negative dependencies. In the bidirectional dependency graph, the negative dependency edge supports O(1) time complexity for querying "which files depend on a certain file", which is the key to efficient dependency propagation.

[0036] A dependency graph consists of nodes and dependency edges. A single node represents a single code file, and a dependency edge is a directed line segment connecting two nodes, representing the dependency relationship between one file and another. The direction of the edge corresponds to the direction of the dependency. For example, in a dependency graph, if code file X depends on code file Y to compile / run, then there exists a directed edge from X to Y; this edge is the dependency edge. If X is the reference point, then the directed edge from X to Y is a positive dependency edge of X; if Y is the reference point, then the directed edge from X to Y is a negative dependency edge of Y. In a dependency graph, if code file Z depends on code file Y to compile / run, and code file Y also depends on code file Z to compile / run, then there exists a dependency edge that points to both Y and Z, which is a bidirectional dependency edge.

[0037] The computer device performs dependency identification on the modified file, determining a direct dependency relationship between the modified file and a first code file in the code repository. This dependency identification uses the modified file as the reference subject, specifying whether the modified file has a forward dependency on the first code file and / or a backward dependency on the first code file. There can be one or more (at least two) first code files, which can be code files that the modified file has a forward dependency on, a code file that the modified file has a backward dependency on, or a code file that the modified file has a bidirectional dependency on. Then, based on the direct dependency relationship between the modified file and the first code file, the computer device updates the dependency information of the nodes corresponding to the modified file and the nodes corresponding to the first code file in the dependency graph, such as by adding, deleting, or modifying the dependency information of nodes. For example, the dependency information includes dependency edges of nodes. The computer device can add and / or delete dependency edges of nodes corresponding to the modified file and the nodes corresponding to the first code file based on the direct dependency relationship. A direct dependency relationship means that there exists a directed path of length 1 between the two nodes.

[0038] For example, if the modified file is a newly added code file, the computer device will create a dirty node corresponding to the newly added code file in the dependency graph, and based on the direct dependency relationship between the newly added code file and the first code file, establish dependency edges between the dirty node and the corresponding node of the first code file. If the modified file is a deleted file, the computer device will delete the node corresponding to the deleted file and the dependency edges recorded under that node in the dependency graph, and delete the dependency edges recorded under the node corresponding to the first code file and the node corresponding to the deleted file. If the modified file is a code file with modified code, and the code files that the modified file depends on have been changed, such as by adding dependent code files, then correspondingly, dependency edges will be established between the modified file and the newly added dependent code files.

[0039] Computer devices can identify cross-language dependencies of modified files based on import or reference syntax in at least two programming languages, determining a direct dependency between the modified file and the first code file in the codebase. That is, the computer device identifies cross-language dependencies of modified files by parsing the import or reference syntax in at least two programming languages. These programming languages ​​include JavaScript, TypeScript, Python, Java, C, C++, C#, Go, Rust, etc. Import syntax includes `import`, `require`, `using`, etc.; reference syntax includes `#include`, `extern`, `@reference`, etc. For example, the computer device may have pre-defined import or reference syntax rules for multiple programming languages ​​such as Python, Java, and C#. Each programming language has independent import or reference syntax rules, and the computer device sequentially uses these rules to identify cross-language dependencies of modified files. For codebases containing multiple programming languages, automatically identifying cross-language dependencies based on the import or reference syntax of different languages ​​ensures the integrity and accuracy of dependency propagation. This is a necessary condition for guaranteeing the correctness of the dependency graph. Furthermore, during incremental updates of the codebase, cross-language dependency identification more accurately completes the incremental update of the dependency graph, laying the foundation for accurately identifying files affected by the incremental update. If the construction and updating of the dependency graph does not support cross-language dependency identification, the dependency propagation chain will be broken, the set of affected files will be incomplete, and this will lead to distortion of the semantic vector index update.

[0040] Optionally, the computer device updates at least one of the forward and reverse dependency edges between the corresponding node of the modified file and the corresponding node of the first code file based on at least one of the forward and reverse dependency relationships between the modified file and the first code file. For example, if there is a forward dependency relationship between the modified file and the first code file, a forward dependency edge is established or deleted between the corresponding node of the modified file and the corresponding node of the first code file; if there is a reverse dependency relationship between the modified file and the first code file, a reverse dependency edge is established or deleted between the corresponding node of the modified file and the corresponding node of the first code file; if there is a bidirectional dependency relationship between the modified file and the first code file, a bidirectional dependency edge is established or deleted between the dirty node and the corresponding node of the first code file.

[0041] In a dependency graph, nodes that are updated are called dirty nodes. Specifically, nodes whose code files have changed, whose dependencies have changed, and whose dependency information has become invalid are all considered dirty nodes. For example, if the dependency information of the node corresponding to the first code file changes, then the node corresponding to the first code file is a dirty node; if the changed file is a newly added code file or a modified code file, then the node corresponding to the changed file is also a dirty node.

[0042] Step 103: Access the dirty nodes and associated nodes that have dependencies on the dirty nodes in the updated dependency graph, and determine the code files corresponding to the dirty nodes and the code files corresponding to the associated nodes as target files. The dependency relationship between the dirty nodes and the associated nodes includes at least one of the forward dependency relationship and the reverse dependency relationship.

[0043] After updating the dependency graph, the computer device propagates layer by layer along either the forward or backward propagation path, accessing the updated dependency graph. For example, it accesses each node along the backward propagation path of the dirty node, starting from the dirty node, then accessing node 1 pointed to by the backward dependency edge of the dirty node, identifying node 1 as an associated node, continuing to access node 2 pointed to by the backward dependency edge of node 1, identifying node 2 as an associated node, and so on, until node N is accessed and there is no backward dependency edge of node N in the updated dependency graph, then the dependency propagation on the backward propagation path of node N stops.

[0044] Optionally, the computer device uses a loop detection mechanism to visit dirty nodes and associated nodes in the updated dependency graph layer by layer along the forward or backward propagation path. That is, the computer device also performs loop closure detection on the updated dependency graph through the loop detection mechanism. Specifically, after visiting a node, the node is marked as visited and its cached state is cached so that it can be skipped directly when the node is visited again in the future.

[0045] For example, the computer device, based on a cycle detection mechanism, starts with a dirty node and visits the updated dirty and associated nodes in the dependency graph layer by layer along the back propagation path. Alternatively, the computer device, based on a cycle detection mechanism, starts with a dirty node and visits the updated dirty and associated nodes in the dependency graph layer by layer along the forward propagation path. The computer device, based on a cycle detection mechanism, starts with a dirty node and visits the updated dirty and associated nodes in the dependency graph layer by layer along both the forward and back propagation paths.

[0046] Optionally, the target file includes at least one of the following: a modified file; a first code file that has a direct dependency on the modified file; and a second code file that has a transitive dependency on the modified file. A direct dependency means there exists a directed path of length 1 between two nodes, and a transitive dependency means there exists a directed path of length 2 or greater between two nodes. Here, the path length between two nodes with a direct dependency is 1. For example, in the above example, if the dirty node is the node corresponding to the newly added code file, then the length between "node 1" and the "dirty node" is equal to 1, and the code file corresponding to "node 1" is the first code file; the length between "node 2" and the "dirty node" is equal to 2, and the code file corresponding to "node 2" is the second code file.

[0047] If the modified file is a code file obtained through a modification method other than deletion, then the target file includes at least the modified file; further, the target file may also include at least one of a first code file that has a direct dependency on the modified file and a second code file that has a transitive dependency on the modified file. If the modified file is a deleted code file, then the target file includes at least a second code file that has a transitive dependency on the modified file, but does not include the modified file; further, the target file may also include a second code file that has a transitive dependency on the modified file.

[0048] Both the dependency graph before and after the update contain the forward and reverse dependencies between code files. Therefore, by following the forward or reverse propagation path, the computer device can determine the other code files that the code file has a forward or reverse dependency on.

[0049] For example, computer devices can also employ breadth-first search (BFS) or depth-first search (DFS) algorithms, propagating layer by layer along the forward or backward propagation path to access dirty and associated nodes in the updated dependency graph. During the access process, a loop detection mechanism is used to perform loop closure checks on the updated dependency graph. BFS is a graph traversal algorithm that expands outward layer by layer from the starting node, visiting all adjacent nodes before moving to the next level. It is used to propagate the effects of changes along the dependency graph, with a time complexity of O(V+E), where V is the number of nodes and E is the number of edges. DFS is an algorithm used to traverse or search data structures such as trees and graphs. Starting from the starting node, it explores as deeply as possible along a path until it cannot continue, then backtracks to the previous node, changes a branch, and continues exploring, repeating this process until the target is found or all reachable nodes are visited.

[0050] Computer devices can also cache accessed dirty nodes and associated nodes, so as to obtain the code file corresponding to the dirty node and the code file corresponding to the associated node as the target file based on the dirty node and associated node.

[0051] Step 104: Calculate the semantic vector index of the target file using the AI ​​model, and update the semantic vector index of the target file to the vector index library.

[0052] The computer device retrieves the target file from the code repository, then uses an AI model to calculate the semantic vector index of the target file and updates it to the vector index library.

[0053] This AI model can be a pre-trained language model or a pre-trained large language model. It encodes code files into embedding vectors and outputs these embedding vectors as semantic vector indices for the code files. For example, a computer device uses a pre-trained language model to convert code files into embedding vectors in a high-dimensional vector space, allowing semantically similar code to be located close together in the vector space. For instance, this AI model can employ the CodeBERT model. For example, by encoding the code file using the CodeBERT model, a 768-dimensional semantic vector can be generated, and this 768-dimensional semantic vector can be used as the semantic vector index of the code file in a vector index library, which can then be used for similarity retrieval and semantic clustering.

[0054] For example, the computer device also generates a file set containing target files, then calculates the semantic vector index of each target file in the file set, and updates the semantic vector index of each target file in the file set to the vector index library. For instance, the computer device adds the semantic vector index of the target file to the vector index library, and if the original semantic vector index of the target file exists in the vector index library, it also deletes the original semantic vector index.

[0055] In summary, the AI-based incremental update method for codebases provided in this embodiment, if a change to a code file is detected, obtains the changed file. Then, based on the import or reference syntax of at least two programming languages, it constructs the dependency relationships of the changed file in the dependency graph. It accesses dirty nodes in the updated dependency graph and associated nodes that have dependencies on dirty nodes. The associated nodes can be positive dependencies, negative dependencies, or bidirectional dependencies on dirty nodes. This identifies all target files in the updated codebase that may be affected by file changes. The semantic vector index of the target files is then updated to the vector index library. This ensures that the update of local indexes in the vector index library can cover all indexes affected by the file updates in this codebase, improving the accuracy of local index updates for changed files and ensuring the retrieval quality of the indexes in the updated vector index library. At the same time, the local index updates for changed files also maintain index update efficiency. Furthermore, incremental update is a strategy that only calculates and updates the changed parts, rather than recalculating all data. Verification has shown that updating only the semantic vector indexes of modified files and their dependent files in the codebase, without reprocessing the semantic vector indexes of all files in the codebase, can save over 95% of computational resources. Existing code indexing systems typically use the "changed file itself" as the update boundary, updating only the semantic vector index of the changed file itself. In contrast, the method provided in this application uses the "dependency propagation scope" as the update boundary, updating not only the semantic vector index of the changed file itself, but also identifying files with dependencies on the changed file through dependency propagation and updating the semantic vector indexes of these files. While ensuring semantic consistency, this differentiated design achieves a balance between high real-time performance and low computational cost, i.e., timely incremental updates and reduced overall computational cost. In addition, this method constructs file dependencies based on import or reference syntax of two or more programming languages, ensuring the integrity and accuracy of dependency propagation. If the construction and updating of the dependency graph does not support cross-language dependency identification, the dependency propagation chain will be interrupted, resulting in an incomplete set of affected files and thus causing distortion in the semantic vector index update.

[0056] This method employs a "dependency graph," an information structure that simultaneously maintains both positive and negative dependencies, to depict the bidirectional reference relationships between code files. This structure directly determines "which files depend on a certain file," enabling constant-level dependency tracing and thus supporting rapid incremental updates. This approach plays a core role in the dependency propagation algorithm, achieving rapid location of files affected by code changes by maintaining negative dependency edges between nodes, avoiding the need for a full database scan in traditional unidirectional indexes. Secondly, when a code file is modified, only the dependencies directly related to that file are updated, rather than rescanning all files; real-time maintenance of dependencies is achieved through local updates, significantly reducing reconstruction costs and ensuring the accuracy of dependency data. The method also combines the negative index with a loop detection mechanism to identify dependency cycles and treat files within the cycle as a whole unit for propagation and updating, avoiding redundant calculations and infinite recursion. This prevents repeated traversal and dependency cycle deadlocks, improving system stability and computational efficiency while maintaining linear complexity, ensuring the scalability of large-scale codebases. The introduction of a loop detection mechanism and access result caching also ensures that the propagation results are complete and efficient, guaranteeing that the vectors of all semantically affected files can be updated in a timely manner, preventing semantic vector index degradation.

[0057] This method introduces a graph traversal-based dependency propagation mechanism, recursively identifying all directly and indirectly affected files starting from one or more changed files. For example, by using a breadth-first search algorithm, it propagates layer by layer along forward and / or backward propagation paths to identify the set of all directly or indirectly affected files, thus more accurately covering the scope of the impact of changes on the modified files.

[0058] In summary, this method maintains reverse dependencies and performs dependency propagation based on these dependencies, enabling the rapid identification of all affected files without performing a full library scan, thereby significantly reducing computational complexity and avoiding repeated traversals.

[0059] In some optional implementations, the computer device employs an adaptive index update decision mechanism, which can achieve dynamic decision-making for hierarchical index updates. These index update modes include: real-time synchronous update mode, batch asynchronous update mode, and phased update mode.

[0060] Before the computer device calculates the semantic vector index of the target file using an AI model, it determines the total number of files in the target file and then triggers an adaptive index update decision mechanism to dynamically determine the index update mode for the target file: If the total number of files is less than a first threshold, the semantic vector index of the target file is updated in a real-time synchronous update mode; if the total number of files is greater than or equal to the first threshold and less than a second threshold, the semantic vector index of the target file is updated in a batch asynchronous update mode; if the total number of files is greater than or equal to the second threshold, the semantic vector index of the target file is updated in a phased update mode. The phased update mode is an index update mode that divides the real-time synchronous update stage into a batch asynchronous update stage. In the real-time synchronous update stage, a portion of the code files in the target file are updated synchronously in real time. After the real-time synchronous update is completed, the batch asynchronous update stage begins, and the remaining code files in the target file are updated asynchronously in batches. The first threshold is less than the second threshold.

[0061] The first and second thresholds are dynamically determined by the computer device using an adaptive index update decision mechanism. Specifically, after the computer device triggers the adaptive index update decision mechanism, it first dynamically calculates the first and second thresholds based on the total number of files and the system load of the operating system running the computer, and then executes the decision steps of the index update mode.

[0062] The index update mode also includes a full reconstruction mode. During the decision-making process for the index update mode, if the total number of files is greater than or equal to the second threshold and less than the third threshold, then the semantic vector index of the target file is updated using a phased update mode; if the total number of files is greater than or equal to the third threshold, then the semantic vector index in the vector index library is rebuilt based on the code files in the code repository using a full reconstruction mode; wherein, the second threshold is less than the third threshold.

[0063] The third threshold is dynamically determined by the computer device using an adaptive index update decision mechanism. Specifically, after the computer device triggers the adaptive index update decision mechanism, it first determines the first threshold, the second threshold, and the third threshold based on the total number of files and the system load.

[0064] like Figure 2 The diagram illustrates the decision-making process for the index update mode provided in this embodiment. This decision-making process includes the following steps: Step 201: The computer device calculates the total number of affected files.

[0065] The affected files include target files. The computer device counts the total number of target files.

[0066] Step 202: The computer device compares the total number of files with the threshold.

[0067] The computer device compares the total number of files N with a first threshold T1. If the total number of files N is less than the first threshold T1, then proceed to step 203. If the total number of files N is greater than or equal to the first threshold T1, then compare the total number of files N with a second threshold T2. If the total number of files N is less than the second threshold T2, then proceed to step 204. If the total number of files N is greater than or equal to the second threshold T2, then proceed to step 205.

[0068] Step 203: The computer device performs real-time synchronous updates to the index of the target file.

[0069] The computer device is set to real-time synchronization update mode to update the target file in real time.

[0070] Step 204: The computer device performs batch asynchronous updates to the index of the target file.

[0071] The computer device is configured to use batch asynchronous update mode to update target files in batches asynchronously.

[0072] Step 205: The computer device updates the index of the target file in stages.

[0073] The computer equipment is enabled in a phased update mode, which consists of two phases: the first phase is a real-time synchronous update phase, and the second phase is a batch asynchronous update phase. In the first phase, a portion of the code files in the target file are updated in real-time synchronously, and in the second phase, the remaining code files in the target file are updated in batch asynchronously.

[0074] The computer system determines the number of files affected by the incremental update. When the number of affected files (i.e., the total number of files mentioned above) is small, a real-time synchronous update mode is activated to ensure that the update results are immediately searchable. When the number of affected files is moderate, a batch asynchronous update mode is activated, grouping the affected files for parallel processing to improve throughput. When the number of affected files is large, a background phased update mode is executed, prioritizing the update of core files and completing the remaining parts in the background. The scope of core files across multiple target files can be predefined. For example, predefined core files include: the code files corresponding to dirty nodes in multiple target files, and the code files corresponding to associated nodes whose dependency edges with dirty nodes have a length less than or equal to M, where M is a positive integer. For instance, assuming M is 2, the core files include: the modified files in multiple target files, the first code file, and the second code files that the first code file directly depends on. The first code file includes code files that the modified file has a positive and / or negative dependency on, and the second code file includes code files that the first code file has a positive and / or negative dependency on. Core files can also be core files in a predefined codebase. It is necessary to identify core files in the target file. For example, core files all have core identifiers, and computer devices can identify core files in the target file based on the core identifiers.

[0075] Optionally, after determining that the total number of files is greater than or equal to the second threshold, the computer device further determines whether the total number of files is less than the third threshold. If so, a phased update mode is activated. That is, if the total number of files is greater than or equal to the second threshold and less than the third threshold, a phased update mode is activated to update the semantic vector index of the target files. The second threshold is less than the third threshold.

[0076] Alternatively, after determining that the total number of files is greater than or equal to the second threshold, the computer device activates a phased update mode and begins real-time synchronous updates of a portion of the code files in the target file. While performing real-time synchronous updates of this portion of the code files, the following steps are also executed: Step 206: If the total number of files is greater than or equal to the third threshold, the index of the target file is fully reconstructed.

[0077] While updating the semantic vector index of some code files in the vector index library in real time, the total number of files is compared with the third threshold. If the total number of files is less than the third threshold, the phased update mode continues to be applied. If the total number of files is greater than or equal to the third threshold, the system immediately switches to the full reconstruction mode to fully reconstruct the semantic vector index of all code files in the code library. That is, the semantic vector index of all code files in the code library is recalculated and then updated in the vector index library.

[0078] The hierarchical update strategy has an upper limit, or "third threshold," on the number of affected files. If the total number of files is greater than or equal to the third threshold, the computer device rebuilds the semantic vector index in the vector index library based on the code files in the code library. Instead of using the hierarchical update strategy, it directly and immediately rebuilds the vector index library corresponding to the code library. This maintains index consistency and ensures the accuracy of retrieval through an automatically triggered full index reconstruction.

[0079] For example, before executing a tiered update strategy, a computer device dynamically calculates a first threshold and a second threshold based on the total number of files and the system load of the operating system running on the computer device. These two thresholds are not fixed values, but rather tiered thresholds dynamically calculated based on real-time system load and task scale (reflected by the total number of files).

[0080] These two thresholds are obtained by adjusting two basic thresholds, which are historical experience values ​​derived from historical statistics: the computer device pre-calculates two thresholds based on the average dependency propagation scale of the codebase, and determines three intervals (e.g., <100, 100–1000, >1000) as default values ​​based on these two thresholds.

[0081] System load is a macroscopic measure of the operating system's demand for computing resources. Its core definition is the average number of tasks (processes / threads) in a runnable or uninterruptible sleep state per unit of time. The system continuously monitors metrics such as GPU / CPU usage, queue length, available video memory, and model inference throughput to determine system load; alternatively, the system determines the average number of tasks in a runnable or uninterruptible sleep state per unit of time. When system load is high, the threshold is automatically lowered to reduce the pressure on real-time update tasks; when load is low, the threshold is appropriately raised to maximize the utilization of idle resources.

[0082] Therefore, the first and second thresholds here are not fixed values, but are determined by the system based on historical experience values ​​and real-time load parameters, so that the update strategy can automatically balance real-time performance and resource consumption.

[0083] This method automatically determines the optimal update strategy based on the number of affected files and system load, including three approaches: real-time synchronization, batch asynchronous processing, and background phased processing. Through a combination of reverse dependency propagation and a hierarchical dynamic update mechanism, it achieves real-time semantic vector indexing and efficient incremental maintenance. Furthermore, a strategy selector enables automatic decision-making and priority control, balancing accuracy and response speed in the update process and ensuring stable performance across different scales. As can be seen, the thresholds in this method are not fixed presets but are determined based on historical experience values ​​and real-time load parameters—that is, dynamically calculated based on historical statistical data and real-time operating status. Secondly, the update strategy used for incremental updates is automatically decided by the system, rather than manually configured.

[0084] In some alternative implementations, the semantic vector index can be generated using adaptive batch encoding. For example, a computer device can generate the semantic vector index of the target file by adaptively batch encoding the target file using an AI model.

[0085] For example, a computer device generates a file set containing target files. It then automatically estimates the file length of each code file in the set, groups the code files into multiple file groups, and for each file group, determines the average file length of the code files within that group. Based on this average file length, it adaptively adjusts batch processing parameters, such as the batch size. Based on the adjusted batch processing parameters, it performs batch encoding on the code files in that file group, obtaining the semantic vector indexes of the code files in that group. Here, the file length of the code files is represented by the number of tokens, where a token is the smallest unit of measurement used internally by the model to represent text.

[0086] The grouping rules used to group code files within a file set can be predefined. For example, these rules could include: assigning code files in the file set to file groups corresponding to their respective length ranges, based on multiple predefined length ranges. Alternatively, the grouping rules could include: the number of files in each file group being less than or equal to a file count threshold, and the maximum file length difference between two code files in a file group being less than or equal to a length difference threshold. For instance, the number of files in each file group might be less than or equal to 32, and the maximum token difference between two code files in a file group might be less than or equal to 2. The file count threshold and length difference threshold can be set and adjusted as needed.

[0087] It should be noted that the encoding process adopts an adaptive batch encoding configuration structure to describe file grouping and computational resource allocation parameters.

[0088] The computer device calculates the average file length of each file group, and can estimate the video memory capacity required to generate the semantic vector of each file group based on the average file length. According to the availability of video memory, it dynamically calculates the maximum batch size that each file group can use, thereby maximizing throughput and avoiding video memory overflow when computing resources are limited.

[0089] This method can dynamically adjust batch processing parameters based on file length, complexity, and computing resources to achieve optimal utilization of computing resources. It has automatic grouping and degradation fault tolerance capabilities and can maintain high throughput and reliability under different hardware conditions.

[0090] In some optional embodiments, after updating the vector index library, the computer device further calculates the semantic vector index of each code file in the code library using an AI model to obtain multiple first vector indices; samples multiple second vector indices corresponding to multiple third code files from the updated vector index library, where the third code files are part or all of the target files; calculates the similarity between the first and second vector indices of the same third code file to obtain multiple similarities, i.e., each third code file corresponds to one similarity, and multiple third code files correspond to multiple similarities; determines the error caused by the local update of the vector index library based on the multiple similarities; if the error is less than the error threshold, the update of the vector index library is ended; if the error is greater than or equal to the error threshold, the updated vector index library is rolled back to the vector index library before the update.

[0091] This method verifies the update quality by sampling and comparing the vector similarity between the incremental update results and the full calculation results. The similarity between the two vectors represents the semantic distance. If the error does not exceed the error threshold, it indicates that the update quality is good. If the error exceeds the error threshold, it automatically rolls back to the previous stable version to ensure index consistency and system reliability.

[0092] Before performing the above index update steps, it is necessary to build the dependency graph first. After the dependency graph is built, if a code commit event is detected, the dependency graph is updated and the index is updated accordingly. Figure 3 The diagram shown is a flowchart of the dependency graph construction and incremental update method, which is executed by a computer device. The dependency graph construction and update process includes: Step 301, Project Initialization.

[0093] Prepare for dependency analysis. This includes configuring parameters such as project path, code language (e.g., Python / Java), and dependency resolution rules; initializing storage components such as dependency databases and caches; and loading utility dependencies, such as syntax parsers and dependency extraction libraries.

[0094] Step 302, code scanning and syntax parsing.

[0095] Read the code files and understand their syntax structure to prepare for subsequent dependency extraction. For example, traverse all code files in the project directory and filter out non-code files; use a syntax parser for the corresponding language to convert the code into an abstract syntax tree; and verify the syntactic validity of the code.

[0096] Step 303: Extract import dependencies.

[0097] Based on the parsed code files, the dependencies between code files can be identified. For example, import statements such as import / include / require are extracted from the abstract syntax tree; the code files corresponding to the import statements are parsed; and the dependency relationships between code file X and the imported code file Y are recorded, including positive dependencies and negative dependencies. A positive dependency means that code file X depends on the imported code file Y, and a negative dependency means that the imported code file Y depends on code file X.

[0098] Step 304: Construct forward and reverse dependency mappings.

[0099] Based on the dependencies extracted in step 303, a queryable mapping structure is formed, and this mapping structure is organized into a dependency graph. For example, using a code file as the key, all code files that the code file directly depends on are stored, forming a forward dependency mapping; using a code file as the key, all code files that depend on the code file are stored, forming a reverse dependency mapping; finally, the mapping structure is organized into a dependency graph, where code files are nodes and edges represent dependencies. Specifically, the dependency mapping uses dependency edges to indicate the dependencies between code files.

[0100] Step 305: Persist the storage to the dependent database.

[0101] The constructed dependency graph is stored long-term for easy subsequent querying and analysis. For example, the dependency graph containing positive and negative dependencies is stored in a dependency database; metadata such as file path, extraction time, and code version is recorded; a semantic vector index is created for each code file and stored in a vector index library to improve query efficiency.

[0102] Step 306: Listen for code commit events.

[0103] By listening to commit events of code files, continuous updates of dependency data can be achieved, preventing dependencies from becoming outdated after code file changes. For example, this can be done by integrating with an event listening service of a code repository (such as Git); listening for events such as code commits and branch merges, identifying the list of changed files, and filtering to only include the changed code files. For example, changed code files are those that have been modified, which can be newly added code files, replaced code files, modified code files, deleted code files, code files merged from branches, renamed code files, etc.

[0104] Step 307: Parse the modified file.

[0105] The modified files are parsed to extract their dependencies. This involves performing code scanning and syntax parsing on the modified files, as well as extracting import dependencies; comparing the dependencies before and after the changes, identifying newly added / deleted dependencies, and marking affected dependency chains, such as the forward and reverse dependency nodes of the modified files.

[0106] Step 308: Update the dependent edges and synchronize the index.

[0107] The changed dependencies are synchronized to the dependency graph and saved. For example, based on the results of parsing the changed files, the forward dependency mapping and / or reverse dependency mapping in the dependency graph located in the dependency database are updated; corresponding edges are added and / or deleted in the dependency graph. For example, if code file A adds a dependency on code file E, then a dependency edge is added that code file A has a forward dependency on code file E; the database index is updated synchronously to ensure that the query results are consistent with the latest dependencies.

[0108] For detailed implementation of steps 306 to 308, please refer to the AI-based incremental update method for the code library provided in the above embodiments.

[0109] In summary, the dependency graph construction and incremental update method provided in this embodiment constructs and maintains bidirectional dependency relationships between code files. The introduction of reverse dependency mapping can quickly determine all other files that depend on any given file, avoiding a full traversal. Furthermore, the dependency relationships are stored in the database as a data structure. When code changes occur, the affected files are re-parsed and the corresponding dependency edges are updated, achieving incremental updates without requiring a full rebuild, thus ensuring both accuracy and efficiency.

[0110] Please refer to Figure 4 This diagram illustrates the overall architecture of an AI-based incremental codebase update system 400 provided in an exemplary embodiment of this application. The incremental update system 400 includes: a dependency graph management module 401, a dependency propagation module 403, and an encoding and indexing update module 405.

[0111] The dependency graph management module 401 is used to obtain the changed file if a change to the code file is detected, and construct the dependency relationship of the changed file in the dependency graph based on the import syntax or reference syntax of at least two programming languages ​​to obtain an updated dependency graph. The updated dependency graph is a directed graph indicating the forward and reverse dependencies between code files in the code library. The dependency propagation module 403 is used to access the dirty nodes and the associated nodes with dependencies on the dirty nodes in the updated dependency graph layer by layer along the back propagation path, and determine the code files corresponding to the dirty nodes and the code files corresponding to the associated nodes as target files. The dependency relationship between the dirty nodes and the associated nodes includes at least one of the forward and reverse dependencies. The encoding and index update module 405 is used to calculate the semantic vector index of the target file through the AI ​​model and update the semantic vector index of the target file to the vector index library.

[0112] Optionally, the dependency graph management module 401 constructs the dependency relationships of modified files in the dependency graph based on the import or reference syntax of at least two programming languages, including: performing cross-language dependency identification on the modified files based on the import or reference syntax of at least two programming languages, and determining that there is a direct dependency relationship between the modified files and the first code file in the code library; updating the dependency information of the corresponding node of the modified files and the dependency information of the corresponding node of the first code file in the dependency graph based on the direct dependency relationship between the modified files and the first code file; wherein, a direct dependency relationship means that there is a directed path of length 1 between the two nodes.

[0113] The dependency graph management module 401 is used to build and maintain bidirectional dependencies between code files. This module extracts forward and reverse dependencies from the code files using syntax parsing techniques. For details on the dependency graph construction and incremental update methods performed by this module, please refer to [reference needed]. Figure 3 The embodiments shown will not be described in detail here.

[0114] Optionally, the dependency propagation module 403 visits the dirty nodes and associated nodes with dependencies in the updated dependency graph layer by layer along the back propagation path, including: based on the loop detection mechanism, visiting the dirty nodes and associated nodes in the updated dependency graph layer by layer along the back propagation path.

[0115] Optionally, the target file includes at least one of the following: a modified file; a first code file that has a direct dependency on the modified file; and a second code file that has a transitive dependency on the modified file; wherein, a direct dependency means that there is a directed path of length 1 between the two nodes, and a transitive dependency means that there is a directed path of length greater than or equal to 2 between the two nodes.

[0116] The dependency propagation module 403 calculates the scope of impact of a file change after detecting it. This module can also employ a breadth-first search algorithm to propagate along the reverse dependency path layer by layer, identifying all directly or indirectly affected file sets. Caching and loop detection mechanisms are introduced during the propagation process to prevent repeated traversal or getting trapped in dependency cycles.

[0117] Optionally, the encoding and index update module 405 calculates the semantic vector index of the target file through an AI model, including: performing adaptive batch encoding of the target file through an AI model to generate the semantic vector index of the target file.

[0118] Optionally, the encoding and indexing update module 405 is further configured to calculate the semantic vector index of each code file in the code library using an AI model to obtain multiple first vector indices; sample multiple second vector indices corresponding to multiple third code files from the updated vector index library, wherein the third code files are part or all of the target files; calculate the similarity between the first vector index and the second vector index of the same third code file to obtain multiple similarities; determine the error caused by the local update of the vector index library based on the multiple similarities; if the error is less than the error threshold, the update of the vector index library is terminated; if the error is greater than or equal to the error threshold, the updated vector index library is rolled back to the vector index library before the update.

[0119] In some alternative implementations, the incremental update system 400 also includes a hierarchical strategy selection module 404.

[0120] The hierarchical strategy selection module 404 is used to determine the total number of files in the target file before calculating the semantic vector index of the target file through the AI ​​model; it triggers an adaptive index update decision mechanism and executes the following steps to dynamically determine the index update mode of the target file: based on the total number of files and the system load of the operating system running on the computer device, it dynamically calculates a first threshold and a second threshold, where the first threshold is less than the second threshold; if the total number of files is less than the first threshold, it determines to update the semantic vector index of the target file in a real-time synchronous update mode; if the total number of files is greater than or equal to the first threshold and less than the second threshold, it determines to update the semantic vector index of the target file in a batch asynchronous update mode; if the total number of files is greater than or equal to the second threshold, it determines to update the semantic vector index of the target file in a phased update mode. The phased update mode is an index update mode that divides the real-time synchronous update stage into a batch asynchronous update stage. In the real-time synchronous update stage, a portion of the code files in the target file are updated synchronously in real time. After the real-time synchronous update is completed, the batch asynchronous update stage is entered to update the remaining portion of the code files in the target file in batches asynchronously.

[0121] Optionally, if the total number of files is greater than or equal to the second threshold, the hierarchical strategy selection module 404 determines to update the semantic vector index of the target file in a phased update mode, including: if the total number of files is greater than or equal to the second threshold and less than the third threshold, then the hierarchical strategy selection module 404 determines to update the semantic vector index of the target file in a phased update mode; if the total number of files is greater than or equal to the third threshold, the hierarchical strategy selection module 404 also determines to rebuild the semantic vector index in the vector index library based on the code files in the code library in a full reconstruction mode; wherein, the second threshold is less than the third threshold.

[0122] The target files used by the layering strategy selection module 404 can be a set of files generated by the dependency propagation module 403 and passed to the layering strategy selection module 404.

[0123] The tiered strategy selection module 404 can automatically determine the optimal update mode based on the number of affected files and system load. For its specific implementation, please refer to [link / reference]. Figure 2 The embodiments shown will not be described in detail here.

[0124] In some alternative implementations, the incremental update system 400 also includes a change detection module 402.

[0125] Before accessing dirty nodes and related nodes that have dependencies on dirty nodes in the updated dependency graph, the change detection module 402 is used to extract the changed file if a code change event is captured, determine the dirty node based on the changed file, and pass the code change event and dirty node to the dependency propagation module 403 so that the dependency propagation module 403 can identify the target file.

[0126] For example, such as Figure 5 It illustrates the system workflow during incremental updates, which includes interactions between developers, version control systems, incremental update systems, dependency databases, and vector index libraries. The steps are as follows: Step 501: The developer submits code changes.

[0127] After modifying the code locally, commit the changes to the version control system (such as Git push). This is the starting point for triggering the incremental update process.

[0128] Step 502: The version update system triggers an update event.

[0129] After the version update system detects a code commit, it sends an event notification to the incremental update system, informing it "which files have changed." In other words, it transmits the signal of code file changes to the incremental update system to initiate subsequent processing.

[0130] Step 503: Incrementally update system update dependencies.

[0131] When the incremental update system receives a notification from the version control system, it obtains and re-parses the dependencies of the changed files, and updates the dependency graph in the dependency database with the re-parsed dependencies. This process is executed by the dependency graph management module 401 in the incremental update system, and its implementation details can be found in the embodiments described above.

[0132] Step 504: The incremental update system performs dependency propagation analysis.

[0133] The incremental update system identifies target files by performing dependency propagation analysis on the dependency graph, thereby forming a file set containing the target files. This process is executed by the dependency propagation module 403 in the incremental update system. Its implementation details can be found in the embodiments described above. The dependency propagation module 403 also passes the file set to the hierarchical strategy selection module 404.

[0134] Step 505: Select update mode for incremental update system.

[0135] The incremental update system determines whether to use a real-time synchronous update mode, a batch asynchronous update mode, a phased update mode, or a full reconstruction mode based on the total number of affected files. This process is executed by the hierarchical strategy selection module 404 in the incremental update system, and its implementation details can be found in the embodiments described above.

[0136] Step 506: The incremental update system performs adaptive batch coding.

[0137] The incremental update system performs adaptive batch encoding on the target files in the file set according to the selected update mode. This process is executed by the encoding and index update module 405 in the incremental update system, and its implementation details can be found in the embodiments described above.

[0138] Step 507: The incremental update system synchronously updates the index to the vector index library.

[0139] The incremental update system synchronously updates the encoded semantic vector index to the vector index library. This process is executed by the encoding and index update module 405 in the incremental update system. The implementation details can be found in the embodiments described above.

[0140] Step 508: The incremental update system outputs an update and verification report to the developers.

[0141] After completing the incremental update, the incremental update system also verifies the quality of the incremental update. For example, it uses the same AI model to calculate the semantic vector indexes of all code files in the code repository to obtain the full update result. Then, it samples from the full update result and the incremental update result to obtain multiple pairs of semantic vector indices corresponding to multiple code files. Each pair of semantic vector indices includes the first vector index in the full update result and the second vector index in the incremental update result. Then, it calculates the similarity of each pair of semantic vector indices to obtain multiple similarities. Based on multiple similarities, it determines the error of this incremental update. For example, it can calculate the mean squared error, root mean square error, etc.

[0142] After quality verification is completed, the incremental update system also generates an update and verification report. This report records the update strategy, the total number of affected files, and the execution status. The execution status indicates the status of the update strategy execution, such as in progress, completed, or pending. The report also records the verification results of the incremental update quality, such as whether the quality is acceptable or unacceptable. If the vector index library before the update has been rolled back, the report can also record the rollback status of the vector index library.

[0143] The application scenarios of the incremental update method and system provided in the above embodiments include, but are not limited to: in the continuous integration and continuous deployment (CI / CD) process, to automatically trigger incremental index updates after submission; large-scale code search and semantic retrieval platforms to ensure real-time consistency between the index and the code repository; and intelligent completion and code review systems to achieve real-time retrieval and impact analysis of semantic changes.

[0144] The above functions can be implemented independently or in combination in different software architectures and operating environments, and any equivalent variations should be considered to fall within the protection scope of this application.

[0145] In summary, the incremental update method and system provided in this application have the following advantages: 1. Significantly improves index update speed to meet real-time requirements. Traditional full recalculation methods require reprocessing the entire codebase, resulting in long update cycles and huge computational resource consumption. With frequent code commits, lagging index updates prevent developers from retrieving the latest content in a timely manner. This application, through a dependency propagation-based incremental update strategy, processes only changed files and their affected files, achieving index refreshes from hourly to minutely or even secondly, significantly improving index update speed and making real-time code retrieval possible.

[0146] 2. Maintain retrieval accuracy and avoid semantic obsolescence. Traditional dirty tagging only updates directly modified files, ignoring dependency propagation, which causes the semantic representation of indirectly dependent files to gradually become outdated. Changes in functions, types, or interfaces in dependent files often affect higher-level semantics; failure to update corresponding vectors will lead to retrieval bias. This application uses a bidirectional dependency graph and propagation algorithm to accurately identify all affected files and synchronously update semantic vectors, fundamentally eliminating semantic drift and ensuring that the system maintains high retrieval accuracy and index consistency over the long term.

[0147] 3. Significantly reduced computational and energy costs. Full recalculation requires recoding all files, resulting in wasted computing resources and high energy consumption, making it difficult to support the high-frequency commits in continuous integration. This application's incremental update mechanism only recodes the affected files, reducing computation by over 90%, significantly lowering GPU utilization and energy consumption, and enabling the system to operate with high performance while maintaining energy sustainability.

[0148] 4. Overflow or decreased resource utilization. Code file lengths are often unevenly distributed, and uniform batch configuration can become a performance bottleneck. This application addresses this by using an adaptive grouping and dynamic batch adjustment mechanism to automatically match optimal parameters based on file characteristics. It also features automatic degradation and fault tolerance capabilities, enabling the system to maintain high throughput and stable operation under different hardware environments.

[0149] 5. Tiered Update Strategy Balances Real-Time Performance and Resource Utilization. Code changes vary significantly in scale, making it difficult to balance update speed and system load with fixed strategies. Small-scale changes require immediate feedback, while large-scale changes need to be processed in batches. This application utilizes a tiered dynamic strategy to automatically select real-time, asynchronous, or background update modes, flexibly allocating resources under different change scenarios to achieve a balance between real-time performance and computational efficiency.

[0150] 6. The bidirectional dependency structure significantly improves propagation efficiency. Traditional unidirectional dependency graphs cannot efficiently determine "which files depend on a certain file," and dependency analysis requires repeated traversals, resulting in significant performance bottlenecks. This application stores inverted indexes while constructing forward dependencies, enabling constant-time dependency queries and improving propagation efficiency by an order of magnitude, providing a highly efficient foundation for incremental updates.

[0151] 7. Incremental dependency updates avoid the overhead of a full rebuild. As the codebase structure constantly changes, performing a full dependency rebuild with each update is extremely costly and time-consuming. This application's incremental dependency update strategy only re-parses the changed files and adjusts local dependency edges, keeping the dependency graph synchronized in real time, thus avoiding the high overhead and system blocking caused by a full rebuild.

[0152] 8. Circular dependency detection ensures algorithm correctness and efficiency. Circular dependencies are common in large codebases. Failure to detect them can lead to redundant computations or infinite loops in the propagation algorithm. This application automatically identifies and merges dependency cycles through cycle detection and a global update mechanism within the cycle. Files within the cycle are treated as single units, avoiding redundant propagation and ensuring the algorithm remains efficient and stable even under complex dependency structures.

[0153] Figure 6 This is a schematic block diagram of a computer device provided in an embodiment of this application. Specific embodiments of this application do not limit the specific implementation of the computer device. Figure 6 As shown, the computer device may include: a processor 602, a communications interface 604, a memory 606, and a communications bus 608. Wherein: The processor 602, communication interface 604, and memory 606 communicate with each other via communication bus 608.

[0154] Communication interface 604 is used for communication with other computer devices.

[0155] The processor 602 is used to execute program 610, specifically to execute the relevant steps in any of the aforementioned embodiments of the incremental update method for the codebase based on AI programming.

[0156] Specifically, program 610 may include program code that includes computer operation instructions.

[0157] The processor 602 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The one or more processors included in the smart device may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs.

[0158] RISC-V is an open-source instruction set architecture based on the Reduced Instruction Set Computing (RISC) principle. It can be applied to various aspects of microcontrollers and FPGA chips, specifically in areas such as IoT security, industrial control, mobile phones, and personal computers. Because its design considers small size, speed, and low power consumption, it is particularly suitable for modern computing devices such as warehouse-scale cloud computers, high-end mobile phones, and tiny embedded systems. With the rise of AIoT (Artificial Intelligence of Things), the RISC-V instruction set architecture is receiving increasing attention and support and is expected to become the next generation of widely used CPU architecture.

[0159] The computer operation instructions in this embodiment can be computer operation instructions based on the RISC-V instruction set architecture. Correspondingly, the processor 602 can be designed based on the RISC-V instruction set. Specifically, the processor chip in the computer device provided in this embodiment can be a chip designed using the RISC-V instruction set. This chip can execute executable code based on the configured instructions, thereby realizing the incremental update method of the code library based on AI programming in the above embodiment.

[0160] Memory 606 is used to store program 610. Memory 606 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0161] Specifically, program 610 can be used to cause processor 602 to execute the AI-based codebase incremental update method in any of the foregoing embodiments.

[0162] The specific implementation of each step in program 610 can be found in the corresponding steps and units described in any of the aforementioned AI-based programming codebase incremental update method embodiments, and will not be repeated here. Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the devices and modules described above can be referred to the corresponding process descriptions in the aforementioned method embodiments, and will not be repeated here.

[0163] This application also provides a computer-readable storage medium storing instructions for causing a machine to execute the AI-based programming-based incremental codebase update method as described herein. Specifically, a system or apparatus equipped with a storage medium storing software program code that implements the functions of any of the embodiments described above, and enabling the computer (or CPU or MPU) of the system or apparatus to read and execute the program code stored in the storage medium.

[0164] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of this application.

[0165] Storage media embodiments for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0166] This application also provides a computer program product, including computer instructions that instruct a computing device to perform any corresponding operation in the above-described plurality of method embodiments.

[0167] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this application can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this application.

[0168] The methods described in the embodiments of this application can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code downloaded over a network that is originally stored in a remote recording medium or a non-transitory machine-readable medium and will be stored in a local recording medium. Thus, the methods described herein can be processed by software stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA). It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., RAM, ROM, flash memory, etc.) capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods described herein. Furthermore, when a general-purpose computer accesses code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for executing the methods shown herein.

[0169] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0170] The above embodiments are only used to illustrate the embodiments of this application, and are not intended to limit the embodiments of this application. Those skilled in the art can make various changes and modifications without departing from the inventive concept and scope of the embodiments of this application. Therefore, all equivalent technical solutions also fall within the scope of the embodiments of this application, and the patent protection scope of the embodiments of this application should be defined by the claims.

Claims

1. A method for incremental update of a codebase based on AI programming, characterized in that, Applied to a computer device, the method includes: If changes to the code file are detected, retrieve the changed file; Based on the import or reference syntax of at least two programming languages, the dependency relationships of the changed files are constructed in the dependency graph to obtain an updated dependency graph, wherein the updated dependency graph is a directed graph indicating the positive and negative dependencies between code files in the code library; The dirty nodes and associated nodes that have dependencies on the dirty nodes are visited layer by layer along the back propagation path in the updated dependency graph. The code files corresponding to the dirty nodes and the code files corresponding to the associated nodes are determined as target files. The dependency relationship between the dirty nodes and the associated nodes includes at least one of the forward dependency relationship and the reverse dependency relationship. The semantic vector index of the target file is calculated using an AI model, and the semantic vector index of the target file is updated to the vector index library.

2. The method according to claim 1, characterized in that, The step of visiting dirty nodes and associated nodes with dependencies on the updated dependency graph layer by layer along the backpropagation path includes: Based on the loop detection mechanism, the dirty nodes and associated nodes in the updated dependency graph are visited layer by layer along the back propagation path.

3. The method according to claim 2, characterized in that, The target file includes at least one of the following: the modified file; a first code file that has a direct dependency on the modified file; and a second code file that has a transitive dependency on the modified file. The direct dependency refers to a directed path of length 1 between two nodes, and the transitive dependency refers to a directed path of length 2 or greater between two nodes.

4. The method according to claim 1, characterized in that, The method of constructing the dependency relationships of the modified files in the dependency graph based on import or reference syntax of at least two programming languages ​​includes: Based on the import or reference syntax of the at least two programming languages, cross-language dependency identification is performed on the modified file to determine that there is a direct dependency relationship between the modified file and the first code file in the code library; Based on the direct dependency relationship between the modified file and the first code file, update the dependency information of the node corresponding to the modified file and the dependency information of the node corresponding to the first code file in the dependency graph; The direct dependency relationship refers to the existence of a directed path of length 1 between two nodes.

5. The method according to any one of claims 1 to 4, characterized in that, Before calculating the semantic vector index of the target file using the AI ​​model, the method includes: Determine the total number of files in the target file; An adaptive index update decision mechanism is triggered, and the following steps are executed to dynamically determine the index update mode of the target file: Based on the total number of files and the system load of the operating system running on the computer device, a first threshold and a second threshold are dynamically calculated, wherein the first threshold is less than the second threshold; if the total number of files is less than the first threshold, the semantic vector index of the target file is updated in a real-time synchronous update mode; if the total number of files is greater than or equal to the first threshold and less than the second threshold, the semantic vector index of the target file is updated in a batch asynchronous update mode; if the total number of files is greater than or equal to the second threshold, the semantic vector index of the target file is updated in a phased update mode, wherein the phased update mode is an index update mode that divides the real-time synchronous update stage into a batch asynchronous update stage, wherein, in the real-time synchronous update stage, a portion of the code files in the target file are updated synchronously in real time, and after the real-time synchronous update is completed, the batch asynchronous update stage is entered to batch asynchronously update the remaining portion of the code files in the target file.

6. The method according to claim 5, characterized in that, The step of determining to update the semantic vector index of the target file in a phased update mode if the total number of files is greater than or equal to the second threshold includes: if the total number of files is greater than or equal to the second threshold and less than the third threshold, then determining to update the semantic vector index of the target file in the phased update mode. The method further includes: if the total number of files is greater than or equal to the third threshold, then determining to reconstruct the semantic vector index in the vector index library based on the code files in the code library in a full reconstruction mode; Wherein, the second threshold is less than the third threshold.

7. The method according to any one of claims 1 to 4, characterized in that, The step of calculating the semantic vector index of the target file using an AI model includes: The target file is adaptively batch encoded using an AI model to generate a semantic vector index for the target file.

8. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The semantic vector index of each code file in the code library is calculated using the AI ​​model to obtain multiple first vector indices; Multiple second vector indices corresponding to multiple third code files are sampled from the updated vector index library, wherein the third code files are part or all of the target file; Calculate the similarity between the first vector index and the second vector index of the same third code file to obtain multiple similarities; The error resulting from the local update of the vector index is determined based on the multiple similarities. If the error is less than the error threshold, the update of the vector index library is terminated; if the error is greater than or equal to the error threshold, the updated vector index library is rolled back to the vector index library before the update.

9. A codebase incremental update system based on AI programming, characterized in that, The system includes: The dependency graph management module is used to obtain the changed file if a change to the code file is detected, and construct the dependency relationship of the changed file in the dependency graph based on the import syntax or reference syntax of at least two programming languages ​​to obtain an updated dependency graph. The updated dependency graph is a directed graph that indicates the positive and negative dependencies between the code files in the code library. The dependency propagation module is used to access the dirty nodes and associated nodes with dependencies in the updated dependency graph layer by layer along the back propagation path, and determine the code file corresponding to the dirty node and the code file corresponding to the associated node as the target file. The dependency relationship between the dirty node and the associated node includes at least one of the forward dependency relationship and the reverse dependency relationship. The encoding and index update module is used to calculate the semantic vector index of the target file through an AI model and update the semantic vector index of the target file to the vector index library.

10. A computer device, characterized in that, The computer device includes: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to execute the AI-based codebase incremental update method as described in any one of claims 1-8.

11. A computer storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, implements the AI-based incremental update method for the codebase as described in any one of claims 1-8.

Images