A Method for Building a Multi-Scenario Intelligent Customer Service System in the Energy Industry

Abstract

This application discloses a method for building a multi-scenario intelligent customer service system in the energy industry, belonging to the field of computer technology. By constructing a digital twin of the scenario process and a multi-source business data model, and performing dynamic coupling and automated simulation dialogue in a dynamic business sandbox, a comprehensive pre-playback of the intelligent customer service process in the energy industry is achieved. Through joint analysis of the pre-playback logs and the business data model, conflicts caused by dynamic mismatches in business data or differences in user expression can be identified, and their root causes and scope of impact can be analyzed. Based on this, a structured optimization strategy can be generated and iteratively verified, thereby solving the problems of insufficient coupling, delayed conflict identification, and optimization dependence on trial and error in traditional customer service systems under complex and dynamic business environments, and improving the robustness and deployment efficiency of the intelligent customer service system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for building a multi-scenario intelligent customer service system in the energy industry. Background Technology

[0002] Intelligent customer service systems in the energy industry need to handle complex business scenarios such as dynamic updates to equipment ledgers, frequent policy adjustments, and highly diverse user expressions. Current mainstream construction methods rely on static dialogue templates and fixed rule bases, resulting in a loose coupling between process logic and business data, and a lack of awareness and adaptability to real-time business environments.

[0003] In practical applications, changes in business data can easily cause preset process parameters to become invalid, leading to node jump errors or external call anomalies; non-standard user expressions often cause intent recognition to deviate from the preset path, resulting in dialogue interruption. Existing verification methods can only perform single-point verification based on a limited number of manual test cases, and cannot dynamically simulate the coupling effect of multi-source business data and user interaction before deployment. Conflict identification is lagging and root cause location is vague. The optimization process highly relies on expert experience and repeated trial and error, which is time-consuming, costly, and difficult to cover multi-scenario boundary situations.

[0004] Therefore, how to achieve deep coupling between customer service processes and dynamic business environments, build a pre-simulated, diagnosable, and iterative verification mechanism, identify conflicts caused by mismatches in business data and differences in user expression, and drive automated optimization of processes have become urgent problems to be solved in order to improve the robustness and deployment efficiency of intelligent customer service systems in the energy industry. Summary of the Invention

[0005] This application provides an embodiment of a method for building a multi-scenario intelligent customer service system in the energy industry, the technical solution of which is as follows:

[0006] On the one hand, a method for building multi-scenario intelligent customer service in the energy industry is provided, the method including:

[0007] Based on business specifications, customer service scenario templates are transformed into scenario process digital twins, and equipment ledgers, dynamic policies and historical interaction data are processed in a structured and semantic way to build a multi-source business data model that is compatible with the scenario process digital twins.

[0008] In the dynamic business sandbox, the digital twin of the scenario process is dynamically coupled with the real-time business data in the multi-source business data model, driving the dialogue engine in the sandbox to execute multiple rounds of automated simulation dialogue, generating a pre-drill log containing node jumps, parameter passing and external data call results;

[0009] The pre-drill logs and the multi-source business data model are jointly analyzed to identify dynamic business conflicts caused by dynamic mismatch of business data or differences in user expression, and the root cause categories and the set of affected process nodes of the dynamic business conflicts are parsed.

[0010] Based on the root cause category and the set of affected process nodes, a structured optimization strategy is generated for the digital twin of the scenario process. Through iterative execution of dynamic coupling, automated simulation dialogue and joint analysis, until the pre-run passes, the verified intelligent customer service process is output.

[0011] On the one hand, a multi-scenario intelligent customer service system for the energy industry is provided, the system comprising:

[0012] The module is used to transform customer service scenario templates into scenario process digital twins based on business specifications, and to perform structured and semantic processing on equipment ledgers, dynamic policies and historical interaction data to build a multi-source business data model that is compatible with the scenario process digital twins.

[0013] The driving module is used to dynamically couple the scenario process digital twin with the real-time business data in the multi-source business data model in the dynamic business sandbox, drive the dialogue engine in the sandbox to execute multiple rounds of automated simulation dialogue, and generate a pre-drill log containing node jumps, parameter passing and external data call results.

[0014] The analysis module is used to jointly analyze the pre-run log and the multi-source business data model, identify dynamic business conflicts caused by dynamic mismatch of business data or differences in user expression, and parse out the root cause category and the set of affected process nodes of the dynamic business conflict.

[0015] The generation module is used to generate a structured optimization strategy for the digital twin of the scenario process based on the root cause category and the set of affected process nodes. It iteratively executes the dynamic coupling, automated simulation dialogue and joint analysis until the pre-run passes, and outputs the verified intelligent customer service process.

[0016] On one hand, a computer device is provided, the computer device including one or more processors and one or more memories, the one or more memories storing at least one computer program, the computer program being loaded and executed by the one or more processors to implement the method for building multi-scenario intelligent customer service in the energy industry.

[0017] On the one hand, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, the computer program being loaded and executed by a processor to implement the method for building multi-scenario intelligent customer service in the energy industry.

[0018] On the one hand, a computer program product or computer program is provided, which includes program code stored in a computer-readable storage medium. The processor of a computer device reads the program code from the computer-readable storage medium and executes the program code, causing the computer device to execute the aforementioned method for building multi-scenario intelligent customer service in the energy industry. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the implementation environment for a method for building a multi-scenario intelligent customer service system in the energy industry, as provided in an embodiment of this application.

[0021] Figure 2 This is a flowchart of a method for building a multi-scenario intelligent customer service system in the energy industry, provided in an embodiment of this application.

[0022] Figure 3 This is a flowchart of another method for building a multi-scenario intelligent customer service system in the energy industry, provided in an embodiment of this application;

[0023] Figure 4 This is a flowchart of another method for building a multi-scenario intelligent customer service system in the energy industry, provided in an embodiment of this application;

[0024] Figure 5 This is a flowchart of another method for building a multi-scenario intelligent customer service system in the energy industry, provided in an embodiment of this application;

[0025] Figure 6 This is a flowchart of another method for building a multi-scenario intelligent customer service system in the energy industry, provided in an embodiment of this application;

[0026] Figure 7 This is a flowchart of another method for building a multi-scenario intelligent customer service system in the energy industry, provided in an embodiment of this application;

[0027] Figure 8 This is a flowchart of another method for building a multi-scenario intelligent customer service system in the energy industry, provided in an embodiment of this application;

[0028] Figure 9 This is a schematic diagram of the structure of a multi-scenario intelligent customer service system for the energy industry, provided in an embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0030] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.

[0031] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0032] Figure 1 This is a schematic diagram illustrating the implementation environment of a method for building a multi-scenario intelligent customer service system in the energy industry, as provided in an embodiment of this application. (See attached diagram.) Figure 1 The implementation environment may include node 110 and system 140.

[0033] Node 110 connects to system 140 via a wireless or wired network. Optionally, node 110 can be a smartphone, tablet, laptop, desktop computer, etc., but is not limited to these. Node 110 has an application installed and running that supports the construction of multi-scenario intelligent customer service in the energy industry.

[0034] System 140 is a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, Content Delivery Network (CDN), and big data and artificial intelligence platforms. System 140 can provide background services for applications running on node 110.

[0035] Traditional intelligent customer service systems in the energy industry typically rely on static dialogue templates and fixed rule bases when handling complex business scenarios such as dynamic updates to equipment ledgers, frequent policy adjustments, and diverse user expressions. This results in loose coupling between process logic and business data, lacking the ability to perceive and adapt to real-time business environments. Changes in business data can easily cause process parameters to fail and node jump errors to occur. Non-standard user expressions often lead to deviations in intent recognition, causing dialogue interruptions. Existing verification methods can only perform limited single-point verification and cannot dynamically simulate the coupling effect between multi-source business data and user interactions. Conflict identification is lagging and root cause location is vague. The optimization process heavily relies on expert experience and repeated trial and error, resulting in long cycles, high costs, and difficulty in covering multi-scenario boundary situations.

[0036] In response, this application proposes a method for building multi-scenario intelligent customer service in the energy industry, which includes:

[0037] Based on business specifications, customer service scenario templates are transformed into scenario process digital twins, and equipment ledgers, dynamic policies and historical interaction data are processed in a structured and semantic way to build a multi-source business data model that is compatible with the scenario process digital twins.

[0038] In the dynamic business sandbox, the digital twin of the scenario process is dynamically coupled with the real-time business data in the multi-source business data model, driving the dialogue engine in the sandbox to execute multiple rounds of automated simulation dialogue, generating a pre-drill log that includes node jumps, parameter passing, and external data call results.

[0039] By jointly analyzing the rehearsal logs and multi-source business data models, dynamic business conflicts caused by dynamic mismatches in business data or differences in user expression are identified, and the root cause categories and affected process nodes of the dynamic business conflicts are analyzed.

[0040] Based on the root cause categories and the set of affected process nodes, a structured optimization strategy is generated for the digital twin of the scenario process. Through iterative execution of dynamic coupling, automated simulation dialogue and joint analysis, until the pre-run passes, the verified intelligent customer service process is output.

[0041] For ease of understanding, the following explains some key terms in this embodiment:

[0042] Business specifications refer to a set of rules, standards, and logic used to guide customer service process design, data processing, and system behavior. They encompass business process definitions, data structure requirements, intent recognition standards, action execution logic, and conflict resolution principles, ensuring that the intelligent customer service system maintains consistency and compliance in complex business scenarios.

[0043] A customer service scenario template is a predefined, structured or semi-structured blueprint describing a specific customer service business process. It typically includes elements such as user intent, system response, data interaction points, and process branching logic, serving as the initial input for building an intelligent customer service process.

[0044] A scenario-based digital twin is a dynamic and executable virtual mapping of a customer service scenario template in the digital space. It not only includes the static structure of the process, but also simulates the real-time running status, internal state changes, and interaction behavior with external systems under different business data and user inputs, enabling comprehensive perception and control of the customer service process.

[0045] An equipment ledger is a database that records detailed information about all of a company's equipment assets. It includes static and dynamic attributes such as equipment model, serial number, operating status, maintenance records, and geographical location, and is a crucial data source for customer service in the energy industry to handle equipment-related issues.

[0046] Dynamic policies refer to business rules, terms of service, or promotional activities that are updated in real time as time, market conditions, or regulations change. Changes in these policies directly affect the execution logic of customer service processes and data query results, requiring intelligent customer service systems to have real-time adaptability.

[0047] Historical interaction data refers to records of past dialogues, service requests, and processing results between the intelligent customer service system and users. It includes information such as user expression habits, common problems, problem-solving paths, and system response patterns, providing empirical evidence for system optimization and conflict identification.

[0048] A multi-source business data model refers to a unified data view formed by integrating business data from multiple sources, such as equipment ledgers, dynamic policies, and historical interaction data, and after structured and semantic processing. This model has dynamic response capabilities and can provide real-time and accurate business context information for the digital twin of the scenario process.

[0049] A dynamic business sandbox is an isolated and controlled simulation environment. In this environment, a digital twin of the scenario process can interact with real-time or simulated business data, and the dialogue engine can execute automated simulated dialogues, thereby rehearsing, testing, and verifying customer service processes without affecting the actual production system.

[0050] The dialogue engine is a core component of an intelligent customer service system, responsible for parsing user input, understanding user intent, managing dialogue state, generating system responses, and driving process flow. In a dynamic business sandbox, the dialogue engine executes multi-turn dialogues based on simulated user input and the logic of a digital twin.

[0051] The rehearsal log refers to all key events and data recorded by the system during the execution of automated simulation dialogue in the dynamic business sandbox. It records in detail node jumps, parameter passing, external data call results, rule matching status, and any abnormal events, serving as the basis for subsequent conflict analysis and root cause localization.

[0052] Dynamic business conflict refers to abnormal situations during the execution of intelligent customer service processes, such as the inability of the process to proceed normally, the generation of erroneous responses, or the getting stuck in a loop, due to the mismatch between real-time changes in business data and process logic, or the difference between the user's expression and the system's preset intent.

[0053] Root cause categories refer to the classification of the fundamental causes of dynamic business conflicts identified after in-depth analysis. Examples include data format mismatch, missing business rules, ambiguous intent recognition, and parameter validation failures. These categories help in developing targeted optimization strategies.

[0054] The set of affected process nodes refers to all nodes in the digital twin of the process scenarios that are directly or indirectly affected by a dynamic business conflict. Identifying these nodes helps to clarify the scope of the problem and guide the precise implementation of optimization strategies.

[0055] Structured optimization strategies refer to a series of specific, executable process adjustment instructions generated based on the identified root cause categories of dynamic business conflicts and the set of affected process nodes. These instructions are expressed in a structured form and can be directly applied to the digital twin of the scenario process to achieve automated process repair and improvement.

[0056] This application provides a method for building multi-scenario intelligent customer service in the energy industry. (See also...) Figure 2 This includes the following steps.

[0057] 201. Based on business specifications, transform customer service scenario templates into scenario process digital twins, and perform structured and semantic processing on equipment ledgers, dynamic policies and historical interaction data to build a multi-source business data model that is compatible with the scenario process digital twins.

[0058] Specifically, customer service scenario templates can be manually interpreted, and developers can manually map each dialogue step, user intent, and system response in the template to the corresponding logical unit in the digital twin. For example, in a "query electricity bill" scenario template, each sub-step (such as "ask for user account number," "query database," and "return result") is manually converted into an independent state or action in the digital twin. Alternatively, business specifications can be encoded into a series of transformation rules. These rules are applied to customer service scenario templates, automatically identifying keywords, sentence structures, or predefined tags in the template, and converting them into process nodes and connections in the digital twin based on these identification results. For example, by matching "if...then..." statements in the template using regular expressions, conditional branch nodes in the digital twin are automatically generated. Furthermore, multiple digital twin structure templates are preset. Customer service scenario templates are categorized into a specific template type, and then the content of the scenario template is directly injected into the preset digital twin structure by filling in placeholders in the template. For example, for scenarios like "information query", a general query process digital twin template can be directly applied and filled in with information such as the query object and query conditions.

[0059] Furthermore, equipment ledgers, dynamic policies, and historical interaction data can be easily extracted from their respective storage systems and aggregated into a central database. For example, all data can be imported into a relational database, and separate tables can be created for each data type. As a preferred implementation, a unified database schema is defined for data from different sources. Then, by writing data transformation scripts, the raw data is mapped and its types are converted according to a preset schema to achieve structuring. For example, the "equipment number" field in the equipment ledger is mapped to the "asset_id" field in the data model. In addition, keywords are extracted from unstructured or semi-structured data (such as text in historical interaction data), and these keywords are labeled with predefined tags to achieve preliminary semanticization. For example, keywords such as "electricity bill" and "fault" are identified in user dialogues and marked as "fee inquiry intent" or "repair request intent." Thus, based on the needs of the scenario flow digital twin, a data model is manually designed and constructed. This model defines the required data entities, attributes, and their relationships, and then the raw data, after preliminary structuring and semanticization processing, is populated into the model. For example, a "user" entity can be manually defined, containing attributes such as "account number" and "name", and the corresponding information can be extracted from historical interaction data to populate it.

[0060] 202. In the dynamic business sandbox, the digital twin of the scenario process is dynamically coupled with the real-time business data in the multi-source business data model to drive the dialogue engine in the sandbox to execute multiple rounds of automated simulation dialogue and generate a pre-drill log containing node jumps, parameter passing and external data call results.

[0061] Specifically, when the dynamic business sandbox starts, real-time business data from the multi-source business data model can be directly loaded into the digital twin's memory space or its associated data storage. For example, currently effective policy data can be injected as a global variable into the digital twin's execution environment. As another implementation, during execution, when specific business data is needed, the digital twin sends a query request to the multi-source business data model in real time through a pre-defined application programming interface (API) to obtain the required data. For example, when the digital twin needs to query the operating status of a device, it calls the query interface provided by the data model. Furthermore, when data in the multi-source business data model changes, a data update event is published to notify the dynamic business sandbox. Upon receiving the event, the sandbox triggers the digital twin to update its internal state or related parameters. For example, when the status of a device in the device ledger is updated, the sandbox receives the notification and updates the status of the corresponding device in the digital twin.

[0062] Furthermore, a series of fixed scripts can be pre-written, each defining a user input sequence and a desired system response path. The dialogue engine simulates user input round by round according to the script's instructions and generates system responses based on the logic of the digital twin. For example, a script might contain a fixed dialogue flow such as "User says: Inquire about electricity bill," "System says: Please provide account number," and "User says: 123456." As a preferred implementation, the dialogue engine can randomly generate user input based on a preset vocabulary and grammar rules. These random inputs are fed into the digital twin to drive the dialogue flow. For example, randomly combining verbs such as "inquire," "process," and "modify" with nouns such as "electricity bill," "water bill," and "report repair" generates diverse user requests. During the simulated dialogue execution, the dialogue engine simply records each key event (such as user input, system response, process node activation, parameter assignment, and external system call attempts) to a text file or database, forming a pre-playback log. For example, recording "Timestamp: [XX], Node: [YY], Event: [User Input], Content: [ZZ]." Furthermore, the dialogue engine can be configured to attempt to traverse all possible paths within the digital twin, or a few preset main paths. At each step, the dialogue engine selects a path to explore based on the current state of the digital twin and available transition conditions, and records its execution trajectory.

[0063] 203. Conduct joint analysis of the pre-drill logs and multi-source business data models to identify dynamic business conflicts caused by dynamic mismatch of business data or differences in user expression, and analyze the root cause categories of dynamic business conflicts and the set of affected process nodes.

[0064] Specifically, the rehearsal logs can be manually reviewed line by line. By observing the error messages, abnormal states, or unexpected behaviors recorded in the logs, potential business conflicts can be identified. For example, a human might discover multiple instances of the "invalid parameter" error message in the logs. Alternatively, a series of preset error keywords or patterns can be used for text matching of the rehearsal logs. When these keywords appear in the logs, they are marked as business conflicts. For example, matching words like "data missing," "unrecognizable," and "process interruption." Furthermore, the parameter values ​​recorded in the rehearsal logs can be simply compared with the expected values ​​in the multi-source business data model. If inconsistencies exist, it is identified as a dynamic mismatch conflict in business data. For example, the "account number" recorded in the logs may not exist in the data model. Therefore, a simple comparison can be made between the user input recorded in the rehearsal logs and the intent identified by the dialogue engine. If there is a significant difference between the user input and the identified intent, it is marked as a user expression discrepancy conflict. For example, the user inputs "I want to report a repair," but the system identifies it as "query progress."

[0065] Furthermore, a mapping table between error codes and root cause categories can be pre-defined. When a business conflict is identified, the error code is extracted from the rehearsal log, and the corresponding root cause category is directly looked up according to the mapping table. For example, error code "E001" corresponds to "data format error". As a preferred implementation, a human operator traces back to several nodes before the conflict occurred based on the process execution path recorded in the rehearsal log, and, combined with the data status in the multi-source business data model, manually determines the direct cause of the conflict and the affected process nodes. In addition, based on the static flowchart of the digital twin, when a conflict occurs at a node, that node and its direct downstream nodes are simply marked as the set of affected process nodes. For example, if the "query electricity bill" node fails, the subsequent "display electricity bill result" node is considered affected. Thus, some simple rules can be pre-defined, such as "if parameter validation fails and the parameter value is empty, the root cause category is missing data". These rules are applied to conflict events to infer the root cause category.

[0066] 204. Based on the root cause category and the set of affected process nodes, generate a structured optimization strategy for the digital twin of the scenario process. Through iterative execution of dynamic coupling, automated simulation dialogue and joint analysis, until the pre-run passes, output the verified intelligent customer service process.

[0067] Specifically, based on the identified root cause categories and affected nodes, experts manually modify the process logic or parameter configurations within the digital twin. For example, if the root cause is "parameter validation rules are too strict," the threshold of the validation rules is manually adjusted. As another implementation, some simple optimization templates can be preset, such as "add a data completion step before the affected node for the root cause of missing data." When a specific root cause is identified, the corresponding template is selected and applied to the affected process node. Furthermore, if the root cause is data mismatch, instructions to adjust relevant parameters in the digital twin are generated. For example, the instructions might include "set the default value of parameter Y for node X to Z." Thus, if the root cause is a difference in user expression, instructions to modify the intent recognition logic of the affected node are generated. For example, the instructions might include "add a new intent recognition phrase to node A."

[0068] Furthermore, after generating the optimization strategy, the system manually applies the strategy to the digital twin, then manually starts the dynamic business sandbox to execute a new round of simulated dialogue and analysis. This process is repeated until the pre-simulation results are judged to meet the requirements. As a preferred implementation, a simple pass criterion can be preset, such as "no error messages appear in the pre-simulation log." After each iteration, the system automatically checks whether the pre-simulation log meets this criterion. If it does, the iteration stops and the process is output. Otherwise, the next round of optimization continues. Additionally, a fixed number of iterations can be set. Regardless of whether the pre-simulation passes or fails, the system will execute the preset number of optimization and simulation cycles. After all iterations are completed, the intelligent customer service process obtained from one iteration is output. Thus, after each iteration, the system generates a simple feedback report based on the pre-simulation results. The optimization strategy generation module adjusts the strategy based on this report and then executes the simulation. This cycle continues until a preset performance indicator or iteration limit is reached.

[0069] This method constructs a digital twin of the scenario process and a multi-source business data model, and dynamically couples and automates simulation dialogues within a dynamic business sandbox, achieving a comprehensive pre-playout of the intelligent customer service process in the energy industry. Through joint analysis of the pre-playout logs and the business data model, conflicts arising from dynamic mismatches in business data or differences in user expression can be identified, and their root causes and scope of impact can be analyzed. Based on this, structured optimization strategies can be generated and iteratively verified, thus solving the problems of insufficient coupling, delayed conflict identification, and reliance on trial and error in traditional customer service systems under complex and dynamic business environments, improving the robustness and deployment efficiency of the intelligent customer service system.

[0070] In some of the embodiments described above in this application, a digital twin of the customer service scenario template is proposed to be transformed into a scenario process based on business specifications to build the process foundation. However, in its implementation, the template deconstruction may be incomplete, resulting in a lack of standardization of components. The reorganization may be inaccurate, affecting the integrity of the state transition path. Furthermore, there is a lack of detailed monitoring mechanism for state nodes, which makes it impossible to capture detailed execution context during dynamic business sandbox pre-play, affecting the efficiency of subsequent conflict identification and optimization.

[0071] To address this, this application further proposes a method for transforming customer service scenario templates into digital twins of scenario processes based on business specifications, see [link to relevant documentation]. Figure 3 Specifically, it includes:

[0072] 301. Based on this business specification, deconstruct the customer service scenario template to generate a set of process elements, which includes atomic business intentions and standardized system actions.

[0073] 302. Based on the business logic defined in the business specification, reorganize the set of process components to construct an initial process skeleton with state transition paths.

[0074] 303. For at least a portion of the state nodes of the initial process skeleton, configure observation hooks to trigger internal state acquisition and exposure during the dynamic business sandbox rehearsal, forming a digital twin of the scenario process. The observation hooks enable the dynamic business sandbox to capture the detailed execution context of the state node.

[0075] Based on this business specification, the customer service scenario template is deconstructed to generate a set of process components, which includes atomic business intentions and standardized system actions. This step aims to break down the original customer service scenario template, typically described in natural language, into a series of structured, reusable, and standardized basic building blocks. Deconstruction eliminates ambiguity and redundancy in the template description, laying a solid foundation for subsequent process reengineering and automation. The set of process components is the smallest logical unit constituting the intelligent customer service process, and its degree of standardization directly affects the accuracy and operability of the digital twin. In practical implementation, a rule-based parser can be used, combined with predefined grammatical and semantic rules, to perform pattern matching and information extraction on the text in the customer service scenario template, thereby identifying user intentions and system actions. Alternatively, natural language processing (NLP) technologies, such as Named Entity Recognition (NER), Intent Recognition, and Slot Filling models, can be used to perform deep semantic analysis on the template, transforming unstructured descriptions into structured atomic business intentions and standardized system actions.

[0076] Furthermore, based on the business logic defined in the business specification, the set of process components is reorganized to construct an initial process skeleton with state transition paths. The core of this step lies in organizing the discrete process components according to the inherent logic and sequence of the business, forming a coherent and executable process structure. The initial process skeleton is the preliminary form of the scenario process digital twin; it clarifies the possible state transitions and path directions in the dialogue process, serving as the basis for subsequent configuration of observation hooks and dynamic pre-simulation. Its accuracy directly determines the digital twin's ability to simulate real business processes. In specific implementation, formal modeling methods such as finite state machines (FSMs) or Petri nets can be used to map atomic business intentions and standardized system actions into states and transitions, defining the transition paths between states according to the conditions and rules in the business specification. Alternatively, graph database technology can be used, with process components as nodes and business logic as edges, constructing a directed graph structure, and generating the initial process skeleton with state transition paths through graph traversal and path planning algorithms.

[0077] Furthermore, for at least some state nodes of the initial process skeleton, observation hooks are configured to trigger internal state acquisition and exposure during the dynamic business sandbox rehearsal, forming a digital twin of the scenario process. These observation hooks enable the dynamic business sandbox to capture the detailed execution context of each state node. This step aims to enhance the observability of the scenario process digital twin, allowing it to expose its internal execution state and key data in real-time and with fine-grained detail while running in the dynamic business sandbox. Observation hooks are a key mechanism for achieving this goal, allowing the sandbox to obtain detailed context information during process execution without modifying the core process logic. This is crucial for subsequent conflict identification, root cause analysis, and optimization strategy generation. In specific implementation, an event listener pattern can be used to register callback functions or event handlers on key state nodes of the initial process skeleton. When process execution reaches these nodes, data acquisition logic is automatically triggered, sending information such as the node ID, current parameter values, and external call results to the sandbox's logging component. Alternatively, the concept of Aspect-Oriented Programming (AOP) can be used to insert aspect code before and after the execution of specific methods or functions in the process skeleton. This aspect code is responsible for capturing and exposing the node's internal variables, method call stack, and interactions with external data models, thereby achieving the collection of detailed execution context.

[0078] Through the above technical solutions, this application can solve the problems existing in the conversion of customer service scenario templates, such as incomplete template deconstruction, lack of component standardization, inaccurate reorganization affecting the integrity of state transition paths, and lack of detailed monitoring mechanisms for state nodes. By deconstructing the customer service scenario template based on business specifications, a set of process components containing atomic business intentions and standardized system actions is generated, ensuring the standardization and reusability of the basic process units and avoiding semantic ambiguity or compatibility issues caused by incomplete deconstruction. The set of process components is reorganized according to the business logic defined in the business specifications to construct an initial process skeleton with state transition paths, ensuring the accuracy and integrity of the process logic and resolving path missing or conflict caused by inaccurate reorganization. Observation hooks are configured for at least some state nodes of the initial process skeleton, enabling the dynamic business sandbox to trigger internal state collection and exposure during the pre-playback period, thereby capturing the detailed execution context of state nodes, greatly improving the observability of the process, and providing accurate and fine-grained basis for subsequent conflict identification and optimization. The scenario process digital twin constructed in this way not only possesses high accuracy, robustness, and transparency, but also provides a richer and more accurate real-time execution context when dynamically coupled with multi-source business data models in a dynamic business sandbox. This enhances the effectiveness of automated simulation dialogue, enabling subsequent pre-drill log analysis to more accurately identify dynamic business conflicts, parse out the root cause categories of conflicts, and generate more targeted structured optimization strategies, effectively improving the verification efficiency and quality of intelligent customer service processes.

[0079] In some of the solutions mentioned above in this application, a digital twin of a customer service scenario template is proposed to be transformed into a scenario process based on business specifications, including deconstructing the template to generate a set of process components. However, in its implementation, directly deconstructing the template may not be able to effectively handle the ambiguity of natural language descriptions and the high diversity of user expressions, resulting in a lack of standardization and constraint consistency of intent and action fragments. This can lead to intent recognition deviations or action parameter conflicts when constructing the process skeleton in the future, affecting the accuracy of the digital twin and its adaptability to dynamic business environments.

[0080] To address this, this application further proposes a method based on business specifications to deconstruct customer service scenario templates and generate a set of process components. This includes: parsing the natural language descriptions and logical definitions in the customer service scenario template, performing semantic unit segmentation to obtain a set of user intent expression fragments and a set of system action description fragments; matching and normalizing each fragment in the user intent expression fragment set with a predefined intent semantic library in the business specifications to generate an atomic business intent with associated business constraints; mapping and standardizing each fragment in the system action description fragment set with a predefined action standard library in the business specifications to generate a standardized system action with attached parameter rules; and serializing and encapsulating the generated atomic business intent and standardized system action according to the original execution order defined in the customer service scenario template to output the set of process components.

[0081] Specifically, the natural language descriptions and logical definitions in the customer service scenario template are parsed, and semantic unit segmentation is performed to obtain a set of user intent expression fragments and a set of system action description fragments. This aims to decompose the unstructured or semi-structured customer service scenario template content into smaller, more easily processed semantic units. This helps eliminate the ambiguity of natural language and lays the foundation for subsequent standardization processing. One approach is to utilize Natural Language Processing (NLP) techniques, such as lexical analysis, syntactic analysis, and named entity recognition, to extract key user intent phrases and system action phrases from the natural language description. For logical definitions, rule parsers or syntax analyzers can be used to identify and segment logical expressions. Another approach is to train a machine learning model, such as a sequence labeling model based on the Transformer architecture, to perform end-to-end semantic unit segmentation on the customer service scenario template text, automatically identifying user intent expression fragments and system action description fragments.

[0082] Each fragment in the set of user intent expression fragments is matched and normalized against a predefined intent semantic library in the business specification to generate an atomic business intent with associated business constraints. The purpose is to map diverse user expressions to unified atomic intents with clear business meanings and attach necessary business constraints. This ensures the standardization of intent recognition and the consistency of business logic. One implementation method is to use semantic similarity calculation methods, such as cosine similarity based on word or sentence vectors, to compare user intent expression fragments with standard intents in the intent semantic library, selecting the standard intent with the highest similarity as the matching result. Simultaneously, business constraints associated with this standard intent (e.g., required parameters, preconditions, etc.) are retrieved from the business specification and appended to the generated atomic business intent. Another implementation method is to construct a rule-based intent classifier, combining keyword matching, syntactic pattern recognition, and other technologies to classify user intent expression fragments into a category in the predefined intent semantic library. Once the classification is determined, the system automatically loads and binds the corresponding business constraints from the business specification to form the atomic business intent.

[0083] Each fragment in the system action description set is mapped and standardized against a predefined action standard library in the business specification to generate a standardized system action with attached parameter rules. The aim is to unify system actions with different expressions into standardized, executable actions, and to clarify their required parameters and rules. This ensures the consistency of system action execution and the correctness of parameters. One implementation method is to associate system action description fragments with standard actions in the action standard library using exact matching or fuzzy matching algorithms. Once a match is successful, the system retrieves the standardized name of the action, the list of required parameters, the data type of the parameters, the value range, and other rules from the standard library, and appends them to the generated standardized system action. Another implementation method is to use a pre-trained sequence-to-sequence (Seq2Seq) model or slot-filling techniques to extract the action name and parameter values ​​from the system action description fragments, and then verify and transform them according to the definitions in the action standard library to ensure that the parameters conform to preset rules, thereby generating a standardized system action with attached parameter rules.

[0084] Based on the original execution order defined in the customer service scenario template, the generated atomic business intent and standardized system action are serialized and encapsulated, outputting a set of process components. This serves to maintain the original logical structure and execution flow of the customer service scenario template, ensuring that the deconstructed set of components accurately reflects the sequential relationship of the business process. One implementation is to store the generated atomic business intents and standardized system actions in an ordered list according to their order of appearance in the original customer service scenario template. Each list element is a structured data object containing detailed information about the intent or action and its associated constraints and rules. Another implementation is to construct a lightweight directed acyclic graph (DAG), where each node represents an atomic business intent or standardized system action, and the directed edges between nodes represent the execution order defined in the original template. This approach allows for more flexible representation of processes containing simple branching or parallel structures, encapsulating them as a set of process components.

[0085] Through the above technical solution, this application can effectively handle the ambiguity of natural language descriptions and the diversity of user expressions in customer service scenario templates. By parsing and semantically segmenting natural language descriptions and logical definitions, unstructured template content is transformed into structured user intent expression fragments and system action description fragments, thereby reducing the complexity of subsequent processing. Furthermore, by matching and normalizing user intent expression fragments with a predefined intent semantic library and generating atomic business intents with associated business constraints, this application ensures the standardization of user intent recognition and the rigor of business logic, effectively avoiding intent recognition deviations caused by differences in user expressions. At the same time, mapping and standardizing system action description fragments with a predefined action standard library and generating standardized system actions with attached parameter rules ensures the consistency of system execution actions and the accuracy of parameters, thereby avoiding action parameter conflicts. Based on the original execution order, these standardized, constrained atomic business intents and standardized system actions are serialized and encapsulated to form a set of process elements with consistent business constraints and standardized parameters. This set of process components provides a solid and standardized foundation for the subsequent construction of an initial process skeleton with state transition paths, improving the accuracy, robustness, and adaptability to dynamic business environments of the scenario process digital twin.

[0086] In some of the solutions mentioned above in this application, a process element set is reorganized according to the business logic defined in the business specification to construct an initial process skeleton with state transition paths. However, in the implementation process, due to the complexity of the business logic, the transition paths between state nodes may be unclear or there may be logical conflicts, resulting in an inaccurate initial process skeleton and affecting the formation and simulation effect of the subsequent scenario process digital twin.

[0087] To address this, this application further proposes a method to reorganize the set of process components based on the business logic defined in the business specification, constructing an initial process skeleton with state transition paths. This process includes: instantiating the atomic business intent and the standardized system action within the set of process components into uniquely identified state nodes; determining a set of transition triggering conditions and a successor node identifier for each state node based on a predefined state transition rule base in the business specification; establishing directed connections between the state nodes based on the set of transition triggering conditions and the successor node identifier, forming a node connection network; and optimizing the structure of this node connection network and resolving process logic conflicts to generate the initial process skeleton.

[0088] Specifically, the atomic business intent and the standardized system action within the set of process elements are instantiated as uniquely identified state nodes. This aims to transform abstract business intents and system actions into concrete, identifiable execution units within the process. Each state node represents an independent step or decision point in the customer service process. For example, each node can be assigned a unique alphanumeric identifier (such as "INTENT_QUERY_BALANCE_001") or a globally unique identifier (UUID), and its type, associated atomic business intent, or standardized system action, and other metadata are stored in a structured format. This instantiation ensures the clarity and independence of each step in the process, providing a clear foundation for subsequent path definition.

[0089] Based on this, and using the predefined state transition rule base in the business specification, a set of transition triggering conditions and a successor node identifier are determined for each state node. This state transition rule base is a predefined set of business logic rules used to guide the process from one state node to the next. For example, the rule base might contain rules such as "If the user's intent is to query the balance and the account status is active, then transition to the balance display node." The set of transition triggering conditions could be user input satisfying a specific intent, successful system action execution, data validation results, or specific time events. The successor node identifier explicitly points to the next state node to be executed. In this way, the dynamic behavior of the process is precisely defined, ensuring the compliance and predictability of the transitions.

[0090] Furthermore, based on the set of transition triggering conditions and the identifier of the successor node, directed connections are established between the state nodes, forming a node connection network. A directed connection represents the unidirectional progress of the process, pointing from one state node to its possible successor state node. This connection can be represented internally using a graph data structure (such as an adjacency list or adjacency matrix) or visualized through a graphical interface, where nodes are connected by arrows with triggering conditions labeled next to the arrows. This node connection network visually displays the topology and potential execution paths of the entire customer service process, providing a framework for process analysis and traversal.

[0091] The initial process skeleton is generated by optimizing the network structure and resolving process logic conflicts for this node. Structural optimization aims to improve network efficiency and robustness, for example, by identifying and merging redundant paths, detecting and handling potential infinite loops (such as setting exit conditions or maximum loop counts), and ensuring the reachability of all critical nodes. Process logic conflict resolution focuses on resolving contradictions between rules. For example, when multiple transition rules simultaneously meet their conditions, arbitration is required based on preset priorities. Alternatively, it checks for mutually exclusive conditions that prevent the process from continuing. Through these optimizations and resolutions, the generated initial process skeleton is ensured to be logically consistent, unambiguous, and efficient, providing a stable and reliable foundation for subsequent scenario process digital twins.

[0092] Through the above technical solutions, this application systematically solves the problems of unclear state transition paths and logical conflicts when constructing the initial process skeleton. Atomic business intentions and standardized system actions are instantiated into uniquely identified state nodes, clarifying each independent link in the process, eliminating ambiguity, and laying the foundation for accurately defining transition paths. Based on a predefined state transition rule base, the set of transition trigger conditions and subsequent node identifiers are determined, ensuring that process transitions strictly adhere to business specifications and reducing human error and inconsistencies. By establishing directed connections to form a node connection network, the overall structure of the process is constructed intuitively and logically rigorously. Most importantly, structural optimization of the node connection network and resolution of process logic conflicts proactively identify and resolve redundancies, ambiguities, and contradictions in the process, thereby generating an accurate, robust, and conflict-free initial process skeleton. These steps work together to improve the accuracy and reliability of the initial process skeleton, providing a solid foundation for the effective construction of subsequent scenario process digital twins and simulation pre-runs in dynamic business sandboxes, thereby improving the verification efficiency and optimization quality of the intelligent customer service process.

[0093] In some of the embodiments described above in this application, it is proposed to configure observation hooks for state nodes to capture execution context during the rehearsal. However, in its implementation, there are deficiencies in how to accurately screen key nodes to avoid resource waste, how to define trigger event types that cover internal state transitions and external rule matching to ensure the comprehensiveness of data collection, how to construct a collection template that includes data items of the node's internal state and external environment to provide a complete context, and how to effectively integrate hooks and associate them with log components to achieve automated capture. These deficiencies result in inaccurate or incomplete captured context data, affecting the identification and optimization of subsequent dynamic business conflicts.

[0094] In response, this application further proposes a method for configuring observation hooks for at least some state nodes of the initial process skeleton to trigger internal state acquisition and exposure during the dynamic business sandbox rehearsal, thereby forming a digital twin of the scenario process. The method includes:

[0095] Based on the key judgment rules defined in the business specification, a set of target state nodes that need to be enhanced in observation are selected from the initial process skeleton.

[0096] For each target state node in the set of target state nodes, define at least one trigger event type, which corresponds to the internal state transition or external rule matching event that can be observed in the pre-play of the target state node.

[0097] An observation data acquisition template is constructed for each type of triggering event. This template defines the internal state data items of the node to be captured, as well as the external environment data items from the multi-source business data model to be synchronized and associated.

[0098] The observation data acquisition template is integrated into the execution logic corresponding to the target state node in the form of an executable hook, and the calling relationship between the executable hook and the dynamic business sandbox log component is configured to complete the construction of the digital twin of the scenario process.

[0099] Specifically, when selecting the set of target state nodes requiring enhanced monitoring from the initial process skeleton based on the criticality judgment rules defined in the business specification, these criticality judgment rules can be defined based on dimensions such as business importance, risk level, or historical failure rate. For example, any process node involving user fund operations, sensitive information interaction, or key business decisions can be marked as a critical node. Alternatively, by analyzing historical interaction data, nodes that frequently lead to dialogue interruptions, user complaints, or manual intervention can be identified and included in the target state node set. In this way, monitoring resources can be concentrated on the nodes with the greatest impact on the business, avoiding redundant monitoring of non-critical nodes, thereby improving resource utilization efficiency.

[0100] When defining at least one trigger event type for each target state node in the target state node set, the trigger event type corresponds to an observable internal state transition or external rule matching event of that target state node during the pre-rehearsal. Internal state transition events can include node entry, node exit, parameter update, completion of internal calculation, or start / end of sub-process, etc. External rule matching events can include data verification success / failure, business strategy query results, success / failure of external interface calls, or user input matching a specific pattern, etc. For example, for an "authentication" node, "authentication successful" and "authentication failed" can be defined as internal state transition events, while "external identity service response timeout" can be defined as an external rule matching event. By defining diverse trigger event types, it is ensured that, during the pre-rehearsal process, regardless of how the node's internal state changes or how it interacts with external systems, key execution context information can be captured in a timely manner, enhancing the comprehensiveness of data collection.

[0101] When constructing an observation data collection template for each trigger event type, the template defines the internal state data items of the node to be captured, as well as the external environment data items from the multi-source business data model to be synchronized and associated. The internal state data items can include current node parameter values, execution status, error codes, current user input, etc. The external environment data items can include real-time device status in Device Ledger 100, the latest policy terms in Dynamic Policies, and preference information from user historical interaction data, etc. For example, for the "Order Confirmation" node, its internal state data items might include order amount, product list, and user ID. The external environment data items might be associated with user credit rating (from the multi-source business data model) or current promotional policy (from the multi-source business data model). The observation data collection template can be defined using a structured data format (such as JSON Schema or XML Schema), clearly specifying the name, type, and source of each data item. This ensures that the collected data not only includes the execution details of the node itself but also integrates external environment information closely related to the business logic, providing a more complete context for subsequent conflict analysis.

