Soft-hard double-layer check and threshold cumulative upgrade-based observable improvement method for large model output

Abstract

The application relates to the field of large language model output quality governance, in particular to a large model output observable improvement method based on soft and hard double-layer verification and threshold accumulation upgrade. The method comprises the following steps: receiving structured business data of a large language model output, verifying through a deterministic domain rule engine, and performing soft access control or hard blocking treatment on the current state of a strategy state machine according to a violation rule, wherein the soft access control appends the violation item to an observation list and continues to promote the main process, and the hard blocking injects the violation item as a counterexample into the next round of reasoning prompt word triggering to re-reason; sending the observation list and the structured business data to a business backend through an asynchronous callback channel, and performing a friendly prompt in a non-error form based on observable fields on the client side. The application realizes complete observable security of a violation event through a soft and hard double-layer verification mechanism, and realizes dynamic adaptive response of a verification strategy to a model output quality trend through a threshold accumulation upgrade engine.

Description

Technical Field

[0001] This application belongs to the field of large language model output quality governance technology, specifically involving a method for improving the observability of large model output based on hardware and software dual-layer verification and threshold accumulation upgrade. Background Technology

[0002] In the automatic generation of structured business scenarios such as travel itineraries using large language models, the generated structured data generally suffers from the following two implicit defects due to the probabilistic nature of the reasoning process and the inherent misalignment between training data and the target domain: (1) The semantics seem reasonable, but the execution violates the business rules (such as the user marking the round trip but the model outputs the one-way trip, the cities declared by the user are glossed over, and the self-driving nodes not authorized by the user appear in the trip). (2) There are factual illusions at the data level (such as multiple different attractions within the itinerary sharing the same latitude and longitude, and the starting city information being missing on the first day). Through searching, the following are some representative existing technical solutions that have been publicly disclosed: (1) Existing technology 1: General large model output guardrail framework (open source solutions such as NeMo Guardrails and Guardrails AI) This type of solution embeds common validation mechanisms such as regular expressions, JSON Schema validation, and keyword blacklists / whitelists between the input and output layers of a large model. Its main technical features are: defining validation rules as declarative configurations (YAML / RAIL XML), intercepting the output of the large model at runtime, and performing hard blocking or automatic correction on violations.

[0003] Compared to the technical problem to be solved by this invention, this solution has the following technical defects: ① The verification mechanism is a general framework that is not domain-specific and does not involve specific semantic rules of tourism itinerary business (such as the final destination city constraint of the last transportation node of the round trip, the authorization detection of Chinese and English bilingual keywords of self-driving nodes, and the version-specific uniqueness constraint of the latitude and longitude of attractions, etc.). ② The verification strategy is a static binary structure (block / pass), which does not have the ability to dynamically switch the strategy level based on the cumulative frequency of violations, and cannot identify the drift trend of model output quality over time; ③ Lack of a complete observation signal feedback chain – lack of operational capabilities such as statistics, visualization, and manual intervention for downgrading violations.

[0004] (2) Existing technology 2: arxiv 2510.24719 "Iti-Validator: Towards Reliable Itinerary Generation" (published in September 2025) This solution is the first publicly disclosed domain-specific deterministic validation work for the tourism itinerary field. Its core technical approach is to abandon the self-correction approach of large language models and instead build a rule-based deterministic engine to perform **hard correction** on the model output -- automatically rewriting or rejecting the output if there is a violation.

[0005] Compared to the technical problem to be solved by this invention, this solution has the following technical defects: ① Using a hard correction path: A single violation triggers automatic rewriting or rejection, which loses the engineering value of the verification event itself as an observable signal - the violation event is silently absorbed, and the business backend and operation layer cannot perform observable work such as long-term statistics, trend analysis, and version degradation identification based on the verification event; ② The verification strategy is static hard blocking, lacking a dynamic adaptation mechanism of "observe first and then upgrade" - for occasional low-frequency violations that do not reach the systemic degradation threshold, hard blocking will damage the user experience (frequent "regenerate" prompts); for high-frequency violations that have reached the systemic degradation threshold, it cannot automatically upgrade to a stricter interception level. ③ It does not distinguish between the two levels of handling "soft response" and "hard response" of verification events, nor does it have an automatic conversion mechanism between the two based on cumulative statistics; ④ It lacks a manual downgrade interface (that is, manually reverting rules that have been upgraded to hard blocking to soft access control), and operators cannot intervene in the policy state machine.

[0006] (3) Other relevant public plans The binary design pattern of "log alerts vs. forced assertions" in traditional software engineering and the conventional design of "threshold-triggered alerts" in monitoring systems are not existing technologies in the technical problem area described in this invention. The above design patterns serve system-level fault detection, do not involve domain-specific verification of structured business data output by large language models, and do not have the core mechanism of "automatic state switching between soft access control and hard blocking dual-layer strategies based on cumulative frequency".

[0007] 1.3 Technical problems that urgently need to be solved in the existing technology In summary, existing publicly available technical solutions generally suffer from the following three core engineering defects in scenarios involving observable quality governance of travel itinerary data generated from large language models, and addressing a single defect cannot simultaneously address the other two: The problem of missing observation signals: under the hard correction path, the verification events are silently absorbed, and the business backend and operation layer cannot perform long-term statistics, trend analysis and version degradation identification based on the verification events -- and the capability drift of model versions is precisely the most important observability problem in large model applications; The problem of rigid static strategies: Single-layer verification strategies apply the same level of handling to both low-frequency occasional violations and high-frequency systemic violations, making it impossible to achieve a dynamic balance between "maintaining a smooth user experience" and "long-term compliance bottom line". The problem of human intervention gap: The lack of a visual display of the strategy state machine and a manual degradation interface for operations personnel makes it difficult for the operations layer to adjust the strategy in real time based on the business situation. Summary of the Invention

[0008] To address the aforementioned technical problems, this invention proposes an improved method and system for making large model output observable based on dual-layer soft and hard verification and threshold accumulation upgrades. The core inventive concept of this invention lies in constructing a dynamic policy governance system that coordinates five parts: a deterministic domain rule engine, a policy state machine, a sliding window accumulator, a threshold upgrade determiner, and a manual downgrade intervention interface. This allows the structured business data generated by the large language model to be evaluated by the same set of rules at the exit point. However, the handling strategy for each rule is no longer a static binary structure, but rather automatically migrates between two policy levels—"soft access control" and "hard blocking"—based on the cumulative violation frequency of the rule in historical inference batches.

[0009] The key technical feature of the method described in this invention does not lie in the content of the specific verification rules (the specific rules are subordinate technical features that can be flexibly configured by those skilled in the art based on business scenarios), but rather in: (i) Design of a policy state machine that allows dynamic switching of the handling strategy for the same rule within the same time window; (ii) A dual-dimensional threshold determination algorithm based on sliding window violation rate and absolute frequency; (III) The three-way feedback chain for violations under the soft access control level (AI service writing → business backend persistence → front-end friendly prompts → operation observation panel); (iv) A feedback-based re-reasoning mechanism that uses violations at the hard blocking level as counterexamples to inject into the next round of prompts; (v) The manual downgrade intervention interface allows operators to manually roll back the strategy level based on the business situation.

[0010] The technical solution of this invention does not rely on secondary training (fine-tuning) of the large language model ontology, nor on retrieval-augmented generation (RAG) of external knowledge bases. Instead, it constructs a generalizable dynamic policy governance framework independent of specific large language models and specific business rules through the engineering reconstruction of the post-processing link of the large language model output. At the engineering implementation level, it corresponds to a multi-terminal collaborative system including Python asyncio asynchronous task scheduling, Spring Boot backend persistence, relational database observable field storage, iOS / Android client-friendly prompt display, and operation management backend visualization. However, its core innovation lies in the "dynamic policy state machine" itself, which is not strongly bound to specific technology stack implementations.

[0011] System Composition The system of this invention includes the following functional units according to the data flow direction: Large Model Output Receiving Unit: Receives structured business data F generated by the large language model (such as the FinalItinerary object containing the dailyItinerary array, the item node list, the item_detailed detailed attribute, and other structured fields). Deterministic Domain Rule Engine: Contains a set of deterministic validation rules {R_i} (i=1..K), each rule takes structured data F as input and a set of violation description strings as output, and is configurable and hot-loadable; Strategy State Machine: Maintains the current strategy state state(R_i) ∈ {SOFT,HARD} for each rule R_i, providing state query, state switching, and state persistence capabilities; Soft access control handling unit: When state(R_i) = SOFT and R_i triggers a violation, the violation item is appended to the observation list quality_issues, and the main process continues to proceed without being blocked; Hard blocking handling unit: When state(R_i) = HARD and R_i triggers a violation, the main process is blocked and the violation item is injected as a counterexample into the context of the prompt word in the next round of large language model inference, triggering re-inference; The three-way feedback link unit delivers the observation list quality_issues to the business backend persistence module through an asynchronous callback channel. The business backend writes it into the observable fields of the associated process (such as the biz_itinerary_generation_job.error_message field), and the client displays friendly prompts in a non-error form according to the observable fields. Sliding window cumulative statistics: It continuously extracts the violation events in the most recent N inference batches from the observable fields of the business backend in an asynchronous timed task according to the rule dimension, and calculates the violation rate ρ_i and the absolute violation frequency c_i according to the rule; Threshold upgrade decision maker: For each rule R_i, check whether ρ_i ≥ α or c_i ≥ β is true. If true, trigger the policy state machine to execute state(R_i): SOFT → HARD for automatic upgrade. Manual downgrade intervention interface: Exposes a rule status visualization panel (including violation frequency curve, violation rate trend chart, and current policy status logo) and manual downgrade API to the operations management backend, allowing operations personnel to manually revert rules that have been upgraded to hard blocking to soft access control.

[0012] Core Methodology and Flow The complete flow of the method described in this invention is shown in Figure 1. According to the step sequence shown in Figure 1, the method includes eight main steps from S1 to S8. Step S3 is divided into a soft access control path S4a and a hard blocking path S4b according to the rule policy state. The sub-process S7 is the background asynchronous cumulative statistics and threshold upgrade engine, which is coupled with the main process through asynchronous signal triggering. S8 is the bidirectional interaction interface between the operation backend and the policy state machine.

[0013] Step S1: Receive structured business data output by the large language model Receive structured business data F generated by a large language model according to preset prompts. In the tourism itinerary generation scenario, F is a FinalItinerary object, which includes, but is not limited to, the following fields: overall title, total number of days, itineraryHighlights, budgetAnalysis, cost_total_per_person, and a dailyItinerary array arranged in daily order; each element of the dailyItinerary array is a DailyItinerary object, containing day_number, theme, items, and precautions; each element of the items array is a ScheduleItem object, containing time_slot, activity name, location, description, item_type, and item_detailed (corresponding to Attraction, Diet, Accommodation, and Transportation subtypes according to item_type).

[0014] Step S2: The deterministic domain rule engine evaluates sequentially. Iterate through the preset rule set {R_i} (i=1..K), and perform deterministic validation on the structured business data F for each rule. The input and output contract for each rule is unified as follows: (F, user parameter P) → list of violation description strings issues(R_i); where an empty list of issues(R_i) indicates that the rule has passed the validation, and a non-empty list indicates that the rule has triggered one or more violations, and each string is a readable description of a violation (including location information and violation details).

[0015] Specific rule examples as preferred embodiments of the present invention (not limited to the scope of protection of the present invention): R1 (Round Trip Consistency Check): If the user parameter round_trip=true, then the last item in F.dailyItinerary for the last day must be of type transportation, and the item_detailed.to_location field must contain the origin city name token; in addition, the entire trip description must not contain negative phrases (such as "non-round trip", "one-way", "ending in", etc.). R2 (Non-empty validation of starting city content): The F.dailyItinerary first day's items array must contain at least one item_type ∈ {attraction, dining, manual_input} node, and its location field must contain the starting city's named token; R3 (Non-empty validation of via city content): The via_city string is split into a city set V_set according to a preset delimiter. For each city in V_set, a key token is extracted (English token length ≥ 3 characters, Chinese token length ≥ 2 characters). The concatenated text of the location field of all attraction / manual_input type nodes of F.dailyItinerary contains at least one matching token. R4 (Self-driving node authorization verification): If the set of self-driving declaration keywords {"self-drive", "self drive", "selfdrive", "self-driving", "road trip", "rentalcar", "drive ourselves", "drive myself"} is not detected in the free text of the user parameter notes, then the mode field of all transportation nodes in F.dailyItinerary must not contain driving-related keywords {"drive", "driving", "self-drive", "self drive", "driving", "self-driving", "rental car"}, but non-self-driving and passenger-related usages such as "ride" and "passenger" are allowed; R5 (Coordinate Uniqueness Check): In F.dailyItinerary, the (longitude, latitude) latitude and longitude pairs of all item_type=attraction type nodes are not allowed to be repeated with 5 decimal places of precision. If duplicates are found, a violation will be recorded and the activity names of the two nodes sharing the coordinates will be marked.

[0016] The rule set {R_i} is loaded from the configuration center during system initialization, and new rules can be hot-loaded at runtime. This invention does not limit the specific content of the rule set; the number of rules, rule types, and rule parameters can all be flexibly configured according to differences in business domains. The core innovation of this invention lies not in the content of the five specific rules mentioned above, but in the two-layer policy processing mechanism after rule evaluation (i.e., step S3 and beyond).

[0017] Step S3: Policy Status Query and Traffic Distribution For each rule R_i that triggers a violation, query the policy state machine for its current policy state state(R_i): If state(R_i) = SOFT: Proceed to step S4a (soft access control path); If state(R_i) = HARD: Proceed to step S4b (hard blocking path).

[0018] The policy state machine is a persistent key-value data structure, where the key is a unique identifier for the rule and the value is an enumeration of the current policy state. State transition events (including automatic upgrades and manual downgrades) are recorded in the policy state change log, which includes audit fields such as timestamp, trigger reason, operator (system / operations personnel), and the states before and after the change.

[0019] Step S4a: Soft access control processing (without blocking the main process) The violation descriptions in issues(R_i) are appended to the observation list quality_issues, and the main process continues with subsequent steps. At the engineering implementation level, quality_issues is an array field in the business state object state; write operations to it are performed in an append-only manner, with violation descriptions from multiple rules appended to the same list in the order they were triggered.

[0020] It should be noted that the key technical feature of this invention is that violations do not block the main process under the soft access control path—a single violation event is allowed to be "passed through" to downstream business modules, but it is also collected synchronously as an observable signal for use by the cumulative statistics unit. This design preserves the full observable value of violation events while ensuring a smooth user experience (the user does not experience complete failure due to a single violation).

[0021] Step S4b: Hard blocking handling (blocking the main process + counterexample injection-based re-reasoning) The subsequent steps of the main process are blocked. Issues(R_i) are injected as counter-examples into the context of the prompt words for the next round of reasoning in the large language model, triggering the large language model to re-infer and generate structured business data F'. Then, F' is used as input to return to step S1 and re-execute the process. The number of re-inferences is subject to a preset upper limit. If the upper limit is exceeded, it is treated as a hard error (returning a failure status upstream).

[0022] The counterexample injection-based re-inference is an original design of the hard-blocking path in this invention. Traditional hard-blocking paths only intercept or automatically correct, while this invention uses the specific description of the violation event (including location information, violation fields, and reasons for the violation) as a structured counterexample text and concatenates it into the prompt words of the next round of inference. This allows the large language model to re-infer based on the premise of knowing "where the error occurred in the previous round", which significantly improves the correction hit rate of re-inference.

[0023] Step S5: Three-way feedback loop The observation list `quality_issues` and structured business data `F` are POSTed together to the pre-registered `callbackUrl` in the business backend via an asynchronous task callback channel. Upon receiving the callback, the business backend persistence module performs the following actions: Write F as normal business data into the main business table (such as the biz_itinerary_version table). The list of quality_issues is concatenated into a single string by a preset delimiter and truncated to the maximum column width (e.g., 1900 characters), and then written to the observable field (e.g., error_message) of the business task table (e.g., biz_itinerary_generation_job). The business task table status is updated synchronously to "succeeded" (Note: Although quality_issues exist, the task status is still successful -- this is a specific manifestation of the non-blocking feature of the soft access control in the persistence layer of this invention). The latest results are asynchronously notified to the client via a push channel.

