Question
Migrating ADM Learning from one ADM Model to another
Hi All,
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?
Hi Otto,
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.
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.
Thanks Otto for your response. We would like to go with multiple model rules/configurations & learn parallelly.
Back to my original qn, is there any way to migrate an existing ADM learnings to a new ADM model to meet the above mentioned requirement?
Thanks,
Nanjundan Chinnasamy
Hi Nanjundan,
Just an idea but while running parallel adaptive models you can feed the old model's propensity value to the new one as a predictor to give a head start.
Thanks
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?
Thanks
Otto