[0102] When integrating the observation data acquisition template into the execution logic corresponding to the target state node as an executable hook, and configuring the call relationship between the executable hook and the dynamic business sandbox log component to complete the construction of the scenario process digital twin, the executable hook can adopt aspect-oriented programming (AOP) to "weave" data acquisition and logging functions into the node's execution flow without modifying the core business logic of the target state node. Alternatively, through an event-driven mechanism, when the target state node triggers a predefined event, the executable hook is activated as an event listener, performing data acquisition and calling the log component for recording. The call relationship between the executable hook and the dynamic business sandbox log component is usually implemented through the API interface provided by the log component, ensuring that the collected structured data can be written to the pre-drill log in real time and accurately. Through this tight integration method, the automated capture and synchronous recording of observation data are achieved, greatly improving the traceability and diagnostic efficiency of the pre-drill process.

[0103] Through the aforementioned technical solution, this application can accurately identify key process nodes requiring enhanced observation, avoiding unnecessary resource consumption. Simultaneously, by defining trigger event types covering internal state transitions and external rule matching, it ensures that during the pre-performance, regardless of how the internal logic of the process evolves or how it interacts with external business data, key execution context information can be captured comprehensively and promptly. Furthermore, by constructing an observation data collection template that includes node internal state and external environment data items, the collected data not only reflects the execution details of the node itself but also integrates external environment information closely related to the business logic, providing a more complete and accurate context for subsequent dynamic business conflict identification and root cause analysis. Integrating the observation data collection template into the execution logic of the corresponding target state node in the form of an executable hook, and configuring its call relationship with the dynamic business sandbox log component, achieves automated capture and synchronous recording of observation data, improving the traceability and diagnostic efficiency of the pre-performance process. This solves the problem of inaccurate or incomplete capture of context data, laying a solid foundation for the robustness verification and optimization of the intelligent customer service process.

[0104] In some of the solutions mentioned above in this application, a multi-source business data model is proposed to support the coupling and simulation of dynamic business sandboxes. However, in the process of implementation, the diversity and dynamism of equipment ledgers, dynamic policies and historical interaction data may lead to inconsistent structured parsing and frequent semantic conflicts, making it impossible to ensure the real-time adaptation of data and scenario process digital twins, thereby causing subsequent dynamic coupling failure and inaccurate simulation pre-play.

[0105] To address this, this application further proposes a method for structuring and semantically processing equipment ledgers, dynamic policies, and historical interaction data to construct a multi-source business data model adapted to a digital twin of the scenario process. See [link to relevant documentation] Figure 4 The method includes:

[0106] 401. Perform domain-specific structured parsing on equipment ledgers, dynamic policies, and historical interaction data to extract and encapsulate business data objects with version identifiers.

[0107] This step aims to transform raw, heterogeneous data sources into a unified, machine-readable format. "Domain-specific structured parsing" refers to a customized data extraction, cleaning, and transformation process tailored to the data formats and business semantics specific to the energy industry. For example, predefined parsing rules and data schemas can be used to process SCADA data, GIS data, policy text templates, or customer service dialogue logs. Another approach is to use machine learning-based methods to train Named Entity Recognition (NER) or relation extraction models to automatically identify and extract business entities and their attributes from unstructured or semi-structured data. "Version identifiers" are used to record the evolution history of the data, ensuring traceability and backtracking during dynamic data updates. For example, timestamps, serial numbers, or content hashes can be used as version identifiers to manage different versions of the data.

[0108] 402. Based on the predefined business entity graph, perform semantic merging and conflict resolution on the business data object to generate a standardized set of business entities carrying consistency verification labels.

[0109] The "Business Entity Graph" is a core knowledge base that defines standard business entities in the energy industry (such as "electricity meters," "transformers," "users," and "service orders"), their attributes, and the relationships between them, providing a unified reference for semantic alignment of multi-source data. In implementation, an energy industry ontology can be constructed as the Business Entity Graph, and semantic matching algorithms (such as word vector similarity or ontology reasoning) can be used to align entity instances in business data objects with standard entities in the ontology. When multiple business data objects are mapped to the same standard entity, the system arbitrates and merges attribute values ​​according to preset conflict resolution rules (e.g., "based on the latest data," "based on the authoritative data source," or "majority voting principle"). Another implementation method is to use knowledge graph embedding technology to map entities and relationships in the Business Entity Graph to a low-dimensional vector space and perform semantic matching by calculating vector similarity. For conflict resolution, a machine learning model can be trained to select or calculate the optimal attribute value based on the contextual information of conflicting attributes (such as data source, timestamp, confidence level, etc.). The "Consistency Check Tag" is used to mark entities that have undergone semantic merging and conflict resolution, indicating that they conform to predefined business rules and semantic constraints. For example, it can be a boolean value or a metadata field containing details of the verification result.

[0110] 403. Configure dynamic parameter interfaces for the entities of the standardized business entity set that can be called in real time by the dynamic business sandbox, as well as state evolution rules that can be associated with the logic of the digital twin nodes of the scenario process, thereby generating a multi-source business data model with dynamic response and logical constraint capabilities.

[0111] The "Dynamic Parameter Interface" enables the dynamic business sandbox to query and retrieve the latest business data in real time. For example, it can expose a RESTful API or gRPC interface for each standardized business entity or its key attributes, encapsulating operations such as data querying, data updating, and status change notifications. Another implementation approach is to implement the Dynamic Parameter Interface through a data service layer. This service layer is responsible for handling query requests from the sandbox and retrieving the latest data from the underlying data storage. The "State Evolution Rules" tightly integrate the behavior of the data model with the logic of the scenario process digital twin, allowing data changes to directly affect the simulation process, and vice versa. For example, a rule engine can be built to store state evolution rules (such as "when the device status changes from running to fault, trigger the alarm process and update the relevant work order status") as an executable rule set, directly associated with specific nodes in the scenario process digital twin. Another implementation approach is to adopt an event-driven architecture, publishing entity state changes in the standardized business entity set as events to a message queue. The dynamic business sandbox subscribes to these events and updates its internal state or triggers corresponding simulation logic in real time upon receiving an event.

[0112] Through the above technical solutions, this application can resolve the issues of inconsistent structured parsing and semantic conflicts caused by the diversity and dynamism of equipment ledgers, dynamic policies, and historical interactive data. Domain-specific structured parsing and version identification ensure the standardization and traceability of the original data. Semantic merging and conflict resolution based on business entity graphs achieve semantic alignment and data quality assurance of multi-source data, avoiding inaccurate simulations caused by data ambiguity and conflicts. By configuring dynamic parameter interfaces and state evolution rules, the multi-source business data model possesses real-time response and logical constraint capabilities, enabling deep coupling with the scenario process digital twin, ensuring a high degree of consistency between data and process logic in the simulation environment. This not only improves the accuracy and robustness of dynamic business sandbox pre-simulation but also lays a solid data foundation for subsequent identification of dynamic business conflicts and generation of optimization strategies, thereby resolving dynamic business conflicts caused by dynamic data mismatch or differences in user expression, and improving the efficiency and reliability of building intelligent customer service processes in the energy industry.

[0113] In some of the solutions mentioned above in this application, a semantic merging and conflict resolution of business data objects based on business entity graphs is proposed to generate a standardized set of business entities. However, in the implementation process, attribute conflicts may occur when data objects from different data sources are mapped to the same entity node, and there is a lack of systematic conflict arbitration mechanism and logical verification methods. This results in the generated standardized entities having problems such as inconsistent attributes, non-compliant relationships, or contradictory business logic, which affects the accuracy and dynamic adaptability of the multi-source business data model.

[0114] To address this, this application further proposes a method based on a predefined business entity graph to perform semantic merging and conflict resolution on business data objects, generating a standardized set of business entities carrying consistency verification tags. Specifically, this includes: semantically matching business data objects from different data sources with standard entity nodes in the business entity graph to establish a set of entity mapping relationships; performing attribute-level merging and conflict arbitration on multiple business data objects mapped to the same entity node based on the conflict resolution rule base in the business entity graph, generating merged entities with unique authoritative attribute values; and verifying the attribute integrity, relationship compliance, and business logic consistency of the merged entities based on the logical constraint rules in the business entity graph, and attaching consistency verification tags to merged entities that pass the verification, forming a standardized set of business entities.

[0115] The predefined business entity graph is a structured knowledge representation used to describe entities, entity attributes, and their relationships within a specific business domain. It is typically represented as a graph, where nodes represent entities or attributes, and edges represent relationships between entities. Its purpose is to provide a unified semantic framework and data model for integrating, understanding, and validating heterogeneous business data from different data sources. In one implementation, the business entity graph can be built on an ontology, defining core business concepts, attributes, and relationships, and represented using standards such as OWL (Web Ontology Language) or RDF (Resource Description Framework). In another implementation, the business entity graph can be stored in a graph database (such as Neo4j or JanusGraph), constructed using predefined schemas and relationship types, and can be extended with custom attributes and constraints.

[0116] This business data object is a version-identified business-related data unit extracted and encapsulated from original equipment ledgers, dynamic policies, and historical interaction data after domain-specific structured parsing. Its function is to serve as input for semantic merging and conflict resolution, representing original business information from different data sources. This business data object can be represented as a JSON or XML data structure, containing attribute values ​​and metadata of business entities, such as device ID, policy effective date, and user query content. Alternatively, this business data object can also be a record in a relational database or a document in a NoSQL database, which has undergone preliminary cleaning and formatting but has not yet undergone cross-source semantic alignment and conflict handling.

[0117] The purpose of this semantic matching, which establishes a set of entity mapping relationships, is to identify the semantic equivalence or association between business data objects from different data sources and standard entity nodes in the business entity graph, laying the foundation for subsequent data integration. One implementation approach uses rule-based matching, pre-setting a series of matching rules (such as name similarity, attribute value range, identifier consistency, etc.) and performing matching through a rule engine. Another approach employs machine learning or deep learning methods to train an entity matching model (such as based on word embeddings or graph neural networks) to identify different representations of the same business entity from heterogeneous data sources.

[0118] This conflict resolution rule base is a predefined set of strategies and priority rules for resolving data conflicts. Its function is to automatically or semi-automatically select the most authoritative and accurate attribute value based on preset rules when multiple business data objects are mapped to the same standard entity node, thereby eliminating data inconsistencies. This conflict resolution rule base can include priority rules, such as "official data source takes precedence over third-party data source," "latest data takes precedence over old data," and "manually labeled data takes precedence over automatically extracted data." Furthermore, this conflict resolution rule base can also include aggregation rules, such as "averaging numerical attributes," "merging text attributes or selecting the longest / shortest description," and "majority voting for Boolean attributes."

[0119] The purpose of this attribute-level merging and conflict arbitration to generate merged entities with unique authoritative attribute values ​​is to integrate attribute values ​​representing the same entity from multiple heterogeneous data sources and resolve conflicts according to a conflict resolution rule base, ensuring that each attribute has a unique and authoritative value. In one implementation, all business data objects mapped to the same entity node can be traversed, and for each attribute, the authoritative attribute value is selected or calculated based on the priority or aggregation strategy in the conflict resolution rule base. In another implementation, data fusion technology can be used, combining probabilistic models or trust assessments to weightedly fuse attribute values ​​from different sources to obtain the most reliable attribute value.

[0120] These logical constraint rules are a set of logical restrictions and conditions defined in the business entity graph regarding entity attributes, relationships between entities, and business processes. Their purpose is to verify the internal consistency of merged entities, the compliance of their relationships with other entities, and whether they conform to the expected business logic. These logical constraint rules can include data type constraints (e.g., age must be an integer), range constraints (e.g., temperature must be between -50 and 100), uniqueness constraints (e.g., unique device IDs), and non-null constraints. Furthermore, these logical constraint rules can also include relationship constraints (e.g., "a user can only have one master account"), business process constraints (e.g., "a repair order must have a fault description before it can enter the processing stage"), and ontology-based reasoning rules (e.g., "if A is a subclass of B, then A inherits all attributes of B").

[0121] The purpose of verifying the attribute integrity, relationship compliance, and business logic consistency of merged entities is to ensure that the merged entity data is not only authoritative in terms of attribute values, but also correct and consistent in terms of structure, relationships, and business meaning. One implementation involves checking whether all required attributes have values ​​for attribute integrity. For relationship compliance, it verifies whether the relationships between entities conform to the cardinality and type constraints defined in the graph. For business logic consistency, it checks whether the entity state conforms to the business process by executing predefined business rules or an inference engine. Another implementation uses data quality management tools to automatically check merged entities through a series of preset quality rules, generate quality reports, and mark data that does not meet the specifications.

[0122] The purpose of this additional consistency verification label is to clearly identify which standardized business entities have passed rigorous semantic merging, conflict resolution, and logical verification, thereby improving the credibility and usability of these entities in subsequent intelligent customer service processes. In one implementation, a boolean field (e.g., is_validated: true) or a string field (e.g., validation_status: "Consistency passed") can be added to the metadata of the standardized business entities. In another implementation, a unique verification ID or digital signature can be assigned to entities that pass verification and stored in a blockchain or other immutable ledger to provide a higher level of credibility proof.

[0123] Through the above technical solution, this application addresses the potential attribute conflicts and logical inconsistencies that may arise during semantic merging when constructing multi-source business data models by employing a systematic semantic matching, conflict arbitration, and logical verification mechanism. This ensures the high consistency and reliability of the generated standardized entity set. Specifically, semantic matching is performed based on a predefined business entity graph, associating business data objects from different data sources with standard entity nodes to establish a set of entity mapping relationships. This step utilizes the unified framework of the graph to ensure semantic alignment between data sources, providing an accurate foundation for subsequent merging and avoiding mapping deviations caused by data source heterogeneity. Attribute-level merging and conflict arbitration are performed according to the conflict resolution rule base in the business entity graph. Multiple business data objects mapped to the same entity node are processed to generate merged entities with unique authoritative attribute values. This process eliminates attribute conflicts through the arbitration mechanism of the rule base, ensuring the uniqueness and authority of each entity attribute and resolving data inconsistency issues under multi-data source competition. Based on the logical constraint rules in the business entity graph, the integrity of attributes, compliance of relationships, and consistency of business logic of merged entities are verified. Consistency verification tags are added to entities that pass the verification, forming a standardized set of business entities. This verification step utilizes the graph's constraint rules to verify the overall compliance of entities and adds tags to identify verified entities, thereby improving the quality and credibility of the standardized set and providing reliable data support for dynamic business environments. This application can effectively improve the accuracy and dynamic adaptability of multi-source business data models, providing a high-quality data foundation for subsequent dynamic coupling, automated simulation dialogue, and conflict identification, thereby enhancing the robustness and deployment efficiency of intelligent customer service systems.

[0124] In some of the solutions mentioned above in this application, a dynamic coupling of scenario process digital twins and multi-source business data models is proposed in a dynamic business sandbox to generate pre-simulation logs. However, in this process, the simulation environment initialization may fail to accurately bind real-time business data to process nodes due to a lack of precise data mapping, resulting in an unstable pre-simulation foundation. Input sequence generation may not fully cover key dialogue paths, and boundary scenarios may be missed due to the ineffective utilization of historical interaction patterns. Rule matching may lag behind dynamic business changes, reducing simulation accuracy due to the lack of real-time querying and constraints. Log recording may be incomplete, affecting subsequent conflict analysis due to the failure to synchronously capture node execution details, rule events, and path decision information, resulting in low-quality pre-simulation logs that are difficult to support efficient conflict identification.

[0125] To address this, this application proposes a method for dynamically coupling a scenario process digital twin with real-time business data from a multi-source business data model within a dynamic business sandbox. This drives a dialogue engine within the sandbox to execute multiple rounds of automated simulation dialogue, generating a pre-playback log containing node transitions, parameter passing, and external data call results. See [link to relevant documentation] Figure 5The method specifically includes the following steps:

[0126] 501. Based on the preset data mapping relationship between the multi-source business data model and the scenario process digital twin, real-time business data is dynamically bound to the corresponding process nodes in the dynamic business sandbox to complete the simulation environment initialization.

[0127] The simulation environment initialization aims to provide a foundation for subsequent automated simulation dialogues that closely mirrors the real business environment, ensuring the accuracy and validity of simulation results. It solves the problem of inaccurate simulations caused by loose coupling between data and processes by precisely binding real-time business data to process nodes in the scenario's digital twin. One implementation method is to define the pre-defined data mapping relationships using XML or JSON configuration files, explicitly specifying the correspondence between specific data fields in the multi-source business data model and the required parameters of each process node in the scenario's digital twin, as well as data type conversion rules and data validation logic. During simulation environment initialization, the system parses these configuration files and extracts real-time business data from the multi-source business data model based on the parsing results, dynamically injecting it into the corresponding process node parameters through API interfaces or memory mapping mechanisms. Another implementation method utilizes a graphical interface tool, allowing business experts or configuration personnel to establish data mapping relationships through drag-and-drop, and automatically generating mapping metadata. This metadata is read by the interpreter at runtime. Real-time business data is obtained from the multi-source business data model through the data bus or message queue, and is bound to the runtime variables or attributes of the process nodes in the scenario process digital twin according to the rules defined by the metadata through reflection mechanism or dynamic proxy technology.

[0128] 502. Based on the historical interaction patterns in the multi-source business data model, generate a set of simulated user input sequences covering multiple key dialogue paths in the digital twin of the scenario process.

[0129] The generation of simulated user input sequence sets aims to simulate the diversity of interactions between real users and the intelligent customer service system, ensuring that simulated dialogues cover multiple key dialogue paths in the digital twin of the scenario process, thereby comprehensively verifying the robustness of the process. This solves the problem of missing boundary scenarios due to insufficient input sequence coverage. One implementation involves the system extracting a large amount of historical user interaction logs from a multi-source business data model. Natural language processing techniques (such as intent recognition and slot filling) are used to analyze user dialogue samples and their corresponding system response paths, statistically analyzing the coverage frequency and success rate of different dialogue paths to form historical interaction patterns. Then, combined with the topology of the scenario process digital twin (such as state nodes and transition conditions), key business paths (e.g., paths involving high-frequency business, high-risk operations, or complex decisions) are identified. Based on these historical dialogue samples and the node constraints of key paths, generative adversarial networks (GANs) or rule-based template filling methods are used to generate diverse simulated user input sequences that conform to business logic. Another implementation approach is to employ reinforcement learning-based methods. The agent interacts with the digital twin of the scene process and adjusts its strategy for generating user input sequences based on feedback from the pre-play log (such as whether the dialogue was successfully completed or whether an exception was triggered). At the same time, it combines expert-defined key dialogue path templates to guide the agent to prioritize the exploration of these paths and expand the input sequences through mutation, combination, and other methods to ensure comprehensive coverage of key paths.

[0130] 503. Based on the set of simulated user input sequences, drive the dialogue engine to traverse different state transition paths in the digital twin of the scenario process, and in the process of execution, use the rule interpreter of the dynamic business sandbox to query and match the dynamic business rules and constraints in the multi-source business data model in real time to generate a multi-round automated simulation dialogue process.

[0131] The generation of multi-turn automated simulation dialogue aims to simulate the continuous and dynamic interaction between the intelligent customer service system and the user, verifying the behavioral logic of the scenario process digital twin under different input and business data conditions. It solves the problem of matching failure caused by lagging rule updates through real-time querying and matching by the rule interpreter, ensuring the dynamic adaptability of the simulated dialogue. One implementation involves the dialogue engine receiving the current input from the simulated user input sequence and passing it to the scenario process digital twin for intent recognition and state updates. At each decision node, the scenario process digital twin invokes the rule interpreter of the dynamic business sandbox. The rule interpreter accesses the multi-source business data model in real time, querying dynamic business rules (such as business processing conditions and permission verification rules) and data constraints (such as inventory and user balance) related to the current node state and user input. Based on the query results, the rule interpreter determines the next step of the process (such as which node to jump to and what parameters are required) and returns the instructions to the dialogue engine for execution, thereby driving the multi-turn dialogue. Another implementation involves an event-driven architecture between the dialogue engine and the scenario process digital twin. When the digital twin of the scenario process enters a state requiring external decision-making or data verification, an event is triggered. The rule interpreter in the dynamic business sandbox listens for these events and, based on the event type and current context, retrieves the latest business rules and data from the multi-source business data model in real time. The rule interpreter executes these rules and publishes the execution results (e.g., whether to allow continuation, what information needs to be supplemented) as new events. The dialogue engine receives these events, updates the dialogue state accordingly, generates a system response, and continues processing the next simulated user input.

[0132] 504. During the execution of the automated simulation dialogue process, the node execution details triggered by the scene flow digital twin, the rule matching and data call events generated by the rule interpreter, the content and parsing results of the simulated user input sequence, and the path decision information of the dialogue engine are recorded synchronously and integrated to generate a pre-drill log.

