Rasa: Scoping skills

[wochinge]

Motivation

After doing https://github.com/RasaHQ/rasa/issues/3302, the next step is to be able to scope intents. Currently intents, entities, actions and so on are merged by default. With this enhancement we want to make it possible to add a scope / namespace to a skill import so that you can avoid overlapping.

Example:

Consider imports like:

imports:
  - Skill A
  - Skill B

If both Skill A and Skill B have an intent greet the training data for this intent is currently merged.

Proposed implementation

Config file

The easiest is to use a : to indicate a scoping since that's a yaml dictionary then

imports:
  - Skill A: scope1
  - Skill B

Applying the scopes

The tricky part is:

• to rename things in stories, domain, nlu training data
• separate the scoping since it's only used with skills

TrainingFileImporter

Making the file loading components easily replaceable without affecting any other code.

• separated this part out: https://github.com/RasaHQ/rasa/issues/3937

SkillImporter

Currently the SkillSelector only picks up the config files along the way.
In SkillSelector._from_directory we now also have to find and load story files / domains / nlu training files. These files can then be merged as the skills are merged.

Regarding the scoping:

• We could either do everything from SkillImporter which requires the individual classes (e.g. Domain to expose a lot externals to SkillImporter
• add function scope to Domain, TrainingData, DialogueStateTracker (more intrusive, but less connections between classes + easier testable)

[amn41]

This seems like a lot of code complexity. Can you give an example of where this is needed and it’s not simpler to just write a shell script that prepends the skill name in the nlu & stories files?

[wochinge]

This seems like a lot of code complexity.

That's true, but due to the used interface the implementation would be strictly separated from how the current file loading works. Also we could reduce some code debt, since currently the file loading is distributed all over the code and we could use the proposed interface to centralize it.

it’s not simpler to just write a shell script that prepends the skill name in the nlu & stories files?

A shell script would permanently do these changes to the NLU & story files. However, we just need these changes during training time.

Can you give an example of where this is needed

This is needed when two teams each develop multiple independent skills, whose intents, entities, slots, etc shouldn't overlap. E.g. two skills could have an action utter_address, but once it should be sth like This restaurant is in {address}. and once it's Ok, I saved your home address {address}. (sorry, it's hard to come up with a good example 😄 ).

[amn41]

The fact that it’s hard to come up with a good example is, I think, the point. I’m not sure I see the need for this. It’s a lot of logic to add to the codebase and I don’t see the benefit being big enough

[wochinge]

I see your point now. Maybe the point of this issue should then be to make the file loading in Rasa more modular, which means

• the logic is centralized in a component
• it can be easily exchanged by a different component (similar to how we can exchange policies, custom components now).

By having this alternative / experimental file loading approaches could be implemented / maintained as separate modules / libraries.

We can also do a architectural review in two weeks or so where we can discuss different approaches to achieve this modularity

[wochinge]

I made a new issue for the interface to centralize the import behavior so that these are not longer glued together: https://github.com/RasaHQ/rasa/issues/3937

[ggdupont]

If I may add an example of use that may justify the need: question/answering skill is quite common scheme that is used in many different domains. For our own internal work, we are developing multiple Q/A approaches which relies either on backend knowledge base or more search engine model (answer provided as a part of doc). Both are adapted to a specific of information types and for both w can train the bot for a "question" intend which match the set of questions each skill can address.

If we want to merge these 2 skills, we need to prefix the "question" intend of each skill manually. Not that much of work for now... But as the number of domain Q/A skills it will be painful to maintain these local namespaces. So having a scope/namespace aware importer would help.