Very good point!
I’m personally interested in the specific topic of multiturn dialog management.
See also my rants about the lack of context management in GoogleAssistant and Amazon Alexa:
To manage dialogical context in an open-ended assistant, the keyword is maybe “coreference resolution” concept of pragmatics. See article: https://medium.com/deeppavlov/building-a-knowledge-graph-based-dialogue-system-at-the-2nd-convai-summer-school-ec2d0aa060e5
In broad terms, that assistant could keep memory (history) of intents & entities of (successful) turns. New user request could be “completed” with implicit intents/entities previously annotated (my horrible definition of “coreference”… you will forgive me because I’m not a linguist).
Here an example I submitted in the survey:
// turn 1
U: what’s the weather in Genova?
A: Current weather for Genova: blablabla
// context: { intent: weather, entities: { city: Genova, date: current_time} }
// turn 2
U: And tomorrow in Milano?
// candidate intent: weather
// candidate entities: city, time
A: Tomorrow weather for Milano: blablabla
An adjacent research concerns to integrate context with info user teached to his personal assistant. See the following example:
U: learn the my mom number is 0101234567
A: I get it!
some time after:
U: call my mom
A: calling phone number 0101234567
In this example there is more than a strict-context multiturn. Instead the assistant completes the context with facts learned in previous training dialogs… I love this feature
Besides, in a more closed-ended / task-completion based dialog, maybe the old fashioned state-machine approach (for preplanned workflows) is a practical way. See my article: