Getting Started with Qlik Predict: From Model to Action

Who wouldn't want to predict the future? With Qlik Predict (the new name for AutoML), you can easily create predictive models based on your data. Qlik Predict automates a large part of this process for you. In the previous blogs, we explained how to prepare your data with feature engineering and how to select the best model. In this third part, we show how you actually deploy the trained model within your organization: operationalizing your model.

From Experiment to Deployable Model

Once you're satisfied with the result of your experiment, you can deploy the model. This means you make the model available to generate predictions with. In Qlik, this happens via a so-called 'ML deployment'. You can deploy a model to a new or existing deployment.

Once you've added one or more models to a deployment, at least one of the models needs to be approved before it can generate predictions. If you have multiple models, you choose one of them as the "default" model, and for the remaining models you can create 'aliases'. You can use these aliases to address the right model.

Figure 1: Deployable models (click the figure for a larger view).

Generating Predictions: Manual, Scheduled, or Real-Time

Once the model has been approved, you can use it to generate predictions. This can be done in three ways:

• Batch prediction: via the deployment interface, you choose an existing dataset as input for the prediction. Qlik checks whether the correct features are present based on column names. Then you choose the model you want to use, specify the output dataset, the location where it's stored, its name, and choose the format in which it's stored (qvd, parquet, or CSV). You can then choose whether this export is one-time or run periodically.
• Real-time API: A URL is generated for every alias in a deployment. This is a REST API endpoint where you can generate a prediction via a POST call. This method is ideal when you want to integrate your predictive model with another application outside the Qlik platform.
  To generate a prediction, you provide an "Authorization" header with a valid API key, and in the body the correct column names matching the model's features. An example of a body for such a call is shown below:
  {
"rows": [["feature1value", "feature2value"]],
"schema": [{"name": "feature1"},{"name": "feature2"}]
}
• Analytic connection: If you want to integrate live predictions into a Qlik dashboard, you can use a so-called "Analytic connection". You create the connection the same way as a data connection in the load script. Once you've created the connection, you can generate a prediction in an expression using Server-Side Extension (SSE) syntax. An example expression looks like this:
  =endpoints.ScriptEvalEx(
'SSSSN',
'{"RequestType":"endpoint", "endpoint":{
"connectionname":"MyConnection",
"column":"MyTargetColumn"}}',
[Feature1],
[Feature2],
[Feature3],
[Feature4],
[SyntheticDimension] as [Feature5]
)


The call always starts with a call to endpoints.scriptEvalEx. The first parameter is then a string consisting of the letters S (String) and N (Numeric). This indicates what type of data is expected in each of the features. Next, you provide the name of the analytic connection and specify the name of the column you want to predict. Finally, you provide the various values you want to use for the simulation. By choosing columns from your data model, you make the prediction dynamic, so it responds to the user's selections.

From Prediction to Action

Now that we know how to generate a prediction, it's time to make it part of your dashboards. If you've made a batch prediction, you've received a new dataset that you can load like any other dataset in your model. The dataset contains a key to your data model and, depending on the type of predictive model, a number of columns with the prediction. For example, if you've used binary or multi-class classification, you'll have a column per label containing the probability the model gives that this label is the correct one. Suppose you've built a binary classification model that predicts whether a customer will or won't keep their subscription; with this information you can build a KPI object showing the number of customers with a high, medium, or low risk of canceling their subscription.

The next step is to give your users insight into why the model makes a particular prediction. For that you can use the so-called SHAP values. You can have these SHAP values generated alongside a prediction. You then get, per feature in your predictive model, a value between -1 and 1 for every predicted row. A positive value means the feature had a positive influence on the predicted outcome, and a negative value means a negative influence. The higher (or, for a negative value, the lower) the value, the greater the influence.

In figure 2 you can see an example of how predictions and SHAP values can be used in a dashboard. The bar chart on the left shows, per bike, a prediction of the likelihood that this bike will be delivered late. The bar chart on the right shows the SHAP values per feature. As you can see, the columns "Customer location", "Transport Company", and "Model Configuration" contribute the most to the delivery being late, while "Planned Delivery Season" actually has a positive influence on the delivery being on time. If the user selects a specific delivery, the SHAP values adjust so the user can see which specific factors have the greatest influence on that delivery.

Figure 2: Predictions and SHAP values (click the figure for a larger view).

What-If Scenarios and Sweetspot Analyses

By using the analytic connection, you can enable your users to perform even more advanced analyses. For example, you can let the user choose input values via a variable input box, after which a new prediction is generated. This way, you can, for example, see the effect of changing a supplier on the likelihood that a delivery will arrive on time.

Even more powerful is running a so-called sweetspot analysis. In a sweetspot analysis, you simulate a large number of combinations of feature values at once and plot them, for example, in a scatterplot. In figure 3, you see the likelihood of late deliveries per possible supplier plotted against the costs associated with using that supplier. This way, you can see at a glance which supplier offers the right price/quality combination for this specific delivery. If you then also give the user the ability to confirm that choice via an application automation flow, the whole circle is complete.

Figure 3: Sweetspot Analysis (click the figure for a larger view).

Keeping Your Model Healthy: Monitoring and Replacement

A model isn't static. The world changes, and so does your data. Suppose, for example, that in the 90s I had trained a predictive model to predict how much gasoline my gas station sells monthly. That model would have delivered fine predictions for a while, but with the arrival of electric cars and modern engines becoming more fuel-efficient, the model will make increasingly inaccurate predictions. Qlik Predict automatically monitors whether the data on which predictions are made still resembles the data the model was trained on. This is called data drift monitoring. Qlik uses a metric for this called the Population Stability Index (PSI). A PSI below 0.1 means everything is stable. Between 0.1 and 0.25 there's slight drift, and above 0.25 it's time to retrain or replace your model.

Besides model drift, it's also important to monitor for errors during prediction. Errors can arise, for example, because features are missing or suddenly contain values that weren't seen during training. Suppose, for example, I had "color" as an input feature, and my training dataset contained the colors "red", "green", and "blue". If I then try to generate a new prediction and provide "orange" as the color, the predictive model won't know what to do and will generate an error. If you do a batch prediction, you can choose to write out an error table in addition to the predictions and SHAP values. This can help you keep an eye on whether errors occur and where you need to take action.

Does your model need to be replaced? No problem. Thanks to the use of model aliases, you can link a new model to the same deployment without having to adjust your dashboards or API calls.

Conclusion

Training a predictive model is only the beginning. The real value only emerges once you deploy the model in your processes, dashboards, and decisions. With Qlik Predict, operationalizing a model is easy, scalable, and manageable. By integrating your predictive model into your dashboards, you can truly take action based on the insights you gain. And that's exactly how you get the maximum value out of your predictions.

Written by Lennaert van den Brink
Cluster Manager/Senior BI Consultant