rasa
💬 Open source machine learning framework to automate text- and voice-based conversations: NLU, dialogue management, connect to Slack, Facebook, and more - Create chatbots and voice assistants
Top Related Projects
The open-source hub to build & deploy GPT/LLM Agents ⚡️
Bot Framework provides the most comprehensive experience for building conversation applications.
Pretrained models for TensorFlow.js
💫 Industrial-strength Natural Language Processing (NLP) in Python
Quick Overview
Rasa is an open-source machine learning framework for automated text and voice-based conversations. It allows developers to build contextual AI assistants and chatbots that can understand user intents, maintain context, and respond appropriately. Rasa provides tools for natural language understanding (NLU) and dialogue management.
Pros
- Highly customizable and flexible, allowing developers to create complex conversational AI systems
- Supports multiple languages and can be deployed on various platforms
- Active community and extensive documentation for support and learning
- Open-source nature allows for transparency and contributions from the community
Cons
- Steep learning curve for beginners, especially those new to machine learning
- Requires significant training data for optimal performance
- Can be resource-intensive for large-scale deployments
- Some advanced features may require additional setup or integration with other tools
Code Examples
- Training a Rasa model:
from rasa.cli.scaffold import create_initial_project
from rasa.model_training import train
# Create a new project
create_initial_project("./my_chatbot")
# Train the model
train(domain="domain.yml", config="config.yml", training_files="data/")
- Loading and using a trained model:
from rasa.core.agent import Agent
# Load the trained model
agent = Agent.load("models/20210101-120000.tar.gz")
# Use the model to predict intents and actions
result = agent.parse("Hello, how are you?")
print(result)
- Running a Rasa server:
from rasa.core.run import serve_application
# Start the Rasa server
serve_application(
model_path="models/20210101-120000.tar.gz",
endpoints="endpoints.yml",
port=5005
)
Getting Started
- Install Rasa:
pip install rasa
- Create a new project:
rasa init
- Train the model:
rasa train
- Test the chatbot in the command line:
rasa shell
- Start the Rasa server:
rasa run
Competitor Comparisons
The open-source hub to build & deploy GPT/LLM Agents ⚡️
Pros of Botpress
- User-friendly visual flow builder for easier bot design
- Built-in analytics and conversation testing tools
- Supports multiple channels out-of-the-box (e.g., web, Messenger, Slack)
Cons of Botpress
- Less flexibility for complex NLU tasks
- Smaller community and fewer third-party integrations
- Steeper learning curve for developers familiar with Python
Code Comparison
Botpress (JavaScript):
bp.hear(/hello/i, (event, next) => {
bp.messaging.sendText(event.channel, 'Hello, human!')
})
Rasa (Python):
class ActionGreet(Action):
def name(self) -> Text:
return "action_greet"
def run(self, dispatcher: CollectingDispatcher,
tracker: Tracker,
domain: Dict[Text, Any]) -> List[Dict[Text, Any]]:
dispatcher.utter_message(text="Hello, human!")
return []
Both frameworks offer different approaches to building conversational AI. Botpress focuses on visual development and ease of use, while Rasa provides more flexibility and control for complex NLU tasks. The choice between them depends on the specific project requirements and the development team's expertise.
Bot Framework provides the most comprehensive experience for building conversation applications.
Pros of botframework-sdk
- Seamless integration with Microsoft Azure services and other Microsoft technologies
- Supports multiple programming languages (C#, JavaScript, Python)
- Extensive documentation and community support
Cons of botframework-sdk
- Steeper learning curve for developers new to Microsoft ecosystem
- Less flexibility in customization compared to Rasa
- Potential vendor lock-in with Microsoft services
Code Comparison
Rasa (Python):
from rasa_sdk import Action
class ActionGreet(Action):
def name(self) -> str:
return "action_greet"
def run(self, dispatcher, tracker, domain):
dispatcher.utter_message(text="Hello! How can I help you?")
return []
botframework-sdk (JavaScript):
const { ActivityHandler, MessageFactory } = require('botbuilder');
class GreetingBot extends ActivityHandler {
constructor() {
super();
this.onMessage(async (context, next) => {
await context.sendActivity(MessageFactory.text('Hello! How can I help you?'));
await next();
});
}
}
Both frameworks allow for easy creation of conversational AI, but Rasa offers more flexibility and customization options, while botframework-sdk provides better integration with Microsoft services and multi-language support. The choice between the two depends on specific project requirements and the development team's expertise.
Pretrained models for TensorFlow.js
Pros of tfjs-models
- Runs in the browser, enabling client-side machine learning
- Offers a variety of pre-trained models for common tasks
- Lightweight and optimized for performance on web and mobile devices
Cons of tfjs-models
- Limited to JavaScript/TypeScript environments
- Narrower scope, focusing primarily on computer vision and natural language processing tasks
- Less customizable for complex conversational AI applications
Code Comparison
tfjs-models (Object Detection):
const model = await cocoSsd.load();
const predictions = await model.detect(img);
predictions.forEach(prediction => {
console.log(prediction.class, prediction.score);
});
Rasa (Intent Classification):
from rasa.nlu.model import Interpreter
interpreter = Interpreter.load("./models/nlu")
result = interpreter.parse("Hello, how are you?")
print(result["intent"]["name"], result["intent"]["confidence"])
Summary
While tfjs-models excels in client-side ML applications with pre-trained models, Rasa is better suited for building comprehensive conversational AI systems. tfjs-models offers ease of use and browser compatibility, but Rasa provides more flexibility and customization for complex dialogue management and natural language understanding tasks.
💫 Industrial-strength Natural Language Processing (NLP) in Python
Pros of spaCy
- More focused on core NLP tasks like tokenization, part-of-speech tagging, and named entity recognition
- Faster processing speed for large volumes of text
- Extensive pre-trained models for multiple languages
Cons of spaCy
- Less suitable for building conversational AI systems
- Requires more custom coding for complex language understanding tasks
- Limited built-in support for dialogue management
Code Comparison
spaCy:
import spacy
nlp = spacy.load("en_core_web_sm")
doc = nlp("Apple is looking at buying U.K. startup for $1 billion")
for ent in doc.ents:
print(ent.text, ent.label_)
Rasa:
from rasa.nlu.model import Interpreter
interpreter = Interpreter.load("./models/nlu")
result = interpreter.parse("I want to book a flight to Berlin")
print(result["intent"]["name"])
print(result["entities"])
Summary
spaCy excels in core NLP tasks and processing speed, while Rasa is better suited for building conversational AI systems. spaCy offers more pre-trained models and languages, but Rasa provides built-in support for dialogue management. The choice between the two depends on the specific requirements of your project.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Rasa Open Source
ð¡ We're migrating issues to Jira ð¡
Starting January 2023, issues for Rasa Open Source are located in this Jira board. You can browse issues without being logged in; if you want to create issues, you'll need to create a Jira account.
Rasa is an open source machine learning framework to automate text and voice-based conversations. With Rasa, you can build contextual assistants on:
- Facebook Messenger
- Slack
- Google Hangouts
- Webex Teams
- Microsoft Bot Framework
- Rocket.Chat
- Mattermost
- Telegram
- Twilio
- Your own custom conversational channels
or voice assistants as:
- Alexa Skills
- Google Home Actions
Rasa helps you build contextual assistants capable of having layered conversations with lots of back-and-forth. In order for a human to have a meaningful exchange with a contextual assistant, the assistant needs to be able to use context to build on things that were previously discussed â Rasa enables you to build assistants that can do this in a scalable way.
There's a lot more background information in this blog post.
-
ð¤ Read The Docs
-
ð Install Rasa
-
ð¤ Contribute
Where to get help
There is extensive documentation in the Rasa Docs. Make sure to select the correct version so you are looking at the docs for the version you installed.
Please use Rasa Community Forum for quick answers to questions.
README Contents:
How to contribute
We are very happy to receive and merge your contributions into this repository!
To contribute via pull request, follow these steps:
- Create an issue describing the bug/improvement you want to work on or pick up an existing issue in Jira
- Follow our Pull Request guidelines: write code, test, documentation, changelog and follow our Code Style
- Create a pull request describing your changes
For more detailed instructions on how to contribute code, check out these code contributor guidelines.
You can find more information about how to contribute to Rasa (in lots of different ways!) on our website..
Your pull request will be reviewed by a maintainer, who will get back to you about any necessary changes or questions. You will also be asked to sign a Contributor License Agreement.
Development Internals
Installing Poetry
Rasa uses Poetry for packaging and dependency management. If you want to build it from source, you have to install Poetry first. Please follow the official guide to see all possible options.
To update an existing poetry version to the version, currently used in rasa, run:
poetry self update <version>
Managing environments
The official Poetry guide suggests to use pyenv or any other similar tool to easily switch between Python versions. This is how it can be done:
pyenv install 3.10.10
pyenv local 3.10.10 # Activate Python 3.10.10 for the current project
Note: If you have trouble installing a specific version of python on your system it might be worth trying other supported versions.
By default, Poetry will try to use the currently activated Python version to create the virtual environment for the current project automatically. You can also create and activate a virtual environment manually â in this case, Poetry should pick it up and use it to install the dependencies. For example:
python -m venv .venv
source .venv/bin/activate
You can make sure that the environment is picked up by executing
poetry env info
Building from source
To install dependencies and rasa
itself in editable mode execute
make install
Note for macOS users: under macOS Big Sur we've seen some compiler issues for
dependencies. Using export SYSTEM_VERSION_COMPAT=1
before the installation helped.
Installing optional dependencies
In order to install rasa's optional dependencies, you need to run:
make install-full
Note for macOS users: The command make install-full
could result in a failure while installing tokenizers
(issue described in depth here).
In order to resolve it, you must follow these steps to install a Rust compiler:
brew install rustup
rustup-init
After initialising the Rust compiler, you should restart the console and check its installation:
rustc --version
In case the PATH variable had not been automatically setup, run:
export PATH="$HOME/.cargo/bin:$PATH"
Running and changing the documentation
First of all, install all the required dependencies:
make install install-docs
After the installation has finished, you can run and view the documentation locally using:
make livedocs
It should open a new tab with the local version of the docs in your browser; if not, visit http://localhost:3000 in your browser. You can now change the docs locally and the web page will automatically reload and apply your changes.
Running the Tests
In order to run the tests, make sure that you have the development requirements installed:
make prepare-tests-ubuntu # Only on Ubuntu and Debian based systems
make prepare-tests-macos # Only on macOS
Then, run the tests:
make test
They can also be run at multiple jobs to save some time:
JOBS=[n] make test
Where [n]
is the number of jobs desired. If omitted, [n]
will be automatically chosen by pytest.
Running the Integration Tests
In order to run the integration tests, make sure that you have the development requirements installed:
make prepare-tests-ubuntu # Only on Ubuntu and Debian based systems
make prepare-tests-macos # Only on macOS
Then, you'll need to start services with the following command which uses Docker Compose:
make run-integration-containers
Finally, you can run the integration tests like this:
make test-integration
Resolving merge conflicts
Poetry doesn't include any solution that can help to resolve merge conflicts in
the lock file poetry.lock
by default.
However, there is a great tool called poetry-merge-lock.
Here is how you can install it:
pip install poetry-merge-lock
Just execute this command to resolve merge conflicts in poetry.lock
automatically:
poetry-merge-lock
Build a Docker image locally
In order to build a Docker image on your local machine execute the following command:
make build-docker
The Docker image is available on your local machine as rasa:localdev
.
Code Style
To ensure a standardized code style we use the formatter black. To ensure our type annotations are correct we use the type checker pytype. If your code is not formatted properly or doesn't type check, GitHub will fail to build.
Formatting
If you want to automatically format your code on every commit, you can use pre-commit.
Just install it via pip install pre-commit
and execute pre-commit install
in the root folder.
This will add a hook to the repository, which reformats files on every commit.
If you want to set it up manually, install black via poetry install
.
To reformat files execute
make formatter
Type Checking
If you want to check types on the codebase, install mypy
using poetry install
.
To check the types execute
make types
Deploying documentation updates
We use Docusaurus v2
to build docs for tagged versions and for the main
branch.
To run Docusaurus, install Node.js 12.x
.
The static site that gets built is pushed to the documentation
branch of this repo.
We host the site on netlify. On main
branch builds (see .github/workflows/documentation.yml
), we push the built docs to
the documentation
branch. Netlify automatically re-deploys the docs pages whenever there is a change to that branch.
Releases
Rasa has implemented robust policies governing version naming, as well as release pace for major, minor, and patch releases.
The values for a given version number (MAJOR.MINOR.PATCH) are incremented as follows:
- MAJOR version for incompatible API changes or other breaking changes.
- MINOR version for functionality added in a backward compatible manner.
- PATCH version for backward compatible bug fixes.
The following table describes the version types and their expected release cadence:
Version Type | Description | Target Cadence |
---|---|---|
Major | For significant changes, or when any backward-incompatible changes are introduced to the API or data model. | Every 1 - 2 yrs |
Minor | For when new backward-compatible functionality is introduced, a minor feature is introduced, or when a set of smaller features is rolled out. | +/- Quarterly |
Patch | For backward-compatible bug fixes that fix incorrect behavior. | As needed |
While this table represents our target release frequency, we reserve the right to modify it based on changing market conditions and technical requirements.
Maintenance Policy
Our End of Life policy defines how long a given release is considered supported, as well as how long a release is considered to be still in active development or maintenance.
The maintenance duration and end of life for every release are shown on our website as part of the Product Release and Maintenance Policy.
Cutting a Major / Minor release
A week before release day
- Make sure the milestone already exists and is scheduled for the correct date.
- Take a look at the issues & PRs that are in the milestone: does it look about right for the release highlights we are planning to ship? Does it look like anything is missing? Don't worry about being aware of every PR that should be in, but it's useful to take a moment to evaluate what's assigned to the milestone.
- Post a message on the engineering Slack channel, letting the team know you'll be the one cutting the upcoming
release, as well as:
- Providing the link to the appropriate milestone
- Reminding everyone to go over their issues and PRs and please assign them to the milestone
- Reminding everyone of the scheduled date for the release
A day before release day
- Go over the milestone and evaluate the status of any PR merging that's happening. Follow up with people on their bugs and fixes. If the release introduces new bugs or regressions that can't be fixed in time, we should discuss on Slack about this and take a decision on how to move forward. If the issue is not ready to be merged in time, we remove the issue / PR from the milestone and notify the PR owner and the product manager on Slack about it. The PR / issue owners are responsible for communicating any issues which might be release relevant. Postponing the release should be considered as an edge case scenario.
Release day! ð
- At the start of the day, post a small message on slack announcing release day! Communicate you'll be handling the release, and the time you're aiming to start releasing (again, no later than 4pm, as issues may arise and cause delays). This message should be posted early in the morning and before moving forward with any of the steps of the release, in order to give enough time to people to check their PRs and issues. That way they can plan any remaining work. A template of the slack message can be found here. The release time should be communicated transparently so that others can plan potentially necessary steps accordingly. If there are bigger changes this should be communicated.
- Make sure the milestone is empty (everything has been either merged or moved to the next milestone)
- Once everything in the milestone is taken care of, post a small message on Slack communicating you are about to start the release process (in case anything is missing).
- You may now do the release by following the instructions outlined in the Rasa Open Source README !
After a Major release
After a Major release has been completed, please follow these instructions to complete the documentation update.
Steps to release a new version
Releasing a new version is quite simple, as the packages are build and distributed by GitHub Actions.
Release steps:
- Make sure all dependencies are up to date (especially Rasa SDK)
- For Rasa SDK, except in the case of a patch release, that means first creating a new Rasa SDK release (make sure the version numbers between the new Rasa and Rasa SDK releases match)
- Once the tag with the new Rasa SDK release is pushed and the package appears on pypi, the dependency in the rasa repository can be resolved (see below).
- If this is a minor / major release: Make sure all fixes from currently supported minor versions have been merged from their respective release branches (e.g. 3.3.x) back into main.
- In case of a minor release, create a new branch that corresponds to the new release, e.g.
git checkout -b 1.2.x git push origin 1.2.x
- Switch to the branch you want to cut the release from (
main
in case of a major, the<major>.<minor>.x
branch for minors and patches)- Update the
rasa-sdk
entry inpyproject.toml
with the new release version and runpoetry update
. This creates a newpoetry.lock
file with all dependencies resolved. - Commit the changes with
git commit -am "bump rasa-sdk dependency"
but do not push them. They will be automatically picked up by the following step.
- Update the
- If this is a major release, update the list of actively maintained versions in the README and in the docs.
- Run
make release
- Create a PR against the release branch (e.g.
1.2.x
) - Once your PR is merged, tag a new release (this SHOULD always happen on the release branch), e.g. using
GitHub will build this tag and publish the build artifacts.git checkout 1.2.x git pull origin 1.2.x git tag 1.2.0 -m "next release" git push origin 1.2.0 --tags
- After all the steps are completed and if everything goes well then we should see a message automatically posted in the company's Slack (
product
channel) like this one - If no message appears in the channel then you can do the following checks:
- Check the workflows in Github Actions and make sure that the merged PR of the current release is completed successfully. To easily find your PR you can use the filters
event: push
andbranch: <version number>
(example on release 2.4 you can see here) - If the workflow is not completed, then try to re run the workflow in case that solves the problem
- If the problem persists, check also the log files and try to find the root cause of the issue
- If you still cannot resolve the error, contact the infrastructure team by providing any helpful information from your investigation
- Check the workflows in Github Actions and make sure that the merged PR of the current release is completed successfully. To easily find your PR you can use the filters
- After the message is posted correctly in the
product
channel, check also in theproduct-engineering-alerts
channel if there are any alerts related to the Rasa Open Source release like this one
Cutting a Patch release
Patch releases are simpler to cut, since they are meant to contain only bugfixes.
The only things you need to do to cut a patch release are:
- Notify the engineering team on Slack that you are planning to cut a patch, in case someone has an important fix to add.
- Make sure the bugfix(es) are in the release branch you will use (p.e if you are cutting a
2.0.4
patch, you will need your fixes to be on the2.0.x
release branch). All patch releases must come from a.x
branch! - Once you're ready to release the Rasa Open Source patch, checkout the branch, run
make release
and follow the steps + get the PR merged. - Once the PR is in, pull the
.x
branch again and push the tag!
Additional Release Tasks
Note: This is only required if the released version is the highest version available. For instance, perform the following steps when version > version on main.
In order to check compatibility between the new released Rasa version to the latest version of Rasa X/Enterprise, we perform the following steps:
- Following a new Rasa release, an automated pull request is created in Rasa-X-Demo.
- Once the above PR is merged, follow instructions here, to release a version.
- Update the new version in the Rasa X/Enterprise env file. The Rasa-X-Demo project uses the new updated Rasa version to train and test a model which in turn is used by our CI to run tests in the Rasa X/Enterprise repository, thus validating compatibility between Rasa and Rasa X/Enterprise.
Actively maintained versions
Please refer to the Rasa Product Release and Maintenance Policy page.
License
Licensed under the Apache License, Version 2.0. Copyright 2022 Rasa Technologies GmbH. Copy of the license.
A list of the Licenses of the dependencies of the project can be found at the bottom of the Libraries Summary.
Top Related Projects
The open-source hub to build & deploy GPT/LLM Agents ⚡️
Bot Framework provides the most comprehensive experience for building conversation applications.
Pretrained models for TensorFlow.js
💫 Industrial-strength Natural Language Processing (NLP) in Python
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot