Posted: 11 May 2018 9:32 EDT Last activity: 16 May 2018 8:56 EDT
Question on delay learning architecture
I have a question on the delay learning design architecture.We have configured adaptive delay learning. Pega stores the outbound request sent along with the interaction id into the decision data store(Cassandra). It also stores ADMInputs(with values) and pxSubjectID(CustomerID).
Question 1: (We want to change the design): We pega needs customerID in the response? It already has all the predictors with values stored in the request going to decision data store(pxADMInputs). If we don't pass the CustomerID, delay learning process is not working,
Question 2: Lets say if it gets the CustomerID in the delay learning response. What happens if the customer details are updated in the customer table before the response is captured? Ex: Age is updated but the pxADMInputs still has the old values. Does it take the new values for learning or will it go with the old values? Can we customize this?
Please let me know if we are missing something. Thanks in advance.
It looks like you have a pretty good understanding of how "delayed learning" works. For those reading this that are less familiar: please check PDN for the articles about this, or consider the Pega Academy courses on the subject.
Regarding your questions: the internal cache (technically: pxDecisionResults) is keyed by subject ID and interaction ID, so you'll need to provide both to fetch the original data used at decision time. Interaction ID can be left out, but then you get the data for all decisions for a certain customer and you will need to do more work in the response strategy.
This architecture is designed so the learning is always proper and you don't run the risk of training your models with data that was post decision time (in Data Science parlance, a leaker). So in your example, it will always take Age at decision time, not response time, and this is how you should want it to be.
Question 1: Read this concept in one of the forums. Pega uses both the keys to support multi level decisioning. But pega should have given a checkbox to support responses based on single level decisioning. I mean one customer will have one interaction based response. Just an idea for future implementations. We resolved this issue with a work around by storing the consumerId (as a concatenated string of two keys of customer table).
I tried with all the different approaches. Pega is not able to fetch the records if the "InteractionID" and "ConsumerID" are not passed to the response flow. The external input shape is using both the keys to open the response results.
Question 2: Thanks for explaining me the core concept of data science. Though I am new to this area, I got more clarity after I read your comment.
The responses that the data set receives can contain an InteractionID, but it is no longer required. When the channel application does not keep track of the InteractionID in a headless decisioning scenario, use a response strategy that fetches all the interactions for a particular customer in a specific date range. In the DMSample application, the ResponseStrategyWithoutInteractionID strategy is a simple example of such a strategy.
Thanks for sharing this article @Otto_Perdeck. This article is explaining about the adaptive batch learning when the response contains the OfferId, CustomerId and Response. But in out scenario, we are using real time adaptive learning where the customer is offered through a specific channel and every new interaction with our decisioning service, sends a new offer. We have a plan to upgrade our models for batch learning once we start our campaign management.
The article isn't really about batch, it focusses on how to use Pega as a headless decisioning service (which can be used in any way you like). I mentioned it because the article contains a reference to how you do send a response when you have not kept track of the interaction ID at decision time.
Perhaps I don't really understand what your question is?