Large language model inference enhancement method and apparatus

Abstract

The application discloses a large language model reasoning enhancement method and device, the method comprises the following steps: converting a natural language task input by a user into a formal task representation and initializing a state space; maintaining state information containing a current reasoning node, a set of achieved sub-goals and a set of unachieved sub-goals in a reasoning process; iteratively generating a candidate action sequence according to the current state information based on a large language model; performing multiple verifications including at least syntax correctness verification and semantic logic consistency verification on the candidate action sequence; if the verification is passed, updating the state information and continuing iteration, and if the verification fails, generating a failure category label and error context information; generating a structured correction instruction according to the failure information and feeding it back to the large language model generation process; monitoring the iteration rounds, and terminating the iteration and outputting the reasoning result when reaching a preset upper limit or a target state is achieved. The application significantly improves the reliability, accuracy and efficiency of reasoning.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, specifically to a method, apparatus, and storage medium for enhancing reasoning in large language models. Background Technology

[0002] Large Language Models (LLMs), based on the Transformer architecture and pre-trained on large-scale corpora, have demonstrated powerful capabilities in tasks such as natural language understanding, text generation, and code completion. However, the essence of LLMs is sequence prediction based on contextual conditional probabilities. Their reasoning is "statistical approximation" rather than "logical deduction." In complex reasoning scenarios that require strict logical chains, the stability and reliability of the model's output have inherent limitations. It may output seemingly reasonable but actually erroneous conclusions with high confidence (i.e., hallucinations) without being aware of or correcting them.

[0003] Researchers have proposed various technical solutions to enhance the reasoning capabilities of large language models. The thought chain prompting method guides the model to gradually output the reasoning process by incorporating demonstrations of intermediate reasoning steps into prompts. However, the reasoning steps are presented in free natural language, lacking formal structure and objective verification, and errors rely on the model's own inability to identify them. The process reward model progressively labels and models rewards intermediate reasoning steps, but its validator is a data-driven learning model, which may itself contain errors and lacks deterministic verification capabilities. The self-reflection method enables the model to generate natural language reflections based on execution results and guide subsequent improvements, but the feedback originates from the model itself, posing a risk of "correcting errors with errors." The COPRA system combines a large language model with a Coq theorem prover, achieving a basic closed loop of "generation → verification → correction." However, its abstract world model has an implicit structure, lacking explicit state representation and path backtracking capabilities. Feedback is a direct transmission of raw error logs, lacking classification of error types, precise identification of error locations, and structured generation of correction directions. The system is only oriented towards Coq provers and cannot be extended to other verification tools. AlphaGeometry, which alternates between a neural language model and a symbolic inference engine, is the most representative neural symbolic collaborative reasoning system currently available. However, its architecture is highly coupled with the geometric domain, and its feedback mechanism is a binary success / failure signal. The model cannot know the specific error steps and correction directions, and it does not have explicit reasoning state representation and path backtracking capabilities.

[0004] In general, existing technologies share common limitations in the following aspects: Large language models lack external objective verification mechanisms for their inference conclusions, making it impossible to automatically identify and correct erroneous conclusions; intermediate inference steps lack structured representations of task constraints and logical relationships, resulting in ambiguous dependencies between steps and making it difficult to trace and locate errors accumulated along the inference chain; technical error information output by the verifier is transmitted in the form of raw logs that are difficult for large language models to understand directly, and the system cannot transform verification failure information into structured feedback containing error location and correction direction to drive the model to make targeted corrections; existing systems are typically built for specific domains, lacking a unified access architecture for multiple types of verifiers, resulting in insufficient cross-domain scalability; intermediate inference states are untraceable, and after a failure inference path, it is impossible to effectively backtrack to a valid node and explore alternative paths, leading to low search efficiency.

[0005] In summary, existing technologies cannot provide a general closed-loop reasoning enhancement framework for large language models in complex reasoning tasks that combines external objective verification, structured state management, accurate error localization, and targeted correction capabilities. It is also difficult to achieve cross-domain scalability while ensuring the reliability of reasoning. Summary of the Invention

[0006] The purpose of this application is to provide a method, apparatus, and storage medium for enhancing reasoning in large language models.

[0007] To achieve the above objectives, the first aspect of this application provides a method for enhancing reasoning in large language models, the method comprising:

[0008] Step S10: Obtain the natural language task input by the user, convert the natural language task into a formal task representation under a preset formal specification, and initialize the state space of the current inference process based on the formal task representation;

[0009] Step S20: In the inference process, maintain the state information in the state space, the state information including at least the current inference node, the set of achieved sub-goals and the set of unachieved sub-goals;

[0010] Step S30: Based on the large language model, and according to the current state information, iteratively generate a sequence of candidate actions to advance the reasoning process;

[0011] Step S40: Perform multiple verifications on the candidate action sequence, wherein the multiple verifications include at least syntactic correctness verification and semantic logic consistency verification;

[0012] If the candidate action sequence passes the multiple verifications, the state information is updated according to the candidate action sequence, and the process returns to step S30 to continue iterating.

[0013] If the candidate action sequence fails the multiple verifications, a corresponding failure category label and error context information are generated, and the process proceeds to step S50.

[0014] Step S50: Based on the failure category label and the error context information, generate a structured correction instruction according to a preset feedback strategy, and feed the structured correction instruction into the large language model generation process in step S30 to instruct subsequent iterations to avoid the error types that have occurred and adjust the generation direction of candidate action sequences.

[0015] Step S60: Monitor the iteration rounds of the inference process. When the iteration rounds reach a preset upper limit threshold or the state space determines that the target state corresponding to the natural language task has been achieved, terminate the iteration and output the final inference result.

[0016] In this process, the candidate action sequence generated in step S30 is verified in step S40, and the verification result is converted into a correction instruction in step S50 and fed back to step S30 as the input basis for subsequent iterations in step S30. Steps S30, S40 and S50 constitute a loop path for information transmission, and the repeated execution of the loop path is controlled by the termination condition of step S60.

[0017] In this embodiment of the application, the step of maintaining the state information within the state space includes:

[0018] Step S201: Maintain a knowledge rule base, which stores axioms, lemmas, reasoning rules, and constraints of the domain to which the current reasoning task belongs;

[0019] Step S202: Maintain the reasoning state of the current reasoning process. The reasoning state includes at least the set of verified propositions, the set of target propositions to be verified, and the current reasoning context information. The current reasoning context information includes at least the set of used reasoning rules, the identifiers of excluded reasoning paths, and the current iteration round.

[0020] Step S203: In response to each candidate action sequence being verified and the state update being completed, a state transition operation is performed to transfer the inference state from the current state to the next state;

[0021] Step S204: Maintain the reasoning path graph, which records all the reasoning paths explored in the reasoning process in a directed acyclic graph structure;

[0022] Step S205: When any candidate action sequence fails verification, a backtracking operation is performed to revert the current inference process to the previously verified inference state and guide the generation direction of subsequent candidate action sequences to avoid the failed path in order to reduce repeated invalid attempts.

[0023] In this embodiment of the application, the step of performing a backtracking operation when any candidate action sequence fails verification includes:

[0024] Step S2051: Mark the corresponding node in the current inference path as a failed node and record the reason for the failure;

[0025] Step S2052: Backtrack along the inference path graph to the most recently verified node and take that node as a valid node;

[0026] Step S2053: Open a new inference branch at the effective node to guide the generation of subsequent candidate action sequences to explore along the new branch;

[0027] Step S2054: The identification information and failure reason of the failed node are stored as taboo information in the inference path graph, which is used to suppress the generation of candidate action sequences associated with the failed node by the large language model in subsequent iterations.

[0028] In this embodiment of the application, the state transition operation specifically includes the following in response to each candidate action sequence passing verification and completing the state update:

[0029] The formal conclusion corresponding to the current candidate action sequence is moved from the set of target propositions to be verified to the set of verified propositions;

[0030] Based on the reasoning rules applied to the current candidate action sequence, update the set of target propositions to be verified, remove sub-targets that have been covered by the current verification results, and add newly generated sub-targets;

[0031] Update the current inference context information, and at least record the inference rules used in the current step and the number of iterations consumed in this iteration.

[0032] In this embodiment of the application, the step of converting the natural language task into a formal task representation under a preset formal specification, and initializing the state space of the current inference process based on the formal task representation, includes:

[0033] Step S101: Perform input preprocessing on the natural language task. The input preprocessing includes at least word segmentation, named entity recognition, and relation extraction to extract key objects, quantitative relationships, and logical constraints involved in the natural language task.

[0034] Step S102: Based on the rule matching and classification model, the natural language task is classified into a predefined task type set, which includes at least: mathematical proof tasks, program verification tasks, scientific inference tasks, and engineering decision-making tasks.

[0035] Step S103: Invoke the domain ontology corresponding to the classified task type and the predefined conversion prompt template, and convert the natural language task into a formal statement under the target domain through the large language model;

[0036] Step S104: Perform a legality verification of the transformation result on the formal statement; if the verification passes, proceed to step S105; if the verification fails, trigger step S103 again to re-transform until the verification passes or the number of re-transformations reaches the preset retry limit. If the verification still fails after reaching the retry limit, return a transformation failure message to the user and request clarification.

[0037] Step S105: Based on the formal statement, explicitly define the target state corresponding to the termination condition of the reasoning process, and extract the preconditions, constraints and boundary conditions from the natural language task and / or the formal statement, and write the preconditions, constraints and boundary conditions as the initial hard constraints of the state space into the state space.

[0038] In this embodiment of the application, the step of iteratively generating a candidate action sequence for advancing the reasoning process based on the current state information and a large language model includes:

[0039] Step S301: Serialize the current status information into a structured prompt containing multiple fixed partition formats. The structured prompt includes at least a task definition partition, a known condition partition, a current target partition, an available rule partition, a historical failure path summary partition, and an output format partition.

[0040] Step S302: Based on the structured prompts, call the large language model to generate k candidate inference steps with a preset bundle width;

[0041] Step S303: Maintain k active inference paths, submit the current candidate inference steps of each active inference path to the verification unit for verification, and perform path management operations based on the verification results:

[0042] Step S304: In response to the received structured correction instruction, the structured correction instruction is injected into the preset feedback partition of the structured prompt, the large language model is called again, a corrected candidate inference step is generated for the specified inference step, and the corrected candidate inference step is submitted to the verification unit for re-verification; wherein, the corrected candidate inference step is recorded as a new branch in the inference path graph, and the branch corresponding to the original failed inference step is retained in the inference path graph and is not covered.

[0043] In this embodiment of the application, the step of performing path management operation based on the verification result in step S303 includes:

[0044] Step S3031: For the candidate reasoning steps that have passed the verification, retain the corresponding path, update the formal conclusion corresponding to the candidate reasoning steps to the state space, and continue to advance the next round of reasoning for the path.

[0045] Step S3032: For candidate inference steps that fail verification, record the failure information of the corresponding path to the inference path graph and trigger the feedback generation process.

[0046] Step S3033: When all k active inference paths fail to be verified at the same number of inference steps, a global backtracking operation is performed: each path is backtracked to the most recently verified common fork node, and based on the failure history information recorded in the inference path graph, the large language model is guided to generate new candidate inference steps at the fork node and re-explore along the new branch.

[0047] Step S3034: If the cumulative number of global backtracking operations exceeds the preset backtracking limit, it is determined that the current inference task cannot be completed within the existing inference framework, the inference process is terminated and a failure report is output.

[0048] In this embodiment of the application, the multi-verification in step S40 is implemented using a pluggable verification architecture. The pluggable verification architecture accesses at least two different types of verifiers through a unified interface protocol. The type of verifier is selected and switched according to the task type of the current inference task.

[0049] In this embodiment of the application, the step of generating a structured correction instruction based on the failure category label and the error context information according to a preset feedback strategy includes:

[0050] Step S501: Based on the error type field output by the verifier, classify the errors that have occurred into the corresponding categories in the predefined error category set. The predefined error category set includes at least logic layer errors, target layer errors, constraint layer errors, and formal layer errors.

[0051] Step S502: Combining the error location information output by the verifier with the current inference path graph, locate the step number that caused the error and the corresponding expression fragment;

[0052] Step S503: Based on the categorized error types and the current knowledge rule base, retrieve candidate alternative rules that match the current error structure from the knowledge rule base through rule matching, and generate at least one correction direction suggestion;

[0053] Step S504: Assemble the error category, the error location information, and the correction direction suggestion into structured feedback information according to a preset format. The structured feedback information includes at least the error step number, error type name, error location expression fragment, error cause description, current uncompleted target list, and correction direction suggestion list.

[0054] Step S505: Monitor the iteration rounds and global backtracking counts of the current inference process. When the iteration rounds reach the preset maximum iteration round limit or the global backtracking count reaches the preset maximum backtracking count limit, execute the termination operation: Select the candidate path with the most verified steps from the inference path graph, output the inference process of the path and the list of currently incomplete targets, and mark the incomplete status.

[0055] A second aspect of this application provides a large language model reasoning enhancement apparatus, comprising: a memory configured to store instructions; a processor configured to retrieve instructions from the memory and to implement a large language model reasoning enhancement method when executing the instructions.

[0056] A third aspect of this application provides a machine-readable storage medium storing instructions for causing a machine to execute a large language model reasoning enhancement method.

[0057] The method of this application includes: converting the natural language task input by the user into a formal task representation and initializing the state space; maintaining state information including the current inference node, the set of achieved sub-goals, and the set of unachieved sub-goals during the inference process; iteratively generating candidate action sequences based on the current state information using a large language model; performing multiple verifications on the candidate action sequences, including at least syntactic correctness verification and semantic logical consistency verification; updating the state information and continuing iteration if the verification passes, and generating failure category labels and error context information if the verification fails; generating structured correction instructions based on the failure information and feeding them back to the large language model generation process to avoid errors that have occurred and adjust the generation direction; monitoring the iteration rounds, terminating the iteration and outputting the inference result when a preset upper limit is reached or the target state is achieved. This invention, through a closed-loop iterative architecture of "generation-verification-feedback-correction," achieves external objective verification and precise targeted correction of the large language model inference process, significantly improving the reliability, accuracy, and efficiency of inference.

[0058] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0059] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings:

[0060] Figure 1 The schematic diagram illustrates a flowchart of a large language model reasoning enhancement method according to an embodiment of this application;

[0061] Figure 2 This diagram schematically illustrates the overall system architecture of the large language model reasoning enhancement method according to an embodiment of this application.

[0062] Figure 3 This illustration schematically shows the overall reasoning path diagram of the large language model reasoning enhancement method according to an embodiment of this application;

[0063] Figure 4 This illustration schematically shows a flowchart of the large model inference engine of the large language model inference enhancement method according to an embodiment of this application;

[0064] Figure 5 A schematic diagram of a computer device according to an embodiment of this application is shown. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0066] Figures 1-5 The diagram illustrates a flowchart and system architecture diagram related to a large language model reasoning enhancement method according to an embodiment of this application. Figure 1 and Figure 2 As shown in the figure, this application provides a method and system architecture diagram for enhancing reasoning in a large language model. The method may include the following steps:

[0067] Step 10: Obtain the natural language task input by the user, convert the natural language task into a formal task representation under a preset formal specification, and initialize the state space of the current inference process based on the formal task representation.

[0068] Step S10 is the starting point of the method of this invention. It is responsible for converting the reasoning task expressed by the user in natural language into a formal representation that the system can accurately process, and initializing the reasoning state space based on this formal representation. The correctness of this step has a decisive impact on the reliability of the entire system—if there is an error in the initial formal transformation (such as entity recognition deviation, omission of logical relations, or type error in the formal statement), all subsequent reasoning steps will be based on the erroneous premise, causing the verification result to become meaningless. Therefore, this step introduces an independent legality verification sub-step and a retry mechanism during the transformation process to ensure that the formal task representation entering the reasoning loop has syntactic and type correctness.

[0069] Step S10 specifically includes the following sub-steps S101 to S105.

[0070] Sub-step S101: Input preprocessing, specifically performing input preprocessing on the natural language task. The input preprocessing includes at least word segmentation, named entity recognition, and relation extraction to extract key objects, quantitative relationships, and logical constraints involved in the natural language task.

[0071] Sub-step S101 performs preprocessing operations on the user-input natural language task, extracting structured information from the unstructured natural language text to lay the data foundation for subsequent task classification and formal transformation. Specifically, preprocessing includes at least the following three core operations:

[0072] (1) Tokenization

[0073] The user-input natural language text is segmented into the smallest semantic units (Tokens). For Chinese input, a segmentation strategy combining dictionary and statistical models is employed, such as a cascade of Bi-MM (Bidirectional Maximum Matching) and Conditional Random Field (CRF) sequence labeling models, to correctly handle domain-specific terms and compound terms. For English input, basic segmentation based on spaces and punctuation is used, combined with lemmatization to restore words with different inflectional forms to their original forms (e.g., unifying "proved" and "proving" into "prove"), facilitating subsequent entity recognition and relation matching.

[0074] (2) Named Entity Recognition (NER)

[0075] Based on a pre-trained named entity recognition model (such as the BERT-BiLSTM-CRF architecture), key entities involved in the task are identified from the word segmentation results. Entity types include at least: mathematical entities (such as "even number", "prime number", "matrix", "derivative"), procedural entities (such as "array", "linked list", "sorting algorithm", "time complexity"), scientific entities (such as "mass", "speed", "temperature", "chemical element"), and engineering entities (such as "stress", "yield strength", "voltage", "tolerance"). Identified entities are assigned type labels, and their location and context within the task are recorded.

[0076] (3) Relation Extraction

[0077] Based on dependency parsing and a predefined relation-triggered lexicon, semantic relationships between entities are extracted. Relation types include at least: quantitative relationships (e.g., "A is greater than B", "C equals D × 2"), logical constraint relationships (e.g., "If P then Q", "A if and only if B"), inclusion relationships (e.g., "S is a subset of T", "A belongs to category B"), and causal relationships (e.g., "X causes Y", "Because U therefore V"). The extracted relationships are output as triples, in the form of <entity 1, relation type, entity 2>, serving as structured input for subsequent formal transformations.

[0078] After processing in sub-step S101, the unstructured natural language input is transformed into structured data with entity labels and relation annotations, providing feature input for task type classification in step S102.

[0079] Sub-step S102: Task type classification, specifically, based on a rule matching and classification model, classifying the preprocessed natural language tasks into a predefined set of task types. Accurate task type determination directly determines the subsequent domain ontology, conversion prompt template, and validator type.

[0080] Tasks are categorized into a predefined set of task types: M-type (Mathematical Proof, requiring a formal proof of the proposition). A typical example is proving that any even number is divisible by 2; P-type (Program Verification, requiring the generation of program code that satisfies the specification); for example, generating a quicksort algorithm and verifying its correctness; S-type (Scientific Inference, requiring the derivation of scientific conclusions under domain knowledge constraints), for example, predicting the products of a chemical reaction given initial conditions; E-type (Engineering Decision-Making, requiring the output of a decision plan under engineering specifications constraints), for example, selecting appropriate materials and cross-sectional dimensions for a bridge structure.

[0081] The classification strategy employs a two-tier architecture: rule matching takes precedence, while the classification model serves as a fallback.

[0082] Rule matching layer: Performs fast matching based on a predefined keyword rule base. For example, inputs containing keywords such as "proof," "theorem," "if and only if," and "holds true for all" are preferentially classified into class M; those containing keywords such as "code," "program," "function," and "test case" are preferentially classified into class P; those containing keywords such as "prediction," "simulation," "law," and "conservation" are preferentially classified into class S; and those containing keywords such as "specification," "standard," "safety factor," and "compliance" are preferentially classified into class E.

[0083] Classification Model Layer: For inputs with a rule matching confidence score below a preset threshold (e.g., 0.7), a fine-tuned pre-trained language model (e.g., a BERT-based text classifier) ​​is invoked for soft classification, outputting the probability distribution of each category. The category with the highest probability is taken as the classification result. The classification model needs to be fine-tuned in advance on a training dataset labeled with four task categories.

[0084] After classification, the task type identifier (M / P / S / E) will be passed to sub-step S103 for selecting the corresponding domain ontology and conversion prompt template.

[0085] Sub-step S103: Formal Transformation Based on Hint Templates: Specifically, this involves calling the domain ontology corresponding to the categorized task type and predefined transformation hint templates, and using the large language model to transform the natural language task into a formal statement under the target domain. The core design of this step lies in customizing the transformation hint templates according to the task type, ensuring that the output format of the large language model is strictly aligned with the grammatical specifications of the target formalization system.

[0086] (1) Calling of DomainOntology

[0087] Based on the task type identifier, the system loads the corresponding domain ontology from the ontology repository. The domain ontology defines the core concepts, predicates, function symbols, constants, and axiomatic system within that domain, providing the lexical constraints and semantic context necessary for formal transformation of large language models.

[0088] M-class tasks: Load mathematical ontology, including mathematical object types (such as Nat, Int, Real, Set), predicates (such as Prime, Even, Divisible), operators (such as +, *, ^), and the core definitions of the Mathlib standard library.

[0089] P-class tasks: Loaders verify domain ontology, including program semantic predicates (such as Requires, Ensures, Invariant), data types (such as Array, List, Tree), and reduction patterns.

[0090] S-class tasks: Load ontologs in the field of scientific inference, including physical quantities (such as Mass, Velocity, Temperature), physical laws (such as Newton Second Law, Mass Conservation), and unit systems.

[0091] Task E: Load the engineering decision domain ontology, including engineering parameters (such as Stress, SafetyFactor, Voltage), specification clauses, and constraint expression patterns.

[0092] (2) Predefined conversion prompt template

[0093] The system provides pre-defined structured conversion prompt templates for each type of task. These templates use a fixed partition structure and include the following core elements:

[0094] Role positioning: Specify the expert role that the large language model will play (e.g., "formal mathematics expert" or "program verification expert").

[0095] Task instructions: Clearly define the objectives and output requirements of the task to be converted;

[0096] Format constraints: Specify the output syntax (e.g., "output only Lean4 code, without proof strategy").

[0097] Ontology guidance: Suggestions for using domain-specific ontologies (e.g., "Use Mathlib standard library definitions").

[0098] Ambiguity handling rules: Specify the default handling strategy when encountering ambiguity (e.g., "select the most common mathematical interpretation and explain it in the comments").

[0099] Input placeholder: Enter the preprocessed natural language task description in the {input} position.

[0100] Taking the M-type (mathematical proof) task as an example, the specific content of the transformed prompt template is as follows:

[0101] "You are a formal mathematics expert. Convert the following natural language mathematical propositions into Lean4 theorem statements."

[0102] Requirements: (1) Output only the Lean4 code, without proof strategies; (2) Use the Mathlib standard library definition; (3) If the proposition is ambiguous, select the most common mathematical interpretation and explain it in the comments.

[0103] Natural language input: {input}

[0104] Output format: theorem{name}({params}):{statement}:=by”

[0105] For P-type tasks, the prompt template guides the output of program code with preconditions / postconditions (such as ACS or Dafny style); for S-type tasks, the prompt template guides the output of inference propositions with physical unit annotations and conservation constraints; for E-type tasks, the prompt template guides the output of decision scheme expressions with references to canonical clauses.

[0106] (3) Large language model invocation and formal statement generation

[0107] The fully filled partitioning prompts are input into a large language model (such as a base model like GPT-4, Claude3, or the open-source Llama3), which then generates the corresponding formal statements. Guided by output format constraints, the large language model returns formal statement text that conforms to the grammatical specifications of the target formalization system.

[0108] Sub-step S104: Verification of the transformation result's validity. Sub-step S104 performs validity verification on the formal statement output by sub-step S103, that is, it calls the parser corresponding to the target domain to perform syntax correctness and type correctness checks on the formal statement. Specifically, it includes:

[0109] (1) Verification execution

[0110] The system calls the corresponding parser / verifier based on the task type:

[0111] For tasks of type M, the parser of Lean4 or Coq is invoked to check whether the formal statement conforms to the syntax specification and whether all referenced definitions and theorems exist and match in type; for tasks of type P, the corresponding programming language compiler or program specification checker (such as Dafny verifier) ​​is invoked to perform syntax and type checks; for tasks of type S and E, the domain constraint checker is invoked to check the syntax validity and type consistency of the expression.

[0112] The verification only examines the format validity of the formal statement itself, and does not involve the correctness of the content it proves.

[0113] (2) Verification result processing

[0114] If the verification passes (the verifier returns "Success"), proceed to sub-step S105.

[0115] If verification fails (the validator returns Failure, including error type and error location information), the system determines whether the current number of retries has reached the preset retry limit (default 3 times):

[0116] If the retry limit is not reached, the system will use the error information (error type, error location, error description) returned by the validator as an additional constraint and re-trigger sub-step S103 for re-conversion. Specifically, the system will add the instruction "The previous conversion failed the verification. The error message is: {error_message}. Please correct and re-output" to the prompt template to guide the large language model to perform corrective regeneration based on the error feedback.

[0117] If the verification still fails after reaching the retry limit, the system returns a conversion failure message to the user, describing the reason for the conversion failure in natural language (such as "Unable to parse the input into a valid Lean4 theorem statement. Please check if the input is a valid mathematical proposition"), and requests the user to clarify or restate the input task.

[0118] Sub-step S105: Target state definition and initial constraint extraction: Specifically, based on the formal statement that has passed the legality verification, the target state corresponding to the termination condition of the reasoning process is clearly defined, and the preconditions, constraints and boundary conditions are extracted from the natural language task and / or formal statement, and the conditions are written into the state space as the initial hard constraints of the state space.

[0119] (1) Definition of target state

[0120] Extract the final state definition of reasoning from formal statements. For M-class mathematical proof tasks, the goal state is the theorem statement to be proved itself—the goal state is achieved when the statement is successfully proved and all proof objectives are closed. For P-class program verification tasks, the goal state is the completion of the proof when the program satisfies all reduction conditions (preconditions, postconditions, loop invariants, etc.). For S-class and E-class tasks, the goal state is when all constraints are satisfied and the reasoning conclusion does not conflict with all known facts.

[0121] (2) Initial hard constraint extraction

[0122] Extract the following three types of initial constraints from the natural language task description and / or formal statement:

[0123] Premises: Known facts or assumptions given at the start of reasoning, such as the premises in mathematical propositions, the preconditions in program verification, the initial observation data in scientific inference, and the known design parameters in engineering decisions.

[0124] Constraints: Restrictions that must be followed during the reasoning process, such as definitional constraints in mathematics ("a and b are both integers"), resource constraints in programming ("memory does not exceed 1024MB"), conservation laws in science ("mass conservation"), and safety specifications in engineering ("safety factor must not be less than 2.0").

[0125] Boundary conditions: Boundary restrictions on the inference space, such as the range of values ​​for variables, the domain of functions, the upper limit of the number of iterations, and the range of the search space.

[0126] (3) State space initialization

[0127] The extracted preconditions, constraints, and boundary conditions are encoded into standardized rules and written into the knowledge rule submodule of the Abstract World Model (AWM). These rules serve as hard constraints that the large language model must adhere to when generating candidate reasoning steps during subsequent reasoning processes. Hard constraints cannot be violated during reasoning—any candidate reasoning step that violates a hard constraint, regardless of its logical structure, will be directly judged as a verification failure by the verifier.

[0128] Simultaneously, the inference state S_0 is initialized according to the target state definition: the target proposition is placed into the target proposition set P_pending to be verified, and the premises are moved into the set of verified propositions P_proved (the premises are considered as known facts that have been "initially verified"). The current inference context C_context is initialized to an empty set. At this point, the inference state space initialization is complete, and the system can proceed to step S20 to begin iterative inference.

[0129] Step S20: In the inference process, maintain the state information in the state space, the state information including at least the current inference node, the set of achieved sub-goals and the set of unachieved sub-goals;

[0130] Step S20 involves maintaining state information within the state space during the inference process. This state information includes at least the current inference node, the set of achieved sub-goals, and the set of unachieved sub-goals. This step is implemented using an Abstract World Model (AWM) and is one of the core innovations of this invention that distinguishes it from existing large language model inference methods.

[0131] AWM provides an abstract deduction space with task constraints and logical structure for large language model inference, recording the knowledge state, intermediate state, and historical path during the inference process. AWM is not a simple storage container, but a proactive inference management hub with dynamic update capabilities, supporting path backtracking and knowledge evolution. It simultaneously undertakes three responsibilities: first, providing the inference engine with structured knowledge (available rules and constraints); second, providing the validator with a complete snapshot of the current inference state; and third, providing the feedback generation module with path history and failure information.

[0132] AWM consists of three cooperating sub-modules: the knowledge rule sub-module, the reasoning state sub-module, and the reasoning path graph sub-module. Step S20 achieves comprehensive management of the state space by maintaining these three sub-modules.

[0133] Sub-step S201: Maintaining the Knowledge Rule Base: Sub-step S201 maintains the knowledge rule base, which stores the axioms, lemmas, inference rules, and constraints of the domain to which the current inference task belongs. The knowledge rule base is the knowledge foundation layer of AWM, providing a constraint space of available rules for the generation of inference steps in the large language model, and providing a judgment criterion for the correctness judgment of the verifier.

[0134] (1) Storage format of knowledge entries

[0135] Knowledge entries in the knowledge rule base are stored in a standardized triple format: <entity / proposition, relation type, entity / proposition>. This triple format has good versatility and scalability, and can cover the knowledge representation needs of most reasoning tasks. A typical knowledge entry example is shown below: ,

[0136] (2) Dynamic expansion mechanism of knowledge rule base

[0137] The knowledge rule base supports dynamic expansion, specifically through two approaches:

[0138] Approach 1: Batch Import of External Knowledge. The system can batch import knowledge items from external formal knowledge bases (such as the LeanMathlib mathematical library, the Coq standard library, domain ontology libraries, etc.). The import process uses a knowledge adapter to convert the external knowledge format into the system's internal triple representation and performs consistency checks on the imported knowledge items (checking for conflicts or duplicate definitions). This mechanism allows the system to quickly expand to new task domains without requiring manual input of domain knowledge item by item.

[0139] Approach Two: Automatic Update of Reasoning Conclusions. During the reasoning process, for each candidate reasoning step that passes verification and completes a state update, the system determines whether the formal conclusion of that step belongs to generalizable domain knowledge (such as a newly proven lemma, a newly discovered relation, etc.). If it does, the system automatically converts it into a standardized triple and adds it to the knowledge rule base for use by subsequent reasoning steps. This mechanism enables the knowledge rule base to dynamically evolve and enrich itself as the reasoning process progresses, achieving "reasoning and accumulation simultaneously."

[0140] (3) Query interface of knowledge rule base

[0141] The knowledge rule base provides a standardized query interface, supporting the following query modes:

[0142] Rule retrieval: Based on the current target type and available entities, query all applicable inference rules;

[0143] Constraint checking: Based on the given candidate results, query whether there are any violated hard constraints;

[0144] Relationship query: Given a pair of entities, query whether a specific relationship exists between them.

[0145] Before generating candidate reasoning steps, the large language model reasoning engine obtains a list of reasoning rules applicable to the current step through a query interface; during the verification process, the verifier checks whether the candidate conclusions are consistent with known axioms and constraints through a query interface.

[0146] Sub-step S202: Maintain the reasoning state: Specifically, maintain the reasoning state of the current reasoning process. The reasoning state includes at least the set of verified propositions, the set of target propositions to be verified, and the current reasoning context information.

[0147] (1) Structured definition of the reasoning state: The reasoning state S_t is defined as a structured triple: S_t = (P_proved, P_pending, C_context). The specific meanings of each component are as follows:

[0148] P_proved (Set of Verified Propositions): Stores all propositions or conclusions that have been verified by the verifier in the current inference process. Each entry in this set includes a snapshot of its state when it was verified (including the verification time, the applied inference rule, and a list of dependent preceding steps). P_proved provides directly referable known conclusions for subsequent inference steps, avoiding redundant proofs.

[0149] P_pending (Set of Target Propositions to be Verified): Stores a list of target propositions that have not yet been verified in the current inference process. P_pending is the main driving force of the inference engine—the large language model prioritizes generating candidate inference steps for the targets in P_pending in each iteration. When P_pending is empty, it means that all targets have been proven or verified, and the inference task has achieved its target state.

[0150] C_context (Current Inference Context Information): Stores auxiliary state information of the inference process, including at least the following sub-items:

[0151] used_rules: The set of inference rules that have been used to avoid loops caused by repeatedly applying the same rule in the same path;

[0152] excluded_paths: A list of excluded inference paths (from failed nodes in the path graph), used as taboo information during the large language model generation step to suppress invalid attempts;

[0153] iteration_count: The current iteration number, used to determine the termination condition in step S60;

[0154] current_depth: A measure of the current inference depth (such as the total number of verified steps) used to assess inference progress;

[0155] active_path_id: A unique identifier for the currently active inference path (in a bundle search strategy, multiple active paths may exist simultaneously).

[0156] (2) Initialization of the inference state: After step S10 is completed, the inference state S_0 is initialized according to the following rules:

[0157] P_proved is initialized to the set of prerequisites extracted in step S105 (the prerequisites are considered as initial known facts).

[0158] P_pending is initialized to the target proposition corresponding to the target state defined in step S105 (for M-class tasks, this is the theorem statement to be proved; for P-class tasks, this is the set of reduction assertions to be verified).

[0159] C_context is initialized to an empty set (used_rules is empty, excluded_paths is empty, iteration_count=0, current_depth=0).

[0160] (3) Persistence and recovery of inference state: The inference state is stored in a memory cache (such as Redis) in a structured format to ensure the real-time read and write of the state. At the same time, the system supports persisting a complete snapshot of the inference state to the storage layer (such as a relational database). When the system is interrupted due to abnormality or needs to be paused due to resource scheduling, the inference state can be restored from the most recent persistent snapshot to realize breakpoint resumption.

[0161] Sub-step S203: State transition operation. Sub-step S203 responds to each candidate action sequence that passes verification and completes state update by performing a state transition operation to transfer the inference state from the current state to the next state.

[0162] State transition is the core dynamic behavior of AWM—whenever a candidate reasoning step is verified by the validator, the system triggers a state transition, incorporates the verified conclusion into the knowledge system, updates the to-do list, and records the context information of this transition.

[0163] Specifically, state transition operations follow these three rules:

[0164] Rule 1: Shift the conclusion in (P_pending → P_proved)

[0165] The formal conclusion corresponding to the current candidate action sequence is moved from the set of target propositions to be verified (P_pending) to the set of verified propositions (P_proved). This operation means that the conclusion has been objectively verified as correct and has become a known fact that subsequent reasoning can rely on.

[0166] The following metadata is required for the import operation:

[0167] The list of prerequisite steps on which this conclusion is based (dependency_steps);

[0168] The name of the inference rule applied and its instantiation parameters;

[0169] The timestamp and validator identifier of the successful verification.

[0170] Rule 2: Target Update (Update of P_pending)

[0171] Based on the reasoning rules applied to the current candidate action sequence, update the set of target propositions to be verified (P_pending): remove sub-targets that have been covered by the current verification results and add newly generated sub-targets.

[0172] Under different task types, the update logic of P_pending is driven by the inference rule set of the corresponding domain:

[0173] For M-class (mathematical proof) tasks, the goal stack update mechanism of the interactive theorem prover (such as Lean4) is used. When a proof strategy (Tactic) is applied, the current goal may be decomposed into multiple subgoals. The system removes the closed subgoals from P_pending and adds the newly generated subgoals to P_pending.

[0174] For P-class (program verification) tasks, the system updates the set of assertions to be verified according to the program specification. After verifying one program assertion, the system moves on to the next assertion to be verified.

[0175] For S-class (scientific inference) and E-class (engineering decision) tasks, the remaining constraint set is updated based on the domain constraint checker—when a constraint condition is met, the system removes it from the set to be verified.

[0176] Rule 3: Context Update (Update of C_context)

[0177] Update the current inference context information, and at least record the inference rule used in the current step and the number of iterations consumed in this iteration:

[0178] Append the names of the inference rules used in this step to the used_rules set;

[0179] Increment iteration_count by 1;

[0180] Increment current_depth by 1;

[0181] Update active_path_id to the current path identifier (if the path is changed, update it to the new path identifier).

