Code analysis methods, devices, equipment, and storage media based on large language models

Abstract

This invention discloses a code analysis method, apparatus, device, and storage medium based on a large language model, relating to computer technology and the field of large language model technology. The method includes: extracting key call chains based on a call relationship graph file and a project structure file to obtain the first batch of data, which is then input into the large language model to generate the first batch of context information; sequentially extracting configuration information as the second batch of data, combining the first batch of context information with call relationship information to obtain the third batch of data, and extracting data operation information as the fourth batch of data, inputting each batch into the large language model to generate context information for the corresponding batch; and integrating the context information from all batches to generate a code analysis report. This invention, through key call chain extraction and batch processing, solves the problem of reduced accuracy of analysis results caused by the limited amount of input data for the large language model, effectively improving the accuracy of code analysis results.

Description

Technical Field

[0001] This invention relates to the fields of computer technology and large language model technology, and in particular to a code analysis method, apparatus, device and storage medium based on a large language model. Background Technology

[0002] In the development and maintenance of large software projects, using large language models to assist in the analysis of project code has become a common practice. This type of method typically inputs the structured information or source code text into a large language model, which then outputs analysis results on the code's functionality, architecture, or potential defects.

[0003] However, large language models have a clear limit on the amount of data that can be input at one time. For large projects that include a large number of code units, the size of the complete structured information often exceeds this input limit. If the excess data is discarded by directly truncating it before inputting it into the large language model, it will lead to the loss of critical business call chain information, thereby reducing the accuracy of the code analysis results.

[0004] Therefore, improving the accuracy of code analysis results for large-scale projects has become an urgent problem to be solved. Summary of the Invention

[0005] Based on this, embodiments of the present invention provide a code analysis method, apparatus, device, and storage medium based on a large language model, to solve the problem in the prior art where, due to the limited amount of input data for a large language model, data is directly truncated when analyzing code from large projects, resulting in the loss of critical business call chain information and thus reducing the accuracy of the analysis results.

[0006] Firstly, a code analysis method based on a large language model is provided, including: Obtain the structured data of the target code project, including the project structure file, call relationship diagram file, project configuration file, and data operation file; Based on the call relationship graph file and the project structure file, key call links are extracted to obtain the first batch of data; The first batch of data is input into a preset large language model to obtain the first analysis result, and the first analysis result is saved as the first batch of context information; The configuration information in the project configuration file is extracted as the second batch of data. The second batch of data is input into the large language model to obtain the second analysis result, and the second analysis result is saved as the second batch of context information. Load the first batch of context information, extract call relationship information from the call relationship graph file, construct the third batch of data based on the first batch of context information and the call relationship information, input the third batch of data into the large language model, obtain the third analysis result, and save the third analysis result as the third batch of context information; Extract the data operation information from the data operation file as the fourth batch of data, input the fourth batch of data into the large language model to obtain the fourth analysis result, and save the fourth analysis result as the fourth batch of context information; Based on the first batch of context information, the second batch of context information, the third batch of context information, and the fourth batch of context information, a code analysis report for the target code project is generated.

[0007] Secondly, a code analysis device based on a large language model is provided, including: The acquisition module is used to acquire the structured data of the target code project, which includes the project structure file, the call relationship diagram file, the project configuration file, and the data operation file. The extraction module is used to extract key call chains based on the call relationship graph file and the project structure file to obtain the first batch of data; The first processing module is used to input the first batch of data into a preset large language model, obtain the first analysis result, and save the first analysis result as the first batch of context information; The second processing module is used to extract the configuration information in the project configuration file as the second batch of data, input the second batch of data into the large language model, obtain the second analysis result, and save the second analysis result as the second batch of context information. The third processing module is used to load the first batch of context information, extract call relationship information from the call relationship graph file, construct a third batch of data based on the first batch of context information and the call relationship information, input the third batch of data into the large language model, obtain a third analysis result, and save the third analysis result as the third batch of context information. The fourth processing module is used to extract the data operation information from the data operation file as the fourth batch of data, input the fourth batch of data into the large language model to obtain the fourth analysis result, and save the fourth analysis result as the fourth batch of context information. The generation module is used to generate a code analysis report for the target code project based on the first batch of context information, the second batch of context information, the third batch of context information, and the fourth batch of context information.

[0008] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described code analysis method based on a large language model.

[0009] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the above-described code analysis method based on a large language model.

[0010] Based on this, a technical solution provided by an embodiment of the present invention has the following technical effects: First, key call chains are extracted based on the call relationship graph file and project structure file. From the complete structured data, key call paths constituting the core business framework are selected, generating a first batch of data with significantly reduced volume. This ensures complete adaptation to the single-input limitations of the large language model, effectively avoiding the loss of key business call chain information caused by direct truncation and ensuring the integrity of the project's core architecture analysis. Based on this, a batch processing strategy is adopted. Configuration information from the project configuration file is used as the second batch of data; the first batch of data, composed of the first batch's context information and call relationship information extracted from the call relationship graph file, is used as the third batch; and data operation information from the data operation file is used as the fourth batch. These are then input into the large language model for analysis. The third batch of data, composed of the first batch's context information and call relationship information, allows the large language model to perform in-depth analysis of call relationship information based on the understood overall project architecture and core business processes, rather than performing syntactic analysis on isolated call edges. Each batch of analysis results is saved as independent context information, allowing each batch of analysis to focus on in-depth analysis of specific data types while providing a complete business semantic foundation for subsequent integration through the preservation of context information. Ultimately, by integrating all four batches of context information, a complete code analysis report was generated, effectively improving the accuracy of the code analysis results while fully adhering to the input data volume limitations of the large language model. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram of an application environment for a code analysis method based on a large language model according to an embodiment of the present invention; Figure 2 This is a flowchart of a code analysis method based on a large language model in one embodiment of the present invention; Figure 3 This is another flowchart of a code analysis method based on a large language model in one embodiment of the present invention; Figure 4 This is another flowchart of a code analysis method based on a large language model in one embodiment of the present invention; Figure 5 This is another flowchart of a code analysis method based on a large language model in one embodiment of the present invention; Figure 6 This is another flowchart of a code analysis method based on a large language model in one embodiment of the present invention; Figure 7 This is another flowchart of a code analysis method based on a large language model in one embodiment of the present invention; Figure 8 This is a schematic diagram of a code analysis device based on a large language model in one embodiment of the present invention; Figure 9 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

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

[0014] The code analysis method based on a large language model provided in this invention can be applied to, for example... Figure 1 The application environment is shown. Specifically, this code analysis method based on a large language model is applied in a code analysis system based on a large language model, which includes, for example, […]. Figure 1 The diagram illustrates a client and server that communicate over a network to implement the code analysis method based on a large language model. The client, also known as the user terminal, refers to the program that provides local services to the client, corresponding to the server. Clients can include, but are not limited to, various personal computers, laptops, smartphones, and tablets. The server can be a standalone server or a server cluster consisting of multiple servers.

[0015] Firstly, such as Figure 2 As shown, this embodiment of the invention provides a code analysis method based on a large language model, which is applied to... Figure 1Taking the server in the example, the following steps are included: S101: Obtain the structured data of the target code project. The structured data includes the project structure file, call relationship diagram file, project configuration file, and data operation file.

[0016] The target code project refers to the software project to be analyzed. It can be a small project with dozens of classes or a large system with hundreds of classes, tens of thousands or even hundreds of thousands of lines of code. Its programming language can be any one or more such as Java, Python, C++, and Go.

[0017] Structured data refers to data with a unified format and structure extracted from source code files, original configuration files, database operation files, and other original files of the target code project after engineering-level structured parsing. It can include the following four types of files: Project structure files, which contain structural information about each class in the target code project, including class name, package, type, methods defined in the class, attributes defined in the class, inheritance relationships, and implementation relationships. Call graph files, which contain information about the call relationships between multiple classes in the target code project, including caller classes and methods, callee classes and methods, and call types. Project configuration files, which contain configuration information required for the target code project to run. Data operation files, which contain information related to the interaction between the target code project and the database, including database operation statements, table structure information, and the mapping relationship between database operations and business methods. All four types of files can be in JSON format, for example, named project.json, call-graph.json, configs.json, and sql.json, respectively.

[0018] In one possible approach, the method of obtaining structured data of a target code project may include: generating structured data by performing engineering-level structured parsing on the source code repository of the target code project; directly obtaining it by reading a pre-prepared structured data file; or obtaining it through offline or online analysis by calling code scanning tools or third-party AST parsing tools.

[0019] S102: Extract key call chains based on the call relationship diagram file and project structure file to obtain the first batch of data.

[0020] The critical call chain refers to the call path that constitutes the core business process in the target code project, formed by multiple class nodes connected sequentially according to their call relationships. The first batch of data is a collection of information about all class nodes located on the critical call chain, extracted from the project structure file; its data volume is smaller than that of the structured data.

[0021] In one possible implementation, key call chain extraction is performed based on a call relationship graph file and a project structure file to obtain the first batch of data. This may include: constructing a directed call relationship graph with classes as nodes and call relationships between classes as edges based on the call relationship graph file; identifying classes with preset entry annotation types as business entry nodes in the directed call relationship graph; traversing the directed call relationship graph from the business entry nodes to extract node sequences that conform to preset call patterns, obtaining at least one call path; scoring the criticality of each obtained call path and selecting key call paths based on the scoring results; extracting information of all class nodes on each key call path from the project structure file and performing intelligent filtering to obtain the first batch of data.

[0022] In another possible approach, a call chain index can be built based on the call relationship graph file. The class node names on the call path are matched according to the preset core business keywords to extract the call chain related to the core business. The corresponding class node information is then extracted from the project structure file to obtain the first batch of data.

[0023] In another possible approach, the call relationship graph file and project structure file can be input into a pre-trained machine learning model. The machine learning model can then predict the importance of the call paths, identify the call chains that have the greatest impact on the project's business logic, and extract the corresponding class node information from the project structure file to obtain the first batch of data.

[0024] S103: Input the first batch of data into the preset large language model to obtain the first analysis result, and save the first analysis result as the first batch of context information.

[0025] The pre-selected large language model refers to a pre-selected large language model used for code analysis. Large language models can include, but are not limited to, OpenAI (such as GPT-4o, GPT-4o-mini), DeepSeek, Grok, Gemini, Doubao, and Wenxin Yiyan. The first analysis result can include an overall architecture description of the target code project, identification of major business modules, explanation of the business logic of the core call chain, functional description of key classes and methods, data flow analysis of core business processes, and analysis of potential architectural risk points.

[0026] In one possible approach, the initial batch of data can be input into a pre-defined large language model by either calling an API provided by the large language model provider or directly calling a local model loading and inference interface. Before inputting the initial batch of data into the pre-defined large language model, a cue word containing the initial batch of data is constructed. The cue word may include a description of the analysis task and requirements for the output format.

[0027] For example, suppose the first batch of data includes information on six core classes: OrderController, OrderServiceImpl, OrderLogic, InventoryLogic, OrderSal, and OrderRpc, as well as their call relationships. The prompt could be: "Please analyze the core business architecture of the following target code project. The following are the core classes and their call relationships extracted after key call chain analysis. Please output: 1. Overall architecture description; 2. Identification of main business modules; 3. Business logic description of core call chain; 4. Functional description of key classes and methods; 5. Data flow analysis of core business processes; 6. Analysis of potential architectural risk points." S104: Extract the configuration information from the project configuration file as the second batch of data, input the second batch of data into the large language model to obtain the second analysis result, and save the second analysis result as the second batch of context information.

[0028] The configuration information in the project configuration file refers to the configuration items related to the target code project's runtime environment extracted from the project configuration file, including: database connection address, database connection pool size, cache server address, cache expiration time, message queue server address, RPC service timeout time, and retry policy parameters.

[0029] Based on their respective functional areas, database connection address and database connection pool size belong to database configuration, used to control the connection method and connection resources with the database; cache server address and cache expiration time belong to cache configuration, used to control the access address and data validity period of the cache service; message queue server address belongs to message queue configuration, used to control the sending and receiving channels of asynchronous messages; RPC service timeout time and retry policy parameters belong to remote service call configuration, used to control the timeout threshold and failure retry behavior when communicating with remote services.

[0030] The second batch of data refers to the data to be analyzed, which mainly consists of configuration information from the project configuration file. The second analysis result refers to the output of the large language model after receiving the second batch of data and performing analysis and reasoning on it. This may include: classification and summarization of configuration information, analysis of relationships between configuration items, analysis of the impact of configuration items on system performance, analysis of potential risks associated with configuration items, and conflict detection between configuration items.

[0031] For example, suppose the configuration information extracted from the project configuration file includes: a database connection pool size of 10, a cache expiration time of 3600 seconds, an RPC service timeout of 3 seconds, and an RPC service retry policy of 2 retries. After constructing the above configuration information into prompts and inputting them into a large language model, the second analysis result indicates that: a database connection pool size of 10 may lead to connection timeouts in high-concurrency scenarios, and it is recommended to increase it to 30; a RPC service timeout of 3 seconds may be insufficient considering the long call chain reflected in the first batch of context information, and it is recommended to extend it to 10 seconds; a RPC service retry policy of 2 retries may be insufficient to handle temporary network failures, and it is recommended to increase the number of retries or introduce a circuit breaker mechanism; a cache expiration time of 3600 seconds is within a reasonable range and does not show any significant conflict with the database connection pool size configuration.

[0032] S105: Load the first batch of context information, extract the call relationship information from the call relationship graph file, construct the third batch of data based on the first batch of context information and the call relationship information, input the third batch of data into the large language model, obtain the third analysis result, and save the third analysis result as the third batch of context information.

[0033] In one possible implementation, firstly, the first batch of context information is loaded, and the summary information recorded therein is read. Call relationship information is extracted from the call relationship graph file, which may include the caller class and method, the callee class and method, and the call type. The summary information from the first batch of context information and the call relationship information are combined to construct prompts for input into the large language model. These prompts include the content of the summary information and the call relationship information, instructing the large language model to analyze the call relationship information based on the overall project architecture and core business processes recorded in the summary information, identifying the position and role of each call relationship in the overall business process. The prompts are then input into the large language model to obtain a third analysis result. This third analysis result, combined with the project architecture, explains the position and role of each call relationship in the overall business process. The third analysis result is saved as the third batch of context information.

[0034] The reason for setting up a third batch is as follows: The first batch of data is a collection of core class information extracted and intelligently filtered from key call chains. The data volume has been compressed to fit the single input limit of the large language model. The analysis goal is to establish a global understanding of the project's core business architecture. The call relationship graph file records the complete call relationship network between all known classes in the project, and its coverage far exceeds the core class set in the first batch of data. If the complete call relationship information is merged with the first batch of data for input, the input data volume may exceed the single input limit of the large language model. If the call relationship information is directly input into the large language model without the context information of the first batch, the large language model can only perform syntactic analysis on isolated call edges. Therefore, the call relationship information needs to be processed separately as a third batch, and the summary information from the context information of the first batch is combined with it to form the input data, enabling the large language model to perform in-depth analysis of the call relationships in conjunction with the understood overall project architecture and core business processes.

[0035] For example, the first batch of context information is loaded by reading the batch_1_context.json file. The first batch of context information is a summary of the first analysis results, which contains key content extracted from the first analysis results: The layered architecture of this project is the controller layer (OrderController), service layer (OrderServiceImpl), business logic layer (OrderLogic), service aggregation layer (OrderSal), and remote call layer (OrderRpc); the core business chain is OrderController→OrderServiceImpl→OrderLogic→OrderSal→OrderRpc; the processOrder method defined in the OrderLogic class is the core method for order processing, which is responsible for calling validateOrder to verify the order, calling InventoryLogic.deductStock to deduct inventory, calling PaymentLogic.processPayment to process payment, and calling OrderSal.submitOrder to submit the order.

[0036] Extract call relationship information from the call graph file (call-graph.json), parse the file to obtain all the call relationship data recorded therein, and the extraction results include: OrderController calls OrderServiceImpl, OrderServiceImpl calls OrderLogic, OrderLogic calls InventoryLogic, OrderLogic calls PaymentLogic, OrderLogic calls OrderSal, and OrderSal calls OrderRpc.

[0037] The summary information from the first batch of context information is combined with the aforementioned call relationship information to construct prompt words for input into the large language model. The first part of the prompt word is the functional description of the aforementioned layered architecture, core business links, and key class methods recorded in the summary information. The second part of the prompt word is the aforementioned call relationship information, instructing the large language model to analyze the call relationship information in the second part based on the architecture and links already understood in the first part. The prompt words are input into the large language model, which outputs the third analysis result, identifying that OrderLogic's call to InventoryLogic and its call to PaymentLogic belong to the inventory deduction and payment processing branches, respectively; OrderLogic's call to OrderSal belongs to the call from the business logic processing layer to the service aggregation layer; and OrderSal's call to OrderRpc belongs to the call from the service aggregation layer to the remote call layer. The third analysis result is then summarized to extract the aforementioned call relationship analysis conclusions, which are saved as the third batch of context information.

[0038] S106: Extract the data operation information from the data operation file as the fourth batch of data, input the fourth batch of data into the large language model to obtain the fourth analysis result, and save the fourth analysis result as the fourth batch of context information.

[0039] The data operation information in the data operation file refers to the information extracted from the data operation file, which may include data table structure information, data table field information, and the mapping relationship between database operations and business methods. The fourth batch of data refers to the data to be analyzed, primarily consisting of the data operation information from the data operation file. The fourth analysis result refers to the output of the large language model after receiving the fourth batch of data and performing analysis and inference on it.

[0040] The reason for setting up a fourth batch is that the data operation information in the data operation file describes the project from a "data" perspective, which is fundamentally different in structure from the "code" perspective described in the first batch of data. If the data tables, fields, and their mapping relationships with business methods are merged with the core code call relationships, it will create a mixture of two different dimensions of information. This not only increases the data volume but also causes the focus of the large language model analysis to switch between code architecture and data structure, affecting the depth of the analysis. Therefore, the data operation information in the data operation file is processed separately as a fourth batch, and its analysis results are then integrated with the architecture analysis, configuration analysis, and call relationship analysis in the final integration stage.

[0041] For example, the data operation information extracted from the data operation file may include: the data table name t_order, and the data table fields including order_id (primary key, VARCHAR(32)), user_id, product_id, amount, status, and create_time; the mapping relationship between database operations and business methods shows that the OrderDao.insertOrder method is responsible for performing data insertion operations into the t_order table, and the OrderDao.queryOrder method is responsible for performing data query operations into the t_order table. The above data operation information is input into the large language model as the fourth batch of data. When analyzing this information, the large language model will evaluate its normalization in combination with the data table structure, and associate the data operations with the core business links identified in the first batch of analysis according to the mapping relationship, so as to verify the rationality and potential risks from business logic to data persistence.

[0042] It should be noted that the second batch of context information mentioned above is the context information formed after summarizing the second analysis results, the third batch of context information is the context information formed after summarizing the third analysis results, and the fourth batch of context information is the context information formed after summarizing the fourth analysis results.

[0043] S107: Generate a code analysis report for the target code project based on the first batch of context information, the second batch of context information, the third batch of context information, and the fourth batch of context information.

[0044] The code analysis report is the final output generated after a comprehensive analysis of the target code project. It may include architecture documents, call flow documents, data flow documents, configuration overview documents, troubleshooting manuals, etc.

[0045] In one feasible approach, the first, second, third, and fourth batches of context information can be integrated into a fifth batch of data. This fifth batch of data is then input into a large language model to obtain comprehensive analysis results. Based on these results, a code analysis report for the target code project is generated. Since each batch of context information has undergone digest processing during storage, and its individual data length is controlled, the length of the integrated fifth batch of data can not exceed the single-batch context token limit of the large language model.

[0046] In summary, the code analysis method based on the large language model described above achieves the following effects: First, by extracting key call chains, the key call paths constituting the core business framework are filtered from the complete structured data, generating a first batch of data with significantly reduced data volume. This ensures that the data volume is fully adapted to the single input data volume limit of the large language model, effectively avoiding the loss of key business call chain information caused by direct truncation, and ensuring the integrity of the project's core architecture analysis. Second, through a batch processing strategy, configuration information, call relationship information, and data operation information are input into the large language model as independent second, third, and fourth batches of data for analysis. This allows each batch of analysis to focus on specific types of data for in-depth analysis without interference. Simultaneously, the third batch uses the context information of the first batch as the analysis background for call relationship analysis, enabling the large language model to conduct in-depth analysis of call relationships in conjunction with the understood overall project architecture and core business processes. Third, the analysis results of each batch are summarized during saving, controlling the amount of context data while preserving core semantic information. When the context information of the four batches is finally integrated, the analysis results of the four dimensions can be uniformly organized and arranged, cross-validated from a global perspective, eliminating information silos between batches, discovering cross-dimensional correlation issues that may have been missed in single batch analysis, and generating a comprehensive and internally consistent code analysis report that covers everything from the core architecture to configuration information, from call relationships to data operations, effectively improving the accuracy of code analysis results.

[0047] In one embodiment, the code analysis method based on a large language model further includes a batch dependency management mechanism. Dependency types are assigned to each batch, with the first, third, and fifth batches designated as critical batches, and the second and fourth batches as non-critical batches. When the analysis of a critical batch fails, a retry mechanism is automatically triggered for that critical batch. The input data for that critical batch is reconstructed and re-input into the large language model for analysis. If the number of retries exceeds a preset threshold and still fails, the entire analysis process is terminated. When the analysis of a non-critical batch fails, an alarm message is recorded, and that non-critical batch is skipped, continuing the analysis of subsequent batches. A partial analysis report mode is also provided. When there are failed non-critical batches, a partial analysis report is generated based on the analysis results of other successfully executed batches and the first analysis result, and the missing analysis content is marked in the partial analysis report.

[0048] In the batch dependency management mechanism, the first batch corresponds to the step of inputting the first batch of data obtained after extracting the key call chain into the large language model to obtain the first analysis result; the third batch corresponds to the step of extracting the key call relationship information from the context information of the first batch as the third batch of data input into the large language model to obtain the third analysis result; the fifth batch corresponds to the step of generating a code analysis report based on the context information of the fourth batch; the second batch corresponds to the step of extracting the configuration information from the project configuration file as the second batch of data to obtain the second analysis result; and the fourth batch corresponds to the step of extracting the data operation information from the data operation file as the fourth batch of data to obtain the fourth analysis result.

[0049] In one embodiment, such as Figure 3 As shown, step S102, which involves extracting key call chains based on the call relationship diagram file and project structure file to obtain the first batch of data, includes the following steps: S121: Based on the call relationship graph file, construct a directed call relationship graph with classes as nodes and the call relationships between classes as edges.

[0050] A directed call graph is a directed graph structure used to represent call relationships between classes, consisting of a set of nodes and a set of edges. Each node in the node set represents a class in the target code project, and each edge in the edge set represents a call relationship between two classes. The direction of the edge indicates the direction of the call, i.e., from the calling class to the called class. The formal representation of a directed call graph is G(V,E), where V is the set of nodes and E is the set of edges.

[0051] The process of constructing the directed call graph is implemented in computer memory using a graph data structure. An adjacency list is used to store the directed call graph, with each node as the key and the list of neighboring nodes pointed to by that node as the value.

[0052] For example, suppose the target code project includes five classes: OrderController, OrderServiceImpl, OrderLogic, OrderSal, and OrderRpc. The call graph file records the following call relationships: OrderController calls OrderServiceImpl, OrderServiceImpl calls OrderLogic, OrderLogic calls OrderSal, and OrderSal calls OrderRpc. Then, the constructed directed call graph contains nodes V including {OrderController, OrderServiceImpl, OrderLogic, OrderSal, OrderRpc}, and edges E including {OrderController→OrderServiceImpl, OrderServiceImpl→OrderLogic, OrderLogic→OrderSal, OrderSal→OrderRpc}.

[0053] S122: Identify classes with preset entry annotation types as business entry nodes in the directed call relationship graph.

[0054] The preset entry point annotation type refers to a pre-defined annotation type used to identify the business entry point class. For example, in a Java project, the preset entry point annotation types include the `@RestController` annotation and the `@Controller` annotation. A class with a preset entry point annotation type is a controller class that receives and processes external HTTP requests; it is the entry point for the business process. A business entry point node refers to the node in the directed call graph that corresponds to a class marked with a preset entry point annotation type.

[0055] In one possible implementation, the business entry point node can be identified by: traversing all nodes in the directed call graph; for each node, checking whether the class corresponding to that node has a preset entry point annotation type; if so, marking the node as a business entry point node. For example, in the directed call graph, the OrderController class is annotated with @RestController and is identified as a business entry point node.

[0056] S123: Starting from the business entry node, traverse the directed call relationship graph, extract the node sequence that conforms to the preset call pattern, and obtain at least one call path.

[0057] The preset call pattern refers to a pre-defined call pattern that reflects the layered architecture of the business code. The call path refers to the sequence of nodes that conform to the preset call pattern, extracted by traversing the edges of the directed call relationship graph starting from the business entry node. The nodes in the call path are arranged sequentially according to the call order, reflecting the complete flow of the business request from the entry point to the final processing.

[0058] S124: Calculate the criticality score of each call path in at least one call path.

[0059] The criticality score measures the importance and representativeness of a call path. The higher the criticality score of a call path, the greater the likelihood that the call path is a core business processing path of the target code project.

[0060] S125: Select a preset number of call paths as critical call paths based on the criticality score of each call path in at least one call path.

[0061] The preset quantity refers to the number of critical call paths to be selected in advance. For example, the preset quantity can be 5, 6, 7, 8, 9, or 10, etc., and is not limited here. Critical call paths refer to the call paths selected from all call paths based on their criticality score. The method for selecting critical call paths can be as follows: select the preset number of call paths as critical call paths from all call paths in descending order of criticality score.

[0062] S126: Extract information of all class nodes on each key call path from the project structure file, and perform intelligent filtering to obtain the first batch of data.

[0063] Extracting information about all class nodes on each critical call path from the project structure file refers to retrieving detailed information about each class node on the selected critical call paths from the project structure file. This detailed information can include the class name, the package it belongs to, the class type, the methods and properties defined in the class, and the class's inheritance and implementation relationships.

[0064] Intelligent filtering refers to the filtering of extracted class node information, which can include deduplication and filtering of non-core classes. Deduplication means that when multiple critical call paths pass through the same class node, that class node is extracted only once to effectively avoid information duplication. Filtering of non-core classes means removing class node information identified as utility classes, constant classes, or pure configuration classes to reduce data volume.

[0065] In summary, the first batch of data obtained after key call path extraction and intelligent filtering significantly reduces the data volume compared to the original structured data. Taking a project with 137 classes as an example, the first batch of data may only include information on about 15 core classes, compressing the data volume from about 1.6MB to about 32KB, a compression ratio of about 2%. The first batch of data retains the complete information of core class nodes on the key call path while filtering out non-core class node information. This significantly compresses the data volume while ensuring the integrity of the core business link information, making it fully adaptable to the single input data volume limit of large language models, thus effectively avoiding the loss of key business call link information caused by direct truncation.

[0066] In one embodiment, such as Figure 4 As shown, step S123, which involves traversing the directed call relationship graph from the business entry node to extract a node sequence that conforms to the preset call pattern, and obtaining at least one call path, includes the following steps: S131: Starting from the business entry node, traverse along the edges of the directed call relationship graph.

[0067] Traversal refers to the process of moving from one node to another along the edges of a directed call graph. The starting node for traversal is the business entry node. A depth-first traversal can be used, starting from the business entry node and exploring as many nodes in the directed call graph as possible along a path until no further exploration is possible. When this point, the traversal backtracks to the previous node and continues exploring other paths. Depth-first traversal effectively extracts the complete call chain from the business entry node to the end node.

[0068] For example, starting from OrderController, a depth-first traversal is performed, visiting OrderController→OrderServiceImpl→OrderLogic in sequence. At the OrderLogic node, two outgoing edges are found, one pointing to InventoryLogic and the other to PaymentLogic. First, the traversal proceeds along the InventoryLogic direction, visiting InventoryLogic→OrderSal→OrderRpc. After reaching the terminal node, the traversal backtracks to OrderLogic. Then, the traversal proceeds along the PaymentLogic direction, visiting PaymentLogic→OrderSal→OrderRpc. Through this depth-first traversal, all paths leading to terminal nodes from OrderController are traversed.

[0069] S132: Identify the node sequence that matches the preset invocation pattern during the traversal. The preset invocation pattern is: starting from the business interface implementation class node, passing through the business logic processing class node, connecting to other logic or service class nodes, and then reaching the remote procedure call class node through the service aggregation layer class node.

[0070] Among them, business interface implementation class nodes refer to the concrete implementation classes that implement the business interface, usually named with the ServiceImpl suffix and annotated with @Service or injected into the controller by @Autowired. Business logic processing class nodes refer to the classes responsible for handling specific business logic, usually named with the Logic suffix. Other logic or service class nodes refer to other auxiliary logic classes or service classes that need to be called during business logic processing, including other Logic classes, cache service classes, etc. Service aggregation layer class nodes refer to the classes used to aggregate multiple service calls, usually named with the SAL suffix. Remote procedure call class nodes refer to the classes responsible for communicating with remote services, usually named with the RPC suffix or annotated with remote service call related annotations, interacting with external systems through the remote procedure call protocol. Node sequences that conform to the above node types and order are identified as conforming to the preset call pattern.

[0071] For example, the node sequence obtained through traversal is OrderController→OrderServiceImpl→OrderLogic→InventoryLogic→OrderSal→OrderRpc. Here, OrderController is the business entry point node, OrderServiceImpl is the business interface implementation class node, OrderLogic is the business logic processing class node, InventoryLogic is other logic or service class nodes, OrderSal is the service aggregation layer class node, and OrderRpc is the remote procedure call class node. This node sequence starts from the business interface implementation class node, connects to other logic or service class nodes via the business logic processing class node, and then reaches the remote procedure call class node via the service aggregation layer class node, conforming to the preset call pattern. Another node sequence obtained through traversal, OrderController→OrderServiceImpl→OrderLogic→PaymentLogic→OrderSal→OrderRpc, also conforms to the preset call pattern.

[0072] S133: Determine a call path for a sequence of nodes that conforms to the preset call pattern.

[0073] Each call path corresponds to a sequence of nodes that conforms to a preset call pattern, reflecting the complete business call chain from the business entry point to the final processing.

[0074] For example, OrderController→OrderServiceImpl→OrderLogic→InventoryLogic→OrderSal→OrderRpc is determined as path 1; and OrderController→OrderServiceImpl→OrderLogic→PaymentLogic→OrderSal→OrderRpc is determined as path 2. Thus, starting from the business entry node, through depth-first traversal, preset call pattern identification, and call path determination, at least one call path is obtained.

[0075] In one embodiment, such as Figure 5 As shown, step S125, which involves selecting a preset number of call paths as critical call paths based on the criticality score of each call path in at least one call path, includes the following steps: S1251: For each call path, a criticality score is obtained by weighting the following at least two factors: the number of nodes included in the call path, the total frequency of the edges on the call path appearing in the call relationship graph file, the degree of matching between the class node names on the call path and the preset core business keywords, and whether the call path constitutes a complete link from the business interface implementation class node to the remote procedure call class node.

[0076] The criticality score is a comprehensive score calculated by weighting multiple scoring factors. The number of nodes in the call path reflects the length of the call path; the more nodes, the longer the business process. The total frequency of edges appearing in the call relationship graph file reflects the frequency of use of the call relationship in the project; the higher the total frequency, the more frequent the calls. The matching degree between the class node names in the call path and the preset core business keywords measures whether the class node names in the call path include the preset core business keywords. These preset core business keywords can include "Order," "Payment," "User," "Product," "Inventory," "Transaction," and "Account."

[0077] In one possible implementation, the matching degree is quantified as the number of nodes matching the preset core business keyword among all class nodes on the call path divided by the total number of nodes. Whether the call path constitutes a complete link from the business interface implementation class node to the remote procedure call class node means that the starting node of the call path is the business interface implementation class node and the ending node is the remote procedure call class node. This factor is a binary indicator, with 1 for constituting and 0 for not constituting.

[0078] The criticality score can be calculated using a weighted average. Each scoring factor is assigned a weight coefficient, and the values ​​of each factor are multiplied by their respective weight coefficients and then summed. In one possible implementation, a weight of 0.2 is assigned to the number of nodes included in the call path, a weight of 0.3 is assigned to the total frequency of edges appearing in the call relationship graph file, a weight of 0.3 is assigned to the degree of matching between the class node names on the call path and preset core business keywords, and a weight of 0.2 is assigned to whether the call path constitutes a complete link from the business interface implementation class node to the remote procedure call class node.

[0079] For example, suppose three call paths are extracted. Path 1: OrderController→OrderServiceImpl→OrderLogic→InventoryLogic→OrderSal→OrderRpc. This call path includes 6 nodes, with a total frequency of 12+8+6+10+8=44. The matching degree is 100% (all class node names include the keywords "Order" or "Inventory"), forming a complete link (value 1). Overall score = 6×0.2+44×0.3+100%×0.3+1×0.2=1.2+13.2+0.3+0.2=14.9. Path 2: OrderController→OrderServiceImpl→OrderLogic→PaymentLogic→OrderSal→OrderRpc. This call path includes 6 nodes, with a total frequency of 12+8+5+10+8=43. The matching degree is 83% (5 / 6 matches), forming a complete link (value 1). Overall score = 6 × 0.2 + 43 × 0.3 + 83% × 0.3 + 1 × 0.2 = 1.2 + 12.9 + 0.249 + 0.2 = 14.549. Path 3: OrderController → OrderServiceImpl → OrderLogic → OrderSal → OrderRpc. The number of nodes in this call path is 5, the total frequency is 12 + 8 + 10 + 8 = 38, and the matching degree is 100% (all class node names contain the keyword "Order"), forming a complete link (value 1). Overall score = 5 × 0.2 + 38 × 0.3 + 100% × 0.3 + 1 × 0.2 = 1.0 + 11.4 + 0.3 + 0.2 = 12.9.

[0080] S1252: Select a preset number of call paths as critical call paths according to the criticality score from high to low.

[0081] For example, path 1 scores 14.9 points, path 2 scores 14.549 points, and path 3 scores 12.9 points. With a preset quantity of 2, path 1 and path 2 are selected as the critical call paths. By scoring and selecting based on criticality, the two most representative critical call paths are chosen from the three call paths, preserving the integrity of the core business chain while reducing interference from redundant paths.

