A multi-source information fusion fault diagnosis method for drilling simulation training

Abstract

The application provides a kind of multi-source information fusion fault diagnosis method for drilling simulation training, it is related to petroleum drilling fault diagnosis technical field, the method is to obtain the multi-source information data and historical database of drilling simulation, by preprocessing, respectively get the initial item of task blackboard and structured analysis result;Based on multi-source information data and structured analysis result, respectively get structured evidence list, environmental reasoning result and historical case result, for building node and edge, get dynamic evidence consensus graph;Through multi-hop propagation and consensus generation to dynamic evidence consensus graph, get fusion diagnosis result;Based on fusion diagnosis result, carry out fault diagnosis interpretation to input key element, get repair guide;Using feedback cycle and knowledge updating intelligent agent, monitor and update repair guide, get multi-source information fusion fault diagnosis result.The application solves the problem that accurate fault diagnosis is difficult in existing drilling simulation.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of oil drilling fault diagnosis, and in particular, to a multi-source information fusion fault diagnosis method for drilling simulation training. BACKGROUND

[0002] A drilling simulator is a software / hardware combined training system that simulates the equipment state and operation process of an actual drilling site. A trainee can perform operations such as “drilling” “stopping drilling” “adjusting pump speed” in the simulator, and the simulator will give a corresponding “snapshot” containing real-time parameters such as well depth, pump pressure, and drilling pressure. The simulator is used for drilling trainee training and fault drilling. The steps include: running in / drilling down: sending the drill bit to a deeper place. Pull out / trip out: pulling the drill bit out of the downhole. Circulation: mud circulates up and down in the well to remove drill cuttings and balance the well pressure. Cementing: cement is poured between the casing and the well wall to fix the casing and the packer. Each step has corresponding parameters to be monitored, and incorrect operation or failure will cause “stuck pipe” “well kick” and other on-site accidents.

[0003] Common faults include: stuck pipe: the drill string is clamped by the clamp, and cannot move up and down freely. Loss of circulation: mud seeps into the formation, causing imbalance of well pressure. Well kick / blowout: formation fluid enters the well, causing abnormal pressure rise. Pump failure: mud pump failure causes pump pressure to drop or become unstable. Limitations of manual diagnosis: experience dependence: field engineers rely on experience to judge, but experience is limited and different people may have different conclusions. Difficulty in integrating multi-source information: evidence of failure may come from manuals (written rules), real-time parameters, and historical cases, and it is difficult for humans to quickly weigh these heterogeneous evidence. Need for repeatable and teachable diagnosis process: in training, trainees want to see the traceable process of “why this judgment, what steps were taken, and what the results were”.

[0004] Common implementation components in this field (explanation at the engineering implementation level): (1) Deployment and interface of LLM: Cloud services (OpenAI, Anthropic, etc.) or local deployment (open source models such as Llama3) can be used to provide parsing and generation capabilities. The key is to ensure that the latency is within an acceptable range for teaching scenarios. (2) Rule base and symbolic reasoning: For real-time environmental variables (WOB, RPM, pump pressure, etc.), many diagnoses still rely on well-defined rules (e.g., "when pump_on = true and RPM is normal and there is no movement below, suspect a stuck drill"). These rules serve as the operating criteria within the simulator and perform numerical threshold judgments more reliably than LLM.

[0005] Existing single methods are insufficient to meet the dual needs of teaching and reliable diagnosis: (1) Rule-driven methods: are powerless against text, fuzzy expressions or complex semantics. (2) LLM-driven methods: lack verifiability, numerical accuracy and long-term self-learning mechanisms. (3) Methods based solely on historical student learning cases: have inconsistent quality, a large amount of redundancy, are difficult to retrieve, and are easily misled by outdated or unverifiable cases. Summary of the Invention

[0006] To address the aforementioned shortcomings in existing technologies, this invention provides a multi-source information fusion fault diagnosis method for drilling simulation training, which solves the problem of difficulty in accurate fault diagnosis in existing drilling simulations.

[0007] To achieve the aforementioned objectives, the present invention employs the following technical solution: a multi-source information fusion fault diagnosis method for drilling simulation training, comprising:

[0008] S1: Obtain multi-source information data and historical databases from drilling simulations, and obtain initial entries for the task blackboard and structured parsing results through preprocessing;

[0009] S2: Based on multi-source information data and structured analysis results, structured evidence lists, environmental reasoning results, and historical case results are obtained through information extraction.

[0010] S3: Based on the structured evidence list, environmental reasoning results, and historical case results, construct nodes and edges to obtain a dynamic evidence consensus graph;

[0011] S4: By performing multi-hop propagation and consensus generation on the dynamic evidence consensus graph, a fusion diagnostic result is obtained;

[0012] S5: Based on the fusion diagnostic results, perform fault diagnosis and interpretation on the key input elements to obtain repair guidelines;

[0013] S6: Monitor and update the repair guide using the feedback loop and the knowledge updating agent, obtain the multi-source information fusion fault diagnosis result, and complete the diagnosis of the multi-source information fusion fault.

[0014] The beneficial effects of the present application are: the present application provides a multi-source information fusion fault diagnosis method for drilling simulation training, by introducing a context-enhanced intention analysis mechanism, when analyzing user problems, not only relying on the current statement, but also fusing the recent 3-5 rounds of dialogue history, and setting a confidence threshold (>=0.8) to trigger a counter-question clarification. The traditional RAG system only relies on static knowledge retrieval, which is easy to ignore real-time working conditions and historical experience. The present scheme concurrently enables knowledge retrieval, environment reasoning and historical case three-way agents, and constructs a dynamic evidence consensus graph (DECG), which maps the operation manual rules, the simulator state symbolic logic and the real student cases to the same semantic vector space. On this basis, the confidence weighted graph attention propagation and conflict debate mechanism is adopted, so that the large model can be automatically called for expert-type reasoning when there is contradictory evidence. Strictly quote the evidence source in the fusion chain (such as "based on operation manual rules and intermediate student successful cases"), and clearly mark the expected parameter change (such as "P_pump return to 12MPa"). This source-transparent and step- verifiable output method enables students not only to perform operations, but also to understand the underlying engineering logic. Through the feedback loop and the knowledge updating agent, successful experience can be automatically converted into new historical cases (match_score>0.8, stored in the database), and failed cases can be automatically generated into new verifiable rules (initial evidence_conf=0.6).

[0015] Further, the S1 comprises:

[0016] Obtain multi-source information data of drilling simulation, and obtain initial task blackboard entries through text cleaning;

[0017] Based on the historical database, the structured analysis result is obtained through the intention analysis and clarification mechanism.

[0018] Further, the obtaining multi-source information data of drilling simulation, and obtaining initial task blackboard entries through text cleaning comprises:

[0019] Obtain natural language description, simulator snapshot and student metadata; wherein the natural language description, simulator snapshot and student metadata belong to multi-source information data;

[0020] Remove stop words and correct spelling from the natural language description to obtain a standardized problem text;

[0021] Based on the standardized problem text, the simulator snapshot and the student metadata, the task identifier is generated for correspondence to obtain the initial task blackboard entries.

[0022] Introducing intent completion (combined with dialogue history H) + terminology recognition + confidence filtering + question clarification mechanism to ensure the semantic accuracy of the initial entries on the task blackboard.

[0023] Furthermore, the structured parsing results obtained by processing the historical database through intent parsing and clarification mechanisms include:

[0024] Based on the historical database, the context set is obtained by querying the dialogue records associated with the current student;

[0025] By using a large language model to analyze the context set, we can obtain the user's complete intent, the identification results of key domain elements, and the resolution confidence.

[0026] By utilizing confidence filtering and question clarification mechanisms, the user's complete intent, the identification results of key domain elements, and the resolution confidence are processed to obtain structured resolution results.

[0027] The system concurrently launches a historical case retrieval agent, which embeds the user's intent together with the sequence of the most recent N steps to retrieve similar historical cases. It also introduces a time decay factor and a weighted matching of the student's level to evaluate the applicability of the cases and realize personalized experience reuse.

