Rasa: multiple domains

[tmbo]

Currently, you can only have one domain. We need to make that clear in the documentation. In the meantime, we should think about ways to support multiple domains.

[oziee]

I’m trying to think how best to structure domain items so that it is easy to control and update.. In my NLU data I have quite a few intents.
Currently with my NLU model i have intents built like
TV - "turn on the TV", "turn off the TV", "Turn the TV volume up" etc with entities {ON,OFF,VOLUME,UP,DOWN}
AUTOMATION - "Turn the kitchen light on", "Turn the fan off" entities {OBJECT, LOCATION, ON,OFF}
blah blah.. you get the idea

I have built a plugin system where I am able to write new modules that run depending on the intent. So I have a module for TV, Automation, Weather, Time etc etc and these check that all required entities are there.

This is just static, there is no conversation.. ask a question and if the plugin module has all the required entities - do something - else just say something basic like "i need more info about {missing_entity}" or "I don't know how to do that"

Structuring all these intents, slots, templates, topics and actions etc in one domain file will be hard to follow, make changes and add new items

One problem would be the config section in the domain file. how different domain files could function in terms of "store_entities_as_slots"

To have a folder where seperate structured domain files lived which contained all the info for each intent would be one idea.. each file could be named by the intent

CORE could then build one huge file as it loads by reading in all the seperate files in the folder

Checks would have to be made for duplicate item names.. or maybe some way when building the main domain file during load would be to read in items like "utter_goodbye:" but in the building file change it to something like "utter_{entity_name}_goodbye:" which would reduce the duplicate problem

[juncaofish]

I have the same problems of handling multiple domains. Currently, I work around by this way: create several domain directories with specific policy/interpreter/action/yml file. In the run script, there will be multiple agent instances, I use agent.handle_message() for input and collect the output message of all domains, then I chain a final ranker to decide which one should be the best reply... Also, I need to reset previous agent tracker if user input switches among domains. Although it works for some cases, it's a little bit overhead anyway. Any comment on my try?

[oziee]

anything in the pipeline for this?

[raypp]

multiple domains are useful, please support

[tmbo]

I mean one approach would be to allow to define multiple domain files. Loading multiple story files is already part of a PR.

I am not sure that solves the task though, one needs to be especially aware of conflicts between the intents / entities of the different domains.

[juncaofish]

yes, the different domains should have no shared entities, other while it'll be a big trouble... I'm trying to implement a travel bot that helps to book a flight and then a hotel and maybe also query weather.. of course, the city/date entities should be shared by each other.. however, it seems to be very hard, when using rasa-core currently. Tell me if you guys have any ideas for this use case..

[ewagner70]

any thoughts/ideas/PR already?

[andreasstuber]

multiple domain files would be good, or possibly a primary domain (that will determine which sub-domain to refer to) and sub-domains. We have three types of visitors: potential employees, current employees, customers, suppliers. The type of information/ intents/ actions and services that is provided to each type of visitor is very different.

[tmbo]

@andreasstuber that is a very interesting use case and I see the reason why you need this to be modular.

@amn41 this reminds me of the miniskills in one of the papers. I mean we could do something like add a feature field like the topic but not use a stack. Just really a value that behaves much like a categorical slot (so you have predefined values for it {None, "customer", "employee"}). The different domains could live as separate bots and get trained with the topic field always set to one value. But still not sure who'd set/change the topic in the first place.

[amn41]

in the miniskills idea you learn a meta-policy which decides which domain should handle any given message. you could also let the sub-policies themselves decide when they should hand off. In practice, I don't think I've seen a case where it wouldn't work to simply merge the domains and training data with a preprocessing script and then training core. (i'm willing to be convinced otherwise)

I think there is some complexity in dealing with NLU data and slots across domains, and I'm skeptical there's a one-size-fits-all solution. Would it really make sense to support something like this natively? IMO only if there is a strong case that some important problems cannot be solved with a merged domain.

[ewagner70]

@amn41: I also support the idea of having a "meta-policy" or "top-domain" which sets the overall context. Reasons are: overlapping of entities, stories, actions but with different paths, semantics, etc.
It would significantly reduce training examples and reducing jeopardized training results when respective contexts are preset. (Hope I'm at least somewhat clear with what I want to say?)

[amn41]

do you have a concrete example of two domains with the stories you'd like to support?

[juncaofish]

@amn41 hello, how to handle the situation of duplicate slot_name in several domains, as you suggest merging all slots into one with some preprocessing script? i.e. I want to book flight and hotel, and also query weather, for these domains, the destination slot should be stored separately, but some case allows value inheriting from each other.

[ghost]

Wouldn't merging the domains present a scaling issue if the resulting domain had many intents?

I'm building an user-facing interactive learning / (edit: Wizard of Oz) system, where customer teams will be training their own domains. So I don't even know what domains will be created, or how many intents they'll contain. (What would be a reasonable cap, BTW? 100?)

So I also keep thinking that either there should be a root domain dispatching to the others, or that every domain should be able to pass the user to another domain; perhaps be based on a template which has intents for switching domains.

[karthikbalu]

My idea that im implementing is very simple...

Just by keeping different folders for different domains with its story, nlu, actions and running them as HTTP server each domains with separate server port in parallel

I have a nodejs proxy REST interface that routes request to corresponding python HTTP server port based on the selected agent domain given as part of the input message, already Rasa Core has the HTTP server with sender id tracking etc., so i felt its a good idea not to reinvent the wheel here

Pls Let me know what are the down side of this approach other than port exhaustion?
Thanks

[Manvendra01]

@karthikbalu That's what I was thinking.
If RASA can provide failover message processing pipeline, it will be a superb feature.
i.e. when intent accuracy falls below a certain value on a message, pass that message to another sub-domain handler.

[amn41]

@Manvendra01 that's possible with the fallbackpolicy http://core.rasa.com/patterns.html#fallback-default-actions

[karthikbalu]

But lets say we are serving multiple domain for different use case and not related to each other, fallback policy wont be the solution i guess, any alternate solutions pls? @akelad

[akelad]

we're looking into multiple domains for the future, we have no update as of yet though

[Patrick-DS]

I just wanna add in my input too : currently I am building FAQ bots and to structure my data correctly I create one file per FAQ question that generates all the relevant data for that question : the stories, the training examples for NLU, and the stuff that needs to be added in the domain. I store all those things in temporary files (for testing purposes, since my code is a bit experimental haha) so I get one mini domain per question. Before training NLU and Core I use the merge function of the Domain class, and that works well enough for me.

I think that since Rasa already enables multiple policies, if someone has a use-case where bot behavior changes drastically and permanently depending on a single input from the user, it's good to write a custom policy that decides which policies should be considered "active" and which ones shouldn't (for example, on a customer service use-case, if a user is either a private customer or a business customer, turn on/off the corresponding policies at the point where the bot gets that information if that changes the conversation drastically). The option of training multiple NLU interpreters to deal with different intents can also be figured out with a bit of engineering.

I'm open for discussions :)

[yondu22]

@karthikbalu would your solution require lots of resources as you need to spun up servers for each core, ideally if it could be like the nlu solution where one server is running and it uses the files based on the parameter passed

[karthikbalu]

So far I’m using it with multiple server ports, I know it’s not as scalable but there isn’t a better way that I’m aware of... but in my use case I don’t have too many agents running in parallel and this isn’t a problem related to core count

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[solyarisoftware]

@karthikbalu what do you mean with

based on the selected agent domain given as part of the input message,

? May you give us an example (of the input message) that would act as "multiplexer" ?

[chikubee]

Hi,
does RASA support

1. Identification of multiple intent in the same domain from the utterance (faq/rasax , faq/channels) -> utterance that talked of both.
2. Identification of multiple intent across diff domains from the utterance (greet + faq/channels)

[akelad]

going to close this as with the 2.0 RC release, loading from multiple domain files is now possible.