A Survey of Available Corpora for Building Data-Driven Dialogue Systems

During the past decade, several areas of speech and language understanding have witnessed substantial breakthroughs from the use of data-driven models. In the area of dialogue systems, the trend is less obvious, and most practical systems are still built through significant engineering and expert knowledge. Nevertheless, several recent results suggest that data-driven approaches are feasible and quite promising. To facilitate research in this area, we have carried out a wide survey of publicly available datasets suitable for data-driven learning of dialogue systems. We discuss important characteristics of these datasets, how they can be used to learn diverse dialogue strategies, and their other potential uses. We also examine methods for transfer learning between datasets and the use of external knowledge. Finally, we discuss appropriate choice of evaluation metrics for the learning objective.

If you think there are any errors or missing datasets, please submit a pull request or issue to the repository for this site!

• Iulian Vlad Serban
• Ryan Lowe
• Peter Henderson
• Laurent Charlin
• Joelle Pineau
[ PDF ]    

Human-Machine Dialogue Datasets

Name	Type	Topics	Avg. # of turns	Total # of dialogues	Total # of words	Description	Links
DSTC1 [Williams et al., 2013]	Spoken	Bus schedules	13.56	15,000	3.7M	Bus ride information system	Info and download
DSTC2 [Henderson et al., 2014b]	Spoken	Restaurants	7.88	3,000	432K	Restaurant booking system	Info and Download
DSTC3 [Henderson et al., 2014a]	Spoken	Tourist information	8.27	2,265	403K	Information for tourists	Info and Download
CMU Communicator Corpus [Bennett and Rudnicky, 2002]	Spoken	Travel	11.67	15,481	2M*	Travel planning and booking system	Info and Download
ATIS Pilot Corpus [Hemphill et al., 1990]	Spoken	Travel	25.4	41	11.4K*	Travel planning and booking system	Info Download
Ritel Corpus [Rosset and Petel, 2006]	Spoken	Unrestricted/ Diverse Topics	9.3*	582	60k	An annotated open-domain question answering spoken dialogue system	Info Contact corpus authors for download
DIALOG Mathematical Proofs [Wolska et al., 2004]	Spoken	Mathematics	12	66	8.7K*	Humans interact with computer system to do mathematical theorem proving	Info Contact corpus authors for download
MATCH Corpus [Georgila et al., 2010]	Spoken	Appointment Scheduling	14.0	447	69K*	A system for scheduling appointments.	Info and download
Maluuba Frames [El Asri et al., 2017]	Chat, QA & Recommendation	Travel & Vacation Booking	15	1369	-	For goal-driven dialogue systems. Semantic frames labeled and actions taken on a knowledge-base annotated.	Info and Download

Table 1: Human-machine dialogue datasets. Starred (*) numbers are approximated based on the average number of words per utterance.

Human-Human Constrained Dialogue Datasets

Name	Topics	Total # of dialogues	Total # of words	Total length	Description	Links
HCRC Map Task Corpus [Anderson et al., 1991]	Map-Reproducing Task	128	147k	18hrs	Dialogues from HLAP Task in which speakers must collaborate verbally to reproduce on one participant’s map a route printed on the other’s.	Info and Download
The Walking Around Corpus [Brennan et al., 2013]	Location Finding Task	36	300k*	33hrs	People collaborating over telephone to find certain locations.	Info and Download
Green Persuasive Database [Douglas-Cowie et al., 2007]	Lifestyle	8	35k*	4hrs	A persuader with (genuinely) strong pro-green feelings tries to convince persuadees to consider adopting more ‘green’ lifestyles.	Info Download
Intelligence Squared Debates [Zhang et al., 2016]	Debates	108	1.8M	200hrs*	Various topics in Oxford-style debates, each constrained to one subject. Audience opinions provided pre- and post-debates.	Info and Download
The Corpus of Professional Spoken American English [Barlow, 2000]	Politics, Education	200	2M	220hrs*	Interactions from faculty meetings and White House press conferences.	Info and Download (Download may require purchase.)
MAHNOB Mimicry Database [Sun et al., 2011]	Politics, Games	54	100k*	11hrs	Two experiments: a discussion on a political topic, and a role-playing game.	Info and Download
The IDIAP Wolf Corpus [Hung and Chittaranjan, 2010]	Role-Playing Game	15	60k*	7hrs	A recording of Werewolf role-playing game with annotations related to game progress.	Info and Download
SEMAINE corpus [McKeown et al., 2010]	Emotional Conversations	100	450k*	50hrs	Users were recorded while holding conversations with an operator who adopts roles designed to evoke emotional reactions.	Info and Download
DSTC4/DSTC5 Corpora [Kim et al., 2015,Kim et al., 2016]	Tourist	35	273k	21hrs	Tourist information exchange over Skype.	DSTC4 DSTC5 (DSTC4 Training Set with Chinese lang. Test Set)
Loqui Dialogue Corpus [Passonneau and Sachar, 2014]	Library Inquiries	82	21K	140*	Telephone interactions between librarians and patrons. Annotated dialogue acts, discussion topics, frames (discourse units), question-answer pairs.	Info and Download
MRDA Corpus [Shriberg et al., 2004]	ICSI Meetings	75	11K*	72hrs	Recordings of ICSI meetings. Topics include: ICSI meeting recorder project itself, automatic speech recognition, natural language processing and neural theories of language. Dialogue acts, question-answer pairs, and hot spots.	Info and Download
TRAINS 93 Dialogues Corpus [Heeman and Allen, 1995]	Railroad Freight Route Planning	98	55K	6.5hrs	Collaborative planning of railroad freight routes.	Info and Download
Verbmobil Corpus [Burger et al., 2000]	Appointment Scheduling	726	270K	38Hrs	Spontaneous speech data collected for the Verbmobil project. Full corpus is in English, German, and Japanese. We only show English statistics.	Info Download I Download II
ICT Rapport Datasets [Gratch et al., 2007]	Sexual Harassment Awareness	165	N/A	N/A	A speaker tells a story to a listener. The listener is asked to not speak during the story telling. Contains audio-visual data, transcriptions, and annotations.	Info and Download

Table 2: Human-human constrained spoken dialogue datasets. Starred (*) numbers are estimates based on the average rate of English speech from the National Center for Voice and Speech.

Human-Human Spontaneous Dialogue Datasets

Name	Topics	Total # of dialogues	Total # of words	Total length	Description	Links
Switchboard [Godfrey et al., 1992]	Casual Topics	2,400	3M	300hrs*	Telephone conversations on pre-specified topics	Info and Download
British National Corpus (BNC) [Leech, 1992]	Casual Topics	854	10M	1,000hrs*	British dialogues many contexts, from formal business or government meetings to radio shows and phone-ins.	Info and Download
CALLHOME American English Speech [Canavan et al., 1997]	Casual Topics	120	540k*	60hrs	Telephone conversations between family members or close friends.	Info and Download
CALLFRIEND American English Non-Southern Dialect [Canavan and Zipperlen, 1996]	Casual Topics	60	180k*	20hrs	Telephone conversations between Americans with a Southern accent.	Info and Download
The Bergen Corpus of London Teenage Language [Haslerud and Stenström, 1995]	Unrestricted	100	500k	55hrs	Spontaneous teenage talk recorded in 1993. Conversations were recorded secretly.	Info and Download
The Cambridge and Nottingham Corpus of Discourse in English [McCarthy, 1998]	Casual Topics	-	5M	550hrs*	British dialogues from wide variety of informal contexts, such as hair salons, restaurants, etc.	Info and Download Note: CANCODE is a subset of the Cambridge English Corpus.
D64 Multimodal Conversation Corpus [Oertel et al., 2013]	Unrestricted	2	70k*	8hrs	Several hours of natural interaction between a group of people	Contact corpus authors for data.
AMI Meeting Corpus [Renals et al., 2007]	Meetings	175	900k*	100hrs	Face-to-face meeting recordings.	Info and Download
Cardiff Conversation Database (CCDb) [Aubrey et al., 2013]	Unrestricted	30	20k*	150min	Audio-visual database with unscripted natural conversations, including visual annotations.	Info and Download
4D Cardiff Conversation Database (4D CCDb) [Vandeventer et al., 2015]	Unrestricted	17	2.5k*	17min	A version of the CCDb with 3D video	Info and Download
The Diachronic Corpus of Present-Day Spoken English [Aarts and Wallis, 2006]	Casual Topics	280	800k	80hrs*	Selection of face-to-face, telephone, and public discussion dialogue from Britain.	Info and Download
The Spoken Corpus of the Survey of English Dialects [Beare and Scott, 1999]	Casual Topics	314	800k	60hrs	Dialogue of people aged 60 or above talking about their memories, families, work and the folklore of the countryside from a century ago.	Info Contact corpus authors for download.
The Child Language Data Exchange System [MacWhinney and Snow, 1985]	Unrestricted	11K	10M	1,000hrs*	International database organized for the study of first and second language acquisition.	Info and Download
The Charlotte Narrative and Conversation Collection (CNCC) [Reppen and Ide, 2004]	Casual Topics	95	20K	2hrs*	Narratives, conversations and interviews representative of the residents of Mecklenburg County, North Carolina.	Info and Download

Table 3: Human-human spontaneous spoken dialogue datasets. Starred (*) numbers are estimates based on the average rate of English speech from the National Center for Voice and Speech.

Human-Human Scripted Dialogue Datasets

Name	Topics	Total # of utterances	Total # of dialogues	Total # of works	Total # of words	Description	Links
Movie-DiC [Banchs, 2012]	Movie dialogues	764k	132K	753	6M	Movie scripts of American films.	Contact corpus authors for data.
Movie-Triples [Serban et al., 2016]	Movie dialogues	736k	245K	614	13M	Triples of utterances which are filtered to come from X-Y-X triples.	Contact corpus authors for data.
Film Scripts Online Series	Movie scripts	1M*	263K	1,500	16M*	Two subsets of scripts (1000 American films and 500 mixed British/American films).	Info and Download
Cornell Movie-Dialogue Corpus [Danescu-Niculescu-Mizil and Lee, 2011]	Movie dialogues	305K	220K	617	9M*	Short conversations from film scripts, annotated with character metadata.	Info and Download
Filtered Movie Script Corpus [Nio et al., 2014]	Movie dialogues	173k	86K	1,786	2M*	Triples of utterances which are filtered to come from X-Y-X triples.	Info and Download
American Soap Opera Corpus [Davies, 2012b]	TV show scripts	10M*	1.2M	22,000	100M	Transcripts of American soap operas.	Info and Download
TVD Corpus [Roy et al., 2014]	TV show scripts	60k*	10K	191	600k*	TV scripts from a comedy (Big Bang Theory) and drama (Game of Thrones) show.	Info and Download
Character Style from Film Corpus [Walker et al., 2012a]	Movie scripts	664k	151K	862	9.6M	Scripts from IMSDb, annotated for linguistic structures and character archetypes.	Contact corpus authors for data.
SubTle Corpus [Ameixa and Coheur, 2013]	Movie subtitles	6.7M	3.35M	6,184	20M	Aligned interaction-response pairs from movie subtitles.	Contact corpus authors for data.
OpenSubtitles [Tiedemann, 2012]	Movie subtitles	140M*	36M	207,907	1B	Movie subtitles which are not speaker-aligned.	Info and Download
CED (1560-1760) Corpus [Kytö and Walker, 2006]	Written Works & Trial Proceedings	-	-	177	1.2M	Various scripted fictional works from (1560-1760) as well as court trial proceedings.	Info and Download

Table 4: Human-human scripted dialogue datasets. Quantities denoted with () indicate estimates based on average dialogues per movie seen in [Banchs, 2012] and the number of scripts or works. Dialogues may not be explicitly separated in these datasets. TV show datasets were adjusted based on the ratio of average film runtime (112 minutes) to average TV show runtime (36 minutes). This data was scraped from the IMBD database (http://www.imdb.com/interfaces). ( Starred (*) quantities are estimated based on the average number of words and utterances per film, and the average lengths of films and TV shows. Estimates derived from the Tameri Guide for Writers (http://www.tameri.com/format/wordcounts.html).

Human-Human Written Dialogue Datasets

Name	Type	Topics	Avg. # of turns	Total # of dialogues	Total # of words	Description	Links
NPS Chat Corpus [Forsyth and Martell, 2007]	Chat	Unrestricted	704	15	100M	Posts from age-specific online chat rooms.	Info and Download
Twitter Corpus [Ritter et al., 2010]	Microblog	Unrestricted	2	1.3M	125M	Tweets and replies extracted from Twitter	Contact corpus authors for data.
Twitter Triple Corpus [Sordoni et al., 2015]	Microblog	Unrestricted	3	4,232	65K	A-B-A triples extracted from Twitter	Info and Download
UseNet Corpus [Shaoul and Westbury, 2009]	Microblog	Unrestricted	687	47860	7B	UseNet forum postings	Info and Download
NUS SMS Corpus [Chen and Kan, 2013]	SMS messages	Unrestricted	18	3K	580,668*[¯]	SMS messages collected between two users, with timing analysis.	Info and Download
Reddit Domestic Abuse Corpus [Schrading et al., 2015]	Forum	Abuse help	17.53	21,133	19M-103M \triangle	Reddit posts from either domestic abuse subreddits, or general chat.	Info and Download
Reddit All Comments Corpus	Forum	General	--	--	--	1.7 Billion Reddit comments.	Info and Download
Settlers of Catan [Afantenos et al., 2012]	Chat	Game terms	95	21	-	Conversations between players in the game `Settlers of Catan'.	Info Contact corpus authors for download.
Cards Corpus [Djalali et al., 2012]	Chat	Game terms	38.1	1,266	282K	Conversations between players playing `Cards world'.	Info and Download
Agreement in Wikipedia Talk Pages [Andreas et al., 2012]	Forum	Unrestricted	2	822	110K	LiveJournal and Wikipedia Discussions forum threads. Agreement type and level annotated.	Info and Download
Agreement by Create Debaters [Rosenthal and McKeown, 2015]	Forum	Unrestricted	2	10K	1.4M	Create Debate forum conversations. Annotated what type of agreement (e.g. paraphrase) or disagreement.	Info and Download
Internet Argument Corpus [Walker et al., 2012b]	Forum	Politics	35.45	11K	73M	Debates about specific political or moral positions.	Info and Download
MPC Corpus [Shaikh et al., 2010]	Chat	Social tasks	520	14	58K	Conversations about general, political, and interview topics.	Contact corpus authors for data.
Ubuntu Dialogue Corpus [Lowe et al., 2015a]	Chat	Ubuntu Operating System	7.71	930K	100M	Dialogues extracted from Ubuntu chat stream on IRC.	Info and Download
Ubuntu Chat Corpus [Uthus and Aha, 2013]	Chat	Ubuntu Operating System	3381.6	10665	2B*[¯]	Chat stream scraped from IRC logs (no dialogues extracted).	Info and Download
Movie Dialog Dataset [Dodge et al., 2015]	Chat, QA & Recommendation	Movies	3.3	3.1M\blacktriangledown	185M	For goal-driven dialogue systems. Includes movie metadata as knowledge triples.	Info and Download

Table 5: Human-human written dialogue datasets. Starred (*) quantities are computed using word counts based on spaces (i.e. a word must be a sequence of characters preceded and followed by a space), but for certain corpora, such as IRC and SMS corpora, proper English words are sometimes concatenated together due to slang usage. Triangle (^\triangle) indicates lower and upper bounds computed using average words per utterance estimated on a similar Reddit corpus Schrading [2015]. Square (^[¯]) indicates estimates based only on English part of the corpus. Note that 2.1M dialogues from the Movie Dialog dataset (^{\blacktriangledown}) are in the form of simulated QA pairs. Dialogs indicated by () are contiguous blocks of recorded conversation in a multi-participant chat. In the case of UseNet, we note the total number of newsgroups and find the average turns as average number of posts collected per newsgroup. () indicates an estimate based on a Twitter dataset of similar size and refers to tokens as well as words.

Acknowledgements

The authors gratefully acknowledge financial support by the Samsung Advanced Institute of Technology (SAIT), the Natural Sciences and Engineering Research Council of Canada (NSERC), the Canada Research Chairs, the Canadian Institute for Advanced Research (CIFAR) and Compute Canada. Early versions of the manuscript benefited greatly from the proofreading of Melanie Lyman-Abramovitch, and later versions were extensively revised by Genevieve Fried and Nicolas Angelard-Gontier. The authors also thank Nissan Pow, Michael Noseworthy, Chia-Wei Liu, Gabriel Forgues, Alessandro Sordoni, Yoshua Bengio and Aaron Courville for helpful discussions.

The “AI” Label is Bullsh*t

The term “AI” has become overused, overextended, and marketed to oblivion like “HD” or “3D.” A new product with “AI” in the headline of its press release is thought to be more advanced. The time has come for us to speak clearly about “artificial intelligence” (“AI”) and arrive at a new, clean starting point from which to discuss things productively.

supermarket tabloids

Let’s begin with the words themselves, because if they are vague then we are already obscuring things. Let’s accept “artificial” at face value: it implies something synthetic, inorganic, not from nature, as in “artificial sweetener” or “artificial turf”. So be it.

The painfully overcharged word here when paired with the word artificial is “intelligence”.

In thinking about artificial intelligence, I won’t refer to Alan Turing or his famous “test,” for he himself pointed out (correctly) that this was meaningless. Nor will I quote Marvin Minsky, who passed away recently concerned we were repeating a so-called “AI Winter”: in that lofty expectations would lead to disappointment and an under-investment in the science for years. His worries are well founded, and that’s a different discussion. Another separate discussion is AI’s existential threat to humanity, which Bostrom, Musk, Kurzweil and others have pondered.

Instead let’s look at what nearly all of the software carrying the label “AI” is doing and how it relates to working with information.

I’ve been among the many who have long admired the thinking and writing of Peter Drucker. His clarity of thought is reminiscent of prior generation Austrian writers, including Zweig and Rilke.

So what would Drucker say about artificial intelligence?

Drucker would say that we are mostly talking about machines performing knowledge work. He would view the “intelligence” label as chimerical.

The term “knowledge worker” was coined by Drucker, who said in 1957 that “the most valuable asset of a 21st-century institution, whether business or non-business, will be its knowledge workers and their productivity.”

The utility of this term was to distinguish laborers (farmers, machinists, construction workers, etc.) in the workforce from a new emerging type of worker (accountants, architects, lawyers, etc.) who worked primarily with information.

Knowledge Work and Software

Here’s where it gets interesting. This new frontier of work “by thinking” certainly did not exclude machines — more accurately: computers — more specifically: software. That’s because the new knowledge-working genre that Drucker perceived in the 1950s was just beginning to interact with computers. Now of course, software has increasingly augmented and replaced human work as it relates to information, and today it is a pervasive phenomenon.

In fact, a software spreadsheet (one of the most useful and common pieces of software ever created) is capable of knowledge work. It’s doing a fair amount of the work that was done previously by calculators, and prior to that — a mano by number crunching humans. The spreadsheet is performing tasks that were once performed by a human knowledge worker. That is what it does.

We don’t refer to the work of an accounting package, a travel booking server, a payroll processor, CAD (computer aided design), and countless other software systems as “AI”.

Software has for a long time performed knowledge work and this work has evolved in complexity for decades. It has done so in narrowly defined tasks, always with a specific goal in mind. This is still true today.

The evolution of software as a knowledge worker

What about the “AI” that recognizes patterns in stock market data, translates writing from one language to another, transcribes audio or recognizes image patterns? This is also software applied to knowledge work.

We’re referring to a set of instructions applied to a computer system (CPU, memory, etc.) to move data around, calculate and output values. Today we have have a lot more “system” today than ever before, and we have a lot more data as well.

The fact that software is now doing its thing increasingly everywhere is a big thing. It is able to perform “knowledge work” in your car, in your hands, and in the world. It is able to do this kind of work while being connected to informational resources. Knowledge work, as Drucker pointed out, is intrinsically about information.

The primary difference between today’s knowledge worker and yesterday’s is the amount of processing and information at hand. What is deceivingly branded “AI” today is based on old algorithms (eg. neural networks, invented decades ago) applied to larger computing and datasets.

Intelligence?

Herein lies the significance of the term “intelligence”. A laborer is undoubtedly intelligent, a farmer deals with extraordinary amounts of information about crops, soil, weather, etc. But farmers are not knowledge workers, because their craft is not predominantly working with information, that’s secondary to the actual task at hand. The accountant, also intelligent, is on the other hand primarily working with information.

This is not about “intelligence”, but rather what they are working on, the nature of the work.

Just as knowledge work can be the job of a person, artificial knowledge work can be the job of a software application. This is what the vast majority of software with the “AI” branding is actually doing. But just because it’s called Artificial Intelligence doesn’t mean the software has any intelligence. But that too may be changing.

A field known as “Artificial General Intelligence”, or “AGI” is examining the possibility of software that can “think” in the pure sense of the word. What is referred to as “AGI” should simply and properly be called “AI” because once machines can acquire knowledge, learn adaptively and make rational choices, they become not just knowledge workers, but truly intelligent.

In conclusion, software continues to evolve in its capacity to perform knowledge work: narrowly defined information-driven tasks with specific objectives. The label “intelligence” has to do with something much more fundamental and elusive.

The human accountant has the ability to learn to be an architect (a different type of knowledge worker) but today’s artificial knowledge worker cannot adapt this way. Software code can “learn” but thus far only within a specific type of task. DeepMind’s “AlphaGo” defeated a Go professional player but it cannot play checkers, tic-tac-toe, or any other game. The “smartest” software applied in consumer and business settings today lacks the capacity to adapt itself outside of its intended purpose. It is utilitarian.

The scientific pursuit of artificial intelligence aims to change this. Will we see real advancements on this front? Are you ready?

Natural language processing problems in chatbot system development (3 vấn đề NLP cơ bản khi phát triển một hệ thống chatbot và một số phương pháp giải quyết điển hình)

In online systems with large numbers of users, the demand for automated chatbots to serve users is increasing. Chatbot systems can be used to support or replace customer care officers in several tasks that can be automated.

For example, question-answering chatbot can answer automatically questions about the services which a company provides; a hospital can use the chatbot on its website to obtain patients’ information or to assist patients with initial information about the symptoms, or to guide procedures for registration of medical examination and treatment.

Chatbot systems communicate with humans by voice (like Siri) or by text (like chatbots developed on Facebook Messenger platform). No matter what kind of communication means, chatbot needs to understand input texts so that it can provide the right answers forcustomers. The component responsible for this work in a chatbot system is called NLU (Natural Language Understanding), which incorporates a number of natural language processing (NLP) techniques.

In this article, we introduce three basic NLP problems when one develops a chatbot system and some typical approaches. We focus onchatbot systems used in the closed domain and applyretrieval-based model. The information retrieval-based model is a model in which the chatbot provides feedback that is prepared in advance or in accordance with certain patterns. This model is different from the generative model, in which the chatbot’s responses are automatically generated by learning from a dialogue data set (read more from reference [1]). Most of chatbot systems that are deployed in practice follow information retrieval-based models and are applied in certain application domains.

The three NLP problems covered in this article are: 1) Intent classification or intent detection; 2) Information extraction; and 3) Dialogue management. At last, we also point out the challenges of developing the chatbot system and the limitations of the current technology.

User intent detection

In common, users often visit the chatbot system with a desire that the system will take action to help themselves on a certain issue. For example, users of the chatbot system which supports booking air tickets may offer their booking requests at the beginning of the conversation. To provide accurate support, the chatbot needs to determine the intent of the user. User intent detection will determine how the next conversation between the user and the chatbot will take place. Therefore, if the user intent is misinterpreted, chatbot will give incorrect responses.. At that time, the user may feel disgusted and have no intention of using the system again. The problem of detecting user intent is therefore very important in the chatbot system.

For closed domains, we can limit the number of user intentions to a finite set of defined intents, which are related to the business operations that chatbot can support. With this limitation, the problem of detecting user intents can be formalized as the text categorization problem. With input being a saying of the user, the classification system determines the intent corresponding to that saying from the set of intents that have been defined.

To build an intent classification model, we need a training dataset that includes different expressions for each intent. For example, with the same question about the weather in Hanoi today, users can use the following expressions:

– What is the weather today in Hanoi?

– Does Hanoi rain today?

– What is the temperature in Hanoi today?

– Excused me, when going out today should we bring a raincoat?

It can be said that the training step for the intent classification problem is one of the most important tasks in developing the chatbot system, and it has a huge impact on the quality of the chatbot system. This work also requires considerable time and effort of chatbot developers.

Machine learning model for the problem of categorizing user intent

Once the training data for the intent categorization problem is available, we will model the problem into a text categorization problem. Text categorization is a classic problem in the NLP field and Text mining. The text categorization model for the intent classification problem is expressed in the following form:

We are given a training set consisting of pairs (message, intent), D = {(x⁽¹⁾, y⁽¹⁾),…, (x⁽ⁿ⁾, y⁽ⁿ⁾)}, where x⁽ⁱ⁾ is a message and y⁽ⁱ⁾ is the corresponding intent for x⁽ⁱ⁾ . The intent y⁽ⁱ⁾ is in a finite set Κ including intents that are defined already. We need to learn from this training data, a classification  model Θ, which is capable of classifying a new message into one of the intents in the set K. The architecture of the intent categorization system is illustrated in Figure 1.

Figure 1. Achitecture of the intent categorization system

The intent categorization system has some basic components:

• Data pre-processing
• Feature extraction
• Model training
• Categorizing

In the data pre-processing stage, we will perform the “cleaning” of data such as removing redundant information, standardizing data such as turning misspelled words into correct ones, standardizing Abbreviations, etc. Pre-processing data plays an important role in the chatbot system due to the specificity of the chatting and conversational language: abbreviation, misspelling, or “teencode”.

After pre-processing and obtaining the data that has been cleaned, we will extract the features from this data. In machine learning, this step is called feature extraction or feature engineering. In traditional machine learning model (before deep learning model is widely applied), the feature extraction step affects the accuracy of the classification model significantly. To extract good features, we need to carefully analyze dataand also to use expert knowledge in each specific application domain.

The training step uses extracted features as input and  applies machine learning algorithms to learn a classification model. Classification models may be classification rules (if using decision trees) or a weight vector corresponding to extracted features (as in logistic regression model, SVM, or Neural network).

After having an intent classification model, we can use it to classify a new message. The input message also goes through preprocessing and extraction steps, then the classification model determines the “score” for each intent in the set and gives out the intent which has the highest score.

Model based on content matching

The intent classification model based on statistical machine learning requires training data including different expressions for each intent. This training data is usually prepared manually. The data preparation step takes quite some time and effort, especially in applications where the  number of intents is relatively large.

An approach that can reduce the effort required to prepare training data is content matching approach. In this approach, we still need to prepare the data, each intent has at least one corresponding question. With a given message, we will apply a content matching algorithm to match the message with each question in the dataset. The answer to the question with the closest content to the input will be returned. In practical application, we can give list (e.g: top 3) most appropriate answers for the user to choose.

The method of matching information is quite suitable for chatbot systems used for answering frequently asked questions (FAQ). We can take advantage of existing FAQ data to create a FAQ Chatbot by content matching method without creating training data as in the statistical machine learning model.

One of the challenges of the content-matching model is thathandlingdifferent expressions for the same question requireshand-crafted rules. Since the number of samplesfor each intent is small, the matching model will have to use rules or semantic resources to handle different variations when expressing a word, phrase, or an sentence. Sentences 1) and 2) in the example below use different expressions for the same customer’s question of a telecom company about slow network condition.

1. Ad, why is my home network so slow recently?
2. My network lags many times, so frustrated.

In the example above, if we use the content-matching model, the system needs to recognize that the word “slow” and “lag” (the language used on the Internet) have the same meaning.

Currently, semantic resources for Vietnamese language processing are not sufficient, so the approach based on statistical machine learning model or hybrid model – combining both statistical machine learning andcontent matching may be more appropriate for Vietnamese chatbots.

Information Extraction

Besides detectingthe intent in a user’s message, we need to extract the information we need in it. The information to be extracted in a message is usually entities of certain types. For example, when a customer wants to book an airplane ticket, the system needs to know the departure and destination location, the date and time the customer wants to travel, etc. NLU components of chatbot systems usually support following entity types(read more in reference [2]):

• Location
• Datetime
• Number
• Contact
• Distance
• Duration

Could

you

please

book

me

a

flight

to

London

on

25th

this

month

?

O

O

O

O

O

O

O

O

B-LOCATION

O

B-TIME

I-TIME

I-TIME

I-TIME

Figure 2: Assign word labels according to B-I-O model in extracting information

The input of a information extraction module is a message. The information extraction module needs to locate the entities in the statement (from start and end of entity). The following example illustrates a messageand entities extracted from that.

• Input message: Could you please book me a flight to London on 25^th this month ?
• The message with identified entities: Could you please book me a flight to [London]_LOCATION on [25^th this month]_TIME ?

In the sentence above there are two entities (in the [ ] with the corresponding entity types written in subscript font).

The common approach to the problem of extracting information is to formalizethe problem into a sequence labeling problem. The input of a sequence labeling problem is a sequence of words, and the output is a sequence of labels corresponding to the words in the input. We will use machine learning models to learn a labeling model from a set of input data including pairs (x₁…x_n, y₁…y_n), where x₁…x_n is the sequence of words, y₁…y_n is the sequence of labels. The length of the sequences in the dataset may vary.

In the information extraction problem, the label set for the words in the input sentence usually uses the BIO model, in which B stands for “Beginning”, I for “Inside”, and O for “Outside”. When we know the position of the first word of an entity and words within that entity, we can determine position of that entity in the sentence. In the example above, the sequence of labels corresponding to the sequence of words in the input message is illustrated in Figure 2.

The popular sequence labelingalgorithm is the Hidden Markov Models (HMM) [3], Conditional Random Fields (CRF)[4]. With textual data, CRF model usually outperforms HMM model. There are several of open sources setting CRF tool for sequence labeling problem such as CRF ++ [5], CRF Suite [6], Mallet [7], and more.

Recently, Recurrent Neural Networks have been used widely for sequence labeling. The Recurrent Neural Networks model has been proved effective with textual data because it models the dependency relationship between words in the sentence. For example, the Recurrent Neural Network is applied to POS Tagging problem or problem of named entity recognition [8].

Dialogue Management

In long conversation between a person and a chatbot, the chatbot needs to remember the context or manage dialogue states. The problem of dialogue management is important to ensure that the communication between people and machines is smooth.

The function of the dialogue management component is to receive input from NLU component, to manage dialogue states, dialogue contexts, and to transmit output to Natural Language Generation (NLG). For example, the dialogue management module in an air ticket booking chatbot needs to know when the user has provided enough information for booking tickets to create a ticket to the system or when they need to reconfirm the information put by that user. Currently, chatbot products typically use Finite State Automata (FSA) model, Frame-based model (Slot Filling), or a combination of these two models.

  

Figure 3: Illustration of Dialogue Management using Finite State Automata (FSA) model

FSA is the simplest dialogue management model. For example, imagine a customer care system of a telecom company, serving customers who complain about slow network issues. The task of chatbot is to ask the customer’s name, phone number, Internet package name he/she is using, the actual Internet speed. Figure 3 illustrates a dialogue management model for chatbot customer care. FSA states correspond to questions that dialogue manager asks the user. The links between the states corresponding to actions that the chatbot would take. These actions depend on user’s response to the questions. In FSA model, chatbot is the user-oriented side of the conversation.

The advantages of FSA model are simple and the chatbot will pre-define the response that user wants. However, FSA model is not really suitable for complex chatbot systems or when users offer different information in the same message. In the example above, when a user simultaneously provides both name and phone number, if the chatbot continues asking for the phone number, the user may feel uncomfortable.

A Frame-based model (also called Form-based) can solve the problem that FSA model faces. Frame-based model is based on predefined frames to navigate the conversation. Each frame contains the required slots and corresponding questions that dialogue manager asks the user. This model allows user to fill in the various slots in the frame. Figure 4 is an example of a frame for the chatbot above.

Slot	Question
Full name	What is your name?
Phone number	What is your phone number?
Internet package name	What is the name of your Internet package?
Actual Internet speed	What is your current Internet speed?

Figure 4: Frame for chatbot to ask for information (in slow Internet connection example)

The dialogue manager using Framework-based model will ask questions to the customer, fill in the slots based on the information that customer provided until it collects enough necessary information. When the user answers multiple questions at the same time, the system will have to fill in the corresponding slots and remember to not ask questions that have already been answered.

In complex application domains, a dialogue can have many different frames. The problem for chatbot developers is how to know when to switch between frames. An approach commonly used to manage the change of control between frames is to define production rules. These rules are based on a number of elements, such as the last messages or questions an user has asked.

Challenges

Although NLP and Machine Learning fields have improved a lot, there are still many challenges in chatbot development that researchers need to overcome. We list two issues below.

The first problem is coreference. In speaking and writing, we often use short way to address the objects we mentioned earlier. For example, while writing or speaking English, people may use pronouns like “it”, “they”, “he”, … Without contextual information and a coreference analyzer, it is very difficult for chatbots to know what/who these words refer to. Failure to identify the correct object to which these alternative words refers may cause chatbot to misunderstand user’s dialogue. This challenge is quite apparent in long conversations.

The second problem is how to reduce the effort in annotating data while developing chatbot. According to the above approaches, when developing a chatbot application, the developer needs to label the training data for the intent classifier and the named entity recognizer . In complex application domains (such as mecial and health care), it is quite expensive to create such datasets. Therefore, the development of methods to utilize available data sources in the enterprise to reduce the amount of data required to label as well as ensuring the accuracy of the natural language processing models is necessary.

Conclusion

In this article, we have introduced three basic NLP problems in developing chatbot systems which are used in the closed domain and follow the retrieval-based model. Within the volume of an article, we can not provide more detailed information about the mentioned models and newer approaches in chatbot development (eg, Generative Hierarchical Neural Network approach – sequence to sequence [9]). Interested readers can read more in the references.

References

1. Stefan Kojouharov. “Ultimate Guide to Leveraging NLP & Machine Learning for your Chatbot”. On Chatbotlife. https://chatbotslife.com/ultimate-guide-to-leveraging-nlp-machine-learning-for-you-chatbot-531ff2dd870c#.rabx346bq
2. Pavlo Bashmakov. Advanced Natural Language Processing Tools for Bot Makers – LUIS, Wit.ai, Api.ai and others (UPDATED). https://stanfy.com/blog/advanced-natural-language-processing-tools-for-bot-makers/
3. Michael Collins. Hidden Markov models and tagging (sequence labeling) problems. http://www.cs.columbia.edu/~mcollins/hmms-spring2013.pdf
4. Michael Collins. Log-Linear Models, MEMMs, and CRFs. http://www.cs.columbia.edu/~mcollins/crf.pdf
5. Taku Kudo. CRF++: Yet Another CRF toolkit. https://taku910.github.io/crfpp/
6. Naoaki Okazaki. CRFsuite: A fast implementation of Conditional Random Fields (CRFs). http://www.chokkan.org/software/crfsuite/
7. Mallet toolkit: http://mallet.cs.umass.edu/
8. Zhiheng Huang, Wei Xu, Kai Yu. 2015. Bidirectional LSTM-CRF Models for Sequence Tagging. On arxiv, https://arxiv.org/abs/1508.01991
9. Iulian V. Serban, Alessandro Sordoni, Yoshua Bengio, Aaron Courville, Joelle Pineau. Building End-To-End Dialogue Systems Using Generative Hierarchical Neural Network Models. On arxiv, https://arxiv.org/abs/1507.04808
10. Jurafsky, D., & Martin, J. H. Speech and Language Processing: An Introduction to Natural Language Processing, Computational Linguistics, and Speech Recognition. Chapter 24. “Dialogue and Conversational Agents”.

Pham Quang Nhat Minh – FPT Technology Research Institute (FTRI)

Facebook Built-in NLP

Natural Language Processing (NLP) allows you to understand and extract meaningful information (called entities) out of the messages people send. You can then use these entities to identify intent, automate some of your replies, route the conversation to a human via livechat, and collect audience data.
If you are currently leveraging an NLP API, you have to make an extra call when you receive the user message, which adds latency and complexity (example: async, troubleshooting, etc.). With built-in NLP, entities are automatically detected in every text message that someone sends.

Contents

1. How It Works
2. Enabling Built-in NLP
3. Handling a Message With Entities
4. Customizing NLP via Wit.ai

How It works

Once Messenger's built-in NLP is enabled for your Facebook Page, it automatically detects meaning and intent in every text message before it is sent to your bot. The message will be relayed to your bot as usual, along with any entities detected in the body. See Handling a Message With Entities.

Default NLP

By default, Messenger's built-in NLP detects the following entities in English only:

• Greetings
• Thanks
• Bye

It also detects information like date, time, location, amount of money, phone number and email. For example, if someone sends the message, “tomorrow at 2pm” or “2 days before Xmas,” you will get the actual timestamp with the message.
For other languages, check Customizing NLP via Wit.ai.

Enabling Built-in NLP

To enable built-in NLP, do the following:

1. Go to your app's 'Messenger Settings' page.
2. Toggle the "on off" switch to enable/disable built-in NLP for your app.

Enabling Built-in NLP with the Graph API

You can also use the graph API to enable built-in NLP programmatically:

curl -i -X POST \
  -d "access_token=$PAGE_APP_ACCESS_TOKEN" \
  "https://graph.facebook.com/v2.8/me/nlp_configs?nlp_enabled=$NLP_ENABLED"

You must append the nlp_enabled parameter which will either enable or disable NLP for that Page.

Handling a Message With Entities

Once built-in NLP is enabled, you will see an nlp key in the request sent to your message webhook.
For example, the message, "bye, see you tomorrow at 4pm" would include the following entities:

{...,
  entities: {
    "datetime": [
      {
        "confidence": 0.97249440664957,
        "values": ["..."],
        "value": "2017-05-10T14:00:00.000-07:00",
        "grain": "hour","type": "value"
        }
      ],
    "greetings": [
      {
        "confidence": 1,
        "value": "true"
      }
    ]
  }
}

For each message, the Messenger Platform will return a mapping of the entities that were captured alongside their structured data. The key pieces of information here are the confidence and the value for each entity.
confidence is a value between 0 and 1 that indicates the probability the parser thinks its recognition is correct.
value is the parser output. For example, 2pm can be converted to an ISO string you can use in your app, like "2017-05-10T14:00:00.000-07:00".
You can learn more about the JSON structure of all the entities in the Wit.ai docs

Example Usage

In your message webhook, you can update the logic used to respond to messages by taking advantage of DefaultNLP. For example, if you have a handleMessage() function in your webhook that responds to each message received, you can use the greeting entity to send an appropriate response:

function firstEntity(nlp, name) {
  return nlp && nlp.entities && nlp.entities && nlp.entities[name] && nlp.entities[name][0];
}

function handleMessage(message) {
  // check greeting is here and is confident
  const greeting = firstEntity(message.nlp, 'greeting');
  if (greeting && greeting.confidence > 0.8) {
    sendResponse('Hi there!');
  } else { 
    // default logic
  }
}

Replicate this logic for other entities, and you will be on your way to using built-in NLP!

Customizing NLP via Wit.ai

You can customize Messenger's built-in NLP to detect additional entities in English, as well as entities in the 57 languages supported by Wit.ai.
To customize NLP with Wit.ai, do the following:

1. Go to your app's 'Messenger Settings' page.
2. In the 'Built-in NLP' section, select one of your subscribed Pages.
3. Add your Wit Server access token. You can find your access token in the Wit App settings.
4. Save your settings.

Updating NLP Settings with the Graph API

You can also update your NLP settings programmatically with a POST request to the Graph API:

curl -i -X POST \
  -d "access_token=$PAGE_APP_ACCESS_TOKEN" \
  "https://graph.facebook.com/v2.8/me/nlp_configs?nlp_enabled=$NLP_ENABLED&&custom_token=$CUSTOM_TOKEN"

You must provide an nlp_enabled option which will either enable NLP or disable NLP for that Page. You can optionally provide a custom_token option, which lets you set a server access token from Wit.

3 vấn đề NLP cơ bản khi phát triển một hệ thống chatbot và một số phương pháp giải quyết điển hình

13/04/2017

Các hệ thống chatbot giao tiếp với con người bằng giọng nói (như Siri) hoặc bằng văn bản (như các chatbot phát triển trên nền Facebook Messenger). Dù giao tiếp bằng hình thức nào, chatbot cũng cần phải hiểu văn bản để có thể đưa ra những câu trả lời phù hợp cho khách hàng. Thành phần đảm nhiệm công việc này trong hệ thống chatbot được gọi là NLU (Natural Language Understanding), trong đó có rất nhiều các kĩ thuật xử lý ngôn ngữ tự nhiên (Natural Language Processing, viết tắt là NLP) được áp dụng.

Trong bài viết này, người viết giới thiệu 3 vấn đề NLP cơ bản khi phát triển một hệ thống chatbot và một số phương pháp giải quyết điển hình. Người viết tập trung vào các chatbot được sử dụng trong miền ứng dụng đóng (closed domain) và trả lời theo mô hình truy xuất thông tin (retrieval-based model). Mô hình truy xuất thông tin là mô hình trong đó, chatbot đưa ra những phản hồi được chuẩn bị trước hoặc tuân theo những mô thức nhất định. Mô hình này khác với mô hình tự động sinh câu trả lời (generative), trong đó câu trả lời của chatbot được tự động sinh ra bằng việc học từ một tập dữ liệu các đoạn hội thoại (tham khảo tài liệu [1]). Các hệ thống chatbot được triển khai trong thực tế phần lớn tuân theo mô hình truy xuất thông tin và được áp dụng trong những miền ứng dụng nhất định.

Ba vấn đề NLP được giới thiệu trong bài bao gồm: 1) Xác định/Phân loại ý định người dùng (intent classification hay intent detection); 2) Trích xuất thông tin (information extraction); và 3) Quản lý hội thoại (Dialog management). Cuối cùng, chúng tôi cũng nêu ra những thách thức khi phát triển hệ thống chatbot và những giới hạn của công nghệ hiện tại.

1. Xác định ý định người dùng

Thông thường, người dùng thường truy cập hệ thống chatbot với mong muốn hệ thống sẽ đưa ra những hành động trợ giúp mình về một vấn đề nào đó. Ví dụ, người dùng của hệ thống chatbot hỗ trợ đặt vé máy bay có thể đưa ra yêu cầu đặt vé của mình khi bắt đầu cuộc hội thoại. Để đưa ra hỗ trợ được chính xác, chatbot cần xác định được ý định (intent) đó của người dùng. Việc xác định ý định của người dùng sẽ quyết định hội thoại tiếp theo giữa người và chatbot sẽ diễn ra như thế nào. Vì thế, nếu xác định sai ý định người dùng, chatbot sẽ đưa ra những phản hồi không đúng, không hợp ngữ cảnh. Khi đó, người dùng có thể thấy chán ghét và không quay lại sử dụng hệ thống. Bài toán xác định ý định người dùng vì thế đóng vai trò rất quan trọng trong hệ thống chatbot.

Đối với miền ứng dụng đóng, chúng ta có thể giới hạn rằng số lượng ý định của người dùng nằm trong một tập hữu hạn những intent đã được định nghĩa sẵn, có liên quan đến những nghiệp vụ doanh nghiệp mà chatbot có thể hỗ trợ. Với giới hạn này, bài toán xác định ý định người dùng có thể quy về bài toán phân lớp văn bản. Với đầu vào là một câu giao tiếp của người dùng, hệ thống phân lớp sẽ xác định intent tương ứng với câu đó trong tập các intent đã được định nghĩa.

Để xây dựng một mô hình phân lớp intent, chúng ta cần một tập dữ liệu huấn luyện bao gồm các cách diễn đạt khác nhau cho mỗi intent. Ví dụ, cùng một mục đích hỏi về thời tiết ở Hà Nội trong ngày hôm nay, người dùng có thể dùng những cách diễn đạt sau:

• Thời tiết hôm nay ở Hà Nội thế nào ad?
• Hà Nội hôm nay có mưa không vậy?
• Hà Nội hôm nay bao nhiêu độ vậy?
• Cho mình hỏi, ra ngoài đường hôm nay có phải mang áo mưa không?

Có thể nói, bước tạo dữ liệu huấn luyện cho bài toán phân lớp intent là một trong những công việc quan trọng nhất khi phát triển hệ thống chatbot và ảnh hưởng lớn tới chất lượng sản phẩm của hệ thống chatbot về sau. Công việc này cũng đòi hỏi thời gian, công sức khá lớn của nhà phát triển chatbot.

Mô hình học máy cho bài toán phân lớp ý định người dùng

Khi đã có dữ liệu huấn luyện cho bài toán phân lớp intent, chúng ta sẽ mô hình bài toán thành bài toán phân lớp văn bản. Bài toán phân lớp văn bản (text categorization) là một bài toán kinh điển trong ngành NLP và khai phá văn bản (Text Mining). Mô hình phân lớp văn bản cho bài toán phân lớp intent được phát biểu một cách hình thức như sau:

Chúng ta được cho trước một tập huấn luyện bao gồm các cặp (câu hội thoại, intent), D = {(x⁽¹⁾, y⁽¹⁾),…, (x⁽ⁿ⁾, y⁽ⁿ⁾)}, trong đó x⁽ⁱ⁾ là các câu hội thoại và y⁽ⁱ⁾ là intent tương ứng cho x⁽ⁱ⁾. Các intent y⁽ⁱ⁾ nằm trong một tập hữu hạn Κ các intent được định nghĩa trước. Chúng ta cần học từ tập huấn luyện này một mô hình phân lớp Θ có chức năng phân lớp một câu hội thoại mới vào một trong các intent thuộc tập K. Kiến trúc của hệ thống phân lớp intent được minh hoạ trong hình 1.

Hình 1. Kiến trúc của hệ thống phân lớp intent

Hệ thống phân lớp intent có một số thành phần cơ bản:

• Tiền xử lý dữ liệu
• Trích xuất đặc trưng
• Huấn luyện mô hình
• Phân lớp

Trong bước tiền xử lý dữ liệu, chúng ta sẽ thực hiện các thao tác “làm sạch” dữ liệu như: loại bỏ các thông tin dư thừa, chuẩn hoá dữ liệu như chuyển các từ viết sai chính tả thành đúng chính tả, chuẩn hoá các từ viết tắt,… Việc tiền xử lý dữ liệu có vai trò quan trọng trong hệ thống chatbot do đặc thù của ngôn ngữ chat, nói: viết tắt, sai chính tả, hay dùng “teencode”.

Sau khi tiền xử lý dữ liệu và thu được dữ liệu đã được làm sạch, chúng ta sẽ trích xuất những đặc trưng từ dữ liệu này. Trong học máy, bước này được gọi là trích xuất đặc trưng (feature extraction hay feature engineering). Trong mô hình học máy truyền thống (trước khi mô hình học sâu được áp dụng rộng rãi), bước trích xuất đặc trưng ảnh hưởng lớn đến độ chính xác của mô hình phân lớp. Để trích xuất được những đặc trưng tốt, chúng ta cần phân tích dữ liệu khá tỉ mỉ và cần cả những tri thức chuyên gia trong từng miền ứng dụng cụ thể.

Bước huấn luyện mô hình nhận đầu vào là các đặc trưng đã được trích xuất và áp dụng các thuật toán học máy để học ra một mô hình phân lớp. Các mô hình phân lớp có thể là các luật phân lớp (nếu sử dụng decision tree) hoặc là các vector trọng số tương ứng với các đặc trưng được trích xuất (như trong các mô hình logistic regression, SVM, hay mạng Neural).

