Improved technique for out-of-domain (OOD) detection

The method improves chatbot OOD detection using clustering and metric-based techniques, enhancing user interaction and simplifying development by accurately classifying utterances as in-domain or out-of-domain.

JP2025122001AActive Publication Date: 2025-08-20ORACLE INT CORP
View PDF 8 Cites 0 Cited by

Patent Information

Application Number
JP2025078489
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2020-03-30
Filing Date
2025-05-09
Publication Date
2025-08-20
Estimated Expiration
2041-03-30

AI Technical Summary

Technical Problem

Existing chatbots struggle to identify out-of-domain (OOD) utterances accurately, leading to suboptimal user interactions and increased development complexity due to the need for specialized knowledge and iterative model training.

Method used

A method using clustering and metric-based techniques to detect OOD utterances, involving sentence embeddings, metric learning models, and outlier detection algorithms to classify utterances as in-domain or out-of-domain based on similarity and distance deviations.

Benefits of technology

Enhances chatbot performance by accurately identifying OOD utterances, improving user interaction and reducing development complexity through automated OOD detection.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025122001000001_ABST
    Figure 2025122001000001_ABST
Patent Text Reader

Abstract

To provide a method, system and program for identifying out-of-domain utterances.SOLUTION: A method includes: receiving an utterance and a target domain of a chatbot; generating a sentence embedding for the utterance; obtaining an embedding representation for each cluster of in-domain utterances associated with the target domain; predicting, using a metric learning model, a first probability that the utterance belongs to the target domain, based on a similarity or difference between the sentence embedding and each embedding representation for each cluster; predicting, using an outlier detection model, a second probability that the utterance belongs to the target domain, based on a determined distance or density deviation between the sentence embedding and embedding representations for neighboring clusters; and classifying the utterance as in-domain or out-of-domain based on a final probability determined by evaluating the first probability and the second probability.SELECTED DRAWING: Figure 5
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] Priority claim This application is a direct application of and claims the benefit of and priority to U.S. Provisional Application No. 63 / 002,139, filed March 30, 2021. The entire contents of the above application are incorporated herein by reference for all purposes.

[0002] FIELD OF THE INVENTION The present disclosure relates generally to chatbot systems, and more particularly to improved techniques for identifying out-of-domain (OOD) utterances. [Background technology]

[0003] background Many users around the world are on instant messaging or chat platforms to get immediate responses. Organizations often use these instant messaging or chat platforms to have live conversations with customers (or end users). However, it can be very expensive for organizations to utilize service representatives to communicate live with customers or end users. Chatbots, or bots, have begun to be developed to simulate conversations with end users, especially over the internet. End users can communicate with bots through messaging apps that the end users already have installed and using. Intelligent bots, generally enabled by artificial intelligence (AI), are smarter and more contextual in their live conversations, enabling a more natural conversation between the bot and the end user, improving the conversational experience. Instead of end users learning a fixed set of keywords or commands that the bot knows how to respond to, intelligent bots can understand the end user's intent based on the user's utterances in natural language and respond accordingly.

[0004] However, chatbots are difficult to build because these automated solutions require specialized knowledge in specific domains and the application of specific techniques that may be entirely within the capabilities of specialized developers. As part of building such a chatbot, a developer may first understand the needs of the enterprise and end users. The developer may then perform analysis and decisions related to, for example, selecting a dataset to be used for analysis, processing this input dataset in preparation for analysis (e.g., cleansing the data, extracting, formatting, and / or transforming the data before analysis, performing data feature engineering, etc.), identifying an appropriate machine learning (ML) technique or model to perform the analysis, and refining this technique or model to improve results / outcomes based on feedback. The task of identifying an appropriate model may involve developing multiple models, possibly in parallel, and iteratively testing and experimenting with these models before identifying the specific model(s) to be used. Furthermore, supervised learning-based solutions generally include a training phase followed by an application (i.e., inference) phase and an iterative loop between the training and application phases. The developer will be responsible for carefully executing and monitoring these phases to achieve an optimal solution. For example, to train an ML technique or model, accurate training data is required to enable the algorithm to understand and learn specific patterns or features (e.g., in a chatbot, intent extraction and careful syntactic parsing, rather than just raw language processing) that the ML technique or model uses to predict a desired outcome (e.g., inferring intent from an utterance). Summary of the Invention [Means for solving the problem]

[0005] Quick Overview The technology disclosed herein relates generally to chatbots. More specifically, but not exclusively, the technology disclosed herein relates to improved techniques for identifying OOD utterances. A chatbot (also referred to as a bot) includes an OOD detector that uses one or more algorithms to determine whether an utterance provided to the bot is not within the bot's (e.g., skillbot's) domain. When such an OOD utterance is detected, the bot can respond with an appropriate response, such as a message that enables the user to identify that the utterance is not something the bot can process or address. In certain embodiments, techniques using various clustering-based and metric-based algorithms and combinations thereof are used for OOD detection.

[0006] In various embodiments, a method is provided, the method comprising receiving an utterance and a target domain of a chatbot; generating sentence embeddings for the utterance; and obtaining an embedding for each cluster of a plurality of clusters of in-domain utterances associated with the target domain, the embedding for each cluster being an average of sentence embeddings for each in-domain utterance in the cluster; the method further comprises inputting the sentence embeddings for the utterance and the embeddings for each cluster into a metric learning model, the metric learning model having trained model parameters configured to provide a first probability as to whether the utterance belongs to the target domain; the method further comprises using the metric learning model to determine similarities or differences between the sentence embeddings for the utterance and each embedding for each cluster; and using the metric learning model to determine similarities or differences between the sentence embeddings for the utterance and each embedding for each cluster. and inputting the sentence embeddings for the utterance and the embeddings for each cluster into an outlier detection model, the outlier detection model being constructed with a distance or density algorithm for outlier detection, wherein the method further comprises using the outlier detection model to determine a distance or density deviation between the sentence embeddings for the utterance and the embeddings for adjacent clusters, using the outlier detection model to predict the second probability as to whether the utterance belongs to the target domain based on the determined distance or density deviation, evaluating the first probability and the second probability to determine a final probability as to whether the utterance belongs to the target domain, and classifying the utterance as being in-domain or out-of-domain for the chatbot based on the final probability.

[0007] In some embodiments, obtaining the embedded representations for each cluster comprises obtaining in-domain utterances based on the target domain; generating sentence embeddings for each in-domain utterance; and inputting the sentence embeddings for each in-domain utterance into an unsupervised clustering model, wherein the unsupervised clustering model is configured to interpret the in-domain utterances to identify the plurality of clusters in the feature space of the in-domain utterances; and obtaining the embedded representations for each cluster further comprises using the unsupervised clustering model to classify the sentence embeddings for each in-domain utterance into one of the plurality of clusters based on similarities and differences between features of the sentence embeddings and features of sentence embeddings in each cluster; and calculating a centroid for each cluster of the plurality of clusters. and outputting the embedded representation and the centroid for each cluster of the plurality of clusters.

[0008] In some embodiments, the method further comprises calculating a z-score for the utterance based on the distance or density deviation between the sentence embedding for the utterance and the embedding representations for the neighboring clusters, and determining the second probability of whether the utterance belongs to the target domain by applying a sigmoid function to the z-score.

[0009] In some embodiments, the sentence embedding for the utterance is generated using an embedding model that maps natural language elements, including sentences, words, and n-grams, to sequences of numbers, each of which is represented as a single point in a vector space.

[0010] In some embodiments, determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster comprises: (i) calculating an absolute difference between the sentence embedding for the utterance and each embedded representation for each cluster; and (ii) inputting the absolute difference, the sentence embedding for the utterance, and the embedded representation for each cluster into a Wide and Deep Learning Network, wherein the Wide and Deep Learning Network comprises a linear model and a deep neural network; and determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster further comprises: (iii) predicting a wide-based probability of whether the utterance belongs to the target domain using the linear model and the absolute difference; and (iv) determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster using the deep neural network, the sentence embedding for the utterance, and the embedded representation for each cluster, wherein predicting the first probability comprises evaluating the similarity or difference between the wide probability and the sentence embedding for the utterance and each embedded representation for each cluster using a final layer of the wide-and-deep learning network.

[0011] In some embodiments, the linear model comprises a plurality of model parameters trained using a set of training data, the set of training data including absolute differences between a sentence embedding for an utterance and each embedding for each cluster for in-domain utterances from a plurality of domains, and during training of the linear model with the set of training data, a hypothesis function is used to learn a linear relationship between the sentence embedding for the utterance and each embedding for each cluster, and during learning the linear relationship, the plurality of model parameters are trained to minimize a loss function.

[0012] In some embodiments, the deep learning network comprises a plurality of model parameters trained using a set of training data, the set of training data including sentence embeddings for in-domain utterances from a plurality of domains, and during training of the deep learning network with the set of training data, high-dimensional features of the sentence embeddings for the in-domain utterances are converted into low-dimensional vectors, which are then concatenated with features from the in-domain utterances and fed to a hidden layer of the deep neural network, and values of the low-dimensional vectors are randomly initialized and, together with the plurality of model parameters, learned to minimize a loss function.

[0013] In various embodiments, a computer program product is provided, said computer program product tangibly embodied in a non-transitory machine-readable storage medium, The method includes instructions configured to cause one or more data processors to perform some or all of one or more of the methods disclosed herein.

[0014] In various embodiments, a system is provided that includes one or more data processors and a non-transitory computer-readable storage medium that includes instructions that, when executed on the one or more data processors, cause the one or more data processors to perform some or all of one or more methods disclosed herein.

[0015] The techniques described above and below can be implemented in a variety of forms and in a variety of contexts. As described in more detail below, some example implementations and contexts are provided with reference to the following drawings. However, the following implementations and contexts are just a few of many. [Brief explanation of the drawings]

[0016] [Figure 1]FIG. 1 is a simplified block diagram of a distributed environment incorporating an illustrative embodiment; [Figure 2] FIG. 1 is a simplified block diagram of a computing system implementing a Masterbot, according to certain embodiments. [Figure 3] FIG. 1 is a simplified block diagram of a computing system implementing a skillbot, according to certain embodiments. [Figure 4] FIG. 1 is a simplified block diagram of a chatbot training and deployment system according to various embodiments. [Figure 5] FIG. 1 illustrates an ensemble architecture comprising a metric learning model and an outlier detection model for identifying OOD utterances, according to various embodiments. [Figure 6] FIG. 1 illustrates a process flow for identifying OOD utterances, according to various embodiments. [Figure 7] 1 is a simplified diagram of a distributed system for implementing various embodiments. [Figure 8] FIG. 1 is a simplified block diagram of one or more components of a system environment in which services provided by one or more components of an embodiment system may be offered as cloud services, according to various embodiments. [Figure 9] FIG. 1 illustrates an exemplary computer system that can be used to implement various embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0017] Detailed Description In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of particular embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. The drawings and description are not intended to be limiting. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

[0018] Introduction A digital assistant is an artificial intelligence-driven interface that helps users accomplish various tasks in natural language conversation. For each digital assistant, customers can combine one or more skills. Skills (also referred to herein as chatbots, bots, or skillbots) are individual bots that specialize in specific types of tasks, such as tracking inventory, submitting time cards, and creating expense reports. When an end user engages with a digital assistant, the digital assistant evaluates end-user input and routes conversations to and from the appropriate chatbot. Digital assistants can be made available to end users through various channels, such as Facebook® Messenger, Skype Mobile® Messenger, or Short Message Service (SMS). Channels allow chats to go back and forth between end users on various messaging platforms and the digital assistant and its various chatbots. These channels can also support user-agent escalation, event-triggered conversations, and testing.

[0019] Intents enable a chatbot to understand what a user wants it to do. Intents consist of a reordering of typical user requests and utterances (e.g., get account balance, make a purchase, etc.), also referred to as utterances. As used herein, an utterance or message refers to a set of words (e.g., one or more sentences) exchanged during a conversation with a chatbot. An intent can be created by providing a name for some user action (e.g., order a pizza) and compiling a set of real-world user utterances or utterances typically associated with triggering that action. Because the chatbot's cognition is derived from these intents, each intent can be created from a robust and diverse (one to two dozen utterances) dataset to enable the chatbot to interpret ambiguous user input. A rich set of utterances enables the chatbot to understand what the user wants when it receives messages like "Forget this order!" or "Cancel delivery!"—messages that mean the same thing but are expressed differently. Intents and their associated utterances collectively constitute the training corpus for the chatbot. By training a model with this corpus, customers essentially turn the model into a reference tool for decomposing end-user input into a single intent, allowing customers to improve the cognitive capabilities of their chatbot through multiple rounds of intent testing and intent training.

[0020] However, building a chatbot that can determine an end user's intent based on user utterances is a challenging task, due in part to the subtleties and ambiguities of natural language, the dimensions of the input space (e.g., possible user utterances), and the size of the output space (number of intents). Illustrative examples of this difficulty arise from features of natural language, such as utilizing euphemisms, synonyms, or ungrammatical speech to express intent. For example, an utterance may express the intent to order a pizza without explicitly mentioning pizza, ordering, or delivery. For example, in the local dialect of a particular region, "pizza" is referred to as "pie." These natural language tendencies, such as imprecision or variability, introduce uncertainty, and the inclusion of keywords, for example, introduces reliability as a parameter for predicting intent different from the explicit display of intent. Therefore, chatbots may need to be trained, monitored, debugged, and retrained to improve their performance and the user experience with them. In conventional systems, training systems are provided for training and retraining machine learning models for digital assistants or chatbots in Spoken Language Understanding (SLU) and Natural Language Processing (NLP). Traditionally, models used in chatbot systems are trained with NLP using "crafted" utterances for any intent. For example, an utterance of "Would you like to change the price?" can be used to train a classifier model for the chatbot system to classify this type of utterance as the intent of "Would you like to offer a price match?" Training the model with crafted utterances helps initially train the chatbot system to provide a service, after which the chatbot system is deployed and receives user feedback. It can be retrained as it starts to get real utterances from the

[0021] Traditional training of a model for text classification begins with training on a dataset of utterances labeled with a predefined list of intents (or categories, or classes). For example, a banking chatbot may be trained using predefined intents such as "open an account," "query balance," "close account," and "transfer money." These intents are generally considered to belong to the same domain (e.g., the banking domain) that the chatbot can handle. Chatbots are typically trained using training data that includes multiple examples of utterances and, for each training utterance, an intent associated with that utterance. Once training is complete, the chatbot can receive new utterances (e.g., in a real-world or production environment) and infer the intent for each utterance from the predefined intents.

[0022] However, the utterances that a chatbot receives from actual users in a real-world environment (e.g., a production environment) can be quite diverse and noisy. Some of these received utterances can be very different from the utterances used to train the chatbot and may not fall within the range of the intents the chatbot is trained to infer and address. For example, a banking chatbot may receive utterances such as "How do I book a trip to Italy?" that are unrelated to banking. Such utterances are referred to as out-of-domain (OOD) utterances because they are not within the domain of the trained chatbot's intents. It is important that the chatbot system be able to identify such OOD utterances so that it can take appropriate response actions. For example, when a chatbot detects an OOD utterance, rather than selecting the closest matching intent, the chatbot can respond to the user indicating that the utterance is not something the bot can handle or address.

[0023] Therefore, a different approach is needed to address these issues. This disclosure describes various embodiments for addressing these issues by identifying out-of-domain utterances. In various embodiments, a combination of clustering and metric-based techniques is used for OOD determination. One exemplary technique includes receiving an utterance and a target domain of a chatbot; generating sentence embeddings for the utterance; obtaining embeddings for each cluster of in-domain utterances associated with the target domain; predicting a first probability that the utterance belongs to the target domain based on similarities or differences between the sentence embeddings and each embedding for each cluster using a distance learning model; predicting a second probability that the utterance belongs to the target domain based on determined distances or density deviations between the sentence embeddings and embeddings for adjacent clusters using an outlier detection model; evaluating the first and second probabilities to determine a final probability; and classifying the utterance as in-domain or out-of-domain for the chatbot based on the final probability.

[0024] In certain embodiments, a method is provided, the method comprising: receiving an utterance and a target domain of a chatbot; generating a sentence embedding for the utterance; and obtaining an embedding representation for each cluster of a plurality of clusters of in-domain utterances associated with the target domain, the embedding representation for each cluster being an average of sentence embeddings for each in-domain utterance in the cluster; the method further comprising inputting the sentence embedding for the utterance and the embedding representation for each cluster into a metric learning model, the metric learning model configured to provide a first probability as to whether the utterance belongs to the target domain. the method further comprises using the distance learning model to determine similarities or differences between the sentence embeddings for the utterance and each embedding for each cluster; using the distance learning model to predict the first probability as to whether the utterance belongs to the target domain based on the determined similarities or differences between the sentence embeddings for the utterance and each embedding for each cluster; and inputting the sentence embeddings for the utterance and the embeddings for each cluster into an outlier detection model, wherein the outlier detection model uses a distance or density algorithm for outlier detection. the method is built on an algorithm, and further comprises using the outlier detection model to determine a distance or density deviation between the sentence embedding for the utterance and embedding representations for adjacent clusters; using the outlier detection model to predict the second probability as to whether the utterance belongs to the target domain based on the determined distance or density deviation; evaluating the first probability and the second probability to determine a final probability as to whether the utterance belongs to the target domain; and classifying the utterance as being in-domain or out-domain for the chatbot based on the final probability.

[0025] Bots and analytics systems A bot (also referred to as a skill, chatbot, chatterbot, or talkbot) is a computer program that can converse with end users. Bots can generally respond to natural language messages (e.g., questions or comments) through messaging applications that use natural language messages. Businesses can use one or more bot systems to communicate with end users through messaging applications. The messaging application, which may be referred to as a channel, may be a messaging application of the end user's choice that the end user already has installed and is familiar with. Thus, end users do not have to download and install a new application to chat with a bot system. Messaging applications may include, for example, over-the-top (OTT) messaging channels (such as Facebook Messenger, Facebook WhatsApp, WeChat, Line, Kick, Telegram, Talk, Skype, Slack, or SMS), virtual private assistants (such as Amazon Dot, Echo, or Show, Google Home, Apple HomePod), mobile and web app extensions that extend native or hybrid / responsive mobile apps or web applications with chat capabilities, or voice-based input (such as devices or apps with interfaces that use Siri, Cortana, Google Voice, or other voice input for interaction).

[0026] In some examples, a bot system may be associated with a Uniform Resource Identifier (URI). The URI may identify the bot system using a string of characters. The URI may be used as a webhook for one or more messaging application systems. The URI may include, for example, a Uniform Resource Locator (URL) or a Uniform Resource Name (URN). The bot system may be designed to receive a message (e.g., a HyperText Transfer Protocol (HTTP) post call message) from the messaging application system. The HTTP post call message may be directed to a URI from the messaging application system. In some embodiments, the message may be different from an HTTP post call message. For example, the bot system may receive a message via Short Message Service (SMS). While the description herein refers to a communication received by the bot system as a message, the message may be an HTTP post call message, an SMS message, or any other type of communication between two systems. It should be understood that this is also acceptable.

[0027] End users may interact with bot systems through conversational interactions (sometimes referred to as conversational user interfaces (UIs)), similar to human-to-human interactions. In some cases, this interaction may involve the end user saying "hello" to the bot, with the bot responding "hi" and asking the end user how they can help. In some cases, this interaction may be transaction-related, such as with a banking bot, transferring money from one account to another, information-related, such as with an HR bot, checking a vacation balance, or a retail bot, such as discussing the return of a purchase or requesting technical support.

[0028] In some embodiments, the bot system can intelligently handle end-user interactions without interaction with a bot system administrator or developer. For example, an end user may send one or more messages to the bot system to achieve a desired goal. The messages may include specific content, such as text, emojis, audio, images, video, or other methods of conveying a message. In some embodiments, the bot system may convert this content into a standardized format (e.g., a Representational State Transfer (REST) call to an enterprise service with appropriate parameters) to generate a natural language response. The bot system may also request additional input parameters from the end user or request other additional information. In some embodiments, the bot system may initiate communication with the end user rather than passively responding to end-user utterances. Various techniques are described herein for identifying explicit invocations of the bot system and determining input for the bot system being invoked. In certain embodiments, the analysis of the explicit invocation is performed by a master bot based on detecting an invocation name in the utterance. In response to detecting the invocation name, the utterance can be refined for input to a skill bot associated with the invocation name.

[0029] A conversation with a bot will follow a specific conversational flow that includes multiple states. This flow may define what happens next based on input. In some embodiments, a bot system may be implemented using a state machine that includes user-defined states (e.g., end-user intents) and actions to take at or for each state. A conversation can take different paths based on end-user input, which may affect the decisions the bot makes regarding the flow. For example, at each state, based on end-user input or utterances, the bot may determine the end-user's intent to determine the next appropriate action to take. In the context of utterances, the term "intent" as used herein refers to the intent of the user who provided the utterance. For example, a user may intend to converse with a bot to order a pizza, and thus the user's intent may be expressed by the utterance "Order me a pizza." User intent can be directed to a specific task the user wants the chatbot to perform on their behalf. Thus, utterances can be expressed as questions, commands, requests, etc. that reflect the user's intent. An intent may include a goal the end user wants to achieve.

[0030] In the context of configuring chatbots, the term "intent" is used herein to refer to configuration information for mapping user utterances to specific tasks / actions or categories of tasks / actions that the chatbot can perform. To distinguish between the intent of an utterance (i.e., user intent) and the intent of a chatbot, the latter is sometimes referred to herein as a "bot intent." A bot intent may comprise a set of one or more utterances associated with the intent. For example, For example, an intent to order a pizza may have various permutations of utterances that express the desire to order a pizza. These associated utterances can be used to train a chatbot's intent classifier so that it can later determine whether an input utterance from a user matches the pizza-ordering intent. A bot intent may be associated with one or more dialog flows for initiating a conversation with a user in a particular state. For example, the first message for a pizza-ordering intent may be the question, "What kind of pizza do you like?" In addition to the associated utterances, a bot intent may further comprise a named entity associated with the intent. For example, a pizza-ordering intent may include variables or parameters used to perform the task of ordering a pizza, such as topping 1, topping 2, type of pizza, size of pizza, quantity of pizza, etc. The value of an entity is generally obtained by conversing with a user.

[0031] FIG. 1 is a simplified block diagram of an environment 100 incorporating a chatbot system, according to certain embodiments. The environment 100 includes a Digital Assistant Builder Platform (DABP) 102, which enables users of the DABP 102 to create and deploy digital assistant or chatbot systems. The DABP 102 can be used to create one or more digital assistant (or DA) or chatbot systems. For example, as shown in FIG. 1, a user 104 representing a particular business can use the DABP 102 to create and deploy a digital assistant 106 for users of the particular business. For example, the DABP 102 may be used by a bank to create one or more digital assistants for use by its customers. The same DABP 102 platform may be used by multiple businesses to create digital assistants. As another example, a restaurant (e.g., a pizza shop) owner may use the DABP 102 to create and deploy a digital assistant that enables customers of the restaurant to order food (e.g., order pizza).

[0032] For purposes of this disclosure, a "digital assistant" is an entity that helps a user of the digital assistant accomplish various tasks through natural language conversation. A digital assistant may be implemented using software alone (e.g., a digital assistant is a digital entity implemented using programs, codes, or instructions executable by one or more processors), hardware, or a combination of hardware and software. A digital assistant may be embodied or implemented in a variety of physical systems or devices, such as a computer, a mobile phone, a watch, an appliance, or a vehicle. A digital assistant is sometimes referred to as a chatbot system. Thus, for purposes of this disclosure, the terms digital assistant and chatbot system are interchangeable.

[0033] A digital assistant, such as a digital assistant 106 built using DABP 102, can be used to perform various tasks through natural language-based conversations between the digital assistant and its user 108. As part of the conversation, the user can provide one or more user inputs 110 to the digital assistant 106 and obtain responses 112 from the digital assistant 106. A conversation can include one or more of the inputs 110 and responses 112. Through these conversations, the user requests one or more tasks to be performed by the digital assistant, and in response, the digital assistant is configured to perform the user-requested tasks and respond to the user with an appropriate response.

[0034] User input 110 is generally in the form of natural language and is referred to as an utterance. User utterance 110 may be in text form, such as when a user types a sentence, a question, a text fragment, or a single word and provides it as input to the digital assistant 106. In some embodiments, user utterance 110 may be in the form of voice input or speech, such as when a user says or speaks something and provides it as input to the digital assistant 106. Utterances are generally in the language spoken by the user 108. For example, the utterances may be in English or another language. If the utterance is in speech form, the speech input is converted into text form utterances in that particular language, and these text utterances are then processed by the digital assistant 106. Various speech-to-text processing techniques may be used to convert speech or voice input into text utterances, which are then processed by the digital assistant 106. In some embodiments, the speech-to-text conversion may be done by the digital assistant 106 itself.

[0035] The utterance, which may be a text utterance or a speech utterance, may be a fragment, a sentence, multiple sentences, one or more words, one or more questions, a combination of the above types, etc. The digital assistant 106 is configured to apply natural language understanding (NLU) techniques to the utterance to understand the meaning of the user input. As part of the NLU processing of the utterance, the digital assistant 106 is configured to perform processing to understand the meaning of the utterance, which processing includes identifying one or more intents and one or more entities corresponding to the utterance. Upon understanding the meaning of the utterance, the digital assistant 106 may perform one or more actions or operations in response to the understood meaning or intent. For purposes of this disclosure, it is assumed that the utterance is a text utterance provided directly by a user 108 of the digital assistant 106 or is the result of converting an input speech utterance into text format. However, this is not intended to be limiting or restrictive in any way.

[0036] For example, user 108 input may request to order a pizza by providing an utterance such as "I would like to order a pizza." Upon receiving such an utterance, digital assistant 106 is configured to understand the meaning of the utterance and take appropriate action. These appropriate actions may include responding to the user with a question requesting user input regarding, for example, the type of pizza the user wants to order, the size of the pizza, the pizza toppings, etc. Additionally, the responses provided by digital assistant 106 may be in natural language format and generally in the same language as the input utterance. As part of generating these responses, digital assistant 106 may perform natural language generation (NLG). If the user orders a pizza, through a conversation between the user and digital assistant 106, the digital assistant may provide all the information required to order a pizza and then guide the user to order the pizza at the end of the conversation. Digital assistant 106 may end the conversation by outputting information to the user indicating that a pizza has been ordered.

[0037] At a conceptual level, digital assistant 106 performs various processes in response to utterances received from a user. In some embodiments, this processing includes a series or pipeline of processing steps, including, for example, understanding the meaning of the input utterance (sometimes referred to as natural language understanding (NLU)), determining an action to perform in response to the utterance, executing the action as appropriate, generating a response to the user in response to the user utterance that is output to the user, and outputting the response to the user. NLU processing can include parsing the received input utterance to understand the structure and meaning of the utterance, and refining and refining the utterance to create a more understandable form (e.g., logical form) or structure of the utterance. Generating a response can include the use of NLG technology.

[0038] NLU processing performed by a digital assistant, such as digital assistant 106, may include various NLP-related processes, such as parsing sentences (e.g., tokenizing, lemmatizing, and identifying part-of-speech tags for utterances, identifying named entities in sentences, generating dependency trees to represent sentence structure, dividing sentences into clauses, parsing individual clauses, breaking down repetitions, performing chunking, etc.). In particular embodiments, the NLU processing, or portions thereof, is performed by the digital assistant 106 itself. In some other embodiments, the digital assistant 106 may use other resources to perform portions of the NLU processing. For example, the syntax and structure of an input spoken sentence may be identified by processing the sentence using a parser, a part-of-speech tagger, and / or a named entity recognizer. In one implementation, for English, a parser, a part-of-speech tagger, and a named entity recognizer, such as those provided by the Stanford Natural Language Processing (NLP) Group, are used to parse the structure and syntax of the sentence. These are provided as part of the Stanford CoreNLP Toolkit.

[0039] Although various examples provided in this disclosure show speech in English, this is intended to be exemplary only. In certain embodiments, the digital assistant 106 can also handle speech in languages other than English. The digital assistant 106 may provide subsystems (e.g., components that implement NLU functionality) configured to perform processing for various languages. These subsystems may be realized as pluggable units that can be invoked using service calls from the NLU core server. This makes NLU processing flexible and extensible for each language, including allowing for various orders of processing. Language packs may be provided for individual languages, and the language packs can register a list of subsystems that can be served from the NLU core server.

[0040] 1 may be made available or accessible to its user 108 through a variety of different channels, such as, but not limited to, through a particular application, through social media platforms, through various messaging services and applications, and other applications or channels. A single digital assistant may have several channels configured for it such that it runs on and is accessible by different services simultaneously.

[0041] A digital assistant or chatbot system typically includes or is associated with one or more skills. In particular embodiments, these skills are individual chatbots (referred to as skillbots) configured to interact with a user to perform specific types of tasks, such as tracking inventory, submitting a timecard, creating an expense report, ordering food, checking a bank account, making a reservation, or purchasing a widget. For example, in the embodiment shown in FIG. 1 , the digital assistant or chatbot system 106 includes skills 116-1, 116-2, etc. For purposes of this disclosure, the terms “skill” and “skills” are used interchangeably with the terms “skillbot” and “skillbots,” respectively.

[0042] Each skill associated with a digital assistant helps a user of the digital assistant complete a task through a conversation with the user, which may include a combination of text or voice input provided by the user and responses provided by the skill bot. These responses may be in the form of text or voice messages to the user and / or using simple user interface elements (e.g., list selections) presented to the user for the user to make a selection.

[0043] There are various ways in which skills or skillbots can be associated with or added to a digital assistant. In some cases, skillbots may be developed by a company and then added to a digital assistant using DABP 102. In other cases, skillbots may be developed and created using DABP 102 and then added to a digital assistant created using DABP 102. In still other cases, DABP 102 provides an online digital store (referred to as a "skill store") that offers multiple skills aimed at a wide range of tasks. Skills offered through the skill store may also expose various cloud services. To add a skill to a digital assistant created using DABP 102, a user of DABP 102 can access the skill store via DABP 102, select the desired skill, and indicate that the selected skill be added to the digital assistant created using DABP 102. Skills from the skill store may be added to the digital assistant as is, or may be added to the digital assistant in a modified form (e.g., a user of DABP102 may select and clone a particular skillbot provided by the skill store, make customizations or modifications to the selected skillbot, and then add the modified skillbot to a digital assistant created using DABP102).

[0044] A variety of different architectures may be used to implement a digital assistant or chatbot system. For example, in certain embodiments, a digital assistant created and deployed using DABP 102 may be implemented using a masterbot / child (or sub-)bot paradigm or architecture. According to this paradigm, a digital assistant is implemented as a masterbot that interacts with one or more childbots, which are skillbots. For example, in the embodiment shown in FIG. 1, digital assistant 106 comprises masterbot 114 and skillbots 116-1, 116-2, etc., that are childbots of masterbot 114. In certain embodiments, digital assistant 106 itself may function as the masterbot.

[0045] A digital assistant implemented according to the master-childbot architecture allows users of the digital assistant to interact with multiple skills through a unified user interface, i.e., through a masterbot. When a user engages with the digital assistant, user input is received by the masterbot. The masterbot then performs processing to determine the meaning of the user input utterance. The masterbot then determines whether the masterbot itself can handle the task requested by the user in the utterance; otherwise, the masterbot selects an appropriate skillbot to handle the user request and routes the conversation to the selected skillbot. This allows users to converse with the digital assistant through a common, single interface while still providing the ability to use several skillbots configured to perform specific tasks. For example, in a digital assistant developed for an enterprise, the digital assistant's masterbot may connect to skillbots with specific capabilities, such as a CRM bot for performing functions related to customer relationship management (CRM), an ERP bot for performing functions related to enterprise resource planning (ERP), and an HCM bot for performing functions related to human capital management (HCM). In this way, the end user or consumer of the digital assistant only needs to know how to access the digital assistant through a common masterbot interface, and behind the scenes, multiple skillbots are provided to handle user requests.

[0046] In certain embodiments, the masterbot / childbot infrastructure The masterbot is configured to be aware of a list of available skillbots. The masterbot has access to metadata identifying various available skillbots and, for each skillbot, the skillbot's capabilities, including the tasks the skillbot can perform. Upon receiving a user request in the form of an utterance, the masterbot is configured to identify or predict a specific skillbot from multiple available skillbots that can best serve or process the user request. The masterbot then routes the utterance (or a portion of the utterance) to that specific skillbot for further processing. Thus, control flows from the masterbot to the skillbot. The masterbot can support multiple input and output channels. In certain embodiments, routing may be performed with the help of processing performed by one or more available skillbots. For example, as described below, a skillbot can be trained to infer the intent of an utterance and determine whether the inferred intent matches an intent for which the skillbot is configured. Thus, routing performed by the masterbot may include the skillbot communicating to the masterbot an indication of whether the skillbot is configured with an intent suitable for processing the utterance.

