Scoping skills

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)

[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]

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 😄 ).