Talk skill generation method and device, medium and equipment

Abstract

The invention provides a verbal skill generation method and device, a medium and equipment. The method comprises the steps that a verbal skill process request from a coach robot is received through a rule engine; querying a customer characteristic index according to the call identifier; inputting the customer characteristic indexes into a pre-configured rule set for condition judgment; sequentially executing rule judgment according to a priority sequence, and returning a rule result corresponding to the rule when the condition group of any rule is met; if all the rules are not hit, returning a preset bottom result; and mapping the hit rule result or the bottom result to a corresponding verbal skill template, generating a personalized verbal skill, and returning the personalized verbal skill to the intelligent seat platform for display. The verbal skill generation method and device can improve verbal skill generation diversification, personalization and flexibility.

Description

A method, apparatus, medium and equipment for generating scripts Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method, apparatus, medium and device for generating speech. Background Technology

[0002] In today's digital business environment, communication and interaction between businesses and customers are crucial, with customer service playing a key role. This is especially true in industries like telemarketing and finance, which handle massive amounts of customer inquiries, complaints, and service requests daily. Traditional customer service models, such as purely human customer service, face numerous challenges. Firstly, human customer service is extremely inefficient when dealing with large-scale, repetitive inquiries. For example, during telemarketing promotions, order and inquiry volumes explode, making it difficult for human customer service representatives to process the large volume of inquiries in a short time, resulting in excessively long customer wait times and significantly reducing customer satisfaction. According to relevant data, during peak inquiry periods, the average response time for human customer service can exceed 5 minutes, while customers typically expect a response time of less than 1 minute from online customer service.

[0003] To address the efficiency issues of human customer service, intelligent customer service systems have emerged and become widely used. However, current intelligent customer service technology has significant limitations. In terms of natural language processing, intelligent customer service systems have low semantic understanding accuracy when faced with diverse and personalized customer expressions. For example, if a customer asks, "The thing I bought before broke after a short time, how do you handle it?", the intelligent customer service system may fail to accurately understand the specific product referred to by "that thing," resulting in irrelevant or generic answers and frequent instances of "not answering the question." Related research indicates that the accuracy rate of intelligent customer service systems in complex semantic understanding scenarios is currently only 40%-60%. Moreover, intelligent customer service systems lack in-depth analysis and utilization of customer characteristics and historical interaction data. Each customer has different consumption habits, preferences, and consultation history, making it difficult for intelligent customer service systems to generate targeted communication scripts based on this personalized information. For example, for a customer who frequently buys high-end products and is not price-sensitive, the intelligent customer service system may still recommend products with average cost-performance ratios using generic scripts, failing to meet the customer's potential needs and reducing sales conversion opportunities.

[0004] Some companies use simplistic and crude methods for generating customer service scripts. Some only have a limited number of fixed script templates, failing to consider the diversity of customer characteristics and business scenarios. Whether the customer is new or returning, asking simple or complex questions, the same script is used to respond. This results in a lack of targeted and personalized service, failing to effectively solve customer problems and hindering the improvement of customer goodwill and loyalty. For example, in the financial industry, when customers inquire about loan services, different communication strategies should be used for customers with different credit ratings, income levels, and loan needs, but fixed script templates cannot achieve this differentiated service.

[0005] In conclusion, existing customer service communication models, whether human or intelligent, as well as the simple script generation methods used by enterprises, cannot adequately meet the diverse needs of customers, make it difficult to achieve efficient and personalized customer communication, and have significant room for improvement in enhancing customer experience and business conversion rates. Summary of the Invention

[0006] In view of this, this application provides a method and apparatus for generating scripts, the main purpose of which is to meet the needs of diverse, personalized and flexible script generation.

[0007] According to one aspect of this application, a script generation method is provided, comprising: receiving a script flow request from a coaching robot via a rule engine, the request including a call identifier and a task number; querying customer characteristic indicators based on the call identifier, the customer characteristic indicators including at least one of real-time interface data, data delivery information, and big data query results; inputting the customer characteristic indicators into a pre-configured rule set for condition judgment, the rule set containing multiple rules ordered by priority, each rule containing one or more condition groups, wherein conditions within a condition group are logical AND relations, and conditions between condition groups are logical OR relations; executing rule judgments sequentially according to priority order, and returning the rule result corresponding to the rule when the condition group of any rule is satisfied; if all rules are not matched, returning a preset fallback result; mapping the matched rule result or fallback result to the corresponding script template to generate a personalized script and returning it to the smart agent platform for display.

[0008] In one implementation, the configuration process of the rule set includes: defining multiple business metrics, each business metric including a metric name, data source and acquisition method; configuring at least one rule for each business scenario, each rule containing at least one condition group, the condition group consisting of a business metric, a comparison operator and a threshold; sorting the multiple rules according to business priority to form a rule set, and configuring a fallback result for the rule set.

[0009] In one implementation, the condition judgment supports nested combination of multiple conditions, including: supporting interval judgment of numerical conditions; supporting multi-value matching of enumerated conditions; and supporting range comparison of time-related conditions.

[0010] In one implementation, the method further includes: configuring a dialogue flow node in the dialogue forest system, associating at least one flow node with the rule set; automatically triggering the execution of the rule set when the call flow reaches the associated node; and dynamically jumping to the corresponding dialogue node based on the rule execution result.

[0011] In one implementation, the generation of the personalized dialogue includes: extracting indicator key-value pairs from the hit rule results; replacing placeholders in the dialogue template with the corresponding actual indicator values; and performing natural language optimization processing on the replaced dialogue.

[0012] According to one aspect of this application, a script generation device is provided, comprising: a rule engine module for executing the script generation method; a coaching robot module for managing script flow configuration and triggering rule engine execution; a smart agent platform module for displaying the generated script and collecting agent operation feedback; and a management configuration module for maintaining the definition of business indicators and data acquisition logic, and providing a visual interface for business personnel to configure rules and rule sets.

[0013] In one implementation, the rule engine module includes: a condition parsing unit for parsing logical expressions in a condition group; a rule execution unit for executing rule judgments in priority order; a result mapping unit for associating rule results with corresponding discourse templates; and an exception handling unit for returning a fallback result when rule execution fails.

[0014] In one implementation, the coaching robot module further includes: a process design unit for configuring script flow nodes and jump logic; an intent recognition unit for analyzing the customer's voice feedback on their willingness to complete the process; and a real-time monitoring unit for tracking the script execution effect and generating optimization suggestions.

[0015] According to one aspect of this application, a storage medium is provided that stores a computer program, wherein the computer program is configured to execute the above-described script generation method at runtime.

[0016] According to one aspect of this application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the above-described script generation method.

[0017] By employing the above technical solutions, the script generation method, apparatus, medium, and equipment provided in this application, through the multi-condition processing capabilities of the rule engine, the configurable extension mechanism, and the personalized script generation logic, comprehensively overcome the shortcomings of existing technologies in terms of logical dimension, scalability, and personalization, and realize the upgrade of telemarketing script recommendation from "rigid and static" to "intelligent and dynamic".

[0018] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and constitute a part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 shows a logical schematic diagram of a script generation method provided by an embodiment of this application; Figure 2 shows a flowchart of a script generation method provided by an embodiment of this application; Figure 3 shows a structural schematic diagram of a script generation device provided by an embodiment of this application. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of the present application can be combined with each other.

[0021] The inventors of this application have discovered that the core logical relationships of existing script recommendation schemes can only support binary judgment patterns such as "yes / no" and "have / don't have," thus exhibiting significant limitations at the logical judgment level. Specifically, during user interaction, the system can only make judgments based on simple attributes of a single dimension. For example, it can determine whether a user is a new customer by querying the user's registration time (registration time < 30 days is "yes," otherwise "no"), or determine whether there are overdue records based on repayment history (existing overdue repayment records are "yes," otherwise "no").

[0022] This implementation method manifests in the technical architecture as a static mapping mechanism of "single condition - fixed message": when the system detects that a user meets a certain binary condition, it directly retrieves the preset message bound to it. For example, if the judgment result is "the user is a new customer," then the message "exclusive offer for new customers" is always pushed; if it is "there is an overdue payment record," then the message "overdue payment reminder" is pushed. Throughout the process, the correspondence between the condition and the message is pre-written in the code and cannot be dynamically adjusted according to the combination of multiple conditions.

[0023] Taking telemarketing installment payment scenarios as an example, existing solutions can only handle single judgments such as "whether the user is eligible for installment payments": if the eligibility judgment is "yes," a fixed script of "installment payment services are available" is played; if it is "no," a script of "installment payments are not currently supported" is played. For complex situations that require consideration of multiple dimensions, such as "new customers with current bill amount > 10,000 yuan" or "existing customers with no overdue payments in the past 6 months," the system cannot make effective judgments and can only resort to using generic scripts.

[0024] Therefore, the existing solutions have at least the following technical defects.

[0025] 1. Limited Logic Dimension and Rigid Script Recommendations. The core flaw of existing solutions lies in their limited logical processing capabilities, supporting only basic binary judgments and unable to handle scenarios with nested combinations of multiple conditions. This single-dimensional logical design prevents the system from generating accurately matched scripts when faced with diverse user characteristics and behavioral data, ultimately resulting in mechanical and rigid script recommendations. Specifically, when business scenarios require combining multiple conditions for judgment (such as "user credit limit > 50,000 yuan and spending > 3,000 yuan in the past 3 months" or "customer tagged as VIP or with more than 5 purchases in the past month"), existing systems lack the ability to combine logical operators such as "AND / OR," making it impossible to verify composite conditions. For example, for high-value customers who simultaneously meet the criteria of "high credit limit" and "high-frequency spending," the system cannot identify their combined characteristics and can only push ordinary scripts based on a single condition (such as only "credit limit"), missing precise marketing opportunities. In actual telemarketing, this deficiency directly affects communication effectiveness. For example, when a user asks "how much is the installment interest?", if the user has multiple characteristics such as "high-quality customer", "large bill", and "first time using installment", the existing system cannot recommend a combination of "low interest + fee reduction" offers based on these conditions. Instead, it can only push a uniform interest explanation, which makes the offers unattractive and reduces the user's willingness to apply.

[0026] 2. Poor scalability and difficulty in adapting to business changes. In existing solutions, the binding of statements and conditions is hard-coded, meaning the conditional judgment logic, statement content, and their corresponding relationships are all directly written into the program code. This architectural design results in extremely poor system scalability. When the business needs to add conditions, modify judgment logic, or adjust statements, technical personnel must modify the source code and redeploy the system, making rapid response through configuration impossible. For example, when a new promotion is launched offering a 20% discount to new customers with installment periods > 12 months, the existing system needs to add a condition to determine whether the installment period is > 12 months and modify the binding relationship between the "new customer" condition and the statement in the code. The entire process involves multiple stages, including requirement confirmation, code development, testing, and deployment, typically requiring a 3-5 day cycle. In the context of rapid business iteration, this response speed is clearly insufficient, potentially causing new promotions to miss their optimal launch opportunity. Furthermore, the hard-coded model increases system maintenance costs. As business scenarios increase, a large number of fragmented conditional judgments and statement binding logic accumulate in the code, creating "code redundancy." When a condition needs to be modified (such as changing "new customer definition" from "registered for <30 days" to "registered for <60 days"), technical personnel need to locate the relevant logic in a large amount of code. This is not only inefficient, but may also cause new system problems due to omissions or errors, affecting stability.

[0027] This application addresses the problems of existing solutions by proposing a script generation method. Referring to Figure 1, which is a logical schematic diagram of a script generation method provided in an embodiment of this application, at least two fundamental changes exist compared to existing methods.

[0028] I. From "Fixed Mapping" to "Rule Engine Driven". Existing methods use a static mapping of "keywords / single conditions – fixed scripts". This solution achieves dynamic decision-making through rule sets (multiple condition combinations, priorities, and fallbacks). The core is the introduction of an intelligent flow mechanism of "condition judgment – ​​rule matching – script matching", rather than hard-coded binding. From "Single Module Independence" to "Multi-Module Collaboration". Existing methods rely solely on a single script library module. This solution adds collaboration between "rule sets", "indicator configuration", "5G smart agent platform", and "coach robot", forming a closed loop of "data collection – rule calculation – script generation", supporting end-to-end dynamic adaptation.

[0029] II. Collaborative Workflow of Each Module (Data Flow Perspective). Coaching Robot: Script flow and node configuration; determines script nodes by calling the rule engine; Smart Agent Platform (5G Smart Agent Platform): Front-end script node display; displays scripts based on the script nodes determined by the coaching robot; Rule Engine: determines the hit rules through rule configuration and returns the indicator name of the hit rules; obtains the script placeholder display value for the specified rule set through tasks and calls.

[0030] Figure 1 illustrates the interaction process of script generation and rule judgment, involving modules such as the coach robot, rule set, and 5G smart agent platform. The following explanation focuses on the implementation principles and process. Core Modules and Interaction Relationships: Coach Robot: As the process initiator, it triggers the script generation request, transmitting key parameters such as rule set encoding, call ID, and 5G task number, driving the rule judgment process. Rule Set: The core decision-making module, containing built-in rule judgment logic (condition groups, rule priorities, fallback strategies), outputting the result of hitting the rule or the fallback result (e.g., "xx broadcast", "yy broadcast"). 5G Smart Agent Platform: The data provider, querying and outputting dynamic indicators (e.g., customer name, available credit, maximum amount, etc.) through taskId, providing customer characteristic data for rule judgment. Script Template: Stores pre-configured script formats (including placeholders), replacing placeholders after receiving rule results to generate personalized scripts. The rule set achieves precise decision-making through "nested condition groups + priority sorting": Condition group structure: Each rule contains multiple condition groups (such as "condition group A, condition group B"). Conditions within a group are related by "logical AND (&&)" (all conditions must be satisfied), and conditions between groups are related by "logical OR (||)" (satisfying any one of these groups triggers the rule). For example: Condition group A: Indicator A = Condition 1 && Indicator B = Condition 2 && Indicator C = Condition 3; Condition group B: Indicator A = Condition 4 && Indicator B = Condition 5 && Indicator C = Condition 6; As long as either condition group A or condition group B is satisfied, the corresponding rule result is triggered. Priority control: Rules are sorted according to business priority (such as rule A > rule B), and the judgment is executed sequentially. Once a match is found, the process stops, ensuring that key rules take effect first. Fallback mechanism: If all rules are not matched, a preset fallback result is returned (such as "fallback result: xx broadcast") to avoid process interruption. The process from request to script generation is described below. 1. Request triggering. During a call, when the coaching robot needs to generate personalized scripts (such as inquiries about installment plans or incoming complaints), it sends a request to the rule set, carrying the rule set code (specifying which set of rules to use for judgment), the call ID (associated with customer data), and the 5G task number (business process identifier). 2. Indicator Query (Customer Feature Acquisition): The rule set calls the query interface of the 5G smart agent platform through the call ID, passing in the taskId to obtain dynamic customer indicators; the 5G smart agent platform executes the query and outputs indicator key-value pairs (such as {userName: "Zhang San", maxMoney: "10000"}), which serve as the "raw materials" for rule judgment. 3. Rule Judgment (Condition Group Validation): The rule set executes the judgment according to the following logic: Step 1: Load the rules corresponding to the rule set code (such as rule A, rule B), and sort them by priority (rule A is executed first).Step 2: Iterate through the condition groups of Rule A (condition group A, condition group B), and verify the conditions using the indicators returned by the 5G platform: If the indicator satisfies condition group A (e.g., indicator A ≥ threshold && indicator B contains enumerated values), trigger the result of Rule A (e.g., "xx broadcast"); if condition group A is not satisfied, verify condition group B, and if satisfied, trigger the result of Rule A; if all condition groups of Rule A are not satisfied, execute the judgment of Rule B (same logic as Rule A). Step 3: If all rules are not matched, return a fallback result (e.g., "Fallback result: xx broadcast"). 4. Script generation and output. Rule result mapping: The matched rule result (or fallback result) is associated with the script template library. The template contains placeholders (e.g., Dear {userName}, your available credit is {maxMoney}...). Personalized replacement: Replace the placeholders with the indicator values ​​returned by the 5G platform to generate a complete script (e.g., Dear Zhang San, your available credit is 10000...). Output Demonstration: The generated scripts are returned to the coaching robot and ultimately displayed on the intelligent agent platform for customer service personnel to refer to when communicating with customers. Thus, this application achieves personalized script recommendations tailored to each customer's characteristics through multi-condition nesting and priority control (e.g., recommending large installment plans to high-limit customers, emphasizing first-order benefits to new customers). Through rule set configuration (condition groups, indicators, and script templates can be flexibly adjusted), it supports rapid business iteration (e.g., adding a condition like "≥5 purchases in the last 3 months" requires no code modification, only rule configuration updates). Furthermore, automated rule judgment replaces manual decision-making, reducing customer service response time from minutes of "manual thinking + script search" to millisecond-level system judgment, significantly increasing the daily processing capacity per agent. In summary, Figure 1 illustrates the automated script generation process of "data-driven - rule-based decision-making - template rendering." Through modular interaction and condition validation, it solves the problems of slow response and inaccurate scripts in manual customer service, adapting to high-frequency dialogue scenarios such as telemarketing and customer service.

[0031] Referring to Figure 2, a flowchart of a script generation method provided in this application embodiment is shown, including the following steps S201-S206. S201: Receive a script request from a coaching robot via a rule engine. The request includes a call identifier and a task number. S202: Query customer characteristic indicators based on the call identifier. Customer characteristic indicators include at least one of real-time interface data, data delivery information, and big data query results. S203: Input the customer characteristic indicators into a pre-configured rule set for condition judgment. The rule set contains multiple rules ordered by priority. Each rule contains one or more condition groups, where conditions within a condition group are logical AND relations, and conditions between condition groups are logical OR relations. S204: Execute rule judgments sequentially according to priority. When the condition group of any rule is satisfied, return the rule result corresponding to that rule. S205: If all rules are not matched, return a preset fallback result. S206: Map the matched rule result or fallback result to the corresponding script template to generate a personalized script and return it to the smart agent platform for display.

[0032] As the core scheduling module of the entire system, the rules engine possesses an efficient request listening and processing mechanism. During a call with a customer, when a specific script needs to be generated, the coaching robot sends a request containing a call identifier and a task number to the rules engine, based on the current call scenario and task assignment. The call identifier uniquely identifies the current call session, allowing the system to accurately associate all information related to that call; the task number clarifies the type of business task carried by this call, such as product promotion, customer follow-up, or Q&A. The rules engine listens for these requests from the coaching robot in real time through pre-defined communication protocols and interfaces, and quickly adds them to the processing queue upon receipt. For example, consider a telemarketing company whose customer service team uses a coaching robot to assist in communicating with customers. When a customer inquires about the return policy of a product, the coaching robot identifies the call as belonging to the "Customer Inquiry - Return Policy" task type, generates a unique call identifier, such as "20250808143001," and sends a request to the rules engine along with the corresponding task number "TASK – 003" (representing a return policy inquiry within the customer inquiry category). This request receiving method achieves system modularity and functional decoupling, allowing the coaching robot to focus on customer interaction, while the rule engine focuses on complex rule judgments and script generation decisions based on the requests, improving the overall system efficiency and maintainability. Simultaneously, through clear call identifiers and task numbers, the background and objective of each call request can be accurately identified, providing clear guidance for subsequent processing.