[0047] 1 illustrates digital assistant 106 with masterbot 114 and skillbots 116-1, 116-2, and 116-3, but this is not intended to be limiting. The digital assistant may include various other components (e.g., other systems and subsystems) that provide the functionality of the digital assistant. These systems and subsystems may be implemented solely in software (e.g., code, instructions stored on a computer-readable medium and executable by one or more processors), solely in hardware, or in an implementation using a combination of software and hardware.

[0048] DABP 102 provides infrastructure and various services and features that enable users of DABP 102 to create digital assistants, including one or more skillbots associated with the digital assistant. In some cases, a skillbot can be created by cloning an existing skillbot, for example, cloning a skillbot provided by a skill store. As described above, DABP 102 provides a skill store or skill catalog that offers multiple skillbots for performing various tasks. Users of DABP 102 can clone skillbots from this skill store. Modifications or customizations may be made to the cloned skillbot as needed. In some other cases, users of DABP 102 create skillbots from scratch using tools and services provided by DABP 102. As described above, the skill store or skill catalog provided by DABP 102 may offer multiple skillbots for performing various tasks.

[0049] In particular embodiments, creating or customizing a skillbot generally involves the following steps:

[0050] (1) Steps to configure the new skill bot settings (2) configuring one or more intents for the skill bot; (3) configuring one or more entities for one or more intents; (4) training the skill bot; (5) Creating a dialogue flow for the skill bot (6) Add custom components to the skill bot as needed. (7) Test and deploy the skill bot. Each of the above steps is briefly described below.

[0051] (1) Configuring Settings for a New Skillbot—Various settings can be configured for a skillbot. For example, a skillbot designer can specify one or more invocation names for the skillbot being created. A user of the digital assistant can then explicitly invoke the skillbot using these invocation names. For example, a user can enter an invocation name in a user utterance to explicitly invoke the corresponding skillbot.

[0052] (2) Configuring one or more intents and associated example utterances for the skillbot—A skillbot designer specifies one or more intents (also referred to as bot intents) for the skillbot being created. The skillbot is then trained based on these specified intents. These intents represent categories or classes of input utterances that the skillbot is trained to infer. Upon receiving an utterance, the trained skillbot infers the intent of the utterance, and the inferred intent is selected from a predefined set of intents used to train the skillbot. The skillbot then takes an appropriate action in response to the utterance based on the intent inferred for the utterance. In some cases, the intents of a skillbot represent tasks that the skillbot can perform for a user of the digital assistant. Each intent is given an intent identifier or intent name. For example, in a skillbot trained for banking, the intents specified for the skillbot may be "CheckBalance," "TransferMoney," "DepositCheck," etc. It may include.

[0053] For each intent defined for a skillbot, the skillbot designer may also provide one or more example utterances that represent and explain the intent. These example utterances are intended to represent utterances a user might input to the skillbot for that intent. For example, for the CheckBalance intent, example utterances might include, "What's the balance in my savings account?", "How much is in my checking account?", "How much do I have in my account?", etc. Thus, various permutations of typical user utterances may be specified as example utterances for an intent.

[0054] The intents and their associated example utterances are used as training data to train the skill bot. A variety of different training techniques may be used. This training results in a predictive model that is configured to take an utterance as input and output an intent for the utterance that is inferred by the predictive model. In some cases, the input utterance is provided to an intent analysis engine that is configured to predict or infer the intent of the input utterance using the trained model. The skill bot may then take one or more actions based on the inferred intent.

[0055] (3) Configuring entities for one or more intents for the skill bot - In some cases, additional context will be necessary to enable the skill bot to respond appropriately to a user utterance. For example, there may be situations where a user input utterance resolves to the same intent in the skill bot. For example, in the example above, the utterances "What's the balance in my savings account?" and "How much do I have in my checking account?" both resolve to the same CheckBalance intent, but these utterances are different requests that ask for different things. To clarify such requests, one or more entities are added to the intent. Using the banking skill bot example, we can create an entity called AccountType that defines values called "checking" and "regular." The property can enable the skill bot to parse the user request and respond appropriately. In the example above, the utterance resolves to the same intent, but with respect to the AccountType entity. The associated values are different for these two utterances. This allows the skill bot to potentially perform different actions for the two utterances, even though they resolve to the same intent. One or more entities can be specified for a particular intent configured for the skill bot. Thus, entities are used to add context to the intent itself. Entities help to more fully describe the intent, enabling the skill bot to complete the user request.

[0056] In certain embodiments, there are two types of entities: (a) built-in entities provided by DABP 102 and (2) custom entities that can be specified by the skill bot designer. Built-in entities are generic entities that can be used with a wide variety of bots. Examples of built-in entities include, but are not limited to, time, date, address, number, email address, duration, recurring period, currency, phone number, URL, etc. Custom entities are used for more customized applications. For example, in a banking skill, an AccountType entity is provided in the skill bot that enables various banking transactions by checking user input for keywords such as checking, saving, and credit card. It can be defined by the software designer.

[0057] (4) Training the Skillbot—A skillbot is configured to receive user input in the form of an utterance and parse or process the received input to identify or select an intent associated with the received user input. As described above, the skillbot must be trained for this. In certain embodiments, the skillbot is trained based on intents configured for the skillbot and example utterances associated with the intents (collectively, training data) so that the skillbot can decompose a user input utterance into one of its configured intents. In certain embodiments, the skillbot is trained using the training data to use a predictive model that enables the skillbot to discern what a user is saying (or, in some cases, what they are trying to say). DABP 102 provides a variety of different training techniques that a skillbot designer can use to train a skillbot, including various machine learning-based training techniques, rule-based training techniques, and / or combinations thereof. In certain embodiments, a portion (e.g., 80%) of the training data is used to train the skillbot model, and another portion (e.g., the remaining 20%) is used to test or validate the model. Once trained, the trained model (sometimes referred to as a trained skill bot) can be used to process and respond to user utterances. In certain cases, the user utterance may be a question that requires only one answer and no further conversation. To address such situations, a Q&A (Question and Answer) intent can be defined for the skill bot, allowing the skill bot to output an answer to a user request without the need to update the dialog definition. A Q&A intent is created in a similar manner to a regular intent. The dialog flow for a Q&A intent may be different from that of a regular intent.

[0058] (5) Creating a dialog flow for the skill bot—The dialog flow specified for the skill bot describes how the skill bot will react as the skill bot's various intents are resolved in response to received user input. This dialog flow defines the behavior or actions that the skill bot will take, for example, how the skill bot will respond to user utterances, how the skill bot will prompt the user for input, and how the skill bot will return data. A dialog flow resembles a flowchart that a skill bot follows. Skill bot designers specify the dialog flow using a language such as Markdown. In certain embodiments, a version of YAML called OBotML may be used to specify the dialog flow of a skill bot. A skill bot's dialog flow definition serves as a model of the conversation itself, i.e., a model that allows a skill bot designer to compose the interaction between a skill bot and the user it serves.

[0059] In certain embodiments, a skill bot's dialog flow definition includes the following three sections:

[0060] (a) Context Section (b) Default transition section (c) Status section Context Section - Skill bot designers can define variables used in the conversation flow in the context section. Other variables that may be named in the context section include, but are not limited to, variables for error handling, variables for built-in or custom entities, user variables that allow the skill bot to recognize and honor user preferences, etc.

[0061] Default Transition Section - Transitions for a skill bot can be defined in the dialog flow state section or the default transition section. Transitions defined in the default transition section act as fallbacks and are triggered when there are no applicable transitions defined within a state or when the conditions required to trigger a state transition cannot be met. The default transition section can be used to define routing that allows the skill bot to gracefully handle unexpected user actions.

[0062] State Section - A dialog flow and its associated behavior are defined as a series of temporary states that govern the logic within the dialog flow. Each state node in a dialog flow definition names a component that provides the functionality needed at that point in the dialog. Thus, states are built around components. A state contains characteristics specific to the component and defines the transitions to other states that occur after the component executes.

[0063] The state section may be used to handle special case scenarios. For example, there may be times when you want to temporarily leave a first skill that the user is involved in and provide the user with the option to do something in a second skill within the digital assistant. For example, if a user is interacting with a shopping skill (e.g., making a purchase selection), they may want to jump to a banking skill (e.g., to ensure they have enough money for the purchase), and then return to the shopping skill to complete the user's order. To handle this, an action in a first skill may be configured to return to the original flow after initiating an interaction with a second, different skill within the same digital assistant.

[0064] (6) Adding Custom Components to the Skillbot - As noted above, states specified in a skillbot's dialog flow name components that provide the necessary functionality corresponding to those states. Components enable the skillbot to perform its functions. In certain embodiments, DABP 102 provides a set of pre-configured components to perform a wide range of functions. A skillbot designer can select one or more of these pre-configured components and associate them with states in the skillbot's dialog flow. Additionally, the skillbot A skill bot designer can create custom or new components using the tools provided by DABP 102 and associate these custom components with one or more states in the dialog flow of the skill bot.

[0065] (7) Testing and Deploying the Skillbot—DABP 102 provides several features that allow skillbot designers to test the skillbots being developed, which can then be deployed and included in digital assistants.

[0066] While the above discussion describes how to create a skillbot, similar techniques may also be used to create a digital assistant (or masterbot). At the masterbot or digital assistant level, built-in system intents may be configured for the digital assistant. These built-in system intents are used to identify common tasks that the digital assistant itself (i.e., the masterbot) can handle without invoking the skillbot associated with the digital assistant. Examples of system intents defined for a masterbot include: (1) Exit, which applies when a user signals a desire to exit the current conversation or context in the digital assistant; (2) Help, which applies when a user requests help or orientation; and (3) UnresolvedIntent, which applies to user input that does not match well with the exit and help intents. The digital assistant also stores information about one or more skillbots associated with the digital assistant. This information allows the masterbot to select a specific skillbot to process an utterance.

[0067] At the masterbot or digital assistant level, when a user inputs a phrase or utterance into the digital assistant, the digital assistant is configured to perform processing to determine how to route the utterance and associated conversation. The digital assistant makes this determination using a routing model, which may be rule-based, AI-based, or a combination thereof. The digital assistant uses this routing model to determine whether the conversation corresponding to the user-input utterance is routed to a specific skill for processing, handled by the digital assistant or masterbot itself per built-in system intent, or handled as a different state in the current conversation flow.

[0068] In certain embodiments, as part of this processing, the digital assistant determines whether the user input utterance explicitly identifies a skillbot using its invocation name. If an invocation name is present in the user input, it is treated as an explicit invocation of the skillbot corresponding to the invocation name. In such a scenario, the digital assistant may route the user input to the explicitly invoked skillbot for further processing. In the absence of a specific or explicit invocation, in certain embodiments, the digital assistant evaluates the received user input utterance to calculate confidence scores for the system intent and the skillbot associated with the digital assistant. The calculated score for the skillbot or system intent indicates how likely the user input represents the task that the skillbot is configured to perform, or represents the system intent. Any system intent or skillbot with an associated calculated confidence score above a threshold (e.g., a confidence threshold routing parameter) is selected as a candidate for further evaluation. The digital assistant then selects a specific system intent or skillbot from the identified candidates for further processing of the user input utterance. In certain embodiments, after one or more skillbots are identified as candidates, the system intent or skillbot associated with those candidate skills is selected. The selected intents are evaluated (according to the intent model for each skill) and a confidence score is determined for each intent. Generally, any intent with a confidence score above a threshold (e.g., 70%) is treated as a candidate intent. Once a particular skill bot is selected, the user utterance is routed to that skill bot for further processing. Once a system intent is selected, one or more actions are performed by the master bot itself according to the selected system intent.

[0069] FIG. 2 is a simplified block diagram of a Masterbot (MB) system 200, according to certain embodiments. The MB system 200 may be implemented solely in software, solely in hardware, or a combination of hardware and software. The MB system 200 includes a pre-processing subsystem 210, a multiple-intent subsystem (MIS) 220, an explicit invocation subsystem (EIS) 230, a skillbot invoker 240, and a data store 250. The MB system 200 shown in FIG. 2 is merely one example of an arrangement of components in a Masterbot. Those skilled in the art will recognize many possible modifications, alternatives, and variations. For example, in some implementations, the MB system 200 may have more or fewer systems or components than those shown in FIG. 2, may combine two or more subsystems, or may have a different configuration or arrangement of subsystems.

[0070] The pre-processing subsystem 210 receives an utterance "A" 202 from a user and processes the utterance through a language detector 212 and a language parser 214. As noted above, the utterance can be provided in a variety of forms, including audio or text. The utterance 202 may be a sentence fragment, a complete sentence, multiple sentences, etc. The utterance 202 may include punctuation. For example, if the utterance 202 is provided as audio, the pre-processing subsystem 210 may convert the audio to text using a speech-to-text converter (not shown), which inserts punctuation marks, such as commas, semicolons, periods, etc., into the resulting text.

[0071] The language detector 212 detects the language of the utterance 202 based on the text of the utterance 202. The manner in which the utterance 202 is processed is language dependent, as each language has its own grammar and semantics. Differences between languages are taken into account when analyzing the syntax and structure of the utterance.

[0072] The language parser 214 parses the utterance 202 to extract part-of-speech (POS) tags for individual linguistic units (e.g., words) in the utterance 202. POS tags include, for example, nouns (NN), pronouns (PN), verbs (VB), etc. The language parser 214 may also tokenize the linguistic units of the utterance 202 (e.g., converting each word into a separate token) and lemmatize the words. A lemma is the primary form of a set of words as found in a dictionary (e.g., "run" is a lemma for run, runs, ran, running, etc.). Other types of preprocessing the language parser 214 can perform include chunking complex expressions, for example, combining "credit" and "card" into a single expression such as "credit_card." The language parser 214 may also identify relationships between words in the utterance 202. For example, in some embodiments, language parser 214 generates a dependency tree that indicates which parts of the utterance (e.g., particular nouns) are direct objects, which parts of the utterance are prepositions, etc. The results of the processing performed by language parser 214 form extracted information 205, which is provided as input to MIS 220 along with utterance 202 itself.

[0073] As noted above, an utterance 202 may contain more than one sentence. For purposes of detecting explicit invocations, utterance 202 may be treated as a single unit even if it contains multiple sentences. However, in particular embodiments, preprocessing may be performed, for example, by preprocessing subsystem 210, to identify single sentences within multiple sentences for multi-intent analysis and explicit invocation analysis. In general, the results produced by MIS 220 and EIS 230 are substantially identical regardless of whether utterance 202 is processed at the individual sentence level or as a single unit containing multiple sentences.

[0074] The MIS 220 determines whether the utterance 202 expresses multiple intents. While the MIS 220 can detect the presence of multiple intents in the utterance 202, the processing performed by the MIS 220 does not include determining whether the intent of the utterance 202 matches any intent configured for the bot. Instead, the processing for determining whether the intent of the utterance 202 matches a bot intent can be performed by the intent classifier 242 of the MB system 200 or the intent classifier of the skill bot (shown in the embodiment of FIG. 3). The processing performed by the MIS 220 assumes the existence of a bot (e.g., a particular skill bot or the master bot itself) that can process the utterance 202. Thus, the processing performed by the MIS 220 does not require knowledge of what bots are in the chatbot system (e.g., the identities of the skill bots registered with the master bot) or what intents are configured for a particular bot.

[0075] To determine that utterance 202 contains multiple intents, MIS 220 applies one or more rules from rule set 252 in data store 250. The rules applied to utterance 202 depend on the language of utterance 202 and may include a sentence pattern that indicates the presence of multiple intents. For example, the sentence pattern may include a coordinating conjunction (e.g., a conjunction) that joins two parts of a sentence, both parts corresponding to separate intents. If utterance 202 matches the sentence pattern, it can be inferred that utterance 202 expresses multiple intents. Note that an utterance with multiple intents does not necessarily have different intents (e.g., intents directed to different bots or different intents within the same bot). Instead, the utterance may have different instances of the same intent, such as "order pizza using payment account X, then order pizza using payment account Y."

[0076] As part of determining that utterance 202 represents multiple intents, MIS 220 also determines which portions of utterance 202 are associated with each intent. For each intent represented in the multiple-intent utterance, MIS 220 constructs a new utterance for separate processing to replace the original utterance, e.g., utterance “B” 206 and utterance “C” 208 shown in FIG. 2 . Thus, original utterance 202 may be split into two or more separate utterances that are processed one at a time. MIS 220 determines which of the two or more utterances should be processed first using extracted information 205 and / or from an analysis of utterance 202 itself. For example, MIS 220 may determine that utterance 202 contains a marker word indicating that a particular intent should be processed first. The newly formed utterance corresponding to this particular intent (e.g., either utterance 206 or utterance 208) is sent first for further processing by EIS 230. After the conversation caused by the first utterance has ended (or been temporarily interrupted), the next highest priority utterance (e.g., the other of utterance 206 or utterance 208) may be sent to EIS 230 for processing.

[0077] The EIS 230 determines whether the utterance it receives (e.g., utterance 206 or utterance 208) includes the invocation name of the skill bot. Each skillbot in the chatbot system is assigned a unique invocation name that distinguishes the skillbot from other skillbots in the chatbot system. A list of invocation names can be maintained in the data store 250 as part of the skillbot information 254. An utterance is considered to be an explicit invocation if the utterance contains a word match with the invocation name. If the bot is not explicitly invoked, the utterance received by the EIS 230 is considered to be an implicit invocation utterance 234 and input to an intent classifier (e.g., intent classifier 242) of the masterbot to determine which bot to use to process the utterance. In some cases, the intent classifier 242 determines that the masterbot should process the implicit invocation utterance. In other cases, the intent classifier 242 determines which skillbot the utterance should be routed to for processing.

[0078] The explicit invocation feature provided by EIS 230 has several advantages. It can reduce the amount of processing that a masterbot must perform. For example, when there is an explicit invocation, the masterbot may not need to perform intent classification analysis (e.g., using intent classifier 242) or may be able to reduce the intent classification analysis that it must perform to select a skillbot. Thus, explicit invocation analysis can enable the selection of a specific skillbot without relying on intent classification analysis.

[0079] Additionally, there may be situations where there is overlap in functionality between multiple skill bots. This can occur, for example, when the intents handled by two skill bots overlap or are very close to each other. In such situations, it may be difficult for the master bot to identify which of the multiple skill bots to select based solely on intent classification analysis. In such scenarios, an explicit invocation clarifies the specific skill bot to use.

[0080] In addition to determining that an utterance is an explicit invocation, EIS 230 is responsible for determining whether any portion of the utterance should be used as input to the skill bot being explicitly invoked. In particular, EIS 230 can determine whether any portion of the utterance is not associated with the invocation. EIS 230 can make this determination through analysis of the utterance and / or analysis of extracted information 205. Instead of sending the entire utterance received by EIS 230, EIS 230 can send the portion of the utterance that is not associated with the invocation to the invoked skill bot. In some cases, the input to the invoked skill bot is formed by simply removing any portion of the utterance that is associated with the invocation. For example, "I would like to order a pizza using PizzaBot" can be shortened to "I would like to order a pizza" because "using PizzaBot" is related to the invocation of PizzaBot but is unrelated to the processing performed by PizzaBot. In some cases, EIS 230 may reformat the portion sent to the invoked bot, for example, to form a complete sentence. Thus, the EIS 230 determines not only that there is an explicit call, but also what to send to the skillbot when there is an explicit call. In some cases, there may be no text to input to the bot being called. For example, if the utterance is "pizzabot," the EIS 230 will determine that the pizzabot is being called, but there is no text to be processed by the pizzabot. In such a scenario, the EIS 230 may inform the skillbot invoker 240 that there is nothing to send.

[0081] The skillbot invoker 240 invokes a skillbot in a variety of ways. For example, the skillbot invoker 240 can invoke the bot in response to receiving an indication 235 that a particular skillbot has been selected as a result of an explicit invocation. The indication 235 may be sent by the EIS 230 along with the input to the explicitly invoked skillbot. In this scenario, the skillbot invoker 240 will relinquish control of the conversation to the explicitly invoked skillbot. The explicitly invoked skillbot will determine an appropriate response to the input from the EIS 230 by treating the input as a standalone utterance. For example, the response may be to perform a specific action or to start a new conversation in a specific state where the initial state of the new conversation depends on the input sent from the EIS 230.

[0082] Another way that the skillbot invoker 240 can invoke a skillbot is through implicit invocation using the intent classifier 242. The intent classifier 242 can be trained using machine learning and / or rule-based training techniques to determine the likelihood that an utterance represents a task that a particular skillbot is configured to perform. The intent classifier 242 is trained for different classes, one class for each skillbot. For example, each time a new skillbot is registered with the masterbot, a list of example utterances associated with the new skillbot can be used to train the intent classifier 242 to determine the likelihood that a particular utterance represents a task that the new skillbot can perform. Parameters generated as a result of this training (e.g., a set of values for the parameters of a machine learning model) can be stored as part of the skillbot information 254.

[0083] In particular embodiments, the intent classifier 242 is implemented using a machine learning model, as described in further detail herein. Training the machine learning model may include inputting at least a subset of utterances from example utterances associated with various skill bots and generating, as an output of the machine learning model, an inference about which bot is the correct bot for processing any particular training utterance. For each training utterance, an indication that the correct bot is used with this training utterance may be provided as ground truth information. The behavior of the machine learning model may then be adapted (e.g., via backpropagation) to minimize the difference between the generated inference and the ground truth information.

[0084] In particular embodiments, the intent classifier 242 determines a confidence score for each skillbot registered with the masterbot, indicating the likelihood that the skillbot can process the utterance (e.g., the implicit invocation utterance 234 received from the EIS 230). The intent classifier 242 may also determine a confidence score for each configured system-level intent (e.g., help, exit). If a particular confidence score satisfies one or more conditions, the skillbot invoker 240 invokes the bot associated with this particular confidence score. For example, a threshold confidence score value may need to be met. Thus, the output 245 of the intent classifier 242 is either an identification of a system intent or an identification of a particular skillbot. In some embodiments, in addition to meeting the threshold confidence score value, the confidence score must exceed the next-highest confidence score by a particular win margin. Imposing such a condition may enable routing to a particular skillbot if the confidence scores of multiple skillbots each exceed the threshold confidence score value.

[0085] After identifying the bot based on the evaluation of the confidence score, the skillbot invoker 240 hands over the processing to the identified bot. In the case of a system intent, the identified bot is a masterbot. In other cases, the identified bot is a skillbot. Furthermore, the skillbot invoker 240 determines what to provide as input 247 to the identified bot. As mentioned above, in the case of an explicit invoke, the input 247 may be based on a portion of the utterance that is not associated with this invoke, or the input 247 may be nothing (e.g., an empty string). In the case of an implicit invoke, the input 247 is the entire utterance. obtain.

[0086] The data store 250 comprises one or more computing devices that store data used by various subsystems of the masterbot system 200. As described above, the data store 250 includes rules 252 and skillbot information 254. The rules 252 include, for example, rules for the MIS 220 to determine when an utterance expresses multiple intents and how to divide an utterance expressing multiple intents. The rules 252 further include rules for the EIS 230 to determine which portions of an utterance that explicitly invokes a skillbot to send to the skillbot. The skillbot information 254 includes invocation names of skillbots in the chatbot system, for example, a list of invocation names of all skillbots registered to a particular masterbot. The skillbot information 254 may also include a confidence score for each skillbot in the chatbot system, for example, information used by the intent classifier 242 to determine parameters of a machine learning model.

[0087] 3 is a simplified block diagram of a Skillbot system 300, according to certain embodiments. Skillbot system 300 is a computing system that can be implemented solely in software, solely in hardware, or a combination of hardware and software. In certain embodiments, such as the embodiment shown in FIG. 1, Skillbot system 300 can be used to implement one or more Skillbots within a digital assistant.

[0088] Skillbot system 300 includes MIS 310, intent classifier 320, and conversation manager 330. MIS 310 is similar to MIS 220 in FIG. 2 and provides similar functionality, including being operable to use rules 352 in data store 350 to determine (1) whether an utterance represents multiple intents, and if so, (2) how to split the utterance into separate utterances for each of the multiple intents. In certain embodiments, the rules applied by MIS 310 to detect multiple intents and to split the utterance are identical to the rules applied by MIS 220. MIS 310 receives utterance 302 and extracted information 304. Extracted information 304 is similar to extracted information 205 in FIG. 1 and can be generated using language parser 214 or a language parser local to skillbot system 300.

[0089] The intent classifier 320 may be trained in a manner similar to the intent classifier 242 described above in connection with the embodiment of FIG. 2 and as described in more detail herein. For example, in particular embodiments, the intent classifier 320 is implemented using a machine learning model. The machine learning model for the intent classifier 320 is trained for a particular skill bot using at least a subset of the example utterances associated with the particular skill bot as training utterances. The ground truth for each training utterance will be the particular bot intent associated with the training utterance.

[0090] The utterance 302 may be received directly from a user or provided via a masterbot. If the utterance 302 is provided via a masterbot, for example as a result of processing via the MIS 220 and EIS 230 in the embodiment shown in FIG. 2, the MIS 310 may be bypassed so as not to repeat processing already performed by the MIS 220. However, if the utterance 302 is received directly from a user, for example during a conversation that occurs after routing to a skillbot, the MIS 310 may process the utterance 302 to determine whether the utterance 302 represents multiple intents. If so, the MIS 310 applies one or more rules to split the utterance 302 into separate utterances for each intent, e.g., utterance "D" 306 and utterance "E" 308. If the utterance 302 is If multiple intents are not represented, the MIS 310 forwards the utterance 302 to the intent classifier 320 for intent classification without splitting the utterance 302 .

[0091] The intent classifier 320 is configured to match a received utterance (e.g., utterance 306 or 308) with an intent associated with the skillbot system 300. As described above, a skillbot may be configured with one or more intents, each of which includes at least one example utterance associated with the intent and used to train the classifier. In the embodiment of FIG. 2, the intent classifier 242 of the masterbot system 200 is trained to determine a confidence score for each skillbot and a confidence score for the system intent. Similarly, the intent classifier 320 may be trained to determine a confidence score for each intent associated with the skillbot system 300. The classification performed by the intent classifier 242 is at the bot level, while the classification performed by the intent classifier 320 is at the intent level and is therefore more fine-grained. The intent classifier 320 has access to intent information 354. The intent information 354 includes, for each intent associated with the skillbot system 300, a list of utterances that describe and explain the meaning of the intent and are generally associated with the tasks that can be performed by that intent. The intent information 354 may further include parameters generated as a result of training on this list of utterances.

[0092] The conversation manager 330 receives as an output of the intent classifier 320 an indication 322 that the particular intent identified by the intent classifier 320 best matches the utterance input to the intent classifier 320. In some cases, the intent classifier 320 is unable to determine any match. For example, if the utterance is directed to a system intent or an intent of a different skill bot, the confidence score calculated by the intent classifier 320 may fall below a threshold confidence score value. When this occurs, the skill bot system 300 may refer the utterance to the master bot for processing, e.g., routing to a different skill bot. However, if the intent classifier 320 successfully identifies the intent within the skill bot, the conversation manager 330 begins a conversation with the user.

[0093] The conversation initiated by the conversation manager 330 is specific to the intent identified by the intent classifier 320. For example, the conversation manager 330 may be implemented using a state machine configured to execute a dialog flow for the identified intent. The state machine may include a default starting state (e.g., the intent is invoked without any additional input) and one or more additional states, each associated with an action to be performed by the skill bot (e.g., perform a purchase transaction) and / or a dialog to be presented to the user (e.g., question, response). Thus, the conversation manager 330 can determine an action / dialog 335 upon receiving an indication 322 identifying an intent and can determine further actions or dialog in response to subsequent utterances received during the conversation.

[0094] Data store 350 comprises one or more computing devices that store data used by various subsystems of skillbot system 300. As shown in Figure 3, data store 350 includes rules 352 and intent information 354. In particular embodiments, data store 350 can be integrated into a masterbot or digital assistant data store, such as data store 250 in Figure 2.

[0095] Systems and Architectures for OOD Detection When an utterance is received by a chatbot, the chatbot must accurately determine whether the utterance is an in-domain or out-of-domain utterance. It has been found that models used to classify utterances as intents can be overconfident and provide poor results for OOD text. To overcome this problem, various embodiments are directed to a technique that uses a clustering-based approach and a metrics-based approach to calculate a probability as to whether an utterance belongs to a target domain (e.g., a given skill bot). The calculated probabilities from the clustering-based approach and the metrics-based approach are then combined into an ensemble approach to obtain the best from both the clustering-based approach and the metrics-based approach. This ensemble approach finally classifies the utterance as in-domain or out-of-domain for the target domain based on the final combined probability.

[0096] 4 is a block diagram illustrating aspects of a chatbot system 400 configured to train and utilize a classifier (e.g., the intent classifier 242 or 320 described with respect to FIGS. 2 and 3) based on text data 405. As shown in FIG. 4, the text classification performed by the chatbot system 400 in this example includes various stages: a predictive model training stage 410; a skill bot invocation stage 415 to determine the likelihood that an utterance represents a task (e.g., in-domain or out-of-domain) that a particular skill bot is configured to perform; and an intent prediction stage 420 to classify the utterance as one or more intents. The predictive model training stage 410 builds and trains one or more predictive models 425a-425n (where "n" represents any natural number) (which may be individually or collectively referred to herein as predictive models 425) that are used by the other stages. For example, the predictive models 425 may include one or more models (or an ensemble of models) for determining the likelihood that an utterance represents a task that a particular skillbot is configured to perform (e.g., calculating a probability as to whether the utterance belongs to a target domain), another model for predicting intent from utterances for a first type of skillbot, and another model for predicting intent from utterances for a second type of skillbot. Other types of predictive models may be implemented in other examples of the present disclosure.

[0097] The predictive model 425 may be a machine learning (“ML”) model such as a convolutional neural network (“CNN”) (e.g., an Inception Neural Network, a Residual Neural Network (“Resnet”)), or a recurrent neural network (e.g., a long-short-term memory (“LSTM”) model or a gated recurrent unit (“GRU”) model), or other variants of a deep neural network (“DNN”) (e.g., a stacked highway network, a wide and deep learning network with a linear model and a deep neural network, a multi-label n-binary DNN classifier, or a multi-class DNN classifier for single-intent classification). The predictive model 425 may also be other suitable ML models trained for natural language processing, such as a naive Bayes classifier, a linear classifier, a support vector machine, a bagging model such as a random forest model, a boosting model, a shallow neural network, or one or more combinations of such techniques (e.g., a CNN-HMM or an MCNN (multiscale convolutional neural network)). The chatbot system 400 may use the same or different types of predictive models to predict intents from utterances for a first type of skillbot and to predict intents from utterances for a second type of skillbot to determine the likelihood that the utterance represents a task that the particular skillbot is configured to perform. Other types of predictive models may be implemented in other examples of the present disclosure.

[0098] To train the various predictive models 425, the training phase 410 consists of three main components: dataset preparation 430, feature engineering 435, and model training 440. Dataset preparation 430 involves loading data assets 445, splitting the data assets 445 into training and validation sets 445a-n, and performing basic preprocessing so that the system can train and test the predictive models 425. The data assets 445 may include at least a subset of utterances from example utterances associated with various skill bots. As noted above, the utterances can be provided in a variety of forms, including audio or text. The utterances may be sentence fragments, complete sentences, multiple sentences, etc. For example, if the utterances are provided as audio, data preparation 430 may convert the audio to text using a speech-to-text converter (not shown), which inserts punctuation marks, such as commas, semicolons, periods, etc., into the resulting text. In some cases, the example utterances are provided by a client or customer. In other cases, example utterances are automatically generated from a library of prior utterances (e.g., by identifying utterances from the library that are specific to the skill the chatbot is learning). Data assets 445 for the predictive model 425 may include input text or speech (or input features of text or speech frames) and labels 450 corresponding to the input text or speech (or input features) as a matrix or table of values. For example, for each training utterance, an indication that the correct bot will be used with the training utterance may be provided as ground truth information for the label 450. The behavior of the predictive model 425 can then be adapted (e.g., via backpropagation) to minimize the difference between the generated inference and the ground truth information. Alternatively, the predictive model 425 may be trained for a particular skill bot using at least a subset of example utterances associated with the skill bot as training utterances. The ground truth information for the label 450 for each training utterance would be the particular bot intent associated with the training utterance.

[0099] In various embodiments, data preparation 430 includes OOD data augmentation 455 of data assets 445 to include OOD utterance examples in various contexts to make predictive model 425 more resilient to OOD utterances. By augmenting data assets 445 with OOD examples in various contexts, predictive model 425 becomes better at focusing on the most important parts of these examples and the context that connects them to their classes, including OOD classes. The augmentation 455 can be achieved using OOD augmentation techniques to combine OOD utterances in various contexts with the original utterances of data assets 445. The OOD expansion technique may include four operations, which generally include: (i) generating a dataset containing multiple OOD examples; (ii) filtering out OOD examples with contexts that are too similar to the context of the original utterance; and (iii) feeding OOD examples to the model during training in a batch process, starting with batches containing easier OOD examples and progressing to batches containing more difficult OOD examples, in order to strike a balance between OOD examples and in-domain examples, since the number of OOD examples may be much larger compared to in-domain utterances.

[0100] In some cases, further augmentation (through OOD augmentation) may be applied to the data assets 445. For example, easy data augmentation (EDA) techniques may be used to improve the performance of text classification tasks. EDA includes four operations that help prevent overfitting and train more robust models: synonym replacement, random insertion, random swap, and random deletion. Note that, in contrast to OOD augmentation, EDA operations generally (i) take words from the original text and (ii) incorporate these words into each data asset 445 relative to the original text. For example, a synonym replacement operation may be used to The random insertion operation involves randomly selecting n words from the original sentence (e.g., utterance) that are not stop words and replacing each of these words with one of its randomly selected synonyms. The random insertion operation involves finding random synonyms for random words in the original sentence that are not stop words and inserting the synonyms into random positions in the sentence n times. The random swap operation involves randomly selecting two words in the sentence and swapping their positions n times. The random deletion operation involves randomly removing each word in the sentence with probability p.

[0101] In various embodiments, feature engineering 435 involves using an encoding model, such as a Multilingual Universal Sentence Encoder (MUSE), to convert data assets 445 into feature vectors and / or create new features using data assets 445. An encoding model is a model that can map natural language elements, such as sentences, words, and n-grams (a collection of n characters / words), to sequences of numbers. In this way, each natural language element can be represented as a single point in vector space. The goal is to obtain representations of sentences, words, and n-grams that a computing device can use for data processing without losing too much information. The feature vectors can include count vectors as features, term frequency-inverse document frequency (TF-IDF) vectors at the word, n-gram, or character level as features, word embeddings as features, text / NLP features, topic models as features, or combinations thereof. A count vector is a matrix representation of a data asset 445, where each row represents an utterance, each column represents a term from the utterance, and each cell represents the frequency count of a particular term in the utterance. TF-IDF scores represent the relative importance of a term in the utterance. Word embeddings are a form of representing words and utterances using dense vector representations. A word's position in the vector space is learned from text and is based on the words that surround it when used. Text / NLP-based features may include the number of words in the utterance, the number of characters in the utterance, the average word density, the number of punctuation marks, the number of capital letters, the number of lemmas, the frequency distribution of part-of-speech tags (e.g., nouns and verbs), or any combination thereof. Topic modeling is a technique for identifying groups of words (called topics) from a collection of utterances that contain the best information.

[0102] In various embodiments, model training 440 includes training a predictive model 425 using the feature vectors and / or sentence embeddings using new features created in feature engineering 435. In some cases, the training process includes iterative operations to find a set of parameters for the predictive model 425 that minimizes a loss or error function of the predictive model 425. Each iteration may include finding a set of parameters for the predictive model 425 such that the value of the loss or error function using that set of parameters is less than the value of the loss or error function using another set of parameters in a previous iteration. The loss or error function may be constructed to measure the difference between the output predicted using the predictive model 425 and the labels 450 included in the data assets 445. Once the set of parameters is identified, the predictive model 425 is trained and can be used for prediction as designed.

[0103] In addition to data assets 445, labels 450, feature vectors, and / or new features, other techniques and information can be utilized to refine the training process of predictive model 425. For example, feature vectors and / or new features may be combined to help improve the accuracy of a classifier or model. Additionally or alternatively, hyperparameters may be adjusted or optimized, e.g., multiple parameters such as tree length, leaf, and network parameters may be fine-tuned to obtain the best-fit model. While the training mechanisms described herein primarily focus on training predictive model 425, these training mechanisms may also be used to train predictive models trained from other data assets. It can also be used to fine-tune an existing predictive model 425. For example, in some cases, the predictive model 425 may have been pre-trained using utterances specific to another skill bot. In such cases, the predictive model 425 can be retrained using data assets 445 (e.g., by OOD augmentation).

[0104] The prediction model training stage 410 outputs trained prediction models 425, which include a task prediction model 460 and an intent prediction model 465. The task prediction model 460 may be used in the skillbot invocation stage 415 to determine (470) the likelihood that an utterance represents a task that a particular skillbot is configured to perform, and the intent prediction model 465 may be used in the intent prediction stage 420 to classify (475) the utterance as one or more intents. In some cases, the skillbot invocation stage 415 and the intent prediction stage 420 may proceed independently to separate models in some instances. For example, the trained intent prediction model 465 may be used in the intent prediction stage 420 to predict the intent of a skillbot without first identifying the skillbot in the skillbot invocation stage 415. Similarly, the task prediction model 460 may be used in the skillbot invocation stage 415 to predict the task or skillbot to be used in an utterance without identifying the intent of the utterance in the intent prediction stage 420.

[0105] Alternatively, the skillbot invocation stage 415 and the intent prediction stage 420 may be performed sequentially, with one stage using the output of the other stage as input, or one stage being invoked in a manner specific to a particular skillbot based on the output of the other stage. For example, for given text data 405, a skillbot invoker can invoke a skillbot via implicit invocation using the skillbot invocation stage 415 and the task prediction model 460. The task prediction model 460 can be trained using machine learning and / or rule-based training techniques to determine the likelihood that an utterance represents a task that a particular skillbot 470 is configured to perform. For an identified or invoked skillbot and given text data 405, the intent prediction stage 420 and the intent prediction model 465 can then be used to match the received utterance (e.g., an utterance in a given data asset 445) with an intent 475 associated with the skillbot. As described herein, a skillbot may be composed of one or more intents, each of which includes at least one example utterance associated with the intent and used to train a classifier. In some embodiments, the skillbot invocation stage 415 and task prediction model 460 used in the masterbot system are trained to determine confidence scores for individual skillbots and system intents. Similarly, the intent prediction stage 420 and intent prediction model 465 may be trained to determine confidence scores for each intent associated with the skillbot system. The classification performed by the skillbot invocation stage 415 and task prediction model 460 is at the bot level, while the classification performed by the intent prediction stage 420 and intent prediction model 465 is at the intent level and therefore more fine-grained.

[0106] FIG. 5 is a block diagram illustrating aspects of a model architecture 500 that provides a clustering-based approach and a metrics-based approach for calculating the probability of whether an utterance belongs to a target domain (e.g., the skill bot invocation stage 415 described with reference to FIG. 4). The model architecture 500 includes a clustering component 505, a classification component 510, and an ensemble component 515. The clustering component 505 includes two stages: (i) an unsupervised clustering model 520 and (ii) an outlier detection model 525. The unsupervised clustering model 520 finds clusters within the in-domain data 535. The clustering-based approach and the metrics-based approach share the same method for computing 530, calculating centroids 540, and generating 545 an embedding for the cluster. The outlier detection model 525 is built with a distance or density algorithm (e.g., Z-score, K-means, DBSCAN, local outlier detection (LOF), isolation forest, etc.) to provide a probability 550 (e.g., a second probability) as to whether the input utterance 555 belongs to the target domain. The classification component 510 includes two stages: (i) an unsupervised clustering model 520 and (ii) a distance learning model 560. The distance learning model 560 is built with a deep learning network 575 having trained model parameters configured to compute an absolute difference 565 between the sentence embedding 570 for the input utterance 555 and the embedding for the cluster 545, and provide a probability 580 (e.g., a first probability) as to whether the input utterance 555 belongs to the target domain. The ensemble component 515 is configured to evaluate the probabilities 580 and 550 to arrive at a final probability 585 as to whether the input utterance 555 belongs to the target domain or not, and based on the final probability 585, classify the input utterance 555 as being in-domain or out-of-domain for the chatbot.

[0107] With respect to the clustering-based approach performed by the clustering component 505, the in-domain data 535 used to train the unsupervised clustering algorithm comprises in-domain utterances associated with a particular domain or skill bot (e.g., pizza-ordering training data only). An embedding model 590 (e.g., MUSE) can be used to generate sentence embeddings for each in-domain utterance by mapping natural language elements, including sentences, words, and n-grams, to sequences of numbers. Each natural language element is represented as a single point in a vector space. Thus, each sentence embedding is a vector of values representing the natural language element. An unsupervised clustering algorithm (e.g., K-means, affinity propagation, agglomerative clustering, balanced iterative shrinkage and clustering (BIRCH), DBSCAN, mean shift, ordering points to identify clustering structure (OPTICS), etc.) takes the data points (i.e., sentence embeddings for each in-domain utterance) as input and groups them into clusters. This grouping process is the training phase of the unsupervised clustering algorithm. The result will be an unsupervised clustering model 520 that takes as input a data sample (e.g., a sentence embedding for a new in-domain utterance) and returns the cluster to which the new data point belongs, according to the training it has undergone. Once clusters have been found for the in-domain data 535, an embedding 545 is generated for each cluster. The embedding 545 is the average of the sentence embeddings for each in-domain utterance in the cluster. The clustering process narrows the in-domain data 535 down to a more manageable size of embeddings 545 for the cluster (e.g., 1000 or fewer embeddings, 500 or fewer embeddings, or 250 or fewer embeddings).

[0108] The outlier detection model 525 optionally comprises an unsupervised clustering algorithm (e.g., K-means, affinity propagation, agglomerative clustering, BIRCH, DBSCAN, mean shift, OPTICS, etc.) that takes as input the data points (i.e., the embedding representations 545 and centroid calculations for the clusters determined by centroid calculation 535 and cluster detection 530) and further groups them into refined clusters. This grouping process is the training phase of the unsupervised clustering algorithm. The result will be an unsupervised clustering model that takes as input the data samples (e.g., the embedding representations and centroid calculations for the clusters) and returns the refined cluster to which the new data point belongs, according to the training that the unsupervised clustering model has undergone. Once the refined clusters have been determined for the embedding representations 545, for each refined cluster, A refined embedding is generated. This refined embedding is the average of the embeddings 545 for each refined cluster. The outlier detection model 525 includes a distance or density algorithm (e.g., Z-score, K-means, DBSCAN, local outlier detection (LOF), isolation forest, etc.) configured to determine the distance or density deviation between the sentence embedding 570 for the input utterance 555 and the embeddings (or refined embeddings) for neighboring clusters. The outlier detection model 525 predicts a probability 525 as to whether the input utterance 555 belongs to the target domain based on the determined distance or density deviation. For example, the outlier detection model 525 can consider an input utterance 555 that has a significant distance from or a substantially lower density than any neighboring cluster to be an outlier, and can then use this outlier to provide a probability 525 as to whether the input utterance 555 belongs to the target domain.

[0109] For the metrics-based approach performed by classification component 510, deep learning network 575 may be trained using a set of training data that includes (i) sentence embeddings for the input utterance, (ii) an embedding representation for each cluster composed of sentence embeddings for the in-domain data, and (iii) the absolute difference between the sentence embeddings for the input utterance and each embedding representation for each cluster composed of sentence embeddings for the in-domain data. The in-domain data 535 used to train deep learning network 575 comprises in-domain utterances associated with various domains or skill bots (e.g., pizza ordering training data, but also training data from other available domains or bots, such as payroll bots, weather bots, bank account bots, etc.).

[0110] In some embodiments, the deep learning network 575 is a stacked highway network with a nonlinear transformation as part of the gating function. Model parameters for the stacked highway network may be learned using a set of training data. During training of the metric learning model 560 with the set of training data, the high-dimensional features of the sentence embeddings and the embedding representations for each cluster are converted into low-dimensional vectors, which are then concatenated with features from in-domain utterances and fed to hidden layers of a deep neural network, where the values of the low-dimensional vectors are randomly initialized and, together with the model parameters, learned to minimize a loss function.

[0111] Once trained, the stacked highway network can determine the similarities or differences between sentence embeddings 570 for an input utterance 555 and each embedding 545 for each cluster. An embedding model 595 (e.g., MUSE) can be used to generate sentence embeddings 570 for an input utterance 555 by mapping natural language elements, including sentences, words, and n-grams, to sequences of numbers. Each natural language element is represented as a single point in a vector space. Thus, a sentence embedding is a vector of values that represent the natural language elements.

[0112] A layered highway network can be formulated as follows:

[0113]

number

[0114] The similarity or difference between the sentence embeddings 570 for the input utterance 555 and each embedding 545 for each cluster may be determined by (i) calculating the absolute difference 565 between the sentence embeddings for the utterance and each embedding for each cluster, (ii) inputting the absolute difference 565, the sentence embeddings 570 for the input utterance, and the embeddings 545 for each cluster into a stacked highway network, and (iii) using the stacked highway network, the absolute difference 565, the sentence embeddings 570 for the input utterance 555, and the embeddings 545 for each cluster to determine the similarity or difference between the sentence embeddings 570 for the input utterance 555 and each embedding 545 for each cluster. 5, the absolute difference between the sentence embedding 570 for the input utterance 555 and each embedding 545 for each cluster is calculated by taking the absolute value (e.g., |UV|=[0.2,0.3,0.9]|) of the difference between the vector value (e.g., V=[0.1,0.4,-0.5]) of the sentence embedding 570 for the input utterance 555 and the vector value (e.g., U=[0.3,0.1,0.4]) of each embedding 545 for each cluster composed of sentence embeddings for the in-domain data 535. The probability 580 of whether 55 belongs to the target domain can be predicted by the stacked highway network based on the determined similarities or differences between the sentence embeddings 570 for the input utterance 555 and each embedding representation 545 for each cluster.

[0115] In another embodiment, the deep learning network 575 is a wide-and-deep learning network having a linear model and a deep neural network. The linear model comprises model parameters trained using a set of training data. The set of training data includes absolute differences between sentence embeddings for the utterance and each embedding for each cluster for in-domain utterances from multiple domains. During training of the linear model using the set of training data, a linear relationship between the sentence embeddings for the utterance and each embedding for each cluster is learned using a hypothesis function. During learning of the linear relationship, multiple model parameters are learned to minimize a loss function. The deep learning network comprises model parameters trained using a set of training data. The set of training data includes sentence embeddings for in-domain utterances from multiple domains. During training of the deep learning network with a set of training data, the high-dimensional features of the sentence embeddings for the in-domain utterances are converted into low-dimensional vectors, which are then concatenated with features from the in-domain utterances and fed into a hidden layer of the deep neural network, where the values of the low-dimensional vectors are randomly initialized and, together with several model parameters, are learned to minimize a loss function.

[0116] Once trained, the Wide and Deep Learning network can determine similarities or differences between sentence embeddings 570 for an input utterance 555 and each embedding 545 for each cluster. An embedding model 595 (e.g., MUSE) can be used to generate sentence embeddings 570 for an input utterance 555 by mapping natural language elements, including sentences, words, and n-grams, to sequences of numbers. Each natural language element is represented as a single point in a vector space. Thus, a sentence embedding is a vector of values that represent the natural language elements.

[0117] Determining the similarity or difference between the sentence embeddings 570 for the input utterance 555 and each embedding 545 for each cluster may comprise (i) calculating the absolute difference 565 between the sentence embeddings 570 for the input utterance 555 and each embedding 545 for each cluster; (ii) inputting the absolute difference 565, the sentence embeddings 570 for the input utterance 565, and the embeddings 545 for each cluster into a wide and deep learning network; (iii) predicting a wide-based probability of whether the input utterance 555 belongs to the target domain using a linear model and the absolute difference 565; and (iv) using the deep neural network, the sentence embeddings 570 for the input utterance 555, and the embeddings 545 for each cluster to determine the similarity or difference between the sentence embeddings 570 for the input utterance 555 and each embedding 545 for each cluster. The probability 580 of whether the input utterance 555 belongs to the target domain can be predicted using the final layer of the wide and deep learning network by evaluating the similarity or difference between the wide probability and the sentence embedding 570 for the input utterance 555 and each embedding 545 for each cluster.

[0118] The ensemble component 515 evaluates the probabilities 580 and 550 to arrive at a final probability 585 as to whether the input utterance 555 belongs to the target domain or not, and classifies the input utterance 555 as being in-domain or out-of-domain for the chatbot based on the final probability 585. In a particular case, the ensemble component 515 utilizes the following in_domain_prob function: in_domain_prob(ensemble,x) = max(in_domain_prob(cluster-based,x), in_domain_prob(metric-based,x)), which is It takes into account the clustering-based approach and the metrics-based approach and returns the in-domain probability of utterance x. Essentially, an utterance is in the target domain if either approach says x is in-domain, and an utterance is out-of-domain if both approaches say x is out-of-domain (the error on the side of utterance x is in-domain).

[0119] OOD decision-making technology FIG. 6 is a flowchart illustrating a process 600 for identifying OOD utterances, according to certain embodiments. The process illustrated in FIG. 6 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of a respective system, in hardware, or a combination thereof. The software may be stored in a non-transitory storage medium (e.g., a memory device). The method illustrated in FIG. 6 and described below is intended to be exemplary and non-limiting. While FIG. 6 depicts various processing steps occurring in a particular sequence or order, this is not intended to be limiting. In certain alternative embodiments, these steps may be performed in a different order, or some steps may be performed in parallel. In certain embodiments, such as those illustrated in FIGS. 1-5, the process illustrated in FIG. 6 may be performed by a trained model architecture (e.g., model architecture 500) for identifying OOD utterances.

[0120] At 605, an utterance and a target domain for the chatbot are received (e.g., a skill or chatbot as described with reference to Figures 1, 2, and 3). The target domain is defined for a chatbot that specializes in a particular type of task, such as tracking inventory, submitting time cards, and creating expense reports.

[0121] At 610, a sentence embedding is generated for the utterance. The sentence embedding for the utterance may be generated using an embedding model that maps natural language elements, including sentences, words, and n-grams, to sequences of numbers. Each natural language element is represented as a single point in a vector space. Thus, each sentence embedding is a vector of values that represent the natural language element.

[0122] At 615, an embedding representation is obtained for each cluster of a plurality of clusters of in-domain utterances associated with the target domain. The embedding representation for each cluster is an average of the sentence embeddings for each in-domain utterance in the cluster. Obtaining the embedding representation for each cluster may comprise obtaining in-domain utterances based on the target domain (e.g., if the target domain is ordering pizza, then all of the in-domain utterances relate to utterances associated with ordering pizza, such as "I would like to order a cheese pizza"); generating sentence embeddings for each in-domain utterance; inputting the sentence embeddings for each in-domain utterance into an unsupervised clustering model configured to interpret the in-domain utterances and identify a plurality of clusters in a feature space of the in-domain utterances; classifying the sentence embeddings for each in-domain utterance into one of a plurality of clusters based on similarities or differences between features of the sentence embeddings and features of the sentence embeddings in each cluster using the unsupervised clustering model; calculating a centroid for each cluster of the plurality of clusters; and outputting the embedding representations and the centroid for each cluster of the plurality of clusters. The unsupervised clustering model may be K-means, affinity propagation, agglomerative clustering, BIRCH, DBSCAN, mean shift, OPTICS, etc.

[0123] A sentence embedding for each in-domain utterance can be generated using an embedding model that maps natural language elements, including sentences, words, and n-grams, to sequences of numbers. Each natural language element is represented as a single point in a vector space. Thus, each sentence embedding is a vector of values that represent the natural language elements.

[0124] At 620, the sentence embeddings for the utterance and the embeddings for each cluster are input into a metric learning model, the metric learning model having trained model parameters configured to provide a first probability as to whether the utterance belongs to the target domain. At 625, the metric learning model is used to determine similarities or differences between the sentence embeddings for the utterance and each embedding for each cluster. At 630, the metric learning model is used to predict a first probability as to whether the utterance belongs to the target domain based on the determined similarities or differences between the sentence embeddings for the utterance and each embedding for each cluster.

[0125] In some embodiments, the metric learning model comprises a stacked highway network having a nonlinear transformation as part of the gating function. Determining the similarity or difference between the sentence embedding for the utterance and each embedding for each cluster includes (i) calculating the absolute difference between the sentence embedding for the utterance and each embedding for each cluster; (ii) inputting the absolute difference, the sentence embedding for the utterance, and the embedding for each cluster into the stacked highway network; and (iii) calculating the similarity or difference between the sentence embedding for the utterance and each embedding for each cluster. and determining similarities or differences between the sentence embeddings for the utterance and each embedding representation for each cluster using the embedded representations.

[0126] Model parameters for the stacked highway network can be learned using a set of training data, which includes (i) sentence embeddings for the utterance, (ii) an embedding for each cluster composed of sentence embeddings for in-domain utterances from multiple domains, and (iii) the absolute difference between the sentence embedding for the utterance and each embedding for each cluster composed of sentence embeddings for in-domain utterances. During training of the metric learning model with the set of training data, high-dimensional features of the sentence embeddings and the embedding for each cluster are converted to low-dimensional vectors, which are then concatenated with features from the in-domain utterances and fed to hidden layers of a deep neural network, where the values of the low-dimensional vectors are randomly initialized and, together with the model parameters, are learned to minimize a loss function.

[0127] In another embodiment, the metric learning model comprises a wide-and-deep learning network having a linear model and a deep neural network. Determining the similarity or difference between the sentence embedding for the utterance and each embedding for each cluster may comprise: (i) calculating the absolute difference between the sentence embedding for the utterance and each embedding for each cluster; (ii) inputting the absolute difference, the sentence embedding for the utterance, and the embedding for each cluster into the wide-and-deep learning network; (iii) predicting a wide-based probability of whether the utterance belongs to the target domain using the linear model and the absolute difference; and (iv) determining the similarity or difference between the sentence embedding for the utterance and each embedding for each cluster using the deep neural network, the sentence embedding for the utterance, and the embedding for each cluster. Predicting the first probability may comprise evaluating the similarity or difference between the wide probability and the sentence embedding for the utterance and each embedding for each cluster using a final layer of the wide-and-deep learning network.

[0128] The linear model comprises model parameters trained using a set of training data. The set of training data includes absolute differences between sentence embeddings for the utterance and each embedding for each cluster for in-domain utterances from multiple domains. During training of the linear model with the set of training data, a linear relationship between the sentence embeddings for the utterance and each embedding for each cluster is learned using a hypothesis function. During learning of the linear relationship, the multiple model parameters are learned to minimize a loss function.

[0129] The deep learning network comprises model parameters trained using a set of training data, the set of training data including sentence embeddings for in-domain utterances from multiple domains. During training of the deep learning network with the set of training data, high-dimensional features of the sentence embeddings for the in-domain utterances are converted into low-dimensional vectors, which are then concatenated with features from the in-domain utterances and fed to a hidden layer of the deep neural network, where the values of the low-dimensional vectors are randomly initialized and, together with multiple model parameters, are learned to minimize a loss function.

[0130] At 635, the sentence embeddings for the utterance and the embedding representations for each cluster are input into an outlier detection model, which is built with a distance or density algorithm for outlier detection, which may be Z-score, K-means, DBSCAN, local outlier detection (LOF), isolation forest, etc.

[0131] At 640, the outlier detection model is used to determine a distance or density deviation between the sentence embedding for the utterance and the embedding representations for the adjacent clusters. At 645, the outlier detection model is used to predict a second probability of whether the utterance belongs to the target domain based on the determined distance or density deviation. The prediction may comprise calculating a z-score for the utterance based on the distance or density deviation between the sentence embedding for the utterance and the embedding representations for the adjacent clusters, and determining the second probability of whether the utterance belongs to the target domain by applying a sigmoid function to the z-score.

[0132] At 650, the first probability and the second probability are evaluated to determine a final probability as to whether the utterance belongs to the target domain. At 655, the utterance is classified as being in-domain or out-of-domain for the chatbot based on the final probability. The probabilities calculated from the clustering-based approach and the distance-based approach are combined as an ensemble approach to get the best from both the clustering-based approach and the distance-based approach. In a particular case, the ensemble approach comprises (in_domain_prob(ensemble,x) = max(in_domain_prob(cluster-based,x),in_domain_prob(metric-based,x)), where the in_domain_prob function is the clustering-based probability. It takes into account the metric-based approach and the in-domain probability of utterance x. Essentially, an utterance is in the target domain if either approach says x is in-domain, and an utterance is out-of-domain if both approaches say x is out-of-domain (the error on the side of utterance x is in-domain).

[0133] Exemplary System 7 is a simplified diagram of a distributed system 700. In the illustrated example, the distributed system 700 includes one or more client computing devices 702, 704, 706, and 708, which are coupled to a server 712 via one or more communication networks 710. The client computing devices 702, 704, 706, and 708 may be configured to execute one or more applications.

[0134] In various examples, server 712 may be adapted to run one or more services or software applications that enable one or more embodiments described in this disclosure. In certain examples, server 712 may also provide other services or software applications, which may include non-virtualized and virtualized environments. In some examples, these services may be provided to users of client computing devices 702, 704, 706, and / or 708 as web-based or cloud services, such as under a Software as a Service (SaaS) model. Users operating client computing devices 702, 704, 706, and / or 708 may then utilize one or more client applications to interact with server 712 to utilize the services provided by these components.

[0135] In the configuration shown in Figure 7, server 712 may include one or more components 718, 720, and 722 that implement the functions performed by server 712. These components may include software components, hardware components, or a combination thereof that may be executed by one or more processors. It should be understood that a variety of different system configurations are possible that may differ from distributed system 700. The example shown in Figure 7 is therefore one example of a distributed system for implementing an exemplary system and is not intended to be limiting. do not have.

[0136] A user may use client computing devices 702, 704, 706, and / or 708 to execute one or more applications, models, or chatbots, which may generate one or more events or models that may be executed or provided in accordance with the teachings of this disclosure. The client devices may provide an interface that allows a user of the client device to interact with the client device. The client devices may also output information to the user through this interface. While FIG. 7 shows only four client computing devices, any number of client computing devices may be supported.

[0137] Client devices may include various types of computing systems, such as portable handheld devices, general-purpose computers (such as personal computers and laptops), workstation computers, wearable devices, gaming systems, thin clients, various messaging devices, sensors or other sensing devices, etc. These computing devices may run various types and versions of software applications and operating systems (e.g., Microsoft Windows, Apple Macintosh, UNIX or UNIX-like operating systems, Linux or Linux-like operating systems (such as Google Chrome™ OS)), including various mobile operating systems (e.g., Microsoft Windows Mobile, iOS, Windows Phone, Android, BlackBerry, Palm OS). Portable handheld devices may include mobile phones, smartphones (e.g., iPhones), tablets (e.g., iPads), personal digital assistants (PDAs), etc. Wearable devices may include Google Glass head-mounted displays and other devices. Gaming systems may include various handheld gaming devices, Internet-enabled gaming devices (e.g., Microsoft Xbox® gaming consoles with or without Kinect® gesture input devices, Sony PlayStation® systems, various gaming systems offered by Nintendo®, etc.), etc. Client devices may include various Internet-related apps, communication applications (e.g., email applications, short messaging applications, etc.), and the like. The mobile device may be capable of running a variety of different applications, such as SMS applications, and may use a variety of communication protocols.

[0138] Network 710 may be any type of network familiar to those skilled in the art that is capable of supporting data communications using any of a variety of available protocols, including, but not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Exchange), AppleTalk®, etc. By way of example only, network 710 may be a local area network (LAN), an Ethernet-based network, a token ring, a wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., a network operating under any of the Institute of Electrical and Electronics Engineers (IEEE) 1002.11 suite of protocols, Bluetooth® and / or other wireless protocols), and / or any combination of these and / or other networks. .

[0139] The servers 712 may be comprised of one or more general-purpose computers, specialized server computers (including, by way of example, PC (personal computer) servers, UNIX servers, midrange servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or other suitable configurations and / or combinations. The servers 712 may include one or more virtual machines running a virtual operating system or other computing architectures that involve virtualization, such as one or more flexible pools of logical storage devices that may be virtualized to maintain virtual storage devices for the servers. In various examples, the servers 712 may be adapted to run one or more services or software applications that provide the functionality described in the foregoing disclosure.

[0140] The computing systems in server 712 may run one or more operating systems, including any of those described above, as well as any commercially available server operating system. Server 712 may also run any of a variety of other server and / or middle-tier applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, JAVA servers, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from Oracle Corporation®, Microsoft Corporation®, Sybase®, IBM® (International Business Machines), etc.

[0141] In some implementations, server 712 may include one or more applications for parsing and consolidating data feeds and / or event updates received from users of client computing devices 702, 704, 706, and 708. By way of example, the data feeds and / or event updates may include, but are not limited to, Twitter feeds, Facebook updates, or real-time updates received from one or more third-party sources and continuous data streams, which may include real-time events related to sensor data applications, financial stock tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc. Server 712 may also include one or more applications for displaying the data feeds and / or real-time events via one or more display devices of client computing devices 702, 704, 706, and 708.

[0142] The distributed system 700 may also include one or more data repositories 714, 716. In certain examples, these data repositories may be used to store data and other information. For example, one or more of the data repositories 714, 716 may be used to store information, such as information related to the performance of a chatbot or generated models used by the chatbot that are used by the server 712 in performing various functions according to various embodiments. The data repositories 714, 716 may be in various locations. For example, the data repository used by the server 712 may be local to the server 712 or may be remote from the server 712 and in communication with the server 712 via a network-based or dedicated connection. The data repositories 714, 716 may be of different types. In certain examples, the data repository used by the server 712 may be a database, e.g., a relational database, such as databases provided by Oracle Corporation and other vendors. One or more of these databases may be adapted to allow data to be stored, updated, and retrieved from the database in response to SQL formatted commands.

[0143] In particular examples, one or more of the data repositories 714, 716 may also be used by an application to store application data. The data repositories used by an application may be of different types, such as a key-value store repository, an object store repository, or a general storage repository supported by a file system.

[0144] In certain examples, the functionality described in this disclosure may be provided as services via a cloud environment. Figure 8 is a simplified block diagram of a cloud-based system environment in which various services may be provided as cloud services, according to certain examples. In the example shown in Figure 8, cloud infrastructure system 802 may provide one or more cloud services that may be requested by users using one or more client computing devices 804, 806, and 808. Cloud infrastructure system 802 may comprise one or more computers and / or servers, which may include those described above for server 812. The computers in cloud infrastructure system 802 may be organized as general-purpose computers, specialized server computers, server farms, server clusters, or any other suitable configuration and / or combination.

[0145] Network 810 may facilitate the communication and exchange of data between clients 804, 806, and 808 and cloud infrastructure system 802. Network 810 may include one or more networks. These networks may be of the same type or different types. Network 810 may support one or more communication protocols, including wired and / or wireless protocols, to facilitate communication.

[0146] The example shown in Figure 8 is merely one example of a cloud infrastructure system and is not intended to be limiting. It should be understood that in some other examples, cloud infrastructure system 802 may have more or fewer components than those shown in Figure 8, may combine two or more components, or may have a different configuration or arrangement of components. For example, while Figure 8 shows three client computing devices, any number of client computing devices may be supported in alternative examples.

[0147] The term cloud services is generally used to refer to services made available to users on demand over a communications network, such as the Internet, by a service provider's system (e.g., cloud infrastructure system 802). Generally, in a public cloud environment, the servers and systems that make up the cloud service provider's system are distinct from the customer's own on-premise servers and systems. The cloud service provider's systems are managed by the cloud service provider. Thus, customers can utilize these services without having to purchase separate licenses, support, or hardware and software resources for the cloud services offered by the cloud service provider. For example, the cloud service provider's system may host an application, and users can order this application on demand over the Internet without having to purchase infrastructure resources to run the application. Cloud services can be used as a service provider. Cloud services are designed to provide easy and scalable access to applications, resources, and services. Several providers offer cloud services. For example, several cloud services, such as middleware services, database services, and Java cloud services, are offered by Oracle Corporation of Redwood Shores, California.

[0148] In particular examples, cloud infrastructure system 802 may provide one or more cloud services using various models, such as under a Software as a Service (SaaS) model, a Platform as a Service (PaaS) model, an Infrastructure as a Service (IaaS) model, etc., including a hybrid service model. Cloud infrastructure system 802 may include a set of applications, middleware, databases, and other resources that enable the delivery of various cloud services.

[0149] The SaaS model allows applications or software to be delivered to customers as a service over a communications network such as the Internet, without the customer having to purchase hardware or software for the underlying application. For example, the SaaS model may be used to provide customers with access to on-demand applications hosted by cloud infrastructure system 802. Examples of SaaS services offered by Oracle Corporation® include, but are not limited to, various services for human capital / capital management, customer relationship management (CRM), enterprise resource planning (ERP), supply chain management (SCM), enterprise performance management (EPM), analytics services, social applications, etc.

[0150] The IaaS model is commonly used to provide infrastructure resources (e.g., servers, storage, hardware and networking resources) as a cloud service to customers to provide elastic compute and storage capabilities. Various IaaS services are offered by Oracle Corporation.

[0151] The PaaS model is commonly used to provide platform and environment resources as a service that enables customers to develop, run, and manage applications and services without the need for customers to procure, build, or maintain such resources. Examples of PaaS services offered by Oracle Corporation® include, but are not limited to, Oracle Java Cloud Services (JCS), Oracle Database Cloud Services (DBCS), data management cloud services, and various application development solution services.

[0152] Cloud services are generally provided in an on-demand self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. For example, a customer may order one or more services provided by cloud infrastructure system 802 via a subscription order. Cloud infrastructure system 802 then performs processing to provide the services requested in the customer's subscription order. For example, a user may use utterances to request the cloud infrastructure system to take a particular action (e.g., intent), as described above, and / or to provide a service to a chatbot system, as described herein. Cloud infrastructure system 802 may be configured to provide one or more cloud services.

[0153] The cloud infrastructure system 802 supports a variety of deployment models. In a public cloud model, cloud infrastructure system 802 may be owned by a third-party cloud service provider, and cloud services may be offered to any public customer, which may be an individual or a business. In certain other examples, under a private cloud model, cloud infrastructure system 802 may be operated within an organization (e.g., within a corporate organization), and services may be offered to customers within the organization. For example, customers may be various departments of a company, such as a human resources department, a payroll department, or individuals within the company. In certain other examples, under a community cloud model, cloud infrastructure system 802 and the services offered may be shared by several organizations within an associated community. Various other models, such as hybrids of the above models, may also be used.

[0154] Client computing devices 804, 806, and 808 may be of different types (such as client computing devices 702, 704, 706, and 708 shown in FIG. 7) and may be capable of running one or more client applications. Users may use the client devices to interact with cloud infrastructure system 802, such as to request services provided by cloud infrastructure system 802. For example, users may use client devices to request information or actions from a chatbot as described in this disclosure.

[0155] In some examples, the processing performed by cloud infrastructure system 802 to provide services may include model training and deployment. This analysis may include using, analyzing, and manipulating datasets to train and deploy one or more models. This analysis may be performed by one or more processors, possibly processing the data in parallel or performing simulations using the data. For example, big data analysis may be performed by cloud infrastructure system 802 to generate and train one or more models for a chatbot system. The data used in this analysis may include structured data (e.g., data stored in a database or structured according to a structured model) and / or unstructured data (e.g., data blobs (binary large objects)).

[0156] 8, cloud infrastructure system 802 may include infrastructure resources 830 utilized to facilitate the provision of various cloud services offered by cloud infrastructure system 802. Infrastructure resources 830 may include, for example, processing resources, storage or memory resources, networking resources, etc. In particular examples, storage virtual machines available to provide storage requested by applications may be part of cloud infrastructure system 802. In other examples, the storage virtual machines may be part of a different system.

[0157] In particular examples, to facilitate efficient provisioning of these resources to support various cloud services offered by cloud infrastructure system 802 to various customers, resources may be bundled into sets of resources or resource modules (also referred to as "pods"). Each resource module or pod may comprise a pre-integrated and optimized combination of one or more types of resources. In particular examples, different pods may be pre-provisioned for different types of cloud services. For example, a first set of pods may be provisioned for database services, and a second set of pods, which may include a different combination of resources than the pods in the first set of pods, may be pre-provisioned for Java services. may be provisioned, etc. In some services, resources allocated to provisioning a service may be shared between services.

[0158] Cloud infrastructure system 802 itself may internally use services 832 that are shared by various components of cloud infrastructure system 802, which facilitates the provisioning of services by cloud infrastructure system 802. These internal shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelist services, high availability, backup and recovery services, services to enable cloud support, email services, notification services, file transfer services, etc.

[0159] Cloud infrastructure system 802 may comprise multiple subsystems. These subsystems may be implemented in software, hardware, or a combination thereof. As shown in FIG. 8 , these subsystems may include a user interface subsystem 812 that allows users or customers of cloud infrastructure system 802 to interact with cloud infrastructure system 802. User interface subsystem 812 may include a variety of different interfaces, such as a web interface 814, an online store interface 816 (through which cloud services offered by cloud infrastructure system 802 are advertised and available for purchase by consumers), and other interfaces 818. For example, a customer may use a client device to request one or more services offered by cloud infrastructure system 802 (service request 834) using one or more of interfaces 814, 816, and 818. For example, a customer may access an online store to browse cloud services offered by cloud infrastructure system 802 and place a subscription order for one or more services offered by cloud infrastructure system 802 for which the customer wishes to subscribe. This service request may include information identifying the customer and the one or more services for which the customer wishes to subscribe. For example, a customer may place a subscription order for services provided by cloud infrastructure system 802. As part of the order, the customer may provide information identifying the chatbot system for which the services are to be provided, and optionally, one or more credentials for that chatbot system.

[0160] 8 , cloud infrastructure system 802 may include an order management subsystem (OMS) 820 configured to process new orders. As part of this processing, OMS 820 may be configured to create a customer account if not already done, receive billing and / or billing information from the customer that is used to issue a bill to the customer for providing the customer with the requested services, verify the customer information, confirm the customer's order upon verification, and orchestrate various workflows to prepare the order for provisioning.

[0161] Once properly authenticated, OMS 820 may then invoke Order Provisioning Subsystem (OPS) 824. OPS 824 is configured to provision resources for the order, including processing, memory, and networking resources. Provisioning may include allocating resources for the order and configuring these resources to facilitate the services requested by the customer order. The manner in which resources are provisioned for the order and the types of resources provisioned may depend on the type of cloud service ordered by the customer. For example, according to one workflow, OPS 824 may be configured to determine that a particular cloud service is being requested and identify the number of pods that may have been pre-configured for that particular cloud service. The number of pods allocated to an order may depend on the size / amount / level / scope of the service requested. For example, the number of pods allocated may be determined based on the number of users supported by the service, the duration for which the service is being requested, etc. The allocated pods may then be customized to the particular requesting customer to provide the requested service.

[0162] In certain examples, the above setup phase processing may be performed by cloud infrastructure system 802 as part of a provisioning process. Cloud infrastructure system 802 may generate an application ID and select a storage virtual machine for the application from among storage virtual machines provided by cloud infrastructure system 802 itself or from storage virtual machines provided by other systems other than cloud infrastructure system 802.

[0163] Cloud infrastructure system 802 may send a response or notification 844 to the requesting customer indicating when the requested service will be ready for use. In some cases, information (e.g., a link) may be sent to the customer that enables the customer to begin using and utilizing the benefits of the requested service. In a particular example, when a customer requests a service, the response may include a chatbot system ID generated by cloud infrastructure system 802 and information identifying the chatbot system selected by cloud infrastructure system 802 that corresponds to the chatbot system ID.

[0164] Cloud infrastructure system 802 may provide services to multiple customers. For each customer, cloud infrastructure system 802 is responsible for managing information related to one or more subscription orders received from the customer, maintaining customer data related to these orders, and providing the requested services to the customer. Cloud infrastructure system 802 may also collect usage statistics regarding the customer's use of the subscribed services. For example, statistics may be collected on the amount of storage used, the amount of data transferred, the number of users, and system up and down time. This usage information may be used to bill the customer. Billing may occur, for example, on a monthly cycle.

[0165] Cloud infrastructure system 802 may provide services to multiple customers concurrently. Cloud infrastructure system 802 may store information of these customers, including, in some cases, proprietary information. In particular examples, cloud infrastructure system 802 includes an identity management subsystem (IMS) 828 configured to manage customer information and segregate the managed information so that information associated with one customer is not accessible by another customer. IMS 828 may be configured to provide various security-related services, such as identity services (information access management, authentication and authorization services, services for managing customer identities and roles and related functions, etc.).

[0166] 9 is a diagram illustrating an example of a computer system 900. In some examples, the computer system 900 may be used to implement a digital assistant or chatbot system in a distributed environment, as well as any of the various servers and computer systems described above. As shown in FIG. 9, the computer system 900 includes various subsystems, including a processing subsystem 904. 904 communicates with several other subsystems via bus subsystem 902. These other subsystems may include a processing acceleration unit 906, an I / O subsystem 908, a storage subsystem 918, and a communication subsystem 924. The storage subsystem 918 may include non-transitory computer-readable storage media, including a storage medium 922 and a system memory 910.

[0167] Bus subsystem 902 provides a mechanism for allowing the various components and subsystems of computer system 900 to communicate with each other as intended. While bus subsystem 902 is shown schematically as a single bus, alternative examples of the bus subsystem may utilize multiple buses. Bus subsystem 902 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a local bus, etc., using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, which may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0168] The processing subsystem 904 controls the operation of the computer system 900 and may comprise one or more processors, application specific integrated circuits (ASICs), or field programmable gate arrays (FPGAs). These processors may include single-core or multi-core processors. The processing resources of the computer system 900 may be organized into one or more processing units 932, 934, etc. A processing unit may include one or more processors, one or more cores from the same or different processors, a combination of cores and processors, or other combinations of cores and processors. In some examples, the processing subsystem 904 may include one or more special-purpose coprocessors, such as a graphics processor, a digital signal processor (DSP), etc. In some examples, some or all of the processing units of the processing subsystem 904 may be implemented using customized circuitry, such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA).

[0169] In some examples, processing units within processing subsystem 904 can execute instructions stored in system memory 910 or on computer-readable storage medium 922. In various examples, the processing units can execute various program or code instructions and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code being executed can be in system memory 910 and / or on computer-readable storage medium 922 (including, in some cases, on one or more storage devices). Through suitable programming, processing subsystem 904 can provide the various functions described above. In instances where computer system 900 is running one or more virtual machines, one or more processing units can be assigned to each virtual machine.

[0170] In certain examples, the processing acceleration unit 906 may be optionally provided to perform customized processing to accelerate the overall processing performed by the computer system 900 or to offload portions of the processing performed by the processing subsystem 904.

[0171] The I / O subsystem 908 inputs information into the computer system 900 and / or transfers information from or to the computer system 900. The user interface input devices may include devices and mechanisms for outputting information via a keyboard, a mouse, or a trackball. In general, use of the term input device is intended to include all possible types of devices and mechanisms for inputting information into computer system 900. User interface input devices may include, for example, keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include motion-sensing and / or gesture-recognition devices such as Microsoft Kinect® motion sensors that allow a user to control and interact with the input device, a Microsoft Xbox® 360 game controller, and devices that provide an interface for receiving input using gestures and verbal commands. The user interface input devices may also include eye gesture recognition devices, such as a Google Glass® blink detector, that detects eye movements from the user (e.g., "blinks" while taking a picture and / or making a menu selection) and translates the eye gestures as input to the input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows the user to interact with a voice recognition system (e.g., Siri® Navigator) via voice commands.

[0172] Other examples of user interface input devices include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, as well as audio / visual devices (such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode reader 3D scanners, 3D printers, laser range finders, and eye-tracking devices). Additionally, user interface input devices may include medical imaging input devices, such as, for example, computed tomography, magnetic resonance imaging, position emission tomography, and medical ultrasound devices. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, and the like.

[0173] In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 900 to a user or to another computer. User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. Display subsystems may be flat-panel devices such as those using cathode ray tubes (CRTs), liquid crystal displays (LCDs), or plasma displays, projection devices, touch screens, etc. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / visual information, such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0174] The storage subsystem 918 provides a repository or data store for storing information and data used by the computer system 900. The storage subsystem 918 provides a tangible, non-transitory, computer-readable storage medium for storing the basic programming and data structures that provide some example functionality. The storage subsystem 918 may store software (e.g., programs, code modules, instructions) that, when executed by the processing subsystem 904, provides the above functionality. This software may be used by one or more processing units of the processing subsystem 904. The storage subsystem 918 may also provide authentication according to the teachings of this disclosure.

[0175] The storage subsystem 918 may include one or more non-transitory memory devices, including volatile and non-volatile memory devices. As shown in FIG. 9, the storage subsystem 918 includes a system memory 910 and a computer-readable storage medium 922. The system memory 910 may include several memories, including volatile main random access memory (RAM) for storing instructions and data during program execution, and non-volatile read-only memory (ROM) or flash memory in which fixed instructions are stored. In some implementations, a basic input / output system (BIOS), containing basic routines that help transfer information between elements within the computer system 900, such as during start-up, may typically be stored in ROM. RAM typically contains data and / or program modules currently being operated on and executed by the processing subsystem 904. In some implementations, the system memory 910 may include several different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), etc.

[0176] 9, system memory 910 may load running application programs 912 (which may include various applications such as a web browser, a middle-tier application, a relational database management system (RDBMS), etc.), program data 914, and operating system 916. By way of example, operating system 916 may include various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems, various commercially available UNIX or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome OS, etc.), and / or mobile operating systems such as iOS, Windows Phone, Android OS, BlackBerry OS, Palm OS, etc.

[0177] The computer-readable storage medium 922 may store programming and data structures that provide some example functionality. The computer-readable medium 922 may provide storage of computer-readable instructions, data structures, program modules, and other data for the computer system 900. Software (programs, code modules, instructions) that, when executed by the processing subsystem 904, provide the above-described functionality may be stored in the storage subsystem 918. By way of example, the computer-readable storage medium 922 may include non-volatile memory such as a hard disk drive, a magnetic disk drive, a CD-ROM, an optical disk drive such as a DVD or Blu-ray disc, or other optical media. The computer-readable storage medium 922 may include, but is not limited to, a Zip drive, a flash memory card, a Universal Serial Bus (USB) flash drive, a Secure Digital (SD) card, a DVD disc, a digital video tape, etc. The computer-readable storage medium 922 may also include solid-state drives (SSDs) based on non-volatile memory such as flash memory-based SSDs, enterprise flash drives, solid-state ROM, SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM-based SSDs and flash memory-based SSDs.

[0178] In particular examples, storage subsystem 918 may also include a computer-readable storage medium reader 920 that may be further connected to a computer-readable storage medium 922. Reader 920 may be configured to receive and read data from a memory device such as a disk, flash drive, or the like.

[0179] In certain examples, computer system 900 may support virtualization techniques, including but not limited to virtualization of processing and memory resources. For example, computer system 900 may provide support for running one or more virtual machines. In certain examples, computer system 900 may execute a program such as a hypervisor that facilitates configuration and management of virtual machines. Each virtual machine may have allocated memory, computational (e.g., processors, cores), I / O, and networking resources. Each virtual machine generally operates independently from other virtual machines. A virtual machine generally runs its own operating system, which may be the same as or different from the operating systems run by other virtual machines executed by computer system 900. Thus, in some cases, multiple operating systems may be executed simultaneously by computer system 900.

[0180] The communications subsystem 924 provides an interface to other computer systems and networks. The communications subsystem 924 serves as an interface for sending and receiving data between other systems and the computer system 900. For example, the communications subsystem 924 may enable the computer system 900 to establish a communications channel with one or more client devices over the Internet for sending and receiving information to and from the client devices. For example, if the computer system 900 is used to implement the bot system 120 shown in FIG. 1, the communications subsystem may be used to communicate with a chatbot system selected for the application.

[0181] The communications subsystem 924 may support both wired and / or wireless communications protocols. In particular examples, the communications subsystem 924 may include a radio frequency (RF) transceiver component for accessing wireless voice and / or data networks (e.g., using cellular telephone technology, advanced data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.XX family of standards), or other mobile communications technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components. In some examples, the communications subsystem 924 may provide a wired network connection (e.g., Ethernet) in addition to or instead of a wireless interface.

[0182] The communications subsystem 924 can send and receive data in a variety of formats. In some examples, the communications subsystem 924 may receive incoming communications in the form of structured and / or unstructured data feeds 926, event streams 928, event updates 930, etc., among other formats. For example, the communications subsystem 924 may be configured to receive (or send) data feeds 926 in real time from users of social media networks and / or other communications services, such as web feeds, such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party sources.

[0183] In a particular example, the communications subsystem 924 receives data in the form of a continuous data stream. , which may include an event stream 928 of real-time events and / or event updates 930 that may be continuous or infinite in nature without a clear end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial stock ticker boards, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0184] Communications subsystem 924 may also be configured to communicate data from computer system 900 to other computer systems or networks. This data may be communicated in a variety of different formats, such as structured and / or unstructured data feeds 926, event streams 928, event updates 930, etc., to one or more databases, which may communicate with one or more streaming data source computers coupled to computer system 900.

[0185] Computer system 900 can be of various types, including a handheld portable device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a personal computer, a workstation, a mainframe, a kiosk, a server rack, or other data processing system. Because the nature of computers and networks is constantly changing, the description of computer system 900 shown in FIG. 9 is intended as an example only. Many other configurations are possible, having more or fewer components than the system shown in FIG. 9. It should be understood that there are other aspects and / or methods for implementing various examples, based on the disclosure and teachings herein.

[0186] While specific examples have been described, various modifications, variations, alternative constructions, and equivalents are possible. The examples are not limited to operation in any particular data processing environment, but can freely operate in multiple data processing environments. Furthermore, while specific examples have been described using a particular sequence of transactions and steps, it should be apparent to those skilled in the art that this is not intended to be limiting. While some flowcharts describe operations as a sequential process, many of these operations may be performed in parallel or simultaneously. Also, the order of operations may be rearranged. A process may have additional steps not included in the figures. Various features and aspects of the above examples may be used individually or together.

[0187] Furthermore, while particular examples have been described using particular combinations of hardware and software, it should be recognized that other combinations of hardware and software are possible. Particular examples may be implemented exclusively in hardware, exclusively in software, or using a combination thereof. The various processes described herein may be implemented on the same processor in any combination, or on different processors in any combination.

[0188] Although a device, system, component, or module is described as being configured to perform particular operations or functions, such configuration may be implemented by, for example, designing electronic circuitry to perform the operations, such as by executing computer instructions or code, or a processor or core programmed to execute code or instructions stored on a non-transitory memory medium. The communication may be achieved by programming a programmable electronic circuit (such as a microprocessor), or by any combination thereof. Processes may communicate using a variety of techniques, including but not limited to conventional techniques for inter-process communication, and different process pairs may use different techniques, and the same process pair may use different techniques at different times.

[0189] Specific details are provided in this disclosure to provide a thorough understanding of the examples. However, the examples can be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques are shown without unnecessary detail to avoid obscuring the examples. This description provides only illustrative examples and is not intended to limit the scope, applicability, or configuration of other examples. Rather, the above description of the examples will provide one skilled in the art with an enabling description for implementing various examples. Various changes may be made in the function and arrangement of elements.

[0190] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other modifications and alterations may be made therein without departing from the broader spirit and scope of the appended claims. Accordingly, although particular examples have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

[0191] While the foregoing specification describes aspects of the disclosure with reference to specific examples thereof, those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above disclosure may be used individually or together. Moreover, the examples may be utilized in many environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense.

[0192] In the above description, the methods have been described in a particular order for purposes of illustration. It should be understood that, in alternative examples, the methods may be performed in an order different from that described. It should also be understood that the methods described above may be performed by hardware components or embodied in a sequence of machine-executable instructions that can be used to cause a machine, such as a general-purpose or special-purpose processor or logic circuitry programmed with the instructions, to perform the methods. These machine-executable instructions may be stored on one or more machine-readable media, such as a CD-ROM or other type of optical disk, a floppy diskette, ROM, RAM, EPROM, EEPROM, a magnetic or optical card, flash memory, or other type of machine-readable medium suitable for storing electronic instructions. Alternatively, the methods may be performed by a combination of hardware and software.

[0193] Where a component is described as being configured to perform a particular operation, such configuration may be achieved, for example, by designing electronic circuitry or other hardware to perform the operation, by programming a programmable electronic circuitry (e.g., a microprocessor or other suitable electronic circuitry) to perform the operation, or by any combination thereof.

[0194] Although illustrative examples of the present application have been described in detail herein, it should be understood that the concepts of the present invention may be embodied and utilized in various ways, and the appended claims are intended to be construed to include such modifications except insofar as limited by the prior art.

Claims

1. 1. A method comprising: receiving an utterance and a target domain of the chatbot; generating a sentence embedding for the utterance; obtaining an embedding for each cluster of a plurality of clusters of in-domain utterances associated with the target domain, the embedding for each cluster being an average of sentence embeddings for each in-domain utterance in the cluster, the method further comprising: inputting the sentence embedding for the utterance and the embedding representation for each cluster into a metric learning model, the metric learning model having trained model parameters configured to provide a first probability as to whether the utterance belongs to the target domain, the method further comprising: using the metric learning model to determine similarities or differences between the sentence embedding for the utterance and each embedding for each cluster; using the metric learning model to predict the first probability of whether the utterance belongs to the target domain based on the determined similarities or differences between the sentence embedding for the utterance and each embedding for each cluster; and inputting the sentence embedding for the utterance and the embedding for each cluster into an outlier detection model, wherein the outlier detection model is built with a distance or density algorithm for outlier detection, the method further comprising: using the outlier detection model to determine distance or density deviation between the sentence embedding for the utterance and embedding representations for neighboring clusters; predicting the second probability of whether the utterance belongs to the target domain based on the determined distance or density deviation using the outlier detection model; evaluating the first probability and the second probability to arrive at a final probability as to whether the utterance belongs to the target domain; and classifying the utterance as being in-domain or out-of-domain for the chatbot based on the final probability.

2. The step of obtaining the embedding representation for each cluster includes: obtaining the in-domain utterances based on the target domain; generating sentence embeddings for each in-domain utterance; and inputting the sentence embeddings for each in-domain utterance into an unsupervised clustering model, the unsupervised clustering model being configured to interpret the in-domain utterance to identify the plurality of clusters in the feature space of the in-domain utterances, wherein obtaining the embedding representations for each cluster further comprises: using the unsupervised clustering model to classify the sentence embeddings for each in-domain utterance into one of the plurality of clusters based on similarities and differences between features of the sentence embeddings and features of sentence embeddings in each cluster; calculating a centroid for each cluster of the plurality of clusters; and outputting the embedded representation and the centroid for each cluster of the plurality of clusters.

3. calculating a z-score for the utterance based on the distance or density deviation between the sentence embedding for the utterance and the embedding representations for the neighboring clusters; By applying a sigmoid function to the z-scores, the utterance is compared with the target and determining the second probability as to whether the first or second channel belongs to a main.

4. 10. The method of claim 1, wherein the sentence embedding for the utterance is generated using an embedding model that maps natural language elements, including sentences, words, and n-grams, to sequences of numbers, each of which is represented as a single point in a vector space.

5. the step of determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster comprises: (i) calculating an absolute difference between the sentence embedding for the utterance and each embedded representation for each cluster; (ii) inputting the absolute difference, the sentence embedding for the utterance, and the embedded representation for each cluster into a wide-and-deep learning network, wherein the wide-and-deep learning network comprises a linear model and a deep neural network; and the step of determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster further comprises: (iii) predicting a wide-based probability of whether the utterance belongs to the target domain using the linear model and the absolute difference; and (iv) using the deep neural network, the sentence embedding for the utterance, and the embedded representation for each cluster to determine the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster.

2. The method of claim 1 , wherein predicting the first probability comprises using a final layer of the wide and deep learning network to evaluate the similarity or difference between the wide probability and the sentence embedding for the utterance and each embedding for each cluster.

6. the linear model comprises a plurality of model parameters trained using a set of training data; the training data set includes absolute differences between sentence embeddings for utterances and each embedding representation for each cluster for in-domain utterances from a plurality of domains; During training of the linear model with the set of training data, a hypothesis function is used to learn a linear relationship between the sentence embedding for the utterance and each embedding for each cluster; The method of claim 5 , wherein during training of the linear relationship, the plurality of model parameters are trained to minimize a loss function.

7. the deep learning network comprises a plurality of model parameters trained using a set of training data; the training data set includes sentence embeddings for in-domain utterances from multiple domains; 6. The method of claim 5, wherein during training of the deep learning network with the set of training data, high-dimensional features of the sentence embeddings for the in-domain utterances are converted into low-dimensional vectors, which are then concatenated with features from the in-domain utterances and fed to a hidden layer of the deep neural network, and the values of the low-dimensional vectors are randomly initialized and learned, together with the plurality of model parameters, to minimize a loss function.

8. 1. A computer program product tangibly embodied in a non-transitory machine-readable storage medium, the non-transitory machine-readable storage medium including instructions configured to cause one or more data processors to perform actions, the actions including: receiving an utterance and a target domain for the chatbot; generating a sentence embedding for the utterance; and obtaining an embedding for each cluster of a plurality of clusters of in-domain utterances associated with the target domain, the embedding for each cluster being an average of sentence embeddings for each in-domain utterance in the cluster, the actions further comprising: inputting the sentence embeddings for the utterance and the embedding representations for each cluster into a metric learning model, the metric learning model having trained model parameters configured to provide a first probability as to whether the utterance belongs to the target domain, and the actions further include: using the metric learning model to determine similarities or differences between the sentence embedding for the utterance and each embedding for each cluster; using the metric learning model to predict the first probability of whether the utterance belongs to the target domain based on the determined similarities or differences between the sentence embedding for the utterance and each embedding for each cluster; and and inputting the sentence embeddings for the utterance and the embedding representations for each cluster into an outlier detection model, wherein the outlier detection model is built with a distance or density algorithm for outlier detection, and the actions further include: using the outlier detection model to determine distance or density deviation between the sentence embedding for the utterance and embedding representations for neighboring clusters; predicting the second probability of whether the utterance belongs to the target domain based on the determined distance or density deviation using the outlier detection model; and evaluating the first probability and the second probability to determine a final probability as to whether the utterance belongs to the target domain; and classifying the utterance as being in-domain or out-of-domain for the chatbot based on the final probability.

9. Obtaining the embedding representation for each cluster includes: obtaining the in-domain utterance based on the target domain; generating a sentence embedding for each in-domain utterance; and inputting the sentence embeddings for each in-domain utterance into an unsupervised clustering model, the unsupervised clustering model being configured to interpret the in-domain utterance to identify the plurality of clusters in the feature space of the in-domain utterances, and obtaining the embedding representations for each cluster further comprises: using the unsupervised clustering model to classify the sentence embeddings for each in-domain utterance into one of the plurality of clusters based on similarities and differences between features of the sentence embeddings and features of sentence embeddings in each cluster; calculating a centroid for each cluster of the plurality of clusters; and outputting the embedded representation and the centroid for each cluster of the plurality of clusters.

10. The action is calculating a z-score for the utterance based on the distance or density deviation between the sentence embedding for the utterance and the embedding representations for the neighboring clusters; and determining the second probability as to whether the utterance belongs to the target domain by applying a sigmoid function to the z-score.

11. The sentence embedding for the utterance may be a set of natural language elements including sentences, words, and n-grams.

9. The computer program product of claim 8, wherein the natural language elements are generated using an embedding model that maps to sequences of numbers, each of the natural language elements being represented as a single point in a vector space.

12. determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster comprises: (i) calculating an absolute difference between the sentence embedding for the utterance and each embedded representation for each cluster; (ii) inputting the absolute difference, the sentence embedding for the utterance, and the embedded representation for each cluster into a wide-and-deep learning network, the wide-and-deep learning network comprising a linear model and a deep neural network; determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster further comprises: (iii) predicting a wide-based probability of whether the utterance belongs to the target domain using the linear model and the absolute difference; and (iv) determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster using the deep neural network, the sentence embedding for the utterance, and the embedded representation for each cluster.

9. The method of claim 8, wherein predicting the first probability comprises using a final layer of the wide and deep learning network to evaluate the similarity or difference between the wide probability and the sentence embedding for the utterance and each embedding for each cluster.

13. the linear model comprises a plurality of model parameters trained using a set of training data; the training data set includes absolute differences between sentence embeddings for utterances and each embedding representation for each cluster for in-domain utterances from a plurality of domains; During training of the linear model with the set of training data, a hypothesis function is used to learn a linear relationship between the sentence embedding for the utterance and each embedding for each cluster; The method of claim 12 , wherein during training of the linear relationship, the plurality of model parameters are trained to minimize a loss function.

14. the deep learning network comprises a plurality of model parameters trained using a set of training data; the training data set includes sentence embeddings for in-domain utterances from multiple domains; 13. The method of claim 12, wherein during training of the deep learning network with the set of training data, high-dimensional features of the sentence embeddings for the in-domain utterances are converted into low-dimensional vectors, which are then concatenated with features from the in-domain utterances and fed to a hidden layer of the deep neural network, and the values of the low-dimensional vectors are randomly initialized and learned, together with the plurality of model parameters, to minimize a loss function.

15. 1. A system comprising: one or more data processors; a non-transitory computer-readable storage medium comprising instructions that, when executed on the one or more data processors, cause the one or more data processors to perform actions, the actions including: receiving an utterance and a target domain for the chatbot; generating a sentence embedding for the utterance; and obtaining an embedding for each cluster of a plurality of clusters of in-domain utterances associated with the target domain, the embedding for each cluster being an average of sentence embeddings for each in-domain utterance in the cluster, the actions further comprising: inputting the sentence embeddings for the utterance and the embedding representations for each cluster into a metric learning model, the metric learning model having trained model parameters configured to provide a first probability as to whether the utterance belongs to the target domain, and the actions further include: using the metric learning model to determine similarities or differences between the sentence embedding for the utterance and each embedding for each cluster; using the metric learning model to predict the first probability of whether the utterance belongs to the target domain based on the determined similarities or differences between the sentence embedding for the utterance and each embedding for each cluster; and and inputting the sentence embeddings for the utterance and the embedding representations for each cluster into an outlier detection model, wherein the outlier detection model is built with a distance or density algorithm for outlier detection, and the actions further include: using the outlier detection model to determine distance or density deviation between the sentence embedding for the utterance and embedding representations for neighboring clusters; predicting the second probability of whether the utterance belongs to the target domain based on the determined distance or density deviation using the outlier detection model; and evaluating the first probability and the second probability to determine a final probability as to whether the utterance belongs to the target domain; and classifying the utterance as being in-domain or out-of-domain for the chatbot based on the final probability.

16. Obtaining the embedding representation for each cluster includes: obtaining the in-domain utterance based on the target domain; generating a sentence embedding for each in-domain utterance; and inputting the sentence embeddings for each in-domain utterance into an unsupervised clustering model, the unsupervised clustering model being configured to interpret the in-domain utterance to identify the plurality of clusters in the feature space of the in-domain utterances, and obtaining the embedding representations for each cluster further comprises: using the unsupervised clustering model to classify the sentence embeddings for each in-domain utterance into one of the plurality of clusters based on similarities and differences between features of the sentence embeddings and features of sentence embeddings in each cluster; calculating a centroid for each cluster of the plurality of clusters; and outputting the embedded representation and the centroid for each cluster of the plurality of clusters.

17. The action is calculating a z-score for the utterance based on the distance or density deviation between the sentence embedding for the utterance and the embedding representations for the neighboring clusters; 16. The system of claim 15, further comprising: determining the second probability as to whether the utterance belongs to the target domain by applying a sigmoid function to the z-score.

18. The sentence embedding for the utterance is generated using an embedding model that maps natural language elements, including sentences, words, and n-grams, to sequences of numbers, and each of the natural language elements 16. The system of claim 15, wherein each is represented as a single point in vector space.

19. determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster comprises: (i) calculating an absolute difference between the sentence embedding for the utterance and each embedded representation for each cluster; (ii) inputting the absolute difference, the sentence embedding for the utterance, and the embedded representation for each cluster into a wide-and-deep learning network, the wide-and-deep learning network comprising a linear model and a deep neural network; determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster further comprises: (iii) predicting a wide-based probability of whether the utterance belongs to the target domain using the linear model and the absolute difference; and (iv) determining the similarity or difference between the sentence embedding for the utterance and each embedded representation for each cluster using the deep neural network, the sentence embedding for the utterance, and the embedded representation for each cluster.

16. The system of claim 15, wherein predicting the first probability comprises using a final layer of the wide and deep learning network to evaluate the similarity or difference between the wide probability and the sentence embedding for the utterance and each embedding for each cluster.

20. the linear model comprises a plurality of model parameters trained using a set of training data; the training data set includes absolute differences between sentence embeddings for utterances and each embedding representation for each cluster for in-domain utterances from a plurality of domains; During training of the linear model with the set of training data, a hypothesis function is used to learn a linear relationship between the sentence embedding for the utterance and each embedding for each cluster; During training of the linear relationship, the plurality of model parameters are trained to minimize a first loss function; the deep learning network comprises a plurality of model parameters trained using the set of training data; 20. The system of claim 19, wherein during training of the deep learning network with the set of training data, high-dimensional features of the sentence embeddings for the in-domain utterances are converted into low-dimensional vectors, which are then concatenated with features from the in-domain utterances and fed to a hidden layer of the deep neural network, and values of the low-dimensional vectors are randomly initialized and learned, together with the plurality of model parameters, to minimize a loss function.

Citation Information

Patent Citations

  • Training device for domain verifier, domain verifying device for input data, and computer program

    JP2005164836A

  • Detection device, speech recognition device, detection method and program

    JP2010191046A

  • Orphan speech detection system and method

    JP2017534941A

  • Dialog system, method, and program

    JP2018147189A

  • Information processing apparatus, information processing method, and information processing program

    JP2019046019A