[0082] In summary, steps S1251 to S1252 above achieve the selection of a preset number of key call paths based on the criticality score of each call path within at least one call path. This process uses multi-factor weighted calculation to comprehensively evaluate the number of nodes, call frequency, business keyword matching degree, and link integrity of each call path. This ensures that the selected key call paths have both long business processing flows and high call frequencies, while also being closely related to the core business and forming a complete closed loop. The criticality score uses a weighted calculation method, and the weight coefficients of different scoring factors can be adjusted according to the actual project type, enhancing the flexibility and applicability of the scoring. The selected key call paths accurately reflect the core business process of the target code project, ensuring that the first batch of data retains the complete semantics of the core business link while significantly compressing the data volume. This allows it to fully adapt to the single input data volume limitations of large language models, effectively avoiding the loss of key business call link information caused by direct truncation, and providing a reliable data foundation for the entire code analysis process.

[0083] In one embodiment, such as Figure 6 As shown, step S126, which involves extracting information on all class nodes along each key call path from the project structure file and performing intelligent filtering to obtain the first batch of data, includes the following steps: S1261: Extract information of all class nodes on each critical call path from the project structure file to obtain the first extraction result. When multiple critical call paths pass through the same class node, that class node is extracted only once.

[0084] The first extraction result refers to the set of basic information of all class nodes located on each critical call path, extracted from the project structure file. When multiple critical call paths pass through the same class node, the information of that class node is extracted only once.

[0085] For example, both path 1 (OrderController→OrderServiceImpl→OrderLogic→InventoryLogic→OrderSal→OrderRpc) and path 2 (OrderController→OrderServiceImpl→OrderLogic→PaymentLogic→OrderSal→OrderRpc) include OrderController and OrderServiceImpl, and after deduplication, they are extracted only once. The first extraction result includes: OrderController, OrderServiceImpl, OrderLogic, InventoryLogic, PaymentLogic, OrderSal, and OrderRpc.

[0086] S1262: Extract information about the direct dependent classes declared by dependency injection annotations on the class nodes on the key call path to obtain the second extraction result.

[0087] In this context, dependency injection annotations are used to declare dependencies between classes, including `@Autowired`, `@Reference`, and `@Resource`. Direct dependency classes are other classes declared using dependency injection annotations that are depended upon by class nodes on the critical call path. Although these direct dependency classes are not on the critical call path, their information needs to be preserved because they have direct dependencies on class nodes on the critical call path, ensuring the completeness of business logic analysis. The second extraction result refers to the set of information about the direct dependency classes declared by class nodes on the critical call path using dependency injection annotations.

[0088] For example, OrderLogic declares a dependency on the CacheService class using the @Autowired annotation. Although the CacheService class is not on the critical call path, as a direct dependency, its information is extracted into the second extraction result. The second extraction result includes: CacheService.

[0089] S1263: From the information set composed of the first extraction result and the second extraction result, filter out the information of class nodes identified as tool class, constant class or pure configuration class to obtain the first batch of data.

[0090] In this context, utility classes refer to classes that provide general utility methods, typically named with the suffixes "Utils" or "Helper". Constant classes refer to classes that only include constant definitions, typically named with the suffix "Constants". Pure configuration classes refer to classes used solely for framework configuration, typically annotated with the "@Configuration" annotation. Identifying whether a class is a utility class, constant class, or pure configuration class involves: analyzing the class's naming pattern, analyzing the types of methods and properties defined within the class, and analyzing the annotations on the class. From the information set composed of the first and second extraction results, the information of class nodes identified as utility classes, constant classes, or pure configuration classes is filtered out; the remaining information after filtering constitutes the first batch of data.

[0091] For example, StringUtils and DateUtils, included in the first extraction result, were identified as utility classes and filtered out. ErrorCodeConstants, also included in the information set, were identified as constant classes and filtered out. The first batch of filtered data included eight core classes: OrderController, OrderServiceImpl, OrderLogic, InventoryLogic, PaymentLogic, OrderSal, OrderRpc, and CacheService, totaling approximately 32KB of data.

[0092] In summary, steps S1261 to S1263 extract information from all class nodes on each critical call path in the project structure file and perform intelligent filtering to obtain the first batch of data. This process eliminates information redundancy when multiple critical call paths share the same class node through deduplication. By extracting information from directly dependent classes, it retains information about the key service classes that class nodes on critical call paths depend on, ensuring the integrity of business logic analysis. By filtering information from non-core business classes such as utility classes, constant classes, and pure configuration classes, it removes redundant information that contributes little to business logic analysis but occupies a large amount of data space. The first batch of data after intelligent filtering significantly reduces the amount of data compared to the original structured data, while fully retaining the information of key class nodes constituting the core business processing flow and their direct dependencies. The compressed first batch of data can fully adapt to the single input data volume limit of the large language model, effectively avoiding the loss of critical business call chain information caused by direct truncation.

[0093] In one embodiment, such as Figure 7 As shown, the relationship diagram file is generated in the following way: S201: Perform static syntax tree analysis on the source code files of the target code project to obtain the first type of relational information, which includes the basic structure information of classes and the inheritance and implementation relationships between classes.

[0094] Static syntax tree (STL) analysis refers to generating an abstract syntax tree (AST) from source code without running the code, and then extracting structural information from the AST. The process can be as follows: traverse the source code directory of the target code project, parsing each source code file one by one; perform lexical and syntactic analysis on the source code using a parser to generate an AST; traverse the AST to extract basic class structure information and inheritance and implementation relationships between classes; and summarize the extracted information to obtain the first type of relationship information.

[0095] For example, parsing the OrderController.java file, we extract the class name: OrderController, the package: com.example.order.controller, and the inheritance relationship: it inherits from BaseController. Parsing the OrderServiceImpl.java file, we extract the class name: OrderServiceImpl, and the implementation relationship: it implements the OrderService interface.

[0096] S202: Perform annotation scanning on the source code files to obtain the second type of relationship information, which includes the dependency relationships between classes declared by dependency injection annotations.

[0097] Annotation scanning refers to the identification and analysis of annotations used in source code files. The process can be as follows: after parsing the source code file to obtain the abstract syntax tree, traverse the annotation nodes in the abstract syntax tree and identify the dependency injection annotations (including @Autowired, @Reference, and @Resource); for each identified dependency injection annotation, extract the dependency relationships between the classes it declares; summarize all the extracted dependency relationships between classes to obtain the second type of relationship information.

[0098] For example, scanning the OrderLogic.java file identifies the @Autowired privateInventoryLogic inventoryLogic and extracts the dependency relationship between OrderLogic and InventoryLogic. Scanning the OrderSal.java file identifies the @Reference private OrderRpc orderRpc and extracts the dependency relationship between OrderSal and OrderRpc.

[0099] S203: Parse the original configuration file of the target code project to obtain the third type of relationship information, which includes the configuration-driven call relationship.

[0100] The original configuration file refers to the original configuration file existing in the source code of the target code project, which is different from the project configuration file. The process can be as follows: select the appropriate parser according to the format of the original configuration file; parse the configuration items in the original configuration file; extract the configuration information related to the call relationship from the configuration items; summarize the extracted configuration-driven call relationships to obtain the third type of relationship information.

[0101] For example, the dubbo.xml configuration file is parsed to extract the Dubbo service reference configuration, which indicates that there is a reference call relationship to the OrderRpc remote service in the project.

[0102] S204: Generate a calling relationship graph file based on the first type of relationship information, the second type of relationship information, and the third type of relationship information.

[0103] The fusion process can be as follows: Based on the basic structure information of classes in the first type of relationship information, determine all classes in the target code project; integrate the inheritance and implementation relationships between classes in the first type of relationship information, the dependency relationships between classes declared by dependency injection annotations in the second type of relationship information, and the call relationships driven by configuration in the third type of relationship information to determine whether there is a call relationship between any two classes and the direction of the call relationship; record all call relationships in a call relationship graph file in a unified format.

[0104] In summary, steps S201 to S204 above achieve the generation of the call relationship graph file. This process extracts basic class structure information and inheritance relationships from the source code through static syntax tree analysis, extracts dependency relationships declared by dependency injection annotations through annotation scanning, and extracts configuration-driven call relationships through configuration file parsing. These three methods independently obtain call relationship information between classes from different dimensions, forming multi-source data. When merging and generating the call relationship graph file, all classes are determined based on the first type of relationship information, and then the three types of relationship information are integrated. This allows the generated call relationship graph file to cover multiple call sources, including static code calls, framework auto-assembly, and configuration-driven calls. Compared with single-source call relationship extraction methods, it has higher completeness and accuracy, providing a data foundation for constructing directed call relationship graphs and extracting key call chains based on the call relationship graph file.

[0105] In one embodiment, the code analysis report generated for the target code project further includes: matching the code features, configuration patterns, call chain patterns, and exception patterns from the comprehensive analysis results with historical failure patterns stored in a pre-set failure pattern library; and supplementing the generated code analysis report with failure pattern reference information based on the matching results. Each historical failure pattern in the failure pattern library includes code features, configuration patterns, call chain patterns, exception patterns, and corresponding root cause analysis and remediation solutions. The matching is based on at least two dimensions of code pattern matching, configuration pattern matching, call chain pattern matching, and exception pattern matching. The similarity of each dimension is weighted and summed according to preset weights to obtain a comprehensive score. Historical failure patterns with similarity exceeding a preset threshold are selected based on the comprehensive score, and the root cause analysis and remediation solutions corresponding to the selected historical failure patterns are added to the code analysis report.

[0106] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic.

[0107] Secondly, embodiments of the present invention provide a code analysis device based on a large language model, which corresponds one-to-one with the code analysis method based on a large language model described in the above embodiments. For example... Figure 8 As shown, the code analysis device based on a large language model includes an acquisition module 301, an extraction module 302, a first processing module 303, a second processing module 304, a third processing module 305, a fourth processing module 306, and a generation module 307.

[0108] The acquisition module 301 is used to acquire the structured data of the target code project, the structured data including the project structure file, the call relationship diagram file, the project configuration file and the data operation file; Extraction module 302 is used to extract key call links based on the call relationship graph file and the project structure file to obtain the first batch of data; The first processing module 303 is used to input the first batch of data into a preset large language model, obtain a first analysis result, and save the first analysis result as the first batch of context information; The second processing module 304 is used to extract the configuration information in the project configuration file as the second batch of data, input the second batch of data into the large language model, obtain the second analysis result, and save the second analysis result as the second batch of context information. The third processing module 305 is used to load the first batch of context information, extract call relationship information from the call relationship graph file, construct a third batch of data based on the first batch of context information and the call relationship information, input the third batch of data into the large language model, obtain a third analysis result, and save the third analysis result as the third batch of context information. The fourth processing module 306 is used to extract the data operation information from the data operation file as the fourth batch of data, input the fourth batch of data into the large language model to obtain the fourth analysis result, and save the fourth analysis result as the fourth batch of context information. The generation module 307 is used to generate a code analysis report for the target code project based on the first batch of context information, the second batch of context information, the third batch of context information, and the fourth batch of context information.

[0109] In one embodiment, the extraction module 302 is further configured to: Based on the aforementioned call relationship graph file, a directed call relationship graph is constructed with classes as nodes and the call relationships between classes as edges; In the directed call relationship graph, classes with preset entry annotation types are identified as business entry nodes; Starting from the business entry node, traverse along the directed call relationship graph, extract the node sequence that conforms to the preset call pattern, and obtain at least one call path; Calculate the criticality score of each call path in the at least one call path; Based on the criticality score of each call path in the at least one call path, a preset number of call paths are selected as critical call paths; Information on all class nodes on each of the key call paths is extracted from the project structure file and intelligently filtered to obtain the first batch of data.

[0110] In one embodiment, the extraction module 302 is further configured to: Starting from the business entry node, traverse along the edges of the directed call relationship graph; During the traversal, a sequence of nodes that conforms to a preset calling pattern is identified. The preset calling pattern is: starting from a business interface implementation class node, passing through a business logic processing class node, connecting to other logic or service class nodes, and then passing through a service aggregation layer class node to reach a remote procedure call class node. The sequence of nodes that conforms to the preset calling pattern is determined as a calling path.

[0111] In one embodiment, the extraction module 302 is further configured to: For each of the aforementioned call paths, a weighted calculation is performed based on at least two of the following factors to obtain a criticality score for the call path: the number of nodes included in the call path, the total frequency of the edges on the call path appearing in the call relationship graph file, the degree of matching between the class node names on the call path and the preset core business keywords, and whether the call path constitutes a complete link from the business interface implementation class node to the remote procedure call class node. According to the criticality scores from high to low, a preset number of call paths are selected as the critical call paths.

[0112] In one embodiment, the extraction module 302 is further configured to: From the project structure file, extract the information of all class nodes on each of the key call paths to obtain the first extraction result. When multiple key call paths pass through the same class node, the class node is extracted only once. Extract the information of the direct dependent classes declared by the dependency injection annotation on the class nodes on the key call path to obtain the second extraction result; From the information set composed of the first extraction result and the second extraction result, filter out the information of class nodes identified as tool class, constant class or pure configuration class to obtain the first batch of data.

[0113] In one embodiment, the call relationship graph file is generated in the following manner: Static syntax tree analysis is performed on the source code file of the target code project to obtain the first type of relational information, which includes the basic structure information of classes and the inheritance and implementation relationships between classes. The source code file is annotated to obtain a second type of relationship information, which includes the dependency relationships between classes declared by dependency injection annotations. The original configuration file of the target code project is parsed to obtain a third type of relationship information, which includes configuration-driven call relationships. The call relationship graph file is generated based on the first type of relationship information, the second type of relationship information, and the third type of relationship information.