Sau khi có một mô hình phân lớp intent, chúng ta có thể sử dụng nó để phân lớp một câu hội thoại mới. Câu hội thoại này cũng đi qua các bước tiền xử lý và trích xuất đặc trưng, sau đó mô hình phân lớp sẽ xác định “điểm số” cho từng intent trong tập các intent và đưa ra intent có điểm cao nhất.

Mô hình dựa trên đối sánh nội dung

Mô hình phân lớp intent dựa trên học máy thống kê yêu cầu dữ liệu huấn luyện bao gồm các cách diễn đạt khác nhau cho mỗi intent. Dữ liệu huấn luyện này thông thường được chuẩn bị một cách thủ công. Bước chuẩn bị dữ liệu này tốn khá nhiều thời gian và công sức, đặc biệt là trong các ứng dụng mà số lượng intent tương đối lớn.

Một cách tiếp cận có thể giảm công sức chuẩn bị dữ liệu huấn luyện là sử dụng mô hình đối sánh thông tin (content matching). Trong cách tiếp cận này, chúng ta vẫn cần chuẩn bị dữ liệu, trong đó mỗi intent có ít nhất một câu hỏi tương ứng. Với một câu hội thoại cho trước, chúng ta sẽ áp dụng thuật toán đối sánh thông tin để đối sánh với từng câu hỏi trong tập dữ liệu. Câu trả lời cho câu hỏi có nội dung gần nhất với câu đầu vào sẽ được đưa ra. Trong ứng dụng thực tế, chúng ta có thể đưa ra danh sách (ví dụ top 3) các câu gần nhất để người dùng lựa chọn.

Phương pháp đối sánh thông tin khá thích hợp cho các hệ thống chatbot phục vụ cho công việc trả lời các câu hỏi thường gặp (FAQ).  Chúng ta có thể tận dụng dữ liệu FAQ sẵn có để tạo ngay một FAQ chatbot bằng phương pháp đối sánh nội dung mà không cần tạo dữ liệu huấn luyện như trong mô hình học máy thống kê.

Một trong những thách thức của mô hình đối sánh nội dung là việc xử lý những cách diễn đạt khác nhau cho cùng một câu hỏi yêu cầu những luật phải chuẩn bị bằng tay. Vì số lượng mẫu cho mỗi intent không nhiều, mô hình đối sánh sẽ phải sử dụng các luật hoặc tài nguyên ngữ nghĩa để xử lý những biến thể khác nhau khi diễn đạt một từ, một cụm từ, hay một ý trong câu. Các câu 1) và 2) trong ví dụ dưới đây sử dụng các cách diễn đạt khác nhau cho cùng một câu hỏi của khách hàng của một công ty viễn thông về tình trạng mạng chậm.

1. Ad ơi, sao mạng nhà em dạo này chậm thế?
2. Mạng lag lắm, dùng rất ức chế.

Trong ví dụ ở trên, nếu dùng mô hình đối sánh thông tin, hệ thống cần nhận ra từ “chậm” và “lag” (ngôn ngữ được dùng trên mạng) mang cùng ý nghĩa.

Hiện nay các tài nguyên ngữ nghĩa cho xử lý ngôn ngữ tiếng Việt còn chưa đầy đủ, nên cách tiếp cận dựa trên mô hình học máy thống kê hoặc mô hình lai (hybrid model) – kết hợp cả học máy thống kê và đối sánh thông tin có thể thích hợp hơn cho các chatbot tiếng Việt.

2. Trích xuất thông tin

Bên cạnh việc xác định intent trong câu hội thoại của người dùng, chúng ta cần trích xuất các thông tin cần thiết trong đó. Các thông tin cần trích xuất trong một câu hội thoại thường là các thực thể thuộc về một loại nào đó. Ví dụ, khi một khách hàng muốn đặt vé máy bay, hệ thống cần biết địa điểm xuất phát và địa điểm khách muốn đến, ngày giờ khách hàng muốn bay,…Thành phần NLU của các hệ thống chatbot thường hỗ trợ các loại thực thể sau (tham khảo tài liệu [2]):

• Vị trí (Location)
• Thời gian (Datetime)
• Số (Number)
• Địa chỉ liên lạc (Contact)
• Khoảng cách (Distance)
• Khoảng thời gian (Duration)

Hình 2: Gán nhãn từ theo mô hình B-I-O trong trích xuất thông tin

Đầu vào của một module trích xuất thông tin là một câu hội thoại. Module trích xuất thông tin cần xác định vị trí của các thực thể trong câu (vị trí bắt đầu vàvị trí kết thúc của thực thể). Ví dụ sau minh hoạ một câu hội thoại và các thực thể được trích xuất từ đó.

• Câu hội thoại: Tôi muốn đặt vé máy bay đi Phú Quốc từ sân bay Nội Bài lúc 8 giờ tối ngày mai.
• Câu có các thực thể được xác định: Tôi muốn đặt vé máy bay đi [Phú Quốc]_LOCATION từ sân bay [Nội Bài]_LOCATION lúc [8 giờ tối ngày mai]_TIME.

Trong câu trên có 3 thực thể (nằm trong các dấu [ ]) với các loại thực thể tương ứng (được viết với font chữ nhỏ hơn ở dưới).

Cách tiếp cận phổ biến cho bài toán trích xuất thông tin là mô hình hoá bài toán thành bài toán gán nhãn chuỗi (sequence labeling). Đầu vào của bài toán gán nhãn chuỗi là một dãy các từ, và đầu ra là một dãy các nhãn tương ứng các các từ trong đầu vào. Chúng ta sẽ sử dụng các mô hình học máy để học một mô hình gán nhãn từ một tập dữ liệu đầu vào bao gồm các cặp (x₁…x_n, y₁…y_n), trong đó x₁…x_n là dãy các từ, y₁…y_n là dãy các nhãn. Độ dài của các dãy từ trong tập dữ liệu có thể khác nhau.

Trong bài toán trích xuất thông tin, tập nhãn cho các từ trong câu đầu vào thường được tạo ra theo  mô hình BIO, với B là viết tắt của “Beginning”, I là viết tắt của “Inside”, và O là viết tắt của “Outside”. Khi biết vị trí từ bắt đầu của một thực thể và các từ nằm trong thực thể đó, chúng ta có thể xác định vị trí của thực thể trong câu. Trong ví dụ ở trên, dãy các nhãn tương ứng với dãy của các từ trong câu hội thoại đầu vào được minh hoạ ở hình 2.

Thuật toán huấn luyện mô hình gán nhãn chuỗi phổ biến là mô hình Markov ẩn (HMM – Hidden Markov Models) [3], mô hình CRF (Conditional Random Fields) [4]. Với dữ liệu văn bản, mô hình CRF thường cho kết quả tốt hơn mô hình HMM. Có khá nhiều các công cụ mã nguồn mở cài đặt mô hình CRF cho bài toán gán nhãn chuỗi như CRF++ [5], CRF Suite [6], Mallet [7],…

Gần đây, các mô hình mạng neural hồi quy (Recurrent Neural Networks) được áp dụng khá nhiều cho bài toán gán nhãn chuỗi. Mô hình mạng neural hồi quy tỏ ra hiệu quả với dữ liệu dạng chuỗi vì nó mô hình mối quan hệ phụ thuộc giữa các từ trong câu. Ví dụ, mạng neural hồi quy được áp dụng cho bài toán gán nhán từ loại (POS Tagging), bài toán xác định thực thể tên gọi [8].

3. Quản lý hội thoại

Trong các phiên trao đổi dài (long conversation) giữa người và chatbot, chatbot sẽ cần ghi nhớ những thông tin về ngữ cảnh (context) hay quản lý các trạng thái hội thoại (dialog state). Vấn đề quản lý hội thoại (dialoge management) khi đó là quan trọng để đảm bảo việc trao đổi giữa người và máy là thông suốt.

Chức năng của thành phần quản lý hội thoại là nhận đầu vào từ thành phần NLU, quản lý các trạng thái hội thoại (dialogue state), ngữ cảnh hội thoại (dialogue context), và truyền đầu ra cho thành phần sinh ngôn ngữ (Natural Language Generation, viết tắt là NLG). Ví dụ module quản lý dialogue trong một chatbot phục vụ đặt vé máy bay cần biết khi nào người dùng đã cung cấp đủ thông tin cho việc đặt vé để tạo một ticket tới hệ thống hoặc khi nào cần phải xác nhận lại thông tin do người dùng đưa vào. Hiện nay, các sản phẩm chatbot thường dùng mô hình máy trạng thái hữu hạn (Finite State Automata – FSA), mô hình Frame-based (Slot Filling), hoặc kết hợp hai mô hình này.

Hình 3: Minh hoạ quản lý hội thoại theo mô hình máy trạng thái hữu hạn FSA

FSA là mô hình quản lý hội thoại đơn giản nhất. Ví dụ, hãy tưởng tượng một hệ thống chăm sóc khách hàng của một công ty viễn thông, phục vụ cho những khách hàng than phiền về vấn đề mạng chậm. Nhiệm vụ của chatbot là hỏi tên khách hàng, số điện thoại, tên gói Internet khách hàng đang dùng, tốc độ Internet thực tế của khách hàng.  Hình vẽ 3 minh hoạ một mô hình quản lý hội thoại cho chatbot chăm sóc khách hàng. Các trạng thái của FSA tương ứng với các câu hỏi mà dialogue manager hỏi người dùng. Các cung nối giữa các trạng thái tương ứng với các hành động của chatbot sẽ thực hiện. Các hành động này phụ thuộc phản hồi của người dùng cho các câu hỏi. Trong mô hình FSA, chatbot là phía định hướng người sử dụng trong cuộc hội thoại.

Ưu điểm của mô hình FSA là đơn giản và chatbot sẽ định trước dạng câu trả lời mong muốn từ phía người dùng. Tuy nhiên, mô hình FSA không thực sự phù hợp cho các hệ thống chatbot phức tạp hoặc khi người dùng đưa ra nhiều thông tin khác nhau trong cùng một câu hội thoại. Trong ví dụ chatbot ở trên, khi người dùng đồng thời cung cấp cả tên và số điện thoại, nếu chatbot tiếp tục hỏi số điện thoại, người dùng có thể cảm thấy khó chịu.

Mô hình Frame-based (hoặc tên khác là Form-based) có thể giải quyết vấn đề mà mô hình FSA gặp phải. Mô hình Frame-based dựa trên các frame định sẵn để định hướng cuộc hội thoại. Mỗi frame sẽ bao gồm các thông tin (slot) cần điền và các câu hỏi tương ứng mà dialogue manager hỏi người dùng. Mô hình này cho phép người dùng điền thông tin vào nhiều slot khác nhau trong frame. Hình vẽ 4 là một ví dụ về một frame cho chatbot ở trên.

Hình 4: Frame cho chatbot hỏi thông tin khách hàng cho tình huống mạng chậm

Thành phần quản lý dialogue theo mô hình Frame-based sẽ đưa ra câu hỏi cho khách hàng, điền thông tin vào các slot dựa trên thông tin khách hàng cung cấp cho đến khi có đủ thông tin cần thiết. Khi người dùng trả lời nhiều câu hỏi cùng lúc, hệ thống sẽ phải điền vào các slot tương ứng và ghi nhớ để không hỏi lại những câu hỏi đã có câu trả lời.

Trong các miền ứng dụng phức tạp, một cuộc hội thoại có thể có nhiều frame khác nhau. Vấn đề đặt ra cho người phát triển chatbot khi đó là làm sao để biết khi nào cần chuyển đổi giữa các frame. Cách tiếp cận thường dùng để quản lý việc chuyển điều khiển giữa các frame là định nghĩa các luật (production rule). Các luật này dựa trên một số các thành tố như câu hội thoại hoặc câu hỏi gần nhất mà người dùng đưa ra.

Những thách thức

Mặc dù lĩnh vực NLP và Machine Learning đã và đang có rất nhiều bước tiến mạnh mẽ, trong phát triển chatbot, vẫn còn tồn tại nhiều thách thức mà các nhà nghiên cứu xử lý ngôn ngữ tự nhiên và học máy cần vượt qua. Chúng tôi liệt kê hai vấn đề ở dưới đây.

Vấn đề thứ nhất là vấn đề đồng tham chiếu (coreference). Trong nói và viết, thông thường chúng ta thường dùng những cách gọi rút gọn cho những đối tượng mà chúng ta đã đề cập trước đó. Ví dụ trong tiếng Anh, người nói và viết có thể dùng các đại từ như “it”, “they”, “he”,… Nếu không có thông tin ngữ cảnh và bộ phân tích đồng tham chiếu, sẽ là rất khó để chatbot biết các từ này tham chiếu đến đối tượng nào. Việc không xác định được đúng đối tượng mà từ thay thế tham chiếu đến có thể khiến chatbot hiểu không chính xác câu hội thoại của người dùng. Thách thức này là khá rõ ràng trong các đoạn hội thoại dài.

Vấn đề thứ hai là làm sao để giảm bớt công sức làm dữ liệu khi phát triển chatbot. Theo những cách tiếp cận ở trên, khi phát triển một ứng dụng chatbot, nhà phát triển cần gán nhãn dữ liệu huấn luyện cho bộ phân lớp intent và nhận dạng thực thể tên gọi. Trong những miền ứng dụng phức tạp (chẳng hạn như y tế), công sức để tạo ra những bộ dữ liệu đó là khá đắt đỏ. Vì thế, việc phát triển các phương pháp để tận dụng những nguồn dữ liệu sẵn có trong doanh nghiệp để giảm lượng dữ liệu cần gán nhãn, trong khi vẫn đảm bảo được độ chính xác của các mô hình xử lý ngôn ngữ tự nhiên là cần thiết.

Lời kết

Trong bài viết này, chúng tôi đã giới thiệu ba vấn đề NLP cơ bản trong phát triển hệ thống chatbot trong miền ứng dụng đóng và theo mô hình truy xuất thông tin. Trong khuôn khổ của một bài viết, chúng tôi không thể cung cấp thông tin chi tiết hơn về các mô hình được đề cập và các cách tiếp cận mới hơn trong phát triển chatbot (chẳng hạn cách tiếp cận sinh hội thoại theo mô hình mạng neural – sequence to sequence [9]). Bạn đọc quan tâm có thể đọc thêm các tài liệu trong mục tài liệu tham khảo.

Tài liệu tham khảo

1. Stefan Kojouharov. “Ultimate Guide to Leveraging NLP & Machine Learning for your Chatbot”. On Chatbotlife. https://chatbotslife.com/ultimate-guide-to-leveraging-nlp-machine-learning-for-you-chatbot-531ff2dd870c#.rabx346bq
2. Pavlo Bashmakov. Advanced Natural Language Processing Tools for Bot Makers – LUIS, Wit.ai, Api.ai and others (UPDATED). https://stanfy.com/blog/advanced-natural-language-processing-tools-for-bot-makers/
3. Michael Collins. Hidden Markov models and tagging (sequence labeling) problems. http://www.cs.columbia.edu/~mcollins/hmms-spring2013.pdf
4. Michael Collins. Log-Linear Models, MEMMs, and CRFs. http://www.cs.columbia.edu/~mcollins/crf.pdf
5. Taku Kudo. CRF++: Yet Another CRF toolkit. https://taku910.github.io/crfpp/
6. Naoaki Okazaki. CRFsuite: A fast implementation of Conditional Random Fields (CRFs). http://www.chokkan.org/software/crfsuite/
7. Mallet toolkit: http://mallet.cs.umass.edu/
8. Zhiheng Huang, Wei Xu, Kai Yu. 2015. Bidirectional LSTM-CRF Models for Sequence Tagging. On arxiv, https://arxiv.org/abs/1508.01991
9. Iulian V. Serban, Alessandro Sordoni, Yoshua Bengio, Aaron Courville, Joelle Pineau. Building End-To-End Dialogue Systems Using Generative Hierarchical Neural Network Models. On arxiv, https://arxiv.org/abs/1507.04808
10. Jurafsky, D., & Martin, J. H. Speech and Language Processing: An Introduction to Natural Language Processing, Computational Linguistics, and Speech Recognition. Chapter 24. “Dialogue and Conversational Agents”.

Phạm Quang Nhật Minh – FTRI