I had the opportunity to catch several sessions on conversational interfaces (you know, BOTS) at re:invent and wanted to collect some notes that I found interesting.
One point was: don’t launch early with a convo interface that is just kind of barely working. The data you’ll get once deployed will actually be skewed by the deficiencies in your interface/bot. Instead launch a greater competence w less data, then your real data will have more meaning and drive better performance
Rubric for thinking about success:
- What can you do
- How useful is it?
- Am I training you or are you trainings me to use you?
- How dependable?
- How performamt?
- How well do you know me?
- I trust you
- I can take some services for granted
- I can focus on other decisions
Advanced Dialog attributes
- Mixed initiative
- User may answer in a way that doesn’t address question, but instead expresses a desire to focus on something else
- Be good at things related to what you’re asking user about
- Adding constraints when replying to a req for input
- Exception handling
- Handle exceptions to rules
- Speech acts
- Interpretation in context: partial info makes sense in context
- World state
- Complex language
- Meta dialogue, talk about the dialogue itself, self awareness
State of the art is not available in a deployed toolkit. Have to search for what tools libraries to put together.
AWS Lex looks like a pretty easy way to create a conversational bot (text or audio). Very little programming required. It seems very goal oriented (define intents and inputs - slots - needed to fulfill those intents) rather than requiring you to design a big branching conversation hierarchy. Got some good notes on an architecture to support doing more sophisticated things with Lex. Limitations from the speaker: limited ability to correct Lex’s interpretations of users, cannot easily set a slot/input to be conditionally required (eg based on user session), need to route user to sub-bots in order to handle more complex/branching conversations.