# A Modular Framework for Domain-Specific Conversational Systems Powered by Never-Ending Learning
## 3 Architecture
### Architecture Overview  
The overall architecture of the framework follows the design of previous dialog systems, such as [3], with four central modules: Natural Language Understanding (NLU), Belief Tracker, Policy, and Natural Language Generation (NLG). Some additional modules are present in the architecture to split responsibilities in a deliverable dialog system. The framework architecture is presented in Figure 1.  
On the left side, we have the communication channels that could be used by the user, which could be in textual or audio form. On the right side are some of the knowledge sources the dialog system could use. In this work, we focus on ontologies, which is the preferred method, but others are also possible. At the bottom, some possible applications can use the dialog system as a new interface to interact with the user by employing natural language. A description of each module of the proposed framework is as follows:  
* User Connection: this deals with all communication channel interfaces and converges all incoming messages to a specific format of InputMessage so that the system can process all kinds of messages in the same way;
* NLU: the Natural Language Understanding module has to interpret the user messages and extract helpful semantic information to assist the system in responding to the user, producing the Semantic Document with all the relevant semantic information;
* Belief Tracker: this updates the current dialog state with the new user message. This module keeps the short-term memory that contains information mentioned previously in this conversation;
* Policy: the dialog policy observes the current state and selects which action should be taken by the agent;
* NLG: the Natural Language Generation module transforms the action chosen by the policy into a natural language sentence to be sent to the user, delivered by the same channel through which the user sent the message;
* Knowledge Management: this has the role of managing the domain knowledge; it fetches external APIs, ontologies, or relational databases to provide domain information to the Belief Tracker and Policy modules;
* App Gate: this acts as a connector between the dialog system and the application. After a sufficient number of exchange messages between the user and the dialog system for a specific operation, the Policy module triggers the action for this module  
Figure 1: Architecture of the dialog system framework. to request an operation. This operation is performed by the external application, and its result returns to the dialog system to be included in the response;
* User Authentication: when the user requests an operation, this module authenticates the user. Authentication is not required when the user only asks informational questions. These questions are the user's doubts about the operations available or specific domain knowledge, whereas transactional messages aim to perform a task. The data passed between modules are of standard types to allow each module to be replaced independently from others. The Semantic Document should hold semantic information extracted from the user message, such as classified intents, named entities, sentiments, and desired operations. That information is extracted by the NLU, usually by task-specialized machine learning models. The State contains the current dialog state, holding the data from the most recent Semantic Document and other information mentioned previously in the dialog; this is a representation of the short-term memory of the dialog system. The Action is the representation of the system's reaction to the current state; it holds the system intent, operation, and other slots needed to generate a response. For example, in a response about an account balance, the action might have an informed intent about the check balance operation with the slot balance with the balance available to the user. These data types can be extended to support other use cases; the data presented are a minimal example.