[0033] The system can internally establish a massive customer information database, which is synchronized with various data sources in real time or periodically to ensure data timeliness and accuracy. When the rule engine receives a request with a call identifier, it uses that identifier as an index to quickly query the database for characteristic indicators related to that customer. Real-time interface data may come from enterprise-related platforms currently used by the customer, such as the customer's real-time browsing history and shopping cart information on telemarketing platforms, obtained through real-time interfaces with the platforms; data delivery information records the various marketing activities previously conducted by the enterprise for this customer, such as whether specific advertisements or promotional information have been pushed to this customer; big data query results are obtained through in-depth mining and analysis of massive amounts of customer data, such as customer consumption preference models and credit scores. In the example of the telemarketing company mentioned above, the call identifier query shows that the customer has recently frequently browsed a certain brand of women's clothing products and added them to the shopping cart but did not complete the purchase (real-time interface data); previously received promotional pushes from this brand of women's clothing but did not click on them (data delivery information); and big data analysis shows that this customer belongs to a fashion-sensitive group with high purchasing power (big data query results). Comprehensive and accurate customer characteristic index queries provide a rich data foundation for subsequent personalized script generation. Based on these indicators, the system can gain a deeper understanding of customers' behavioral habits, interests, and needs, thereby generating scripts that are more tailored to customers' actual situations, improving the relevance and effectiveness of customer communication, and enhancing customer experience and business conversion rates.

[0034] A rule set consists of a series of carefully designed business rules, prioritized according to business needs and objectives. Each rule comprises one or more condition groups. Conditions within a group are logically connected via AND, meaning a condition group is valid only if all conditions within it are met. Different condition groups are logically connected via OR, meaning a rule is considered satisfied if any one condition group is met. Once customer characteristic metrics are acquired, the system sequentially substitutes these metrics into the condition groups of each rule according to the priority order of the rule set. In a telemarketing scenario, the rule set might include a high-priority rule for handling the specific needs of high-value customers. This rule has two condition groups: Condition Group 1: The customer's cumulative spending exceeds 10,000 yuan (from big data query results) and the number of purchases in the past month is greater than 3 (real-time interface data); Condition Group 2: The customer belongs to the VIP customer level set by the enterprise (big data query results) and has viewed specific high-end product pages in the past week (real-time interface data). When a customer's characteristic metrics are input, the system checks whether these two condition groups are met in turn. This flexible and hierarchical rule set design can adapt to complex and ever-changing business scenarios and customer needs. Prioritization ensures that, when multiple rules are applicable, the rules most critical and important to the business are executed first, improving the efficiency and accuracy of rule judgment. Simultaneously, the combined use of logical AND and OR operations allows rules to accurately match different combinations of customer characteristics, providing precise decision-making basis for personalized script generation. The system strictly follows the pre-defined priority order of the rule set, starting with the highest priority rule and evaluating each rule's condition group one by one. During the evaluation process, the system compares customer characteristic indicators with each condition in the condition group, determining whether the condition group is true based on the logical AND and OR operation rules. Once any condition group of a rule is found to be true, the system immediately stops evaluating subsequent rules and returns the pre-defined rule result for that rule. This rule result is usually a specific indication or data corresponding to the business scenario or customer characteristics targeted by the rule, used to guide the selection of subsequent script templates. Continuing with the example of a telemarketing company, assume there are three rules in the rule set, with decreasing priorities. When processing a customer's request, the system first checks the highest priority rule. If the customer meets all the conditions in condition group one of that rule—that is, the customer's cumulative spending exceeds 10,000 yuan and the number of purchases in the past month is greater than 3—the system immediately returns the result corresponding to that rule, such as "High-value active customer discount recommendation," without checking the second and third rules. Executing rule checks according to priority avoids unnecessary rule calculations and greatly improves the system's operational efficiency.It can quickly and accurately determine the most suitable rule results based on customer characteristics, ensuring the timely generation of personalized scripts. This enables a rapid response and provides appropriate script guidance even in real-time communication scenarios with customers.

[0035] To address situations where customer characteristics may not match any existing rules, the system pre-sets a fallback result. When the system completes its evaluation of all rules in the rule set and finds that no rule's condition set is met, it triggers the fallback mechanism and returns this pre-set fallback result. The fallback result is typically a general indication or data applicable to most common situations, ensuring that appropriate script generation strategies are available even in complex or special customer scenarios. In the telemarketing system, if no specific rule suitable for a particular customer is found after evaluating all rules, the system returns the fallback result "General Customer Greeting and Product Introduction," meaning that subsequent generated scripts will be based on a general greeting and a standard product introduction. The fallback result increases the system's stability and reliability, preventing script generation failures or errors due to rule mismatches. It guarantees a basic script framework for communication with customers under any circumstances, maintaining service consistency and integrity, and reducing the negative impact on customer experience caused by system anomalies. The system can pre-build a script template library, where each script template corresponds to a specific rule result or fallback result. Once the system receives a rule-matched result or a fallback result, it uses that result as an index to search for a matching script template in the script template library. After finding the template, it replaces the placeholders in the template based on specific data from the customer characteristic indicators, thereby generating a personalized script perfectly tailored to the customer's actual situation. Finally, through the interface with the intelligent agent platform, the generated personalized script is sent and displayed on the agent's interface so that the agent can directly refer to it and communicate with the customer. For the rule result of "High-Value Active Customer Discount Recommendation," the corresponding script template might be: "Dear [Customer Name], thank you for your continued support. As you are one of our high-value active customers, we would like to recommend a [Product Name] to you. This product currently has an exclusive [X] discount, which is perfect for your needs." The system replaces the placeholders in the template based on the customer name and specific product information from the customer characteristic indicators, generating a script like: "Dear Ms. Zhang, thank you for your continued support. As you are one of our high-value active customers, we would like to recommend a fashionable dress to you. This product currently has an exclusive 20% discount, which is perfect for your needs." The generated scripts are then displayed on the intelligent agent platform. By mapping the rule results to the script templates, the generation of scripts is automated and standardized. Personalized scripts closely align with customer characteristics and business needs, significantly improving the effectiveness and quality of communication with customers. Simultaneously, displaying the scripts on the intelligent agent platform allows agents to quickly access and use them, enhancing the efficiency and consistency of customer service and contributing to improved customer satisfaction and business performance.

[0036] In the first implementation, the rule set configuration process includes the following steps: defining multiple business metrics, each including a metric name, data source, and acquisition method; configuring at least one rule for each business scenario, each rule containing at least one condition group, the condition group consisting of a business metric, comparison operators, and a threshold; sorting multiple rules according to business priority to form a rule set, and configuring a fallback result for the rule set. This is explained in detail below. First, multiple business metrics are defined, each including a metric name, data source, and acquisition method. Before constructing the rule set, the key metrics involved in the business need to be clearly defined. The metric name is used to uniquely identify each business metric, giving it clear identifiability throughout the system. The data source indicates the source of the metric's data, such as a customer database, business system logs, or a third-party data platform. The acquisition method details the specific technical means and operational procedures for obtaining the metric data from the data source, which may include database query statements, API call interfaces, data file reading, etc. Through the definition of these aspects, the system can accurately understand and obtain the data of each business metric, providing a foundation for subsequent rule formulation and condition judgment. For example, in financial lending, a "customer credit score" business indicator is defined, named "CreditScore." The data source is a database from a third-party credit rating agency, obtained by calling the agency's API, passing in the customer's unique identifier, and retrieving the corresponding credit score data. Similarly, a "customer loan application count" indicator is defined, named "LoanApplicationCount." The data source is the company's internal loan business system database, obtained by executing an SQL query to count the number of loan applications for each customer from the loan application record table. Thus, clear business indicator definitions make the system's data acquisition process more standardized and manageable. Different business personnel and developers can work based on unified indicator definitions, avoiding data confusion or errors caused by inconsistent understanding of the indicators. At the same time, clear data sources and acquisition methods ensure data accuracy and timeliness, thereby improving the reliability and effectiveness of the rule set, as rule judgments rely on accurate business indicator data. Secondly, at least one rule is configured for each business scenario, and each rule contains at least one condition group, which consists of a business indicator, comparison operators, and a threshold. For different business scenarios, such as loan approval, customer marketing, and risk assessment, corresponding rules are configured according to business objectives and needs. Each rule is used to determine whether it applies to the current business situation through a set of conditions. A condition set consists of business metrics, comparison operators (such as greater than, less than, equal to, and inclusive), and thresholds. When the system executes rule judgments, it retrieves the actual values ​​of the business metrics from the data source and then compares them with the thresholds in the condition set using comparison operators to determine whether the condition set is valid.For example, in a loan approval scenario, a rule might be used to determine whether to grant a loan to a customer. Its condition set might be: the customer's credit score (business indicator) is greater than (comparison operator) 600 (threshold) and the customer's number of loan applications (business indicator) is less than (comparison operator) 3 (threshold). Similarly, in a telemarketing scenario, a rule might be configured to target new customers with promotional activities. This rule has a condition set: the customer's registration time (business indicator) is within the last 30 days (threshold) and the customer's purchase amount (business indicator) equals (comparison operator) 0 (threshold). The rule is only triggered when both conditions are met—that is, for newly registered customers who have not yet made a purchase. Subsequent marketing messages such as exclusive new user coupons might then be pushed to these customers. This rule configuration method allows the system to flexibly handle various complex business scenarios. By reasonably setting business indicators, comparison operators, and thresholds, the judgment criteria for different business scenarios can be precisely defined, achieving refined control over the business process. Different business scenarios can have their own independent rules, or they can be interconnected to build a comprehensive and orderly business rule system, providing strong support for the company's business operations. For example, more precise customer marketing can improve marketing effectiveness and customer conversion rates, while reasonable loan approval rules help control risks. Finally, multiple rules are sorted according to business priority to form a rule set, and a fallback result is configured for the rule set. In actual business, different rules have different levels of importance and urgency. Therefore, it is necessary to sort the configured rules according to priority based on business logic and objectives to form a rule set. The determination of priority may consider various factors, such as the importance of the business involved in the rule, the degree of impact on business performance, and the frequency of rule application. At the same time, to deal with the special case where all rules cannot match the business situation, a fallback result is configured for the rule set. When the system executes rule judgment, it will judge according to the priority order of the rule set. Once the condition group of a rule is met, the rule is executed; if all rules are not matched, the fallback result is returned. For example, in a telemarketing order processing system, the rule set might include rules for prioritizing high-value customer orders, special handling rules for promotional orders, and standard handling rules for regular orders. Based on business importance, high-value customer order processing rules are set to the highest priority, followed by promotional order processing rules, and then regular order processing rules. If an order's customer characteristics and order information do not match any of the preceding rules, the system returns a fallback result and processes it according to the standard procedure for regular orders. Thus, prioritizing rules ensures that the system executes the most critical rules for the business process first, improving efficiency and accuracy. It also avoids business errors or unreasonable processing caused by disordered rule execution order in complex business scenarios.The configuration of fallback results increases the completeness and fault tolerance of the rule set, ensuring that the business has a basic processing method under any circumstances, guaranteeing the continuity and stability of the business, and reducing the negative impact on the business caused by system anomalies or incomplete rules.

[0037] In the second implementation, conditional judgments support nested combinations of multiple conditions, including: range judgments for numerical conditions; multi-value matching for enumerated conditions; and range comparisons for time-related conditions. Examples are provided below. 1. Support for range judgments of numerical conditions. In the condition group of a rule, when numerical business indicators are involved, the system supports range judgments. This is achieved by using specific combinations of comparison operators in the condition definition, such as greater than or equal to (>=) and less than or equal to (<=). When the system executes rule judgments, for range judgments of numerical conditions, it compares the obtained actual value of the business indicator with the set upper and lower limits of the range. If the actual value is within the set range, the numerical condition is valid; otherwise, it is invalid. For example, in a condition for judging a customer's spending range, the spending amount (business indicator) is set to be greater than or equal to 100 (lower limit) and less than or equal to 500 (upper limit). The system will compare the customer's actual spending amount with these two thresholds during the judgment. For example, in the promotional activity rules of a telemarketing platform, there is a discount rule for customers with medium spending amounts. One of the condition groups is a numerical condition: the customer's current order amount is greater than or equal to 200 yuan and less than or equal to 800 yuan. When the system obtains a customer's order amount data, it performs a range judgment. If the amount is between 200 and 800 yuan, the condition is met, potentially triggering subsequent processes for the customer to participate in the promotional activity, such as offering a discount or coupons. It is evident that range judgment for numerical conditions greatly enhances the flexibility and applicability of the rules. In many business scenarios, such as customer spending stratification, product price range filtering, and setting business indicator threshold ranges, it is necessary to define numerical ranges to determine the business processing method. By supporting this range judgment, the system can more accurately match customer characteristics and business data under different business scenarios, enabling more detailed business rule formulation and execution, thereby improving the refinement and effectiveness of business operations. 2. Support for multi-value matching of enumerated conditions. Enumerated conditions predefine a finite set of values. When judging, the system matches the input value with each value in the enumerated set. As long as the input value is equal to any value in the set, the condition is true. The system completes the matching process by traversing the enumerated set and performing one-to-one comparisons. For example, in a product category management system, product categories are defined as enumerated types, including "electronic products," "clothing," "food," and "household goods." To find products with the category "electronic products" or "clothing," the system will match each product's category attribute against "electronic products" and "clothing." When a product with the category "clothing" is encountered, that product satisfies the multi-value matching of this enumerated condition. For condition judgments with a clearly defined and finite range of values, multi-value matching of enumerated conditions provides a simple, intuitive, and efficient judgment method.It can accurately filter data from large amounts of data to identify those meeting specific category requirements, and is widely used in information classification, data filtering, and other scenarios, improving the system's ability to retrieve and process specific types of data. 3. Supports range comparison for time-based conditions. Time-based conditions also set start and end times, and the system compares the time data to be judged with the set time range. Time data is usually stored in a specific time format, and the system uses a time order comparison algorithm to compare the chronological order of times to determine whether the time falls within the specified time interval. Range comparison for time-based conditions is extremely important, as it enables the system to effectively filter and analyze data based on the time dimension, helping to identify events or tasks completed within a specific time period and providing accurate time-based data support for decision-making.

[0038] In the third implementation, the above-mentioned script generation method further includes: configuring script flow nodes in the script forest system, associating at least one flow node with the rule set; automatically triggering the execution of the rule set when the call flow reaches the associated node; and dynamically jumping to the corresponding script node based on the rule execution result. This is explained in detail below. First, configuring script flow nodes in the script forest system, associating at least one flow node with the rule set. The script forest system constructs a tree-structured flow model, where each node represents a script step. Through the configuration interface or programming interface provided by the system, operators can explicitly specify which flow nodes are associated with a specific rule set. Internally, by establishing a data mapping relationship, the unique identifier of the node and the relevant information of the rule set are stored in an association table for quick subsequent lookup and retrieval. For example, in a customer service script system, there are flow nodes such as "greeting the customer," "inquiring about needs," "product introduction," and "handling complaints." Suppose that for high-value customers, a special marketing rule set needs to be executed. The operator associates the "inquiring about needs" node with the rule set for high-value customers. At the system's underlying layer, the correspondence between the ID of the "Inquire about needs" node and the ID of the corresponding rule set is recorded. This association configuration method allows for flexible customization of the script flow based on different business rules. When business scenarios change, such as requiring different rules for different customer groups or business stages, the association between nodes and rule sets can be easily reconfigured in the system without large-scale modifications to the entire script flow's code logic, greatly improving the maintainability and adaptability of the script system. Then, when the call flow reaches the associated node, the execution of the rule set is automatically triggered. During operation, the system continuously monitors the progress of the call flow. When it detects that the current flow has progressed to a node associated with a pre-configured rule set, the system quickly locates the corresponding rule set based on the previously established association mapping and starts the rule set's execution engine. The execution engine processes and judges the relevant data sequentially according to the order and logic set within the rule set. For example, in the aforementioned customer service script system, when the call flow between the customer service representative and the customer reaches the "Inquire about needs" node, the system monitors in real time that this node is associated with a rule set for high-value customers. The system immediately invokes the rule set, which begins analyzing customer information (such as purchase history and frequency) to determine the next sales pitch strategy. This automatic rule set execution mechanism ensures that appropriate business rules are applied promptly at the right time, eliminating the need for manual intervention, reducing the possibility of human error, and improving the automation and efficiency of the call process. Simultaneously, it allows the entire sales pitch to be dynamically adjusted based on the customer's real-time situation and business rules, enhancing the quality and relevance of customer service. Finally, based on the rule execution result, the system dynamically redirects to the corresponding sales pitch node.After the rule set is executed, an execution result is generated, which is typically presented as a specific status code, Boolean value, or other predefined data format. Based on the pre-defined mapping relationship between the result and the script node, the system finds the corresponding target script node according to the rule execution result and directs the call flow to that node. This mapping relationship is also stored in the system's configuration data for easy querying and use. For example, if the rule set execution result for high-value customers indicates that the customer has potential interest in a certain type of new product, the system will jump the call flow to the "Detailed Introduction of New Products" script node according to the pre-defined mapping relationship. Assuming the rule set execution result returns a status code "003," the system can query the configuration data to find that the target node corresponding to "003" is "Detailed Introduction of New Products," thus achieving the flow jump. It is evident that dynamically jumping to script nodes based on the rule execution result allows the script flow to be intelligently adjusted based on customer feedback and business judgment, achieving a personalized service experience. Customers receive script guidance that better matches their needs, improving customer engagement and satisfaction, while also helping businesses better understand customer needs and promote business growth.

[0039] In the fourth implementation method, the personalized script generation process described above includes: extracting indicator key-value pairs from the hit rule results; replacing placeholders in the script template with the corresponding actual indicator values; and performing natural language optimization on the replaced script. This is explained in detail below. First, extracting indicator key-value pairs from the hit rule results. After the rule set is executed and a specific rule is hit, the rule results contain a series of business-related information, organized in key-value pairs. The system parses the rule result data structure, extracts rules according to predefined key-value pairs, and identifies the indicator names (keys) and their corresponding values. For example, if the rule result is JSON format data, the system will locate and extract the required key-value pair elements according to the JSON syntax rules. For example, in a telemarketing script generation scenario, after executing a rule set for a certain promotional activity, the hit rule results show that a customer meets the condition of "purchased a specific product and the consumption amount exceeded 1000 yuan". The rule result data contains key-value pairs such as "Customer ID: 12345", "Purchased Product Category: Electronic Products", and "Consumption Amount 1500 Yuan". The system extracts "Consumption Amount" as the key and "1500 Yuan" as the value according to the extraction rules, which is then used for subsequent script generation. This precise extraction of key-value pairs from the matched rules provides a crucial data foundation for personalized script generation. These key-value pairs reflect specific customer attributes and business-related information, ensuring the generated script closely aligns with the customer's actual situation, enhancing its relevance and personalization. Next, placeholders in the script template are replaced with their corresponding actual values. The script template is pre-designed and includes placeholders to identify locations where specific data needs to be filled. The system matches and replaces the values ​​from the extracted key-value pairs with the placeholders in the script template. Using a string replacement algorithm, the string representation of specific placeholders in the template is replaced with the actual indicator values, generating preliminary personalized script text. For example, the script template might be: "Dear customer, your previous purchase of [Product Category] amounted to [Consumption Amount] Yuan. We now recommend an upgrade product that is more suitable for you…". The system extracts the data "Product Category: Electronics" and "Amount: 1500 yuan," and replaces "[Product Category]" with "Electronic Products" and "[Amount]" with "1500 yuan" in the template, resulting in the message: "Dear customer, your previous purchase of electronic products has reached 1500 yuan. We now recommend an upgrade product that is more suitable for you..." This method of generating personalized scripts through placeholder replacement makes the script template highly reusable. Only one script template framework needs to be maintained, and combined with specific indicator values ​​for different customers, a large amount of personalized script content can be quickly generated, improving the efficiency and flexibility of script generation while ensuring consistency in script style.Finally, the replaced text undergoes natural language processing (NLP). NLP techniques are used to perform grammar checks, semantic optimization, and fluency adjustments on the replaced text. The grammar check module detects and corrects grammatical errors. Semantic optimization uses synonym replacement and vocabulary selection to make the text more accurate and clear. Fluency adjustments optimize sentence structure and add appropriate conjunctions to make the text read and sound more natural and fluent. The system typically trains models based on a large amount of language data to achieve these optimization functions. For example, in the generated text "Dear customer, your previous purchase of electronic products amounted to 1500 yuan. Now we recommend an upgrade product that is more suitable for you…", NLP might optimize "amounted to 1500 yuan" to "up to 1500 yuan," making the expression more persuasive; adding conjunctions like "therefore" between sentences makes the transition more natural, resulting in "Dear customer, your previous purchase of electronic products amounted to 1500 yuan. Therefore, we recommend an upgrade product that is more suitable for you…". Therefore, the language used in the optimized natural language processing is more in line with human language habits and communication styles, improving customer acceptance and comprehension. Customers experience a more natural and friendly communication experience when interacting with customer service personnel or receiving marketing information, which helps strengthen the positive interaction between customers and the company, ultimately improving business results.

[0040] In summary, the proposed solution can be summarized as follows: First, configure indicators, including indicator names, acquisition channels, and other information; configure rules, selecting one or more indicators as conditional judgments, setting their judgment methods, a rule can contain multiple condition groups, the relationship between condition groups is OR, a condition group can configure multiple conditions, the relationship between multiple conditions is AND; set rule sets, rule sets contain multiple rules, rules have priorities, judgments are executed according to priority, if the condition is met, the result of that rule is returned, if none are met, a fallback rule can be set; set dialogue flow nodes in the dialogue forest, configure node flow methods, this rule system can be used for interface judgments, specify a rule set, a rule result is calculated through rule logic, if the result is satisfied, jump to that result node.

[0041] The following is a specific example. In this example, the scenario is: a bill installment product marketing scenario. The system involves the following processing nodes: rule configuration - outbound call connection - launching the auxiliary robot process - pop-up script prompt box - entering the opening remarks - judging intent and calling the configured rule set - obtaining current customer characteristics - inputting the rule set [the rule set contains rules, rules contain condition groups, condition groups contain conditions, and conditions consist of various customer characteristic indicators + operators] - performing calculations - obtaining the script result indicator - mapping the result indicator to the associated script template library, and returning the corresponding marketing script. Detailed explanations are as follows: 1. Rule Configuration: Before the function is applied, business personnel complete the relevant configuration through the 5G-Telemarketing Service-Script Forest menu and the coach robot's internal management system. 2. Outbound Call Connection: After predicting and previewing the customer task via 5G and connecting the outbound call, the 5G front-end invokes the coach robot and launches the relevant coach robot scenario. 3. Opening Remarks Judgment: At this point, the agent needs to read the marketing opening remarks aloud. The rule engine can use the coaching robot to call the rule set to judge the customer's installment characteristics (e.g., the entire bill can be processed, the customer has a temporary credit limit adjustment, installment discounts, etc.), and prompt the agent with the marketing opening remarks based on the judgment results (e.g., "We noticed that your recent spending at CITIC Bank, including both outstanding and unbilled amounts, totals X yuan, which can all be included in this installment activity. You don't need to pay a penny this period. You don't need to pay on x days, and you can pay next month. This installment will not affect your fixed credit limit and will not affect your normal card spending. We also offer you a limited-time X% interest discount. If you choose a 36-month installment plan, the monthly interest for 10,000 yuan will only be X yuan, while it would be 75 yuan without the discount." The agent reads the opening remarks aloud as prompted by the coaching robot. 4. Retention Script Judgment: After the agent reads the opening remarks, the customer will express their willingness to apply. The coaching robot can identify the customer's intent through an intent recognition model (e.g., high cost) and enter the customer retention process. At this point, based on the customer's intentions and installment characteristics (such as high costs + installment discounts), you can suggest retention tactics (e.g., "Many of our internal employees don't enjoy this discount, otherwise I wouldn't have strongly recommended you take it. No collateral or guarantee is required. Really, this is a rare opportunity, let's register!"). 5. Important Reminder Judgment: After the agent's retention efforts, if the customer agrees to proceed, the processing begins. At this time, based on the customer's installment characteristics (e.g., the customer has a temporary credit limit), you can provide important information (e.g., "Our bank has configured a pre-approved credit line for you. After successfully processing the installment plan, it can be activated as a dedicated credit line. This credit line will be used first and will not affect your fixed credit line; during the installment period, the installment principal will be used first and will occupy the dedicated credit line, while the portion exceeding the pre-approved credit line will occupy the fixed credit line...").

[0042] As can be seen, the script generation method provided in this application, based on the existing process, adds process and script matching based on a rule engine to meet the diverse needs of telemarketing. Specifically, the rule engine adopts a configurable rule engine that supports multi-condition combination logic (&& within condition groups, and || between condition groups), and handles rule matching logic through priority sorting and a fallback mechanism. For example, rule A includes "condition group A (user credit limit > 10,000 yuan && no overdue payments in the past 3 months)" and "condition group B (user tag is A || number of purchases > 10 times)". Meeting either condition group will match rule A.

[0043] Therefore, this application includes the following technical means and advantages: (1) Indicator configuration: Predefine indicators (such as "available points", "maximum amount of Dream Fund", "current total consumption amount of a single bill"), and clarify the indicator name, data source (such as real-time interface, data delivery, big data query) and acquisition method; (2) Rule configuration: Configure rules for each business scenario, including one or more condition groups (conditions within the group are "AND" relationship, and conditions between groups are "OR" relationship), and bind the rule results; (3) Rule set management: Sort multiple rules according to priority to form a rule set, and the rule with higher priority is judged first. If no rule is hit, trigger the fallback result (such as general script). (4) Script matching: The rule set is associated in the process node of the script forest. The rule set is called in real time during the call and the corresponding script node is dynamically jumped according to the rule hit result; (5) Multi-condition coverage of complex scenarios: Through the "AND / OR" combination of the condition group, it can adapt to the diverse combination of user characteristics, behavioral data and scenario requirements, and break through the limitation of single conditions; (6) Dynamic adaptation and priority mechanism: The rule set is sorted by priority, which can respond to high weight requirements first. At the same time, the fallback mechanism ensures that there are still suitable scripts in extreme scenarios; (7) Configuration improves flexibility: Indicators, rules and rule sets all support visual configuration. No code modification is required to add scenarios and quickly respond to business changes.

[0044] Corresponding to the above-described script generation method, this application also provides a script generation device. Referring to Figure 3, a schematic diagram of a script generation device provided in this application is shown. The device includes: a rule engine module 301, used to execute the aforementioned script generation method; a coaching robot module 302, used to manage script flow configuration and trigger rule engine execution; a smart agent platform module 303, used to display the generated script and collect agent operation feedback; and a configuration management module 304, used to maintain the definition of business indicators and data acquisition logic, and to provide a visual interface for business personnel to configure rules and rule sets.

[0045] In one implementation, the rule engine module 301 includes: a condition parsing unit for parsing logical expressions in a condition group; a rule execution unit for executing rule judgments according to priority order; a result mapping unit for associating rule results with corresponding discourse templates; and an exception handling unit for returning a fallback result when rule execution fails.

[0046] In one implementation, the coaching robot module 302 further includes: a process design unit for configuring script process nodes and jump logic; an intent recognition unit for analyzing the customer's voice feedback on their willingness to complete the process; and a real-time monitoring unit for tracking the script execution effect and generating optimization suggestions.

[0047] In one implementation, the rule engine module 301 is further configured to: configure a dialogue flow node in the dialogue forest system, associate at least one flow node with the rule set; automatically trigger the execution of the rule set when the call flow reaches the associated node; and dynamically jump to the corresponding dialogue node according to the rule execution result.

[0048] In one implementation, the rule engine module 301 generates personalized scripts by: extracting indicator key-value pairs from the hit rule results; replacing placeholders in the script template with the corresponding actual indicator values; and performing natural language optimization on the replaced scripts.

[0049] Embodiments of this application also provide a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0050] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0051] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0052] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0053] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0054] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0055] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0056] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0057] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0058] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0059] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0060] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for generating dialogue scripts, characterized in that, include: The rule engine receives a script flow request from the coach robot, the request containing a call identifier and a task number. The call identifier is used to query customer characteristic indicators, which include at least one of real-time interface data, data delivery information, and big data query results. The customer characteristic indicators are input into a pre-configured rule set for condition judgment. The rule set contains multiple rules sorted by priority. Each rule contains one or more condition groups, where conditions within a condition group are logical AND relations, and conditions between condition groups are logical OR relations. The rules are judged sequentially according to priority. When the condition group of any rule is satisfied, the rule result corresponding to that rule is returned. If all rules are not matched, a preset fallback result is returned. The matched rule result or fallback result is mapped to the corresponding script template to generate personalized scripts and returned to the smart agent platform for display.

2. The method according to claim 1, characterized in that, The configuration process of the rule set includes: defining multiple business metrics, each business metric including metric name, data source and acquisition method; configuring at least one rule for each business scenario, each rule containing at least one condition group, the condition group consisting of business metrics, comparison operators and thresholds; sorting multiple rules according to business priority to form a rule set, and configuring a fallback result for the rule set.

3. The method according to claim 2, characterized in that, The condition judgment supports nested combination of multiple conditions, including: range judgment of numerical conditions; multi-value matching of enumerated conditions; and range comparison of time conditions.

4. The method according to claim 1, characterized in that, The method further includes: configuring a script flow node in the script forest system, associating at least one flow node with the rule set; automatically triggering the execution of the rule set when the call flow reaches the associated node; and dynamically jumping to the corresponding script node based on the rule execution result.

5. The method according to claim 1, characterized in that, The generation of personalized dialogue includes: extracting indicator key-value pairs from the hit rule results; replacing placeholders in the dialogue template with the corresponding actual indicator values; and performing natural language optimization processing on the replaced dialogue.

6. A script generation device, characterized in that, include: The rules engine module is used to execute the method described in any one of claims 1-5; The coach robot module is used to manage the configuration of the script flow and trigger the execution of the rules engine; The intelligent agent platform module is used to display the generated scripts and collect agent operation feedback; The management configuration module is used to maintain the definition of business metrics and data acquisition logic, as well as to provide a visual interface for business personnel to configure rules and rule sets.

7. The apparatus according to claim 6, characterized in that, The rule engine module includes: a condition parsing unit for parsing logical expressions in a condition group; a rule execution unit for executing rule judgments according to priority order; a result mapping unit for associating rule results with corresponding speech templates; and an exception handling unit for returning a fallback result when rule execution fails.

8. The apparatus according to claim 6, characterized in that, The coaching robot module also includes: a process design unit for configuring script flow nodes and jump logic; an intent recognition unit for analyzing customer voice feedback on their willingness to complete the process; and a real-time monitoring unit for tracking the script execution effect and generating optimization suggestions.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method described in any one of claims 1 to 5 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method as described in any one of claims 1 to 5.

Images