Emergency process generation method and device based on large model, equipment and medium

Abstract

The invention discloses an emergency process generation method and device based on a large model, equipment and a medium, and relates to application of the field of artificial intelligence in the fields of business architecture and financial science and technology, and the method comprises the steps: carrying out the semantic understanding and structured analysis of a natural language instruction through calling a large language model, and obtaining a structured intention description result; performing knowledge retrieval and context construction on the structured intention description result to obtain a real-time state snapshot and a structured knowledge packet of the system environment; filling the structured intention description result, the real-time state snapshot and the structured knowledge packet into a preset cue word template, and calling a large language model to construct an emergency operation sequence; and performing dual static verification and dynamic verification on the emergency operation sequence, and returning the verified emergency operation sequence as an emergency process response to the user side. From user natural language input to executable process output, full-process automatic connection is realized, manual intervention is reduced, and the timeliness and standardization level of emergency response are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of artificial intelligence, and is suitable for the financial technology scene, and in particular relates to an emergency process generation method and device based on a large model, equipment and medium. BACKGROUND

[0002] With the complexity of enterprise IT system architecture and the close dependence of services, emergency disposal efficiency has become the key to business continuity, and the emergency process generation system has become a core operation and maintenance tool. The current mainstream solution is divided into two categories: one is the traditional manual solution, in which operation and maintenance personnel manually design the process according to static plans or experience, and the system only checks the permissions through built-in static rules and other basic constraints; the second is the modular and automated solution, in which operation and maintenance personnel combine and execute as needed, and the system supports the functions of time parameter scanning and parameter self-discovery to reduce some manual steps.

[0003] However, the existing emergency process generation system has obvious shortcomings: first, it has high dependence on manual operation, and the creation and scene adaptation of the process require manual experience support, which has high communication costs and is prone to introduce risks due to operational errors, and the flexibility in dealing with new faults is limited; second, the constraint strategy is rigid, and the fixed rules can only check hard constraints and cannot identify implicit problems such as resource conflicts, and the rule library is difficult to maintain and adapt to rapid iteration of service dependencies; third, the knowledge is not preserved, and the fault causes and solutions in drills and emergencies are difficult to integrate and retain, similar problems occur repeatedly, and the operation and maintenance efficiency is reduced. SUMMARY

[0004] Therefore, the present application provides an emergency process generation method and device based on a large model to solve the problems of high dependence on manual operation, rigid constraint strategy, and insufficient knowledge preservation in the existing emergency process generation system, which leads to low process generation efficiency, high risk, and poor adaptability.

[0005] In a first aspect, an emergency process generation method based on a large model is provided, comprising:

[0006] receiving a natural language instruction input by a user end, performing semantic understanding and structured analysis on the natural language instruction by calling a large language model, and obtaining a structured intent description result;

[0007] performing knowledge retrieval and context construction on the structured intent description result, obtaining a real-time state snapshot of the system environment and a structured knowledge package;

[0008] aggregating the structured intent description result, the real-time state snapshot, and the structured knowledge package, filling them into a preset prompt word template, performing emergency operation serialization construction by calling a large language model, and outputting an emergency operation sequence;

[0009] double static verification is performed on the emergency operation sequence based on a preset verification engine, a dependency analysis report and a conflict detection report are generated, and the dependency analysis report and the conflict detection report are integrated into a comprehensive verification report;

[0010] According to the comprehensive verification report, dynamic verification is performed on the emergency operation sequence, if the dynamic verification fails, structured modification instructions are generated according to the comprehensive verification report, the structured modification instructions are re-input into the large language model, iterative modification is performed on the emergency operation sequence, and the iterative modified emergency operation sequence passes the dynamic verification.

[0011] The emergency operation sequence that passes the dynamic verification is returned to the user terminal as an emergency process response matched with the natural language instruction of the user.

[0012] In a second aspect, the embodiments of the present application also provide an emergency process generation device based on a large model, comprising:

[0013] A natural language instruction analysis module is configured to receive a natural language instruction input by a user terminal, perform semantic understanding and structured analysis on the natural language instruction by calling a large language model, and obtain a structured intention description result.

[0014] A retrieval and integration module is configured to perform knowledge retrieval and context construction on the structured intention description result, obtain a real-time state snapshot of a system environment and a structured knowledge package.

[0015] An emergency operation sequence construction module is configured to aggregate the structured intention description result, the real-time state snapshot and the structured knowledge package, fill in a preset prompt word template, perform emergency operation sequence construction by calling a large language model, and output an emergency operation sequence.

[0016] A static verification module is configured to perform double static verification on the emergency operation sequence based on a preset verification engine, generate a dependency analysis report and a conflict detection report, and integrate the dependency analysis report and the conflict detection report into a comprehensive verification report.

[0017] A dynamic verification module is configured to perform dynamic verification on the emergency operation sequence according to the comprehensive verification report, if the dynamic verification fails, generate structured modification instructions according to the comprehensive verification report, re-input the structured modification instructions into the large language model, perform iterative modification on the emergency operation sequence, and the iterative modified emergency operation sequence passes the dynamic verification.

[0018] An emergency process response module is configured to return the emergency operation sequence that passes the dynamic verification to the user terminal as an emergency process response matched with the natural language instruction of the user.

[0019] In a third aspect, an electronic device is provided, and the electronic device comprises:

[0020] at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the method for generating an emergency process based on a large model according to any one of the embodiments of the present application.

[0021] In a fourth aspect, a computer readable storage medium is provided, and the computer readable storage medium stores computer instructions for enabling a processor to implement the method for generating an emergency process based on a large model according to any one of the embodiments of the present application when the processor executes the computer instructions.

[0022] According to the embodiments of the present application, the large language model is used to convert the unstructured natural language instructions into structured intents, without the need for the user to master professional terms, while avoiding the bias of manual conversion, and realizing the accurate connection from the fuzzy demand to the explicit benchmark. The knowledge retrieval constructs the context of "real-time state snapshot + structured knowledge package", so that the generated emergency process not only fits the current system running state, but also refers to historical experience and field rules, avoiding the empty process that deviates from reality. The double static verification pre-filters obvious logical defects, reduces the invalid resource consumption of dynamic verification, and through the closed loop of verification and iterative correction, quickly optimizes the process, shortens the cycle from demand input to available process output, and dynamically verifies the real execution scene in the simulation environment, combined with the directional optimization of the structured correction instruction, so that the final output process not only meets the logical compliance, but also can be executed in the real system, reducing the risk of emergency operation failure. From the natural language input of the user to the executable process output, the whole link is automatically connected, reducing manual intervention, and improving the timeliness and standardization level of emergency response.

[0023] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present application, nor is it used to limit the scope of the present application. Other features of the present application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0025] Figure 1 is a flowchart of a method for generating an emergency process based on a large model according to an embodiment of the present application;

[0026] Figure 2 is a flowchart of another large model-based emergency process generation method according to Embodiment Two of the present application;

[0027] Figure 3 is a structural schematic diagram of a large model-based emergency process generation device according to Embodiment Three of the present application;

[0028] Figure 4 is a structural schematic diagram of an electronic device for implementing a large model-based emergency process generation method according to an embodiment of the present application. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first", "second", and the like in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0031] Embodiment One

[0032] Figure 1 A flowchart of a large model-based emergency process generation method according to Embodiment One of the present application is provided, and this embodiment can be applicable to the case when an enterprise IT system has service failures, resource abnormalities, and other emergency events, and operation and maintenance personnel need to quickly generate executable emergency processes. The method can be executed by a large model-based emergency process generation device, which can be realized in the form of hardware and / or software, and the device can be configured in an enterprise emergency process generation system or an IT operation and maintenance management platform. As shown in the figure, the method comprises: Figure 1

[0033] ​S110, receive a natural language instruction input by a user terminal, and obtain a structured intent description result by calling a large language model to perform semantic understanding and structural analysis on the natural language instruction.

[0034] The natural language instruction is an unstructured emergency demand expression input by a user through a client, and has the characteristics of colloquialism and flexible expression but is difficult for a machine to directly analyze. The large language model in this embodiment specifically refers to a pre-trained language model fine-tuned for an emergency scene, and has the directional ability of "keyword recognition-semantic mapping-structured output", rather than a general large model. The structured intent description result is demand standardization data presented in a machine-readable format such as JSON / XML, and the core field is strongly bound to the subsequent steps. S110 is a demand entry conversion layer of the whole process, which solves the problem that unstructured user demand cannot directly drive the machine to process. After receiving the original natural language instruction of the user, the semantic understanding ability of the large language model is used to strip redundant expressions and extract core demand elements, and finally output structured data. The value lies in establishing a connection bridge between user demand and subsequent technical processes, ensuring that the subsequent steps can be based on clear and unified demand benchmarks, and avoiding process deviation caused by ambiguous demand expression.

[0035] S120, knowledge retrieval and context construction are performed on the structured intent description result, and a real-time state snapshot and a structured knowledge package of a system environment are obtained.

[0036] Knowledge retrieval and context construction refer to a process of obtaining information required for process generation from external data sources guided by the structured intent description result, and integrating the information into a unified context. The real-time state snapshot is a data set reflecting the real situation of the current system environment, including the running state information of key entities of the system. The structured knowledge package is a standardized collection of various knowledge required for emergency process generation, which provides knowledge support for subsequent sequence construction. The structured intent description result is used as a retrieval anchor point to obtain the current system state and domain knowledge through knowledge retrieval, and the two are integrated into a context that can be directly used by the subsequent steps.

[0037] S130, aggregate the structured intent description result, the real-time state snapshot, and the structured knowledge package, fill in a preset prompt word template, and output an emergency operation sequence by calling a large language model to perform emergency operation sequence construction.

[0038] The preset prompt word template refers to a fixed format framework designed to guide the large language model to generate standardized output, including preset input fields related to process generation. The emergency operation sequence construction refers to the process of organizing scattered emergency operation elements into ordered steps based on the structured intent of the input, real-time state snapshot, and structured knowledge package. The emergency operation sequence is a structured collection containing ordered emergency operation steps, which is the preliminary output form of the emergency process. S130, as the core layer of the whole process generation, solves the problem of how to convert requirements and knowledge into ordered operation steps. First, fill in the structured intent, real-time state snapshot, and structured knowledge package into the preset prompt word template to form an input that the large language model can understand. Then, through the reasoning ability of the large language model, the input information is converted into an ordered emergency operation sequence. The value lies in converting requirements and information into executable step prototypes, providing specific objects for subsequent verification steps, and is the key conversion node from information to process.

[0039] S140, based on the preset verification engine, double static verification is performed on the emergency operation sequence to generate dependency analysis report and conflict detection report, and the dependency analysis report and conflict detection report are integrated into comprehensive verification report.

[0040] The preset verification engine refers to an independent functional module with specific verification logic built-in, used to check the compliance of the emergency operation sequence. Double static verification refers to non-running state logic check of the emergency operation sequence from two dimensions. Dependency analysis report and conflict detection report are two types of output documents of double static verification, which record different types of logical problems in the sequence; the comprehensive verification report is a summary document integrating the above two types of reports, providing a problem list for subsequent verification and correction.

[0041] S150, according to the comprehensive verification report, dynamic verification is performed on the emergency operation sequence, if the dynamic verification fails, structured correction instructions are generated according to the comprehensive verification report, the structured correction instructions are re-input to the large language model, and iterative correction is performed on the emergency operation sequence until the iterative corrected emergency operation sequence passes the dynamic verification.

[0042] Dynamic verification refers to a verification method that simulates the actual execution process of the emergency operation sequence in a simulated real system environment. The structured correction instruction is a standardized instruction generated based on the comprehensive verification report, containing problem description and correction requirements. Iterative correction improves the emergency operation sequence through a cycle process of "dynamic verification-problem identification-instruction correction-sequence optimization". The value lies in verifying the actual operability of the sequence through the simulation execution scenario, ensuring that the final output sequence not only complies with the logic, but also can be executed in the real environment.

[0043] S160, return the emergency operation sequence verified by the dynamic verification to the user terminal as an emergency process response matched with the natural language instruction of the user.

[0044] The emergency operation sequence verified by the dynamic verification is returned to the user terminal as an emergency process response matched with the original natural language instruction of the user, which has the value of delivering the emergency process that is double-verified and has actual executability to the user, directly meeting the emergency processing needs of the user, and is the final value embodiment of the whole method.

[0045] In the embodiment of the application, the unstructured natural language instruction is converted into a structured intent by a large language model, without the need for the user to master professional terms, while avoiding the bias of manual conversion, and realizing accurate connection from fuzzy demand to clear benchmark; the context of "real-time state snapshot + structured knowledge package" is constructed by knowledge retrieval, so that the generated emergency process not only fits the current system running state, but also refers to historical experience and field rules, avoiding empty process that is out of touch with reality; double static verification pre-filters obvious logical defects, reducing invalid resource consumption of dynamic verification; through the closed loop of verification and iterative correction, the process is quickly optimized, and the period from demand input to available process output is shortened; dynamic verification reproduces the real execution scene in the simulation environment, and combined with the directional optimization of the structured correction instruction, the final output process not only complies with the logic, but also can be executed in the real system, reducing the risk of emergency operation failure. From the natural language input of the user to the executable process output, the whole link is automatically connected, reducing manual intervention, and improving the timeliness and standardization level of emergency response.

[0046] Embodiment two

[0047] Figure 2 Another flowchart of the emergency process generation method based on a large model provided by the second embodiment of the application is shown in FIG. 2, which is based on the first embodiment and is refined, specifically as shown in FIG. 2, the method comprises: Figure 2

[0048] S210, receiving the natural language instruction input by the user terminal, and inputting the natural language instruction into a large language model.

[0049] S220, identifying a result class keyword in the natural language instruction by the large language model, and mapping the result class keyword into a user intent.

[0050] ​The result class keyword refers to a target-oriented word in the natural language instruction, such as "restore service", "solve lag", "clean up disk", "restart log service", and the like, which directly points to the ultimate goal of the emergency operation. The user intent is a unified target expression obtained after standardizing mapping of the result class keyword, for example, the result class keywords "restore log write function" and "solve log problem caused by full disk" are uniformly mapped to the user intent "restore normal operation of master database log service". The large language model strips off the final result concerned by the user from the natural language instruction through the keyword recognition rule adapted to the domain, and converts the scattered result expression into a standardized user intent through the preset "keyword-intent mapping table".

[0051] S230, identifying the fault class keyword in the natural language instruction through the large language model, and matching with the pre-defined emergency scene library to determine the emergency scene type.

[0052] The fault class keyword refers to a word in the natural language instruction describing abnormal conditions of the system, such as "master database full disk", "log write failure", "service downtime", "too high connection number", and the like, which reflects the trigger cause of the emergency event. The pre-defined emergency scene library is a database storing various types of standardized emergency event types, each scene type containing a set of typical fault keywords, such as "full disk + log write failure" corresponding to the master database storage abnormal scene, having the function of "keyword matching -> scene positioning". The emergency scene type is a standardized scene identifier matched from the emergency scene library, such as "master database storage abnormal scene", "service performance overload scene", "network connection fault scene", and the like. The large language model first identifies the fault class keyword in the instruction, and then matches the keyword with the set of typical fault keywords of each scene in the emergency scene library according to the similarity, and finally determines the unique emergency scene type, which has the value of providing clear scene dimension constraints for knowledge retrieval, and ensuring that the knowledge retrieved subsequently is the same scene adaptation content.

[0053] S240, identifying the behavior class keyword in the natural language instruction through the large language model, and mapping the behavior class keyword to an emergency operation step.

[0054] The behavior class keyword refers to a specific operation action vocabulary mentioned by the user in the natural language instruction, such as "cleaning the disk", "restarting the service", "switching the slave library", "backing up the data", etc., reflecting the operation direction that the user thinks may solve the problem. The emergency operation step is an operation expression obtained by standardizing the behavior class keyword, such as "deleting old logs in the master library disk" and "cleaning the redundant storage of the master library". The large language model extracts the operation action suggested by the user from the instruction through action semantic recognition, and then removes the colloquial expression and supplements the operation object to convert it into a standardized emergency operation step. Its value lies in providing an initial operation list for subsequent emergency operation serialization construction, reducing the reasoning cost of the model from zero to build operation steps.

[0055] In S250, the large language model identifies the entity class keyword in the natural language instruction, and constructs a key entity list according to the entity class keyword, wherein the key entity list contains the entity identifier of the key entity corresponding to the emergency operation step.

[0056] The entity class keyword refers to the specific object vocabulary involved in the natural language instruction, such as "master library", "slave library", "log service", "disk", etc., which is the object of the emergency operation. The key entity list is a structured list formed by integrating all entity class keywords and supplementing entity identifiers. The entity identifier refers to the unique identification code assigned to each key entity, which is used to associate specific entity resources in the subsequent system environment. The large language model first identifies the entity class keyword in the instruction, and then supplements a unique entity identifier for each entity through a pre-set "entity-identifier mapping rule", and finally constructs a key entity list. Its value lies in clearly defining the specific object of the subsequent real-time state snapshot collection, ensuring that the collected state data can be accurately associated with the object of the emergency operation.

[0057] In S260, the large language model converts the user intent, emergency scenario type, emergency operation step, and key entity list recognized into a structured data format, and obtains the structured intent description result.

[0058] The structured data format is a unified data format that meets the machine-readable specification, such as JSON format. The large language model integrates and encapsulates the user intent, emergency scenario type, emergency operation step, and key entity list recognized according to the pre-set structured data format template to form a standardized input that can be directly read, avoiding the problem that the subsequent steps cannot be normally connected due to the chaotic format of the parsed results, and ensuring the smoothness and consistency of data transmission in the whole process.

[0059] The embodiment converts the ambiguous natural language instruction into the structured intent with clear elements by classifying the recognition result, fault, behavior, and entity class keyword, avoids analysis deviation; the user intent is clear, the target is oriented, the emergency scene type provides the knowledge retrieval dimension, the key entity list locks the state collection object, and ensures that the subsequent steps are "targeted, within the scope, and based on evidence"; the emergency operation steps are refined in advance as initial materials, the reasoning burden of model generation from zero is reduced during subsequent sequence construction, and the process generation efficiency is improved; the analysis is expanded based on the keywords mentioned by the user, and the generated structured intent is highly consistent with the original user demand.

[0060] S270, knowledge retrieval and context construction are performed on the structured intent description result, and a real-time state snapshot and a structured knowledge package of a system environment are obtained.

[0061] Optionally, the knowledge retrieval and context construction on the structured intent description result to obtain the real-time state snapshot and the structured knowledge package of the system environment can include:

[0062] The configuration management database interface is called to process each entity identifier in the key entity list to obtain the static attribute of each key entity;

[0063] The monitoring system interface is called to process each entity identifier in the key entity list to obtain the dynamic running state of each key entity;

[0064] The static attribute and the dynamic running state of each key entity are integrated into a real-time state snapshot;

[0065] According to the emergency operation steps in the structured intent description result, a unique emergency operation tool is matched in a modular tool library, and tool metadata corresponding to the emergency operation tool is extracted; wherein the tool metadata includes preconditions and postconditions required for the execution of the emergency operation steps;

[0066] All entity identifiers and emergency scene types are used as retrieval conditions, at least one historical alternative scheme with complete entity identifier coverage and consistent emergency scene is screened out from a historical process library, and historical step sequences in each historical alternative scheme are extracted as a historical information set;

[0067] Logical constraints and operation execution rules matching the emergency scene type are extracted from a pre-defined rule library, and the tool metadata, the historical information set, the logical constraints and the operation execution rules are integrated into a structured knowledge package;

[0068] The historical alternative solution is a complete historical step sequence that historically handles the same type of emergency scene, which is formed by combining historical emergency operation steps arranged in execution order; and the pre-defined rule library stores logical constraints and operation execution rules corresponding to each emergency scene type.

[0069] The configuration management database interface is a standardized data interaction interface connected to the configuration management database, supporting the query of configuration information of the corresponding entity through entity identification. Static attributes are inherent configuration information of key entities that do not change with the running state, such as server IP address, database storage capacity, service deployment path, hardware model, etc. The monitoring system interface is a standardized data interaction interface connected to the real-time monitoring system, supporting real-time pulling of running data by entity identification. Dynamic running state refers to real-time running indicators of key entities that change over time, such as server CPU usage, database disk occupancy, service request response time, connection number, etc. Real-time state snapshot is a standardized data collection integrating the "static attributes + dynamic running state" of key entities with entity identification as the unified index. Aligning static attributes and dynamic states by entity identification, a structured snapshot is formed, enabling subsequent large models and verification engines to quickly obtain the inherent attributes and current state of the entity through the same data collection. The modular tool library is a database storing executable tools classified by emergency operation type, with each tool binding a unique applicable operation step and entity type, such as: disk cleaning tool binding cleaning disk step, applicable to storage class entity. Emergency operation tool refers to a program or script in the modular tool library that can be directly called to execute a specific emergency operation step, such as "log cleaning script" and "service restart tool".

[0070] The historical flow library refers to a database storing complete flow solutions that successfully handled emergency events in history, each solution containing information such as "emergency scene type, involved entity identification, historical step sequence, execution result". The historical alternative solution refers to a historical flow selected from the historical flow library that highly adapts to the current scene, with the selection criteria being: the entities involved in the historical solution include all entities in the current key entity list, and the emergency scene is consistent. The historical information set is a collection of historical step sequences integrated from all historical alternative solutions. The "entity identification + emergency scene" double condition filtering ensures that the selected historical alternative solution highly adapts to the current demand. The pre-defined rule library refers to a database storing operation logical constraints and execution specifications by emergency scene type. Logical constraints and operation execution rules are the normative requirements in the rule library that match the current scene and are used to constrain emergency operation logic, which can be divided into prohibited rules and mandatory rules. The structured knowledge package is a standardized knowledge collection integrating "tool metadata, historical information set, logical constraints and operation execution rules".

[0071] The embodiment reflects the entity status comprehensively through the real-time status snapshot integrated by "static + dynamic" attributes, avoids the process generation from deviating from the actual system environment; the unique matching mechanism of the modular tool library ensures that each operation step has a corresponding executable tool, and the tool metadata provides clear execution constraints; the historical information set reuses successful experience, the rule library provides compliance constraints, and the generated sequence is both in line with practical logic and does not violate operation specifications; the standardized format of the real-time status snapshot and the structured knowledge package eliminates the need for subsequent heterogeneous data analysis, improving the efficiency of the whole process.

[0072] S280, aggregate the structured intent description result, the real-time status snapshot, and the structured knowledge package, fill in the preset prompt word template, and output the emergency operation sequence by calling a large language model for emergency operation serialization construction.

[0073] Further, aggregating the structured intent description result, the real-time status snapshot, and the structured knowledge package, filling in the preset prompt word template, and outputting the emergency operation sequence by calling a large language model for emergency operation serialization construction can include:

[0074] extracting all entity identifiers and emergency operation steps from the structured intent description result and filling them into the associated entity set field and the to-be-executed operation field of the preset prompt word template;

[0075] extracting the dynamic running state of each entity from the real-time status snapshot and filling it into the entity current state field of the preset prompt word template;

[0076] extracting tool metadata and all historical step sequences from the structured knowledge package and filling them into the tool mapping field and the historical step sequence reference field of the preset prompt word template;

[0077] inputting the filled prompt word template into the large language model;

[0078] determining a unique execution order for each emergency operation step according to the prompt word template by the large language model, associating a corresponding key entity identifier for each emergency operation step based on the structured intent description result, and matching a corresponding current dynamic running state for the current entity identifier according to the binding relationship between the key entity identifier and the dynamic running state in the real-time status snapshot;

[0079] querying tool metadata corresponding to each emergency operation step, binding the preconditions and postconditions stored in the tool metadata with the key entity identifier and the dynamic running state, and integrating to form a structured emergency operation sequence containing the emergency operation step execution order, the associated entity identifier, the dynamic running state, the emergency operation tool, the precondition, and the postcondition, and outputting the emergency operation sequence.

