Method, device and medium for generating model heterogeneous structure response verification and limited repair

Abstract

This invention discloses a method, apparatus, and medium for heterogeneous structural response verification and finite repair of a generative model. The computer system initiates an initial automatic generation call based on language input, language context, and a unified structural contract, obtains the response data output by the generative model, and sequentially performs structural normalization, structural decoding, pattern consistency verification, and pattern-specific data constraints. When verification fails, a structured error containing error identifiers, locations, and reasons is generated, and a targeted repair is initiated based on the original input, invalid response, unified structural contract, and the error. The repair response re-identifies the input feature description to be re-verified, the result pattern identifier, candidate payloads, and actual heterogeneous branches, and performs a complete verification. Finite state control ensures that no repair is performed on the first successful verification, and no third automatic call is generated after repair. Data that passes the complete verification is typed to form a complete result, while data that fails enters a restricted processing path or a predefined error state to control subsequent processing paths.

Description

Technical Field

[0001] This invention relates to the fields of computer data processing and generative model response processing, and in particular to a method, apparatus, electronic device, and computer-readable storage medium for performing deterministic verification, limited repair, typified path access, and restricted processing on heterogeneous structural response data output by a generative model by a computer system. Background Technology

[0002] Generative models can generate structured responses based on natural language input. An application entry point may need to receive result payloads with different structures depending on the input language, input format, and input quality. Existing implementations typically use JSON Schema, object models, parsers, or validators to check the response structure and can also re-request the generative model after parsing or validation fails.

[0003] However, the generated model output is not necessarily consistent with the schema simply because a schema is provided in the request. The response may be completely undecipherable as a structured object, or it may have valid root objects and field types, but the resulting schema identifier may not match the actual load branches, or the combination, quantity, and directional relationships between schema-specific fields may not meet the deterministic constraints required by the application. If it is assumed that the response already contains identifiable candidate loads before structural decoding, completely unresolvable response paths cannot be accurately represented.

[0004] Submitting the original request repeatedly may generate the same structural error again, and cause the number of automatic calls to be uncertain. Data that fails complete validation may be incorrectly consumed as complete data if it shares typed, structured operations or storage paths with the complete result. Simply saving the raw text does not guarantee that the typed domain objects required by the application can be recovered.

[0005] Therefore, a computer data processing scheme is needed: connecting the unified structural contract, actual response branches, pattern-specific data constraints, machine-locatable errors, one-time targeted repair, complete verification, and subsequent path admission into a deterministic execution processing chain, and limiting the generative model call boundary of an automatic processing cycle through finite state control. Summary of the Invention I. Technical problems to be solved

[0006] This invention solves at least the following technical problems:

[0007] 1. Normalize and decode the heterogeneous structural response data output by the generated model. If decoding is not possible, do not predict the existence of candidate loads. If decoding is possible, identify the input feature description, result pattern identifier, candidate result load and actual heterogeneous branch.

[0008] 2. In the same entry point, deterministically verify the consistency between the result pattern identifier and the actual branch, and select pattern-specific data constraints based on the result pattern;

[0009] 3. Convert structural or data constraint failures into machine-locatable structured errors and incorporate these errors into a targeted repair input;

[0010] 4. Enable the repair response to re-identify and fully validate the complete top-level data, rather than simply checking a hypothetical repair postload;

[0011] 5. By controlling the initial call, one repair call, and termination status through finite state control, a third automatically generated call is prevented;

[0012] 6. Use complete verification status to control the type of complete result path and restricted processing path, preventing data that fails complete verification from entering the complete result storage;

[0013] 7. Restore the complete results that have already been generated and saved in a versioned manner, without requesting to generate the model again by reading the history. II. Technical Solution

[0014] This invention provides a method for verifying and performing limited repair of heterogeneous structural responses of generative models executed by a computer system.

[0015] The computer system acquires language input and language context, and parameterizes a predefined unified structure contract template based on the language context to obtain a unified structure contract. The unified structure contract specifies at least the input feature description structure, result pattern identifier, and multiple heterogeneous result load branches. Each heterogeneous result load branch has a branch type identifier or can be identified by load structure features. The unified structure contract is not a post-hoc rule arbitrarily assembled based on each generated output; in one implementation, its branch structure, field rules, and validation rules are predefined, and the language context is used to instantiate language code, allow enumeration, or specify contract parameters relevant to the current request.

[0016] The computer system initiates its first automatic generation call based on language input, language context, and a unified structural contract, obtaining the initial response data output by the generative model. Obtaining the response data does not equate to the presence of identifiable input feature descriptions, result pattern identifiers, or candidate result payloads. The computer system first performs structural normalization and structural decoding. Only when structural decoding is successful does it identify the input feature descriptions, result pattern identifiers, candidate result payloads, and the actual heterogeneous result payload branches determined based on the structural features of the branch type identifier or candidate result payloads from the decoded object. If structural decoding fails, a structural error is directly generated, and the response is deemed to have failed complete validation.

[0017] After successful structural decoding, the computer system performs a pattern consistency check and selects pattern-specific data constraint rules based on the resulting pattern identifier. The pattern consistency check verifies whether the resulting pattern identifier corresponds to the actual heterogeneous result load branch to which the candidate result load belongs. The pattern-specific data constraint rules check for relationships, allowed combinations, quantitative relationships, or directional relationships between predefined fields and input feature descriptions, the resulting pattern identifier, and pattern-specific fields. Preferably, data constraint rules dependent on pattern-specific fields are executed only after both structural decoding and pattern consistency checks have passed.

[0018] If any validation step fails, the computer system generates a structured error. A structured error includes at least an error identifier, error location, and error cause. The error location is the machine-locatable path from the response root object to the corresponding field or array element; if it cannot be decoded into the root object at all, the error location is the root location. A structured error does not require proof that the generated content is semantically incorrect, but rather that the structural or data constraints that the computer system can determine are not met.

[0019] The computer system uses finite state control to automatically invoke the model's state. If the initial response passes full validation, the system enters the initial validation passed state and does not initiate a repair call. In the normal automatic processing path where the initial response fails full validation, the system enters the repair allowed state, initiating a targeted repair call with four parts of repair input: language input, initial invalid response data, the unified structural contract as the target structural contract, and structured errors. A single automatic processing cycle contains at most one targeted repair call.

[0020] After obtaining the repair response data, the computer system re-executes the full verification. If the repair response structure is successfully decoded, the system re-identifies the input feature description to be verified, the result pattern identifier to be verified, the candidate result payload to be verified, and the branch of the actual heterogeneous result payload to which the payload belongs from the decoded object of the repair response. Subsequently, this data is used to perform pattern consistency verification and pattern-specific data constraints. If the repair response structure decoding fails, no input feature description, result pattern identifier, or candidate result payload to be verified is assumed to exist; the system directly determines that the repair response has failed the full verification.

[0021] Only candidate result payloads that pass full validation are allowed into the typed full result processing path and undergo type transformation to form the full result. Data that fails full validation does not enter this path. Partially restricted results formed by deterministic extraction rules or original text restricted results enter different restricted processing paths, do not enter the full result storage, and do not perform structured operations that depend on the full fields.

[0022] If the repair response fails to pass complete verification, the computer system can output a restricted degradation result that meets the objective formation conditions from the initial response data or the repair response data; in a preferred embodiment, the restricted degradation result formed in the initial stage takes priority. When neither of the obtained response data from the two stages forms a complete result or a restricted degradation result, a predefined invalid response error state is entered.

[0023] If a service exception occurs during a targeted repair call, or if the calling layer fails to return a response data object that can be delivered to the normalization and decoding chain, the initial limited degradation result will be output if a limited degradation result has already been formed in the initial stage; otherwise, a predefined service error state will be entered. If the calling layer has already returned response data, but the data is empty, cannot be decoded, or does not meet data constraints, the data will be treated as a complete verification failure and will not be disguised as a service call exception.

[0024] After a targeted repair call is initiated, the finite state enters the repair completed or terminated state. There is no control path to return to the repair allowed state. No third automatic generation call will be issued within one automatic processing cycle. III. Beneficial Effects

[0025] Compared to methods that use schema validation, retries, and type conversions independently, this invention achieves at least the following computer data processing effects:

[0026] 1. Decode the output of the generated model before identifying the actual branch, reducing the possibility of unparseable data or pattern-branch inconsistent data entering the error type processing path;

[0027] 2. Unify structural errors and pattern-specific constraint errors into machine-locatable data containing identifiers, locations, and causes, so that the second generation can target specific errors in the same response;

[0028] 3. The repair response re-identifies the input feature description to be re-verified, the result pattern identifier to be re-verified, and the candidate result payload to be re-verified, and performs a complete verification to avoid taking "already repaired" as a prejudgment of validity;

[0029] 4. Establish a definite automatic call termination boundary with finite states to avoid the automatic repair chain from extending indefinitely or uncertainly;

[0030] 5. Control the processing and storage paths of complete results and restricted results based on the verification status, and prevent data that fails the complete verification from entering the complete result storage;

[0031] 6. Deterministic local recovery of the complete versioned results is achieved without needing to request model generation again to read historical records.

[0032] The above effects are the results of structured data processing, automatic recall control, and storage recovery, and are not predicated on language learning effectiveness, user preferences, business costs, model "intelligence" or the certainty of successful repair. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the overall architecture of the present invention.

[0034] Figure 2 This is a schematic diagram of the overall process of the method of the present invention.

[0035] Figure 3 A diagram illustrating a unified contract structure.

[0036] Figure 4 A schematic diagram for layered verification and structured error generation.

[0037] Figure 5 This is a schematic diagram for targeted repair input and complete re-verification.

[0038] Figure 6 This is a schematic diagram of a finite automatic state machine.

[0039] Figure 7 This diagram illustrates the data processing path splitting between complete results and limited degradation results.

[0040] Figure 8 This is a schematic diagram illustrating versioned persistence and modelless history recovery. Detailed Implementation I. Terminology and Boundaries

[0041] 1. Language input and language context

[0042] "Language Input" refers to the text data processed in this automatic processing cycle. It can be words, phrases, sentences, or passages, and may contain information about one language, two or more languages, or an undetermined language. "Language Context" refers to computer-available parameters related to this input processing, and may include at least the learning language code, the native language code, or the descriptive language code.

[0043] "Input feature description" is data output by the generative model in the response data, used to describe the state of the input language, input morphology, and input quality. It is part of the response to be validated and is not an objective truth value generated by an independent language detector. The validation process can check the relationship between the input feature description and the result pattern and payload fields, but does not claim that its description is necessarily semantically correct based on this.

[0044] 2. Unified structure contract template and parameterized instances

[0045] The "predefined unified structure contract template" is a machine-processable template that predefines a common top-level structure, result mode identifier, input feature description structure, heterogeneous result load branches, branch type identifiers, or identifiable load structure features and verification constraints. "Parameterization" involves substituting language codes, allowed enumerations, or other request-related parameters from the language context into this template to form a unified structure contract instance for use in this automatic processing cycle.

[0046] The current embodiment is a parameterized instantiation based on a predefined template, rather than outputting a provisional invention contract based on a generated model. A unified structure contract can be represented using JSON Schema, equivalent object Schema, type descriptions, or contract data capable of expressing the same structural constraints. The number of branches and the meaning of branch business operations may vary depending on the implementation method and are not necessarily limited by the specific number in the current embodiment.

[0047] "Same unified structural contract" refers to maintaining consistency in the content and structural identifier of the target contract during the initial and repair phases of an automated processing cycle. The current embodiment achieves this consistency by reusing the same contract data and the same schema name. "Same" does not require that the two calling parameters point to the same memory object, nor does it require the use of the same underlying model session.

[0048] The following pseudo-structures are used to illustrate the common top-level relationship of a uniform structure contract, without limiting field names or data representation formats:

[0049] UnifiedContract {

[0050] contractId

[0051] inputFeatures {

[0052] languageState

[0053] inputForm

[0054] inputQuality

[0055] }

[0056] resultMode

[0057] payload {

[0058] branchKind

[0059] branchData = branchA | branchB | ... | branchN

[0060] }

[0061] }

[0062] In one embodiment, the pattern-branch correspondence can be represented as:

[0063] Result mode identifier; branch type identifier; actual heterogeneous branch determined by the branch identifier or load structure; example constraint type.

[0064] mode-A; kind-A; branch-A; mode-specific fields exist and the direction is consistent.

[0065] mode-B; kind-B; branch-B; number of candidates, field combinations

[0066] mode-C; kind-C; branch-C; combination of input quality status and clarification fields

[0067] The result mode identifier and branch type identifier are set separately in the table. The actual heterogeneous branch is determined based on the branch type identifier or the load structure characteristics that can distinguish the branch; the result mode identifier does not determine the actual branch independently. The mode consistency check is used to determine whether the result mode identifier corresponds to the determined actual branch. A, B, and C are only used to illustrate the correspondence and rule selection, and do not limit the specific business mode.

[0068] In a non-limiting language processing embodiment, the following heterogeneous result payloads can be configured:

[0069] Result pattern; representative load field; at least one deterministic constraint.

[0070] Word analysis; standardizes word entries, pronunciation, part of speech, core meaning, sense, collocation, example sentences, and word form information; the sense set must contain at least one usable sense.

[0071] Close reading of passages; processing direction, two language texts, aligned segments, tone, key expressions, and grammatical explanations; aligned segments are not empty, and the processing direction is consistent with the source language description.

[0072] Candidate terms; original text, question description, candidate terms, recommendation tags, meaning, usage, reasons, and example sentences; the number of candidate terms is within a predefined range.

[0073] Correction suggestions; original text, problem fragment, problem description, literal meaning, and correction candidates with recommendation tags; the number of correction candidates is within a predefined range, and each candidate has a unique recommendation.

[0074] Expression exploration; concept description, target expression, explanation, register, scenario, example sentences, and in-depth explanation; the number of target expressions is within a predefined range.

[0075] Clarification; Clarification of questions and suggestions; Clarification of questions that are not empty and satisfy a predefined identifiable question format.

[0076] The six modes, mode names, field names, and specific field combinations mentioned above are only used to illustrate heterogeneous loads, branch identification, and mode-specific deterministic constraints, and do not constitute a limitation on the number of result modes, load structure, or field naming. Other implementations may add, reduce, merge, or replace result modes and heterogeneous load branches as needed for verifiable structured processing.

[0077] 3. Response data, candidate payloads, and actual branches

[0078] "Initial response data" refers to the data that is automatically generated and retrieved by the computer system for the first time. Before successful structure decoding, this data may only be text, wrapper objects, stringified structures, or response objects provided by other output adaptation layers, and cannot be pre-defined as a structured document containing identifiable candidate payloads.

[0079] "Candidate result payloads" are payloads identified from the decoded object after successful structural decoding, which still require pattern consistency and pattern-specific data constraint verification. "Actual heterogeneous result payload branches" are determined based on the branch type identifier in the decoded object or the structural characteristics of the candidate result payloads, and are not based on a reverse assumption of the result pattern identifier. The result pattern identifier and branch type identifier are set separately; only after the pattern consistency verification passes is the correspondence between the result pattern identifier and the determined actual branch confirmed.

[0080] "Input Feature Description to be Re-verified," "Result Pattern Identifier to be Re-verified," and "Candidate Result Load to be Re-verified" are the three top-level data components re-identified after successful decoding of the repair response structure. The candidate result load to be re-verified also has a branch of actual heterogeneous result loads to be re-verified. All of these data need to be re-verified and cannot be replaced by the result pattern identifier or input feature description from the initial response.

[0081] 4. Complete verification

[0082] A “complete verification” consists of at least the following processes:

[0083] 1. Perform finite structure normalization on the response data;

[0084] 2. Perform structure decoding on the normalized data;

[0085] 3. After successful structure decoding and identification of result pattern identifiers, candidate result payloads, and actual heterogeneous branches, perform a pattern consistency check between the result pattern identifiers and the actual heterogeneous branches;

[0086] 4. Select and execute schema-specific data constraint rules based on the result schema identifier.

[0087] In the preferred strict order, data constraints on schema-dependent fields are only executed after both structure decoding and schema consistency checks have passed. Both the initial response and the repair response perform the aforementioned full checks. During the repair phase, various checks are performed using the re-identified input feature description to be retested, the schema identifier of the result to be retested, the candidate result payload to be retested, and the actual heterogeneous branch to be retested.

[0088] "Passing full verification" requires that structural decoding, pattern consistency, and the selected pattern-specific data constraints all pass. If structural decoding fails, there is no reliably identifiable top-level data for the three categories, and candidate payloads or result pattern identifiers are not further assumed.

[0089] 5. Structured errors

[0090] "Structured errors" are machine data generated by a computer system from failures in normalization, structure decoding, schema consistency, or schema-specific data constraints, and include at least the following:

[0091] Error identifiers: used to distinguish the types of errors;

[0092] Error location: The path pointing to a field or array element starting from the root position of the response; the root position is when it is completely undecodeable.

[0093] Error reason: Explanation of the violated structural conditions or data constraints.

[0094] Structured errors can be listed. Targeted repair uses this error data to locate the structures or fields that need to be regenerated, but there is no guarantee that the second generation will succeed.

[0095] 6. Partially restricted results, original text restricted results, and unavailable results.

[0096] A "complete result" is the result formed after candidate data has passed complete validation, entered the typed complete result processing path, and undergone type conversion. Validated responses that have not yet completed type conversion can be called "response data that has passed complete validation," but are not referred to as complete results in advance.

[0097] A "partial result" meets the following objective conditions:

[0098] 1. The original response failed the complete validation;

[0099] 2. Predefined deterministic extraction rules extract at least one non-empty digest, pattern hint, or restricted field that does not depend on the complete field from the decodeable portion of the response;

[0100] 3. At the same time, retain the original non-empty response.

[0101] Extraction rules can limit the types of fields that can be extracted, the nesting depth, or the number of fields to avoid treating any unknown object as complete data. Pattern hints only indicate the pattern values ​​that can be extracted from the response and do not prove that they are consistent with the actual branches.

[0102] "Raw text restricted result" refers to a non-empty raw response text that does not form a partially restricted result, and the computer system only retains this raw response text.

[0103] "Unavailable" means that neither a partially restricted result has been formed nor a non-empty original response text exists. Unavailable is not a restricted result.

[0104] Partially restricted results and original text restricted results are not complete documents, do not enter the complete results store, do not perform structured operations that depend on complete fields, and do not claim that their content is semantically correct.

[0105] 7. Predefined error states

[0106] "Predefined service error status" indicates that an exception occurred during the service call or the calling layer failed to obtain a response data object that can be delivered to the normalization and decoding chain, and there is no initial limited degradation result to output. This status can use the system's existing service failure classifications and exception information, without requiring the addition of new error codes, network fields, or recovery mechanisms.

[0107] The "Predefined Invalid Response Error Status" indicates that response data has been obtained and corresponding verification processing has been completed in both the initial and repair phases, but neither phase's data has formed a complete result or a limited downgraded result. Data that has been obtained but is empty or completely undecodeable belongs to the response verification problem; the existence of non-empty original text determines whether a limited result of original text can be formed.

[0108] This invention uses the predefined error states with objective triggering conditions and does not require error states to be recovered across applications upon restart.

[0109] 8. One automatic processing cycle

[0110] An "automatic processing cycle" is triggered by a single voice input, starting with the first automatically generated call and ending upon initial success, success or failure after a repair, an exception during the repair call, termination due to no response, or an error status output. This cycle does not cover the entire application lifecycle, nor does it encompass new inputs initiated by the user or subsequent requests explicitly triggered. II. System Structure

[0111] like Figure 1As shown, the computer system may include an input and contract unit, a generation service access unit, a response normalization unit, a structure decoding and verification unit, a structured error unit, a repair control unit, a result path unit, and an optional versioned persistence unit.

[0112] The input and contract unit acquires language input and language context, and generates a unified structural contract. The generation service access unit submits language input and the unified structural contract to a remote generation service, a local generation engine, or a hybrid generation engine consisting of both. The deployment location of the generation engine is not a core necessity; its output must be acquired by the computer system and formed into data that can enter the response normalization and structural decoding chain.

