A method and device for constructing a calling instruction of a large language model

Abstract

This specification discloses a method and device for constructing invocation instructions for a large language model. By responding to a request to invoke code generation from the large language model, the AST structure and code editing location in the code editing environment are determined. Structured path information and semantic representation information of the code context are extracted. Then, a dual-track hybrid retrieval is performed in the decision memory node library based on a comprehensive matching degree of semantic similarity and structural feature matching. Finally, the large language model invocation instructions are constructed based on the selected decision memory nodes. This specification embodiment can accurately match architectural constraints through a dual-track hybrid retrieval of semantics and structure before the large language model generates code, and dynamically inject these constraints into the large language model invocation instructions, thereby guiding the large language model to generate code that conforms to the project architecture specifications, effectively solving the problem of architecture decision drift during the large language model code generation process.

Description

Technical Field

[0001] This disclosure relates to the field of software engineering technology, and in particular to a method and device for constructing calling instructions for a large language model. Background Technology

[0002] In software engineering scenarios, with the development of large language models, AI-assisted programming tools have been widely used in the field of code generation. Existing AI programming systems are mainly based on retrieval-enhanced generation technology, and their standard workflow is as follows: extract lexical fragments from the developer's current editor, search for similar code segments in the code library, merge the similar code with the user's prompts, and submit them to the large language model to generate new code.

[0003] In the face of the complex long-term evolution of enterprise software, the project specifications (such as system architecture and design patterns) set by the project leader need to be strictly adhered to. Therefore, there is a technical requirement in this scenario: when calling a large language model to generate code, it is necessary to accurately perceive the current context of the code and inject accurate normative constraints (such as architectural constraints) accordingly, so as to guide the large language model to generate code that conforms to the project specifications.

[0004] Therefore, a technical solution is needed that can inject context constraints when calling large language models to generate code. Summary of the Invention

[0005] This disclosure provides a method for constructing invocation instructions for a large language model, including:

[0006] In response to a request to invoke a large language model to generate code in a code editing environment, determine the abstract syntax tree (AST) structure in the code editing environment, and determine the code editing location specified in the request;

[0007] The code editing location is mapped to the leaf node of the AST structure, and the structured path information is extracted; wherein, the structured path information is used to record the declarative nodes and control flow nodes on the path from the leaf node to the root node of the AST.

[0008] Based on the code editing location, the code context is extracted to obtain the semantic representation information of the code context;

[0009] In the preset decision memory node library, for each decision memory node, the comprehensive matching degree is calculated based on the semantic similarity between the node-related semantic information of the decision memory node and the semantic representation information of the code context, and the determination result of whether the constraint triggering rule field of the decision memory node matches the structured path information; wherein, the calculation weight of semantic similarity is less than the calculation weight of the determination result.

[0010] Decision memory nodes are selected based on the comprehensive matching degree, and a large language model invocation instruction is constructed based on the selected decision memory nodes to invoke the large language model to generate code.

[0011] Optionally, determining the AST structure in the code editing environment specifically includes:

[0012] In the code editing environment, invoke the incremental parser to obtain the AST structure of the incremental code.

[0013] Optionally, the data structure of each decision memory node may also include at least one of the following fields:

[0014] Node basic metadata fields, node type fields, scope fields;

[0015] Among them, the node type field stores one of the following: design intent type, prohibition mode type, constraint condition type, and trade-off type;

[0016] The scope field stores the project file path range of the code files to which this decision memory node applies, and / or, a set of external dependency identifiers.

[0017] Optionally, the decision memory node library includes a directed acyclic graph database;

[0018] The method further includes:

[0019] In response to a decision update command, a decision memory node is added to the decision memory node library; wherein, if the newly added decision memory node has an overwrite relationship with at least one existing decision memory node, a directed edge is established from the at least one existing decision memory node to the newly added decision memory node.

[0020] Optionally, the decision update instruction is issued based on the iteration of project architecture decisions, the iteration including discarding existing decision memory nodes and / or making new decision memory nodes effective.

[0021] Optionally, the code editing environment includes a user-interactive code editing area;

[0022] Determining the code editing location specified in the request specifically includes:

[0023] Obtain the interaction location triggered by the request in the code editing area, and use it as the code editing location specified by the request.

[0024] Optionally, before extracting structured path information, the following steps are also included:

[0025] Determine whether the leaf nodes of the AST match the preset code risk structure rules;

[0026] If so, risk flag information is generated according to the matched code risk structure rules, and the risk flag information is added to the structured path information.

[0027] Optionally, the preset code risk structure rules include at least one of the following:

[0028] Whether it is in a loop, the depth of loop nesting, whether it is in a conditional branch, the depth of condition nesting, whether it is in an exception handling block, and whether it is in an asynchronous context.

[0029] Optionally, before obtaining the semantic representation information of the code context, the following steps are also included:

[0030] Based on the code editing location, extract the code context within a set capacity window;

[0031] Obtain the input user prompts, which are used to prompt the large language model to perform code-related tasks.

[0032] Based on the combination of the code context and the user prompt words, a comprehensive semantic representation information is generated;

[0033] The representation information corresponding to the code context is the comprehensive semantic representation information.

[0034] Optionally, before extracting structured path information, the following steps are also included:

[0035] Extract the project file path to which the current code file belongs, and / or extract the external dependency identifiers in the declaration of the current code file;

[0036] The method further includes:

[0037] A first set of nodes is selected from the decision memory node library; wherein the scope field of each first node matches the project file path and / or the external dependency identifier;

[0038] For each decision memory node, a comprehensive matching degree is calculated, specifically including:

[0039] Calculate the overall matching degree for each decision memory node in the first node set.

[0040] Optionally, the weight of the semantic similarity calculation is S times smaller than the weight of the determination result, where S≥10.

[0041] Optionally, the decision memory nodes are selected based on the comprehensive matching degree, specifically including:

[0042] Select the top K decision memory nodes, sorted by overall matching score from largest to smallest, where K > 0;

[0043] For any two decision memory nodes among the first K decision memory nodes, denoted as A and B, if there exists a directed edge from A to B, then A is deleted from the first K decision memory nodes.

[0044] The selection results are obtained based on the L remaining decision memory nodes from the first K decision memory nodes; K≥L.

[0045] Optionally, large language model invocation instructions are constructed based on the selected decision memory nodes, specifically including:

[0046] Based on the node-related semantic information of each selected decision memory node, determine the token length of each selected decision memory node;

[0047] Select the top M decision memory nodes from the selected decision memory nodes, sorted by comprehensive matching degree from largest to smallest; wherein, the number of selected decision memory nodes is denoted as L, L≥M, and the sum of the token lengths of the top M decision memory nodes is less than or equal to the first length threshold.

[0048] Based on the first M decision memory nodes, generate operation constraint information;

[0049] The large language model invocation instructions are constructed based on the operational constraint information.

[0050] Optionally, the first length threshold is less than the second length threshold; the second length threshold is determined based on the maximum context length allowed by the large language model.

[0051] Optionally, the data structure of each decision memory node also includes a node type field, which stores one of the following: design intent type, prohibition mode type, constraint type, and trade-off type.

[0052] Based on the first M decision memory nodes, operational constraint information is generated, including:

[0053] Extract instruction-related information corresponding to each decision memory node; the instruction-related information includes node-related semantic information and XML tags identifying the node type;

[0054] According to the node type priority of each decision memory node from low to high, the instruction-related information corresponding to each selected decision memory node is assembled to obtain the first assembled information;

[0055] The first assembly information is assembled after the second assembly information; the second assembly information includes the representation information corresponding to the code context.

[0056] Based on the first assembly information and the second assembly information after assembly, the operation constraint information is obtained.

[0057] Optionally, the node types are prioritized from highest to lowest as follows: prohibited mode type, constraint type, design intent type, and trade-off type.

[0058] Optionally, operational constraint information is obtained based on the first assembly information and the second assembly information after assembly, specifically including:

[0059] A third assembly is assembled before the second assembly information, the third assembly including at least a temperature value specified for the large language model, the temperature value being less than 0.5;

[0060] Based on the first assembly information, the second assembly information, and the third assembly information after assembly, the operation constraint information is obtained.

[0061] This disclosure also provides a system for constructing calling instructions for a large language model, including one or more program modules, which are used to implement the above method steps.

[0062] This disclosure also provides a computer program product having at least one instruction stored thereon, which, when executed by a processor, implements the above-described method steps.

[0063] This disclosure also provides an electronic device, including: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed by the above-described steps.

[0064] The technical solution provided in the manual determines the AST structure and code editing location in the code editing environment by responding to requests to generate code using a large language model. It extracts structured path information and semantic representation information of the code context. Then, it performs a dual-track hybrid retrieval in the decision memory node library based on a comprehensive matching degree of semantic similarity and structural feature matching. Finally, it constructs the large language model invocation instruction based on the selected decision memory nodes. This solution can accurately match architectural constraints through a dual-track hybrid retrieval of semantics and structure before the large language model generates code, and dynamically injects these constraints into the large language model invocation instruction. This guides the large language model to generate code that conforms to the project architecture specifications, effectively solving the problem of architecture decision drift during the large language model code generation process. Attached Figure Description

[0065] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0066] Figure 1 This is a schematic diagram illustrating the process of constructing a calling instruction for a large language model;

[0067] Figure 2 This is a schematic diagram of a code generation context dynamic injection system based on an external decision memory.

[0068] Figure 3 This is a schematic diagram of the internal computational pipeline of the multimodal context extraction module;

[0069] Figure 4 This is a schematic diagram of the internal execution pipeline of the hybrid scoring retrieval engine;

[0070] Figure 5 This is a schematic diagram of the internal execution pipeline of the context dynamic assembly and injection gateway module;

[0071] Figure 6 This is a schematic diagram of the structure of an electronic device. Detailed Implementation

[0072] Unless otherwise expressly stated, throughout the specification and claims, the term "comprising" or its variations such as "including" or "comprises" shall be understood to include the stated elements or components without excluding other elements or other components.

[0073] The technical solutions of this disclosure are illustrated below through specific embodiments. It should be understood that one or more steps mentioned in this disclosure do not preclude the existence of other methods and steps before or after the combined steps, or that other methods and steps may be inserted between these explicitly mentioned steps. It should also be understood that these examples are for illustrative purposes only and are not intended to limit the scope of this disclosure. Unless otherwise stated, the numbering of each method step is only for the purpose of identifying each method step, and not to limit the order of each method or to limit the scope of implementation of this disclosure. Changes or adjustments to their relative relationships, without substantial changes to the technical content, can also be considered as within the scope of implementation of this disclosure.

[0074] In software engineering scenarios, developers write, complete, modify, save, or commit code in code editing environments such as integrated development environments (IDEs). During this process, tools such as large language models are sometimes used to assist in code generation, thereby improving development efficiency.

[0075] In software engineering scenarios, with the development of large language models, AI-assisted programming tools have been widely applied in code generation. When developers call large language models to generate code, they need to ensure that the generated code conforms to the project architecture specifications. Therefore, there is a technical requirement in this scenario: when calling large language models to generate code, it is necessary to accurately perceive the current context of the code and inject accurate normative constraints (such as architectural constraints) accordingly, thereby guiding the large language model to generate code that conforms to the project specifications.

[0076] To meet the above technical requirements, the following optional technical solutions can be adopted:

[0077] The first alternative technical solution is a purely semantic retrieval scheme. This involves segmenting the existing codebase and calculating its semantic features. When a user request is received, historical code fragments are matched based on semantic similarity and injected as context.

[0078] The second alternative is a rule injection scheme based on static configuration. This involves configuring a static rule file in a specific project directory to force all requests to attach fixed plain text system prompt rules.

[0079] However, the above-mentioned alternative technical solutions have the following technical problems:

[0080] For the first alternative technical solution, since pure semantic features can only represent the surface semantics of the code, but cannot represent the abstract syntax tree structure and architectural intent behind the code, when both obsolete old standard code and new standard code exist in the codebase, if the semantics of the current task are similar to the old standard, it is very easy to use the incorrect old standard as context, resulting in the negative result of local semantic correctness but overall specification violation.

[0081] For the second alternative technical solution, static configuration files cannot perform precise matching based on the context of code operations, and can only perform coarse-grained rule checks. Because they cannot perceive the specific syntax structure of the current code, they are prone to triggering numerous irrelevant rules, negatively impacting project development.

[0082] This specification provides a method for constructing invocation instructions for a large language model. The technical idea is as follows: In response to a request to invoke code generated by the large language model, structured path information based on AST and semantic representation information of the code context are extracted. Then, a dual-track hybrid retrieval is performed in the decision memory node library based on a comprehensive matching degree of semantic similarity and structural feature matching. Finally, the large language model invocation instructions are constructed based on the selected decision memory nodes. This solution can accurately match architectural constraints through a dual-track hybrid retrieval of semantics and structure before the large language model generates code, and dynamically inject these constraints into the large language model invocation instructions, thereby guiding the large language model to generate code that conforms to the project architecture specifications, effectively solving the problem of architecture decision drift during the large language model code generation process.

[0083] The technical solutions provided in this disclosure are described in detail below with reference to the accompanying drawings.

[0084] Figure 1 This is a schematic diagram of the method flow for constructing calling instructions in a large language model.

[0085] like Figure 1 As shown, the method for constructing large language model invocation instructions according to the present invention includes the following steps:

[0086] Step S101: In response to the request to call the large language model to generate code, determine the AST structure and code editing location.

[0087] When a request to generate code using a large language model occurs in the code editing environment, the system responds to the request by determining the AST structure in the code editing environment and the code editing location specified in the request.

[0088] A code editing environment can be an integrated development environment (IDE), an online code editor, or any application, operating system, or monitorable physical environment that supports code editing. A code editing environment can have an interactive code editing area where users can edit code.

[0089] It should be noted that the execution entity of the scheme in this embodiment may be, for example, a process, plugin, script, etc., implanted in a code editing environment.

[0090] Determining the AST structure within a code editing environment can be achieved by invoking an incremental parser within that environment. An incremental parser can parse the AST structure of incremental code (i.e., the changed code portions), offering higher efficiency compared to full parsing. For example, Tree-sitter, an incremental parsing library, can be used as an incremental parser to quickly parse code and generate its AST structure.

[0091] Determining the code editing location specified by the request to generate code from the large language model can be achieved by obtaining the interactive location triggered by that request in the code editing area. For example, when a user clicks on a location or selects a section of code in the code editing area, the system can obtain the line number and column number of that interactive location as the code editing location. Similarly, when a user performs a code save operation, the system can use the current cursor position in the editor as the code editing location.

[0092] Step S102: Map the code editing location to the leaf nodes of the AST and extract the structured path information.

[0093] After determining the AST structure and the code editing location, the code editing location can be mapped to the leaf nodes of the AST structure. AST leaf nodes are nodes in the AST structure that represent the smallest syntactic unit of code, such as identifier nodes, literal nodes, etc. The corresponding leaf node can be located in the AST structure using the row and column numbers.

[0094] After mapping to the leaf nodes of the AST, structured path information can be extracted. This structured path information records the declarative nodes and control flow nodes along the path from the leaf node to the root node. Declarative nodes can include class declaration nodes, method declaration nodes, function declaration nodes, and other nodes representing the code declaration structure. Control flow nodes can include conditional branch nodes, loop nodes, exception handling nodes, and other nodes representing the code control flow.

[0095] Optionally, structured path information can be represented in string form, for example:

[0096] "Project / Class:UserService / Method:createUser / IfStatement".

[0097] This string indicates that the code was edited within the `if` statement of the `createUser` method in the `UserService` class. Structured path information allows for precise representation of the code's location within the project architecture.

[0098] Optionally, before extracting structured path information, the system can also determine whether the AST leaf nodes match preset code risk structure rules. Code risk structure rules can include: whether the node is in a loop, the depth of loop nesting, whether it is in a conditional branch, the depth of condition nesting, whether it is in an exception handling block, and whether it is in an asynchronous context. If an AST leaf node matches a code risk structure rule, risk flag information is generated based on the matched rule and added to the structured path information. For example, if the code editing location is in a loop with a nesting depth of 3, the flag "[LOOP_DEPTH:3]" can be added to the structured path information. Risk flag information can help subsequent constraint rule matching more accurately identify high-risk code regions.

[0099] Step S103: Extract semantic representation information of the code context

[0100] After extracting the structured path information, the system extracts the code context based on the code editing location to obtain the semantic representation information of the code context.

[0101] Optionally, before obtaining the semantic representation information of the code context, the system can extract the code context within a set capacity window based on the code editing position. For example, N lines of code before and after the code editing position can be extracted as the code context.

[0102] Optionally, the system can also acquire prompts input by the user. These prompts are used to guide the large language model to perform code-related tasks, such as "generate a method to create a user." The system can generate comprehensive semantic representation information based on the combination of code context and user prompts. This comprehensive semantic representation information can be a semantic vector representation concatenated from the code context and prompts. By integrating this semantic representation information, the user's intent and code context information can be fused, providing richer semantic information for subsequent constraint rule matching.

[0103] Optionally, before extracting the structured path, the system can also extract the project file path to which the current code file belongs, and / or extract external dependency identifiers from the declarations in the current code file. The project file path can be used to distinguish code files from different modules or levels. External dependency identifiers can be identifiers of external libraries or modules imported into the code file. This enables scope-based constraint rule filtering.

[0104] Step S104: Calculate the comprehensive matching degree in the decision memory node library, filter decision memory nodes, and construct the large language model invocation instructions.

[0105] After extracting the structured path information and the semantic representation information of the code context, the system calculates a comprehensive matching degree for each decision memory node in a pre-defined decision memory node library. This is based on the semantic similarity between the node-related semantic information and the semantic representation information of the code context, as well as the determination result of whether the constraint triggering rule field of the decision memory node matches the structured path information. Then, decision memory nodes are selected based on the comprehensive matching degree, and a large language model invocation instruction is constructed based on the selected decision memory nodes to invoke the large language model to generate code.

[0106] Pre-defined constraint triggering rules can be stored in a decision memory node library. This library can be a constraint rule repository specifically for the target development project, where at least some decision memory nodes are configured according to the project architecture specifications corresponding to the target development project.

[0107] Each decision memory node's data structure includes at least two fields: a constraint triggering rule field and a semantic field. The constraint triggering rule field stores regular expressions or exact matching patterns that match the structured path. For example, the constraint triggering rule field could store the regular expression " / Service / .java / Method:*", representing a match for any method in any Java class under the Service package. The semantic field stores node-related semantic information, such as: prohibiting the use of hard-coded switch / if-else enumerations to handle UI distribution for different UserRoles; current system evolution requires: a new subclass inheriting from `BaseRoleRenderer` must be added, and the `render_view()` method must be implemented.

[0108] Optionally, in addition to the instruction text, the node-related semantic information may also include the technical trade-offs behind the decision (for auditing purposes) and the semantic vector of the instruction text (e.g., a 1536-dimensional dense vector of the instruction text after dimensionality reduction by a pre-trained model).

[0109] Optionally, the decision memory node library may include a vector database. The vector database stores the semantic vectors corresponding to the semantic fields of the decision memory nodes. Through the vector database, constraint rule retrieval based on semantic similarity can be implemented.

[0110] It is understandable that node-related semantic information is used to specify the specific content of the operation constraint mechanism, such as constraint description, prohibition mode, recommendation mode, etc.

[0111] Optionally, the data structure of each decision memory node may also include at least one of the following: a node basic metadata field, a node type field, and a scope field. The node basic metadata field may store metadata information such as the node's creation time, modification time, and creator. The node type field may store one of the following: design intent type, prohibition mode type, constraint type, or trade-off type. Different types of nodes may have different processing priorities during the subsequent constraint information assembly process.

[0112] Optionally, the scope field can store the project file path range of the code files to which this decision memory node applies, and / or a set of external dependency identifiers. The scope field allows for scope filtering of constraint rules, improving retrieval efficiency.

[0113] The decision memory node library can employ various storage methods. Optionally, the decision memory node library may include a directed acyclic graph (DAG) database. In the DAG database, overwrite relationships can be established between decision memory nodes. When a new decision memory node is added to the decision memory node library in response to a decision update instruction, if the new node has an overwrite relationship with an existing node, a directed edge is established from the existing node to the new node. This design can support version management and historical tracing of constraint rules. It should be noted that the decision update instruction may be issued based on the iteration of project architecture decisions, which includes discarding existing decision memory nodes and / or making newly added decision memory nodes effective.

[0114] The following example illustrates the process of retrieving matching constraint triggering rules from the decision memory node library.

[0115] The process of performing a dual-track hybrid retrieval in the decision memory node library may include the following stages:

[0116] Phase S201: Scope Filtering

[0117] Optionally, the system can first filter out a first set of nodes from the decision memory node library. For each decision memory node, it determines whether its scope field matches the project file path and / or external dependency identifier. Nodes with matching scopes are added to the first set of nodes. Scope filtering can significantly reduce the number of nodes that need to be matched subsequently, improving retrieval efficiency.

[0118] Phase S202: Calculate the overall matching degree

[0119] For each decision memory node in the decision memory node library (or each decision memory node in the first node set), the system calculates the comprehensive matching degree based on the semantic similarity between the node-related semantic information of the decision memory node and the semantic representation information of the code context, as well as the determination result of whether the constraint triggering rule field of the decision memory node matches the structured path information.

[0120] Semantic similarity can be calculated using methods such as cosine similarity, Euclidean distance, or dot product. For determining whether a constraint triggering rule field matches the structured path information, the matching method can be regular expression matching or exact string matching. If the constraint triggering rule field matches the structured path information, the result is considered a successful match; otherwise, the result is considered a failed match.

[0121] The overall matching degree can be calculated as a weighted sum of semantic similarity and the judgment result. In this embodiment, the weight of semantic similarity is less than the weight of the judgment result to ensure that accurate matching of structural features takes precedence over semantic similarity.

[0122] Furthermore, the weight for calculating semantic similarity can be significantly smaller than the weight for calculating the judgment result. For example, the weight for calculating semantic similarity can be S times smaller than the weight for calculating the judgment result, where S ≥ 10. For instance, the weight for calculating semantic similarity can be set to 1, and the weight for calculating the judgment result can be set to 10.

[0123] It should be noted that by setting the weight of semantic similarity calculation to be significantly smaller than the weight of the judgment result calculation, a non-linear reward can be achieved for "once a decision memory node is matched". For example, if a developer performs a dangerous operation in the code editing environment (such as a deeply nested switch), the constraint trigger field containing a negative path constraint mechanism (preventing deeply nested switch) will be matched. In this case, regardless of the specific semantics of the code context, the influence of semantic similarity on the calculation of the overall matching degree is reduced to a very low level, while the influence of the judgment result on the calculation of the overall matching degree is greatly increased. This decision memory node can ultimately be filtered out, thereby ensuring that the mandatory constraint is triggered.

[0124] Phase S203: Filtering Decision Memory Nodes

[0125] Filtering decision memory nodes based on overall matching degree can include: filtering the top K decision memory nodes sorted from largest to smallest overall matching degree, where K > 0.

[0126] Optionally, if the decision memory node library includes a DAG database, conflict resolution is also required during the selection process. For any two nodes A and B among the first K decision memory nodes, if there exists a directed edge from A to B, it means that B has overwritten A, and A should be removed from the first K nodes. Finally, the selection result is obtained based on the remaining L decision memory nodes, where K is greater than or equal to L. Conflict resolution ensures that the finally selected constraint rules are the latest versions, avoiding the use of old rules that have been overwritten.

[0127] Phase S204: Construct a large language model and invoke instructions based on the selected decision memory nodes.

[0128] After selecting the decision memory nodes, the system constructs a large language model invocation instruction based on the selected decision memory nodes to invoke the large language model to generate code.

[0129] After retrieving L decision memory nodes, the system can select all or some of them. The selection process can consider token length limitations. Specifically, based on the node-related semantic information of each selected decision memory node, the token length of each selected decision memory node is determined. The top M decision memory nodes, sorted by their overall matching degree from highest to lowest, are selected. The number of selected decision memory nodes is denoted as L, where L ≥ M, and the sum of the token lengths of the top M decision memory nodes is less than or equal to a first length threshold. The first length threshold can be less than a second length threshold, which is determined based on the maximum context length allowed by the large language model. By limiting the token length, it can be ensured that the injected constraint information does not exceed the context length limit of the large language model.

[0130] Then, based on the first M decision memory nodes, operational constraint information is generated; and based on the operational constraint information, a large language model is constructed to invoke instructions.

[0131] The following details the process of constructing large language model call instructions.

[0132] The process of constructing large language model invocation instructions based on the selected decision memory nodes can include:

[0133] Step S301: Extract instruction-related information

[0134] For each selected decision memory node, extract the instruction-related information corresponding to its node-related semantic information. Instruction-related information can be textual content such as constraint descriptions, prohibited patterns, and recommended patterns stored in the semantic fields. Furthermore, the semantics of the node type can be XML-tagged and included in the instruction-related information to enhance attention for large language models.

[0135] Step S302: Assemble instruction information according to priority

[0136] Assemble instruction-related information according to the node type priority of the selected decision memory node. Node types can include design intent type, prohibition mode type, constraint type, and trade-off type. Different types of nodes can have different priorities. The node type priority order can be from high to low as follows: prohibition mode type, constraint type, design intent type, and trade-off type.

[0137] For example, nodes of the prohibition mode type can have the highest priority because prohibition mode represents behavior that must be avoided; nodes of the design intent type and constraint type can have medium priority; and nodes of the trade-off type can have low priority. Assembling them in order of low to high priority ensures that high-priority constraint information appears later in the instructions, thus gaining greater attention weight (according to the attention mechanism characteristics of large language models, later tokens usually receive higher attention).

[0138] The assembled instruction-related information forms the first assembly information.

[0139] Step S303: Assemble code context information

[0140] The first assembly information is assembled after the second assembly information. The second assembly information includes representation information corresponding to the code context, such as truncated code snippets or comprehensive semantic representation information. Assembling constraint information after the code context can anchor the first assembly information to the end of the large language model's call instruction, effectively combating the intermediate forgetting characteristics of large models.

[0141] Step S304: Assembly temperature parameters

[0142] Optionally, a third assembly information is assembled before the second assembly information. The third assembly information includes at least a temperature value specified for the large language model. The temperature value can be set to less than 0.5, such as 0.1 or 0. A lower temperature value can reduce the randomness of the large language model's output, making it more guided by the constraint information and generating a more deterministic output.

[0143] In addition, the third assembly information may also include the identifier of the large language model to be invoked, the role identifier of each prompt message, etc.

[0144] Step S305: Generate final instructions

[0145] Based on the assembled first, second, and third assembly information (if any), the final large language model invocation instruction is generated. This instruction can be injected into the context of the large language model as a system prompt.

[0146] Ultimately, the system uses the constructed large language model invocation instructions to invoke the large language model in order to generate code that conforms to the project architecture specifications.

[0147] Furthermore, based on the same inventive concept, embodiments of this specification also provide a large language model invocation scheme, which may include: when the preset type operation is to invoke the large language model to generate code, obtaining a large language model invocation instruction based on the triggering method of the above-mentioned optional operation constraint mechanism; and applying the large language model invocation instruction to invoke the large language model to generate code.

[0148] This disclosure also provides a system including one or more program modules, which are used to implement the embodiments of this application.

[0149] The overall architecture of the system of the present invention is illustrated below.

[0150] The system of the present invention may include the following main modules:

[0151] Code editing environment module: Provides an interactive code editing area for users, supporting operations such as code editing, saving, and committing. When a request to generate code using a large language model is triggered, a request event is sent to the AST parsing module.

[0152] AST parsing module: In response to a request to generate code using a large language model, it invokes the incremental parser to obtain the AST structure of the code. It maps the code editing locations to AST leaf nodes and extracts structured path information. This structured path information is then sent to the feature construction module.

[0153] Feature construction module: Extracts semantic representation information of the code context based on the code editing location. Sends structured path information and semantic representation information to the retrieval engine module.

[0154] Decision Memory Node Library: Stores decision memory nodes. It can include directed acyclic graph databases and vector databases, supporting overwrite relationships between nodes and semantic vector storage.

[0155] Search engine module: In the decision memory node library, for each decision memory node, the comprehensive matching degree is calculated based on the judgment results of semantic similarity and structural feature matching, and decision memory nodes are filtered.

[0156] Constraint Assembly Module: Generates operational constraint information based on the selected decision memory nodes. Assembles instruction-related information according to node type priority to construct the large language model invocation instructions.

[0157] Constraint Injection Gateway Module: Sends the large language model invocation command to the large language model service invocation request.

[0158] The modules described above can be implemented using software, hardware, or a combination of both. Communication between modules can be achieved through inter-process communication, network communication, or function calls.

[0159] In summary, one or more of the publicly disclosed embodiments may have the following beneficial effects:

[0160] Effect 1: Achieve precise constraint matching based on a hybrid retrieval system combining semantic and structural approaches.

[0161] By employing a technique that calculates the comprehensive matching degree for each decision memory node in the decision memory node library based on the judgment results of semantic similarity and structural feature matching, this invention enables precise constraint matching based on a hybrid retrieval system of semantic and structural elements. Compared to existing retrieval methods based on pure semantic vectors, this invention ensures that precise matching of structural features takes precedence over semantic similarity by setting the calculation weight of semantic similarity to be less than the calculation weight of the judgment result, thereby achieving more accurate matching of architectural constraints.

[0162] Effect 2: Supports dynamic updates and version management of constraint rules

[0163] Because it uses a directed acyclic graph database to store decision memory nodes and establishes overwrite relationships between nodes, it can support dynamic updates and version management of constraint rules. When project architecture specifications change, constraint rules can be updated by adding new decision memory nodes without deleting old rules, thus preserving historical decision information.

[0164] Effect 3: Guide the large language model to generate code that conforms to the project architecture specifications

[0165] By employing a technique that constructs large language model invocation instructions based on selected decision memory nodes, it is possible to guide the large language model to generate code that conforms to the project architecture specifications. By dynamically injecting architectural constraints into the large language model invocation instructions before invoking the code, the problem of architectural decision drift during the large language model code generation process can be effectively solved.

[0166] Effect 4: Optimize the construction of large language model invocation instructions

[0167] By employing techniques that prioritize instruction information according to node type and control the temperature value to less than 0.5, the construction of large language model call instructions can be optimized. Through reasonable instruction assembly order and temperature value control, the large language model can be guided to generate code that better conforms to project architecture specifications, reducing architecture decision drift issues.

[0168] Furthermore, to make the technical solutions of the embodiments in this specification clearer, the following will clarify them in conjunction with specific application scenarios, specifically the constraint injection process for generating large language model code based on semantic and structural dual-track hybrid retrieval.

[0169] Within the code editing client, when a developer calls the large language model to generate code, the system can execute the following process:

[0170] The system pre-enters a decision node about the code rendering architecture in the decision memory node library. This node is of type prohibited mode, and its scope is limited to specific view component paths. Its constraint triggering rules are set to match control flow branch structures (such as switch or if-else), and its semantic information requires that hard-coded enumerations be prohibited and that new subclasses inheriting from a specific base class be added.

[0171] When a developer places the cursor within an existing function in a view component file and enters a prompt to request the large language model to add rendering logic for a specific role, the system responds to this request to generate code using the large language model, extracts the current file path, parses the AST, and extracts the structured path information at the cursor's location and the semantic representation information of the code context (such as detecting function declaration nodes and predicting that a control flow branch will be generated soon).

[0172] The system performs a dual-track hybrid search in the decision memory node library, calculating the comprehensive matching degree for each decision memory node. This file path matches the scope of the aforementioned decision node. Furthermore, although the user's suggestion word has some semantic similarity to this node, the successful AST structured path matching amplifies the weight of the judgment result, resulting in an extremely high comprehensive matching degree for this decision node, which is therefore prioritized.

[0173] When constructing the large language model invocation instructions, the system assembles the constraint information of the decision node (i.e., prohibiting hard coding and requiring subclass inheritance) into the user code context representation, assigns it a high attention weight using a tail anchoring mechanism, sets a low temperature value, and sends the request to the large language model. Ultimately, the large language model follows these architectural constraints, generating polymorphic architectural code that meets evolutionary requirements and preventing software architecture degradation.

[0174] To provide a more comprehensive description of the technical solutions disclosed herein, the following exemplarily illustrates the application background, the technical problem solved, the technical principle, and the technical effects of one embodiment of the present disclosure.

[0175] With the development of large language models, AI-assisted programming tools have been widely used in the field of software engineering. Existing AI programming systems are mainly based on retrieval-enhanced generation technology. Their standard workflow is as follows: extract lexical fragments from the developer's current editor, search for similar code segments in the code library, merge the similar code with the user's prompts, and submit them to the large language model to generate new code.

[0176] While some alternatives significantly improve development speed in terms of code completion and boilerplate code elimination, they expose the problem of "architectural decision drift" when facing the long-term evolution of complex enterprise software.

[0177] The optional AI context injection mechanisms mainly rely on the following two schemes:

[0178] Option 1: Vector retrieval based on pure semantics. The existing codebase is segmented and embedding vectors are calculated. When a user asks a question, historical code fragments are matched using cosine similarity as context.

[0179] Option 2: Rule injection based on static configuration. For example, forcibly append a fixed system prompt text to all AI requests in a specific directory.

[0180] The above solution has the following specific drawbacks:

[0181] Defect 1: Semantic vector-based code retrieval suffers from "decision state deficiency," making it prone to "self-betrayal." Existing vector databases can only map the "current code appearance of the system," but cannot represent the "underlying architectural intent." When the codebase contains both old, legacy, dirty code and refactored, new standard code, if the semantics of the user's current task are closer to the legacy code, vector retrieval will incorrectly inject the old standard as context, causing the system to unknowingly copy an implementation method that has been abandoned by the team.

[0182] Defect 2: Static rule injection lacks dynamic and precise routing based on abstract syntax trees. Existing static rule files are global or directory-level effective. Due to the upper limit of the context window of a large language model and the dilution of attention mechanisms as prompt words become longer, developers cannot write all the system's architectural constraints into a single static file. When a developer is writing a specific function, the existing system cannot dynamically perceive the specific syntactic structure of the current code, either injecting a large number of irrelevant rules that lead to illusions in the large language model and wasted lexical units, or lacking specific enforced constraints for the current code structure.

[0183] Defect 3: The greedy generation strategy of large language models leads to "local optima but global degradation". Most existing AI generation gateways reward and optimize based on whether the current compilation or unit test can be passed. In order to quickly complete the current single task, existing AI systems tend to take the shortest path and do not have the awareness of long-term system maintenance boundaries and component compatibility requirements.

[0184] Defect 4: Lack of a structured storage and injection mechanism for "negative paths" and "historical trial-and-error trajectories". Existing tools' context extractors only read currently active, valid code, completely losing historical trial-and-error records that have been rolled back or deleted. When AI attempts to solve a complex problem or refactor, due to the lack of historical error-prevention memory, the AI's inference tree often regenerates erroneous solutions that humans had already proven problematic months ago.

[0185] This disclosure provides a method for constructing invocation instructions for a large language model. By responding to a request to invoke code generation from the large language model, it extracts structured path information based on AST and semantic representation information of the code context. Then, it performs a dual-track hybrid retrieval in a decision memory node library based on a comprehensive matching degree of semantic similarity and structural feature matching. Finally, it constructs large language model invocation instructions based on the selected decision memory nodes, thereby guiding the large language model to generate code that conforms to the project architecture specifications.

[0186] Figure 2 This is a schematic diagram of a large language model invocation command construction system. The system workflow begins with user input triggering the multimodal context extraction module to perform three concurrent extractions: syntax tree parsing to extract abstract syntax tree features, text truncation to extract surrounding text embeddings, and path routing to extract file scope information. The three outputs are fed into a hybrid retrieval engine, which simultaneously performs dual-track searches with both a vector database and a graph database. The search results are then converged into a scoring engine for nonlinear fusion calculation, outputting a set of decision nodes. These decision nodes undergo context assembly and prompt word compilation, and are finally sent to the large model interface to complete code generation.

[0187] This system constructs an external "hybrid retrieval engine combining semantic vectors and structural features" to intercept requests before calling the large language model to generate code, and then performs state queries and constraint injection. The system as a whole consists of four core modules: a multimodal context extractor, a structured decision memory, a hybrid scoring retrieval engine, and a constraint assembly and injection gateway.

[0188] In this system, "architectural decisions" are visualized as a composite graph-vector data structure. The system's underlying storage is jointly supported by a directed acyclic graph database and a vector database.

[0189] The data structure of each decision memory node includes the following fields:

[0190] The node's basic metadata field is used to store basic information such as the node's unique identifier, creation time, and version number.

[0191] The node type field is used to store the node type, which can include one of the following: design intent type, prohibition mode type, constraint type, and trade-off type.

[0192] The scope field is used to limit the scope of the project file path of the code file to which this decision memory node applies, and / or the set of external dependency identifiers.

[0193] The constraint trigger rule field is used to store regular expressions or exact matching patterns that match the structured path.

[0194] Semantic fields are used to store semantic information related to nodes, which is used to specify operational constraint mechanisms.

[0195] Figure 3 This is a schematic diagram of the internal computational pipeline of the multimodal context extraction module. The overall system workflow begins with the integrated development environment / language server (IDE / LSP Server). When an Event_Trigger occurs, the main controller of the multimodal extraction module receives payload parameters containing the file path, cursor position, and user prompt words, and then initiates a three-way concurrent extraction process. The first route, the lexical extractor (Text), is responsible for processing. This module receives the incoming file stream and cursor information, extracts surrounding text using a bidirectional sliding window algorithm, calculates local embeddings, and outputs the context text and local embeddings (Q_text). The second route, the abstract syntax tree parsing engine (Tree-sitter), is responsible for processing. This module receives the incoming complete source code and cursor information, and sequentially performs three steps: incremental parsing to build the abstract syntax tree, coordinate collision testing to address nodes, and upward traversal to extract parent signatures, finally outputting the structured signature path (Q_ast). The third-party environment dependency scanner (FS) handles this process. This module receives the file path parameter, parses the import / require static topology relationships, and outputs the file path pattern and dependency tree (Q_env). These three outputs converge into a query structure (Query Object Q), which is then serialized and assembled into a query payload before being delivered to the downstream hybrid retrieval engine for further processing.

[0196] The multimodal context extraction module can be deployed on the client side, such as in an integrated development environment (IDE) plugin or a local language server protocol. This module listens for requests to generate code from a large language model, captures the current machine state of the workspace, and compiles it into a structured query payload.

[0197] This module performs three-way concurrent extraction:

[0198] Subsystem 1: Lexical and Semantic Feature Extractor. This subsystem is responsible for acquiring plain text for subsequent semantic similarity calculation. It employs a bidirectional sliding window algorithm based on cursor position to obtain the absolute character offset of the current editor cursor, sets a maximum truncation window size, and extracts the code context within the set window size. It then concatenates the current user input suggestions with the code context and calls an embedding model to generate semantic vectors.

[0199] Subsystem Two: Abstract Syntax Tree Feature Extractor. This subsystem helps the system determine which type of control flow the user is writing in which class and method. It uses an incremental parser (such as Tree-sitter or Babel) at the underlying level. The core algorithm includes: mapping the cursor coordinates to the two-dimensional space of the abstract syntax tree; finding the smallest leaf node surrounding the cursor using depth-first search; traversing upwards from the leaf node along the parent pointer to the root node, collecting all key declarative nodes (such as class declaration nodes, method declaration nodes, and function declaration nodes) to generate a structured path; and detecting whether the cursor's position is within a high-risk branch logic (such as a switch or if-else statement with a nesting depth greater than a threshold), generating risk flag information.

[0200] The preset code risk structure rules may include at least one of the following: whether it is in a loop, the depth of loop nesting, whether it is in a conditional branch, the depth of condition nesting, whether it is in an exception handling block, or whether it is in an asynchronous context.

[0201] Subsystem 3: Environment and Topology Feature Extractor. This subsystem addresses the scope isolation problem of decision constraints. It includes: physical path extraction, calculating the relative path string of the current file relative to the project root directory; and static dependency graph scanning, scanning the import statements at the beginning of the current file and extracting the set of external dependency identifiers.

[0202] The extraction module ultimately outputs a standard query structure, which includes: semantic vectors, structured path information, project file paths, external dependency identifiers, and representation information corresponding to the code context.

[0203] Figure 4This is a schematic diagram of the internal execution pipeline of the hybrid scoring retrieval engine. The overall system workflow begins with the input query structure, which contains three data streams: text, syntax tree, and environment data output by the multimodal context extractor. The process enters Phase 1, scope hard pruning. First, the environment path is read to obtain the relative path of the current file. Then, global pattern matching is performed to filter out nodes that do not conform to the scope, generating a filtered candidate node pool. The candidate node pool enters Phase 2, dual-track concurrent scoring. This phase executes two parallel computation paths: the first is the semantic computation path, which calculates the semantic score vector through vector search; the second is the structural computation path, which calculates the structural score vector through syntax tree signature matching. The score vectors from both paths are input into Phase 3, nonlinear weighted fusion, to perform hybrid score calculation. This calculation uses a nonlinear fusion algorithm to give overwhelming weight to the syntax tree structural features, and then sorts them in descending order of score to obtain the candidate pool. The candidate pool enters the four-graph topology conflict resolution stage. First, it queries the covering edges in the directed acyclic graph to identify the covering relationship between the old and new decisions. Then, it removes abandoned nodes and outputs a decision array, which will be submitted to the downstream constraint assembly and injection gateway for further processing.

[0204] The hybrid scoring retrieval engine receives the query structure generated by the multimodal context extractor, performs dual-track retrieval and cross-fusion weight calculation in a composite external memory consisting of vector indexes and graph indexes, and finally outputs a set of decision nodes after sorting and conflict resolution.

[0205] The execution lifecycle of this module is divided into four computational phases:

