A multi-scene multi-round dialogue method and system for virtual customer service

Abstract

The present application relates to a kind of multi-scene multi-round conversation method and system for virtual customer service, the system includes conversation scheduling component, business handling component, knowledge base query component and chat component.Conversation scheduling component is used to manage the running order and calling relationship of each scene conversation component, business handling component is responsible for handling the conversation related to business handling, knowledge base query component is responsible for handling the general knowledge retrieval type conversation of non-business handling type, chat component is responsible for handling the general conversation of non-business handling and non-knowledge base query type.The multi-scene multi-round conversation method for virtual customer service proposed in the present application can make virtual customer service robot flexibly switch between different conversation scenes, and the switching is automatically perceived by the conversation content at each round of natural conversation, without external intervention, solves the problem of conversation fragmentation, and further promotes the development of virtual digital people in personification, interaction ability and other aspects.

Description

Technical Field

[0001] This invention relates to the field of natural language processing technology, specifically to a multi-scenario, multi-turn dialogue method and system for virtual customer service. Background Technology

[0002] Virtual customer service refers to the application of virtual digital humans in intelligent customer service scenarios. Traditional customer service typically only needs to have the ability to inquire about and process business, while virtual customer service, due to its vividness, interactivity, and other characteristics, often also undertakes tasks such as natural conversation, casual chat, and question-and-answer. This not only requires virtual customer service to have more general conversational abilities beyond business rules, but also requires it to be able to determine the current conversational scenario based on the user's input and context, and to be able to switch naturally between different scenarios.

[0003] Several works have already been proposed for implementing multi-scenario, multi-turn dialogue switching. Xu Min et al., in their invention patent "Conversation Scene Switching Method and Device" (patent number 201811626785.8), proposed a dialogue scene switching method. This method determines whether to remain in the first scene, switch to the second scene, or revert to the first scene based on the similarity of user input messages in two adjacent rounds. Li Chunlan et al., in their invention patent "A Method and System for Constructing a Multi-Turn Dialogue System Based on Business Scenarios" (patent number 201911166714.9), proposed a multi-turn dialogue method for multi-scenario businesses. This method presets keywords and expectations for different business scenarios and uses an intent determination model and a rule matching model for scenario matching and conversion. Wang Zihao et al., in their invention patent "Method and Device for Intelligent Customer Service Multi-Turn Conversation Management" (patent number 202010809597.X), proposed a multi-turn intent model. By identifying user intent during multiple rounds of communication with the user, the system can execute different business logic based on potential user intent categories.

[0004] The problem with the aforementioned methods is that they are designed to switch between only two scenarios or multiple scenarios with similar functions, and most of them can only provide the "intention" or "signal" for scenario switching, requiring other methods to implement the specific dialogue logic. These methods are more suitable for traditional customer service robots, which identify the type of business the user needs to handle through two or more rounds of dialogue and then hand it over to system components to implement the business process. For the application of virtual digital human technology in intelligent customer service scenarios, the virtual human needs to possess complete dialogue logic similar to that of a real person and be able to switch naturally and flexibly between different dialogue scenarios, which is something that existing methods do not possess. Summary of the Invention

[0005] This invention addresses the technical problems existing in the prior art by providing a multi-scenario, multi-turn dialogue method and system for virtual customer service. It provides multi-turn dialogue capabilities for three different scenarios: business processing, knowledge base query, and casual conversation. Through an overall scenario dialogue scheduling and method and three independent scenario dialogue methods, it intelligently identifies user semantics and switches between different scenario contexts to complete the dialogue.

[0006] The technical solution of the present invention to solve the above-mentioned technical problems is as follows:

[0007] On the one hand, the present invention provides a multi-scenario, multi-turn dialogue system for virtual customer service, wherein the multi-scenario includes business processing scenarios, knowledge base query scenarios, and casual conversation scenarios.

[0008] The business processing scenario refers to the process where users select from various preset business processing routes according to guidance to move forward, backward, jump, or exit between different business processing steps. The knowledge base query scenario refers to the process where users retrieve the content corresponding to a specific entry from a database containing knowledge entries and knowledge content. The casual chat scenario refers to the conversational process where users chat aimlessly, engaging in non-business queries and non-specific content retrievals.

[0009] The dialogue system includes a dialogue scheduling component, a business processing component, a knowledge base query component, and a chat component.

[0010] The dialogue scheduling component is used to manage the running order and calling relationship of dialogue components in each scenario, and provides an interface for interaction with the outside world; in each round of dialogue, it receives text or voice input from the outside world, processes it and returns the response text or voice, and waits for the next input;

[0011] The business processing component is used to handle business processing-related dialogues, maintain all business rule processing paths, and record the current business processing progress.

[0012] The knowledge base query component is used to process general knowledge retrieval dialogues that are not business processing types, maintain the knowledge base and manage a context recorder to track the query progress.

[0013] The chat component is used to handle chat-type dialogues that are neither related to business processing nor content retrieval, and to maintain the historical conversation content of the current multi-turn chat.

[0014] Furthermore, the business processing component includes a business processing line, a progress recorder, a business processing query interface, and a progress reset interface;

[0015] The business processing line includes a linear data structure composed of nodes of business processing steps arranged in sequence, supporting single or multiple business processing lines; each node contains at least the pre-set data entering the node, information pointing to the next node, and a method for processing user responses; each node is responsible for processing one round of dialogue, the node first returns a pre-set data, the user responds according to the data, the node checks the user's response information and determines the node jump information;

[0016] The progress recorder is a variable used to record the current node position, including the current line and the node position of that line; initially, the progress recorder points to an initial node; the initial node does not contain preset corpus and next node information, and uses the first node of each business processing line as the jump node, and uses the business description of each business processing line as the trigger text.

[0017] The business processing query interface is used to execute a single-round business processing dialogue; it sends user input to the node pointed to by the current progress recorder, and the node returns a response text and points the progress recorder to a new node according to the node's rules;

[0018] The progress reset interface is used to reset the progress recorder and point it to the initial node.

[0019] Furthermore, the business processing route also includes special jump nodes, which contain special trigger text and the jump node, response text or exit information after triggering.

[0020] Furthermore, the node examines the user's response information and determines the node redirection information, including:

[0021] After receiving a user's reply, the node determines whether it contains special trigger text. If it does, the node matches the user's reply with the special trigger text. If the match fails or the node does not contain special trigger text, the node proceeds to the next node. If the match succeeds, the node jumps to the trigger-related jump node it contains.

[0022] Furthermore, the knowledge base query component includes a knowledge base module, a retrieval context module, a knowledge base query interface, and a context reset interface;

[0023] The knowledge base module includes one or more directed acyclic tree structures, which consist of knowledge tags and knowledge content; the root node is a first-level knowledge tag, the intermediate nodes are nested multi-level tags, and the leaf nodes are the final knowledge content. Each node contains at least the knowledge tag text or knowledge content text represented by that node.

[0024] The retrieval context module contains a list of sub-tags of the current retrieval node and the position index of each sub-tag. Initially, or when the retrieval node is a leaf node, the retrieval context module is empty.

[0025] The knowledge base query interface is used to execute a single-round knowledge base query dialogue; during the query, it directly retrieves any knowledge tag of a non-leaf node.

[0026] The context reset interface is used to reset the retrieval context module to empty.

[0027] Furthermore, when executing a single-round knowledge base query dialogue, the knowledge base query interface performs the following operations:

[0028] Obtain the user's query text and determine if the retrieval context module is empty;

[0029] If the retrieval context module is not empty, calculate the similarity between the query text and the retrieval context; if the highest similarity is greater than the first preset threshold, return the sub-tags or knowledge content of the sub-tag with the highest similarity and update the retrieval context module; otherwise, return a "matching failure" signal.

[0030] If the retrieval context module is empty, calculate the similarity between the query text and all knowledge tags; if the highest similarity is greater than the second preset threshold, return the sub-tags or knowledge content of the knowledge tag corresponding to the highest similarity and update the retrieval context module; otherwise, return a "retrieval failed" signal.

[0031] Furthermore, the chat component includes: a multi-turn dialogue chat model, a historical chat history module, a chat history query interface, and a chat history reset interface;

[0032] The multi-turn chat model is a generative Seq2Seq neural network model that takes historical chat records and the query text of the current turn as input and outputs the chat response text of the current turn.

[0033] The historical chat history module is used to record query text and response text within a certain number of historical rounds. The number of historical rounds can be finite or infinite. Initially, the historical chat history module is empty.

[0034] The chat history query interface is used to execute a single-turn chat dialogue; its chat method is as follows: the historical chat history and the query text are concatenated and then forwarded through a multi-turn dialogue chat model, and the result is returned to the model output.

[0035] The chat history reset interface is used to reset the historical chat history module to empty.

[0036] Furthermore, the dialogue scheduling component includes:

[0037] The information receiving module is used to receive user-input query text or query voice.

[0038] The conversion module is used to parse the input query speech into query text using a speech-to-text algorithm;

[0039] The scheduling response module is used to take the query text as input, sequentially call the business processing component, knowledge base query component and chat component to match the query text, obtain the corresponding response text as output text, and confirm the dialogue intent;

[0040] The output module is used to return the output text to the user.

[0041] Furthermore, the scheduling response module is specifically used for:

[0042] The query text is used as input, and the business processing query interface in the business processing component is called to perform text matching. The first response text is obtained according to the matching result. If the first response text is not a "matching failure" signal, the dialogue intent is confirmed to be business processing. The first response text is used as the output text, and the context reset interface of the knowledge base query component and the chat history reset interface of the chat component are called. Otherwise, the knowledge base query interface in the knowledge base query component is called to perform text matching.

[0043] The knowledge base query component obtains a second response text based on the matching result. If the second response text is not "match failed" or "retrieval failed", the intent of the dialogue is confirmed as a knowledge base query. The second response text is used as the output text, and the progress reset interface of the business processing component and the chat history reset interface of the chat component are called. If the second response text is a "match failed" signal, the context reset interface of the knowledge base query component is called to reset the historical state of the knowledge base query, and the business processing query interface in the business processing component is called to perform text matching. If the second response text is "retrieval failed", the intent of the dialogue is confirmed as a general chat. The chat history query interface in the chat component is called to obtain a third response text as the output text, and the progress reset interface of the business processing component and the context reset interface of the knowledge base query component are called.

[0044] On the other hand, the present invention also provides a multi-scenario, multi-turn dialogue method for virtual customer service. This method is based on the aforementioned multi-scenario, multi-turn dialogue system for virtual customer service and includes the following steps:

[0045] Step 1: Receive the user's query text or voice input. If the input is voice, proceed to Step 2; otherwise, proceed to Step 3.

[0046] Step 2: Use a speech-to-text algorithm to parse the query speech into query text;

[0047] Step 3: Using the query text as input, call the query interface of the business processing component to obtain the first response text; if the first response text is not a "failure" signal, confirm that the intention of this round of dialogue is business processing, temporarily store the first response text as the output text, call the context reset interface of the knowledge base query component, call the chat history reset interface of the chat component, and execute step 6; otherwise, execute step 4.

[0048] Step 4: Using the query text as input, call the query interface of the knowledge base query component to obtain the second response text; if the second response text is not a "match failed" or "retrieval failed" signal, then confirm that the intent of this round of dialogue is a knowledge base query, and temporarily store the second response text as the output text; call the progress reset interface of the business processing component, call the chat history reset interface of the chat component, and execute Step 6; if the second response text is a "match failed" signal, it means that the intent of the previous round of dialogue was a knowledge base query, but the query progress of this round does not match the previous round, then call the context reset interface of the knowledge base query component to reset the historical state of the knowledge base query, and then execute Step 3; if the second response text is a "retrieval failed" signal, it means that the query text does not match the knowledge base entry, then confirm that the intent of this round of dialogue is not a knowledge base query, and execute Step 5;

[0049] Step 5: Confirm that the intent of this round of dialogue is general chat. Take the query text as input, call the query interface of the chat component, obtain the third response text as the output text and store it temporarily; call the progress reset interface of the business processing component, call the context reset interface of the knowledge base query component, and execute step 6.

[0050] Step 6: If the user input is text, return the temporarily stored output text to the user; otherwise, use a text-to-speech algorithm to synthesize the output text into audio and return it to the user.

[0051] The beneficial effects of this invention are as follows: The multi-scenario, multi-turn dialogue method for virtual customer service proposed in this invention provides multi-turn dialogue capabilities for three different scenarios: business processing, knowledge base query, and casual conversation. Through an overall scenario dialogue scheduling and method and three independent scenario dialogue methods, it intelligently identifies user semantics and switches between different scenario contexts to complete the dialogue. The scenario switching does not require external signal intervention but is intelligently judged and implemented in each round of dialogue with the user. The judgment is based on the semantic similarity between user input and scenario text entries in multi-turn dialogues, rather than simple intent classification based on keywords, thus achieving high accuracy. Furthermore, this invention realizes a complete dialogue function from user input information to the return of response text, without relying on an external dialogue system.

[0052] In summary, the method proposed in this invention solves, to some extent, the problems of external intervention and dialogue fragmentation when virtual customer service switches between different dialogue scenarios, and further promotes the development of virtual digital humans in terms of anthropomorphism and interactive capabilities. Attached Figure Description

[0053] Figure 1 This is a schematic diagram of components for a multi-scenario, multi-turn dialogue system for virtual customer service according to an embodiment of the present invention;

[0054] Figure 2 This is a schematic diagram of the business processing route according to an embodiment of the present invention;

[0055] Figure 3 This is a schematic diagram of the knowledge base query dialogue process according to an embodiment of the present invention;

[0056] Figure 4 This is a schematic diagram of a casual conversation flow according to an embodiment of the present invention;

[0057] Figure 5 This is a schematic diagram of a multi-scenario dialogue scheduling process according to an embodiment of the present invention. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0059] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0060] In the description of this application, the term "for example" is used to mean "used as an example, illustration, or description." Any embodiment described as "for example" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that the invention can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of the invention with unnecessary detail. Therefore, the invention is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0061] Example 1

[0062] Figure 1 As one embodiment of the present invention, a multi-scenario, multi-turn dialogue system for virtual customer service is provided. This system supports three dialogue scenarios: business processing, knowledge base query, and casual conversation. It can automatically identify the user's intent based on input and switch between the three scenarios, providing responses accordingly. Specifically, the business processing scenario refers to the process where the user selects from various preset business processing routes to move forward, backward, jump, or exit between different business processing steps; the knowledge base query refers to the process where the user retrieves the content corresponding to a specific entry from a database containing knowledge entries and content; and the casual conversation scenario refers to a dialogue process where the user engages in aimless chatting, without business-related queries or specific content retrieval.

[0063] like Figure 1 As shown, the system 10 includes: a dialogue scheduling component 100, a business processing component 200, a knowledge base query component 300, and a chat component 400.

[0064] The system comprises the following components: Dialogue Scheduling Component 100 receives each round of dialogue input from the user, calls the dialogue components for each scenario according to a specific method, obtains the output text, and returns it to the user. Business Processing Component 200 is responsible for executing business processing dialogue methods. It maintains all business rule processing routes and records the current business processing progress, and additionally interfaces with an external real business system to execute business logic. Knowledge Base Query Component 300 handles general knowledge retrieval dialogues that are not related to business processing. It maintains a knowledge base and manages a context logger to track query progress. Chat Component 400 handles more general chat-type dialogues that are neither related to business processing nor content retrieval. It maintains the historical conversation content of the current multi-round chat.

[0065] like Figure 1As shown, the operation of system 10 in this embodiment also depends on two external components, namely the business system and the pre-trained model.

[0066] The business system is a real business operation environment used to actually execute business logic. It is independent of the multi-scenario, multi-turn dialogue system of this patent and is only used as an example in this embodiment when the dialogue system is used to execute actual business. The business processing component 200 interfaces with the business system to perform business processing outside the dialogue layer. Preferably, the interface between the business processing component 200 and the business system can occur at each dialogue node, submitting information to the business system and obtaining return values ​​when needed. Alternatively, the business processing component 200 can collect sufficient business processing information during the dialogue process and submit it to the business system all at once to obtain return values.

[0067] The pre-trained models are arbitrary neural network models used for text feature extraction and casual conversation. They are unrelated to the core functions of the multi-scenario multi-turn dialogue method and system proposed in this invention and have a certain degree of arbitrariness. This invention does not limit the specific business environment and pre-trained models used.

[0068] Preferably, the business processing component 200 includes a business processing line, a progress recorder, a business processing query interface, and a progress reset interface.

[0069] The aforementioned business processing line refers to a linear data structure composed of nodes of business processing steps arranged sequentially, supporting single or multiple business processing lines. Each node is responsible for handling one round of dialogue. The node first returns a pre-set corpus, the user replies based on the corpus, and the node checks the reply and determines the node jump information. Each node includes at least the pre-set corpus for entering the node, information pointing to the next node, and the method for processing the user's reply. For nodes that require step jump based on the reply information, they also include special trigger text and the jump node, response text, or exit information after triggering. For any node, if the node does not have trigger text or the user's reply does not trigger special text, then proceed to the next node.

[0070] The progress recorder is a variable used to record the current node position, including the current line and the node position of that line. Initially, the recorder points to a special initial node, which does not contain pre-set corpus or next node information, but uses the first node of each business processing line as the jump node and its business description as the trigger text. When the user input text does not match any trigger text, a "match failed" signal is returned.

[0071] The business processing query interface is used to execute a single-round business processing dialogue; it sends user input to the node pointed to by the current progress recorder. If the node returns a "failure" signal, the progress recorder remains unchanged and returns a "failure" signal and the reason for the error. Otherwise, it returns a response text and points the progress recorder to a new node according to the rules of that node.

[0072] The progress reset interface is used to reset the progress recorder and point it to the initial node.

[0073] Preferably, the knowledge base query component 300 includes a knowledge base module, a retrieval context module, a knowledge base query interface, and a context reset interface.

[0074] The knowledge base module includes one or more directed acyclic tree structures, which consist of knowledge tags and knowledge content; the root node is a first-level knowledge tag, the intermediate nodes are nested multi-level tags, and the leaf nodes are the final knowledge content. Each node contains at least the knowledge tag text or knowledge content text represented by that node.

[0075] The retrieval context module contains a list of sub-tags of the current retrieval node and the position index of each sub-tag. Initially, or when the retrieval node is a leaf node, the retrieval context module is empty.

[0076] The knowledge base query interface is used to execute a single-round knowledge base query dialogue. It does not need to start from the first-level tags in sequence; it can directly retrieve any knowledge tag from non-leaf nodes. The retrieval method is as follows: If the retrieval context is not empty, calculate the similarity between the input text and the retrieval context; if the highest similarity is greater than a first preset threshold, return the sub-tags or knowledge content of the sub-tag with the highest similarity, and update the retrieval context; otherwise, return a "matching failure" signal. If the retrieval context is empty, calculate the similarity between the input text and all knowledge tags; if the highest similarity is greater than a second preset threshold, return the sub-tags or knowledge content of the knowledge tag corresponding to the highest similarity, and update the retrieval context; otherwise, return a "retrieval failure" signal.

[0077] The context reset interface is used to reset the retrieval context module to empty.

[0078] Preferably, the chat component 400 includes: a multi-turn dialogue chat model, a historical chat history module, a chat history query interface, and a chat history reset interface;

[0079] The multi-turn chat model is a generative Seq2Seq neural network model that takes historical chat records and the query text of the current turn as input and outputs the chat response text of the current turn.

[0080] The historical chat history module is used to record query text and response text within a certain number of historical rounds. The number of historical rounds can be finite or infinite. Initially, the historical chat history module is empty.

[0081] The chat history query interface is used to execute a single-turn chat dialogue; its chat method is as follows: the historical chat history and the query text are concatenated and then forwarded through a multi-turn dialogue chat model, and the result is returned to the model output.

[0082] The chat history reset interface is used to reset the historical chat history module to empty.

[0083] Preferably, the dialogue scheduling component 100 includes:

[0084] The information receiving module is used to receive user-input query text or query voice.

[0085] The conversion module is used to parse the input query speech into query text using a speech-to-text algorithm;

[0086] The scheduling and response module is used to implement dialogue scheduling and response between the three scenarios;

[0087] The output module is used to return the output text to the user.

[0088] Specifically, the scheduling response module takes the query text as input, calls the business processing query interface in the business processing component to perform text matching, and obtains the first response text based on the matching result. If the first response text is not a "matching failure" signal, the dialogue intent is confirmed to be business processing, the first response text is taken as the output text, and the context reset interface of the knowledge base query component and the chat history reset interface of the chat component are called. Otherwise, the knowledge base query interface in the knowledge base query component is called to perform text matching.

[0089] The knowledge base query component obtains a second response text based on the matching result. If the second response text is not "match failed" or "retrieval failed", the intent of the dialogue is confirmed as a knowledge base query. The second response text is used as the output text, and the progress reset interface of the business processing component and the chat history reset interface of the chat component are called. If the second response text is a "match failed" signal, the context reset interface of the knowledge base query component is called to reset the historical state of the knowledge base query, and the business processing query interface in the business processing component is called to perform text matching. If the second response text is "retrieval failed", the intent of the dialogue is confirmed as a general chat. The chat history query interface in the chat component is called to obtain a third response text as the output text, and the progress reset interface of the business processing component and the context reset interface of the knowledge base query component are called.

[0090] According to this embodiment, during each round of dialogue, system 10 receives a piece of input text from the user, then outputs a response text. The user then uses the response text to organize a second round of text as input, and this process repeats. After processing the current round, system 10 waits for the user to input the next piece of text until the system closes. It should be noted that the input and output formats listed here are designed to illustrate the main working principle of this system. The user's original input can also be any form that can be converted into text, such as speech. The output text can also be presented to the user for a second round of dialogue through speech synthesis, action generation, or other methods. This invention does not limit the source data format for the system's interaction with the user.

[0091] Example 2

[0092] In this embodiment, a business processing dialogue method is provided, which can be executed by the business processing component 200. This embodiment takes a telecommunications service processing scenario of a telecommunications operator as an example, providing two services: pre-printing invoices and fund arrival verification. The text matching method used is exact matching. Figure 2 A schematic diagram of the business processing route in this embodiment is shown.

[0093] according to Figure 2 As shown, the execution logic of each node in the business processing dialogue process of this embodiment is explained as follows (the following steps are all executed by the business processing component 200):

[0094] Initial node. Determine if the input text matches the trigger text. If it matches "pre-printing service", point the progress logger to business A - step 1; if it matches "funds arrival and verification service", point the progress logger to business B - step 1. Otherwise, return "match failed".

[0095] Business A - Step 1. Return the message "Please enter the contract number". After the user replies, point the progress logger to Business A - Step 2.

[0096] Business A - Step 2. Return the message "Please enter the payment period" to the corpus. After the user replies, point the progress logger to Business A - Step 3.

[0097] Business A - Step 3. Return the message "Please confirm that the contract number and payment period are correct". If the user's reply matches "incorrect" or "incorrect", point the progress logger to Business A - Step 1; otherwise, point it to Business A - Step 4.

[0098] Business A - Step 4. Return the corpus "Pre-ticket printing service started", call the business system, return the execution result of the business system, and point the progress recorder to the initial node.

[0099] Business B - Step 1. Return the corpus to "Confirm receipt and reimbursement of start-up funds?". If the user replies "No", point the progress logger to the initial node; otherwise, point it to Business B - Step 2.

[0100] Business B - Step 2. Return the corpus to "Task started", call the business system, return the execution result of the business system, and point the progress recorder to the initial node.

[0101] Example 3

[0102] In this embodiment, a knowledge base query dialog method is provided, such as... Figure 3 As shown, this method can be executed by the knowledge base query component 300.

[0103] according to Figure 3 As shown, the specific process of the knowledge base query dialogue in this embodiment is as follows.

[0104] Step S101: Initialize the knowledge base.

[0105] Record No. k Knowledge Tree, the first l The first layer i The knowledge tags or knowledge content text of each node are .in , , , K For the number of knowledge trees, For the first k The maximum number of levels in a knowledge tree. For the first k Tree No. l The number of sibling knowledge tags in a layer, when it is a leaf node. .

[0106] Extract using BERT model The eigenvectors of are denoted as . BERT is a neural network pre-trained on a large-scale corpus using a language model. It can map a text string into a real-valued feature vector. , h This refers to the hidden layer dimension in BERT. Note that the BERT pre-trained model is an external component in <Example 1> above. Using the BERT pre-trained model to extract text feature vectors is merely a text featureization method for calculating text similarity. This invention does not limit the text similarity metrics and specific calculation methods for knowledge base queries.

[0107] The initial retrieval context for knowledge base queries is as follows: .

[0108] Cosine similarity is used as a metric for text similarity. The cosine similarity threshold is set to... .

[0109] Step S102: Input text BERT is used to extract its feature vector as .

[0110] Step S103: If the search context Empty, set the feature to be matched as Otherwise, set the feature to be matched to .

