Code generation method and electronic device

Abstract

The application discloses a code generation method and an electronic device. In response to a query request, a query text of the query request is parsed to obtain an initial query vector. Based on multi-dimensional index information, the initial query vector is subjected to multi-dimensional retrieval to obtain a candidate code element. When a total amount of codes of the candidate code element is greater than a preset context window threshold, the candidate code element is subjected to hierarchical clipping according to a dependency distance and an information density of each node in the candidate code element, to obtain a target code element. The dependency distance is used to represent a shortest path length between the node and each dependent element having a dependency relationship in a program dependency graph. The information density is used to represent a total number of dependent elements having a dependency relationship in the program dependency graph. The target code element is subjected to structured assembly, and the structured assembled target code element is processed through a target language model to obtain a target code text corresponding to the query request.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to code generation methods and electronic devices. Background Technology

[0002] With the rapid development of AI code generation technology, using large models to assist in code generation has become an important means to improve software development efficiency. Currently, commonly used code generation models have limited ability to understand the core features and unique syntax structure of the C language, and cannot accurately understand the unique syntax and dependencies of the code. In addition, the context window of the code generation model has a certain limit. A large number of code elements cannot be fully input into the model, and critical context information may be forced to be discarded due to window overflow, affecting the quality of the generated code. Summary of the Invention

[0003] This application provides a code generation method and an electronic device to at least address the problems in related technologies, such as the limited ability of code generation models to understand the core features and unique syntax of the C language, and the limited number of context windows in code generation models, which may force the discard of key context information due to window overflow.

[0004] This application provides a code generation method, including: In response to a query request, the query text of the query request is parsed to obtain an initial query vector, which includes at least a semantic vector and code entities. Based on multi-dimensional index information, the initial query vector is searched in multiple dimensions to obtain candidate code elements. The multi-dimensional index information includes: semantic vector index, symbol keyword index, and dependency structure index. When the total amount of code in the candidate code element is greater than a preset context window threshold, the candidate code element is layered and pruned according to the dependency distance and information density of each node in the candidate code element to obtain the target code element. The dependency distance is used to characterize the shortest path length between the node and each dependent element with a dependency relationship in the program dependency graph, and the information density is used to characterize the total number of dependent elements with a dependency relationship in the program dependency graph. The target code elements are structurally assembled, and the structured assembly of the target code elements is processed by the target language model to obtain the target code text corresponding to the query request.

[0005] This application also provides a code generation apparatus, including: The processing module is used to respond to a query request by parsing the query text of the query request to obtain an initial query vector, wherein the initial query vector includes at least: a semantic vector and code entities; The processing module is also used to perform multi-dimensional retrieval on the initial query vector based on multi-dimensional index information to obtain candidate code elements. The multi-dimensional index information includes: semantic vector index, symbol keyword index, and dependency structure index. The processing module is further configured to, when the total amount of code in the candidate code element is greater than a preset context window threshold, perform layered pruning on the candidate code element according to the dependency distance and information density of each node in the candidate code element to obtain the target code element. The dependency distance is used to characterize the shortest path length between the node and each dependent element with a dependency relationship in the program dependency graph, and the information density is used to characterize the total number of dependent elements with a dependency relationship in the program dependency graph. The processing module is further configured to perform structured assembly of the target code elements, and process the structured assembled target code elements through a target language model to obtain the target code text corresponding to the query request.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described code generation methods when executing the computer program.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described code generation methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described code generation methods.

[0009] This application addresses the following: In response to a query request, the query text is parsed to obtain an initial query vector, which includes at least a semantic vector and code entities. Based on multi-dimensional index information, the initial query vector is searched in multiple dimensions to obtain candidate code elements. The multi-dimensional index information includes a semantic vector index, a symbol keyword index, and a dependency structure index. When the total amount of code in the candidate code elements exceeds a preset context window threshold, the candidate code elements are tiered and pruned according to the dependency distance and information density of each node in the candidate code elements to obtain target code elements. The dependency distance is used to characterize the shortest path length between a node and each dependent element with a dependency relationship in the program dependency graph, and the information density is used to characterize the total number of dependent elements with a dependency relationship in the program dependency graph. The target code elements are then structurally assembled, and the structured target code elements are processed using a target language model to obtain the target code text corresponding to the query request. This approach employs a multi-dimensional retrieval system, enabling the retrieval process to accurately understand the unique syntax and dependency information of the C language. Furthermore, within a limited context window, candidate code is categorized and pruned based on dependency distance and information density. This approach prioritizes the integrity of core code while filtering out less important code, effectively improving the accuracy and quality of the final code results. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the 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.

[0011] Figure 1 A flowchart of a code generation method provided in this application embodiment Figure 1 ; Figure 2 A flowchart of a code generation method provided in this application embodiment Figure 2 ; Figure 3 A structural diagram of a code generation apparatus provided in an embodiment of this application; Figure 4 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] In the server storage field, with the widespread adoption of relevant protocols, the ability of solid-state drives (SSDs) to complete over 1 million read / write requests per second in typical random read / write scenarios, and the exponential improvement in hardware performance, the underlying storage software has become a core technological bottleneck determining the overall I / O performance and data reliability of the system. Core storage software modules such as caching algorithms, device drivers, RAID implementation, erasure coding calculation, and snapshot management have extremely stringent requirements for code correctness, reliability, and performance under extreme scenarios. These modules are typically developed using C / C++ to fully leverage hardware performance, achieve efficient management of underlying resources, and precisely control memory layout.

[0015] In recent years, with the rapid development of AI code generation technology, using large models to assist in code generation has become an important means of improving software development efficiency. For example, a basic paradigm for directly generating code can be achieved using large language models. Developers input their code generation requirements in the form of natural language descriptions into the LLM model, which, based on the code knowledge acquired during its pre-training phase, directly generates corresponding code snippets or function implementations. In practical applications, to provide more background information, developers may include a small amount of relevant code snippets or brief project descriptions in the prompts, or fine-tune the model based on domain data; however, the core still relies on the model's own code understanding and generation capabilities.

[0016] However, the pre-training corpora of these code generation models primarily consist of high-level languages ​​such as Python and Java, with a relatively low proportion of C / C++ data. This results in significant limitations in their understanding of core C language features such as pointer arithmetic, manual memory management, complex macro definitions, conditional compilation, and bit-field operations. Furthermore, server storage software has evolved over decades, with codebases typically reaching millions to tens of millions of lines. These codebases contain numerous project-specific data structures, macro definitions, API conventions, and domain knowledge. General pre-training knowledge from the model is insufficient to cover these highly specialized private implementation details. Adapting through fine-tuning requires building large-scale, high-quality training data, incurring high computational and time costs. Moreover, each project iteration or new project launch necessitates re-fine-tuning, hindering its widespread application in actual R&D. Additionally, submitting code containing core business secrets to external LLM services poses serious security risks and the risk of intellectual property leakage. Even with private deployment, the model's global understanding of large codebases remains limited, making it difficult to accurately grasp complex dependencies across files.

[0017] To address the issue of insufficient adaptability of models to project-specific knowledge, Retrieval-Augmented Generation (RAG) technology has been introduced into the field of code generation. Its core idea is to retrieve code snippets relevant to the current task from the existing codebase during code generation as context, helping the model understand the project's unique coding conventions and dependencies, thereby generating code that better reflects the project's reality. For this purpose, a general-purpose code generation RAG system based on vector retrieval can be introduced. The codebase is divided into multiple code blocks (e.g., functions, classes as units), which are then converted into vectors through an embedding model and stored in a vector database. When a user submits a request, the query statement is also converted into a vector, and the K most similar code blocks are retrieved from the database as context, submitted along with the query to the LLM to generate code.

[0018] However, most existing general RAG solutions treat code as plain text and flatten it, severely neglecting the inherent structural characteristics and complex compilation dependencies of C language code. Vector similarity is based on semantics and cannot accurately express compilation-level constraints such as precise type matching, leading to technical bottlenecks such as low retrieval quality, poor context utilization, and low compilability of generated code. Furthermore, existing LLMs have fixed-length limitations on their context windows (e.g., 4K, 8K, 32K tokens), while server-stored software code repositories are large and easily exceed these window limits. Existing methods typically employ simple truncation strategies, concatenating multiple retrieved code blocks before input, which also results in a large amount of irrelevant or low-relevance context crowding out valuable window space. This not only increases computational costs but may also introduce noise that interferes with model generation. Additionally, the critical context information forced to be discarded due to window overflow directly leads to low-quality generated code. Moreover, using functions or files as the retrieval granularity fails to handle the complex cross-file dependencies in C language. In storage software development, the correct implementation of a function often depends on type definitions, macro definitions, structure declarations, and function prototypes in multiple header files. Coarse retrieval granularity leads to broken dependency chains and low compilation success rate of generated code.

[0019] In related technologies, compiler front-ends can be used to perform syntax and dependency analysis on code, constructing abstract syntax trees, symbol tables, or call graphs for code search, understanding, and quality analysis. However, these tools are primarily used for code understanding, search, and quality checking; their output (such as AST nodes and dependency lists) is not in a context format designed for LLM generation tasks and cannot be directly used to assist code generation. These technologies exist in isolation, not integrated with LLM generation capabilities, and cannot leverage their analysis results to enhance the accuracy and dependency completeness of code generation. Structure-matching-based searches rely on precise symbol names, failing to understand the user's natural language query intent and making it difficult to map user needs to specific code elements. While existing tools can construct ASTs and basic call graphs, their ability to trace deep semantic relationships unique to the C language, such as macro expansion chains, conditional compilation branch dependencies, and type alias passing, is limited.

[0020] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] like Figure 1 As shown, Figure 1 A flowchart of a code generation method provided for embodiments of this application, the code generation method may include the following steps: 101. In response to the query request, the query text of the query request is parsed to obtain the initial query vector.

[0022] In this embodiment of the application, the query request may be a query request initiated by a user. The query text of the query request may be natural language text input by the user. Of course, the user may also input a code snippet, etc. There is no restriction on the form of the query text. After receiving the user's query request, the query text of the query request can be parsed to obtain an initial query vector. The initial query vector may include at least: semantic vector and code entity.

[0023] It should be noted that the semantic vector can be understood as directly understanding the semantics of the query text, and knowing what the query text is specifically saying; the code entity can be understood as the key nouns related to code in the query text, which can be extracted according to specific entity rules.

[0024] 102. Based on multi-dimensional index information, perform multi-dimensional retrieval on the initial query vector to obtain candidate code elements.

[0025] In this embodiment of the application, after obtaining the initial query vector, the initial query vector can be retrieved from multiple dimensions. The retrieval basis can be pre-constructed multi-dimensional index information, which can be index information pre-constructed from multiple dimensions based on the code files stored in the code library. The multi-dimensional index information can include: semantic vector index, symbol keyword index, and dependency structure index.

[0026] It should be noted that the multi-dimensional retrieval here can be understood as the pre-construction of three-dimensional index information. This allows for the retrieval of the initial query vector within each dimension of the index information, which is equivalent to performing a three-level retrieval on the initial query vector. Each level of retrieval can obtain some candidate code elements, thus obtaining the candidate code elements corresponding to the initial query vector. There is no limit to the number of these candidate code elements. These candidate code elements can be considered as code elements that exist in the multi-dimensional index information and have a high degree of similarity to the initial query vector.

[0027] 103. When the total amount of code in the candidate code elements exceeds the preset context window threshold, the candidate code elements are layered and pruned according to the dependency distance and information density of each node in the candidate code elements to obtain the target code elements.

[0028] In this embodiment, the code elements ultimately need to be input into the LLM model. Based on the input code elements, the LLM model generates code function implementations that conform to project specifications and compilation requirements. However, the context window of current LLM models usually has a limit on the total number of code elements. Since the code library of the server-stored software is quite large, usually including millions or even tens of millions of lines, the total amount of candidate code elements recalled during the retrieval phase often exceeds the carrying capacity of the LLM model's context window. Therefore, after obtaining the candidate code elements, if the total amount of candidate code elements is greater than the preset context window threshold, it means that these candidate code elements cannot be directly input into the LLM model. Therefore, it is necessary to prune the candidate code elements, which is equivalent to deleting some of the code elements. So, which code elements need to be retained and which can be deleted can be determined by first layering the candidate code elements according to the dependency distance and information density of each node in the candidate code elements. The candidate code elements in each layer correspond to different levels of importance. After layering, the candidate code elements in different layers can be pruned separately, thereby reducing the total amount of candidate code elements and obtaining the final target code element. This target code element can be considered as the code element that meets the carrying capacity of the LLM model's context window.

[0029] It should be noted that during the layered pruning process, dependency distance and information density can be used as the basis. The dependency distance can be used to characterize the shortest path length between a node and each dependent element in the program dependency graph, while the information density is used to characterize the total number of dependent elements in the program dependency graph.

[0030] In some embodiments, the program dependency graph can be a code dependency network pre-constructed based on code files in the code repository. It can be understood that the program dependency graph describes the dependencies between all code elements. A code element can be represented as a node in the program dependency graph, and each node will have at least one dependent element. Therefore, the total number of dependent elements with dependencies in the program dependency graph can be counted to obtain the information density. Then, the path length between each dependent element with a dependency relationship and the node is determined, and the shortest path length is determined as the dependency distance.

[0031] 104. The target code elements are structurally assembled, and the structurally assembled target code elements are processed through the target language model to obtain the target code text corresponding to the query request.

[0032] In this embodiment, after obtaining the target code elements, they need to be structurally assembled according to the cognitive characteristics of LLM and the task requirements of code generation to maximize the generation quality. LLM is the target language model. After the target code elements are structurally assembled, they can be input into the LLM. The target language model processes the structurally assembled target code elements. Based on the complete dependency context, target function signature and constraints provided in the structurally assembled target code elements, the target language model can generate a function implementation that conforms to the project specifications and compilation requirements, and output the target code text corresponding to the query request.

[0033] In this embodiment, in response to a query request, the query text of the query request is parsed to obtain an initial query vector, which includes at least a semantic vector and code entities. Based on multi-dimensional index information, the initial query vector is searched in multiple dimensions to obtain candidate code elements. The multi-dimensional index information includes a semantic vector index, a symbol keyword index, and a dependency structure index. When the total amount of code in the candidate code elements exceeds a preset context window threshold, the candidate code elements are tiered and pruned according to the dependency distance and information density of each node in the candidate code elements to obtain target code elements. The dependency distance is used to characterize the shortest path length between a node and each dependent element with a dependency relationship in the program dependency graph, and the information density is used to characterize the total number of dependent elements with a dependency relationship in the program dependency graph. The target code elements are structurally assembled, and the structured target code elements are processed by a target language model to obtain the target code text corresponding to the query request. This approach employs a multi-dimensional retrieval system, enabling the retrieval process to accurately understand the unique syntax and dependency information of the C language. Furthermore, within a limited context window, candidate code is categorized and pruned based on dependency distance and information density. This approach prioritizes the integrity of core code while filtering out less important code, effectively improving the accuracy and quality of the final code results.

[0034] like Figure 2 As shown, Figure 2 Another flowchart of the code generation method provided for embodiments of this application, the code generation method may further include the following steps: 201. Perform semantic analysis on the code elements and corresponding comment information in the code library to obtain the semantic vector index of the code elements.

[0035] In this embodiment of the application, during the process of pre-constructing multi-dimensional index information, a code-specific embedding model can be used to perform semantic analysis on the code elements in the code library and their associated annotation information to obtain the semantic vector index corresponding to the code elements in the code library.

[0036] In some embodiments, summary vectors and detailed vectors of code elements can also be generated, which can support retrieval at different granularities, and the semantic vector index, summary vector and detailed vector are all stored in the vector database to support efficient similarity retrieval.

[0037] 202. Extract symbol information from code elements and construct a symbol keyword index based on the symbol information and context position.

[0038] In this embodiment of the application, when constructing a symbol keyword index, the symbol information of code elements can be extracted first. This symbol information may include function names, variable names, macro names, type names, file names, etc. An inverted index is built for this symbol information, supporting prefix matching, suffix matching, and exact matching. The context and role of the symbol's appearance are recorded and stored in a traditional search engine to support fast text retrieval.

[0039] 203. Based on the target symbol table and program dependency graph, determine the dependencies and dependency strengths between code elements, and generate a dependency structure index based on the dependencies and dependency strengths.

[0040] In this embodiment of the application, when constructing the dependency structure index, the dependency relationships and dependency strengths between code elements can be determined based on the target symbol table and the program dependency graph. For any code element, there will be at least one dependent element with a dependency relationship, and this dependency relationship will also have a dependency strength. Therefore, the target symbol table and the program dependency graph can be stored as a graph-structured JSON file, recording file inclusion relationships, symbol definition relationships, function call relationships, type usage relationships, macro dependency relationships, and declaration and implementation relationships, etc., and defining the dependency strength and dependency type for each relationship; then, the dependency structure index can be generated based on the dependency relationships and dependency strengths.

[0041] In some embodiments, the target symbol table and the program dependency graph can both be generated in advance based on the code files in the code library. Specifically, before determining the dependencies and dependency strengths between code elements based on the target symbol table and the program dependency graph, and generating a dependency structure index based on the dependencies and dependency strengths, the process may further include: performing syntax analysis on each code file in the code library to obtain a code syntax tree; performing a post-order traversal on the code syntax tree to obtain symbol information, data type information, and scope chain in the code syntax tree; and generating a target symbol table based on the symbol information, data type information, and scope chain.

[0042] It's important to note that the codebase contains a large number of code files. To understand the content of each file, a syntax analysis can be performed. Specifically, the Clang compiler frontend can be used to perform deep syntax analysis on each code file in the codebase, generating an Abstract Syntax Tree (AST) containing complete syntactic information. The AST fully preserves the hierarchical structure and syntactic relationships of the code, including function definitions, type declaration scopes, control flow structures, and expression nesting levels. Unlike shallow parsing based on regular expressions or simple lexical analysis, the AST generated by Clang has compiler-level semantic accuracy and completeness. Each node in the AST corresponds to a code element.

[0043] Then, since C allows forward references (such as functions declared after being used), but the complete semantic information of a symbol can only be determined when traversing to its definition node, a post-order traversal can be used to perform deep semantic analysis by traversing the abstract syntax tree. Post-order traversal ensures that the semantic information of child nodes is processed before that of parent nodes, enabling parent nodes to perform type inference and dependency analysis based on the parsed semantics of child nodes. Specifically, the post-order traversal process may include the following steps: Step 1: Symbol Collection: Traverse all declaration class nodes in the AST (function declarations, variable declarations, type definitions, macro definitions, etc.), collect basic information about the symbols (name, category, definition location), and establish a preliminary mapping from symbol names to symbol entries. For symbols with duplicate definitions (such as macros with the same name inside and outside conditional compilation branches), record all definition variants and their valid conditions.

[0044] Step Two: Type Resolution: After symbol collection is complete, the expression and statement nodes of the AST are traversed a second time to resolve the data type of the symbols referenced in each expression, establishing a mapping from type usage relationships to type definition relationships. For pointer type expressions, the base type it points to is recorded; for function call expressions, the matching relationship between the actual parameter types and the formal parameter types is recorded.

[0045] Step 3: Scope Binding: The scope structure of the AST is traversed for the third time (file scope, function scope, block scope), binding each symbolic reference to the nearest definition on its visible scope chain, establishing a precise binding relationship between symbolic references and symbolic definitions. For symbolic references that cross scopes (such as global variables referenced within a function, or external functions referenced within a block), their scope crossing paths are recorded.

[0046] Through the above steps, we can obtain the symbol information, data type information, and scope chain in the code syntax tree, thereby generating the target symbol table, which can include the following information: (1) Header file inclusion relationship: Record the header file chain that each file directly and indirectly includes, as well as the inclusion order.

[0047] (2) Function definition and declaration: Record the function name, return type, parameter list (including parameter type and name), function body location, declaration location, storage class (static / extern / inline, etc.), and calling convention attributes.

[0048] (3) Global variables and static variables: record variable name, data type, initial value, definition location, scope, and storage type.

[0049] (4) Macro definition and preprocessing directives: Record the macro name, macro body content, parameter list (for functional macros), definition location, expansion level, and the location and nesting relationship of conditional compilation directives such as #include, #ifdef, #ifndef, #else, #elif, and #endif.

[0050] (5) Structure / Union / Enumeration definition: record type tag, member list (including member type, name, bit field width), definition position, forward declaration chain.

[0051] (6) Type definition (typedef): Records the type alias, primitive type, definition location, and the passing relationship of the typedef chain.

[0052] In some embodiments, before determining the dependencies and dependency strengths between code elements based on the target symbol table and the program dependency graph, and generating a dependency structure index based on the dependencies and dependency strengths, the method may further include: traversing symbol reference records in the target symbol table and assigning type dependency labels to directed edges corresponding to symbol reference relationships; determining the code blocks corresponding to control statements based on control statements in the code syntax tree, and determining the control dependency labels of the symbols corresponding to the code blocks; traversing header file inclusion relationships and creating file dependency labels based on the definition positions in the included files and the reference positions in the included files; and creating a program dependency graph based on type dependency labels, control dependency labels, and file dependency labels.

[0053] It should be noted that after obtaining the target symbol table, it is also necessary to construct a Program Dependence Graph (PDG) oriented towards the characteristics of C language storage software. This PDG is a graph structure used to represent the data and control dependencies of the code. The PDG can include four basic dependencies and three C language-specific dependencies. Specifically, basic dependencies can include control dependencies, data dependencies, type dependencies, and file dependencies; C language-specific dependencies can include macro expansion dependencies, dependencies within conditional compilation blocks, and dependencies on pointer indirect access to structure members.

[0054] Among them, control dependencies record the control relationship between conditional statements (if / switch) and loop statements (for / while / do-while) and the execution of internal code; data dependencies record the def-use chain between variable definition and usage, including stream dependencies, anti-dependencies, and output dependencies; type dependencies record the dependency relationship between type definition and type usage, including structure definition and member access, typedef definition and type reference; and file dependencies record the inclusion relationship between source files and header files, as well as the symbol propagation path introduced by header file inclusion.

[0055] Additionally, macro expansion dependencies: This involves tracking the symbolic reference relationships after macro definitions have undergone multiple levels of expansion. In C language storage software, numerous type names and constants are derived through macro definitions (such as `#define SECTOR-SIZE(1<<12)`, `#define container_of(ptr, type, member)`, etc.). The system records the symbolic dependencies at each level of the macro expansion chain to ensure that macro definitions are correctly recalled. Specifically, the system analyzes each macro definition body, identifies other macro names, type names, and symbol names referenced within it, constructs a macro expansion tree, and records the hierarchical reference relationships and expansion order constraints between macros.

[0056] Conditional compilation block dependencies: Identifies symbol dependencies within code blocks enclosed by conditional compilation directives such as `#ifdef`, `#ifndef`, and `#if defined`. In cross-platform storage software, conditional compilation is widely used for operating system adaptation (e.g., Linux / Windows kernel interface differences), hardware feature switching, and debugging function control. It records the predicate conditions, nesting level, symbols defined within the block, and their references to external symbols for each conditional compilation block, ensuring correct symbol visibility in the generated code under a specific compilation configuration.

[0057] Pointer indirect access to structure members: Tracing the type dependency chain of indirect access to structure members via pointers. In storage software, many operations call callback functions through function pointers and access nested structures through pointers. Analyze the structure definition pointed to by the pointer type, the types of the accessed member fields, and the type conversions involved (void). (Convert to a pointer to a specific type) to build a complete type dependency chain.

