Removing projects for Rasa NLU server

Announcements
9

Hi,

glad to hear that I could help. Regarding the JSONs:

Basically I have forked an empty rasa bot into a builder directory, meaning that during runtime, a python library fetches data needed for the bot and takes the builder directory to fill in the information needed. I decided that JSON is much easier to use than markdown in terms of serialization and persistence. The only thing remaining is the stories.md - the JSON is converted into proper markdown in the RASA input format. So in this step, there is actually no magic. The data for the JSON training files can be stored elsewhere. If I’d recommend a message broker, I’d choose:

https://www.rabbitmq.com/

since it could easily plugged into any pipeline.

Now the exciting thing: actions.py

I have asked myself how to generalize those CustomActions or FormActions - is it even possible? I thought about 3 scenarios:

  1. Having exactly one predefined GeneralAction(Action) and one predefined GeneralFormAction(FormAction) which does all the heavy lifting
  2. Accepting the fact that actions.py has to be predefined by a developer for specific cases
  3. Prepare actions.py in a way, that after instanciating, it adds every needed Class and their methods at runtime based on the information in domain.yml

For deciding how to proceed it is important to think about:

  1. What are the things needed at build time?
  2. What are the things needed at run time?

Keep in mind that of course it would be possible to just modify the source code since it is open source, but I wanted to keep it mostly update-safe. I can’t go into deep details in this posting since that would cause a wall of text - i try to keep my explanations simple, please don’t hesitate to ask.

For scenario one, you have to modify your stories and your domain since both Action-types needs the name which registers the action to rasa core. Then everytime you start an action or form, it will be the general one. The triggering point which decides which information actually has to be filled into the action depends on the intent which lead to the execution. If it is a feasible approach for you, you then have to modify the validation method such that it calls the “old” version: validation every slot in one single method. The rules for validation, slot_mapping and submit could be injected during runtime.

Scenario two tends to be self-explanatory. Imho a feasible way would be to open the file in browser and let a developer decide how to proceed. This way has a strong dependancy to UI/UX since it is advanced.

Actually scenario three has been implemented by me using a facade pattern to add classes and methods at runtime. After longer investigation, I don’t believe that this is a proper approach since it heavily depends on validating every rule that inserts a class or a method. A single change in the source data could cause several other problems and for productive use I really can’t recommend this version for now.

If I should help you or give you more advices, it would be crucial to know more about your specific scenario because I think generalization is good BUT has it’s limits.

Regards