[0111] Step S104: Calculate the cosine similarity between the input text and the features to be matched, and find the maximum similarity value. Its corresponding knowledge base node :

[0112]

[0113]

[0114]

[0115]

[0116]

[0117] Step S105: If If the above steps are not executed, proceed to step S106; otherwise, proceed to step S109.

[0118] Step S106: If (i.e., leaf nodes), proceed to step S107; otherwise, proceed to step S108.

[0119] Step S107: Reset the search context Return to knowledge content .

[0120] Step S108: Set the search context to , Return all knowledge titles of the sub-level. , .

[0121] Step S109: If the search context If empty, return a "match failed" signal; otherwise, return a "retrieval failed" signal.

[0122] The above-described process examples are for a single-turn query dialogue, where the user inputs query text, and the knowledge base query component 300 returns a response text through the aforementioned dialogue method. In actual use, the knowledge base initialization step S101 will only be executed once at the very beginning.

[0123] Example 4

[0124] In this embodiment, a casual conversation method is provided, such as... Figure 4 As shown, this method can be executed by the chat component 400.

[0125] As an example, this embodiment uses a NEZHA-based generative multi-turn dialogue model, which has been trained on a large-scale chatter corpus. Note that the trained generative multi-turn dialogue model is an external component in the above-described <System Embodiment>, and this invention does not limit the specific chatter algorithm model used.

[0126] according to Figure 4 As shown, the specific process of the casual conversation method in this embodiment is as follows.

[0127] Step S201: Initialize chat history.

[0128] Step S202: Accept the dialogue text input by the user.

[0129] Step S203: Concatenate the chat history with the input text, using the special string "[SEP]" as the separator.

[0130] Step S204: Input the concatenated text into the generative dialogue model to obtain the output text.

[0131] Step S205: Append the input text and output text to the end of the chat history.

[0132] Step S206: Return the output text.

[0133] The above examples are for single-round casual conversations. In actual use, the chat history initialization step S201 will only be executed once at the very beginning.

[0134] Example 5

[0135] The above-described <Examples 2>, <Examples 3>, and <Examples 4> propose implementation methods applicable to dialogue in various scenarios. To combine and connect these dialogue methods according to the present invention, this embodiment provides a multi-scenario, multi-turn dialogue scheduling method, such as... Figure 5 As shown, this is used to integrate the scene dialogue methods proposed in the above three embodiments to realize the core logic of dialogue intent recognition and scene switching.

[0136] The multi-scenario, multi-turn dialogue scheduling method proposed in this embodiment does not rely on other intent recognition or classification algorithms besides the business processing dialogue method, knowledge base query dialogue method, and casual conversation dialogue method for intent recognition and scene switching. Instead, it calls each method sequentially based on the fact that the clarity of purpose gradually decreases among business processing, knowledge base query, and casual conversation. If a certain scenario dialogue method successfully identifies the intent, it is considered that the intent of that turn of dialogue belongs to that scenario; otherwise, the dialogue scheduling method submits the input text to the next scenario dialogue method. Until finally, if the intent of that turn of dialogue is neither business processing nor knowledge base query, it is input into the chat component according to the scenario with the weakest purpose (i.e., general aimless dialogue), and the response statement for casual conversation is returned.

[0137] This method can be executed by the dialogue scheduling component 100. According to... Figure 5 As shown, the specific process of the multi-scenario, multi-turn dialogue scheduling method in this embodiment is as follows.

[0138] Step S301: Initialize the business processing component, knowledge base query component, and chat component.

[0139] Step S302: Receive text or voice input from the user.

[0140] Step S303: If the input is speech, use a speech-to-text algorithm to parse the user's speech into text.

[0141] Step S304: Input the text into the business processing component query interface to obtain the business processing output.

[0142] Step S305: If the business processing output is "Matching Failed", proceed to step S307; otherwise, proceed to step S306.

[0143] Step S306: Temporarily store the query output of the business processing component. Call the knowledge base query component to retrieve the context reset interface, and call the chat component's historical chat record reset interface.

[0144] Here, when the business processing component returns a value other than "match failed," it means that the business processing component considers the user's dialogue intent to be business processing. The dialogue scheduling component resets the historical state of the knowledge base query (retrieval context) and the historical state of the chat (historical chat history) to clear the historical information of other dialogue scenarios after confirming entry into a certain dialogue scenario. As an optional implementation method, if it is desired to temporarily store the dialogue state of a certain scenario and restore the dialogue progress when entering that scenario again, the historical information does not need to be reset.

[0145] Step S307: Input the dialogue text into the knowledge base query interface to obtain the knowledge base output.

[0146] Step S308: If the knowledge base output is "retrieval failed", proceed to step S309; ​​otherwise, proceed to step S310.

[0147] Step S309: Call the knowledge base query component to retrieve the context reset interface, and then execute step S304.