[0058] In some embodiments, the PDG construction process can employ an incremental graph construction method, which may specifically include the following steps: Step 1: Traverse all symbol reference records in the symbol table. For each "definition-reference" relationship, create a directed edge in the PDG, with the starting point of the edge being the code element where the reference is located and the ending point being the code element where the definition is located. Simultaneously, assign an initial dependency type label to the edge based on the reference method (direct reference, indirect reference, conditional reference).

[0059] Step 2: Based on the control flow structure in the AST, analyze the scope of influence of each control predicate condition on the execution of the internal code. For the conditional expression in the control predicate, if it contains symbol references, create a control dependency edge between the code block referencing the condition and the referenced symbol.

[0060] Step 3: Traverse header file inclusion relationships. For symbol definitions included through header file inclusion, create file dependency edges between the definition location in the included file and the reference location in the including file. For indirect inclusions (e.g., A includes B, B includes C, then A indirectly includes symbols in C), calculate indirect file dependency edges using transitive closures to ensure the integrity of cross-file dependencies.

[0061] Step 4: Based on the basic dependency edges, perform specialized dependency edge identification and supplementation for three C language-specific scenarios: macro expansion, conditional compilation, and pointer indirect access.

[0062] In some embodiments, the dependencies and dependency strengths between code elements are determined based on the target symbol table and the program dependency graph. Specifically, this may include: determining the dependent elements that have dependencies on the code elements based on the target symbol table and the program dependency graph, thereby obtaining at least one dependency relationship corresponding to the code element; and determining the dependency strength between the code element and the dependent elements based on the dependency chain length, compilation importance, semantic coupling degree, and dependency chain usage frequency between the code element and the dependent elements.

[0063] It should be noted that after obtaining the target symbol table and program dependency graph, we can first identify the dependent elements that have a dependency relationship with each code element, and then assign a dependency strength to each dependency relationship. Specifically, we can combine four factors, namely dependency chain length, compilation necessity, semantic coupling, and usage frequency, to assign a dependency strength value in the range of 0-1 to each edge. For example, the shorter the dependency chain length, the higher the dependency strength; the stronger the compilation necessity, the higher the dependency strength, as the lack of this dependency will cause compilation failure; semantic coupling can measure the tightness of the binding between the two nodes of the edge in terms of business semantics and logical functions, and the higher the semantic coupling, the higher the corresponding dependency strength; the higher the usage frequency, the higher the corresponding dependency strength.

[0064] In some embodiments, the original C language codebase is transformed into a multi-dimensional knowledge base rich in structured information and capable of efficient retrieval. Through compiler-level deep syntactic and semantic analysis, three interconnected indexes are constructed: a semantic vector index, a symbol keyword index, and a dependency structure index. This fundamentally solves the problems of low retrieval quality and incomplete dependency recall caused by a lack of structured awareness. Furthermore, a target symbol table and a program dependency graph are constructed, converting the relationships between code elements into a graph structure that is clearer and more intuitive.

[0065] 204. Use a code semantic embedding model to perform semantic transformation on the query text to obtain a semantic vector.

[0066] In this embodiment of the application, the query text of the query request can be parsed at multiple levels, and the query text can be converted into a semantic vector through a code-specific embedding model for subsequent semantic similarity retrieval.

[0067] 205. Entity recognition is performed on the query text using regular expression rules to obtain the initial entity text.

[0068] 206. Based on the pre-stored target symbol table, perform matching processing on the initial entity text to obtain the code entity.

[0069] In this embodiment, key code entity names can be extracted from the query text. A method combining rule matching and pattern recognition is used to identify function names, type names, macro names (all uppercase mode or known name mode), and file names based on regular expressions. Entity disambiguation is performed based on prefix / suffix matching of the bullet point table to avoid confusion between different functions with the same name. A candidate list for each identified entity is recorded to obtain the initial entity text.

[0070] In some embodiments, in addition to extracting the semantic vectors and code entities mentioned above, intent recognition can also be performed: classifying the task type of the query request to identify whether it belongs to new feature implementation, code repair, performance optimization, or API call example generation. The recognition results are used to guide subsequent retrieval strategy selection and L1 core layer location. Additionally, constraint recognition can be performed: identifying constraints in the query to guide subsequent Prompt template filling and code generation stages, mainly including coding style constraints and performance constraints. Coding style constraints can include function naming conventions, indentation style, and comment format, constrained in a predefined markdown file format. Performance constraints can include time complexity requirements, space complexity requirements, zero-copy requirements, and lock granularity requirements.

[0071] 207. Based on the semantic vector index, perform semantic retrieval on the semantic vector to obtain the first candidate code.

[0072] In this embodiment, since the multi-dimensional index information includes multiple layers of indexes, initial query vectors can be used for retrieval. First, a first-stage semantic retrieval can be performed. Specifically, based on vector similarity, Top-K (e.g., K=100) candidate codes are recalled from the semantic vector index. Summary vectors are used for rapid initial screening, followed by detailed vector sorting. The advantage of semantic retrieval lies in its ability to understand the semantic intent of the query and recall functionally relevant code elements whose symbol names may not precisely match.

[0073] 208. Based on the symbol keyword index, keyword retrieval is performed on the code entities to obtain the second candidate code.

[0074] In this embodiment of the application, the second stage can perform keyword retrieval, and based on the code entities extracted from the entities, perform precise matching and filtering in a pre-built symbol keyword index.

[0075] In some embodiments, keyword retrieval is performed on code entities based on symbol keyword indexing to obtain a second candidate code. Specifically, this may include: determining the confidence level corresponding to each code entity; when the confidence level of the first code entity is greater than a preset confidence threshold, keyword retrieval is performed on the first code entity based on symbol keyword indexing to obtain a second full candidate code, the second full candidate code including the definition or declaration of the first code entity; when the confidence level of the second code entity is less than or equal to a preset confidence threshold, keyword retrieval is performed on the second code entity based on symbol keyword indexing to obtain a second symbol candidate code, the second symbol candidate code including the symbol of the second code entity; and a second candidate code is obtained based on the second full candidate code and the second symbol candidate code.

[0076] It should be noted that for code entities with different confidence levels, different content of the code entity can be retained. For high-confidence entity recognition results (confidence > 0.8), the candidate code must contain the definition or declaration of the code entity. For results with medium confidence levels (0.5 < confidence ≤ 0.8), they are included in the ranking as a bonus item, and only the symbol of the code entity can be retained. Keyword retrieval ensures the accurate hit of the core symbol, making up for the shortcomings of pure semantic retrieval that may miss the precise type match.

[0077] 209. Based on the first and second candidate codes, perform graph traversal expansion processing in the dependency structure index to obtain the third candidate code.

[0078] In this embodiment of the application, after performing semantic search and keyword search, candidate code can be further filtered based on the search results of the two stages. It can be understood that the number of code files stored in the code library is very large, and the number of first and second candidate codes obtained through semantic search and keyword search is still very large. Therefore, a third candidate code can be obtained by filtering from the first and second candidate codes based on the dependency structure index.

[0079] In some embodiments, based on the first candidate code and the second candidate code, a graph traversal expansion process is performed in the dependency structure index to obtain the third candidate code. Specifically, this may include: extracting code symbols contained in the first candidate code and the second candidate code; and traversing the compilation dependencies and semantic enhancement dependencies in the dependency structure index with the code symbols as the starting position to obtain the third candidate code.

[0080] It should be noted that for the first candidate code obtained from semantic retrieval and the second candidate code obtained from keyword retrieval, the graph traversal expansion is performed in the dependency structure index using the symbols they contain as anchor points: starting from each anchor point symbol, a breadth-first search is performed along the program dependency graph, and the search depth is dynamically adjusted according to the task type; compilation-necessary dependencies (type definitions, function declarations) are expanded first, followed by semantically enhanced dependencies (implementation references, similar patterns); macro definition chains are traced upwards along the macro expansion tree, active code paths under the current configuration are identified in the conditional compilation graph, and structure member definitions are traced along the pointer type chain.

[0081] 210. Merge the first candidate code, the second candidate code, and the third candidate code to obtain candidate code elements.

[0082] In this embodiment of the application, after the retrieval in all three stages is completed, the retrieval results of the three stages can be merged, that is, the first candidate code, the second candidate code and the third candidate code can be merged to obtain the final candidate code element.

[0083] In some embodiments, the fusion process can be understood as a weighted summation, fusing the first candidate code, the second candidate code, and the third candidate code to obtain candidate code elements. Specifically, it may include: performing type analysis on the query text to obtain the query type corresponding to the query text; determining the weight distribution corresponding to the query type according to the query type; calculating the fusion score of the first candidate code, the second candidate code, and the third candidate code according to the weight distribution, and determining the candidate code elements from the first candidate code, the second candidate code, and the third candidate code based on the fusion score.

[0084] It should be noted that in the weighted summation process, the semantic similarity, keyword matching degree, and dependency importance of each candidate code can be considered as being obtained in the three stages of retrieval. However, the weight of each parameter can be dynamically adjusted according to the query type of this query task. Therefore, the corresponding query type can be determined based on the query text, thereby determining the weight distribution. Then, the weighted summation is performed to obtain the fusion scores corresponding to the first, second, and third candidate codes respectively. After sorting the fusion scores, a certain number of candidate code elements with the highest scores are selected.

[0085] Furthermore, according to the weight distribution, the fusion scores of the first candidate code, the second candidate code, and the third candidate code are calculated separately. Specifically, this may include: determining and calculating the semantic similarity, keyword matching degree, and dependency importance of the first candidate code, the second candidate code, and the third candidate code respectively; and based on the weight distribution, weighted summing of the semantic similarity, keyword matching degree, and dependency importance to obtain the fusion score.

[0086] In some embodiments, the fusion score of the candidate code can be expressed as:

[0087] In some embodiments, when determining the weight distribution, when the query contains explicit code entities such as function names or type names (the average confidence level of entity recognition is higher than 0.7), the reliability of keyword retrieval is high. In this case, the keyword weight w2 is increased by 0.05-0.10, and the semantic weight w1 is decreased accordingly to enhance the influence of exact matching on the ranking results. Conversely, when the query is a pure natural language description (the average confidence level of entity recognition is lower than 0.3), the semantic weight w1 is increased by 0.05-0.10, and the keyword weight w2 is decreased accordingly to avoid missing relevant code blocks due to a lack of exact symbol matching.

[0088] In addition, when the ratio of the number of dependent elements recalled by structural retrieval to the number of elements recalled by semantic retrieval exceeds the threshold (ratio greater than 0.5), it indicates that the query involves a complex dependency chain. In this case, the dependency weight w3 is increased by 0.05-0.10 to enhance the guiding role of compilation completeness in ranking. Conversely, when the ratio is lower than the threshold (ratio less than 0.2), it indicates that the dependency relationship involved in the query is relatively simple. The dependency weight w3 is decreased to allocate more ranking influence to semantic quality and code quality.

[0089] When the retrieval task type is code repair, the code quality weight w4 is increased by 0.03-0.05 because the repair task has high requirements for code quality.

[0090] In some embodiments, the retrieval is performed in parallel from three dimensions: semantics, symbolic keywords, and dependency structure. The final candidate code element set is generated by a fusion ranking algorithm. The fusion ranking of the candidate codes ensures that the final candidate set simultaneously meets the requirements of semantic relevance, symbolic accuracy, and compilation completeness. In addition, the dynamic weight adjustment mechanism enables the fusion ranking to adapt to different query features and task scenarios, ensuring that the optimal candidate code ranking result can be generated under various conditions.

[0091] 211. Based on the code content of the candidate code elements, divide the candidate code elements into the core layer, the direct dependency layer, and the indirect reference layer.

[0092] In the embodiments of this application, the number of candidate code elements may be quite large. Some of these code elements may be only related but not necessary, so they can be appropriately discarded. However, some are core elements that cannot be deleted. Therefore, the candidate code elements can be divided into the core layer, the direct dependency layer, and the indirect reference layer.

[0093] In some embodiments, the core layer, or L1 layer, contains code elements directly related to the query and crucial to the generation task, serving as the core reference for generating the code. Specifically, it may include: The target function implementation or interface declaration explicitly mentioned in the query; The main code for generating tasks determined by intent identification (the current implementation of functions to be repaired, and the algorithm functions to be optimized); The code block that ranks 3-5 in semantic similarity to the query and is precisely matched by the keyword.

[0094] L1 layer code elements retain their complete content (including function body implementation and detailed comments), without collapsing any details. The token's proportion in the context window is 30%-40%.

[0095] In some embodiments, the direct dependency layer, or L2 layer, contains type definitions, function declarations, macro definitions, and global variables that the L1 layer code elements directly depend on for compilation and execution. This layer is crucial for ensuring that the generated code is compileable. Specifically, it includes: Prototype declarations of all functions that are called in L1 but not defined in L1; Full type definitions for all data structures (structures / unions / enumerations) used in L1 but not defined in L1; Complete definitions of all macros referenced in L1 but not defined in L1; Declarations of global and static variables used in L1; The definition of the type of the structure members accessed indirectly by pointers in L1; The definition of conditional compilation block predicate macros involved in L1.

[0096] L2 layer code elements retain complete interface signatures and type definitions, while function implementations only retain declarations (function name, return type, parameter list) and first-line comments (functional summary), collapsing function body implementation details. Token budget allocation is 40%-50%.

[0097] In some embodiments, the indirect reference layer, or L3 layer, contains task-related but not compilation-required implementation references, providing coding style references, algorithm implementation ideas, and design pattern guidance. Specifically, it includes: A reference implementation that is similar in function to the L1 layer code but is not directly called; Representative code snippets from similar modules or subsystems within the project; Search for the unit test code related to the task (as a reference for the functional specifications).

[0098] L3 code elements employ aggressive digestion, retaining only function signatures and single-line function descriptions. Structures retain member lists but omit comments, and macro definitions retain names and summaries of their expansion results. Token budget allocation is 10%-20%.

[0099] In some embodiments, the token ratio of the number of code elements in each of the three layers can be dynamically adjusted. Specifically, after dividing the candidate code elements into the core layer, the direct dependency layer, and the indirect reference layer according to the code content of the candidate code elements, it may also include: performing intent recognition on the query text to obtain the task type corresponding to the query text; and dynamically adjusting the number of code elements in the core layer, the direct dependency layer, and the indirect reference layer according to the task type.

[0100] It should be noted that the basis for adjusting the number of code elements in each layer can be the task type, similar to the process of adjusting the fusion weights mentioned earlier. The ratio of each layer can be dynamically adjusted according to the task type of intent recognition, for example: New features implemented: L1(35%)+L2(50%)+L3(15%), with sufficient dependency type definitions and interface declarations; Code fixes: L1(40%)+L2(45%)+L3(15%), preserving more target code context; Performance optimization: L1 (35%) + L2 (40%) + L3 (25%), increase the reference implementation ratio to obtain optimization ideas; API calls: L1(30%)+L2(50%)+L3(20%), maximizing interface declarations and type definitions.

[0101] In some embodiments, after the L1 / L2 / L3 code element partitioning is completed, the original code volume of each layer may still exceed the context window limit of the target language model. Therefore, a token budget adaptive adjustment mechanism can be adopted to dynamically allocate token usage for each layer, ensuring that critical information is retained preferentially.

[0102] First, based on the target LLM's context window size, 35% of the space is reserved for user queries and system commands, and the remaining 65% is allocated to the L1, L2, and L3 layers according to task type. Default allocation ratios for different task types are pre-configured; for example, for new feature implementations, L1 might allocate 35%, L2 50%, and L3 15%.

[0103] When the actual token usage of a certain layer exceeds its budget, the system dynamically compensates according to priority. L1 core layer has absolute priority: If L1 exceeds its limit, quota is borrowed from the L3 layer budget to ensure L1 is not pruned. L2 direct dependency layer: If L2 exceeds its limit and L1 is satisfied, dependencies with greater distance and not required for compilation are downgraded to summary form, and low-value elements are removed if necessary. L3 indirect reference layer is pruned last: If L3 exceeds its limit, function implementations retain only the signature and a one-line functional summary; structs retain the member list but remove comments; macro definitions retain the name and a summary of the expanded result.

[0104] In some embodiments, the budget usage, pruning status, and generation quality (compilation pass rate, functional correctness rate) of each generation task can be recorded. After offline analysis, the default allocation ratio and pruning threshold can be automatically adjusted to achieve optimal adaptation under different task types and model windows.

[0105] In some embodiments, after dividing the candidate code elements into a core layer, a direct dependency layer, and an indirect reference layer according to their code content, the method may further include: recursively expanding the candidate code elements according to the dependency graph and recording the initial access depth of each node; when a duplicate node is detected, determining the loop length between the current access depth and the initial access depth of the duplicate node; when the loop length is less than a preset length threshold, retaining the duplicate node and stopping the expansion process of the duplicate node; when the loop length is greater than or equal to the preset length threshold, pruning the dependency chain of the duplicate node.

[0106] It should be noted that for each candidate code element, a pre-built dependency graph index is used for recursive expansion to construct a complete dependency tree. The expansion process adopts a breadth-first strategy, capturing the code elements that the core code block depends on layer by layer until the preset maximum expansion depth is reached.

[0107] To address potential circular dependencies in the codebase, a depth-based tagging and loop-breaking mechanism can be introduced. During recursive expansion, the initial access depth of each visited code node is recorded. When a duplicate node is detected, the difference between the current depth and the initial access depth is calculated, representing the loop length. If the loop length is less than a preset threshold, it is considered a short loop; the node is retained, but expansion to its child dependencies is stopped to avoid infinite recursion. If the loop length is large, it is considered a long loop, and the branch is directly pruned to prevent redundant information from crowding the context window. This mechanism works in conjunction with a maximum expansion depth limit to ensure that the context building process always terminates in complex dependency networks, while preserving critical dependency information to the maximum extent possible.

[0108] 212. When the total amount of code in candidate code elements exceeds the preset context window threshold, determine the dependency distance and information density of each code element in the core layer, direct dependency layer, and indirect reference layer, respectively.

[0109] In this embodiment, when the total amount of code in the candidate code elements exceeds the preset context window threshold, the candidate code elements need to be pruned. Based on the three-layer structure, different pruning operations can be performed on each layer. Therefore, the dependency distance and information density of each code element in the core layer, direct dependency layer, and indirect reference layer can be determined separately.

[0110] It should be noted that dependency distance is used as the main pruning criterion. This dependency distance can be understood as the shortest path length from the L1 anchor point to each dependent element in the program dependency graph. Elements with larger dependency distances are more likely to be pruned or summarized.

[0111] It should be noted that an information density score is calculated for each candidate code element. Information density is equal to the ratio of symbol importance score to token usage, i.e., the symbol importance score carried by a unit token. Elements with low information density are preferentially pruned.

[0112] The symbol importance score is calculated by weighting the following factors: Dependency Graph Centrality Score: This calculates the centrality of a candidate code element in the program's dependency graph, which is the ratio of the number of the node's direct neighbors to its maximum degree in the graph. Candidate code elements with high centrality are typically hub nodes between modules (core data structure definitions, general utility functions), and their absence can cause a large amount of dependent code to fail to compile. The centrality score is obtained by multiplying the centrality by a weighting coefficient.

[0113] Interface definition identification score: If the candidate code element is an interface class definition such as a function declaration, struct definition, or macro definition (i.e., an element used by other code through referencing its symbol, rather than a local implementation used only internally), a fixed score of 0.4 is assigned; if it is a purely internal implementation element (such as a local variable or static function), a fixed score of 0.1 is assigned. This score is multiplied by a weighting coefficient.

[0114] The token usage refers to the number of tokens required after the code element is converted into text, which can be estimated based on the LLM's token rules.

[0115] 213. Based on dependency distance and information density, according to preset pruning rules, code elements in the direct dependency layer and indirect reference layer are pruned to obtain target code elements.

[0116] In this embodiment of the application, during the pruning process, code elements with a dependency distance of 1 can be retained and classified into the L2 layer; code elements with a dependency distance of 2 can be retained first and summarized when necessary; code elements with a dependency distance of 3 or above can be retained only when there is sufficient window space, and can be classified into the L3 layer first and summarized to the maximum extent.

[0117] In some embodiments, when a certain type of dependency (such as a specific header file or type definition) is frequently missing, directly causing errors in the generation of large model code and compilation failures, the priority score of this type of dependency in the L2 direct dependency layer will be automatically increased. Originally, the L2 layer sorted dependencies by fixed weights. Now, these frequently missing dependencies will be preferentially retained in the context, fundamentally preventing subsequent generated code from failing to compile due to the accidental removal of critical compilation dependencies.

[0118] In some embodiments, the number of candidates K returned by each retrieval path is dynamically adjusted based on context utilization and dependency completeness. Context utilization is the proportion of effective information actually used by the model within the context fed into the large model; dependency completeness is the coverage ratio of all dependencies required for code generation within the context. When context utilization remains low, it indicates that a large number of previously recalled semantic and symbolic retrieval results are redundant and invalid information. The initial recall quantity of semantic and keyword retrieval can be proactively reduced to lower subsequent pruning pressure and prevent invalid information from crowding out the token window. When dependency completeness is insufficient, it indicates that the currently recalled structural information is insufficient. The expansion depth and number of candidates in structural retrieval can be appropriately increased to supplement more related structural dependencies and complete the complete dependency chain required for code generation.

[0119] In some embodiments, the ratio of L2 / L3 layers is dynamically adjusted based on the generation success rate and context utilization. When the context window is small, the content of the L3 layer can be compressed first to ensure that all necessary compilation dependencies of the L2 layer are completely sent into the context, avoiding the complete failure of generation due to missing basic dependencies. When the generated code frequently shows inconsistent style or missing logic, the content ratio of the L3 layer can be appropriately increased, and more reference examples and coding style snippets from the same project can be injected to make the generated code more consistent with the original style of the project, and the logical integrity can also be improved.

[0120] In some embodiments, the pruning parameters, evaluation metrics, and generation results generated each time form a historical experience base. Once sufficient samples have been accumulated, the default parameter configuration of the pruning strategy can be optimized through offline analysis, enabling continuous iteration from experience to strategy.

[0121] In some embodiments, the server stores a large software codebase (typically millions to tens of millions of lines), and the total number of code elements recalled during the retrieval phase often far exceeds the capacity of the LLM context window. Therefore, the program dependency graph can be used as the basis for decision-making, and the retrieval results can be intelligently layered and pruned according to dependency distance and information density to ensure that the dependency information necessary for compilation is retained first. This allows for finding the optimal balance between pruning efficiency and generation quality in scenarios with different context window sizes and different project dependency complexities.

[0122] 214. The target code elements are structurally assembled, and the structurally assembled target code elements are processed by the target language model to obtain the target code text corresponding to the query request.

[0123] In some embodiments, the code elements, after hierarchical pruning and filtering, need to be structurally assembled according to the cognitive characteristics of LLM and the task requirements of code generation to maximize the generation quality. Specifically, role labeling can be performed first, marking the functional role of each code block in the generation task to help LLM understand the importance hierarchy and usage of code elements: [CORE_IMPL]: The main target code for the generated task. LLM should focus on its logical structure and coding style. [TYPE_DEF]: Data structure and type constraints that the generated code must follow. The LLM should strictly match its member definitions and type naming. [API_DECL]: External interfaces that the generated code needs to call or follow. The LLM should ensure that the function signature and parameter types are consistent. [REF_EXAMPLE]: Implementation ideas and coding patterns for LLM to learn from. LLM can refer to them flexibly but are not required to follow them.

[0124] Then, explicit dependency annotations can be performed, explicitly annotating the dependencies between code blocks in the Prompt, thus compensating for LLM's weak ability to perceive implicit dependencies in code.

[0125] In some embodiments, a corresponding Prompt template can be selected based on the intent recognition result. Each template consists of several predefined components, and is structured and populated based on the output of the layered cropping. For example: [System Role] Defines the role and function of the generated task; [Task Description] Please implement a new feature that meets the requirements based on the following project code context; [Dependency Type Definition] {L2 Layer Type Definition}; [Dependency Interface Declaration] {L2 Layer Function Declaration}; [Core Reference Implementation] {L1 Layer Core Code}; [Reference Example] {L3 Layer Reference Code}; [Requirement Description] {User Query}; [Constraints] {Identified constraint requirements}; [Output Requirements] Please generate complete C language implementation code, including necessary header file inclusions and error handling.

[0126] In some embodiments, the structured prompt words described above can be input into the target language model, which will then generate a function implementation that conforms to project specifications and compilation requirements based on the complete dependency context, target function signature, and constraints provided in the prompt words, thus obtaining the target code text.

[0127] Specifically, a target language model optimized for C / C++ can be used. This eliminates the need to rely on pre-trained knowledge to guess missing type definitions or function prototypes, instead generating the code directly based on accurate information from the context. This fundamentally avoids common errors such as "undefined identifier" and "type mismatch." After generation, code blocks are extracted from the model output and returned to the user as the final code result.

[0128] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0129] like Figure 3 As shown, embodiments of this application also provide a code generation apparatus, which may include: The processing module 301 is used to respond to the query request by parsing the query text of the query request to obtain an initial query vector, which includes at least a semantic vector and code entities. Processing module 301 is also used to perform multi-dimensional retrieval on the initial query vector based on multi-dimensional index information to obtain candidate code elements. The multi-dimensional index information includes: semantic vector index, symbol keyword index and dependency structure index. The processing module 301 is also used to perform layered pruning of the candidate code elements according to the dependency distance and information density of each node in the candidate code elements when the total amount of code of the candidate code elements is greater than the preset context window threshold, so as to obtain the target code elements. The dependency distance is used to characterize the shortest path length between the node and each dependent element with a dependency relationship in the program dependency graph, and the information density is used to characterize the total number of dependent elements with a dependency relationship in the program dependency graph. The processing module 301 is also used to perform structured assembly of target code elements, and to process the structured assembled target code elements through the target language model to obtain the target code text corresponding to the query request.

[0130] In some embodiments, the processing module 301 is specifically used to perform semantic transformation on the query text through a code semantic embedding model to obtain a semantic vector; Processing module 301 is specifically used to perform entity recognition on the query text using regular expression rules to obtain the initial entity text; The processing module 301 is specifically used to perform matching processing on the initial entity text based on the pre-stored target symbol table to obtain the code entity.

[0131] In some embodiments, the processing module 301 is further configured to perform semantic analysis on code elements and corresponding comment information in the code library to obtain the semantic vector index of the code element; The processing module 301 is also used to extract symbol information of code elements and construct a symbol keyword index based on the symbol information and context position; The processing module 301 is also used to determine the dependencies and dependency strengths between code elements based on the target symbol table and the program dependency graph, and to generate a dependency structure index based on the dependencies and dependency strengths.

[0132] In some embodiments, the processing module 301 is further configured to perform syntax analysis on each code file in the code library to obtain a code syntax tree; The processing module 301 is also used to perform a post-order traversal of the code syntax tree to obtain symbol information, data type information and scope chain in the code syntax tree; The processing module 301 is also used to generate a target symbol table based on symbol information, data type information, and scope chain.

[0133] In some embodiments, the processing module 301 is further configured to traverse the symbol reference records in the target symbol table and assign type dependency labels to the directed edges corresponding to the symbol reference relationships; The processing module 301 is also used to determine the code block corresponding to the control statement based on the control statement in the code syntax tree, and to determine the control dependency label of the symbol corresponding to the code block; Processing module 301 is also used to traverse header file inclusion relationships and create file dependency tags based on the definition position in the included file and the reference position in the included file; Processing module 301 is also used to create a program dependency graph based on type dependency tags, control dependency tags, and file dependency tags.

[0134] In some embodiments, the processing module 301 is specifically used to determine the dependent elements that have a dependency relationship with the code elements based on the target symbol table and the program dependency graph, and to obtain at least one dependency relationship corresponding to the code element. The processing module 301 is specifically used to determine the dependency strength between code elements and dependent elements based on the dependency chain length, compilation importance, semantic coupling degree, and dependency chain usage frequency between code elements and dependent elements.

[0135] In some embodiments, the processing module 301 is specifically used to perform semantic retrieval on the semantic vector based on the semantic vector index to obtain the first candidate code; Processing module 301 is specifically used to perform keyword retrieval on code entities based on symbol keyword indexing to obtain the second candidate code; The processing module 301 is specifically used to perform graph traversal expansion processing in the dependency structure index based on the first and second candidate codes to obtain the third candidate code. The processing module 301 is specifically used to merge the first candidate code, the second candidate code, and the third candidate code to obtain candidate code elements.

[0136] In some embodiments, the acquisition module 302 is used to determine the confidence level corresponding to each code entity; The processing module 301 is specifically used to perform keyword retrieval on the first code entity based on the symbol keyword index when the confidence of the first code entity is greater than the preset confidence threshold, and obtain the second full candidate code, which includes the definition or declaration of the first code entity. The processing module 301 is specifically used to perform keyword retrieval on the second code entity based on the symbol keyword index when the confidence of the second code entity is less than or equal to a preset confidence threshold, and to obtain the second symbol candidate code, wherein the second symbol candidate code includes the symbol of the second code entity; The processing module 301 is specifically used to obtain the second candidate code based on the second full candidate code and the second symbol candidate code.

[0137] In some embodiments, the acquisition module 302 is specifically used to extract code symbols contained in the first candidate code and the second candidate code; Processing module 301 is specifically used to traverse compilation dependencies and semantic enhancement dependencies in the dependency structure index, starting from the code symbol, to obtain the third candidate code.

[0138] In some embodiments, the processing module 301 is specifically used to perform type analysis on the query text to obtain the query type corresponding to the query text. The processing module 301 is specifically used to determine the weight distribution corresponding to the query type according to the query type; The processing module 301 is specifically used to calculate the fusion score of the first candidate code, the second candidate code, and the third candidate code according to the weight distribution, and to determine the candidate code element from the first candidate code, the second candidate code, and the third candidate code based on the fusion score.

[0139] In some embodiments, the acquisition module 302 is specifically used to determine the semantic similarity, keyword matching degree, and dependency importance of the first candidate code, the second candidate code, and the third candidate code, respectively. The processing module 301 is specifically used to perform a weighted summation of semantic similarity, keyword matching degree and dependency importance based on weight distribution to obtain a fusion score.

[0140] In some embodiments, the processing module 301 is specifically used to divide the candidate code elements into a core layer, a direct dependency layer, and an indirect reference layer according to the code content of the candidate code elements. The processing module 301 is specifically used to determine the dependency distance and information density of each code element in the core layer, direct dependency layer and indirect reference layer when the total amount of code of the candidate code elements is greater than the preset context window threshold. The processing module 301 is specifically used to prune code elements in the direct dependency layer and the indirect reference layer according to preset pruning rules based on dependency distance and information density, to obtain target code elements.

[0141] In some embodiments, the processing module 301 is further configured to perform intent recognition on the query text to obtain the task type corresponding to the query text; The processing module 301 is also used to dynamically adjust the number of code elements in the core layer, direct dependency layer and indirect reference layer according to the task type.

[0142] In some embodiments, the processing module 301 is further configured to recursively expand the candidate code elements according to the dependency graph and record the initial access depth corresponding to each node. The processing module 301 is also used to determine the loop length between the current access depth and the initial access depth of the duplicate node when a duplicate node is detected. The processing module 301 is also used to retain the duplicate node and stop the expansion processing of the duplicate node when the loop length is less than the preset length threshold. The processing module 301 is also used to trim the dependency chain of duplicate nodes when the loop length is greater than or equal to a preset length threshold.

[0143] For a description of the features in the embodiment corresponding to the code generation device, please refer to the relevant description in the embodiment corresponding to the code generation method, which will not be repeated here.

[0144] like Figure 4 As shown, embodiments of this application also provide an electronic device, including a memory 401 and a processor 402, wherein the memory 401 stores a computer program and the processor 402 is configured to run the computer program to perform the steps in any of the code generation method embodiments described above.

[0145] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the code generation method embodiments described above at runtime.

[0146] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0147] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the code generation method embodiments described above.

[0148] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the code generation method embodiments described above.

[0149] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, processors (CPUs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), microprocessors (MCUs), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0150] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0151] The code generation method and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A code generation method, characterized in that, include: In response to a query request, the query text of the query request is parsed to obtain an initial query vector, which includes at least a semantic vector and code entities. Based on multi-dimensional index information, the initial query vector is searched in multiple dimensions to obtain candidate code elements. The multi-dimensional index information includes: semantic vector index, symbol keyword index, and dependency structure index. When the total amount of code in the candidate code element is greater than a preset context window threshold, the candidate code element is layered and pruned according to the dependency distance and information density of each node in the candidate code element to obtain the target code element. The dependency distance is used to characterize the shortest path length between the node and each dependent element with a dependency relationship in the program dependency graph, and the information density is used to characterize the total number of dependent elements with a dependency relationship in the program dependency graph. The target code elements are structurally assembled, and the structured assembly of the target code elements is processed by the target language model to obtain the target code text corresponding to the query request.

2. The code generation method according to claim 1, characterized in that, In response to a query request, the query text of the query request is parsed to obtain an initial query vector, including: The query text is semantically transformed using a code semantic embedding model to obtain a semantic vector; The query text is used to perform entity recognition through regular expression rules to obtain the initial entity text; Based on the pre-stored target symbol table, the initial entity text is matched to obtain the code entity.

3. The code generation method according to claim 1, characterized in that, Before performing multi-dimensional retrieval on the initial query vector based on multi-dimensional index information to obtain candidate code elements, the method further includes: Semantic analysis is performed on code elements and their corresponding comment information in the code library to obtain the semantic vector index of the code element; Extract the symbol information of the code elements, and construct the symbol keyword index based on the symbol information and context position; Based on the target symbol table and the program dependency graph, the dependencies and dependency strengths between the code elements are determined, and the dependency structure index is generated based on the dependencies and dependency strengths.

4. The code generation method according to claim 3, characterized in that, Before determining the dependencies and dependency strengths between the code elements based on the target symbol table and the program dependency graph, and generating the dependency structure index based on the dependencies and dependency strengths, the method further includes: Syntax analysis is performed on each code file in the code library to obtain a code syntax tree; Perform a post-order traversal of the code syntax tree to obtain the symbol information, data type information, and scope chain in the code syntax tree; The target symbol table is generated based on the symbol information, the data type information, and the scope chain.

5. The code generation method according to claim 3, characterized in that, Before determining the dependencies and dependency strengths between the code elements based on the target symbol table and the program dependency graph, and generating the dependency structure index based on the dependencies and dependency strengths, the method further includes: Traverse the symbol reference records in the target symbol table and assign type dependency labels to the directed edges corresponding to the symbol reference relationships; Based on the control statements in the code syntax tree, determine the code block corresponding to the control statement, and determine the control dependency label of the symbol corresponding to the code block; Iterate through the header file inclusion relationships and create file dependency tags based on the definition location in the included file and the reference location in the including file; The program dependency graph is created based on the type dependency tag, the control dependency tag, and the file dependency tag.

6. The code generation method according to claim 3, characterized in that, The step of determining the dependencies and dependency strengths between code elements based on the target symbol table and the program dependency graph includes: Based on the target symbol table and the program dependency graph, the dependent elements that have a dependency relationship with the code element are determined, and at least one dependency relationship corresponding to the code element is obtained; The dependency strength between the code element and the dependent element is determined based on the dependency chain length, compilation importance, semantic coupling degree, and dependency chain usage frequency between the code element and the dependent element.

7. The code generation method according to claim 1, characterized in that, The step of performing a multi-dimensional search on the initial query vector based on multi-dimensional index information to obtain candidate code elements includes: Based on the semantic vector index, semantic retrieval is performed on the semantic vector to obtain the first candidate code; Based on the symbol keyword index, keyword retrieval is performed on the code entity to obtain the second candidate code; Based on the first candidate code and the second candidate code, a graph traversal expansion process is performed in the dependency structure index to obtain the third candidate code; The candidate code element is obtained by fusing the first candidate code, the second candidate code, and the third candidate code.

8. The code generation method according to claim 7, characterized in that, The step of performing keyword retrieval on the code entity based on the symbol keyword index to obtain the second candidate code includes: Determine the confidence level for each code entity; When the confidence level of the first code entity is greater than the preset confidence threshold, the first code entity is searched for keywords based on the symbol keyword index to obtain the second full candidate code, which includes the definition or declaration of the first code entity. When the confidence level of the second code entity is less than or equal to the preset confidence threshold, the second code entity is searched for keywords based on the symbol keyword index to obtain the second symbol candidate code, which includes the symbol of the second code entity; Based on the second full candidate code and the second symbol candidate code, the second candidate code is obtained.

9. The code generation method according to claim 7, characterized in that, The step of performing graph traversal expansion processing on the dependency structure index based on the first candidate code and the second candidate code to obtain the third candidate code includes: Extract the code symbols contained in the first candidate code and the second candidate code; Starting with the code symbol, the compiler dependencies and semantic enhancement dependencies are traversed in the dependency structure index to obtain the third candidate code.

10. The code generation method according to claim 7, characterized in that, The process of fusing the first candidate code, the second candidate code, and the third candidate code to obtain the candidate code element includes: Perform type analysis on the query text to obtain the query type corresponding to the query text; Determine the weight distribution corresponding to the query type according to the query type; According to the weight distribution, the fusion scores of the first candidate code, the second candidate code, and the third candidate code are calculated respectively, and the candidate code element is determined from the first candidate code, the second candidate code, and the third candidate code based on the fusion scores.

11. The code generation method according to claim 10, characterized in that, The step of calculating the fusion score of the first candidate code, the second candidate code, and the third candidate code according to the weight distribution includes: Semantic similarity, keyword matching degree, and dependency importance of the first candidate code, the second candidate code, and the third candidate code are determined and calculated respectively. Based on the weight distribution, the semantic similarity, the keyword matching degree, and the dependence importance are weighted and summed to obtain the fusion score.

12. The code generation method according to claim 1, characterized in that, When the total amount of code in the candidate code elements exceeds a preset context window threshold, the candidate code elements are layered and pruned according to the dependency distance and information density of each node in the candidate code elements to obtain the target code elements, including: Based on the code content of the candidate code elements, the candidate code elements are divided into a core layer, a direct dependency layer, and an indirect reference layer; When the total amount of code in the candidate code element is greater than the preset context window threshold, the dependency distance and information density of each code element in the core layer, the direct dependency layer and the indirect reference layer are determined respectively. Based on the dependency distance and the information density, the code elements in the direct dependency layer and the indirect reference layer are pruned according to the preset pruning rules to obtain the target code element.

13. The code generation method according to claim 12, characterized in that, After dividing the candidate code elements into a core layer, a direct dependency layer, and an indirect reference layer according to their code content, the method further includes: The query text is subjected to intent recognition to obtain the task type corresponding to the query text; The number of code elements in the core layer, the direct dependency layer, and the indirect reference layer are dynamically adjusted according to the task type.

14. The code generation method according to claim 12, characterized in that, After dividing the candidate code elements into a core layer, a direct dependency layer, and an indirect reference layer according to their code content, the method further includes: According to the dependency graph, the candidate code elements are recursively expanded, and the initial access depth of each node is recorded. When a duplicate node is detected, the loop length between the current access depth of the duplicate node and the initial access depth is determined. When the loop length is less than a preset length threshold, the repeated node is retained, and the expansion process of the repeated node is stopped; When the cycle length is greater than or equal to a preset length threshold, the dependency chain of the repeating node is pruned.

15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for implementing the steps of the code generation method as described in any one of claims 1 to 14 when executing the computer program.

Images