Practical examples
The examples provided in this section showcase the effective utilization of the Gen AI cell in combined with other cells in the Dialog Manager.
This page is broadly descriptive, hence it's highly recommended refer to the following pages for further information about:
Rephrasing your answer
One of the capabilities offered by GenAI Cells is the generation of dynamic texts, such as rephrasing any given text with a hint of randomness. For example:
Add to the prompt a instruction such as: Rewrite the following sentence in a positive, reinforcing tone: "<Your text>", then fill the Variable (hidden context) field with a variable, like generatedResponse, and click save.
After that, add an Answer cell and write on the text template the variable used in the Gen AI cell, using the example above, it would be: $hiddenContext.generatedResponse.
Now, every time a customer passes through this answer cell, the text will be slightly modified, adding variations.
In this example, the prompt gives the instruction for a specific tone, asking to rewrite in "a positive, reinforcing tone", specifying and restricting a random generation into a specific format. You can ask for any tone you desire, or leave without a specification: "Rewrite this phrase with slight differences", but be aware that this may end up producing texts with an unwanted tone.
Extracting user text information into JSON and Variables
With a Gen AI cell you can also extract and process user inputs into context variables.
To accomplish this, simply add a wait-input cell right before the Gen AI cell (image below) with a prompt similar to the this:
Extract and respond with only a JSON with uppercase USERNAME, DATE_OF_BIRTH and DOCUMENT_NUMBER from the user input below (data might be missing). The user input is: "$text"
The LLM will parse the last input (found at the variable: $text) and generate a JSON output with the specified fields.
By adding to the prompt "data might be missing," we instruct the LLM to allow for empty fields. This means that if the user mentions any of those three items in their phrase, the LLM will identify and store them in their respective JSON fields, if they are present.
You can then choose to use this JSON elsewhere, or to parse it with a code cell as follows:
This code block extracts the "generativeResponse" from the hiddenContext and parses the JSON data into context variables. In case of any issues during this process, it also creates a variable indicating whether the parsing was successful or not, which allows us to discern where to go on a rule cell.
Modular answer building
You can use Gen AI cells to infer if a certain ammount of data was filled or not. Using the previous example, one may want all three fields filled: username, date of birth and document number.
We might prompt the customer to provide the remaining fields to be used after a Rule Cell identified it failed to provide all three. For instance, the following prompt may be used:
Rewrite the following: "Please, you need to provide some information before continuing: #if( !$hiddenContext.someVar.user) Username, #end #if( !$hiddenContext.someVar.birthdate) Birth date, #end #if( !$hiddenContext.someVar.document) Document number #end"
By doing so, you are building your answer in a modular fashion, adding into the content only the fields that still weren't filled.
You can also do the opposite, and use existing variables as prompt instructions instead.
For another scenario, we might want to write an answer modularly when all those fields have been filled.
With the information below, ask the user to confirm if the informed data is correct, but any date format must be mm/dd/yyyy. $hiddenContext.someVar
Essentially, we are asking the user to validate if the information below ($hiddenContext.someVar) is correct, meaning it will present any data within it, like user, birthdate and document and their values. We also specified that any date must be presented as "mm/dd/yyyy", so regardless of how the birthdate was provided by the customer, you will have it shown in the specified format. You can do any kind of format manipulation with these.
Rerouting not-expected answers
If you are familiar with NLPs, you are likely aware of the Not Expected answers and how the customer might end up in the Not Expected Flow. Tipically, by then, they go into ground zero, and have to restart the user journey from scratch.
Because the input text persists across flows, once you arrive at the not expected flow, you can still read this user input and work with it to discern what was being attempted, allowing the bot to use a zero-shot strategy to reroute your customer right back to where they were. For instance, the following prompt may assist you with such:
This prompt instructs the LLM to read the last thing the user wrote, and try to discern what they were talking about. Often, this might be an innefective, as some inputs may be too generic (Such as a 'yes' text), and the category identified will be "OTHER". But the last input may also contain specific keywords which can be identified into the designated categories.
The presence of the words "username" or "birthdate" on the text might be indicative that the customer was accessing something regarding profile editting. The presence of the word "help", by itself, may indicate they are searching for support options.
By immediately using a Rule Cell you are able to parse if the identified category is one of those, with rules such as:
And so on for each case. From there, you have a linear path you may draw on a reroute journey - you may immediately setup a Jump Cell and send them into specific user journeys that fit the theme, or ask a direct question such as "Are you attempting to receive support regarding our products?" to confirm the zero-shot identification was correct. You can even build reroute cases for topics unrelated to any one specific user journey.
It is important to note that the category "OTHER" is very important, as it should retain the standard not-expected response.
Full example: Extracting user input into a JSON format to feed a Rest Connector Cell's body
To weave those concepts together into a concise, larger picture example, we will now design a Flight Booking flow. In this demonstration, it is a User Journey flow.
We will use the examples provided above to build a cohesive flow which will read inputs, parse them into variables, confirm them, and print the results, which could even be used to send a Rest Connector Cell request with!
First thing to note is that this flow is rather short. It makes use of a loop with a jump cell. The core idea here is as follows: We start the flow by collecting informations from the input that brought the user here. We then parse it, and use a Rule Cell to verify if all fields have been filled. If they haven't, we prompt them to fill in the missing fields, and open an Wait Input Cell, before a jump that will set the user back to the beggining this flow.
This will continue until all three requested fields are filled - in which the Rule Cell will send the user too the lower section of the flow, presenting the result.
So, let's go into specifics.
The first cell is a variable setup. We will be storing used data into the "flightInfo" variable, so we state it:
Immediately after, we have our first GenAI Cell, parsing that input. You will see that this prompt is slightly more complex than the one presented before:
Because we are working on a loop, we have some conditional cases that evaluate if a field is already filled, and set the previously filled fields again into the prompt. For instance, if ORIGIN was already filled, this ensures that the prompt will receive it again regardless of the current user input.
Note - This is the cell the jump will return to in case of a failure to provide all data further into the flow
Next thing we do is parsing. We read use a code cell identical to the one presented in the examples above, as follows:
Now that we have our values parsed, we want to know if they are all filled. We do so by a Rule Cell, which will branch our paths:
If this evaluation succeeds, it means there is at least one missing field. We carry on to a new GenAI Cell which will generate a text and immediately present to them through an answer cell containing the result as the text, indicating to our user which fields are missing, right before a Wait Input Cell awaiting a new input from the user.
Once the user has written down their input, a Jump Cell sends them back to the "Extract Flight Info" GenAI Cell at the beggining of the flow, restarting the proccess. Because that GenAI promot is build with pre-filled fields, we will retain previous information. The user can fill the fields step by step, if the they only provide one information at a time, or at a single step if they provide all at once.
Lastly, when everything is filled, the "Missing Info" rule cell will evaluate to false, meaning we now go into the "All info Ok" Cell, which contains a single "true"
Because we now contain all required data, we can move forward. In this example, we simply present them to the user for confirmation, using the following GenAI Cell, which will also format date and reply the destination and origin as airport codes. The LLM will presume the closest available:
The text is then displayed, formatted, to the user. Because we also referenced the current date, if the flight date is at the following day, for instance, it may refer to it as "tomorrow", or if the date is clonse, it might even refer to it by week day name, should the date be close enough.
ALTERNATIVELY, you could do the following:
This generates a new JSON, with a specified date format and airport codes as strings. This could, for instance, be used to build a JSON you would use as the body of a Rest Connector Cell to your API, immediately after this, in order to retrieve a list of flights, register a search, or whichever you need, seamlessly integrating your API directly into the eva's virtual assistant.