diff --git a/changelog/6457.improvement.md b/changelog/6457.improvement.md
new file mode 100644
index 000000000000..821a5d33ec8d
--- /dev/null
+++ b/changelog/6457.improvement.md
@@ -0,0 +1 @@
+Support for test stories written in yaml format.
diff --git a/data/test_dialogues/default.json b/data/test_dialogues/default.json
index abadf0e407ad..1a8ce03e8000 100644
--- a/data/test_dialogues/default.json
+++ b/data/test_dialogues/default.json
@@ -39,6 +39,8 @@
"confidence": 0.0,
"name": "greet"
},
+ "message_id": null,
+ "metadata": {},
"text": "Hi my name is Peter"
},
"text": "Hi my name is Peter",
diff --git a/data/test_endpoints/event_brokers/file_endpoint.yml b/data/test_endpoints/event_brokers/file_endpoint.yml
deleted file mode 100644
index 13c7002f397e..000000000000
--- a/data/test_endpoints/event_brokers/file_endpoint.yml
+++ /dev/null
@@ -1,3 +0,0 @@
-event_broker:
- path: "rasa_event.log"
- type: file
diff --git a/data/test_multi_domain/config.yml b/data/test_multi_domain/config.yml
index 61e0b5b7133b..dba37fe301bd 100644
--- a/data/test_multi_domain/config.yml
+++ b/data/test_multi_domain/config.yml
@@ -1,17 +1,10 @@
language: en
pipeline:
- - name: SpacyNLP
- - name: SpacyTokenizer
- - name: SpacyFeaturizer
- - name: RegexFeaturizer
- - name: CRFEntityExtractor
- - name: EntitySynonymMapper
- - name: SklearnIntentClassifier
+ - name: "KeywordIntentClassifier"
policies:
- name: MemoizationPolicy
- - name: TEDPolicy
importers:
- name: MultiProjectImporter
diff --git a/data/test_trackers/tracker_moodbot.json b/data/test_trackers/tracker_moodbot.json
index 4103cedf0f66..634047470629 100644
--- a/data/test_trackers/tracker_moodbot.json
+++ b/data/test_trackers/tracker_moodbot.json
@@ -5,6 +5,8 @@
"confidence": 0.60,
"name": "mood_great"
},
+ "message_id": null,
+ "metadata": {},
"text": "/mood_great",
"intent_ranking": [
{
@@ -46,6 +48,8 @@
"confidence": 0.54,
"name": "greet"
},
+ "message_id": null,
+ "metadata": {},
"text": "/greet",
"intent_ranking": [
{
@@ -89,6 +93,8 @@
"confidence": 0.60,
"name": "mood_great"
},
+ "message_id": null,
+ "metadata": {},
"text": "/mood_great",
"intent_ranking": [
{
diff --git a/docs/docs/business-logic.mdx b/docs/docs/business-logic.mdx
index ebc006fd2447..79c187fb6f27 100644
--- a/docs/docs/business-logic.mdx
+++ b/docs/docs/business-logic.mdx
@@ -292,7 +292,7 @@ Here's a minimal checklist of files we modified to handle business logic using a
* `actions.py`: Define the form action, including the `required_slots`, `slot_mappings` and `submit` methods
-* `data/nlu.md`:
+* `data/nlu.yml`:
* Add examples for an intent to activate the form
@@ -308,7 +308,7 @@ Here's a minimal checklist of files we modified to handle business logic using a
* Add all intents and entities from your NLU training data
-* `data/stories.md`: Add a story for the form
+* `data/stories.yml`: Add a story for the form
* `config.yml`:
diff --git a/docs/docs/chitchat-faqs.mdx b/docs/docs/chitchat-faqs.mdx
index 53904b852f2d..0cb89973bbe2 100644
--- a/docs/docs/chitchat-faqs.mdx
+++ b/docs/docs/chitchat-faqs.mdx
@@ -6,109 +6,71 @@ title: Chitchat and FAQs
import useBaseUrl from '@docusaurus/useBaseUrl';
-
-
-After following the basics of [prototyping an assistant](./prototype-an-assistant.mdx), we'll
-now walk through building a basic FAQ chatbot and then build a bot that can handle
-contextual conversations.
-
-
-
FAQ assistants are the simplest assistants to build and a good place to get started.
-These assistants allow the user to ask a simple question and get a response. We're going to
-build a basic FAQ assistant using features of Rasa designed specifically for this type of assistant.
+These assistants allow the user to ask a simple question and get a response. You're
+going to build a basic FAQ assistant using features of Rasa designed specifically
+for this type of assistant. You can handle chitchat in the same way.
-In this section we're going to cover the following topics:
+In this section you will read about the following topics:
-* [Responding to simple intents](./chitchat-faqs.mdx#respond-with-memoization-policy) with the MemoizationPolicy
+* [Responding to simple messages](./chitchat-faqs.mdx#responding-to-simple-messages)
+ with the `MemoizationPolicy`
-* [Handling FAQs](./chitchat-faqs.mdx#faqs-response-selector) using the ResponseSelector
+* [Handling FAQs](./chitchat-faqs.mdx#handling-faqs-using-a-response-selector)
+ using a `ResponseSelector`
-We're going to use content from [Sara](https://github.com/RasaHQ/rasa-demo), the Rasa
-assistant that, amongst other things, helps the user get started with the Rasa products.
-You should [first install Rasa](installation.mdx)
-and then [prototype an assistant](prototype-an-assistant.mdx)
-to make sure you know the basics.
+## Prerequisites
-To prepare for this tutorial, we're going to start a new Rasa project:
+You should [first install Rasa](installation.mdx) and
+[prototype an assistant](prototype-an-assistant.mdx) to make sure
+you understand the basic concepts of intents, stories and domains.
+
+For this tutorial, you can create a new Rasa project using the CLI:
```bash
rasa init
```
-Let's remove the default content from this bot, so that the `data/nlu.yml`, `data/stories.yml`
-and `domain.yml` files are empty.
+If you want to start from scratch, you should remove the default content from
+the `data/nlu.yml`, `data/stories.yml` and `domain.yml` files.
+
+## Responding to simple messages
-
+Responding to single messages requires the assistant to recognize the message and
+trigger a response.
-## Memoization Policy
+Rasa Open Source uses what is called a `MemoizationPolicy` to
+predict what it needs to do once it receives such a message.
-The MemoizationPolicy remembers examples from training stories for up to a `max_history`
-of turns. One “turn” includes the message sent by the user and any actions the
-assistant performed before waiting for the next message. For the purpose of a simple,
-context-less FAQ bot, we only need to pay attention to the last message the user sent,
-and therefore we'll set that to `1`.
+:::note MemoizationPolicy
+If the `policies` key in your `config.py` is empty (or only contains
+comments) the `MemoizationPolicy` will be added automatically using
+[config suggestions](model-configuration.mdx#suggested-config).
+You do not need to do configure any policies.
-You can do this by editing your configuration file as follows
-(you can remove `TEDPolicy` for now):
+If you customized your `policies`, you need to make sure the
+[Memoization Policy](policies.mdx#memoization-policy)
+is part of your configuration:
-```yaml title="config.yml"
+```yaml-rasa title="config.yml"
policies:
- name: MemoizationPolicy
max_history: 1
-- name: MappingPolicy
-```
-
-:::note MappingPolicy
-The `MappingPolicy` is there because it handles the logic of the `/restart` intent,
-which allows you to clear the conversation history and start fresh.
-
-:::
-
-Now that we've defined our policies, we can add some stories for the `goodbye`, `thank` and `greet`
-intents to our stories:
-
-```yaml title="data/stories.yml"
-stories:
-- story: greet # name of the story
- steps:
- - intent: greet # intent of the user message
- - action: utter_greet # reaction of the bot
-
-- story: thank
- steps:
- - intent: thank
- - action: utter_noworries
-
-- story: goodbye
- steps:
- - intent: bye
- - action: utter_bye
+# ... your other policies
```
-We'll also need to add the intents, actions and responses to our domain:
-
-```yml title="domain.yml"
-intents:
- - greet
- - bye
- - thank
-
-responses:
- utter_noworries:
- - text: No worries!
-
- utter_greet:
- - text: Hi
+:::
- utter_bye:
- - text: Bye!
-```
+### 1. Creating intents
-Finally, we'll copy over some user message training data from Sara to train our
-intents (more can be found [here](https://github.com/RasaHQ/rasa-demo/blob/master/data/nlu/nlu.md)):
+The first step is to define the messages you want the bot to handle. You can copy
+over some user message training data from Sara to train your
+intents. Sara is the Rasa assistant that helps users to get started with our
+Rasa products, you can find more training data to use in your projects
+[here](https://github.com/RasaHQ/rasa-demo/blob/master/data/nlu/nlu.md).
+Add the training data to your bot, you'll need to add it to the training data files:
```yaml-rasa title="data/nlu.yml"
nlu:
@@ -145,6 +107,58 @@ nlu:
- cheers
```
+### 2. Writing stories
+
+Now that you've defined your intents, you'll need to add some [stories](stories.mdx)
+for the `goodbye`, `thank` and `greet` intents.
+You can add the following stories to define how the bot will respond to the intents:
+
+```yaml-rasa title="data/stories.yml"
+stories:
+
+- story: greet # name of the story
+ steps:
+ - intent: greet # intent of the user message
+ - action: utter_greet # reaction of the bot
+
+- story: thank
+ steps:
+ - intent: thank
+ - action: utter_noworries
+
+- story: goodbye
+ steps:
+ - intent: bye
+ - action: utter_bye
+```
+
+:::note Lots of intents
+Do you have lots of intents that you want to respond to? In that case you should
+check out [Handling FAQs](./chitchat-faqs.mdx#handling-faqs-using-a-response-selector).
+You'll avoid the need to specify one story for each of your intents.
+:::
+
+You'll need to tie all these pieces together by adding the intents, actions
+and responses to our [domain](domain.mdx):
+
+```yaml-rasa title="domain.yml"
+intents:
+- greet
+- bye
+- thank
+
+responses:
+ utter_noworries:
+ - text: No worries!
+
+ utter_greet:
+ - text: Hi
+
+ utter_bye:
+ - text: Bye!
+```
+
+### 3. Using the bot
You can now train a first model and test the bot, by running the following commands:
```bash
@@ -158,14 +172,18 @@ For example:
-While it's good to test the bot interactively, we should also add end to end test cases that
-can later be included as part of a [CI/CD system](./setting-up-ci-cd). End-to-end [test conversations](./testing-your-assistant#end-to-end-testing)
-include NLU data, so that both components of Rasa can be tested.
-The file `tests/conversation_tests.md` contains example test conversations. Delete all the test conversations and replace
-them with some test conversations for your assistant so far:
+### 4. Testing the bot
-```yaml title="tests/conversation_tests.yml"
-e2e_tests:
+While it's good to test the bot interactively, you should also add story tests that
+can later be included as part of a [CI/CD system](./setting-up-ci-cd).
+[Story tests](./testing-your-assistant#end-to-end-testing)
+include user messages, bot actions and responses. This ensures that
+the dialogue handling is tested as well as the message handling.
+The initial project already contains test conversations, you can replace
+them with some test conversations for your assistant:
+
+```yaml-rasa title="tests/test_stories.yml"
+stories:
- story: greet and goodybe
steps:
- user: |
@@ -204,36 +222,50 @@ e2e_tests:
- action: utter_bye
```
-To test our model against the test file, run the command:
+This test file contains three separate test stories. You can
+test your bot on all of them using `rasa test`:
```bash
-rasa test --stories tests/conversation_tests.yml
+rasa test --stories tests/test_stories.yml
```
-The test command will produce a directory named `results`. It should contain a file
+The test command will produce a directory named `results`. It will contain a file
called `failed_stories.yml`, where any test cases that failed will be printed. It will
also specify whether it was an NLU or Core prediction that went wrong. As part of a
CI/CD pipeline, the test option `--fail-on-prediction-errors` can be used to throw
-an exception that stops the pipeline.
+an exception that stops the pipeline:
+
+```bash
+rasa test --stories tests/test_stories.yml --fail-on-prediction-errors
+```
+
+## Handling FAQs using a Response Selector
-
+When you need to handle lots of different messages like FAQs or chitchat, the above
+approach using the `MemoizationPolicy` will become cumbersome. You will need to write
+one story for each of the different intents.
-## Response Selectors
+The [ResponseSelector](components/selectors.mdx#responseselector) is designed to
+make it easier to handle conversation patterns like small talk and FAQ messages.
+When you use the `ResponseSelector`, you only need one story to handle all FAQs,
+instead of adding one story for each intent.
-The [ResponseSelector](components/selectors.mdx#responseselector) NLU component
-is designed to make it easier to handle conversation patterns like small talk and
-FAQ messages in a simple manner. By using the `ResponseSelector`, you only need one
-story to handle all FAQs, instead of adding new stories every time you want to
-increase your bot's scope.
+:::note More details on the Response Selector
+
+This walk through shows you how to use the response selector. If you want to know
+more about how it works under the hood, head over to this [blog post](https://blog.rasa.com/response-retrieval-models/) and the
+[Retrieval Actions](./retrieval-actions.mdx) page.
+:::
+
+### 1. Creating intents
People often ask Sara different questions surrounding the Rasa products, so let's
start with three intents: `ask_channels`, `ask_languages`, and `ask_rasax`.
-We're going to copy over some user messages from the
-[Sara training data](https://github.com/RasaHQ/rasa-demo/blob/master/data/nlu/nlu.md)
-into our training data. It's important that these intents have an `faq/` prefix, so
-they're recognized as the faq intent by the `ResponseSelector`:
-```yml title="data/nlu.yml"
+Similar to the `MemoizationPolicy`, you'll need to define the intents and add some
+training data for them:
+
+```yaml-rasa title="data/nlu.yml"
nlu:
- intent: faq/ask_channels
examples: |
@@ -260,11 +292,19 @@ nlu:
- Tell me about rasa x
- tell me what is rasa x
```
+:::info FAQ/ prefix
+It's important that these intents have a common prefix that is separated by a `/`.
+E.g. in the above example, all intents share the `faq/` prefix. This is necessary
+for the intents to be recognized by the `ResponseSelector`.
-Next, we'll need to define the responses associated with these FAQs in a new
+:::
+
+### 2. Creating responses
+
+Next, you'll need to define the responses associated with these FAQs in a new
file:
-```yaml title="data/responses.yml"
+```yaml-rasa title="data/responses.yml"
responses:
faq/ask_channels:
- text: |
@@ -279,9 +319,11 @@ responses:
- text: "Rasa X is a tool to learn from real conversations and improve your assistant. Read more [here](https://rasa.com/docs/rasa-x/)"
```
+### 3. Configuring the bot
+
The `ResponseSelector` should already be at the end of your pipeline configuration:
-```yaml title="config.yml" {14-15}
+```yaml-rasa title="config.yml" {14-15}
language: en
pipeline:
- name: WhitespaceTokenizer
@@ -303,7 +345,7 @@ Now that we've defined the message handling side, we need to make
the dialogue handling parts aware of these changes. First, we need to add the
new intents to our domain:
-```yaml title="domain.yml"
+```yaml-rasa title="domain.yml"
intents:
- greet
- bye
@@ -316,14 +358,14 @@ which takes care of sending the response predicted from the `ResponseSelector`
back to the user, to the list of actions. These actions always have to start
with the `respond_` prefix:
-```yaml title="domain.yml"
+```yaml-rasa title="domain.yml"
actions:
- respond_faq
```
Next we'll write a story so that the dialogue engine knows which action to predict:
-```yml title="data/stories.yml"
+```yaml-rasa title="data/stories.yml"
stories:
- story: Some question from FAQ
steps:
@@ -333,6 +375,8 @@ stories:
This prediction is handled by the `MemoizationPolicy`, as we described earlier.
+### 4. Using the bot
+
After all of the changes are done, train a new model and test the modified FAQs:
```bash
@@ -340,10 +384,12 @@ rasa train
rasa shell
```
+### 5. Testing the bot
+
At this stage it makes sense to add a few test cases for our conversations:
-```yaml title="tests/conversation_tests.yml"
-e2e_tests:
+```yaml-rasa title="tests/test_stories.yml"
+stories:
- story: ask channels
steps:
- user: |
@@ -365,25 +411,20 @@ e2e_tests:
intent: faq
- action: respond_faq
```
-
-You can read more in this [blog post](https://blog.rasa.com/response-retrieval-models/) and the
-[Retrieval Actions](./retrieval-actions.mdx) page.
+### Response Selector Checklist
Using the features we described in this tutorial, you can easily build a context-less assistant.
-:::note Checklist
-Here's a minimal checklist of files we modified to build a basic FAQ assistant:
+Here's a **minimal checklist of files you need to modify** to build a basic FAQ assistant:
-* `data/nlu.yml`: Add NLU training data for `faq/` intents
+* `data/nlu.yml`: Add user message training data for `faq/` intents
* `data/responses.yml`: Add responses associated with `faq/` intents
* `config.yml`: Add `ResponseSelector` in your NLU pipeline
-* `domain.yml`: Add a retrieval action `respond_faq` and intent `faq`
+* `domain.yml`: Add a retrieval action `respond_faq` and the intent `faq`
* `data/stories.yml`: Add a simple story for FAQs
-* `tests/conversation_tests.yml`: Add E2E test stories for your FAQs
-
-:::
+* `tests/test_stories.yml`: Add E2E test stories for your FAQs
diff --git a/docs/docs/command-line-interface.mdx b/docs/docs/command-line-interface.mdx
index afe619ba1fb2..4ece80398364 100644
--- a/docs/docs/command-line-interface.mdx
+++ b/docs/docs/command-line-interface.mdx
@@ -25,7 +25,7 @@ The command line interface (CLI) gives you easy-to-remember commands for common
|`rasa x` |Launch Rasa X locally. |
|`rasa -h` |Shows all available commands. |
-## Create a new project
+## rasa init
A single command sets up a complete project for you with some example training data.
@@ -42,14 +42,14 @@ This creates the following files:
├── config.yml
├── credentials.yml
├── data
-│ ├── nlu.md
-│ └── stories.md
+│ ├── nlu.yml
+│ └── stories.yml
├── domain.yml
├── endpoints.yml
├── models
│ └── .tar.gz
└── tests
- └── conversation_tests.md
+ └── test_stories.yml
```
The `rasa init` command will ask you if you want to train an initial model using this data.
@@ -59,7 +59,7 @@ With this project setup, common commands are very easy to remember.
To train a model, type `rasa train`, to talk to your model on the command line, `rasa shell`,
to test your model type `rasa test`.
-## Train a Model
+## rasa train
The main command is:
@@ -87,7 +87,7 @@ If training data for only one model type is present, the command automatically f
:::
-## Interactive Learning
+## rasa interactive
To start an interactive learning session with your assistant, run
@@ -114,9 +114,10 @@ The full list of arguments that can be set for `rasa interactive` is:
```text [rasa interactive --help]
```
-## Talk to your Assistant
+## rasa shell
-To start a chat session with your assistant on the command line, run:
+This command allows you to talk to your assistant. To start a chat session
+with your assistant on the command line, run:
```bash
rasa shell
@@ -149,7 +150,7 @@ The full list of options for `rasa shell` is:
```text [rasa shell --help]
```
-## Start a Server
+## rasa run
To start a server running your Rasa model, run:
@@ -175,7 +176,7 @@ The following arguments can be used to configure your Rasa server:
For more information on the additional parameters, see [Model Storage](./model-storage.mdx).
See the Rasa [HTTP API](./http-api.mdx) docs for detailed documentation of all the endpoints.
-## Start an Action Server
+## rasa run actions
To run your action server run
@@ -188,7 +189,7 @@ The following arguments can be used to adapt the server settings:
```text [rasa run actions --help]
```
-## Visualize your Stories
+## rasa visualize
To open a browser tab with a graph showing your stories:
@@ -204,7 +205,7 @@ Additional arguments are:
```text [rasa visualize --help]
```
-## Evaluating a Model on Test Data
+## rasa test
To evaluate your model on test data, run:
@@ -212,23 +213,38 @@ To evaluate your model on test data, run:
rasa test
```
-Specify the model to test using `--model`.
-Check out more details in [Evaluating an NLU Model](./testing-your-assistant.mdx#evaluating-an-nlu-model) and [Evaluating a Core Model](./testing-your-assistant.mdx#evaluating-a-core-model).
+Specify the model to test using `--model`. The above command will test your model
+end-to-end using test stories. You can evaluate the dialogue and nlu
+model separately using
+```bash
+rasa test core
+```
+and
+
+```bash
+rasa test nlu
+```
+
+Check out more details in
+[Evaluating an NLU Model](./testing-your-assistant.mdx#evaluating-an-nlu-model) and
+[Evaluating a Core Model](./testing-your-assistant.mdx#evaluating-a-core-model).
The following arguments are available for `rasa test`:
```text [rasa test --help]
```
-## Create a Train-Test Split
+## rasa data split
-To create a split of your NLU data, run:
+This commands allows you to create a train-test split of your training data. To
+create a split of your NLU data, run:
```bash
rasa data split nlu
```
-You can specify the training data, the fraction, and the output directory using the following arguments:
+You can specify the training data, the fraction, and the output directory using
+the following arguments:
```text [rasa data split nlu --help]
```
@@ -239,14 +255,25 @@ If you have NLG data for retrieval actions, this will be saved to seperate files
```bash
ls train_test_split
- nlg_test_data.md test_data.json
- nlg_training_data.md training_data.json
+ nlg_test_data.yml test_data.json
+ nlg_training_data.yml training_data.json
```
-## Convert Data Between Markdown and JSON
+## rasa data convert
+
+You cam convert NLU data from
+- LUIS data format,
+- WIT data format,
+- Dialogflow data format,
+- JSON, or
+- Markdown
+
+to
+- YAML or
+- JSON or
+- Markdown.
-To convert NLU data from LUIS data format, WIT data format, Dialogflow data format, JSON, or Markdown
-to JSON or Markdown, run:
+You can start the converter by running:
```bash
rasa data convert nlu
@@ -257,7 +284,7 @@ You can specify the input file, output file, and the output format with the foll
```text [rasa data convert nlu --help]
```
-## Export Conversations to an Event Broker
+## rasa export
To export events from a tracker store using an event broker, run:
@@ -272,7 +299,7 @@ should be published.
```text [rasa export --help]
```
-## Start Rasa X
+## rasa x
Rasa X is a toolset that helps you leverage conversations to improve your assistant.
You can find more information about it here.You can start Rasa X locally by executing
@@ -282,7 +309,9 @@ rasa x
```
To be able to start Rasa X you need to have Rasa X local mode installed
-and you need to be in a Rasa project.:::note
+and you need to be in a Rasa project.
+
+:::note
By default Rasa X runs on the port 5002. Using the argument `--rasa-x-port` allows you to change it to
any other port.
diff --git a/docs/docs/fallback-handoff.mdx b/docs/docs/fallback-handoff.mdx
index bbc03e94495f..3bfa2509e647 100644
--- a/docs/docs/fallback-handoff.mdx
+++ b/docs/docs/fallback-handoff.mdx
@@ -285,11 +285,11 @@ let's say the user asks “I want to apply for a job at Rasa”, we can then rep
:::note
Here's a minimal checklist of files we modified to help our assistant fail gracefully:
-* `data/nlu.md`:
+* `data/nlu.yml`:
* Add training data for the `out_of_scope` intent & any specific out of scope intents that you want to handle seperately
-* `data/stories.md`:
+* `data/stories.yml`:
* Add stories for any specific out of scope intents
diff --git a/docs/docs/jupyter-notebooks.mdx b/docs/docs/jupyter-notebooks.mdx
index 5b0b86e68861..2b5d20c09a5f 100644
--- a/docs/docs/jupyter-notebooks.mdx
+++ b/docs/docs/jupyter-notebooks.mdx
@@ -82,7 +82,8 @@ The return values are the paths to these newly created directories.
```bash
import rasa.data as data
-stories_directory, nlu_data_directory = data.get_core_nlu_directories(training_files)
+nlu_data_directory = data.get_data_directories(training_files, data.is_nlu_file)
+stories_directory = data.get_data_directories(training_files, data.is_story_file)
print(stories_directory, nlu_data_directory)
```
To test your model, call the `test` function, passing in the path
@@ -108,5 +109,5 @@ else:
if os.path.isdir("results"):
print("\n")
print("Core Errors:")
- print(open("results/failed_stories.md").read())
+ print(open("results/failed_test_stories.yml").read())
```
diff --git a/docs/docs/policies.mdx b/docs/docs/policies.mdx
index 53b9bb53f1c3..9787693f8c3b 100644
--- a/docs/docs/policies.mdx
+++ b/docs/docs/policies.mdx
@@ -384,10 +384,25 @@ a fixed behavior. Please see [Rules](./rules.mdx) for further information.
## Memoization Policy
-The `MemoizationPolicy` just memorizes the conversations in your
-training data. It predicts the next action with confidence `1.0`
-if this exact conversation exists in the training data, otherwise it
-predicts `None` with confidence `0.0`.
+The `MemoizationPolicy` remembers the stories from your
+training data. It checks if the current conversation matches a story
+in the training data. If so, it will predict the next action from the matching
+story of your training data with a confidence of `1.0`. If no matching conversation
+is found, the policy predicts `None` with confidence `0.0`.
+
+When looking for a match in your training data, the policy will take the last
+`max_history` number of turns of the conversation into account.
+One “turn” includes the message sent by the user and any actions the
+assistant performed before waiting for the next message.
+
+You can configure the number of turns the `MemoizationPolicy` should use in your
+configuration:
+```yaml title="config.yml"
+policies:
+ - name: "MemoizationPolicy"
+ max_history: 3
+```
+
## Augmented Memoization Policy
diff --git a/docs/docs/setting-up-ci-cd.mdx b/docs/docs/setting-up-ci-cd.mdx
index 960fbec395ce..4dbb1f8e9294 100644
--- a/docs/docs/setting-up-ci-cd.mdx
+++ b/docs/docs/setting-up-ci-cd.mdx
@@ -93,7 +93,7 @@ important as you start introducing more complicated stories from user
conversations.
```bash
-rasa test --stories tests/conversation_tests.md --fail-on-prediction-errors
+rasa test --stories tests/test_stories.yml --fail-on-prediction-errors
```
The `--fail-on-prediction-errors` flag ensures the test will fail if any test
@@ -106,7 +106,7 @@ to be representative of the true distribution of real conversations.
Rasa X makes it easy to [add test conversations based on real conversations](https://rasa.com/docs/rasa-x/user-guide/test-assistant/#how-to-create-tests).
Note: End-to-end testing does **not** execute your action code. You will need to
-[test your action code](./setting-up-ci-cd.mdx#testing-action-code) in a seperate step.
+[test your action code](./setting-up-ci-cd.mdx#testing-action-code) in a separate step.
### Compare NLU Performance
diff --git a/docs/docs/testing-your-assistant.mdx b/docs/docs/testing-your-assistant.mdx
index 2e581c34bdb3..3ba4df183f73 100644
--- a/docs/docs/testing-your-assistant.mdx
+++ b/docs/docs/testing-your-assistant.mdx
@@ -7,31 +7,35 @@ description: Test your Rasa Open Source assistant to validate and improve your c
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
+Rasa Open Source lets you test dialogues end-to-end by running through
+test stories. The test makes sure that user messages are processed correctly
+and the dialogue predictions are correct. In addition to end-to-end tests, you can
+also test the dialogue handling (core) and the message processing (nlu)
+separately.
+
:::note
If you are looking to tune the hyperparameters of your NLU model,
check out this [tutorial](https://blog.rasa.com/rasa-nlu-in-depth-part-3-hyperparameters/).
:::
-
## End-to-End Testing
-Rasa Open Source lets you test dialogues end-to-end by running through
-test conversations and making sure that both NLU and Core make correct predictions.
+Testing your assistant requires you to write test stories, which include
+the user messages and the conversation history. The format is the same as the one
+used to specify stories in your training data.
-To do this, you need some stories in the end-to-end format,
-which includes both the NLU output and the original text.
Here are some examples:
- ```yaml-rasa
- e2e_tests:
+ ```yaml-rasa title="tests/test_stories.yml"
+ stories:
- story: A basic end-to-end test
steps:
- user: |
- hey
+ hello
intent: greet
- action: utter_ask_howcanhelp
- user: |
@@ -39,41 +43,41 @@ Here are some examples:
intent: inform
- action: utter_ask_location
- user: |
- in [Paris]{"entity": "location"}
+ in [Paris]{"entity": "location"}
intent: inform
- action: utter_ask_price
```
-
- ```yaml-rasa
- e2e_tests:
- - story: A test where a custom action returns events
+
+ ```yaml-rasa title="tests/test_stories.yml"
+ stories:
+ - story: A test where a custom action returns events
steps:
- user: |
- hey
+ hey
intent: greet
- action: my_custom_action
- slot_was_set:
- - my_slot: "value added by custom action"
- - action:
- - utter_ask_age
+ - my_slot: "value added by custom action"
+ - action: utter_ask_age
- user: |
- thanks
+ thanks
intent: thankyou
- action: utter_no_worries
```
+
-
- ```yaml-rasa
- e2e_tests:
+
+ ```yaml-rasa title="tests/test_stories.yml"
+ stories:
- story: A test conversation with a form
steps:
- user: |
- hi
+ hi
intent: greet
- action: utter_greet
- user: |
@@ -82,41 +86,41 @@ Here are some examples:
- action: restaurant_form
- active_loop: restaurant_form
- user: |
- [afghan](cuisine) food
+ [afghan](cuisine) food
intent: inform
- action: restaurant_form
- active_loop: null
- action: utter_slots_values
- user: |
- thanks
+ thanks
intent: thankyou
- action: utter_no_worries
```
-
- ```yaml-rasa
- e2e_tests:
+
+ ```yaml-rasa title="tests/test_stories.yml"
+ stories:
- story: A test conversation with unexpected input during a form
steps:
- user: |
- hi
+ hi
intent: greet
- action: utter_greet
- user: |
- im looking for a restaurant
+ im looking for a restaurant
intent: request_restaurant
- action: restaurant_form
- active_loop: restaurant_form
- user: |
- can you share your boss with me?
+ can you share your boss with me?
- action: utter_chitchat
- action: restaurant_form
- active_loop: null
- action: utter_slots_values
- user: |
- thanks
+ thanks
intent: thankyou
- action: utter_no_worries
```
@@ -124,34 +128,30 @@ Here are some examples:
-By default Rasa Open Source saves conversation tests to `tests/conversation_tests.md`.
+By default Rasa Open Source saves conversation tests to `tests/test_stories.yml`.
You can test your assistant against them by running:
```bash
rasa test
```
-:::note
-[Custom Actions](./actions.mdx#custom-actions) are **not executed as part of end-to-end tests.** If your custom
-actions append any events to the tracker, this has to be reflected in your end-to-end
-tests (e.g. by adding `slot` events to your end-to-end story).
+The command will always load all stories from any story files, where the file
+name starts with `test_`, e.g. `test_stories.yml`. Your story test
+file names should always start with `test_` for this detection to work.
-To test your custom actions, write unit tests for them and include these
-tests in your CI/CD pipeline.
+:::info Custom Actions
+[Custom Actions](./custom-actions.mdx) are **not executed as part of end-to-end tests.** If your custom
+actions append any events to the conversation, this has to be reflected in your end-to-end
+tests (e.g. by adding `slot_was_set` events to your end-to-end story).
+
+If you want to test the code of your custom actions, you should write unit tests
+for them and include these tests in your CI/CD pipeline.
:::
If you have any questions or problems, please share them with us in the dedicated
[testing section on our forum](https://forum.rasa.com/tags/testing) !
-:::note
-Make sure your model file in `models` is a combined `core`
-and `nlu` model. If it does not contain an NLU model, Core will use
-the default `RegexInterpreter`.
-
-:::
-
-
## Evaluating an NLU Model
A standard technique in machine learning is to keep some data separate as a *test set*.
@@ -162,10 +162,11 @@ into train and test sets using:
rasa data split nlu
```
-If you've done this, you can see how well your NLU model predicts the test cases using this command:
+If you've done this, you can see how well your NLU model predicts the
+test cases:
```bash
-rasa test nlu -u train_test_split/test_data.md --model models/nlu-20180323-145833.tar.gz
+rasa test nlu --nlu train_test_split/test_data.yml
```
If you don't want to create a separate test set, you can
@@ -173,13 +174,11 @@ still estimate how well your model generalises using cross-validation.
To do this, add the flag `--cross-validation`:
```bash
-rasa test nlu -u data/nlu.md --config config.yml --cross-validation
+rasa test nlu --nlu data/nlu.yml --cross-validation
```
-The full list of options for the script is:
-
-```text [rasa test nlu --help]
-```
+You can find the full list of options in the
+[CLI documentation on rasa test](command-line-interface.mdx#rasa-test)
### Comparing NLU Pipelines
@@ -188,7 +187,7 @@ a comparative examination between the pipelines.
```bash
rasa test nlu --config pretrained_embeddings_spacy.yml supervised_embeddings.yml
- --nlu data/nlu.md --runs 3 --percentages 0 25 50 70 90
+ --nlu data/nlu.yml --runs 3 --percentages 0 25 50 70 90
```
The command in the example above will create a train/test split from your data,
@@ -278,10 +277,10 @@ You can evaluate your trained model on a set of test stories
by using the evaluate script:
```bash
-rasa test core --stories test_stories.md --out results
+rasa test core --stories test_stories.yml --out results
```
-This will print the failed stories to `results/failed_stories.md`.
+This will print the failed stories to `results/failed_test_stories.yml`.
We count any story as failed if at least one of the actions
was predicted incorrectly.
diff --git a/docs/docs/training-data-format.mdx b/docs/docs/training-data-format.mdx
index 74476a4484a9..0c66a2e0133b 100644
--- a/docs/docs/training-data-format.mdx
+++ b/docs/docs/training-data-format.mdx
@@ -57,6 +57,18 @@ Here's a short example which keeps all training data in a single file:
```yaml-rasa
version: "2.0"
+nlu:
+- intent: greet
+ examples: |
+ - Hey
+ - Hi
+ - hey there [Sara](name)
+
+- intent: faq/language
+ examples: |
+ - What language do you speak?
+ - Do you only handle english?
+
stories:
- story: greet and faq
steps:
@@ -71,21 +83,13 @@ rules:
- intent: greet
- action: utter_greet
-nlu:
-- intent: greet
- examples: |
- - Hey
- - Hi
- - hey there [Sara](name)
-
-- intent: faq/language
- examples: |
- - What language do you speak?
- - Do you only handle english?
+```
-e2e_tests:
+If you want to specify your test stories, you need to put them into a separate file:
+```yaml-rasa title="tests/test_stories.yml"
+stories:
- story: greet and ask language
-- steps:
+- steps:
- user: |
hey
intent: greet
@@ -95,7 +99,7 @@ e2e_tests:
intent: faq/language
- action: respond_faq
```
-
+They use the same format as the story training data.
## NLU Training Data
@@ -103,7 +107,7 @@ e2e_tests:
**intent**, i.e. what the user is trying to convey or accomplish with their
message. Training examples can also include **entities**. Entities are structured
pieces of information that can be extracted from a user's message. You can also
-add extra information such as regular expressions and lookup tables to your
+add extra information such as regular expressions and lookup tables to your
training data to help the model identify intents and entities correctly.
NLU training data is defined under the `nlu` key. Items that can be added under this key are:
@@ -122,7 +126,7 @@ nlu:
- [Synonyms](#synonyms)
```yaml-rasa
-nlu:
+nlu:
- synonym: credit
examples: |
- credit card account
@@ -169,7 +173,7 @@ However, it's also possible to use an extended format if you have a custom NLU c
```yaml-rasa
nlu:
- intent: greet
- examples:
+ examples:
- text: |
hi
metadata:
@@ -178,14 +182,14 @@ nlu:
hey there!
```
-The `metadata` key can contain arbitrary key-value data that stays with an example and is accessible by the components in the NLU pipeline. In the example above, the sentiment of
+The `metadata` key can contain arbitrary key-value data that stays with an example and is accessible by the components in the NLU pipeline. In the example above, the sentiment of
the example could be used by a custom component in the pipeline for sentiment analysis.
### Entities
[Entities](glossary.mdx#entity) are structured pieces of information that can be extracted from a user's message. For entity extraction to work, you need to either specify training data to train an ML model or you need to define [regular expressions](#regular-expressions-for-entity-extraction) to extract entities using the [`RegexEntityExtractor`](components/entity-extractors.mdx#regexentityextractor) based on a character pattern.
-Entities are annotated in training examples with minimally the entity's name.
+Entities are annotated in training examples with minimally the entity's name.
In addition to the entity name, you can annotate an entity with synonyms, roles, or groups.
In training examples, entity annotation would look like this:
@@ -200,7 +204,7 @@ nlu:
```
-The full possible syntax for annotating an entity is:
+The full possible syntax for annotating an entity is:
```text
[]{"entity": "", "role": "", "group": "", "value": ""}
@@ -243,7 +247,7 @@ pipeline in your configuration file contains the
should define synonyms when there are multiple ways users refer to the same
thing.
-#### Example
+#### Example
Let's say you had an entity `account`, and you expect the
value "credit". Your users also refer to their "credit" account as "credit
@@ -264,16 +268,16 @@ recognize these as entities and replace them with `credit`.
### Regular Expressions
-You can use regular expressions to improve intent classification and
+You can use regular expressions to improve intent classification and
entity extraction in combination with the [`RegexFeaturizer`](components/featurizers.mdx#regexfeaturizer) and [`RegexEntityExtractor`](components/entity-extractors.mdx#regexentityextractor) components in the pipeline.
-#### Regular Expressions for Intent Classification
+#### Regular Expressions for Intent Classification
-You can use regular expressions to improve intent classification by including the `RegexFeaturizer` component in your pipeline. When using the `RegexFeaturizer`, a regex does not act as a rule for classifying an intent. It only provides a feature that the intent classifier will use
+You can use regular expressions to improve intent classification by including the `RegexFeaturizer` component in your pipeline. When using the `RegexFeaturizer`, a regex does not act as a rule for classifying an intent. It only provides a feature that the intent classifier will use
to learn patterns for intent classification.
-Currently, all intent classifiers make use of available regex features.
+Currently, all intent classifiers make use of available regex features.
-The name of a regex in this case is a human readable description. It can help you remember what a regex is used for, and it is the title of the corresponding pattern feature. It does not have to match any intent or entity name. A regex for greeting might look like this:
+The name of a regex in this case is a human readable description. It can help you remember what a regex is used for, and it is the title of the corresponding pattern feature. It does not have to match any intent or entity name. A regex for greeting might look like this:
```yaml-rasa
nlu:
@@ -303,7 +307,7 @@ If your entity has a deterministic structure (like an account number), you can u
`DIETClassifier` component. Other entity extractors, like
`MitieEntityExtractor` or `SpacyEntityExtractor`, won't use the generated
features and their presence will not improve entity recognition for
- these extractors.
+ these extractors.
2. For rule-based entity extraction using the [`RegexEntityExtractor`](components/entity-extractors.mdx#regexentityextractor) component in the pipeline.
@@ -326,7 +330,7 @@ nlu:
When using the `RegexFeaturizer`, a regular expression only provides a feature
that helps the model learn an association between intents/entities and inputs
that fit the regular expression. In order for the model to learn this association,
-you must provide example inputs that include that regular expression!
+you must provide example inputs that include that regular expression!
:::
@@ -379,16 +383,16 @@ model. [**Stories**](stories.mdx) are used to train a machine learning model
to identify patterns in conversations and generalize to unseen conversation paths.
**[Rules](rules.mdx)** describe parts of conversations that should always
follow the same path and are used to train the
-[RulePolicy](policies.mdx#rule-policy).
+[RulePolicy](policies.mdx#rule-policy).
### Stories
Stories are composed of:
-
- - `story`: The story's name. The name is arbitrary and not used in training;
+
+ - `story`: The story's name. The name is arbitrary and not used in training;
you can use it as a human-readable reference for the story.
- - `metadata`: arbitrary and optional, not used in training,
+ - `metadata`: arbitrary and optional, not used in training,
you can use it to store relevant information about the story
like e.g. the author
- a list of `steps`: The user messages and actions that make up the story
@@ -431,7 +435,7 @@ messages the users can send to mean the same thing.
User messages follow the format:
```yaml-rasa
-stories:
+stories:
- story: user message structure
steps:
- intent: intent_name # Required
@@ -505,8 +509,8 @@ A [form](glossary.mdx#form) is a specific kind of custom action that contains th
a set of required slots and ask the user for this information. You
[define a form](forms.mdx#defining-a-form) in the `forms` section in your domain.
Once defined, the [happy path](glossary.mdx#happy-unhappy-paths)
-for a form should be specified as a [rule](forms.mdx), but interruptions of forms or
-other "unhappy paths" should be included in stories so that the model can
+for a form should be specified as a [rule](forms.mdx), but interruptions of forms or
+other "unhappy paths" should be included in stories so that the model can
generalize to unseen conversation sequences.
As a step in a story, a form takes the following basic format:
@@ -527,10 +531,10 @@ The `action` step activates the form and begins looping over the required slots.
step indicates that there is a currently active form. Much like a `slot_was_set` step,
a `form` step doesn't **set** a form to active but indicates that it should already be activated.
In the same way, the `active_loop: null` step indicates that no form should be active before the subsequent
-steps are taken.
+steps are taken.
-A form can be interrupted and remain active; in this case the interruption should come after the
-`action: