Process control type code generation method and device for large language model

Abstract

This invention relates to the field of automatic code generation technology in the next-generation information technology field, and particularly to a process-controlled code generation method for large language models, which addresses the semantic drift and accumulation problems in the code generation process. The method includes: receiving an architecture specification document; constructing a structured constraint rule base and a specification semantic graph based on the document parsing results; formally mapping the graph to an FSM state transition table; compiling the FSM state transition table into an FSM runtime instance; in the code generation loop, using the FSM runtime instance to monitor each atomic execution step of the large language model in real time; after each token is generated, performing compliance verification based on the structured constraint rules associated with the current FSM state and the current state node; when a constraint rule is violated, triggering a corresponding gating mechanism and performing local correction. This invention fundamentally eliminates semantic drift caused by long sequence reasoning, ensuring that the generated industrial code strictly converges to the preset specification.

Description

Technical Field

[0001] This invention relates to artificial intelligence-assisted programming and software engineering technology, and in particular to a process-controlled code generation method and device for large language models. Background Technology

[0002] In recent years, with the widespread application of Large Language Models (LLMs) in assisted programming and software development, they have shown significant potential in improving code generation efficiency. Code-specific large language models, such as CodeT, StarCoder, and Codex, have demonstrated near-human programmer code generation capabilities in various programming tasks, achieving significant breakthroughs, particularly in tasks like automated program repair and code completion. However, existing technologies still face the following technical challenges:

[0003] First, existing Large Language Models (LLMs) are constrained by an autoregressive (token-by-token) generation mechanism, resulting in uncontrollable inference paths during code generation. Because the generation process relies solely on preceding tokens and lacks explicit constraints on the overall architecture and design specifications, the model is highly susceptible to semantic drift in long-sequence code generation tasks. This semantic drift effect accumulates throughout the generation process, ultimately leading to generated code that, while syntactically correct in parts, deviates significantly from the intended architectural goals in its overall structure.

[0004] Secondly, existing LLM code generation methods have significant shortcomings in satisfying architectural constraints. In industrial software engineering, code often needs to adhere to specific architectural design patterns, module partitioning specifications, interface definition standards, and other constraints. Existing code generation models typically implicitly encode these constraints in the training data, lacking explicit constraint mechanisms. This can lead to generated code that violates architectural specifications, requiring extensive manual correction. For example, in a microservice architecture, interface calls between different services need to follow strict protocols, and existing LLMs struggle to guarantee that the generated code fully complies with these protocol requirements.

[0005] Furthermore, most existing constrained decoding methods employ prefix trees or regular expressions for hard filtering. These methods can only control errors at the "syntax" level (such as forcing JSON output), but they cannot handle complex architectural pattern mappings and lack the ability to express and control higher-level "architectural" constraints (such as adhering to the MVC pattern). Due to the lack of a formal constraint mechanism to translate high-level architectural requirements into low-level machine instructions, existing methods are prone to architectural violations, often requiring significant manual correction costs when applied on a large scale in industry. Summary of the Invention

[0006] To address the problems in the existing technology, this invention proposes a process-controlled code generation method for large language models, which includes:

[0007] S1. Receive the architecture specification document provided by the user, parse the architecture specification document, and construct a structured constraint rule base and specification semantic graph based on the parsing results;

[0008] S2. The specification semantic graph is formally mapped to an FSM state transition table, wherein each state node in the FSM state transition table is associated with a corresponding structured constraint rule in the structured constraint rule base; the FSM state transition table is compiled into an FSM runtime instance;

[0009] S3. In the loop of calling the large language model for code generation, the FSM running instance is used to monitor each atomic execution step of the large language model in real time;

[0010] S4. After each token is generated, the compliance verification in the real-time monitoring is performed based on the structured constraint rules associated with the current FSM state and the current state node; when the generation behavior is detected to violate the structured constraint rules, the corresponding gating mechanism is triggered and local correction is performed; if the verification is successful, code generation continues.

[0011] The following technical effects can be achieved through this invention:

[0012] 1. This invention utilizes an FSM runtime instance to perform prediction and judgment at the instant each token is generated. This atomic-level control mechanism establishes a forced constraint flow in the unclosed streaming intermediate state, fundamentally blocking the accumulation of drift features and ensuring endogenous convergence at every step of the model inference process.

[0013] 2. This invention uses a specification semantic graph to directly reduce the dimensionality of high-level design specifications such as multi-layered architecture and inter-layer call prohibitions to hard transition conditions of the underlying state machine. This enables large language models to not only guarantee the correctness of local syntax in industrial-grade code generation with long sequence dependencies, but also to ensure that the generated overall structure achieves pixel-level strict consistency with the preset global architecture topology network.

[0014] 3. This invention deeply couples compliance verification with the streaming generation loop. Once a violation tendency is detected, the gating mechanism and local corrector at the breakpoint immediately intervene. Through rule-driven, in-situ correction is completed within milliseconds, avoiding the huge computational waste of "generating and then reporting errors, followed by a full reconstruction" in traditional methods, thus minimizing the cost of code repair.

[0015] 4. This invention can seamlessly adapt to various industrial-grade architecture standards. When the architecture specification changes, only the external specification semantic graph and the FSM state transition table need to be updated to achieve a smooth upgrade of the control logic. Therefore, it has extremely high engineering practical value and dynamic maintenance convenience.

[0016] According to some embodiments of the present invention, the method further includes: after each token is generated, concatenating the generated token to the current local code fragment, and performing incremental parsing on the concatenated local code fragment through an incremental syntax tree analyzer to dynamically update the incremental abstract syntax tree; based on the latest node state of the incremental abstract syntax tree, determining whether the conditions for triggering an FSM state transition are met; if so, triggering a state transition and updating the current FSM state; otherwise, retaining the current FSM state and continuing to accumulate subsequently generated tokens.

[0017] The above embodiments overcome the bottleneck that incomplete text in autoregressive code generation cannot be parsed by traditional static compilers. Instead of performing a full re-parsing after appending tokens, a streaming, local incremental refresh is used to maintain the abstract syntax tree, significantly reducing computational overhead. This allows for real-time transformation of micro-symbol changes into the logical deduction of the macro-state machine, achieving temporal alignment between code structure evolution and state machine control flow.

[0018] According to some embodiments of the present invention, the method further includes: when performing incremental parsing on the concatenated local code fragment, if an incomplete syntax is parsed, generating a dangling node; and determining whether the conditions for triggering an FSM state transition are met based on the latest node state of the incremental abstract syntax tree, including: determining whether the updated incremental abstract syntax tree has syntax errors, semantic errors, and architectural constraint errors; and dynamically triggering a gating mechanism according to the detected violation level to execute an immediate interruption strategy, a delayed intervention strategy, or a recording warning strategy.

[0019] The above embodiments utilize "dangling nodes" for placeholder evaluation, enabling the system to be fault-tolerant in autoregressive inference with incomplete code, preventing crashes and errors. Based on this, three layers of verification—syntax, semantics, and architecture—are implemented, with tiered gating strategies applied according to the severity of violations. This ensures that architectural red lines are not crossed through immediate interruption or delayed intervention, while maximizing the continuity of model generation through an early warning mechanism.

[0020] According to some embodiments of the present invention, the method further includes: calculating the kernel violation count (KVC) and / or structural complexity volatility (SCV) based on the state of each node in the incremental abstract syntax tree; dynamically determining the risk status of the current generation process based on the comparison results of the current values ​​of the KVC and SCV with their respective preset thresholds; adaptively adjusting the sampling parameters of the large language model by calling a preset parameter mapping table according to the determined risk status; and generating a token according to the updated sampling parameters.

[0021] Through the above embodiments, a feedback adjustment closed loop based on the evolution trend of code intermediate states was constructed. The system cross-correlates the kernel violation count (KVC) and structural complexity volatility (SCV) to assess multidimensional risk. Once an indicator becomes abnormal, the sampling parameters (such as temperature) can be adaptively tightened or loosened through a parameter mapping table. This forces the model to revert to a low-randomness compliance trajectory when it exhibits a violation tendency, ensuring the determinism of the output structure.

[0022] According to some embodiments of the present invention, parsing the architecture specification document includes parsing and obtaining syntax layer constraints, semantic layer constraints, and architecture layer constraints; the structured constraint rules include rule identifiers, rule types, constraint conditions, triggering conditions, correction suggestions, and priorities.

[0023] Through the above embodiments, a multi-dimensional constraint expression specification was established. The design specification was deconstructed into three layers of constraints: syntax, semantics, and architecture, achieving comprehensive control. The introduction of multi-dimensional metadata improved the parsing and matching accuracy when FSM nodes mount rules, and the priority mechanism ensured deterministic scheduling when multiple rules conflicted.

[0024] According to some embodiments of the present invention, calculating the structural complexity variability (SCV) includes: traversing each node in the current incremental abstract syntax tree, and calculating the complexity of each node using different complexity calculation rules according to the node state type; summing the complexity of all nodes in the current incremental abstract syntax tree to obtain the current total complexity; subtracting the current total complexity from the total complexity at the previous time step and taking the absolute value to obtain the final SCV value; the node state type includes complete nodes, incomplete nodes, and dangling nodes.

[0025] The above embodiments provide a quantification method for streaming intermediate code. By performing differentiated weighted calculations on complete, incomplete, and dangling state nodes and comparing the total complexity difference between adjacent time series, the dynamic fluctuations in code structure caused by model inference are accurately captured, providing quantifiable data support for the adaptive adjustment of sampling parameters.

[0026] According to some embodiments of the present invention, the method further includes: intercepting the original predicted probability distribution of the large language model for the next token in real time before each token generation sampling; determining the set of tokens that can be generated based on the current FSM state and the associated structured constraint rules, adjusting the token probability distribution in the token set, and sampling tokens based on the adjusted token probability distribution.

[0027] The above embodiments implement a pre-emptive interception control mechanism. Before sampling occurs, the original Logits probability distribution is intercepted, and probabilistic penalties or zeroing are applied to non-compliant tokens, thus limiting them to the compliance whitelist. This pre-emptive reshaping and post-emptive correction form a combined defensive strategy, effectively preventing idle computing power caused by frequent interruptions and modifications.

[0028] According to some embodiments of the present invention, the execution immediate interruption strategy includes performing the following actions: freezing the current FSM state and generation context; analyzing the root cause of the violation and determining the correction strategy; invoking the local corrector for automatic correction or waiting for manual intervention; after the correction is completed, restoring the FSM state and context; and continuing to generate code from the breakpoint.

[0029] Through the above embodiments, a protection mechanism for in-situ freezing and breakpoint resumption has been established. In the event of a serious violation, it can "freeze" the state machine data and text in situ, similar to an operating system interruption, preventing errors from contaminating the context. After completing root cause analysis and in-situ correction, the state is seamlessly restored, avoiding the hidden overhead of a complete overhaul and ensuring the continuity of the generation chain.

[0030] This application also proposes a process-controlled code generation device, wherein the system includes a processor and a memory, the memory stores a computer program, and the processor executes the computer program to implement the code generation method.

[0031] This application also proposes a computer program product, including a computer program, wherein the computer program, when executed by a processor, implements the code generation method described above. Attached Figure Description

[0032] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used are briefly described below:

[0033] Figure 1 A schematic diagram of the overall architecture of a process-controlled code generation system for large language models (hereinafter referred to as Sentinel-K system) according to some embodiments of the present invention is shown.

[0034] Figure 2A flowchart illustrating a process-controlled code generation method for large language models according to some embodiments of the present invention is provided.

[0035] Figure 3 A flowchart illustrating a process-controlled code generation method for large language models according to some embodiments of the present invention is provided.

[0036] Figure 4 A flowchart illustrating the constraint check process according to some embodiments of the present invention is shown;

[0037] Figure 5 A gating decision flowchart is shown according to some embodiments of the present invention;

[0038] Figure 6 A flowchart illustrating partial corrections according to some embodiments of the present invention is shown;

[0039] Figure 7 A schematic structural diagram of a process-controlled code generation device for large language models according to some embodiments of the present invention is shown. Detailed Implementation

[0040] The present invention will now be described by way of example with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. In particular, this application has provided a detailed description of each module and each process step involved in the various embodiments of the present invention. To avoid repetition, the description of the process steps in the present invention does not completely repeat the content of the preceding module sections. However, those skilled in the art will understand that the process actions described in the various module sections are also applicable to... Figure 2-6 The process steps involved may be applicable to further refining the latter.

[0041] like Figure 1As shown, the system architecture of the Sentinel-K model according to some embodiments of the present invention is divided into three main layers: a reduction parsing layer 110, a controlled execution layer 120, and a metric monitoring layer 130. The reduction parsing layer 110 includes an architecture reduction parsing module 111 and a reduction-FSM mapping engine 113, responsible for converting user-provided architecture specifications into formalized FSM state transition tables. The controlled execution layer 120 includes a finite state automaton FSM modeling module 121 (referred to as the FSM modeling module), a constraint rule engine 122, an atomic execution monitoring module 123, a gating mechanism module 124, and a local corrector 125, used to achieve real-time control of the generation process. The metric monitoring layer 130 includes a process metric engine 131 and an adaptive sampling controller, responsible for calculating and tracking metrics such as KVC and SCV, and feeding the metric results back to the adaptive sampling controller (not shown in the figure) for sampling parameter adjustment. The metric monitoring layer 130 also includes a context management module 132 and a human-computer interaction interface 133. The modules interact through clear interfaces, with data flowing from top to bottom and control feedback from bottom to top, forming a closed-loop control system. Exemplary embodiments of each module are described in further detail below.

[0042] Architecture specification parsing module

[0043] This module is responsible for parsing user-provided architecture specification documents (which can be natural language descriptions, UML diagrams, interface definition files, etc.) into formalized constraint rules. It supports various specification formats as input, including: Natural language specifications: extracting key constraint information using natural language processing techniques; Interface definition files: parsing API documents, IDL files, and other interface specifications; Architecture diagrams: extracting module relationships and interface constraints from UML class diagrams and component diagrams; Code comments: extracting design constraints from comments and docstrings in existing code.

[0044] The parsing process is divided into three levels: (1) Syntax constraints: including programming language syntax specifications, naming conventions, code style, etc.; (2) Semantic constraints: including type consistency, interface compatibility, data flow correctness, etc.; (3) Architectural constraints: including module division, call relationships, dependency constraints, deployment specifications, etc. The parsing results generate a structured constraint rule base. Each rule can contain metadata such as rule identifier, rule type, constraint conditions, trigger conditions, correction suggestions, and priority. The rule base is hierarchically organized and supports complex relationships such as rule inheritance, overriding, and combination.

[0045] Specification - FSM Mapping Engine

[0046] This engine is responsible for mapping user-provided architecture specification documents, such as natural language architecture specifications or UML diagrams, to FSM state transition tables, achieving a transparent transition from the architecture layer to the token level. According to some embodiments of the present invention, the mapping includes the following three-layer mapping method:

[0047] The first layer, the specification semantic extraction layer, performs dependency parsing on the natural language specification to extract key entities (modules, classes, methods, relationships); performs syntactic parsing on the UML diagram to extract class diagram elements (classes, interfaces, inheritance, implementations, associations); and constructs a specification semantic graph (SG).

[0048] The second layer, pattern recognition and abstraction, identifies architectural design patterns (such as MVC, Repository, Factory, etc.); it traverses a pre-defined design pattern library, matching the specification semantic graph with the design pattern library (for example, first identifying architectural design patterns in the architectural specification document or specification semantic graph, such as MVC, Repository, Factory, etc.); based on the matching results, it selects the corresponding FSM template; if no corresponding FSM template exists, it generates a custom FSM structure.

[0049] The third layer, State Unfolding and Encoding Layer, unfolds the FSM template (or a custom FSM structure) into specific state nodes and transition edges; encodes the associated constraint rules for each state node; and generates the FSM State Transition Table (STT).

[0050] FSM mapping table structure:

[0051] {

[0052] "state_id": A unique identifier for the state.

[0053] "state_type": State type (CLASS_DECL / METHOD_DECL, etc.)

[0054] "enter_conditions": [A list of prerequisite conditions for entering this state],

[0055] "exit_conditions": [a list of postconditions for leaving this state],

[0056] "allowed_transitions": [List of allowed next transitions],

[0057] "forbidden_transitions": [List of forbidden next transitions],

[0058] "constraint_rules": [List of associated constraint rule IDs],

[0059] "token_pattern": [The token pattern that triggered this state],

[0060] "context_requirements": [context requirements]

[0061] }

[0062] The following is an example mapping algorithm flow.

[0063] Input: Natural Language Specification Document or UML Diagram File

[0064] deal with:

[0065] Step 1: Reduction parsing → Reduction semantic graph (SSG)

[0066] Step 2: Pattern Recognition → FSM Template Matching

[0067] Step 3: Template Instantiation → State Node Generation

[0068] Step 4: Constraint Association → Rule and State Binding

[0069] Step 5: Transition Derivation → State Transition Table Generation

[0070] Step 6: Encoding optimization → FSM executable output

[0071] Output: FSM State Transition Table (STT)

[0072] The following is a mapping example. Assuming the architecture specification requires the implementation of the Repository pattern, the mapping engine's processing is as follows: Pattern Identification: Identify the Repository design pattern; Template Matching: The Repository pattern corresponds to a set of standard FSM states; State Expansion: Generate states such as InterfaceDecl, ImplClassDecl, and MethodDecl; Constraint Association: InterfaceImplConstraint (interface implementation constraint), MethodSignatureConstraint (method signature constraint); Transformation Generation: InterfaceDecl → ImplClassDecl → MethodDecl → END.

[0073] Finite State Automaton (FSM) Modeling Module

[0074] The Finite State Automaton (FSM) modeling module is used to model the code generation process as a finite state automaton. Its core idea is to map the structural features of the code to the states of the state machine and the code generation logic to state transitions.

[0075] The state definitions include: Initial state: the state at the start of code generation; Interface definition state: generating class / module interface definitions; Property definition state: generating class / module properties; Method signature state: generating method / function signatures; Method body state: generating method / function implementation bodies; Exception handling state: generating exception handling code; State transition state: returning after a subroutine call; Termination state: code generation is complete.

[0076] State transition conditions: Each state transition is accompanied by constraint checks; a state transition can only occur if specific constraints are met. For example: from the interface definition state to the property definition state, it is necessary to check whether the interface is fully defined; from the method signature state to the method body state, it is necessary to check whether the method signature conforms to the interface specification; from the method body state to the state transition state, it is necessary to check whether the method implementation is complete and correct.

[0077] Safety Constraints: A safety constraint mechanism is introduced based on the FSM to define which state combinations are safe and which transitions are prohibited. Safety constraints include: Unreachable State Constraints: Prohibit entry into invalid states; Cyclic Constraints: Limit the number of state transition cycles to avoid infinite loops; Constraint Conservation Constraints: Ensure that critical constraints are always satisfied during state transitions; Termination Constraints: Ensure that the generation process reaches a finite number of termination states.

[0078] FSM employs a deterministic finite automaton (DFA) modeling approach, ensuring that the transitions of each state under a given input are deterministic, thereby guaranteeing the repeatability and predictability of the generation process. Furthermore, FSM supports dynamic state expansion, automatically adjusting the size and complexity of the state machine based on the complexity of the architecture specification.

[0079] Incremental state mechanism

[0080] To address the atomicity issue of token-level triggering, this invention introduces an incremental state mechanism, where the incremental state = (main state, buffer, prepared token sequence). For example: the main state is CLASS_DECL (class declaration state); the buffer is "cl" (a received but incomplete token); and the prepared token sequence is ["cl", "ass"] (tote fragments to be merged). When the token "cl" is received, the system does not immediately trigger a state transition. Instead, it: 1. Adds the token to the buffer; 2. Checks if the buffer forms a complete syntactic unit; 3. If a complete syntactic unit (such as "class") is formed, a state transition is triggered; 4. If a complete syntactic unit is not formed, the current state is maintained and the buffer is updated.

[0081] Constraint rule engine

[0082] The constraint rule engine is responsible for managing and executing all constraint rules. This engine employs a rule-based reasoning mechanism, supporting efficient rule matching and conflict detection. According to some embodiments of the present invention, in terms of rule representation, each constraint rule is represented by a triple: (condition, action, priority). The condition part defines when the rule is triggered and may include: contextual conditions: the current generated code location, already generated code snippets, etc.; state conditions: the current state of the FSM; semantic conditions: the semantic characteristics of the generated code, such as type, reference relationships, etc.; and architectural conditions: the degree of conformity with the architectural specifications.

[0083] The action section defines the operations to be performed after a rule is triggered, including: Allow generation: continue the normal code generation process; Interrupt generation: pause the current generation and wait for manual intervention or automatic correction; Force correction: automatically modify the generated code to meet the constraints; Rollback operation: undo part of the generated content and regenerate; Record warning: generate warning information without interrupting the process.

[0084] Rule Execution: The rule engine uses the Rete algorithm to optimize rule matching efficiency and supports incremental rule updates. When a new token is generated, the rule engine matches all applicable rules in real time and determines which rule to execute based on its priority. When multiple rules are triggered simultaneously, a priority arbitration mechanism is used to ensure that key constraints are satisfied first.

[0085] Rule Conflict Detection and Resolution: The rule engine can detect conflicts between rules, including condition conflicts and action conflicts. For conflicting rules, the following strategies are used to resolve them: Priority Strategy: Execute higher-priority rules first; Specialization Strategy: Select rules with more specific conditions; Constraint Strategy: Select rules with stricter constraints; Combination Strategy: Combine the actions of multiple rules for execution.

[0086] Incremental Abstract Syntax Tree Analyzer

[0087] Traditional AST parsers require syntactically complete code and cannot handle incomplete code generated during the generation process. Large Language Models (LLMs) generate code in an "autoregressive" manner, outputting tokens one by one. This means that for 99% of the time, the code is in an "incomplete" intermediate state. If a traditional AST parser is used to monitor a large model, it will continuously report errors and crash, making it impossible to calculate cyclomatic complexity in real time. Parsing can only begin after the large model has written hundreds of lines of code. This results in severe monitoring lag, meaning that "current technology can only perform static post-processing."

[0088] The "Incremental Abstract Syntax Tree (IST)" of this invention breaks the limitation of traditional AST parsers requiring "perfect closure". When encountering if(x>0){, it does not crash, but instead generates a "dangling node" and a "slot", telling the system: "I know there is an incomplete if structure here, I'll reserve a space for it to estimate the complexity, and I'll complete it when the later tokens arrive." This allows the invention to achieve "real-time generation, monitoring, and evaluation", and the incremental analysis can be detected at the millisecond level.

[0089] The incremental abstract syntax tree technique of this invention enables structural analysis of intermediate code.

[0090] The incremental parsing process of the incremental abstract syntax tree is as follows:

[0091] Step 1: Construct an incremental AST (Incremental Abstract Syntax Tree) to efficiently update the syntax tree when introducing newly generated tokens, without having to re-parse the entire code from scratch. This includes: S11. Locating changed regions: By comparing with the incremental AST (IST_prev) from the previous time step, the system finds the last complete node, thus only extracting newly generated or changed local code regions; S12. Incremental parsing: The system reuses the unchanged code syntax tree portion from the previous time step, only re-parseing the newly changed regions (incremental_parse). This greatly reduces computational overhead; S13. Handling dangling nodes: When parsing a position with incomplete syntax (such as only outputting if(x>0){), the system does not report an error, but generates a "dangling node" to prepare for subsequent complexity estimation.

[0092] Step 2: SCV calculation.

[0093] Complexity calculation: The system traverses each node in the current incremental AST, applying different complexity calculation rules based on the node's state: For COMPLETE nodes: standard cyclomatic complexity calculation rules are used (e.g., incrementing by 1 for a complete if branch). For PARTIAL nodes: fuzzy estimation is performed based on the currently constructed syntax structure (e.g., if / for / while) combined with its fill factor (existing token sequence). For DANGLING nodes: marked as "in progress," a preset complexity contribution value is directly assigned (0.5 in the code). The final SCV value is obtained by subtracting the total complexity (CC_current) of all nodes in the current syntax tree from the total complexity (CC_prev) of the previous time step.

[0094] Incremental AST node structure:

[0095] {

[0096] "node_id": A unique identifier for a node.

[0097] "node_type": Node type (FunctionDef / IfStmt, etc.)

[0098] "status": Node status (COMPLETE / PARTIAL / DANGLING)

[0099] "children": [list of child nodes],

[0100] "token_range": [starting token position, ending token position],

[0101] "partial_token": The current incomplete token (if any).

[0102] "estimated_cyclomatic_complexity": Estimated cyclomatic complexity.

[0103] "parent_node": Reference to the parent node

[0104] }

[0105] Logits constraint filter

[0106] The Logits constraint filter of this invention differs from existing hard filtering (which directly blocks disallowed tokens). This invention employs a soft filtering approach combined with probability adjustment, achieving effective constraints while maintaining generation flexibility. The following describes the implementation process of the Logits constraint filter according to some embodiments of this invention:

[0107] 1. Generation of Token Candidate Sets

[0108] LLM outputs the original Logits distribution.

[0109] The probability distribution P(token) of the token is obtained through Softmax.

[0110] Select the top-K candidate tokens to form a candidate set C.

[0111] 2. FSM constraint matching

[0112] Based on the current FSM state and specification constraints, generate an allowed token set A.

[0113] Forbidden Token Set F

[0114] Optional but encouraged set of tokens E

[0115] 3. Probability Adjustment

[0116] For tokens in A∩C: the probability remains the same or slightly increases.

[0117] For tokens in AC: probability is reduced but not reduced to zero.

[0118] For tokens in F∩C: the probability is greatly reduced, but a small probability is still retained.

[0119] 4. Resampling

[0120] Resampling based on the adjusted probability distribution

[0121] If a token in F is sampled N times consecutively, a warning is triggered.

[0122] Logits filter data structure:

[0123] Logits filtering context:

[0124] {

[0125] "current_fsm_state": Current FSM state.

[0126] "constraint_mask": {

[0127] "allowed_tokens": The set of allowed tokens A,

[0128] "forbidden_tokens": The set of forbidden tokens F,

[0129] "encouraged_tokens": The set of encouraged tokens E

[0130] },

[0131] "probability_adjustments": {

[0132] "token_id": Probability adjustment coefficient

[0133] },

[0134] "sampling_history": [The most recent N sampling records]

[0135] }

[0136] The following describes predictive intervention strategies according to some embodiments of the present invention.

[0137] Input: Raw LLM Logits, current FSM state, constraint rules

[0138] deal with:

[0139] Step 1: State Prediction

[0140] Predict the next state based on the current state and context.

[0141] Predict possible state sequences: S(t+1), S(t+2), ...

[0142] Step 2: Assessment of the probability of violation

[0143] For each candidate token, assess the probability P_violation that it will trigger a violation.

[0144] P_violation = f(token, S(t), rules)

[0145] Step 3: Intervention Decision

[0146] If P_violation > THRESHOLD_HIGH: Force filtering

[0147] elif P_violation > THRESHOLD_LOW: Reduce weighting

[0148] else: Keep the original probability

[0149] Step 4: Feedback Update

[0150] Record this intervention decision

[0151] Used to optimize subsequent prediction models

[0152] Output: Adjusted Logits distribution

[0153] Atomic Execution Monitoring Module

[0154] The atomic execution monitoring module performs real-time monitoring at each token generation step, and its core function is to detect whether the generation behavior violates the constraint rules.

[0155] Monitoring Granularity: The smallest granularity of monitoring is the atomic execution step, i.e., the generation of a single token. After each token is generated, the monitoring module immediately checks: Syntax correctness: whether the generated code snippet conforms to the syntax specification; Type consistency: whether the type of the newly generated token matches the context; Reference validity: whether the newly introduced identifier is defined or importable; Constraint satisfaction: whether any architectural specification constraints are violated.

[0156] Monitoring Algorithm: Employs a combination of static analysis and dynamic checks. Static analysis predicts potential constraint violations before generation, while dynamic checks verify actual violations after generation. Algorithm Steps: 1. Before generating the next token, predict potential violations based on the current context; 2. If a high-risk violation is predicted, adjust the generation strategy or provide constraint hints in advance; 3. After token generation, immediately perform a complete constraint check; 4. If a violation is detected, trigger the gating mechanism; 5. Record violation information and update metrics. Violation Classification: Based on the severity and correctability of the violation, violations are classified into three categories: P0 violation (serious violation, generation must be immediately interrupted, such as type errors, syntax errors, etc.); P1 violation (moderate violation, can be automatically corrected, such as non-standard naming, formatting issues, etc.); P2 violation (minor violation, only requires generating a warning, such as code style issues, etc.). According to some embodiments of the present invention, the prediction of possible constraint violations before generation includes: intercepting the original predicted probability distribution of the large language model for the next token in real time before each token generation sampling; calculating the set of legal tokens that meet the constraints in real time based on the current FSM state and the associated structured constraint rules; adjusting the predicted probability of tokens that do not meet the state transition constraints or the structured constraint rules to a preset penalty value or zero based on the set of legal tokens; and sampling tokens based on the adjusted probability distribution.

[0157] Gating mechanism module

[0158] The gating mechanism module is responsible for deciding how to intervene and control when violations are detected. The gating mechanism employs a multi-layered decision-making strategy, making a comprehensive judgment based on factors such as the type of violation, contextual information, and historical data.

[0159] Gating strategy:

[0160] Immediate interruption strategy: For P0 violations, the generation process is immediately interrupted and the system enters correction mode;

[0161] Delayed intervention strategy: For P1 violations, continue to generate but record the violations, and perform batch corrections at an appropriate time;

[0162] Warning logging policy: For P2 violations, only a warning is logged, and generation is not interrupted;

[0163] Predictive intervention strategy: When a potential risk of violation is detected, the generation strategy is adjusted in advance to prevent violations from occurring;

[0164] Interrupt handling process:

[0165] When the interrupt policy is triggered, the gating mechanism processes the data according to the following procedure:

[0166] State Freeze: Freezes the current FSM state and generation context;

[0167] Violation analysis: Analyze the root causes of violations and determine corrective strategies;

[0168] Correction Execution: Invoke the local corrector for automatic correction, or wait for manual intervention;

[0169] State restoration: After the correction is complete, restore the FSM state and context;

[0170] Continue generating: Continue generating code from the breakpoint.

[0171] Gated decision model

[0172] Gating decisions are based on a comprehensive evaluation of multiple factors, including: severity of violation: P0 / P1 / P2 level; frequency of violation: historical occurrence rate of this type of violation; contextual importance: importance of the currently generated part in the entire system; difficulty of correction: difficulty and success rate of automatic correction; and manual cost: cost required for manual intervention.

[0173] The decision-making model employs a weighted scoring mechanism, assigning weights to each factor, calculating a comprehensive score, and determining the gating strategy based on the score. The weight parameters can be optimized using historical data and machine learning.

[0174] Local corrector

[0175] The local corrector is responsible for automatically correcting detected violations. The corrector employs various techniques, including rule-based correction and lightweight LLM (Lightweight Large Language Model) collaborative correction.

[0176] Correcting technical classifications

[0177] 1. Rule-driven deterministic correction, which includes: for syntax errors (such as mismatched parentheses or missing semicolons), deterministic rules are used to correct them. The correction logic is based on a preset syntax repair rule library and does not involve LLM calls, ensuring the determinism and real-time nature of the correction.

[0178] 2. Semi-deterministic correction driven by architectural patterns, which includes: correcting architectural violations (such as cross-layer calls) based on architectural patterns provided by the specification-FSM mapping engine; the correction process includes: violation detection → pattern matching → architectural refactoring; the architectural refactoring scheme is predefined by the FSM state machine to ensure the compliance of the correction.

[0179] 3. Lightweight LLM collaborative correction, which includes: for complex semantic correction requirements, calling a lightweight LLM for collaborative correction. The lightweight LLM only processes local code snippets and does not involve the overall generation; the correction request includes context constraints, limiting the scope of the LLM correction; the correction result takes effect after rule verification.

[0180] Correct strategy selection algorithm:

[0181] Input received: violation record V, code context C

[0182] Perform the following steps:

[0183] Step 1: Violation classification, where if V is a syntax / format class: jump to rule correction; if V is an architectural pattern class: jump to pattern correction; if V is a complex semantic class: jump to LLM correction.

[0184] Step 2: Rule correction, which includes matching syntax / format rules, performing deterministic modifications, verifying the modification results, and outputting the correction results.

[0185] Step 3: Pattern correction, which includes obtaining the current architecture state from the FSM, matching the refactoring template, performing structured refactoring, verifying architecture consistency, and outputting the correction results.

[0186] Step 4: LLM correction, which includes: building constraint hints, calling the lightweight LLM, validating the LLM output, if the validation fails, downgrading to rule / pattern correction, and outputting the correction result.

[0187] In existing gating technologies, if code generation fails, it typically rolls back N tokens and re-encodes, leading to low generation efficiency. In this invention, when gating triggers an interrupt, the system "freezes" the semantic state of the current FSM, calls a local corrector to perform targeted adjustments, and then "hot-recovers" from the breakpoint. This state machine-based "breakpoint continuation" capability makes the gating mechanism of this invention more than just simple 'admission control,' but a closed-loop micro-operating system with context observation and execution state backtracking capabilities. This deep control mechanism is key to solving the stability problem of industrial-grade code generation and is fundamentally different from current techniques that rely solely on regular expressions or syntax trees for filtering.

[0188] Adaptive sampling controller

[0189] Based on kernel violation count (KVC), structural complexity volatility (SCV), and the current sampling parameters (Temperature, Top-P, Top-K) of the large language model, the controller transforms process monitoring indicators into process control actions to achieve dynamic closed-loop regulation of the generation process.

[0190] Status Determination Phase: The controller first determines the risk status of the generation process by comparing the current values ​​of KVC and SCV with their respective preset thresholds. Specifically, if KVC exceeds the severity threshold, it is determined to be in a "high-risk" state; if KVC exceeds the warning threshold but does not reach the severity threshold, it is determined to be in a "warning" state; if KVC does not exceed the limit but SCV exceeds the severity threshold, it is determined to be in a "structural change" state; if SCV only exceeds the warning threshold, it is determined to be in a "fluctuation" state; if neither indicator exceeds its respective threshold, it is determined to be in a "stable" state.

[0191] Parameter Adjustment Phase: Based on the aforementioned state determination, the controller implements differentiated adaptive adjustments to the sampling parameters. In the "High-Risk" state, to force the model output to converge to the compliance boundary, the controller significantly tightens randomness: halving the Temperature parameter, compressing Top-P to 0.8 times its original value (with an upper limit of 0.9), and reducing Top-K by 10 (with a lower limit of 20). In the "Alert" state, the controller moderately reduces randomness: adjusting Temperature to 0.8 times its original value and Top-P to 0.9 times its original value. In the "Structural Change" state, the controller guides generation towards stability while allowing some exploration space: adjusting Temperature to 0.7 times its original value and Top-P to 0.85 times its original value (with a lower limit of 0.85 to ensure no over-tightening). In the "Fluctuating" state, only slight intervention is performed: adjusting Temperature to 0.9 times its original value. In the "Stable" state, parameters such as Temperature and Top-P remain unchanged.

[0192] Boundary check phase: After the above adjustments are completed, the controller performs a validity check on each parameter to ensure that the adjusted Temperature falls within the closed interval of 0.0 to 2.0, Top-P falls within the closed interval of 0.0 to 1.0, and Top-K falls within the closed interval of 1 to 100, so as to prevent the parameters from going out of bounds and causing sampling abnormalities.

[0193] Historical record phase: Finally, the controller persistently saves the parameter values ​​before and after the adjustment, and records the KVC and SCV metrics that triggered this adjustment, forming a complete adjustment history log, which provides data support for subsequent process backtracking, trend analysis and strategy optimization.

[0194] Process Measurement Engine

[0195] The process metrics engine is responsible for calculating and tracking various metrics of the generation process in real time, providing quantitative basis for process evaluation and optimization. This invention proposes two core metrics.

[0196] Kernel Violation Count (KVC):

[0197] The KVC metric is used to characterize the strength of constraint corrections during the generation process, and is defined as the number of constraint violations per unit code length.

[0198] Calculation formula:

[0199] KVC = (Total number of violations) / (Total number of tokens generated)

[0200] KVC reflects the stability of the generation process; the lower the KVC value, the more stable the generation process and the fewer violations. KVC can be further subdivided according to violation type: KVC_syntax: syntax violation count; KVC_semantic: semantic violation count; KVC_architecture: architecture violation count.

[0201] The trend of KVC can reflect the dynamic characteristics of the generation process. For example: KVC continuously rising indicates that the generation process is becoming increasingly unstable and needs to be adjusted in terms of constraints or strategies; KVC continuously falling indicates that the generation process is gradually stabilizing and the constraint configuration is reasonable; KVC suddenly soaring indicates that constraints that are difficult to satisfy have been encountered and manual intervention may be required.

[0202] Structural complexity volatility (SCV):

[0203] The SCV metric is used to characterize the degree of change in code structure stability during the generation process. This invention solves the problem of calculating the complexity of intermediate code through an incremental abstract syntax tree analyzer.

[0204] Calculation formula:

[0205] SCV = |CC(t+1), the average value of CC(t)|

[0206] The complexity is calculated using incremental cyclomatic complexity: For complete syntax nodes: standard cyclomatic complexity is used (branch + 1); for partial syntax nodes: estimation is based on structure type (each branch type contributes 0.5-1.0); for dangling nodes: marked as "in progress", contributing 0.5.

[0207] Other auxiliary metrics:

[0208] In addition to KVC and SCV, the engine also tracks the following auxiliary metrics: Generation speed: the number of tokens generated per unit time; Correction success rate: the success rate of automatic correction; Human intervention rate: the proportion requiring human intervention; Constraint satisfaction rate: the proportion of generated code that satisfies constraints; Sampling parameter history: records the adjustment trajectory of parameters such as temperature and Top-P; Violation pattern sequence: records the temporal pattern of violations.

[0209] Context Management Module

[0210] The context management module is responsible for maintaining all context information during the code generation process, providing context query and update services for other modules. Context information includes: code context (generated code snippets); current generation location; code syntax tree; incremental abstract syntax tree state; state context: current FSM state; state transition history; state transition constraints; incremental buffer state; constraint context: triggered constraint rules; constraint violation records; constraint satisfaction status; Logits filtering context; metric context: current KVC value; current SCV value; current values ​​of other metrics; sampling parameter history; metadata context: generation start time; number of generated tokens; consumed computing resources; and specification-FSM mapping table references.

[0211] Context query service

[0212] The module provides an efficient query interface that supports: querying code snippets by location; querying historical status by time; querying constraint records by type; querying metrics by time range; and querying FSM transformation history by status.

[0213] Context update service

[0214] When a new token is generated or a state transition occurs, the module automatically updates the relevant context information to ensure context consistency and real-time performance. Update operations employ an incremental update strategy to avoid full-scale reconstruction and improve performance.

[0215] Figure 2 A flowchart illustrating a process-controlled code generation method for large language models according to some embodiments of the present invention is shown; as shown in the figure, the method includes S1-S4:

[0216] S1. Receive the architecture specification document provided by the user, parse the architecture specification document, and construct a structured constraint rule base and specification semantic graph based on the parsing results.

[0217] Users can provide a MISRA-C security architecture specification document for the sensor readout module. Upon receiving this document, the system performs deep analysis, extracting all hard programming restrictions and transforming them into machine-readable structured constraint rules, which are then stored in a constraint rule base. Simultaneously, the system analyzes the entire sensor module's topology, such as how data flows from the underlying hardware registers into the filtering algorithm and then from the filtering algorithm to the upper-layer application interface. The system constructs a specification semantic graph from these inter-module call relationships, data flow, and the boundary conditions they must adhere to.

[0218] S2. The specification semantic graph is formally mapped to an FSM state transition table, wherein each state node in the FSM state transition table is associated with a corresponding structured constraint rule in the structured constraint rule base; the FSM state transition table is compiled into an FSM runtime instance.

[0219] In this step, the semantic graph is mapped to a FSM state transition table with multiple states. Then, the system precisely binds specific entries from the structured constraint rule base to these state nodes.

[0220] S3. In the loop of calling the large language model for code generation, the FSM running instance is used to monitor each atomic execution step of the large language model in real time.

[0221] In each state, the running instance loads the compliance rules associated with that state and performs real-time compliance checks on the model’s current output or output tendency, ensuring that every inference and logical jump of the large language model is completely within the preset security and compliance track.

[0222] S4. After each token is generated, the compliance verification in the real-time monitoring is performed based on the structured constraint rules associated with the current FSM state and the current state node; when the generation behavior is detected to violate the structured constraint rules, the corresponding gating mechanism is triggered and local correction is performed; if the verification is successful, code generation continues.

[0223] Within the loop of the large language model generation sensor reading function, the system performs atomic-level real-time monitoring of each token. If a serious violation at the P0 level is detected, the system can immediately trigger a gating mechanism to perform local corrections, continuing to generate compliant code and ultimately successfully outputting fully compliant code.

[0224] Figure 3 A flowchart illustrating a process-controlled code generation method for large language models according to some embodiments of the present invention is shown, which mainly consists of three stages:

[0225] The first phase is the initialization phase: First, the architecture specification document is loaded; then, the specification-FSM mapping engine parses the specification and generates the FSM state transition table (at the same time, the specification is parsed to generate the constraint rule base, not shown in the figure); a finite state automaton is built; the FSM is initialized to the initial state; and the context manager and the adaptive sampling controller (not shown in the figure) are initialized in sequence.

[0226] The second phase is the generation loop phase: the system performs closed-loop control at each atomic execution step (Token level). After the loop begins, the Logits constraint filter first predictively filters and adjusts the probability distribution of the next Token based on the current FSM state and association rules. Subsequently, the large language model combines the current state and context to generate the next Token using the adjusted sampling parameters. Atomic execution monitoring checks for constraint violations. If a generation behavior is detected to violate structured constraint rules, the system will immediately trigger a gating mechanism decision. The gating mechanism determines the decision result according to a preset strategy (such as immediate interruption, delayed intervention, or warning recording). For immediate interruption, the state is frozen, and local corrections and verification of corrections are performed. If verification is successful, the state is restored; otherwise, manual intervention is requested. For delayed intervention or warning handling, the violation delay handling and warning are recorded respectively. If no violation has been detected previously, the metrics are updated.

[0227] Based on the output of the above five nodes (updating metrics, restoring status, requesting manual intervention, recording violation delays, and recording warnings), update the context and update the FSM status.

[0228] If the compliance check does not detect any violations (i.e., the check is successful), the system skips the correction mechanism and directly allows the generation loop to continue.

[0229] The third stage is the termination stage: continuously checking whether the termination condition or termination state has been reached in the loop; if so, the generated complete code is globally verified and the final compliant code result and measurement report are output; if not, the generation loop continues to execute.

[0230] The above and following processes can be summarized from the preceding steps. Figure 1 The various modules or engines described herein work together to achieve this. The following provides more exemplary implementations of the various process steps in the methods according to some embodiments of the present invention. These processes can be combined with each other to jointly achieve various solutions of the present invention.

[0231] The following describes a specification-FSM mapping process according to some embodiments of the present invention, which includes the following steps:

[0232] Step 1 is specification parsing, which involves performing NLP dependency parsing on the natural language to extract key entities, and simultaneously parsing the UML diagram using XML or YAML to extract class diagram elements, ultimately outputting a specification semantic graph (SSG).

[0233] Step 2 is pattern recognition. It iterates through the design pattern library (such as MVC, Repository, Factory, etc.), calculates the matching degree between the specification and each pattern, selects the design pattern with the highest matching degree, and outputs a list of recognized architecture patterns.

[0234] Step 3 is FSM template matching. Based on the identified pattern, the corresponding FSM template is loaded. This template defines the standard state structure and transition rules, and outputs an FSM template instance.

[0235] Step 4 is template instantiation, which replaces the placeholders in the FSM template with specific elements in the specification, such as mapping class names, method names, and interface definitions to state attributes, and outputs the concretized FSM state diagram.

[0236] Step 5 involves constraint association, which assigns the applicable constraint rules to each state association. These rules are derived from the specification parsing results and the rules inherent in the design pattern, and outputs a state-rule mapping table.

[0237] Step 6 generates the transition table, derives all possible state transitions, marks allowed and prohibited transitions, and outputs the FSM State Transition Table (STT).

[0238] Step 7 is encoding optimization, which encodes the state transition table into an executable format and optimizes the state query efficiency. Finally, the FSM executable file is output, thus obtaining the complete FSM state transition table and executable FSM.

[0239] The following describes a constraint check process according to some embodiments of the present invention.

[0240] Starting with receiving the raw LLM Logits, the process involves FSM state acquisition, token candidate set generation, violation probability prediction, probability adjustment, and re-normalization, finally outputting the adjusted token. This process embodies a predictive constraint mechanism: by using a Logits constraint filter to assess and adjust the violation probability before token sampling, it achieves early intervention for potential violations, unlike the hard filtering method of traditional Constrained Decoding. The specific execution steps of the constraint checking process are as follows:

[0241] Step 1 involves receiving the raw Logits from the LLM inference interface, obtaining the raw Logits vector, and converting it into a probability distribution using the Softmax function.

[0242] Step 2 is to obtain the FSM state. First, obtain the current FSM state, and then determine the set of tokens A that can be generated under the current state.

[0243] Step 3 is to generate the Token candidate set, extract the Top-K candidate Tokens, and generate the forbidden Token set F.

[0244] Step 4 is to predict the probability of violation. For each candidate token, the probability of violation P_violation is calculated. This probability is based on a comprehensive evaluation of the token's matching degree with the current state, historical violation patterns, and coverage of constraint rules.

[0245] Step 5 is probability adjustment, which executes the corresponding strategy according to the numerical range of P_violation: if P_violation is less than T1, the probability remains unchanged; if T1 is less than or equal to P_violation and less than T2, the weight is reduced; if P_violation is greater than or equal to T2, forced filtering is performed.

[0246] Step 6 is to renormalize the adjusted probabilities to ensure that the sum of all probabilities equals 1.

[0247] Step 7 is the sampling output, which samples based on the adjusted probability distribution and returns the final sampled token.

[0248] Figure 4 A flowchart illustrating the constraint check process according to some embodiments of the present invention is shown.

[0249] First, the generated token is received and appended to the current code snippet. Then, an incremental syntax tree (AST) is constructed.

[0250] After the build is complete, the system proceeds to the syntax check stage. The system determines if the syntax is correct. If incorrect, the process moves directly to the left branch, marking it as a P0 violation and jumping to the violation record update stage. If correct, the system proceeds to the semantic check stage. In the semantic check, the system sequentially performs type checks, checks reference validity, and checks scope rules. After these actions, the system checks for semantic errors. If errors are found, they are marked as P1 violations, and the system then proceeds to the architecture constraint check stage. If no semantic errors are found, the system directly proceeds to the architecture constraint check stage.

[0251] During the architecture constraint check phase, the system begins to traverse all architecture constraint rules and checks whether the current code satisfies each rule. If the code does not meet a rule, it is marked as a violation (P1 or P2), and then it is determined whether there are any remaining rules to check. If the code meets the rule, it is directly determined whether there are any remaining rules. As long as there are still unchecked rules, the process will loop back to the node that traverses all architecture constraint rules and continue execution.

[0252] Once all architectural rules have been checked (i.e., there are still rules that fail to meet the criteria), the process will end its loop and merge with the P0 violation branch caused by the previous syntax error, proceeding to the violation record update node. After the record update is complete, the process continues to update the KVC metric and finally returns the check result.

[0253] Figure 5 A gating decision flowchart according to some embodiments of the present invention is shown. As shown in the figure, the process includes:

[0254] Receive violation reports (first obtain the violation list from the atomic execution monitoring module) and analyze the severity and type of the violations.

[0255] To determine the level of violation, the corresponding strategy is implemented based on the violation: if there is a P0 level violation, an immediate interruption strategy is implemented; if there is a P1 level violation, the difficulty of correction is assessed; if there is only a P2 level violation, a warning recording strategy is implemented.

[0256] Assess the difficulty of correction: For P1 level violations, analyze the possibility of automatic correction and calculate the expected success rate of correction; if the success rate is higher than the threshold, execute automatic correction; otherwise, request manual intervention.

[0257] Decision Execution: Take action based on the assessment results: If immediate interruption is selected, the state is frozen and correction mode is entered; if delayed intervention is selected, the violation is recorded and corrected at an appropriate time; if warning recording is selected, generation continues after the warning is recorded.

[0258] Update the SCV metric: Calculate the current structural complexity to obtain the SCV value.

[0259] Trigger adaptive sampling: Input the metrics into the adaptive sampling controller, receive the adjusted sampling parameters, and apply them to the subsequent generation process.

[0260] Return decision result: Return the final decision result to the generation loop.

[0261] Figure 6 A flowchart illustrating a partial correction process according to some embodiments of the present invention is presented. Starting with analyzing the cause of the violation, the process involves selecting a correction strategy, executing the correction, verifying the correction, updating the context, and finally returning the correction result. This process embodies a multi-layered, progressive correction strategy: from simple rule-driven correction to pattern-driven correction based on FSM templates, and then to lightweight LLM collaborative correction, gradually attempting each step until the correction is successful or it is confirmed that automatic correction is not possible. This multi-layered correction strategy improves the success rate of automatic correction and reduces the frequency of manual intervention. The specific steps of the correction process are described in further detail below:

[0262] Analyze the reasons for the violation, pinpoint the specific location of the violation, analyze the root cause of the violation, and determine the target for correction.

[0263] Choose a correction strategy: Select the corresponding corrector based on the type of violation. Specifically: if it is a syntax or format violation, use rule-driven deterministic correction; if it is an architectural pattern violation, use pattern-driven semi-deterministic correction; if it is a complex semantic violation, use lightweight LLM collaborative correction; if the above strategies fail, downgrade to other correction strategies.

[0264] Perform corrections (in order: attempt quick correction, attempt heuristic correction, attempt regeneration correction): operate according to the selected strategy: rule correction directly applies deterministic modifications; pattern correction executes a predefined refactoring template; LLM correction builds constraint hints and calls a lightweight LLM.

[0265] Verify the correction, re-perform constraint checks, ensure that the correction does not result in a violation, and ensure that no new violations are introduced.

[0266] Update context: Updates the code context, state context, and constraint context respectively. Returns "Repair successful".

[0267] If the correction fails, request manual intervention.

[0268] Further illustrative details of exemplary embodiments of the present invention are described below.

[0269] Interface Specification

[0270] Specification parsing interface

[0271] Interface functionality: Parse the architecture specification document and generate a constraint rule base and specification semantic graph.

[0272] Input parameters: specification document path or content, specification document format type (JSON / XML / YAML / Natural Language / UML).

[0273] Output: List of constraint rules, reduction semantic graph (SSG).

[0274] Processing flow: 1. Read the specification document content. 2. Parse according to the document format. 3. Extract constraint information and convert it into rule objects. 4. Construct a specification semantic graph. 5. Perform rule consistency verification. 6. Return the rule list and semantic graph.

[0275] Specification - FSM Mapping Interface

[0276] Interface function: Map the specification semantic graph to the FSM state transition table.

[0277] Input parameters: Reduction Semantic Graph (SSG), Design Pattern Library.

[0278] Output: FSM State Transition Table (STT), FSM executable instance.

[0279] Processing flow: 1. Receive the specification semantic graph. 2. Traverse the design pattern library for pattern matching. 3. Select a matching FSM template. 4. Instantiate the FSM template. 5. Associate constraint rules. 6. Generate a state transition table. 7. Return the FSM instance.

[0280] Logits filtering interface

[0281] Interface Functionality: Predictive filtering of LLM output Logits based on FSM state.

[0282] Input parameters: LLM original Logits vector, current FSM state, activity constraint rules

[0283] Output: Adjusted probability distribution, filtered statistical information.

[0284] Processing flow: 1. Receive LLM Logits 2. Calculate the candidate token set 3. Calculate the violation probability of each token 4. Perform probability adjustment 5. Renormalize 6. Return the adjusted distribution

[0285] Incremental AST interface

[0286] Interface functionality: Incremental abstract syntax tree analysis of intermediate code.

[0287] Input parameters: Current token sequence, incremental AST from the previous time step.

[0288] Output: Current incremental AST, cyclomatic complexity, SCV value

[0289] Processing flow: 1. Locate the changing region; 2. Incrementally analyze the changing region; 3. Handle dangling nodes; 4. Calculate the complexity of each node; 5. Calculate SCV; 6. Return the analysis results.

[0290] Adaptive sampling control interface

[0291] Interface Functionality: Dynamically adjust LLM sampling parameters based on metrics.

[0292] Input parameters: current KVC value, current SCV value, current sampling parameters

[0293] Output: Adjusted sampling parameters

[0294] Processing flow: 1. Collect current metrics 2. Determine control status 3. Adjust parameters according to the status mapping table 4. Perform boundary checks 5. Record adjustment history 6. Return adjusted parameters

[0295] Local correction interface

[0296] API Functionality: Automatically corrects non-compliant code.

[0297] Input parameters: violation record, current code content, violation type

[0298] Output: Correction result, correction status

[0299] Processing flow: 1. Analyze the violation type. 2. Select a remediation strategy. 3. Execute the remediation. 4. Verify the remediation results. 5. If it fails, downgrade to another strategy. 6. Return the remediation results.

[0300] Application Examples

[0301] Example 1: Microservice Architecture Code Generation

[0302] Application Scenario: Generating Python backend service code that conforms to microservice architecture specifications. Architecture Requirements: Each microservice should only access its own database; cross-service calls must go through an API Gateway; inter-service communication should use a RESTful API; all services must implement a health check interface.

[0303] Specification-FSM mapping process: 1. Parse the specification to identify the Repository pattern and layered architecture pattern; 2. Load the corresponding FSM template; 3. Instantiate it into a specific microservice FSM state machine; 4. Associate architectural constraint rules.

[0304] Generation Process: 1. User describes requirements: Generate a user management microservice; 2. Sentinel-K loads the microservice architecture specification; 3. Generates an FSM state transition table through the specification-FSM mapping engine; 4. Logits filter performs predictive constraints based on FSM state; 5. Generates the UserService class definition; 6. During the generation of database access code, code directly using database connections is detected; 7. Architecture constraint violation detection is triggered; 8. The gating mechanism determines the violation to be automatically correctable; 9. The local corrector uses pattern-driven correction to refactor direct database access into a Repository pattern; 10. Continue generation, ensuring all code conforms to the architecture specification.

[0305] Technical effects: The specification-FSM mapping achieves a transparent transformation from architectural constraints to token-level control; the generated code strictly follows the microservice architecture specification; database access is decoupled through the Repository pattern; health check interfaces are automatically generated; KVC metrics are kept at a low level; and corrections can be completed without manual intervention.

[0306] Example 2: Embedded System Code Generation

[0307] Application scenario: Generating embedded C code that conforms to the MISRA-C specification. Architectural requirements: No dynamic memory allocation; all functions must have return values; no recursive calls; all pointers must be initialized.

[0308] Specification-FSM mapping process: 1. Parse the specification and identify resource-constrained modes; 2. Instantiate the embedded FSM state machine; 3. Associate MISRA-C constraint rules with each state.

[0309] Generation Process: 1. User describes requirements: Generate a temperature sensor reading module; 2. Sentinel-K loads the MISRA-C specification; 3. Generates an FSM state transition table through the specification-FSM mapping engine; 4. Logits filter predictively filters tokens related to dynamic memory allocation; 5. Generates the sensor reading function; 6. During generation, dynamic memory allocation is detected; 7. Triggers a P0-level serious violation; 8. Gating mechanism immediately interrupts generation; 9. Local corrector changes dynamic memory allocation to a static array; 10. Adaptive sampling controller adjusts sampling parameters to reduce randomness; 11. Continue generation, ensuring compliance with the MISRA-C specification.

[0310] Technical effects: Logits predictive filtering effectively prevents the generation of dynamically allocated tokens; the generated code fully complies with the MISRA-C specification; static arrays are used instead of dynamic memory allocation; all pointers are initialized; and there are no artificially introduced memory safety risks.

[0311] Example 3: Enterprise Application Code Generation

[0312] Application Scenario: Generating Java Spring Boot application code that conforms to enterprise layered architecture specifications. Architecture Requirements: The Controller layer is only responsible for request processing and response; the Service layer implements business logic; the Repository layer is responsible for data access; direct calls across layers are prohibited.

[0313] Specification-FSM mapping process: 1. Parse the specification to identify the layered architecture pattern and MVC pattern; 2. Instantiate the multi-layer FSM state machine; 3. Generate inter-layer call constraint rules.

[0314] Generation Process: 1. User describes requirements: Generate an order management module; 2. Sentinel-K loads the enterprise layered architecture specification; 3. Generates an FSM state transition table through the specification-FSM mapping engine; 4. During the generation of the Service layer, it is detected that the Controller directly accesses the database; 5. Layered architecture violation is triggered; 6. Gating mechanism triggers local correction process; 7. Incremental AST analyzer identifies the syntax structure of the violating code; 8. Local corrector automatically refactors into a correct three-tier architecture; 9. SCV calculation shows that the change in structural complexity is within a controllable range; 10. Adaptive sampling controller fine-tunes sampling parameters; 11. Verifies that the refactored code conforms to the layered architecture specification.

[0315] Technical effects: The specification-FSM mapping engine ensures the integrity of architectural constraints; automatically generates code structures that conform to the layered architecture; Controller, Service, and Repository each perform their respective functions; decoupling between layers is achieved; SCV monitoring ensures the structural stability of the generation process; and code maintainability and testability are guaranteed.

[0316] Figure 7 A schematic structural diagram of a process-controlled code generation device 4000 for large language models according to some embodiments of the present invention is shown. The device includes a processor 4051, a memory 4052, and a bus 4053. In some instances, the device may further include an input device 4001, an input port 4002, an output port 4003, and an output device 4004. The input port 4002, processor 4051, memory 4052, and output port 4003 are connected via the bus 4053. The input device 4001 and output device 4004 are connected to the bus 4053 via the input port 4002 and output port 4003, respectively, and are subsequently connected to other components of the device.

[0317] The aforementioned memory 4052 includes a large-capacity memory for data or instructions. The bus, including hardware, software, or both, couples the components together. The processor executes the described process-oriented code generation method for large language models based on computer programs stored in the memory.

[0318] This application also proposes a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the process control-type code generation method for large language models.

[0319] This application also provides a computer program product, which includes a computer program, characterized in that, when the computer program is executed by a processor, it implements the process control-type code generation method for large language models.

[0320] It should be noted that, for ease of understanding, this application has broken down each step in the method and each module in the system in detail. However, those skilled in the art will understand that, depending on the actual implementation needs, each step and module can be further broken down or reorganized, and these are all within the scope of the present invention.

Claims

1. A method for generating process control type code oriented to a large language model, characterized by, include: S1. Receive the architecture specification document provided by the user, parse the architecture specification document, and construct a structured constraint rule base and specification semantic graph based on the parsing results; S2. The specification semantic graph is formally mapped to a finite state machine (FSM) state transition table, wherein each state node in the FSM state transition table is associated with a structured constraint rule; the FSM state transition table is compiled into an FSM runtime instance; S3. In the loop of calling the large language model for code generation, the FSM running instance is used to monitor each atomic execution step of the large language model in real time; S4. After each token is generated, the compliance verification in the real-time monitoring is performed based on the structured constraint rules associated with the current FSM state and the current state node; when the generation behavior is detected to violate the structured constraint rules, the corresponding gating mechanism is triggered and local correction is performed; if the verification is successful, code generation continues.

2. The code generation method of claim 1, wherein, The formal mapping of the reduced semantic graph to an FSM state transition table includes: Traverse the preset design pattern library, perform pattern matching between the specification semantic graph and the design pattern library, and select the corresponding FSM template according to the matching result. If there is no corresponding FSM template, generate a custom FSM structure. The FSM template or custom FSM structure is expanded into specific state nodes and transition edges, and the associated structured constraint rules are encoded for each state node.

3. The code generation method of claim 2, wherein, The aforementioned triggering of the corresponding gating mechanism and local correction includes selecting rule-driven correction, pattern-driven correction, or collaborative correction using a lightweight large language model (LLM) based on the type of violation. The rule-driven correction includes: performing deterministic modifications according to the rules; Pattern-driven corrections include: refactoring the aforementioned FSM template; The lightweight LLM collaborative correction method includes: building constraint hints and calling the lightweight LLM to make modifications based on the constraint hints.

4. The code generation method according to claim 1 or 2, characterized by, Also includes: After each token is generated, the generated token is concatenated to the current local code snippet, and the concatenated local code snippet is incrementally parsed by the incremental syntax tree analyzer to dynamically update the incremental abstract syntax tree; Based on the latest node state of the incremental abstract syntax tree, determine whether the conditions for triggering an FSM state transition are met. If so, trigger the state transition and update the current FSM state; otherwise, retain the current FSM state and continue to accumulate subsequently generated tokens.

5. The code generation method of claim 4, wherein Also includes: When performing incremental parsing on the concatenated local code fragment, if a position with incomplete syntax is encountered, a dangling node is generated. And the determination of whether the conditions for triggering FSM state transition are met based on the latest node state of the incremental abstract syntax tree includes: determining whether the updated incremental abstract syntax tree has syntax errors, semantic errors and architectural constraint errors; The system dynamically triggers gating mechanisms based on the detected violation level to implement immediate interruption, delayed intervention, or record warning strategies.

6. The code generation method of claim 5, wherein, Also includes: Based on the state of each node in the incremental abstract syntax tree, calculate the kernel violation count (KVC) and / or structural complexity variability (SCV). Based on the comparison results between the current values ​​of KVC and SCV and their respective preset thresholds, the risk status of the current generation process is dynamically determined. Based on the determined risk status, a preset parameter mapping table is invoked to adaptively adjust the sampling parameters of the large language model; Token generation is performed based on the updated sampling parameters.

7. The code generation method according to claim 1 or 2, characterized by, The parsing of the architecture specification document includes parsing and obtaining syntax layer constraints, semantic layer constraints, and architecture layer constraints; the structured constraint rules include rule identifier, rule type, constraint conditions, triggering conditions, correction suggestions, and priority.

8. The code generation method of claim 6, wherein, The calculation of Structural Complexity Volatility (SCV) includes: Traverse each node in the current incremental abstract syntax tree and calculate the complexity of each node using different complexity calculation rules according to the node state type; sum the complexity of all nodes in the current incremental abstract syntax tree to obtain the current total complexity; subtract the current total complexity from the total complexity of the previous time step and take the absolute value to obtain the final SCV value; the node state types include complete nodes, incomplete nodes, and dangling nodes.

9. The code generation method according to claim 1 or 2, characterized by, Also includes: Before each token is generated and sampled, the original predicted probability distribution of the large language model for the next token is intercepted in real time. Based on the current FSM state and associated structured constraint rules, the set of tokens that can be generated is determined, the probability distribution of the tokens in the set is adjusted, and token sampling is performed based on the adjusted probability distribution.

10. The code generation method of claim 5, wherein, The immediate interruption strategy includes performing the following actions: Freeze the current FSM state and generation context; Analyze the root causes of the violations and determine corrective strategies; Use the local corrector for automatic correction, or wait for manual intervention; After the correction is complete, restore the FSM state and context; Continue generating code from the breakpoint.

11. A process control type code generation device for a large language model, characterized by, The device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the code generation method as described in any one of claims 1 to 10.

12. A computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the code generation method as described in any one of claims 1 to 10.

Images