Patent Application
20240135116
The present disclosure relates generally to artificial intelligence (AI) techniques, and more particularly, to building and using a multi-lingual multi-task (MLMT) machine learning (ML) model that can predict the sentiment of input utterances in a plurality of different languages using a plurality of different task-based approaches.
Artificial intelligence has many applications. For example, an intelligent bot, powered by artificial intelligence, can communicate more intelligently and contextually in live conversations, and thus may allow for a more natural conversation between the bot and the end users. Instead of the end user learning a fixed set of keywords or commands that the bot knows how to respond to, an intelligent bot may be able to understand the end user's intention and/or sentiment based upon user utterances in natural language and respond accordingly.
Machine learning (ML) is an area of artificial intelligence where computers have the capability to learn without being explicitly programmed. There are different types of ML techniques including supervised learning techniques, unsupervised learning techniques, and others. In a supervised learning technique, an ML model is created and trained using training data, where the training data includes multiple training examples, each training example including an input and a known output corresponding to the input (e.g., a ground truth). Models trained using supervised learning techniques are typically used to solve two types of tasks: a classification task or a regression task. For a classification task, as a part of the training, a model learns a function that maps an input to an output value, where the output value is from a discrete set of classes (or class labels). Accordingly, in a classification problem, the model learns to map an input to one or more of the classes in a set of discrete classes. For a regression task, the model learns a function that maps inputs to continuous output values (e.g., continuous real numbers).
In an unsupervised learning technique, an ML model is created and provided with unlabeled data, and is tasked to analyze and find patterns in the unlabeled data. The examples of unsupervised learning technique are dimension reduction and clustering.
Recently, the ML techniques have been proposed to perform sentiment analysis on the documents. Sentiment analysis is the process of analyzing digital text to determine the emotional tone of the message, e.g., if the tone is positive, negative, mixed, or neutral. For instance, sentiment analysis may be performed on social media to determine overall opinion on a particular trending topic. As another example, companies can utilize sentiment analysis to monitor brand reputation across large volumes of text data, e.g., emails, customer support chat transcripts, social media, reviews, etc.
However, the related art ML techniques used for sentiment analysis using different algorithms are unavailable in different languages, at least partially due to the lack of sufficient amount of annotated training data in the different foreign languages.
Techniques disclosed herein relate generally to artificial intelligence techniques, and more particularly, to building and using an MLMT model that can predict the sentiment of input utterances in a plurality of different languages using a plurality of different task-based approaches. More specifically and without limitation, techniques disclosed herein relate to techniques for data augmentation and weighted batch balancing for building an MLMT that can predict the sentiment for an input text.
In various embodiments, a computer-implemented method is provided that includes: accessing a plurality of datasets, where each dataset of the plurality of datasets includes training examples; generating training batches including the training examples, where the generating includes: selecting datasets among the plurality of datasets that include the training examples in a source language and a target language, and sampling, based on a sampling weight that is determined for each of the selected datasets, the training examples from the selected datasets to generate the training batches, where the sampling weight is determined for each of the selected datasets based on one or more attributes common to the training examples of the selected dataset, the one or more attributes including at least one among a language identifier, a translation source origin, and a presence of labels; training a machine learning (ML) model for performing at least a first task using the training examples of the training batches, where the training includes: interleavingly inputting the training batches to the ML model, evaluating, using a first loss, performance of at least the first task by the ML model on the training examples of the training batches, and updating, using an optimization function, model parameters of the ML model based on the performance of the at least the first task; and outputting the trained ML model configured to perform the at least the first task on input utterances in the source language and/or the target language.
In some embodiments, the plurality of datasets includes a labeled source language dataset including source language sentences in the source language and corresponding labels, as the training examples of the labeled source language dataset, where the computer-implemented method further includes: prior to accessing the plurality of datasets, inputting into an ML translation model, the source language sentences and the corresponding labels, where the ML translation model is configured to translate the source language sentences from the source language into the target language, and obtaining a labeled machine-translated target language dataset based on an output provided by the ML translation model. The labeled machine-translated target language dataset may be included in the plurality of datasets and includes machine-translated target language sentences in the target language and corresponding labels, as the training examples of the labeled machine-translated target language dataset.
In some embodiments, the plurality of datasets further includes a labeled target language dataset including human-created target language sentences in the target language and corresponding labels, as the training examples of the labeled target language dataset, where the sampling the training examples includes: sampling the training examples from the labeled source language dataset, to generate one or more labeled source language training batches, sampling the training examples from the labeled target language dataset, to generate one or more labeled target language training batches, and sampling the training examples from the labeled machine-translated target language dataset, to generate one or more labeled machine-translated target language training batches, where the sampling weight for the labeled target language dataset is greater than the sampling weight for the labeled machine-translated target language dataset, which results in a greater number of the training examples sampled from the labeled target language dataset as compared to a number of the training examples sampled from the labeled machine-translated target language dataset. The ML model may be trained using the training examples from the one or more labeled source language training batches, the one or more labeled target language training batches, and the one or more labeled machine-translated target language training batches.
In some embodiments, obtaining the labeled machine-translated target language dataset includes: identifying, in at least one of the source language sentences, a multi-word sequence in the source language; identifying, in at least one of the machine-translated target language sentences that corresponds to the at least one of the source language sentences, respective words in the target language that correspond to the multi-word sequence; determining whether the labels of the machine-translated target language sentences correctly identify the respective words in the target language; and based on the determining that the labels of the machine-translated target language sentences do not correctly identify the respective words, correcting an alignment of the labels of the machine-translated target language sentences to correctly identify the respective words in the target language.
In some embodiments, the plurality of datasets further includes an unlabeled bilingual sentence pairs dataset including unlabeled bilingual sentence pairs in the source language and the target language, as the training examples of the unlabeled bilingual sentence pairs dataset, and a labeled target language dataset including human-created target language sentences in the target language and corresponding labels, as the training examples of the labeled target language dataset, where the sampling the training examples includes: sampling the training examples from a set of labeled datasets including the labeled source language dataset, the labeled target language dataset, and the labeled machine-translated target language dataset, to generate one or more labeled training batches, each of the one or more labeled training batches including the training examples from one of the labeled source language dataset, the labeled target language dataset, or the labeled machine-translated target language dataset, and sampling the training examples from the unlabeled bilingual sentence pairs dataset, to generate one or more unlabeled training batches, where the sampling weight for sampling the training examples from the set of labeled datasets is greater than the sampling weight for sampling the training examples from the unlabeled bilingual sentence pairs dataset, which results in a greater number of the training examples being sampled from the set of labeled datasets as compared to a number of the training examples sampled from the unlabeled bilingual sentence pairs dataset. The ML model is trained using the training examples from at least one among (i) the one or more labeled training batches and (ii) the one or more unlabeled training batches, where the computer-implemented method further includes: when the ML model is trained using the one or more of the labeled training batches, updating the model parameters by minimizing the first loss, which is a cross entropy loss function, and when the ML model is trained using the one or more of the unlabeled training batches, updating the model parameters by minimizing a second loss, which is a Kullback-Leibler divergence function.
In some embodiments, the ML model is a multi-task model trained for performing the first task and a second task, the first task is an aspect-based sentiment analysis (ABSA) task configured to predict a sentiment of the input utterances based on an aspect in the input utterances, the second task is a sentence-level sentiment analysis (SLSA) task configured to predict a sentiment of the input utterances based on per sentence sentiment of the input utterances, and the sampling the training examples includes: sampling the training examples from the selected datasets to generate a set of ABSA training batches including ABSA training examples for training the ML model on the ABSA task, and sampling the training examples from the selected datasets to generate a set of SLSA training batches including SLSA training examples for training the ML model on the SLSA task. The ML model may be trained on the ABSA task using the ABSA training examples and on the SLSA task using the SLSA training examples, where the set of ABSA training batches and the set of SLSA training batches are interleavingly provided to the ML model.
In some embodiments, the computer-implemented method further includes: when the ML model is trained using the training examples of the set of ABSA training batches, updating the model parameters by minimizing the first loss; and when the ML model is trained using the training examples of the set of SLSA training batches, updating the model parameters by minimizing a second loss.
In various embodiments, a computer system is provided that includes one or more processors and one or more computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform part or all of the operations and/or methods disclosed herein.
In various embodiments, one or more non-transitory computer-readable media are provided that store instructions that, when executed by one or more processors of a computer system, cause the one or more processors to perform part or all of the operations and/or methods disclosed herein.
The techniques described herein may be implemented in a number of ways and in a number of contexts. Several example implementations and contexts are provided with reference to the following figures, as described below in more detail. However, the following implementations and contexts are but a few of many.
In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of certain embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. The figures and description are not intended to be restrictive. 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.
Techniques disclosed herein relate generally to artificial intelligence techniques, and more particularly, to building an MLMT model that can predict the sentiment for input utterances, e.g., text, in a plurality of different languages using a plurality of different task-based approaches. The disclosed techniques are for data augmentation and weighted batch balancing for building a robust an MLMT that can predict the sentiment for input utterances in a plurality of different languages using a plurality of different task-based approaches with high accuracy and improved latency.
Sentiment analysis is the process of analyzing digital text to determine if the emotional tone of the message is positive, negative, mixed, or neutral. For instance, sentiment analysis may be performed on social media to determine overall opinion on a particular trending topic. As another example, companies can utilize sentiment analysis to monitor brand reputation across large volumes of text data, e.g., emails, customer support chat transcripts, social media, reviews, etc.
Recently, the ML techniques have been proposed to perform sentiment analysis on the documents. In implementations, where an ML model is used to predict sentiment based on input text, the ML model has to be first trained using training data. A trained model can then be used to predict sentiments within real documents.
The performance of an ML model is only as good as its training. To properly train a model that can accurately and reliably predict sentiment in different languages, a large amount of training data is needed to ensure that the model is accurate and reliable in predicting sentiments from utterances and/or documents. The training data also has to be diverse covering various situations and different types of expressions. The availability of such training data is presently very limited for some languages. There are several reasons for this. A large volume of diverse training documents covering diverse situations is not easily available in low-resource languages. Additionally, each training document has to be annotated (e.g., labeled). These annotations are typically done manually. This is a very tedious and time-consuming task.
For example, while significant labeled training data is available for English, very limited high quality labeled training data is presently available for Spanish, Hindu, etc. As a result, training data that is typically available for training models to predict sentiment in low-resource languages is limited and non-diverse, leading to deficient training of the ML models, which in turn leads to degraded performance (e.g., accuracy) of the models. While efforts are being made to increase both the volume and quality of such training data using automated techniques, these efforts are still quite deficient, very time and resource intensive, and not scalable. These limitations present a big hurdle in generating accurate and reliable models for predicting sentiments from documents in low-resource languages.
One approach in creating a multi-lingual model is to start with a model trained to predict sentiment classes in a high-resource language (e.g., English) and refine the model to predict sentiments in a low-resource language, e.g., a target language. However, a fewer number of training examples in the low-resource language creates an imbalance in the training data that leads to inaccuracies of predictions.
Another approach is to generate more training data in the target language. Such training data may be generated by humans by manually labeling training examples and/or translating a previously existing labeled dataset from one language to another (e.g., English to Spanish). However, this approach has limited effectiveness and is cost and resource intensive. Additionally, such training data lacks diversity.
In order to overcome the above-noted problems and others, various embodiments are for building a high-accuracy and low-latency multi-lingual multi-task (MLMT) model for sentiment analysis by implementing various augmentation methods that increase the size and diversity of the training data in both the source language and the target language.
The disclosed techniques improve imbalance in the size of the labeled training data available for the high-resource language and the low-resource language (e.g., target language) by providing a greater number of the training examples available in the low-resource language, by augmenting the available human-created training examples in the target language with machine-translated training examples in the target language. Further, the disclosed techniques are scalable to any pair of different languages.
For example, in various embodiments, the labeled training examples available in the low-resource language are supplemented by the labeled machine-translated training examples. Further, the labeled training examples available in the high-resource language and the low-resource language may be supplemented by the unlabeled training examples.
The disclosed techniques also improve a diversity of training examples by using training examples designed to alleviate the partiality of the model, e.g., with respect to predicting sentiments on the text including references to race, ethnicity, etc. For example, the disclosed techniques can also be applied for toxic sentence classification and labelling (e.g., toxic word detection).
The disclosed techniques are further for implementing a hierarchical weighted batch balancing method to sample training examples from different datasets for the model training.
In some embodiments, a weighted batch balancing method can be implemented by creating weight-balanced training batches containing training examples hierarchically sampled with a sampling weight at different levels, from various datasets. For example, a dataset, which is assigned a higher sampling weight, may be sampled more frequently than a dataset with a lower weight, so more training batches containing the training examples from the dataset with a higher sampling weight are generated. The weight-balanced training batches may be then interleavingly provided for the model training.
The weighted batch balancing method creates training batches by interleavingly sampling multiple datasets at different levels (i.e., hierarchically). The different levels can include a task level for the SLSA vs. the ABSA, labeled vs. unlabeled level, and the dataset level including language sources (e.g., source language vs. target language), translation sources (e.g., human translation vs. machine-translated), and invariance types (e.g., unlabeled bilingual sentence pairs, NER debiasing, fairness invariance).
In some embodiments, training batches can be sampled from different sources with different weights. These weights can be hyperparameters for hyper-tuning to achieve the best performance.
The disclosed hierarchical weighted batch balancing method is applicable for any deep learning model that is trained based on the stochastic gradient descent algorithm.
The augmentation and weighted batching techniques disclosed herein create a machine-learning model that can accurately predict the sentiment of an input sentence.
In order to accurately predict the sentiment for low-resource languages, the machine-learning model can be trained using a combination of augmented datasets including unlabeled translation pairs for multi-lingual performance enhancement and unlabeled invariance groups for behavioral performance enhancement.
In various embodiments, a computer-implemented method is provided that includes: accessing a plurality of datasets, where each dataset of the plurality of datasets includes training examples; generating training batches including the training examples, where the generating includes: selecting datasets among the plurality of datasets that include the training examples in a source language and a target language, and sampling, based on a sampling weight that is determined for each of the selected datasets, the training examples from the selected datasets to generate the training batches, where the sampling weight is determined for each of the selected datasets based on one or more attributes common to the training examples of the selected dataset, the one or more attributes including at least one among a language identifier, a translation source origin, and a presence of labels; and training a machine learning (ML) model for performing a first task and a second task using the training examples of the training batches including a set of training batches for training the first task and a set of training batches for training the second task, by interleavingly inputting the set of training batches for training the first task and the set of training batches for training the second task to the ML model, evaluating performance of the first task and the second task by the ML model on the training examples of the respective sets of training batches, and updating, using an optimization function, model parameters of the ML model based on the performance. As a result of the training, the MLMT model is output that is configured to perform the first task and the second task on input utterances in the source language and/or the target language with high levels of accuracy.
The MLMT model of various embodiments can be implemented in chatbots that may perform accurately on sentiment analysis of utterances in various languages.
A. Bot and Analytic Systems
A bot (also referred to as a skill, chatbot, chatterbot, or talkbot) is a computer program that can perform conversations with end users. The bot can generally respond to natural-language messages (e.g., questions or comments) through a messaging application that uses natural-language messages. Enterprises may use one or more bot systems to communicate with end users through a messaging application. The messaging application, which may be referred to as a channel, may be an end user preferred messaging application that the end user has already installed and familiar with. Thus, the end user does not need to download and install new applications in order to chat with the bot system. The messaging application may include, for example, over-the-top (OTT) messaging channels (such as Facebook Messenger, Facebook WhatsApp, WeChat, Line, Kik, Telegram, Talk, Skype, Slack, or SMS), virtual private assistants (such as Amazon Dot, Echo, or Show, Google Home, Apple HomePod, etc.), mobile and web app extensions that extend native or hybrid/responsive mobile applications or web applications with chat capabilities, or voice based input (such as devices or applications with interfaces that use Siri, Cortana, Google Voice, or other speech input for interaction).
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 a messaging application system. The HTTP post call message may be directed to the URI from the messaging application system. In some embodiments, the message may be different from a HTTP post call message. For example, the bot system may receive a message from a Short Message Service (SMS). While discussion herein may refer to communications that the bot system receives as a message, it should be understood that the message may be an HTTP post call message, a SMS message, or any other type of communication between two systems.
End users may interact with the bot system through a conversational interaction (sometimes referred to as a conversational user interface (UI)), just as interactions between people. In some cases, the interaction may include the end user saying “Hello” to the bot and the bot responding with a “Hi” and asking the end user how it can help. In some cases, the interaction may also be a transactional interaction with, for example, a banking bot, such as transferring money from one account to another; an informational interaction with, for example, a HR bot, such as checking for vacation balance; or an interaction with, for example, a retail bot, such as discussing returning purchased goods or seeking technical support.
In some embodiments, the bot system may intelligently handle end user interactions without interaction with an administrator or developer of the bot system. For example, an end user may send one or more messages to the bot system in order to achieve a desired goal. A message may include certain content, such as text, emojis, audio, image, video, or other method of conveying a message. In some embodiments, the bot system may convert the content into a standardized form (e.g., a representational state transfer (REST) call against enterprise services with the proper parameters) and generate a natural language response. The bot system may also prompt the end user for additional input parameters or request other additional information. In some embodiments, the bot system may also initiate communication with the end user, rather than passively responding to end user utterances. Described herein are various techniques for identifying an explicit invocation of a bot system and determining an input for the bot system being invoked. In certain embodiments, explicit invocation analysis is performed by a master bot based on detecting an invocation name in an utterance. In response to detection of the invocation name, the utterance may be refined for input to a skill bot associated with the invocation name.
A conversation with a bot may follow a specific conversation flow including multiple states. The flow may define what would happen next based on an input. In some embodiments, a state machine that includes user defined states (e.g., end user intents) and actions to take in the states or from state to state may be used to implement the bot system. A conversation may take different paths based on the end user input, which may impact the decision the bot makes for the flow. For example, at each state, based on the end user input or utterances, the bot may determine the end user's intent in order to determine the appropriate next action to take. As used herein and in the context of an utterance, the term “intent” refers to an intent of the user who provided the utterance. For example, the user may intend to engage a bot in conversation for ordering pizza, so that the user's intent could be represented through the utterance “Order pizza.” A user intent can be directed to a particular task that the user wishes a chatbot to perform on behalf of the user. Therefore, utterances can be phrased as questions, commands, requests, and the like, that reflect the user's intent. An intent may include a goal that the end user would like to accomplish.
In the context of the configuration of a chatbot, the term “intent” is used herein to refer to configuration information for mapping a user's utterance to a specific task/action or category of task/action that the chatbot can perform. In order to distinguish between the intent of an utterance (i.e., a user intent) and the intent of a chatbot, the latter is sometimes referred to herein as a “bot intent.” A bot intent may include a set of one or more utterances associated with the intent. For instance, an intent for ordering pizza can be communicated by various permutations of utterances that express a desire to place an order for pizza. These associated utterances can be used to train an intent classifier of the chatbot to enable the intent classifier to subsequently determine whether an input utterance from a user matches the order pizza intent. A bot intent may be associated with one or more dialog flows for starting a conversation with the user and in a certain state. For example, the first message for the order pizza intent could be the question “What kind of pizza would you like?” In addition to associated utterances, a bot intent may further include named entities that relate to the intent. For example, the order pizza intent could include variables or parameters used to perform the task of ordering pizza, e.g., topping 1, topping 2, pizza type, pizza size, pizza quantity, and the like. The value of an entity is typically obtained through conversing with the user.
For purposes of this disclosure, a “digital assistant” is an entity that helps users of the digital assistant accomplish various tasks through natural language conversations. A digital assistant can be implemented using software only (e.g., the digital assistant is a digital entity implemented using programs, code, or instructions executable by one or more processors), using hardware, or using a combination of hardware and software. A digital assistant can be embodied or implemented in various physical systems or devices, such as in a computer, a mobile phone, a watch, an appliance, a vehicle, and the like. A digital assistant is also sometimes referred to as a chatbot system. Accordingly, for purposes of this disclosure, the terms digital assistant and chatbot system are interchangeable.
A digital assistant, such as digital assistant 106 built using DABP 102, can be used to perform various tasks via natural language-based conversations between the digital assistant and its users 108. As part of a conversation, a user may provide one or more user inputs 110 to digital assistant 106 and get responses 112 back from digital assistant 106. A conversation can include one or more of inputs 110 and responses 112. Via these conversations, a user can request 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 with appropriate responses to the user.
User inputs 110 are generally in a natural language form and are referred to as utterances. A user utterance 110 can be in text form, such as when a user types in a sentence, a question, a text fragment, or even a single word and provides it as input to digital assistant 106. In some embodiments, a user utterance 110 can be in audio input or speech form, such as when a user says or speaks something that is provided as input to digital assistant 106. The utterances are typically in a language spoken by the user 108. For example, the utterances may be in English, or some other language. When an utterance is in speech form, the speech input is converted to text form utterances in that particular language and the text utterances are then processed by digital assistant 106. Various speech-to-text processing techniques may be used to convert a speech or audio input to a text utterance, which is then processed by digital assistant 106. In some embodiments, the speech-to-text conversion may be done by digital assistant 106 itself.
An utterance, which may be a text utterance or a speech utterance, can be a fragment, a sentence, multiple sentences, one or more words, one or more questions, combinations of the aforementioned types, and the like. 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 for a utterance, digital assistant 106 is configured to perform processing to understand the meaning of the utterance, which involves identifying one or more intents and one or more entities corresponding to the utterance. Upon understanding the meaning of an utterance, digital assistant 106 may perform one or more actions or operations responsive to the understood meaning or intents. For purposes of this disclosure, it is assumed that the utterances are text utterances that have been provided directly by a user 108 of digital assistant 106 or are the results of conversion of input speech utterances to text form. This however is not intended to be limiting or restrictive in any manner.
For example, a user 108 input may request a pizza to be ordered by providing an utterance such as “I want to order a pizza.” Upon receiving such an utterance, digital assistant 106 is configured to understand the meaning of the utterance and take appropriate actions. The appropriate actions may involve, for example, responding to the user with questions requesting user input on the type of pizza the user desires to order, the size of the pizza, any toppings for the pizza, and the like. The responses provided by digital assistant 106 may also be in natural language form and typically in the same language as the input utterance. As part of generating these responses, digital assistant 106 may perform natural language generation (NLG). For the user ordering a pizza, via the conversation between the user and digital assistant 106, the digital assistant may guide the user to provide all the requisite information for the pizza order, and then at the end of the conversation cause the pizza to be ordered. Digital assistant 106 may end the conversation by outputting information to the user indicating that the pizza has been ordered.
At a conceptual level, digital assistant 106 performs various processing in response to an utterance received from a user. In some embodiments, this processing involves 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 be performed in response to the utterance, where appropriate causing the action to be performed, generating a response to be output to the user responsive to the user utterance, outputting the response to the user, and the like. The NLU processing can include parsing the received input utterance to understand the structure and meaning of the utterance, refining and reforming the utterance to develop a better understandable form (e.g., logical form) or structure for the utterance. Generating a response may include using NLG techniques.
The NLU processing performed by a digital assistant, such as digital assistant 106, can include various NLP related processing such as sentence parsing (e.g., tokenizing, lemmatizing, identifying part-of-speech tags for the sentence, identifying named entities in the sentence, generating dependency trees to represent the sentence structure, splitting a sentence into clauses, analyzing individual clauses, resolving anaphoras, performing chunking, and the like). In certain embodiments, the NLU processing or portions thereof is performed by digital assistant 106 itself. In some other embodiments, digital assistant 106 may use other resources to perform portions of the NLU processing. For example, the syntax and structure of an input utterance 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 the English language, a parser, a part-of-speech tagger, and a named entity recognizer such as ones provided by the Stanford Natural Language Processing (NLP) Group are used for analyzing the sentence structure and syntax. These are provided as part of the Stanford CoreNLP toolkit.
While the various examples provided in this disclosure show utterances in the English language, this is meant only as an example. In certain embodiments, digital assistant 106 is also capable of handling utterances in languages other than English. Digital assistant 106 may provide subsystems (e.g., components implementing NLU functionality) that are configured for performing processing for different languages. These subsystems may be implemented as pluggable units that can be called using service calls from an NLU core server. This makes the NLU processing flexible and extensible for each language, including allowing different orders of processing. A language pack may be provided for individual languages, where a language pack can register a list of subsystems that can be served from the NLU core server.
A digital assistant, such as digital assistant 106 depicted in
A digital assistant or chatbot system generally contains or is associated with one or more skills. In certain embodiments, these skills are individual chatbots (referred to as skill bots) that are configured to interact with users and fulfill specific types of tasks, such as tracking inventory, submitting timecards, creating expense reports, ordering food, checking a bank account, making reservations, buying a widget, and the like. For example, for the embodiment depicted in
Each skill associated with a digital assistant helps a user of the digital assistant complete a task through a conversation with the user, where the conversation can include a combination of text or audio inputs provided by the user and responses provided by the skill bots. These responses may be in the form of text or audio messages to the user and/or using user interface elements (e.g., select lists) that are presented to the user for the user to make selections.
There are various ways in which a skill or skill bot can be associated or added to a digital assistant. In some instances, a skill bot can be developed by an enterprise and then added to a digital assistant using DABP 102. In other instances, a skill bot can be developed and created using DABP 102 and then added to a digital assistant created using DABP 102. In yet other instances, DABP 102 provides an online digital store (referred to as a “skills store”) that offers multiple skills directed to a wide range of tasks. The skills offered through the skills store may also expose various cloud services. In order to add a skill to a digital assistant being generated using DABP 102, a user of DABP 102 can access the skills store via DABP 102, select a desired skill, and indicate that the selected skill is to be added to the digital assistant created using DABP 102. A skill from the skills store can be added to a digital assistant as is or in a modified form (for example, a user of DABP 102 may select and clone a particular skill bot provided by the skills store, make customizations or modifications to the selected skill bot, and then add the modified skill bot to a digital assistant created using DABP 102).
Various different architectures may be used to implement a digital assistant or chatbot system. For example, in certain embodiments, the digital assistants created and deployed using DABP 102 may be implemented using a master bot/child (or sub) bot paradigm or architecture. According to this paradigm, a digital assistant is implemented as a master bot that interacts with one or more child bots that are skill bots. For example, in the embodiment depicted in
A digital assistant implemented according to the master-child bot architecture enables users of the digital assistant to interact with multiple skills through a unified user interface, namely via the master bot. When a user engages with a digital assistant, the user input is received by the master bot. The master bot then performs processing to determine the meaning of the user input utterance. The master bot then determines whether the task requested by the user in the utterance can be handled by the master bot itself, else the master bot selects an appropriate skill bot for handling the user request and routes the conversation to the selected skill bot. This enables a user to converse with the digital assistant through a common single interface and still provide the capability to use several skill bots configured to perform specific tasks. For example, for a digital assistance developed for an enterprise, the master bot of the digital assistant may interface with skill bots with specific functionalities, 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), an HCM bot for performing functions related to human capital management (HCM), etc. This way the end user or consumer of the digital assistant need only know how to access the digital assistant through the common master bot interface and behind the scenes multiple skill bots are provided for handling the user request.
In certain embodiments, in a master bot/child bots infrastructure, the master bot is configured to be aware of the available list of skill bots. The master bot may have access to metadata that identifies the various available skill bots, and for each skill bot, the capabilities of the skill bot including the tasks that can be performed by the skill bot. Upon receiving a user request in the form of an utterance, the master bot is configured to, from the multiple available skill bots, identify or predict a specific skill bot that can best serve or handle the user request. The master bot then routes the utterance (or a portion of the utterance) to that specific skill bot for further handling. Control thus flows from the master bot to the skill bots. The master bot can support multiple input and output channels. In certain embodiments, routing may be performed with the aid of processing performed by one or more available skill bots. For example, as discussed below, a skill bot can be trained to infer an intent for an utterance and to determine whether the inferred intent matches an intent with which the skill bot is configured. Thus, the routing performed by the master bot can involve the skill bot communicating to the master bot an indication of whether the skill bot has been configured with an intent suitable for handling the utterance.
While the embodiment in
DABP 102 provides an infrastructure and various services and features that enable a user of DABP 102 to create a digital assistant including one or more skill bots associated with the digital assistant. In some instances, a skill bot can be created by cloning an existing skill bot, for example, cloning a skill bot provided by the skills store. As previously indicated, DABP 102 provides a skills store or skills catalog that offers multiple skill bots for performing various tasks. A user of DABP 102 can clone a skill bot from the skills store. As needed, modifications or customizations may be made to the cloned skill bot. In some other instances, a user of DABP 102 created a skill bot from scratch using tools and services offered by DABP 102. As previously indicated, the skills store or skills catalog provided by DABP 102 may offer multiple skill bots for performing various tasks.
In certain embodiments, at a high level, creating or customizing a skill bot involves the following steps:
Each of the above steps is briefly described below.
(1) Configuring settings for a new skill bot—Various settings may be configured for the skill bot. For example, a skill bot designer can specify one or more invocation names for the skill bot being created. These invocation names can then be used by users of a digital assistant to explicitly invoke the skill bot. For example, a user can input an invocation name in the user's utterance to explicitly invoke the corresponding skill bot.
(2) Configuring one or more intents and associated example utterances for the skill bot—The skill bot designer specifies one or more intents (also referred to as bot intents) for a skill bot being created. The skill bot is then trained based upon these specified intents. These intents represent categories or classes that the skill bot is trained to infer for input utterances. Upon receiving an utterance, a trained skill bot infers an intent for the utterance, where the inferred intent is selected from the predefined set of intents used to train the skill bot. The skill bot then takes an appropriate action responsive to an utterance based upon the intent inferred for that utterance. In some instances, the intents for a skill bot represent tasks that the skill bot can perform for users of the digital assistant. Each intent is given an intent identifier or intent name. For example, for a skill bot trained for a bank, the intents specified for the skill bot may include “CheckBalance,” “TransferMoney,” “DepositCheck,” and the like.
For each intent defined for a skill bot, the skill bot designer may also provide one or more example utterances that are representative of and illustrate the intent. These example utterances are meant to represent utterances that a user may input to the skill bot for that intent. For example, for the CheckBalance intent, example utterances may include “What's my savings account balance?”, “How much is in my checking account?”, “How much money do I have in my account,” and the like. Accordingly, various permutations of typical user utterances may be specified as example utterances for an intent.
The intents and their associated example utterances are used as training data to train the skill bot. Various different training techniques may be used. As a result of this training, a prediction model is generated that is configured to take an utterance as input and output an intent inferred for the utterance by the prediction model. In some instances, input utterances are provided to an intent analysis engine, which is configured to use the trained model to predict or infer an intent for the input utterance. The skill bot may then take one or more actions based upon the inferred intent.
(3) Configuring entities for one or more intents of the skill bot—In some instances, additional context may be needed to enable the skill bot to properly respond to a user utterance. For example, there may be situations where a user input utterance resolves to the same intent in a skill bot. For instance, in the above example, utterances “What's my savings account balance?” and “How much is in my checking account?” both resolve to the same CheckBalance intent, but these utterances are different requests asking for different things. To clarify such requests, one or more entities are added to an intent. Using the banking skill bot example, an entity called AccountType, which defines values called “checking” and “saving” may enable the skill bot to parse the user request and respond appropriately. In the above example, while the utterances resolve to the same intent, the value associated with the AccountType entity is different for the two utterances. This enables the skill bot to perform possibly different actions for the two utterances in spite of them resolving to the same intent. One or more entities can be specified for certain intents configured for the skill bot. Entities are thus used to add context to the intent itself. Entities help describe an intent more fully and enable the skill bot to complete a user request.
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 a 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, without limitation, entities related to time, date, addresses, numbers, email addresses, duration, recurring time periods, currencies, phone numbers, URLs, and the like. Custom entities are used for more customized applications. For example, for a banking skill, an AccountType entity may be defined by the skill bot designer that enables various banking transactions by checking the user input for keywords like checking, savings, and credit cards, etc.
(4) Training the skill bot—A skill bot is configured to receive user input in the form of utterances parse or otherwise process the received input, and identify or select an intent that is relevant to the received user input. As indicated above, the skill bot has to be trained for this. In certain embodiments, a skill bot is trained based upon the intents configured for the skill bot and the example utterances associated with the intents (collectively, the training data), so that the skill bot can resolve user input utterances to one of its configured intents. In certain embodiments, the skill bot uses a prediction model that is trained using the training data and allows the skill bot to discern what users say (or in some cases, are trying to say). DABP 102 provides various different training techniques that can be used by a skill bot designer to train a skill bot, including various machine-learning based training techniques, rules-based training techniques, and/or combinations thereof. In certain embodiments, a portion (e.g., 80%) of the training data is used to train a skill bot model and another portion (e.g., the remaining 20%) is used to test or verify the model. Once trained, the trained model (also sometimes referred to as the trained skill bot) can then be used to handle and respond to user utterances. In certain cases, a user's utterance may be a question that requires only a single answer and no further conversation. In order to handle such situations, a Q&A (question-and-answer) intent may be defined for a skill bot. This enables a skill bot to output replies to user requests without having to update the dialog definition. Q&A intents are created in a similar manner as regular intents. The dialog flow for Q&A intents can be different from that for regular intents.
(5) Creating a dialog flow for the skill bot—A dialog flow specified for a skill bot describes how the skill bot reacts as different intents for the skill bot are resolved responsive to received user input. The dialog flow defines operations or actions that a skill bot will take, e.g., how the skill bot responds to user utterances, how the skill bot prompts users for input, how the skill bot returns data. A dialog flow is like a flowchart that is followed by the skill bot. The skill bot designer specifies a dialog flow using a language, such as markdown language. In certain embodiments, a version of YAML called OBotML may be used to specify a dialog flow for a skill bot. The dialog flow definition for a skill bot acts as a model for the conversation itself, one that lets the skill bot designer choreograph the interactions between a skill bot and the users that the skill bot services.
In certain embodiments, the dialog flow definition for a skill bot contains three sections:
Context section—The skill bot designer can define variables that are used in a conversation flow in the context section. Other variables that may be named in the context section include, without limitation: variables for error handling, variables for built-in or custom entities, user variables that enable the skill bot to recognize and persist user preferences, and the like.
Default transitions section—Transitions for a skill bot can be defined in the dialog flow states section or in the default transitions section. The transitions defined in the default transition section act as a fallback and get triggered when there are no applicable transitions defined within a state, or the conditions required to trigger a state transition cannot be met. The default transitions section can be used to define routing that allows the skill bot to gracefully handle unexpected user actions.
States section—A dialog flow and its related operations are defined as a sequence of transitory states, which manage the logic within the dialog flow. Each state node within a dialog flow definition names a component that provides the functionality needed at that point in the dialog. States are thus built around the components. A state contains component-specific properties and defines the transitions to other states that get triggered after the component executes.
Special case scenarios may be handled using the states sections. For example, there might be times when you want to provide users the option to temporarily leave a first skill they are engaged with to do something in a second skill within the digital assistant. For example, if a user is engaged in a conversation with a shopping skill (e.g., the user has made some selections for purchase), the user may want to jump to a banking skill (e.g., the user may want to ensure that he/she has enough money for the purchase), and then return to the shopping skill to complete the user's order. To address this, an action in the first skill can be configured to initiate an interaction with the second different skill in the same digital assistant and then return to the original flow.
(6) Adding custom components to the skill bot—As described above, states specified in a dialog flow for a skill bot name components that provide the functionality needed corresponding to the states. Components enable a skill bot to perform functions. In certain embodiments, DABP 102 provides a set of preconfigured components for performing a wide range of functions. A skill bot designer can select one of more of these preconfigured components and associate them with states in the dialog flow for a skill bot. The skill bot designer can also create custom or new components using tools provided by DABP 102 and associate the custom components with one or more states in the dialog flow for a skill bot.
(7) Testing and deploying the skill bot—DABP 102 provides several features that enable the skill bot designer to test a skill bot being developed. The skill bot can then be deployed and included in a digital assistant.
While the description above describes how to create a skill bot, similar techniques may also be used to create a digital assistant (or the master bot). At the master bot or digital assistant level, built-in system intents may be configured for the digital assistant. These built-in system intents are used to identify general tasks that the digital assistant itself (i.e., the master bot) can handle without invoking a skill bot associated with the digital assistant. Examples of system intents defined for a master bot include: (1) Exit: applies when the user signals the desire to exit the current conversation or context in the digital assistant; (2) Help: applies when the user asks for help or orientation; and (3) UnresolvedIntent: applies to user input that doesn't match well with the exit and help intents. The digital assistant also stores information about the one or more skill bots associated with the digital assistant. This information enables the master bot to select a particular skill bot for handling an utterance.
At the master bot or digital assistant level, when a user inputs a phrase or utterance to the digital assistant, the digital assistant is configured to perform processing to determine how to route the utterance and the related conversation. The digital assistant determines this using a routing model, which can be rules-based, AI-based, or a combination thereof. The digital assistant uses the routing model to determine whether the conversation corresponding to the user input utterance is to be routed to a particular skill for handling, is to be handled by the digital assistant or master bot itself per a built-in system intent, or is to be handled as a different state in a current conversation flow.
In certain embodiments, as part of this processing, the digital assistant determines if the user input utterance explicitly identifies a skill bot using its invocation name. If an invocation name is present in the user input, then it is treated as explicit invocation of the skill bot corresponding to the invocation name. In such a scenario, the digital assistant may route the user input to the explicitly invoked skill bot for further handling. If there is no specific or explicit invocation, in certain embodiments, the digital assistant evaluates the received user input utterance and computes confidence scores for the system intents and the skill bots associated with the digital assistant. The score computed for a skill bot or system intent represents how likely the user input is representative of a task that the skill bot is configured to perform or is representative of a system intent. Any system intent or skill bot with an associated computed confidence score exceeding a threshold value (e.g., a Confidence Threshold routing parameter) is selected as a candidate for further evaluation. The digital assistant then selects, from the identified candidates, a particular system intent or a skill bot for further handling of the user input utterance. In certain embodiments, after one or more skill bots are identified as candidates, the intents associated with those candidate skills are evaluated (according to the intent model for each skill) and confidence scores are determined for each intent. In general, any intent that has a confidence score exceeding a threshold value (e.g., 70%) is treated as a candidate intent. If a particular skill bot is selected, then the user utterance is routed to that skill bot for further processing. If a system intent is selected, then one or more actions are performed by the master bot itself according to the selected system intent.
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 indicated above, an utterance can be provided in various ways including audio or text. The utterance 202 can be a sentence fragment, a complete sentence, multiple sentences, and the like. Utterance 202 can 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) that inserts punctuation marks into the resulting text, e.g., commas, semicolons, periods, etc.
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 handled depends on the language since each language has its own grammar and semantics. Differences between languages are taken into consideration when analyzing the syntax and structure of an utterance.
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, noun (NN), pronoun (PN), verb (VB), and the like. Language parser 214 may also tokenize the linguistic units of the utterance 202 (e.g., to convert each word into a separate token) and lemmatize words. A lemma is the main form of a set of words as represented in a dictionary (e.g., “run” is the lemma for run, runs, ran, running, etc.). Other types of pre-processing that the language parser 214 can perform include chunking of compound expressions, e.g., combining “credit” and “card” into a single expression “credit card.” Language parser 214 may also identify relationships between the words in the utterance 202. For example, in some embodiments, the language parser 214 generates a dependency tree that indicates which part of the utterance (e.g., a particular noun) is a direct object, which part of the utterance is a preposition, and so on. The results of the processing performed by the language parser 214 form extracted information 205 and are provided as input to MIS 220 together with the utterance 202 itself.
As indicated above, the utterance 202 can include more than one sentence. For purposes of detecting multiple intents and explicit invocation, the utterance 202 can be treated as a single unit even if it includes multiple sentences. However, in certain embodiments, pre-processing can be performed, e.g., by the pre-processing subsystem 210, to identify a single sentence among multiple sentences for multiple intents analysis and explicit invocation analysis. In general, the results produced by MIS 220 and EIS 230 are substantially the same regardless of whether the utterance 202 is processed at the level of an individual sentence or as a single unit including multiple sentences.
MIS 220 determines whether the utterance 202 represents multiple intents. Although MIS 220 can detect the presence of multiple intents in the utterance 202, the processing performed by MIS 220 does not involve determining whether the intents of the utterance 202 match to any intents that have been configured for a bot. Instead, processing to determine whether an intent of the utterance 202 matches a bot intent can be performed by an intent classifier 242 of the MB system 200 or by an intent classifier of a skill bot (e.g., as shown in the embodiment of
To determine that the utterance 202 includes multiple intents, the MIS 220 applies one or more rules from a set of rules 252 in the data store 250. The rules applied to the utterance 202 depend on the language of the utterance 202 and may include sentence patterns that indicate the presence of multiple intents. For example, a sentence pattern may include a coordinating conjunction that joins two parts (e.g., conjuncts) of a sentence, where both parts correspond to a separate intent. If the utterance 202 matches the sentence pattern, it can be inferred that the utterance 202 represents multiple intents. It should be noted that an utterance with multiple intents does not necessarily have different intents (e.g., intents directed to different bots or to different intents within the same bot). Instead, the utterance could have separate instances of the same intent, e.g., “Place a pizza order using payment account X, then place a pizza order using payment account Y.”
As part of determining that the utterance 202 represents multiple intents, the MIS 220 also determines what portions of the utterance 202 are associated with each intent. MIS 220 constructs, for each intent represented in an utterance containing multiple intents, a new utterance for separate processing in place of the original utterance, e.g., an utterance “B” 206 and an utterance “C” 208, as depicted in
EIS 230 determines whether the utterance that it receives (e.g., utterance 206 or utterance 208) contains an invocation name of a skill bot. In certain embodiments, each skill bot in a chatbot system is assigned a unique invocation name that distinguishes the skill bot from other skill bots in the chatbot system. A list of invocation names can be maintained as part of skill bot information 254 in data store 250. An utterance is deemed to be an explicit invocation when the utterance contains a word match to an invocation name. If a bot is not explicitly invoked, then the utterance received by the EIS 230 is deemed a non-explicitly invoking utterance 234 and is input to an intent classifier (e.g., intent classifier 242) of the master bot to determine which bot to use for handling the utterance. In some instances, the intent classifier 242 will determine that the master bot should handle a non-explicitly invoking utterance. In other instances, the intent classifier 242 will determine a skill bot to route the utterance to for handling.
The explicit invocation functionality provided by the EIS 230 has several advantages. It can reduce the amount of processing that the master bot has to perform. For example, when there is an explicit invocation, the master bot may not have to do any intent classification analysis (e.g., using the intent classifier 242), or may have to do reduced intent classification analysis for selecting a skill bot. Thus, explicit invocation analysis may enable selection of a particular skill bot without resorting to intent classification analysis.
Also, there may be situations where there is an overlap in functionalities between multiple skill bots. This may happen, for example, if the intents handled by the two skill bots overlap or are very close to each other. In such a situation, it may be difficult for the master bot to identify which of the multiple skill bots to select based upon intent classification analysis alone. In such scenarios, the explicit invocation disambiguates the particular skill bot to be used.
In addition to determining that an utterance is an explicit invocation, the 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 part of the utterance is not associated with the invocation. The EIS 230 can perform this determination through analysis of the utterance and/or analysis of the extracted information 205. EIS 230 can send the part of the utterance not associated with the invocation to the invoked skill bot in lieu of sending the entire utterance that was received by the EIS 230. In some instances, the input to the invoked skill bot is formed simply by removing any portion of the utterance associated with the invocation. For example, “I want to order pizza using Pizza Bot” can be shortened to “I want to order pizza” since “using Pizza Bot” is relevant to the invocation of the pizza bot, but irrelevant to any processing to be performed by the pizza bot. In some instances, EIS 230 may reformat the part to be sent to the invoked bot, e.g., to form a complete sentence. Thus, the EIS 230 determines not only that there is an explicit invocation, but also what to send to the skill bot when there is an explicit invocation. In some instances, there may not be any text to input to the bot being invoked. For example, if the utterance was “Pizza Bot”, then the EIS 230 could determine that the pizza bot is being invoked, but there is no text to be processed by the pizza bot. In such scenarios, the EIS 230 may indicate to the skill bot invoker 240 that there is nothing to send.
Skill bot invoker 240 invokes a skill bot in various ways. For instance, skill bot invoker 240 can invoke a bot in response to receiving an indication 235 that a particular skill bot has been selected as a result of an explicit invocation. The indication 235 can be sent by the EIS 230 together with the input for the explicitly invoked skill bot. In this scenario, the skill bot invoker 240 will turn control of the conversation over to the explicitly invoked skill bot. The explicitly invoked skill bot will determine an appropriate response to the input from the EIS 230 by treating the input as a stand-alone utterance. For example, the response could be to perform a specific action or to start a new conversation in a particular state, where the initial state of the new conversation depends on the input sent from the EIS 230.
Another way in which skill bot invoker 240 can invoke a skill bot is through implicit invocation using the intent classifier 242. The intent classifier 242 can be trained, using machine-learning and/or rules-based training techniques, to determine a likelihood that an utterance is representative of a task that a particular skill bot is configured to perform. The intent classifier 242 is trained on different classes, one class for each skill bot. For instance, whenever a new skill bot is registered with the master bot, a list of example utterances associated with the new skill bot can be used to train the intent classifier 242 to determine a likelihood that a particular utterance is representative of a task that the new skill bot can perform. The parameters produced as result of this training (e.g., a set of values for parameters of a machine-learning model) can be stored as part of skill bot information 254.
In certain embodiments, the intent classifier 242 is implemented using a machine-learning model, as described in further detail herein. Training of the machine-learning model may involve inputting at least a subset of utterances from the example utterances associated with various skill bots to generate, as an output of the machine-learning model, inferences as to which bot is the correct bot for handling any particular training utterance. For each training utterance, an indication of the correct bot to use for the training utterance may be provided as ground truth information. The behavior of the machine-learning model can then be adapted (e.g., through back-propagation) to minimize the difference between the generated inferences and the ground truth information.
In certain embodiments, the intent classifier 242 determines, for each skill bot registered with the master bot, a confidence score indicating a likelihood that the skill bot can handle an utterance (e.g., the non-explicitly invoking utterance 234 received from EIS 230). The intent classifier 242 may also determine a confidence score for each system level intent (e.g., help, exit) that has been configured. If a particular confidence score meets one or more conditions, then the skill bot invoker 240 will invoke the bot associated with the particular confidence score. For example, a threshold confidence score value may need to be met. Thus, an output 245 of the intent classifier 242 is either an identification of a system intent or an identification of a particular skill bot. In some embodiments, in addition to meeting a threshold confidence score value, the confidence score must exceed the next highest confidence score by a certain win margin. Imposing such a condition would enable routing to a particular skill bot when the confidence scores of multiple skill bots each exceed the threshold confidence score value.
After identifying a bot based on evaluation of confidence scores, the skill bot invoker 240 hands over processing to the identified bot. In the case of a system intent, the identified bot is the master bot. Otherwise, the identified bot is a skill bot. Further, the skill bot invoker 240 will determine what to provide as input 247 for the identified bot. As indicated above, in the case of an explicit invocation, the input 247 can be based on a part of an utterance that is not associated with the invocation, or the input 247 can be nothing (e.g., an empty string). In the case of an implicit invocation, the input 247 can be the entire utterance.
Data store 250 includes one or more computing devices that store data used by the various subsystems of the master bot system 200. As explained above, the data store 250 includes rules 252 and skill bot information 254. The rules 252 include, for example, rules for determining, by MIS 220, when an utterance represents multiple intents and how to split an utterance that represents multiple intents. The rules 252 further include rules for determining, by EIS 230, which parts of an utterance that explicitly invokes a skill bot to send to the skill bot. The skill bot information 254 includes invocation names of skill bots in the chatbot system, e.g., a list of the invocation names of all skill bots registered with a particular master bot. The skill bot information 254 can also include information used by intent classifier 242 to determine a confidence score for each skill bot in the chatbot system, e.g., parameters of a machine-learning model.
Skill bot system 300 includes an MIS 310, an intent classifier 320, and a conversation manager 330. The MIS 310 is analogous to the MIS 220 in
Intent classifier 320 can be trained in a similar manner to the intent classifier 242 discussed above in connection with the embodiment of
The utterance 302 can be received directly from the user or supplied through a master bot. When the utterance 302 is supplied through a master bot, e.g., as a result of processing through MIS 220 and EIS 230 in the embodiment depicted in
Intent classifier 320 is configured to match a received utterance (e.g., utterance 306 or 308) to an intent associated with skill bot system 300. As explained above, a skill bot can be configured with one or more intents, each intent including at least one example utterance that is associated with the intent and used for training a classifier. In the embodiment of
Conversation manager 330 receives, as an output of intent classifier 320, an indication 322 of a particular intent, identified by the intent classifier 320, as best matching the utterance that was input to the intent classifier 320. In some instances, the intent classifier 320 is unable to determine any match. For example, the confidence scores computed by the intent classifier 320 could fall below a threshold confidence score value if the utterance is directed to a system intent or an intent of a different skill bot. When this occurs, the skill bot system 300 may refer the utterance to the master bot for handling, e.g., to route to a different skill bot. However, if the intent classifier 320 is successful in identifying an intent within the skill bot, then the conversation manager 330 will initiate a conversation with the user.
The conversation initiated by the conversation manager 330 is a conversation specific to the intent identified by the intent classifier 320. For instance, the conversation manager 330 may be implemented using a state machine configured to execute a dialog flow for the identified intent. The state machine can include a default starting state (e.g., for when the intent is invoked without any additional input) and one or more additional states, where each state has associated with it actions to be performed by the skill bot (e.g., executing a purchase transaction) and/or dialog (e.g., questions, responses) to be presented to the user. Thus, the conversation manager 330 can determine an action/dialog 335 upon receiving the indication 322 identifying the intent, and can determine additional actions or dialog in response to subsequent utterances received during the conversation.
Data store 350 includes one or more computing devices that store data used by the various subsystems of the skill bot system 300. As depicted in
B. Prediction Model(s)
In certain implementations, the system 400 is configured to train and utilize classifiers based on text data 405. As shown in
For example, the prediction models 425 can include a model for determining a likelihood that an utterance is representative of a task that a particular skill bot is configured to perform, another model for predicting a sentiment from an utterance, another model for predicting an intent from an utterance for a first type of skill bot, and another model for predicting an intent from an utterance for a second type of skill bot. Still other types of prediction models may be implemented in other examples according to this disclosure.
A prediction model 425 can be an ML model. As used herein, a “machine learning model,” “ML model,” or a “model” can refer to a software module configured to be run on one or more processors to provide a classification or numerical value of a property of one or more samples. An example type of model is supervised learning that can be used with embodiments of the present disclosure. Example supervised learning models may include different approaches and algorithms including analytical learning, artificial neural network, backpropagation, boosting (meta-algorithm), Bayesian statistics, case-based reasoning, decision tree learning, inductive logic programming, Gaussian process regression, genetic programming, group method of data handling, kernel estimators, learning automata, learning classifier systems, minimum message length (decision trees, decision graphs, etc.), multilinear subspace learning, naive Bayes classifier, maximum entropy classifier, conditional random field, nearest neighbor algorithm, probably approximately correct learning (PAC) learning, ripple down rules, a knowledge acquisition methodology, symbolic machine learning algorithms, subsymbolic machine learning algorithms, minimum complexity machines (MCM), random forests, ensembles of classifiers, ordinal classification, statistical relational learning, or Proaftn, a multicriteria classification algorithm.
The model may include linear regression, logistic regression, deep recurrent neural network (e.g., long short term memory, LSTM), hidden Markov model (HMM), linear discriminant analysis (LDA), k-means clustering, density-based spatial clustering of applications with noise (DBSCAN), random forest algorithm, support vector machine (SVM), or any model described herein. Supervised learning models can be trained in various ways using various cost/loss functions that define the error from the known label (e.g., least squares and absolute difference from known classification) and various optimization techniques, e.g., using backpropagation, steepest descent, conjugate gradient, and Newton and quasi-Newton techniques.
In some embodiments, the ML models could include, but not limited to, convolutional neural network (CNN), linear regression, logistic regression, deep recurrent neural network (e.g., fully-connected recurrent neural network (RNN), Gated Recurrent Unit (GRU), long short-term memory, (LSTM)), transformer-based methods (e.g., XLNet, BERT, XLM, RoBERTa), Bayes' classifier, hidden Markov model (HMM), linear discriminant analysis (LDA), k-means clustering, density-based spatial clustering of applications with noise (DBSCAN), random forest algorithm, adaptive boosting (AdaBoost), eXtreme Gradient Boosting (XGBoost), support vector machine (SVM), or a composite model including one or more models mentioned above.
Examples of the ML models further include a residual neural network (Resnet), variants of Deep Neural Networks (“DNN”) (e.g., a multi-label n-binary DNN classifier or multi-class DNN classifier for single intent classification), a Naive Bayes Classifier, Linear Classifier, Support Vector Machine, Bagging Models such as Random Forest Model, Boosting Models, Shallow Neural Networks, or combinations of one or more of techniques—e.g., CNN-HMM or Multi-Scale CNN.
The system 400 may employ the same type of prediction model or different types of prediction models for determining a likelihood of a task that a particular skill bot is configured to perform, sentiment analysis and predicting a sentiment for an utterance, predicting an intent from an utterance for a first type of skill bot, and predicting an intent from an utterance for a second type of skill bot. Still other types of prediction models may be implemented in other examples according to this disclosure.
To train the various prediction models 425, the prediction model training stage 410 may include three components: dataset preparation 430, feature engineering 435, and model training 440. The dataset preparation 430 includes the process of loading data assets 445, splitting the data assets 445 into training and validation sets 445a-n so that the system can train and test the prediction models 425, and performing basic pre-processing. The data assets 445 may include at least a subset of utterances from example utterances associated with various skill bots. As indicated above, an utterance can be provided in various ways including audio or text. The utterance can be a sentence fragment, a complete sentence, multiple sentences, and the like. For example, if the utterance is provided as audio, the dataset preparation 430 may convert the audio to text using a speech-to-text converter (not shown) that inserts punctuation marks into the resulting text, e.g., commas, semicolons, periods, etc. In some instances, the example utterances are provided by a client or customer. In other instances, the example utterances are automatically generated from prior libraries of utterances (e.g., identifying utterances from a library that are specific to a skill that a chatbot is to learn). The data assets 445 for a prediction model 425 can include input text or audio (or input features of text or audio frames) and labels 450 corresponding to the input text or audio (or input features) as a matrix or Table of values. For example, for each training utterance, an indication of the correct bot to use for the training utterance may be provided as ground truth information for labels 450. The behavior of the prediction model 425 can then be adapted (e.g., through back-propagation) to minimize the difference between the generated inferences and the ground truth information. Alternatively, a prediction model 425 may be trained for a particular skill bot, using at least a subset of example utterances associated with that particular skill bot as training utterances. The ground truth information for labels 450 for each training utterance may be a sentiment or a particular bot intent associated with the training utterance.
In some instances, additional augmentation may be applied to the data assets 445 (with augmentation). For example, Easy Data Augmentation (EDA) techniques may be used for boosting performance on text classification tasks. EDA includes four operations: synonym replacement, random insertion, random swap, and random deletion that prevent overfitting and helping train more robust models. The EDA operations in general: (i) obtain words from the original text, and (ii) incorporate the words within each data asset 445 relative to the original text. For example, synonym replacement operation includes 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 synonyms chosen at random. The random insertion operation includes—n times—finding a random synonym of a random word in the original sentence that is not a stop word and inserting that synonym into a random position in the sentence. The random swap operation includes—n times—randomly choosing two words in the sentence and swapping their positions. The random deletion operation includes randomly removing each word in the sentence with probability p.
In various embodiments, the feature engineering 435 includes transforming the data assets 445 (with augmentation) into feature vectors and/or creating new features will be created using the data assets 445 (with augmentation). The feature vectors may include count vectors as features, TF-IDF vectors as features such as word level, n-gram level or character level, word embedding as features, text/NLP as features, topic models as features, or a combination thereof. Count vector is a matrix notation of the data assets 445 in which every row represents an utterance, every column represents a term from the utterance, and every cell represents the frequency count of a particular term in a utterance. TF-IDF score represents the relative importance of a term in the utterance. A word embedding is a form of representing words and utterances using a dense vector representation. The position of a word within the vector space is learned from text and is based on the words that surround the word when it is used. Text/NLP based features may include word count in the utterance, character count in the utterance, average word density, punctuation count, upper case count, title word count, frequency distribution of part of speech tags (e.g., nouns and verbs), or any combination thereof. Topic modelling is a technique to identify the groups of words (called a topic) from a collection of utterances that contains best information in the collection.
In various embodiments, the model training 440 includes training a classifier using the feature vectors and/or new features created in the feature engineering 435. In some instances, the training process includes iterative operations to find a set of model parameters for the prediction model 425 that minimizes a loss or error function for the prediction models 425. Each iteration can involve finding a set of model parameters for the prediction model 425 so that the value of the cost function such as loss or error function using the set of model parameters is smaller or larger than the value of the cost function using another set of model parameters in a previous iteration. The cost function can be constructed to measure the difference between the outputs predicted using the prediction models 425 and the labels 450 contained in the data assets 445. Once the set of model parameters is identified, the prediction model 425 has been trained and can be utilized for prediction as designed.
In addition to the data assets 445, labels 450, the feature vectors and/or new features, other techniques and information can also be employed to refine the training process of the prediction models 425. For example, the feature vectors and/or new features may be combined together to help to improve the accuracy of the classifier or model. Additionally or alternatively, the hyperparameters may be tuned or optimized, for example, a number of model parameters such as tree length, leaves, network parameters etc. can be fine-tuned to get a best fit model. Although the training mechanisms described herein mainly focus on training a prediction model 425, these training mechanisms can also be utilized to fine tune existing prediction models 425 trained from other data assets. For example, in some cases, a prediction model 425 might have been pre-trained using utterance specific to another skill bot. In those cases, the prediction models 425 can be retrained using the data assets 445 (with augmentation) as discussed herein.
The prediction model training stage 410 outputs trained prediction models 425 including one or more task prediction models 460, one or more intent prediction models 465, and/or one or more sentiment prediction models 467 to be used in the implementation (e.g., deployment) stage 402.
For example, the task prediction models 460 may be used in the skill bot invocation stage 415 to determine a likelihood that an utterance is representative of a task that a particular skill bot 470 is configured to perform, the intent prediction models 465 may be used in the intent prediction stage 420 for classifying utterances as one or more intents 475, and the sentiment prediction models 467 may be used in the sentiment prediction stage 417 for classifying utterances with a sentiment 477. In some instances, the skill bot invocation stage 415 and the intent prediction stage 420 may proceed independently in some examples with separate models. For example, trained intent prediction models 465 may be used in the intent prediction stage 420 to predict intents for skill bots without first identifying the skill bots in the skill bot invocation stage 415. Similarly, the task prediction models 460 may be used in the skill bot invocation stage 415 to predict tasks or skill bots to be used for utterances without identifying the intent of the utterances in the intent prediction stage 420. Similarly, the sentiment prediction models 467 may be used in the sentiment prediction stage 417 to predict sentiment 477 of utterances without identifying the intent of the utterances in the intent prediction stage 420 and/or without first identifying the skill bots in the skill bot invocation stage 415.
Alternatively, the skill bot invocation stage 415, the sentiment prediction stage 417, and the intent prediction stage 420 may be conducted sequentially with one stage using the outputs of the other as inputs or one stage being invokes in a particular manner for a specific skill bot based on the outputs of the other. For instance, for a given text data 405, a skill bot invoker can invoke a skill bot through implicit invocation using the skill bot invocation stage 415 and the task prediction models 460. The task prediction models 460 can be trained, using ML and/or rules-based training techniques, to determine a likelihood that an utterance is representative of a task that a particular skill bot 470 is configured to perform. Then for an identified or invoked skill bot and a given text data 405, the sentiment prediction stage 417 and sentiment prediction models 467 can be used to classify the sentiment of an utterance (e.g., utterance within given data asset 445). Then for an identified or invoked skill bot and a given text data 405, the intent prediction stage 420 and intent prediction models 465 can be used to match a received utterance (e.g., utterance within given data asset 445) to an intent 475 associated with skill bot. As explained herein, a skill bot can be configured with one or more intents, each intent including at least one example utterance that is associated with the intent and used for training a classifier. In some embodiments, the skill bot invocation stage 415 and the task prediction models 460 used in the master bot system are trained to determine confidence scores for individual skill bots and confidence scores for system intents. Similarly, the intent prediction stage 420 and intent prediction models 465 can be trained to determine a confidence score for each intent associated with the skill bot system. Whereas the classification performed by the skill bot invocation stage 415 and the task prediction models 460 is at the bot level, the classification performed by the intent prediction stage 420 and intent prediction models 465 is at the intent level and therefore finer grained.
The embodiment described above with reference to
The techniques are for building a multi-lingual multi-task machine learning (ML) model that can accurately predict the sentiment of input utterances in a plurality of different languages using a plurality of different task-based approaches. For example, the built multi-lingual multi-task model can perform sentiment analysis using an aspect-based sentiment analysis (ABSA), e.g., an ABSA task, and a sentence-level sentiment analysis (SLSA), e.g., an SLSA task, in different languages.
For the ABSA, the task is to locate aspects (e.g., features) in an input text and determine the sentiments expressed toward the aspects through sequence labeling. An aspect can include any term, phrase, entity, etc. that has sentiment expressed toward it excluding pronouns such as he, she, it, etc. In the ABSA, one or more of the previous sentences and one or more of the following sentences may be considered. As an example, the aspect may be located in a first sentence “I bought coffee from this store,” while the sentiment can be expressed in a second sentence “It was terrible.” The ABSA analyzes both sentences, detects an aspect “coffee,” and determines that the sentiment for the coffee is “negative,” based on the word “terrible.”
The ABSA may predict sentiments from four classes: positive, negative, neutral, and mixed, as shown in Table 1 below. The bold words in the column “Examples” indicate the aspect or a feature with respect to which the sentiment is determined.
For the SLSA, the task is to predict the sentiments of an individual sentence in an input text through sentiment classification, by analyzing that sentence. If the input text is a combination of a plurality of sentences, the input text is split into separate sentences, the SLSA analyzes each sentence, and outputs a prediction for each individual sentence. Similarly to the ABSA, the SLSA may predict sentiments from four classes: positive, negative, neutral, and mixed, as shown in Table 2 below.
As described in detail below, the model training system 500 may access, obtain, or generate a plurality of datasets 508 that differ from each other in one or more differentiating attributes. Conversely, each of the datasets 508 is characterized by at least one common attribute. The attributes of the datasets 508 are described in a greater detail below.
In certain implementations, the model training system 500 is configured to train a model of predetermined architecture using the datasets 508, to generate a target model, e.g., a trained ML model, which is capable of predicting sentiments in different languages. For example, the model of predetermined architecture may be a multi-task model 510. The multi-task model 510 is a transformer-based model pretrained on the source language training examples to generate sentiment predictions using the ABSA (e.g., an ABSA task) and the SLSA (e.g., an SLSA task) on input utterances in the source language. For simplicity, embodiments describe an example of the multi-task model 510 including a token labeling head 512 pretrained to generate sentiment predictions using the ABSA task and a sequence classification head 514 pretrained to generate predictions using the SLSA task. However, this is not intended to be limiting. In some implementations, the multi-lingual model may be built to perform tasks different from the ABSA task and the SLSA task.
As described in detail below, embodiments can implement a hierarchical weighting for the training examples of the datasets 508, e.g., by sampling the training examples from each dataset based on a sampling weight determined for that dataset and forming training batches, where each training batch includes the training examples from one dataset. The sampling weight may be variously determined for each dataset, based on at least one differentiating attribute, so that more training batches may be created for a dataset with a higher sampling weight than for a dataset with a lower sampling weight.
The ABSA training batches and SLSA training batches may be generated for training the ABSA task and the SLSA task, where a differentiating attribute is a task identifier. The ABSA training batches for training the ABSA task and the SLSA training batches for training the SLSA task may be interleavingly provided between the tasks to the multi-task model 510 that is being trained.
Further, some of the datasets 508 within the SLSA datasets may be labeled datasets and some may be unlabeled datasets, where a differentiating attribute is presence (or absence) of labels. For example, in providing the SLSA training batches for training the SLSA task, the training batches formed from the labeled datasets and the training batches formed from the unlabeled datasets are provided interleavingly or successively.
Further, the datasets within the ABSA datasets and the datasets within the SLSA datasets may be labeled datasets in different languages, where a differentiating attribute may be a language identifier, e.g., “EN” for English and “ES” for Spanish. For example, in providing the ABSA training batches and the SLSA training batches, the training batches formed from the source language labeled datasets and the training batches formed from the target language datasets are provided interleavingly or successively within each task.
The datasets including the target language may be human-translated (e.g., human-created) or machine-translated, where a differentiating attribute is a translation source origin or a source origin, e.g., a human or machine. For example, in providing the ABSA training batches and the SLSA training batches, the training batches formed from the human-created target language dataset(s) and the training batches formed from the machine-translated target language dataset(s) are provided interleavingly or successively within each task.
Within the unlabeled datasets, the datasets include unlabeled bilingual sentence pairs or various unlabeled behavioral-related datasets. For the unlabeled datasets, an additional differentiating attribute may be a type of invariance. Herein, the unlabeled datasets may be referred to as invariance datasets.
The contents of the datasets 508 and methods of obtaining and/or generating the datasets 508 are described in detail below.
With reference again to
In an example, the source language is English and a target language is Spanish, but this is not intended to be limiting. The target language may be any language different from the source language. Likewise, the source language may be any well-sourced language.
As a result of the training performed by the model training system 500, an MLMT model capable of making predictions based on text in at least two different languages using two different sentiment prediction algorithms (e.g., tasks) may be built and output by the model training system 500.
In various embodiments, the training data preparation subsystem 502 may access or obtain data from various sources and generate ABSA training batches configured for training the multi-task model 510 to generate predictions using the ABSA. The ABSA training batches may include training examples in the source language and the target language from some of the datasets 508, where the training examples may be labeled. In certain implementations, the ABSA training batches may be weight-balanced based on the sampling weight.
In various embodiments, the training data preparation subsystem 502 may also access or obtain data from various sources and generate an SLSA training batches configured for training the multi-task model 510 to generate predictions using the SLSA. The SLSA training batches may include training examples in the source language and the target language from some of the datasets 508 that may be at least partially the same datasets as the datasets used for generating the ABSA training batches. The training examples in the SLSA training batches may include labeled and/or unlabeled training examples. In certain implementations, the SLSA training batches may be weight-balanced based on the sampling weight.
The MLMT model generation subsystem 504 may use the ABSA training batches and the SLSA training batches, to generate the MLMT model. The MLMT model is trained to predict sentiments by performing the ABSA and the SLSA on the text provided in two different languages.
A. Training Data Preparation
The training data preparation subsystem 502 may obtain or access input data, for example, from the public data source(s) or database(s). The training data preparation subsystem 502 may then generate training data 518, e.g., including the datasets 508 using the input data. As another example, the training data preparation subsystem 502 may obtain or access one or more datasets prepared by a vendor. The training data preparation subsystem 502 may prepare labeled datasets and unlabeled datasets that may be used, as an input, to by the MLMT model generation subsystem 504 for generation of the MLMT model.
1. Labeled Training Data Generation
With reference to
For example, the labeled training data generation subsystem 530 may obtain an original source language dataset including labeled sentences, e.g., examples, in the source language, e.g., English. The examples of the original source language dataset may be split into two portions, where one portion of the examples is the training examples used for model training and forms a labeled source language dataset 532. Another portion of the examples is the validation examples used for validation.
For instance, the original source language dataset may be obtained from a vendor or from a storage or a database that is accessible to the training data preparation subsystem 502 or the model training system 500. Herein, the original source language dataset may be referred to as an original English dataset.
The training examples of the labeled source language dataset 532 may form one of the datasets 508, and may be used for training the ABSA task and the SLSA task of the multi-task model 510.
The labeled training data generation subsystem 530 may further obtain an original target language dataset. In an embodiment, the original target language dataset is a human-curated dataset that includes sentences in the target language, e.g., Spanish. The sentences of the human-curated dataset are high-quality sentences that include labels. In certain implementations, the sentences in the target language are translated by a human from the source language into the target language or created by a human who is a native speaker of the target language. In some embodiments, the original target language dataset may be obtained from a vendor (e.g., a target language servicing vendor) or from a storage or a database that is accessible to the training data preparation subsystem 502 or the model training system 500.
The examples of the original target language dataset may be split into two portions, where one portion of the examples is the training examples included a labeled target language dataset 534 and are used for model training. Another portion of the examples is the validation examples used for validation. Herein, the labeled target language dataset 534 may be referred to an original Spanish dataset or a golden dataset.
The training examples of the labeled target language dataset 534 may form one of the datasets 508, and may be used for training the ABSA task and the SLSA task of the multi-task model 510.
The number of training examples included in the labeled target language dataset 534 (e.g., several hundreds of examples) is substantially smaller as compared to a number of training examples in the labeled source language dataset 532 (e.g., 10s of thousands of examples). Therefore, in various embodiments, the training examples from the labeled target language dataset 534 may be supplemented by the machine-translated training examples in the target language, as described below. Supplementing the training examples from the labeled target language dataset 534 with the machine-translated training examples in the target language is one of the examples of augmentation methods used in various embodiments.
a. Augmentation of Target Language Training Examples Using Machine Translation
With continuing reference to
In certain implementations, the translated text generation subsystem 540 may obtain sentences in the source language from the labeled source language dataset 532. However, this is not intended to be limiting. In some implementations, the translated text generation subsystem 540 may obtain sentences in the source language from another dataset that includes labeled sentences in the source language.
The translated text generation subsystem 540 can then generate labeled machine-translated sentences in the target language using a first translation model 542. The first translation model 542 may be a translation model known to those skilled at the art.
The first translation model 542 may receive, as an input, the sentences with the corresponding labels of the labeled source language dataset 532 and perform certain processing on the received sentences, to translate the received labeled sentences from the source language to the target language. As a result of the processing performed by the first translation model 542, the first translation model 542 can output a labeled machine-translated target language dataset 544 as one of the machine-translated target language datasets. The labeled machine-translated target language dataset 544 includes sentences in the target language and corresponding labels.
The labeled machine-translated target language dataset 544 may be stored in the labeled vocabulary 531, and, in some instances, used as one of the datasets 508 for training the SLSA task of the multi-task model 510. However, for training the ABSA task of the multi-task model 510, an order of the labels is corrected, according to various embodiments.
b. Label Alignment Correction for Training ABSA Task
As described above, each translated target language sentence of the labeled machine-translated target language dataset 544 has a parallel labeled sentence in the source language. However, in some instances, the order of translated words of the translated target language sentences might not be the same as the order of words of the parallel labeled sentence in the source language. Because the labels in the source language sentences are linked to the associated words, the labels in the labeled machine-translated target language dataset 544 are linked to the target language words that are translation of the source language words.
For example, the aspect analyzed by the ABSA may be a multi-word aspect. In embodiments, the order of the machine-translated words of the multi-word aspect and the associated labels may be different as compared to the order of the words of the multi-word aspect and their associated labels in the parallel sentences in the source language.
Thus, for training the ABSA task, embodiments perform label alignment, e.g., correcting an order of the labels of the machine-translated text. This is described below with reference to Table 3.
Referring to row 2 of Table 3, the English example ‘The credit card is good’ has an aspect ‘credit card.’ The machine-translated Spanish example is ‘La tarjeta de credito es buena’ and has the translated aspect ‘tarjeta de credito.’ In this example, a word ‘credit’ is translated to a word ‘credito’ and a word ‘card’ is translated to a word ‘tarjeta,’ which becomes a beginning of the aspect ‘tarjeta de credito.’ In rows 3 and 4, the labels mean I-Pos=Intermediary Positive, B-Pos=Beginning Positive, and O=Ignored.
As shown in row 3 of Table 3, the labels with word-by-word alignment for English text are {O B-Pos I-Pos O O}. The labels with word-by-word alignment for Spanish are {O I-Pos O B-Pos O O}. Since the words in the aspect switch places in the sequence (e.g., ‘credit card’ becomes ‘tarj eta de credito’), the labels switch places too so that the label sequence for the translated aspect is {I-Pos O B-Pos}, which a reverse of the original label sequence {B-Pos I-Pos} and incorrectly identifies the first word of the multi-word aspect, e.g., as an intermediary instead of beginning. In this instance, the labels for the aspect are in an incorrect order.
Accordingly, in certain implementations, the translated text generation subsystem 540 may include an aligner 546. The aligner 546 may receive labeled sentences in the source language from the labeled source language dataset 532 and the labeled machine-translated sentences in the target language from the labeled machine-translated target language dataset 544. The aligner 546 performs certain processing on the parallel sentences and outputs the machine-translated target language sentences with the labels that are rearranged in the correct order. For example, the aligner 546 may receive pairs of parallel sentences from the labeled source language dataset 532 and the labeled machine-translated target language dataset 544, and correctly align the labels with the translated words of the multi-word aspect.
In some implementations, the aligner 546 may perform the following processing.
Given a sentence x=(x1, . . . , xn) in the source language and its corresponding parallel sentence y=(y1, . . . , ym) in the target language, the aligner 546 tries to find a set of pairs of source and target words: A={(xi, yj): xi→x, yj→y}, where for each word pair (xi, yj), xi and yj are semantically similar to each other within the context of the sentence.
In some embodiments, the aligner 546 may include an ML model 548. For example, the ML model 548 may be a contextualized word embeddings model, e.g., a multi-lingual BERT model, that is capable of determining the alignment. For example, the ML model 548 can extract contextualized word embeddings hx=(hx1, . . . , hxn) and hy=(hy1, . . . , hym) for each pair of parallel sentences x and y. This can be done by extracting the hidden states of the i-th layer of the model, where i is an empirically-chosen hyper-parameter. Given the contextualized embeddings, the alignment scores can be calculated via a probability simplex approach. These scores are then transformed into alignment matrices and reconciled in forward and backward directions to generate the alignment.
In some instances, the processing performed by the aligner 546 does not provide labels to the prepositions and/or articles. For example, after performing the alignment on the Spanish aspect “tarjeta de credito,” the aligner 546 might not consider “de.”
Accordingly, in certain implementations, the translated text generation subsystem 540 may further include a post-processor 552. The post-processor 552 may normalize the label alignment by, for example, inserting labels for the prepositions and/or articles between two words of the multi-word aspect.
Referring to row 4 of Table 3 shown above, as a result of the processing performed by the aligner 546 and the post-processor 552, the labels in the Spanish translation may be realigned, e.g., corrected, from {O I-Pos O B-Pos O O} to {O B-Pos I-Pos I-Pos O O}, thereby correctly identifying a beginning part (e.g., word) of the aspect (e.g., B-Pos) and the intermediary parts (e.g., I-Pos).
Also, as a result of the processing performed by the aligner 546 and the post-processor 552, a label-aligned machine-translated target language dataset 554 may be generated as one of the machine-translated target language datasets. The label-aligned machine-translated target language dataset 554 may be stored in the labeled vocabulary 531.
In embodiments, the label-aligned machine-translated target language dataset 554 may be used as one of the datasets 508 for training the ABSA task of the multi-task model 510. As mentioned above, the labeled machine-translated target language dataset 544 may be used as one of the datasets 508 for training the SLSA task of the multi-task model 510. However, this is not intended to be limiting. The label-aligned machine-translated target language dataset 554 may be also used for training the SLSA task of the multi-task model 510.
For simplicity of description, the labeled machine-translated target language dataset 544 and the label-aligned machine-translated target language dataset 554 may be referred herein as machine-translated target language datasets.
2. Unlabeled Training Data Generation
With continuing reference to
a. Unlabeled Bilingual Sentence Pairs
In embodiments, the unlabeled training data generation subsystem 555 may use one of the publicly available data sources to obtain an unlabeled bilingual sentence pairs dataset 557.
For example, the unlabeled training data generation subsystem 555 may include a data miner 562. The data miner 562 can obtain or receive the input data and perform certain processing on the input data, to output data as unlabeled sentence pairs in at least two languages. For example, the data miner 562 can access a database or another system to retrieve the input data. In some implementations, the input data may be a web content, publicly available databases, etc., that can be obtained from a publicly available large dataset(s), e.g., Tatoeba, Bible, European Parliament statements, etc.
Tatoeba is a free collection of example sentences with translations, as known to those skilled in the art. It is available in more than 400 languages. Each sentence in the Tatoeba Corpus is arranged next to its translations in other languages.
Also, the Bible is currently translated into over 700 languages. Accordingly, parallel translation pairs may be obtained from the parallel Bible translations.
As another example, European Union documents, e.g., European Parliament statements, speeches of the members, etc., are translated into 24 languages. Accordingly, parallel translation pairs may be obtained from the parallel translations of European Union documents.
However, this is not intended to be limiting, and, in some implementations, the input data may be obtained from other public source or sources or may be a mix of data from several public sources.
In some implementations, the data miner 562 may include a language detector 564. As described above, a user may provide, through the UI subsystem 516, an input for identifying a target language to be processed by the model training system 500, where the unlabeled training data generation subsystem 555 may be tasked to generate the unlabeled bilingual sentence pairs dataset 557 for the target language, e.g., Spanish, and the source language, e.g., English.
The language detector 564 may receive, as the input data, the input data from Tatoeba and identify the sentence pairs in English and Spanish. As an example, the language detector 564 may use a language detecting model, e.g., a classification model, which provides an identification of the languages. As such, the unlabeled training data generation subsystem 555 may generate the unlabeled bilingual sentence pairs dataset 557 for any given pair of languages.
In some embodiments, where the data miner 562 obtains data from the public source or sources where the translation sentences are not paired (e.g., Bible translation, European materials translations, etc.), the data miner 562 may include a sentence pair alignment subsystem (not shown) that may use one or more models (e.g., NLP models) to process and align parallel sentences in different languages.
The unlabeled bilingual sentence pairs dataset 557 may be one of the datasets 508 for training the SLSA task of the multi-task model 510.
b. Unlabeled Fairness Invariance Training Data
In some embodiments, to accurately predict the sentiment class of the input data without bias, the training of the multi-task model 510 may include invariance-related training, where the multi-task model 510 can be trained on invariance datasets to handle fairness among many other features and characteristics of the input data. The goal of the invariance-related training is to train the model to generate invariant (e.g., fair) predictions in the presence of words from different demographic groups.
As used herein, fair predictions mean the same predicted class, irrespective of the demographic group represented in the training examples.
Table 4 shows an example of a demographic group with corresponding invariant set of sentences.
Australian car.”,
In constructing the fairness invariance dataset, the unlabeled training data generation subsystem 555 may access, e.g., a database, containing a list of demographic words associated with demographic groups identified for the fairness training protocol, e.g., by a user.
The demographic words and groups may, for example, include:
The data miner 562 may search the publicly available datasets, e.g., the web content, database(s), etc., to identify original examples including at least one demographic word from the list of demographic words corresponding to each demographic group.
The unlabeled training data generation subsystem 555 may then create additional training examples, e.g., augmented examples, by generating multiple versions of the original examples. For example, the unlabeled training data generation subsystem 555 may substitute the demographic word in each original example with another demographic word from the same demographic group. The example of this operation is shown in column 3 of Table 4 above.
Although only a brief description is provided above, a detailed description may be found in US Published Application No. 2023/0153688 (U.S. Ser. No. 17/984,768), which is incorporated by reference herein in its entirety.
The source language fairness dataset 580 may be one of the datasets included in the unlabeled source language behavioral augmented datasets 558 and in the datasets 508.
c. Unlabeled Invariance Training Data for Named Entity Recognition (NER) Debiasing
In some embodiments, to accurately predict the sentiment class of the input data without bias, the training of the multi-task model 510 may include named entity debiasing training.
A named entity is an object in the real world mentioned in a text with a proper name such as a person, location, organization, etc. In the below sentences, “Melbourne”, “Bank of America”, and “Amanda” are three named entities, e.g., a location, an organization, and a person:
In sentiment analysis, a model could bias its predictions for some named entities toward either a positive or negative class so that even within neutral or opposite sentiment contexts, the predictions might still be biased.
Table 5 below shows examples of named entity biases collected using a BERT-based sentiment analysis model fine-tuned on a sentiment labeled dataset. Column 1 of Table 5 shows examples of unbiased entities. Column 2 shows examples of biased entities. Column 3 provides comments for possible reasons of the noted biasing.
Melbourne.” →
Wyndham.” →
America.” →
One.” →
Accordingly, as shown in column 1, “Melbourne”, “Bank of America”, and “Okami” are neutral entities that are unbiased. As shown in column 2, “Wyndham”, “Capital One”, and “Adam's Mark” are biased toward negative or positive classes, while they should be classified as neutral similarly to the entities in column 1.
One of the reasons the NER biases are introduced into the machine learning model (e.g., a fine-tuned model) is the skewed appearance of some named entities across sentiment classes. For example, since “Capital One” appears in negative sentiment training examples more frequently than the positive ones, the model attaches “Capital One” inappropriately to the negative class.
Such biases are not expected for a sentiment analysis service since the model should be agnostic with respect to the named entities, i.e., the model's predictions should be the same for all named entities.
In some implementations, to construct the NER debiasing dataset, the unlabeled training data generation subsystem 555 may access, e.g., a database, containing a list of named entities that are identified as being more likely to be biased. For example, these named entities are identified from domains that are frequently used by the sentiment analysis services, e.g., auto, finance, retail, etc. The named entities may be grouped by a value of the named entity tag, e.g., location <LOC>, person <PER>, organization <ORG>, etc.
The data miner 562 can crawl publicly available sources, e.g., web content, database(s), etc., to collect original examples from the domains that are frequently used by the sentiment analysis services, e.g., auto, finance, retail, etc. The unlabeled training data generation subsystem 555 may replace the values of the entity values in the original examples with tags, e.g., <LOC>, <PER>, <ORG>, thereby creating templates corresponding to the original examples.
The unlabeled training data generation subsystem 555 may then create additional training examples, e.g., augmented training examples, by generating multiple versions of one or more original examples. For example, the unlabeled training data generation subsystem 555 may substitute the location <LOC> in each original example with another location from the list of named entities that are identified as being more likely to be biased, by using the templates corresponding to the original examples. This is shown in column 2 of Table 6 below.
Portland and Geelong have excellent ports,
Fremantle and Kimberley have excellent
Although only a brief description is provided above, a detailed description may be found in US Published Application No. 2023/0153687 (U.S. Ser. No. 17/984,717), which is incorporated by reference herein in its entirety.
The source language NER debiasing dataset 582 may be one of the datasets included in the unlabeled source language behavioral augmented datasets 558 and in the datasets 508.
As mentioned above, in some embodiments, the unlabeled training data generation subsystem 555 may further generate the unlabeled target language behavioral augmented datasets 559.
In certain implementations, the unlabeled training data generation subsystem 555 may include a second translation model 583. The second translation model 583 can translate the training examples of the datasets of the unlabeled source language behavioral augmented datasets 558 into the training examples in the target language.
However, the described-above is not intended to be limiting. In some embodiments, the unlabeled training data generation subsystem 555 may use the same translation model as the labeled training data generation subsystem 530, that is, the first translation model 542.
The training examples of the datasets of the unlabeled source language behavioral augmented datasets 558 translated into the target language are included in the corresponding datasets of an unlabeled target language behavioral augmented datasets 559. The unlabeled target language behavioral augmented datasets 559 correspondingly include a target language fairness dataset 585 and a target language NER debiasing dataset 586. The target language fairness dataset 585 and the target language NER debiasing dataset 586 may be included in the datasets 508.
The unlabeled source language behavioral augmented datasets 558 and the unlabeled target language behavioral augmented datasets 559 may be stored in the unlabeled vocabulary 556 and may be used for training the SLSA task of the multi-task model 510.
B. MLMT Model Generation
With reference again to
As described above, the multi-task model 510 is a model pretrained on the source language training examples to generate predictions using the ABSA (e.g., an ABSA task) and the SLSA (e.g., an SLSA task). For example, the multi-task model 510 may have the token labeling head 512 pretrained to generate predictions using the ABSA task and the sequence classification head 514 pretrained to generate predictions using the SLSA task, on the utterances in the source language. A language model 573 may generate token embeddings to be provided to the token labeling head 512 and the sequence classification head 514. Although in
In some embodiments, the training batch preparation subsystem 506 may select a first plurality of datasets among the datasets 508, to form training batches for training the multi-task model 510 for the ABSA task, and/or may select a second plurality of datasets among the datasets 508, to form training batches for training the multi-task model 510 for the SLSA task. Within each task, the training batches may be weighted, e.g., sampled, based on each sampling weight determined for each of the datasets 508.
As described above, to resolve the imbalance of the labeled target training data across different languages, e.g., a high-resource language such as English and a low-resource language such as Spanish, embodiments provide for augmentation of the training examples from the labeled target language dataset 534 with the training examples from the machine-translated target language datasets (e.g., the label-aligned machine-translated target language dataset 554 or the labeled machine-translated target language dataset 544). The goal of the augmentation of the original target language training examples with the machine-translated training examples is to provide a compatible number of training examples in the source language and the target language. In some embodiments, as a result of augmentation of the training examples for the target language, an approximately same number of training examples in the source language and in the target language can be provided for training the multi-task model 510. The “approximately same number of training examples” means that a number of training examples in the source language and a number of training examples in the target language may differ from 0% to 15-20%, with the number of training examples being from several thousands to tens of thousands in each of the source language and the target language. However, this is not intended to be limiting. In some instances, a ratio of the training examples in the source language and the training examples in the target language may be 2 to 1 or any other appropriate ratio.
The quality of the machine translation is typically worse than a human translation, which might affect the model performance. Therefore, in various embodiments, a weighted batch balancing method is implemented to down-sample the training examples from the machine-translated target language datasets. In an embodiment, a ratio may be used (e.g., weighting), where for each machine-translated training example, a greater number of the training examples from the labeled target language dataset 534 (e.g., golden dataset) is used. For example, when the training batches are created using the labeled target language dataset 534 and one of the machine-translated target language datasets, a ratio of 2 to 1 may be used for providing the training batches corresponding to the labeled target language dataset 534 and the training batch(es) corresponding to the machine-translated target language dataset, so that a number of human-created (e.g., original) training examples used for training the multi-task model 510 is twice a number of the machine-translated training examples. However, this is not intended to be limiting and another ratio may be used, e.g., 3/1, 4/1, etc.
In various embodiments, the training batch preparation subsystem 506 may randomly provide the training batches to the MLMT model training subsystem 570, by interleaving the training batches. The MLMT model training subsystem 570 is configured to receive, as an input, the training batches that are formed using the datasets 508 and variously sampled based on the sampling weight, and iteratively train the token labeling head 512 and the sequence classification head 514 of the multi-task model 510.
In some embodiments, the training batch preparation subsystem 506 may include a dataset selector 574. The dataset selector 574 is configured to select datasets among the datasets 508 for training the multi-task model 510.
For example, the dataset selector 574 may select the datasets for training the ABSA task and/or the SLSA task, based on a predefined default, a user input through the UI subsystem 516, a signal provided by the MLMT model generation subsystem 504, or randomly.
In an embodiment, the dataset selector 574 may select at least two datasets among the datasets 508 for forming separate training batches from separate datasets. In some implementations, for training the ABSA task, the dataset selector 574 may select the labeled source language dataset 532, the labeled target language dataset 534, and the label-aligned machine-translated target language dataset 554. For training the SLSA task, the dataset selector 574 may select the labeled source language dataset 532, the labeled target language dataset 534, the labeled machine-translated target language dataset 544 or the label-aligned machine-translated target language dataset 554, and one or all of the unlabeled datasets from the unlabeled vocabulary 556.
The training batch preparation subsystem 506 may further include a sampling weight determining subsystem 575. The sampling weight determining subsystem 575 is configured to determine a sampling weight for each of the datasets selected by the dataset selector 574. As an example, one or more sampling weights may be predefined as a default. As another example, the sampling weight determining subsystem 575 may determine sampling weights based on a mix of the datasets selected by the dataset selector 574, from which the training batches are formed, and the attributes of the selected datasets.
In some implementations, the training batch preparation subsystem 506 may further include a sample selector 577. The sample selector 577 may sample the datasets selected by the dataset selector 574 based on the sampling weight determined for the dataset.
In an embodiment, the training batch preparation subsystem 506 may include a training batch forming subsystem 578. The training batch forming subsystem 578 is configured to form training batches using training examples sampled from each of the selected datasets by the sample selector 577. The training batch forming subsystem 578 is further configured to provide the training batches to the MLMT model training subsystem 570, to train the multi-task model 510. For example, each training batch includes the training examples from a single dataset.
In certain implementations, the sampling weight determining subsystem 575 may determine (e.g., assign) the sampling weight hierarchically. For example, the sampling weight determining subsystem 575 may assign an equal weight to the training batches to be formed from the datasets having training examples in the source language and the target language, so that the model training is not imbalanced.
In the example of the ABSA training, the sampling weight determining subsystem 575 may assign a sampling weight of 1 to the training batch(es) to be formed from the training examples of the labeled source language dataset 532. The sampling weight determining subsystem 575 may assign a sampling weight of 1 to a combination of the training batches to be formed from the training examples of the labeled target language dataset 534 and the label-aligned machine-translated target language dataset 554.
Further, the sampling weight determining subsystem 575 may assign a sampling weight of 2/3 to the training batch(es) to be formed from the training examples of the labeled target language dataset 534 and a sampling weight of 1/3 to the training batch(es) to be formed from the training examples of the label-aligned machine-translated target language dataset 554. The sample selector 577 may sample the training examples of the labeled target language dataset 534 twice as much as the training examples of the label-aligned machine-translated target language dataset 554.
Continuing with the above example, the sample selector 577 may randomly sample the training examples of the labeled source language dataset 532, the training examples of the labeled target language dataset 534, and the training examples of the label-aligned machine-translated target language dataset 554.
As a result of this example of the sampling performed the sample selector 577, the training batch forming subsystem 578 can form six training batches: three training batches containing examples from the labeled source language dataset 532, two training batches containing examples from the labeled target language dataset 534, and one training batch containing examples from the label-aligned machine-translated target language dataset 554.
The training batch forming subsystem 578 can then randomly provide the training batches formed using the sampling weight to the MLMT model training subsystem 570, by interleaving the formed training batches.
However, the described above is not intended to be limiting and a number of training batches more than six can be formed based on the determined sampling weight.
The MLMT model training subsystem 570 may then train the ABSA task using the training batches.
As mentioned above, the MLMT model generation subsystem 504 includes the MLMT model validation subsystem 572. The MLMT model training subsystem 570 may perform training using the token labeling head 512, the sequence classification head 514, and the training batches formed using the training examples from the datasets 508. The MLMT model validation subsystem 572 may perform a validation of the result of the training performed by the MLMT model training subsystem 570 using the validation examples. When one of MLMT model versions satisfies the validation stopping criteria, e.g., performance criteria or criterion such as accuracy score and/or F1 score, that particular MLMT model version is output as the MLMT model.
As described above, the validation examples may be obtained from the labeled source language dataset 532 and the labeled target language dataset 534 e.g., by sampling the examples included therein.
Similarly to what is described above with reference to
Using Labeled and Unlabeled Training Batches for Training SLSA Task
In an embodiment, the training batch preparation subsystem 506 may form the training batches for training the SLSA task, using the datasets including the labeled training examples and the datasets including the unlabeled training examples, among the datasets 508.
The dataset selector 574 may select one or more datasets including the labeled training examples, from the datasets 508. For example, the dataset selector 574 may select one or more among the labeled source language dataset 532, the labeled target language dataset 534, and the labeled machine-translated target language dataset 544.
The dataset selector 574 may also select one or more datasets including the unlabeled training examples, from the datasets 508. In an embodiment, the dataset selector 574 may select one or more among the unlabeled bilingual sentence pairs dataset 557, the source language fairness dataset 580, the source language NER debiasing dataset 582, the target language fairness dataset 585, and the target language NER debiasing dataset 586.
As described above, in various embodiments, a weighted batch balancing method can be implemented by creating training batches hierarchically sampled with a sampling weight at different levels. The weighted training batches may be then interleavingly provided to the MLMT model training subsystem 570.
A non-limiting example of the different levels (e.g., hierarchy) can include:
Accordingly, at each level of predefined hierarchy, the training examples from each of the corresponding datasets can be variously sampled. Further, at the data source level, the training examples from different datasets can be sampled with different weights. The sampling weights can be hyperparameters for hyper-tuning to achieve the best performance.
The sample selector 577 may sample the selected datasets based on the sampling weight hierarchically determined for the datasets by the sampling weight determining subsystem 575. In some embodiments, the sampling weight may be assigned so that an approximately equal number of training examples is selected in the source language and the target language, e.g., with a ratio of 1:1.
Further, the sampling weight may be assigned so a different number of the labeled training examples and the unlabeled training examples is provided to the MLMT model training subsystem 570. In embodiment, the sample selector 577 may sample the datasets containing the labeled training examples and the unlabeled training examples, based on the sampling weight. The training batch forming subsystem 578 may then interleavingly provide the training batches having the labeled training examples and the training batches having the unlabeled training examples, so that the ratio of the labeled training batches to the unlabeled training batches is 2/1, . . . 5/1, . . . , etc.
For example, the sampling weight determining subsystem 575 may assign a sampling weight ratio of 2:1 to the training batches containing labeled target language training examples dataset and the training batches containing the machine-translated target language training examples.
Further, among the unlabeled training examples of the invariance datasets, the sampling weight determining subsystem 575 may determine the sampling weight variously for the training batches formed from each of the unlabeled bilingual sentence pairs dataset 557, the source language fairness dataset 580, the source language NER debiasing dataset 582, the target language fairness dataset 585, and the target language NER debiasing dataset 586.
In various embodiments, the model parameters can be incrementally updated by minimizing a loss function for randomly provided training batches with the labeled training examples and the unlabeled training examples.
The training batch preparation subsystem 506 may provide a configuration flag to the SLSA labeled training batch and/or the SLSA unlabeled training batch, to signal the presence (or absence of the labels). For simplicity of description, in an example below, the configuration flag is provided to the SLSA unlabeled training batch.
Upon receiving a training batch from the training batch preparation subsystem 506, the MLMT model training subsystem 570 may determine a presence or absence of the configuration flag. Based on the configuration flag being present, the MLMT model training subsystem 570 may identify that the SLSA unlabeled training batch is received. Based on the configuration flag being absent, the MLMT model training subsystem 570 may identify that the SLSA labeled training batch is received.
Based on the configuration flag being present or absent, the MLMT model training subsystem 570 may use a different loss function for the training being performed.
In the case that the configuration flag is absent, e.g., the MLMT model training subsystem 570 performs the SLSA task training using the SLSA labeled training batch, the MLMT model training subsystem 570 may use a cross-entropy loss function on text X:
where:
In the case that the configuration flag is present, e.g., the MLMT model training subsystem 570 performs the SLSA task training using the SLSA unlabeled training batch, the MLMT model training subsystem 570 may use a KL divergence loss function to minimize the sum of KL divergence losses on the unlabeled training examples from the invariance dataset.
Below is an example of the KL divergence loss function for an unlabeled bilingual translation sentence pair (e, s):
where:
In the equation (1) above, θ is the model parameters to be learned. In embodiments, θ may be suppressed from the prediction probabilities to simplify the notation.
Further, the KL divergence could be replaced or supplemented by another distance metric on probability or logit vectors such as L1 or L2 norm.
As described above, the training data preparation subsystem 502 may access or obtain data from various input sources. The training data preparation subsystem 502 can use the data from the various input sources to generate ABSA training batches for training the multi-task model 510 to generate predictions using the ABSA task. The ABSA training batches may include training examples from a first plurality of datasets selected from the datasets 508.
The training data preparation subsystem 502 may further use the data from the various input sources to generate SLSA training batches for training the multi-task model 510 to generate predictions using the SLSA task. The SLSA training batches may include training examples from a second plurality of datasets selected from the datasets 508.
In some embodiments, the model parameters can be incrementally updated by minimizing a loss function over the training examples of randomly sampled datasets selected for the SLSA training and the training examples of randomly sampled datasets selected for the ABSA training. For the MLMT model training, the disclosed techniques can use a weighted combination of cross-entropy losses for the SLSA task and the ABSA task.
Below is the SLSA cross-entropy of input text x:
where:
The ABSA cross-entropy of the input text of n words x=(x1, . . . , xn) with corresponding labels y=(y1, . . . , yn)
where:
Otherwise, it is zero.
CRFs are a class of statistical modeling methods used for structured prediction. For example, a classifier predicts a label for a single sample without considering “neighboring” samples, and a CRF can take context into account.
Therefore, at the highest task level, the disclosed techniques can update the model parameters by interleavingly minimizing a weighted combination of the cross entropies over SLSA and ABSA data:
where:
Within each task, the disclosed techniques can interleave between labeled vs. unlabeled data groups in a similar manner. Within the labeled or unlabeled data, the disclosed techniques can interleave among different dataset types. For example, for the labeled ABSA data, the disclosed techniques can have two datasets with different marginal sampling ratios, including one for languages and one for machine-translated data. The languages (e.g., English vs. Spanish) can have a sampling ratio of 1:1 whereas the translation sources (e.g., original vs. machine-translated) can have a sampling ratio of 2:1. The disclosed techniques can sample original examples twice more than translated ones since the original data have higher quality.
In some embodiments, the MLMT model validation subsystem 572 may implement an early stopping technique to prevent from overfitting. The early stopping technique is provided such that one task in the model does not dominate over the other task(s). For the multi-task model implementing the ABSA and the SLSA, an embodiment implements a weighted combination of metrics from different tasks:
α×F1ABSA+(1−α)×AccuracySLSA (4)
The F1 score is a measure of the test's accuracy. F1 score is the harmonic mean calculated from the precision and recall of the test, where the precision is the number of true positive results divided by the number of all positive results, including those not identified correctly, and the recall is the number of true positive results divided by the number of all samples that should have been identified as positive.
The accuracy score is calculated by dividing the number of correct predictions by the total prediction number.
Accordingly, in an embodiment, the F1 score for the ABSA and the accuracy for the SLSA are used, instead of using a same metric for both tasks, and combined as a weighted average. The hyper-tuner is used to find the proper weight for each of the F1 score for the ABSA and the accuracy for the SLSA.
As a result of the training performed by the model training system 500, an MLMT model capable of making predictions using at least two different languages and two different sentiment prediction algorithms, may be built and output by the model training system 500.
Table 7 below shows an example of the ABSA task training and illustrates a hierarchical weighting.
At level 1, as seen in column 4 of Table 7, the same sampling ratio is used for the training examples in English and the training examples in Spanish, e.g., 1:1.
For level 2, columns 2 and 3 of table 7 illustrate sampling weights for the original training examples and the machine-translated sampling examples, e.g., 2:1.
As described above, the “original” training examples are included in the labeled source language dataset 532 (English) and the labeled target language dataset 534 (Spanish).
As seen in row 2 of column 3 of Table 7, in this example, the data translated from Spanish to English may be used. Although not illustrated in the drawings, the translated text generation subsystem 540 may include a Spanish to English translation model to convert original Spanish training examples from the labeled target language dataset 534 to English training examples. This is another example of augmentation where high-resource source language (e.g., English) can be supplemented with diverse examples that might otherwise not be present in the labeled source language dataset 532. For the ABSA task, a label alignment processing may be performed that is similar to what is described above for the training examples that are machine-translated from English to Spanish.
The machine-translated training examples that are referred to in row 2 of column 3 of Table 7 are the training examples from the label-aligned machine-translated target language dataset 554.
The sampling weights for all four dataset combinations are computed, as provided in Table 7 below:
For the above example, the ABSA cross-entropy loss is itself a weighted combination of four losses over different data group combinations:
During training, the disclosed techniques can use a similar weighted early stopping criterion.
The benefits of the disclosed techniques were demonstrated by conducting various experiments. To implement the experiments, the disclosed techniques were used to fine-tune the mDistilBERT pretrained multi-lingual model using two datasets, including without Spanish and with translated Spanish. The “without Spanish” dataset included labeled English data only and the “with translated Spanish” dataset included labeled English data and the corresponding Spanish translation.
Benefits of Using Machine-Translated Data for SLSA Task
Experiments showing the benefit of the machine-translated data for the SLSA task were implemented. Below are accuracies of these models on the English and Spanish SLSA test datasets. As shown in columns 3 and 5 of Table 8, with both English and translated Spanish training data, the disclosed techniques improved the SLSA test accuracy on Spanish. Performance on the English test set is also improved, as shown in Table 8 below:
Benefits of Using Machine-Translated Data for ABSA Task
As described above, the disclosed techniques augment the English-to-Spanish machine-translated version using the described-above label alignment method. Experiments showing the benefit of machine-translated data for the ABSA task were implemented. Table 9 provides the summary of the ABSA training after the data augmentation step/label alignment:
Below are F1 scores of the models using the English and Spanish ABSA test sets. With both English and translated Spanish training data, the disclosed techniques provide improved ABSA accuracy on Spanish while maintaining the same performance on English test set, as shown in Table 10 below:
Benefit of Using KL Divergence Loss for Unlabeled Human-Translated Data for SLSA
The benefit of KL divergence loss for unlabeled human-translated data (e.g., unlabeled bilingual sentence pairs) for the SLSA is provided below. The disclosed techniques were used to fine-tune a focused mDistilBERT on original English+Spanish-translated training data to get a baseline SLSA model. The disclosed techniques were used to train another model on the same data plus 40,000 unlabeled translation pairs from Tatoeba. The sampling ratio between labeled examples and the unlabeled translation pairs was 5:1. Results are averaged across five random runs, as provided in Table 11 below:
80.4
84.3
83.8
86.2
Overall Results
By deploying the above-disclosed techniques with additional labeled English and Spanish data and hyper-parameter tuning, the model disclosed herein achieved the performance improvements, as shown Table 12 below:
As shown in
As shown in
An example of a cloud infrastructure architecture provided by the CSP is depicted in
The processing 700 depicted in
With continuing reference to
In an example, the plurality of datasets includes a labeled source language dataset including source language sentences and corresponding labels, as the training examples of the labeled source language dataset. The training batch preparation subsystem 506 can, prior to accessing the plurality of datasets, provide as an input to an ML translation model, the source language sentences and the corresponding labels, where the ML translation model is configured to translate the source language sentences from the source language into the target language, and obtain a labeled machine-translated target language dataset based on an output provided by the ML translation model. In embodiments, the labeled machine-translated target language dataset is included in the plurality of datasets and includes labeled machine-translated target language sentences in the target language, as the training examples.
In embodiments, obtaining the labeled machine-translated target language dataset includes identifying, in at least one of the source language sentences, a multi-word sequence in the source language; identifying, in at least one of the machine-translated target language sentences that corresponds to the at least one of the source language sentences, respective words in the target language that correspond to the multi-word sequence; determining whether the labels correctly identify the respective words in the target language; and based on the determining that the labels do not correctly identify the respective words, correcting an alignment of the labels to correctly identify the respective words in the target language.
At operations 704 and 706, the training batch preparation subsystem 506 can generate training batches including the training examples.
At operation 704, the training batch preparation subsystem 506 can select datasets among the plurality of datasets that include the training examples in a source language and a target language.
At operation 706, the training batch preparation subsystem 506 can sample, based on a sampling weight that is determined for each of the selected datasets, the training examples from the selected datasets to generate the training batches, where the sampling weight is determined for each of the selected datasets based on one or more attributes common to the training examples of the selected dataset, the one or more attributes including at least one among a language identifier, a translation source origin, and a presence of labels.
In an example, the plurality of datasets further includes a labeled target language dataset including human-translated target language sentences in the target language and corresponding labels, as the training examples of the labeled target language dataset. The training batch preparation subsystem 506 can sample the training examples from the labeled source language dataset, to generate one or more labeled source language training batches, sample the training examples from the labeled target language dataset, to generate one or more labeled target language training batches, and sample the training examples from the labeled machine-translated target language dataset, to generate one or more labeled machine-translated target language training batches, where the sampling weight for the labeled target language dataset is greater than the sampling weight for the labeled machine-translated target language dataset, which results in a greater number of the training examples sampled from the labeled target language dataset as compared to a number of the training examples sampled from the labeled machine-translated target language dataset.
In an example, the plurality of datasets further includes an unlabeled bilingual sentence pairs dataset including unlabeled sentence pairs in the source language and the target language, as the training examples of the unlabeled bilingual sentence pairs dataset, and a labeled target language dataset including human-translated target language sentences in the target language and corresponding labels, as the training examples of the labeled target language dataset. The training batch preparation subsystem 506 can sample the training examples from labeled datasets including the labeled source language dataset, the labeled target language dataset, and the labeled machine-translated target language dataset, to generate one or more labeled training batches, each of the one or more labeled training batches including the training examples from one of the labeled source language dataset, the labeled target language dataset, or the labeled machine-translated target language dataset, and sample the training examples from the unlabeled bilingual sentence pairs dataset, to generate one or more unlabeled training batches, where the sampling weight for sampling the training examples from the labeled datasets is greater than the sampling weight for sampling the training examples from the unlabeled bilingual sentence pairs dataset, which results in a greater number of the training examples being sampled from the labeled datasets as compared to a number of the training examples sampled from the unlabeled bilingual sentence pairs dataset.
At operation 708, the MLMT model generation subsystem 504 can train an ML model for performing at least a first task using the training examples of the training batches, by interleavingly inputting the training batches to the ML model, evaluating, using a first loss, performance of at least the first task by the ML model on the training examples of the training batches, and updating, using an optimization function, model parameters of the ML model based on the performance of the at least the first task.
In embodiments, the ML model is trained using the training examples from the one or more labeled source language training batches, the one or more labeled target language training batches, and the one or more labeled machine-translated target language training batches.
In embodiments, the ML model is trained using the training examples from at least one among (i) the one or more labeled training batches and (ii) the one or more unlabeled training batches. When the ML model is trained using the one or more of the labeled training batches, the model parameters are updated by minimizing the first loss, which is a cross entropy loss function, and, when the ML model is trained using the one or more of the unlabeled training batches, the model parameters are updated by minimizing a second loss, which is a Kullback-Leibler divergence function.
At operation 710, the MLMT model generation subsystem 504 can output the trained ML model configured to perform the at least the first task on input utterances in the source language and on input utterances in the target language.
In some embodiments, the ML model is a multi-task model trained for performing the first task and a second task, the first task is an aspect-based sentiment analysis (ABSA) task for predicting a sentiment of the input utterances based on an aspect in the input utterances, the second task is a sentence-level sentiment analysis (SLSA) task for predicting a sentiment of the input utterances based on an overall sentiment polarity within the input utterances. The training batch preparation subsystem 506 can sample the training examples from the selected datasets to generate a set of ABSA training batches including ABSA training examples for training the ML model on the ABSA task, and sample the training examples from the selected datasets to generate a set of SLSA training batches including SLSA training examples for training the ML model on the SLSA task. The ML model can be then trained on the ABSA task using the ABSA training examples and on the SLSA task using the SLSA training examples, where the set of ABSA training batches and the set of SLSA training batches are interleavingly provided to the ML model.
When the ML model is trained using the ABSA training examples of the set of ABSA training batches, the model parameters are updated by minimizing the first loss, and, when the ML model is trained using the SLSA training examples of the set of SLSA training batches, the model parameters are updated by minimizing a second loss.
The set of ABSA training batches can include one or more ABSA training batches. The set of SLSA training batches can include one or more SLSA training batches.
Example Cloud Implementation
As noted above, infrastructure as a service (IaaS) is one particular type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In an IaaS model, a cloud computing provider can host the infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., a hypervisor layer), or the like). In some cases, an IaaS provider may also supply a variety of services to accompany those infrastructure components (example services include billing software, monitoring software, logging software, load balancing software, clustering software, etc.). Thus, as these services may be policy-driven, IaaS users may be able to implement policies to drive load balancing to maintain application availability and performance.
In some instances, IaaS customers may access resources and services through a wide area network (WAN), such as the Internet, and can use the cloud provider's services to install the remaining elements of an application stack. For example, the user can log in to the IaaS platform to create virtual machines (VMs), install operating systems (OSs) on each virtual machine, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software into that virtual machine. Customers can then use the provider's services to perform various functions, including balancing network traffic, troubleshooting application issues, monitoring performance, managing disaster recovery, etc.
In most cases, a cloud computing model will require the participation of a cloud provider. The cloud provider may, but need not be, a third-party service that specializes in providing (e.g., offering, renting, selling) IaaS. An entity might also opt to deploy a private cloud, becoming its own provider of infrastructure services.
In some examples, IaaS deployment is the process of putting a new application, or a new version of an application, onto a prepared application server or the like. It may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider, below the hypervisor layer (e.g., the servers, storage, network hardware, and virtualization). Thus, the customer may be responsible for handling (OS), middleware, and/or application deployment (e.g., on self-service virtual machines (e.g., that can be spun up on demand) or the like.
In some examples, IaaS provisioning may refer to acquiring computers or virtual hosts for use, and even installing needed libraries or services on them. In most cases, deployment does not include provisioning, and the provisioning may need to be performed first.
In some cases, there are two different challenges for IaaS provisioning. First, there is the initial challenge of provisioning the initial set of infrastructure before anything is running. Second, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.) once everything has been provisioned. In some cases, these two challenges may be addressed by enabling the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., what resources depend on which, and how they each work together) can be described declaratively. In some instances, once the topology is defined, a workflow can be generated that creates and/or manages the different components described in the configuration files.
In some examples, an infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., a potentially on-demand pool of configurable and/or shared computing resources), also known as a core network. In some examples, there may also be one or more inbound/outbound traffic group rules provisioned to define how the inbound and/or outbound traffic of the network will be set up and one or more virtual machines (VMs). Other infrastructure elements may also be provisioned, such as a load balancer, a database, or the like. As more and more infrastructure elements are desired and/or added, the infrastructure may incrementally evolve.
In some instances, continuous deployment techniques may be employed to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques can enable infrastructure management within these environments. In some examples, service teams can write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across various different geographic locations, sometimes spanning the entire world). However, in some examples, the infrastructure on which the code will be deployed must first be set up. In some instances, the provisioning can be done manually, a provisioning tool may be utilized to provision the resources, and/or deployment tools may be utilized to deploy the code once the infrastructure is provisioned.
The VCN 806 can include a local peering gateway (LPG) 810 that can be communicatively coupled to a secure shell (SSH) VCN 812 via an LPG 810 contained in the SSH VCN 812. The SSH VCN 812 can include an SSH subnet 814, and the SSH VCN 812 can be communicatively coupled to a control plane VCN 816 via the LPG 810 contained in the control plane VCN 816. Also, the SSH VCN 812 can be communicatively coupled to a data plane VCN 818 via an LPG 810. The control plane VCN 816 and the data plane VCN 818 can be contained in a service tenancy 819 that can be owned and/or operated by the IaaS provider.
The control plane VCN 816 can include a control plane demilitarized zone (DMZ) tier 820 that acts as a perimeter network (e.g., portions of a corporate network between the corporate intranet and external networks). The DMZ-based servers may have restricted responsibilities and help keep breaches contained. Additionally, the DMZ tier 820 can include one or more load balancer (LB) subnet(s) 822, a control plane app tier 824 that can include app subnet(s) 826, a control plane data tier 828 that can include database (DB) subnet(s) 830 (e.g., frontend DB subnet(s) and/or backend DB subnet(s)). The LB subnet(s) 822 contained in the control plane DMZ tier 820 can be communicatively coupled to the app subnet(s) 826 contained in the control plane app tier 824 and an Internet gateway 834 that can be contained in the control plane VCN 816, and the app subnet(s) 826 can be communicatively coupled to the DB subnet(s) 830 contained in the control plane data tier 828 and a service gateway 836 and a network address translation (NAT) gateway 838. The control plane VCN 816 can include the service gateway 836 and the NAT gateway 838.
The control plane VCN 816 can include a data plane mirror app tier 840 that can include app subnet(s) 826. The app subnet(s) 826 contained in the data plane mirror app tier 840 can include a virtual network interface controller (VNIC) 842 that can execute a compute instance 844. The compute instance 844 can communicatively couple the app subnet(s) 826 of the data plane mirror app tier 840 to app subnet(s) 826 that can be contained in a data plane app tier 846.
The data plane VCN 818 can include the data plane app tier 846, a data plane DMZ tier 848, and a data plane data tier 850. The data plane DMZ tier 848 can include LB subnet(s) 822 that can be communicatively coupled to the app subnet(s) 826 of the data plane app tier 846 and the Internet gateway 834 of the data plane VCN 818. The app subnet(s) 826 can be communicatively coupled to the service gateway 836 of the data plane VCN 818 and the NAT gateway 838 of the data plane VCN 818. The data plane data tier 850 can also include the DB subnet(s) 830 that can be communicatively coupled to the app subnet(s) 826 of the data plane app tier 846.
The Internet gateway 834 of the control plane VCN 816 and of the data plane VCN 818 can be communicatively coupled to a metadata management service 852 that can be communicatively coupled to public Internet 854. Public Internet 854 can be communicatively coupled to the NAT gateway 838 of the control plane VCN 816 and of the data plane VCN 818. The service gateway 836 of the control plane VCN 816 and of the data plane VCN 818 can be communicatively couple to cloud services 856.
In some examples, the service gateway 836 of the control plane VCN 816 or of the data plane VCN 818 can make application programming interface (API) calls to cloud services 856 without going through public Internet 854. The API calls to cloud services 856 from the service gateway 836 can be one-way: the service gateway 836 can make API calls to cloud services 856, and cloud services 856 can send requested data to the service gateway 836. But, cloud services 856 may not initiate API calls to the service gateway 836.
In some examples, the secure host tenancy 804 can be directly connected to the service tenancy 819, which may be otherwise isolated. The secure host subnet 808 can communicate with the SSH subnet 814 through an LPG 810 that may enable two-way communication over an otherwise isolated system. Connecting the secure host subnet 808 to the SSH subnet 814 may give the secure host subnet 808 access to other entities within the service tenancy 819.
The control plane VCN 816 may allow users of the service tenancy 819 to set up or otherwise provision desired resources. Desired resources provisioned in the control plane VCN 816 may be deployed or otherwise used in the data plane VCN 818. In some examples, the control plane VCN 816 can be isolated from the data plane VCN 818, and the data plane mirror app tier 840 of the control plane VCN 816 can communicate with the data plane app tier 846 of the data plane VCN 818 via VNICs 842 that can be contained in the data plane mirror app tier 840 and the data plane app tier 846.
In some examples, users of the system, or customers, can make requests, for example create, read, update, or delete (CRUD) operations, through public Internet 854 that can communicate the requests to the metadata management service 852. The metadata management service 852 can communicate the request to the control plane VCN 816 through the Internet gateway 834. The request can be received by the LB subnet(s) 822 contained in the control plane DMZ tier 820. The LB subnet(s) 822 may determine that the request is valid, and in response to this determination, the LB subnet(s) 822 can transmit the request to app subnet(s) 826 contained in the control plane app tier 824. If the request is validated and requires a call to public Internet 854, the call to public Internet 854 may be transmitted to the NAT gateway 838 that can make the call to public Internet 854. Metadata that may be desired to be stored by the request can be stored in the DB subnet(s) 830.
In some examples, the data plane mirror app tier 840 can facilitate direct communication between the control plane VCN 816 and the data plane VCN 818. For example, changes, updates, or other suitable modifications to configuration may be desired to be applied to the resources contained in the data plane VCN 818. Via a VNIC 842, the control plane VCN 816 can directly communicate with, and can thereby execute the changes, updates, or other suitable modifications to configuration to, resources contained in the data plane VCN 818.
In some embodiments, the control plane VCN 816 and the data plane VCN 818 can be contained in the service tenancy 819. In this case, the user, or the customer, of the system may not own or operate either the control plane VCN 816 or the data plane VCN 818. Instead, the IaaS provider may own or operate the control plane VCN 816 and the data plane VCN 818, both of which may be contained in the service tenancy 819. This embodiment can enable isolation of networks that may prevent users or customers from interacting with other users', or other customers', resources. Also, this embodiment may allow users or customers of the system to store databases privately without needing to rely on public Internet 854, which may not have a desired level of threat prevention, for storage.
In other embodiments, the LB subnet(s) 822 contained in the control plane VCN 816 can be configured to receive a signal from the service gateway 836. In this embodiment, the control plane VCN 816 and the data plane VCN 818 may be configured to be called by a customer of the IaaS provider without calling public Internet 854. Customers of the IaaS provider may desire this embodiment since database(s) that the customers use may be controlled by the IaaS provider and may be stored on the service tenancy 819, which may be isolated from public Internet 854.
The control plane VCN 916 can include a control plane DMZ tier 920 (e.g., the control plane DMZ tier 820 of
The control plane VCN 916 can include a data plane mirror app tier 940 (e.g., the data plane mirror app tier 840 of
The Internet gateway 934 contained in the control plane VCN 916 can be communicatively coupled to a metadata management service 952 (e.g., the metadata management service 852 of
In some examples, the data plane VCN 918 can be contained in the customer tenancy 921. In this case, the IaaS provider may provide the control plane VCN 916 for each customer, and the IaaS provider may, for each customer, set up a unique compute instance 944 that is contained in the service tenancy 919. Each compute instance 944 may allow communication between the control plane VCN 916, contained in the service tenancy 919, and the data plane VCN 918 that is contained in the customer tenancy 921. The compute instance 944 may allow-resources, that are provisioned in the control plane VCN 916 that is contained in the service tenancy 919, to be deployed or otherwise used in the data plane VCN 918 that is contained in the customer tenancy 921.
In other examples, the customer of the IaaS provider may have databases that live in the customer tenancy 921. In this example, the control plane VCN 916 can include the data plane mirror app tier 940 that can include app subnet(s) 926. The data plane mirror app tier 940 can reside in the data plane VCN 918, but the data plane mirror app tier 940 may not live in the data plane VCN 918. That is, the data plane mirror app tier 940 may have access to the customer tenancy 921, but the data plane mirror app tier 940 may not exist in the data plane VCN 918 or be owned or operated by the customer of the IaaS provider. The data plane mirror app tier 940 may be configured to make calls to the data plane VCN 918 but may not be configured to make calls to any entity contained in the control plane VCN 916. The customer may desire to deploy or otherwise use resources in the data plane VCN 918 that are provisioned in the control plane VCN 916, and the data plane mirror app tier 940 can facilitate the desired deployment, or other usage of resources, of the customer.
In some embodiments, the customer of the IaaS provider can apply filters to the data plane VCN 918. In this embodiment, the customer can determine what the data plane VCN 918 can access, and the customer may restrict access to public Internet 954 from the data plane VCN 918. The IaaS provider may not be able to apply filters or otherwise control access of the data plane VCN 918 to any outside networks or databases. Applying filters and controls by the customer onto the data plane VCN 918, contained in the customer tenancy 921, can help isolate the data plane VCN 918 from other customers and from public Internet 954.
In some embodiments, cloud services 956 can be called by the service gateway 936 to access services that may not exist on public Internet 954, on the control plane VCN 916, or on the data plane VCN 918. The connection between cloud services 956 and the control plane VCN 916 or the data plane VCN 918 may not be live or continuous. Cloud services 956 may exist on a different network owned or operated by the IaaS provider. Cloud services 956 may be configured to receive calls from the service gateway 936 and may be configured to not receive calls from public Internet 954. Some cloud services 956 may be isolated from other cloud services 956, and the control plane VCN 916 may be isolated from cloud services 956 that may not be in the same region as the control plane VCN 916. For example, the control plane VCN 916 may be located in “Region 1,” and cloud service “Deployment 8,” may be located in Region 1 and in “Region 2.” If a call to Deployment 8 is made by the service gateway 936 contained in the control plane VCN 916 located in Region 1, the call may be transmitted to Deployment 8 in Region 1. In this example, the control plane VCN 916, or Deployment 8 in Region 1, may not be communicatively coupled to, or otherwise in communication with, Deployment 8 in Region 2.
The control plane VCN 1016 can include a control plane DMZ tier 1020 (e.g., the control plane DMZ tier 820 of
The data plane VCN 1018 can include a data plane app tier 1046 (e.g., the data plane app tier 846 of
The untrusted app subnet(s) 1062 can include one or more primary VNICs 1064(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 1066(1)-(N). Each tenant virtual machine 1066(1)-(N) can be communicatively coupled to a respective app subnet 1067(1)-(N) that can be contained in respective container egress VCNs 1068(1)-(N) that can be contained in respective customer tenancies 1070(1)-(N). Respective secondary VNICs 1072(1)-(N) can facilitate communication between the untrusted app subnet(s) 1062 contained in the data plane VCN 1018 and the app subnet contained in the container egress VCNs 1068(1)-(N). Each container egress VCNs 1068(1)-(N) can include a NAT gateway 1038 that can be communicatively coupled to public Internet 1054 (e.g., public Internet 854 of
The Internet gateway 1034 contained in the control plane VCN 1016 and contained in the data plane VCN 1018 can be communicatively coupled to a metadata management service 1052 (e.g., the metadata management service 852 of
In some embodiments, the data plane VCN 1018 can be integrated with customer tenancies 1070. This integration can be useful or desirable for customers of the IaaS provider in some cases such as a case that may desire support when executing code. The customer may provide code to run that may be destructive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response to this, the IaaS provider may determine whether to run code given to the IaaS provider by the customer.
In some examples, the customer of the IaaS provider may grant temporary network access to the IaaS provider and request a function to be attached to the data plane app tier 1046. Code to run the function may be executed in the virtual machines 1066(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN 1018. Each virtual machine 1066(1)-(N) may be connected to one customer tenancy 1070. Respective containers 1071(1)-(N) contained in the virtual machines 1066(1)-(N) may be configured to run the code. In this case, there can be a dual isolation (e.g., the containers 1071(1)-(N) running code, where the containers 1071(1)-(N) may be contained in at least the virtual machine 1066(1)-(N) that are contained in the untrusted app subnet(s) 1062), which may help prevent incorrect or otherwise undesirable code from damaging the network of the IaaS provider or from damaging a network of a different customer. The containers 1071(1)-(N) may be communicatively coupled to the customer tenancy 1070 and may be configured to transmit or receive data from the customer tenancy 1070. The containers 1071(1)-(N) may not be configured to transmit or receive data from any other entity in the data plane VCN 1018. Upon completion of running the code, the IaaS provider may kill or otherwise dispose of the containers 1071(1)-(N).
In some embodiments, the trusted app subnet(s) 1060 may run code that may be owned or operated by the IaaS provider. In this embodiment, the trusted app subnet(s) 1060 may be communicatively coupled to the DB subnet(s) 1030 and be configured to execute CRUD operations in the DB subnet(s) 1030. The untrusted app subnet(s) 1062 may be communicatively coupled to the DB subnet(s) 1030, but in this embodiment, the untrusted app subnet(s) may be configured to execute read operations in the DB subnet(s) 1030. The containers 1071(1)-(N) that can be contained in the virtual machine 1066(1)-(N) of each customer and that may run code from the customer may not be communicatively coupled with the DB subnet(s) 1030.
In other embodiments, the control plane VCN 1016 and the data plane VCN 1018 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 1016 and the data plane VCN 1018. However, communication can occur indirectly through at least one method. An LPG 1010 may be established by the IaaS provider that can facilitate communication between the control plane VCN 1016 and the data plane VCN 1018. In another example, the control plane VCN 1016 or the data plane VCN 1018 can make a call to cloud services 1056 via the service gateway 1036. For example, a call to cloud services 1056 from the control plane VCN 1016 can include a request for a service that can communicate with the data plane VCN 1018.
The control plane VCN 1116 can include a control plane DMZ tier 1120 (e.g., the control plane DMZ tier 820 of
The data plane VCN 1118 can include a data plane app tier 1146 (e.g., the data plane app tier 846 of
The untrusted app subnet(s) 1162 can include primary VNICs 1164(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 1166(1)-(N) residing within the untrusted app subnet(s) 1162. Each tenant virtual machine 1166(1)-(N) can run code in a respective container 1167(1)-(N), and be communicatively coupled to an app subnet 1126 that can be contained in a data plane app tier 1146 that can be contained in a container egress VCN 1168. Respective secondary VNICs 1172(1)-(N) can facilitate communication between the untrusted app subnet(s) 1162 contained in the data plane VCN 1118 and the app subnet contained in the container egress VCN 1168. The container egress VCN can include a NAT gateway 1138 that can be communicatively coupled to public Internet 1154 (e.g., public Internet 854 of
The Internet gateway 1134 contained in the control plane VCN 1116 and contained in the data plane VCN 1118 can be communicatively coupled to a metadata management service 1152 (e.g., the metadata management service 852 of
In some examples, the pattern illustrated by the architecture of block diagram 1100 of
In other examples, the customer can use the containers 1167(1)-(N) to call cloud services 1156. In this example, the customer may run code in the containers 1167(1)-(N) that requests a service from cloud services 1156. The containers 1167(1)-(N) can transmit this request to the secondary VNICs 1172(1)-(N) that can transmit the request to the NAT gateway that can transmit the request to public Internet 1154. Public Internet 1154 can transmit the request to LB subnet(s) 1122 contained in the control plane VCN 1116 via the Internet gateway 1134. In response to determining the request is valid, the LB subnet(s) can transmit the request to app subnet(s) 1126 that can transmit the request to cloud services 1156 via the service gateway 1136.
It should be appreciated that IaaS architectures 800, 900, 1000, 1100 depicted in the figures may have other components than those depicted. Further, the embodiments shown in the figures are only some examples of a cloud infrastructure system that may incorporate an embodiment of the disclosure. In some other embodiments, the IaaS systems may have more or fewer components than shown in the figures, may combine two or more components, or may have a different configuration or arrangement of components.
In certain embodiments, the IaaS systems described herein may include a suite of applications, middleware, and database service offerings that are delivered to a customer in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such an IaaS system is the Oracle Cloud Infrastructure (OCI) provided by the present assignee.
Example Computer System
Bus subsystem 1202 provides a mechanism for letting the various components and subsystems of computer system 1200 communicate with each other as intended. Although bus subsystem 1202 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1202 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, which can be implemented as a Mezzanine bus manufactured to the IEEE P1386.1 standard.
Processing unit 1204, which can be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of computer system 1200. One or more processors may be included in processing unit 1204. These processors may include single core or multicore processors. In certain embodiments, processing unit 1204 may be implemented as one or more independent processing units 1232 and/or 1234 with single or multicore processors included in each processing unit. In other embodiments, processing unit 1204 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.
In various embodiments, processing unit 1204 can execute a variety of programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in processor(s) 1204 and/or in storage subsystem 1218. Through suitable programming, processor(s) 1204 can provide various functionalities described above. Computer system 1200 may additionally include a processing acceleration unit 1206, which can include a digital signal processor (DSP), a special-purpose processor, and/or the like.
I/O subsystem 1208 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, pointing devices such as a mouse or trackball, a touchpad or touch screen incorporated into a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and/or gesture recognition devices such as the Microsoft Kinect® motion sensor that enables users to control and interact with an input device, such as the Microsoft Xbox® 360 game controller, through a natural user interface using gestures and spoken commands. User interface input devices may also include eye gesture recognition devices such as the Google Glass® blink detector that detects eye activity (e.g., ‘blinking’ while taking pictures and/or making a menu selection) from users and transforms the eye gestures as input into an input device (e.g., Google Glass®). Additionally, user interface input devices may include voice recognition sensing devices that enable users to interact with voice recognition systems (e.g., Siri® navigator), through voice commands.
User interface input devices may also include, without limitation, three dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic Tablets, and 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 rangefinders, and eye gaze tracking devices. Additionally, user interface input devices may include, for example, medical imaging input devices such as computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasonography devices. User interface input devices may also include, for example, audio input devices such as MIDI keyboards, digital musical instruments and the like.
User interface output devices may include a display subsystem, indicator lights, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat-panel device, such as that using a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, and the like. 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 1200 to a user or other computer. For example, user interface output devices may include, without limitation, a variety of display devices that visually convey text, graphics and audio/video information such as monitors, printers, speakers, headphones, automotive navigation systems, plotters, voice output devices, and modems.
Computer system 1200 may include a storage subsystem 1218 that includes software elements, shown as being currently located within a system memory 1210. System memory 1210 may store program instructions that are loadable and executable on processing unit 1204, as well as data generated during the execution of these programs.
Depending on the configuration and type of computer system 1200, system memory 1210 may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.) The RAM typically contains data and/or program services that are immediately accessible to and/or presently being operated and executed by processing unit 1204. In some implementations, system memory 1210 may include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer system 1200, such as during start-up, may typically be stored in the ROM. By way of example, and not limitation, system memory 1210 also illustrates application programs 1212, which may include client applications, Web browsers, mid-tier applications, relational database management systems (RDBMS), etc., program data 1214, and an operating system 1216. By way of example, operating system 1216 may include various versions of Microsoft Windows®, Apple Macintosh®, and/or Linux operating systems, a variety of commercially-available UNIX® or UNIX-like operating systems (including without limitation the variety of GNU/Linux operating systems, the Google Chrome® OS, and the like) and/or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS operating systems.
Storage subsystem 1218 may also provide a tangible computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code services, instructions) that when executed by a processor provide the functionality described above may be stored in storage subsystem 1218. These software services or instructions may be executed by processing unit 1204. Storage subsystem 1218 may also provide a repository for storing data used in accordance with the present disclosure.
Storage subsystem 1218 may also include a computer-readable storage media reader 1220 that can further be connected to computer-readable storage media 1222. Together and, optionally, in combination with system memory 1210, computer-readable storage media 1222 may comprehensively represent remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information.
Computer-readable storage media 1222 containing code, or portions of code, can also include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information. This can include tangible computer-readable storage media such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer readable media. This can also include nontangible computer-readable media, such as data signals, data transmissions, or any other medium which can be used to transmit the desired information and which can be accessed by computer system 1200.
By way of example, computer-readable storage media 1222 may include a hard disk drive that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive that reads from or writes to a removable, nonvolatile magnetic disk, and an optical disk drive that reads from or writes to a removable, nonvolatile optical disk such as a CD ROM, DVD, and Blu-Ray® disk, or other optical media. Computer-readable storage media 1222 may include, but is not limited to, Zip® drives, flash memory cards, universal serial bus (USB) flash drives, secure digital (SD) cards, DVD disks, digital video tape, and the like. Computer-readable storage media 1222 may also include, solid-state drives (SSD) based on non-volatile memory such as flash-memory based SSDs, enterprise flash drives, solid state ROM, and the like, 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 and flash memory based SSDs. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program services, and other data for computer system 1200.
Communications subsystem 1224 provides an interface to other computer systems and networks. Communications subsystem 1224 serves as an interface for receiving data from and transmitting data to other systems from computer system 1200. For example, communications subsystem 1224 may enable computer system 1200 to connect to one or more devices via the Internet. In some embodiments, communications subsystem 1224 can include radio frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data network technology, such as 3G, 4G, 5G or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof)), global positioning system (GPS) receiver components, and/or other components. In some embodiments, communications subsystem 1224 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.
In some embodiments, communications subsystem 1224 may also receive input communication in the form of structured and/or unstructured data feeds 1226, event streams 1228, event updates 1230, and the like on behalf of one or more users who may use computer system 1200.
By way of example, communications subsystem 1224 may be configured to receive data feeds 1226 in real-time from users of social networks and/or other communication services such as Twitter® feeds, Facebook® updates, web feeds such as Rich Site Summary (RSS) feeds, and/or real-time updates from one or more third party information sources.
Additionally, communications subsystem 1224 may also be configured to receive data in the form of continuous data streams, which may include event streams 1228 of real-time events and/or event updates 1230, that may be continuous or unbounded in nature with no explicit end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measuring tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.
Communications subsystem 1224 may also be configured to output the structured and/or unstructured data feeds 1226, event streams 1228, event updates 1230, and the like to one or more databases that may be in communication with one or more streaming data source computers coupled to computer system 1200.
Computer system 1200 can be one of various types, including a handheld portable device (e.g., an iPhone® cellular phone, an iPad® computing Tablet, a PDA), a wearable device (e.g., a Google Glass® head mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.
Due to the ever-changing nature of computers and networks, the description of computer system 1200 depicted in the figure is intended only as a specific example. Many other configurations having more or fewer components than the system depicted in the figure are possible. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, firmware, software (including applets), or a combination. Further, connection to other computing devices, such as network input/output devices, may be employed. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.
Although specific embodiments have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the disclosure. Embodiments are not restricted to operation within certain specific data processing environments, but are free to operate within a plurality of data processing environments. Additionally, although embodiments have been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described series of transactions and steps. Various features and aspects of the above-described embodiments may be used individually or jointly.
Further, while embodiments have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present disclosure. Embodiments may be implemented only in hardware, or only in software, or using combinations thereof. The various processes described herein can be implemented on the same processor or different processors in any combination. Accordingly, where components or services are described as being configured to perform certain operations, such configuration can be accomplished, e.g., by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as microprocessors) to perform the operation, or any combination thereof. Processes can communicate using a variety of techniques including but not limited to conventional techniques for inter process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.
The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions, and other modifications and changes may be made thereunto without departing from the broader spirit and scope as set forth in the claims. Thus, although specific disclosure embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.
The use of the terms “a” and “an” and “the” and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “including,” “having,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. The term “connected” is to be construed as a partly or wholly contained within, attached to, or joined together, even if there is something intervening. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate embodiments and does not pose a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.
Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is intended to be understood within the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.
Preferred embodiments of this disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. Those of ordinary skill should be able to employ such variations as appropriate and the disclosure may be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein.
All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.
In the foregoing specification, aspects of the disclosure are described with reference to specific embodiments thereof, but those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above-described disclosure may be used individually or jointly. Further, embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. The specification and drawings are, accordingly, to be regarded as illustrative rather than restrictive.
As used herein, when an action is “based on” something, this means the action is based at least in part on at least a part of the something. As used herein, the terms “substantially,” “approximately” and “about” are defined as being largely but not necessarily wholly what is specified (and include wholly what is specified) as understood by one of ordinary skill in the art. In any disclosed embodiment, the term “substantially,” “approximately,” or “about” may be substituted with “within [a percentage] of” what is specified, where the percentage may be from 0 to 10 percent, as a non-limiting example.
While illustrative examples of the application have been described in detail herein, it is to be understood that the inventive concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be construed to include such variations, except as limited by the prior art.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202241058581 | Oct 2022 | IN | national |
The present application is a Non-Provisional Application of and claims the benefit and priority under 35 U.S.C. 119(e) of Indian Provisional Application 202241058581, filed Oct. 13, 2022. The present application is related to U.S. Non-Provisional application Ser. No. 18/485,700, filed Oct. 12, 2023, entitled “Multi-Task Model with Context Masking.” The disclosures of the above-named applications are incorporated by reference herein in their entireties.