[0206] Phase 1: Scope-based Boolean hard filtering. Iterate through the scope field of all nodes in the decision memory node library and call the file path matching library for matching. If the project file path in the query structure matches the scope field of a node, the node is added to the candidate pool; otherwise, it is removed from the candidate pool.

[0207] Phases Two and Three: Calculation of Overall Matching Degree.

[0208] For each node in the candidate pool, calculate the overall matching degree. The calculation method is as follows:

[0209] Overall matching degree = Semantic similarity weight × Semantic similarity + Judgment result weight × Judgment result value

[0210] The semantic similarity weight is less than the judgment result weight. Furthermore, the semantic similarity weight is S times less than the judgment result weight, where S ≥ 10.

[0211] Semantic similarity: The distance between the current prompt word vector and the node vector is calculated using cosine similarity.

[0212] The judgment result value: The structured path information passed to the extractor is a string array. The constraint trigger field of the memory node is a preset regular expression or exact match pattern. If any element in the structured path information is matched by the constraint trigger field, the judgment result value is 1; otherwise, it is 0. By setting the judgment result weight to a larger value, the overall matching degree of the architecture constraint can be significantly improved once the developer triggers a specific abstract syntax tree node in the current file, regardless of the user's current semantic prompt.

[0213] Phase 4: Conflict resolution based on directed acyclic graph topology.

[0214] Because architectural decisions are continuously evolving, old and new decisions may coexist in the external memory. Simple score sorting might inject contradictory nodes into a large language model simultaneously. Therefore, conflict resolution based on directed acyclic graphs needs to be performed in memory.

[0215] When a newly added decision memory node has an overwrite relationship with at least one existing decision memory node, a directed edge is established from the existing decision memory node to the newly added decision memory node. During the selection process, for any two nodes, if there is a directed edge from A to B, then A is deleted from the candidate nodes, and B is retained (i.e., the updated decision is retained).

[0216] After the above four stages, the hybrid scoring retrieval engine outputs a precisely filtered and sorted array of nodes.

[0217] Figure 5This is a schematic diagram of the internal execution pipeline of the context dynamic assembly and injection gateway module. The overall system workflow begins with the input of the top K decision node array (TopK_Nodes) and the input context text and user prompt words (Q_text & User_Prompt), and is processed in three stages. The first stage is token budget calculation. First, the length is calculated by the byte pair encoding tokenizer (BPE Tokenizer), while receiving the input context text and user prompt words. Then, the truncation allocation formula is executed, and the available budget token limit (Token_Limit) is output. After being sorted by priority queue, it enters the second stage. The second stage is attention-biased structured serialization. First, it is grouped into three categories according to the enumeration type (Enum): highest priority, second highest priority, and general priority. Each category is wrapped in Extensible Markup Language (XML), and then a unified in-memory string concatenation is performed to generate a system message (SystemMessage). The third stage is payload construction and injection. The context text and user prompt words directly generate user messages. The system messages and user messages together construct the standard large language model interface request (LLM API RequestJSON), which is finally sent to the remote large language model inference cluster (LLM Inference Cluster) to complete code generation.

[0218] This module is located at the very end of the system architecture, acting as a proxy layer between the client and the underlying large language model inference interface. It receives the node array output by the retrieval engine and the original user request and context text extracted by the extraction module.

[0219] This module performs three core computational steps: dynamic allocation of lexical budgets, structured compilation based on attention weights, and construction of network payloads.

[0220] Dynamic allocation of lexical budget: Large language models have an absolute upper limit on the context window. To prevent overload and attention dilution, the gateway executes a strict budget allocation algorithm. Let the number of lexical units in the user prompt be a certain value, the number of lexical units in the local code text be a certain value, and the maximum safe context window of the current model be a certain value. Calculate the remaining budget available for injecting decision memory. The system traverses candidate nodes in descending order of node score, converting the node's content into lexical length each time. If the cumulative lexical length exceeds the remaining budget, the lower-ranked nodes are strictly discarded.

[0221] Structured serialization based on attention bias: Due to the "forgetting in the middle" phenomenon in large language models, the model assigns significantly higher attention scores to the beginning and end of the input text than to the middle. To ensure that the decision on prohibited patterns is fully adhered to by the model, the gateway employs a structured isolation and tail anchoring algorithm. The system forcibly assembles the decision on prohibited patterns at the absolute end of the system prompt, right next to the user prompt, thus assigning it the highest attention weight when calculating the attention matrix.

[0222] Assemble information according to node type priority: Extract instruction-related information corresponding to the node-related semantic information of each selected decision memory node; Assemble the instruction-related information corresponding to each selected decision memory node in order of node type priority from low to high to obtain the first assembled information; Assemble the first assembled information after the second assembled information, the second assembled information including the representation information corresponding to the code context.

[0223] A third assembly of information can be assembled before the second assembly of information. The third assembly of information includes a temperature value specified for the large language model, which can be less than 0.5 to ensure the determinism of model generation.

[0224] The final network payload is generated by processing the data through the compilation module and then sending the structured payload downstream via an interface. This payload has clearly defined roles, including system roles and user roles.

[0225] This section describes the entire process of code generation and constraint injection for a large language model based on a hybrid retrieval system using both semantic and structural approaches:

[0226] Within the integrated development environment client, when a developer calls the large language model to generate code, how does this system complete constraint injection through dual-track hybrid retrieval?

[0227] System initialization and decision state entry. The senior architect records a low-level architectural decision regarding UI polymorphic rendering within the system, generating a decision memory node. This node is a prohibited mode type, with its scope field matching files in a specific directory, its constraint trigger field set to match control flow branches, and its semantic field indicating that hard-coded use of switch or if-else enumerations to handle UI distribution for different roles is prohibited. It requires the addition of a subclass inheriting from the base class and implementing the corresponding methods.

[0228] Client-side event triggering and multimodal slicing. The developer opens the target file, and the cursor hovers inside an existing function. The developer triggers AI inline generation, inputting prompts to request the addition of rendering logic for a specific role, thus triggering a request to call the large language model to generate code. The local language server protocol daemon captures a physical snapshot of the working area: path extraction captures the current path; abstract syntax tree parsing extracts the cursor's parent path, generating structured path information, detecting the developer's intention to directly modify logic within the function; and simultaneously extracting semantic representation information of the code context.

[0229] Dual-track hybrid retrieval and comprehensive matching degree calculation. The local process sends the sliced ​​data to the retrieval engine, and the comprehensive matching degree calculation is performed in memory. Scope filtering determines the scope field of the node that matches the current path and enters the calculation pool. Semantic similarity is calculated by the cosine similarity between the user's prompt and the node vector. If the decision result determines that the branch node will be generated if the code continues within the existing function following the user's prompt, the decision result value is output as 1. Since the decision result weight is set to be significantly greater than the semantic similarity weight, the comprehensive matching degree of this node is extremely high, and it is placed in the top sequence.

[0230] Payload compilation and underlying interface scheduling. After receiving the request from the node, the injection gateway intercepts the original request and performs structured formatting. The final request payload sent to the remote large model forcibly includes the semantic information of the decision node at the end of the system prompt.

[0231] Model inference and physical protection of the architecture. Due to the mandatory constraints on the end of the system prompts, the attention matrix of the large language model is forcibly redirected. The generated code will follow the architectural constraints and be implemented using inheritance and polymorphism, rather than hard-coded branch enumeration.

