iai-group / dialoguekit Goto Github PK

Change UserPreferences to be in [-1,1]

Use the types Utterance and Intent to build the NLG template.

The problem

Parroting agents are not necessarily the best agents too test with as the poses no logic.
A better solution should be created. So development with UserSimCRS can progress.

Sugested solution

A simple mathematics agent will suffice to develop UserSimCRS further.

Agent conversation flow.

• Ask simple addition, multiplication and division questions.
• If user answers correctly ask new question.
• If user answers wrongly, say that they were wrong.

Currently, it's hard-coded in the dialogue manager on "bye".
Instead, this should be part of the Agent's functionality.

Create AnnotatedUtterance and replace Utterance with that wherever appropriate (incl. build_template_from_instances())

Todays Utterance functionality should be kept in the AnnotatedUtterance, while the Utterance class should only contain the uttered text.

It's needed for

• Preference modeling
• Slot annotation
• (Third-party agent, but we probably don't need to worry about it here.)

E.g.,
https://github.com/iai-group/moviebot/blob/master/moviebot/nlu/text_processing.py

Some strings such as "USER" and "EXIT" are used as constants but not defined in that way.
Find a good location for them.

The problem

The current NLG template does not use the core classes.
This makes future improvements to the core classes irrelevant to the template. As this is a mayor drawback of the current implementation which uses strings for the template.

Proposed solution

Rework the template structure to use the core classes.
Important to maintain the same functionality as the current solution.

The cosine and Rasa intent classification models should support being saved and loaded.

The problem

The way the Platform and DM (Dialogue Manager) interact as of now, has made the scope of what the DM does too large and tied to DialogueKit. Restricting communication of participants to native to DialogueKit implementations. Much off what the current DM does should be handled by different implementations of the Platform.

Suggested implementation:

Platform
The Platform should be the way the participants communicate. This can either be native to DialogueKit, or other means such as REST APIs etc.

Dialogue Manager
The DM should only orchestrate the communication, and request the Platform to communicate to the participants.

The test of Rasa annotation converter need to validated the generated yml files. Especially the one that gets fed to the training of Rasa models.

The problem

Developer experience

When developing with a package it is quite frustrating if the developing experience is unnecessarily tedious. Two examples: Firstly, when debugging it is quite frustrating to just see a scrambled mess off a hash with the corresponding class name for an object and it is not immediately clear what the content is. Secondly, the same problem occurs when printing an object.

Functionality

Lost of data object functionality hinges on comparisons and hashing. Thus our classes can be easily used, by us and others alike.

Examples of something that we want to work, that do not work currently.

Comparison

A = Intent(text="HELLO")
B = Intent(text="HELLO")

# This will not work
A == B

Hashing

A = Intent(text="HELLO")
B = {}

# This will not work
B[A] = "somevalue"

Proposed solution

Our core classes would be much easier to use if they implemented some of the python class special name methods. The most useful special methods are listed below with link to python docs.

• __repr__
• __str__
• __eq__
• __hash__

The default Rasa nlu pipeline performs well, try to implemented it.

• Change DialogueKit NLU API to conform with Rasa (i.e., nlu.py)
• Write a specific instantiation that uses the Rasa NLP pipeline(i.e., nlu_rasa.py)
• Remove everything else from dialoguekit/nlu/
• Write some tests to check if it’s working

Some default behaviours are different between macOS and Windows, such as open().
We have to make sure our functionality works across platforms.

Specifically for open(), we need to specify the encoding ex. open(filepath, encoding="uff-8").

Create a function that can export/save the dialogue history to a yml file.
The common format should be the same as the one used from moviebot, a sample can be seen here.

Optionally provide an Ontology for the Item constructor; if given, only properties that are present in the ontology would be allowed.
Likely do the same in ItemCollection.

The Rasa parrot agent should communicate with the rasa-parrot with localhost requests.

To make it simple to test DialogueKit add documentation on how to use the User.
With the User we can talk to an Agent using the terminal.

This will group the same functionality in the Participant class

Figure out how to change dialogue_manager to dialogue_manager: DialogueManager in register_dialogue_manager() without triggering circular imports error.

Some classes would be much easier to use if they had comparison functions.

Classes of primary interest:

• Intent
• Annotation
• Utterance

Create an abstract class for annotation converters, and also implement a converter from dialoguekit/moviebot data to rasa specific format. In addition create files that may be useful as entity type to entity examples, etc.

To comply with the agent-based simulator, we need to design the preference model.
It should be able to:

• initialize preferences (load data) for a simulator (e.g. sample items to represent the preferences)
• Keep track of the slots that the users have been received from the agent and sent to
• Update the next slot(s) based on the previous agent reply (intent and agent slots)

Guidelines: https://github.com/iai-group/guidelines/tree/main/python#install-pre-commit-hooks