LarsLiden
commented
5 years ago Great question, Jeff. In order for the neural network to make decisions about which actions to take (and in order to replay Train Dialogs) it needs full access to anything in the Bot’s memory that could impact that decision. BotFramework’s MemoryStorage is opaque to CL. For this reason, when CL is in control of the Bot it needs to manage its own memory.
If you haven’t done so already, take a look at the “tutorialHybrid” which shows how to pass state back and forth between BF memory store and that of CL (video http://aka.ms/cl_Tutorial_v3_Hybrid_Applications)
Essentially CL acts a bit like a function call in which you set initial Entity state that the Model needs and get back values that you can then store in BF’s MemoryStorage. This translation layer also makes CL Models more portable/pluggable as one doesn’t have to agree on memory schema (i.e. name could be stored as “UserName” in one system and “Name” in another.
From: Jeff Cordes notifications@github.com Sent: Tuesday, January 22, 2019 6:26 AM To: Microsoft/ConversationLearner-SDK ConversationLearner-SDK@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [Microsoft/ConversationLearner-SDK] BotState parity with botframework (#418)
Question
What is the long term intention of state management for CL? It appears that today it has its own BotState class, that through CLMemory still targets some of of the BotFramework for storage.
Is this a case of CL being out of sync with the latest bot framework where stateAccessors and DI were added to state management in version 4? Or is the intent that CL will always require its own state management, storage etc and not use the bot framework state?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FConversationLearner-SDK%2Fissues%2F418&data=02%7C01%7CLars.Liden%40microsoft.com%7C973f8353025b4e4e6dd108d680757a62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636837639386823872&sdata=yyntel17n7fEjkGxitf8nDAKFqhKiHvz1iPym9hMnPM%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGOd5hIK_bbdJzETIdEoOtgowr8a3Kt1ks5vFx9bgaJpZM4aMx88&data=02%7C01%7CLars.Liden%40microsoft.com%7C973f8353025b4e4e6dd108d680757a62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636837639386833882&sdata=JHXcmtojnUA0E7vUh%2FrSf5p1DbpGC2nN9T%2BvnMppNB4%3D&reserved=0.
JeffCordes
Question
What is the long term intention of state management for CL? It appears that today it has its own BotState class, that through CLMemory still targets some of of the BotFramework for storage.
Is this a case of CL being out of sync with the latest bot framework where stateAccessors and DI were added to state management in version 4? Or is the intent that CL will always require its own state management, storage etc and not use the bot framework state?