[0113] The response normalization unit performs only limited, predefined structural adjustments. The structure decoding and verification unit generates pass / fail statuses and structured errors. The repair control unit determines whether to allow one targeted repair based solely on this status and is not responsible for directly classifying failed data as a complete result. The result path unit implements typed admission or restricted path routing based on the complete verification status.

[0114] Verification can be performed on the client, server, or both, as long as the complete verification status can control the repair call and subsequent data processing path. Rules can be built-in as static rules, from a rule file corresponding to the contract version, or executed by a deterministic rule engine; the input and pass conditions of the rules should be objectively determined by the computer system. III. Main Processing Flow

[0115] The following combination Figure 2 Describe one implementation method. S101: Get Input

[0116] Obtain language input and language context. Language input is first processed to remove leading and trailing whitespace, without altering the meaning of the input. Empty input can be rejected by input validation before the generation model is called. S102: Parametric Unified Structure Contract

[0117] The contract instance for this cycle is created from a predefined unified structure contract template. Parameterizations can include learning language code, native language code, allowed enumerations, and output specification languages. The unified structure contract places input feature descriptions, result pattern identifiers, and heterogeneous result payload branches within a single verifiable top-level object. S103: Obtain initial response data

[0118] The initial automatic generation call is initiated based on language input, language context, and a unified structural contract. The model input consists of at least three intrinsically related parts: language text, language context, and a unified structural contract; the model output is response data that awaits deterministic verification. When this data is obtained, it is not assumed that it can be decoded, nor that its pattern matches the payload. S104: Structural Standardization

[0119] Before structural decoding, perform limited structural normalization on the response data. Optional actions include removing code fences around the structural data, unwrapping predefined outer layers, parsing stringified structures, normalizing predefined field aliases, or adding default values ​​explicitly allowed by the contract.

[0120] The following conditions must be met simultaneously when filling in the default value:

[0121] 1. The uniform structure contract explicitly allows the field to have a default value or an empty set;

[0122] 2. Adding does not change the semantics of the result pattern;

[0123] 3. Do not create missing model-specific substantive data.

[0124] For example, an empty set can be added to a display empty list that allows defaults in a contract; a substantial value cannot be generated for missing schema-specific interpretations, candidate content, or correction content. S105: Structure Decoding and Mode Consistency

[0125] The structure decoding checks the root object, field set, field type, enumeration value, and required value. If decoding is successful, it identifies the input feature description, result pattern identifier, candidate result payload, and actual heterogeneous branch, and checks whether the pattern identifier corresponds to the actual branch. If it cannot be parsed into an object at all, a root position structure error is generated, and the complete validation is directly determined to have failed. S106: Pattern-Specific Data Constraints

[0126] Select a rule based on the result pattern identifier. Rules can be checked for:

[0127] The directional correspondence between the language state and the source language field;

[0128] The relationship between the pattern identifier and the pattern-specific required fields;

[0129] Allowed combinations between input quality status and clarification fields;

[0130] The minimum or maximum number of candidates in the set;

[0131] Other pre-listed field relationships that can be definitively determined.

[0132] Schema consistency checks differ from schema-specific data constraint objects: the former compares the discriminant value with the actual branch, while the latter checks the relationship within a branch or across common fields. S107: First Success Path

[0133] Upon successful initial verification, the state machine enters the initial verification-passed state. This cycle involves only one automatic generation call, without initiating a repair process. Verified candidate result payloads enter the first data processing path, undergoing type conversion to form the complete result. S108: Determination of First Failure and Limited Results

[0134] If the initial response fails the full validation, a structured error is generated, and a deterministic extraction rule is used to determine whether a partially restricted result, a restricted original text result, or an unusable state is formed. The restricted information retained here does not change the conclusion of the full validation failure. S109: Single-stage targeted repair

[0135] In the normal automatic processing path, the state machine initiates a directed repair only once, starting from the repair-allowed state. The schematic structure of the repair input is as follows:

[0136] RepairInput {

[0137] originalInput: This week's language input

[0138] invalidResponse: First invalid response data

[0139] targetContract: This period's unified structure contract

[0140] validationErrors: [

[0141] { errorId, errorPath, errorReason}, ... ]

[0144] }

[0145] The field names are for illustrative purposes only. The relationship between the four input parts is as follows: the original input limits this task, invalid responses preserve the objects to be corrected, the target contract specifies the expected structure, and structured errors locate unmet items. The repair instruction requires regenerating the response according to the target contract, but success is not guaranteed.

[0146] If the repair call throws an existing service exception, or the calling layer does not receive a response data object that can be subsequently normalized and decoded, then a backup Provider call or a third request will not be initiated. If there is already a partially restricted result or a restricted result in the original text in the initial stage, the initial restricted result will be output; otherwise, a predefined service error state will be entered. S110: Complete verification of repair response

[0147] The repaired response data remains a new candidate response. Its top-level structure should be redistributed:

[0148] RepairResponseCandidate {

[0149] inputFeatures: Description of input features to be verified

[0150] resultMode: Identifier of the mode of the result to be re-verified

[0151] payload: The candidate result payload to be verified and its actual heterogeneous branch to be verified.

[0152] }

[0153] The computer system re-executes structural normalization and structural decoding on the repair response. Upon successful structural decoding, it re-identifies the three types of top-level data and actual branches, and performs pattern consistency and pattern-specific data constraints. The initial result pattern identifier cannot replace the pattern identifier of the result to be re-verified, nor can it only re-verify the candidate loads to be re-verified.

[0154] When the repair response is completely unparseable, a root location structured error is directly generated, and the repair response is determined to have failed the complete verification. At this time, it is not assumed that there is a description of the input feature to be verified, a pattern identifier of the result to be verified, or a candidate result payload to be verified. S111: Path repair successful

[0155] When a repair response passes full verification, the candidate result payload to be re-verified is admitted into the first data processing path and transformed into a complete result through type conversion. The occurrence of repair itself does not indicate success; this path is only triggered when full verification passes. S112: Repair failure and termination path

[0156] If the repair response structure decoding is successful but the pattern consistency or pattern-specific data constraint fails, or if the repair response structure decoding fails, the repair failure termination process will begin. If a restricted degradation result is formed in the initial stage or during the repair phase, it will be output according to the predefined selection rules; in the preferred implementation, the initial restricted result will be selected first, and if there is no initial restricted result, the repair restricted result will be selected.

[0157] If the obtained two-stage response data fails to form a complete result, a partially limited result, or a result with limited original text, the system enters a predefined invalid response error state. The state machine then enters a termination state, does not return to the repair-allowed state, and does not issue a third automatic generation call. S113: Versioning Persistence

[0158] Only complete results that have passed full validation and undergone type conversion are written to the complete results store. The persistent structure includes a format version identifier and fields required to restore the typed domain object. Partially restricted results, raw text restricted results, and error states are not written to this store as complete results. S114: Model-free history recovery

[0159] When reading the history, the persistent structure is decoded according to the format version identifier, and the typed domain objects in the closed type set are restored without re-requesting model generation. In older versions, when input quality fields are missing, they can be restored to an explicit unknown state; this compatibility handling does not reconstruct missing schema-specific substantive data. IV. Finite State Control

[0160] Figure 6 The state machine shown can be represented by the following states:

[0161] 1. Initial Invocation Status: Allows for one automatic invocation upon first attempt;

[0162] 2. Initial Verification Status: Performing a complete verification of the initial response;

[0163] 3. Initial verification passed: Output complete results, no repairs allowed;

[0164] 4. Repair allowed status: Only allow entry into normal paths that fail the initial full verification;

[0165] 5. Repair execution status: Initiate a targeted repair call;

[0166] 6. Repair Verification Status: Perform a full verification on the obtained repair response;

[0167] 7. Termination Status: Output complete result, limited result, predefined service error status, or predefined invalid response error status.

[0168] State transitions can be illustrated using the following pseudocode:

[0169] initialResponse = firstGenerate(input, contract)

[0170] initialOutcome = fullValidate(initialResponse, contract)

[0171] if initialOutcome.complete:

[0172] return typedComplete(initialOutcome)

[0173] initialLimited = deterministicLimited(initialResponse)

[0174] try:

[0175] repairResponse = targetedRepair(

[0176] input, initialResponse, contract, initialOutcome.errors)

[0177] except existingServiceFailure:

[0178] return initialLimited ?? predefinedServiceError

[0179] if repairResponse is not delivered by call layer:

[0180] return initialLimited ?? predefinedServiceError

[0181] repairOutcome = fullValidate(repairResponse, contract)

[0182] if repairOutcome.complete:

[0183] return typedComplete(repairOutcome)

[0184] repairLimited = deterministicLimited(repairResponse)

[0185] return initialLimited ?? repairLimited ??predefinedInvalidResponseError

[0186] The null value merging in the pseudocode only indicates prioritizing existing results, not that adding new results will be retried. The state machine does not return to the repair-allowed state after `targetedRepair`, and there is no third automatic generation call. V. Complete Results and Limited Results Path

[0187] like Figure 7 As shown, a complete verification status is a path admission condition.

[0188] The first data processing path receives response data that has passed full validation and converts candidate payloads into typed domain objects corresponding to the result pattern identifier within the path. These typed objects can come from a predefined set of closed types. Only after a typed object is formed is it considered a complete result. Complete results can be stored in versioned memory or depend on subsequent structured operations involving the complete fields.

[0189] The second data processing path only receives partially restricted results or raw text-restricted results. This path can perform secure text representation or limited field reading, but does not perform structured operations that depend on the complete fields, nor does it write to the complete result storage. The representation component can select different representation methods based on the complete result, partially restricted result, raw text-restricted result, or error status, but this interface mapping is not an essential technical feature of the first version of the claims of this invention. VI. Versioned persistence and compatibility recovery

[0190] like Figure 8 As shown, the persistent encoder only receives the complete result. The persistent structure carries a format version identifier. The decoder selects the corresponding decoding rule based on this identifier to recover the typed domain object.

[0191] The compatibility with explicit unknown values ​​in older versions is a specific implementation: if the input quality field is missing in the older version, the decoder restores the field to a predefined explicit unknown state so that the typed model can meet the closed enumeration requirement; this process does not infer the true quality of the user input, nor does it create pattern-specific substantive content.

[0192] The historical recovery process reads the saved structure from local or other persistent storage without re-requesting the model. Therefore, what is recovered is data that has already been fully validated and saved, rather than a newly generated answer. VII. Common Adaptation of Multiple Output Modes

[0193] The generation service can return a direct structured object, structured text, function parameter objects, or a response object with wrapper fields. The common goal of the output adaptation layer is to transform service outputs into "response data that can enter the structure normalization and structure decoding chain," rather than pre-identifying different service outputs as valid candidate structures.

[0194] Different output methods of the generated service can have candidate text, structured objects, or raw responses extracted by different adapters, and then uniformly handed over to the same complete validation, structured error correction, one-time targeted repair, and path routing chain. Each output format, interface adaptation, or provider selection is not claimed as an inventive contribution, nor is it required that the first version of the claims cover any unknown interface.

[0195] The generated model can be a remote, local, or hybrid generation engine. If data representations such as XML, Protocol Buffers, or function parameters are used, adaptation and decoding mechanisms are required to form equivalent root objects, result pattern identifiers, branch type identifiers, or identifiable load structure features, heterogeneous load branches, and machine-locatable error locations. These representations are alternative implementation methods and do not change the complete verification and finite state control relationships. VIII. Examples Example 1: First Response Passed

[0196] The computer system parameterizes the unified structural contract and obtains the initial response data. Normalization and structural decoding are successful, identifying input feature descriptions, result pattern identifiers, candidate payloads, and actual branches; pattern consistency and pattern-specific data constraints are both passed. Candidate payloads enter the first data processing path and are categorized to form a complete result. This cycle only involves the initial call. Example 2: The first response is completely unresolvable

[0197] The initial response data cannot be decoded into the root object. The system generates a root location structure error, without assuming the existence of candidate payloads or result pattern identifiers. If the original response text is not empty, a restricted result based on the original text can be generated; subsequently, a directed repair is initiated on the normal path. Example 3: Initial business data constraint failure, successful repair

[0198] The initial response structure decoding and schema consistency passed, but schema-specific data constraints revealed that field direction or quantity relationships were not satisfied. The system generated a structured error containing field paths, combining the language input, the initial invalid response, the unified structural contract, and the error list into repair input. The repair response re-provides the feature description of the input to be verified, the schema identifier of the result to be verified, and the candidate payload to be verified. After passing complete verification, a complete result is formed in the first path. Example 4: Repair response is completely unresolvable

[0199] The repair call returns non-empty text, but cannot be decoded into the root object. The system generates a root position error during the repair phase, without assuming the existence of the three types of data to be verified. If a partially restricted result or a restricted result of the original text has already been generated in the initial phase, the initial restricted result is preferred; otherwise, if the repair text is not empty, the original text restricted result is generated; if neither exists, a predefined invalid response error state is entered. There is no third automatically generated call. Example 5: Repairing Business Verification Failure

[0200] The repair response can decode and identify the three types of top-level data to be verified, but the schema-branch inconsistency or schema-specific constraints are not met. The system determines that the repair has not passed complete verification and selects either the initial or restricted result formed during the repair phase; if neither exists, it enters a predefined invalid response error state. Example 6: Repairing call exceptions or failure to obtain response objects

[0201] This resolves instances where existing system-generated services fail to respond, or where the calling layer fails to return a response data object that can be normalized and decoded. The system does not start a backup provider or initiate a third request. If a partially restricted result or a restricted original text result has already been generated in the initial stage, the restricted result is output; otherwise, a predefined service error state is entered. Example 7: Historical Restoration

[0202] The system encodes the complete results into a persistent structure containing a formatted version identifier. During reading, it decodes and restores the typed domain object based on the version. For older version records lacking input quality fields, it restores explicit unknown values ​​and does not request model generation. IX. Devices, electronic equipment, storage media and computer program products

[0203] The present invention also provides a generative model heterogeneous structure response verification and limited repair device, including an input and contract module, an initial generation module, a complete verification module, a repair control module, a result path module, and a termination and error status module.

[0204] The initial generation module is only responsible for obtaining the initial response data and does not pre-determine whether the data contains candidate payloads before decoding. The complete verification module is responsible for structure normalization, structure decoding, identification of the three types of top-level data and actual branches, pattern consistency, pattern-specific data constraints, and structured errors. The repair control module is responsible for finite state transitions, four parts of repair input, and one repair call, and does not directly consider the repair result as valid. The result path module implements typed admission or restricted path routing based on the complete verification status. The termination and error status module is responsible for handling service errors, invalid response errors, and termination without a third automatic call.

[0205] The device may further include a first data processing submodule, a second data processing submodule, a versioned persistence module, and a history recovery module. Each module may be implemented by software, a combination of software executed by a processor and memory, or an equivalent computer processing unit. The module division is used to describe functional boundaries and does not require them to be physically independent of each other.

[0206] The present invention also provides an electronic device including a processor and a memory, wherein a program stored in the memory implements the above-described method when executed by the processor. The present invention also provides a computer-readable storage medium having a program stored thereon that implements the above-described method when executed by a processor.

[0207] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method. 10. Achieving Boundaries

[0208] This invention does not limit the brand of the generated model, does not guarantee the semantic correctness of the generated content or the success of the repair, does not take the input feature description as the objective detection truth value, does not extend one automatic processing cycle to the application life cycle, does not take partially restricted results or restricted original text results as the complete results that have been persisted, and does not require the addition of a third request, a backup provider, cross-restart repair and recovery, or undocumented hardware structures.

[0209] The above embodiments are used to illustrate the technical relationships of the present invention. Without changing the overall technical chain of "heterogeneous response complete verification—machine-locatable error—first-time directional repair—complete re-verification—bounded termination—verification status control processing path," those skilled in the art can make equivalent substitutions for specific field names, data representations, or module deployment locations.

Claims

1. A method for verifying and finitely repairing the response of heterogeneous structures in a generative model, characterized in that, include: Obtain language input and corresponding context, and parameterize a unified structural contract for constraining multiple heterogeneous result load branches based on the context; Based on the language input, the context, and the unified structural contract, an initial generation call to the generative model is initiated to obtain initial response data. A complete verification is then performed on the initial response data according to the unified structural contract. This complete verification includes identifying the result pattern identifier and the actual heterogeneous result payload branch and determining whether they are consistent. If the initial response data fails the complete verification, a structured error is formed. In the normal automatic processing path, a targeted repair call is initiated based on the language input, the initial response data, the unified structural contract used in the initial generation call, and the structured error. This targeted repair call can be initiated at most once per automatic processing cycle. The complete verification is re-executed on the repair response data; Output a complete result or a limited result based on the verification result, or enter a predefined error state.

2. The method according to claim 1, characterized in that, The unified structural contract has a common top-level structure, sets the result mode identifier and branch type identifier respectively, and specifies multiple heterogeneous result load branches; The actual heterogeneous result load branch is determined based on the branch type identifier or the structural features of the candidate result load identified from the response data. The complete verification identifies and compares the result pattern identifier and the actual heterogeneous result load branch respectively.

3. The method according to claim 1, characterized in that, The complete verification process includes the following steps: when the response data has a structural representation corresponding to a predefined normalization sub-operation, select from removing code fences, unwrapping predefined outer wrappers, parsing stringified structures, or normalizing predefined field aliases to perform the corresponding structural normalization operation; perform structural decoding on the normalized data; after successful structural decoding, perform consistency verification between the result pattern identifier and the actual heterogeneous result load branch; if consistent, perform pattern-specific data constraints; the structural normalization does not recreate missing pattern-specific substantive data.

4. The method according to claim 1, characterized in that, The structured error includes an error identifier, the error location pointing from the root position of the response data to the field or array element that failed validation, and the error reason; The targeted repair call uses the language input, the initial response data as the initial invalid response, the unified structure contract used by the initial generation call, and the structured error as repair inputs; The complete verification is re-executed on the repair response data.

5. The method according to claim 1, characterized in that, Within an automatic processing cycle, the system enters a unique repair state only after the first response data fails the complete verification. Once the system leaves the unique repair state, it is not allowed to re-enter the repair state and no third automatic generation call is issued. If the targeted repair call encounters an error or fails to obtain repair response data that can be delivered to the complete verification, and if the initial response data has already formed the restricted result, then the restricted result is output; otherwise, a predefined service error state is entered. When neither the initial response data nor the repair response data forms the complete result or the limited result, a predefined invalid response error state is entered.

6. The method according to claim 1, characterized in that, The restricted result is either a partially restricted result or a restricted result of the original text; when at least one non-empty restricted field can be obtained from the response data that has not passed the complete verification according to the predefined deterministic extraction rules and the non-empty original response is retained, the partially restricted result is formed. When the partially restricted result is not formed but non-empty original response text exists, the original text restricted result is formed; When neither of the two can be formed, the response data is determined to be unusable; when both the initial response data and the repair response data form the restricted result, the restricted result formed by the initial response data is used first. The data that passes the complete verification is then converted into a complete result and enters the complete result processing path. The restricted results are processed through a different restricted processing path than the complete results. Data that fails the complete verification cannot be used as a complete result.

7. A device for verifying and finitely repairing the response of heterogeneous structures in a generative model, characterized in that, include: The input and contract module is used to obtain language input and corresponding context, and parameterize a unified structural contract for constraining multiple heterogeneous result load branches according to the context. The generation invocation module is used to initiate the first generation invocation to the generation model based on the language input, the context, and the unified structural contract, and obtain the first response data; The response verification module is used to perform a complete verification on the first response data according to the unified structural contract. The complete verification includes identifying the result pattern identifier and the actual heterogeneous result load branch and determining whether the two are consistent. The error and targeted repair module is used to generate a structured error when the initial response data fails the complete verification, and to initiate a targeted repair call in the normal automatic processing path based on the language input, the initial response data, the unified structure contract used in the initial generation call, and the structured error. The targeted repair call is initiated at most once in an automatic processing cycle, and the repaired response data is re-entered into the response verification module to re-execute the complete verification. The result control module is used to output a complete result or a limited result based on the result of the complete verification, or to enter a predefined error state.

8. An electronic device comprising a processor, a memory, and a computer program stored in the memory, characterized in that, When the computer program is executed by the processor, it implements the method of any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

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

Images