[0024] Step S6: Front-end friendly prompts When the client retrieves the latest business data from the business backend, it synchronously retrieves observable fields and presents them according to the following display rules: If the observable field is empty: the standard results will be displayed without any prompts; If the observable field is not empty: add a friendly prompt in a non-error form to the results display interface (such as "The itinerary has been generated, but we have noticed N optimization suggestions"), and provide two user action buttons: "Accept current results" and "Regenerate". The prompts should not be presented in a strong warning format such as red / error icons, so as to avoid giving users the impression that the system is malfunctioning.

[0025] Step S7: Cumulative Statistics and Threshold Upgrade Engine (Asynchronous Background) This step is a background, asynchronous sub-process for adaptive policy state upgrades, decoupled from the main process by sharing observable fields in the business database. Its complete logic includes the following sub-steps: S7-1 Sliding Window Cumulative Statistics: Continuously scan the observable field records of the most recent N inference batches (N is the window length, which can be configured as a system parameter, preferably 100~1000) in the business task table in a sliding window manner, and aggregate statistics according to the rule unique identifier: (a) Violation rate ρ_i = (number of batches that triggered R_i violation) / N; (b) Absolute violation frequency c_i = number of batches that triggered R_i violation.

[0026] S7-2 Dual-Dimensional Threshold Determination: For each rule R_i, check whether ρ_i ≥ α_i or c_i ≥ β_i is true, where α_i is the upper limit threshold for the violation rate of rule i (preferably 0.10~0.30) and β_i is the upper limit threshold for the absolute frequency of rule i (preferably 20~100). The two thresholds are combined using "OR" logic—an upgrade is triggered as soon as either condition is met, because: (a) the violation rate determination can identify long-term systemic degradation trends; (b) the absolute frequency determination can identify short-term sudden concentrated violations, and the two complement each other.

[0027] S7-3 Automatic Upgrade and State Switching: If an upgrade is triggered by S7-2, a state switching request of state(R_i): SOFT → HARD is sent to the policy state machine. The state switching event is recorded in the policy state change log and broadcast to all running main process instances via message queue, ensuring that subsequent requests to step S3 can query the updated policy state.

[0028] S7-4 Continuous Accumulation Mode: If S7-2 does not trigger an upgrade, the current strategy state remains unchanged, and the sliding window continues to advance; the window advancement step size ΔN is configurable (preferably ΔN = N / 10).

[0029] Step S8: Manual downgrade intervention interface The operations management backend provides the following capabilities to operations personnel: Rule Status Visualization Panel: Displays all rules and their current policy status (SOFT / HARD), the most recent N violation rate ρ_i, the most recent N absolute frequencies c_i, the timestamp of the most recent status change, and the reason for the most recent status change in a list format; Violation frequency curve: The evolution trend of ρ_i and c_i of each rule over time is presented in the form of a time series line graph, and the horizontal reference lines of the current state switching thresholds α_i and β_i are marked. Manual Degradation API: After confirming that a high-frequency violation of a rule has been resolved by the business side (such as fixing the model version or adjusting the business strategy), the operations personnel can manually roll back the rule's strategy status from HARD to SOFT through this interface; manual degradation events are also recorded in the strategy status change log, including audit fields such as the operator's identity and the reason for degradation; New Rule Injection API: Operations personnel can inject new rules into the rule set {R_i} through this interface without restarting the system. The initial policy state of the new rule is SOFT by default and it is automatically included in the S7 cumulative statistics monitoring scope.

[0030] Compared with the prior art, the present invention has the following beneficial effects: The technical effects to be achieved by this invention revolve around three core engineering defects: "missing observation signals," "rigid static strategies," and "artificial intervention in tomography." The technical effects corresponding to each innovation are as follows: 1. Preservation of the integrity of the observed signal This invention employs a dual-processing design under the soft access control path—ensuring that "violation events do not block the main process but are written to the observation list"—to guarantee that all information of each verification event (including rule identifier, violation location, violation details, associated business entity ID, and timestamp) is fully persisted to the business database. In internal empirical testing: The observable preservation rate of violations reaches 100% (in stark contrast to the silent absorption of violations under the traditional hard correction path). Based on the preserved sequence of violations, operators can plot rule-level violation frequency curves and identify model version degradation trends. For example, after a certain large language model supplier version upgrade, the violation rate of rule R3 (non-empty content in the cities it passes through) increased from 4% to 18% within 48 hours. This trend is completely invisible under the traditional hard correction path. The observation list, through the connection between the persistence layer and the front-end presentation layer, forms a complete observable signal chain from "violation event → business situation → operational decision".

[0031] 2. Dynamic adaptation at the strategy level This invention employs a three-stage dynamic strategy mechanism—sliding window cumulative statistics, dual-dimensional threshold determination, and automatic upgrade state switching—to achieve an adaptive response of the validation strategy to the trend of model output quality. Specific effects include: Low-frequency occasional violations (ρ) i Much lower than α i And c i Much lower than β i () is allowed to "pass through" to the downstream, maintaining a smooth user experience and significantly reducing the overall failure rate; High-frequency systemic violations (ρ) i≥α i or c i ≥β i This triggers an automatic upgrade to a hard block, ensuring long-term compliance. The automatic migration process at the strategy level is transparent to the business side—the business side does not need to be aware of the policy state change, and the system completes all decisions and switching in the background. In internal empirical testing, the automatic upgrade mechanism successfully identified three model version degradation events and completed the strategy switch within 6 hours, with an average false upgrade rate (mistakenly judging normal fluctuations as systemic degradation) of less than 2%.

[0032] 3. Improved hit rate of corrective reasoning through counterexample injection. This invention employs a design that injects the structured description of the violation as a counterexample into the next round of inference prompts under a hard-blocking path. Compared to the traditional "violation equals rejection / violation equals random retry" path, this significantly improves the correction hit rate. In internal empirical testing: Counterexample injection-based re-inference achieves a hit rate of approximately 78% in correcting violations on the first retry (i.e., approximately 78% of violations are eliminated after the second round of inference). In the same scenario, the first retry correction hit rate of traditional random retries (without injecting counterexamples) is approximately 32%; The hit rate is improved by approximately 46 percentage points, resulting in a reduction of approximately 35% to 50% in model API call costs (each successful correction avoids multiple subsequent retries).

[0033] 4. The manual degradation interface enhances the controllability of the strategy state machine. This invention introduces a manual downgrade intervention interface to compensate for the shortcomings of the fully automatic policy state machine in the following scenarios: (i) after model version rollback, high-frequency violations have been eliminated but the cumulative window has not decayed naturally; (ii) after business policy adjustments, some original violation events have been redefined as compliant by the business side; (iii) under urgent operational needs, it is necessary to quickly relax the policy level of a certain rule. Specific effects include: After confirming the business situation, operators can roll back the strategy status within seconds, which is a significant reduction compared to the time (several hours to tens of hours) of waiting for the sliding window to decay naturally. The full audit fields of manual downgrade events (operator, downgrade reason, before and after status, timestamp) ensure that the operation is traceable and meets enterprise-level compliance requirements; The new rule injection API allows operations personnel to dynamically expand the rule set without restarting the system, enabling the system to flexibly respond to new business rule requirements.

[0034] 5. Model decoupling and cross-model portability All technical features of the method described in this invention are located in the post-processing link of the large language model output. It does not rely on secondary training of the large language model ontology, nor on the internal weights or fine-tuning capabilities of a specific model, nor on a specific prompt style. When external large language models are upgraded (e.g., MiniMax-M2 is upgraded to Claude Opus 4.6, GPT-5, DeepSeek-V4, etc.), the core steps of the method of this invention can continue to be applied without any modification. The same rule engine and state machine can simultaneously manage the output of multiple different large language models, resulting in high cross-model portability. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the overall technical solution architecture according to an embodiment of this application; Figure 2 This is a partial flowchart of the overall technical solution according to the embodiments of this application; Figure 3 This is a schematic diagram of the cumulative statistics and threshold upgrade engine process in the overall technical solution according to the embodiments of this application. Detailed Implementation