[0148] Here, when the knowledge base query component returns a "retrieval failed" signal, it means the knowledge base is in the process of being queried, and the user's previous input matched a knowledge tag at an intermediate level. This knowledge tag contains a series of sub-tags, which need to be selected by the user in this round of input. "Retrieval failed" means that the text information entered by the user was not matched in the current retrieval context. Therefore, the user's intention in this round of input is likely to switch to a new dialogue scenario or to jump out of the existing knowledge base query path to search for a new knowledge tag. Therefore, the dialogue scheduling component resets the knowledge base retrieval context information and re-executes step S304 from the beginning. Since the knowledge base retrieval context has been reset, this step S309 will not be repeated in the new iteration, thus avoiding an infinite loop.

[0149] Step S310: If the knowledge base output is not "match failed", proceed to step S311; otherwise, proceed to step S312.

[0150] Step S311: Temporarily store the knowledge base output text. If the output is a list of knowledge tags, it is preferable to use a pre-set corpus to organize them according to certain rules, such as "Please select the sub-tag you want to query:...", to prompt the user for the next level of knowledge tag information.

[0151] Step S312: Input the dialogue text into the chat component query interface to obtain the chat output, and temporarily store the chat output text.

[0152] Step S313: If the input of the dialogue is speech, use a speech synthesis algorithm to convert the temporarily stored output text into speech as the final output; otherwise, use text as the final output.

[0153] Step S314: Return the final output to the user and wait for the next round of input.

[0154] The multi-scenario, multi-turn dialogue method and system for virtual customer service proposed in this invention enables virtual customer service robots to flexibly switch between different dialogue scenarios. The switching is automatically detected by the dialogue content during each round of natural dialogue without external intervention, solving problems such as dialogue fragmentation and further promoting the development of virtual digital humans in terms of anthropomorphism and interactive capabilities.

[0155] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0156] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A multi-scenario, multi-turn dialogue system for virtual customer service, wherein the multiple scenarios include business processing scenarios, knowledge base query scenarios, and casual conversation scenarios, characterized in that, This includes a dialogue scheduling component, a business processing component, a knowledge base query component, and a chat component; The dialogue scheduling component is used to manage the running order and calling relationship of dialogue components in each scenario, and provides an interface for interaction with the outside world; in each round of dialogue, it receives text or voice input from the outside world, processes it and returns the response text or voice, and waits for the next input; The business processing component is used to handle business processing-related dialogues, maintain all business rule processing paths, and record the current business processing progress. The knowledge base query component is used to process general knowledge retrieval dialogues that are not business processing types, maintain the knowledge base and manage a context recorder to track the query progress. The chat component is used to handle chat-type dialogues that are neither related to business processing nor content retrieval, and to maintain the historical conversation content of the current multi-turn chat. The business processing components include a business processing line, a progress recorder, a business processing query interface, and a progress reset interface; The business processing line includes a linear data structure composed of nodes of business processing steps arranged in sequence, supporting single or multiple business processing lines; each node contains at least the pre-set data entering the node, information pointing to the next node, and a method for processing user responses; each node is responsible for processing one round of dialogue. The node first returns a pre-set data, the user responds based on the pre-set data, and the node checks the user's response information and determines the node jump information. The progress recorder is a variable used to record the current node position, including the current line and the node position of that line; initially, the progress recorder points to an initial node; the initial node does not contain preset corpus and next node information, and uses the first node of each business processing line as the jump node, and uses the business description of each business processing line as the trigger text. The business processing query interface is used to execute a single-round business processing dialogue; it sends user input to the node pointed to by the current progress recorder, and the node returns a response text and points the progress recorder to a new node according to the node's rules; The progress reset interface is used to reset the progress recorder and point it to the initial node.

2. The multi-scenario, multi-turn dialogue system for virtual customer service according to claim 1, characterized in that, The dialogue scheduling component includes: The information receiving module is used to receive user-input query text or query voice. The conversion module is used to parse the input query speech into query text using a speech-to-text algorithm; The scheduling response module is used to take the query text as input, sequentially call the business processing component, knowledge base query component and chat component to match the query text, obtain the corresponding response text as output text, and confirm the dialogue intent; The output module is used to return the output text to the user.

3. The multi-scenario, multi-turn dialogue system for virtual customer service according to claim 1, characterized in that, The service processing route also includes special jump nodes, which contain special trigger text and the jump node, response text or exit information after triggering.

4. The multi-scenario, multi-turn dialogue system for virtual customer service according to claim 3, characterized in that, The node examines the user's reply and determines the node redirection information, including: After receiving a user's reply, the node determines whether it contains special trigger text. If it does, the node matches the user's reply with the special trigger text. If the match fails or the node does not contain special trigger text, the node proceeds to the next node. If the match succeeds, the node jumps to the trigger-related jump node it contains.

5. The multi-scenario, multi-turn dialogue system for virtual customer service according to claim 1, characterized in that, The knowledge base query component includes a knowledge base module, a retrieval context module, a knowledge base query interface, and a context reset interface; The knowledge base module includes one or more directed acyclic tree structures, which consist of knowledge tags and knowledge content; the root node is a first-level knowledge tag, the intermediate nodes are nested multi-level tags, and the leaf nodes are the final knowledge content. Each node contains at least the knowledge tag text or knowledge content text represented by that node. The retrieval context module contains a list of sub-tags of the current retrieval node and the position index of each sub-tag. Initially, or when the retrieval node is a leaf node, the retrieval context module is empty. The knowledge base query interface is used to execute a single-round knowledge base query dialogue; During the query, any knowledge tag of a non-leaf node can be retrieved directly; The context reset interface is used to reset the retrieval context module to empty.

6. The multi-scenario, multi-turn dialogue system for virtual customer service according to claim 5, characterized in that, When executing a single-round knowledge base query dialogue, the knowledge base query interface performs the following operations: Obtain the user's query text and determine if the retrieval context module is empty; If the retrieval context module is not empty, calculate the similarity between the query text and the retrieval context; if the highest similarity is greater than the first preset threshold, return the sub-tags or knowledge content of the sub-tag with the highest similarity and update the retrieval context module; otherwise, return a "matching failure" signal. If the retrieval context module is empty, calculate the similarity between the query text and all knowledge tags; if the highest similarity is greater than the second preset threshold, return the sub-tags or knowledge content of the knowledge tag corresponding to the highest similarity, and update the retrieval context module. Otherwise, return a "retrieval failed" signal.

7. The multi-scenario, multi-turn dialogue system for virtual customer service according to claim 5, characterized in that, The chat component includes: a multi-turn dialogue chat model, a historical chat history module, a chat history query interface, and a chat history reset interface; The multi-turn chat model is a generative Seq2Seq neural network model that takes historical chat records and the query text of the current turn as input and outputs the chat response text of the current turn. The historical chat history module is used to record query text and response text within a certain number of historical rounds. The number of historical rounds can be finite or infinite. Initially, the historical chat history module is empty. The chat history query interface is used to execute a single-turn chat dialogue; its chat method is as follows: the historical chat history and the query text are concatenated and then forwarded through a multi-turn dialogue chat model, and the result is returned to the model output. The chat history reset interface is used to reset the historical chat history module to empty.

8. The multi-scenario, multi-turn dialogue system for virtual customer service according to claim 7, characterized in that, The scheduling response module in the dialogue scheduling component is specifically used for: The query text is used as input, and the business processing query interface in the business processing component is called to perform text matching. The first response text is obtained according to the matching result. If the first response text is not a "matching failure" signal, the dialogue intent is confirmed to be business processing. The first response text is used as the output text, and the context reset interface of the knowledge base query component and the chat history reset interface of the chat component are called. Otherwise, the knowledge base query interface in the knowledge base query component is called to perform text matching. The knowledge base query component obtains a second response text based on the matching result. If the second response text is not "match failed" or "retrieval failed", the intent of the dialogue is confirmed as a knowledge base query. The second response text is used as the output text, and the progress reset interface of the business processing component and the chat history reset interface of the chat component are called. If the second response text is a "match failed" signal, the context reset interface of the knowledge base query component is called to reset the historical state of the knowledge base query, and the business processing query interface in the business processing component is called to perform text matching. If the second response text is "retrieval failed", the intent of the dialogue is confirmed as a general chat. The chat history query interface in the chat component is called to obtain a third response text as the output text, and the progress reset interface of the business processing component and the context reset interface of the knowledge base query component are called.

9. A multi-scenario, multi-turn dialogue method for virtual customer service, the method being implemented based on a multi-scenario, multi-turn dialogue system for virtual customer service as described in any one of claims 1-8, characterized in that, Includes the following steps: Step 1: Receive the user's query text or voice input. If the input is voice, proceed to Step 2; otherwise, proceed to Step 3. Step 2: Use a speech-to-text algorithm to parse the query speech into query text; Step 3: Using the query text as input, call the query interface of the business processing component to obtain the first response text; If the first response text is not a "failure" signal, confirm that the intent of this round of dialogue is business processing, temporarily store the first response text as the output text, call the context reset interface of the knowledge base query component, call the chat history reset interface of the chat component, and execute step 6. Otherwise, proceed to step 4; Step 4: Using the query text as input, call the query interface of the knowledge base query component to obtain the second response text; If the second response text is not a "match failed" or "retrieval failed" signal, then the intent of this round of dialogue is confirmed to be a knowledge base query, and the second response text is temporarily stored as the output text; the progress reset interface of the business processing component is called, and the chat history reset interface of the chat component is called, and step 6 is executed; if the second response text is a "match failed" signal, it means that the intent of the previous round of dialogue was a knowledge base query, but the query progress of this round does not match the previous round, then the context reset interface of the knowledge base query component is called to reset the historical state of the knowledge base query, and then step 3 is executed; if the second response text is a "retrieval failed" signal, it means that the query text does not match the knowledge base entry, then the intent of this round of dialogue is confirmed not to be a knowledge base query, and step 5 is executed; Step 5: Confirm that the intent of this round of dialogue is general chat. Take the query text as input, call the query interface of the chat component, obtain the third response text as the output text and store it temporarily; call the progress reset interface of the business processing component, call the context reset interface of the knowledge base query component, and execute step 6. Step 6: If the user input is text, return the temporarily stored output text to the user; otherwise, use a text-to-speech algorithm to synthesize the output text into audio and return it to the user.

Images