Code retrieval method and computer program product

Abstract

The invention discloses a code retrieval method and a computer program product, relates to the field of artificial intelligence, and is used for solving the problem of low code retrieval efficiency in the prior art. The method comprises the following steps: based on a code retrieval demand, determining a target retrieval carrier meeting the code retrieval demand through a retrieval carrier of each code snippet in a source code library; any retrieval carrier is constructed through a source code library and a corresponding business document and comprises semantic information representing the code snippets and structural information representing the code snippets; wherein the structure information comprises hierarchical information of the code snippets in the codes to which the code snippets belong; and obtaining a response result of the code retrieval demand based on the code snippets indicated by the target retrieval carrier. Through the scheme, the code retrieval efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and in particular to a code retrieval method and a computer program product. Background Technology

[0002] As software systems continue to expand in scale and business iteration frequency increases, developers often need to quickly locate code related to a specific functional requirement or anomaly within massive amounts of source code during code development, testing, and verification, in order to further carry out modification, verification, or analysis. However, current technologies for code retrieval in large code repositories are inefficient.

[0003] Therefore, how to improve code retrieval efficiency is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a code retrieval method and a computer program product to improve code retrieval efficiency.

[0005] Firstly, this application provides a code retrieval method, which includes: based on code retrieval requirements, determining a target retrieval carrier that meets the code retrieval requirements through retrieval carriers of various code segments in a source code repository; any retrieval carrier is constructed through a source code repository and corresponding business documents, including semantic information representing the code segment and structural information representing the code segment, the structural information including the hierarchical information of the code segment in its respective code; and obtaining a response result for the code retrieval requirements based on the code segment indicated by the target retrieval carrier.

[0006] Through the above scheme, this application introduces a "retrieval carrier" as an intermediate expression in the code retrieval stage. This retrieval carrier is jointly constructed by the source code repository and the corresponding business documents. Based on this, on the one hand, the retrieval no longer relies solely on keyword matching or single semantic similarity matching of the code text. Instead, it incorporates the business semantics reflected in the business documents and the hierarchical affiliation of the code fragments within the system into the matching criteria. This makes it easier to converge the retrieval scope to candidate code fragments that simultaneously match the retrieval requirements in terms of both "business meaning" and "structural position," thereby improving the relevance and accuracy of the retrieval results. On the other hand, since hierarchical information can characterize the positioning relationship of code fragments at the levels of interfaces, components, modules, classes, or methods, when the code repository is large and the call and dependency relationships are complex, the retrieval can prioritize positioning within the scope that conforms to hierarchical constraints, thereby reducing the blind expansion of the entire repository and improving retrieval efficiency.

[0007] Optionally, the retrieval carrier includes summary information and data information representing semantic information, hierarchical information and relational information representing structural information, and index information pointing to code segments; the summary information represents at least one of function, scenario, input / output, and exception mechanism; the hierarchical information represents at least one of interface, component, module, and submodule; the relational information represents at least one of inclusion, implementation, inheritance, overriding, calling, and dynamic calling; the data information represents data operation information; and the index information represents the physical storage location of the corresponding code segment.

[0008] Based on the above scheme, by simultaneously setting summary information, hierarchical information, relational information, data information and index information in the retrieval carrier, the same carrier can characterize code fragments from multiple dimensions such as "business semantics - structural position - association relationship - data operation - physical location", thereby forming a more sufficient and discriminative matching basis in the retrieval stage.

[0009] Optionally, any retrieval carrier is constructed from a source code repository and corresponding business documents, including: determining the nodes corresponding to different code segments based on each code segment in the source code repository; the nodes include dynamic nodes and static nodes; determining the connection relationships between static nodes based on the relationships between each code segment; determining the connection relationships between dynamic nodes and static nodes based on the runtime information of the source code repository; generating semantic information of the nodes corresponding to any code segment based on any code segment and its corresponding business documents; and integrating each node, the connection relationships between each node, and the semantic information of each node into a retrieval carrier for each code segment.

[0010] Based on the above scheme, the retrieval carrier of this application includes at least structural information and semantic information representing code fragments. Compared with the prior art which only has structural information or only semantic information, the retrieval carrier of this application can carry more code information.

[0011] Optionally, the connection relationship between dynamic nodes and static nodes is determined based on the runtime information of code snippets, including: obtaining function call chain data of the source code library at runtime based on a set probe; the function call chain data includes multiple call chain data, and each call chain data includes multiple span information; for any dynamic node, the runtime log of the dynamic node obtained by running the source code library is obtained; the call chain data and the runtime log of the dynamic node with the same tracking identifier are determined; the similarity between any runtime log and any span information in the call chain data is determined; and the static node indicated by the span information that meets the similarity matching requirement is connected to the dynamic node.

[0012] The above approach collects function call chain data at runtime and combines it with dynamic node runtime logs for alignment and matching to determine the connection relationship between dynamic and static nodes. This allows dynamic calls to no longer rely solely on the inference results of static code parsing, but to establish mapping relationships based on real runtime evidence, thereby improving the accuracy and stability of dynamic relationship construction.

[0013] Optionally, determining the similarity between any runtime log and any span information in the call chain data includes: for any runtime log and any span information, determining a first keyword in the runtime log and a second keyword in the span information; determining a first similarity between the runtime log and the span information based on each first keyword and each second keyword; determining a second similarity based on the first time information in the runtime log and the second time information in the span information; and determining a matching degree based on the first similarity and the second similarity.

[0014] The above scheme decomposes the similarity calculation between the operation log and the span information into a joint matching degree of "keyword similarity + time similarity". This makes the alignment of dynamic nodes and span information no longer dependent on a single signal. Thus, even when the operation link data is complex, the log noise is high, or the number of spans is large, the target span that meets the matching requirements can still be selected more stably, improving the accuracy and robustness of the matching.

[0015] Optionally, the first similarity includes set similarity and cosine similarity. The first similarity of each running log and each span information is determined based on each first keyword and each second keyword, including: determining set similarity based on the number of first keywords and the number of second keywords; determining cosine similarity based on the vectors of the first keywords and the vectors of the second keywords; and determining the matching degree based on the first similarity and the second similarity, including: adjusting the weights of set similarity, cosine similarity and the second similarity based on the application scenario of the source code library; and determining the matching degree based on the first similarity and the second similarity based on the adjusted weights.

[0016] The above scheme introduces set similarity and cosine similarity into the first similarity, and further combines it with the second similarity obtained based on time information to form the matching degree. This allows the matching judgment between the operation log and the span information to take into account the "keyword coverage", "semantic similarity" and "temporal consistency", thereby improving the accuracy and adaptability of the matching results under different data forms and different operation scenarios.

[0017] Optionally, based on the code snippets in the source code library, determine the nodes corresponding to different code snippets, including: any component code snippet in the source code library corresponds to a static node, and the component code snippet includes multiple sub-code snippets, each of which corresponds to a static node; determine the functional modules from the flowchart of the component code snippets; any functional module corresponds to a static node; determine the connection relationship between the static nodes based on the relationship between the code snippets, including: establishing the connection relationship between the static node corresponding to any functional module and the static node corresponding to the component code snippet; for any functional module, determine the keywords of the business functions belonging to the functional module from the business document corresponding to the component code snippet; and determine the connection relationship between the static node corresponding to any sub-code snippet and the static node corresponding to the functional module based on the keywords of the business functions of the functional module and the structural information of the functional module.

[0018] The above approach establishes a "component-functional module-sub-code fragment" connection relationship at the node level for component code fragments, functional modules, and sub-code fragments. This allows the retrieval carrier to simultaneously express the code's breakdown structure at the physical implementation level and its functional structure at the business process level, thereby improving the clarity and usability of the code fragment structure.

[0019] Optionally, based on the keywords of the business functions of the functional module and the structural information of the functional module, the connection relationship between the static node corresponding to any sub-code segment and the static node corresponding to the functional module is determined, including: determining the semantic similarity between the keywords of the business functions of the functional module and the sub-code segment; determining the structural similarity between the structural information of the functional module and the sub-code segment; determining a comprehensive score of similarity based on semantic similarity and structural similarity; and determining the connection relationship between the static node corresponding to the sub-code segment and the static node corresponding to the functional module based on the comprehensive score.

[0020] The above scheme calculates the semantic similarity between the functional module's business function keywords and the sub-code fragments, as well as the structural similarity between the functional module's structural information and the sub-code fragments, and integrates the two into a comprehensive score before determining the node connection relationship. This allows the process of attaching sub-code fragments to functional modules to be determined by both semantic and structural constraints, thereby improving the accuracy and stability of connection relationship construction.

[0021] Optionally, after determining the connection relationship between the static node corresponding to the sub-code snippet and the static node corresponding to the functional module based on the comprehensive score, the method further includes: determining the edge weights between nodes with connection relationships based on the historical running data of the component code snippet and the completeness of the business documents; determining the clustering value of nodes at the same level based on the edge weights, and merging nodes at the same level to generate a new node when the clustering value is greater than a first threshold; determining the module degree value based on each edge weight, and stopping the merging of any two nodes when the module degree value is less than a second threshold.

[0022] The above scheme establishes the connection between static nodes of sub-code snippets and static nodes of functional modules based on comprehensive scores. Then, it determines the edge weights between nodes based on historical runtime data of component code snippets and the completeness of business documentation. This provides subsequent clustering decisions with runtime and semantic evidence, making node merging more consistent with the reliability of real business calls and document descriptions. Furthermore, clustering values ​​are calculated based on edge weights, and merging to generate new nodes is only performed when the clustering value is greater than a first threshold, thus avoiding the erroneous merging of low-association nodes. Simultaneously, merging of any two nodes is stopped when the module degree value is less than a second threshold. This allows for setting global constraints on the clustering process, preventing indefinite clustering. Merging is terminated promptly when continued merging would damage module boundaries or degrade module partitioning quality, thus achieving adaptive control of clustering granularity and avoiding over-clustering.

[0023] Optionally, it also includes: acquiring function call chain data in real time and acquiring the cross-node call frequency between any two nodes; when the cross-node call frequency between two nodes is higher than the third threshold, splitting the two nodes separately; when the change in modularity value is greater than the fourth threshold, determining whether to merge the two nodes based on the edge weight between the two nodes.

[0024] Through the above scheme, the carrier structure can be dynamically corrected according to changes in operational behavior, thereby achieving adaptive adjustment of "splitting when it should be split and merging when it should be merged", avoiding structural distortion or inappropriate clustering caused by long-term solidification of node structure.

[0025] Optionally, based on code retrieval requirements, the process includes: determining the code and retrieval requirements corresponding to the user input information through a large language model; and obtaining the response results for the code retrieval requirements based on the code fragment indicated by the target retrieval carrier, including: using the target retrieval carrier and the code fragment as context for reasoning through a large language model, and obtaining the reasoning results corresponding to the user input information.

[0026] Through the above scheme, since the retrieval carrier of this application can express the structural and semantic information of the code with less content, the large language model only needs a few retrievals to retrieve the corresponding target retrieval carrier and target code fragment when performing code retrieval based on user needs. Furthermore, after obtaining the target retrieval carrier, the target retrieval carrier and target code fragment are used as context for reasoning. Compared with the prior art of filling the context window with a large amount of irrelevant code, irrelevant documents or a wide range of search results, the context content of this application focuses more on the carrier information and corresponding code fragments related to the needs. Therefore, it can significantly reduce the number of tokens occupied by redundant information in the context, reduce the pressure on the context window, thereby reducing the risk of reasoning or generation failure due to too many tokens, and improving the efficiency and stability of reasoning response.

[0027] Secondly, this application provides a code retrieval device, the device comprising: The determination module is used to determine the target retrieval carrier that meets the code retrieval requirements based on the retrieval carriers of each code segment in the source code library. Each retrieval carrier is constructed by the source code library and the corresponding business documents, including semantic information representing the code segment and structural information representing the code segment. The structural information includes the hierarchical information of the code segment in the code it belongs to. The retrieval module is used to obtain response results for code retrieval requests based on the code snippets indicated by the target retrieval carrier.

[0028] In one possible implementation, the retrieval carrier includes summary information and data information representing semantic information, hierarchical information and relational information representing structural information, and index information pointing to code segments; the summary information represents at least one of function, scenario, input / output, and exception mechanism; the hierarchical information represents at least one of interface, component, module, and submodule; the relational information represents at least one of inclusion, implementation, inheritance, overriding, calling, and dynamic calling; the data information represents data operation information; and the index information represents the physical storage location of the corresponding code segment.

[0029] In one possible implementation, the determination module is specifically used to: determine the nodes corresponding to different code segments based on the code segments in the source code library; the nodes include dynamic nodes and static nodes; determine the connection relationships between static nodes based on the relationships between the code segments; determine the connection relationships between dynamic nodes and static nodes based on the runtime information of the source code library; generate semantic information of the nodes corresponding to any code segment based on any code segment and its corresponding business document; and integrate each node, the connection relationships between each node, and the semantic information of each node into a retrieval carrier for each code segment.

[0030] In one possible implementation, the determining module is specifically used for: acquiring function call chain data of the source code library at runtime based on a set probe; the function call chain data includes multiple call chain data, and each call chain data includes multiple span information; for any dynamic node, acquiring the runtime log of the dynamic node obtained by running the source code library; determining the call chain data and the runtime log of the dynamic node with the same tracking identifier; determining the similarity between any runtime log and any span information in the call chain data; and establishing a connection relationship between the static node indicated by the span information that meets the similarity matching requirement and the dynamic node.

[0031] In one possible implementation, the determining module is specifically used to: for any running log and any span information, determine a first keyword in the running log and a second keyword in the span information; determine a first similarity between the running log and the span information based on each first keyword and each second keyword; determine a second similarity based on the first time information in the running log and the second time information of the span information; and determine a matching degree based on the first similarity and the second similarity.

[0032] In one possible implementation, the first similarity includes set similarity and cosine similarity. The determining module is specifically used to: determine set similarity based on the number of first keywords and the number of second keywords; determine cosine similarity based on the vectors of the first keywords and the vectors of the second keywords; the determining module is specifically used to: adjust the weights of set similarity, cosine similarity and second similarity based on the application scenario of the source code library; and determine the matching degree based on the adjusted weights of the first similarity and the second similarity.

[0033] In one possible implementation, the module determination is specifically used for: each component code fragment in the source code library corresponds to a static node, the component code fragment includes multiple sub-code fragments, and each sub-code fragment corresponds to a static node; determining functional modules from the flowchart of the component code fragment; each functional module corresponds to a static node; the module determination is specifically used for: establishing the connection relationship between the static node corresponding to any functional module and the static node corresponding to the component code fragment; for any functional module, determining the keywords of business functions belonging to the functional module from the business document corresponding to the component code fragment; based on the keywords of the business functions of the functional module and the structural information of the functional module, determining the connection relationship between the static node corresponding to any sub-code fragment and the static node corresponding to the functional module.

[0034] In one possible implementation, the determining module is specifically used to: determine the semantic similarity between the keywords of the business functions of the functional module and the sub-code fragments; determine the structural information of the functional module and the structural similarity between the sub-code fragments; determine a comprehensive score of similarity based on semantic similarity and structural similarity; and determine the connection relationship between the static nodes corresponding to the sub-code fragments and the static nodes corresponding to the functional modules based on the comprehensive score.

[0035] In one possible implementation, the determining module is also used to: determine the edge weights between nodes with a connection relationship based on the historical running data of the component code snippet and the completeness of the business document; determine the clustering value of nodes at the same level based on the edge weights, and merge nodes at the same level to generate a new node when the clustering value is greater than a first threshold; determine the module degree value based on each edge weight, and stop merging any two nodes when the module degree value is less than a second threshold.

[0036] In one possible implementation, the determining module is also used to: acquire function call chain data in real time and acquire the cross-node call frequency between any two nodes; when the cross-node call frequency between two nodes is higher than a third threshold, split the two nodes respectively; when the change value of the module degree value is greater than a fourth threshold, determine whether the two nodes should be merged based on the edge weight between the two nodes.

[0037] In one possible implementation, the determination module is specifically used to: determine the code and retrieval requirements corresponding to the user input information through a large language model; the retrieval module is specifically used to: use the target retrieval carrier and code fragment as context for reasoning through the large language model, and obtain the reasoning results corresponding to the user input information.

[0038] Thirdly, this application also provides a code retrieval device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method described in various possible designs of the first aspect.

[0039] Fourthly, this application also provides a computer-readable storage medium storing a computer program or instructions that, when executed by a processor, implement the method described in various possible designs of the first aspect.

[0040] Fifthly, this application also provides a computer program product that, when run on a computer, causes the computer to perform any of the methods described in the first aspect above.

[0041] These or other implementations of this application will become clearer and easier to understand in the following description of the embodiments. Attached Figure Description

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

[0043] Figure 1 A flowchart illustrating a code generation method based on a large language model, provided for an embodiment of this application; Figure 2 A flowchart illustrating a code retrieval method provided in an embodiment of this application; Figure 3 A schematic diagram of a retrieval carrier provided in an embodiment of this application; Figure 4 A schematic diagram illustrating the structural information of a retrieval carrier provided in an embodiment of this application; Figure 5 A flowchart illustrating a method for constructing a retrieval carrier provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating a method for retrieving carrier relationship information, as provided in an embodiment of this application. Figure 7 A flowchart illustrating a method for constructing dynamic node connection relationships provided in an embodiment of this application; Figure 8 This is a schematic diagram illustrating the establishment of a connection between a dynamic node and a static node, provided as an embodiment of this application. Figure 9 A flowchart illustrating a method for constructing a retrieval carrier provided in an embodiment of this application; Figure 10 A flowchart illustrating a carrier node construction method provided in an embodiment of this application; Figure 11 A schematic diagram illustrating the structural information of a retrieval carrier provided in an embodiment of this application; Figure 12 A schematic diagram of a retrieval carrier node provided in an embodiment of this application; Figure 13 A schematic diagram of another retrieval carrier node provided in an embodiment of this application; Figure 14 A schematic diagram of a retrieval carrier node provided in the embodiments of this application; Figure 15 A schematic diagram of a code retrieval device provided in an embodiment of this application; Figure 16 This is a schematic diagram of another code retrieval device provided in an embodiment of this application. Detailed Implementation

[0044] To make the objectives, technical solutions, and beneficial effects of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0045] The business scenarios described in the embodiments of this application are for illustrative purposes only and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0046] With the rapid development and widespread application of artificial intelligence (AI) technology, a new application scenario has emerged in the field of intelligent code modification. In this scenario, when a user requests modifications to an existing codebase, the AI ​​system retrieves and analyzes various related content within the codebase, including relevant code files, function definitions, data structures, and dependencies. Based on an understanding of the original code logic and context, it then generates modified code that meets the user's needs. However, currently, automatically generated code suffers from low accuracy, low efficiency, and a high failure rate.

[0047] For example, please refer to Figure 1 This paper illustrates a flowchart of a code generation method based on a large language model. The method generates code through multiple rounds of iterative retrieval and analysis, specifically including the following steps: The first round of retrieval and analysis includes steps 101-104.

[0048] Step 101: Enter the business requirements document.

[0049] In this step, the user inputs the business function requirements to be implemented into the system in the form of a document. The business requirement document contains a description of the code functions that the user wants to generate or modify.

[0050] Step 102, Large Language Model (LLM) reasoning and understanding requirements.

[0051] In this step, LLM performs semantic analysis and understanding of the input business requirements document, extracting key information from the requirements, such as the functional modules to be implemented, business logic, input and output parameters, etc., to provide a basis for subsequent code retrieval.

[0052] It is worth noting that step 102 also includes: writing the requirements obtained from LLM reasoning into the context window, i.e., proceeding to step 106 (ordered writing and appending to the context window).

[0053] The context window refers to the maximum length of input information that a large language model (LLM) can process and understand simultaneously during reasoning or text generation. The context window of a large language model has technical limitations, typically measured in terms of the number of tokens. For example, the context window limit of a certain large language model might be M tokens. When the total amount of information that needs to be input into the large language model exceeds this limit, the model will not function properly. In code generation scenarios, if the total length of retrieved code files, documentation, relational information, etc., exceeds the context window limit of the large language model, the LLM will be unable to continue processing, ultimately causing the code generation task to fail.

[0054] Appending refers to appending new code or document content to the context window after each iteration during multi-round retrieval. Instead of overwriting the existing content, the new content is appended to the end of the context window, allowing the information in the context window to continuously accumulate and grow. This appending method preserves information retrieved in all previous rounds, enabling large language models to comprehensively utilize all acquired code, document, and relational information for reasoning and analysis. However, this appending method also causes the content in the context window to grow rapidly with each retrieval round, making it easier to reach the context window length limit of large language models.

[0055] Step 103: Retrieve the corresponding process and the node code under the process.

[0056] In this step, based on the requirements as understood by the LLM (usually in natural language), the business process code related to the requirements is retrieved from the code repository (e.g., using keyword matching in document tools or semantic matching in vector libraries) to obtain the code entry points and main functional modules involved in the requirements, as well as the functional module documentation.

[0057] Step 104: Retrieve the corresponding process and the node documents under the process.

[0058] In this step, technical documents, interface documents, functional descriptions, and other documents related to the above processes and nodes are further retrieved, and the retrieved code and document content are written into the context window of the LLM to provide an information basis for subsequent analysis.

[0059] The process then proceeds to the second through Nth iterations. Specifically, based on the results of the first round of retrieval, the code's hierarchical structure is converted into an abstract syntax tree, and correlation analysis is performed in conjunction with the functional module documentation. When the analysis reveals that the currently retrieved code module involves deeper sub-modules, the retrieval of the next level of sub-module code and the next level of sub-functional module documentation continues. This process is repeated in sequence, performing multiple iterations of retrieval until the Nth round is completed, at which point all relevant sub-module code and sub-functional module documentation have been retrieved. The following section provides a more detailed explanation of this process.

[0060] Step 105: LLM performs correlation analysis between inference requirements and retrieval results.

[0061] In this step, since the first round of retrieval may not be able to obtain all relevant code information, multiple rounds of iterative retrieval are required. In each iteration, LLM performs inference analysis based on the retrieved content, identifies the call relationships, dependencies and other related information between code, and continues to retrieve deeper-level related code and documents based on these relationships, continuously writing the newly retrieved content into the context window (proceeding to step 106).

[0062] Step 107: Determine if the information is sufficient.

[0063] In the steps, it is determined whether the retrieved code and relationship information is sufficient, that is, whether there is enough information for reasoning. If not, proceed to steps 108 and 109; otherwise, proceed to step 110.

[0064] Step 108: Retrieve the submodule code under the node.

[0065] Step 109: Retrieve documents for sub-modules under the node.

[0066] In steps 108 and 109 above, since the retrieved information is insufficient, the code and documentation of the submodules under the current node are further retrieved to obtain more granular code implementation details.

[0067] Step 110: Determine if the context window of the LLM exceeds the limit.

[0068] If the limit is exceeded, proceed to step 111; code generation fails. If the limit is not exceeded, proceed to the next step: code generation.

[0069] It is worth noting that steps 105 to 110 are iterative processing cycles. In each iteration, the LLM performs reasoning analysis based on the currently retrieved content and identifies code relationships. Then it determines whether the retrieved information is complete enough. If the result is no, it continues to retrieve deeper submodule code and documentation and appends them to the context window before entering the next iteration. The iteration ends when the context window exceeds the limit, causing generation failure, or when the context window does not exceed the limit and the information is complete enough, and then enters the code reasoning and generation stage.

[0070] Step 111: Window exceeded limit, generation failed.

[0071] Step 112, LLM performs reasoning based on context.

[0072] Step 113: Generate code.

[0073] After completing all searches, a comprehensive analysis is performed on all retrieved module code and functional module documentation, and new code is generated based on the analysis results.

[0074] The above process requires inputting the code carrier into a large language model, enabling the model to perform reasoning and generate code based on the carrier. The carrier refers to a data structure used to express the structure and relationships of code. Specifically, a code carrier is a structured data container that carries and organizes source code information, storing and expressing various characteristic information of the source code, including information across multiple dimensions such as syntax structure, module hierarchy, call relationships, business semantics, and data operations. The code carrier essentially transforms the source code from its raw text form into a structured data representation that is easy for computer programs to analyze and process, thereby supporting intelligent applications such as code retrieval, code understanding, and code generation.

[0075] Traditional code carriers include abstract syntax trees (ASTs) and vector libraries. However, in complex scenarios, relying solely on traditional code carriers can lead to code generation failures or inefficient code generation.

