A method for risk quantification using AI large-scale models in engineering safety production

Abstract

This invention discloses a risk quantification method for AI large-scale models in engineering safety production, relating to the field of engineering safety technology. The method includes: S1, acquiring a domain causal template library constructed based on preset engineering safety standards, the domain causal template library including multiple standardized causal chain structure templates; S2, parsing the inference text generated by the main model in real time, and constructing an instance graph reflecting the current safety inference logic; S3, performing structural matching between the instance graph and the templates in the domain causal template library, and determining whether there is a structural deviation in the inference chain of the main model based on the matching result; if so, triggering a backup model to take over; S4, extracting key safety commitments from the inference context or instance graph of the main model, converting the key safety commitments into formal logical constraints, and injecting the formal logical constraints into the backup model; S5, verifying the response generated by the backup model and determining whether it satisfies the formal logical constraints.

Description

Technical Field

[0001] This application relates to the field of engineering safety technology, and more specifically, to a method for risk quantification processing of AI large-scale models in engineering safety production. Background Technology

[0002] With the deep application of large-scale AI models in engineering safety production, real-time reasoning, decision support, and equipment linkage control in high-risk operation scenarios using these models has become an important means to improve the intelligence level of construction site safety management. However, in actual engineering environments, the reasoning logic and decision results generated by large-scale models are directly related to the safety of on-site personnel and the operational reliability of critical equipment. Any potential reasoning deviations, logical inconsistencies, or decision drifts may lead to the failure of risk control. Therefore, quantifying the risks of AI large-scale models in the safety production process—that is, systematically identifying, measuring, and intervening in their potential uncertainties—is of paramount importance for ensuring the continuous safety and controllability of engineering operations.

[0003] In the application of large-scale models for engineering safety production, existing technologies typically focus only on the accuracy of model output results for a single task, lacking a systematic risk assessment mechanism for the structural integrity and logical consistency of the model's reasoning chain. Especially when large models face complex engineering scenarios or abnormal operating conditions, their internal reasoning processes may deviate from preset safety standards or causal logic.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method for risk quantification processing of large AI models in engineering safety production to solve the above-mentioned technical problems.

[0006] This application provides a risk quantification method for AI large-scale models in engineering safety production, including: S1, acquiring a domain causal template library constructed based on preset engineering safety standards, the domain causal template library including multiple standardized causal chain structure templates; S2, parsing the inference text generated by the main model in real time, and constructing an instance graph reflecting the current safety inference logic; S3, performing structural matching between the instance graph and the templates in the domain causal template library, and determining whether there is a structural deviation in the inference chain of the main model based on the matching result; if so, triggering a backup model to take over; S4, extracting key safety commitments from the inference context of the main model or the instance graph, converting the key safety commitments into formal logical constraints, and injecting the formal logical constraints into the backup model; S5, verifying the response generated by the backup model and determining whether it satisfies the formal logical constraints.

[0007] Based on the embodiments provided in this application, a causal template library conforming to engineering safety standards is pre-constructed in S1, and an instance graph is formed by real-time parsing of the inference text of the main model in S2. S3 further performs structural matching between the instance graph and the template library. This process transforms the abstract inference logic of the main model into quantifiable structural comparison results, thereby proactively determining whether there is a structural deviation in the inference chain of the main model without relying on feedback from the large model itself, providing an objective decision-making basis for disaster recovery switching. Based on the matching results of S3, when a structural deviation is determined in the main model, the standby model is immediately triggered to take over, solving the problem of difficulty in timely fault detection and switching in the prior art. Simultaneously, S4 extracts key security commitments from the inference context or instance graph of the main model and converts them into formal logical constraints, injecting them into the standby model. This allows the standby model to continue the original security inference logic of the main model after takeover, ensuring that the response to the current problem during the switching process remains contextually consistent and logically coherent. S5 verifies the response generated by the standby model using formal logical constraints, ensuring that its output conforms to the security commitments extracted from the original context. This verification mechanism mitigates the risk of uncontrollable output that may result from simply switching models. It ensures that even if the main model deviates from its structure in high-risk operation scenarios, the response of the backup model after taking over can still meet the established safety logic requirements, thereby enhancing the fault tolerance of the engineering safety management system. Attached Figure Description

[0008] The accompanying drawings, which are included to provide a further understanding of embodiments of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0009] Figure 1 This is a flowchart of an optional risk quantification method for AI large-scale models in engineering safety production according to an embodiment of this application;

[0010] Figure 2 A flowchart illustrating another optional risk quantification method for AI large-scale models in engineering safety production according to an embodiment of this application;

[0011] Figure 3 This is a flowchart of another optional risk quantification method for AI large-scale models in engineering safety production according to an embodiment of this application;

[0012] Figure 4 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of this application.

[0013] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0014] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0015] According to one aspect of the embodiments of this application, such as Figure 1 As shown, this application provides a method for risk quantification processing of AI large-scale models in engineering safety production, including:

[0016] S1, Obtain the domain causal template library built based on preset engineering safety standards. The domain causal template library includes multiple standardized causal chain structure templates.

[0017] This invention first constructs a domain-specific causal template library as a safety benchmark. This template library is not a simple collection of texts, but a knowledge base that structures and formally encodes causal relationships in engineering safety standards.

[0018] In practice, pre-set engineering safety standards can be national standards, industry standards, or internal enterprise safety production specifications, or industry-specific "Construction Safety Inspection Standards," etc. The first step in building a template library is to analyze the chapter structure of these standard texts.

[0019] The system identifies the internal structure of the standard text based on its clause numbering and heading hierarchy. For example, the parsing rules can be set to identify lines beginning with "Chapter X" or "X." as chapter headings, and numbers in the format "XYZ" as clauses. In this way, the system can automatically locate and extract the core chapters most relevant to the causal logic of safety, such as "Hazard Identification," "Risk Assessment," and "Control Measures" chapters, and combine these chapters into a standardized chapter sequence according to their inherent hierarchical relationship, ensuring that the causal information extracted subsequently is within the correct context and scope of validity.

[0020] S2, real-time parsing of the reasoning text generated by the main model, constructing an instance graph reflecting the current security reasoning logic;

[0021] S3, perform structural matching between the instance graph and the templates in the domain causal template library, and determine whether there is structural deviation in the inference chain of the main model based on the matching result. If so, trigger the backup model to take over.

[0022] S4. Extract key security commitments from the reasoning context or instance graph of the main model, convert the key security commitments into formal logical constraints, and inject the formal logical constraints into the standby model.

[0023] S5 verifies the response generated by the backup model to determine whether it meets the formal logic constraints.

[0024] Furthermore, S1 includes:

[0025] S11, perform chapter structure analysis on the pre-set engineering safety standard text, identify the reference relationship based on clause number and title level, extract the hazard identification chapter, risk assessment chapter and control measures chapter, and combine the hazard identification chapter, risk assessment chapter and control measures chapter into a standardized chapter sequence;

[0026] S12, based on the trigger word library and dependency syntax pattern in the field of engineering safety, extracts candidate causal triples from the standardized chapter sequence. The trigger word library includes inducing words, inhibiting words, preconditioning words and enabling words.

[0027] Based on the standardized chapter sequence described above, candidate causal triples are extracted using a trigger lexicon and dependency parsing techniques from the field of engineering safety. The trigger lexicon serves as a linguistic landmark for identifying relationships between entities.

[0028] For example, causative words such as "cause," "lead to," "initiate," and "cause" are used to identify a positive correlation between a hazard and a risk event. Inhibitory words such as "prevent," "avoid," "stop," and "eliminate" are used to identify the negative effects of safety measures on risk events. Precondition words such as "must," "should," and "first" are used to identify the conditions required before implementing a measure. Enabling words such as "allow," "may," and "can" are used to identify the states or conditions that make an operation possible.