[0182] After state transition, the inference state is updated from S_t=(P_proved, P_pending, C_context) to S_{t+1}=(P_proved', P_pending', C_context'), where P_proved'=P_proved∪{the currently verified conclusion}, P_pending'=(P_pending-{the covered target})∪{the newly generated sub-target}, and C_context' is the updated context information.

[0183] Sub-step S204: Maintain the inference path graph. Sub-step S204 maintains the inference path graph, which records all inference paths explored in the inference process using a directed acyclic graph structure. The inference path graph is the core data structure in AWM for implementing intelligent backtracking and failure path management.

[0184] (1) Definition of graph structure of a spectrum

[0185] The reasoning path graph G=(V,E) is defined as a directed acyclic graph (DAG), where: Nodes (V): Each node represents a reasoning state S_t, i.e., an intermediate state after a certain step in the reasoning. The initial node S_0 corresponds to the starting state of the reasoning; the target node S_Goal corresponds to the state when the target state is achieved. Each node has the following attributes: node number, corresponding reasoning state snapshot (which can reference the state definition in sub-step S202), the depth of the node (the length of the longest path starting from S_0), and the state label of the node (valid / failed / to be explored). Directed edges (E): Each directed edge represents a reasoning action—transferring from the parent state S_parent to the child state S_child after verification by candidate reasoning step a_i. Each edge has the following annotation information:

[0186] The name of the inference rule applied and its instantiation parameters;

[0187] Verification result (SUCCESS or FAILURE);

[0188] Summary of reasons for failure (recorded only when the verification result is FAILURE, including the error type and a brief description);

[0189] The unique identifier (step_id) for this reasoning step.

[0190] (2) Dynamic construction of the map

[0191] The reasoning path graph is dynamically constructed as the reasoning process progresses:

[0192] When a candidate reasoning step on an active path is validated, the system adds a new node (representing the updated state) and a directed edge (marked SUCCESS) from the old node to the new node in the graph.

[0193] When a candidate reasoning step on an active path fails verification, the system adds a directed edge (with a FAILURE label and the reason for failure) from the current node to a "Terminal-FailNode" in the graph for the failure attempt, but the Terminal-FailNode does not continue to extend.

[0194] (3) Atlas query and navigation functions

[0195] The inference path graph provides the following query and navigation interfaces:

[0196] Path backtracking query: Given the current node, return the complete path from S_0 to that node;

[0197] Recent valid node query: Given the current node, backtrack along the reverse edge to the nearest node with the status label "valid";

[0198] Taboo Path Query: Returns all nodes marked as FAILURE and a summary of their failure reasons (used to populate the [historical failure area] in the structured hints in step S30);

[0199] Deepest path lookup: Returns the candidate path with the most verified steps starting from S_0 (used for the termination output in step S505).

[0200] Sub-step S205: Backtracking operation. In sub-step S205, when any candidate action sequence fails verification, a backtracking operation is performed to revert the current inference process to a previously verified inference state and guide the generation of subsequent candidate action sequences to avoid failed paths, thereby reducing repetitive and invalid attempts. The backtracking operation is the core mechanism for AWM's intelligent trial-and-error mechanism—it doesn't simply "start over" when inference fails, but precisely reverts to the most recent feasible state and strategically opens up new paths.

[0201] Steps S201 to S205 above describe a preferred implementation of the Abstract World Model (AWM), in which the knowledge rule base uses standardized triples to store knowledge entries, and the reasoning path graph uses a directed acyclic graph structure to record reasoning paths. However, the present invention is not limited to the above implementation. Depending on the characteristics and reasoning requirements of different task types, the AWM can adopt the following alternative construction schemes. Each scheme, while maintaining the closed-loop architecture of "generation-verification-feedback-correction," replaces or enhances the knowledge representation, reasoning mechanism, or path exploration strategy within the AWM.

[0202] Alternative Solution 1: The knowledge representation of AWM is replaced by a set of first-order logic (FOL) formulas instead of triples. The inference rules are expressed in FOL implications, and automatic inference is achieved using the resolution algorithm. This solution is suitable for engineering decision-making tasks with relatively regular logical constraints.

[0203] Alternative Solution 2: The inference path graph of AWM is replaced by a Monte Carlo Tree Search (MCTS) structure, which evaluates the expected value of each inference node in a reinforcement learning manner and guides the search to concentrate on high-quality paths. This is suitable for mathematical competition tasks with a very large inference branch space.

[0204] Alternative Solution 3: The knowledge rules submodule of AWM is replaced by an AnswerSet Programming (ASP) solver, which supports non-monotonic reasoning and default reasoning, and is suitable for scientific inference tasks with incomplete information.

[0205] The aforementioned backtracking operation satisfies the following:

[0206] (1) Triggering conditions for backtracking operation

[0207] The backtracking operation is triggered when any of the following conditions are met:

[0208] The candidate inference step of the current active path failed to be verified (single path backtracking);

[0209] In the bundle search, all k active paths fail to be verified at the same number of inference steps (global backtracking).

[0210] (2) Specific steps of backtracking operation

[0211] Sub-step S2051: Failure Node Marking and Reason Recording. Mark the corresponding node in the current inference path as a failure node and record the reason for the failure. Specifically, this includes:

[0212] In the reasoning path graph, mark the current node as a "failed node" (status label = FAILURE);

[0213] Record the error type output by the validator (such as TYPE_ERROR, GOAL_NOT_CLOSED, RULE_VIOLATION, etc.).

[0214] Record the error descriptions output by the verifier (key points extracted from verifier_message);

[0215] Record the context information of the current step (the reasoning rule attempted, the preceding steps it depends on, etc.).

[0216] Sub-step S2052: Backtrack to the most recent valid node. Backtrack along the inference path graph to the most recently verified node and designate that node as the valid node. The backtracking algorithm is as follows:

[0217] Starting from the current failed node, backtrack step by step along the opposite direction of the directed edge;

[0218] Check the status label of each ancestor node and find the node with the most recent status label "valid";

[0219] If no valid node exists among all ancestor nodes, then backtrack to the initial node S_0;

[0220] Set this valid node as the new working node for the current inference process.

[0221] Sub-step S2053: Open a new inference branch. At the valid node, open a new inference branch to guide the generation of subsequent candidate action sequences along the new branch. Specifically, this includes:

[0222] Generate a new branch identifier (branch_id) for the valid node;

[0223] Restore the current inference state to the state snapshot corresponding to the valid node (i.e., restore to the P_proved, P_pending, C_context saved by that node);

[0224] In the next round of generation in step S30, the large language model will generate new candidate inference steps based on the recovered state and explore along the new branch;

[0225] The new branch is recorded as a new child node of the valid node in the reasoning path graph.

[0226] Sub-step S2054: Storage and use of taboo information. The identification information and failure reason of the failed node are stored as taboo information in the inference path graph, which is used to suppress the generation of candidate action sequences associated with the failed node by the large language model in subsequent iterations.

[0227] The mechanism by which taboo information works is as follows:

[0228] In the structured hint construction in step S30, taboo information is filled into the [historical failure area] partition; when the large language model generates candidate reasoning steps, it receives a summary of failed paths (including failed steps and reasons), thereby actively avoiding repeated attempts of reasoning actions that have been proven invalid; taboo information is persistently retained in the reasoning path graph, and even if the system restarts or switches to other reasoning tasks, taboo information can still be viewed and referenced.

[0229] (3) Coordination between single-path backtracking and global backtracking

[0230] Single-path backtracking: When the verification of an active path fails, that path independently performs a backtracking operation (sub-steps S2051 to S2054), while other active paths remain unaffected and continue. This mechanism ensures that the failure of a single path does not affect the inference process of other paths, demonstrating the fault-tolerance advantage of bundle search.

[0231] Global backtracking: When all k active paths fail verification, the system performs global backtracking—each path backtracks to the most recently verified common fork node, and based on the failure history information accumulated in the inference path graph, guides the large language model to generate new candidate inference steps at the fork node. Global backtracking is the last resort to deal with the scenario of "multiple paths getting stuck at the same time", and its cumulative number of times is controlled by R_max in step S505.

[0232] The complete information flow of sub-steps S201~S205 can be summarized as follows: the knowledge rule base provides the basis for reasoning → the reasoning state records the current progress → verification passes and triggers a state transition → the path graph records the entire exploration history → verification fails and triggers precise backtracking (marking the failed node → reverting to the valid node → opening a new branch → recording taboo information), forming a complete closed loop for state maintenance.

[0233] In this way, step S20 completes the comprehensive maintenance of the state space, providing a complete, accurate, and traceable state context for the generation of candidate action sequences in step S30.

[0234] Step S30: Based on the large language model and the current state information, iteratively generate candidate action sequences to advance the reasoning process. This step, implemented by the Large Language Model Reasoning Engine (LLMRE), is the core of the "generation" process in the entire closed-loop iterative architecture.

[0235] LLMRE takes the current state of the AWM as contextual input and generates a sequence of candidate inference steps that satisfy the task constraints. After receiving structured correction instructions from the Feedback Generation Module (FGM), it can perform targeted corrections on specified inference steps instead of regenerating the entire model. The core design of LLMRE lies in three aspects: First, it accurately transmits the complete state information in the AWM to the large language model through structured prompts, avoiding information loss or semantic drift; second, it achieves a balance between exploration depth and computational cost through multi-path parallel generation and bundle search strategies; and third, it achieves accurate error correction rather than brute-force retries through a feedback-driven targeted correction mechanism.

[0236] Step S30 specifically includes the following sub-steps S301 to S304.

[0237] Sub-step S301: Structured Hint Construction. Sub-step S301 serializes the current state information into structured hints containing multiple fixed partition formats. Structured hints serve as an information bridge between the Large Language Model (AWM) and the AWM—they transform the structured state information (knowledge rules, reasoning states, path graphs) stored in the AWM into a natural language instruction format that the Large Language Model can understand and follow, ensuring that the model has complete and accurate context when generating candidate reasoning steps.

[0238] (1) Structured prompt partition design

[0239] Structured hints use a fixed partition format, with partitions arranged in a fixed order, and each partition responsible for conveying specific information. Hints must include at least the following seven partitions: ,

[0240] (2) Serialization method of partition content

[0241] The serialization of the content in each partition follows these principles:

[0242] Structured presentation: For set-type data (such as P_proved, P_pending), a numbered list is used to present each entry, with each entry accompanied by its unique identifier (such as proposition ID) and a brief description, which is convenient for the model to refer to during the generation process.

[0243] Constraint Priority Labeling: In the [Available Rules Area], rules are prioritized—high-priority rules (such as those directly matching the current goal) are listed first, and low-priority rules are listed later. The ranking criteria include: the structural similarity between the rule and the current goal, and the frequency of the rule's use in historical successful paths.

[0244] Concise representation of failure information: The failure summary in the [historical failure area] adopts a compact format of "step number + brief description of failure reason + key error expression" to avoid excessive redundant information that may distract the model while ensuring sufficient warning effect.

[0245] Structured expression of feedback instructions: The correction guidelines in the [feedback area] adopt a mapping format of "error step number → error type → suggested correction direction", which enables the model to accurately locate the steps that need to be corrected and their correction strategies.

[0246] (3) Build timing and caching strategy of the prompt

[0247] Structured hints are rebuilt in each iteration because the AWM state may change after each iteration (P_proved increases, P_pending is updated, the iteration number in C_context increases, etc.). To improve efficiency, the system adopts an incremental build strategy: only the content of the changed partitions is updated (such as adding newly validated propositions to the [Known Conditions] section, and injecting new correction instructions into the [Feedback] section), while the content of fixed partitions (such as the [Task Definition] section and the [Output Format] section) is cached and reused after the first build.

[0248] Sub-step S302: Generation of multi-path candidate inference steps. Sub-step S302, based on the structured prompts, calls the large language model to generate k candidate inference steps with a preset bundle width. Multi-path generation is the foundation of the bundle search strategy—by generating multiple candidate steps at once, the system can retain multiple alternative paths in the early stages of inference, avoiding premature commitment to a potentially incorrect inference direction.

[0249] (1) Setting the beam width k

[0250] The beam width k is a preset integer greater than or equal to 2 (default value k=3). The choice of k value needs to be weighed between inference quality and computational cost:

[0251] Larger k values ​​(e.g., k=5~10) can explore more diverse reasoning paths and increase the probability of finding the correct path in the end, but will correspondingly increase the computational overhead of each iteration (number of large language model calls × k, number of verifications × k).

[0252] Smaller k values ​​(e.g., k=2~3) are more computationally efficient, but in complex reasoning tasks, they may lead to an increase in the number of global backtracking attempts due to prematurely eliminating the correct path.

[0253] The system supports dynamically adjusting the value of k based on task complexity: for M-type mathematical proof tasks, the default value is k=3; for P-type program verification tasks with higher complexity, the value can be increased to k=5; for simple tasks, the value can be decreased to k=2.

[0254] (2) Calling and generation of large language models

[0255] The structured suggestions built in sub-step S301 are input into a large language model (such as a base model like GPT-4, Claude 3.5 Sonnet, or DeepSeek), and the generation parameters are set to encourage candidate diversity:

[0256] The temperature parameter was set to 0.7~0.9 to achieve a balance between generation quality and diversity;

[0257] Top-p sampling (kernel sampling) is set to 0.9 to truncate low-probability outputs to maintain the reasonableness of the generated content;

[0258] Set an independent random seed for each candidate to ensure the difference between the k candidates.

[0259] Under the constraints of the output format area, the model returns k candidate inference steps in a uniform structured data format.

[0260] (3) Data format of candidate inference steps

[0261] Each candidate inference step is output in a uniform structured data format. This format includes at least the following fields: ,

[0262] (4) Preliminary filtering of candidate steps

[0263] Before submitting candidate reasoning steps to the validator (step S40), the system performs preliminary filtering:

[0264] Check if the formal_expression field is empty or obviously truncated;

[0265] Check if applied_rule is within the [available rules area] range (if not, mark it as "rule unavailable" and skip validation to reduce invalid validation calls);

[0266] Check if the steps referenced in dependency_steps actually exist in P_proved (if not, mark it as "dependency missing").

[0267] The initial filtering process uses quick rule checks to remove obviously invalid candidates, thus avoiding submitting clearly erroneous results to the computationally expensive validator.

[0268] Sub-step S303: Beam Search Path Management. Sub-step S303 maintains k active inference paths simultaneously, submits the current candidate inference steps of each active inference path to the verification unit for verification, and performs path management operations based on the verification results. Beam search path management is the core mechanism for LLMRE to achieve parallel exploration and intelligent fault tolerance.

[0269] (1) Parallel maintenance of paths: The system maintains data structures for k active inference paths simultaneously in memory. Each path contains the following information:

[0270] Path unique identifier (path_id);

[0271] The current inference state of this path (referencing the state definition in AWM, but each path independently maintains its own copy of P_proved, P_pending, and C_context, which is only synchronized to the global AWM after verification).

[0272] The current depth of the path (number of verified steps);

[0273] The historical sequence of path steps (used for updating the path map);

[0274] The cumulative confidence score of the path (the cumulative confidence score of each step).

[0275] (2) Path management operations for verification results: After the candidate inference steps for each path are submitted to the verification unit, the following management operations are performed based on the verification results:

[0276] Branch 1: Validation passed – Path preserved and advanced

[0277] For candidate inference steps that pass validation, the corresponding paths are retained. Specific operations include:

[0278] Update the formal conclusions corresponding to the candidate reasoning steps to the state space of the path (add P_proved to the path and update P_pending).

[0279] The verified steps are appended to the historical step sequence of this path;

[0280] Increment the depth of the path by 1;

[0281] The path continues to the next round of reasoning (returning to sub-step S301 to construct the next round of hints based on the updated state).

[0282] If multiple paths pass the verification at the same time, all successful paths are retained and advanced independently without pruning (because the verifier has given a deterministic judgment, all paths that pass the verification are valid paths).

[0283] Branch 2: Verification Failure - Log and Feedback Trigger

[0284] For candidate inference steps that fail verification, the failure information of the corresponding path is recorded in the inference path graph, and the feedback generation process is triggered. Specific operations include:

[0285] In the reasoning path graph, add a directed edge from the current node to the "failure termination node" for each failed attempt, and label the reason for the failure.

[0286] Mark the path as "blocked" but do not discard it immediately (because it may be recovered later through feedback correction);

[0287] The failure category label generation in step S40 is triggered, and the feedback generation process in step S50 is invoked to generate structured correction instructions.

[0288] If the path can generate correction steps and pass verification after receiving the correction instruction, the path can be restored from the "blocked" state and continue to advance.

[0289] Branch 3: Full path failure - Global backtracking

[0290] When all k active inference paths fail verification at the same number of inference steps, a global backtracking operation is performed. Global backtracking is a key mechanism for handling scenarios where multiple paths are simultaneously stuck, and it specifically includes:

[0291] Each path is rolled back to the most recently verified common fork node (i.e., the last shared state node of each path starting from the initial state S_0).

[0292] Based on the failure history information recorded in the reasoning path graph (including the specific error type and failure reason summary of each failure path), this taboo information is summarized and injected into the [historical failure area] of the new round of structured prompts in sub-step S301;

[0293] The large language model is guided to generate new candidate reasoning steps at the fork node and re-explore along the new branch;

[0294] Reset the depth of each path to the depth of the common fork node, and restart from that node.

[0295] Branch 4: Backtracking Exceeds Limits - Terminate and Exit

[0296] If the cumulative number of global backtracking operations exceeds the preset backtracking limit (default R_max=5), the current inference task is determined to be unfinishable within the existing inference framework, the inference process is terminated, and a failure report is output. The failure report includes: the total number of paths explored, a summary of the reasons for failure, the status of the most advanced path, and suggested directions for manual intervention or parameter adjustment.

[0297] (3) Path selection and pruning strategy: In each iteration, the system selects which paths from the k paths to advance to the next iteration. The selection strategy is as follows:

[0298] All valid paths are preserved (without pruning) because the validator provides a deterministic guarantee;

[0299] If a blocked path receives a valid correction instruction, it will be reactivated after the correction verification is successful.

[0300] If no path passes the verification step is generated in multiple consecutive rounds (default 3 rounds), the system will prune the path separately, mark it as "stagnant", and remove it from the active path set, even if the global backtracking trigger condition is not met.

[0301] Sub-step S304: Feedback-driven targeted correction. In response to the received structured correction instruction, sub-step S304 injects the structured correction instruction into the preset feedback partition of the structured prompt, re-invokes the large language model, generates corrected candidate inference steps for the specified inference step, and submits the corrected candidate inference steps to the verification unit for re-verification. Targeted correction is the core innovation of LLMRE that distinguishes it from the "complete restart" strategy—it only corrects the specific step that errs, retaining the remaining parts of the inference chain that have been verified as correct.

[0302] (a) Receiving and parsing the correction instruction: The system receives a structured correction instruction from the feedback generation module (step S50). The correction instruction contains at least the following information (step S504):

[0303] Error step number (error_step_id): pinpoints exactly which candidate inference step went wrong;

[0304] Error type (error_type): such as logic layer error, target layer error, constraint layer error, or formal layer error;

[0305] Error location expression fragment (error_location): The specific expression fragment that caused the error;

[0306] Error description (error_description): A natural language description of the reason for the error;

[0307] Suggestions for correction: a list of candidate alternative rules recommended by the rule base (up to three);

[0308] Excluded_summary: Taboo information related to the current error.

[0309] (ii) Construction of correction prompts: The system constructs targeted correction prompts based on correction commands.

[0310] Fill the [feedback area] with correction instructions from the copy of the structured prompts;

[0311] Append a summary of the current error to the [failure history area] ("Note: Step {step_id} failed in the previous attempt, reason: {error_description}, path summary excluded: {excluded_summary}").

[0312] Add the following constraint to the [Output Format Area]: "Please only correct step {error_step_id}, regenerate the formal_expression for that step, and ensure that the corrected step meets the resolution requirements of {error_type}. Other verified steps remain unchanged."

[0313] Retain all content in the original structured prompts except for the step being corrected (P_proved, P_pending, and other state information) to ensure that the model has a complete context during correction.

[0314] (iii) Generation and verification of the correction steps: Input the correction prompts into the large language model, and the model returns the corrected candidate inference steps. The data format of the correction steps is consistent with the format in sub-step S302 (JSON structure).

[0315] Submit the revised candidate reasoning steps to the validator for re-validation:

[0316] If the verification passes: the corrected step is recorded as a new branch in the inference path graph, and the branch corresponding to the original failed inference step is retained in the inference path graph and is not overwritten. The path resumes its progression, and inference continues from the corrected step.

[0317] If verification still fails: the correction attempt will also be recorded in the inference path graph (marked as "second failure"), and the feedback generation process will be triggered again. If the same error on the same path fails to be corrected more than the preset number (default 2 times), the system will determine that the path is not capable of correcting this error, mark the path as "correction failed", and remove it from the active paths.

[0318] (iv) The strategy for retaining the original failed branch: A key design feature of this invention is that the branch corresponding to the original failed verification reasoning step is retained in the reasoning path graph and is not overwritten. This design has the following technical advantages:

[0319] Historical traceability: A complete failure history is available for human review, helping to understand why the system made certain reasoning choices;

[0320] Accumulation of taboo information: The error types and reasons for failure in failed branches are extracted as taboo information for reference in subsequent reasoning (including different branches of the same task or completely different reasoning tasks), realizing "reuse of failure experience";

[0321] Comparative analysis capability: By comparing failed branches and successful branches at the same fork point, the basis for choosing the correct reasoning strategy can be analyzed, providing data support for the automatic optimization of the knowledge rule base.

[0322] The complete information flow of sub-steps S301~S304 can be summarized as follows: AWM state serialization into structured prompts → Large language model generates k candidate inference steps → Each path is submitted for verification independently → If it passes, it is retained and advanced; if it fails, it is recorded and feedback is provided → If all fail, it is globally backtracked → If the limit is exceeded, it is terminated → After receiving the correction instruction, it is corrected in a targeted manner → If the correction passes, it is recorded as a new branch, and the original failed branch is retained without being overwritten.

[0323] Steps S301 to S304 above describe a preferred implementation of a Large Language Model Inference Engine (LLMRE), in which a single large language model is responsible for generating candidate inference steps, and a bundle search strategy simultaneously maintains k active inference paths to balance exploration depth and breadth. However, the present invention is not limited to the above implementation. Depending on the inference complexity of different tasks, computational resource constraints, and verifier call costs, the inference engine can adopt the following alternative construction schemes.

[0324] Alternative Solution 1: Replace the single large language model inference engine with a multi-agent collaborative architecture: The "Proposer Agent" is responsible for generating candidate inference steps, and the "Critic Agent" pre-screens and scores the candidate steps. The screened candidate steps are then submitted to an external validator to reduce the number of validator calls and reduce computational overhead.

[0325] Alternative 2: Replace the bundle search strategy with a process reward-guided depth-first search (DFS) or best-first search, which has higher search efficiency in task scenarios with deep inference branches but few forks.

[0326] Thus, step S30 completes the entire process of generating, verifying, managing paths, and correcting the candidate action sequence, forming a close connection between the verification in step S40 and the feedback in step S50.

[0327] Step S40 performs multiple verifications on the candidate action sequence, including at least syntactic correctness verification and semantic logical consistency verification. This step is implemented by the PluggableVerifier (PV) module and is the core of the "verification" in the entire closed-loop iterative architecture. It provides objective and deterministic correctness judgments for the candidate inference steps generated by the large language model, fundamentally changing the open-loop mode of "generation is the answer" in traditional large language model inference.

[0328] The core design concept of multiple verification includes three aspects: First, determinism—the verification results are based on objective standards such as formal logic, program execution, or physical constraints, rather than the subjective judgment of the model, thus the verification results are reliable and repeatable; Second, multiplicity—different task types require different types of verification (mathematical proofs require type theory checks, programs require execution tests, scientific inferences require physical consistency checks, and engineering decisions require standard compliance checks), and the system supports multiple verification methods simultaneously through a plug-in architecture; Third, pluggability—verifiers are connected to the system through a unified interface protocol, which can be flexibly selected, switched, and horizontally expanded according to the task type, giving the system good scalability and adaptability. The input fields of the unified interface protocol include at least: the step number of the reasoning step to be verified, the formal reasoning expression, the state snapshot of the current state space, and the verifier type identifier; the verifier type identifier is used to specify the type of verifier currently used.

[0329] The output fields of the unified interface protocol include at least: a verification status field, which takes the value of success or failure; an error type field, the value of which includes at least type error, target unclosed, rule conflict, syntax error, and timeout; an error location field, which includes at least the step number of the reasoning step to be verified and the error expression fragment; a list of remaining incomplete targets; and a verifier raw output information field, used for logging and debugging.

[0330] The multi-factor verification is implemented using a plug-in verification architecture, which connects to at least two different types of verifiers through a unified interface protocol. The type of verifier is selected and switched according to the task type of the current inference task.

[0331] (a) Plug-in architecture of validators

[0332] The validator module adopts a plug-in architecture, with all validators connecting to the system through a unified validator interface protocol (UnifiedVerifierInterfaceProtocol). The core features of this architecture include:

[0333] 1. Plug and play access mechanism

[0334] Each validator implements a unified interface specification (including standard methods for input parameter parsing, validation execution, and result output), and is registered in the system via a configuration file (such as YAML or JSON format). Registered validator plugins are dynamically loaded upon system startup, and at runtime, candidate inference steps are routed to the corresponding validator instance based on the task type identifier (M / P / S / E).

[0335] 2. Types and Selection Strategies of Validators

[0336] The system supports multiple types of validators, including: ,

[0337] The selection of validators is based on the task type identifiers obtained in step S102: M-type tasks are routed to the mathematical formalization validator, P-type tasks are routed to the program execution validator, S-type tasks are routed to the scientific consistency validator, and E-type tasks are routed to the engineering rule engine. For composite tasks (such as mixed tasks that include both mathematical proof and program verification), the system supports chaining multiple validators—candidate steps are checked by each validator in turn, and the overall verification is considered successful only when all validators return SUCCESS.

[0338] 3. Horizontal scaling support for validators

[0339] The validator cluster layer supports horizontal scaling to handle high-concurrency verification requests. When the verification task queue backlog exceeds a preset threshold (e.g., queue length > 100), the system automatically starts new validator instances (e.g., starting additional Lean4 prover containers or sandbox execution nodes) to achieve elastic scaling of verification capabilities.

[0340] (II) Specific Implementation of the Four Verifiers

[0341] (1) Mathematical formal verifier

[0342] The mathematical formal verifier integrates interactive theorem provers such as Lean4 and Coq, running as independent subprocesses. Formal proof steps generated by the large language model (expressed in the form of proof strategies, Tactics) are submitted to the verifier for compilation and type checking. The verifier performs rigorous type-theoretic verification on the input proof fragments.

[0343] The verification process is as follows:

[0344] Syntax parsing: Submit the formal_expression field in the candidate reasoning step to the prover parser to check whether it conforms to the syntax specification of the target formal system (such as Lean4).

[0345] Type checking: Verifies that the types of all variables in the expression match, and that the definitions and theorems of all references exist and have consistent type signatures.

[0346] Target state check: Check whether the current proof strategy can close the current target (i.e., after applying the strategy, whether the current proof target is decomposed into simpler sub-targets or completely closed).

[0347] Timeout Control: The validator has a timeout control (default 30 seconds / step). If the timeout occurs, the verification is considered to have failed and a TIMEOUT error type is returned.

[0348] The verification output includes: SUCCESS or Failure (including specific error types such as TYPE_ERROR, GOAL_NOT_CLOSED, SYNTAX_ERROR, etc., error location, and list of unclosed targets).

[0349] (2) Program execution verifier

[0350] The program execution verifier executes the program code generated by the large language model in an isolated sandbox environment and verifies the correctness of the output against the predefined test case set (TestSuite); it also supports pre / postcondition contract verification to check whether the program meets the functional specification.

[0351] The verification process is as follows:

[0352] Code compilation: Compile the program code in the candidate inference steps in the sandbox environment (if compilation fails, return SYNTAX_ERROR).

[0353] Test case execution: Runs a predefined set of test cases and compares the program output with the expected output. This verification is successful when all test cases pass.

[0354] Contract checking: Extract the preconditions (Requires) and postconditions (Ensures) assertions in the program, and verify whether these assertions are true before and after program execution.

[0355] Resource isolation: The sandbox environment strictly limits CPU time, memory usage, network access, etc., to prevent malicious code from affecting the host system.

[0356] (3) Scientific Consistency Verifier

[0357] The scientific consistency verifier targets scientific inference tasks (S-type), constructs a set of constraint rules based on domain physical laws, chemical conservation rules, etc., and performs consistency checks on the inference conclusions of large language models; it also supports access to a domain simulator to perform numerical simulation verification of the inference conclusions.

[0358] The verification process is as follows:

[0359] Constraint rule matching: Based on the physical quantities / chemical substances involved in the reasoning conclusion, retrieve the corresponding conservation laws (such as conservation of mass, conservation of energy, conservation of momentum) and physical laws (such as Newton's laws, laws of thermodynamics) from the constraint rule set.

[0360] Consistency check: Checks whether the inference conclusion is consistent with all matching constraint rules. If a conflict exists (e.g., the total mass of reactants in the inference conclusion is not equal to the total mass of products), a RULE_VIOLATION error type is returned.

[0361] Simulation verification: For quantifiable scientific inferences, the reasoning conclusions are submitted as input parameters to the domain simulator for numerical simulation to verify whether the simulation results are within a reasonable error range.

[0362] (4) Engineering rule engine

[0363] The engineering rules engine encodes engineering specifications, industry standards, and safety constraints into a set of rules for engineering decision-making tasks (Category E), and performs compliance checks on the design schemes output by reasoning.

[0364] The verification process is as follows:

[0365] Standard coding: Encode engineering specification clauses (such as "safety factor shall not be less than 2.0" and "material yield strength shall not be less than 345MPa") into executable rule expressions.

[0366] Check each rule individually: Traverse all rules and check whether the design solution output by the reasoning satisfies each rule. If any rule is not satisfied, return RULE_VIOLATION and indicate the specific rule number that was violated.

[0367] Priority weighting: Different specification clauses have different priorities (e.g., security constraints are hard constraints, performance recommendations are soft constraints). Violation of hard constraints is directly judged as verification failure, while violation of soft constraints only generates warning messages.

[0368] (III) Unified Verifier Interface Protocol

[0369] All validators adhere to a unified interface protocol specification. This protocol standardizes the data format for validator inputs and outputs, ensuring standardized communication between validators and other modules of the system.

[0370] (a) Input field definition ,

[0371] (ii) Output field definition ,

[0372] (iv) Verification of the execution process

[0373] (a) Scheduling of verification tasks

[0374] After candidate inference steps are generated (step S30), the system submits the verification request for each candidate step to the verifier scheduling layer. The scheduling layer performs the following operations:

[0375] Task queue management: Add verification requests to the verification task queue (TaskQueue) and assign them to the corresponding verifier node according to the task type (MATH / PROGRAM / SCIENCE / ENGINEERING).

[0376] Timeout control: Set a timeout timer for each verification task (default 30 seconds). The verification task will automatically terminate and return a TIMEOUT error after the timeout.

[0377] Result aggregation: For multi-path verification scenarios (k paths in beam search), the scheduling layer collects the return results of each verifier node, aggregates them according to the path identifier, and returns them to the inference computing layer in a unified manner.

[0378] (ii) Parallel verification execution

[0379] For k active inference paths in the beam search, the system submits the candidate inference steps of each path to a validator for independent verification. The verification tasks for each path are executed in parallel (in a multi-validator node environment) without affecting each other. The advantage of parallel verification is that even if the verification of one path fails, the verification of other paths is not affected, significantly improving inference efficiency.

[0380] (III) Processing of Verification Results

[0381] After verification is complete, the following branch processing will be executed based on the verification results:

[0382] Branch 1: Validation passed (status=SUCCESS)

[0383] If the candidate action sequence passes the multiple verifications, the state information is updated based on the candidate action sequence, and the process returns to step S30 to continue iteration. Specific operations include:

[0384] Call the state transition operation in step S203 to incorporate the verified conclusion into AWM (update P_proved, P_pending, C_context).

[0385] Add a pass node and a directed edge (labeled SUCCESS) to the inference path graph for this path.

[0386] Return to step S30 and generate the next round of candidate inference steps based on the updated AWM state.

[0387] Branch 2: Validation failed (status=FAILURE)

[0388] If the candidate action sequence fails the multiple verifications, a corresponding failure category label and error context information are generated, and the process proceeds to step S50. Specific operations include:

[0389] Based on the error_type and verifier_message output by the verifier, generate failure category labels (logic layer error / target layer error / constraint layer error / formal layer error) – this step is elaborated in step S501;

[0390] By combining error_location and AWM inference path graph, complete error context information is generated (including error step number, error expression fragment, list of currently incomplete targets, etc.).

[0391] Add failure nodes and directed edges (labeled with FAILURE and a summary of the reasoning reason) to failed attempts in the reasoning path graph.

[0392] In step S50, the feedback generation module converts the technical error information into structured correction instructions that can be understood by the large language model.

[0393] (v) Fault tolerance and reliability assurance of the verifier

[0394] (a) Verifier Fault Isolation

[0395] Each validator runs as an independent process or container, and a validator crash will not affect other modules of the system (such as AWM and LLMRE). The validator scheduling layer monitors the health status of each validator node. When a validator node is detected to be unresponsive or has exited abnormally, it will automatically restart the node and reassign the current validation task to a standby node.

[0396] (ii) Cache of verification results

[0397] To improve verification efficiency, the system caches verification results. The cache key is composed of the hash value of formal_expression and verifier_type, and the cache value is the verification result (status + error_type + verifier_message). When the same candidate inference step reappears in subsequent iterations (e.g., different paths produce the same intermediate step), the system directly reads the verification result from the cache, eliminating the need to repeatedly call the verifier and significantly reducing computational overhead.

[0398] (III) Hierarchical Verification Strategy

[0399] The system supports a tiered verification strategy to optimize computing resource allocation:

[0400] Quick Validation: Performs only syntax correctness checks (such as parser checks and type checks), takes a short time (<1 second), and is used for initial screening;

[0401] Full verification: Executes all verification content (including semantic and logical consistency verification, program execution, simulation verification, etc.), which takes a long time (several seconds to tens of seconds) and is only performed on candidate steps that have passed the fast verification.

[0402] The tiered verification strategy avoids wasting resources on high-cost verification—by quickly verifying and eliminating obviously invalid candidates, only allowing promising candidates to enter the complete verification process.

[0403] The complete information flow of step S40 can be summarized as follows: Candidate reasoning steps are submitted through a unified interface protocol → the scheduling layer routes to the corresponding validator → the validator performs dual syntactic and semantic verification → outputs standardized verification results (SUCCESS / FAILURE + error details) → if successful, a state transition is triggered and the process returns to S30 → if unsuccessful, a failure label and error context are generated and the process enters S50, while the failure record is written to the path graph.

[0404] Thus, step S40 completes the external objective verification of the content generated by the large language model, providing a precise source of error information for the feedback generation in step S50.

[0405] Step S40 above describes a preferred implementation scheme for multiple verifications, wherein the mathematical formal verifier uses the Lean4 / Coq theorem prover for deterministic verification, the program execution verifier uses sandbox execution and test case verification, the scientific consistency verifier performs consistency checks based on a set of physical law rules, and the engineering rule engine performs compliance checks based on a set of specification rules. However, the present invention is not limited to the above implementation scheme. Depending on the verification requirements of different tasks (such as the existence of formal specifications, verification rigor requirements, computational resource constraints, etc.), the verifier module can adopt the following alternative construction schemes.

[0406] Alternative Option 1: Replace the deterministic formal validator with or combine it with a learning-based process reward model (PRM). The PRM provides probabilistic scoring for inference steps, serving as a supplement to the deterministic validator or as a replacement in domains without formal validators, sacrificing some validation rigor for broader domain coverage. When using this option, the system's reliability guarantee is downgraded from "deterministic" to "high confidence," which must be explicitly stated in the claims.

[0407] Alternative Solution 2: Employ an ensemble verification mechanism, which aggregates the verification conclusions of multiple independent verifiers for the same reasoning step and uses majority vote as the final verification criterion to improve verification robustness. This is suitable for scenarios where the reliability of a single verifier is insufficient.

[0408] Alternative Solution 3: For program verification tasks, replace the test case execution verifier with a formal program verifier (such as Dafny or Why3) to perform a complete functional correctness proof of the program, thereby further improving the rigor of program verification.

[0409] Step S50: Feedback Generation and Targeted Correction. Step S50 generates structured correction instructions based on the failure category label and the error context information, using a preset feedback strategy. These instructions are then fed into the large language model generation process in Step S30 to instruct subsequent iterations to avoid the types of errors that have occurred and adjust the generation direction of candidate action sequences. This step is implemented by the Feedback Generation Module (FGM), which is the core of the "feedback" in the entire closed-loop iterative architecture. It transforms the technical error information output by the validator into structured feedback that the large language model can understand, precisely guiding the model to perform targeted reasoning corrections.

[0410] The core design philosophy of the feedback generation module includes three aspects: First, the translation of error semantics—error information output by the validator (such as Lean4 compiler reports and type check error stacks) is technically complex and semantically granular, making it difficult for large language models to understand directly. FGM translates it into correction guidelines described in natural language. Second, the certainty of correction direction—correction direction suggestions are obtained by retrieving them from the knowledge rule base through rule matching, rather than relying on the large language model itself to generate them, fundamentally avoiding the risk of "correcting errors with errors". Third, a hierarchical feedback mechanism—from error classification, precise location, correction direction generation to structured assembly, each step is progressive, ensuring the completeness and accuracy of the feedback information.

[0411] Step S50 specifically includes the following sub-steps S501 to S505.

[0412] Sub-step S501: Error Classification

[0413] Sub-step S501 classifies the occurring error into the corresponding category in the predefined error category set based on the error type field (error_type) output by the verifier. Error classification is the primary step in feedback generation—different error types require different correction strategies, and accurate classification is a prerequisite for targeted correction.

[0414] (a) Predefined set of error categories

[0415] The predefined set of error categories includes at least the following four error categories: ,

[0416] (ii) Mapping Logic for Misclassification

[0417] Error classification is based on mapping the error_type field output by the validator (with values ​​ranging from TYPE_ERROR, GOAL_NOT_CLOSED, RULE_VIOLATION, SYNTAX_ERROR, TIMEOUT, etc.) to the four error categories mentioned above. The mapping rules are as follows:

[0418] If error_type is SYNTAX_ERROR or TYPE_ERROR, it is classified as a formal error (FORMAL_ERROR) - this type of error indicates that the expression itself does not conform to the syntax or type specification of the formal system. It is a "compilability" level problem, with the highest priority, and must be resolved first.

[0419] If error_type is GOAL_NOT_CLOSED and the error message points to "the current target does not match the postcondition of the applied rule", it is classified as a logic layer error (LOGIC_ERROR) - this type of error indicates that the inference rule was selected incorrectly and needs to be changed;

[0420] If error_type is GOAL_NOT_CLOSED and the error message points to "the newly generated sub-target is unrelated to the original target", it is classified as a target-level error (GOAL_ERROR) - this type of error indicates that the reasoning direction has deviated from the correct path and the strategy needs to be adjusted;

[0421] If error_type is RULE_VIOLATION and the error message points to "violation of known constraints", it is classified as a constraint layer error (CONSTRAINT_ERROR) - this type of error indicates that the conclusion has touched the hard constraint red line and a conclusion that meets the constraints needs to be regenerated;

[0422] If error_type is TIMEOUT, it is classified as a comprehensive error. Timeouts can be caused by various reasons (excessive inference path, getting stuck in a loop, excessive computational complexity of the validator, etc.). Before classifying, the system checks the output before the timeout. If there are other error types in the output, it is classified according to the corresponding category. If there is no clear error, it is classified as a target layer error (because timeout means that the inference progress has stalled).

[0423] (iii) Output of misclassification

[0424] After error classification is completed, the system generates the following output information:

[0425] error_category: Error category identifier (LOGIC_ERROR / GOAL_ERROR / CONSTRAINT_ERROR / FORMAL_ERROR);

[0426] error_category_description: A Chinese description of the error category (e.g., "Logical error: The reasoning rule used is not applicable to the current propositional structure").

[0427] priority_level: Correction priority (formal layer error > constraint layer error > logic layer error > target layer error), used to determine the processing order when generating subsequent correction directions - formal layer errors must be resolved first, because logic and semantic analysis are meaningless if syntax errors are not resolved.

[0428] Sub-step S502: Precise error location

[0429] Sub-step S502 combines the error location information output by the verifier with the current inference path graph to accurately locate the step number that caused the error and the corresponding expression fragment. The accuracy of error location directly affects the efficiency and accuracy of correction—"correcting the error" is more critical than "knowing that there is an error."

[0430] (a) Sources of location information

[0431] Error location information comes from two data sources:

[0432] Data source 1: The error_location field output by the validator. This field must contain at least:

[0433] step_id: The error step number reported by the validator;

[0434] expression_fragment: The erroneous expression fragment pointed out by the validator (such as the specific line of code that caused the error, a subexpression with a mismatched type, etc.);

[0435] line_number (optional): If the validator supports line number output (such as compiler reports), provide the line number of the error;

[0436] column_range (optional): The range of characters at the error location.

[0437] Data source two: Node and edge information in the inference path graph (step S204). By matching the step_id reported by the validator with the node numbers in the path graph, the system is able to:

[0438] Obtain the complete inference context of the erroneous step (including the steps it depends on, inference rules, and previous states).

[0439] Tracing back the generation history of this step (e.g., whether it has been corrected, whether there have been similar failures before);

[0440] Obtain the position (depth, branching relationship) of this step in the reasoning path graph, and determine whether the error is an isolated problem or a structural problem affecting the entire path.

[0441] (ii) Precise positioning at multiple granular levels

[0442] The system supports multi-level granularity positioning and automatically selects the appropriate positioning accuracy based on the error type. ,

[0443] (III) Contextual Analysis

[0444] After determining the location of the error, the system further performs contextual analysis:

[0445] Dependency chain check: This checks whether there are potential problems in the preceding steps that the erroneous step depends on—sometimes the root cause of the error is not in the current step, but in the preceding steps that provide incorrect intermediate conclusions. If there are preceding steps with low confidence scores (<0.5) or steps that have been corrected, the system marks them as "suspicious dependencies" and includes them in the localization results.

[0446] Similarity error detection: The system queries the inference path graph to check if there are historical failure records that are similar to the current error type and location (e.g., the same error type, the same rule application scenario). If so, the system extracts historical correction strategies as a reference to avoid repeated trial and error.

[0447] (iv) Output of positioning results

[0448] After precise positioning is completed, the system generates the following output information:

[0449] target_step_id: A unique identifier for the erroneous step;

[0450] target_expression_fragment: The specific expression fragment of the error (accurate to the subexpression level);

[0451] dependency_suspicion_list: A list of suspicious preceding dependency steps (if any);

[0452] historical_similar_errors: Historical similar error records and corresponding correction strategies (if any);

[0453] location_description: Natural language description of the error location (e.g., "In step P1-003, at the type annotation of '∀(nm:ℕ)', the type 'Prop' does not match the expected 'Nat→Prop'").

[0454] Sub-step S503: Correction direction generation

[0455] Sub-step S503, based on the categorized error types and the current knowledge rule base, retrieves candidate alternative rules that match the current error structure from the knowledge rule base through rule matching, and generates at least one correction direction suggestion.

[0456] (I) Design Principles of "Rule Matching Retrieval"

[0457] The most critical design principle in this step is that the suggested correction direction is obtained from the knowledge rule base through rule matching, rather than relying on the large language model itself for generation. The technical reason for this principle is:

[0458] Avoid the risk of “correcting errors with errors”: In a context where an error has already occurred, the large language model may not accurately determine the cause of the error. If the model is relied upon to generate correction directions on its own, new errors may be generated, creating a vicious cycle of error propagation.

[0459] Ensure the certainty of the correction direction: The rules in the knowledge rule base are domain knowledge that has been formally verified. The alternative rules retrieved through structure matching are logically certain and correct, which at least ensures that the correction direction itself does not violate domain constraints.

[0460] Computational efficiency advantage: Rule-based matching retrieval is an index-based structured query (such as pattern matching and graph matching), with a computational cost that is far lower than calling a large language model for generation, especially in high-frequency correction scenarios where the efficiency advantage is significant.

[0461] (II) Process for Generating Correction Direction

[0462] The direction correction generation includes the following steps:

[0463] Step 1: Error Structure Extraction

[0464] Extract the structured features of the current error from the localization results:

[0465] Error Modes: Based on the error category (logic layer / target layer / constraint layer / formal layer) and the specific error type, construct error mode identifiers. For example, in the logic layer, "induction applied to non-inductive types" corresponds to the error mode INDUCTION_ON_NON_INDUCTIVE; in the constraint layer, "violation of mass conservation" corresponds to the error mode MASS_CONSERVATION_VIOLATION.

[0466] Current target structure: Extract the current target structure features (such as the type of target, the predicates and constants involved, the current proof state, etc.) of the P_pending set in the reasoning path where the erroneous step is located.

[0467] Failure rule identifier: Extracts the name of the inference rule attempted in the applied_rule field of the erroneous step.

[0468] Step 2: Knowledge Rule Base Retrieval

[0469] Based on the extracted error structure and error pattern, a retrieval is performed in the knowledge rule base (step S201):

[0470] Pattern matching retrieval: Using the error pattern as the query key, pre-labeled "error pattern → alternative rule" mapping entries are retrieved from the knowledge rule base. For example, the alternative rules corresponding to the error pattern INDUCTION_ON_NON_INDUCTIVE include "For this non-inductive type, it is recommended to use a constructive proof strategy" or "It is recommended to first prove the relevant lemmas of this type to support induction."

[0471] Structural similarity retrieval: Using the current target structure as the query vector, the system retrieves rules from the knowledge rule base that are most similar to the current target structure and have historically successfully solved similar targets. Similarity measurement is based on the degree of overlap between the rule's preconditions and the current target (e.g., identical predicates, identical operators, similar structural patterns).

[0472] Tabu exclusion: In the search results, rules that have been marked as taboos by the reasoning path graph (i.e., rules that have failed in the same or similar contexts) are excluded to ensure that the suggested correction direction does not repeat attempts that have been proven to be ineffective.

[0473] Step 3: Sorting and filtering candidate substitution rules

[0474] The retrieved candidate substitution rules are sorted according to the following scoring criteria:

[0475] Match score (40% weight): The degree to which the rule matches the current error structure (full score for a complete pattern match, decreasing score for a partial match);

[0476] Historical success rate score (30% weight): The success rate of this rule in historical reasoning tasks (the higher the success rate, the higher the score).

[0477] Minimum Modification Principle Score (30% weight): The extent of changes required to apply the alternative rule—the smaller the change (such as only replacing the rule name while keeping the rest of the structure unchanged), the higher the score, and the more it is recommended.

[0478] After sorting, the system selects the top three candidate alternative rules as suggestions for correction.

[0479] (iv) Correction of the output format of the direction suggestion

[0480] Each suggested correction direction includes the following information:

[0481] suggested_rule: The name of the inference rule that is suggested as an alternative;

[0482] suggested_rule_description: A Chinese description of the suggested rule;

[0483] replacement_strategy: Description of the replacement strategy (e.g., "Replace 'nat.even_mul' with 'nat.even_div' in step P1-003, and change the precondition from 'evenn' to 'evenn and n≠0'").

[0484] expected_impact: Expected impact of the correction (e.g., "After the replacement, the new sub-target is..., and it is expected to advance the target to completion").

[0485] confidence: The confidence score of the suggestion (a comprehensive score based on rule matching degree and historical success rate, ranging from 0 to 1).

[0486] Sub-step S504: Assembly of structured feedback information

[0487] Sub-step S504 assembles the error category, the error location information, and the correction direction suggestion into structured feedback information according to a preset format. Structured feedback is a carrier of correction instructions that the large language model can accurately understand and execute—it must simultaneously meet the dual requirements of being machine-parseable (facilitating automatic system processing) and model-understandable (facilitating the large language model to execute instructions).

[0488] (a) Field definition of structured feedback information

[0489] The structured feedback information includes at least the following fields: ,

[0490] (ii) Assembly process of structured feedback information

[0491] Step 1: Information Extraction and Summarization

[0492] Extract the required error classification results, location results, correction direction suggestions, and status information from steps S501, S502, S503, and AWM, respectively.

[0493] Step 2: Natural Language Generation of Error Descriptions

[0494] Based on the error category and location information, the `error_description` field is generated using template population. The template library provides pre-defined natural language description templates for each error category.

[0495] Logic layer error template: "In step {step_id}, rule '{rule_name}' was applied, but the precondition of this rule is {precondition}, while the actual condition of the current target is {actual_condition}, and the two do not match. It is recommended to replace it with an alternative rule that applies to {actual_condition}."

[0496] Error template for the target layer: "In step {step_id}, applying rule '{rule_name}' generated subgoals {subgoals}, but these subgoals are irrelevant to the proof progress of the original target {original_goal}. It is recommended to adjust the inference strategy to focus on advancing the completion of the currently pending target {current_pending}."

[0497] Constraint layer error template: "In step {step_id}, the reasoning conclusion '{conclusion}' violates the established hard constraint '{constraint}'. It is recommended to generate an alternative conclusion that conforms to this constraint, with constraint details as: {constraint_detail}".

[0498] Formal error template: "In step {step_id}, the expression '{expression}' failed the syntax or type check. The validator reports an error: {verifier_message}. Please check the syntax and type annotations of the expression to ensure that all variables are correctly defined."

[0499] Step 3: Standardized assembly of feedback instructions

[0500] Assemble all fields into a structured feedback message according to the preset JSON Schema.

[0501] Step 4: Verification of feedback information

[0502] Before sending structured feedback information to LLMRE, the system performs a self-check:

[0503] Check if suggestions is empty (if empty, it means there are no available alternative rules in the knowledge rule base, and the system will generate feedback "Unable to provide correction suggestions, manual intervention is recommended").

[0504] Check if error_description is complete (check if all template placeholders have been filled);

[0505] Check if error_step_id actually exists in the current inference path graph (to prevent incorrect location).

[0506] Sub-step S505: Iteration Termination Control. Sub-step S505 monitors the iteration rounds and global backtracking counts of the current inference process. When the iteration rounds reach the preset maximum iteration round limit or the global backtracking count reaches the preset maximum backtracking count limit, a termination operation is performed. Termination control is the system's "safety valve"—ensuring that the inference process does not loop indefinitely, guaranteeing the system's controllability and the rationality of resource usage.

[0507] (a) Definition of Termination Condition

[0508] The system monitors two metrics simultaneously: ,

[0509] The operation will terminate if either of the two metrics is met. The default values ​​mentioned above can be adjusted in the configuration file according to the task complexity—for known complex tasks (such as large mathematical proofs), N_max and R_max can be increased appropriately; for simple reasoning tasks, they can be decreased to improve response speed.

[0510] (II) Execution process for termination operation

[0511] When the termination condition is met, the system performs the following termination operation:

[0512] Step 1: Optimal Path Selection

[0513] The candidate path with the most verified steps (i.e., the most profound effective path) is selected from the inference path graph. The selection logic is as follows:

[0514] Exclude all paths with a status label of "failed node";

[0515] Among the remaining valid paths, sort them in descending order of depth;

[0516] If the depths are the same, sort them in descending order by cumulative confidence score (the sum of confidence_scores for each step);

[0517] The path ranked first is selected as the optimal path.

[0518] Step 2: Reasoning Process and Output of Results

[0519] Output the reasoning process for this path and the list of currently incomplete targets:

[0520] Inference process output: Output all verified inference steps on this path in the order of steps (including step number, applied rules, intermediate propositions, and formal expressions), forming a complete inference chain from S_0 to the current node;

[0521] List of currently incomplete targets: Output all targets in the P_pending set on this path, clearly indicating which targets have not yet been completed;

[0522] Termination status label: Mark the "Verification incomplete" status in a prominent position in the output result to clearly inform the user that the reasoning has not achieved the goal of complete proof / verification.

[0523] Step 3: Manual Intervention Interface

[0524] The system also outputs the following supplementary information for human experts to review or further process:

[0525] The complete path graph of the current optimal path (including all branches and failure records);

[0526] Summary of the reasons for failure at each failed node;

[0527] A complete log of the current inference process (including all validator outputs, feedback generation records, etc.);

[0528] Manual operation suggestion: "It is recommended that human experts review the deepest path of current progress, assess whether there are any missing inference rules, or consider restarting the inference process after increasing the N_max / R_max parameters."

[0529] (III) Incomplete Termination and Resumption of Breakpoint

[0530] A key design feature of this invention is that the termination of step S505 is an "incomplete termination"—although the system stops the automatic inference loop, all inference states (AWM knowledge rule base, inference state S_t, inference path graph) are fully persisted to the storage layer (the storage layer in step S11) and saved as a "breakpoint snapshot." This design supports the following two subsequent operations:

[0531] Restart after manual intervention: After reviewing the optimal path, if human experts find adjustable parameters or supplementary rules, they can manually modify the configuration file and restore the inference state from the breakpoint snapshot to restart automatic inference.

[0532] Continue with greater computing resources: If the initial N_max / R_max is limited by the computing resource budget, when the resource conditions improve, the number of iterations can be increased from the breakpoint without losing the existing inference results.

[0533] This "incomplete termination" design avoids the waste of "discarding all results upon timeout" in traditional methods, and preserves valuable information in the reasoning process to the maximum extent.

[0534] The complete information flow of step S50 can be summarized as follows: technical error information output by the validator → error classification (mapped to four error categories) → precise error location (step level → expression level → lexical level) → generation of correction direction (rule matching retrieval, non-LLM generation, up to three suggestions) → assembly of structured feedback information (including error description, suggestions, and taboo information) → feedback injection into the [feedback area] of the LLMRE → simultaneous monitoring of iteration rounds and global backtracking counts → when the upper limit is reached, the optimal path is selected to output the inference process and unfinished goals (marked as "validation incomplete"), and breakpoint resumption is supported.

[0535] At this point, step S50 completes the full conversion of error information into correction instructions, providing precise correction guidance for the next round of generation in step S30, and the closed-loop iterative architecture can continue to operate until the termination condition is met.

[0536] Steps S501 to S505 above describe a preferred embodiment of the Feedback Generation Module (FGM), in which the technical error information output by the verifier is transformed into natural language correction instructions understandable by a large language model through error classification, precise localization, correction direction generation, and structured assembly processes. However, the present invention is not limited to the above embodiment. Depending on different task characteristics and optimization objectives, the Feedback Generation Module may adopt the following alternative construction schemes.

[0537] Alternative Solution 1: Replace the structured natural language feedback with reinforcement learning (RL) reward signals, using the pass / fail signals of the validator as rewards, and perform online policy fine-tuning on the large language model, so that the model can gradually improve its inference accuracy on specific tasks through continuous interaction with the validator.

[0538] Alternative Solution 2: Add an error case memory to the feedback generation module, storing typical error patterns that have appeared in historical reasoning and their corresponding effective correction strategies in vector form. When encountering the same type of error in a new reasoning task, targeted correction suggestions are provided through Retrieval-Augmented Generation (RAG) to improve the convergence speed of iterative correction.

[0539] Alternative Solution 2 (Formal Transformation Alternative): The formal transformation based on prompt templates in the above steps can be replaced by a Natural Language to Formal Language (NL2FL) translation model based on a dedicated neural network model. The transformation is completed by a sequence-to-sequence (Seq2Seq) model finely tuned on a domain-specific NL-FL corpus. The legality verification sub-step in the above steps is also applicable under this alternative solution.

[0540] Step S60: Iteration Termination Control and Closed-Loop Management. Step S60 monitors the iteration rounds of the inference process. When the iteration rounds reach a preset upper limit threshold or the state space determines that the target state corresponding to the natural language task has been achieved, the iteration is terminated and the final inference result is output. This step is the "exit" of the entire closed-loop iterative inference architecture—it is responsible for determining when the inference should end and ensuring that the inference result is output in a user-understandable manner.

[0541] Step S60 simultaneously undertakes two key responsibilities: first, iterative termination determination—determining whether to terminate the inference loop through a dual-condition monitoring mechanism (goal achievement determination and resource limit determination); second, closed-loop logic expression—defining the loop path for information transmission between steps S30, S40, and S50 at the system architecture level, and clarifying that the repeated execution of this loop path is controlled by the termination condition of step S60.

[0542] (a) Two-condition monitoring mechanism for iteration termination

[0543] After each iteration (i.e., after the feedback information injection in step S50, or after the state transition is completed in step S40), the system executes the termination condition check in step S60. The determination of the termination condition follows the priority order of "checking the goal achievement first, then checking the resource limit"—if the goal has been achieved, the system terminates immediately without checking the resource limit; if the goal has not been achieved, the system continues to check whether the resource limit has been reached.

[0544] Condition 1: Target state achieved

[0545] When the state space determination reaches the target state corresponding to the natural language task, the iteration terminates and the final inference result is output. The determination of target state achievement is based on the target state explicitly defined in step S105, and varies depending on the task type: ,

[0546] The determination of whether the target state has been achieved also requires additional verification of the completeness of the reasoning chain:

[0547] Dependency chain integrity check: Verify that the dependency chain of all conclusions in P_proved is complete (i.e., the preceding steps that each conclusion depends on do exist in P_proved, and there are no "dangling dependencies").

[0548] Formal statement closure check: For tasks of type M, an additional Qed or Done check of the Lean4 / Coq prover is called to ensure that all objectives in the proof context have been fully consumed by the policy, with no remaining "holes" or unclosed sub-objectives.

[0549] When all the above conditions are met, the system determines that the target state has been achieved and proceeds to the termination output sub-process in step S60.

[0550] Condition 2: Monitoring the upper limit of iteration rounds

[0551] When the number of iterations reaches a preset upper limit threshold, the iteration terminates and the final inference result is output. The system monitors the number of iterations in the current inference process (recorded in the iteration_count field of C_context) and compares it with the preset maximum number of iterations N_max.

[0552] The counting rule for iteration rounds is as follows: starting from the initial state S_0, each time a complete "Generate (S30) → Verify (S40) → Feedback / Correction (S50)" closed loop is completed (regardless of whether the verification is successful or whether feedback is generated in that round), iteration_count is incremented by 1.

[0553] When iteration_count ≥ N_max, the system triggers "timeout termination"—at this point, the target state may not have been achieved, but due to the preset computing resource budget (iteration round limit), the system must terminate automatic inference to avoid infinite loops or resource exhaustion.

[0554] The default value for N_max is recommended to be 10, but it can be adjusted according to the complexity of the task and the constraints of computing resources. For mathematical proof tasks, N_max can be set to 15~20; for program verification tasks, N_max can be set to 10~15; for simple scientific inference or engineering decision-making tasks, N_max can be set to 5~10.

[0555] Connection between dual-condition monitoring and step S505

[0556] Step S505 establishes dual termination control with a maximum number of iterations Nmax and a maximum number of global backtracking iterations Rmax. The upper limit of the number of iterations in step S60 uses the same parameter as Nmax in step S505. The goal achievement determination in step S60 complements the termination output condition in step S505—step S505 focuses on the "optimal path output after resource exhaustion," while step S60 focuses on the "complete result output after normal goal achievement." Together, they constitute the system's complete termination management mechanism.

[0557] (ii) Output processing after termination triggering

[0558] (a) Output processing for successful termination (goal achieved)

[0559] When the target state is achieved, the system outputs the complete final inference result:

[0560] 1. Output of reasoning result summary

[0561] Present the final reasoning conclusion to the user in natural language:

[0562] M-class task: Output confirmation information that the formal proof has been verified, along with the complete text of the theorem statement and proof script;

[0563] P-type tasks: Output confirmation information indicating successful verification, along with the generated program code and a report showing that the test cases have been executed successfully;

[0564] S-type task: Output scientific inference conclusions and confirmation information that all constraint consistency checks have passed, along with simulation verification results (if any).

[0565] Category E task: Output confirmation information indicating that the decision-making plan and all engineering specifications and clauses have passed compliance checks.

[0566] 2. Output of the complete reasoning chain

[0567] Output the complete inference chain from S_0 to S_Goal (including all intermediate steps), presented in a structured format:

[0568] The number of each step, the reasoning rules applied, intermediate propositions / conclusions, and formal expressions;

[0569] The verification results for each step (all marked SUCCESS);

[0570] Dependency graph for each step (showing the dependency chain between steps).

[0571] 3. Output of inference statistical information

[0572] Output statistical information about the inference process to allow users to evaluate inference efficiency:

[0573] Total number of iterations (iteration_count);

[0574] Total number of verification steps (number of propositions in P_proved);

[0575] Number of failed attempts (number of FAILURE nodes in the path graph);

[0576] Number of times feedback is generated and corrected (number of times step S50 is called);

[0577] Total computation time (total running time from step S10 to step S60).

[0578] (ii) Output processing for timeout termination (reaching the upper limit of N_max / R_max)

[0579] When the maximum number of iterations or the maximum number of global backtracking attempts are reached before the target state is achieved, the system executes an "incomplete termination" output:

[0580] 1. Optimal path output

[0581] As described in step S505, the candidate path with the deepest progress (the most verified steps) is selected from the inference path graph, and the inference process of this path and the list of currently incomplete goals are output. The output includes:

[0582] A complete sequence of inference steps from S_0 to the current node of the optimal path;

[0583] The list of currently unfinished targets (the contents of P_pending);

[0584] A summary of all failed attempts on this path (including the steps that failed and the reasons for the failures).

[0585] 2. Termination status label

[0586] Mark the "Verification incomplete" status in a prominent position in the output results to clearly inform the user that the reasoning has not achieved a complete proof / verification goal, and attach a summary of the reasons for failure (such as "Maximum iteration round limit N_max=10" or "Maximum global backtracking number limit R_max=5").

[0587] 3. Recommendations for human intervention

[0588] The following supplementary information will be provided for review by human experts:

[0589] Manual operation suggestions: "The reasoning will terminate if it is incomplete. It is recommended to (1) manually review the deepest path of the current progress and evaluate whether the reasoning progress is reasonable; (2) if the reasoning direction is considered to be correct, the N_max / R_max parameters can be appropriately increased and then restarted; (3) if the reasoning direction is found to be deviated, domain knowledge can be supplemented or the constraints can be adjusted and then restarted."

[0590] Current breakpoint snapshot identifier (facilitates recovery of inference state from storage layer).

[0591] (III) State persistence and breakpoint continuation

[0592] After termination is triggered (whether it's a successful termination or a timeout termination), the system persists the current complete inference state to the storage layer:

[0593] The knowledge rule base (including the initially imported knowledge and the knowledge dynamically expanded during the reasoning process) is persisted to a relational database;

[0594] The reasoning path graph (including all nodes, edges, failure markers, and taboo information) is persisted to the graph database;

[0595] The inference state (a complete snapshot of S_t: P_proved, P_pending, C_context) is persisted to persistent storage in an in-memory database;

[0596] The inference process log (including all validator outputs, feedback generation records, and large language model call records) is persisted to the document database.

[0597] This persistence mechanism supports the following subsequent operations:

[0598] Resume from breakpoint: When inference timeout due to resource limitations, users can adjust parameters and resume inference from the most recent breakpoint snapshot to continue automatic inference without having to start from scratch.

[0599] Historical Reasoning Retrospective Query: Users can query the complete record of historical reasoning tasks (including successful and failed cases) as a reference for subsequent reasoning tasks;

[0600] Knowledge transfer: The knowledge rules extended in successful reasoning can be imported into the initial knowledge rule base of other similar tasks, realizing knowledge reuse.

[0601] (iv) Logical explanation of the closed-loop iterative architecture

[0602] Step S60 not only controls the termination of the iteration at the execution level, but also defines the logical relationship of the entire closed-loop iteration at the system architecture level:

[0603] After the candidate action sequence generated in step S30 is verified in step S40, the verification result is converted into a correction instruction in step S50 and fed back to step S30 as the input basis for subsequent iterations in step S30.

[0604] The above statement clearly defines the information flow between the three core steps:

[0605] Forward flow: S30 (Generation) → S40 (Verification): Candidate action sequences flow from the LLMRE to the validator;

[0606] Conditional branch flow: S40 (validation failure) → S50 (feedback): Validation failure information flows from the validator to the feedback generation module;

[0607] Reverse flow: S50 (feedback) → S30 (generation): Structured correction instructions flow back from the feedback generation module to LLMRE as the input for the next round of generation;

[0608] Forward recovery flow: S30 (correct generation) → S40 (revalidate): The corrected candidate steps are submitted to the validator again.

[0609] Steps S30, S40 and S50 form a loop path for information transmission, and the repeated execution of the loop path is controlled by the termination condition of step S60.

[0610] The above statement clarifies the two core characteristics of the closed-loop architecture:

[0611] (1) The circular path of information transmission

[0612] Steps S30, S40, and S50 constitute a complete information loop, rather than a unidirectional linear process:

[0613] S30 generates candidate steps (carrying inference state information);

[0614] S40 Verify candidate steps (generate verification result information);

[0615] S50 converts the verification results into correction instructions (generating correction guidance information);

[0616] S30 receives the correction instruction and regenerates based on the corrected direction (the correction information is consumed, generating new candidate steps).

[0617] Each complete execution of this loop path represents a "trial and error-correction-trial and error" iteration of the system, and the inference quality is continuously improved in the loop.

[0618] (2) Control body of the loop path

[0619] Step S60 is the "control switch" of this loop path—it is not part of the loop path (it does not participate in information transmission), but rather the monitor and terminator of the loop path:

[0620] When the goal is achieved, S60 "closes" the loop and outputs a success result;

[0621] When resources are exhausted, S60 "closes" the loop and outputs the timeout result and the current optimal path;

[0622] During the execution of the loop path, S60 continuously monitors without interfering with the normal operation inside the loop.

[0623] This control structure ensures the controllability and resource security of the closed-loop iterative process—the system will not continue reasoning indefinitely due to a lack of termination conditions.

[0624] (v) Complete flowchart of termination control

[0625] The complete control flow of step S60 can be summarized as follows:

[0626] Step 1: After each iteration is completed (after step S50 is completed or step S40 is verified), the system enters the termination check process in step S60.

[0627] Step 2: Check whether the target state has been achieved (by comprehensively judging whether the P_pending set of AWM is empty, dependency chain integrity check, formal closure check, etc.):

[0628] If the objective is achieved: the system enters the "Successfully terminated" sub-process, outputs the complete inference results and statistical information, and the process ends.

[0629] If the objective is not achieved: the system continues to check the resource limit conditions.

[0630] Step 3: Check if iteration_count ≥ N_max or global_backtrack_count ≥ R_max is true:

[0631] If any of the conditions are met: the system enters the "timeout termination" sub-process, selects the optimal path (maximum depth, highest confidence), outputs the reasoning process, the list of incomplete targets and the "verification incomplete" status mark, provides suggestions for manual intervention, and the process ends.

[0632] If all conditions are not met: the system determines that the reasoning process should continue and returns to step S30 to start the next iteration.

[0633] Step 4: After the termination operation is completed, the system performs complete state persistence (knowledge rule base, reasoning path graph, reasoning state snapshot, process log) to ensure that all reasoning results are saved, providing a data foundation for resuming reasoning from breakpoints and backtracking history.

[0634] The complete function of step S60 can be summarized as follows: dual-condition monitoring (goal achievement + resource limit) → condition judgment (goal achievement priority) → successful termination output of complete result / timeout termination output of optimal path and unfinished goals → state persistence supports breakpoint resume → define the closed-loop path of S30-S40-S50 and its logical relationship controlled by S60 from the architectural level.

[0635] Thus, step S60 completes the termination control and result output management of the entire closed-loop iterative inference process, making the method flow of the present invention form a complete, controllable, and traceable end-to-end inference link from "task input" to "result output".

[0636] This invention provides a method and system for enhancing reasoning in large language models. By constructing a closed-loop iterative architecture of "generation-verification-feedback-correction", combined with an abstract world model with explicit state representation and path backtracking capabilities, a feedback generation module that can transform technical error information of validators into structured correction instructions, and a pluggable architecture that supports access of multiple types of validators through a unified interface protocol, it achieves external objective verification and precise targeted correction of the reasoning process of large language models, significantly improving the reliability, accuracy and cross-domain scalability of reasoning.

[0637] Regarding the state representation of the Explicit Abstract World Model (AWM), AlphaGeometry relies solely on an implicit geometric rule base, COPRA maintains the inference state through context splicing, and DeepSeek-Prover records the search state in the form of MCTS nodes. None of these three establish an explicit state representation system independent of the inference engine. This invention, through a three-layer architecture of the AWM's knowledge rule submodule (triple knowledge storage), inference state submodule (P_proved / P_pending / C_context structured definition), and inference path graph submodule (directed acyclic graph recording all inference paths), achieves for the first time the decoupling and independent maintenance of the inference state and the inference engine.

[0638] Regarding structured feedback generation, AlphaGeometry only returns binary success / failure signals to the language model, COPRA directly transmits the raw error logs of the Coq validator back to the large language model, and DeepSeek-Prover uses MCTS node score updates as feedback. All three lack systematic classification, precise localization, and suggestions for corrective actions regarding validation failure information. This invention performs error classification (four categories: logic layer, target layer, constraint layer, and formal layer) through the Feedback Generation Module (FGM), precisely locates erroneous steps and expression fragments by combining the inference path graph, and retrieves alternative rules through rule matching in the knowledge rule base. This transforms technical error information into structured corrective instructions that the large language model can directly understand.

[0639] In terms of formal transformation verification, COPRA, DeepSeek-Prover, and AlphaGeometry all lack a validity verification step independent of the formal statement generation step. This invention incorporates an independent transformation verification sub-step within the Task Parsing and Formal Transformation Module (TPFM). After converting the natural language task into a formal statement, it calls the parser corresponding to the target domain to perform syntactic correctness and type correctness checks. Only after successful verification does it enter the inference loop, fundamentally guaranteeing the correctness of the initial formal representation.

[0640] Regarding support for pluggable multi-type validators, AlphaGeometry only integrates a fixed geometric symbol engine, COPRA is only for Coq provers, and DeepSeek-Prover only supports Lean 4 theorem provers; none of these can be extended to other verification tools or task types. This invention, through a unified verifier interface protocol, supports four types of validators—mathematical formal validators (Lean 4 / Coq), program execution validators (sandbox + test cases), scientific consistency validators (physical laws + simulators), and engineering rule engines—to access via a unified interface. The system can flexibly select and switch between these validators according to the task type.

[0641] Regarding path backtracking mechanisms, neither AlphaGeometry nor COPRA possesses path backtracking capabilities—the former lacks an effective backtracking mechanism after inference failure, and the latter cannot trace the source of errors after error correction; while DeepSeek-Prover has node-level backtracking within the MCTS framework, its backtracking mechanism is embedded within the search strategy, lacking auditable backtracking records independent of the search algorithm. This invention, through a directed acyclic graph inference path graph, marks failed nodes and records the reasons for failure, accurately backtracking along the graph to the nearest valid node and opening new branches. The information on failed nodes is simultaneously injected as tabu information into the subsequent generation process of the large language model, achieving auditable and reusable path backtracking.

[0642] Regarding cross-domain versatility, AlphaGeometry is only applicable to Euclidean geometry proofs, COPRA only covers mathematical proofs and code generation scenarios, and DeepSeek-Prover is only for Lean 4 mathematical theorem proofs. This invention, through a unified task type classification system (M-type mathematical proofs / P-type program verification / S-type scientific inference / E-type engineering decision-making), combined with a pluggable verifier architecture and a configurable domain ontology mechanism, natively supports four different types of reasoning tasks, possessing cross-domain general extensibility.

[0643] In one embodiment, an automated task inference and verification system based on a large language model, the system adopting a layered architecture, includes:

[0644] The user interface layer is configured to provide multiple access interfaces for receiving natural language tasks input by users and returning inference results to users;

[0645] The inference computing layer, coupled to the user interface layer, includes a large language model inference engine and an abstract world model storage management module;

[0646] The large language model inference engine is deployed on an accelerated computing cluster and is used to iteratively generate candidate inference steps based on the current inference state.

[0647] The abstract world model storage management module is used to maintain the state space of the reasoning process. The state space includes at least a reasoning path graph, a knowledge rule base, and the current reasoning state.

[0648] The validator scheduling layer, coupled to the inference computation layer, is configured to route the candidate inference steps to the corresponding validator nodes according to the task type, and manage the verification task queue, timeout control, and verification result aggregation, and return verification results in a unified format to the inference computation layer.

[0649] The validator cluster layer, coupled to the validator scheduling layer, includes various types of validator nodes. Each validator node is used to perform a corresponding type of correctness verification on the candidate inference steps and return the verification result. The validator cluster layer supports horizontal scaling to cope with concurrent verification requests.

[0650] In addition, a storage layer, coupled to the inference computation layer and the validator cluster layer, uses multiple database types to persistently store different categories of data. The data includes at least the inference path graph, the knowledge rule base, the inference process log, and the verification result cache. The storage layer supports system breakpoint resume and historical inference backtracking query.

[0651] The user interface layer, the inference computation layer, the validator scheduling layer, the validator cluster layer, and the storage layer are sequentially coupled to form a five-layer architecture. The candidate inference steps generated by the large language model inference engine are routed to the validator cluster layer for verification via the validator scheduling layer. The verification results are returned to the inference computation layer via the validator scheduling layer. The inference computation layer updates the state space based on the verification results and triggers the next round of inference until the termination condition is met, at which point the final inference result is output through the user interface layer.

[0652] In one embodiment, a large language model reasoning enhancement device is provided, which includes a processor and a memory, wherein the processor executes the aforementioned program modules stored in the memory to implement the corresponding functions.

[0653] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and adjusting kernel parameters can implement methods to enhance inference for large language models.

[0654] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0655] This application provides a storage medium on which a program is stored, which, when executed by a processor, implements the above-described large language model inference enhancement method.

[0656] This application provides a processor for running a program, wherein the program executes the above-described large language model inference enhancement method during runtime.

[0657] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor A01, a network interface A02, memory (not shown), and a database (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02, and a database (not shown). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A04. The database is used to store data. The network interface A02 is used for communication with external terminals via a network connection. When executed by the processor A01, the computer program B02 implements a large language model reasoning enhancement method.

[0658] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0659] This application provides a computer (electronic) device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of any of the above-mentioned large language model reasoning enhancement methods.

[0660] This application also provides a computer program product that, when executed on a data processing device, is suitable for executing a program that initializes a method for enhancing reasoning with a large language model.

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

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

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

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

[0665] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0666] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0667] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0668] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0669] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for enhancing reasoning in a large language model, characterized in that, The method includes: Step S10: Obtain the natural language task input by the user, convert the natural language task into a formal task representation under a preset formal specification, and initialize the state space of the current inference process based on the formal task representation; Step S20: In the inference process, maintain the state information in the state space, the state information including at least the current inference node, the set of achieved sub-goals and the set of unachieved sub-goals; Step S30: Based on the large language model, and according to the current state information, iteratively generate a sequence of candidate actions to advance the reasoning process; Step S40: Perform multiple verifications on the candidate action sequence, wherein the multiple verifications include at least syntactic correctness verification and semantic logic consistency verification; If the candidate action sequence passes the multiple verifications, the state information is updated according to the candidate action sequence, and the process returns to step S30 to continue iterating. If the candidate action sequence fails the multiple verifications, a corresponding failure category label and error context information are generated, and the process proceeds to step S50. Step S50: Based on the failure category label and the error context information, generate a structured correction instruction according to a preset feedback strategy, and feed the structured correction instruction into the large language model generation process in step S30 to instruct subsequent iterations to avoid the error types that have occurred and adjust the generation direction of candidate action sequences. Step S60: Monitor the iteration rounds of the inference process. When the iteration rounds reach a preset upper limit threshold or the state space determines that the target state corresponding to the natural language task has been achieved, terminate the iteration and output the final inference result. In this process, the candidate action sequence generated in step S30 is verified in step S40, and the verification result is converted into a correction instruction in step S50 and fed back to step S30 as the input basis for subsequent iterations in step S30. Steps S30, S40 and S50 constitute a loop path for information transmission, and the repeated execution of the loop path is controlled by the termination condition of step S60.