[0232] In addition, this disclosure also provides a computer program product having at least one instruction stored thereon, which, when executed by a processor, implements the embodiments of this application.

[0233] This disclosure also provides an electronic device, including: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed according to embodiments of this application.

[0234] Figure 6 This is a schematic diagram of the structure of an electronic device provided in this disclosure.

[0235] This disclosure also provides a storage medium having a computer program stored thereon, which, when executed by a processor, implements the embodiments of this application.

[0236] The example electronic devices described in this disclosure are intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their patterns are merely examples and are not intended to limit the implementations of this disclosure described and / or claimed herein.

[0237] The electronic device includes a computing unit that can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) or a computer program loaded from a storage unit into a random access memory (RAM). The RAM may also store various programs and data required for the operation of the electronic device. The computing unit, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0238] Multiple components in an electronic device are connected to an I / O interface, including: input units such as keyboards and mice; output units such as various types of displays and speakers; storage units such as disks and optical discs; and communication units such as network interface cards (NICs), modems, and wireless transceivers. The communication unit allows the electronic device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

Claims

1. A method for constructing calling instructions for a large language model, characterized in that, include: In response to a request to invoke a large language model to generate code in a code editing environment, determine the abstract syntax tree (AST) structure in the code editing environment, and determine the code editing location specified in the request; The code editing location is mapped to the leaf node of the AST structure, and the structured path information is extracted; wherein, the structured path information is used to record the declarative nodes and control flow nodes on the path from the leaf node to the root node of the AST. Based on the code editing location, the code context is extracted to obtain the semantic representation information of the code context; In the preset decision memory node library, for each decision memory node, the comprehensive matching degree is calculated based on the semantic similarity between the node-related semantic information of the decision memory node and the semantic representation information of the code context, and the determination result of whether the constraint triggering rule field of the decision memory node matches the structured path information; wherein, the calculation weight of semantic similarity is less than the calculation weight of the determination result. Decision memory nodes are selected based on the comprehensive matching degree, and a large language model invocation instruction is constructed based on the selected decision memory nodes to invoke the large language model to generate code.

2. The method as described in claim 1, characterized in that, Determining the AST structure in the code editing environment specifically includes: In the code editing environment, invoke the incremental parser to obtain the AST structure of the incremental code.

3. The method as described in claim 1, characterized in that, Each decision memory node's data structure also includes at least one of the following fields: Node basic metadata fields, node type fields, scope fields; Among them, the node type field stores one of the following: design intent type, prohibition mode type, constraint condition type, and trade-off type; The scope field stores the project file path range of the code files to which this decision memory node applies, and / or, a set of external dependency identifiers; The decision memory node library includes a directed acyclic graph database; The method further includes: In response to a decision update command, a decision memory node is added to the decision memory node library; wherein, if the newly added decision memory node has an overwrite relationship with at least one existing decision memory node, a directed edge is established from the at least one existing decision memory node to the newly added decision memory node; The decision update instruction is issued based on the iteration of project architecture decisions, and the iteration includes discarding existing decision memory nodes and / or making new decision memory nodes effective.

4. The method as described in claim 1, characterized in that, in, The code editing environment has an interactive code editing area; Determining the code editing location specified in the request specifically includes: Obtain the interaction location triggered by the request in the code editing area, and use it as the code editing location specified by the request.

5. The method as described in claim 1, characterized in that, Before extracting structured path information, the following is also included: Determine whether the leaf nodes of the AST match the preset code risk structure rules; If so, risk flag information is generated according to the matched code risk structure rules, and the risk flag information is added to the structured path information; The preset code risk structure rules include at least one of the following: Whether it is in a loop, the depth of loop nesting, whether it is in a conditional branch, the depth of condition nesting, whether it is in an exception handling block, and whether it is in an asynchronous context.

6. The method as described in claim 1, characterized in that, Before obtaining the semantic representation information of the code context, it also includes: Based on the code editing location, extract the code context within a set capacity window; Obtain the input user prompts, which are used to prompt the large language model to perform code-related tasks. Based on the combination of the code context and the user prompt words, a comprehensive semantic representation information is generated; The representation information corresponding to the code context is the comprehensive semantic representation information.

7. The method as described in claim 1, characterized in that, Before extracting structured path information, the following is also included: Extract the project file path to which the current code file belongs, and / or extract the external dependency identifiers in the declaration of the current code file; The method further includes: A first set of nodes is selected from the decision memory node library; wherein the scope field of each first node matches the project file path and / or the external dependency identifier; For each decision memory node, a comprehensive matching degree is calculated, specifically including: Calculate the overall matching degree for each decision memory node in the first node set.

8. The method as described in claim 1, characterized in that, The weight of the semantic similarity calculation is S times smaller than the weight of the judgment result, where S≥10.

9. The method as described in claim 1, characterized in that, The decision memory nodes are selected based on the comprehensive matching degree, specifically including: Select the top K decision memory nodes, sorted by overall matching score from largest to smallest, where K > 0; For any two decision memory nodes among the first K decision memory nodes, denoted as A and B, if there exists a directed edge from A to B, then A is deleted from the first K decision memory nodes. Based on the L remaining decision memory nodes from the first K decision memory nodes, the selection results are obtained; K≥L; Based on the selected decision memory nodes, large language model invocation instructions are constructed, specifically including: Based on the node-related semantic information of each selected decision memory node, determine the token length of each selected decision memory node; Select the top M decision memory nodes from the selected decision memory nodes, sorted by comprehensive matching degree from largest to smallest; wherein, the number of selected decision memory nodes is denoted as L, L≥M, and the sum of the token lengths of the top M decision memory nodes is less than or equal to the first length threshold. Based on the first M decision memory nodes, generate operation constraint information; Construct large language model invocation instructions based on the aforementioned operational constraint information; Wherein, the first length threshold is less than the second length threshold; the second length threshold is determined based on the maximum context length allowed by the large language model.

10. The method as described in claim 9, characterized in that, The data structure of each decision memory node also includes a node type field, which stores one of the following: design intent type, prohibition mode type, constraint type, and trade-off type. Based on the first M decision memory nodes, operational constraint information is generated, including: Extract instruction-related information corresponding to each decision memory node; the instruction-related information includes node-related semantic information and XML tags identifying the node type; According to the node type priority of each decision memory node from low to high, the instruction-related information corresponding to each selected decision memory node is assembled to obtain the first assembled information; The first assembly information is assembled after the second assembly information; the second assembly information includes representation information corresponding to the code context. Based on the first assembly information and the second assembly information after assembly, the operation constraint information is obtained; Among them, the priority order of node types from high to low is: prohibited mode type, constraint condition type, design intent type, and trade-off type.

11. The method as described in claim 10, characterized in that, Based on the first and second assembly information after assembly, operational constraint information is obtained, specifically including: A third assembly is assembled before the second assembly information, the third assembly including at least a temperature value specified for the large language model, the temperature value being less than 0.5; Based on the first assembly information, the second assembly information, and the third assembly information after assembly, the operation constraint information is obtained.

12. An electronic device, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the method as claimed in any one of claims 1 to 11.

Images