Discourse-Driven Integrated Dialogue Development Environment for Open-Domain Dialogue Systems (2021)

Abstract: Development environments for spoken dialogue systems are popular today because they enable rapid creation of the dialogue systems in times when usage of the voice AI Assistants is constantly growing. We describe a graphical Discourse-Driven Integrated Dialogue Development Environment (DD-IDDE) for spoken open-domain dialogue systems. The DD-IDDE allows dialogue architects to interactively define dialogue flows of their skills/chatbots with the aid of the discourse-driven recommendation system, enhance these flows in the Python-based DSL, deploy, and then further improve based on the skills/chatbots usage statistics. We show how these skills/chatbots can be specified through a graphical user interface within the VS Code Extension, and then run on top of the Dialog Flow Framework (DFF). An earlier version of this framework has been adopted in one of the Alexa Prize 4 socialbots while the updated version was specifically designed to power the described DD-IDDE solution.

## introduction conversational ai focused on the development of the dialogue systems is one of the most challenging areas in the artificial intelligence given the subjectivity of the human language interpretation, and is gaining more and more popularity across both academia @xcite and consumer & enterprise markets @xcite . dialogue systems are classified into taskoriented dialogue systems and chat (or non-taskoriented) dialogue systems. usually they are studied differently, but combining them has been proposed @xcite , and has been found effective in improving user impressions and the relationships with users @xcite . while taskoriented systems are more widespread and used in different business scenarios @xcite , building systems that can carry multi-turn open-domain conversations is still far from a solved problem @xcite . while there is a significant effort in using large generative models @xcite , @xcite in the open-domain dialogue systems, recent tests of gpt-3 @xcite , and conversational ai challenges like alexa prize socialbot grand challenge @xcite highlight the inherent weaknesses of these models, namely inability to maintain context, avoid contradictions, and control the dialogue strategically in the long dialogues. these fallacies experienced by us and other teams during the amazon alexa prize 3 @xcite led us to the importance of continuing research towards the tightly-controlled open-domain dialogue management frameworks like e-stdm @xcite . during the amazon alexa prize 4 @xcite competition we developed @xcite a first iteration of such framework called dialog flow framework (dff) @xcite to aid in rapid development of open-domain "skills" covering various societal topics in our dream socialbot. usage showed that while users enjoy controlled conversation in their favorite domains, they often interrupt the conversation with the out-of-domain @xcite responses leading it into the non-anticipated directions. feedback of our alexa prize 4 team members who wrote dff-based open-domain "skills" shows that predictions of the possible user response could significantly cut the time needed by the developer to design and develop these skills. the key insight into the conversation is that each utterance in the dialogue is also a kind of action being performed by the speaker @xcite . these actions are called speech or dialog acts @xcite . yet while dialog acts used by some of the alexa prize teams e.g., midas @xcite , are quite sophisticated in understand-ing higher level user intents conceptually similar to those used in task-oriented systems @xcite , they are single turn-based and don't support the development of the open-domain conversations that are interactional and sequential @xcite . indeed, these dialog act taxonomies lack connection to the discourse level of the casual conversation analysis as shown by @xcite . in the effort of making it easier for developers to design and develop sequential and interactional multi-turn open-domain dialogue "skills" we propose a new graphical discourse-driven integrated dialogue development environment (dd-idde) that combines a novel discourse-driven recommendation system and a dsl for the dialog flow framework, encapsulated together into an extension to the popular ide visual studio code. ## related work one of the first development environments designed for spoken language systems, @xcite , was created in 2000. while it supported an entire dialogue system development lifecycle, it lacked the power of the modern nlp components such as ner, entity linking, etc. as well as the means for the development of the open-dialogue skills/chatbots. today, there is a variety of dialogue development frameworks that have emerged to aid in rapid dialogue system creation. rule-based approaches used e.g. in @xcite are common in the task-oriented systems broadly used in businesses. other systems incorporate support for full development lifecycle of the dialogue systems starting with individual nlp ml models and ending with the complete chatbots @xcite . some of these systems are also encapsulated in the form of web-based ides e.g. @xcite . domain-specific languages (dsls) are typically used in dialogue systems to aid in rapid layout of the dialogue logic. one of the oldest dsls in this space, aiml @xcite was created as an xml dialect that supports pattern matching of the user utterance and template-based entity extraction and was used in development of the famous opendomain dialogue system "a.l.i.c.e." @xcite . rasa dsl @xcite was designed for the development of the task-oriented systems and includes nlu (intent detection and entity extraction) and stories (actions for intents) components. jaicf (ai, 2021), a javascript-based state machine-based dsl, was designed to support both task-oriented systems and chatbots. a winner of alexa prize 2, gunrock team enhanced their socialbot's @xcite internal dialog flow framework with the midas dialog act scheme to create an adaptive and unique conversation experience with the user. however it does not enable bot developers with the mechanisms to manage dialogue strategically across multiple conversation turns. slugbot @xcite , another alexa prize team, proposed a drdm dialogue model to control the coherence of the open-domain dialogue using discourse relations. their approach introduced a combination of dialog acts and four discourse relations from the pdtb 2.0 @xcite as means to model interaction within individual turns and at a higher level. nonetheless, pdtb 2.0 is based on the 1-million-word wall street journal corpus which is a written language and is not best suited for the spoken casual conversation analysis. dd-idde is powered by the dialog flow framework (dff) derived from the e-stdm framework which is conceptually similar to both dialog flow framework described in @xcite and the drdm-dialogue model. it's newly developed dsl was specifically created so that: (1) all conditions, responses and even dialogue flows could be implemented as python functions, and (2) conditions for state transition could use any of the available annotators like speech function classifier and predictor and others within the larger dream socialbot or derived chatbots and assistants. however, while it is relatively common for dialogue flow frameworks to have a built-in dsl and support pluggable nlu components, dd-idde specifically incorporates the support for the novel discourse-driven recommendation system as well as the visual tools aiding in designing open-domain dialogues across multiple conversation steps. ## concepts development of the discourse-driven open-domain dialogue "skills" and chatbots is an ongoing iterative cycle that includes: (1) design of the "skill"/chatbot as the sequence of conditional transitions between states, aided by the discourse moves recommendations, (2) development of the "skill"/chatbot, (3) deployment, ending with the (4) analysis of the running solution, followed by the restart of the cycle. flows, nodes, transitions, conditions and responses: we split the dialogue graph into the logically related parts called flows to make it more convenient to work with. each flow represents a dialogue subgraph. typically, flows can be organized to cover different topics in the dialogue graph. like in @xcite , we identify the states of the dialogue at a certain moment, such states correspond to the nodes of the dialogue graph. being in a certain node of the graph, we can go to an another node if the condition that corresponds to this transition is true. after each transition, the responses corresponding to the node are returned.