2. The large language model reasoning enhancement method according to claim 1, characterized in that, The step of maintaining the state information within the state space includes: Step S201: Maintain a knowledge rule base, which stores axioms, lemmas, reasoning rules, and constraints of the domain to which the current reasoning task belongs; Step S202: Maintain the reasoning state of the current reasoning process. The reasoning state includes at least the set of verified propositions, the set of target propositions to be verified, and the current reasoning context information. The current reasoning context information includes at least the set of used reasoning rules, the identifiers of excluded reasoning paths, and the current iteration round. Step S203: In response to each candidate action sequence being verified and the state update being completed, a state transition operation is performed to transfer the inference state from the current state to the next state; Step S204: Maintain the reasoning path graph, which records all the reasoning paths explored in the reasoning process in a directed acyclic graph structure; Step S205: When any candidate action sequence fails verification, a backtracking operation is performed to revert the current inference process to the previously verified inference state and guide the generation direction of subsequent candidate action sequences to avoid the failed path in order to reduce repeated invalid attempts.

3. The large language model reasoning enhancement method according to claim 2, characterized in that, The step of performing a backtracking operation when any candidate action sequence fails verification includes: Step S2051: Mark the corresponding node in the current inference path as a failed node and record the reason for the failure; Step S2052: Backtrack along the inference path graph to the most recently verified node and take that node as a valid node; Step S2053: Open a new inference branch at the effective node to guide the generation of subsequent candidate action sequences to explore along the new branch; Step S2054: The identification information and failure reason of the failed node are stored as taboo information in the inference path graph, which is used to suppress the generation of candidate action sequences associated with the failed node by the large language model in subsequent iterations.

