Flows

Video



When building your assistant, defining flows is crucial as they add the necessary business logic to ensure the assistant can complete user tasks efficiently. Flows help prevent LLM-based systems from hallucinating, which is vital in enterprise settings where accuracy is paramount.

Flows don’t represent entire conversations; instead, they define logical steps for specific situations, such as asking for more information or calling an API. This pairing with LLM-based dialogue systems allows for building user-goal-oriented assistants efficiently, without the need for extensive training data.

Flows are defined for specific scenarios where the assistant must follow a set sequence of steps. For example, when a user wants to open a bank account, the assistant should check the user's age before proceeding. This represents a simple flow.

Key components of a flow

Flows are defined in YAML files, such as flows.yml. Here are the key components of a flow:

  • id: A unique identifier for the flow.
  • name: An optional, human-readable name for the flow. It’s recommended to give flows short, descriptive names for clarity.
  • description: A brief explanation of what the flow does.
  • if: An optional condition, known as a flow guard, that determines whether the flow should start.
  • steps: A required list of steps the flow will execute.

An example

To better understand each flow components, let’s dive deeper into an actual example. Here we have an example of flows.yml file built for a financial services assistant. In the flows.yml example for a financial services assistant, there are three flows:

  • say_hello: Responds to the user’s greeting and steers the conversation towards collecting personal details.
  • collect_personal_details: Collects user details like first name, last name, and age, and initiates a process to check if the user is under a legal age limit.
  • age_limit: Checks if the user is 18 or older. If they are, the conversation continues; if not, it ends.

Flow descriptions

Each flow starts with a description, used by the Dialogue Understanding component to predict when the flow should begin. Accurate descriptions are crucial for optimal assistant performance.

Flow steps

The steps component includes different types of steps:

  • action step: Executes a custom action or utterance action immediately. For instance, the say_hello flow uses the action: "utter_greet" to respond right away.

  • collect step: Asks the user questions to fill a slot, halting progression until the slot is filled. The collect_personal_details flow includes steps to gather the user's first name, last name, and age.

    By default, if any of these slots are filled before the flow is triggered, the steps for collecting these slots will be skipped. However, this behaviour can be configured by adding ask_before_filling: true flag to a specific slot. In that case, the question to fill this slot will always be asked.

    Another thing about slots collected during the collect step. By default, the slots are automatically reset when the flow is complete. If you’d like to retain the slot values after the flow is complete, you can achieve that by adding a flag reset_after_flow_ends: false.

    You can also add slot validation using if/else statements just like it’s shown in the flow age_limit. Here, we are checking if the user is 18 or above. When validation fails, your assistant will automatically try to collect the information again. The assistant will repeatedly ask for the slot until the value is not rejected.

  • link step: Links to another flow, starting it at the end of the current one. This helps break down complex processes into manageable pieces.

  • set slots step: Sets or resets slots, often used when a specific action is needed based on user input. For example, resetting the amount_of_money slot if a user tries to send more money than they have.

Branching

Branching allows for advanced flows with different outcomes based on conditions. For instance, the age_limit flow checks if the user is 18 or older. You can define conditions to check specific slot values, such as:

For more sophisticated flows, namespaces allow access to specific data points from slots or current dialogue frame properties.

Starting flows

There are two main components to start flows:

  • LLMCommandGenerator: Uses flow descriptions, conversation context, and other factors to decide when to start a flow. Concise and descriptive descriptions are essential here.
  • NLUCommandAdapter: Uses a predicted intent to start a flow. This component is optional and relies on traditional NLU-based approaches, requiring specific intents to trigger flows.

In some cases, additional checks before starting a flow might be necessary. For example:

flows:
  show_latest_bill:
    if: "slots.authenticated AND slots.email_verified"
    steps:

The next section will dive deeper into the dialogue understanding components.

2016-2024 © Rasa.