[0080] The associated entity set field is a special field in the preset prompt word template for collecting key entity identifiers, and functions to explicitly indicate the object range of the emergency operation to the large language model. The operation to be performed field is a special field in the preset prompt word template for listing emergency operation steps, and functions to provide the large language model with an initial operation material list. All entity identifiers and emergency operation steps are accurately extracted from the structured intent description result and filled into the corresponding fields of the template, so as to avoid omission of core operation objects or steps by the large model during reasoning, ensure that the sequence generated by the model always revolves around the analyzed user demand, and reduce the information retrieval cost during reasoning by field classification to quickly locate "what to operate" and "who to operate". The entity current state field is a special field in the preset prompt word template for storing the dynamic running state of each entity, and functions to provide the large language model with real-time running basis of the entity. The tool mapping field is a special field in the preset prompt word template for associating "emergency operation steps-emergency operation tools-tool metadata", and functions to provide the large language model with operation tools and constraint basis. The special field in the preset prompt word template for storing historical information set functions to provide the large language model with operation sequence reference cases of similar scenarios. The essence is to integrate knowledge-level constraints and experience into the template to provide the large model with knowledge guidance of "operation tools + sequence logic".

[0081] The reasoning logic of the large model has three layers: ① sequence determination: reference the successful cases in the historical step sequence reference field in the template, and determine the step execution priority in combination with the user intent; ② entity association: based on the established "step-entity identifier" correspondence, bind a special key entity to each step; ③ state matching: through the entity identifier, associate the dynamic running state in the real-time state snapshot. The structured emergency operation sequence is the final output product, which is a standardized sequence with "steps as units and elements as fields", and each step contains "execution sequence, associated entity identifier, dynamic running state, emergency operation tool, precondition, and postcondition" six core elements. The essence is to convert the multi-dimensional binding information of the large model reasoning into a standardized sequence that can be directly verified and executed, realizing the final conversion of "information → process".

[0082] In this embodiment, the field constraint of the preset prompt word template forces the large model to reason within the framework of "demand-state-knowledge", avoiding output of non-standardized sequences with disordered elements and missing elements; the structured intent, real-time snapshot, and knowledge package are bound through the step-entity-identifier link, ensuring that each element in the sequence has a clear data source; the element field design of the structured emergency operation sequence enables direct field retrieval and comparison for precondition matching and state conflict detection, improving verification efficiency; in combination with the historical step sequence reference and real-time state reasoning sequence, the generated sequence not only conforms to the successful experience of similar scenarios, but also adapts to the dynamic present situation of the current system.

[0083] S290, double static verification is performed on the emergency operation sequence based on a preset verification engine, a dependency analysis report and a conflict detection report are generated, and the dependency analysis report and the conflict detection report are integrated into a comprehensive verification report.

[0084] Optionally, double static verification is performed on the initial emergency operation sequence based on a preset verification engine, a dependency analysis report can include:

[0085] The dynamic running states of the key entities are obtained from the real-time state snapshot, and the dynamic running states are recorded as initial states in a predefined blank condition pool to obtain an initial condition pool.

[0086] A current emergency operation step is obtained in sequence according to the execution order of the emergency operation steps in the emergency operation sequence, and a current precondition of the current emergency operation step is subjected to an accurate matching query in the initial condition pool.

[0087] If the current precondition of the current emergency operation step matches the initial condition pool successfully, a current postcondition of the current emergency operation step is stored in the initial condition pool, and the operation of obtaining a current emergency operation step in sequence according to the execution order of the emergency operation steps in the emergency operation sequence is returned.

[0088] If the current precondition of the current emergency operation step fails to match the initial condition pool, all alternative historical satisfaction steps matching the current precondition are searched for in the historical process library, and historical average confidence degrees of the alternative historical satisfaction steps are calculated.

[0089] Based on the logical constraints, operation execution rules in the structured knowledge package and the current emergency scene type of the current emergency operation step, a logical confidence degree of the current precondition is derived.

[0090] The historical average confidence degrees and the logical confidence degree are weighted to obtain a comprehensive confidence degree according to a preset weight, and a dependency level of the current precondition is obtained according to the comprehensive confidence degree and a preset confidence degree threshold.

[0091] If the dependency level satisfies a condition pool updating condition, a current postcondition of the current emergency operation step is stored in the initial condition pool, and the operation of obtaining a current emergency operation step in sequence according to the execution order of the emergency operation steps in the emergency operation sequence is returned.

[0092] If the dependency level does not satisfy the condition pool updating condition, the current emergency operation step corresponding to the current precondition is stored in a dependency exception set as a dependency exception operation step, and the operation of obtaining a current emergency operation step in sequence according to the execution order of the emergency operation steps in the emergency operation sequence is returned.

[0093] After processing all emergency operation steps in the emergency operation sequence, a dependency analysis report is generated by sorting out the dependency relationships between each dependency exception operation step in the dependency exception set.

[0094] The condition pool is a structured data container used to store the dynamic operating status of key entities and the post-conditions of emergency operation steps. Its core function is to serve as the benchmark data source for matching pre-conditions. The initial condition pool is constructed using the dynamic operating status of each key entity in the real-time status snapshot as the initial data, and it serves as the initial comparison benchmark for dependency verification. The current emergency operation step refers to the step to be verified extracted one by one according to the execution order of the emergency operation sequence, and it is the smallest processing unit for dependency verification. The exact match query refers to comparing the pre-conditions of the current step with the data in the condition pool to ensure complete consistency. When the pre-conditions of the current step match successfully, it means that the step has the prerequisites for execution. At this time, its post-conditions are stored in the condition pool to update the data. After the current step is executed, the post-conditions will become the new system state. The pre-conditions of subsequent steps need to be compared with the updated condition pool, thus forming a coherent logic of "verification-update-re-verification", which closely matches the state transmission process in actual execution.

[0095] The alternative historical steps to satisfy the current preconditions are historical emergency operation steps from the historical process library that have successfully satisfied the current preconditions. The historical average confidence level is the average success probability of all alternative historical steps to satisfy the current preconditions, reflecting the probability that the preconditions can be satisfied based on historical experience. When exact matching fails, alternative steps that can satisfy the current preconditions are found by searching the historical process library, and their historical average confidence level is calculated, avoiding mechanical verification that directly determines anomalies simply because the current state is not satisfied. Logical confidence level refers to the probability that the current preconditions can theoretically be satisfied based on logical constraints, operation execution rules, and the current emergency scenario type in the structured knowledge package, reflecting the feasibility at the domain rule level. Combining the content of the structured knowledge package, the logical confidence level of the preconditions is derived, forming a dual judgment dimension of experience and logic with the historical average confidence level: if historical data is insufficient, logical confidence level can provide a basis for judgment alone; if historical data is biased, logical confidence level can correct its judgment, improving the comprehensiveness of the judgment.

[0096] The overall confidence level is calculated by weighting the historical average confidence level and the logical confidence level according to preset weights. It is the final indicator for judging the likelihood of the preconditions being met. The confidence threshold is a predefined critical value used to classify dependency levels; different thresholds correspond to different dependency levels. The dependency level is the likelihood level of precondition satisfaction based on the overall confidence level and the confidence threshold, and it serves as the decision basis for subsequent condition pool updates. When the dependency level meets the condition pool update conditions, the current step's postcondition is stored in the condition pool and the loop continues, avoiding interruption of verification due to minor uncertainties. The dependency anomaly set is a structured set used to store emergency operation steps when the dependency level does not meet the condition pool update conditions. It records the identifier of each anomaly step, its corresponding preconditions, and the overall confidence level, serving as the foundational data for generating the dependency analysis report. When the dependency level is not met, the current step is stored in the dependency anomaly set and the loop continues, ensuring that all dependency anomalies are completely recorded without affecting the verification process of other steps. The dependency analysis report is a structured report based on a set of dependency anomalies, which outlines the "precondition-postcondition" relationships between each anomaly operation step. The report may include a list of anomaly steps, the cause of the anomaly in each step, the dependency chain between steps, and a severity rating. By analyzing the sources of preconditions for each step in the dependency anomaly set, the dependency chain is identified, avoiding the report from merely listing isolated anomalies but clearly defining "which anomalies are the root cause and which are derivative problems."

[0097] This embodiment employs a triple-judgment mechanism of "precise matching + historical confidence + logical confidence" to avoid the one-sidedness of single-dimensional verification, covering multiple scenarios such as "currently satisfied," "historically satisfied," and "logically satisfied." The dynamic update logic of the condition pool simulates the state transmission in actual execution, allowing continued verification in high-confidence scenarios, balancing rigor with adaptability to complex scenarios. The "abnormal steps + dependency chains" outlined in the dependency analysis report clarify the root cause and derivative relationships of problems, avoiding aimless corrections. The introduction of information from the historical process library and structured knowledge packages reduces the reasoning cost of judging the feasibility of preconditions from scratch, improving verification efficiency.

[0098] Furthermore, based on a preset verification engine, the emergency operation sequence undergoes dual static verification to generate a conflict detection report, which may include:

[0099] Starting with the dynamic operating status of each key entity recorded in real-time status snapshots, the execution process of each emergency operation step is simulated one by one according to the execution order of the emergency operation sequence, and a continuous state trajectory of each key entity for the entire simulated execution process is formed.

[0100] If any of the following conditions are met when reading the continuous state trajectory: there are mutually exclusive state requirements for the associated target key entity in the same emergency operation step; there is a logical conflict in the running state of the continuous state trajectory of the same target key entity; or the post-condition of the preceding emergency operation step is destroyed by the intermediate emergency operation step, resulting in the pre-condition of the subsequent emergency operation step being unable to match, then the severity of the matched conflict situation is rated according to the predefined conflict level.

[0101] A conflict detection report is generated based on the severity rating, the type of conflict, and all associated emergency response procedures.

[0102] Continuous state trajectories are time-based sequences recording the complete sequence of state changes for each critical entity, starting from its initial state in a real-time snapshot and proceeding through each simulated emergency operation step. Execution process simulation refers to the verification engine's non-real-world operational state deduction of the entity's state after each step's execution, based on the post-conditions and entity state change rules of the emergency operation steps. This simulation does not affect the real system environment. Mutually exclusive state requirements refer to two state demands imposed on the associated target critical entity by the same emergency operation step that cannot be simultaneously met. Logical conflicts in operational states are contradictory state changes occurring in the continuous state trajectory of the same target critical entity. For example, the main database state changes directly from "disk utilization 60% (after step 1)" to "disk utilization 95% (step 2 did not involve disk operations)," violating the logical rule that utilization should not surge when there are no disk write operations. Predefined conflict levels are grading standards based on the degree of impact of the conflict on the entire emergency process execution. For example, a high level is defined as causing all subsequent steps to fail, while a low level is defined as only causing localized state anomalies but not affecting the main process. Severity ratings are impact labels assigned to identified conflict situations based on predefined conflict levels, serving as the priority for subsequent conflict handling.

[0103] Intra-step mutual exclusion detection checks whether a single step makes mutual exclusion requests to the same entity, such as simultaneous restarts and runs; if so, a conflict is directly marked. Entity state logic detection checks whether the state trajectory of the same entity conforms to basic logical rules, such as sudden state changes when there is no operation, or a closed service suddenly receiving requests; if violated, a conflict is marked. Inter-step condition transitivity detection checks whether the post-conditions of a preceding step are violated by intermediate steps; for example, if the post-condition of a preceding step is "disk utilization < 60%", and an intermediate step writes a large amount of data causing the utilization to rise to 75%, the pre-condition of subsequent steps "< 70%" cannot be met; if so, a conflict is marked. The conflict detection report is a structured document that integrates conflict identification results. Its core content includes information such as "conflict type, associated emergency operation steps, involved key entities, severity rating, and conflict state trajectory fragments."

[0104] This embodiment covers three core conflict types: "intra-step mutual exclusion, entity state logic, and inter-step conditional propagation," filling the gaps left by analysis-based verification and ensuring the consistency of the emergency operation sequence. By simulating the execution process, state conflicts are exposed in advance, preventing them from being carried into the dynamic verification stage and improving the overall verification process efficiency. The conflict detection report's "type + location + rating + trajectory" information allows subsequent corrections to directly pinpoint the root cause of the problem, enabling targeted adjustments to operation parameters or sequences and avoiding aimless corrections. Eliminating state conflict risks in advance prevents system anomalies or process interruptions due to mutually exclusive states or logical contradictions during actual execution, improving the reliability of emergency operations.

[0105] S2100. Based on the comprehensive verification report, the emergency operation sequence is dynamically verified. If the dynamic verification fails, a structured correction instruction is generated based on the comprehensive verification report. The structured correction instruction is re-inputted into the large language model to iteratively correct the emergency operation sequence until the iteratively corrected emergency operation sequence passes the dynamic verification.

[0106] Optionally, based on the comprehensive verification report, the emergency operation sequence is dynamically verified. If the dynamic verification fails, a structured correction instruction is generated based on the comprehensive verification report, and the structured correction instruction is re-inputted into the large language model to iteratively correct the emergency operation sequence until the iteratively corrected emergency operation sequence passes the dynamic verification. This may include:

[0107] Based on the real-time state snapshot, a dynamic verification simulation environment consistent with the system environment is constructed, and the logical constraints, operation execution rules and tool metadata in the structured knowledge package are loaded as the basis for dynamic verification execution.

[0108] The emergency operation sequence is input into the dynamic verification simulation environment, and the actual execution process of each emergency operation step is simulated in the execution order.

[0109] If no dependent abnormal operation step or conflict situation in the comprehensive verification report is hit during the actual execution process, and all emergency operation steps can be executed normally and achieve the user's intention, then the dynamic verification is deemed to be passed.

[0110] If any dependency anomaly or conflict is encountered during the actual execution process, the dynamic verification is deemed to have failed.

[0111] When dynamic verification fails, extract the dependent abnormal operation steps, conflict type, severity rating and related entity identifier from the comprehensive verification report, and generate correction instruction elements in a preset structured format.

[0112] Based on the aforementioned correction instruction elements, a structured correction instruction is constructed. The structured correction instruction, along with the structured intent description result, real-time status snapshot, and structured knowledge package, is then filled into a preset prompt word template and input again into the large language model, triggering the large language model to perform targeted iterative corrections on the emergency operation sequence.

[0113] The iteratively corrected emergency operation sequence is then input into the dynamic verification simulation environment for repeated dynamic verification until the iteratively corrected emergency operation sequence passes the dynamic verification.

[0114] The dynamic verification simulation environment is a virtual simulation environment built on real-time state snapshots, completely consistent with the real system environment. It is used to simulate the actual execution process of emergency operation sequences without affecting the operation of the real system. The execution basis of dynamic verification refers to the core constraint information related to the execution of emergency procedures in the structured knowledge package, including logical constraints, operation execution rules, and tool metadata, which are used to standardize the operation execution logic in the simulation environment. On the one hand, the static attributes and initial dynamic states of entities are replicated based on real-time state snapshots to ensure that the simulation environment is consistent with the starting point of the real system; on the other hand, the rules and tool metadata in the structured knowledge package are loaded to ensure that the operation constraints during simulation are completely consistent with the actual execution. The execution order of the emergency operation sequence is strictly followed, and the actual execution of the operation is simulated step by step in the simulation environment. The purpose is to expose problems that static verification cannot find and ensure that the verification results are close to the actual execution effect. Verification must be passed simultaneously if three conditions are met: ① No dependency anomalies or conflicts in the comprehensive verification report are hit, indicating that the problems found by static verification have been resolved; ② All emergency operation steps can be executed normally; ③ The user's intention is achieved. The three conditions are progressive, ensuring that the process is free of anomalies and that the process meets the user's core needs. If any dependency exception or conflict occurs during the simulation execution, the simulation will fail.

[0115] The correction instruction elements refer to the core data units extracted from the comprehensive verification report used to construct structured correction instructions. These include dependent abnormal operation steps, conflict type, severity rating, and associated entity identifiers, and are the core targets of the correction instructions. Structured correction instructions are standardized instructions built upon these correction instruction elements, containing "problem description - correction requirements - reference basis." For example, "Problem: Step 3 violates the postcondition of Step 2; Correction requirements: Adjust the execution parameters of Step 3 or adjust the step order; Reference basis: Operation execution rules for abnormal scenarios stored in the main library of the structured knowledge package." The iteratively corrected emergency operation sequence is then input back into the dynamic verification simulation environment, repeating the "simulation execution - result judgment" process. If it still fails, the correction instruction elements and structured correction instructions are updated, and iteration continues, forming a closed-loop control of "problem discovery - targeted correction - effect verification." This gradually eliminates all anomalies at both the static and dynamic levels, ultimately outputting an emergency operation sequence that can be stably executed in the real system and achieves the user's intent.

[0116] In this embodiment, the dynamic verification simulation environment is consistent with the real system and loaded with standardized execution criteria to ensure that the simulated execution process closely resembles reality. Based on the dual standards of "no anomalies + achieving intent," it ensures that the process is free of logical and operational errors while also meeting the core user needs. The structured correction instructions focus on core issues and synchronize the complete context, ensuring that the large model correction is not blind or deviates from the requirements. Through the iterative closed loop of "verification-correction-re-verification," anomalies at both the static and dynamic levels are continuously eliminated, ensuring that the final output emergency operation sequence has extremely high reliability and feasibility.

[0117] S2110. The emergency operation sequence that has passed dynamic verification is returned to the user terminal as an emergency process response that matches the user's natural language command.

[0118] This invention, through the refinement of the overall solution, transforms unstructured requirements into clearly defined structured intentions, laying the foundation for precise process generation; integrates real-time system status and multi-source knowledge to provide practical information support for process generation; generates structured operation sequences with clear execution order and complete elements, ensuring sequence standardization; employs dual static verification to pre-filter dependency anomalies and state conflicts, improving verification efficiency; and utilizes high-fidelity dynamic verification and targeted iterative correction to ensure the actual executability and reliability of the process. A complete technical system encompassing "requirement transformation - information support - sequence generation - dual verification - closed-loop optimization" is constructed.

[0119] Example 3

[0120] Figure 3 This is a schematic diagram of the structure of a runoff prediction device for a target watershed provided in Embodiment 3 of the present invention. Figure 3 As shown, the device includes:

[0121] The natural language instruction parsing module 310 is used to receive natural language instructions input by the user terminal, and to perform semantic understanding and structured parsing of the natural language instructions by calling a large language model to obtain a structured intent description result.

[0122] The retrieval and integration module 320 is used to perform knowledge retrieval and context construction on the structured intent description results to obtain a real-time state snapshot of the system environment and a structured knowledge package.

[0123] The emergency operation sequence construction module 330 is used to aggregate the structured intent description results, real-time status snapshots, and structured knowledge packages, fill them into the preset prompt word template, and construct the emergency operation sequence by calling the large language model to output the emergency operation sequence.

[0124] The static verification module 340 is used to perform dual static verification on the emergency operation sequence based on a preset verification engine, generate a dependency analysis report and a conflict detection report, and integrate the dependency analysis report and the conflict detection report into a comprehensive verification report.

[0125] The dynamic verification module 350 is used to perform dynamic verification on the emergency operation sequence according to the comprehensive verification report. If the dynamic verification fails, a structured correction instruction is generated according to the comprehensive verification report, and the structured correction instruction is re-input into the large language model to iteratively correct the emergency operation sequence until the iteratively corrected emergency operation sequence passes the dynamic verification.

[0126] The emergency response module 360 ​​is used to return the dynamically verified emergency operation sequence as an emergency response that matches the user's natural language instructions to the user.

[0127] This invention, through a large language model, transforms unstructured natural language instructions into structured intents, eliminating the need for users to master technical terminology and avoiding the biases of manual conversion, achieving precise connection from vague requirements to clear benchmarks. By constructing a context of "real-time state snapshot + structured knowledge package" through knowledge retrieval, the generated emergency process not only fits the current system operation state but also references historical experience and domain rules, avoiding vague processes detached from reality. Dual static verification filters out obvious logical defects beforehand, reducing the ineffective resource consumption of dynamic verification. Through a closed loop of verification and iterative correction, the process is rapidly optimized, shortening the cycle from requirement input to usable process output. Dynamic verification reproduces real execution scenarios in a simulation environment, combined with targeted optimization of structured correction instructions, ensuring that the final output process is not only logically compliant but also executable in real systems, reducing the risk of emergency operation failure. From user natural language input to executable process output, the entire process is automated, reducing human intervention and improving the timeliness and standardization of emergency response.

[0128] Optionally, based on the above embodiments, the natural language instruction parsing module 310 may include:

[0129] The instruction input unit is used to input the natural language instruction into the large language model;

[0130] The user intent mapping unit is used to identify result-type keywords in the natural language instructions through a large language model, and map the result-type keywords to user intents.

[0131] An emergency scenario matching unit is used to identify fault-related keywords in the natural language instructions through a large language model and match them with a predefined emergency scenario library to determine the emergency scenario type.

[0132] An emergency operation step mapping unit is used to identify behavioral keywords in the natural language instructions through a large language model and map the behavioral keywords to emergency operation steps;

[0133] The key entity list construction unit is used to identify entity class keywords in the natural language instructions through a large language model, and construct a key entity list based on the entity class keywords, wherein the key entity list contains entity identifiers of key entities corresponding to emergency operation steps;

[0134] The structured transformation unit is used to transform the identified user intent, emergency scenario type, emergency operation steps, and key entity list into a structured data format through a large language model, thereby obtaining the structured intent description result.

[0135] Optionally, based on the above embodiments, the retrieval and integration module 320 may include:

[0136] The static attribute acquisition unit is used to call the configuration management database interface to process the entity identifiers in the key entity list and acquire the static attributes of each key entity.

[0137] The dynamic status acquisition unit is used to call the monitoring system interface to process the identifiers of each entity in the list of key entities and obtain the dynamic running status of each key entity.

[0138] The real-time status snapshot generation unit is used to integrate the static attributes and dynamic operating status of each key entity into a real-time status snapshot.

[0139] An emergency operation tool matching unit is used to match a uniquely suitable emergency operation tool in a modular tool library based on the emergency operation steps in the structured intent description result, and extract the tool metadata corresponding to the emergency operation tool; wherein, the tool metadata includes the preconditions and postconditions required to execute the emergency operation steps;

[0140] The historical alternative solution filtering unit is used to filter at least one historical alternative solution in the historical process library with complete entity identification and consistent emergency scenario, using all entity identifiers and emergency scenario types as search conditions, and simultaneously extracting the historical step sequence in each historical alternative solution as a historical information set.

[0141] The structured knowledge package generation unit is used to extract logical constraints and operation execution rules that match the emergency scenario type from a predefined rule base, and to integrate the tool metadata, the historical information set, the logical constraints and operation execution rules into a structured knowledge package.

[0142] The historical alternative solutions are complete historical sequence of steps for handling similar emergency scenarios, formed by combining historical emergency operation steps arranged in execution order; the predefined rule base stores logical constraints and operation execution rules corresponding to each emergency scenario type.

[0143] Optionally, based on the above embodiments, the emergency operation sequence construction module 330 may include:

[0144] The first type of prompt word template filling unit is used to extract all entity identifiers and emergency operation steps from the structured intent description results, and fill in the associated entity set field and the operation to be executed field of the preset prompt word template respectively;

[0145] The second type of prompt word template filling unit is used to extract the dynamic running status of each entity from the real-time status snapshot and fill in the entity current status field of the preset prompt word template.

[0146] The third type of prompt word template filling unit is used to extract tool metadata and all historical step sequences from the structured knowledge package, and fill them into the tool mapping field and historical step sequence reference field of the preset prompt word template respectively;

[0147] The prompt word template input unit is used to input the completed prompt word template into the large language model;

[0148] The large language model processing unit is used to determine a unique execution order for each emergency operation step based on the prompt word template through the large language model, and to associate a corresponding key entity identifier for each emergency operation step based on the structured intent description result, and to match the current dynamic operation state for the current entity identifier according to the binding relationship between the key entity identifier and the dynamic operation state in the real-time status snapshot.

[0149] The emergency operation sequence construction unit is used to query the tool metadata corresponding to each emergency operation step, bind the preconditions and postconditions stored in the tool metadata with the key entity identifier and dynamic running status, and integrate them to form a structured emergency operation sequence containing the execution order of emergency operation steps, associated entity identifiers, dynamic running status, emergency operation tools, preconditions and postconditions, and output it as an emergency operation sequence.

[0150] Optionally, based on the above embodiments, the static verification module 340 may include:

[0151] The initial condition pool creation unit is used to obtain the dynamic running status of each key entity from the real-time state snapshot, and enter each dynamic running status as the initial state into the predefined blank condition pool to obtain the initial condition pool.

[0152] The precondition matching unit is used to sequentially obtain a current emergency operation step according to the execution order of each emergency operation step in the emergency operation sequence, and perform an exact matching query on the current precondition of the current emergency operation step in the initial condition pool.

[0153] The initial condition pool update unit is used to store the current postcondition of the current emergency operation step into the initial condition pool if the current precondition of the current emergency operation step matches the initial condition pool, and return to execute the operation of the current emergency operation step in the order of execution of each emergency operation step in the emergency operation sequence.

[0154] The historical average confidence calculation unit is used to search for all alternative historical satisfying steps that match the current preconditions in the historical process library if the current preconditions of the current emergency operation step fail to match the initial condition pool, and to calculate the historical average confidence of all alternative historical satisfying steps.

[0155] The logical confidence derivation unit is used to derive the logical confidence of the current preconditions based on the logical constraints, operation execution rules and the current emergency scenario type of the current emergency operation steps in the structured knowledge package.

[0156] The dependency level acquisition unit is used to calculate the comprehensive confidence level by weighting the historical average confidence level and logical confidence level according to the preset weight, and to obtain the dependency level of the current precondition based on the comprehensive confidence level and the preset confidence level threshold.

[0157] The emergency operation step traversal unit is used to store the current postcondition of the current emergency operation step into the initial condition pool if the dependency level meets the condition pool update condition, and return to execute the operation of the current emergency operation step in the order of execution of each emergency operation step in the emergency operation sequence.

[0158] The dependency exception set storage unit is used to store the current emergency operation step corresponding to the current precondition as a dependency exception operation step into the dependency exception set if the dependency level does not meet the condition pool update condition, and return to execute the operation of obtaining a current emergency operation step in the order of execution of each emergency operation step in the emergency operation sequence.

[0159] The dependency analysis report generation unit is used to generate a dependency analysis report by sorting out the dependency relationships between each dependency exception operation step in the dependency exception set after processing all emergency operation steps in the emergency operation sequence.

[0160] Optionally, based on the above embodiments, the static verification module 340 may include:

[0161] The virtual execution process simulation unit is used to simulate the execution process of each emergency operation step one by one, starting from the dynamic running status of each key entity recorded in real-time status snapshots, and forming a continuous state trajectory of each key entity for the entire simulated execution process.

[0162] The severity rating unit is used to read the continuous state trajectory. If any of the following conditions are met: there are mutually exclusive state requirements for the associated target key entity in the same emergency operation step; the continuous state trajectory of the same target key entity has a logical conflict in the running state; or the post-condition of the preceding emergency operation step is destroyed by the intermediate emergency operation step, resulting in the pre-condition of the subsequent emergency operation step being unable to match, then the severity rating of the matched conflict situation is performed according to the predefined conflict level.

[0163] The conflict detection report generation unit is used to generate a conflict detection report based on the severity rating results, the type of conflict situation, and all associated emergency response steps.

[0164] Optionally, based on the above embodiments, the dynamic verification module 350 may include:

[0165] The simulation environment building unit is used to construct a dynamic verification simulation environment consistent with the system environment based on the real-time state snapshot, and loads the logical constraints, operation execution rules and tool metadata in the structured knowledge package as the basis for dynamic verification execution.

[0166] The actual execution process simulation unit is used to input the emergency operation sequence into the dynamic verification simulation environment and simulate the actual execution process of each emergency operation step in the execution order.

[0167] The verification pass determination unit is used to determine that dynamic verification passes if no dependent abnormal operation step or conflict situation in the comprehensive verification report is hit during the actual execution process, and all emergency operation steps can be executed normally and achieve the user's intention.

[0168] The verification failure unit is used to determine that dynamic verification has failed if any dependency anomaly or conflict is encountered during the actual execution process.

[0169] The instruction element generation unit is used to extract the dependent abnormal operation steps, conflict type, severity rating and related entity identifier from the comprehensive verification report when the dynamic verification fails, and generate correction instruction elements in a preset structured format.

[0170] The structured correction instruction construction unit is used to construct a structured correction instruction based on the correction instruction elements, and fill the structured correction instruction together with the structured intent description result, real-time status snapshot, and structured knowledge package into a preset prompt word template, and input it again into the big language model to trigger the big language model to perform targeted iterative correction of the emergency operation sequence.

[0171] The iterative correction unit is used to input the iteratively corrected emergency operation sequence back into the dynamic verification simulation environment for repeated dynamic verification until the iteratively corrected emergency operation sequence passes the dynamic verification.

[0172] The emergency process generation device based on a large model provided in this embodiment of the invention can execute the emergency process generation method based on a large model provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0173] Example 4

[0174] Figure 4A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0175] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0176] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0177] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a contingency process generation method based on a large model.

[0178] That is: receiving natural language instructions input from the user terminal, performing semantic understanding and structured parsing of the natural language instructions by calling a large language model, and obtaining a structured intent description result;

[0179] The structured intent description results are subjected to knowledge retrieval and context construction to obtain a real-time state snapshot of the system environment and a structured knowledge package.

[0180] The structured intent description results, real-time status snapshots, and structured knowledge packages are aggregated, filled into a preset prompt word template, and emergency operation sequence is constructed by calling a large language model to output the emergency operation sequence.

[0181] The emergency operation sequence is subjected to dual static verification based on a preset verification engine, generating a dependency analysis report and a conflict detection report, and then the dependency analysis report and the conflict detection report are integrated into a comprehensive verification report.

[0182] According to the comprehensive verification report, the emergency operation sequence is dynamically verified. If the dynamic verification fails, a structured correction instruction is generated according to the comprehensive verification report. The structured correction instruction is re-input into the large language model to iteratively correct the emergency operation sequence until the iteratively corrected emergency operation sequence passes the dynamic verification.

[0183] The emergency operation sequence that has passed dynamic verification will be returned to the user as an emergency process response that matches the user's natural language instructions.

[0184] In some embodiments, a large-model-based emergency procedure generation method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the large-model-based emergency procedure generation method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform a large-model-based emergency procedure generation method by any other suitable means (e.g., by means of firmware).

[0185] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0186] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0187] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0188] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0189] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0190] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0191] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0192] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A large model-based emergency procedure generation method, characterized by, Comprise: Receiving a natural language instruction input by a user, performing semantic understanding and structured analysis on the natural language instruction by calling a large language model to obtain a structured intent description result; Performing knowledge retrieval and context construction on the structured intent description result to obtain a real-time state snapshot of the system environment and a structured knowledge package; Aggregating the structured intent description result, the real-time state snapshot, and the structured knowledge package, filling in a preset prompt word template, performing emergency operation sequence construction by calling a large language model, and outputting an emergency operation sequence; Based on the preset verification engine, double static verification is performed on the emergency operation sequence to generate a dependency analysis report and a conflict detection report, and the dependency analysis report and the conflict detection report are integrated into a comprehensive verification report; According to the comprehensive verification report, dynamic verification is performed on the emergency operation sequence, if the dynamic verification fails, a structured correction instruction is generated according to the comprehensive verification report, the structured correction instruction is re-input into the large language model, and the emergency operation sequence is iteratively corrected until the iteratively corrected emergency operation sequence passes the dynamic verification; The emergency operation sequence that passes the dynamic verification is taken as an emergency process response matched with the user's natural language instruction and returned to the user end.

2. The method of claim 1, wherein, Performing semantic understanding and structured analysis on the natural language instruction by calling a large language model to obtain a structured intent description result, comprising: Inputting the natural language instruction into a large language model; Identifying result class keywords in the natural language instruction by the large language model, and mapping the result class keywords to user intent; Identifying fault class keywords in the natural language instruction by the large language model, and matching them with a predefined emergency scenario library to determine an emergency scenario type; Identifying behavior class keywords in the natural language instruction by the large language model, and mapping the behavior class keywords to emergency operation steps; Identifying entity class keywords in the natural language instruction by the large language model, and constructing a key entity list according to the entity class keywords, wherein the key entity list contains entity identifiers of key entities corresponding to the emergency operation steps; Converting the identified user intent, emergency scenario type, emergency operation steps, and key entity list into a structured data format by the large language model to obtain the structured intent description result.

3. The method of claim 2, wherein, Performing knowledge retrieval and context construction on the structured intent description result to obtain a real-time state snapshot of the system environment and a structured knowledge package, comprising: Calling a configuration management database interface to process each entity identifier in the key entity list to obtain the static attributes of each key entity; Calling a monitoring system interface to process each entity identifier in the key entity list to obtain the dynamic running state of each key entity; Integrating the static attributes and dynamic running state of each key entity into a real-time state snapshot; According to the emergency operation step in the structured intention description result, a uniquely matched emergency operation tool is matched in a modular tool library, and tool metadata corresponding to the emergency operation tool is extracted; wherein the tool metadata contains preconditions and postconditions required for the execution of the emergency operation step; At least one historical alternative scheme with complete entity identification coverage and consistent emergency scene is screened out from the historical process library by taking all entity identifications and emergency scene types as retrieval conditions, and the historical step sequence in each historical alternative scheme is synchronously extracted as a historical information set; Logical constraints and operation execution rules matching the emergency scene type are extracted from a pre-defined rule library, and the tool metadata, the historical information set, the logical constraints and the operation execution rules are integrated into a structured knowledge package; Wherein, the historical alternative scheme is a complete historical step sequence for handling the same type of emergency scene in history, which is formed by combining historical emergency operation steps arranged in execution order; the pre-defined rule library stores logical constraints and operation execution rules corresponding to each emergency scene type.

4. The method of claim 3, wherein, The structured intention description result, real-time state snapshot and structured knowledge package are aggregated, filled into a preset prompt word template, and an emergency operation sequence is output by calling a large language model for emergency operation serialization construction, including: All entity identifications and emergency operation steps are extracted from the structured intention description result and filled into the associated entity set field and the to-be-executed operation field of the preset prompt word template respectively; The dynamic running state of each entity is extracted from the real-time state snapshot and filled into the entity current state field of the preset prompt word template; Tool metadata and all historical step sequences are extracted from the structured knowledge package and filled into the tool mapping field and the historical step sequence reference field of the preset prompt word template respectively; The filled prompt word template is input into the large language model; The large language model determines a unique execution order for each emergency operation step according to the prompt word template, and associates each emergency operation step with a corresponding key entity identification based on the structured intention description result, and matches the corresponding current dynamic running state for the current entity identification according to the binding relationship between the key entity identification and the dynamic running state in the real-time state snapshot; The tool metadata corresponding to each emergency operation step is queried, and the preconditions and postconditions stored in the tool metadata are bound with the key entity identification and the dynamic running state, and a structured emergency operation sequence containing the execution order of the emergency operation step, the associated entity identification, the dynamic running state, the emergency operation tool, the preconditions and the postconditions is integrated and formed, and is output as an emergency operation sequence.

5. The method according to claim 3 or 4, characterized in that, The initial emergency operation sequence is subjected to double static verification based on a preset verification engine, and a dependency analysis report is generated, including: The dynamic running state of each key entity is obtained from the real-time state snapshot, and each dynamic running state is input into a pre-defined blank condition pool as an initial state to obtain an initial condition pool; According to the execution sequence of each emergency operation step in the emergency operation sequence, a current emergency operation step is acquired in sequence, and a current precondition of the current emergency operation step is subjected to an exact match query in the initial condition pool; If the current precondition of the current emergency operation step matches the initial condition pool successfully, the current postcondition of the current emergency operation step is stored in the initial condition pool, and the operation of acquiring a current emergency operation step in sequence according to the execution sequence of each emergency operation step in the emergency operation sequence is returned; If the current precondition of the current emergency operation step fails to match the initial condition pool, all candidate historical satisfaction steps matching the current precondition are searched for in the historical process library, and historical average confidence degrees of the all candidate historical satisfaction steps are calculated; Based on the logical constraint, the operation execution rule in the structured knowledge package and the current emergency scene type of the current emergency operation step, a logical confidence degree of the current precondition is derived; The historical average confidence degrees and the logical confidence degree are weighted and calculated to obtain a comprehensive confidence degree according to a preset weight, and a dependency level of the current precondition is acquired according to the comprehensive confidence degree and a preset confidence threshold; If the dependency level meets the condition pool updating condition, the current postcondition of the current emergency operation step is stored in the initial condition pool, and the operation of acquiring a current emergency operation step in sequence according to the execution sequence of each emergency operation step in the emergency operation sequence is returned; If the dependency level does not meet the condition pool updating condition, the current emergency operation step corresponding to the current precondition is stored in the dependency exception set as a dependency exception operation step, and the operation of acquiring a current emergency operation step in sequence according to the execution sequence of each emergency operation step in the emergency operation sequence is returned; After the processing of all emergency operation steps in the emergency operation sequence is completed, a dependency analysis report is generated by analyzing the dependency relationship between the dependency exception operation steps in the dependency exception set.

6. The method according to claim 3 or 4, characterized in that, The emergency operation sequence is subjected to double static verification based on a preset verification engine to generate a conflict detection report, including: Taking the dynamic running state of each key entity recorded by the real-time state snapshot as a starting point, the execution process of each emergency operation step is simulated in sequence according to the execution sequence of the emergency operation sequence, and a continuous state trajectory of each key entity for the entire simulated execution process is formed; The continuous state trajectory is read, and if any of the following conditions is met: there is a mutual exclusion state requirement for a target key entity associated with the same emergency operation step, there is a logical conflict in the continuous state trajectory of the same target key entity, or the postcondition of a previous emergency operation step is destroyed by an intermediate emergency operation step, resulting in the precondition of a subsequent emergency operation step being unable to match, the matched conflict is rated in severity according to a predefined conflict level; According to the severity rating result, the conflict type and all associated emergency operation steps, a conflict detection report is generated.

7. The method of claim 5, wherein, According to the comprehensive verification report, the emergency operation sequence is dynamically verified, if the dynamic verification fails, the structured modification instruction is generated according to the comprehensive verification report, the structured modification instruction is re-input to the large language model, the emergency operation sequence is iteratively modified, and the iteratively modified emergency operation sequence is dynamically verified until the iteratively modified emergency operation sequence passes the dynamic verification, comprising: Based on the real-time state snapshot, a dynamic verification simulation environment consistent with the system environment is constructed, and the logical constraints, operation execution rules and tool metadata in the structured knowledge package are loaded as the basis for dynamic verification; The emergency operation sequence is input to the dynamic verification simulation environment, and the actual execution process of each emergency operation step is simulated according to the execution order; If any dependent abnormal operation step and conflict situation in the comprehensive verification report is not hit in the actual execution process, and all emergency operation steps can be normally executed and the user's intention is achieved, it is determined that the dynamic verification passes; If any dependent abnormal or conflict situation is hit in the actual execution process, it is determined that the dynamic verification fails; When the dynamic verification fails, the dependent abnormal operation step, the conflict situation type, the severity rating and the associated entity identifier in the comprehensive verification report are extracted, and the modification instruction elements are generated in a preset structured format; Based on the modification instruction elements, a structured modification instruction is constructed, and the structured modification instruction, the structured intent description result, the real-time state snapshot and the structured knowledge package are filled into a preset prompt word template, and then input to the large language model again to trigger the large language model to iteratively modify the emergency operation sequence; The iteratively modified emergency operation sequence is input to the dynamic verification simulation environment again for repeated dynamic verification until the iteratively modified emergency operation sequence passes the dynamic verification. 8.A large model-based emergency procedure generation apparatus, characterized by, The device comprises: A natural language instruction analysis module for receiving a natural language instruction input by a user terminal, performing semantic understanding and structured analysis on the natural language instruction by calling a large language model, and obtaining a structured intent description result; A retrieval and integration module for performing knowledge retrieval and context construction on the structured intent description result to obtain a real-time state snapshot of a system environment and a structured knowledge package; An emergency operation sequence construction module for aggregating the structured intent description result, the real-time state snapshot and the structured knowledge package, filling them into a preset prompt word template, constructing an emergency operation sequence by calling a large language model, and outputting the emergency operation sequence; A static verification module for performing double static verification on the emergency operation sequence based on a preset verification engine, generating a dependency analysis report and a conflict detection report, and integrating the dependency analysis report and the conflict detection report into a comprehensive verification report; A dynamic verification module for dynamically verifying the emergency operation sequence according to the comprehensive verification report, generating a structured modification instruction according to the comprehensive verification report if the dynamic verification fails, re-inputting the structured modification instruction to the large language model, iteratively modifying the emergency operation sequence, and iteratively modifying the iteratively modified emergency operation sequence until the iteratively modified emergency operation sequence passes the dynamic verification. An emergency procedure response module is configured to return the emergency operation sequence verified dynamically to the user terminal as an emergency procedure response matching the natural language instruction of the user.

9. An electronic device, comprising: The electronic device includes: at least one processor; and a memory connected to the at least one processor in communication, wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for causing the processor to implement the method of any one of claims 1-7 when executed.

Images