[0028] Further, S2 includes:

[0029] S210: Retrieve and generate the structured analysis results to obtain a list of structured evidence;

[0030] S220: Extract information from simulator snapshots in multi-source information data to obtain environmental inference results;

[0031] S230: Based on the initial entries of the task blackboard and simulator snapshots in multi-source information data, historical case results are obtained through vector similarity retrieval.

[0032] Further, S210 includes:

[0033] Construct a retrieval query vector using the structured parsing results;

[0034] Vector similarity retrieval is performed on the search query vector, and the large language model is used for analysis to obtain evidence summary, verifiable rules, and rule confidence.

[0035] The evidence summary, verifiable rules, and rule confidence are structured to obtain a structured evidence list.

[0036] Further, S220 includes:

[0037] Information is extracted from simulator snapshots in multi-source information data to obtain the latest environmental status data;

[0038] Build a working condition rule base;

[0039] The latest environmental status data is matched with the operating condition rule base to obtain preliminary matching results;

[0040] Using a large language model, the preliminary matching results are analyzed to obtain the causal inference chain and confidence level;

[0041] The causal reasoning chain and confidence level are structured to obtain the environmental reasoning results.

[0042] An independent environmental reasoning agent was designed to directly extract symbolic state variables from simulator snapshot S and match them with the working condition rule base to generate causal chains, thereby achieving "numerical + semantic" dual-driven reasoning.

[0043] Further, S230 includes:

[0044] Based on the initial entries of the task blackboard and simulator snapshots from multi-source information data, construct composite query content;

[0045] By constructing a historical case vector index library, vector similarity retrieval is performed on composite query content to obtain candidate cases;

[0046] Based on candidate cases, time decay factor calculation and grade matching weighting are performed to obtain comprehensive search cases;

[0047] Using a large language model, we analyze comprehensive retrieval cases, initial entries on the task blackboard, and simulator snapshots from multi-source information data to obtain historical case results.

[0048] In the historical case retrieval agent, a time decay factor exp(-λ•Δdays) and a student level matching weight are introduced, and the model is required to evaluate the applicability of the case to the current situation (0–1) and the reason, so as to ensure the relevance and safety of the recommendation.

[0049] Further, S3 includes:

[0050] Graph nodes are constructed using a structured list of evidence, environmental reasoning results, and historical case results;

[0051] Construct the root node of user intent;

[0052] Based on the graph nodes and the user intent root node, traverse the graph and dynamically construct edges between nodes;

[0053] Based on graph nodes, user intent root nodes, and edges between nodes, a graph is constructed to obtain a dynamic evidence consensus graph.

[0054] Furthermore, the expression for the edge between the nodes is:

[0055] ;

[0056] ;

[0057] in, This represents the cosine similarity of feature vectors between nodes. express node, express node, This represents the feature vector obtained by encoding the text information contained in node A using a vector embedding model. This represents the feature vector obtained by encoding the text information contained in node B using a vector embedding model. The vector magnitude of the eigenvector is represented by the length of the vector. Represents edge weight, Represents the balance coefficient. This represents the support value corresponding to whether there is a clear logical consistency relationship between node A and node B.

[0058] Further, S4 includes:

[0059] By performing multi-hop attention propagation on the dynamic evidence consensus graph, the current layer neighbor nodes are collected, the attention weights are calculated, and a new consensus vector is obtained.

[0060] Based on the new consensus vector, consensus conflicts are monitored and a debate mechanism is triggered to generate consensus and obtain fusion diagnostic results including fusion confidence.

[0061] A Dynamic Evidence Consensus Graph (DECG) is proposed, which transforms knowledge evidence, environmental reasoning, and historical cases into graph nodes, constructs edges based on semantic similarity and logical association, and performs multi-hop consensus fusion through graph traversal agents, and even triggers "consensus debate" to resolve conflicts, and finally outputs a ranking hypothesis with fusion confidence.

[0062] Furthermore, the expression for the new consensus vector is:

[0063] ;

[0064] ;

[0065] in, This represents the current consensus vector generated during the t-th multi-hop propagation process. This represents the attention weight value contributed by the i-th node to the current consensus vector during the t-th propagation. This represents the feature vector corresponding to the i-th neighbor node. This represents the node confidence score corresponding to the i-th node (this confidence score is derived from the credibility of the evidence, the credibility of the reasoning, or the applicability of the case). Represents cosine similarity. This represents the consensus vector generated in the previous round of propagation. This represents the node confidence level corresponding to the j-th node. This represents the feature vector corresponding to the j-th neighbor node. This represents the preset smoothing control parameter, used to adjust the dispersion of the attention weight distribution.

[0066] Furthermore, the expression for the fusion confidence is:

[0067] ;

[0068] in, This represents the confidence level of the final fusion diagnosis. This refers to the set of nodes that provide positive support for the same fault hypothesis or diagnostic conclusion during the final consensus phase. This represents the attention weight value corresponding to the i-th supporting node in the final propagation round T. This represents the final effective confidence value of the i-th supporting node after consensus propagation is completed.

[0069] Further, S5 includes:

[0070] Based on the fusion diagnostic results and key input elements, the main fault hypotheses are obtained;

[0071] Based on the main fault assumptions, an intent confirmation statement is generated using a large language model.

[0072] By using reasoning chains to interpret intent confirmation statements for fault diagnosis, and through step-by-step repair guidance, a repair guide is obtained.

[0073] Further, S6 includes:

[0074] Asynchronous feedback monitoring is used to perform cyclical implicit behavioral feedback monitoring and explicit negative feedback monitoring on the response process of the repair guide, and the monitoring results are obtained.

[0075] When the monitoring results show failure, the system constructs reflection prompts and injects knowledge vector indexes for updating, obtains multi-source information fusion fault diagnosis results, and completes the diagnosis of multi-source information fusion faults.

[0076] The design incorporates a feedback loop and a knowledge-updating agent to monitor subsequent student actions (S'). If the fix is ​​successful, a new high-quality case is added; if it fails, a new "verifiable rule" is generated and injected into the retrieval index with low confidence, thus achieving continuous adaptive evolution. Attached Figure Description

[0077] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0078] Figure 1 This is an exemplary flowchart illustrating a multi-source information fusion fault diagnosis method for drilling simulation training, according to some embodiments of this specification. Detailed Implementation

[0079] The specific embodiments of the present invention are described below to enable those skilled in the art to understand the present invention. However, it should be understood that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the present invention as defined and determined by the appended claims. All inventions utilizing the concept of the present invention are protected.

[0080] Example

[0081] Figure 1 This is an exemplary flowchart illustrating a multi-source information fusion fault diagnosis method for drilling simulation training, according to some embodiments of this specification. Figure 1 As shown, the process includes the following steps. In some embodiments, the process may be executed by a processor.

[0082] S1: Obtain multi-source information data and historical databases from drilling simulations, and obtain initial entries for the task blackboard and structured parsing results through preprocessing.

[0083] Multi-source information data refers to data acquired synchronously upon receiving a question-and-answer request from a student. For example, multi-source information data includes natural language descriptions, simulator snapshots, and student metadata.

[0084] The historical database is a database of student questions and answers.

[0085] The initial entries on the task blackboard are key-value pairs and contain at least the following information: task ID (task_id), cleaned user question text (Q_clean), structured state snapshot (S) obtained from the drilling simulator, trainee metadata (U), task status (initially set to "initialized"), and the timestamp of task creation.

[0086] The structured parsed result, Parsed_Q, expresses the user's complete intent (e.g., "mechanical jamming occurred during drilling") in structured data form, identifying relevant technical terms (e.g., "stuck drill string," "drill string," "wellbore"), key parameters (e.g., "drill pressure," "pump pressure," "mud flow rate"), and involved technological processes (e.g., "running drill string"). It also includes a confidence score (e.g., 0.92) to reflect the reliability of the parsed result and is associated with the result of the unique identifier task_id for the current task. This Parsed_Q structure is written to the blackboard data area, serving as the unified semantic foundation and input for all subsequent collaborative work of all agents.

[0087] In some embodiments, the processor can acquire multi-source information data from drilling simulations, obtain initial entries for the task blackboard through text cleaning, and process the data based on a historical database through intent parsing and clarification mechanisms to obtain structured parsing results.

[0088] In some embodiments, the processor can acquire natural language descriptions, simulator snapshots, and student metadata; perform stop word removal and spell correction on the natural language descriptions to obtain standardized question text; and based on the standardized question text, simulator snapshots, and student metadata, generate task identifiers to match them and obtain initial entries for the task blackboard.

[0089] The natural language description Q is the raw question string entered by the student through the text interface, such as: "What should I do if I get stuck while drilling?".

[0090] The simulator snapshot S is a record of the most recent N operation steps (N is a preset positive integer, typically 5 to 10) pulled from the real-time interface of the oil drilling simulator. Each operation step includes a timestamp, operation type (such as "start mud pump", "lower drill string"), operation parameters (such as setting the drilling pressure value), and operation result status; it also includes the latest set of environmental state variables, including but not limited to: drilling pressure (Weight on Bit, WOB), rotation speed (Revolutions Per Minute, RPM), pump pressure (P_pump), mud flow rate, tool status (such as "rotating", "stationary", "stuck"), etc.

[0091] The student metadata U is structured information stored in the user database, including the student's unique identifier user_id, training level (such as beginner / intermediate / advanced), major, and distribution of historical error types.

[0092] In some embodiments, the processor may call the large model llama3 to perform the following preprocessing operations on the original Q: Remove stop words: Fill the prompt with a pre-built Chinese stop word list (including meaningless words such as "de", "le", "qing wen", etc.) to filter out redundant words that do not affect the semantics; Spelling correction: Correct obvious typos (e.g., correct "wellbore expansion drilling" to "wellbore expansion"); Obtain the cleaned and standardized question text Q_clean.

[0093] In some embodiments, the processor may call a globally unique identifier generator (e.g., the UUID algorithm based on the combination of timestamp and random number) to generate a unique task identifier task_id for the current Q&A task. Subsequently, construct an initial blackboard entry, which adopts a key-value pair structure and contains at least the following information: task ID (task_id), the cleaned user question text (Q_clean), the structured state snapshot (S) obtained from the drilling simulator, the trainee's metadata (U), the task status (initially set to "initialized"), and the timestamp when the task was created. This entry is written into the blackboard data area in the shared memory as the unified context for this task, for all subsequent agents to read concurrently and update collaboratively.

[0094] In some embodiments, the processor may, based on the historical database, query the conversation records associated with the current trainee to obtain the context set; use the large language model to analyze the context set to obtain the user's complete intention, the recognition results of domain key elements, and the parsing confidence; use the confidence filtering and rhetorical clarification mechanism to process the user's complete intention, the recognition results of domain key elements, and the parsing confidence to obtain the structured parsing result.

[0095] The context set H contains the last 3 to 5 rounds (the number can be configured) of complete Q&A pairs, each pair including: the trainee's question text, the system's response text, and the set of corresponding task_id and timestamp.

[0096] In some embodiments, the processor may query the most recent conversation records associated with the current trainee user_id from the trainee Q&A historical database to construct the context set H; Time window limit: Only select the conversations that do not exceed a preset threshold (e.g., 10 minutes) from the current request time to avoid introducing irrelevant history; Concatenate the context: Arrange the Q&A in H in reverse chronological order and concatenate them with the current cleaned question Q_clean to form the structured prompt context C = [H1, H2,..., Hk, Q_clean]. Example: If the trainee said "I am running the drill string" in the previous round and asked "Why is it stuck?" in this round, then C contains this historical statement, enabling the model to associate the causal relationship between "running the drill string" and "stuck".

[0097] In some embodiments, the processor can input the context C into the open-source large language model Llama3 and guide it to output the following three types of structured information through preset structured prompt templates: complete user intent, identification results of key domain elements, and resolution confidence. For example, the prompt could be: "You are an oil drilling expert assistant. Based on the following dialogue history and current question, please output: (1) complete user intent; (2) identified technical terms, key parameters, and process steps; (3) your resolution confidence (0–1). Return only in JSON format."

[0098] The user's complete intent includes semantics that the model needs to complete, such as omissions or unclear references. For example, "stuck" is parsed as "the drill string experienced mechanical jamming during drilling." The output format is a natural language sentence that explicitly includes the process steps, the object equipment, and the abnormal phenomenon.

[0099] The domain key element identification results include the following three types of structured labels that the model needs to extract from Q_clean and H: technical terms: such as "wellbore enlargement", "mud weight loss", "blowout preventer shutdown"; key parameters: such as "drill pressure", "pump pressure", "rotation speed", "mud density"; and process steps: such as "running in", "pulling out", "circulation flushing", "cementing operation". The output is three lists: terms: [str], parameters: [str], procedures: [str].

[0100] The analytical confidence score requires the model to self-assess based on its internal probability distribution, outputting a value between 0 and 1, representing the overall credibility of the analytical results. This confidence score comprehensively considers terminology matching, contextual consistency, and question clarity.

[0101] In some embodiments, the processor can judge the confidence_score returned by the model: If confidence_score ≥ 0.8 (threshold is configurable): accept the parsing result, and output the complete intent, terminology list, parameter list, and process step list as structured output, denoted as Parsed_Q, and proceed to the context set acquisition process. If confidence_score < 0.8: trigger the question clarification sub-process, specifically as follows: input the original context C and the model's preliminary parsing result (including uncertain parts) back into Llama3; use special prompts to request the model to generate concise, closed-ended clarification questions, focusing on the points of ambiguity, such as: "Do you mean the mud pump outlet pressure is rising, or the wellhead back pressure is rising?" "Did the jam occur during the running-in stage or the tripping-out stage?" return the clarification question to the student terminal and pause the subsequent process; after the student inputs a clarification answer, append it to the end of context C to form a new context C′; re-execute the intent parsing process of this step until confidence_score ≥ 0.8 or the maximum number of clarification rounds (e.g., 2 times).

[0102] S2: Based on multi-source information data and structured analysis results, information extraction is used to obtain a list of structured evidence, environmental reasoning results, and historical case results.

[0103] A structured evidence list is a knowledge evidence entry. Each entry contains the original document identifier (doc_id), a refined core content summary (snippet), a verifiable conditional-action rule (verifiable_rule), a semantic similarity score to the user's question (sim_score), the confidence level of the evidence (evidence_conf), and the source type (e.g., "user manual"). All K such evidence entries are aggregated into a structured list Evidence_List, containing K knowledge evidence entries, each with fields such as snippet, verifiable_rule, evidence_conf, and origin_type, and written to the blackboard data area for subsequent evidence fusion agent to read and use.

[0104] The environmental inference result is the most probable fault type (e.g., "mechanical stuck"), accompanied by a causal inference chain derived from the observed state (e.g., "drill pressure rises to a high level, tool status indicates jamming, while mud flow remains normal → typical behavior of mechanical stuck"). It also includes the confidence score of the inference (e.g., 0.93), the matched operating condition rule number (e.g., "stuck_pipe_01"), the current symbolic environmental state (including discretized values ​​of variables such as drill pressure, rotational speed, pump pressure, tool status, and mud flow), and the associated task identifier (task_id). The environmental inference result, Env_Result, contains fault_label, reasoning_chain, env_confidence, and symbolic_state. These objects are written to the blackboard data area as an important input source for the subsequent evidence fusion agent.

[0105] Historical case results include a unique case identifier (case_id), extracted core handling steps (key_steps), expected changes in key parameters after execution (expected_delta, such as pump pressure dropping to 12MPa, drilling pressure dropping to 80kN), the original case's handling outcome (outcome, such as "success"), the applicability score between the current situation and the case (relevance_score), and the scoring basis (reason, such as pointing out that the fault phenomena are highly consistent but the well depth differs). In addition, it records the original operator's training level (original_level), the current user level (current_user_level), the semantic similarity between the case and the current problem (sim_score_case), the time decay-based weighting factor (decay_factor), and the associated task ID (task_id). All M such historical case entries are aggregated into a list Case_List, containing M case entries, each with fields such as key_steps, expected_delta, relevance_score, and outcome, and written to the blackboard data area for subsequent evidence fusion agent reading and comprehensive use.

[0106] In some embodiments, the processor may implement S2 based on the following steps.

[0107] S210: Retrieve and generate the structured analysis results to obtain a list of structured evidence.

[0108] In some embodiments, the processor can use the structured parsing results to construct a retrieval query vector; perform vector similarity retrieval on the retrieval query vector, analyze it using a large language model, and obtain an evidence summary, verifiable rules, and rule confidence; and perform structured processing on the evidence summary, verifiable rules, and rule confidence to obtain a structured evidence list.

[0109] The retrieval query vector is composed of the following four items concatenated into a single text string Q_query: the user's complete intent; all elements in the terminology list (terms), separated by commas; all elements in the parameter list (parameters); and all elements in the procedure list (procedures). Example: If Parsed_Q.intent = "Drill string mechanically jammed during drilling", terms = ["stuck drill string", "drill string"], parameters = ["drill pressure", "pump pressure"], procedure = ["drilling"], then Q_query = "Drill string mechanically jammed during drilling. Related terms: stuck drill string, drill string. Key parameters: drill pressure, pump pressure. Procedure: drilling."

[0110] Vectorization involves encoding the Q_query using a pre-trained unified embedding model (such as bge-large-zh) to generate a query vector v_q with fixed dimensions (such as 1024 dimensions).

[0111] In some embodiments, the processor can access a pre-built knowledge vector index library in the oil drilling field and perform the following operations: Knowledge Base Composition: Contains multi-source heterogeneous document fragments, including: chapters from the official Drilling Operations Manual; expert-written troubleshooting annotations; real-world case discussion posts from internal training forums; and relevant clauses from industry standards (such as API specifications). Each document fragment has been segmented into semantically complete paragraphs (length controlled between 200 and 500 characters) before being stored in the database, and annotated with metadata fields: doc_id (unique document identifier) ​​and origin_type (source type, enumerated values: operations manual / expert annotations / forum cases / industry standards). Index Structure: All paragraphs are encoded using the same embedding model and stored in an efficient approximate nearest neighbor (ANN) index structure (such as FAISS), supporting fast cosine similarity retrieval. Search process: Using v_q as the query vector, calculate its cosine similarity with all paragraph vectors in the index; return the Top-K paragraphs with the highest similarity (K is a preset positive integer, typical value K=5); for each returned paragraph, record: doc_id, original text text, origin_type, similarity score sim_score (range [0,1]).

[0112] In some embodiments, for each retrieved Top-K paragraph, the processor inputs it along with Parsed_Q into Llama3, guiding the model to perform two structured tasks with dedicated prompts: (a) generating an evidence snippet: requiring the model to extract the core facts or conclusions most relevant to the current intent from the paragraph, compress them into concise sentences (≤50 words), and remove redundant background. Example input paragraph: "When the drilling pressure suddenly increases while the mud pump discharge is normal, if the drill string cannot continue to descend, the first priority should be to check for stuck drill bit or drill bit mud." Output snippet: "When the drilling pressure suddenly increases and the drill string cannot descend, the first priority should be to check for stuck drill bit or drill bit mud." (b) Generate verifiable rules or precautions (verifiable_rule) and rule confidence (evidence_conf): The model is required to generate a conditional-action rule or safety precaution based on the paragraph content and the current context, in the format: "When [state condition], [suggested action or risk warning]." At the same time, the model is required to evaluate the confidence level of the rule and output evidence_conf ∈ [0,1]. The calculation basis includes: paragraph source type weight (operation manual > expert annotation > forum case); paragraph and query sim_score; whether the rule contains explicit observable variables (e.g., "pump pressure > 20MPa" is better than "pressure abnormality"). Example output rule: "When pump_on == true && rpm_normal == true && downhole_motion == false, prioritize checking bit-bind and downhole jamming." evidence_conf = 0.88 (because the source is the user manual and the conditions are clear). Hint word constraint: Force the model to output {snippet, verifiable_rule, evidence_conf} in JSON format to avoid arbitrary interpretation.

[0113] S220: Extract information from simulator snapshots in multi-source information data to obtain environmental inference results.

[0114] In some embodiments, the processor can extract information from simulator snapshots in multi-source information data to obtain the latest environmental state data; construct a working condition rule base; match the latest environmental state data with the working condition rule base to obtain preliminary matching results; use a large language model to analyze the preliminary matching results to obtain causal reasoning chains and confidence levels; and perform structured processing on the causal reasoning chains and confidence levels to obtain environmental reasoning results.

[0115] In some embodiments, the processor can extract the latest environmental state data from the simulator snapshot S obtained in step 1 and perform symbolic transformation: the original state variable source: snapshot S contains the operation records and sensor readings of the current moment and the most recent N steps (N=5~10).

[0116] The latest environmental status data includes weight on bit (WOB), in kilonewtons (kN); revolutions per minute (RPM), in revolutions per minute; pump pressure (P_pump), in megapascals (MPa); mud flow rate (Q_mud), in liters per second; tool state (tool_state), enumerated values: {"rotating", "stationary", "stuck", "lifting"}; and auxiliary parameters such as mud density and well depth.

[0117] In some embodiments, the symbolic representation rules are used to map continuous numerical variables to discrete symbolic states according to a preset threshold interval, forming a symbolic state vector S_sym. For example, the final result can be S_sym = {“WOB: high”,“RPM: normal”, “P_pump: abnormal”, “tool_state: stuck”, …}. The symbolic representation rules are shown in Table 1.

[0118] Table 1 Symbolic Representation Rules

[0119]

[0120] The operating condition rule base is a pre-configured, structured set of operating condition rules used to identify typical faults or abnormal patterns based on the current symbolic simulator state.

[0121] Each rule in this rule base includes a unique identifier (rule_id), a corresponding fault label (fault_label), a trigger condition consisting of a Boolean logic expression, a natural language description of the rule's meaning, and a priority value indicating the rule's typicality. Rule source: Extracted from the internal operating logic rules of the drilling simulator; Condition expression: Uses Boolean logic combinations, supports AND / OR, and variable names strictly match the symbolic status fields; Priority: Reflects the rule's typicality among similar faults and is used for subsequent confidence weighting.

[0122] The initial matching results can include a list: Matched_Rules = [{fault_label, priority,condition_matched}, ...].

[0123] In some embodiments, the processor can match the symbolic state vector S_sym with the operating condition rule base one by one: for each rule, it determines whether all clauses in its condition are true in S_sym; if all are true, the rule is activated, and its fault_label and priority are recorded; multiple rules can be activated simultaneously (e.g., "stuck drill" and "mud bag" may coexist). The preliminary matching results are output.

[0124] In some embodiments, the processor may input the following information as context into Llama3: the user's complete intent; the symbolic state vector S_sym; and the list of activated Matched_Rules. The model is guided to perform the following tasks using specific prompts: (a) Generate a natural language causal inference chain: The model is required to integrate intent, state, and rules to generate a coherent causal explanation chain in the format: "[Observation A] + [Observation B] → may lead to [Fault C]." Example output: "Drilling pressure rises to a high level, tool status shows jamming, while mud flow remains normal → consistent with typical mechanical stuck drill bit behavior." (b) Output inference confidence (env_confidence): The model is required to self-assess confidence (0–1) based on the following factors: the highest priority value of the matching rule; state variable coverage (whether all key parameters are available); consistency between user intent and fault label (e.g., bonus points are awarded if intent contains "stuck" and fault_label is "stuck drill bit"). Hint word constraint: Force output in JSON format {reasoning_chain, fault_label, env_confidence}.

[0125] S230: Based on the initial entries of the task blackboard and simulator snapshots in multi-source information data, historical case results are obtained through vector similarity retrieval.

[0126] In some embodiments, the processor can construct composite query content based on the initial entries of the task blackboard and simulator snapshots in multi-source information data; perform vector similarity retrieval on the composite query content by constructing a historical case vector index library to obtain candidate cases; calculate the time decay factor and perform grade matching weighting based on the candidate cases to obtain comprehensive retrieval cases; and analyze the comprehensive retrieval cases, the initial entries of the task blackboard, and simulator snapshots in multi-source information data using a large language model to obtain historical case results.

[0127] The composite query consists of two parts concatenated into a single text string, Q_case: the user's complete intent; and a structured summary of the most recent N-step operation sequence. The format is: "Operation 1: Type → Result; Operation 2:…". For example: "Operation 1: Lower the drill string (WOB=120kN) → Normal; Operation 2: Start the mud pump (Q=30L / s) → Normal; Operation 3: Continue drilling → Jammed." Example: If intent = "Drill string mechanically jammed during drilling", and the operation sequence is ["Lower the drill string (WOB=130kN)", "Start the pump (Q=28L / s)", "Continue drilling → Jammed"], then Q_case = "Drill string mechanically jammed during drilling. Operation sequence: Lower the drill string (WOB=130kN) → Normal; Start the mud pump (Q=28L / s) → Normal; Continue drilling → Jammed."

[0128] In some embodiments, the processor can vectorize the Q_case using the same unified embedding model (such as bge-large-zh) as the knowledge retrieval module to generate the query vector v_c, ensuring semantic space consistency.

[0129] The candidate cases are the Top-M cases with the highest similarity.

[0130] In some embodiments, the processor can access a pre-built historical case vector index and perform the following operations: Case library composition: Cases are derived from real interaction records of past trainees in the same or similar drilling simulators. Each case includes: a unique identifier (case_id); the original problem and intent; the operation sequence (timestamp, operation type, parameters, result status); key status variable changes (delta_metrics, e.g., WOB from 80→140 kN, P_pump from 10→18 MPa); the final result label: success / fail; the repair step sequence (e.g., "1. Stop drilling; 2. Raise the drill string 1 meter; 3. Circulate mud for 10 minutes"); metadata: creation time (timestamp), operator level (beginner / intermediate / advanced), well type, etc. Index construction: Before each case is stored in the database, its "intent + operation sequence" fields are concatenated and encoded using the same embedding model, and stored in an efficient approximate nearest neighbor (ANN) index structure (e.g., FAISS). Retrieval process: Using v_c as the query vector, calculate the cosine similarity in the case index; return the Top-M cases with the highest similarity (M is a preset positive integer, typically M=5); for each returned case, record: case_id, step_sequence, delta_metrics, result, level, timestamp, and sim_score_case.

[0131] In some embodiments, to improve retrieval relevance, the processor applies a dynamic weight to each candidate case: time decay factor decay(t): Let the current time be t_now and the case creation time be t_case, then: decay(t) = exp( λ (t_now t_case)) where λ is the attenuation coefficient (typical value λ=0.01), ensuring that newer cases have higher weights. Student level matching weight_level: If the case operator's level is the same as the current student's U.level, then weight_level=1.2; if they are adjacent levels (e.g., intermediate vs. advanced), then weight_level=1.0; otherwise, weight_level=0.8. Overall search score adjustment: Although the sorting order is not changed, the above weights will be used for subsequent applicability evaluation to obtain the overall search cases.

[0132] In some embodiments, the processor can input the complete content of each Top-M case along with the current Parsed_Q and S into Llama3, and guide the model to perform the following tasks through dedicated prompts: (a) Extract structured case snippets: Output fields include: key_steps: simplified core repair steps (≤5 steps); expected_delta: expected changes in key parameters after execution (e.g., "P_pump should fall back to 12MPa"); outcome: original case result (success / fail). (b) Evaluate current applicability (relevance_score ∈ [0,1]) and justification: The model is required to determine whether the case is applicable to the current situation based on the following dimensions: the degree of matching between intent and fault type; the degree of overlap between current state variables and case delta_metrics; contextual differences such as well depth, formation, and equipment model; and whether the operator level matches. Example output format: relevance_score: 0.87. Reason: "The fault symptoms are highly consistent, and the parameter change trends match, but the current well depth is relatively shallow (2000m vs. case 3500m), which may affect the determination of the stuck point location." Hint word constraint: Force output in JSON format {case_snippet, relevance_score, reason}.

[0133] S3: Based on the structured evidence list, environmental reasoning results, and historical case results, construct nodes and edges to obtain a dynamic evidence consensus graph.

[0134] The dynamic evidence consensus graph is stored in the form of an adjacency list, containing: a set of nodes (Nodes): each node contains ID, type, feature vector, confidence, and metadata; a set of edges (Edges): each edge contains (node_A, node_B, weight); and a root node identifier: root_node_id = "node_intent". This DECG structure is written to the blackboard data area as input for the next step of graph traversal and consensus generation.

[0135] In some embodiments, the processor can construct graph nodes using a list of structured evidence, environmental reasoning results, and historical case results; construct user intent root nodes; traverse the graph nodes and user intent root nodes to dynamically construct edges between nodes; and construct a graph based on the graph nodes, user intent root nodes, and edges between nodes to obtain a dynamic evidence consensus graph.

[0136] Graph nodes are graph nodes transformed from evidence units. Each type of evidence corresponds to a node type and is assigned standardized attributes: (a) Knowledge Evidence Node (Type = "knowledge"), for each piece of evidence in Evidence_List: Node ID: node_k_{i} (i=1..K); Feature Text: concatenated snippet + verifiable_rule; Feature Vector: encoded using the same embedding model as in the retrieval stage, resulting in vi; Initial Confidence: evidence_conf; Metadata: origin_type, doc_id. (b) Environment Reasoning Node (Type = "environment"), for Env_Result (only one): Node ID: node_e_1; Feature Text: reasoning_chain; Feature Vector: embedded in this text, resulting in v_env; Initial Confidence: env_confidence; Metadata: fault_label, symbolic_state. (c) Historical case nodes (Type = "case"): For each case in Case_List: Node ID: node_c_{j} (j=1..M); Feature text: concatenated key_steps (connected with semicolons) + expected_delta description; Feature vector: embedded in this text, resulting in vj_case; Initial confidence score: relevance_score; Metadata: case_id, outcome, decay_factor. All nodes share the same embedding model to ensure that the feature vectors are in a unified semantic space.

[0137] The user intent root node includes a node ID: node_intent; feature text: the intent field output in step 1; feature vector: the embedding of this text, resulting in v_intent; type: "intent"; confidence level: 1.0 (considered as deterministic input). This node will serve as the logical starting point for DECG.

[0138] In some embodiments, the processor can traverse all node pairs (including the root node and other nodes) and decide whether to establish undirected edges and their weights based on two criteria: Criterion 1: Semantic similarity threshold. For any two nodes A and B, calculate the cosine similarity of their feature vectors; if sim_sem(A,B)>θ_sim (a preset threshold, typically θ_sim=0.7), then they are considered semantically related and an edge can be established. Criterion 2: Logical association rule (cross-source strong connection). Even if the semantic similarity does not reach the threshold, if a logical association in a specific domain is satisfied, an edge is still forcibly established and assigned a high weight: Knowledge. Environment: If the state condition (e.g., "WOB == 'high') contained in the verifiable_rule of the knowledge evidence perfectly matches the symbolic_state of the environment node, then add an edge with a base weight of 1.0. Example Environment: If the direction of change of key parameters in the expected_delta of the case (e.g., "P_pump ↓") is consistent with the abnormal direction of the current environment state (e.g., the current P_pump abnormally increases, while it decreases after the case is fixed), then it is considered logically supported, and an edge is added. Case Knowledge: If the key_steps of a case contains actions suggested by knowledge rules (such as "circulating mud"), then an associated edge is created. Edge weight calculation: If it is decided to create an edge, its weight is calculated. Where: α∈[0,1] is the balance coefficient (typical value 0.6); C_logic=1.0 (indicating strong logic support); for edges involving historical cases, multiply by the decay_factor and relevance_score of that case to reflect the decay of timeliness and applicability.

[0139] In some embodiments, the expression for the edge between nodes is:

[0140] ;

[0141] ;

[0142] in, This represents the cosine similarity of feature vectors between nodes. express node, express node, This represents the feature vector obtained by encoding the text information contained in node A using a vector embedding model. This represents the feature vector obtained by encoding the text information contained in node B using a vector embedding model. The vector magnitude of the eigenvector is represented by the length of the vector. Represents edge weight, Represents the balance coefficient. This represents the support value corresponding to whether there is a clear logical consistency relationship between node A and node B.

[0143] S4: By performing multi-hop propagation and consensus generation on the dynamic evidence consensus graph, a fusion diagnostic result is obtained.

[0144] The fusion diagnostic results include the primary fault hypothesis, fused confidence, consensus chain, recommended repair steps, uncertainty flag, and task ID. This result is written to the blackboard for use by the response generation module in subsequent step 8.

[0145] In some embodiments, the processor can collect neighboring nodes of the current layer and calculate attention weights by performing multi-hop attention propagation on the dynamic evidence consensus graph to obtain a new consensus vector; based on the new consensus vector, it can monitor consensus conflicts and trigger a debate mechanism to generate consensus and obtain a fusion diagnostic result containing fusion confidence.

[0146] The new consensus vector is a vector that incorporates information from highly confident and highly correlated neighbors.

[0147] In some embodiments, the processor can read the constructed Dynamic Evidence Consensus Graph (DECG) from the blackboard and perform the following initialization operations: Set the root node: using node_intent as the propagation starting point; Initialize the consensus vector c(0): directly using the root node's feature vector v_intent; Set hyperparameters: maximum propagation hops Tmax = 3 (typical value, to prevent excessive diffusion); temperature parameter τ = 1.0 (used for attention normalization); consensus convergence threshold. =0.2 (used for conflict score determination); maximum number of debate rounds Rmax=3.

[0148] In some embodiments, at the t-th hop (t=1,2,...,Tmax), the processor performs the following aggregation operation: Step A: Collect the current layer's neighbor nodes. For all nodes semantically related to the previous consensus vector (initially direct neighbors of the root node), obtain their: feature vector v_i; initial confidence γ_i∈[0,1] (original confidence from knowledge / environment / case); and edge weight w_i with the current consensus vector (from the DECG construction phase). Step B: Calculate the attention weights. For each neighbor node i, calculate its contribution weight to the current consensus. Step C: Aggregate to generate a new consensus vector, update the consensus vector, and obtain the new consensus vector.

[0149] In some embodiments, the expression for the new consensus vector is:

[0150] ;

[0151] ;

[0152] in, This represents the current consensus vector generated during the t-th multi-hop propagation process. This represents the attention weight value contributed by the i-th node to the current consensus vector during the t-th propagation. This represents the feature vector corresponding to the i-th neighbor node. This represents the node confidence score corresponding to the i-th node (this confidence score is derived from the credibility of the evidence, the credibility of the reasoning, or the applicability of the case). Represents cosine similarity. This represents the consensus vector generated in the previous round of propagation. This represents the node confidence level corresponding to the j-th node. This represents the feature vector corresponding to the j-th neighbor node. This represents the preset smoothing control parameter, used to adjust the dispersion of the attention weight distribution.

[0153] In some embodiments, after each propagation (or after the final t=Tmax), the processor evaluates whether there is high-confidence conflict evidence: Conflict detection method: Extract all nodes activated with high weight (a_i>0.3); if there are two or more nodes belonging to different fault labels (e.g., one pointing to "stuck drill" and the other pointing to "mud weightlessness"), and their original confidence scores are all ≥ 0.8, then they are judged as significant conflicts; calculate the conflict score. : Take the sum of the products of the confidence scores of conflicting nodes, if If the value is ≥0.64 (i.e., 0.8 × 0.8), a debate is triggered. The consensus debate submodule is started: the processor calls Llama3 to perform the following operations: Construct debate prompts: The core content of the conflicting nodes (such as knowledge rules, environmental chains, and case steps) is concatenated with the current simulator state S to generate a prompt: "Evidence A (from the operation manual) supports 'mechanical stuck drill bit' due to high drilling pressure and tool jamming; Evidence B (from historical cases) supports 'mud weightlessness leading to wellbore collapse' due to low mud density and large well depth. Current state: WOB = 140kN (high), Mud Density = 1.05g / cm³ (low), tool_state = stuck. Please determine which explanation is more likely based on the current working conditions and explain your reasoning." The debate conclusion is generated, requiring the model to output: the more likely failure hypothesis; supporting reasons; and a new fusion confidence adjustment suggestion. Update node confidence: Based on the debate results, the confidence of the conflicting nodes is adjusted (e.g., +0.05 for the winner, +0.05 for the loser). 0.1, but not less than 0.5). Iterative optimization: Using the corrected confidence, re-execute the multi-hop propagation (maximum Rmax = 3 rounds) until: conflict score < =0.2, or the maximum number of debate rounds is reached.

[0154] In some embodiments, after consensus propagation and conflict resolution are completed, the processor performs final integration: Extracting the dominant fault hypothesis: The most frequently occurring `fault_label` among all highly active nodes (a_i>0.2) is used as the primary diagnostic result. Calculating the fused confidence score `fused_conf`: A weighted average of the confidence scores of all nodes supporting the fault is calculated, with the weights representing their attention weights in the final hop. Constructing a comprehensive reasoning chain: Key statements from various sources of evidence are integrated and ordered according to causal logic, for example: "Combining the operation manual rules (prioritizing checking for stuck drill when drill pressure is high and tool is stuck), the current environmental state (WOB=high, tool_state=stuck), and successful case experience (upward + loop effective), it is determined to be mechanical stuck drill." Extracting a recommended repair step sequence: Core handling steps (key_steps) are extracted from cases with high confidence (high relevance_score) and successful results to form a recommended repair operation sequence. Before output, these steps undergo safety and applicability checks based on verifiable rules in the knowledge base, such as checking whether the current operating parameters meet the preconditions required by the rules. Simultaneously, the fusion confidence score (fused_conf) of the overall diagnosis is calculated. If this value is below 0.85, the diagnosis is considered to have significant uncertainty, and the uncertainty_flag is marked as true, indicating the need for further clarification or manual intervention. Finally, a structured diagnostic result is generated.

[0155] In some embodiments, the expression for the fused confidence score is:

[0156] ;

[0157] in, This represents the confidence level of the final fusion diagnosis. This refers to the set of nodes that provide positive support for the same fault hypothesis or diagnostic conclusion during the final consensus phase. This represents the attention weight value corresponding to the i-th supporting node in the final propagation round T. This represents the final effective confidence value of the i-th supporting node after consensus propagation is completed.

[0158] S5: Based on the fusion diagnostic results, perform fault diagnosis and interpretation on the key input elements to obtain repair guidelines.

[0159] The repair guide is based on the recommended repair step sequence (recommended_steps), which is then translated into specific action instructions. Each step should include precautions and expected parameter changes. For example, the first step, "Stop Drilling," is described as: "First, immediately stop all drilling activities." The second step, "Raise the Drill String 1 Meter," is detailed as: "Next, raise the drill string 1 meter, observing for any abnormal vibrations or system warnings." The third step, "Circulate Mud for 10 Minutes," is translated as: "Finally, start the mud circulation system and keep it running for at least 10 minutes to remove cuttings from the bottom of the well and restore wellbore cleanliness." Ultimately, the processor integrates the intent confirmation statement, diagnostic explanation, structured repair instructions, uncertainty flags, and task identifiers into a standard response object and outputs it in a specified format for display on the front-end interface or for subsequent process calls.

[0160] In some embodiments, the processor can obtain a primary fault hypothesis based on the fusion diagnostic results and key input elements; based on the primary fault hypothesis, generate an intent confirmation statement using a large language model; interpret the intent confirmation statement for fault diagnosis using a reasoning chain; and obtain a repair guide through step-by-step repair guidance.

[0161] In some embodiments, the processor can obtain key elements of user input (such as the described problem, specific environmental parameters, etc.) from the blackboard and combine them with the fusion diagnostic results to obtain the primary fault hypothesis.

[0162] Example of an intent confirmation statement: "Based on your description, we are concerned about the mechanical stuck drill problem encountered during drilling. Next, we will analyze the possible causes in detail and provide solutions."

[0163] In some embodiments, the processor can utilize the comprehensive reasoning chain `consensus_chain` constructed in step S4 to translate it into easily understandable language. Emphasis is placed on the types of evidence sources (operation manuals, historical cases, real-time data, etc.) to increase the credibility of the diagnosis. For example: "By comparing the rules in the operation manual (prioritizing checking for stuck drill bit when drill pressure is high and the tool is stuck), the current environmental state (WOB=high, tool_state=stuck), and historical cases that successfully handled similar situations, we determine that the most likely problem is mechanical stuck drill bit." Confidence level explanation: The fused confidence level `fused_conf` of the consensus vector is mentioned to help users understand the reliability of the diagnosis. For example: "Our diagnosis is based on multi-source evidence integration and has a high confidence level (91%), which increases the accuracy of the conclusion."

[0164] S6: Utilize feedback loops and knowledge-updating intelligent agents to monitor and update the repair guidelines, obtain multi-source information fusion fault diagnosis results, and complete the diagnosis of multi-source information fusion faults.

[0165] The multi-source information fusion fault diagnosis result includes a new verifiable_rule (format: "when [condition], [action / warning]"); the corresponding snippet (≤50 characters); and an initial confidence level evidence_conf = 0.6 (because the source is model-generated, not expert-confirmed).

[0166] Example output of multi-source information fusion fault diagnosis results:

[0167] {

[0168] "snippet": "When sticking occurs under low mud density, wellbore instability should be considered first."

[0169] "verifiable_rule": "When mud_density < 1.05 && tool_state == 'stuck', the regular unblocking operation should be paused, and the wellbore stability should be assessed first."

[0170] "evidence_conf": 0.65

[0171] }

[0172] In some embodiments, the processor can utilize asynchronous feedback monitoring to perform cyclic implicit behavioral feedback monitoring and explicit negative feedback monitoring on the response process of the repair guide, and obtain monitoring results; when the monitoring results show failure, a reflection prompt is constructed and an injected knowledge vector index is updated to obtain the multi-source information fusion fault diagnosis results, and the diagnosis of multi-source information fusion faults is completed.

[0173] The monitoring results include implicit behavioral feedback monitoring results and explicit negative feedback monitoring results, which are respectively divided into monitoring success and monitoring failure.

[0174] In some embodiments, the processor may perform the following operations immediately after generating the final response: Associate task_id: Bind the complete response structure (including intent_confirmation, diagnosis_explanation, structured repair_guidance, etc.) with the unique identifier task_id of the current task; Write to student history H: Append the question-and-answer pair to the dialogue history of the corresponding user_id in the user database, with fields including: timestamp: response generation time; question: original Q_clean; response: complete response JSON; task_id; primary_hypothesis; recommended_steps. This operation provides the data foundation for context-enhanced intent parsing.

[0175] In some embodiments, the processor may create an asynchronous background task indexed by task_id to continuously listen for the following two types of feedback signals: (a) Implicit behavioral feedback: monitoring subsequent state snapshots S′ of the simulator. Triggering conditions: After the response is sent, if the trainee continues to operate the simulator and generates a new snapshot (time window ≤ 10 minutes), the latest snapshot S′ is captured; Problem resolution judgment: Extract key state variables (WOB, RPM, tool_state, P_pump, etc.) from S′; Construct a “repaired state summary” text T_after, for example: “Tool state: rotating; WOB: 80kN (normal); P_pump: 12MPa (normal)”; Concatenate T_after with the repair guidance in step 8 to form the expected result description T_expected, for example: “After performing lift + loop, the tool should resume rotation and the pump pressure should drop”; Encode T_after and T_expected using a unified embedding model (such as bge-large-zh) respectively, and calculate the cosine similarity match_score; If match_score > 0.8, the problem is judged to be resolved (success). (b) Explicit negative feedback: Trainee active evaluation. Feedback Channel: Provide a "Valid / Invalid" button or a free text feedback box on the response interface; Triggering Condition: If the student clicks "Invalid" or enters text containing negative keywords (such as "useless", "wrong", "incorrect"), the knowledge correction process will be triggered.

[0176] Successful Case Storage: When the processor determines that a trainee's problem has been successfully resolved (i.e., marked as "success"), a new historical case entry is automatically generated and stored in the case database. This entry includes an automatically generated unique identifier (case_id, formatted as "auto_case_" followed by the current task ID), the corresponding fault hypothesis (intent), the complete operation sequence (including the most recent N simulator operations before the problem was triggered and the trainee's subsequent handling operations), changes in key parameters before and after the handling (delta_metrics, e.g., drilling pressure decreasing from 140 kN to 80 kN, tool status changing from "stuck" to "rotating," pump pressure decreasing from 18 MPa to 12 MPa), the sequence of repair steps used (step_sequence), the result marked as "success," the trainee's training level, the timestamp, and the source identifier "auto_feedback" to indicate that the case was automatically generated by the processor. This new case is then converted into vector form and added to the vector index of historical cases for future retrieval and reference.

[0177] In some embodiments, when the processor detects explicit negative feedback or implicit failure (i.e., match_score ≤ 0.4 and tool_state is still "stuck"), the processor performs the following actions: Constructing a reflection prompt: Concatenating the following information into Llama3: original Parsed_Q; fused diagnostic results; actual subsequent state S′ (or student negative feedback text); original recommended steps and knowledge rules.

[0178] Example prompt: "The original suggestion of 'lifting + cycling' was used to deal with mechanically stuck drills, but the tool still got stuck after the trainee executed it, and the mud density was only 1.02 g / cm³. Please analyze the factors that may have been overlooked and generate a new verifiable rule or point of attention." Generate a new knowledge unit, requiring Llama3 to output: a new verifiable_rule (format: "when [condition], [action / warning]"); the corresponding snippet (≤50 characters); initial confidence level evidence_conf = 0.6 (because the source is model generated, not expert confirmed).

[0179] Example output:

[0180] {

[0181] "snippet": "When sticking occurs under low mud density, wellbore instability should be considered first."

[0182] "verifiable_rule": "When mud_density < 1.05 && tool_state == 'stuck', the regular unblocking operation should be paused, and the wellbore stability should be assessed first."

[0183] "evidence_conf": 0.65

[0184] }

[0185] Injecting Knowledge Vector Index: Concatenate the new rule with the snippet into text; use unified embedding model encoding; write it into the oil drilling domain knowledge vector index library with low initial weights; mark origin_type = "model_generated" for easy subsequent manual review or confidence enhancement. Note: The processor can periodically perform expert review on frequently used model_generated rules. If the verification is valid, increase its evidence_conf to ≥0.85 and update origin_type.

[0186] In some embodiments, successful cases are automatically accumulated into high-quality experience, improving the retrieval hit rate and applicability for similar scenarios in the future; error diagnosis triggers incremental updates to the knowledge base, avoiding the recurrence of similar misjudgments; manual rules (high confidence), case experience (medium confidence), and model generation (low confidence) form a three-level knowledge system, ensuring a balance between the robustness and innovation of the method.

[0187] In some embodiments of this specification, a multi-source information fusion fault diagnosis method for drilling simulation training is provided. By introducing a context-enhanced intent parsing mechanism, when parsing user questions, it not only relies on the current statement but also integrates the most recent 3-5 rounds of dialogue history, and sets a confidence threshold (≥0.8) to trigger clarification through counter-questions. Traditional RAG systems rely solely on static knowledge retrieval, easily neglecting real-time operating conditions and historical experience. This solution concurrently enables three intelligent agents: knowledge retrieval, environmental reasoning, and historical cases, and constructs a dynamic evidence consensus graph (DECG) to uniformly map operation manual rules, simulator state symbolization logic, and real student cases to the same semantic vector space. Based on this, a confidence-weighted graph attention propagation and conflict debate mechanism are adopted, enabling automatic invocation of a large model for expert-style reasoning when contradictory evidence exists. The evidence sources in the fusion chain are strictly cited (e.g., "based on operation manual rules and successful cases of intermediate students"), and expected parameter changes are clearly marked (e.g., "P_pump should fall back to 12MPa"). This transparent and verifiable output method allows students not only to perform operations but also to understand the underlying engineering logic. Through feedback loops and knowledge-updating agents, successful handling experiences can be automatically transformed into new historical cases (added to the database when match_score>0.8), and failed cases can drive the generation of new verifiable rules (initial evidence_conf = 0.6).

Claims

1. A multi-source information fusion fault diagnosis method for drilling simulation training, characterized in that, include: S1: Acquire multi-source information data and historical databases from drilling simulations, and through preprocessing, obtain initial entries for the task blackboard and structured parsing results; including: The process involves acquiring multi-source information data from drilling simulations, cleaning the text, and obtaining initial entries for the task blackboard. This includes acquiring natural language descriptions, simulator snapshots, and student metadata. Natural language descriptions, simulator snapshots, and student metadata are multi-source information data. Stop word removal and spell correction are performed on the natural language descriptions to obtain standardized question text. Based on the standardized question text, simulator snapshots, and student metadata, task identifiers are generated and matched to obtain the initial entries for the task blackboard. Based on a historical database, structured parsing results are obtained through intent parsing and clarification mechanisms. This includes: obtaining a context set by querying dialogue records associated with the current learner from the historical database; analyzing the context set using a large language model to obtain the user's complete intent, domain key element identification results, and parsing confidence; and processing the user's complete intent, domain key element identification results, and parsing confidence using confidence filtering and question clarification mechanisms to obtain structured parsing results. S2: Based on multi-source information data and structured analysis results, through information extraction, a structured evidence list, environmental reasoning results, and historical case results are obtained, including: S210: Retrieve and generate the structured analysis results to obtain a list of structured evidence; S220: Extract information from simulator snapshots in multi-source information data to obtain environmental inference results; S230: Based on the initial entries of the task blackboard and simulator snapshots in multi-source information data, historical case results are obtained through vector similarity retrieval; S3: Based on the structured evidence list, environmental reasoning results, and historical case results, construct nodes and edges to obtain a dynamic evidence consensus graph; S4: By performing multi-hop propagation and consensus generation on the dynamic evidence consensus graph, a fusion diagnostic result is obtained; S5: Based on the fusion diagnostic results, perform fault diagnosis and interpretation on the key input elements to obtain repair guidelines; S6: Utilize feedback loops and knowledge-updating intelligent agents to monitor and update the repair guidelines, obtain multi-source information fusion fault diagnosis results, and complete the diagnosis of multi-source information fusion faults.

2. The multi-source information fusion fault diagnosis method for drilling simulation training according to claim 1, characterized in that, S210 includes: Construct a retrieval query vector using the structured parsing results; Vector similarity retrieval is performed on the search query vector, and the large language model is used for analysis to obtain evidence summary, verifiable rules, and rule confidence. The evidence summary, verifiable rules, and rule confidence are structured to obtain a structured evidence list.

3. The multi-source information fusion fault diagnosis method for drilling simulation training according to claim 1, characterized in that, S220 includes: Information is extracted from simulator snapshots in multi-source information data to obtain the latest environmental status data; Build a working condition rule base; The latest environmental status data is matched with the operating condition rule base to obtain preliminary matching results; Using a large language model, the preliminary matching results are analyzed to obtain the causal inference chain and confidence level; The causal reasoning chain and confidence level are structured to obtain the environmental reasoning results.

4. The multi-source information fusion fault diagnosis method for drilling simulation training according to claim 1, characterized in that, S230 includes: Based on the initial entries of the task blackboard and simulator snapshots from multi-source information data, construct composite query content; By constructing a historical case vector index library, vector similarity retrieval is performed on composite query content to obtain candidate cases; Based on candidate cases, time decay factor calculation and grade matching weighting are performed to obtain comprehensive search cases; Using a large language model, we analyze comprehensive retrieval cases, initial entries on the task blackboard, and simulator snapshots from multi-source information data to obtain historical case results.

5. The multi-source information fusion fault diagnosis method for drilling simulation training according to claim 1, characterized in that, S3 includes: Graph nodes are constructed using a structured list of evidence, environmental reasoning results, and historical case results; Construct the root node of user intent; Based on the graph nodes and the user intent root node, traverse the graph and dynamically construct edges between nodes; Based on graph nodes, user intent root nodes, and edges between nodes, a graph is constructed to obtain a dynamic evidence consensus graph.

6. The multi-source information fusion fault diagnosis method for drilling simulation training according to claim 5, characterized in that, The expression for the edge between the nodes is: ； ； in, This represents the cosine similarity of feature vectors between nodes. express node, express node, This represents the feature vector obtained by encoding the text information contained in node A using a vector embedding model. This represents the feature vector obtained by encoding the text information contained in node B using a vector embedding model. The vector magnitude of the eigenvector is represented by the length of the vector. Represents edge weight, Represents the balance coefficient. This represents the support value corresponding to whether there is a clear logical consistency relationship between node A and node B.

7. The multi-source information fusion fault diagnosis method for drilling simulation training according to claim 1, characterized in that, S4 includes: By performing multi-hop attention propagation on the dynamic evidence consensus graph, the current layer neighbor nodes are collected, the attention weights are calculated, and a new consensus vector is obtained. Based on the new consensus vector, consensus conflicts are monitored and a debate mechanism is triggered to generate consensus and obtain fusion diagnostic results including fusion confidence.

8. The multi-source information fusion fault diagnosis method for drilling simulation training according to claim 7, characterized in that, The expression for the new consensus vector is: ； ； in, This represents the current consensus vector generated during the t-th multi-hop propagation process. This represents the attention weight value contributed by the i-th node to the current consensus vector during the t-th propagation. This represents the feature vector corresponding to the i-th neighbor node. This represents the node confidence score corresponding to the i-th node (this confidence score is derived from the credibility of the evidence, the credibility of the reasoning, or the applicability of the case). Represents cosine similarity. This represents the consensus vector generated in the previous round of propagation. This represents the node confidence level corresponding to the j-th node. This represents the feature vector corresponding to the j-th neighbor node. This represents the preset smoothing control parameter, used to adjust the dispersion of the attention weight distribution.

9. The multi-source information fusion fault diagnosis method for drilling simulation training according to claim 7, characterized in that, The expression for the fusion confidence score is: ； in, This represents the confidence level of the final fusion diagnosis. This refers to the set of nodes that provide positive support for the same fault hypothesis or diagnostic conclusion during the final consensus phase. This represents the attention weight value corresponding to the i-th supporting node in the final propagation round T. This represents the final effective confidence value of the i-th supporting node after consensus propagation is completed.

10. The multi-source information fusion fault diagnosis method for drilling simulation training according to claim 1, characterized in that, S5 includes: Based on the fusion diagnostic results and key input elements, the main fault hypotheses are obtained; Based on the main fault assumptions, an intent confirmation statement is generated using a large language model. By using reasoning chains to interpret intent confirmation statements for fault diagnosis, and through step-by-step repair guidance, a repair guide is obtained.

11. The multi-source information fusion fault diagnosis method for drilling simulation training according to claim 1, characterized in that, S6 includes: Asynchronous feedback monitoring is used to perform cyclical implicit behavioral feedback monitoring and explicit negative feedback monitoring on the response process of the repair guide, and the monitoring results are obtained. When the monitoring results show failure, the system constructs reflection prompts and injects knowledge vector indexes for updating, obtains multi-source information fusion fault diagnosis results, and completes the diagnosis of multi-source information fusion faults.

Images