Accessing text analytics from a chatbot: Sentiment

As the SAS Conversation Designer (CD) user community grows, expectations arise with regards to its abilities to access capabilities from other offerings, one such being SAS Visual Text Analytics (VTA). SAS Conversation Designer is available with every offering that also provides SAS Visual Analytics (and this includes VTA). Consumers expect to easily access VTA capabilities from SAS Conversation Designer with minimum additional configuration. To address this, let us consider the following questions:

What do we want to accomplish? Overlapping capabilities between SAS Conversation Designer and SAS Visual Text Analytics (for example, detect entities or match user input to intents) make it important to first establish the purpose so that efforts are not redundant (accomplishing something that was already within SAS Conversation Designer’s ambit).
How do we access such capabilities? Once a purpose is clearly established, we can then look at the steps required, which can be based on existing functionality. The SAS Code Data Provider Node and the Web Service Data Provider Node are examples of such existing functionality. Both enable a connection to other SAS capabilities which may exist on the same, or on other environments.

What do we want to accomplish?

Here are some initial thoughts around likely objectives customers may have, which involve text analytics accessed from a chatbot.

Customers may wish to provide their feedback, review, or complaint in freeform text. This may then get analyzed for the sentiment. The chatbot could treat negative feedback, as determined by a text analytics engine, by directing the customer to a dialogue that seeks to mitigate the risk due to such negative sentiment.
Analyzing complaints through a categorization model helps indicate the broad area around which the customer had a complaint, and that topic can be then be addressed within a dialogue.
Customer support centers may have off-hours and may sometimes ask customers to write in their complaints, saying someone will get back to them. In such cases, chats may be sent to an analysis engine to get categorized, useful information extracted and could be routed to other places (a workflow to escalate an issue), including the chatbot for a response.
Similar customer queries and complaints may have been raised in the past and also addressed. A specific customer’s text input could be used as the basis for search against an existing index, and recommendations/answers provided for past complaints of a similar nature could be used as a way to handle this complaint.
The next section will address use cases centered around sentiment analysis and use case #1. The approach for sentiment analysis use cases can be reapplied for other similar text analytics models (concepts and categories). Search-based use cases are tackled in a slightly different manner and will be the subject of another blog.

How do we access sentiment analytics from a chatbot?

A high-level dialogue is provided. The scenario is a situation when, typically at the end of an interaction, the customer is asked to provide feedback regarding their experience. While the technical steps can be better explored in a different blog or provided as an example, here is the sequence of activities that ensue:

The bot invites the customer to provide feedback. Note, the Start Chat Event is provided here only for convenience. In production scenarios, this would be a dialogue triggered after the end of some other dialogue. A typical message could be, provided through a Text response / HTML response node:

“Thanks for the interaction so far. If you would like to provide some feedback, please feel free to enter the same.”

Customers provide their feedback to the bot. Other complex cases need to be tackled in production scenarios (such as, if the customer chooses to provide feedback over a series of chats) and therefore, this is a simplification. The customer’s feedback in this case is captured through a Text Input node. A parameter within the Text Input node (call it textByUser) stores this.
As an optional step, the feedback provided by the customer is also stored in a variable for easy retrieval (Feedback is logged). A Modify Context Data Provider node is used for this purpose. In this case, the same variable textByUser was assigned as a string. This aids reuse of the variable in succeeding dialogues and nodes:

Feedback is analyzed – During this stage, the bot connects to Visual Text Analytics. The connection is through a SAS Code Data Provider node, where a CAS (the analytical engine of SAS Viya) session is started, and the feedback is analyzed for the sentiment. The response/output from the SAS Code Data Provider node is then returned to the bot in the form of a JSON. The following is the code used inside the SAS Code Data Provider Node:
Logic (through a Logic Node) is applied over the JSON to decide and execute an appropriate response. A positive sentiment (the If branch) may lead to the bot thanking the user and ending the conversation on a positive note. A negative sentiment (the Else branch) may however need empathy from the bot, and mitigation or remediation if possible. This can be accomplished through another flow (or redirecting to another dialogue). Other data variables surrounding the sentiment analysis’ final output ( e.g. in addition to sentiment, return the matches indicating negative sentiment) can also be provided.

The following is the Logic for the IF condition (the node labeled “If Sentiment is positive”). The JSON returned from the previous SAS Code Data Provider node is called sentOut.

$sentOut["SASTableData+OUT_SENT"][0]["_sentiment_"] == "Positive"

Other Considerations

When using the SAS Code Data Provider node, one needs to maintain realistic expectations with regards to speed/latency. Accounting for speed and performance is important; remember the chatbot makes a connection to another application and therefore you should account for some time between the handoff. The ‘art’ aspects of designing a chatbot gain importance here and it is recommended that you choose only those sorts of situations where the user understands that the process might take time. A tactic could be to inform the user, “Hold on while our system analyzes this…” to passively engage the user.

Another key development to look out for, would be to access sentiment analysis (and other text analytics models) through future APIs or web services. There are plans to make text analytics capabilities callable through APIs and provide output more directly and synchronously. Upon such improvements, a call to text analytics through the Web Service Data Provider node can be considered.

Designer skills also need to be considered. The choice of whether to use the SAS Code Data Provider node or the Web services Data Provider node depends on whether the chatbot designer happens to be a data scientist or analyst who is familiar with coding in the SAS language, as opposed to a designer who is comfortable with web services and APIs.

Conclusion

You were provided a broad approach on how to access other analytical capabilities through SAS Conversation Designer, taking text analytics as an example. Also, you also obtained an overview of the steps required. In a future blog, we shall also look at the possibilities of calling search actions from a chatbot. Click here to learn more, and request a demo of the many other ways you can leverage a SAS Conversation Designer chatbot to obtain answers to questions, query data and reports, and access Artificial Intelligence through a conversational experience!