For close than 3 decades, prescriptive logic has been ruling the world of financial decisions, fraud detection, claim management, healthcare diagnostics and countless many other use cases. Traditionally, the pattern by which automated decisions have been integrated into business applications has been to first gather all data needed to take a decision, then call out to a decision engine, passing in collected data.
Typically, data was gathered from databases, system of records or other backend systems, sometimes at quite an expense in terms of processing or network. The decision taking itself is usually very fast, and once done, the caller can proceed with its normal processing steps.
Lately however, Machine Learning models have become cheap and cheaper, and as pervasive as ever. In fact, teams of data scientists keep coming up with models in charge of predicting various possible outcomes based on analysis of past production data. These predictions can prove useful in guiding the automated decision taking by infusing it with data-derived insights.
This article will explore how, using ADS (Automated Decision Services, part of IBM Cloud Pak for Business Automation), can we take AI-enhanced automated decisions.
Architectural considerations
As mentioned at the beginning of the article, the most prevalent pattern has always been to gather data first, then use it to apply prescriptive logic to take a decision. Typically, when data was gathered from a database, this was making sure the calling application, which has knowledge of the object graph, could be efficient at loading all the data in one step, taking care of error conditions, complex queries, missing data, etc. and come up with a clean object model. Only then, it would call the decision engine. This would prevent rule execution from triggering data loads as side-effects, and thus have to deal with data loss, timeouts, data cleaning, etc.
However, if the need for an external system is simply for a functional call to get additional data, even remotely, then another approach is possible, which consists of calling said external system on the fly.
Yes, the execution of the decision step will take longer, since we’re now adding a remote call in the middle of the rule evaluation, but that remote call would have happened anyway in the pre-load phase, so overall the transaction time is not really impacted. In fact, it can even be lowered, as this remote call would only happen if the rules deem it necessary. Should other rules determine that, say, an applicant is not eligible for a loan for some administrative reason, then there’s no need to go and reach out to get some predictive score, while the preload approach would have performed the call in all cases.
Why do that?
We have reached the era of cheap and available ML models everywhere, including for usages that are mostly debatable when one considers the carbon footprint compared to what a regular search and a bit of thinking could achieve. Yet, one has to accept how ubiquitous ML models are becoming nowadays. With this comes along a variety of tools that make modeling data and building up predictions more mainstream than ever, and corporations have assembled large teams of data scientists that are able to analyze past production data and come up with all kinds of useful prediction models.
Yet, despite them being plentiful, they can’t really be a substitute for proper decision modeling. Prediction is not decision.
Knowing that this customer propensity to churn is over 90% doesn’t tell what do to about it, or even If we want to do anything about it, given our strategic objectives and marketing budget. Only prescriptive logic could determine this, and it would be a shame not to tap into this through of insights to guide the decision making and improve it in line with our strategic goals.
ADS composition model
A Decision Model is inherently very functional in nature. It describes a decision – an output – from data – various inputs. Each of the sub-decision it takes is a nested function, with clear input and output, and as such, integrating a call to an external function – a predictive model – is very natural and seamless.
A TaskModel (formerly known as a Ruleflow) doesn’t initially look so functional, but can be thought as such when defining input and output variables, as well as an explicitly defined function that computes the output from given input variables. As such, it becomes functional, and blends into the same approach easily.
In addition to those, ADS defines a clear dependency model between Decision Models, Task Models, and even Data Models. This makes composability of the models easy and natural. In fact, they can even be compiled separately of each other, and can reference each other using a standard maven dependency, which makes modularity even easier including in the case of complex enterprise systems containing dozens of interdependent, versioned models.
Consequently, we’ve defined the notion of “Predictive Model”, as being a model, composable likes the ones described above, which wraps a call to an external ML model hosted elsewhere, for example on Watsonx.ai.
This way, the prescriptive logic can end up calling an external ML model without even having to know and care. It’s not different for rules to determine the risk score of an applicant by calling to a Decision Model, which implements it as a series of Decision Tables handcrafted from expert knowledge than it is to call an ML model representing the same risk score derived from predictions crafted by data scientists from existing data.
This encapsulation preserves the logic from implementation details and allows evolving existing logic when predictive models become available as scientists are refining them, without major impact on the rest of the logic, a definitive advantage.
This approach allows combining predictive scores, coming from an externally defined ML model, into the prescriptive logic of a usual Decision Model, thus blending in data-infused insights with policy driven decision making, when needed (and only when needed), in a way that is very consumable for the rule writer since the reference to the predictive score is done using the exact same language as is done for referring to other attributes of the data model.
Implementation
ADS includes the concept of an “ML provider”. This artifact is authored by a user with administrative privileges over the decision project, as it contains the technical details that a rule writer wouldn’t typically handle, such as the URL and credentials (API key) used for invocation of the external ML model. These credentials are used during authoring of the decision logic, as they allow the discovery of the model. They are also passed on to the runtime, so that it can actually perform the call during rule evaluation.
During authoring of the decision model, the ML provider allows discovery of how the ML model has been implemented. It happens often that the data model used by rule writer and the one used by data scientists are not aligned.
Rule writers may use a Business facing data model which represents data with a vocabulary close to natural language, as would be found in policy document. For example, it may represent customer category as Bronze, Silver and Gold. Whereas data scientists often use data derived from databases backing actual legacy production systems, in which data may be represented differently, for example a customer category may be described a 1, 2 or 3 as a DB field.
This is where the wrapping of the ML model into a Predictive Model in ADS may prove handy, as it provides a pre- and a post-processing steps in which to perform such data transformation, that would hide this additional complexity to the rule writer, who can then focus on defining business policies using an easy to maintain language.
ADS also provides the user with a wizard that helps the writer maps easily the types needed as part of the function call to the predictive model. It also handles the versioning, something important as the decision model is only valid and validated with a specific version of the matching ML model, thus they need be governed together.
For a detailed step-by-step example of how to implement such an invocation, the reader should refer to the Sample called “Machine Learning Model – Full Path” as pointed at this url: https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/24.0.1?topic=artifacts-integrating-machine-learning
Openness
Even though out of the box samples are provided for models developed with Watsonx.ai, ADS can cater for customers who have chosen a different vendor for their ML model development and execution. As such, the functionality of ADS, both at authoring and run times, is not limited to the Watsonx implementation, and can instead be linked to other 3rd party platforms, such as Amazon Sagemaker, Microsoft Azure and others. In order to do so, the integration bridge, called Open Prediction Service Hub, is available as open source software, at this url: https://github.com/IBM/open-prediction-service-hub
Conclusion
In this article, we outlined the structure of the various decision models in ADS, and how they can be composed to take advantage of available predictive models in order to augment the prescriptive logic with prediction scores derived from data.
This combination gives full strength to the decisioning capability and helps automate decisions in a more intelligent way by leveraging data-driven insight in policy-driven prescriptive logic, to achieve automation that is more inline with corporate strategy and more precise to reach set business goals.