[0076] Specifically, abstract syntax trees (ASTs) are primarily used to express the basic syntactic structure of code, but they can only capture this basic structure, lacking system architecture and business semantics. This means they lack information such as business semantics and runtime relationships, and cannot express implicit reflection calls, asynchronous messages, and other runtime dynamics. Vector libraries, on the other hand, store code snippets as semantic vectors, supporting semantic matching and retrieval, but they lose the structured information and precise call relationships of the code, and cannot be directly extended to include syntactic structure information. Because existing carriers (syntactic trees or vector libraries) cannot fully express the overall system architecture, business semantics, and implicit dependencies between code modules, large language models do not understand the code accurately enough, ultimately resulting in extremely low code generation accuracy.

[0077] To compensate for insufficient carrier information, manual guidance and multiple rounds of retrieval and analysis are often required. Since syntax trees cannot meet retrieval needs, and code snippets stored in vector libraries are not precise enough through semantic segmentation and matching, multiple rounds of manual correction of the retrieval scope are necessary to achieve the desired results. This approach not only increases the manual cost of retrieval but also significantly reduces retrieval and code generation efficiency.

[0078] Furthermore, in overly complex business scenarios, a multi-layered structural design is often adopted, including interfaces, components, modules, and sub-modules. Since existing carrier structures cannot effectively reflect this layered design, the retrieval process requires multiple iterative searches layer by layer. As the number of retrieval rounds increases, the code and document data written to the context window accumulate, leading to excessive context data being fed into the large language model. Ultimately, this causes the context window to exceed the length limit of the large language model, making it impossible to complete the code generation task.

[0079] Furthermore, existing carrier structures consume excessive storage space in code scenarios and cannot perform summarization or compression. Specifically, traditional abstract syntax trees require storing complete syntactic structure information, and vector libraries require storing a large number of code snippet vector representations. These carriers consume a lot of storage space, and their build and refresh speeds are slow when updating the code library, affecting the system's real-time responsiveness and overall performance.

[0080] Therefore, the carrier is crucial in the above applications. Especially in the code retrieval stage (such as steps 103 or 108 above), if the carrier cannot carry more code information, multiple rounds of retrieval are required, and even manual assistance may be necessary. Therefore, improving code retrieval efficiency is a pressing issue that needs to be addressed.

[0081] Based on this, this application provides a code retrieval method that can improve code retrieval efficiency by constructing a novel retrieval carrier (also known as a code carrier, or simply a carrier).

[0082] The following is a detailed description of the proposed solution in conjunction with the accompanying drawings.

[0083] Please see Figure 2 The diagram illustrates a code retrieval method, which includes the following steps: Step 210: Based on the code retrieval requirements, determine the target retrieval carrier that meets the code retrieval requirements by using the retrieval carriers of each code fragment in the source code library.

[0084] For example, code retrieval requirements can be referred to Figure 1 Examples include modifying or continuing code. Users can input code to the LLM to modify their requirements (e.g., in natural language), and the LLM understands the user's needs and retrieves relevant code from the codebase.

[0085] Here, any retrieval vehicle is constructed from the corresponding business documentation in the source code repository, including semantic information representing the code snippet and structural information representing the code snippet. The structural information includes the hierarchical information of the code snippet within its parent code. For example, the business documentation can be requirements specifications, interface specifications, comments, etc.; the hierarchical relationship can be, for example, a port, component, module, submodule, class, or method, etc., thus enabling the retrieval process to not only rely on code text matching but also to combine business semantics and structural hierarchy for effective retrieval.

[0086] Based on the above scheme, the retrieval carrier of this application includes at least structural information and semantic information representing code fragments. Compared with the prior art which only has structural information or only semantic information, the retrieval carrier of this application can carry more code information.

[0087] Step 220: Based on the code fragment indicated by the target retrieval carrier, obtain the response result for the code retrieval request.

[0088] For example, the response result may include the target code fragment itself, the identification information and location information of the target code fragment, or associated code fragments, etc., so that users can complete code location, associated code tracking or further analysis and processing based on the response result.

[0089] Compared to existing technologies that rely solely on semantic or structural matching when performing code retrieval, the retrieval carrier of this application carries more code information (including both semantic and structural information). This allows for faster convergence to a candidate range that meets retrieval requirements, even with large code volumes and numerous files. It also reduces the screening costs associated with irrelevant results and improves retrieval efficiency and the relevance of retrieval results.

[0090] Furthermore, this application introduces a "retrieval carrier" as an intermediate expression in the code retrieval process. This retrieval carrier is jointly constructed by the source code repository and the corresponding business documents. Based on this, on the one hand, the retrieval no longer relies solely on keyword matching or single semantic similarity matching of the code text. Instead, it incorporates the business semantics reflected in the business documents and the hierarchical affiliation of the code fragments within the system into the matching criteria. This makes it easier to narrow the retrieval scope to candidate code fragments that simultaneously match the retrieval requirements in terms of both "business meaning" and "structural location," thereby improving the relevance and accuracy of the retrieval results. On the other hand, since hierarchical information can characterize the positioning relationship of code fragments at the levels of interfaces, components, modules, classes, or methods, when the code repository is large and the call and dependency relationships are complex, the retrieval can prioritize positioning within the scope that conforms to hierarchical constraints. This reduces the blind expansion of the entire repository for retrieval and improves retrieval efficiency.

[0091] Optionally, the retrieval carriers include summary information and data information representing semantic information, hierarchical information and relational information representing structural information, and retrieval information pointing to code snippets. For details, please refer to [link to relevant documentation]. Figure 3 The diagram shows a retrieval carrier. The following sections will describe in detail the five dimensions of information included in the retrieval carrier.

[0092] 1. Summary Information. The summary information represents at least one of the following: function, scenario, input / output, and exception mechanism. The summary information in the carrier is used to store the core elements of the code element corresponding to the current carrier, such as the business semantic description of the code element, a summary of the working principle, functional description, application scenario, input / output parameters, and exception handling mechanism, etc., so that the large language model can quickly understand the main function and purpose of the code element.

[0093] 2. Hierarchical Information. The hierarchical information in the carrier is used to store the structural position information of the current carrier in the whole system. This includes multi-level hierarchical structure information such as the interface information, component information, module information, and sub-module information to which the code belongs. It clearly expresses the ownership and hierarchical positioning of the code element in the system architecture, such as representing at least one of the interface, component, module, and sub-module to which it belongs.

[0094] 3. Relationship Information. The relationship information in the carrier stores various associations between the current carrier and other code elements, representing at least one of the following: inclusion, implementation, inheritance, overriding, invocation, and dynamic invocation. For example, for a class, it includes the class's element information and inheritance relationships; for a method, it includes the method's element information, overloading relationships, overriding relationships, and invocation relationships between methods; for an interface, it includes the interface's implementation relationships and invocation relationships between interfaces, as well as implicit relationships generated at runtime, such as dynamic invocation relationships like reflection invocation and asynchronous message invocation.

[0095] 4. Data Information. The data information in the carrier is used to store data operation information involved in the current carrier, including operation information such as reading, writing, updating, and deleting data tables, as well as operation information such as reading, writing, updating, and deleting caches, and data interaction information such as calls to downstream services.

[0096] 5. Index Information. The index information in the carrier is used to store the actual index information of the physical storage location corresponding to the current carrier, including the file path, start line number, and end line number of the code element in the source code file. The index information can be used to quickly locate the specific code block in the source code file without storing the complete code text content in the carrier.

[0097] like Figure 3 As shown, the carrier structure integrates summary information, hierarchical information, relational information, and index information from multiple dimensions, and points to the corresponding code block through the index information. This preserves the structured features and call relationships of the code while containing rich business semantics and hierarchical information. At the same time, the indexing method avoids storing the complete code text, thus compressing storage space. When it is necessary to obtain the specific code implementation, the corresponding code block can be directly located and read through the index information.

[0098] Thus, by simultaneously setting summary information, hierarchical information, relational information, data information, and index information in the retrieval carrier, the same carrier can characterize code fragments from multiple dimensions such as "business semantics—structural location—association—data operation—physical location," thereby forming more comprehensive and discriminative matching criteria during the retrieval stage. For example, in... Figure 1 In application scenarios, by embedding multi-dimensional information such as business semantic layer, hierarchical information, and relational information into the retrieval carrier, LLM can efficiently understand the target code and its associations. When LLM uses the above retrieval carrier to retrieve relevant code, it can obtain more semantic information and understand it more accurately, further improving the efficiency and accuracy of LLM code retrieval, as well as improving the accuracy of LLM generated results. At the same time, since the retrieval and understanding process is more likely to converge, it reduces the reliance on repeated manual intervention for correction, reduces the number of retrieval rounds, and improves code generation efficiency.

[0099] It is worth noting that the retrieval carrier of this application compresses the original content into a summary and maintains only the index data without maintaining the actual code file, thereby reducing storage space while maintaining the availability of code structure and semantic information, and improving retrieval speed and efficiency.

[0100] Furthermore, optionally, the retrieval carrier Z consists of a node set V and an edge set E. Nodes and edges in the carrier can be created or updated using the function λ. The structural carrier Z is as follows:

[0101] The node set V contains multiple nodes. Each node ∈V is a structure containing three fields. The first is the structure's id; the second is the category field, used to identify the type of code element this node represents, with values ​​including interface, component, module, submodule, class, internal interface, method, data table, cache, and downstream service; and the third is the structure field, used to store multi-dimensional information about the node. Among these, the node... The expression is as follows:

[0102] The expression for the structure field is as follows:

[0103] The structure consists of five subfields: First, the `desc` subfield stores the node's core information, including its functional summary, business scenario, input parameters, output parameters, and exception handling mechanisms. Second, the `hier` subfield stores the hierarchical position of the node within its code structure, such as interfaces, components, modules, and submodules. Third, the `rel` subfield stores various code relationships between the node and other nodes, including inclusion, implementation, inheritance, overriding, calling, and dynamic calling relationships. Fourth, the `data` subfield stores information about data operations such as reading, writing, updating, and deleting related to the node. Fifth, the `idx` subfield stores the physical location information of the corresponding code elements, such as classes, interfaces, tables, and methods, including their names, file paths, start line numbers, and end line numbers. The five fields of the `structure` subfield can be found in the provided text. Figure 3 The description.

[0104] The edge set E is used to represent the connection relationships between nodes, where, .

[0105] The carrier also includes node label functions. This function maps the node set V to node labels, assigning a set of labels to each node to identify its attribute characteristics. This involves adding, updating, or removing tags from nodes. For example, （V）Returning {"core", "high load"} indicates that node v is a core component and has a high load.

[0106] The carrier also includes a set of node labels L v To characterize a predefined type of label, for example, L v It can be {core, obsolete, high load, ...}.

[0107] The carrier HIA includes side label functions. This function maps the set of edges E to edge labels, assigning one or more labels to each edge to identify the type of relation it represents. For example, L e It can be {call, inheritance, dependency, data flow, ...}.

[0108] The carrier includes a set of node tags. , indicating the edge assignment label (such as type). For example, λ e(e) It may return {“call”}, representing a call edge.

[0109] The carrier also includes an attribute function μ, which is used to attach additional attribute information to nodes and edges, where, K represents the set of attribute keys, and S represents the set of attribute values. Attribute functions allow for the flexible addition of custom attributes to elements within the carrier. For example, the following is the implementation of the attribute function μ: / / Implementation of property function μ function μ( element: Vertex | Edge, / / Programming representation of V∪E key: PropertyKey / / K ): PropertyValue { / / S return element.properties[key]; } Here's another example of how the attribute function μ is used: / / Use the u function to add the following properties to the node (V) structure. μ(v, "id") = "interface name" μ(v, "desc.func") = "Get user information" μ(v, "desc.scene") = "User Login" In the above Figure 3 The text mentions that the retrieval carrier includes hierarchical information and relational information representing structural information; please refer to [link / reference]. Figure 4This diagram illustrates a structural information retrieval carrier. As shown, the diagram displays the carrier's layered design from top to bottom. The top layer is the interface, which connects to components via relationships. Components connect to modules via inclusion relationships, and modules further contain finer-grained code elements such as classes and methods. This hierarchical structure clearly expresses the multi-layered architectural design from the interface layer to the component layer, from the component layer to the module layer, and from the module layer to the concrete implementation layer, corresponding to the hierarchical information dimensions within the carrier.

[0110] Because the retrieval vehicle of this application can clearly express code structure relationships, for example, it can explicitly represent implicit call relationships between methods and implicit call relationships between internal interfaces (see reference). Figure 4 (Example) This allows for the direct acquisition of relationships between methods during the retrieval process, enabling location and tracking without relying on highly uncertain methods such as fuzzy matching or vector matching, and without requiring multiple rounds of human intervention for correction and repeated filtering, thereby reducing labor costs and improving retrieval efficiency.

[0111] The following section will provide a more detailed explanation of the carrier construction, which is understandable. Figure 4 Used to display the hierarchical and relational information of the carrier. Figure 3 It is the multi-dimensional fusion of information on the carrier, that is Figure 4 yes Figure 3 Part of, and Figure 3 It is a complete carrier A portion of node V.

[0112] Please see Figure 5 This diagram illustrates a flowchart of a method for constructing a retrieval vehicle. Any retrieval vehicle is constructed using a source code repository and corresponding business documentation, specifically including the following steps: Step 510: Based on the code snippets in the source code library, determine the nodes corresponding to different code snippets.

[0113] Specifically, the source code repository can be traversed and parsed, with code snippets serving as the smallest modeling unit and assigned node identifiers. Here, nodes include dynamic nodes and static nodes; static nodes represent nodes corresponding to code elements that can be directly determined in the source code, such as classes, interfaces, methods, and components; dynamic nodes represent nodes corresponding to execution units or call units that are difficult to fully and explicitly determine based solely on static source code but will actually occur during runtime, such as execution path nodes corresponding to reflection calls and asynchronous message triggering. This allows the node set to cover both the static structure of the source code and the dynamic execution characteristics formed at runtime.

[0114] Optionally, before determining nodes, preset extraction rules and preset cleaning rules can be established. Based on these rules, code extraction and data cleaning are performed on the source code repository to ensure the accuracy and effectiveness of subsequent node construction. The preset extraction rules may include extraction tags for identifying carrier nodes, such as @Api and @RequestMap, to quickly extract code snippets related to business entry points and interface definitions from the source code and form corresponding nodes. The preset cleaning rules may include cleaning tags for identifying obsolete code, such as @obsolete. Based on these preset extraction rules, static structure information can be extracted from the source code, and static nodes can be determined accordingly.

[0115] Optionally, during the extraction process, a data cleaning operation is further performed. That is, when a code fragment is detected to contain the aforementioned cleaning tags, the code fragment is determined to be obsolete code and is directly removed, thereby preventing obsolete code from entering the node set and affecting the construction of subsequent connection relationships, as well as the accuracy and retrieval efficiency of the retrieval carrier.

[0116] Optionally, step 510 may further include: directly classifying code fragments in the source code repository that meet preset conditions using pre-approved static dimension classification rules, and initializing the classification results into the retrieval carrier. Specifically, a set of static dimension classification rules can be pre-configured, and rule matching can be performed on code fragments when parsing the source code; when a match is successful, the category of the corresponding node is directly determined and written into the structural information of the carrier, thereby obtaining a relatively clear node type identifier and initial structured information in the initial stage of carrier construction.

[0117] For example, static dimension classification rules may include: Rule 1: When a code snippet corresponding to a method is detected to contain annotations such as @Api or @RequestMap, the node corresponding to that method will be marked as an external interface. Rule 2: When a code snippet corresponding to a class is detected to contain annotations such as @Feign or @Client used for external calls, the node corresponding to that class is marked as a downstream service. Rule 3: When a code snippet corresponding to a class is detected to contain annotations such as @Entity or @Table, the node corresponding to that class will be marked as a data table. Rule 4: When a code snippet contains keywords such as invoke, task, submit, execute, or thread, the corresponding node will be marked as a dynamic call. Rule 5: When a code snippet is detected to contain annotations such as @Cache, the corresponding node will be marked as cached.

[0118] Through the above-mentioned rule-based static classification, coarse-grained classification of different types of code fragments can be completed during the node initialization stage, providing a foundation for relationship analysis and retrieval matching.

[0119] Furthermore, based on the static classification results, a carrier node set V is constructed, so that each code element in the source code library corresponds to a node in set V, where the code fragments include classes, internal interfaces, methods, data tables, caches, and downstream services, etc.

[0120] Step 520: Based on the relationships between the code snippets, determine the connection relationships between the static nodes.

[0121] Here, the relationships between the code fragments are analyzed, and a carrier edge set E is constructed to represent the associations between nodes. The relationships between the code fragments can be obtained from the source code and are reflected as the connection relationships between nodes.

[0122] Optionally, after constructing the edge set E, the λ function can be used to label the relation type of each edge in the carrier to distinguish the semantic meaning of different connection relations, thus enabling the edges to express the relationship categories between different code elements. Furthermore, the μ function adds attributes to the carrier nodes and edges. For example, node attributes are used to characterize the basic and classification information of the code fragment corresponding to the node, and edge attributes are used to characterize the additional information of the connection relations. This allows the carrier to simultaneously possess node set, edge set, relation type, and attribute information in the initial stage, providing a foundation for subsequent dynamic relation injection, semantic information generation, and carrier integration for retrieval.

[0123] Based on steps 510-520 above, we can obtain Figure 6 The diagram shown illustrates the relationship information of the retrieval carrier. For example... Figure 6 As shown, the connection relationships between nodes such as interfaces, classes, internal interfaces, methods, data tables, caches, and downstream services are illustrated in the form of nodes and directed edges. The edge labels are used to represent different relationship types such as inclusion, inheritance, implementation, definition, overriding, usage, and read / write, so that the carrier can simultaneously express the hierarchical affiliation of code elements, static call dependencies, and interaction relationships related to data operations within the same graph structure.

[0124] Step 530: Determine the connection relationship between dynamic nodes and static nodes based on the runtime information of the source code library.

[0125] Because the source code only contains static semantics, it cannot identify the incomplete and inaccurate call chain analysis caused by dynamic calling mechanisms such as reflection and asynchronous calls. Therefore, in steps 510 and 520 above, this application constructs a preliminary call chain containing dynamic call markers by analyzing the static source code. Then, in step 530, it collects the system's time-series call chain data. Through the extraction and matching of key log information, it associates and stitches the potential dynamic calls obtained from static analysis with the actual call sequences captured at runtime to obtain a complete and accurate global call chain.

[0126] Optional, please refer to Figure 7 The diagram illustrates a flowchart of a method for constructing dynamic node connection relationships. Step 530 includes the following steps: Step 710: Obtain function call chain data of the source code library at runtime based on the set probe.

[0127] Optionally, during system production runtime (i.e., when the source code library is running), function call chain data can be collected using preset probes to obtain the runtime call chain set T. race ={ , ,..., }, where any call chain T i For an ordered sequence T i = <spa ,spa ,...,span m > and any span i It includes information such as method signature, timestamp, trace identifier (trace_id), and parent span identifier.

[0128] A probe is a pre-configured and deployed data collection component in the source code repository runtime environment, used to automatically acquire runtime information such as function call chains during system operation. This probe can work in an instrumentation manner, automatically recording information such as the time of the call, the signature of the called method, and parent-child call relationships at function entry points, exit points, or key call points, thereby forming the aforementioned "function call chain data."

[0129] Step 720: For any dynamic node, obtain the running log of the dynamic node from the running source code library.

[0130] Here, the "dynamic method" nodes from the carrier construction in step 510 are selected to obtain a set of dynamic nodes that require further processing. Then, during runtime in the source code repository, a trace identifier (trace_id) consistent with the call chain is recorded in the runtime log (i.e., the runtime log that identifies call chain data and dynamic nodes with the same trace identifier), so that log entries can be associated with call chain data.

[0131] The trace identifier (trace_id) is a unique identifier used to identify a single request or business transaction. It is used to associate call chain data generated during multiple service or method calls of the same request with the runtime logs. Specifically, when the same request passes through different services or different method calls, the relevant log entries and chain spans will carry the same trace identifier, allowing the scattered runtime information to be linked into a complete chain based on this trace identifier.

[0132] Optionally, log entries that are not output in a preset format can be cleaned to reduce the interference of noisy data on subsequent association matching.

[0133] Step 730: Determine the connection relationship between dynamic nodes and static nodes based on the runtime logs and function call chain data.

[0134] The spans in the function call chain data obtained in step 710 i The trace identifier `trace_id` is included in the log entries, and the runtime log obtained in step 720 also contains the trace identifier `trace_id`. Therefore, log entries and spans can be linked based on the same trace identifier. i Perform correlation matching to obtain the corresponding span position of the log entry in the call chain.

[0135] Furthermore, optionally, when a log entry is associated with a certain span... i When the tracking identifier is consistent and the log timestamp and span timestamp meet the preset time window conditions, the log entry is determined to correspond to the span. i Subsequently, based on the span... i The recorded method signatures and parent-child span relationships are used to determine the static method nodes corresponding to the dynamic nodes, and connection edges from the dynamic nodes to the static nodes are generated accordingly. Please refer to [link / reference]. Figure 8 This diagram illustrates the establishment of a connection between dynamic and static nodes. Following steps 710-730, the "dynamic call" node and the "method" node establish an "asynchronous call" connection to further supplement and improve the process. Figure 6 A schematic diagram of the carrier relationship information.

[0136] Through steps 710-730 above, by collecting runtime logs and function call chains, observable evidence is provided for capturing dynamic and static nodes, thereby facilitating the acquisition of connection relationships between dynamic and static nodes and improving the accuracy and completeness of dynamic connection relationship construction. Furthermore, by collecting function call chain data at runtime and combining it with dynamic node runtime logs for alignment and matching, the connection relationships between dynamic and static nodes are determined. This ensures that dynamic calls no longer rely solely on the inference results of static code parsing but can establish mapping relationships based on real runtime evidence, thus improving the accuracy and stability of dynamic relationship construction.

[0137] Step 540: Generate semantic information of the corresponding node of the code snippet based on any code snippet and its corresponding business document.

[0138] Specifically, source code repositories, database documents, and interface documents can be used as sources of semantic information. These texts can undergo unified preprocessing, including removing invalid symbols, segmentation, field alignment, and synonym normalization, to obtain natural language suitable for model input. Optionally, a code semantic representation model (such as CodeBERT) can be used to vectorize code fragments, and an attention-based transformer can be combined to fuse and model multi-source text, thereby extracting summary information that represents functionality, scenario, input / output parameters, and anomaly mechanisms.

[0139] Optionally, after obtaining the summary information, the summary information is written into the structure field of the corresponding node of the carrier through the attribute function μ, so that the carrier node can still represent the business semantics of the code fragment without storing the complete code text.

[0140] Step 550: Integrate each node, the connection relationship between each node, and the semantic information of each node into a retrieval carrier for each code fragment.

[0141] Specifically, this step encapsulates the node set V, edge set E, and semantic summary information of the nodes obtained in steps 510-540 into a unified carrier object Z for retrieval.

[0142] Through steps 510-540 above, nodes are divided into static nodes and dynamic nodes, so that the carrier simultaneously covers "explicit structures that can be directly parsed in the source code" and "implicit execution units that only occur at runtime" at the structural level. Furthermore, the retrieval carrier of this application not only includes structural relationships but also semantic information, which can improve retrieval efficiency during the retrieval stage.

[0143] Furthermore, this application can extract complex systems hierarchically according to dimensions such as interfaces, components, modules, and sub-modules without manual intervention, and automatically write the hierarchical results into the retrieval carrier, thereby improving the efficiency of retrieval carrier generation.

[0144] The following is an implementation of steps 710-730 above, to further explain the connection method between dynamic nodes and static nodes.

[0145] Specifically, let L be the set of runtime logs from the source code repository. First, filter the runtime log set L and extract the log entries related to the target dynamic node, denoted as L0. vd For each log entry I∈L vd Extract the key vector for log entry I. The key vector can be extracted based on TF-IDF or word embedding models; this application is not limited to this. For example, the key vector may include information such as the trace identifier (trace_id), timestamp, and keywords.

[0146] Meanwhile, the set of runtime function call chains obtained in step 710 can be denoted as T. race For the runtime call chain set T race Each span i Extract contextual information; for example, contextual information includes each span. i The method signature, business parameters, parent-child span identifier, timestamp, and trace identifier (trace_id) are used to generate a vector representation of the context information.

[0147] In this way, we can obtain the key vector for each log entry I, and the span for each log entry. i The key vector of contextual information links log entry I with the span. i By performing correlation matching, the corresponding span position of the log entry in the call chain can be obtained, and the connection relationship between dynamic nodes and static nodes can be further obtained.

[0148] Optionally, the correlation between log entries and spans can be matched in the following ways:

[0149] Jaccard is used to calculate the matching degree of the keyword set, and cosSim is used to calculate the cosine similarity of the vector space. The calculation formula is as follows:

[0150] Time p Used to calculate the proximity of log time t_l to span time t_span_j. In one example, Timep The calculation method is as follows:

[0151] Optionally, α, β, and γ are adjustable weight coefficients. In one example, α + β + γ = 1 is satisfied. In another example, the weight coefficients can be dynamically adjusted and optimized based on one or more factors to adapt to the stitching requirements in different scenarios and achieve better stitching results. For example, in a system with a high level of log specification maturity, if the trace identifier (trace_id) can be automatically passed through all logs and links, the time proximity weight γ can be significantly increased, and combined with the trace identifier (trace_id) to achieve more accurate matching, while the weights of α and β can be reduced accordingly. Furthermore, in other examples, the weight coefficients can also be learned through feedback based on the matching results of historical data. For example, adaptive optimization can be achieved by maximizing the sum of similarities of positive sample pairs and minimizing the sum of similarities of negative sample pairs, i.e.:

[0152] Then, for any dynamic call edge e(v) in the carrier s →v d During runtime, the candidate span is traversed in the link data. j And calculate log entry I and span. j correlation between Select the matching pair with the highest relevance (I , span j When the maximum correlation Sim(I) , span j When the value is greater than the preset threshold θ, determine the dynamic node v. d At runtime, it corresponds to the span. j and the nodes vv in the carrier d span nodes in the runtime link j Establish connections between dynamic and static nodes (or their corresponding method nodes). By sequentially performing the above matching and connection operations on all dynamic call edges, the dynamic and static nodes can be stitched together, and a complete global call chain can be constructed.

[0153] The above scheme decomposes the similarity calculation between the operation log and the span information into a joint matching degree of "keyword similarity + time similarity". This makes the alignment of dynamic nodes and span information no longer dependent on a single signal. Thus, even when the operation link data is complex, the log noise is high, or the number of spans is large, the target span that meets the matching requirements can still be selected more stably, improving the accuracy and robustness of the matching.

[0154] The following example illustrates steps 710-730 above. It should be understood that the following example is for illustration only and does not limit the solution of this application.

[0155] Assume a dynamic node in the carrier is: V d =="validateUser" # The dynamic calling node identified in the carrier The following section further constructs the connection relationship between the dynamic nodes and the static nodes. It is understood that only one dynamic node is used as an example below, and other dynamic nodes can refer to this example.

[0156] First, input the runtime logs of the source code repository, and then obtain the function call chain data of the source code repository during runtime based on the set probe. For example, the runtime logs are as follows: logs = [ "2023-08-28 11:00:04 [INFO] [trace_id=TX301] Permission verification started: user=U123role=admin", "2023-08-28 11:00:04 [DEBUG] [trace_id=TX301] Access permission table: scope=user_detail", "2023-08-28 11:00:14 [WARN] [trace_id=TX302] Permission verification failed: user=U456role=guest", "2023-08-28 11:00:14 [ERROR] [trace_id=TX302] Access denied: Admin privileges required" ] The function call chain data is as follows (taking the call chain set including T1 and T2 as an example, each chain includes multiple span information): T_race = [ T1: [ span1: {method: "Method_getUserDetailInfo", trace_id: "TX301", ts:1630000000000}, span2: {method: "UserRepository.findById", trace_id: "TX301", ts:1630000000200}, span3: {method: "validateUser", trace_id: "TX301", ts:1630000000400}, # Key permission verification point span4: {method: "buildUserResponse", trace_id: "TX301", ts:1630000000600} ], T2: [ span1: {method: "Method_getUserDetailInfo", trace_id: "TX302", ts:1630000001000}, span2: {method: "CacheManager.get", trace_id: "TX302", ts:1630000001200}, span3: {method: "validateUser", trace_id: "TX302", ts: 1630000001400} ] ] After extracting the above runtime logs and call chain data, the connection relationship between dynamic nodes and static nodes is analyzed according to the following steps: Step 1: Vectorize key logs. For dynamic node v d (validateUser) extracts the log set L(v) related to it from the runtime log. d ), for example L(v d = [l1:“Permission verification started: user=U123 role=admin”, l2:“Permission verification failed: user=U456 role=guest”]. Based on this, construct the keyword list V=[“Permission”, “Verification”, “Start”, “Failed”, “user”, “role”, “admin”, “guest”], and for any log entry l∈L(vd Perform TF-IDF vectorization to obtain the corresponding log vector Vec_log(l). For example: Vec_log(l1)=[0.9,0.8,0.7,0.0,0.6,0.7,0.8,0.0] Vec_log(l2)=[0.9,0.8,0.0,0.9,0.6,0.7,0.0,0.8].

[0157] Step 2: Runtime Span Vectorization. Extract the span context information from the runtime call chain. For example, span3_T1={method:“validateUser”, params:{userId:“U123”, requiredRole:“admin”}, tags:{result:“success”}}, span3_T2={method:“validateUser”, params:{userId:“U456”, requiredRole:“admin”}, tags:{result:“failed”}}. Further, obtain the span keyword vocabulary in the same way as in Step 1, and vectorize any span to obtain the span vector Vec_span(span). For example: Vec_span(span3_T1)=[0.8,0.9,0.0,0.0,0.7,0.8,1.0,0.0]# Successful verification Vec_span(span3_T2)=[0.8,0.9,0.0,1.0,0.7,0.8,0.0,0.8]#Verification failed.

[0158] Step 3: Relevance Calculation. For log entry l and runtime span, extract the log keyword set Key(l) and span context set Context(span), and calculate their similarity to represent the degree of relevance. Where: Key(l1) = {"Permissions", "Validation", "Start", "user", "role", "admin"}; Context(span3_T1) = {"validateUser", "userId", "requiredRole", "admin", "success"}

[0159] Jaccard similarity is used to characterize the degree of overlap in keyword sets, for example: Jaccard=|{"Permissions","Validation","admin"}| / |{"Permissions","Validation","Start","user","role","admin","validateUser","userId","requiredRole","success"}| =3 / 10=0.3 Cosine similarity (cosSim) is used to characterize the similarity of vector spaces, for example: Vec_log(l1)=[0.9, 0.8, 0.7, 0.0, 0.6, 0.7, 0.8, 0.0] Vec_span(span3_T1)=[0.8, 0.9, 0.0, 0.0, 0.7, 0.8, 1.0, 0.0] cosSim = (0.9 0.8 + 0.8 0.9 + 0.7 0 + ... + 0.8 1.0) / (||l1|| ||span3_T1||) ≈ 2.38 / (1.82 1.78) ≈ 0.73 Time proximity is used to characterize the degree of match between a log entry and a span in the time dimension. For example, if log entry ts = 1630000000400 and span ts = 1630000000400, then Time... p =1 / (1+0) = 1.0 Based on this, the keyword set matching degree (Jaccard), vector space similarity (cosSim), and time proximity (Time) are combined. p The weighted fusion is performed according to the weights to obtain the comprehensive correlation Sim, where α, β, and γ correspond to Jaccard, cosSim, and Time, respectively. p The weights are such that α + β + γ = 1. For example, when α = 0.4, β = 0.4, and γ = 0.2, we can obtain Sim = 0.4 × 0.3 + 0.4 × 0.73 + 0.2 × 1.0 = 0.652.

[0160] During the link reconstruction and stitching phase, taking the permission verification edge e (Method_getUserDetailInfo→validateUser) as an example, the comprehensive correlation degree between log entries and candidate spans is calculated, and the matching pair with the highest correlation degree is taken as the candidate stitching result. For example, the correlation degree Sim=0.652 between log l1 and span3_T1, and the correlation degree Sim=0.785 between log l2 and span3_T2 (calculation process omitted). When the correlation degree is greater than the preset threshold θ (e.g., θ=0.6), it is determined that the corresponding log entry and span match, and the stitching and reconstruction of the dynamic call link are completed accordingly, thus obtaining the reconstruction results TX301: Method_getUserDetailInfo→validateUser (success) and TX302: Method_getUserDetailInfo→validateUser (failure) (the above reconstruction process can be understood as the process of establishing a relationship between dynamic nodes and static nodes, that is, the dynamic node validateUser establishes a connection with the static nodes TX301 and TX302 respectively).

[0161] During the dynamic weight optimization phase, the weight parameters α, β, and γ can be adaptively adjusted according to different scenarios. For example, when call_type contains permission_check (i.e., if "permission_check" in call_type), permission verification relies more on keyword overlap and semantic consistency. Therefore, α can be increased while β remains at a relatively high level, and γ can be appropriately decreased. For example, α=0.5, β=0.4, and γ=0.1 can be set. When call_type contains data_access (i.e., elif "data_access" in call_type), data access relies more on time order constraints. Therefore, γ can be increased while α and β are decreased accordingly. For example, γ=0.6, α=0.2, and β=0.2 can be set.

[0162] Furthermore, the weight parameters can be optimized based on historical matching results, constructing a set of positive samples (e.g., (l1, span3_T1), (l2, span3_T2)) and a set of negative samples (e.g., (l1, span3_T2)# incorrect match), and updating the parameters with the goal of maximizing the sum of the correlation of positive samples and minimizing the sum of the correlation of negative samples, i.e., max(Σ positive sample Sim - Σ negative sample Sim), thereby obtaining a weight configuration that is more suitable for the current system logs and link characteristics through iterative learning.

[0163] Optional, please refer to Figure 9 This illustrates a flowchart of another method for constructing a retrieval carrier. For example... Figure 9As shown, this application integrates static source code, runtime dynamic information, and layered information to jointly construct the carrier structure. Specifically, during the carrier initialization phase, static modules of the carrier are built based on the code repository, database documentation, and interface documentation; then, dynamic modules of the carrier are built based on production logs and production call lines to supplement the carrier's dynamic information; finally, business information is layered based on component documentation, interface documentation, component flowcharts, interface flowcharts, system documentation, and other documents, such as interface-component-module-submodule hierarchy, so that the carrier not only has a structure at the code syntax level but also a hierarchical structure at the business level.

[0164] The initialization of the aforementioned carrier can be referenced in steps 510-550 above, and the construction of dynamic information can be referenced in steps 710-730 above. Repeated content will not be described again. The construction of hierarchical information is described in detail below to supplement step 510 above.

[0165] To address the evolving nature of business functions over time, this application implements a component-based sub-module decomposition mechanism that dynamically adapts to business needs and automatically matches the boundaries of business functions. Existing systems typically only layer components, but the granularity and coverage of modules within components are gradually adjusted with version iterations. As business continues to develop, the system structure inevitably becomes more complex. Figure 1 In application scenarios, directly relying on LLM to infer the original source code not only results in a longer inference chain and heavier context dependencies, but also increases the pressure on the context window caused by the full code injection, thus continuously reducing the success rate and efficiency of code generation and modification tasks. Therefore, it is necessary to build a logical intermediate layer on top of the source code to further structure the implementation details within components as a hierarchical node network of "module → submodule, submodule → submodule node".

[0166] Furthermore, common industry solutions often rely on manual module decomposition and boundary maintenance within components. However, as the system scales up, dependencies increase, and dynamic calls become more frequent, manual decomposition not only requires continuous investment of domain experience and maintenance costs, but also struggles to guarantee the consistency and reusability of the decomposition criteria across multiple versions and multi-team collaboration scenarios. Therefore, the layered module construction proposed in this application is primarily implemented through the following methods.

[0167] Please see Figure 10 The diagram illustrates a flowchart of a carrier node construction method, which includes the following steps: Step 1001: Determine the keywords of the business function from the document corresponding to the component code snippet.

[0168] Here, the source code repository includes component code snippets, each with corresponding component documentation. N business function keywords are extracted from the component documentation (generally a business function description document), denoted as set K = { , , ..., }, each keyword K j It can be represented as a vector.

[0169] Step 1002: Identify module nodes from the flowchart of the component code snippet.

[0170] Suppose that a component code snippet contains M logical modules (also called functional modules), denoted as set M = { , ,..., }, module nodes can be extracted from the flowchart, and a module logical relationship diagram G can be constructed. Each module M i It can be represented as a node in a graph, with edges representing the call or process relationships between modules.

[0171] Step 1003: Identify multiple sub-code snippets from the component code snippets.

[0172] Here, each sub-code snippet corresponds to a node, such as a method node. P sub-code snippets are extracted from the component code snippet, denoted as a set C = { , , ..., }, each sub-code segment C i It can be represented as a feature vector, including: a) Code text features: function names, variable names, etc., can be represented by word vectors; b) Code structure characteristics: calling relationships, inheritance relationships, etc., can be represented by a graph structure.

[0173] Step 1004: Based on keywords, module nodes, and sub-code snippets, determine the module node to which the node corresponding to each sub-code snippet belongs.

[0174] In step 1004, for any sub-code segment C i Calculate the sub-code segment C i With any business function keyword K j Semantic similarity Sim_semantic(C i K j ), and calculate the sub-code segment C. i With any module node M j Structural similarity Sim_structural(C i M j). Among them, Sim_semantic(C i K j Cosine similarity can be used to calculate it, that is: Sim_semantic Sim_semantic(C i K j )=cos(vec(C i ), vec(K j )) Among them, vec(C i ) indicates code segment C i The text feature vector, vec(K) j ) represents the keyword K j Word vectors; Optional, Sim_structural(C i M j Similarly, cosine similarity can also be used to calculate it, that is: Sim_structural(C i M j )=cos(vec(C i ), vec(M j )), Among them, vec(M j ) represents module node M j For example, the feature vector of a module node can be generated by the module name, the module description text, and the upstream and downstream adjacent nodes of the module in the flowchart.

[0175] Furthermore, for any sub-code segment C i With any module node M j Calculate the attribution score S(Ci, Mj). The attribution score is calculated by the semantic similarity between the sub-code fragment Ci and all business function keywords, Sim_semantic(C). i K j ) and weighted sum structural similarity Sim_structural(C i M j The calculation, for example, yields the following formula for the attribution score:

[0176] Where α and β are hyperparameters used to balance the contributions of semantic similarity and structural similarity; the weights W(Kj) of business function keywords can be assigned according to the importance of the keywords in the document, for example, using TF-IDF values ​​as weights W(Kj); the weights W(Ll) of module nodes can be assigned according to the centrality of the module in the flowchart (such as PageRank value); A[j][l] is an N×M dimensional association matrix (where N = number of business keywords, M = number of modules), used to represent business keywords K j With module M l The semantic association is strong, and the value range is [0, 1], where 0 represents no association and 1 represents complete association.

[0177] Optionally, for each sub-code snippet, select an attribution score. The highest-ranking module is the module to which it belongs, and the specific formula is as follows:

[0178] Finally, by looping through the entire process, the relationship between all modules and sub-code snippets under the component is finally constructed.

[0179] Step 1005: Construct a weighted hierarchy graph within the component.

[0180] Based on the module node attribution results and module-sub-code segment association matrix obtained in step 1004, a weighted hierarchical graph within the component can be further constructed. Specifically, the hierarchical graph within the component can be represented as G=(V, E, W), where the node set V represents all nodes |V|=m within the component, including static nodes and module nodes; the edge set E represents: when the above attribution score S ij When the value is greater than θ, a connection is established between the two nodes, including connecting the node corresponding to the sub-code module to the module node, and connecting the module node to the sub-module node; the edge weight set W is jointly determined by the document integrity score doc_quality, the call chain stability call_stability, and the data operation complexity data_complexity, as shown in the following formula: W = α + β + γ in,

[0181] The doc_quality value ranges from 0 to 1 and is used to characterize the completeness of the module's related documents; call_stability is determined based on the standard deviation of historical production call frequency and is used to characterize the stability of the call relationship between modules; data_complexity is determined based on the historical production data update frequency and is used to characterize the complexity of data interaction between modules.

[0182] Step 1006: Determine the nodes that can be clustered in the weighted hierarchy graph.

[0183] This application employs a hierarchical clustering approach to adaptively aggregate nodes, resulting in a hierarchical structure that better aligns with business semantics. First, each node is set up as an independent cluster, i.e. Then, the iterative merging phase begins, repeatedly performing inter-cluster similarity calculations and cluster merging operations until the termination condition is met.

[0184] Specifically, in each iteration, the similarity between any two clusters is first calculated, and the cluster pair with the highest similarity is selected as the candidate for merging. When the similarity of the cluster pair meets the preset merging criterion, the two clusters are merged into a new cluster, thus gradually forming a hierarchical structure from fine to coarse. For example, the formula for calculating inter-cluster similarity is as follows:

[0185] In one example, when If the preset merging criteria are met, the two clusters are merged into a new cluster.

[0186] Optionally, to avoid over-clustering leading to module boundary distortion, a modularity Q-value is introduced as a dynamic termination condition during the iteration process. The Q-value is calculated based on the adjacency matrix A in the graph structure. ij Node degree k i And the total number of edges m, the specific formula is as follows:

[0187] in, Let k be an adjacency matrix, used to characterize whether there is a connection between node i and node j. i δ is the node degree, used to characterize the number of edges connected to node i, and δ( is the Kronecker function, which takes the value 1 when node i and node j belong to the same cluster, and 0 otherwise.

[0188] By continuously calculating the Q-values ​​after clustering and comparing them with a preset threshold, the clustering process stops when the Q-value is less than the preset threshold, ensuring that the output hierarchical structure maintains a balance between "aggregation degree" and "structural distinguishability". In one example, the preset threshold is 0.3.

[0189] Furthermore, to ensure consistency between clustering results and business logic, business semantic constraints are superimposed during the clustering process. Specifically, for any cluster C, its functional description text desc_C is taken, and a corresponding semantic vector is generated using the BERT model. During candidate cluster merging, the semantic vector of the merged cluster is compared with the target business semantic vector. Only when the similarity meets a preset threshold is the merge confirmed, thereby reducing unreasonable merging based solely on structural similarity. After clustering, the final cluster structure and hierarchical relationships are written into the carrier using the μ function to achieve automatic updating and injection of the module-submodule hierarchy. Specifically, the business semantic constraint formula is as follows:

[0190] in, The functional description text of node C is converted into a semantic vector using the BERT model.

[0191] pass The formula for injecting the hierarchical relationship of nodes into the carrier is as follows:

[0192] The above approach establishes a "component-functional module-sub-code fragment" connection relationship at the node level for component code fragments, functional modules, and sub-code fragments. This allows the retrieval carrier to simultaneously express the code's breakdown structure at the physical implementation level and its functional structure at the business process level, thereby improving the clarity and usability of the code fragment structure.

[0193] Optionally, this application monitors the call chain data in the production environment in real time and automatically adjusts the hierarchical structure in the carrier after detecting preset trigger conditions. Specifically, the preset trigger conditions include at least: cross-node call frequency exceeding a preset threshold (e.g., 15 times / minute by default), and node cohesion decreasing by a preset proportion (e.g., a decrease in cohesion exceeding 20% ​​based on the change in the nodeization degree Q value). Upon meeting the trigger conditions, the corresponding adjustment strategy is executed.

[0194] Specifically, when the frequency of the collected call link span information (span) in the cross-node path is greater than 0.7, a split operation is performed on the relevant nodes, that is, a node is split into two child nodes; when the nodeization degree Q value is greater than 0.05, a merge operation is performed on the relevant nodes, so that the hierarchical structure is dynamically updated with the runtime coupling characteristics and remains stable.

[0195] Through the above scheme, the carrier structure can be dynamically corrected according to changes in operational behavior, thereby achieving adaptive adjustment of "splitting when it should be split and merging when it should be merged", avoiding structural distortion or inappropriate clustering caused by long-term solidification of node structure.

[0196] Based on steps 1001-1006 above, we can obtain the following: Figure 11 The schematic diagram of the structural information of the retrieval carrier, compared to Figure 6 The carrier structure information, Figure 11 The component has multiple module nodes and sub-module nodes, with a clearer hierarchical structure, which provides a foundation for improving subsequent retrieval efficiency.

[0197] Based on the above retrieval carrier structure, the structured hierarchical information of the code and the relationship information between the various structures can be clearly expressed. Figure 1 In application scenarios, it can enhance the global understanding of large LLMs, reduce the risk of illusions in the reasoning process, and improve the generation accuracy. At the same time, retrieval based on carriers can more accurately converge to the target code range, reduce irrelevant content entering the context, reduce token usage, and achieve context compression, thereby improving retrieval efficiency and generation efficiency.

[0198] The following example illustrates steps 1001-1006 above. It should be understood that the following example is for illustration only and does not limit the solution of this application.

[0199] Step 1: Extract the set of business function keywords K from the component code.

[0200] Assume K = {"Authorization Verification", "User Information Query", "Data Transformation", "Database Connection", "Cache Access"}, and use BERT to generate keyword vectors (simplified example). The keyword vectors are as follows: vec("Permission verification") = [0.92, 0.85, 0.13, 0.07] vec("User Information Query") = [0.15, 0.93, 0.24, 0.08] vec("data transformation") = [0.08, 0.27, 0.95, 0.12] Step 2: Extract the set of logical modules M.

[0201] Assume M = {"Permission Verification Node", "Data Transformation Node", "User Management Module", "User Information Query Submodule", "User Information Query Process"}, and generate the logical relationship diagram G of the modules based on the flowchart (e.g., graph TD), as follows: A [User Management Module] --> B [User Information Query Submodule] B --> C [User Information Query Process] C --> D [Permission Verification Node] C --> E [Data Transformation Node] D --> F[UserRepository.findById] D --> G[CacheManager.get] Step 3: Determine a set of multiple sub-code snippets C.

[0202] Suppose that the set of sub-code snippets C includes four sub-code snippets, namely C1, C2, C3, and C4, as follows: # Permission check line (permission_check_line) C1: { "path": "src / main / java / com / example / user / service / UserInfoService.java", "lines": "128-142", "content": "if (!user.hasPermission('VIEW_DETAIL')) throw newAccessDeniedException();" }, # Data conversion code snippet C2: { "path": "src / main / java / com / example / user / service / UserInfoService.java", "lines": "150-170", "content": "UserDetailInfo response = new UserDetailInfo(user);" }, # Database access code snippet C3: { "path": "src / main / java / com / example / user / repository / UserRepository.java", "lines": "30-50", "content": "User findById(String userId) {...}" }, # Cache access code snippet C4: { "path": "src / main / java / com / example / cache / CacheManager.java", "lines": "100-120", "content": "Object get(String key) {...}" } } Next, code feature extraction is performed. Taking sub-code snippet C1 (authorization verification) as an example, the extracted code features are as follows: # a) Code text feature vector text_features = ["Permissions", "Verification", "hasPermission", "AccessDenied"] vec_text(C1) = [0.88, 0.91, 0.05, 0.03] # b) Code structure feature map call_graph = { "validateUser": ["PermissionService.check", "UserRepository.getRole"] } Step 4: Calculate the attribution score to determine the module to which the sub-code snippet belongs.

[0203] This step applies to any sub-code segment C. i Calculate the sub-code segment C i With any business function keyword K j Semantic similarity Sim_semantic(C i K j ), and calculate the sub-code segment C. i With any module node M j Structural similarity Sim_structural(C i M j Finally, the attribution score is calculated based on semantic similarity and structural similarity. The following example uses code segment C1 for illustration.

[0204] (1) Semantic similarity calculation: Calculate the semantic similarity between each keyword and the business function keywords.

[0205] The semantic similarity between code segment C1 and "permission verification" is: Sim_semantic(C1, "Authorization") =cos([0.88,0.91,0.05,0.03],[0.92,0.85,0.13,0.07])=0.9 The semantic similarity between code segment C1 and "user information query" is: Sim_semantic(C1, "User Information Query") =cos([0.88,0.91,0.05,0.03],[0.15,0.93,0.24,0.08])=0.25 (2) Structural similarity calculation: Construct the module vector vec(“Permission Verification Node”) of the module “Permission Verification Node” = [0.85, 0.89, 0.10, 0.05] (e.g., generated from the module description text), and calculate the structural similarity between code segment C1 and the module: Sim_structural(C1, "Authorization Node") =cos([0.88,0.91,0.05,0.03],[0.85,0.89,0.10,0.05])=0.99.

[0206] (3) Calculation of attribution score (assuming α=0.7, β=0.3): Based on the preset weight coefficients α=0.7 and β=0.3, the attribution score is calculated by introducing keyword weight and module weight.

[0207] Specifically, taking W(“Permission Verification”) = 0.9 as the keyword weight and W(“Permission Verification Node”) = 0.85 as the module weight, the attribution score S of sub-code segment C1 belonging to “Permission Verification Node” is: S(C1, "Authorization Node") = 0.7 × (0.98 × 0.9) + 0.3 × (0.99 × 0.85) = 0.869 In contrast, code segment C1, belonging to other modules (such as the "data transformation node"), received the following score: S(C1, "Data Transformation Node") = 0.7 × (0.12 × 0.8) + 0.3 × (0.15 × 0.75) = 0.101 Since 0.869 is greater than 0.101, the node corresponding to sub-code segment C1 is determined to belong to the module "Permission Verification Node", that is, Module(C1) = "Permission Verification Node".

[0208] Step 5: Construct a module hierarchy diagram.

[0209] Based on the aforementioned steps, a module hierarchy graph G=(V, E, W) is constructed from the module set. Here, the node set V includes all nodes within the component, including static nodes and module nodes. For example, V={“Permission Verification Node”, “Data Conversion Node”, “User Management Module”, “User Information Query Submodule”}. The edge set E represents the hierarchical or coupling connection relationship between nodes. When the association strength (the aforementioned attribution score S) between any two nodes is greater than a preset threshold of 0.65, a connection edge is established between the corresponding nodes. For example, if the User Management Module and the User Information Query Submodule are connected with an association strength of 0.92, the User Information Query Submodule and the Permission Verification Node are connected with an association strength of 0.87, the User Information Query Submodule and the Data Conversion Node are connected with an association strength of 0.78, and the Permission Verification Node and the Data Conversion Node are connected with an association strength of 0.68, then the edge set E is: edges = [ ("User Management Module", "User Information Query Submodule", 0.92) ("User Information Query Submodule", "Permission Verification Node", 0.87) ("User Information Query Submodule", "Data Conversion Node", 0.78) ("Permission Verification Node", "Data Transformation Node", 0.68) ] Furthermore, to ensure that the edges of the hierarchical graph simultaneously reflect multiple dimensions such as documents, call chains, and data operations, a comprehensive weight W can be assigned to any edge. Taking the edge between the "permission verification node" and the "data transformation node" as an example, the comprehensive weight can be determined jointly by the document integrity score (doc_quality), the call chain stability (call_stability), and the data operation complexity (data_complexity). For example, when doc_quality = 0.8, call_stability = 0.9, and data_complexity = 0.4, the edge weight W can be calculated as follows: (0.4 + 0.1 × 0.8) + (0.35 + 0.15 × 0.9) + (0.25 - 0.1 × 0.4) = 0.48 + 0.485 + 0.21 = 1.175 Step 6, Dynamic hierarchical clustering.

[0210] In this step, the modules within the component are first initialized as independent clusters. For example, the initial cluster set is [{“Permission Verification Node”}, {“Data Conversion Node”}, {“User Management Module”}, {“User Information Query Submodule”}].

[0211] Subsequently, based on the weighted hierarchical graph obtained in step 5, the similarity σ between clusters is calculated, and the edge weight W(i,j) is used as the basic metric for inter-cluster similarity. For example, the similarity between cluster {“authorization verification node”} and cluster {“data conversion node”} can be taken as: σ({“Permission Verification Node”},{“Data Conversion Node”})=w(“Permission Verification Node”,“Data Conversion Node”)=1.175 Let the maximum similarity among the current available merging pairs be denoted as . =1.175. During cluster merging, a dynamic merging threshold is introduced to control the clustering granularity. For example, when the similarity of a pair of clusters satisfies σ≥0.7× When the condition is met, the cluster is determined to satisfy the merging condition. Since 1.175 is greater than 0.7 × 1.175, the {“Authorization Node”} and {“Data Conversion Node”} are merged to obtain a new cluster {“Authorization Node”, “Data Conversion Node”}, thus forming a higher-level module structure.

[0212] After merging, to avoid over-clustering leading to distorted module boundaries, the modularity Q-value is further calculated as a criterion for dynamically terminating and continuing clustering. For example, based on the adjacency matrix: =[[0,1,0,0],[1,0,0,0],[0,0,0,1],[0,0,1,0]]; Node degree vector k=[1,1,1,1] and total number of edges m=4. According to the formula for Q above, Q=0.09375. Since this Q value is less than the preset threshold of 0.3, it is determined that the current clustering structure has not yet reached the ideal modularity, and the clustering process continues to optimize the hierarchical results.

[0213] Meanwhile, to ensure consistency between the merged results and business logic, business semantic constraints are introduced during the clustering process to verify the merged clusters. For example, the functional description of the new cluster is set to "permission verification and data conversion," and semantic vectors vec_constraint=BERT("This module is responsible for permission verification and data conversion").embedding and target business semantic vector vec_target=BERT("User information processing core").embedding) are generated. Their cosine similarity cos_sim=0.86 is calculated. Since 0.86 is greater than the preset threshold of 0.7, the merged cluster result is determined to be compatible with the target business semantics, thus confirming that the merge conforms to the business logic constraints and is retained as a candidate result for subsequent hierarchical structures.

[0214] Step 7, Dynamic Verification and Adjustment.

[0215] In this step, the existing layering results are dynamically validated based on the call chain data from the production environment, and the node boundaries are automatically corrected when the trigger conditions are met. For example, monitoring shows that the cross-node call frequency between the "permission verification node" and the "data conversion node" is 25 times / minute, exceeding the preset threshold of 15 times / minute; simultaneously, the nodeification degree Q value decreases from 0.42 to 0.09, resulting in ΔQ = -0.33, a decrease of over 20%. Based on these monitoring indicators, when the cross-node call frequency exceeds the threshold and ΔQ is less than -0.2, a split operation is performed on the "permission verification node" and the "data conversion node".

[0216] After the splitting is complete, the adjustment results are written to the carrier to achieve synchronous updates of hierarchical information. For example, hierarchical path information is injected into the "permission verification node" through the attribute function μ, i.e.: μ(“permission verification node”, “hier”) =lookup_hierarchy(“src / main / java / ... / [UserInfoService.java] It returns the hierarchical path "User Management Module / User Information Query Submodule / Permission Verification Node", thus ensuring that the hierarchical affiliation of this node in the carrier is consistent with the internal structure of the component.

[0217] For example, in the final output hierarchical structure, the "User Management Module" has a hierarchical score of 0.92, which includes the "User Information Query Submodule" with a hierarchical score of 0.87. This submodule further contains two internal nodes: the "Permission Verification Node" and the "Data Conversion Node." The "Permission Verification Node" is associated with code segment C1 and records the dynamic adjustment event "2023-09-01: Split from merged cluster." The "Data Conversion Node" is associated with code segment C2 and records its call frequency as 25 times / minute for subsequent continuous monitoring and readjustment. The specific hierarchical structure is as follows: { "User Management Module": { "Level Score": 0.92 "Submodule": { "User Information Query Submodule": { "Level Score": 0.87 "Component": [ { Name: "Permission Verification Node", "code snippet": ["C1"], "Dynamic Adjustment": "2023-09-01: Split from merged cluster" }, { Name: Data Conversion Node "code snippet": ["C2"], Call frequency: 25 } ] } } } } Finally, the structured data of the carrier node (V) generated in this application is as follows: Figure 12 or Figure 13 As shown. For ease of comparison, traditional abstract syntax trees typically only display partial representations, such as those in the reference. Figure 14 (Due to the large amount of space, not all of them can be shown.) Under the same storage space constraints, traditional abstract syntax trees can only depict the local syntax structure of the code. They are difficult to cover the overall syntax structure (it usually requires tens of times the storage overhead to express the overall structure), and they are also difficult to simultaneously carry multi-dimensional information such as business semantics, hierarchical classification, relational dependencies, and data operations. Therefore, they can only form the expression result of the local structure.

[0218] To further illustrate the beneficial effects of this application, specific scenarios are provided below.

[0219] exist Figure 1 In application scenarios, assuming the user's input to the LLM is: to verify permission logic in the user details interface Method_getUserDetailInfo, the LLM needs to clearly define the call chain, key data flow, and specific checkpoints for permission verification to ensure the correctness of the changes, thereby completing the insertion and verification of permission control without affecting the existing data processing flow. Based on the solution provided in this application, the following can be generated: Figure 13 The retrieval carrier shown is used by LLM for code retrieval and code logic verification.

[0220] To make a comparison, let's first introduce the traditional approach's code generation process using LLM. In the traditional process, when LLM searches for code based on user requirements, the first round only retrieves the definition of the `getUserDetailInfo` method, consuming approximately 4,200 tokens, but only obtains basic method signature information, lacking context related to permissions. The second round continues to search for permission-related code based on the results of the first round, also consuming approximately 4,200 tokens. Although the `validateUser` method is found, it still fails to establish a clear association with the current interface. The third round further supplements the search of the interface call chain, consuming approximately 4,200 tokens, finally determining that permission checks need to be added before `buildUserResponse`. However, because the context obtained from multiple rounds of searching is still incomplete and fragmented, the permission verification logic may still have defects when generating subsequent code.

[0221] In contrast, by using the retrieval carrier of this application, complete carrier information can be obtained directly in a single retrieval, consuming approximately 1,800 tokens. The carrier already contains interface level information (hier field) to indicate that it belongs to the user management module, permission checkpoint information (internal field) and the validateUser method, as well as data dependency information (external field) to provide dependency elements such as UserRepository and CacheManager, and error scenario information (err field) to cover abnormal situations such as "insufficient permissions". This allows the LLM to perform reasoning and generate code under a complete and structured context, thereby directly inserting permission verification logic in the correct location. The code generation pass rate can reach 89% on the first attempt, and no manual intervention is required for correction.

[0222] Furthermore, compared to traditional solutions, the retrieval carrier in this application replaces the input of complete code text with summary information (func) and index (idx), achieving context compression and reducing token usage by approximately 70%. In addition, the carrier explicitly expresses key internal call relationships through the rel.internal field, allowing the relationship between validateUser and the target interface to be directly obtained, thereby avoiding fuzzy matching. Also, the carrier identifies module affiliation through the hier field, enabling retrieval to converge once within a clear hierarchical range, eliminating the need for multiple rounds of hierarchical retrieval. The carrier provides error scenario information such as "insufficient permissions" in advance through the desc.err field, thereby guiding the generation of more robust permission verification logic code.

[0223] Table 1 below clearly demonstrates the advantages of this application compared to traditional solutions:

[0224] Table 1

[0225] As shown in Table 1 above, the inference performance of LLM is significantly improved after adopting the retrieval carrier of this application. Specifically, the number of retrieval rounds is reduced from the traditional 3-5 rounds to 1 round, a reduction of about 60-80%. At the same time, due to the more focused input context, the token consumption is reduced from 12,600-21,000 to about 1,800, a reduction of about 85-91%, thereby shortening the processing time from 28 seconds to 9 seconds, a reduction of about 68%. In terms of performance, the generation accuracy is improved from 62% to 89%, an improvement of about 27%, and the code location accuracy can be improved to 100%, which is a significant improvement compared to the 63% location accuracy of the traditional method.

[0226] The aforementioned improvements stem from two main sources. First, the retrieval carrier structure optimizes information organization and storage, resulting in an approximately 85% reduction in storage space and a 7.3-fold increase in retrieval efficiency. Second, the explicit expression of relational information allows for direct utilization of inter-method calls and implicit relationships, thereby reducing reliance on fuzzy matching and improving generation accuracy. Furthermore, the retrieval carrier employs hierarchical information, enabling rapid convergence of searches within a defined hierarchy, avoiding context accumulation from multiple rounds of retrieval and reducing the risk of context overruns. Finally, the summary compression mechanism further reduces token consumption and improves overall processing speed by replacing lengthy original text input with shorter semantic expressions.

[0227] It is understood that the retrieval carrier of this application can be applied to a variety of application scenarios. Figure 1 The application scenarios shown are merely examples. The retrieval carrier of this application can also be applied in other scenarios, such as in artificial intelligence agent (AI agent) systems to improve the quality of code retrieval and code generation; it can also be extended to scenarios such as code understanding, code search, and code recommendation to support comprehensive analysis and result output of code semantic and structural relationships; it can also be deeply integrated with integrated development environment (IDE) to provide more accurate intelligent code completion and refactoring suggestions for the development process, and so on.

[0228] Based on the same concept, this application also provides a code retrieval device that can perform the code retrieval method described above.

[0229] Please see Figure 15 The present application provides a schematic diagram of the structure of a code retrieval device according to an embodiment of the present application, such as... Figure 15 As shown, the code retrieval device includes: The determination module 1501 is used to determine the target retrieval carrier that meets the code retrieval requirements based on the code retrieval requirements and through the retrieval carriers of each code segment in the source code library. Each retrieval carrier is constructed through the source code library and the corresponding business documents, including semantic information representing the code segment and structural information representing the code segment. The structural information includes the hierarchical information of the code segment in the code to which it belongs. The retrieval module 1502 is used to obtain response results for code retrieval requests based on the code fragment indicated by the target retrieval carrier.

[0230] In one possible implementation, the retrieval carrier includes summary information and data information representing semantic information, hierarchical information and relational information representing structural information, and index information pointing to code segments; the summary information represents at least one of function, scenario, input / output, and exception mechanism; the hierarchical information represents at least one of interface, component, module, and submodule; the relational information represents at least one of inclusion, implementation, inheritance, overriding, calling, and dynamic calling; the data information represents data operation information; and the index information represents the physical storage location of the corresponding code segment.

[0231] In one possible implementation, the determining module 1501 is specifically used to: determine the nodes corresponding to different code segments based on each code segment in the source code library; the nodes include dynamic nodes and static nodes; determine the connection relationship between each static node based on the relationship between each code segment; determine the connection relationship between dynamic nodes and static nodes based on the runtime information of the source code library; generate semantic information of the nodes corresponding to any code segment based on any code segment and its corresponding business document; and integrate each node, the connection relationship between each node, and the semantic information of each node into a retrieval carrier for each code segment.

[0232] In one possible implementation, the determining module 1501 is specifically used to: acquire function call chain data of the source code library at runtime based on a set probe; the function call chain data includes multiple call chain data, and each call chain data includes multiple span information; for any dynamic node, acquire the runtime log of the dynamic node obtained by running the source code library; determine the call chain data and the runtime log of the dynamic node with the same tracking identifier; determine the similarity between any runtime log and any span information in the call chain data; and establish a connection relationship between the static node indicated by the span information that meets the similarity matching requirement and the dynamic node.

[0233] In one possible implementation, the determining module 1501 is specifically used to: for any running log and any span information, determine a first keyword in the running log and a second keyword in the span information; determine a first similarity between the running log and the span information based on each first keyword and each second keyword; determine a second similarity based on the first time information in the running log and the second time information of the span information; and determine a matching degree based on the first similarity and the second similarity.

[0234] In one possible implementation, the first similarity includes set similarity and cosine similarity. The determining module 1501 is specifically used to: determine set similarity based on the number of first keywords and the number of second keywords; determine cosine similarity based on the vectors of the first keywords and the vectors of the second keywords; the determining module 1501 is specifically used to: adjust the weights of set similarity, cosine similarity and second similarity based on the application scenario of the source code library; and determine the matching degree based on the first similarity and the second similarity based on the adjusted weights.

[0235] In one possible implementation, the determining module 1501 is specifically used for: determining a static node corresponding to any component code fragment in the source code library, wherein the component code fragment includes multiple sub-code fragments, each sub-code fragment corresponding to a static node; determining a functional module from the flowchart of the component code fragment; wherein any functional module corresponds to a static node; and the determining module 1501 is specifically used for: establishing a connection relationship between the static node corresponding to any functional module and the static node corresponding to the component code fragment; for any functional module, determining keywords of business functions belonging to the functional module from the business document corresponding to the component code fragment; and determining the connection relationship between the static node corresponding to any sub-code fragment and the static node corresponding to the functional module based on the keywords of the business functions of the functional module and the structural information of the functional module.

[0236] In one possible implementation, the determining module 1501 is specifically used to: determine the semantic similarity between the keywords of the business functions of the functional module and the sub-code fragments; determine the structural similarity between the structural information of the functional module and the sub-code fragments; determine a comprehensive score of similarity based on semantic similarity and structural similarity; and determine the connection relationship between the static nodes corresponding to the sub-code fragments and the static nodes corresponding to the functional module based on the comprehensive score.

[0237] In one possible implementation, the determining module 1501 is further configured to: determine the edge weights between nodes with a connection relationship based on the historical running data of the component code snippet and the integrity of the business document; determine the clustering value of nodes at the same level based on the edge weights, and merge nodes at the same level to generate a new node when the clustering value is greater than a first threshold; determine the module degree value based on each edge weight, and stop merging any two nodes when the module degree value is less than a second threshold.

[0238] In one possible implementation, the determining module 1501 is further configured to: acquire function call chain data in real time and obtain the cross-node call frequency between any two nodes; when the cross-node call frequency between two nodes is higher than a third threshold, perform splitting operations on the two nodes respectively; when the change in module degree value is greater than a fourth threshold, determine whether to merge the two nodes based on the edge weight between them. In another possible implementation, the determining module 1501 is specifically configured to: determine the code and retrieval requirements corresponding to the user input information through a large language model; the retrieval module 1502 is specifically configured to: use the target retrieval carrier and code fragment as context for reasoning through a large language model, and obtain the reasoning result corresponding to the user input information.

[0239] Please see Figure 16 This shows a schematic diagram of another code retrieval device provided in an embodiment of this application, such as... Figure 16 As shown, the code retrieval device includes a memory 1601 and a processor 1602, with the processor 1602 coupled to the memory 1601. The memory 1601 stores program instructions, and the processor 1602 calls the program instructions stored in the memory 1601 to execute the code retrieval method described above according to the obtained program.

[0240] Optionally, the code retrieval device may further include an interface circuit 1603, which may be a transceiver or an input / output interface. The input / output interface is used for inputting and / or outputting information; output can be understood as sending, and input as receiving. The processor 1602 can communicate with other devices in the code retrieval device or other devices besides the code retrieval device through the interface circuit 1603 to obtain the information required to perform the above code retrieval method.

[0241] When the code retrieval device 1600 is used to implement Figure 2 In the method shown, the processor 1602 is used to implement the functions of the determination module 1501 and the retrieval module 1502 described above.

[0242] It is understood that the processor in the embodiments of this application may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

[0243] The memory in the embodiments of this application may be random access memory, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, hard disk, portable hard disk, compact disc read-only memory (CD-ROM), or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. The storage medium may also be a component of the processor.

[0244] Based on the same technical concept, embodiments of this application also provide a computer-readable storage medium storing a computer program or instructions, which, when executed by a processor, causes the computer to perform the above-described code retrieval method.

[0245] Based on the same technical concept, embodiments of this application also provide a computer-readable program product, which, when executed, causes a computer to perform the above-described code retrieval method.

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

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

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

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

[0250] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A code retrieval method, characterized in that, include: Based on the code retrieval requirements, the target retrieval carrier that meets the code retrieval requirements is determined by using the retrieval carriers of each code fragment in the source code library; Any retrieval carrier is constructed through the source code library and the corresponding business documents, including semantic information representing the code fragment and structural information representing the code fragment, wherein the structural information includes the hierarchical information of the code fragment in the code to which it belongs; Based on the code fragment indicated by the target retrieval carrier, a response result for the code retrieval request is obtained.

2. The method as described in claim 1, characterized in that, The retrieval carrier includes summary information and data information representing semantic information, hierarchical information and relational information representing structural information, and index information pointing to code fragments; The summary information represents at least one of the following: function, scenario, input / output, and exception mechanism; The hierarchical information represents at least one of the following: interface, component, module, and submodule. The relational information representation includes at least one of the following: implementation, inheritance, overriding, invocation, and dynamic invocation; The data information represents data operation information; The index information represents the physical storage location of the corresponding code segment.

3. The method as described in claim 1, characterized in that, Each of the retrieval carriers is constructed using the source code library and corresponding business documentation, including: Based on the code snippets in the source code library, the nodes corresponding to different code snippets are determined; the nodes include dynamic nodes and static nodes. Based on the relationships between the code snippets, determine the connection relationships between the static nodes; The connection relationship between dynamic nodes and static nodes is determined based on the runtime information of the source code library; Generate semantic information of the corresponding node of any code snippet based on any code snippet and its corresponding business document; The nodes, their connections, and their semantic information are integrated into a retrieval carrier for each code fragment.

4. The method as described in claim 3, characterized in that, Determining the connection relationship between dynamic and static nodes based on the runtime information of the code snippet includes: The function call chain data of the source code library during runtime is obtained based on a set probe; the function call chain data includes multiple call chain data, and each call chain data includes multiple span information. For any dynamic node, obtain the running log of the dynamic node obtained by running the source code library; Identify call chain data with the same tracing identifier and the runtime logs of the dynamic nodes; Determine the similarity between any runtime log and any span of information in the call chain data; The static nodes, whose span information indicates similarity and meets the matching requirements, are connected to the dynamic nodes.

5. The method as described in claim 4, characterized in that, Determining the similarity between any runtime log and any span information in the call chain data includes: For any running log and any span information, determine the first keyword in the running log and the second keyword in the span information; The first similarity between the operation log and the span information is determined based on each first keyword and each second keyword; A second similarity is determined based on the first time information in the operation log and the second time information of the span information; The matching degree is determined based on the first similarity and the second similarity.

6. The method as described in claim 4, characterized in that, The first similarity includes set similarity and cosine similarity. Determining the first similarity between the running log and the span information based on each first keyword and each second keyword includes: The similarity of the set is determined based on the number of the first keyword and the number of the second keyword; The cosine similarity is determined based on the vectors of the first keyword and the second keyword; The step of determining the matching degree based on the first similarity and the second similarity includes: Based on the application scenario of the source code library, adjust the weights of the set similarity, the cosine similarity, and the second similarity. Based on the adjusted weights, the first similarity and the second similarity determine the matching degree.

7. The method according to any one of claims 3-6, characterized in that, The step of determining the nodes corresponding to different code fragments based on the code fragments in the source code library includes: Each component code fragment in the source code library corresponds to a static node; the component code fragment includes multiple sub-code fragments, and each sub-code fragment corresponds to a static node; The functional modules are determined from the flowchart of the component code snippet; each functional module corresponds to a static node; Based on the relationships between the various code snippets, determine the connection relationships between the static nodes, including: Establish the connection relationship between the static node corresponding to any functional module and the static node corresponding to the component code snippet; For any functional module, keywords of the business functions belonging to the functional module are determined from the business document corresponding to the component code fragment; based on the keywords of the business functions of the functional module and the structural information of the functional module, the connection relationship between the static node corresponding to any sub-code fragment and the static node corresponding to the functional module is determined.

8. The method as described in claim 7, characterized in that, The method for determining the connection relationship between the static node corresponding to any sub-code segment and the static node corresponding to the functional module, based on the keywords of the business functions of the functional module and the structural information of the functional module, includes: Determine the semantic similarity between the keywords of the business functions of the functional module and the sub-code fragments; Determine the structural similarity between the functional module and the sub-code fragment; A comprehensive score for similarity is determined based on the semantic similarity and the structural similarity. The connection relationship between the static node corresponding to the sub-code fragment and the static node corresponding to the functional module is determined based on the comprehensive score.

9. The method as described in claim 8, characterized in that, After determining the connection relationship between the static node corresponding to the sub-code fragment and the static node corresponding to the functional module based on the comprehensive score, the method further includes: The edge weights between nodes with connection relationships are determined based on the historical runtime data of the component code snippet and the completeness of the business document. The clustering value of nodes at the same level is determined based on the edge weight. When the clustering value is greater than the first threshold, the nodes at the same level are merged to generate a new node. The modularity value is determined based on the weights of each edge. When the modularity value is less than the second threshold, the merging of any two nodes is stopped.

10. The method as described in claim 8, characterized in that, Also includes: Real-time acquisition of function call chain data, and acquisition of cross-node call frequency between any two nodes; When the frequency of cross-node calls between two nodes exceeds the third threshold, the two nodes are split. When the change in the modularity value is greater than the fourth threshold, it is determined whether the two nodes should be merged based on the edge weight between them.

11. The method according to any one of claims 1-6, characterized in that, The code-based retrieval requirements include: Determine the code retrieval requirements corresponding to user input information through a large language model; The process of obtaining a response to the code retrieval request based on the code fragment indicated by the target retrieval carrier includes: The target retrieval carrier and the code fragment are used as context for reasoning through the large language model to obtain the reasoning result corresponding to the user input information.

12. A computer-readable storage medium, characterized in that, It stores a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of any of the methods described in claims 1 to 11.

13. A computer program product, characterized in that, When it is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 11.

Images