Rasa recently announced new release of Rasa Open Source 3.0, to help build conversational AI. It separates the model architecture from the framework architecture, enabling developers to run arbitrary model architectures. It also comes with several enhancements focused on improving the developer experience when building conversational AI assistants with Rasa.
The revamped computational backend empowers us to experiment with architectures, reducing maintenance costs, and enabling collaborative development at scale. There are improvements to slot mappings that will make it easier to implement desired slot behavior as well as forms.
It also comes with a new experimental feature, intended to help us figure out how to add a “semantic layer” on top of the tracker store of events that makes it easier to identify and track situations of interest in conversations.
The new graph architecture aims to make it easier to understand the relationship between the NLU and policy components in the pipeline. It is much easier to define and modify the dependencies between the training pipeline components. In previous Rasa versions any change to any of the pipeline components required all components to be retrained. The beauty of graph architecture is that it makes it possible to save trained components on disc. This means that if a change is made to a specific component, only that component will need to be retrained. This should save a lot of computational resources and reduce training time.
A graph architecture makes it much easier to visualize and understand the dependencies between different components, especially between NLU and policy components which formerly were treated separately. Now there is no need to worry about classifying components into NLU or policy components.
In the past, if you had an entity and a slot defined with the same name, Rasa would automatically fill the slot with the value of the extracted entity. While this sometimes saved a little bit of development time, it has often led to undesired behaviors (slots being filled in when they shouldn’t have been) and confusion when implementing forms with slot mappings.
With Rasa Open Source 3.0, this behaviour has been changed. From now on it will be necessary to define global slot mappings for all slots defined in a domain file. Those mappings will have to be defined inside of the slots section of your domain.
The team says that the new features and improvements were crucial to making sure that the changes made tackle the most pressing needs of the developer community.