4. The large language model reasoning enhancement method according to claim 2, characterized in that, The state transition operation specifically includes the following steps in response to each candidate action sequence being verified and the state being updated: The formal conclusion corresponding to the current candidate action sequence is moved from the set of target propositions to be verified to the set of verified propositions. Based on the reasoning rules applied to the current candidate action sequence, update the set of target propositions to be verified, remove sub-targets that have been covered by the current verification results, and add newly generated sub-targets; Update the current inference context information, and at least record the inference rules used in the current step and the number of iterations consumed in this iteration.

5. The large language model reasoning enhancement method according to claim 1, characterized in that, The step of converting a natural language task into a formal task representation under a preset formal specification, and initializing the state space of the current inference process based on the formal task representation, includes: Step S101: Perform input preprocessing on the natural language task. The input preprocessing includes at least word segmentation, named entity recognition, and relation extraction to extract key objects, quantitative relationships, and logical constraints involved in the natural language task. Step S102: Based on the rule matching and classification model, the natural language task is classified into a predefined task type set, which includes at least: mathematical proof tasks, program verification tasks, scientific inference tasks, and engineering decision-making tasks. Step S103: Invoke the domain ontology corresponding to the classified task type and the predefined conversion prompt template, and convert the natural language task into a formal statement under the target domain through the large language model; Step S104: Perform a legality verification of the transformation result on the formal statement; if the verification passes, proceed to step S105; if the verification fails, trigger step S103 again to re-transform until the verification passes or the number of re-transformations reaches the preset retry limit. If the verification still fails after reaching the retry limit, return a transformation failure message to the user and request clarification. Step S105: Based on the formal statement, explicitly define the target state corresponding to the termination condition of the reasoning process, and extract the preconditions, constraints and boundary conditions from the natural language task and / or the formal statement, and write the preconditions, constraints and boundary conditions as the initial hard constraints of the state space into the state space.

6. The method for enhancing reasoning in a large language model according to claim 2, characterized in that, The step of iteratively generating a sequence of candidate actions to advance the reasoning process based on a large language model and the current state information includes: Step S301: Serialize the current status information into a structured prompt containing multiple fixed partition formats. The structured prompt includes at least a task definition partition, a known condition partition, a current target partition, an available rule partition, a historical failure path summary partition, and an output format partition. Step S302: Based on the structured prompts, call the large language model to generate k candidate inference steps with a preset bundle width; Step S303: Maintain k active inference paths, submit the current candidate inference steps of each active inference path to the verification unit for verification, and perform path management operations based on the verification results: Step S304: In response to the received structured correction instruction, the structured correction instruction is injected into the preset feedback partition of the structured prompt, the large language model is called again, a corrected candidate inference step is generated for the specified inference step, and the corrected candidate inference step is submitted to the verification unit for re-verification; wherein, the corrected candidate inference step is recorded as a new branch in the inference path graph, and the branch corresponding to the original failed inference step is retained in the inference path graph and is not covered.

7. The large language model reasoning enhancement method according to claim 6, characterized in that, The step S303, which involves performing path management operations based on the verification results, includes: Step S3031: For the candidate reasoning steps that have passed the verification, retain the corresponding path, update the formal conclusion corresponding to the candidate reasoning steps to the state space, and continue to advance the next round of reasoning for the path. Step S3032: For candidate inference steps that fail verification, record the failure information of the corresponding path to the inference path graph and trigger the feedback generation process. Step S3033: When all k active inference paths fail to be verified at the same number of inference steps, a global backtracking operation is performed: each path is backtracked to the most recently verified common fork node, and based on the failure history information recorded in the inference path graph, the large language model is guided to generate new candidate inference steps at the fork node and re-explore along the new branch. Step S3034: If the cumulative number of global backtracking operations exceeds the preset backtracking limit, it is determined that the current inference task cannot be completed within the existing inference framework, the inference process is terminated and a failure report is output.

8. The method for enhancing reasoning in a large language model according to claim 1, characterized in that, The multi-verification in step S40 is implemented using a plug-in verification architecture. The plug-in verification architecture connects to at least two different types of verifiers through a unified interface protocol. The type of verifier is selected and switched according to the task type of the current inference task.

9. The method for enhancing reasoning in a large language model according to claim 8, characterized in that, The step of generating structured correction instructions based on the failure category label and the error context information and a preset feedback strategy includes: Step S501: Based on the error type field output by the verifier, classify the errors that have occurred into the corresponding categories in the predefined error category set. The predefined error category set includes at least logic layer errors, target layer errors, constraint layer errors, and formal layer errors. Step S502: Combining the error location information output by the verifier with the current inference path graph, locate the step number that caused the error and the corresponding expression fragment; Step S503: Based on the categorized error types and the current knowledge rule base, retrieve candidate alternative rules that match the current error structure from the knowledge rule base through rule matching, and generate at least one correction direction suggestion; Step S504: Assemble the error category, the error location information, and the correction direction suggestion into structured feedback information according to a preset format. The structured feedback information includes at least the error step number, error type name, error location expression fragment, error cause description, current uncompleted target list, and correction direction suggestion list. Step S505: Monitor the iteration rounds and global backtracking counts of the current inference process. When the iteration rounds reach the preset maximum iteration round limit or the global backtracking count reaches the preset maximum backtracking count limit, execute the termination operation: Select the candidate path with the most verified steps from the inference path graph, output the inference process of the path and the list of currently incomplete targets, and mark the incomplete status.

10. A large language model reasoning enhancement device, characterized in that, include: The memory is configured to store instructions; A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the large language model reasoning enhancement method according to any one of claims 1 to 9.

Images