Would love to hear your thoughts on our latest blog post that suggests 6 key capabilities of Contextual AI Assistants:
2 Likes
I very much liked the catch-phrase “All user goals are intents but not all intents are user goals (e.g. yes/no is not a user goal)”. Thats a great frame to explain intents to others!
I not yet at a production ready-bot and I try to figure out how to “gracefully handle any user goals” (bot specification 1). Passing over to a human is important, I imagine especially when a user is fed up with the bot performance?
Specification 2 and 3 go along each other, I guess: If a bot is to handle a database which is used for billing, the active confirmation of the user is to be saved… (And adding to your story: Probably the bot will send some sort of e-mail confirmation, to an e-mail which cannot be provided within the conversation…)
Concerning specifications 4 and 5, my understanding is that this - for now- depends on the NLU-Model. If the user provides a new version number, the NLU overrides the version number slot. At least I am not aware how to lock in some slots after they have been set once (except some sort of actions performing a quality check after each user inputs given the previously set slots).
Otherwise: I very much enjoyed your last two post and they helped me a lot thinking about use-cases!
Cheers, Henry
1 Like
Thanks for your response @enryh! A few comments:
- “gracefully handle any user goals” for us actually means also identifying that a user’s goal is out of scope and then handing off to a human before the user is “fed up with the bot performance”
- “disambiguation” can be to confirm a user input but also to check which goal they’d like to pursue - for example in an insurance use case, if a user sends a message like “I have a new address” this could mean that the user wants to change their postal address or edit their renters’ policy
- What do you mean with new version number?
Thanks. Your first point was highlighted greatly by yesterdays RASA Summit Talk by Eduarodo from N26!
To your last bullet point: I meant a number (not a specific version number): I sometimes have troubles getting slots reset by a newly reported number. Using text slots the policy takes only into consideration if a slot has been set or not, as fas as I understand it correctly. If a slot is set once, it can be reset by the NLU at later stage, altough the entity has been provided already and has been set to a useful value. To handle this as “context” is still tricky to me.
Cheers, Henry
Just stumbled on the blog (bit late I know). Really interesting and encouraging, particularly the context part. I asked a related question on this a while ago. Can you expand on your plans to handle context in Rasa?
In particular, ways to solve the problem of entity extraction from single word responses?
Thanks.
Hey @sfinnie. We are looking into possible ways to add more context to NLU, but there is nothing specific that you can try out yet. Though we will keep you updated on this because it’s a common feature asked by devs.
For single word responses, have you tried playing around with lookup tables? As of now, it’s the most reliable way to ensure that single word response entities are picked up.
Thanks @Juste. Lookup tables help in some cases, as do regex. Postcode (zipcode) is a good example, because it’s essentially context-free. That is: it’s pretty difficult to mistakenly interpret an utterance as a postcode when it’s intent is something else. That’s not always the case though.
Realise you’re working on it, and can imagine it’s potentially not trivial. There’s obvious architectural attraction in cleanly separating NLU from dialogue management. I can see how feeding back from the latter into the former could complicate matters.
Look forward to seeing what clever solutions you come up with!
1 Like