Emergency disposal intelligent agent credible generation method and system based on multi-source evidence chain constraint

Abstract

The application provides a kind of method and system for generating credible emergency disposal agent based on multi-source evidence chain constraint, relating to data processing technical field, the application obtains the multi-source evidence data responding to emergency disposal request, constructs real-time fault portrait based on multi-source evidence data, determines a plurality of candidate claim information according to real-time fault portrait and constructs evidence chain constraint structure, carries out credibility evaluation to each candidate claim information by evidence chain constraint structure, generates constraint condition based on evaluation result and gate rule, controls emergency disposal agent to generate emergency disposal content according to generated constraint condition, and outputs credible disposal result after reverse verification to emergency disposal content, the application splits the disposal content to be generated into a plurality of candidate claim information, and each fault judgment and disposal action in disposal content can be checked respectively.

Description

Technical Field

[0001] This invention relates to data processing technology, and more particularly to a reliable generation method and system for emergency response intelligent agents based on multi-source evidence chain constraints. Background Technology

[0002] An emergency response intelligent agent is a data processing tool that automatically generates fault diagnosis and handling suggestions based on system operation data. It is widely used in scenarios such as information system operation and maintenance, production line monitoring, and business assurance. When a system alarm or business anomaly occurs, the emergency response intelligent agent must quickly aggregate data from multiple sources, including alarm data, log data, business metrics, and call chains, to provide operation and maintenance personnel with fault diagnosis and handling action suggestions.

[0003] Currently, when emergency response agents generate response content, they primarily input data from multiple sources as a whole into a language model, which then outputs a single, complete response segment. This approach treats the entire response segment as an indivisible whole, making it impossible to determine whether the fault assessments and response actions within that segment are individually supported by data. When a single response segment contains both data-supported correct assessments and data-lacking erroneous actions, operations and maintenance personnel struggle to distinguish which claims are credible and which lack data support. Consequently, the generated response content may contain fault assessments or response actions without data sources, posing a significant risk to operations and maintenance personnel when performing actions such as restarting or deleting.

[0004] Therefore, how to ensure that the fault diagnosis and response actions generated by the emergency response intelligent agent are supported by verifiable data, and how to intercept or correct parts that lack data support, has become a key issue that urgently needs to be addressed. Summary of the Invention

[0005] This invention provides a reliable generation method and system for emergency response intelligent agents based on multi-source evidence chain constraints. This method enables the fault judgment and response actions generated by the emergency response intelligent agent to have verifiable data support, and intercepts or corrects parts that lack data support.

[0006] A first aspect of the present invention provides a method for generating a trustworthy emergency response agent based on multi-source evidence chain constraints, comprising:

[0007] Acquire multi-source evidence data in response to emergency response requests, and construct a real-time fault profile based on the multi-source evidence data;

[0008] Based on the real-time fault profile, multiple candidate claim information is determined, and an evidence chain constraint structure is constructed;

[0009] The credibility of each candidate claim is evaluated based on the chain of evidence constraint structure, and constraint conditions are generated based on the evaluation results and preset gating rules.

[0010] Based on the aforementioned generation constraints, the emergency response agent is controlled to generate emergency response content, and the emergency response content is reverse-verified to output a reliable response result.

[0011] Optionally, in one possible implementation of the first aspect, constructing a real-time fault profile based on the multi-source evidence data includes:

[0012] The multi-source evidence data is standardized to obtain evidence units;

[0013] Based on the component relationships of the target system in the emergency response request, the evidence units are spliced ​​together to obtain a real-time fault profile.

[0014] Optionally, in one possible implementation of the first aspect, the standardization process of the multi-source evidence data to obtain evidence units includes:

[0015] Field extraction and time alignment are performed on the multi-source evidence data to obtain evidence units;

[0016] The evidence units are marked with evidence polarity, which includes support, rebuttal, conflict, and expiration.

[0017] Optionally, in one possible implementation of the first aspect, determining multiple candidate claim information based on the real-time fault profile includes:

[0018] Based on the fault status to be verified in the real-time fault profile, the corresponding emergency plan component is retrieved from the preset plan component library;

[0019] The fault state to be verified is identified as a fault-type candidate claim information, and the candidate handling steps in the emergency plan component are identified as action-type candidate claim information, resulting in multiple candidate claim information.

[0020] Optionally, in one possible implementation of the first aspect, the construction of the chain of evidence constraint structure includes:

[0021] Based on the relationships between the information of each candidate's claims, multi-source evidence data, and emergency response plan components, an evidence chain diagram is constructed;

[0022] Determine the evidence type corresponding to each piece of evidence in the multi-source evidence data, and construct a claim evidence coverage matrix based on the coverage status of each evidence type to each candidate claim information;

[0023] The evidence chain graph and the claim evidence coverage matrix are determined as the evidence chain constraint structure.

[0024] Optionally, in one possible implementation of the first aspect, the credibility assessment of each candidate claim information based on the chain of evidence constraint structure includes:

[0025] The percentage of supporting evidence types among the required evidence types for each candidate's claim is used to obtain the evidence coverage.

[0026] Calculate the number of pieces of evidence corresponding to the same candidate claim information to obtain the multi-source consistency degree;

[0027] The number of conflicting evidence types in each candidate claim is counted to obtain the conflict value.

[0028] Calculate the sum of the evidence coverage and the multi-source consistency, and subtract the conflict value from the obtained sum to obtain the credibility assessment result of each candidate claim information.

[0029] Optionally, in one possible implementation of the first aspect, generating constraints based on the evaluation results and preset gating rules includes:

[0030] When the credibility assessment result reaches a preset first threshold, the generated constraint condition is set to allow generation.

[0031] When the credibility assessment result reaches the preset second threshold but does not reach the preset first threshold, the generated constraint condition is generated by probability.

[0032] When the credibility assessment result fails to reach the preset second threshold, the generated constraint condition is clarification.

[0033] Optionally, in one possible implementation of the first aspect, it also includes:

[0034] Obtain evidence of the scope of impact, evidence of preconditions, evidence of rollback plans, and evidence of manual confirmation to form a risk evidence set;

[0035] When the action-type candidate claim information is determined to be a preset high-risk action step, and the action-type candidate claim information satisfies all the evidence in the risk evidence set, the generated constraint condition is to allow generation.

[0036] If the action-type candidate claim information is determined to be a preset high-risk action step, and the action-type candidate claim information does not satisfy all the evidence in the risk evidence set, the generated constraint is interception.

[0037] Optionally, in one possible implementation of the first aspect, the reverse verification of the emergency response content and the output of a reliable response result includes:

[0038] The emergency response content is analyzed to obtain the target claim information in the emergency response content and the target entity in the target claim information;

[0039] When it is determined that the target entity exists in the chain of evidence constraint structure, the corresponding evidence is bound to the target claim information;

[0040] If it is determined that the target does not exist in the chain of evidence constraint structure, the target is deleted or rewritten.

[0041] Based on the target claim information bound to the corresponding evidence, a credible disposal result is output.

[0042] A second aspect of the present invention provides a trusted generation system for emergency response intelligent agents based on multi-source evidence chain constraints, comprising:

[0043] The construction module is used to acquire multi-source evidence data in response to emergency response requests and to construct a real-time fault profile based on the multi-source evidence data;

[0044] The constraint module is used to determine multiple candidate claim information based on the real-time fault profile and construct an evidence chain constraint structure.

[0045] The evaluation module is used to evaluate the credibility of each candidate claim information according to the evidence chain constraint structure, and generate constraint conditions based on the evaluation results and preset gating rules.

[0046] The verification module is used to control the emergency response agent to generate emergency response content based on the generation constraints, perform reverse verification on the emergency response content, and output a reliable response result.

[0047] The beneficial effects of this invention are as follows:

[0048] 1. This invention acquires multi-source evidence data in response to emergency response requests, constructs a real-time fault profile based on the multi-source evidence data, determines multiple candidate claims based on the real-time fault profile and constructs an evidence chain constraint structure, evaluates the credibility of each candidate claim through the evidence chain constraint structure, generates constraint conditions based on the evaluation results and gating rules, controls the emergency response agent to generate emergency response content according to the generated constraint conditions, and outputs a credible response result after reverse verification of the emergency response content. This invention breaks down the content to be generated by the emergency response agent into multiple candidate claims and establishes a constraint relationship between each candidate claim and the evidence, enabling separate verification of each fault judgment and each response action in the response content. This avoids treating a whole segment of response content as an indivisible whole, which would make it impossible to determine whether each claim has data support.

[0049] 2. This invention standardizes multi-source evidence data to obtain evidence units, and marks these units with evidence polarities of support, rebuttal, conflict, and expiration. Based on the component relationships of the target system, the evidence units are assembled to obtain a real-time fault profile. Then, based on the fault states to be verified in the real-time fault profile, emergency plan components are retrieved from the contingency plan component library. The fault states to be verified are identified as fault-type candidate claim information, and the candidate handling steps are identified as action-type candidate claim information. This invention unifies evidence data from different sources into evidence units with evidence polarities, and determines candidate claim information based on emergency plan components, ensuring that each candidate claim information has a clear source of evidence and a contingency plan source.

[0050] 3. This invention constructs an evidence chain constraint structure using an evidence chain graph and a claim evidence coverage matrix. Based on evidence coverage, multi-source consistency, and conflict values, a credibility assessment result is obtained. Based on the comparison between the credibility assessment result and a threshold, the generation constraint conditions are determined as allowed generation, probabilistic generation, or clarification. For preset high-risk handling steps, all evidence in the risk evidence set must be satisfied; otherwise, the generation constraint condition is determined as interception. Finally, the emergency handling content is reverse-verified, and targets not supported by the evidence chain constraint structure are deleted or rewritten. This invention adds generation constraints based on the evidence situation before generating handling content and performs reverse verification based on the evidence chain constraint structure after generating handling content, thus achieving credibility constraints on the output content of the emergency handling agent. Attached Figure Description

[0051] Figure 1 A flowchart illustrating a trusted generation method for emergency response intelligent agents based on multi-source evidence chain constraints provided by this invention;

[0052] Figure 2 This is a schematic diagram of the structure of a trusted generation system for emergency response intelligent agents based on multi-source evidence chain constraints provided by the present invention.

[0053] Figure 3 This is a schematic diagram of the hardware structure of an electronic device provided by the present invention. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0055] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein.

[0056] It should be understood that in the various embodiments of the present invention, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0057] It should be understood that in this invention, "comprising" and "having," 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 is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or device.

[0058] It should be understood that in this invention, "multiple" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "Contains A, B, and C", "Contains A, B, and C" means that all three A, B, and C are contained; "Contains A, B, or C" means that one of A, B, and C is contained; "Contains A, B, and / or C" means that any one, two, or three of A, B, and C are contained.

[0059] It should be understood that in this invention, "B corresponding to A", "B corresponding to A", "A and B correspond", or "B and A correspond" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Matching A and B is defined as a similarity between A and B that is greater than or equal to a preset threshold.

[0060] Depending on the context, "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection."

[0061] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0062] This invention provides a reliable generation method for emergency response intelligent agents based on multi-source evidence chain constraints, such as... Figure 1 As shown, it includes:

[0063] S1, acquire multi-source evidence data in response to emergency response requests, and construct a real-time fault profile based on the multi-source evidence data.

[0064] It's important to note that when an information system malfunctions, the data reflecting the failure is often scattered across many different sources. These include alerts from monitoring platforms, operational logs from servers, success rate metrics from business backend statistics, and call records between various services. These data come from different sources and are in different formats; relying on any single document is insufficient to determine the overall situation of the failure. This step first acquires this data and then organizes and combines it into a real-time failure profile that reflects the current operational status of the system.

[0065] Among them, an emergency response request refers to a request used to trigger the emergency response agent to generate response content. The emergency response request includes a fault description, a target system identifier, and a time window; multi-source evidence data refers to data obtained from multiple sources such as alarm data, log data, business indicators, and call chains, used to reflect the operating status of the target system; the target system refers to the information system corresponding to the emergency response request that has experienced a fault; the time window refers to the time range used to obtain multi-source evidence data; and the real-time fault profile refers to a data set reflecting the current operating status of the target system obtained by splicing together various evidence units according to the component relationships of the target system.

[0066] Understandably, the process begins by receiving an emergency response request from operations and maintenance personnel or a monitoring platform. This request includes a fault description, a target system identifier, and a time window. Next, based on the target system identifier and time window in the emergency response request, alarm data generated by the target system within that time window is retrieved from the alarm platform, corresponding log data is obtained from log storage, business metrics are obtained from business monitoring, and call chain data is obtained from call chain tracing, thus obtaining multi-source evidence data. This multi-source evidence data is then standardized, organizing data from different sources into uniformly formatted evidence units. Finally, based on the connection relationships between components in the target system, these evidence units are pieced together at their corresponding component locations to obtain a real-time fault profile.

[0067] In some embodiments, the step S1 of constructing a real-time fault profile based on the multi-source evidence data includes S11-S12:

[0068] S11, The multi-source evidence data is standardized to obtain evidence units.

[0069] Understandably, this step standardizes multi-source evidence data, organizing data from different sources into evidence units with unified fields and time alignment.

[0070] Among them, an evidence unit refers to a data unit with a unified format obtained after field extraction and time alignment of multi-source evidence data.

[0071] In some embodiments, the standardization process of the multi-source evidence data in step S11 to obtain evidence units includes S111-S112:

[0072] S111, Field extraction and time alignment are performed on the multi-source evidence data to obtain evidence units.

[0073] Understandably, the first step is to extract fields from the multi-source evidence data. This involves extracting key fields such as the fault object, occurrence time, and content description from each piece of raw data. For example, from an alarm data point, the fault object might be extracted as "order service," the occurrence time as "a specific moment," and the content description as "interface timeout." Next, time alignment is performed, converting inconsistent time formats across different data points into a unified time format, allowing data from different sources to be arranged along a consistent timeline. After field extraction and time alignment, each piece of raw data is organized into a uniformly formatted evidence unit.

[0074] Among them, field extraction refers to the process of extracting key fields such as fault object, occurrence time and content description from the raw data; time alignment refers to the process of converting the time of data from different sources into the same time format.

[0075] S112, mark the evidence unit with evidence polarity, which includes support, rebuttal, conflict, and expiration.

[0076] Understandably, for each piece of evidence, its content description is compared with the corresponding fault judgment. When the content description of the evidence unit matches the fault judgment, the evidence polarity of that evidence unit is marked as supportive. For example, if the evidence unit records that the order service interface timed out and the fault judgment is that the order service is abnormal, then the evidence polarity of that evidence unit is supportive of the fault judgment. When the content description of the evidence unit contradicts the fault judgment, the evidence polarity is marked as rebuttal. For example, if the evidence unit records that the order service interface responded normally, then its evidence polarity for the judgment that the order service is abnormal is rebuttal. When the content descriptions of multiple evidence units pointing to the same fault judgment contradict each other, the evidence polarity of the corresponding evidence units is marked as conflicting. When the occurrence time of an evidence unit is earlier than the start time of the time window, the evidence polarity is marked as expired.

[0077] Among them, evidence polarity refers to the state of the evidence unit in relation to the corresponding fault judgment. Evidence polarity includes support, rebuttal, conflict, and expiration. Support means that the content description of the evidence unit is consistent with the fault judgment it points to. Rebuttal means that the content description of the evidence unit is contrary to the fault judgment it points to. Conflict means that the content descriptions of multiple evidence units pointing to the same fault judgment contradict each other. Expiration means that the occurrence time of the evidence unit is earlier than the start time of the time window.

[0078] S12, based on the component relationships of the target system in the emergency response request, the evidence units are spliced ​​together to obtain a real-time fault profile.

[0079] Understandably, the process begins by retrieving the component relationships of the target system. These relationships record the various components within the target system and the connections between them. Next, based on the faulty object in each evidence unit, the evidence unit is appended to the corresponding component in the component relationship. For example, evidence units with faulty objects related to the order service are appended to the order service component, and evidence units with faulty objects related to the inventory service are appended to the inventory service component. After all evidence units are appended according to the component relationships, a real-time fault profile is obtained. This profile shows which evidence units each component has and the connections between them.

[0080] Among them, component relationships refer to the records of various components in the target system and the calls and connections between components.

[0081] S2, Based on the real-time fault profile, determine multiple candidate claim information and construct an evidence chain constraint structure.

[0082] It's important to note that the final output of the emergency response agent consists of specific judgments and recommendations. For example, an anomaly in the order service is a judgment, and recommending restarting the order service is a recommendation. If the entire response is treated as a single unit, it's impossible to verify the evidence for each judgment and recommendation individually. This step first breaks down the response content to be generated into independently verifiable candidate claims, and then establishes the constraint relationships between these candidate claims and the evidence.

[0083] Understandably, the process begins by retrieving the fault status to be verified from the real-time fault profile, corresponding emergency plan components from the contingency plan component library. Next, the fault status to be verified is identified as fault-type candidate claim information, and the candidate handling steps recorded in the emergency plan components are identified as action-type candidate claim information, resulting in multiple candidate claim information. Then, using each candidate claim information as an object, an evidence chain graph is constructed, linking the candidate claim information, multi-source evidence data, and the relationships between emergency plan components. A claim evidence coverage matrix is ​​then constructed using candidate claim information and evidence type as dimensions. The evidence chain graph and the claim evidence coverage matrix together serve as the evidence chain constraint structure.

[0084] Among them, candidate claim information refers to fault judgments or handling actions that the emergency response agent is to generate and can be independently verified; fault-type candidate claim information refers to candidate claim information that is determined by the fault state to be verified and is used to judge the fault situation; action-type candidate claim information refers to candidate claim information that is determined by the candidate handling steps and is used to suggest handling actions; the evidence chain constraint structure refers to the structure composed of the evidence chain graph and the claim evidence coverage matrix, which is used to constrain the relationship between candidate claim information and evidence.

[0085] In some embodiments, the determination of multiple candidate claim information based on the real-time fault profile in step S2 includes S21-S22:

[0086] S21, based on the fault status to be verified in the real-time fault profile, retrieve the corresponding emergency plan component from the preset plan component library.

[0087] Understandably, the process begins by extracting the fault status to be verified from the real-time fault profile. For example, the fault status of order service interface timeout can be extracted from the evidence unit on the order service component. Next, the fault status to be verified is compared with the applicable status of each emergency plan component in the contingency plan component library. An emergency plan component whose applicable status matches the fault status to be verified is then retrieved. For example, an emergency plan component applicable to the interface timeout status is retrieved, which contains candidate handling steps, verification points, and rollback schemes.

[0088] Among them, the fault state to be verified refers to the state of potential faults in the target system extracted from the real-time fault profile; the contingency plan component library refers to a pre-established database that stores multiple contingency plan components; the contingency plan component refers to a pre-established handling plan for a specific fault state, which records candidate handling steps, verification points, and rollback schemes; the candidate handling steps refer to the handling action steps for the corresponding fault state recorded in the contingency plan component.

[0089] S22, the fault state to be verified is determined as fault-type candidate claim information, and the candidate handling steps in the emergency plan component are determined as action-type candidate claim information, thus obtaining multiple candidate claim information.

[0090] Understandably, each fault state to be verified extracted from the real-time fault profile is identified as a fault-type candidate claim, such as determining an order service interface timeout as a fault-type candidate claim. Each candidate handling step recorded in the emergency plan component is identified as an action-type candidate claim, such as determining restarting the order service as an action-type candidate claim and clearing the order service cache as another action-type candidate claim. This results in multiple candidate claims containing both fault-type and action-type candidate claims.

[0091] In some embodiments, the construction of the chain of evidence constraint structure in step S2 includes S23-S25:

[0092] S23. Construct an evidence chain map based on the relationships between candidate claims, multi-source evidence data, and emergency response plan components.

[0093] It's important to note that the credibility of a candidate claim depends on the evidence pointing to it, whether that evidence supports or opposes it, and which contingency plan it corresponds to. If candidate claims, evidence, and contingency plans are listed separately, this relationship cannot be determined. This step connects candidate claim information, multi-source evidence data, and contingency plan components into an evidence chain diagram, explicitly linking each candidate claim to the supporting evidence and the contingency plan upon which it is based. This allows for the retrieval of all evidence for a claim during subsequent verification.

[0094] Understandably, each candidate claim is treated as a claim node in the graph, the evidence units corresponding to multi-source evidence data are treated as evidence nodes, and emergency response plan components are treated as plan component nodes. Then, connections are established between the nodes. When an evidence unit points to a candidate claim, a connection is established between that evidence node and the claim node, and the evidence polarity of that evidence unit is recorded on the connection. For example, if the evidence unit of order service interface timeout supports the claim that the order service is abnormal, a connection is established between them, recorded as supported. When an action-type candidate claim comes from an emergency response plan component, a connection is established between that plan component node and the claim node. After all nodes and connections are established, the evidence chain graph is obtained.

[0095] Among them, the evidence chain diagram refers to a diagram that describes the relationship between candidate claim information and evidence and contingency plan, which is composed of claim nodes, evidence nodes and contingency plan component nodes; claim nodes refer to the nodes in the evidence chain diagram that represent candidate claim information; evidence nodes refer to the nodes in the evidence chain diagram that represent evidence units; and contingency plan component nodes refer to the nodes in the evidence chain diagram that represent emergency contingency plan components.

[0096] S24. Determine the evidence type corresponding to each piece of evidence in the multi-source evidence data, and construct a claim evidence coverage matrix based on the coverage status of each evidence type to each candidate claim information.

[0097] It's important to note that judging the evidence for a claim involves not only assessing its existence but also its completeness. For example, a fault diagnosis requires evidence such as status descriptions, business metrics, and logs. Simply counting the number of pieces of evidence without categorizing them can result in a large quantity of evidence but a lack of diversity in its types. This step first determines the type of evidence for each piece of evidence and then establishes a claim evidence coverage matrix based on the candidate claim information and evidence types.

[0098] Understandably, based on the source of each piece of evidence, the corresponding evidence type is determined. For example, evidence from an alarm platform corresponds to an alarm type, evidence from log storage corresponds to a log type, and evidence from business monitoring corresponds to a business metric type. Next, a matrix is ​​created, where each row corresponds to a candidate claim and each column corresponds to an evidence type. Then, the coverage status of each candidate claim for each evidence type is determined one by one. When a claim has supporting evidence of a certain evidence type, the coverage status of the corresponding matrix element is marked as "supporting." When there is conflicting evidence, it is marked as "conflicting." When no evidence of that type exists, it is marked as "missing." When all evidence of that type has expired, it is marked as "expired," thus filling in the claim evidence coverage matrix.

[0099] Among them, evidence type refers to the type of evidence classified according to the source of evidence unit, including alarm type, log type and business indicator type; coverage status refers to the support of a certain evidence type for a certain candidate claim information, including support, conflict, missing and expired; claim evidence coverage matrix is ​​a matrix with candidate claim information as rows, evidence type as columns and coverage status as elements.

[0100] S25, the evidence chain diagram and the claim evidence coverage matrix are determined as the evidence chain constraint structure.

[0101] It is understandable that the evidence chain graph constructed in step S23 and the claim evidence coverage matrix constructed in step S24 are used together as the evidence chain constraint structure. The evidence chain graph is used to describe the connection relationship between each candidate claim information and evidence and plan, and the claim evidence coverage matrix is ​​used to record the coverage status of each candidate claim information on each type of evidence. The evidence chain graph and the claim evidence coverage matrix together constitute the evidence chain constraint structure that constrains the relationship between candidate claim information and evidence.

[0102] S3. Based on the evidence chain constraint structure, the credibility of each candidate claim information is evaluated, and constraint conditions are generated based on the evaluation results and preset gating rules.

[0103] It should be noted that after linking each candidate claim with its evidence, a judgment reflecting the credibility of that claim is needed to determine whether it can be directly generated. If the credibility of a claim is not assessed before generation, claims lacking evidence will be included in the processing. This step first assesses the credibility of each candidate claim based on the evidence chain constraint structure, obtaining an assessment result that reflects its credibility. Then, based on the assessment result and gating rules, the generation constraints for that claim are determined.

[0104] Understandably, the process begins by calculating the evidence coverage, multi-source consistency, and conflict value for each candidate claim based on the claim evidence coverage matrix, thus determining the credibility assessment result for that claim. Next, the credibility assessment result is compared with preset first and second thresholds. Generation constraints are determined according to gating rules. If the credibility assessment result reaches the preset first threshold, generation is allowed; if it reaches the preset second threshold but not the preset first threshold, generation is probabilistic; and if it does not reach the preset second threshold, clarification is required.

[0105] Among them, the credibility assessment result refers to the assessment value of the credibility of the candidate claim information; the gating rule refers to the rule that determines the generation constraint condition based on the credibility assessment result; the generation constraint condition refers to the constraint imposed on the emergency response agent to generate the corresponding candidate claim information, and the generation constraint condition includes allow generation, probability generation, clarification and interception.

[0106] In some embodiments, step S3, which evaluates the credibility of each candidate claim based on the chain of evidence constraint structure, includes S31-S34:

[0107] S31, calculate the percentage of supporting evidence types among the required evidence types for each candidate claim to obtain the evidence coverage.

[0108] Understandably, for each candidate claim, the required evidence types for each claim are first determined. For example, a fault-related candidate claim might require three types of evidence: alarm type, log type, and business indicator type. Next, the coverage status of these three required evidence types is checked in the claim evidence coverage matrix. The number of evidence types in a supporting state is counted. For example, if alarm and log types are supported, and business indicator type is missing, then two types are supported. Then, the ratio of the number of supported evidence types to the total number of required evidence types is calculated to obtain the evidence coverage. In this example, the evidence coverage is two divided by three, i.e., the evidence coverage is two-thirds.

[0109] Among them, the required evidence type refers to the type of evidence required for the establishment of the corresponding candidate claim; the evidence coverage refers to the ratio of the number of supporting evidence types among the required evidence types of the candidate claim to the total number of required evidence types.

[0110] S32, calculate the number of pieces of evidence corresponding to the same candidate claim information to obtain the multi-source consistency.

[0111] Understandably, for each candidate claim, the evidence nodes that point to the claim node through supporting connections are searched in the evidence chain graph, and the number of these evidence nodes is counted to obtain the multi-source consistency. For example, if the claim that the order service is abnormal is supported by an evidence unit from the alarm platform, an evidence unit from log storage, and an evidence unit from business monitoring, then the number of supporting evidence points to this claim is three, and the multi-source consistency of this claim is three.

[0112] Among them, multi-source consistency refers to the number of evidence units in the evidence chain graph that point to the same candidate claim information through supporting connections.

[0113] S33, count the number of conflicting evidence types in each candidate claim information to obtain the conflict value.

[0114] Understandably, for each candidate claim, the coverage status of each evidence type in the claim's row is checked in the claim evidence coverage matrix, and the number of evidence types with conflicting coverage status is counted to obtain the conflict value. For example, if a claim has a conflicting coverage status for alarm types but no conflict for other evidence types, then the conflict value of that claim is one.

[0115] The conflict value refers to the number of conflicting evidence types covered by candidate claim information in the claim evidence coverage matrix.

[0116] S34, calculate the sum of the evidence coverage and the multi-source consistency, and subtract the conflict value from the obtained sum to obtain the credibility assessment result of each candidate claim information.

[0117] Understandably, for each candidate claim, the sum of evidence coverage and multi-source consistency is first calculated, and then the conflict value is subtracted from the sum to obtain the credibility assessment result of the claim.

[0118] In some embodiments, the generation of constraint conditions based on the evaluation results and preset gating rules in step S3 includes S35-S37:

[0119] S35, when the credibility assessment result reaches the preset first threshold, the generated constraint condition is allowed to be generated.

[0120] It should be noted that when the credibility assessment result of a claim is high, it indicates that the evidence is relatively complete and consistent, and can be generated directly. This step sets a high preset first threshold for the credibility assessment result; once this threshold is reached, the claim is approved.

[0121] Understandably, the credibility assessment result of the candidate claim information is compared with a preset first threshold. When the credibility assessment result is greater than or equal to the preset first threshold, the generation constraint of the candidate claim information is determined to be allowed to generate, allowing the emergency response agent to directly generate the content corresponding to the candidate claim information.

[0122] Among them, the preset first threshold is the threshold used to determine whether candidate claim information is allowed to be generated; allowing generation means allowing the emergency response agent to directly generate the corresponding content of the candidate claim information.

[0123] S36, if the credibility assessment result reaches the preset second threshold but does not reach the preset first threshold, the generated constraint condition is generated by probability.

[0124] It should be noted that when the credibility assessment result of a claim is at an intermediate level, it indicates that there is some evidence but it is not sufficient. At this time, it cannot be directly approved, nor can it be completely blocked.

[0125] Understandably, the credibility assessment results of the candidate claim information are compared with the preset second threshold and the preset first threshold respectively. When the credibility assessment result is greater than or equal to the preset second threshold and less than the preset first threshold, the generation constraint of the corresponding candidate claim information is determined to be probabilistic generation. When generating the content corresponding to the candidate claim information, a confirmation mark is added to prompt the operation and maintenance personnel to verify the content.

[0126] The preset second threshold is a threshold used to determine whether candidate claim information is generated probabilistically, and the preset second threshold is less than the preset first threshold; probabilistic generation refers to the generation constraint condition of adding a confirmation mark when generating the corresponding content of the candidate claim information.

[0127] S37, when the credibility assessment result does not reach the preset second threshold, the generated constraint condition is clarification.

[0128] It should be noted that when the credibility assessment result of a claim is low, it indicates a lack of sufficient evidence, and directly generating such a claim would introduce content that lacks basis.

[0129] Understandably, the credibility assessment result of the candidate claim information is compared with the preset second threshold. When the credibility assessment result is less than the preset second threshold, the generation constraint of the candidate claim information is determined to be clarification, and no content corresponding to the candidate claim information is generated. Clarification questions are generated for the type of evidence missing in the candidate claim information, and the operation and maintenance personnel are consulted to supplement the corresponding evidence.

[0130] Clarification refers to generating constraints for clarification questions based on the types of evidence that are missing, rather than generating corresponding content for the candidate claims.

[0131] In some embodiments, S38-S40 are also included:

[0132] S38. Obtain evidence of the scope of impact, evidence of preconditions, evidence of rollback plan, and evidence of manual confirmation to form a risk evidence set.

[0133] It should be noted that actions such as restarting and deleting may affect system operation. Even with relatively complete evidence, it is necessary to further confirm the scope of impact, preconditions, rollback plan, and whether manual confirmation has been obtained. This step compiles these four pieces of evidence into a risk evidence set as an additional requirement for approving high-risk actions, setting stricter conditions for high-risk actions than ordinary claims.

[0134] Understandably, for action-related candidate claims, evidence is gathered including the scope of impact, preconditions, rollback plan, and manual confirmation. This four types of evidence form a risk evidence set. The scope of impact evidence indicates which components the action will affect; the preconditions evidence indicates the conditions that must be met before the action can be executed; the rollback plan evidence indicates the recovery method if the action fails; and the manual confirmation evidence indicates whether the action has been confirmed by operations personnel.

[0135] Among them, the scope of impact evidence refers to evidence indicating which components are affected by the action; the precondition evidence refers to evidence indicating that certain conditions must be met before the action can be performed; the rollback plan evidence refers to evidence indicating the recovery method after the action fails; and the manual confirmation evidence refers to evidence indicating whether the action has been confirmed by the operations and maintenance personnel.

[0136] S39, when the action-type candidate claim information is determined to be a preset high-risk action step, and the action-type candidate claim information satisfies all the evidence in the risk evidence set, the generated constraint condition is allowed to be generated.

[0137] Understandably, the process begins by determining whether the candidate action step corresponding to the action-type candidate claim falls under the pre-defined high-risk action steps. These pre-defined high-risk action steps include actions such as restarting, switching, cleaning, deleting, scaling up, downgrading, modifying configurations, batch recovery, and permission changes. If the action step corresponding to the action-type candidate claim falls under the pre-defined high-risk action steps, the process further determines whether the claim satisfies all the evidence in the risk evidence set. When the evidence of the scope of impact, the evidence of preconditions, the evidence of the rollback plan, and the evidence of manual confirmation are all satisfied, the generation constraint is determined to be allowed.

[0138] Among them, the pre-set high-risk handling steps refer to the pre-set handling steps that may affect the large-scale operation of the system after execution.

[0139] S40, if the action-type candidate claim information is determined to be a preset high-risk action step, and the action-type candidate claim information does not satisfy all the evidence in the risk evidence set, the generated constraint is interception.

[0140] Understandably, referring to step S39, when any one of the evidences in the risk evidence set is not satisfied, the generation constraint will be determined as interception, no action will be generated corresponding to the candidate claim information of that action type, and the missing evidence will be notified to the operation and maintenance personnel.

[0141] Interception refers to the constraint condition that prevents the generation of content corresponding to the candidate claim information.

[0142] S4. Based on the generation constraints, control the emergency response agent to generate emergency response content, perform reverse verification on the emergency response content, and output a reliable response result.

[0143] It should be noted that after determining the generation constraints for each candidate claim, the emergency response agent generates emergency response content under these constraints. However, the agent may still generate content outside the constraints during the generation process. This step performs a reverse verification of the generated emergency response content to identify and remove any parts lacking a supporting chain of evidence.

[0144] Understandably, the process begins by controlling the emergency response agent to generate emergency response content based on the generation constraints of each candidate claim. For claims that are allowed to be generated, corresponding content is generated directly; for claims generated by probability, corresponding content is generated and a pending confirmation flag is added; for claims requiring clarification, clarification questions are generated; and for intercepted claims, no corresponding response action is generated. Next, the generated emergency response content is reverse-verified. It is re-parsed into target claim information, and the target entities are extracted. Each target entity is checked against the evidence chain constraint structure. Claims containing existing target entities are bound to corresponding evidence; non-existent target entities are deleted or rewritten. Finally, a credible response result is output.

[0145] Among them, emergency response content refers to the response content generated by the emergency response agent under the constraints of the generation conditions; reverse verification refers to the verification process of re-analyzing the generated emergency response content and determining whether the target body exists in the evidence chain constraint structure; and credible response result refers to the response result output after reverse verification of the emergency response content.

[0146] In some embodiments, step S4 involves reverse verification of the emergency response content to output a reliable response result, including S41-S44:

[0147] S41, parse the emergency response content to obtain the target claim information in the emergency response content and the target entity in the target claim information.

[0148] It should be noted that the emergency response content is a text generated by the emergency response agent. To check for any parts lacking evidence, this text needs to be broken down into individual claims, and the specific objects mentioned in each claim need to be extracted. This step parses the emergency response content to obtain the target claim information and the target entities within that target claim information.

[0149] Understandably, the emergency response content is divided into target claims according to the boundaries of the statements, and then the systems, components, tools, commands, personnel, thresholds, and paths mentioned in each target claim are extracted as target bodies. For example, from the target claim of restarting the order service, the component target body of order service and the command target body of restart are extracted.

[0150] Among them, the target assertion information refers to the fault judgment or handling action in the emergency response content obtained after analyzing the emergency response content; the target body refers to the system, component, tool, command, personnel, threshold and path mentioned in the target assertion information.

[0151] S42, when it is determined that the target exists in the evidence chain constraint structure, the corresponding evidence is bound to the target claim information.

[0152] Understandably, for each target entity, the evidence chain graph of the evidence chain constraint structure is searched to see if there is a node corresponding to the target entity. When there is a node corresponding to the target entity in the evidence chain graph, it is determined that the target entity exists in the evidence chain constraint structure. The target claim information of the target entity is bound to the evidence represented by the corresponding evidence node in the graph, so that the target claim information has its evidence source.

[0153] S43, if it is determined that the target does not exist in the evidence chain constraint structure, the target is deleted or rewritten.

[0154] Understandably, when a node corresponding to a certain target does not exist in the evidence chain graph, it is determined that the target does not exist in the evidence chain constraint structure, and the target is either deleted or rewritten. Deletion means removing the target claim information containing the target from the emergency response content; rewriting means rewriting the target as a field to be confirmed, prompting the operations and maintenance personnel that the target lacks evidence and needs to be verified.

[0155] S44, based on the target claim information bound to the corresponding evidence, outputs a credible disposal result.

[0156] Understandably, the target claim information that has been retained after reverse verification and is bound to corresponding evidence is aggregated to obtain a credible processing result. Each target claim information in this credible processing result has its corresponding source of evidence. Target claim information generated by probability is marked with a confirmation pending mark, and target bodies that have been rewritten as fields to be confirmed are given corresponding prompts. This credible processing result is then output to the terminal used by the operations and maintenance personnel.

[0157] See Figure 2 This is a schematic diagram of the structure of an emergency response intelligent agent trust generation system based on multi-source evidence chain constraints provided in an embodiment of the present invention. The system includes:

[0158] The construction module is used to acquire multi-source evidence data in response to emergency response requests and to construct a real-time fault profile based on the multi-source evidence data;

[0159] The constraint module is used to determine multiple candidate claim information based on the real-time fault profile and construct an evidence chain constraint structure.

[0160] The evaluation module is used to evaluate the credibility of each candidate claim information according to the evidence chain constraint structure, and generate constraint conditions based on the evaluation results and preset gating rules.

[0161] The verification module is used to control the emergency response agent to generate emergency response content based on the generation constraints, perform reverse verification on the emergency response content, and output a reliable response result.

[0162] See Figure 3 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention. The electronic device 30 includes: a processor 31, a memory 32, and a computer program; wherein...

[0163] The memory 32 is used to store the computer program, and the memory may also be flash memory. The computer program is, for example, an application program or functional module that implements the above method.

[0164] Processor 31 is configured to execute the computer program stored in the memory to implement the various steps performed by the device in the above method. For details, please refer to the relevant descriptions in the preceding method embodiments.

[0165] Alternatively, the memory 32 can be either standalone or integrated with the processor 31.

[0166] When the memory 32 is a device independent of the processor 31, the device may further include:

[0167] Bus 33 is used to connect the memory 32 and the processor 31.

[0168] The present invention also provides a readable storage medium storing a computer program, which, when executed by a processor, is used to implement the methods provided in the various embodiments described above.

[0169] The readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of computer programs from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application-Specific Integrated Circuit (ASIC). Alternatively, the ASIC can be located in a user equipment. Of course, the processor and the readable storage medium can also exist as discrete components in a communication device. The readable storage medium can be a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0170] The present invention also provides a program product including executable instructions stored in a readable storage medium. At least one processor of the device can read the executable instructions from the readable storage medium, and the at least one processor executes the executable instructions to cause the device to implement the methods provided in the various embodiments described above.

[0171] In the embodiments of the above-described device, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0172] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. An emergency disposal intelligent agent trustable generation method based on multi-source evidence chain constraint, characterized in that, include: Acquire multi-source evidence data in response to emergency response requests, and construct a real-time fault profile based on the multi-source evidence data; Based on the real-time fault profile, multiple candidate claim information is determined, and an evidence chain constraint structure is constructed; The credibility of each candidate claim is evaluated based on the chain of evidence constraint structure, and constraint conditions are generated based on the evaluation results and preset gating rules. Based on the aforementioned generation constraints, the emergency response agent is controlled to generate emergency response content, and the emergency response content is reverse-verified to output a reliable response result. The step of determining multiple candidate claim information based on the real-time fault profile includes: Based on the fault status to be verified in the real-time fault profile, the corresponding emergency plan component is retrieved from the preset plan component library; The fault state to be verified is identified as fault-type candidate claim information, and the candidate handling steps in the emergency plan component are identified as action-type candidate claim information, resulting in multiple candidate claim information; The construction of the evidence chain constraint structure includes: Based on the relationships between the information of each candidate's claims, multi-source evidence data, and emergency response plan components, an evidence chain diagram is constructed; Determine the evidence type corresponding to each piece of evidence in the multi-source evidence data, and construct a claim evidence coverage matrix based on the coverage status of each evidence type to each candidate claim information; The evidence chain diagram and the claim evidence coverage matrix are determined as the evidence chain constraint structure; The step of evaluating the credibility of each candidate claim information based on the chain of evidence constraint structure includes: The percentage of supporting evidence types among the required evidence types for each candidate's claim is used to obtain the evidence coverage. Calculate the number of pieces of evidence corresponding to the same candidate claim information to obtain the multi-source consistency degree; The number of conflicting evidence types in each candidate claim is counted to obtain the conflict value. Calculate the sum of the evidence coverage and the multi-source consistency, and subtract the conflict value from the obtained sum to obtain the credibility assessment result of each candidate claim information.

2. The method according to claim 1, characterized in that, The construction of a real-time fault profile based on the multi-source evidence data includes: The multi-source evidence data is standardized to obtain evidence units; Based on the component relationships of the target system in the emergency response request, the evidence units are spliced ​​together to obtain a real-time fault profile.

3. The method according to claim 2, characterized in that, The standardization process of the multi-source evidence data to obtain evidence units includes: Field extraction and time alignment are performed on the multi-source evidence data to obtain evidence units; The evidence units are marked with evidence polarity, which includes support, rebuttal, conflict, and expiration.

4. The method according to claim 1, characterized in that, The generation of constraints based on the evaluation results and preset gating rules includes: When the credibility assessment result reaches a preset first threshold, the generated constraint condition is set to allow generation. When the credibility assessment result reaches the preset second threshold but does not reach the preset first threshold, the generated constraint condition is generated by probability. When the credibility assessment result fails to reach the preset second threshold, the generated constraint condition is clarification.

5. The method of claim 4, wherein, Also includes: Obtain evidence of the scope of impact, evidence of preconditions, evidence of rollback plans, and evidence of manual confirmation to form a risk evidence set; When the action-type candidate claim information is determined to be a preset high-risk action step, and the action-type candidate claim information satisfies all the evidence in the risk evidence set, the generated constraint condition is to allow generation. If the action-type candidate claim information is determined to be a preset high-risk action step, and the action-type candidate claim information does not satisfy all the evidence in the risk evidence set, the generated constraint is interception.

6. The method according to claim 5, characterized in that, The reverse verification of the emergency response content and the output of a reliable response result include: The emergency response content is analyzed to obtain the target claim information in the emergency response content and the target entity in the target claim information; When it is determined that the target entity exists in the chain of evidence constraint structure, the corresponding evidence is bound to the target claim information; If it is determined that the target does not exist in the chain of evidence constraint structure, the target is deleted or rewritten. Based on the target claim information bound to the corresponding evidence, a credible disposal result is output.

7. A trusted generation system for emergency response intelligent agents based on multi-source evidence chain constraints, characterized in that, include: The construction module is used to acquire multi-source evidence data in response to emergency response requests and to construct a real-time fault profile based on the multi-source evidence data; The constraint module is used to determine multiple candidate claim information based on the real-time fault profile and construct an evidence chain constraint structure; The evaluation module is used to evaluate the credibility of each candidate claim information according to the evidence chain constraint structure, and generate constraint conditions based on the evaluation results and preset gating rules. The verification module is used to control the emergency response agent to generate emergency response content based on the generation constraints, perform reverse verification on the emergency response content, and output a reliable response result. The step of determining multiple candidate claim information based on the real-time fault profile includes: Based on the fault status to be verified in the real-time fault profile, the corresponding emergency plan component is retrieved from the preset plan component library; The fault state to be verified is identified as fault-type candidate claim information, and the candidate handling steps in the emergency plan component are identified as action-type candidate claim information, resulting in multiple candidate claim information; The construction of the evidence chain constraint structure includes: Based on the relationships between the information of each candidate's claims, multi-source evidence data, and emergency plan components, an evidence chain diagram is constructed; Determine the evidence type corresponding to each piece of evidence in the multi-source evidence data, and construct a claim evidence coverage matrix based on the coverage status of each evidence type to each candidate claim information; The evidence chain diagram and the claim evidence coverage matrix are determined as the evidence chain constraint structure; The step of evaluating the credibility of each candidate claim information based on the chain of evidence constraint structure includes: The percentage of supporting evidence types among the required evidence types for each candidate claim is used to obtain the evidence coverage. Calculate the number of pieces of evidence corresponding to the same candidate claim information to obtain the multi-source consistency. The number of conflicting evidence types in each candidate claim is counted to obtain the conflict value. Calculate the sum of the evidence coverage and the multi-source consistency, and subtract the conflict value from the obtained sum to obtain the credibility assessment result of each candidate claim information.

Images