[0036] Example 1: This invention presents an improved method for making large model output observable based on dual-layer software and hardware verification and threshold accumulation upgrade. The core innovations to be protected by this invention are as follows: 1. Soft and hard dual-layer policy state machine: Maintain a {SOFT, HARD} two-level (or multi-level) policy state for each verification rule. The processing level after rule evaluation is no longer a static binary structure, but is distributed according to the current policy state of each rule - this is the fundamental innovation of this invention that distinguishes it from all existing single-layer hard blocking or single-layer hard correction schemes.

[0037] 2. Dual-dimensional threshold upgrade judgment based on sliding window: The violation rate ρ_i and absolute violation frequency c_i of each rule in the most recent N inference batches are continuously accumulated and statistically analyzed in the form of sliding window. The dual-dimensional "or" logic judgment of "ρ_i ≥ α_i or c_i ≥ β_i" is adopted to ensure that both long-term systematic degradation and short-term sudden concentrated violation are recognized.

[0038] 3. Observable Preservation of Violation Events: Violation events under the soft access control path do not block the main process but are fully written into the observable fields of the business database. A closed-loop observable signal channel is formed through a four-level link: AI service → business backend persistence → front-end friendly prompts → operation observation panel, ensuring that all information of each violation event is fully preserved.

[0039] 4. Counterexample Injection-Based Re-inference: Under hard-blocking paths, violation descriptions are injected as structured counterexamples into the context of prompt words in the next round of large language model inference. This allows the large language model to re-infer based on the premise of knowing "where the error occurred in the previous round", which significantly improves the correction hit rate (78% empirically vs. 32% for traditional random retry).

[0040] 5. Manual degradation intervention interface and hot loading of new rules: Expose the strategy status visualization panel and manual degradation API to operations personnel to make up for the response lag of the fully automatic state machine in scenarios where the business situation has changed but the sliding window has not decayed naturally; at the same time, it supports the dynamic injection of new rules without restarting the system and automatic inclusion in the cumulative statistical monitoring.

[0041] 6. End-to-end audit of policy status changes: All policy status switching events (automatic upgrades and manual downgrades) are recorded in the policy status change log, including complete audit fields such as trigger reason, operator identity, before and after status, and timestamp, to ensure that the operation is traceable and meets enterprise-level compliance audit requirements.

[0042] 7. Five domain-specific deterministic rules and their specific algorithm implementations: As a preferred embodiment of the present invention in the field of tourism itineraries, the present invention includes specific algorithm implementations of five domain-specific deterministic verification rules, including R1 negative phrase full-text scanning for round-trip consistency, R2 double matching of substrings and prefixes of the starting city, R3 extraction of bilingual tokens of English characters ≥3 characters and Chinese characters ≥2 characters from cities along the route, R4 authorization detection of bilingual keyword sets for self-driving nodes, and R5 version-specific uniqueness constraints with latitude and longitude precision to 5 decimal places, etc.

[0043] The complete process of the method described in this invention is shown in Figures 1-3. The core of the large model output observability improvement method based on dual-layer soft and hard verification and threshold accumulation upgrade described in this invention lies in constructing a dynamic policy governance system that collaboratively operates five parts: a deterministic domain rule engine, a policy state machine, a sliding window accumulator, a threshold upgrade determiner, and a manual downgrade intervention interface. This system enables the structured business data generated by the large language model to undergo verification by a unified set of rules at the output port. The handling strategy for each rule no longer adopts a static binary structure, but rather dynamically migrates between soft access control and hard blocking policy levels based on the cumulative violation frequency of the rule in historical inference batches.

[0044] Step S1 is the stage of receiving structured business data output by the large language model. The large model output receiving unit is responsible for capturing the complete structured business data F generated by the large language model according to the preset prompt word template. In the specific business scenario of travel itinerary generation, F is represented by a FinalItinerary object. The complete data structure of this object includes the following hierarchical fields: The top-level fields cover the overall title, total days, itineraryHighlights, budgetAnalysis, and cost_total_per_person; The core data field is a dailyItinerary array arranged in daily order. Each element in this array is defined as a DailyItinerary object. Each daily itinerary object includes the day number, theme, items, and precautions; Each element in the items array is a ScheduleItem object. Each schedule item object includes the time slot, activity name, location, description, item type, and item_detailed. The item_detailed field corresponds to four sub-types according to the item_type: Attraction, Diet, Accommodation, and Transportation. A complete data structure definition ensures that the subsequent rule validation phase can accurately locate structured fields at any level, thereby performing precise domain rule evaluation.

[0045] Step S2 is the sequential evaluation phase of the deterministic domain rule engine. The deterministic domain rule engine contains a pre-configured set of domain-specific validation rules {R_i} (i=1...K), where K is the total number of rules. During system initialization, the rule engine completes the initial loading of the rule set from the configuration center, supporting runtime hot loading of new rules or hot updating of existing rule logic. Each rule follows a unified input-output contract: structured business data F and user parameters P are used as input, and a list of violation description strings, issues(R_i), is used as output. When issues(R_i) returns an empty list, it indicates that the rule has passed validation on the current data F; when issues(R_i) returns a non-empty list, it indicates that the rule has triggered one or more violations, and each string element in the list is a readable descriptive text containing location information and violation details.

[0046] As a preferred embodiment of the present invention in the field of tourism itineraries, the specific rule set includes the following five exemplary rules, but the scope of protection of the present invention is not limited thereto.

[0047] R1 rule is a round-trip consistency check. Its check logic is as follows: if the user parameter round_trip is marked as true, then the last item of F.dailyItinerary must be a transportation type node, and the item_detailed.to_location field of this node must contain the named token of the origin city. At the same time, the entire trip description must not contain any phrases from the set of negative phrases {"non-round trip", "one-way", "ending in", etc.}.

[0048] The R2 rule is a non-empty check for the starting city content. The check logic is as follows: the items array of the first day of F.dailyItinerary must contain at least one node whose item_type belongs to the {attraction, dining, manual_input} set, and the location field of that node must contain the starting city name token.

[0049] The R3 rule is a non-empty validation for the city content. Its validation logic is as follows: First, the user-declared string via_city is divided into a city set V_set according to a preset delimiter. Then, a key token is extracted from each city in V_set (English tokens must be at least 3 characters long, and Chinese tokens must be at least 2 characters long). Then, it checks whether the concatenated text of the location field of all attraction and manual_input nodes in F.dailyItinerary contains at least one matching token.

[0050] Rule R4 is for authorizing self-driving nodes. Its verification logic is as follows: If no keywords from the self-driving declaration keyword set {"self-drive", "self drive", "selfdrive", "self-driving", "road trip", "rental car", "drive ourselves", "drive myself"} are detected in the user parameter notes free text, then the mode field of all transportation type nodes in F.dailyItinerary must not contain any keywords from the driving keyword set {"drive", "driving", "self-drive", "self drive", "driving", "self-driving", "rental car"}, but the use of non-self-driving passenger keywords such as ride and passenger is allowed.

[0051] The R5 rule is for coordinate uniqueness verification. Its verification logic is as follows: In F.dailyItinerary, all item_type nodes of the attraction class are not allowed to have duplicate longitude and latitude pairs with 5 decimal places of precision. If duplicate longitude and latitude pairs are detected, the violation is recorded and the activity names of the two nodes that share the coordinates are marked.

[0052] The specific content, number of rules, types of rules, and parameters of the rule set {R_i} can be flexibly configured according to differences in business domains. This invention does not limit the specific content of the rule set. The core technical innovation of step S2 is not the content of the specific rules themselves, but the two-layer strategy handling mechanism after the rule evaluation is completed, namely the dynamic strategy governance system constructed in step S3 and subsequent steps.

[0053] Step S3 is the policy state query and routing stage. The policy state machine maintains the current policy state state(R_i) for each rule R_i, which belongs to a value in the policy state enumeration set {SOFT, HARD}. The policy state machine is implemented using a persistent key-value data structure, where the key is the rule's unique identifier (string type) and the value is the current policy state enumeration value. When rule R_i triggers a violation in step S2, the main process sends a state query request to the policy state machine, which returns the current policy state of the rule based on the rule's unique identifier. Based on the returned policy state value, the main process executes the following routing logic: if state(R_i) equals SOFT, it enters the soft access control processing path described in step S4a; if state(R_i) equals HARD, it enters the hard blocking processing path described in step S4b. All state transition events (including automatically triggered upgrade events and manually triggered downgrade events by operations personnel) are synchronously recorded in the policy state change log. This log includes complete audit fields such as timestamp, trigger reason, operator identifier (system or operations personnel account ID), state before switch, and state after switch, ensuring the traceability of policy state change operations. After the policy state switch is completed, the state transition event is pushed to all running main process instances through the message queue broadcast channel, ensuring that subsequent requests reaching step S3 can immediately query the updated policy state.

[0054] Step S4a is the soft access control handling stage, corresponding to the handling path when state(R_i) equals SOFT. When rule R_i triggers a violation in step S2 and the current policy state of the rule is SOFT, the main process sequentially appends all violation description strings in issues(R_i) to the observation list quality_issues. At the engineering implementation level, the observation list quality_issues is an array field in the business state object state. When performing the write operation, an append mode is used, and the violation descriptions of multiple rules are appended to the same list in the order of triggering. After the write operation is completed, the main process continues to proceed with subsequent steps without being blocked by the current violation event.

[0055] One of the key technical features of this invention is that violations under the soft access control path do not block the main process. The technical principle of this design is that a single violation event is allowed to be passed through to downstream business modules for continued processing, and the user's itinerary generation request will not suffer a complete failure or be forced to regenerate due to a single rule violation. Simultaneously, the violation event is collected as an observable signal and written into the observation list for use by the cumulative statistics unit described in step S7. This dual-processing design, while ensuring a smooth user experience, fully preserves the observable value of all violation events, providing a solid data foundation for subsequent rule-level violation frequency statistics, model version degradation trend identification, and operational decision analysis.

[0056] Step S4b is the hard blocking handling stage, which corresponds to the handling path when state(R_i) equals HARD. When rule R_i triggers a violation in step S2 and the current policy state of the rule is HARD, the main process blocks the execution of subsequent steps and injects the violation description in issues(R_i) as a structured counterexample into the prompt context of the next round of reasoning in the large language model. The specific implementation of counterexample injection is as follows: the specific description of the violation event (including the violation rule identifier, the path of the violation location field, the current value of the violation field, and the reason for the violation judgment) is organized into a structured text fragment and concatenated to the end of the system prompt or user prompt of the next round of reasoning, so that the large language model can perform re-reasoning based on the specific error location and error reason of the previous round. The large language model regenerates structured business data F' based on the injected counterexample context, and the main process returns to step S1 with F' as input to re-execute the complete verification process. The number of retry attempts is limited by a preset upper limit (system parameter max_retry_count, typically ranging from 2 to 5 times). When the upper limit is reached but the violation is not eliminated, the system treats it as a hard error, returns a failure status and error code to the upstream system.

[0057] The technical principle of the counterexample-injected re-inference mechanism lies in feeding back the complete contextual information of the violation event to the inference stage, guiding the attention of the large language model to focus on the specific field and judgment condition that erred in the previous round, thereby significantly improving the correction hit rate of re-inference. Compared to the approximately 32% first-retry correction hit rate of traditional random retries (without injecting counterexample information), the first-retry correction hit rate of counterexample-injected re-inference can reach approximately 78%, corresponding to a reduction of approximately 35% to 50% in model API call costs.

[0058] Step S5 is the three-way feedback link phase. After the processing in step S4a or S4b is completed, the main process sends the observation list `quality_issues` and the structured business data `F` (or `F'`) together as an HTTP POST request to the pre-registered `callbackUrl` of the business backend via the asynchronous task callback channel. Upon receiving the callback request, the business backend persistence module performs the following processing operations: First, write F as normal business data into the main business table (such as the biz_itinerary_version table), which stores the complete version history of the trip data; Secondly, the quality_issues list is concatenated into a single string using a preset separator (such as newline character \n). If the length of the concatenated string exceeds the column width limit (such as 1900 characters), the string is truncated and then written to the observable fields (such as the error_message column) of the business task table (such as biz_itinerary_generation_job). Secondly, the status field of the business task table is updated to "succeeded" (it should be noted that although there are violations in quality_issues, the status of the business task table is still marked as successful. This is a specific manifestation of the non-blocking feature of the soft access control in the data persistence layer. The existence of violations does not affect the success status of the business task). Finally, the client is notified of new results to be retrieved via an asynchronous push channel (such as WebSocket push, message queue notification, etc.).

[0059] The three-way feedback loop design constructs a complete four-level data flow channel, from AI service writing to business backend persistence, to user-friendly frontend prompts, and finally to the operation monitoring panel. Each level of the channel undertakes specific data processing and display responsibilities: the AI ​​service is responsible for generating and labeling violation data; the business backend is responsible for persistent storage and related queries; the frontend is responsible for a user-friendly and intuitive display; and the operation management backend is responsible for visual statistics and operational intervention. The integrity of this loop ensures the lossless transmission of violation event information across multiple systems and levels.

[0060] Step S6 is the front-end friendly prompt stage. After receiving the push notification triggered in step S5, the client application retrieves the latest business data and its observable fields from the business backend. The client renders the interface according to the following display rules: if the retrieved observable field is null or an empty string, the normal result display process is executed, and no additional prompt information is displayed; if the retrieved observable field has a non-null value, a friendly prompt text in a non-error format is added to a preset position on the result display interface (such as the bottom of the trip card or the sidebar). The typical text format is "The trip has been generated, but we have noticed N suggestions for optimization," where N is the number of violations in the quality_issues list. Below the friendly prompt area, two parallel operation buttons are provided for the user to choose from: the "Accept Current Result" button allows the user to confirm that there is a minor violation in the trip data that does not affect the basic functions; the "Regenerate" button allows the user to initiate a new round of trip generation requests. It should be specifically stipulated that the visual presentation style of the prompt text should not use strong warning forms such as red text or error icons to avoid giving users the wrong perception of system failure. It is preferable to use gray or blue text combined with information icons and other mild visual elements.

[0061] Step S7 is the cumulative statistics and threshold upgrade engine stage. This stage runs asynchronously in the background and is decoupled from the main process through observable fields in the shared business database. The complete logic of the cumulative statistics and threshold upgrade engine includes the following four sub-steps.

[0062] The S7-1 sub-step is the sliding window cumulative statistics. The sliding window cumulative statistics generator continuously extracts violation event records from the observable fields of the business task table in the backend of the business, according to the rule dimension, using an asynchronous timed task (the timer period is configurable, preferably executed every 10 minutes). Here, N is the sliding window length, a configurable system parameter, preferably ranging from 100 to 1000. The sliding window advances forward using inference batches as the basic unit, and the window advancement step size ΔN is configurable, preferably ΔN equal to N divided by 10, meaning the window advances N / 10 batches every 10 minutes. The extracted violation event records are aggregated and statistically analyzed according to the rule's unique identifier, calculating the following two statistical indicators: the violation rate ρ_i equals the number of batches that triggered rule R_i violations in the most recent N inference batches divided by N; the absolute violation frequency c_i equals the number of batches that triggered rule R_i violations in the most recent N inference batches (this indicator has the same numerator as the violation rate, but a different dimension of expression).

[0063] Sub-step S7-2 involves a two-dimensional threshold determination. For each rule R_i, the system presets a violation rate threshold α_i (preferably ranging from 0.10 to 0.30) and an absolute frequency threshold β_i (preferably ranging from 20 to 100). The threshold determination logic uses an "OR" combination: If either ρ_i ≥ α_i or c_i ≥ β_i is true, then the violation index of the rule is determined to have reached the level requiring a policy upgrade. The reason for using a two-dimensional "OR" logic combination is that the violation rate judgment dimension focuses on identifying long-term systemic degradation trends (even if the absolute frequency is not high, the proportion is consistently high), while the absolute frequency judgment dimension focuses on identifying short-term sudden concentrated violations (even if the violation rate is not high, it breaks out in a concentrated manner within a short period of time). The two dimensions complement each other and together constitute a comprehensive ability to identify abnormal patterns.

[0064] Sub-step S7-3 involves automatic upgrade and state switching. If the threshold determination result of sub-step S7-2 triggers the upgrade condition, the cumulative statistics and threshold upgrade engine initiates a state switching request to the policy state machine, requesting that state(R_i) be changed from SOFT to HARD. Upon receiving the request, the policy state machine executes the state switching operation and synchronously writes the state switching event to the policy state change log. The log includes a description of the triggering reason (e.g., "auto-upgraded due to violationrate 0.19 > threshold 0.15 over recent 500 batches"), the state before the switch (SOFT), the state after the switch (HARD), and audit fields such as a timestamp. After the state switching is completed, the policy state machine pushes the state switching notification to all running main process instances through a message queue broadcast channel, ensuring that subsequent requests arriving at step S3 can immediately query that the policy state has been updated to HARD.

