Tasks

Introduction

At OSA-alpha, we are aiming at solving five important tasks in Conversational Intelligence. These tasks have been developed keeping in mind their business utility and scientific contribution. The following are the tasks

1. A Deep Conversational Framework (Ovation-CI): Build a deep learning based Conversational Intelligence Framework that is actively trainable, stand-alone deployable, RESTful and easily extendable.

2. Core Components of Ovation-CI: Develop the building blocks of a Conversational Intelligence framework, which are,

        a. Intent Classification

        b. Entity Recognition

        c. Sentiment Analysis

3. Business Use-cases: Develop demos for two business use-cases that will be presented at OSA-alpha using some existing open-source frameworks like Rasa.

4. Ovation Voice: Develop demos for the same use-cases (as mentioned above) using the Ovation Voice Interface.

The following sections will describe each of them in detail.

1. A Deep Learning based Conversational Framework (Ovation-CI)

Every chatbot is built upon a Conversational Intelligence framework that is composed of many components. These components enable the chatbot with various functionalities like (1) classifying the intent of what the user said (2) extracting the entities of in the users' statement (3) extracting the sentiment of the users' statement, (4) generating a response or sampling a response from a predefined set of responses, as a reply to the users' statement (query). A conversational Intelligence framework is not limited to just these components. It can have any other component that helps in making the conversation more natural with a user or extract information from what the user said.

This framework needs to have four important features, which are,

1. Active Learnability: A chatbot developer should be able to develop new chat scenarios and train a new model using Ovation-CI whenever he/she wants.

2. Stand-Alone Deployability: Ovation-CI should be deployable as a server and used stand-alone. Ideally, its components should be modular enough to give scope for heterogeneity.

3. RESTful: Ovation-CI should be accessible by RESTful APIs. E.g., you should be able to make an API call like http://<your-domain>/ovation?q="hello Ovation" and get a response like

{
  "query": "hello Ovation",
  "intents": [
    {
      "intent": "greetings",
      "intent_id": 1,
      "confidence": 0.85
    },
    {
      "intent": "welcome",
      "intent_id": 2,
      "confidence": 0.15
    }
    ],
    "entities": [
        {
          "start": 6,
          "end": 12,
          "value": "Ovation",
          "entity": "organisation",
          "confidence": 0.76
        }
    ]
}

4. Easily Extendable: Ovation-CI should be easily extendable by having scope for adding new components to its processing pipeline (described below).

Ovation-CI Architecture

The Ovation-CI architecture that we have in mind is shown in the image below. It is just for reference and not for developing something exactly like this. We want our participants to come up with innovative ideas and extend the architecture mentioned below and develop it.

The following are the components of the above architecture,

Endpoints

An endpoint is a REST API available in the Ovation-CI server. These APIs are the endpoints for any communication with it. The following are the endpoints that are mentioned in the above architecture.

1. /train can be called when a chatbot developer wants to develop his/her own model (e.g., an insurance enquiry bot). This endpoint receives data in the format

{
  "data": [
    {
      "text": "yes",
      "intent": "affirm",
      "entities": []
    },
    {
      "text": "yep",
      "intent": "affirm",
      "entities": []
    },
    {
      "text": "yeah",
      "intent": "affirm",
      "entities": []
    },
    {
        "text": "Techniker Krankenkasse offices in Kaiserslautern",
        "intent": "inquiry",
        "entities": [
          {
            "start": 34,
            "end": 48,
            "value": "Kaiserslautern",
            "entity": "location"
          },
          {
            "start": 0,
            "end": 22,
            "value": "Techniker Krankenkasse",
            "entity": "organisation"
          }
    ]
}
   

We used the above example from rasa-nlu-trainer, which can be used to generate data in this format. This data format is also an example and we expect our participants to come up with their own innovative ideas for structuring the data too.

/train invokes the pipeline, which processes the data that /train receives and trains the individual Blocks of the pipeline.

What is a Pipeline?

A pipeline is a sequence of text processing blocks, which receives a text as input and gives extracted information from the text as output. E.g., if the input text is /train/?q="Techniker Krankenkasse offices in Kaiserslautern" the response from the pipeline should be

{
  "query": "Techniker Krankenkasse offices in Kaiserslautern",
  "intents": [
    {
      "intent": "inquiry",
      "intent_id": 1,
      "confidence": 0.85
    },
    {
      "intent": "affirm",
      "intent_id": 2,
      "confidence": 0.15
    }
    ],
    "entities": [
        {
          "start": 6,
          "end": 12,
          "value": "Ovation",
          "entity": "organisation",
          "confidence": 0.76
        }
    ]
}