Teneo Query Language is a versatile tool that can help you maintain and improve your system. In this section, we'll walk through some strategies for exposing weak points in a bot's repertoire
The query to view user inputs that hit the Safetynet could look like this:
lu t.e1.userInput: t.e2.fname ~= ".*[s|S]afetynet.*"
This query will print all unique user inputs for which the name of the subsequently triggered flow contains the string 'Safetynet'. This is the default name for the Safetynet in Teneo solutions using the Teneo Dialogue Resources. If you're using a Safetynet with a different name, be sure to adjust the query accordingly.
The results will typically include two types of input:
!f you want to view inputs to other flows, you can rewrite the query above using the exact name of the particular flow:
lu t.e1.userInput: t.e2.fname == "Name of your flow here"
If a user input hits the Safetynet, you may want to go one step further and zoom out to get the bigger picture of what happened. A useful query for this is to list the flow and output that preceded the Safetynet input. Maybe the bot's answer was unclear, causing the user to ask a follow-up question for clarification. Or perhaps users did not like the answer they got and reacted with a complaint. In any case, these inputs can help to point out parts of your solution where you may want to take action, either by improving the bot's response or perhaps by adding a follow-up response in an individual flow.
A query that gives you this information can look like this:
lu t1.id as "Session ID", t1.e1.fname as "Preceding Flow", t1.e2.answerText as "Preceding Bot Response", t2.e1.userInput as "Unrecognized User Input" : t1.index == t2.index - 1, t1.e1.fname !~ ".*[s|S]afetynet.*", t2.e2.fname ~= ".*[s|S]afetynet.*"
Let's break down what this query does.
After running the query your results will look like something like this:
You may have noticed that we refer to items from different events in the query above.
In the first transaction we look at:
In the second transaction we look at:
There is an important reason for this. Consider the first case, where we are querying t1: here, we are first accessing the raised flow (with fname) and then the response (answerText). These two are from the same transaction, but different events. The same goes for the second case, where we query the user input, which is associated with the request event, followed by the name of the triggered flow, which is recorded in one of the later path events. If you are writing a query that you know should get results, and it returns nothing, make sure that you are referring to the correct events.
Was this page helpful?