[0029] Dependency parsing can determine the relationships between various components in a sentence (such as subject, predicate, and object), thereby extracting the head and tail entities associated with trigger words to form candidate causal triples, such as <hazard source: ungrounded wire, induce, risk event: electric shock>.

[0030] S13, based on the preset security rule ontology, candidate causal triples including mandatory modal terms are marked as hard constraint edges, and candidate causal triples including advisory modal terms are marked as soft constraint edges. In the case where there are hard constraint edges and soft constraint edges between the same head entity and the same tail entity, the soft constraint edges are removed and the hard constraint edges are retained. In the case where there are two hard constraint edges between the same head entity and the same tail entity and the relationship types of the two hard constraint edges are opposite, the hard constraint edge with the higher validity level is retained according to the preset standard validity level.

[0031] The extracted candidate causal triples may contain contradictions or duplicates. Therefore, a safety rules ontology is introduced. This ontology is a structured knowledge system that defines the conceptual hierarchy (such as hazard sources, risk events, safety measures, consequences, and states) and attributes of the engineering safety domain, as well as the standard relationships between them. During the conflict resolution phase, this ontology is used for consistency checks.

[0032] For example, the safety rules ontology can be obtained in the following ways: First, the terminology definition section in the preset engineering safety standard is parsed to extract core concepts such as hazard sources, risk events, safety measures, consequences, and states, as well as their subcategories; Second, combined with domain expert knowledge, the hierarchical relationships between concepts (such as "electrical hazard sources" belonging to "physical hazard sources") and reasonable relationship constraints (such as "safety measures" can only "suppress" "risk events" and cannot "induce" them) are supplemented; finally, a structured knowledge system is formed.

[0033] In conflict resolution, the use of ontology includes: first, entity normalization, which maps entities with different expressions but the same semantics (such as "ungrounded wire" and "missing ground") to the same concept node in the ontology; second, concept type verification, which judges the rationality of causal triples based on the concept hierarchy and relation constraints defined in the ontology, and eliminates invalid extractions that do not conform to the ontology constraints.

[0034] Specifically, candidate triples are classified as "hard constraints" or "soft constraints" based on the modal terms they contain. Mandatory modal terms, such as "should," "must," and "prohibited," indicate hard constraints that cannot be violated; while advisory modal terms, such as "should," "may," and "suggest," are marked as soft constraints.

[0035] When constructing a domain causal template library, the causal relationships extracted from safety standard texts are represented in a structured form of "head entity - edge - tail entity". Here, the head entity represents the cause (such as hazard source, state), the tail entity represents the result (such as risk event, safety measure), and the edge represents the type of causal relationship between the two (such as inducement, inhibition).

[0036] When multiple causal triples have the same head entity and the same tail entity, they constitute the case of "same head entity and same tail entity". In this case, conflict resolution of the edge relationship is required.

[0037] For example, for the head entity "ungrounded" and the tail entity "electric shock accident", the following triples may be extracted: Triple A: Ungrounded - induces → electric shock accident (from mandatory clauses); Triple B: Ungrounded - suppresses → electric shock accident (from advisory clauses).

[0038] The two triplets mentioned above have the same head and tail entities, but different edge types, and therefore cannot be preserved simultaneously. Resolution is performed according to the following rules:

[0039] First, if there are hard constraint edges (derived from mandatory words such as "should" and "must") and soft constraint edges (derived from suggestive words such as "should" and "may") between the same head entity and the same tail entity, then the hard constraint edges are retained and the soft constraint edges are removed.

[0040] Second, if there are two hard constraint edges with opposite relationship types between the same head entity and the same tail entity (e.g., one is "inducing" and the other is "inhibiting"), the ruling will be based on the validity level of the standards from which the two edges originate. The validity level rules are: national standards are higher than industry standards, mandatory standards are higher than recommended standards, and newer versions of standards are higher than older versions. Hard constraint edges with higher validity levels will be retained, while those with lower validity levels will be discarded.

[0041] Through the above conflict resolution, it is ensured that only a unique and logically consistent causal relationship edge is retained between each pair of head and tail entities in the domain causal template library. S14, the candidate causal triples after conflict resolution are transformed into a directed acyclic graph structure with node type labels and edge relationship labels. The node type labels include hazard source, risk event, safety measure, consequence and state. The edge relationship labels include inducement, inhibition, preconditioning and enabling. The edge confidence weight of hard constraint edges is set to a first preset value, and the edge confidence weight of soft constraint edges is set to a second preset value. The first preset value is greater than the second preset value. The domain causal template library is then output.

[0042] After conflict resolution, all valid candidate causal triples are transformed into a directed acyclic graph (DAG) structure, which is a template from the domain causal template library. In this graph,

[0043] Nodes have clear type markers, such as hazard source, risk event, safety measure, consequence, and status.

[0044] The edges have clear relational markers, such as inducement, inhibition, preconditioning, and enabling.

[0045] In addition, each edge is assigned a confidence weight based on its source. For example, the confidence weight of hard constraint edges extracted from mandatory rules is set to a higher first preset value (e.g., 0.9); the confidence weight of soft constraint edges extracted from advisory rules is set to a lower second preset value (e.g., 0.6). This weight reflects the importance level of the causal relationship in the safety specifications, providing a basis for subsequent quantitative assessment.

[0046] Through the above process, this invention transforms unstructured engineering safety standard texts into a knowledge base composed of multiple standardized, weighted, logically self-consistent causal chain structure templates.

[0047] Furthermore, S2 includes:

[0048] In the process of generating security analysis or decision text during real-time reasoning in the large AI model (i.e., the main model), this invention needs to monitor its reasoning logic in real time and transform the text into a computable structured form, i.e., an instance diagram.

[0049] S21. Using a named entity recognition model trained on a security domain ontology, identify hazard source entities, risk event entities, safety measure entities, consequence entities, and status entities from the reasoning text, and label the corresponding node type tags.

[0050] First, a named entity recognition model trained on a security domain ontology is used to parse the inference text generated by the main model. This model can be a neural network structure such as BiLSTM-CRF, and its training data comes from a large-scale annotated corpus of security-related vocabulary. This corpus uses a security domain ontology to finely annotate the words in the text.

[0051] The model's input is the inference text generated by the main model, and its output is the identified entities and their corresponding node type labels, for example:

[0052] The input text reads: "Because toxic gas (hazard source) was found on site and forced ventilation (safety measure) was not activated, this could lead to **** poisoning and asphyxiation (risk event)."

[0053] Output entities: toxic gas (hazard source), forced ventilation (safety measure), poisoning and asphyxiation (risk event).

[0054] After identifying entities, the relationships between entities are extracted through dependency parsing based on a pre-defined relation type dictionary. The relation type dictionary provides trigger words for each type of relationship, for example:

[0055] Inducing relationships: "lead to", "initiate", "cause". Inhibiting relationships: "prevent", "stop", "eliminate". Preconditioning relationships: "need", "must", "first". Enabling relationships: "make", "allow", "permit".

[0056] By analyzing the dependency path between "toxic gas" and "poisoning and suffocation", and combining it with the trigger word "will lead to", a "triggering" relationship edge can be extracted, thereby constructing the initial edge set of the instance graph.

[0057] S22, based on a pre-defined relation type dictionary, extracts the inducing relations, inhibiting relations, preconditioning relations and enabling relations between entities through dependency parsing, and constructs an initial instance graph edge set;

[0058] The goal of step S22 is to extract the causal relationships between entities from the inference text generated by the main model, forming an edge set of the instance graph. The specific implementation is as follows:

[0059] The relation type dictionary is a predefined lexical mapping table used to map trigger words in natural language to standard edge relation types. In this implementation, the dictionary contains four types of relations and their corresponding trigger words:

[0060] Triggering Relationships: Trigger words include "cause," "lead," "initiate," "cause," "make," etc., indicating a positive causal relationship where a cause leads to a result. Inhibiting Relationships: Trigger words include "prevent," "avoid," "stop," "eliminate," "contain," etc., indicating a negative blocking effect of measures on risks. Preconditional Relationships: Trigger words include "need," "must," "first," "before," "prerequisite," etc., indicating the conditions or sequence required to perform an operation. Enabling Relationships: Trigger words include "allow," "may," "can," "make possible," etc., indicating that a certain state or condition makes another action possible.

[0061] Dependency syntactic analysis is performed on the inference text to obtain the dependency structure tree of the sentences. The dependency structure tree reflects the grammatical modification relationships between words, such as subject-verb, verb-object, and adverbial modification relationships.

[0062] Extracting relationships between entities includes: locating trigger words in the sentence that belong to the relation type dictionary; determining the core components connected by the trigger word based on dependency syntax relations. For example, for the trigger word "cause," its subject usually points to the cause (head entity), and its object points to the result (tail entity); matching the identified head and tail entities with the entities labeled in step S21 to determine the specific entity objects; and establishing a directed edge between the head and tail entities based on the relation type to which the trigger word belongs, with the direction from the head entity to the tail entity, and the edge type being the relation type corresponding to the trigger word.

[0063] Perform the above operation on each sentence in the reasoning text, and summarize all the extracted directed edges to form an initial instance graph edge set. Each edge in this set contains three elements: head entity identifier, tail entity identifier, and edge relationship type.

[0064] Taking the sentence "Toxic gas was found on site, and the ventilation system must be activated immediately to prevent poisoning and suffocation" from the reasoning text as an example, dependency parsing locates the trigger word "prevent," identifies its subject as "activate the ventilation system," and its object as "poisoning and suffocation." Combining this with the entities identified in S21, "activate the ventilation system" corresponds to the "safety measures" type entity, and "poisoning and suffocation" corresponds to the "risk event" type entity. Based on the mapping of the trigger word "prevent" to an "inhibition relationship," a directed edge is established between "activate the ventilation system" and "poisoning and suffocation," with the direction pointing from "activate the ventilation system" to "poisoning and suffocation," and the edge type being inhibition. Through this method, the system transforms the causal relationships in natural language text into structured directed edges, providing a foundation for subsequent instance graph matching.

[0065] S23. For the first entity and the second entity whose relationship is not explicitly expressed in the reasoning text, query whether there is a directed path of length 2 from the node type of the first entity to the node type of the second entity in the domain causal template library. The directed path of length 2 is formed by the first entity connecting to the second entity through a single intermediate entity. If there is a directed path and the edge relationship label of each edge in the directed path is consistent with the contextual semantics of the reasoning text, then add an inference edge in the instance graph and set the edge confidence of the inference edge to the product of the edge confidence weights of each edge in the directed path.

[0066] Causal reasoning in engineering safety often involves implicit logical chains that may not be explicitly stated in the text. Therefore, this invention designs an inference mechanism based on a template library.

[0067] When there are two entities (entity 1 and entity 2) in the instance graph, and the relationship between them is not explicitly expressed in the text, the system queries the domain causal template library. If a directed path of length 2 exists in the template library from the node type of entity 1 to the node type of entity 2 (i.e., entity 1 is connected to entity 2 via an intermediate entity type), the system will make an inference. For example, in the instance graph, there is no direct relationship between entities "toxic gas" (hazard source) and "ventilation detection" (safety measure), but the template library contains the path "hazard source - trigger -> risk event - suppression -> safety measure," and the context of the inference text (e.g., "toxic gas may cause poisoning and suffocation, ventilation detection is required") is semantically consistent with this path.

[0068] The determination of "contextual semantic consistency" is achieved by calculating the similarity between the entity and the nodes in the path in the word vector space. If the similarity exceeds a preset threshold, the system considers the inference reasonable and adds a "suppressed" inference edge from "toxic gas" to "ventilation detection" in the instance graph. The confidence weight of this inference edge is set to the product of the confidence weights of all edges on the directed path in the template library (e.g., 0.9 * 0.9 = 0.81), reflecting the high credibility of the relationship inferred from the standard template.

[0069] Through the above steps, the instance graph constructed by S2 not only reflects the causal logic explicitly expressed in the main model's reasoning text, but also supplements the implicit but important security logic in the text with domain knowledge, laying the foundation for accurate matching with the standard template in the future.

[0070] After constructing the instance graph, it is structurally matched against various templates in the domain causal template library. The core algorithm for matching is subgraph isomorphism detection, which determines whether the instance graph contains a subgraph isomorphic to a given template graph. To ensure efficient and accurate matching, multi-stage constraints are introduced into the matching process:

[0071] Strong type constraint: Only instance graph nodes of the same node type are allowed to match template graph nodes. For example, a "hazard source" node in the instance graph can only match a "hazard source" node in the template graph.

[0072] Direction-sensitive constraint: The matching direction of relation edges must be strictly consistent. For example, the "inducing" edge in the instance graph cannot match the "suppressing" edge in the template graph; otherwise, the matching branch will be pruned.

[0073] Critical Path Validation: Some paths in the template library, such as the shortest path from "risk event" to "safety measure," may be marked as "mandatory paths," meaning that this is a causal chain that is explicitly required by the safety standard. If there is no sub-path isomorphic to this mandatory path in the instance graph, it is immediately determined as a structural deviation, and the matching terminates.

[0074] When the matching degree is lower than a preset threshold or the critical path is missing, the system determines that the inference chain of the main model has a structural deviation and triggers the backup model to take over. Whether the deviation is determined or not, the system needs to prepare guidance information for the backup model, that is, extract key security commitments and convert them into formal logical constraints.

[0075] When no deviation occurs, state nodes, risk event nodes, etc., are extracted from the instance graph and converted into a composite constraint chain according to the predefined causal graph to logical expression mapping rules. For example, the pattern "state node connected to risk event node via enabling edge" can be mapped to a temporal probability constraint of "if the state is true, then the risk event may occur"; the pattern "risk event node connected to safety measure node via preceding edge" can be mapped to a mandatory constraint of "if the risk event exists, then the safety measure must be executed". These constraints are combined into a complete composite constraint chain through logical conjunction (AND) operations, guiding the backup model to generate a response within the correct framework.

[0076] When a deviation occurs, it means that the main model's reasoning has deviated from the baseline framework of the safety specifications. At this point, the system will extract high-confidence "state assertions" from the instance graph as key safety commitments, such as "valve closed" or "alarm triggered." These commitments are converted into "state assertion constraints" and marked as "low-confidence migration patterns," informing the backup model that these are currently verifiable factual states, but that reasoning and generation need to be based on them with caution.

[0077] Finally, these formal logical constraints are injected into the standby model. This can be achieved by encoding the constraints as a Structured Constraint Markup Language (SCCL) and placing it at the very beginning of the standby model's system prompts, ensuring that these constraints are taken into account before any response is generated.

[0078] Through the above mechanism, this invention realizes a complete closed loop from standard construction, real-time monitoring, deviation judgment to reliable takeover, providing a systematic risk quantification method for the application of AI big data models in engineering safety production.

[0079] Furthermore, the core of step S3 is to perform structural matching between the instance graph and templates in the domain causal template library. Through multi-stage constraint screening and quantitative evaluation, it determines whether there is structural deviation in the inference chain of the main model. The specific implementation includes three stages: candidate matching pair generation, matching search, and matching verification, as well as the weighted calculation of the matching degree score. S3 includes:

[0080] S31, In the candidate matching pair generation stage, strong type constraints are implemented based on node type labels, including: only allowing instance graph nodes with the same node type label to establish matching candidates with template graph nodes, and eliminating matching candidates between different node type labels;

[0081] It needs to be explained that during the structure matching process in step S3, the instance graph needs to be compared with the templates in the domain causal template library. Here, a template refers to each standardized causal chain structure template in the domain causal template library; each template is itself a directed acyclic graph (DAG) structure. Therefore, template graph nodes refer to the nodes that constitute this DAG.

[0082] The template graph nodes originate from the domain causal template library constructed in step S1. Specifically, in step S14, the candidate causal triples after conflict resolution are transformed into a directed acyclic graph structure, where each node is a template graph node. Each template graph node has a clear type label, including hazard source, risk event, safety measure, consequence, and state. In step S3, the template graph nodes serve as the benchmark objects for matching, used to compare with nodes in the instance graph.

[0083] During the candidate matching pair generation phase, strong type constraints are implemented, allowing only instance graph nodes with the same node type label to establish matching candidates with template graph nodes.

[0084] A predefined node type mapping table contains the following mandatory correspondences: Hazard source type nodes can only match hazard source type nodes in the template diagram; Risk event type nodes can only match risk event type nodes in the template diagram; Safety measure type nodes can only match safety measure type nodes in the template diagram; Consequence type nodes can only match consequence type nodes in the template diagram; Status type nodes can only match status type nodes in the template diagram.

[0085] For each node in the instance graph, traverse all nodes in the template graph and check if their node type labels are consistent. If the types are inconsistent, the candidate matching pair is directly discarded and not proceeded to the next search. This constraint narrows the candidate matching space to nodes of the same type, avoiding invalid matching calculations.

[0086] S32, In the matching search phase, direction-sensitive constraints are implemented based on edge relationship labels, including: if the induced edge in the instance graph matches the inhibiting edge in the template graph, or the inhibiting edge in the instance graph matches the induced edge in the template graph, then the matching branch is pruned.

[0087] During the matching search phase, direction-sensitive constraints are implemented to strictly verify the direction of edge relationship types.

[0088] The logic for determining a direction error is as follows: when the edge relationship type in the instance graph is inconsistent with the edge relationship type in the template graph, it is considered a direction error. Specifically, this includes: if an induced edge in the instance graph matches a suppressed edge in the template graph, it is determined to be a direction error; if a suppressed edge in the instance graph matches an induced edge in the template graph, it is determined to be a direction error; if a preceding edge in the instance graph matches an enabling edge in the template graph, it is determined to be a direction error.

[0089] The pruning condition is as follows: During the recursive search, if any incorrectly oriented edge match is detected in the current branch, the search for that branch is immediately terminated, and it is no longer expanded downwards. This constraint ensures that the matching results strictly maintain the consistency of the causal relationship direction.

[0090] S33. In the matching verification phase, identify the shortest path from the risk event node type to the safety measure node type in the causal chain structure template, and check whether the shortest path was marked as a mandatory path when the template was built. The mandatory path is a causal chain that is explicitly referenced by the clause number in the preset engineering safety standard and must not be missing. If there is no sub-path isomorphic to the mandatory path in the instance graph, the structure deviation is determined to be valid, the matching calculation is terminated and zero matching degree is output.

[0091] During the matching and verification phase, the forced paths in the template graph are identified, and it is verified whether there are isomorphic sub-paths in the instance graph.

[0092] Determining the shortest path involves using a breadth-first search algorithm to calculate the shortest path from risk event node types to safety measure node types in the template graph. The path length is measured by the number of edges. For example, if a risk event node is directly connected to a safety measure node via an edge, the path length is 1; if it needs to be indirectly connected via an intermediate node (such as a status node), the path length is 2 or more.

[0093] Mandatory path identification rules: During template construction, each causal chain is marked as a mandatory path. The identification rules include: when the standard clauses on which the path is based contain both risk-related terms (such as "accident", "risk", "hazard") and measure-related terms (such as "detection", "protection", "control"), and also contain mandatory modal terms (such as "must", "should", "must not"), the path is marked as a mandatory path.

[0094] Criteria for determining isomorphic subpaths: An improved VF2++ algorithm is used for subgraph isomorphic search. The criteria include: Consistent node type: The node type of the instance graph is the same as the corresponding node type on the forced path of the template graph. Consistent edge type: The edge relationship type of the instance graph is the same as the corresponding edge type on the forced path of the template graph. Consistent edge direction: The edge direction of the instance graph is the same as the edge direction on the forced path of the template graph.

[0095] If there is no sub-path in the instance graph that satisfies the above isomorphism criteria with the forced path, the structural deviation is determined to be valid, and the matching calculation is terminated.

[0096] In some embodiments, after the instance graph passes the forced path verification, a matching score is calculated to quantitatively evaluate the overall matching degree between the instance graph and the template graph. The matching score is calculated using a weighted summation method, as shown in the following formula:

[0097] Match score = (node ​​matching weight × node matching rate) + (edge ​​matching weight × edge matching rate) + (forced path matching weight × forced path matching rate).

[0098] Wherein, node matching rate = number of successfully matched nodes ÷ total number of nodes in the template graph; edge matching rate = number of successfully matched edges ÷ total number of edges in the template graph; forced path matching rate = number of successfully matched forced paths ÷ total number of forced paths in the template graph. Node matching weight, edge matching weight, and forced path matching weight are preset coefficients, and the sum of the three is 1.

[0099] In one specific implementation, the weights are set as follows: node matching weight 0.2, edge matching weight 0.3, and forced path matching weight 0.5. This setting reflects the core role of forced paths in security assessment, ensuring that the matching status of key causal chains plays a decisive role in the matching score.

[0100] The calculated matching score ranges from 0 to 1. When the matching score is lower than a preset threshold (e.g., 0.7), the structural deviation is determined to be true, triggering the backup model to take over; when the matching score is not lower than the preset threshold, the structural deviation is determined to be false, and the main model continues to execute inference.

[0101] Through the above-mentioned multi-stage constraints and quantitative evaluation mechanisms, this invention ensures that the structural matching process has both strict logical consistency and the ability to quantitatively measure the degree of matching, providing a reliable basis for subsequent backup model takeover decisions.

[0102] In one specific embodiment of this application, such as Figure 2 As shown, the first step is to construct a domain causal template library. The pre-defined engineering safety standard text is parsed to extract core chapters such as hazard identification, risk assessment, and control measures, forming a standardized chapter sequence. Subsequently, based on a trigger lexicon and dependency parsing, causal triples are extracted from the chapters, and conflict resolution is performed on the extracted triples, including prioritizing hard constraints and adjudicating standard validity levels. The resolved triples are then converted into a directed acyclic graph structure with node type labels, edge relationship labels, and confidence weights, outputting the domain causal template library.

[0103] During model inference, the inference text generated by the main model is parsed in real time. Entities such as hazards, risk events, safety measures, consequences, and states are identified through a named entity recognition model. A relation type dictionary and dependency parsing are used to extract inducing, inhibiting, preconditioning, and enabling relationships between entities, constructing an initial set of instance graph edges. For relationships not explicitly expressed in the text, implicit relationships are inferred by querying directed paths of length 2 from the template library, ultimately generating a complete instance graph.

