Rasa for Content Creators

In this post, we'll zero in on the third pillar: content creation. Content creators contribute one of the most visible parts of an assistant: the personality, responses, and conversation flows. In order to bring the assistant to life, the content creator needs visibility into the work developers and data scientists are doing, and a toolset that allows them to manage the areas of the assistant they own.

We'll start by discussing how different roles typically collaborate on conversational AI teams and the touchpoints where content creators focus most of their energy. Then we'll discuss the conversational building blocks available to content creators through Rasa and how conversation-driven development can help content creators avoid unnecessary complexity and design conversation paths that reflect the way users behave in the real world.

What does a chatbot content creator do?

But before we dive in, let's establish our terminology. Job titles in the conversational AI space reflect the rapidly changing industry: new roles and titles appear all the time, and there is a lot of variety and specialization across teams who build chatbots and voice assistants. So what do we mean by 'content creator'?

When you browse job descriptions, Chatbot Content Creator might not be the exact title that pops up on listings. Content creator is an umbrella term: it includes conversation designers, subject matter experts, marketing managers, and product owners. Put simply, it's anyone who works on writing the responses the chatbot says and mapping out how the chatbot handles different scenarios. Importantly, the content creator's understanding of the market and the business allow them to translate business requirements into conversations that help the customer. They also ensure that the voice of the assistant fits the use case and the company brand.

To put the role into context, we need to think about how the work of content creators fits into the conversational AI team's work as a whole. So let's go back to our other two pillars: data science and engineering. We'll examine how the work of a content creator is different and how teams can work together where their responsibilities intersect.

Conversational AI teams and collaboration

If content creators are in charge of the look and feel of the assistant, data scientists and engineers are in charge of the underlying mechanisms that control the assistant's behavior. Data scientists primarily focus on the performance of the machine learning models, which control functionality through training data and algorithms, and software engineers who focus on custom actions and integrations, which control functionality through code. (If you want a closer look at conversational AI team roles, we've published an in-depth article.)

Each of the three pillars of building assistants influence the work of the others. A content creator might map out a conversation flow for an assistant, but the assistant needs to correctly interpret what the user says and predict the appropriate next action-that's where data scientists come in. And a conversation flow doesn't just consist of back and forth text; there are also system actions, backend requests, and checks that need to happen-that's where software engineers come in.

Depending on the team, these responsibilities might be crisply defined, or there can be overlap. It's not unusual for content creators to annotate training data in addition to managing responses. Data scientists and content creators often work together to analyze conversation patterns, identify opportunities to create new intents (or merge existing ones), and review incoming messages for phrases that would make good training data. Similarly, content creators and engineers often work together to identify which custom actions are needed to complete a transactional conversation flow.

If you're assembling a conversational AI team or optimizing an existing one, it's helpful to think about the touchpoints between the three pillars. In the next sections, we'll narrow the focus to the touchpoints that most concern the content creator, particularly the tools and workflows that content creators need to build conversation flows, from basic FAQs to complex contextual dialogues.

Conversation building blocks

Content creators have a few important building blocks at their disposal, which can be combined to create a nearly infinite number of conversation flows and scenarios. Let's start with 2 of the most basic: intents and responses.

Intents and responses

All user input is grouped into intents, which are labels that describe the user's meaning or goal. You might have a "login trouble" intent that contains all of the ways a user might express the need to reset their password or ask for help accessing their account, or even an "out of scope" intent that covers all of the topics the assistant hasn't been trained to help with. Intents represent the user's side of the conversation. When you look at the training data used to define intents, you'll see the intent label followed by several examples of how the user might express the intent.

- intent: login_trouble
examples: |
- i can't unlock my account
- help I can't log in
- how do I reset my password?
- I can't remember my password
- I can't access my account
- what's my password
- i've been trying to log in

On the other hand, responses are the bot's side of the conversation. Responses are the text the assistant sends back to the user. For example, if the "login trouble" intent were detected, we'd want to send some text that tells the user how to troubleshoot. This text is defined as a response template in a Rasa assistant. In the example below, we can tell this is a response template because the label starts with the prefix utter_.

  utter_login_help:
  - text: "I'm sorry to hear you're having trouble accessing your account. First, let's try the troubleshooting steps listed in the attached support article."

Using just intents and responses, you can cover quite a bit of ground. Many FAQ assistants rely on just these building blocks. But if you want to support a more transactional use case-for example, where the assistant checks the user's account status or takes an action on their behalf, like renewing an insurance policy-you'll need to add custom actions into the mix.

Custom actions

An action refers to anything the assistant does. Technically, a response is a type of action too, one that sends a piece of text back to the user. But actions can include things besides simple messages, including custom functions that do things like interact with backend systems and integrations. These types of actions, called custom actions, do the necessary tasks that make your assistant truly helpful to customers.

Let's consider an assistant for an insurance company. Custom actions could be used to access details from the customer's account, like their deductible and claim status, or to look up nearby service providers.

Even though custom actions are typically written by software engineers using Python, content creators are often the ones who use the custom actions to build out conversation flows. Once the custom action has been written by an engineer, a content creator only needs to know the name of the custom action and what it returns in order to use it in a conversation flow. If the custom action returns a value, it will be saved to a slot. The value of a slot can influence the conversation flow, and content creators can use conditional logic to specify what should happen next in the dialogue depending on a slot's value.

Turning back to the insurance example, when a customer asks the status of their claim, we want to run a backend check. Let's say a developer on the team has written a custom action called action_check_claim_status, which returns one of these possible slot values: pending, accepted, or rejected. Without diving into any Python code, a content creator can build out a conversation flow by referencing the name of the custom action and the slot value. In the snippet below, we've listed the steps taken by the user and the assistant by referencing the intent label, the response names (which start with utter_), the slot value, and the custom action name (which starts with action_). Of course, we'd want to list out a slightly different set of steps if the slot value returned was pending or rejected.

stories:
- story: Check claim status - approved
steps:
- intent: ask_claim_status
- action: utter_checking_status
- action: action_check_claim_status
- slot_was_set:
- claim_status: approved
- action: utter_status_approved

Designing dialogues

As we've just seen, dialogue elements can be stitched together to create conversation paths by listing out the steps that happen in the conversation. The example above, translated into plain text, would look something like this:

Customer: I was wondering about the status of my claim.

Bot: Certainly, one moment while I check for you

Bot: [runs backend check, which returns 'approved']

Bot: The status of your most recent claim is Approved. You can view the full details of your current and past claims [here].

The format used to define a conversation path is called a story. Stories usually consist of multiple turns, or back-and-forth exchanges, between the user and the assistant. This allows content creators to map out scenarios that depend on things that have happened earlier in the conversation.

In Rasa Open Source, stories are used as training data to help the dialogue management model learn which next action to take based on the examples it's seen. This has an important implication for content creators: because stories are training data, not hard-coded dialogues, Rasa Open Source has the ability to generalize, meaning it can predict the next best action, even if it hasn't seen the exact scenario before. If you've worked with platforms that map out every conversation path using flow charts, you know that things work fine until the user does something unexpected (or until things get complex, as you start adding more and more paths). That complexity, and the unpredictability of user input, is why we recommend designing paths based on past conversation data-which is the surest predictor of what users will do in the future.

Conversation-driven development

Content creators face a dilemma when it comes to designing conversation flows: how to account for the many, many possible conversation paths. And even then, users still do things that weren't anticipated.

The most reliable way to predict what users will say and do in the future is to look at what users have done in the past. Looking at past conversation data gives content creators an important edge when it comes to designing exceptional user experiences. Reviewing conversations, early user testing, and capturing real user messages to turn into training data are all part of a methodology called conversation-driven development: the practice of using insights from real users to influence the development of an assistant. You can read more about the 6 steps that make up conversation-driven development (CDD) on our blog.

For content creators practicing CDD and designing conversation flows, Rasa X is the tool where you'll spend most of your time. It's a browser-based UI that layers on top of a Rasa assistant to make it easier to sift through conversation data, manage responses, and share the assistant with test users. Instead of managing files via a text editor or conversations via spreadsheets, content creators can manage their parts of the assistant through an accessible UI.

Rasa X

Earlier we discussed four conversation building blocks: intents, responses, slots, and custom actions. And we introduced stories, the format that turns conversation building blocks into a dialogue. Through the Rasa X UI, content creators can access these building blocks to create stories, with built-in version control to keep track of changes over time.

One of the most important areas for content creators in Rasa X is the domain file. The domain file lists all of the building blocks a content creator has to work with. It includes the name of every intent, every response, every slot and its possible values, and the names of all of the custom actions that have been created by the development team-kind of like a menu of options for building out conversation flows.

Rasa X also provides easy access to the response text, allowing content creators to add new responses or edit existing ones. And when it comes to putting the building blocks together, Rasa X allows you to create stories by talking to the assistant via interactive learning. The interactive learning screen lets you see what the conversation will look like via a chat UI, with the option to correct any mistakes the assistant has made at the same time. When the dialogue looks correct, you can save the flow to the story format automatically.

Lastly, content creators can review the messages and conversations coming in from real users via the NLU inbox and conversation screen. It's hard to overstate the importance of this input for the content creator: real conversations are the best way to understand where users are getting confused or stuck and identify opportunities to improve. With a clear picture of what users are doing, content creators can make adjustments to response text and conversation flows to keep the user on the happy path and resolve their problems quickly.

Conclusion

Most business-critical AI assistants require the cooperation of multiple team members and skill sets: data scientists to supervise the machine learning model and developers to write custom functions and deploy changes to production. But it's the content creator who arguably has the most visible impact on the final product. The content creator makes sure the assistant is armed with the right knowledge, skills, and personality to meet the project's business goals.

Rasa Open Source and Rasa X offer a toolset where different roles across conversational AI teams can collaborate to build better AI assistants. If you want to practice some of the concepts we've discussed in this blog post, you can explore building a Rasa assistant without installing a thing using the Rasa Playground. The Playground is embedded in the Rasa docs and comes pre-loaded with a few simple conversational building blocks you can edit and experiment with. After you've made changes to the intents, responses, and stories, you can retrain the model and talk to your assistant to see the results.

Want to learn more? Check out some of the resources below for content creators, team collaboration, and conversation-driven development.

• Recipes for building conversational AI teams (Rasa blog)
• Building Scalable Chatbots by Empowering Content Creators (N26) - Rasa Developer Summit 2019 (YouTube)
• Rasa X - Introduction (Rasa docs)
• CDD Playbook (Rasa.com)
• Dev Portal (Rasa docs)