[0114] In one embodiment, the generation module 307 is further configured to: The first batch of context information, the second batch of context information, the third batch of context information, and the fourth batch of context information are integrated into the fifth batch of data; The fifth batch of data is input into the large language model to obtain comprehensive analysis results; Based on the comprehensive analysis results, a code analysis report for the target code project is generated; The data length of the fifth batch of data does not exceed the limit of the number of context tokens in a single batch of the large language model.

[0115] Specific limitations regarding the code analysis device based on large language models can be found in the limitations of the code analysis method based on large language models mentioned above, and will not be repeated here. Each module in the aforementioned code analysis device based on large language models can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0116] Thirdly, embodiments of the present invention provide a computer device, which may be a server, and its internal structure diagram may be as follows. Figure 9 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The database stores structured data, analysis results from a large language model, contextual information, etc. When executed by the processor, the computer program implements a code analysis method based on a large language model.

[0117] In one embodiment, a computer device is provided, including 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 steps of the code analysis method based on a large language model described in the above embodiments.

[0118] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the code analysis method based on a large language model described above.

[0119] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A code analysis method based on a large language model, characterized in that, include: Obtain the structured data of the target code project, including the project structure file, call relationship diagram file, project configuration file, and data operation file; Based on the call relationship graph file and the project structure file, key call links are extracted to obtain the first batch of data; The first batch of data is input into a preset large language model to obtain the first analysis result, and the first analysis result is saved as the first batch of context information; The configuration information in the project configuration file is extracted as the second batch of data. The second batch of data is input into the large language model to obtain the second analysis result, and the second analysis result is saved as the second batch of context information. Load the first batch of context information, extract call relationship information from the call relationship graph file, construct the third batch of data based on the first batch of context information and the call relationship information, input the third batch of data into the large language model, obtain the third analysis result, and save the third analysis result as the third batch of context information; Extract the data operation information from the data operation file as the fourth batch of data, input the fourth batch of data into the large language model to obtain the fourth analysis result, and save the fourth analysis result as the fourth batch of context information; Based on the first batch of context information, the second batch of context information, the third batch of context information, and the fourth batch of context information, a code analysis report for the target code project is generated.

2. The method according to claim 1, characterized in that, The extraction of key call chains based on the call relationship graph file and the project structure file yields the first batch of data, including: Based on the aforementioned call relationship graph file, a directed call relationship graph is constructed with classes as nodes and the call relationships between classes as edges; In the directed call relationship graph, classes with preset entry annotation types are identified as business entry nodes; Starting from the business entry node, traverse along the directed call relationship graph, extract the node sequence that conforms to the preset call pattern, and obtain at least one call path; Calculate the criticality score of each call path in the at least one call path; Based on the criticality score of each call path in the at least one call path, a preset number of call paths are selected as critical call paths; Information on all class nodes on each of the key call paths is extracted from the project structure file and intelligently filtered to obtain the first batch of data.

3. The method according to claim 2, characterized in that, The step of traversing the directed call graph starting from the business entry node and extracting a sequence of nodes that conform to a preset call pattern to obtain at least one call path includes: Starting from the business entry node, traverse along the edges of the directed call relationship graph; During the traversal, a sequence of nodes that conforms to a preset calling pattern is identified. The preset calling pattern is: starting from a business interface implementation class node, passing through a business logic processing class node, connecting to other logic or service class nodes, and then passing through a service aggregation layer class node to reach a remote procedure call class node. The sequence of nodes that conforms to the preset calling pattern is determined as a calling path.

4. The method according to claim 2 or 3, characterized in that, The step of selecting a preset number of call paths as critical call paths based on the criticality score of each call path in the at least one call path includes: For each of the aforementioned call paths, a weighted calculation is performed based on at least two of the following factors to obtain a criticality score for the call path: the number of nodes included in the call path, the total frequency of the edges on the call path appearing in the call relationship graph file, the degree of matching between the class node names on the call path and the preset core business keywords, and whether the call path constitutes a complete link from the business interface implementation class node to the remote procedure call class node. According to the criticality scores from high to low, a preset number of call paths are selected as the critical call paths.

5. The method according to claim 2, characterized in that, The process of extracting information from all class nodes on each of the key call paths in the project structure file and performing intelligent filtering to obtain the first batch of data includes: From the project structure file, extract the information of all class nodes on each of the key call paths to obtain the first extraction result. When multiple key call paths pass through the same class node, the class node is extracted only once. Extract the information of the direct dependent classes declared by the dependency injection annotation on the class nodes on the key call path to obtain the second extraction result; From the information set composed of the first extraction result and the second extraction result, filter out the information of class nodes identified as tool class, constant class or pure configuration class to obtain the first batch of data.

6. The method according to claim 1, characterized in that, The call relationship graph file is generated in the following way: Static syntax tree analysis is performed on the source code file of the target code project to obtain the first type of relational information, which includes the basic structure information of classes and the inheritance and implementation relationships between classes. The source code file is annotated to obtain a second type of relationship information, which includes the dependency relationships between classes declared by dependency injection annotations. The original configuration file of the target code project is parsed to obtain a third type of relationship information, which includes configuration-driven call relationships. The call relationship graph file is generated based on the first type of relationship information, the second type of relationship information, and the third type of relationship information.

7. The method according to claim 1, characterized in that, The step of generating a code analysis report for the target code project based on the first batch of context information, the second batch of context information, the third batch of context information, and the fourth batch of context information includes: The first batch of context information, the second batch of context information, the third batch of context information, and the fourth batch of context information are integrated into the fifth batch of data; The fifth batch of data is input into the large language model to obtain comprehensive analysis results; Based on the comprehensive analysis results, a code analysis report for the target code project is generated; The data length of the fifth batch of data does not exceed the limit of the number of context tokens in a single batch of the large language model.

8. A code analysis device based on a large language model, characterized in that, include: The acquisition module is used to acquire the structured data of the target code project, which includes the project structure file, the call relationship diagram file, the project configuration file, and the data operation file. The extraction module is used to extract key call links based on the call relationship graph file and the project structure file to obtain the first batch of data; The first processing module is used to input the first batch of data into a preset large language model, obtain the first analysis result, and save the first analysis result as the first batch of context information; The second processing module is used to extract the configuration information in the project configuration file as the second batch of data, input the second batch of data into the large language model, obtain the second analysis result, and save the second analysis result as the second batch of context information. The third processing module is used to load the first batch of context information, extract call relationship information from the call relationship graph file, construct a third batch of data based on the first batch of context information and the call relationship information, input the third batch of data into the large language model, obtain a third analysis result, and save the third analysis result as the third batch of context information. The fourth processing module is used to extract the data operation information from the data operation file as the fourth batch of data, input the fourth batch of data into the large language model to obtain the fourth analysis result, and save the fourth analysis result as the fourth batch of context information. The generation module is used to generate a code analysis report for the target code project based on the first batch of context information, the second batch of context information, the third batch of context information, and the fourth batch of context information.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the code analysis method based on a large language model as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the code analysis method based on a large language model as described in any one of claims 1 to 7.

Images