[0104] In the structure matching phase, the instance graph is compared with templates in the template library. First, strong type constraints are applied, allowing only nodes of the same type to establish matching candidates. Then, direction-sensitive constraints are applied to eliminate matching branches with inconsistent edge relationship types. In the forced path verification, it is checked whether the instance graph contains forced paths marked in the template (such as the shortest path from a risk event to a safety measure). If a forced path is missing, a structural deviation is directly determined, and the matching degree is zero. If a forced path exists, the matching degree score is further calculated (based on a weighted sum of node matching rate, edge matching rate, and forced path matching rate), and compared with a preset threshold. Finally, a judgment result of no deviation or structural deviation is output.

[0105] Furthermore, S4 includes:

[0106] S41, Receive the structural deviation determination result of S3;

[0107] After step S3 completes the structure matching, it outputs the structure deviation determination result. This result is an enumeration type data structure, including three states:

[0108] No deviation: The instance graph passes the forced path verification and the matching score is not lower than the preset threshold. Deviation exists: The forced path is missing or the matching score is lower than the preset threshold. Pre-failure mode: The matching score is continuously decreasing but has not yet reached the deviation threshold.

[0109] The decision result is passed from S3 to S4 as follows: step S3 passes the decision result as a return value to the calling interface of step S4, and step S4 selects different constraint transformation strategies based on the result.

[0110] S42, if the structural deviation determination result indicates that there is no structural deviation, then extract the state node, risk event node, safety measure node and consequence node from the instance diagram, and convert them based on the preset mapping rules from cause-effect diagram to logical expression;

[0111] The mapping rules include: the pattern mapping of state nodes connected to risk event nodes via enable edges is a temporal probability constraint; the pattern mapping of risk event nodes connected to safety measure nodes via pre-edges is a mandatory constraint; the pattern mapping of safety measure nodes connected to risk event nodes via suppression edges is a remedial constraint; and the pattern mapping of state nodes connected to safety measure nodes via pre-edges is a permissive constraint. The constraints obtained by mapping are logically combined to obtain a composite constraint chain.

[0112] When the structural deviation determination result is no deviation, state nodes, risk event nodes, safety measure nodes, and consequence nodes are extracted from the instance diagram and transformed based on the preset mapping rules from cause-effect graphs to logical expressions. The four mapping rules are as follows:

[0113] First, temporal possibility constraints:

[0114] Mapping Pattern: State nodes are connected to risk event nodes via enabling edges. Transformation Rule: The existence of a state indicates that a risk event may occur in the future. Logical Expression: State(s) → RiskEvent(r). Where State(s) represents that state s is true, and RiskEvent(r) represents that risk event r may occur at some point in the future. Example: In the instance graph, the "valve locked state" node is connected to the "leakage risk" node via an enabling edge, which is transformed into the constraint: "If the valve is locked, then leakage risk may occur."

[0115] Second, mandatory constraints: Mapping pattern: Risk event nodes are connected to safety measure nodes via a preceding edge. Transformation rule: This indicates that when a risk event exists, the safety measure must be executed. Logical expression: RiskEvent(r) → □ Measure(m). Where RiskEvent(r) indicates that the risk event r has occurred or exists, and □ Measure(m) indicates that the safety measure m must be executed. Example: In the example graph, the "Leakage Risk" node is connected to the "Initiate Emergency Shutdown" node via a preceding edge, which is transformed into the constraint: "If a leakage risk exists, emergency shutdown measures must be initiated."

[0116] Third, elimination constraint: Mapping pattern: Safety measure nodes are connected to risk event nodes via suppression edges. Transformation rule: This indicates that the risk event is eliminated after the safety measure is executed. Logical expression: Measure(m) → ¬RiskEvent(r) where Measure(m) indicates that safety measure m has been executed, and ¬RiskEvent(r) indicates that risk event r no longer exists. Example: In the instance graph, there is a "Initiate Emergency Shutdown" node connected to the "Leakage Risk" node via a suppression edge, which is transformed into the constraint: "If emergency shutdown is initiated, the leakage risk is eliminated."

[0117] Fourth, Permissive Constraints: Mapping Pattern: State nodes are connected to safety measure nodes via a preceding edge. Transformation Rule: This indicates that the state is a prerequisite for the execution of the safety measure. Logical Expression: State(s) → Permit(Measure(m)) where State(s) indicates that state s is true, and Permit(Measure(m)) indicates that safety measure m is allowed to be executed. Example: In the example diagram, there is a state node "Reactor temperature drops to a safe range" connected to the measure node "Open reactor" via a preceding edge, which is transformed into the constraint: "The reactor is only allowed to be opened when the reactor temperature drops to a safe range."

[0118] S43, if the structural deviation determination result indicates that there is a structural deviation, then select entities whose node type is marked as state from the instance graph, and take entities whose edge confidence is higher than the preset confidence threshold as key security commitments, convert them into state assertion constraints, and mark them as low confidence migration modes.

[0119] The constraints obtained from the four mappings described above are logically conjuncted to form a compound constraint chain. The specific implementation of the conjunction operation is as follows: multiple constraint formulas are connected using the logical AND operator (∧) to form a conjunctive normal form.

[0120] The expression for a composite constraint chain is: C = C1 ∧ C2 ∧ C3 ∧ ... ∧ Cn. Here, C1 to Cn are the constraints extracted from the instance graph, respectively. The conjunct composite constraint chain indicates that all constraints must be satisfied simultaneously; violation of any constraint is considered a failure of the entire chain.

[0121] When the structural deviation determination result indicates that a deviation exists, a low-confidence migration mode is adopted, and only high-confidence state entities are extracted as key security commitments.

[0122] For example, a confidence threshold of 0.8 can be preset. This value is determined based on the reliability requirements of state assertions in the field of engineering safety; that is, a state entity is only included in a critical safety commitment if the system's confidence in identifying the entity reaches 80% or higher. State entities below this threshold are considered unreliable and are not extracted.

[0123] The extracted state entities are converted into state assertion constraints, which are single state assertions that do not contain causal logic. For example, the "valve is closed" state entity extracted from the instance graph is converted into a state assertion constraint. This constraint only represents the current state fact and does not involve causal relationships between this state and other entities.

[0124] The difference between state assertion constraints and complete constraint chains: Complete constraint chains (such as compound constraint chains) contain causal logic, such as "If state A is true, then risk event B may occur", which expresses the deductive relationship between state and risk; while state assertion constraints only express a single fact, such as "state A is true", and do not contain deductive relationships.

[0125] Handling strategies for low-confidence transition modes: Under this mode, the following strategies can be adopted: Reduce the number of injected constraints: Inject only state assertion constraints, not causal logic constraints. Reduce the enforcement level of constraints: Downgrade the original hard constraints to soft constraints, allowing the alternative model to deviate with sufficient justification. Increase the rigor of subsequent validation: In the S5 validation stage, apply stricter validation criteria to the responses generated under low-confidence transition modes, for example, increasing the validation threshold from 0.7 to 0.85.

[0126] Furthermore, in S42, the probability constraint indicates that if the state is established, a future risk event may occur; the mandatory constraint indicates that if a risk event exists, the safety measures must be implemented; the elimination constraint indicates that if the safety measures are implemented, the risk event is eliminated; and the permissive constraint indicates that the state is a prerequisite for the safety measures.

[0127] The four constraint mapping rules mentioned above are equivalently expressed by logical formulas in this embodiment to ensure the clarity and computability of the formal constraints.

[0128] Temporal probability constraints correspond to temporal logic formulas, indicating that if a certain state is true, a certain risk event will inevitably occur in the future. Here, "always" means that the implication holds true at all times, and "sometime in the future" means that the risk event will occur at some point in the future.

[0129] Mandatory constraints correspond to the conditional implication formula, which states that if a risk event exists, the safety measures must be implemented. This formula directly reflects the necessary connection between risk and action.

[0130] The elimination constraint corresponds to the negative implication formula, which states that if the safety measures are implemented, the risk event is eliminated. This formula reflects the blocking effect of the measures on the risk.

[0131] Permissive constraints correspond to precondition formulas, indicating that the implementation of security measures is contingent upon the establishment of a certain state.

[0132] The meanings of the above logical symbols are as follows: the implication symbol represents the logical relationship of "if...then...", and the negation symbol represents "not" or "not true". Through these logical formulas, the constraints described in natural language are transformed into a form that can be understood and verified by computers.

[0133] Furthermore, formal logical constraints are injected into the alternative model, including:

[0134] S421 encodes formal logic constraints into a structured constraint markup language format, uses invariant markup segments to encapsulate state assertion constraints, uses dependency markup segments to encapsulate precondition constraints, uses chain markup segments to encapsulate multi-step causal constraints, and uses mandatory attribute markup to distinguish between hard and soft constraints.

[0135] S422, insert a system constraint marker start character at the beginning position of the system prompt word in the standby model, place the encoded constraint after the system constraint marker start character, and close it with a system constraint marker end character, ensuring that the constraint is at the beginning of the system prompt word and is separated from the subsequent natural language context by a newline.

[0136] This invention defines a structured constraint markup language for encoding formal logical constraints into a format recognizable by alternative models. This markup language adopts an XML-style tag structure, specifically defined as follows:

[0137] Invariant marker segment: using <invariant id="约束标识符" type="约束类型"> The `<stateassum>` tag encapsulates state assertion constraints. The `id` attribute uniquely identifies the constraint, and the `type` attribute takes the value `hard` or `soft`, representing hard and soft constraints respectively. The tag content is a natural language description of the state assertion. The closing tag is...< / invariant> .

[0138] Dependency tag section: Use <dependency id="约束标识符" type="约束类型"> The tag encapsulates preconditions and constraints, indicating conditions that must be met before an operation can be performed. The closing tag is...< / dependency> .

[0139] Chained marker segments: using <chain id="约束标识符" type="约束类型"> The tag encapsulates multi-step causal constraints, used to represent a constraint chain formed by multiple causal relationships linked together. The closing tag is...< / chain> .

[0140] Mandatory attribute markers: The type attribute distinguishes the level of mandatory constraint. type="hard" indicates a hard constraint, representing an inviolable safety rule that the backup model must strictly adhere to; type="soft" indicates a soft constraint, representing a suggestive rule that the backup model can deviate from appropriately with sufficient justification.

[0141] The encoded constraints are placed at the very beginning of the system prompt words in the standby model. Specifically, a system constraint start marker is inserted at the beginning of the system prompt words.<SYSTEM_CONSTRAINTS> Place the aforementioned constraint segment after the start symbol, and end with the system constraint tag.< / SYSTEM_CONSTRAINTS> Closure. A blank line is inserted between the constraint section and the subsequent natural language context to ensure that the constraint content is semantically clear and distinct from the model task description. Furthermore, S5 includes:

[0142] S51, the response generated by the backup model is parsed into structured segments and natural language segments; the structured segments are generated by the backup model according to a preset output format, and the structured segments include action marker segments, state marker segments and decision marker segments;

[0143] To ensure the operability of the verification, the backup model generates a response according to a preset output format. This format contains three structured segments:

[0144] Action marker segment: Use <action>The label encapsulates the decision-making actions made by the model, such as <action> Activate the emergency ventilation system< / action> .

[0145] Status flag segment: Use <state>The labels encapsulate the model's expected state changes. Each state change includes a variable name and a target value, for example... <state> Valve status = Closed< / state> .

[0146] Decision marker segment: using <decision>The final decision conclusion of the tag encapsulation model, for example <decision> Permission to enter confined space for work< / decision> .

[0147] S52, extract the state transition sequence and action execution sequence from the structured segment, convert the formal logic constraints into the standard input format of the SMT solver, call the SMT solver to verify whether the state transition sequence satisfies the invariant constraints and dependencies, and verify the satisfiability of the timing logic constraints within the preset step size range;

[0148] Extract the state transition sequence from the structured segment. Each state transition contains four fields: timestamp (indicating the time the state change occurred), variable name (indicating the state variable that changed), old value (indicating the state value before the change), and new value (indicating the state value after the change). The extraction rule is: parse each... <state>The tags are used to separate the variable name and the new value based on the equal sign in the tag content, and the transformation record is generated by combining the time sequence information.

[0149] The extraction method for action execution sequences is similar; each... <action>Tags are used to extract action names and execution times. A correspondence exists between action execution sequences and state transition sequences: action execution typically triggers state changes, and the system establishes this association by comparing timestamps.

[0150] The formal logic constraints are converted into the standard input format (SMT-LIB format) of the SMT solver. The conversion rule is to map the logical connectors in the constraint expressions to the corresponding assertion statements in SMT-LIB.

[0151] During verification, the system uses the state transition sequence and action execution sequence as input models for the solver, and calls the SMT solver to verify whether the state transition sequence satisfies invariant constraints and dependencies. The preset step size range is set to k≤10, meaning the solver verifies the satisfiability of temporal logic constraints within 10 time steps. This step size range is set based on the actual requirements of safety response time in engineering safety production scenarios, that is, to complete the verification of safety constraints within a finite decision step size, avoiding the exhaustion of computational resources caused by infinite time reasoning.

[0152] S53, extract action keywords and state keywords from the natural language segment, calculate the first word vector of the action keyword, calculate the second word vector of the state keyword, calculate the third word vector of the corresponding action and state in the structured segment, calculate the first cosine similarity between the first word vector and the third word vector, calculate the second cosine similarity between the second word vector and the third word vector, if the first cosine similarity or the second cosine similarity is lower than the preset similarity threshold, the verification is deemed to have failed.

[0153] The semantic vectors of the text are generated using a pre-trained word vector model (such as BERT or Word2Vec), with the vector dimension being the model's preset output dimension (such as 768 dimensions). The cosine similarity is calculated by taking the cosine of the angle between the two vectors, with the value ranging from 0 to 1. The closer the value is to 1, the more semantically similar the text is.

[0154] During verification, the system extracts action and state keywords from the natural language segment and calculates their cosine similarity with the word vectors of the corresponding actions and states in the structured segment. The preset similarity threshold is set between 0.6 and 0.8, and in one specific implementation, it is set to 0.7. This value is determined based on the requirement for terminology consistency in the field of engineering safety; that is, when the semantic similarity is below 0.7, it is considered that there is a semantic conflict between the natural language description and the structured statement.

[0155] Furthermore, when S52 or S53 determines that verification has failed, the following actions are taken:

[0156] S54. Based on the verification results of S52, extract the identifier of the violated constraint and determine the violation type according to the tag segment type to which the violated constraint belongs. Violation types include invariant violation, dependency violation and chain violation.

[0157] When validation fails, the system extracts the identifier of the violated constraint. The identifier follows a naming convention of "constraint type + sequence number," for example, inv1 represents the first invariant constraint, dep2 represents the second dependency constraint, and chain1 represents the first chain constraint. The identifier directly corresponds to the tag segment type, facilitating the location of the specific constraint that was violated.

[0158] For example, the criteria for determining the type of violation are as follows: Invariant violation: The state assertion is false. For example, the constraint statement is "valve is locked," but a record of "valve is not locked" appears in the state transition sequence. Dependency violation: Preconditions are not met. For example, the precondition "temperature is below the safety threshold" for a certain measure is not met, but the measure is still executed in the model. Chain violation: Causal chain is broken. For example, a risk event exists, but the corresponding safety measure is not executed, resulting in an incomplete causal chain.

[0159] S55, append the description text containing the violated constraint identifier and the correction direction to the end of the dialogue history of the standby model, request to regenerate the response, and record the number of retries. When the number of retries reaches a preset integer, stop retries.

[0160] Generate a repair suggestion that includes a description of the violated constraint and a direction for correction. The template for the repair suggestion is: "Constraint violated [identifier]: [constraint description], please ensure that the response includes [correction direction]". For example: "Constraint inv1 violated: The reactor is prohibited from being opened when the valve is locked, please ensure that the response does not include the action of 'opening the reactor'."

[0161] The repair prompt is appended to the end of the dialogue history of the backup model, requesting a regeneration of the response and recording the number of retries. The default integer value is 3 retries. This value is set based on a balance between user experience and system security: too few retries may lead to oversensitivity to occasional verification failures, while too many retries will affect the real-time performance of the response.

[0162] S56 If the verification still fails after the number of retries reaches a preset integer, a cascading switch to the third backup model or a rule-based expert system is triggered, and the reasoning text output by the main model is marked as an unreliable sample.

[0163] If verification fails after three retries, a cascading switch is triggered. The triggering conditions for a cascading switch are: the same constraint is violated in three consecutive retries, and the response generated after each retry fails verification.

[0164] The target system for cascading switching is either a third backup model or a rule-based expert system. The third backup model can be a large model from another vendor, serving as an alternative to the current backup model. The rule-based expert system is a predefined decision tree built according to engineering safety standards, generating safety decisions using fixed rule logic. During switching, the system first attempts to call the third backup model; if it remains unavailable, it degrades to the rule-based system.

[0165] The inference text output by the main model is marked as an unreliable sample, and related metadata is recorded. The sample storage format includes the following fields: original inference text (content generated by the main model), matching score (matching score calculated in step S3), validation result (validation failure information in step S5), constraint identifier (violated constraint), and timestamp (time of occurrence).

[0166] Furthermore, S3 also includes a pre-triggering mechanism:

[0167] S34, during the structural matching process, calculates the matching score between the instance graph and the domain causal template library in real time, and records the time series data of the matching score. The sampling frequency of the time series data is synchronized with the model inference cycle.

[0168] The matching score is calculated using a weighted summation method, specifically the formula set in the above embodiment: Matching score = (Node matching weight × Node matching rate) + (Edge matching weight × Edge matching rate) + (Forced path matching weight × Forced path matching rate).

[0169] The node matching rate is the ratio of the number of successfully matched nodes to the total number of nodes in the template graph; the edge matching rate is the ratio of the number of successfully matched edges to the total number of edges in the template graph; and the forced path matching rate is the ratio of the number of successfully matched forced paths to the total number of forced paths in the template graph. The sum of all weight coefficients is one. In one specific implementation, the node matching weight is 0.2, the edge matching weight is 0.3, and the forced path matching weight is 0.5 to reflect the core role of forced paths in security assessment.

[0170] During the structure matching process, the matching score is calculated in real time and recorded as time series data. The sampling frequency is synchronized with the model inference cycle; that is, after each complete inference response of the main model, the system calculates and records the matching score of the instance graph generated by that response. The sampling timing is at the end of model inference, ensuring that each sampling corresponds to a complete inference cycle.

[0171] The time series data is stored in memory using a fixed-length circular queue structure, retaining the data from the 10 most recent sampling points. This length is set based on the following considerations: 10 sampling points are sufficient to identify a continuous trend of decreasing matching accuracy, while avoiding excessive memory consumption due to caching too much historical data. When there are fewer than 10 sampling points, the system stores the actual number, and trend determination is only performed after at least 3 data points have accumulated.

[0172] S35: Calculate the matching degree difference between adjacent sampling time points based on time series data. If three consecutive matching degree differences are negative and the cumulative decrease exceeds the preset proportional coefficient, it is determined to be a pre-failure mode. The backup model is pre-takeover triggered before an explicit structural deviation occurs in the inference chain.

[0173] The system calculates the difference between adjacent sampling time points using the following formula: ,in Indicates the current time point Match score, This represents the matching score at the previous time point. When... When the value is negative, it indicates that the matching degree has decreased compared to the previous moment.

[0174] A sliding window approach is used to determine a continuous downward trend. Each time new sample data arrives, the data within the window is updated; the window length is 3 sample points. A trend is determined when the difference between the three sample points within the window is negative. , and At that time, the first condition for continuous decline is met. If the accumulated data is less than three sampling points, no judgment is made temporarily, and the window is allowed to fill.

[0175] When three consecutive differences are all negative, the system further calculates the cumulative decrease. The formula for calculating the cumulative decrease is:

[0176]

[0177] in, This represents the matching score at the first time point out of three consecutive sampling points. This represents the matching score at the third time point. The formula calculates the percentage decrease between the first and last times of the three most recent sampling points.

[0178] The comprehensive judgment condition for the pre-trigger mechanism is: three consecutive matching degree differences are all negative, and the cumulative decrease exceeds a preset proportional coefficient. This condition can be expressed as the following mathematical inequality:

[0179]

[0180] Wherein, α is a preset proportional coefficient. The preset proportional coefficient ranges from 0.05 to 0.15, and in one specific implementation, it is set to 0.1. This value is set based on a balance between system fault tolerance requirements and false alarm rate: if the coefficient is too small, it will lead to oversensitivity and frequent false triggering of pre-control; if the coefficient is too large, it may miss detection and fail to provide timely warnings before deviations occur.

[0181] When the above conditions are met, the system determines that it is currently in a pre-failure mode. The difference between a pre-failure mode and an explicit structural deviation is that in a pre-failure mode, the matching degree shows a continuous downward trend, but has not yet fallen below the preset deviation threshold, and the forced path still exists. This is an early warning state of potential risk.

[0182] Explicit structural deviation: The matching degree has fallen below the preset threshold, or the forced path is missing. At this point, structural deviation has actually occurred, and the backup model needs to be triggered immediately.

[0183] In pre-failure mode, the system performs pre-takeover operations, including: Pre-loading the standby model: Loading the standby model into memory, completing model initialization, and reducing cold start latency during subsequent switchover. Pre-synchronizing state data: Pre-synchronizing data such as the current inference context, instance graph state, and key security commitments of the primary model to the standby model's cache. Establishing a monitoring channel: Establishing a pre-connection between the standby model and the verification module to ensure that constraint injection and response generation can begin immediately upon triggering formal takeover.

[0184] In one specific embodiment of this application, such as Figure 3 As shown, after the structural deviation determination result is generated, the constraint transformation and injection stage begins. If the determination result is no deviation, state nodes, risk event nodes, and safety measure nodes are extracted from the instance graph. Corresponding temporal possibility constraints, mandatory constraints, elimination constraints, and permissive constraints are generated according to four mapping rules, and a composite constraint chain is formed through logical conjunction. If the determination result is a deviation, only high-confidence state entities are extracted to generate state assertion constraints. All constraints are encoded into a structured constraint markup language (including invariant markup segments, dependency markup segments, and chain markup segments) and injected at the beginning of the system prompt words in the backup model.

[0185] The backup model generates a response under constraints, which is then validated and corrected. First, the structured segments (actions, states, decisions) output by the backup model are parsed. Then, a logic solver verifies the consistency between state transitions and action execution, while semantic similarity verifies the consistency between natural language and structured segments. If both verifications pass, a safe response is output; if verification fails, the violated constraint identifier is extracted, a correction prompt is generated and appended to the dialogue history, triggering a retry. When the number of retries reaches the maximum (e.g., 3 times) and still fails, a cascading switch to a third backup model or a rule-based expert system is triggered, and the main model's output is marked as an unreliable sample.

[0186] Meanwhile, the time series of matching scores is monitored in real time. When the matching score difference of three consecutive sampling points is detected to be negative and the cumulative decrease exceeds the preset ratio coefficient, it is determined to enter the pre-failure mode and perform pre-takeover operations (pre-loading the backup model, synchronizing status data, and establishing a monitoring channel) to prepare for seamless switching in case of subsequent explicit structural deviations.

[0187] According to another aspect of the embodiments of this application, an electronic device is also provided for implementing the above-described risk quantification processing method for AI large-scale models in engineering safety production. This electronic device may be... Figure 4 The terminal device or server shown. This embodiment uses this electronic device as an example of a server. Figure 4 As shown, the electronic device includes a memory 402, a processor 404, and a transmission device 406. The memory 402 stores a computer program, and the processor 404 is configured to execute the steps of any of the above method embodiments through the computer program.

[0188] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0189] Optionally, the transmission device 406 is used to receive or send data via a network. Specific examples of the network described above may include wired and wireless networks. In one example, the transmission device 406 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 406 is a Radio Frequency (RF) module used to communicate with the Internet wirelessly. Furthermore, the electronic device also includes a display 408 and a connection bus 410, which connects the various module components within the electronic device.

[0190] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.< / action> < / state> < / decision> < / state> < / action>

Claims

1. A method for risk quantification processing of AI large-scale models in engineering safety production, characterized in that, include: S1, Obtain a domain causal template library constructed based on preset engineering safety standards, wherein the domain causal template library includes multiple standardized causal chain structure templates; S2, real-time parsing of the reasoning text generated by the main model, constructing an instance graph reflecting the current security reasoning logic; S3, perform structural matching between the instance graph and the templates in the domain causal template library, and determine whether there is structural deviation in the inference chain of the main model based on the matching result. If so, trigger the backup model to take over. S4, extract key security commitments from the inference context of the main model or the instance graph, convert the key security commitments into formal logical constraints, and inject the formal logical constraints into the backup model; S5, verify the response generated by the backup model to determine whether it satisfies the formal logic constraints.

2. The risk quantification method for AI large-scale models in engineering safety production according to claim 1, characterized in that, S1 includes: S11, perform chapter structure analysis on the preset engineering safety standard text, identify the reference relationship based on clause number and title level, extract the hazard identification chapter, risk assessment chapter and control measures chapter, and combine the hazard identification chapter, the risk assessment chapter and the control measures chapter into a standardized chapter sequence; S12, Based on the trigger word library and dependency syntax pattern in the field of engineering safety, extract candidate causal triples from the standardized chapter sequence. The trigger word library includes inducing words, inhibiting words, preconditioning words and enabling words. S13, based on the preset security rule ontology, candidate causal triples including mandatory modal words are marked as hard constraint edges, candidate causal triples including advisory modal words are marked as soft constraint edges, and conflict resolution is performed on the candidate causal triples. S14, the candidate causal triples after conflict resolution are transformed into a directed acyclic graph structure with node type labels and edge relationship labels. The node type labels include hazard source, risk event, safety measure, consequence and state. The edge relationship labels include inducement, inhibition, preconditioning and enabling.

3. The risk quantification method for AI large-scale models in engineering safety production according to claim 2, characterized in that, The conflict resolution of the candidate causal triples includes: For cases where there are hard constraint edges and soft constraint edges between the same head entity and the same tail entity, remove the soft constraint edges and retain the hard constraint edges. If there are two hard constraint edges between the same head entity and the same tail entity, and the relationship types of the two hard constraint edges are opposite, the hard constraint edge with the higher validity level is retained according to the preset standard validity level.

4. The risk quantification method for AI large-scale models in engineering safety production according to claim 1, characterized in that, S2 include: S21, Identify hazard source entities, risk event entities, safety measure entities, consequence entities, and status entities from the reasoning text, and mark the corresponding node type tags; S22, based on a pre-defined relation type dictionary, extracts the inducing relations, inhibiting relations, preconditioning relations and enabling relations between entities through dependency parsing, and constructs an initial instance graph edge set.

5. The risk quantification method for AI large-scale models in engineering safety production according to claim 1, characterized in that, S3 include: S31, In the candidate matching pair generation stage, strong type constraints are implemented based on node type tags; S32, In the matching search phase, direction-sensitive constraints are implemented based on edge relationship labels; S33, In the matching verification stage, identify the shortest path from the risk event node type to the safety measure node type in the causal chain structure template, and detect whether the shortest path is marked as a mandatory path when the template is constructed. The mandatory path is a causal chain that is referenced by the clause number in the preset engineering safety standard and must not be missing. If there is no sub-path isomorphic to the mandatory path in the instance graph, the structural deviation is determined to be valid, the matching calculation is terminated and zero matching degree is output.

6. The risk quantification method for AI large-scale models in engineering safety production according to claim 1, characterized in that, S4 include: S41, Receive the structural deviation determination result of S3; S42, if the structural deviation determination result indicates that there is no structural deviation, then extract the state node, risk event node, safety measure node and consequence node from the instance diagram, and convert them based on the preset mapping rules from cause-effect graph to logical expression; S43, if the structural deviation determination result indicates that there is a structural deviation, then select entities whose node type is marked as state from the instance graph, and take entities whose edge confidence is higher than the preset confidence threshold as key security commitments, convert them into state assertion constraints, and mark them as low confidence migration modes.

7. The risk quantification method for AI large-scale models in engineering safety production according to claim 6, characterized in that, The mapping rules include: The pattern mapping of state nodes connected to risk event nodes via enable edges is transformed into temporal probability constraints. The pattern mapping of risk event nodes connected to safety measure nodes via pre-edges is transformed into mandatory constraints. The pattern mapping of safety measure nodes connected to risk event nodes via suppression edges is transformed into remedial constraints. The pattern mapping of state nodes connected to safety measure nodes via pre-edges is transformed into permissive constraints. The constraints obtained by the mapping are logically combined to obtain a composite constraint chain.

8. The risk quantification method for AI large-scale models in engineering safety production according to claim 7, characterized in that, The probability constraint indicates that if the state is met, a future risk event may occur; the mandatory constraint indicates that if a risk event exists, the safety measures must be implemented; the elimination constraint indicates that if the safety measures are implemented, the risk event is eliminated; and the permissive constraint indicates that the state is a prerequisite for the safety measures.

9. The risk quantification method for AI large-scale models in engineering safety production according to claim 7, characterized in that, S5 include: S51, the response generated by the backup model is parsed into structured segments and natural language segments; the structured segments are generated by the backup model according to a preset output format; S52, extract the state transition sequence and action execution sequence from the structured segment, convert the formal logic constraints into the standard input format of the SMT solver, and call the SMT solver to verify whether the state transition sequence satisfies the invariant constraints and dependencies.

10. The risk quantification method for AI large-scale models in engineering safety production according to claim 9, characterized in that, The method further includes: S53, extract action keywords and state keywords from the natural language segment, calculate the first word vector of the action keywords, calculate the second word vector of the state keywords, calculate the third word vector of the corresponding action and state in the structured segment, calculate the first cosine similarity between the first word vector and the third word vector, calculate the second cosine similarity between the second word vector and the third word vector, and if the first cosine similarity or the second cosine similarity is lower than a preset similarity threshold, the verification is determined to fail.

Images