[0065] Sub-step S7-4 operates in continuous accumulation mode. If the threshold determination result of sub-step S7-2 does not trigger the upgrade condition, the cumulative statistics and threshold upgrade engine maintain the current policy state of the rule, and the sliding window continues to advance according to the preset step size ΔN. As the sliding window advances, the violation records of historical batches gradually move out of the window range, and the violation rate statistics will naturally decay over time until the next threshold determination time when the upgrade condition is reassessed.

[0066] Step S8 is the manual downgrade intervention interface stage. The operations management backend provides operations personnel with complete policy status visualization and intervention capabilities, specifically including the following four functional modules.

[0067] The first functional module is the rule status visualization panel. This panel displays basic information about all rules in the system in a tabular list format, including: rule unique identifier, rule name, rule description, current policy status (presented as a SOFT or HARD logo), violation rate ρ_i of the most recent N inference batches, absolute violation frequency c_i of the most recent N inference batches, timestamp of the most recent status transition, and a summary of the reason for the most recent status transition. Operations personnel can quickly understand the operational status and historical changes of each rule through this panel.

[0068] The second functional module is the violation frequency graph. This visualization component presents the violation rate ρ of each rule in the form of a time-series line graph. i and absolute frequency of violations c i The trend curve evolves over time. The horizontal axis of the line chart represents time, the left side of the vertical axis represents the range of violation rate values ​​(0 to 1), and the right side represents the range of absolute frequency values. Two additional horizontal reference lines are overlaid in the chart, corresponding to the current violation rate threshold α. i and absolute frequency threshold β i The location of the curve allows operators to intuitively judge the distance between the current statistical indicator and the threshold. When the curve breaks through the threshold reference line upwards, it indicates that the policy status of the rule is about to be or has already been automatically upgraded.

[0069] The third functional module is the manual downgrade API. This API allows operations personnel to manually roll back the policy status of a rule from HARD to SOFT after confirming that a high-frequency violation of a rule has been addressed by the business side (e.g., the large language model vendor has released a patch, the business strategy has been adjusted, etc.). When calling the API, a downgrade reason field must be submitted, in which operations personnel must explain the business basis for the downgrade decision. Manual downgrade events are also fully recorded in the policy status change log, which includes the operator's account identifier, the downgrade reason text, the state before downgrade (HARD), the state after downgrade (SOFT), and the operation timestamp. This design ensures the traceability of manual downgrade operations, meeting enterprise-level compliance audit requirements. The response latency for manual downgrades is in the second range, significantly reducing the waiting time for policy rollback compared to waiting for the sliding window to decay naturally (which typically takes several hours to tens of hours).

[0070] The fourth functional module is the new rule injection API. This API allows operators to dynamically inject new rules into the rule set {R_i} without restarting the system. The initial policy state of the newly injected rule is set to SOFT by default and is automatically included in the cumulative statistical monitoring scope of step S7, requiring no additional configuration. The new rule takes effect immediately after injection and begins participating in the verification process of subsequent inference batches. This design enables the system to flexibly respond to new business rule requirements and reduces the operational costs of rule expansion. The following detailed explanation of the complete execution flow of steps S1 to S6 is provided through a specific application example.

[0071] Application Example 1: Single Violation Event Handling under Soft Access Control Path - Observable Delivery of Single Violation Events The user initiates a trip generation request through the client, submitting the following user parameters: departure city Chengdu, destination Lhasa, trip duration (7 days), round-trip identifier round_trip=true, budget level mid, user preferences historicSites, and nature. After the large language model completes inference, it outputs a FinalItinerary object F, which contains the complete 7-day trip data structure. The last item of the trip on the last day (day 7) is a transportation node of type transportation, whose item_detailed.to_location field value is "Lhasa" (destination city), instead of the user's departure city "Chengdu".

[0072] Once step S1 is completed, the FinalItinerary object F is fully received and parsed into a structured object in memory.

[0073] Step S2 executes the deterministic domain rule engine for sequential evaluation. The rule engine executes R1 to R5 in a preset order: R1 round-trip consistency check detects that the item_detailed.to_location field of the last item transportation node on the last day has the value "Lhasa". After case-insensitive matching, this value does not contain the origin city naming token "Chengdu", triggering a violation and generating a violation description "round_trip=true but last transportation to_location='Lhasa' does not contain departure='Chengdu'"; R2 to R5 are executed sequentially without triggering a violation.

[0074] Step S3 executes policy status query and traffic routing. The rule engine queries the policy state machine for the current policy status of R1, and the policy state machine returns state(R1)=SOFT. According to the traffic routing logic, the main process enters the soft access control processing path in step S4a.

