We have an existing ADM model in PRODUCTION and we want to migrate the existing ADM model learnings to a revised/updated ADM model similar to below. Do we have any OOTB Daflow/Utility to support this behavior?
Ok first the technical question: Migrating from one ADM rule to another one with even slightly different configuration is not possible. I would recommend keeping both for a while, having the new one run in "shadow" mode, so learn from the responses but keep using the propensity from the old one - until such a moment that the new one have matured, then take out the old ones.
But more on the use case: The goal is to add "product type" as a context identifier I see? Why is that - is the existing issue/group/name hierarchy not related to product type? Have you tried adding product type simply as a predictor and see whether that improves performance and lift?
There is a need for us to add "product type" as a context identifier. We want to make the ADM propensity specific to "Product type" due to business requirements. So we wanted to migrate an existing learnings to the new model to not to loose the existing learnings.
We could also add "product type" as a predictor. However, it is not guaranteed that ADM predictor is always Active and contribute to the propensity calculation.
Posted: 3 years ago
Posted: 3 Sep 2020 8:12 EDT
Otto Perdeck (Otto_Perdeck)
Director, Data Science, Machine Learning & AI
No you won't have that guarantee, that is correct. Possibly "product type" is a weak predictor or is strongly correlated with better predictors - only the data will tell.
Alternatively to adding a context key you could have multiple model rules/configurations of course, each specific for a product type. That would really accomplish the same goal but may not be practical if there are a lot of product types, or if they change frequently.
It won't help you with the statistics however - so the answer above to either just let them ramp up on their own (usually quick, especially in inbound scenario's) or use as a shadowing model first is still the best I can think of.