[0133] The fusion and generation of pre-drill logs aims to comprehensively and accurately record all key information during the automated simulation dialogue process, providing a detailed data foundation for subsequent conflict identification, root cause analysis, and optimization strategy generation. It solves the problem of information omissions caused by incomplete log recording, ensuring log reliability. One implementation involves deploying multiple log collection agents within the dynamic business sandbox during the execution of the automated simulation dialogue process. These agents are responsible for capturing different types of information: one agent records execution details such as entry, exit, parameter changes, and state transitions for each node in the scenario process digital twin. Another agent records events such as rule IDs, matching results, data call parameters, and return values ​​generated by the rule interpreter when querying and matching dynamic business rules and constraints. A third agent records the original content of the simulated user input sequence, the intent after natural language understanding, and the slot parsing results. The internal modules of the dialogue engine record information such as the path chosen and confidence level during the decision-making process. All this information is aggregated through a unified log bus, sorted and correlated according to timestamps, and fused and stored as a structured pre-drill log file (such as JSON Lines or Parquet format). Another approach is to use a distributed tracing system (such as OpenTracing or OpenTelemetry). At each stage of the simulated dialogue, a Span is generated, recording the start time, end time, operation name, input / output parameters, and any relevant metadata. The node execution of the scene flow digital twin, rule matching by the rule interpreter, data calls, user input parsing, and path decisions by the dialogue engine are all considered independent Spans and associated through Trace IDs. These Spans are sent to a centralized tracing backend for storage and analysis, forming a complete and traceable pre-drill log that clearly shows the entire call chain and data flow of the simulated dialogue.

[0134] Through the above technical solutions, this application refines the simulation dialogue execution process in the dynamic business sandbox and systematically improves the generation quality of pre-simulation logs. Based on preset data mapping relationships, real-time business data is dynamically bound to process nodes to complete the simulation environment initialization. This step utilizes preset mapping to ensure accurate correspondence between data and nodes, avoiding binding deviations caused by loose coupling, thus establishing a solid pre-simulation foundation and solving the problem of inaccurate simulation environment initialization. Based on historical interaction patterns, a set of simulation user input sequences covering multiple key dialogue paths is generated. This step drives input sequence design through historical data, ensuring comprehensive coverage of key paths and solving the defect of missing boundary scenarios due to insufficient input, thereby solving the problem of insufficient path coverage. Then, the dialogue engine traverses the state transition paths based on the input sequences, and the rule interpreter queries and matches dynamic business rules and constraints in real time. This step, leveraging the real-time mechanism of the rule interpreter, applies business rules in real-time during the simulation, overcoming the matching failure problem caused by rule update lag, enhancing the dynamic adaptability of the simulation, and thus solving the problem of rule matching lag. The process of synchronously recording node execution details, rule events, input sequence content, and path decision information, and fusing them to generate a pre-simulation log, eliminates the risk of information omission through multi-dimensional data synchronization, providing a reliable basis for subsequent conflict analysis and thus solving the problem of incomplete log recording. These technical features work synergistically not only optimize every stage of the simulation process but also, through data mapping, historical pattern utilization, real-time rule matching, and comprehensive log fusion, improve the overall accuracy and completeness of the pre-simulation log, effectively supporting the identification and optimization of dynamic business conflicts.

[0135] In some of the solutions mentioned above in this application, a simulation environment initialization is proposed to bind real-time business data to process nodes in a dynamic business sandbox. However, in this process, inaccurate data mapping relationship parsing may lead to incorrect identification of target nodes, insufficient extraction and verification of real-time business data may result in a lack of semantic compatibility, and the inability to dynamically respond to changes in external data may cause initialization rigidity. These problems make the simulation environment initialization inaccurate, affecting the authenticity and reliability of subsequent automated simulation dialogues.

[0136] In response, this application further proposes a method for dynamically coupling a scenario process digital twin with real-time business data in a multi-source business data model within a dynamic business sandbox, driving the dialogue engine within the sandbox to execute multiple rounds of automated simulation dialogue, and generating a pre-simulation log containing node jumps, parameter passing, and external data call results. The specific steps include: based on the preset data mapping relationship between the multi-source business data model and the scenario process digital twin, dynamically binding real-time business data to the corresponding process nodes in the dynamic business sandbox to complete the simulation environment initialization.

[0137] Specifically, this initialization process parses the preset data mapping relationships, determines the target set of process nodes in the scenario process digital twin that need to be bound to data, and the mapping associations and data transformation rules between each node in the target process node set and the data entities in the multi-source business data model. This step aims to accurately identify which nodes in the scenario process digital twin require external data and how this data should be obtained and transformed from the multi-source business data model. For example, this can be implemented in a configuration-based manner, defining mapping configuration files in XML or JSON format, which explicitly specify the correspondence between specific node identifiers in the scenario process digital twin and specific data entities (such as device IDs, policy clause IDs) in the multi-source business data model, and include rules for data type conversion, field renaming, etc. The system reads and parses these configuration files during initialization to build a mapping table in memory. Another implementation method is to configure through a visual interface, allowing business analysts or developers to establish associations between scenario process digital twin nodes and multi-source business data model entities on a graphical interface through drag-and-drop, connection, and other operations, and configure data transformation logic (such as data formatting, unit conversion, default value filling, etc.). The system automatically converts these visual configurations into executable mapping rules.

[0138] Based on the aforementioned mapping and data transformation rules, real-time business data is dynamically extracted and verified from the multi-source business data model to generate a set of context data instances semantically compatible with the target process nodes. The core of this step lies in acquiring the latest business data in real time according to preset rules, ensuring its quality and compatibility with the logic of the digital twin nodes in the scenario process. Dynamic extraction can utilize the API interfaces or database query services provided by the multi-source business data model to obtain the latest business data in real time based on the entity identifiers and attribute paths specified in the mapping. The verification process can include data type checks, range constraint checks, and non-empty checks to ensure that the data conforms to the specifications defined in the data transformation rules. For example, for a node requiring device status, the system will extract the current device's operating status from the device ledger according to the mapping relationship and verify whether it is the expected enumerated value. Furthermore, an efficiency improvement can be achieved by maintaining a data caching layer, periodically synchronizing data from the multi-source business data model, and prioritizing retrieval from the cache during extraction. Verification can be combined with machine learning models to detect anomalies in the extracted data. For example, it can determine whether a device parameter exceeds the historical normal fluctuation range or whether a policy text contains sensitive words, thereby generating a high-quality, semantically compatible set of contextual data instances.

[0139] The context data instance set is dynamically injected and preloaded into the target process node. Simultaneously, dynamic rule channels and data change listeners connected to the multi-source business data model are activated in the dynamic business sandbox. This enables the scenario process digital twin to respond to real-time changes in external data during subsequent simulations, completing the simulation environment initialization. This step aims to ensure data is available at the start of the simulation and establish a dynamic connection between the simulation environment and external real-time data sources. Dynamic injection and preloading can be achieved by storing the context data instance set in a shared memory area within the dynamic business sandbox or in the data slots of specific nodes, allowing direct access to the execution logic of the scenario process digital twin. The dynamic rule channel can be a message queue or event bus, where the data update service of the multi-source business data model publishes data change events. The data change listener subscribes to these events and triggers a re-evaluation or state update of the corresponding node in the scenario process digital twin upon receiving relevant data changes. Alternatively, the dynamic business sandbox can create an independent microservice proxy for each target process node, responsible for maintaining the data state required by the node. When the context data instance set is injected, the proxy updates its internal state. Dynamic rule channels can be a bidirectional communication mechanism based on WebSocket or gRPC, allowing multi-source business data models to proactively push data updates. Data change listeners, as part of the proxy, are responsible for receiving these pushes and updating node data according to preset strategies (such as immediate updates, delayed updates, and conditional updates), thereby ensuring that the digital twin of the scenario process can perceive and respond to external data changes in real time.

[0140] By analyzing the pre-defined data mapping relationships, the target process node set and its mapping relationships and data transformation rules that need to be bound to the scenario process digital twin can be accurately identified. This effectively avoids node binding errors caused by ambiguous mapping relationships, thereby improving the target orientation of initialization. Real-time business data is dynamically extracted and verified based on the mapping relationships and data transformation rules. Rule-driven data extraction and rigorous verification ensure data quality and semantic compatibility with the target process node logic, preventing simulation errors caused by data inconsistency. Furthermore, the dynamic injection and preloading of context data instance sets into the target process nodes achieves real-time data availability in the simulation environment. By synchronously activating dynamic rule channels and data change listeners connected to multi-source business data models, a real-time response mechanism is established, enabling the scenario process digital twin to perceive and respond to real-time changes in external data during subsequent simulations, avoiding the rigidity of the simulation environment. Overall, this precise and dynamic initialization process enhances the realism and reliability of automated simulation dialogue, allowing the intelligent customer service process to more accurately reflect the actual business environment and providing a solid foundation for subsequent conflict identification and optimization.

[0141] In some of the solutions mentioned above in this application, a simulated user input sequence based on a multi-source business data model is proposed to drive automated simulated dialogue. However, in this process, the analysis of historical interaction data is not in-depth enough when directly generating the input sequence, and the scene topology is not effectively integrated, resulting in insufficient coverage of key dialogue paths, low simulation efficiency, and inability to fully reflect potential conflicts in dynamic business environments.

[0142] To address this, this application proposes a method for generating a set of simulated user input sequences covering multiple key dialogue paths in a digital twin of a scenario process. This method is based on historical interaction patterns in a multi-source business data model. Specifically, the method includes: extracting user dialogue samples and system response paths from the historical interaction data of the multi-source business data model, and analyzing to obtain historical dialogue path coverage statistics. Integrating the historical dialogue path coverage statistics with the topological features of the scenario process digital twin, a target set of key dialogue paths is selected. Based on the user dialogue samples and the node constraints of each path in the target set of key dialogue paths, an adapted initial set of simulated user input sequences is generated. The dynamic business sandbox is invoked, and the initial set of simulated user input sequences is used to drive a pre-rendering process. Based on the actual path coverage data triggered by the pre-rendering, the initial set of simulated user input sequences is filtered and enhanced, iteratively generating the final set of simulated user input sequences.

[0143] This method extracts user dialogue samples and system response paths from historical interaction data of a multi-source business data model, and analyzes the historical dialogue path coverage statistics. This step aims to obtain authentic user expression habits and system response patterns from the interaction records between actual users and the intelligent customer service system. Specifically, Natural Language Processing (NLP) technology can be used to deeply analyze massive historical interaction logs, identifying and extracting specific user dialogue expressions in different business scenarios, as well as the system's response action sequences to these dialogues, thereby constructing user dialogue samples. Simultaneously, by tracing and aggregating these interaction sequences, statistical information such as the frequency of occurrence, success rate, and user satisfaction of different dialogue paths can be analyzed, forming historical dialogue path coverage statistics. For example, rule-based pattern matching or machine learning models can be used to identify user intent and entities, and record the start, middle, and end states of each interaction, thereby constructing a complete system response path. Another approach is to construct an interaction graph, abstracting user input, system processing, data querying, and other processes into graph nodes, and the interaction flow into graph edges. Graph algorithms are then used to analyze the connectivity, importance, and historical traffic distribution of the paths.

[0144] By integrating historical dialogue path coverage statistics with the topological characteristics of the scenario's digital twin, a set of target critical dialogue paths is selected. This step aims to comprehensively consider the actual situation of historical interactions and the structural characteristics of the business process itself to determine the most representative and valuable dialogue paths for testing. Integrating historical dialogue path coverage statistics with the topological characteristics of the scenario's digital twin means not only focusing on paths frequently used by users, but also considering those paths that are crucial in business logic but may not be frequently triggered, or those paths containing complex decision points and prone to errors. For example, each node or path in the scenario's digital twin can be assigned attributes such as business criticality and complexity. These attributes are then weighted with statistical data such as historical coverage frequency and success rate to obtain a comprehensive evaluation score. Based on this score, a threshold can be set to select paths with higher scores as the target set of critical dialogue paths. Alternatively, a multi-criteria decision analysis method can be used to balance multiple dimensions such as historical popularity, business risk, and path length to ensure that the selected critical paths reflect mainstream user behavior while covering potential business risk points.

[0145] Based on this, an adapted initial set of simulated user input sequences is generated using the user dialogue sample and the node constraints of each path in the target key dialogue path set. This step aims to construct the initial user input sequence to drive the simulation based on the selected key dialogue paths and real user expression habits. Using the user dialogue sample ensures that the generated input sequence has high realism and diversity, avoiding overly rigid simulation input. Meanwhile, the node constraints of each path (e.g., a node requires the user to provide specific parameters or express a specific intent) guide the generation direction of the input sequence, ensuring it can effectively trigger key nodes on the target path. For example, template generation technology can be used to use key phrases or sentence structures from the user dialogue sample as templates, combined with the parameter types and value ranges defined in the node constraints, to generate input sequences that conform to specific business scenarios. Another approach is to use a rule-based semantic generator to select or rewrite statements that satisfy these constraints from the user dialogue sample based on the expected intent and required entity information of each node on the target path, and combine them according to the execution order of the path to form a complete input sequence.

[0146] The dynamic business sandbox is invoked, and the initial set of simulated user input sequences is used to drive a pre-run. Based on the actual path coverage data triggered by the pre-run, this initial set of simulated user input sequences is filtered and enhanced, iteratively generating the final set of simulated user input sequences. This step aims to verify and optimize the initially generated input sequences through actual simulation pre-runs, thereby improving the comprehensiveness and efficiency of simulation coverage. Invoking the dynamic business sandbox means putting these initial input sequences into a sandbox that simulates a real operating environment for testing. During the pre-run, the sandbox records the actual paths executed by the dialogue engine, i.e., the actual path coverage data. Based on this data, it is possible to analyze which input sequences successfully triggered the target critical path and which failed to trigger or led to unexpected paths. For input sequences that failed to effectively cover the target path, they can be adjusted, supplemented, or regenerated, for example, by modifying keywords in the dialogue, adjusting parameter values, or adding new expressions to enhance their coverage. For paths that have already been covered, their efficiency and redundancy can be evaluated and optimized. This process is iterative until the generated set of simulated user input sequences can fully cover the target critical dialogue path and meet the preset simulation quality requirements. For example, an adaptive generation algorithm based on coverage feedback can be used to dynamically adjust the generation strategy of the input sequence according to the coverage results of each pre-simulation, so as to minimize the uncovered paths and maximize the simulation efficiency.

[0147] Through the above technical solutions, this application addresses the problem of insufficient coverage of key dialogue paths by systematically generating and iteratively optimizing simulated user input sequences, thereby improving the comprehensiveness and efficiency of simulated dialogues. Specifically, user dialogue samples and system response paths are extracted from historical interaction data, and historical dialogue path coverage statistics are obtained through analysis. This utilizes real interaction patterns to quantify path frequency and quality, providing a reliable data foundation for subsequent screening and avoiding bias caused by subjective experience. The target key dialogue path set is screened by integrating historical coverage statistics with scene topology features. This combines historical interaction patterns and scene logical dependencies to ensure that key paths cover both high-frequency interactions and reflect business importance, preventing the omission of key test points. An initial input sequence set is generated based on user dialogue samples and path node constraints. This constructs inputs according to actual user expression habits and path logic requirements, ensuring that simulated inputs fit real scenarios and improving the test realism of the dialogue engine. A dynamic business sandbox is invoked to drive pre-simulation, and input sequences are iteratively screened and enhanced based on actual coverage data. This dynamically adjusts the input sequences through real-time simulation feedback, gradually optimizing coverage and accuracy, reducing redundant testing, and improving overall efficiency.

[0148] In some of the embodiments described above in this application, a method is proposed to integrate historical dialogue path coverage statistics with the topological features of the scenario process digital twin to filter the target key dialogue path set. However, in this process, relying solely on historical coverage statistics may not be able to fully capture the topological complexity and business criticality of the path, resulting in the selected path being incomplete or unrepresentative and unable to effectively cover multiple scenario boundary situations, thereby affecting the generation quality and pre-play effect of subsequent simulated user input sequences.

[0149] In response, this application further proposes a method for selecting a set of target key dialogue paths by integrating historical dialogue path coverage statistics with the topological features of the digital twin of the scenario process, specifically including:

[0150] Based on the topology of the digital twin of the scene process, a set of candidate dialogue paths containing all possible state transition sequences is generated. This step aims to comprehensively explore all potential dialogue flows that the digital twin of the scene process can express, ensuring the completeness of subsequent analysis. Specifically, graph traversal algorithms, such as depth-first search (DFS) or breadth-first search (BFS), can be used to systematically explore all reachable state nodes and transition edges starting from the starting node of the digital twin of the scene process until the ending node is reached, thereby enumerating and recording all valid paths from the start to the end. Another implementation is to use pathfinding algorithms in graph theory, such as path enumeration methods based on matrix operations, to identify and generate all non-repeating state transition sequences as candidate dialogue paths by analyzing the adjacency matrix or reachability matrix of the digital twin of the scene process.

[0151] The historical dialogue path coverage statistics are mapped to the candidate dialogue path set, and each candidate dialogue path is labeled with its historical coverage frequency and interaction quality indicators. This step introduces actual user interaction data into path evaluation, giving the paths importance and performance dimensions in practical applications. Specifically, path matching algorithms, such as those based on sequence alignment or edit distance calculation, can be used to compare the actual dialogue paths extracted from the historical interaction data of the multi-source business data model with the paths in the candidate dialogue path set. For successfully matched candidate paths, the number of times they appear in historical data is counted as the historical coverage frequency, and their interaction quality indicators are calculated and labeled based on indicators such as user satisfaction ratings, session duration, and problem resolution rate associated with historical interaction records. Alternatively, path feature vectors can be constructed to vectorize historical interaction paths and candidate dialogue paths, and then matching can be performed using methods such as cosine similarity. The statistical data (such as frequency and average satisfaction) of historical paths with high matching degrees can be mapped to the corresponding candidate paths.

[0152] This step analyzes the topological features of the digital twin of the scenario process and calculates the path complexity score and business key node density score for each candidate dialogue path. This step quantifies the intrinsic attributes of each path from the perspectives of structure and business importance. Specifically, the path complexity score can be calculated by weighting factors such as path length (number of nodes), number of branches, existence of loop structures, and number of conditional judgment nodes. For example, the longer the path, the more branches, and the more loops or complex conditional judgments it contains, the higher its complexity score. Another way to calculate the path complexity score is to use metrics such as cyclomatic complexity or information entropy in graph theory to measure the structural complexity of the path. The calculation of the business key node density score can be done by pre-defining the business key nodes in the digital twin of the scenario process (e.g., key nodes involving core business logic, data modification, external system calls, or user decisions), then counting the number of business key nodes in each candidate path and calculating the ratio of this number to the total number of nodes in the path, or summing them according to the preset weights of the key nodes to reflect the business importance of the path.

[0153] A multi-objective path evaluation model is constructed, which normalizes and weights the historical coverage frequency, interaction quality index, path complexity score, and business key node density score of each candidate dialogue path to generate a comprehensive path priority. This step aims to comprehensively consider multi-dimensional information and provide a unified and comparable evaluation standard for each path. Specifically, a linear weighting method can be used to normalize each index (historical coverage frequency, interaction quality index, path complexity score, and business key node density score), for example, using Min-Max normalization to scale the values ​​to the [0, 1] interval, and then weighting and summing the normalized indices according to preset weights to obtain the comprehensive path priority. Another approach is to use multi-criteria decision-making methods such as the Analytic Hierarchy Process (AHP) or TOPSIS (Topology for Approximating Ideal Solutions) to more precisely determine the relative importance of each index by comparing each index pairwise or calculating the distance to the ideal solution, and then calculating the comprehensive path priority accordingly.

[0154] The candidate dialogue paths are sorted from highest to lowest based on their overall priority. Paths meeting a preset number or priority threshold are selected to form the target critical dialogue path set. This step determines the most representative and important set of critical paths. Specifically, a fixed number N can be set, and the N paths with the highest overall priority can be directly selected as the target critical dialogue path set. Alternatively, a priority threshold T can be set, and all paths with an overall priority higher than T can be selected. In practical applications, these two methods can be combined. For example, the N highest priority paths can be selected first, while ensuring that the lowest priority of these paths is not lower than a certain preset threshold to ensure the quality of the selected paths.

[0155] By employing the aforementioned technical solution, this application overcomes the problem of incomplete and unrepresentative path selection that may result from relying solely on historical coverage statistics. By comprehensively generating candidate dialogue paths and combining them with multi-dimensional indicators such as historical interaction data, path structure complexity, and business criticality for integrated evaluation, it can more accurately and comprehensively identify truly important and critical dialogue paths that require focused attention. This not only ensures that subsequent simulated user input sequences can effectively cover multiple scenario boundary situations, improving the quality and efficiency of simulation pre-running, but also provides a more accurate diagnostic basis for optimizing intelligent customer service processes, thereby enhancing the robustness and deployment efficiency of the intelligent customer service system.

[0156] In some of the solutions mentioned above in this application, an initial set of simulated user input sequences is generated based on node constraints of user speech samples and target key dialogue path sets to cover key dialogue paths. However, in this process, the generated initial sequences may lack diversity, fail to effectively preserve the original intent semantics, or have redundancy and uneven distribution, resulting in incomplete simulated dialogue coverage and affecting the accuracy of conflict identification.

[0157] To address this, this application further proposes a method for generating an adapted initial simulated user input sequence set based on the user dialogue sample and the node constraints of each path in the target key dialogue path set. This method includes:

[0158] For each path in the set of key dialogue paths for this objective, the business intent constraints and parameter constraints associated with the key nodes in each path are parsed to generate a set of node constraint configurations.

[0159] Using the constraint configuration set of this node as a condition, multi-dimensional semantic matching and constraint compliance verification are performed on the user's speech sample to select compliant user speech samples. Based on semantic similarity, text mutation is performed on the compliant user speech samples while preserving the original intent semantics to generate a diverse speech candidate set.

[0160] Based on the execution sequence and logical dependencies of nodes on each path, suitable dialogues are selected from the diverse dialogue candidate set for each key node and serialized and arranged to generate an initial simulated user input subsequence covering each path.

[0161] The initial simulated user input subsequences generated for all target key dialogue paths are aggregated, and cross-path redundancy elimination and distribution balance optimization are performed to form the set of initial simulated user input sequences.

[0162] Specifically, for each path in the set of key dialogue paths for this objective, the business intent constraints and parameter constraints associated with the key nodes in each path are parsed to generate a set of node constraint configurations. "Business intent constraints" refer to the range or type of intent the system expects the user to express at a specific dialogue node, such as "check electricity bill" or "report a fault." "Parameter constraints" refer to the specific information, format, and value range that the system needs to obtain from user input at a specific dialogue node, such as "device number must be a number" or "repair time must be within the next three days." Parsing these constraints can be achieved in various ways. For example, they can be extracted from the node metadata of the digital twin of the scenario process based on a predefined business rule engine. Alternatively, Natural Language Processing (NLP) technology can be used to perform semantic analysis on the node descriptions to automatically identify and structure these constraints. Generating the set of node constraint configurations aims to integrate these discrete constraint information into a unified format data structure, such as a JSON or XML file, that can be used in subsequent steps. This structure includes fields such as node ID, intent type, parameter name, parameter type, and value range.

[0163] Based on this, using the node constraint configuration set as a condition, multi-dimensional semantic matching and constraint compliance verification are performed on the user dialogue sample to filter out compliant user dialogue samples. Then, based on semantic similarity, text mutation is performed on these compliant user dialogue samples while preserving the original semantic intent, generating a diverse dialogue candidate set. "Multi-dimensional semantic matching" refers to considering not only the literal meaning of the user dialogue but also its deep semantics, contextual relationships, and sentiment tendencies to determine whether it matches the business intent in the node constraints. This can be achieved through semantic embedding and similarity calculation using deep learning models (such as BERT, GPT, etc.) or through rule-based keyword matching and semantic slot filling techniques. "Constraint compliance verification," on the other hand, further checks whether the user dialogue contains all the parameters required by the node, and whether these parameters meet the preset format and value range requirements. For example, regular expressions can be used to verify the parameter format, or database queries can be used to verify the validity of the parameters. After filtering out compliant user dialogue samples, to increase the diversity of the simulated dialogue, these compliant samples need to undergo "text mutation." Text mutation refers to generating various forms of speech without altering the original intent and key information, through methods such as synonym replacement, sentence structure transformation, word order adjustment, and the addition or deletion of non-key modifiers. For example, rule-based template filling or deep generative models such as Generative Adversarial Networks (GANs) or Variational Autoencoders (VAEs) can be used to generate new speech variants while maintaining semantic consistency.

[0164] Furthermore, based on the execution sequence and logical dependencies of nodes along each path, suitable dialogues are selected from the diverse dialogue candidate set for each key node and serialized and arranged to generate an initial simulated user input subsequence covering each path. Here, "execution sequence" refers to the fixed sequential relationship between different nodes in a dialogue path. "Logical dependency" refers to the fact that the execution or parameter acquisition of a node may depend on the output or state of the previous node. When selecting suitable dialogues, a heuristic algorithm can be used to choose the dialogue that best satisfies the constraints of the current node from the diverse dialogue candidate set, based on the node's business intent and parameter requirements. For example, the semantic similarity score between candidate dialogues and node constraints can be calculated, and the dialogue with the highest score can be selected. Serialization and arrangement involves orderly combining the selected suitable dialogues according to the execution sequence and logical dependencies of the path to form a complete input sequence simulating user-system interaction. This can be achieved by constructing a state machine or flowchart, using the dialogue of each node as input for state transitions, and ensuring the correct transmission of parameters and the coherence of the context.

[0165] The initial simulated user input subsequences generated for all target key dialogue paths are aggregated, and redundancy elimination and distribution balance optimization are performed across paths to form the initial simulated user input sequence set. "Redundancy elimination" refers to identifying and removing input sequences that appear repeatedly or are semantically highly similar across different paths to avoid unnecessary repetitive simulations and improve efficiency. This can be achieved by calculating the semantic similarity or hash value between subsequences and setting a threshold for deduplication. "Distribution balance optimization" ensures that the generated initial simulated user input sequence set evenly covers all target key dialogue paths, preventing some paths from being over-simulated while others are ignored. For example, the coverage rate of each path can be calculated, and the sampling weights of each path's subsequences can be adjusted based on the coverage rate, or a graph-based minimum path coverage algorithm can be used to optimize the distribution of the sequence set.

[0166] Through the above technical solutions, this application systematically solves the problems of insufficient diversity, missing intent retention, and redundancy imbalance in the initial simulation user input sequence generation. By parsing the business intent constraints and parameter constraints of key nodes, it ensures that the subsequent generation process strictly follows business rules, avoiding sequence deviations caused by constraint omissions. Through multi-dimensional semantic matching and constraint compliance verification, it guarantees the compliance of user utterance samples, and on this basis, through semantic similarity text variation, it maintains the intent... Figure 1 While maintaining consistency, the scope of dialogue was expanded, resolving the coverage limitations caused by single dialogues. Dialogue selection and serialization were based on the execution sequence and logical dependencies of nodes, ensuring that the generated sub-sequences were logically coherent and specifically covered certain paths, avoiding path jump errors. Through cross-path redundancy elimination and distribution balancing optimization, the overall efficiency of the sequence set was improved, resolving resource waste and uneven coverage issues. These improvements collectively ensure that simulated dialogues can more comprehensively and accurately cover critical paths, thereby improving the accuracy and efficiency of dynamic business conflict identification and providing a more reliable input foundation for subsequent process optimization.

[0167] In some of the solutions mentioned above in this application, a set of simulated user input sequences is proposed to cover the key dialogue paths in the digital twin of the scenario process. However, when driving the dialogue engine to traverse these paths, there are problems of incomplete path coverage and low efficiency. Specifically, due to the lack of a dynamic adjustment mechanism, the traversal process may repeatedly test high-coverage paths while ignoring uncovered or low-coverage key paths, resulting in wasted resources, insufficient boundary case testing, and affecting the comprehensiveness of the pre-simulation and the optimization effect.

[0168] To address this, this application further proposes a step-by-step approach to drive the dialogue engine to traverse different state transition paths in the digital twin of the scenario flow based on the set of simulated user input sequences. This includes: initializing a path traversal scheduling strategy based on the association between the set of simulated user input sequences and the set of target key dialogue paths; selecting the current simulated user input sequence from the set of simulated user input sequences based on the path traversal scheduling strategy, and driving the dialogue engine to execute a single-round simulated dialogue; determining the state transition of the dialogue engine in the digital twin of the scenario flow based on the real-time matching results of the rule interpreter, and recording the generated actual path segments; updating the global path coverage state based on the actual path segments after the single-round simulated dialogue is completed, and dynamically adjusting the path traversal scheduling strategy based on the global path coverage state to give higher execution priority to simulated user input sequences associated with uncovered or low-coverage key dialogue paths; and repeatedly executing the selection, driving, recording, and adjustment steps until the global path coverage state meets the preset traversal termination condition, thus completing the traversal of the multiple state transition paths.

[0169] Specifically, the initial path traversal scheduling strategy aims to provide an initial, directional framework for subsequent path traversal, ensuring the orderliness and targeting of the traversal process, avoiding blind or random traversal, thereby improving the efficiency and effectiveness of the simulation and coverage. For example, a weighted directed graph can be constructed to represent the relationship between the set of simulated user input sequences and the set of target key dialogue paths. The weights of the edges can be preset based on historical coverage data or expert experience, and the scheduling strategy prioritizes input sequences corresponding to paths with lower coverage or higher business importance based on these weights. Alternatively, a rule engine-based approach can be adopted, with a series of preset rules, such as "prioritize covering untraversed paths" and "prioritize covering paths with high business risk levels." These rules are loaded during initialization and used to guide the selection of subsequent input sequences.

[0170] After initializing the path traversal scheduling strategy, the system selects the current simulated user input sequence from the simulated user input sequence set based on this strategy, driving the dialogue engine to execute a single-turn simulated dialogue. This step is the core of the actual simulated dialogue execution. By selecting an input sequence from the pre-generated simulated user input sequence set according to the scheduling strategy and providing it as user input to the dialogue engine, a real user interaction is simulated. The execution of the single-turn simulated dialogue allows the system to observe the behavior and state transitions of the dialogue engine under specific inputs. For example, the scheduler can maintain a queue of input sequences to be executed, and each time it takes the highest priority input sequence from the head of the queue and passes it to the input interface of the dialogue engine. After receiving the input, the dialogue engine processes it according to its internal intent recognition, slot filling, dialogue management, and other modules, and generates a corresponding system response. Alternatively, an event-driven approach can be used. When the scheduling strategy determines the next input sequence to be executed, an event is triggered. This event carries the content of the input sequence and is captured by the dialogue engine's listener, thus initiating the single-turn dialogue processing flow.

[0171] During this single-round simulated dialogue execution, based on the real-time matching results of the rule interpreter, the state transition of the dialogue engine in the scenario flow digital twin is determined, and the generated actual path segments are recorded. This step aims to ensure that each step of the simulated dialogue accurately reflects the actual logic of the scenario flow digital twin. The rule interpreter matches the current state of the dialogue engine, the user input parsing results, and the dynamic business rules in the multi-source business data model in real time. The matching results directly guide the state transition of the dialogue engine in the digital twin, and record in detail the key nodes, parameter changes, and decision paths in this process, providing a basis for subsequent analysis and optimization. For example, the rule interpreter can be an independent module that is invoked at each decision point of the dialogue engine. It receives information such as the current dialogue state, user intent, and collected parameters, and queries the rule base in the multi-source business data model, returning one or more matching rules and their execution instructions (such as which node to jump to or which external interface to call). The dialogue engine updates its current node in the scenario flow digital twin according to these instructions and records this transition process and related data in the pre-play log. Alternatively, the rule interpreter can be embedded in the dialogue management module of the dialogue engine, triggered by preset hook functions when specific events (such as intent recognition completion or slot filling completion) occur. It calculates the next state node based on the current context and business rules, updates the state of the scenario flow digital twin, and records detailed information about the state transition (such as source node, target node, triggering conditions, and passed parameters).

[0172] After a single round of simulated dialogue is completed, the global path coverage status is updated based on the actual path fragment. The path traversal scheduling strategy is then dynamically adjusted according to this global path coverage status, giving higher execution priority to simulated user input sequences associated with uncovered or low-coverage key dialogue paths. This is a crucial step in achieving dynamic optimization and comprehensive coverage. By analyzing the actual path fragments generated in a single round of simulated dialogue, the system can understand in real time which key dialogue paths have been covered and which are still untouched or insufficiently covered. Based on this information, the scheduling strategy can be dynamically adjusted, prioritizing paths that have not yet been fully validated, thereby avoiding repeated testing of fully covered paths and improving traversal efficiency and test comprehensiveness. For example, the system can maintain a global path coverage matrix or graph, recording the coverage count, coverage depth, or coverage rate of each key dialogue path. After each single round of simulated dialogue, the generated actual path fragments are parsed, and the matrix is ​​updated. The scheduling strategy module periodically or under specific conditions queries this matrix to identify paths with coverage below a threshold and increases the priority of their associated simulated user input sequences, for example, by adjusting queue order or increasing weights. Alternatively, reinforcement learning or heuristic algorithms can be used to dynamically adjust the scheduling strategy. The path coverage status serves as environmental feedback, and the scheduling strategy represents the agent's actions. Through learning, the algorithm continuously optimizes the selection order of input sequences to maximize path coverage or minimize traversal time. When uncovered or low-coverage paths are detected, the algorithm generates or selects input sequences that can reach these paths and assigns them higher execution priority.

[0173] The selection, driving, recording, and adjustment steps are executed iteratively until the global path coverage state meets the preset traversal termination condition, completing the traversal of the multiple state transition paths. This step ensures the automation and integrity of the entire simulation pre-run process. By continuously iteratively executing the above core steps, the system can systematically explore all key dialogue paths in the scenario flow digital twin until a preset coverage target is reached or other termination conditions are met, thereby comprehensively verifying the robustness and correctness of the intelligent customer service process. For example, termination conditions may include: the coverage rate of all target key dialogue paths reaches a preset threshold (e.g., 95%); or the preset maximum number of iterations is reached; or the global path coverage state no longer improves in consecutive iterations. The loop terminates when any condition is met. Alternatively, a time-based termination condition can be set, such as the total simulation duration reaching a preset value. Before each loop begins, the system checks whether the current global path coverage state meets the termination condition. If not, the next round of selection, driving, recording, and adjustment operations continues.

[0174] Through the above technical solution, this application can solve the problems of incomplete path coverage and low efficiency in intelligent customer service process simulation. Specifically, by initializing the path traversal scheduling strategy based on the association between the set of simulated user input sequences and the set of target key dialogue paths, a clear guiding direction is provided for the subsequent traversal process, avoiding blind exploration. During the execution of a single round of simulated dialogue, the state transition of the dialogue engine in the digital twin of the scenario process is determined based on the real-time matching results of the rule interpreter, and the actual path fragments are recorded, ensuring the accuracy and traceability of the simulation process. More importantly, after the completion of a single round of simulated dialogue, the global path coverage state is updated based on the actual path fragments, and the path traversal scheduling strategy is dynamically adjusted according to this state, so that simulated user input sequences associated with uncovered or low-coverage key dialogue paths receive higher execution priority. This dynamic feedback and adjustment mechanism can effectively avoid repeatedly testing fully covered paths, concentrate limited simulation resources on unverified or insufficiently verified areas, and improve the efficiency and comprehensiveness of the simulation. By iteratively executing these steps until the preset traversal termination condition is met, the systematic and complete traversal of multiple state transition paths in the digital twin of the scenario process is ensured, thereby fully verifying the robustness of the intelligent customer service process and providing a solid foundation for subsequent conflict identification and optimization.

[0175] In some of the embodiments described above in this application, a method is proposed to query and match dynamic business rules and constraints in a multi-source business data model in real time through the rule interpreter of a dynamic business sandbox during execution, generating a multi-round automated simulation dialogue process to ensure that the simulation dialogue conforms to the dynamic business environment and generate a pre-drill log. However, in this process, the set of dynamic business rules queried and the set of real-time data constraints may be disordered and conflicting, resulting in an unclear rule execution sequence and chaotic instruction execution, affecting the accuracy and efficiency of the dialogue process, and failing to reliably simulate the dynamic changes in real business scenarios.

[0176] To address this, this application further proposes a method where, during execution, a rule interpreter within a dynamic business sandbox queries and matches dynamic business rules and constraints in a multi-source business data model in real time, generating a multi-round automated simulation dialogue process. Specifically, at each decision node of the scenario process digital twin, the rule interpreter, based on the current state node identifier, the current round's simulated user input, and historical parameter transmission records, queries the multi-source business data model in real time for matching sets of dynamic business rules and real-time data constraints. The rule interpreter prioritizes and resolves conflicts within the queried sets of dynamic business rules and real-time data constraints, generating a rule execution sequence suitable for the current decision node. The rule interpreter parses the rule execution sequence into a set of executable instructions, including node jump instructions, parameter transmission instructions, and external data call instructions, and drives the dialogue engine to execute this set of instructions. Simultaneously, rule matching details and instruction execution results are synchronously recorded in the pre-play log. This query, sorting and conflict resolution, parsing, and driving process is repeated until all input sequences in the simulated user input sequence set are processed, forming a multi-round automated simulation dialogue process.

[0177] Specifically, at each decision node of the scenario flow digital twin, the rule interpreter queries the multi-source business data model in real time for a matching set of dynamic business rules and a set of real-time data constraints based on the current state node identifier, the simulated user input content of the current round, and historical parameter transmission records. This step aims to ensure that at each key decision point in the simulated dialogue, the system can obtain the business logic and data constraints most relevant to the current dialogue state, user input, and historical context, thereby making the simulated behavior highly similar to the real business environment. In one implementation, the rule interpreter pulls or receives rules and constraints matching the current state node identifier, user input content, and historical parameter transmission records from the multi-source business data model in real time through an API interface or message queue subscription mechanism. For example, the node identifier can be used as the query key, keywords in the user input as semantic matching conditions, and historical parameters as context filters for efficient retrieval in the rule base and data constraint base. In another implementation, the rule interpreter maintains a lightweight, high-concurrency rule cache and establishes a data synchronization mechanism with the multi-source business data model. When a decision node triggers a query, it first retrieves rules and constraints from the cache. If the rules and constraints are not present in the cache or have expired, it sends a query request to the multi-source business data model in real time and updates the cache to balance query efficiency and real-time performance.

[0178] The rule interpreter prioritizes and resolves conflicts between the retrieved dynamic business rule set and real-time data constraint set, generating a rule execution sequence suitable for the current decision node. This step aims to address potential disorder, redundancy, or logical conflicts in the retrieved dynamic business rules and data constraints, ensuring that there is only one clear, consistent, and optimal execution path at a specific decision node. In one implementation, the rule interpreter incorporates a rule engine containing predefined priority strategies (e.g., rules specific to business scenarios take precedence over general rules, and data validation rules take precedence over business logic rules) and conflict resolution algorithms (e.g., arbitration based on rule creation time, most recent update time, or preset weights). When a rule conflict is detected, the engine automatically selects a rule or generates a composite rule based on these strategies. In another implementation, an expert system or machine learning-based approach can be used. Expert systems handle conflicts through manually defined meta-rules, such as "if rule A and rule B conflict, then execute rule A." Machine learning models can learn and predict the optimal rule execution order and conflict resolution scheme in a specific context based on historical simulation data and manually labeled conflict resolution cases.

[0179] Building upon this foundation, the rule interpreter parses the rule execution sequence into a set of executable instructions, including node jump instructions, parameter passing instructions, and external data call instructions. It then drives the dialogue engine to execute this set of instructions, simultaneously recording rule matching details and instruction execution results to the pre-run log. This step aims to transform abstract business rules and data constraints into concrete operational instructions that the dialogue engine can understand and execute, ensuring that the execution process of these operations is fully recorded, providing a basis for subsequent analysis and optimization. In one implementation, the rule interpreter includes an instruction generation module. This module converts the rule execution sequence into an instruction format recognizable by the dialogue engine API, based on the type (e.g., conditional judgment, data assignment, external service call) and content of the rule. For example, a rule "jump to node X" would be parsed as the `dialogEngine.jumpToNode("X")` instruction. A rule "query user balance" would be parsed as the `externalService.queryBalance(userId)` instruction, and the result would be passed to the dialogue engine. In another implementation, the rule interpreter and the dialogue engine communicate via a standardized message protocol. The rule interpreter encapsulates the parsed set of instructions into a message of a specific format and sends it to the dialogue engine. Upon receiving the message, the dialogue engine invokes the corresponding internal module or external interface to execute the operation based on the instruction type. Simultaneously, the log module of the rule interpreter or the dialogue engine captures information such as the execution status of the instructions, parameter changes, and external call results, and writes this information in a structured manner into the pre-render log.

[0180] The process iteratively executes the query, sorting and conflict resolution, parsing and driving steps until all input sequences in the simulated user input sequence set are processed, forming a multi-round automated simulated dialogue process. This iterative execution mechanism aims to ensure that the simulation process can comprehensively cover all preset simulated user input sequences, thereby fully testing the behavior of the scenario process digital twin under different user input and business data conditions, improving the completeness and coverage of the simulation. In one implementation, the dynamic business sandbox maintains a queue of simulated user input sequences. In each iteration, an input sequence is taken from the queue, driving the dialogue engine to execute one or more rounds of dialogue until the sequence is processed. The loop terminates when the queue is empty. In another implementation, the dynamic business sandbox adopts an event-driven iterative mechanism. When a simulated user input sequence is processed, a "sequence complete" event is triggered. The sandbox scheduler captures this event and selects the next unprocessed input sequence according to a preset traversal strategy (e.g., depth-first, breadth-first, or random selection), and restarts the simulation process. The loop will continue until all input sequences are marked as "processed" or the preset iteration limit is reached.

[0181] Through the above technical solution, at each decision node of the scenario flow digital twin, the rule interpreter can query the matching dynamic business rule set and real-time data constraint set from the multi-source business data model in real time based on the current state node identifier, the simulated user input content of the current round, and historical parameter transmission records. This ensures the real-time nature and context-specificity of rule matching, avoids the limitations of static rule bases, and makes the simulated dialogue closely related to the current dialogue state and user input, effectively preventing mismatches caused by data isolation. Furthermore, the rule interpreter prioritizes and resolves conflicts in the queried dynamic business rule set and real-time data constraint set, generating a rule execution sequence suitable for the current decision node. This approach handles the competition between rules through a clear priority strategy and eliminates logical contradictions through a conflict resolution algorithm, thereby generating a clear and consistent execution sequence, ensuring the accuracy and reliability of decision-making, and solving the problem of execution chaos caused by disordered rules. Building upon this foundation, the rule interpreter parses the rule execution sequence into a set of executable instructions, including node jump instructions, parameter passing instructions, and external data call instructions. It then drives the dialogue engine to execute this set of instructions, simultaneously recording rule matching details and instruction execution results to the pre-run log. This achieves a seamless transformation from abstract rules to concrete operational instructions, ensuring the coherent execution of node jumps, parameter passing, and external calls. By synchronously recording detailed rule matching and instruction execution results, it provides comprehensive and accurate evidence for subsequent conflict analysis and root cause localization. By iteratively executing the above query, sorting and conflict resolution, parsing, and driving steps until all input sequences in the simulated user input sequence set are processed, a multi-round automated simulated dialogue process is formed. This ensures the completeness and multi-round nature of the simulation process, comprehensively covering various user inputs and business scenarios, effectively avoiding omissions of certain scenarios, and improving the robustness and verification efficiency of the intelligent customer service process in dynamic business environments.

[0182] In some of the solutions mentioned above in this application, dynamic business conflicts caused by dynamic mismatch of business data or differences in user expression are proposed to locate problems in joint analysis. However, in this process, there is a lack of a systematic mechanism to distinguish and accurately classify conflict types, resulting in incomplete conflict identification or ambiguous classification, which affects the accuracy of subsequent root cause analysis and optimization strategies, thereby prolonging the iteration cycle and reducing the robustness of intelligent customer service processes.

[0183] To address this, this application proposes a method for jointly analyzing rehearsal logs and multi-source business data models to identify dynamic business conflicts caused by dynamic mismatches in business data or differences in user expression. (See [link to relevant documentation]). Figure 6 The method includes the following steps:

[0184] 601. Extract from the rehearsal logs the parameter validation failure events, rule matching blocking events, and user input parsing events that cause the process execution to be interrupted.

[0185] 602. Associate parameter verification failure events and rule matching blocking events with the real-time status of the corresponding business entities in the multi-source business data model, verify whether the real-time status meets the data requirements of the current node of the scenario process digital twin, and generate a dynamic set of business data mismatch conflicts.

[0186] 603. For user input parsing events, analyze the semantic deviation between the expression of the user input parsing event and the preset standard intent of the scenario flow digital twin, and identify parsing events with semantic deviation exceeding the threshold and actually causing path redundancy as user expression difference conflict set.

[0187] 604. Merge the dynamic mismatch conflict set of business data with the user expression difference conflict set to form a dynamic business conflict.

[0188] Specifically, when extracting parameter validation failure events, rule matching blocking events, and user input parsing events causing dialogue path redundancy from the pre-drill logs, this step aims to accurately filter out key events indicating potential business conflicts from a large amount of pre-drill log data, providing foundational data for subsequent conflict classification and root cause analysis. By focusing on process interruptions (parameter validation failures, rule matching blocking) and dialogue path redundancy (user input parsing events), the main types of problems that intelligent customer service processes may encounter in actual operation can be effectively identified. In one implementation, this can be achieved through preset log parsing rules and pattern matching algorithms. For example, regular expressions or keyword lists can be defined to identify entries in the logs containing specific error codes or descriptive text such as "parameter validation failure," "data type mismatch," "rule blocking," "intent recognition failure," and "path backtracking." When a log entry matches these rules, it is extracted as the corresponding event. In another implementation, different types of anomalies or key behaviors can be clearly labeled with event type tags during the pre-drill log generation stage. For example, when the dialogue engine fails to perform parameter validation, it directly records an entry in the log labeled "Parameter Validation Failure Event," along with the reason for the failure and relevant parameter information. In this way, the extraction process is simplified to filtering by label.

[0189] This step, which involves associating parameter validation failure events and rule matching blocking events with the real-time status of the corresponding business entities in the multi-source business data model to verify whether the real-time status meets the data requirements of the current node of the scenario process digital twin and generating a dynamic mismatch conflict set of business data, aims to deeply analyze the process interruption caused by data issues. By associating the extracted parameter validation failure events and rule matching blocking events with the real-time business data in the multi-source business data model, it can be verified whether the actual state of the business data meets the data conditions and constraints expected by the current node of the scenario process digital twin when the simulated dialogue occurs. This helps to clearly determine whether the conflict stems from the dynamic mismatch of business data. In one implementation, when a parameter validation failure event or rule matching blocking event is extracted, the parameter name, business entity identifier, rule ID, and occurrence time can be parsed from the event log. Then, this information is used to query the real-time status data of the corresponding business entity at that time point in the multi-source business data model. The queried real-time status is then compared and verified with the preset data requirements of the current node of the scenario process digital twin (e.g., parameter data type, value range, business logic constraints, etc.). If the conditions are not met, it is determined to be a dynamic mismatch conflict in business data. In another implementation, data snapshots can be generated for relevant business entities in the multi-source business data model periodically or when triggered at key nodes during the pre-rehearsal process. When a parameter validation failure or rule matching blocking event occurs, the system backtracks to the most recent data snapshot and, in conjunction with the data requirements of the current node in the scenario process digital twin, verifies the snapshot data through the built-in rule engine or validation module.

[0190] When analyzing the semantic deviation between the user input parsing event and the pre-defined standard intent of the scene flow digital twin, and identifying parsing events with semantic deviation exceeding a threshold and actually causing path redundancy as a set of user expression difference conflicts, this step focuses on identifying dialogue flow problems caused by the diversity or ambiguity of user expression. By quantifying the semantic difference between user input and the system's standard intent, and combining this with whether it leads to invalid dialogue paths (redundancy), user expression difference conflicts that truly affect process efficiency and user experience can be effectively filtered out. In one implementation, for user input parsing events, the original user input text and the pre-defined standard intent of the current node of the scene flow digital twin (or the closest intent identified by the intent recognition model) can be extracted. Then, natural language processing (NLP) techniques, such as word embeddings, sentence embeddings, or pre-trained language models (such as BERT, GPT, etc.), are used to calculate the semantic similarity score between the two. When the score is below a preset semantic deviation threshold, and the pre-run log shows that the parsing event led to repetition, backtracking, or entry into unexpected branches in the dialogue path (i.e., path redundancy), it is identified as a user expression discrepancy conflict. In another implementation, the confidence score of the intent recognition model can be utilized. When user input is parsed as an intent, but the confidence score of that intent is below a certain threshold, or the model provides multiple intents with similar confidence scores leading to decision ambiguity, it can be marked as a potential user expression discrepancy event. Combined with the dialogue path recorded in the pre-run log, if these low-confidence or ambiguous recognitions lead to unexpected path jumps or redundant dialogue, it is confirmed as a user expression discrepancy conflict.

[0191] When merging the dynamic mismatch conflict set of business data with the user expression difference conflict set to form a dynamic business conflict, this step integrates the two independently identified conflict types to form a comprehensive and unified view of dynamic business conflicts. This ensures that subsequent root cause analysis and optimization strategies can simultaneously consider all potential conflicts caused by data issues and user expression issues, avoiding omissions and thus providing a more comprehensive solution. In one implementation, the most direct approach is to use a union operation of sets. All conflict instances in the dynamic mismatch conflict set of business data and all conflict instances in the user expression difference conflict set are simply merged into a new set. During the merging process, a "conflict type" label (e.g., "data mismatch" or "user expression difference") can be added to each conflict instance for later differentiation. In another implementation, deduplication logic can be added to the simple merging process to prevent a single event from being classified as a borderline case of both conflicts in certain complex scenarios. Furthermore, priorities can be set for different types of conflicts, and they can be sorted during merging so that more critical conflicts can be addressed first in subsequent analysis.

[0192] Through the aforementioned technical solution, this application achieves accurate identification and classification of dynamic business conflicts by jointly analyzing pre-drill logs and multi-source business data models. Specifically, by extracting parameter validation failure events, rule matching blocking events, and user input parsing events from the pre-drill logs, this application can comprehensively capture key issues leading to process interruptions and dialogue path redundancy, ensuring coverage of all potential conflict sources. By associating parameter validation failure events and rule matching blocking events with real-time business data in the multi-source business data model and verifying whether they meet the data requirements of the current node of the scenario process digital twin, this application can identify conflicts caused by dynamic mismatch of business data, thereby clarifying the root cause of data-related problems. Simultaneously, regarding user input parsing events, this application effectively identifies conflicts caused by differences in user expression by analyzing the semantic deviation between user input expression and the preset standard intent of the scenario process digital twin, combined with the actual occurrence of path redundancy. By merging these two conflict sets, this application constructs a comprehensive and clearly categorized dynamic view of business conflicts, providing structured and high-precision input for subsequent root cause analysis and the formulation of automated optimization strategies. This improves the comprehensiveness and accuracy of conflict identification, thereby enhancing the robustness and iterative efficiency of the intelligent customer service process.

[0193] In some embodiments described above in this application, a method for analyzing the root cause categories and affected process node sets of dynamic business conflicts is proposed to support the generation of optimization strategies. However, in its implementation, the root cause is not accurately located, the impact scope analysis is incomplete, and it relies on manual experience for root cause classification and node impact analysis, resulting in ineffective and inefficient optimization strategies. To address this, this application further proposes a method for analyzing the root cause categories and affected process node sets of dynamic business conflicts, see [link to method]. Figure 7 The method includes:

[0194] 701. For dynamic business conflicts, locate the process node where the dynamic business conflict first occurs in the pre-drill log, extract the data operation context of the process node, and associate it with the specific business entities and attributes in the multi-source business data model to determine the direct root cause node and abnormal data item.

[0195] 702. Based on a predefined root cause classification rule base, perform pattern matching between direct root cause nodes and abnormal data items to determine the root cause category of dynamic business conflicts. The rules of the root cause classification rule base are derived from the business entity relationships and state constraints defined in the multi-source business data model.

[0196] 703. Starting from the direct root cause node, analyze all downstream nodes that depend on abnormal data items or are affected by the state changes of the direct root cause node along the topology of the scenario flow digital twin, and combine the evidence of subsequent execution interruption or path deviation recorded in the pre-run log to determine the set of affected flow nodes.

[0197] Specifically, when locating the process node where a dynamic business conflict first occurs, in-depth analysis of the pre-execution logs can be performed. For example, by searching for the first recorded parameter validation failure event, rule matching blocking event, or user input parsing anomaly event, the initial trigger point of the conflict can be accurately identified. Another approach is to configure a real-time anomaly capture and reporting mechanism for each process node in the scenario's digital twin during the execution of automated simulation dialogue in the dynamic business sandbox. Once any event that does not conform to preset business logic or data constraints is detected, the currently executing node is immediately marked and recorded as the first occurrence node of the conflict. When extracting the data operation context of a process node, all input parameters, output results, intermediate variables, and internal data processing logic executed before and after execution can be recorded. For example, the pre-execution log can record in detail the user input received by the node, the data queried from multi-source business data models, the calculation results performed internally by the node, and the data items attempted to be updated. This contextual information provides a comprehensive data foundation for subsequent root cause analysis. To associate these data operation contexts with specific business entities and attributes in the multi-source business data model, a mapping relationship between process nodes and business entities and their attributes in the multi-source business data model can be predefined when constructing the scenario process digital twin. After extracting the data operation context, the system queries the multi-source business data model based on these mapping relationships to find the specific business entity and its attributes corresponding to the conflicting data item. For example, an invalid "device number" can be associated with the "device ledger" entity and its "device ID" attribute in the multi-source business data model. Through these steps, the direct root cause node leading to the conflict and the specific abnormal data item can be accurately identified.

[0198] Based on this, this application utilizes a predefined root cause classification rule base to perform pattern matching between identified direct root cause nodes and abnormal data items to determine the root cause category of dynamic business conflicts. This root cause classification rule base is a structured knowledge base containing various preset conflict root cause patterns and their corresponding classification labels, such as "incorrect data format," "missing data," "inconsistent business logic," and "insufficient permissions." Each rule defines specific matching conditions, such as "when the abnormal data item is a device status and the error message is an invalid status value, the root cause category is 'data status constraint not satisfied.'" The rules in this rule base are derived from the business entity relationships and status constraints defined in the multi-source business data model, ensuring the business relevance and accuracy of the classification. For example, if the multi-source business data model stipulates that a certain "user" entity must be associated with a "service contract" entity, and the "service contract" must be in an "effective" state, then when the pre-run log shows that a user does not have an effective service contract, the root cause classification rule base can identify it as "business entity relationship not satisfied" or "business status constraint not satisfied." By comparing features such as the type of the direct root cause node, the data type of its operation, the specific value or format of the abnormal data item, and the error message with patterns in the rule base, the root cause category of the conflict can be automatically determined.

[0199] To comprehensively analyze the scope of the conflict's impact, this application takes the direct root cause node as the starting point and systematically analyzes all downstream nodes that depend on anomalous data items or are affected by the state changes of the direct root cause node, following the topology of the scenario flow digital twin. The scenario flow digital twin has clearly defined directed connections and data flow dependencies between nodes. The system can traverse all subsequent nodes that may be affected by anomalous data items or exhibit abnormal behavior due to changes in the state of the direct root cause node, following these connection and dependency paths. For example, if the direct root cause node fails to correctly obtain the operating parameters of a device, all subsequent nodes that need to use these operating parameters for judgment or operation may be affected. Simultaneously, this application empirically confirms the theoretically affected nodes by combining evidence of subsequent execution interruptions or path deviations recorded in the pre-run log. The pre-run log records in detail the execution status, parameter transmission, rule matching results, and dialogue paths of each node. By examining these logs, it's possible to identify whether theoretically affected downstream nodes have indeed experienced execution interruptions (e.g., throwing errors, abnormal termination), rule matching failures (e.g., conditions not being met causing the process to stop), parameter passing anomalies (e.g., receiving null values, type mismatches), or dialogue paths deviating from expectations (e.g., skipping critical business processing nodes, entering incorrect branch processes). All process nodes empirically confirmed to be affected by the conflict are then grouped together to form a set of affected process nodes.

[0200] Through the above technical solution, this application can achieve accurate location of the root causes of dynamic business conflicts and comprehensive analysis of their impact scope. By locating the process node where the conflict first occurred in the pre-run log and extracting its data operation context, and simultaneously associating it with specific business entities and attributes in the multi-source business data model, the source of the conflict can be accurately captured, avoiding misjudgment of the starting point and providing a detailed data foundation for root cause analysis, thereby accurately identifying direct root cause nodes and abnormal data items. This method ensures that root cause analysis is based on the actual business environment and data status, improving the accuracy of root cause location. Furthermore, based on a predefined root cause classification rule base, pattern matching is performed on direct root cause nodes and abnormal data items, automatically determining the root cause category of dynamic business conflicts. Since the rules in this rule base originate from the business entity relationships and state constraints defined in the multi-source business data model, a high degree of consistency between root cause classification and business logic is guaranteed, reducing reliance on manual experience and improving the reliability and efficiency of classification. Furthermore, starting from the direct root cause node, this method systematically analyzes all downstream nodes that depend on anomalous data items or are affected by state changes of the direct root cause node along the topology of the scenario's digital twin. Empirical confirmation is then achieved by combining this with evidence of subsequent execution interruptions or path deviations recorded in the pre-run logs, enabling a comprehensive and accurate identification of the affected process node set. This approach avoids omitting key nodes, ensures the completeness of the impact scope analysis, and lays a solid foundation for generating comprehensive and effective optimization strategies. The implementation method of this application reduces the costs of manual intervention and trial and error, improves the effectiveness and automation level of intelligent customer service process optimization strategies, thereby enhancing the robustness and deployment efficiency of intelligent customer service systems in the energy industry.

[0201] In some of the solutions described above in this application, the downstream nodes are analyzed starting from the direct root cause node to determine the set of affected process nodes. However, in this process, the analysis may be based solely on theoretical dependencies and ignore evidence from actual execution, resulting in the identified set of affected nodes including theoretically unaffected nodes or omitting actually affected nodes, thereby affecting the accuracy and efficiency of subsequent optimization strategies.

[0202] To address this, this application proposes a method for determining the set of affected process nodes. Starting from the direct root cause node, the method analyzes all downstream nodes that depend on the anomalous data item or are affected by the state transition of the direct root cause node along the topology of the digital twin of the scenario process. This analysis, combined with evidence of subsequent execution interruptions or path deviations recorded in the pre-run log, determines the set of affected process nodes. The method specifically includes the following steps:

[0203] Based on the topology of the digital twin of this scenario process, starting from the direct root cause node, all downstream nodes that depend on the abnormal data item or the direct root cause node in terms of data flow or state logic are identified, forming a theoretically influential node set. The topology of this scenario process digital twin refers to the network graph of various nodes (such as user intent recognition, system action execution, data query, etc.) and their state transition relationships in the intelligent customer service process. It can be stored as a directed graph, where nodes represent a state or operation in the process, and edges represent state transitions or data flows. Alternatively, it can be represented using Petri nets or finite state machines to more accurately describe concurrency, synchronization, and state transitions. The direct root cause node refers to the process node first identified in the pre-run log analysis as causing dynamic business conflicts. It is the starting point of the conflict chain; its abnormal state or behavior directly triggers subsequent problems. It can be located by tracing back through the pre-run logs to pinpoint the first node where parameter validation failed, rule matching was blocked, or user input parsing was abnormal. Alternatively, by combining business rules and process logic, one can trace back from the point of conflict occurrence until the smallest, most direct process unit that caused the event is found. The anomalous data item refers to the specific data element or attribute associated with the direct root cause node that causes the business conflict. These data items may not conform to the expected format or value range, or may contradict the business logic. After locating the direct root cause node, one can identify the specific data fields directly related to the conflict by analyzing the input, output, or internal state data that the node depends on during execution. Alternatively, by combining data constraints and validation rules in a multi-source business data model, one can perform reverse validation on the data processed by the direct root cause node to find data instances that do not meet the constraints. All downstream nodes that depend on the anomalous data item or are affected by the state transition of the direct root cause node refer to all subsequent nodes in the scenario flow digital twin whose execution logic, data input, or state transitions are affected by the value of the anomalous data item or the state change of the direct root cause node. This can be identified by analyzing the control flow and data flow dependency graph of the scenario flow digital twin, starting from the direct root cause node, along the data transmission path and state transition path, to identify all nodes that directly or indirectly use the anomalous data item or are affected by the output of the direct root cause node. Alternatively, graph traversal algorithms (such as depth-first search or breadth-first search) can be used to find all reachable nodes in the topology, starting from the direct root cause node, and then filtering based on the data dependency metadata between nodes.The theoretically affected node set refers to the set of all downstream nodes that may theoretically be affected by anomalies, starting from the direct root cause node, based on the topological structure and logical dependencies of the scenario process digital twin. This can be achieved by aggregating all identified downstream nodes using the dependency analysis method described above, forming a preliminary list of potentially affected nodes based on static structural analysis. Alternatively, an influence propagation graph can be constructed, where nodes represent process nodes and edges represent influence relationships; the theoretically affected node set then comprises all nodes reachable from the root cause node.

[0204] To ensure the theory affects each node in the node set, the execution record corresponding to each node is searched in the pre-simulation log. Empirical evidence of execution interruption, rule matching failure, or parameter passing anomalies is extracted from this execution record. The pre-simulation log is the system-recorded log data during the automated simulation dialogue execution in the dynamic business sandbox. It contains detailed execution context data including node jumps, parameter passing, external data call results, rule matching details, user input parsing results, and dialogue engine decision information. It can use a structured log format (such as JSON or XML) to record the input, output, state variables, timestamps, and error messages of each simulation step. Alternatively, a distributed tracing system (such as OpenTracing or Zipkin) can be used to perform end-to-end tracing of the simulation process, capturing the call chain and detailed metadata of each operation. The execution record is a detailed record generated for each execution of a specific node in the scenario flow digital twin within the pre-simulation log. It includes the node's input, output, internal state, execution result, time consumption, and any abnormal events. In the pre-simulation log, each node generates a unique transaction ID or session ID during execution and records all relevant information for that node in a specific simulation round. Alternatively, log hooks can be configured for each node to automatically write its key states and events to the rehearsal log when the node is activated or completes execution. Empirical evidence of execution interruption, rule matching failure, or parameter passing anomalies refers to specific events or states explicitly recorded in the rehearsal log that indicate the process execution failed to proceed as expected or encountered errors. Evidence of execution interruption can be keywords such as "Error," "Exception," or "Timeout" recorded in the log, or the process status changing directly from "Running" to "Failed" without reaching the expected completion state. Evidence of rule matching failure can be explicit messages such as "Rule not matched" or "Condition not met" in the log, or the rule interpreter returning an empty result. Evidence of parameter passing anomalies can be error messages such as "Invalid parameter," "Missing argument," or "Type mismatch" recorded in the log, or parameter values ​​not being updated as expected.

[0205] Nodes for which empirical evidence is found are identified as actually affected nodes. These actually affected nodes are those within the theoretically affected node set whose execution is confirmed to have been interrupted, rule matching failed, or parameter passing anomalies by reviewing the pre-run logs. This can be achieved by iterating through all execution records of each node in the theoretically affected node set within the pre-run logs; if any of the aforementioned anomalies are found, that node is marked as actually affected. Alternatively, a log analyzer can be designed to automatically identify anomaly patterns in the pre-run logs and correlate them with theoretically affected nodes, thereby filtering out the actually affected nodes.

[0206] Arrange all the actually affected nodes according to their order within the topology to generate a set of affected process nodes. This arrangement according to the topology means sorting all identified actually affected nodes based on their execution order or data flow order within the scenario's digital twin topology. This can be done using a topology sorting algorithm to ensure that problems at upstream nodes are addressed before those at downstream nodes. Alternatively, nodes can be sorted according to their depth or level within the process, or according to their distance from the direct root cause node, to facilitate the gradual application of subsequent optimization strategies.

[0207] Through the above technical solution, this application can accurately identify the set of nodes actually affected by dynamic business conflicts in the intelligent customer service process. Specifically, based on the topology structure of the scenario process digital twin, starting from the direct root cause node, all downstream nodes that depend on abnormal data items or the direct root cause node in data flow or state logic are identified, forming a theoretically affected node set. This ensures comprehensive coverage of potentially affected nodes starting from the root cause node, avoiding omission of key dependencies. On this basis, for each node in the theoretically affected node set, the execution record corresponding to each node is searched in the pre-run log to extract empirical evidence of whether there is execution interruption, rule matching failure, or parameter passing anomaly. The actual execution data is used to verify whether the node is truly affected by the anomaly, effectively filtering out theoretically false positive nodes. Nodes with found empirical evidence are determined as actually affected nodes, and only nodes supported by actual evidence are retained, improving the accuracy and reliability of conflict identification. Arranging all the actually affected nodes in the order of the topology to generate a set of affected process nodes not only provides a clear and orderly intervention target for subsequent structured optimization strategies, but also avoids ineffective intervention on unaffected nodes, thereby improving optimization efficiency and accuracy. This solves the problem that relying solely on theoretical dependency analysis may lead to inaccurate identification, which in turn affects the accuracy and efficiency of subsequent optimization strategies.

[0208] In some of the solutions mentioned above in this application, optimization strategies are generated based on root cause categories and the set of affected process nodes. However, this process usually relies on expert experience to manually formulate strategies. The generated strategies may contradict each other, not conform to business logic, and lack executable priority guidance, resulting in low feasibility of optimization solutions, chaotic implementation, and difficulty in directly driving effective process iteration.

[0209] To address this, this application proposes a method for generating structured optimization strategies for digital twins of scene processes, see [link to relevant documentation]. Figure 8 The method includes:

[0210] 801. Based on the root cause category, match the corresponding optimization strategy template from the preset optimization strategy knowledge base. The optimization strategy template includes node adjustment rules and data adaptation rules.

[0211] 802. Parameterize and logically instantiate the node information and associated abnormal data items in the affected process node set with the rules in the optimization strategy template to generate a set of optimization instructions for specific nodes.

[0212] 803. Execute conflict resolution and business logic consistency verification between the execution strategies of the optimized instruction set, and prioritize the execution based on the execution logic of the digital twin of the scenario process to generate the structured optimization strategy.

[0213] Specifically, this optimization strategy knowledge base is a predefined, structured collection of solutions that stores general optimization schemes or templates for different root cause categories (e.g., missing data, mismatched data formats, incorrect intent recognition, etc.). This knowledge base can be a relational database storing the mapping between different root cause categories and their corresponding optimization strategy templates. Each template contains a series of predefined action sequences, conditional statements, and parameter placeholders. Alternatively, it can be an ontology-based knowledge graph, where nodes represent root cause categories, process node types, data entities, etc., edges represent the relationships between them, and optimization strategy templates are associated with specific root cause nodes in the form of rules or scripts. The optimization strategy template is a parameterizable, general blueprint designed for a specific root cause category; it is not a concrete solution but rather an instantiable framework. The optimization strategy template can be described using XML, JSON, or a domain-specific language (DSL), containing rules for node adjustment and rules for data adaptation, including variable placeholders for subsequent parameterization. Alternatively, it can be represented as a series of predefined function or microservice call sequences, each function or service corresponding to a node adjustment or data adaptation operation, with its input parameters being variables to be bound.

[0214] The node adjustment rules are specific instructions within the optimization strategy template that guide how to modify the structure or attributes of the scenario flow digital twin. These rules aim to directly address flow logic issues, such as incorrect jumps, missing steps, or redundant nodes. The node adjustment rules can include instructions such as "add a new node," "delete an existing node," "modify node type," "adjust the connection relationship between nodes," and "update the internal logic of a node (such as intent recognition threshold, parameter validation logic)." Alternatively, it can be a set of condition-action pairs, such as "if the root cause is ambiguous intent recognition, insert a sub-flow node clarifying the intent before the current node." The data adaptation rules are specific instructions within the optimization strategy template that guide how to process or modify data to resolve inconsistencies or mismatches. These rules aim to ensure that the data consumed or generated by the scenario flow digital twin is compatible with its requirements and multi-source business data models. The data adaptation rules can include instructions such as "data format conversion," "data type validation," "missing data filling (such as default values ​​or supplementation through external queries)," "data cleaning (such as removing invalid characters)," and "data mapping (such as unifying synonyms from different data sources)." Alternatively, it can be defined as a data conversion function or script, such as "converting a string date to a standard date format" or "validating the range of input parameters according to business rules".

[0215] When parameterizing and logically instantiating the node information and associated abnormal data items in the affected process node set with the rules in the optimization strategy template, this process aims to fill the general placeholders (parameters) in the optimization strategy template with specific values ​​extracted from the identified problem nodes and related abnormal data items, thereby generating specific, executable instructions. This can be achieved through a rule engine or script interpreter, which receives the optimization strategy template and the node information (such as node ID, type, current configuration) and associated abnormal data items (such as data value, data type, error code) in the affected process node set, and then maps and fills these specific information into the predefined variable placeholders in the template. Alternatively, it can be achieved through dynamic code generation technology based on metadata. The system dynamically generates an executable code or configuration based on the template definition and specific context data; this code or configuration is the instantiated optimization instruction. The resulting set of optimization instructions is a series of specific, executable commands or actions targeting specific conflict issues. When applied to a scenario process digital twin, it aims to resolve identified dynamic business conflicts. This set of optimization instructions can be a structured list of data, where each element represents a specific modification operation, such as "{"Operation Type": "Modify Node Attribute", "Node ID": "N1", "Attribute Name": "Intent Recognition Threshold", "New Value": "0.8"}" or "{"Operation Type": "Insert Data Cleaning Step", "Location": "Before Node N2", "Cleansing Rule ID": "R_format_date"}". Alternatively, it can be a series of callable API interfaces or microservice requests, each carrying specific parameters for modifying a specific part of the scenario flow digital twin.

[0216] To ensure the effectiveness and reliability of the optimization strategy, this application further performs inter-strategy conflict resolution and business logic consistency verification on the optimization instruction set. The inter-strategy conflict resolution aims to identify and resolve contradictions or redundancies between different instructions in the optimization instruction set. This can be achieved by constructing an instruction dependency graph, identifying instructions that operate on the same resource or have logically mutually exclusive relationships, and arbitrating them according to preset priority rules. Alternatively, it can employ an algorithm based on the constraint satisfaction problem (CSP), treating all optimization instructions as constraints and finding an optimal solution set that satisfies all constraints. The business logic consistency verification aims to verify whether the optimization instructions after conflict resolution still conform to the basic business rules, constraints, and overall logic defined in the business specifications and multi-source business data model. This can be achieved by converting the optimization instructions into modifications to the scenario process digital twin, and then using a business rule engine to simulate or statically analyze the modified digital twin to check whether it violates predefined business rules. Alternatively, it can be achieved by comparing the instructions with entity attribute constraints, relationship constraints, and state evolution rules defined in the multi-source business data model to ensure that the instructions do not lead to inconsistencies in the data model or compromise data integrity.

[0217] Building upon this, this application further prioritizes execution based on the execution logic of the scenario process digital twin. This prioritization process aims to allocate execution order for optimization instructions according to their dependencies, scope of impact, and the logical flow of the scenario process digital twin. This can be based on the topology and data flow dependencies of the scenario process digital twin; for example, modifications to upstream nodes should take precedence over modifications to downstream nodes. Data adaptation operations should take precedence over node adjustment operations that depend on that data. Alternatively, it can be achieved by pre-setting priority weights for different types of optimization instructions and combining this with their position in the process for comprehensive prioritization. A structured optimization strategy is generated, which is a complete, coordinated, compliant, and directly executable plan used to modify the scenario process digital twin. This structured optimization strategy can be an executable script or configuration file containing metadata such as instruction sequences, execution conditions, and rollback mechanisms. Alternatively, it can be a sequence of API calls, with each API call corresponding to an optimization instruction, arranged in priority order.

[0218] Through the above technical solution, this application transforms the generation of optimization strategies from a manual mode that heavily relies on expert experience to an automated mode based on knowledge bases and rule engines. By matching corresponding optimization strategy templates from a pre-set optimization strategy knowledge base based on root cause categories, it utilizes pre-defined domain knowledge to provide a standardized solution framework for specific types of root causes, avoiding the need to conceive strategies from scratch, improving efficiency, and ensuring the basic correctness of the strategy direction. By parameterizing and logically instantiating affected node information and abnormal data items with template rules, abstract rules are transformed into executable instructions for specific node contexts, achieving precise customization of strategies from general to specific, ensuring the targeted nature of the strategies. The generated set of optimization instructions undergoes conflict resolution between strategies and business logic consistency verification, proactively identifying and eliminating potential operational overlaps or logical contradictions between different instructions, and ensuring that each instruction conforms to business specifications and data model constraints, thereby guaranteeing the internal consistency and compliance of the strategy set. By prioritizing execution based on the execution logic of the scenario-based digital twin, actionable plans are injected into the strategy set, clarifying the order of execution and dependencies. This ensures that the generated structured optimization strategy is itself a coordinated, compliant, and immediately guiding solution for process iteration, rather than a fragmented list of suggestions. This significantly improves the reliability, usability, and implementation efficiency of the optimization strategy, and is key to supporting the automated and intelligent operation of the entire "simulation-analysis-optimization" closed loop. It solves the problems of low feasibility, chaotic implementation, and difficulty in directly driving effective process iteration in traditional methods, thereby improving the verification and optimization efficiency of intelligent customer service processes.

[0219] In some of the solutions mentioned above in this application, a set of optimization instructions is proposed to support the generation of structured optimization strategies. However, in the implementation process, manually processing the node information and associated abnormal data items in the affected process node set and binding and instantiating them with the rules of the optimization strategy template is inefficient and error-prone, and it is difficult to ensure the accuracy and consistency of the optimization instructions.

[0220] To address this, this application further proposes to parameterize and logically instantiate the node information and associated abnormal data items in the affected process node set with the rules in the optimization strategy template, generating a set of optimization instructions for specific nodes. Specifically, this includes: for each process node in the affected process node set, extracting the node type identifier, current parameter configuration, and associated abnormal data item to form a node feature vector. This node feature vector is then input into the rule adapter corresponding to the optimization strategy template. The rule adapter maps and calculates the node feature vector with variable placeholders in the node adjustment rules and data adaptation rules to generate rule filling results. Based on these rule filling results, instantiated optimization instructions are constructed, including the target node identifier, specific adjustment operations, updated parameter configuration, and associated data change path. The instantiated optimization instructions constructed for all target process nodes are then aggregated to form the optimization instruction set.

[0221] For each process node in the affected process node set, the node type identifier, current parameter configuration, and associated abnormal data item are extracted to form a node feature vector. The node feature vector is a structured representation of key information about the process node. Its function is to integrate discrete node attributes (such as node type, current parameter configuration, and associated abnormal data items) into a unified data structure, thereby facilitating subsequent automated processing of rule matching and parameter binding. In practice, a predefined JSON Schema or Protobuf can be used to define the structure of the node feature vector. During extraction, fields are filled according to this Schema. For example, the node type identifier can be an enumeration value (such as "intent recognition node" or "data verification node"), the current parameter configuration can be a key-value pair (such as {"threshold": 0.8, "data source": "CRM"}), and the abnormal data item can be an abnormal ID or an abnormal description string. Alternatively, an object-oriented approach can be used, abstracting the process node as an object whose attributes include a node type identifier, a current parameter configuration object, and a list of abnormal data items. During extraction, these attributes are directly accessed and serialized to form the feature vector.

[0222] Furthermore, the node feature vector is input into the rule adapter corresponding to the optimization strategy template. The rule adapter maps and calculates the node feature vector with the variable placeholders in the node adjustment rules and data adaptation rules to generate the rule filling result. This rule adapter is an intelligent module whose core function is to parse the node feature vector and match and parameterize it with the preset general rules (including node adjustment rules and data adaptation rules) in the optimization strategy template, thereby transforming the abstract rule template into specific operation instructions for a specific process node. One implementation method is that the rule adapter can have a built-in template engine. The rules in the optimization strategy template contain placeholders (e.g., {{node_type}}, {{param_value}}, {{exception_data}}). After receiving the node feature vector, the rule adapter fills the values ​​in the vector into the corresponding placeholders, thus generating the specific rule filling result. Another approach is that the rule adapter can use a mechanism based on semantic matching or pattern recognition to maintain a rule base. Each rule defines matching conditions (based on the pattern of node feature vectors) and corresponding operation templates. When a node feature vector is received, the adapter will traverse the rule base, find the most matching rule, and perform calculations and filling based on the operation template of that rule and the data in the node feature vector to generate the rule filling result.

[0223] Based on this, and using the rule-filled results, an instantiated optimization instruction is constructed. This instantiated optimization instruction includes the target node identifier, specific adjustment operations, updated parameter configurations, and associated data change paths. The instantiated optimization instruction is a concrete and executable optimization operation; it clearly indicates which process node to adjust, what kind of adjustment to make, and the adjusted parameters and data paths. It serves as a crucial bridge from abstract rules to concrete execution. An instantiated optimization instruction can be defined as a structured data object, such as a JSON object containing fields like `targetNodeId` (target node identifier), `operationType` (specific adjustment operation, such as "modify parameters" or "add branch"), `newParams` (updated parameter configurations), and `dataPath` (associated data change paths). Based on the rule-filled results, these fields are directly constructed and filled. Alternatively, the instantiated optimization instruction can also be an executable script or function call. The rule-filled results may contain a function name and parameter list; constructing the instantiated optimization instruction involves generating a code snippet that calls this function and passes in the corresponding parameters.

[0224] The instantiation optimization instructions constructed for all target process nodes are compiled into this optimization instruction set. This optimization instruction set is a summary of the instantiation optimization instructions for all affected process nodes, providing a complete execution blueprint for subsequent structured optimization strategies and ensuring that all identified conflicts are handled appropriately. All constructed instantiation optimization instructions can be simply stored in a list or array. Considering the possibility of subsequent priority sorting or grouping of instructions, a more complex data structure can also be used, such as a dictionary where the keys are target node identifiers and the values ​​are the list of instantiation optimization instructions corresponding to that node, or an ordered list containing instructions and their metadata (such as priority and dependencies).

[0225] Through the above technical solution, this application solves the problems of low efficiency, error-proneness, and difficulty in guaranteeing accuracy and consistency in manually binding node information with optimization strategy template rules. Its working principle lies in structuring the key information of process nodes (node ​​type identifier, current parameter configuration, and associated abnormal data items) into node feature vectors, and automatically mapping and calculating these feature vectors with general rules in the optimization strategy template using a rule adapter. This efficiently and accurately generates instantiated optimization instructions for specific nodes. These instructions clearly define the target node identifier, specific adjustment operations, updated parameter configurations, and associated data change paths, ensuring the executability and accuracy of the optimization. All instantiated instructions are aggregated to form an optimization instruction set, providing comprehensive and automated input for subsequent structured optimization strategies. Based on the generated structured optimization strategy, this solution transforms the abstract optimization strategy template into precise instructions for specific affected nodes through automation and parameterization. This allows the optimization direction determined by the root cause category and the set of affected process nodes to be efficiently and accurately transformed into executable process adjustment operations. This approach not only improves the efficiency and accuracy of optimization strategy generation, but also ensures that the optimization strategies can accurately target the root causes of problems and affected process nodes, thereby enhancing the optimization efficiency and robustness of the intelligent customer service process.

[0226] In some of the solutions mentioned above in this application, a structured optimization strategy is proposed to optimize the digital twin of the scenario process. However, in this process, there may be conflicts between optimization instruction sets or inconsistencies in business logic, which affect the effective generation and subsequent execution of the strategy.

[0227] To address this, this application further proposes conflict resolution and business logic consistency verification between the execution strategies of the optimized instruction set, and prioritizes execution based on the execution logic of the digital twin of the scenario process to generate the structured optimization strategy. Specifically, the method includes the following steps:

[0228] Based on instruction effect deduction, the optimized instruction set is used to predict conflicts, identify and resolve instructions with overlapping operations or logical mutual exclusion, and generate a coordinated instruction set. Instruction effect deduction aims to detect and resolve conflicts between instructions in advance by simulating the potential impact of optimized instruction execution on the state of the digital twin of the scene flow. For example, an instruction impact model can be constructed that predicts the impact of each optimized instruction execution on the node state, parameter value, or data flow in the digital twin of the scene flow. During conflict prediction, the system can simulate the parallel or sequential execution of multiple instructions and compare their impact on shared resources or state variables. If a conflict is found (e.g., different instructions attempt to modify the same parameter to different values, or the execution prerequisite of one instruction is violated by another instruction), it is marked as a conflict. Another implementation method is to use a detection mechanism based on predefined conflict rules, for example, stipulating that "an instruction to modify parameter X of node A cannot be executed simultaneously with an instruction to delete node A." After the optimized instruction set is generated, the system traverses instruction pairs and matches them against these conflict rules. Once an instruction pair that matches the conflict pattern is found, the conflict resolution process is triggered. Conflict resolution strategies can include priority adjudication (assigning priorities based on instruction type or source, retaining higher-priority instructions), merging (attempting to merge parameters if instructions perform the same operation but have different parameters), or rollback (undoing one or more conflicting instructions). This process ensures the coordination within the optimized instruction set, preventing strategy execution errors or interruptions caused by instruction conflicts.

[0229] The system matches and validates the instructions in the coordination instruction set against the node constraints defined in the business specification, and performs logical consistency checks against the attribute and state rules defined in the multi-source business data model, generating a compliant instruction set that passes the validation. This step aims to ensure that the instruction set, after conflict resolution, is not only internally coordinated but also consistent with the external business specification and data model, preventing the generation of optimization strategies that violate business logic or data integrity. For the node constraints defined in the business specification, the system can maintain a node constraint rule base, which includes the allowed parameter range, preconditions, and postconditions for each node type. For each instruction in the coordination instruction set, the system parses its target node and operation, and then checks against the rule base to see if the operation violates any constraints of the target node. For example, if an instruction attempts to set the parameters of a node beyond the range allowed by the business specification, it is marked as non-compliant. For the attribute and state rules defined in the multi-source business data model, the system can use the API or query interface provided by the data model to verify in real time whether the instruction operation will cause the entity attribute values ​​in the data model to be invalid or the state transition to not conform to preset rules. For example, if an instruction requires a device's status to jump directly from "running" to "scrapped," skipping the "stopped" state, but the data model defines that it must go through the "stopped" state, then the instruction is considered non-compliant. The verification process can employ formal verification methods, transforming the instruction operations and business rules into logical expressions for solution, or a graph traversal approach, checking whether the instruction's impact path on the data model conforms to the pre-defined business logic graph. This step ensures the inherent consistency between the optimization strategy and the dynamic business environment.

[0230] Based on the topological dependencies and critical data flow paths of the scenario's digital twin, the instructions in the compliant instruction set are prioritized and logically grouped to generate instruction sequences with priority and group identifiers. This step aims to optimize the execution order of instructions, ensuring that optimization strategies are applied efficiently and correctly, avoiding problems caused by improper execution order, and improving the manageability of the strategy. Priority calculation can be based on the scope and depth of the instruction's impact on the scenario's digital twin, as well as the criticality of the modified node in the entire process. For example, instructions that modify core business logic nodes may have higher priority. Instructions affecting multiple downstream nodes may also be assigned higher priority. Critical data flow path analysis can identify the data transmission paths that have the greatest impact on the entire process output; instructions located on these paths have higher priority. Logical grouping can be based on the node type, business function module, or their position in the scenario's digital twin. For example, all instructions modifying the "user intent recognition" module can be grouped into one group, and all instructions modifying the "external system call" module into another. After grouping, instructions from one group can be executed first, followed by instructions from the other group, or instructions within a group can be executed in parallel. The instruction sequence can be an ordered list, with each instruction accompanied by a priority value and a group identifier. During execution, the system will prioritize executing instructions with higher priority, or execute them in group order. Instructions within a group can be further scheduled based on their priority or parallelism. Through this step, the execution order is optimized according to the process logic, improving the efficiency of strategy execution.

[0231] The instruction sequence is encapsulated with preset execution control parameters to form the structured optimization strategy. This step packages all optimization instructions and their execution metadata into an executable and manageable whole, providing a standardized interface and control mechanism for automated application optimization strategies. Execution control parameters may include, but are not limited to: strategy effective time, rollback mechanism (such as automatically restoring to the state before strategy application in case of execution failure), execution mode (such as "execute immediately", "execute on schedule", "execute after manual confirmation"), and log level. These parameters, along with the instruction sequence, are encapsulated into a JSON or XML format strategy file, or stored in a database, awaiting invocation by the strategy execution engine. The encapsulation process may involve signing or encrypting the instruction sequence to ensure the integrity and security of the strategy. Simultaneously, a unique version number can be generated for the strategy to facilitate management and tracking. The encapsulated structured optimization strategy can be considered an independent software component, capable of being called by automated deployment systems through API interfaces and applied to the digital twin of the scenario process.

[0232] Through the above technical solutions, this application addresses the potential conflicts between strategies and inconsistencies in business logic within the optimized instruction set by employing a systematic conflict resolution, consistency verification, and priority ranking mechanism, ensuring the reliability and efficiency of the generated structured optimization strategies. Conflict prediction based on instruction effect deduction simulates the potential impact of instruction execution, thereby identifying and resolving overlapping or logically mutually exclusive instructions in advance, avoiding strategy execution errors or interruptions caused by instruction conflicts. Logical consistency verification is performed between the coordinated instructions and business specifications and multi-source business data models to ensure that the instructions comply with business rules and data constraints, guaranteeing the inherent consistency between the strategy and the dynamic business environment. Then, based on the topological dependencies and critical data flow paths of the scenario process digital twin, the execution priority of compliant instructions is calculated and logically grouped, optimizing the execution order according to process logic and improving strategy execution efficiency. Encapsulating the instruction sequence with preset execution control parameters and integrating all elements to support automated execution enhances the robustness and operability of strategy generation. These steps work together to ensure that the generated structured optimization strategies can be accurately and efficiently applied to the digital twin of the scenario process, thereby resolving dynamic business conflicts caused by dynamic mismatch of business data or differences in user expression, and improving the robustness and automated optimization capabilities of the intelligent customer service process.

[0233] In some of the solutions mentioned above in this application, it is proposed to optimize the intelligent customer service process by iteratively executing dynamic coupling, automated simulation dialogue and joint analysis. However, in this process, there is a lack of automatic judgment criteria and termination conditions, which may lead to inefficient or non-convergent optimization processes, and cannot ensure that the verified completed process is reliably output within a reasonable number of iterations.

[0234] To address this, this application further proposes a method for iteratively executing dynamic coupling, automated simulation dialogue, and joint analysis until a pre-run passes, outputting a validated intelligent customer service process. Specifically, this method includes: applying a structured optimization strategy to a scenario process digital twin to generate an updated scenario process digital twin; re-executing the complete dynamic coupling, automated simulation dialogue, and joint analysis process based on the updated scenario process digital twin to obtain the pre-run evaluation results of this iteration; judging the pre-run evaluation results of this iteration based on predefined pass criteria; if the pass criteria are met, the updated scenario process digital twin is output as the validated intelligent customer service process; if the pass criteria are not met, the next round of structured optimization strategy is generated based on the pre-run evaluation results of this iteration, and the application, re-execution, and judgment steps are repeated until the pass criteria are met or a preset iteration termination condition is reached, completing the iterative validation and output of the intelligent customer service process.

[0235] Specifically, when applying structured optimization strategies to a scenario flow digital twin to generate an updated scenario flow digital twin, various methods can be employed. For example, structured optimization strategies (such as modifying node parameters, adjusting transition conditions, adding or deleting nodes, etc.) can be directly written into or updated to the scenario flow digital twin's configuration database or model definition file via automated scripts or API interfaces. Alternatively, a visual interface can be used, where the system automatically generates modification suggestions based on the optimization strategies, prompts operators for confirmation, and then the operators complete the update of the scenario flow digital twin through the interface.

[0236] When re-executing the complete dynamically coupled, automated simulation dialogue, and joint analysis process based on the updated scenario flow digital twin to obtain the pre-evaluation results of this iteration, the system automatically invokes the dynamic business sandbox, loads the updated scenario flow digital twin, and re-executes the same or updated set of simulated user input sequences as the previous round, generating new pre-evaluation logs and performing joint analysis to obtain the pre-evaluation results of this round. Alternatively, the platform can provide a "one-click verification" function. When the scenario flow digital twin is updated, this function automatically triggers a series of preset test cases and simulation processes, collects all relevant execution logs and analysis reports, and summarizes the pre-evaluation results of this round.

[0237] The system evaluates the results of the current iteration's pre-simulation based on predefined pass criteria. If the pass criteria are met, the updated scenario process digital twin is output as the validated intelligent customer service process. These predefined pass criteria may include: the number of dynamic business conflicts in the pre-simulation log is below a certain threshold, the coverage rate of key dialogue paths reaches a preset percentage, the user satisfaction simulation score reaches the target value, and the number of specific error types (such as parameter validation failures) is zero. The system logically compares these criteria with the various indicators in the pre-simulation evaluation results. Alternatively, the pass criteria can be a multi-dimensional scoring model that comprehensively considers factors such as conflict resolution rate, process efficiency, and resource consumption. When the comprehensive score reaches a preset passing threshold, the pass criteria are considered met. During output, the updated scenario process digital twin model file, configuration parameters, and related validation reports can be packaged as a deployable intelligent customer service process.

[0238] If the pass criteria are not met, the system generates a structured optimization strategy for the next round based on the pre-evaluation results of this iteration, and repeats the application, re-execution, and judgment steps until the pass criteria are met or the preset iteration termination conditions are reached, completing the iterative verification and output of the intelligent customer service process. When the pass criteria are not met, the system will conduct an in-depth analysis of the pre-evaluation results of this round, identify new or unresolved dynamic business conflicts, and automatically generate a structured optimization strategy for the next round based on the preset optimization strategy knowledge base and root cause analysis results. Iteration termination conditions may include: reaching the maximum number of iterations, no improvement in optimization effect for multiple consecutive rounds, or termination by manual intervention. In addition, the platform can also provide an intelligent recommendation engine, which recommends multiple possible combinations of optimization strategies based on the current pre-evaluation results and historical optimization experience, and allows users to choose or the system to automatically select the optimal strategy as the structured optimization strategy for the next round. Iteration termination conditions may also include: the pre-evaluation pass rate of all key business scenarios reaches 95% or more, or the recognition accuracy rate of all high-frequency user intents reaches 98% or more.

[0239] Through the above technical solution, this application provides a structured, automated, and controllable iterative optimization mechanism for intelligent customer service processes. This mechanism addresses the inefficiencies and convergence difficulties caused by the lack of automatic judgment criteria and termination conditions in traditional optimization processes by introducing explicit pass criteria and iteration termination conditions. Each iteration updates the digital twin of the scenario process based on the latest optimization strategy and re-performs comprehensive dynamic simulation verification, ensuring the effectiveness of the optimization strategy. This closed-loop iterative verification process enables the intelligent customer service process to continuously improve until it meets preset quality standards, thereby enhancing the robustness, accuracy, and adaptability of the output process, reducing manual trial-and-error costs and deployment risks, and ensuring the reliable output of a verified intelligent customer service process within a reasonable number of iterations.

[0240] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0241] Figure 9 This is a schematic diagram of the structure of a multi-scenario intelligent customer service system for the energy industry, provided in an embodiment of this application. See also... Figure 9 The system includes:

[0242] Module 901 is used to transform customer service scenario templates into scenario process digital twins based on business specifications, and to perform structured and semantic processing on equipment ledgers, dynamic policies and historical interaction data to build a multi-source business data model that is compatible with the scenario process digital twin.

[0243] The driver module 902 is used to dynamically couple the digital twin of the scenario process with the real-time business data in the multi-source business data model in the dynamic business sandbox, drive the dialogue engine in the sandbox to perform multiple rounds of automated simulation dialogue, and generate a pre-drill log containing node jumps, parameter passing and external data call results.

[0244] Analysis module 903 is used to jointly analyze the pre-drill log and the multi-source business data model, identify dynamic business conflicts caused by dynamic mismatch of business data or differences in user expression, and parse out the root cause category and the set of affected process nodes of the dynamic business conflict.

[0245] The generation module 904 is used to generate a structured optimization strategy for the digital twin of the process in the scenario based on the root cause category and the set of affected process nodes. It iteratively executes the dynamic coupling, automated simulation dialogue and joint analysis until the pre-run passes, and outputs the verified intelligent customer service process.

[0246] It should be noted that the above embodiments of the energy industry multi-scenario intelligent customer service system are only illustrated by the division of the functional modules described above. In actual applications, the functions can be assigned to different functional modules as needed, that is, the internal structure of the computer equipment can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the above embodiments of the energy industry multi-scenario intelligent customer service system and the method embodiments for building multi-scenario intelligent customer service in the energy industry belong to the same concept, and their specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0247] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including a computer program that can be executed by a processor to complete the method for building a multi-scenario intelligent customer service system in the energy industry as described in the above embodiments. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0248] In an exemplary embodiment, a computer program product or computer program is also provided, which includes program code stored in a computer-readable storage medium. The processor of a computer device reads the program code from the computer-readable storage medium and executes the program code, causing the computer device to execute the above-described method for building multi-scenario intelligent customer service in the energy industry.

[0249] In some embodiments, the computer program involved in the present application embodiments may be deployed and executed on a computer device, or executed on multiple computer devices located in one location, or executed on multiple computer devices distributed in multiple locations and interconnected through a communication network. Multiple computer devices distributed in multiple locations and interconnected through a communication network may constitute a blockchain system.

[0250] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0251] The above are merely optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for building multi-scenario intelligent customer service in the energy industry, characterized in that, The method includes: Based on business specifications, customer service scenario templates are transformed into scenario process digital twins, and equipment ledgers, dynamic policies and historical interaction data are processed in a structured and semantic way to build a multi-source business data model that is compatible with the scenario process digital twins. In the dynamic business sandbox, the digital twin of the scenario process is dynamically coupled with the real-time business data in the multi-source business data model, driving the dialogue engine in the sandbox to execute multiple rounds of automated simulation dialogue, generating a pre-drill log containing node jumps, parameter passing and external data call results; Extract parameter validation failure events, rule matching blocking events, and user input parsing events that cause dialogue path redundancy from the pre-run logs; associate the parameter validation failure events and rule matching blocking events with the real-time status of the corresponding business entities in the multi-source business data model, verify whether the real-time status meets the data requirements of the current node of the scenario process digital twin, and generate a dynamic mismatch conflict set of business data; for user input parsing events, analyze the semantic deviation between the expression of the user input parsing event and the preset standard intent of the scenario process digital twin, and identify parsing events with semantic deviation exceeding the threshold and actually causing path redundancy as user expression difference conflict sets; merge the dynamic mismatch conflict set of business data with the user expression difference conflict set to form dynamic business conflicts caused by dynamic mismatch of business data or user expression differences, and parse the root cause category and the set of affected process nodes of the dynamic business conflicts. Based on the root cause category and the set of affected process nodes, a structured optimization strategy is generated for the digital twin of the scenario process. Through iterative execution of dynamic coupling, automated simulation dialogue and joint analysis, until the pre-run passes, the verified intelligent customer service process is output.

2. The method according to claim 1, characterized in that, The process of transforming customer service scenario templates into digital twins of scenario flows based on business specifications includes: Based on the aforementioned business specifications, the customer service scenario template is deconstructed to generate a set of process elements, which includes atomic business intentions and standardized system actions. Based on the business logic defined in the business specifications, the set of process elements is reorganized to construct an initial process skeleton with state transition paths; For at least a portion of the state nodes of the initial process skeleton, observation hooks are configured to trigger internal state acquisition and exposure during the dynamic business sandbox rehearsal, forming a digital twin of the scenario process; wherein, the observation hooks are used to enable the dynamic business sandbox to capture the detailed execution context of the state nodes.

3. The method according to claim 1, characterized in that, The process of structuring and semantically processing equipment ledgers, dynamic policies, and historical interaction data to construct a multi-source business data model adapted to the digital twin of the scenario process includes: Perform domain-specific structured parsing on the equipment ledger, the dynamic policies, and the historical interaction data to extract and encapsulate business data objects with version identifiers; Based on a predefined business entity graph, the business data objects are semantically merged and conflict resolved to generate a standardized set of business entities carrying consistency verification labels. Configure dynamic parameter interfaces that can be called in real time by the dynamic business sandbox for entities in the standardized business entity set, as well as state evolution rules that can be associated with the logic of the digital twin nodes of the scenario process, to generate the multi-source business data model with dynamic response and logical constraint capabilities.

4. The method according to claim 1, characterized in that, In the dynamic business sandbox, the digital twin of the scenario process is dynamically coupled with the real-time business data in the multi-source business data model, driving the dialogue engine within the sandbox to execute multi-round automated simulation dialogues, generating a pre-play log containing node jumps, parameter passing, and external data call results, including: Based on the preset data mapping relationship between the multi-source business data model and the scenario process digital twin, the real-time business data is dynamically bound to the corresponding process node in the dynamic business sandbox to complete the simulation environment initialization. Based on the historical interaction patterns in the multi-source business data model, a set of simulated user input sequences covering multiple key dialogue paths in the scenario process digital twin is generated. Based on the set of simulated user input sequences, the dialogue engine is driven to traverse different state transition paths in the digital twin of the scenario process, and during the execution process, the rule interpreter of the dynamic business sandbox queries and matches the dynamic business rules and constraints in the multi-source business data model in real time to generate a multi-round automated simulated dialogue process. During the execution of the automated simulation dialogue process, the node execution details triggered by the digital twin of the scene process, the rule matching and data call events generated by the rule interpreter, the content and parsing results of the simulated user input sequence, and the path decision information of the dialogue engine are recorded synchronously and fused to generate the pre-drill log.

5. The method according to claim 4, characterized in that, The process of generating a set of simulated user input sequences covering multiple key dialogue paths in the scenario process digital twin, based on historical interaction patterns in the multi-source business data model, includes: From the historical interaction data of the multi-source business data model, user dialogue samples and system response paths are extracted, and historical dialogue path coverage statistics are obtained through analysis. By integrating the historical dialogue path coverage statistics with the topological features of the scene process digital twin, a set of target key dialogue paths is selected. Based on the user dialogue samples and the node constraints of each path in the target key dialogue path set, an adapted initial simulated user input sequence set is generated. The dynamic service sandbox is invoked, and the initial simulated user input sequence set is used to drive the pre-simulation. Based on the actual path coverage data triggered by the pre-simulation, the initial simulated user input sequence set is filtered and enhanced, and the simulated user input sequence set is generated iteratively.

6. The method according to claim 5, characterized in that, The process of generating an adapted initial simulated user input sequence set based on the user dialogue samples and the node constraints of each path in the target critical dialogue path set includes: For each path in the target key dialogue path set, the business intent constraints and parameter constraints associated with the key nodes in each path are parsed to generate a node constraint configuration set; Using the node constraint configuration set as a condition, the user dialogue sample is subjected to multi-dimensional semantic matching and constraint compliance verification to filter out compliant user dialogue samples. Based on semantic similarity, the compliant user dialogue samples are subjected to text mutation while preserving the original intention semantics to generate a diverse dialogue candidate set. Based on the execution sequence and logical dependencies of nodes on each path, suitable dialogues are selected from the diverse dialogue candidate set for each key node and serialized and arranged to generate an initial simulated user input subsequence covering each path. The initial simulated user input subsequences generated for all target key dialogue paths are aggregated, and cross-path redundancy elimination and distribution balance optimization are performed to form the initial simulated user input sequence set.

7. The method according to claim 1, characterized in that, The analysis yields the root cause categories and the set of affected process nodes for the dynamic business conflicts, including: For the dynamic business conflict, locate the process node where the dynamic business conflict first occurs in the pre-drill log, extract the data operation context of the process node, and associate it with the specific business entities and attributes in the multi-source business data model to determine the direct root cause node and abnormal data item. Based on a predefined root cause classification rule base, pattern matching is performed between the direct root cause node and the abnormal data item to determine the root cause category of the dynamic business conflict. The rules of the root cause classification rule base are derived from the business entity relationships and state constraints defined in the multi-source business data model. Starting from the direct root cause node, along the topology of the scenario process digital twin, analyze all downstream nodes that depend on the abnormal data item or are affected by the state transition of the direct root cause node, and combine the evidence of subsequent execution interruption or path deviation recorded in the pre-run log to determine the set of affected process nodes.

8. The method according to claim 7, characterized in that, Starting from the direct root cause node, the process analyzes all downstream nodes that depend on the abnormal data item or are affected by the state transition of the direct root cause node along the topology of the digital twin of the scenario flow. Combined with evidence of subsequent execution interruptions or path deviations recorded in the pre-run log, the set of affected flow nodes is determined, including: Based on the topology of the digital twin of the scenario process, starting from the direct root cause node, identify all downstream nodes that depend on the abnormal data item or the direct root cause node in terms of data flow or state logic, forming a theoretically influential node set. For each node in the theoretically affected node set, search for the execution record corresponding to each node in the pre-run log, and extract empirical evidence from the execution record to determine whether there is execution interruption, rule matching failure, or parameter passing anomaly. The nodes where the empirical evidence is found are identified as the nodes that are actually affected. Arrange all the actually affected nodes in the order of the topology to generate the set of affected process nodes.

9. The method according to claim 1, characterized in that, The structured optimization strategy for generating the digital twin of the scenario process based on the root cause category and the set of affected process nodes includes: Based on the root cause category, a corresponding optimization strategy template is matched from a preset optimization strategy knowledge base. The optimization strategy template includes node adjustment rules and data adaptation rules. The node information and associated abnormal data items in the affected process node set are parameterized and logically instantiated with the rules in the optimization strategy template to generate a set of optimization instructions for the node. The optimization instruction set is used to resolve conflicts between execution strategies and verify the consistency of business logic. The execution priority is sorted according to the execution logic of the scenario process digital twin to generate the structured optimization strategy.

10. A multi-scenario intelligent customer service system for the energy industry, characterized in that, The system includes: The module is used to transform customer service scenario templates into scenario process digital twins based on business specifications, and to perform structured and semantic processing on equipment ledgers, dynamic policies and historical interaction data to build a multi-source business data model that is compatible with the scenario process digital twins. The driving module is used to dynamically couple the scenario process digital twin with the real-time business data in the multi-source business data model in the dynamic business sandbox, drive the dialogue engine in the sandbox to execute multiple rounds of automated simulation dialogue, and generate a pre-drill log containing node jumps, parameter passing and external data call results. The analysis module is used to extract parameter verification failure events, rule matching blocking events, and user input parsing events that cause process execution interruption from the pre-run logs; associate the parameter verification failure events and rule matching blocking events with the real-time status of the corresponding business entities in the multi-source business data model, verify whether the real-time status meets the data requirements of the current node of the scenario process digital twin, and generate a dynamic mismatch conflict set of business data; for user input parsing events, analyze the semantic deviation between the expression of the user input parsing event and the preset standard intent of the scenario process digital twin, and identify parsing events with semantic deviation exceeding the threshold and actually causing path redundancy as user expression difference conflict sets; merge the dynamic mismatch conflict set of business data with the user expression difference conflict set to form dynamic business conflicts caused by dynamic mismatch of business data or user expression differences, and parse the root cause category and the set of affected process nodes of the dynamic business conflicts. The generation module is used to generate a structured optimization strategy for the digital twin of the scenario process based on the root cause category and the set of affected process nodes. It iteratively executes the dynamic coupling, automated simulation dialogue and joint analysis until the pre-run passes, and outputs the verified intelligent customer service process.

Images