[0075] Step S4a executes the soft access control procedure. The main process appends the violation description string generated by R1 to the observation list `quality_issues`, at which point `quality_issues = ["round_trip=true but last transportationto_location='Lhasa' does not contain departure='Chengdu'"]. After the write operation is completed, the main process continues to proceed with subsequent steps without being blocked by this violation event.

[0076] Step S5 executes the three-way feedback chain. The main process POSTs both `quality_issues` and `F` to the business backend's `callbackUrl` via an asynchronous callback channel. The business backend performs the following persistence operations: writes `F` as normal business data to the `biz_itinerary_version` table; concatenates the `quality_issues` list with newline characters into the string "[quality_gate] round_trip=true but last transportation to_location='Lhasa'does not contain departure='Chengdu'", truncates it to 1900 characters, and writes it to the `biz_itinerary_generation_job.error_message` field; updates the `biz_itinerary_generation_job` status to `succeeded`; and pushes a notification to the client via WebSocket.

[0077] Step S6 executes the front-end friendly prompt. After receiving the push notification, the client retrieves the latest trip data and observable fields. If the client detects that an observable field is not empty, it adds a friendly prompt at the bottom of the trip display interface: "The trip has been generated, but we noticed one suggestion for optimization," and provides two operation buttons below the prompt: "Accept the current result" and "Regenerate." If the user selects "Accept the current result," the trip data remains unchanged; if the user selects "Regenerate," the client initiates a new generation request.

[0078] Application Example 2: Counterexample Injection-Based Re-inference under Hard Blocking Paths Using the same user parameters and initial inference scenario as in Application Example 1, the difference is that the current policy state of rule R1 is HARD (it has been automatically upgraded via step S7).

[0079] The execution process of steps S1 to S2 is exactly the same as in application example one. Rule R1 also triggers a violation and generates the same violation description.

[0080] Step S3 executes the strategy state query and routing. The strategy state machine returns state(R1)=HARD. According to the routing logic, the main process enters the hard blockage handling path in step S4b.

[0081] Step S4b performs a hard blocking action. The main process blocks the execution of subsequent steps, organizing the violation description generated by R1 into structured counterexample text. The system appends the following counterexample information to the end of the system prompt for the next round of inference: "[Previous Output Error Correction] The previous generation violated rule R1 (Round Trip Consistency Check). Error details: round_trip=true but lasttransportation to_location='Lhasa' does not contain departure='Chengdu'. Required correction: Ensure the last item of the lastday's items array is a transportation type node with the to_location field containing the departure city token 'Chengdu' (case-insensitive match). Please regenerate the complete itinerary satisfying all constraints." The large language model re-infers based on the injected counterexample context, outputting the corrected FinalItinerary object F'. The main process returns to step S1 with F' as input to re-execute the complete verification process. If rule R1 passes the validation in step S2, the process proceeds normally; if R1 still triggers a violation and the number of re-inference attempts has not reached the limit, step S4b is executed again to re-inject the counterexample.

[0082] According to internal empirical test data, the hit rate of correcting violations on the first retry using the counterexample injection re-inference method reaches approximately 78%. If the number of re-inference attempts reaches the preset limit (e.g., 5 times) but the violation is still not eliminated, the system will treat it as a hard error, return a failure status to the upstream system, and carry the error code "RETRIES_EXHAUSTED".

[0083] Application Example 3: Policy State Transition under Automatic Upgrade Path - High-Frequency Violations Trigger Soft Access Control Upgrade Hard Blocking After the large language model provider released a new version, the new version showed a degradation in its ability to identify cities along the route. The violation rate of the R3 rule (non-empty verification of city content along the route) increased significantly from the historical average of 4% to 22% within 48 hours. The system is currently configured with a sliding window length of N=500, a violation rate threshold of α_3=0.15, and an absolute frequency threshold of β_3=50.

[0084] The cumulative statistics and threshold upgrade engine in step S7 continues to run.

[0085] The sliding window accumulator scans the observable fields of the most recent 500 inference batches in the business task table every 10 minutes and performs aggregation statistics according to rule R3.

[0086] Twelve hours after the new version was released, the statistics were as follows: R3 triggered violations in the last 500 inferences, with the number of batches c_3=95 and the violation rate ρ_3=95 / 500=0.19.

[0087] The dual-dimensional threshold judgment logic performs the following checks: the condition ρ_3=0.19 ≥ α_3=0.15 is met, and the condition c_3=95 ≥ β_3=50 is also met, triggering the upgrade judgment in both dimensions.

[0088] Automatic upgrade and state transition sub-step execution: The policy state machine switches state (R3) from SOFT to HARD. The state transition event is written to the policy state change log, and the log content includes "auto-upgraded due to violationrate 0.19 > threshold 0.15 over recent 500 batches". After the state transition is completed, the policy state machine broadcasts the state transition notification to all running main process instances via message queue.

[0089] Subsequent inference batch requests reaching step S3 will all show state(R3)=HARD. If R3 triggers a violation again in a subsequent batch, a hard-blocking path will be entered to perform a counterexample injection-based re-inference, with an initial retry correction hit rate of approximately 78%. The entire automatic upgrade process is completely transparent to the business side, which does not need to be aware of policy state changes or make any configuration changes to obtain stricter compliance protection.

[0090] Application Example 4: Strategy State Rollback under Manual Degradation Path - Operational Intervention Strategy Rollback Using the scenario from Application Example 3, the large language model provider released a patch within 6 hours of receiving feedback. The ability to identify the cities the R3 rule passed through returned to normal, and the violation rate rapidly decreased to near zero within the last 2 hours. However, the sliding window still includes historical violation batches from before the patch, and the statistical violation rate of R3 remains at ρ_3=0.16 (still higher than α_3=0.15), so the automatic state machine will not immediately trigger a downgrade.

[0091] The operations staff observed the violation frequency curve of R3 through the operations management backend and found that the curve showed a rapid downward trend in the last 2 hours, approaching the threshold reference line, indicating that the model version had been fixed.

[0092] Operations personnel submit downgrade requests via the manual downgrade API. The submitted parameters include: target rule R3, downgrade reason "the model supplier has released a patched version, the ability to identify cities along the route has returned to normal, and the violation rate is expected to continue to decline in the next 24 hours".

[0093] The policy state machine executes the manual downgrade operation of state(R3): HARD → SOFT, and records the manual downgrade event in the policy state change log. The log content includes the operator's account identifier, downgrade reason text, state before downgrade HARD, state after downgrade SOFT, and operation timestamp.

[0094] In subsequent inference batches, R3 violated the rules and re-entered the soft access control path, and the user experience immediately returned to a smooth state (without a full retry triggered by strong blocking).

[0095] After the sliding window is implemented in the next 500 batches, the historical violation data will naturally decay, and the violation rate statistics will gradually decrease to a level consistent with the actual situation.

[0096] Example 2

[0097] This invention provides a multi-level state alternative in terms of the scalability of policy state enumeration.

[0098] In addition to the {soft, hard} two-level state enumeration, the system can be extended to three-level or multi-level state enumeration. Typical multi-level enumeration examples include four levels: {OBSERVE, SOFT, HARD, BAN}. The OBSERVE state corresponds to the observation mode (only records violations without adding them to the observation list), the SOFT state corresponds to the soft access control mode (adds to the observation list but does not block), the HARD state corresponds to the hard blocking mode (blocks and injects negative examples for re-inference), and the BAN state corresponds to the banning mode (directly rejects output and returns an error). Each level corresponds to different handling strategies and differentiated upgrade thresholds. For example, the upgrade threshold for OBSERVE→SOFT is ρ_i ≥ 0.05 or c_i ≥ 10, the upgrade threshold for SOFT→HARD is ρ_i ≥ 0.15 or c_i ≥ 50, and the upgrade threshold for HARD→BAN is ρ_i ≥ 0.40 or c_i ≥ 200.

[0099] Regarding the scalability of the threshold determination algorithm, the system supports multiple alternative determination logics.

[0100] Alternative solution one is the "AND" logical combination: An upgrade is triggered only when both the violation rate ρ_i ≥ α_i and the absolute frequency c_i ≥ β_i are true. This logic is suitable for scenarios with extremely low tolerance for erroneous upgrades.

[0101] Alternative solution two uses a weighted summation logic: The violation rate and absolute frequency are normalized separately and then weighted and summed. When the overall score exceeds a preset threshold, an upgrade is triggered. This is suitable for scenarios that need to consider both dimensions but do not want to trigger an upgrade based on a single dimension.

[0102] Alternative solution three is the prediction logic of a machine learning model: A binary classification model (such as logistic regression, random forest, or gradient boosting tree) is trained based on a historical escalation event dataset. The model takes ρ_i, c_i, historical trend slope, business time period characteristics, etc. as input features and outputs an escalation probability prediction. An escalation is triggered when the predicted probability exceeds a preset threshold (such as 0.7). This model is suitable for advanced scenarios that require adaptive learning of complex escalation patterns.

[0103] Regarding the dynamic adjustment of the sliding window length, the system can adjust the window length parameter in real time based on business traffic. During high-traffic periods (such as holidays or promotional periods), the window length is shortened to 50 to 200, improving the sensitivity to abnormal fluctuations; a typical configuration is N=100. During low-traffic periods, the window length is lengthened to 1000 to 5000, improving the stability of statistical results and noise resistance; a typical configuration is N=2000. The dynamic adjustment of the window length is automatically triggered by monitoring the rate of new records added to the business task table, and the adjustment threshold can be configured by operations and maintenance personnel.

[0104] Regarding variations of the negative example injection strategy, the system supports several alternative injection methods. The negative example summarization variant compresses the original violation description into a shorter hint statement (e.g., compressing detailed field paths and decision conditions into a single summary), suitable for scenarios where long violation descriptions cause the hint words to exceed the model's context window limits. The negative example instance variant replaces the violation description with example text of similar correct output, guiding the model to output the correct result through positive examples, suitable for scenarios requiring explicit display of correct format and content. The negative example grading variant categorizes negative examples based on violation severity: mild violations receive brief hints, moderate violations receive detailed descriptions, and severe violations receive mandatory constraint statements, with different severity levels corresponding to different injection depths and constraint strengths.

[0105] Regarding end-to-end protocol extensions for the three-way feedback link, the system supports multiple alternative communication protocols. Alternative protocol one is asynchronous messaging via message queues: Using message queues such as Kafka or RabbitMQ as callback channels, `quality_issues` and `F` are packaged into a message entity and sent to the topic subscribed to by the business backend. This is suitable for asynchronous decoupling in high-concurrency scenarios. Alternative protocol two is WebSocket long-connection push: The AI ​​service establishes a WebSocket long-connection with the business backend, pushing data in real-time via the long connection when a violation event occurs. This is suitable for scenarios with extremely high real-time requirements. Alternative protocol three is timed pull and polling: The business backend periodically polls the observable interfaces of the AI ​​service to pull the latest violation data. This is suitable for scenarios with complex network environments or firewall restrictions on HTTP callbacks.

[0106] Regarding the expansion of visualization options in the operations management backend, the system supports several alternative visualization components. Alternative component one is a heatmap: This presents rule violation rate data as a heatmap, with the horizontal axis representing time, the vertical axis representing rule identifiers, and color intensity indicating the violation rate value, facilitating quick identification of high-frequency violation rules and abnormal periods. Alternative component two is a Sankey diagram: This displays the complete flow path of a violation event from triggering to handling to persistence to display, along with the processing volume at each stage, facilitating analysis of bottlenecks and losses in the feedback chain. Alternative component three is warning badges: In the rule status visualization panel, a prominent red warning badge is assigned to HARD status rules, a yellow warning badge to rules approaching the threshold, and a green status badge to normal rules, allowing operations personnel to quickly identify rules requiring attention.

[0107] Regarding the cross-industry expansion of domain rule sets, the hardware-software dual-layer dynamic governance framework described in this invention is not limited to tourism itinerary generation scenarios, but can be generalized to other domains that require large language models to generate structured business data. In the financial domain, the following exemplary rules can be configured: transaction amount format verification, account balance adequacy verification, counterparty blacklist verification, regulatory compliance rule verification, etc. In the medical domain, the following exemplary rules can be configured: drug dosage range verification, contraindication conflict verification, diagnostic code compliance verification, patient privacy data anonymization verification, etc. In the legal domain, the following exemplary rules can be configured: validity verification of cited legal provisions, statute of limitations compliance verification, evidence chain integrity verification, format specification compliance verification, etc. All extended domain rule sets can be incorporated into the hardware-software dual-layer dynamic governance framework described in this invention for unified management, enjoying the same platform capabilities such as strategy state machines, cumulative statistics and threshold upgrades, and manual downgrade intervention.

[0108] The technical solution of this invention can be deployed using a variety of technology stack combinations at the engineering implementation level. The AI ​​service layer can use the Python asyncio asynchronous task scheduling framework to receive and process high-concurrency inference requests; the business backend layer can use the Spring Boot framework to implement RESTful API interfaces and business logic processing; the data persistence layer can use relational databases such as MySQL or PostgreSQL to store structured business data and observable fields; the client layer can use native development on iOS Swift or Android Kotlin to implement the user interface and friendly prompts; the operation management backend layer can use frontend frameworks such as React or Vue to implement a visual panel and interactive operations; and the message queue layer can use Kafka or RabbitMQ to achieve cross-service instance state synchronization broadcasting. The above technology stack combinations are merely specific implementations of preferred embodiments. The core innovation of this invention lies in the dynamic strategy state machine itself, which is not strongly bound to any specific technology stack implementation. When external technology stacks are upgraded, the core steps can continue to be applied without any changes.

[0109] In summary, the quantitative technical indicators of this invention are summarized as follows: The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the scope of protection of the present invention is not limited to the preferred parameter values ​​and combinations described in the above specific embodiments. All equivalent substitutions of structures, processes, parameters, and interfaces arising from the concept of the present invention should be included within the scope of protection of the present invention.

Claims

1. An improved method for large model output observability based on hardware and software dual-layer verification and threshold accumulation upgrade, characterized in that: Includes the following steps: S1: Receives and parses structured business data generated by a large language model, extracting key business fields; S2: Perform deterministic validation on the structured business data using a deterministic domain rule engine, and output a list of corresponding violation descriptions for each rule; S3: Query the policy status of each verification rule, where the policy status includes soft access control status and hard blocking status; S4a: If the rule is in a soft access control state and a violation is triggered, append the violation description to the observation list and execute step S5; S4b: If the rule is in a hard blocking state and a violation is triggered, the main process is blocked and the violation is injected as a counterexample into the context of the prompt word in the next round of large language model inference. After triggering the large language model to re-infer, the process returns to step S1 and is executed again. S5: The observation list and structured business data are sent to the business backend via an asynchronous callback channel. The business backend writes the observation list into the observable field of the associated business task, and the client provides a friendly prompt in a non-error form based on the observable field.

2. The method for improving the observability of large model output based on hardware and software dual-layer verification and threshold accumulation upgrading as described in claim 1, characterized in that, The deterministic domain rule engine includes at least one of the following domain-specific validation rules: Round-trip consistency verification rules are used to verify whether the destination city of the last transportation node on the last day of the trip contains the origin city's named token when the user parameters mark the round-trip trip. The starting city content non-empty verification rule is used to verify whether the first day's node of the trip contains the starting city named token; the transit city content non-empty verification rule is used to verify whether the trip covers the transit cities declared by the user. The self-driving node authorization verification rules are used to verify whether self-driving keywords appear in the trip traffic nodes when the user has not declared self-driving. The coordinate uniqueness verification rule is used to verify whether the latitude and longitude pairs of all scenic spot nodes in the itinerary are unique under the preset precision.

3. The method for improving the observability of large model output based on hardware and software dual-layer verification and threshold accumulation upgrading as described in claim 1, is characterized in that... The policy state in step S3 is managed by a policy state machine, which is specifically used for: Maintain the mapping relationship between the unique identifier of each verification rule and the policy state; Provides a policy status query interface, allowing the main process to query the current policy status after rule verification is triggered; It provides a policy state switching interface, supporting bidirectional switching between soft access control state and hard blocking state.

4. The method for improving the observability of large model output based on hardware and software dual-layer verification and threshold accumulation upgrading as described in claim 1, characterized in that, This method also includes a cumulative statistics and threshold upgrade engine, specifically: The sliding window accumulator displays the violation rate and absolute violation frequency of each rule in the most recent N inference batches using a sliding window method; the threshold upgrade judge performs two-dimensional threshold determination.

5. The method for improving the observability of large model output based on hardware and software dual-layer verification and threshold accumulation upgrading as described in claim 1, characterized in that, The sliding window accumulator is specifically used for: Extract violation records from the most recent N inference batches from the observable fields of the business backend database, where N is the configurable window length; Aggregate statistics based on the unique identifier of each rule and calculate the violation rate for each rule; ； Among them, c i To trigger R i The number of batches that violated the rules, where N is the length of the sliding window; The statistics are aggregated based on the unique identifier of each rule, and the absolute violation frequency of each rule is calculated. The absolute violation frequency is equal to the number of batches that trigger the violation.

6. The method for improving the observability of large model output based on hardware and software dual-layer verification and threshold accumulation upgrading as described in claim 3, is characterized in that... The threshold upgrade decision-maker uses a two-dimensional "OR" logic for decision-making, specifically for: Check if ρ is satisfied i ≥ α i , where α i Let be the upper limit threshold for the violation rate of rule i; Check if c is satisfied i ≥ β i , where β i Let be the upper limit threshold for the absolute frequency of rule i; When any condition is met, the policy state machine is triggered to perform a state upgrade, which upgrades the corresponding rule from a soft access control state to a hard blocking state.

7. The method for improving the observability of large model output based on hardware and software dual-layer verification and threshold accumulation upgrading according to claim 1, characterized in that, In step S4b, the hard blocking handling unit injects the violation as a counterexample into the next round of inference, specifically including: The structured description text of the violation is concatenated into the prompts for the next round of reasoning, which includes information on the location of the violation, the field of violation, and the reason for the violation. The large language model is triggered to regenerate structured business data based on prompts containing counterexamples; The regenerated business data is returned as input to step S2 to re-execute the verification process.

8. The method for improving the observability of large model output based on hardware and software dual-layer verification and threshold accumulation upgrading according to claim 1, characterized in that, It also includes manual downgrade intervention, used for: Expose a rule status visualization panel to the operations management backend, displaying the current policy status, violation rate trend, and violation frequency curve for each rule; Provides a manual downgrade API, allowing operations personnel to manually revert rules that have been upgraded to a hard blocking state to a soft access control state; Record manual downgrade events into a policy state change log, including the operator's identity, downgrade reason, and timestamp.

9. The method for improving the observability of large model output based on hardware and software dual-layer verification and threshold accumulation upgrading as described in claim 8, is characterized in that, The manual downgrade intervention also includes a new rule hot-loading function, used for: Receive validation rules submitted by operations personnel via the API through the new rules injection; New rules are dynamically loaded into the rule engine during system runtime; Set the initial policy state of the new rule to soft access control and automatically include it in the sliding window cumulative statistics monitoring scope.

10. The method for improving the observability of large model output based on hardware and software dual-layer verification and threshold accumulation upgrading according to claim 1, characterized in that, It also includes policy state change auditing, used for: Record all policy state transition events in the policy state change log; The automatic upgrade event includes the triggering reason, the status before and after the upgrade, and a timestamp. The manual downgrade event includes the operator's identity, the reason for downgrading, the status before and after the upgrade, and the timestamp.

Images