Open JeffCordes opened 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.
Thank Lars for the prompt response.
I read through all the code again and think i more clearly see this hand-off now in the OnSessionEvents, and I can make that all work in ts fine.
I was really trying to get a feel for what a c# bot talking to CL would look like, and didn't understand why the memory was the way it is. The translation concept makes sense through. The first step of ML is always data prep.
Thanks again.
Glad to help. Feedback is always greatly appreciated.
From: Jeff Cordes notifications@github.com Sent: Tuesday, January 22, 2019 12:29 PM To: Microsoft/ConversationLearner-SDK ConversationLearner-SDK@noreply.github.com Cc: Lars Liden larsliden@gmail.com; Comment comment@noreply.github.com Subject: Re: [Microsoft/ConversationLearner-SDK] BotState parity with botframework (#418)
Thank Lars for the prompt response.
I read through all the code again and think i more clearly see this hand-off now in the OnSessionEvents, and I can make that all work in ts fine.
I was really trying to get a feel for what a c# bot talking to CL would look like, and didn't understand why the memory was the way it is. The translation concept makes sense through. The first step of ML is always data prep.
Thanks again.
— You are receiving this because you commented. 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%23issuecomment-456551381&data=02%7C01%7CLars.Liden%40microsoft.com%7Cbb337fc591bc4f809bd908d680a8439c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636837857513236419&sdata=rT7VlrtK2FfK9OTSCzp0Ki8TJris7jXJqapehCd%2Bl4o%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGOd5m5zp18Vtm9dR7yKa2VrVU0KpqnQks5vF3SSgaJpZM4aMx88&data=02%7C01%7CLars.Liden%40microsoft.com%7Cbb337fc591bc4f809bd908d680a8439c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636837857513246424&sdata=ZHtmFieTniYsVzZI9IY0dmGdMnE%2BpQSl77K81I2tpN4%3D&reserved=0.
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?