AI Archives

TrustyAI meets Kogito: decision monitoring

by Jacopo Rota - July 1, 2020 AI Article

In this article, we introduce the metrics monitoring add-on for Kogito. This add-on is part of the TrustyAI initiative already introduced in the previous article https://blog.kie.org/2020/06/trusty-ai-introduction.html . Like Quarkus extensions, the Kogito add-ons are modules that can be imported as dependencies and add capabilities to the application. For example, another add-on is the infinispan-persistence-addon thatRead more →

In this article, we introduce the metrics monitoring add-on for Kogito. This add-on is part of the TrustyAI initiative already introduced in the previous article https://blog.kie.org/2020/06/trusty-ai-introduction.html .

Like Quarkus extensions, the Kogito add-ons are modules that can be imported as dependencies and add capabilities to the application. For example, another add-on is the infinispan-persistence-addon that enables the Infinispan persistence.

The add-on we introduce in this post was already available but now with version 0.11 of Kogito new features related to decision monitoring have been added:

Export of domain specific monitoring metrics with Prometheus.
Generate operational and domain specific grafana dashboards.

In the article cited above, we introduced three personas: the devops engineer, the case worker and the compliance officer. The current version of the add-on exports one or more dashboards for each DMN and DRL resource. In particular, two types of dashboards might be generated depending on the type of the resource: one with operational metrics more oriented for the devops engineer and one with domain specific metrics, oriented to the case worker and the compliance worker needs.

Operational dashboard: this kind of dashboard is generated for each DMN and DRL endpoint and it contains useful information to monitor the status of the applications so as to have a fast reaction in case something goes wrong. The available graphs are about:

The total number of requests on the endpoint.
The average number of requests on the endpoint per minute.
The quantiles on the elapsed time to evaluate the requests.
Exception details.

Domain specific dashboard: currently this dashboard is exported only for each DMN endpoint. In particular, the domain specific dashboard contains a graph for each type of decision in the DMN model. At the moment, the types number, boolean and string are supported, all the other time-based builtin types will be covered in the next Kogito release. In particular

if the output of the decision is a number, the graph contains the quantiles for that metric (on a sliding window of 3 minutes).
If the output is a boolean or a string, the graph contains the number of occurrences for each output (10 minutes average).
if the output is time-based, a graph containing the quantiles is generated (with different scales and measurement unit depending on the type).

The plan for the next versions of the add-on is to also support complex structures and lists.

The devops engineer can directly use the dashboards that the add-on generates, or create custom ones manually based on the metrics exported by the application.

How To Use It

There are a few steps to follow to start using this add-on:

In your kogito project, assuming that you have imported the kogito bom to manage properly the versions of the kogito modules, import the monitoring-prometheus-addon in your pom.xml:

<dependency>
<groupId>org.kie.kogito</groupId>
 <artifactId>monitoring-prometheus-addon</artifactId>
</dependency>

In case you are interested about the number of requests on the endpoints and the status code of the responses, add the following class to your project

import javax.ws.rs.container.ContainerRequestContext;
import javax.ws.rs.container.ContainerResponseContext;
import javax.ws.rs.ext.Provider;

import org.kie.addons.monitoring.system.interceptor.MetricsInterceptor;

@Provider
public class MyInterceptor extends MetricsInterceptor {
    @Override
    public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) {
        super.filter(requestContext, responseContext);
    }
}

At this point, once the application is packaged

mvn clean package

the dashboards are generated under the path target/generated-resources/kogito/dashboards and the devops engineer can easily inject them during the deployment of the grafana container.
For the grafana provisioning, we suggest having a look at the official Grafana documentation https://grafana.com/docs/grafana/latest/administration/provisioning/ . The steps to deploy the dashboards will be integrated with Kogito Operator in a future release.

That’s it! The Kogito application is ready to export operational and domain specific metrics on the endpoint /metrics.

A complete example can be found here https://github.com/kiegroup/kogito-examples/tree/stable/dmn-drools-quarkus-metrics.

Trusty AI Aspects

by Rebecca Whitworth - June 10, 2020 AI Article

As mentioned in the previous blog post we have three aspects that we are implementing: explainability, runtime and accountability. However we need to see how these are connected with the use cases and personas. The first aspect we will consider is runtime tracing and monitoring. The term monitoring refers to the system overseeing performance orRead more →

As mentioned in the previous blog post we have three aspects that we are implementing: explainability, runtime and accountability. However we need to see how these are connected with the use cases and personas.

The first aspect we will consider is runtime tracing and monitoring. The term monitoring refers to the system overseeing performance or decision behaviour in real-time. Tracing refers to the historical data and queries over these. For example: how many decisions have been approved over the last week.

Monitoring and tracing applications at runtime is fundamental to enable auditing. Auditing enables a compliance officer to trace the decision making of the system and ensure it meets regulations.

The second aspect of Trusty AI is explaining machine learning predictive models so that the model outcomes can be trusted. This helps the data scientist to ensure unbiased and trusted models. Bias in ML systems is currently a huge problem with examples such as Google’s photo recognition, recognizing people as gorillas [1]. Trusty AI’s aims to leverage the explainability of the system to avoid model bias and unfair decisions, preserving company’s reputation and mitigating risks of litigation.

The third aspect of Trusty AI is auditing and accountability. This will help to increase compliance throughout the organization, by using auditing data to ensure that company rules and regulations have been met. The compliance officer will audit the system to review the requirements and the development of the system.

The use case covers the runtime and explainability aspects of the initiative. The bank manager can track the decisions of the system over time by using the monitoring implementation shown below. It is a sample dashboard that shows the number of loans that have been rejected or accepted over a given time period. The bank manager can monitor if the system is working correctly – and the constraints are still correct. For example, over time the economy changes and this means that loan constraints may change.

The bank manager then wishes to review individual loan decisions. This can be useful when there is a dispute about a loan or if a customer wants to know how their data has been processed. The bank manager can trace the decisions that have been made in the past as they have been stored for auditing and can be queried individually as shown below.

If the system makes a prediction based on an ML model which is used to make loan decisions, then the system can present these predictions and highlight which features were used to make that decision (see below). Trusty AI services will enrich products with this explainability feature so that users can answer these questions with confidence.

Trusty AI’s aim is to enable trust in AI systems. This includes being able to use AI in business environments and critical systems. This is vital for industries such as healthcare, finance and many others. Trusty AI will enable this support by building services which include the three aspects (explainability, monitoring and auditing) mentioned in this blog post.

References

[1] https://www.wired.com/story/when-it-comes-to-gorillas-google-photos-remains-blind/

Trusty AI Introduction

by Rebecca Whitworth - June 10, 2020 AI Article

Have you ever used a machine learning (ML) algorithm and been confused by its predictions? How did it make this decision? AI-infused systems are increasingly being used within businesses, but how do you know you can trust them? We can trust a system if we have confidence that it will make critical business decisions accurately.Read more →

Have you ever used a machine learning (ML) algorithm and been confused by its predictions? How did it make this decision? AI-infused systems are increasingly being used within businesses, but how do you know you can trust them?

We can trust a system if we have confidence that it will make critical business decisions accurately. For example, can a medical diagnosis made by an AI system be trusted by a doctor? It is integral that domain experts (such as doctors) can trust the system to make accurate and correct decisions. Another important reason for this trust is customer understanding. New laws such as GDPR include the right to access how your data has been processed. Therefore, domain experts must understand the way in which a customer’s data has been processed, so that they can pass this information back to them.

This has led to a new initiative, within the kie group, to increase trust in decision making processes that depend on AI predictive models. This initiative focuses on three aspects: runtime, explainability and accountability.

Within TrustyAI we will combine ML models and decision logic (i.e. levaging on the integration of DMN and PMML) to enrich automated decisions by including predictive analytics. By monitoring the outcome of decision making we can audit systems to ensure they (like the above) meet regulations. We can also trace these results through the system to help with a global overview of the decisions and predictions made. TrustyAI will leverage on the combination of these two standards to ensure trusted automated decision making. Let’s look at a use case to put this into context.

“As a bank manager I want to manage current loans and approval rates to ensure they meet company regulations. I also want to review specific loan decisions so that I can explain to the customer why that loan was rejected or accepted.”

There are four personas that we will use in this example:

A data scientist needs to check a predictive ML model in more detail to check if features are being used correctly. For example: if a bank manager makes a loan request but that loan is denied because of someone’s gender, then that would be an unfair bias in the model. This needs to be rectified. By enabling the user to investigate a model, they have the ability to identify these biases and ensure a model is balanced and accurate.
A compliance officer wants to ensure the whole system is compliant with company policies and regulations.
A caseworker is the end user of the system and they will use the system to make decisions. An example of an end user would be the bank manager who wants to tell the customer why a bank loan was rejected.
A DevOps engineer looks at the health metrics of the system to ensure that the system runs correctly. They will monitor system behaviour over time.

Each of these personas uses a different aspect of Trusty AI, in our next blog post we will relate each of these aspects to the personas and the use cases mentioned here.

PMML revisited

by Gabriele Cardosi - February 20, 2020 AI Article

Hi folks! The beginning of this year brings with it the initiative to re-design the Drools PMML module.In this post I will describe how we are going to approach it, what’s the current status, ideas for future development, etc. etc so… stay tuned! Background PMML is a standard whose aim is to “provide a wayRead more →

Hi folks! The beginning of this year brings with it the initiative to re-design the Drools PMML module.
In this post I will describe how we are going to approach it, what’s the current status, ideas for future development, etc. etc so… stay tuned!

Background

PMML is a standard whose aim is to “provide a way for analytic applications to describe and exchange predictive models produced by data mining and machine learning algorithms.” PMML standard defines a series of models that are managed, and we will refer to them as “Model”.
The maybe-not so obvious consequence of this is that, said differently, PMML may be thought as an orchestrator of different predictive models, each of which with different requirements.
Drools has its own PMML implementation. The original design of it was 100% drools-engine based, but in the long term this proved to be not so satisfactory for all the models, so a decision has taken to implement a new version with a different approach. And here the current story begin…

Requirements

To the bare-bone essence, what a PMML implementation should allow is to:

load a PMML file (xml format)
submit input data to it
returns predicted values

Sounds simple, doesn’t it?

Approach

The proposed architecture aims at fulfilling the requirements in a modular way, following “Clean Architecture” principles.
To achieve that, components are defined with clear boundaries and visibility.
General idea is that there are specific tasks strictly related to the core functionality that should be kept agnostic by other “outer” features.
Whoever wanting to deep delve in the matter may read the book “Clean Architecture” by R. C. Martin, but in the essence it is just a matter to apply good-ol’ design principles to the overall architecture.
With this target clearly defined, the steps required to achieve it are:

identify the core-logic and the implementation details (model-specific)
implement the core-logic inside “independent” modules
write code for the model-specific modules

We choose to implement a plugin pattern to bind the core-logic to the model-specific implementations mostly for two reasons:

incremental development and overall code-management: the core module itself does not depend on any of the model-specific implementations, so the latter may be provided/updated/replaced incrementally without any impact on the core
possibility to replace the provided implementation with a custom one
we also foresee the possibility to choose an implementation at runtime, depending on the original PMML structure (e.g. it may make sense to use a different implementation depending on the size of the given PMML)

(I cheated: those are three)

Models

KiePMMLModel

This is the definition of Kie-representation of the original PMML model.
For every actual model there is a specific implementation, and it may be any kind of object (java map, drools rule, etc).

Could we avoid it? Maybe. We could use the model directly generated by the specification’ xsd. But this has been designed to describe all the predictive models, while any of them may use it in different way and with different convention; so this internal view will represent exactly what is needed for each specific model.

Components

We identified the following main functional components:

Compiler
Assembler
Executor

Compiler

This component read the original PMML file and traslate it to our internal format.
The core-side of it simply unmarshall the xml data into Java object. Then, it uses java SPI to retrieve the model-compiler specific for the given PMML model (if it does not find one, the PMML is simply ignored).
Last, the retrieved model-compiler will “translate” the original PMML model to our model-specific representation (KiePMMLModels).
The core-side part of this component has no direct dependence on any specific Model Compiler implementation and not even with anything drools/kie related – so basically it is a lightweight/standalone library.
This component may be invoked at runtime (i.e. during the execution of the customer project), if its execution is not time-consuming, or during the compilation of the kjar (e.g. for drools-implemented models).

Assembler

This component stores KiePMMLModels created by the Compiler inside KIE knowledge base. None of the other components should have any dependency/knowledge of this one.
In turns, it must not have any dependency/knowledge/reference on actual Model Compiler implementations.

Executor

This component is responsible for actual execution of PMML models. It receives the PMML input data, retrieves the KiePMMLModel specific for the input data and calculates the output.
For each model there will be a specific “executor”, to allow different kinds of execution implementation (drools, external library, etc) depending on the model type.
The core-side of it simply receives the input data and retrieve the model-executor specific for the given PMML model (if it does not find one, the PMML is simply ignored).
Last, the retrieved model-executor will evaluate the prediction based on the input data.
The core-side part of this component has no direct dependence on any specific Model Executor implementation, but of course is strictly dependent on the drool runtime.

Overall Architecture

Model implementations

Drools-based models

Some models will delegate to the drools-engine to allow best performance under heavy load. Here are some details about general scheme for such implementations.

the compiler is invoked at kjar generation (or during runtime for hot-loading of PMML file)
the compiler reads the PMML file and transform it to “descr” object (see BaseDescr, DescrFactory, DescrBuilderTest)
regardless of how the model-compiler is invoked, the drools compiler must be invoked soon after it to have java-class generated based on the descr object
the assembler put the generated classes in the kie base
the executor loads the “drools-model” generated and invoke it with the input parameters

DRL details

for each field in the DataDictionary, a specific DataType has to be defined
for each branch/leaf of the tree, a full-path rule has to be generated (i.e. a rule with the path to get to it – e.g. “sunny”, “sunny_temperature”, “sunny_temperature_humidity”)
a “status-holder” object is created and contains the value of the rule fired – changing that value will fire the children branch/leaf rules matching it (e.g. the rule “sunny” will fire “sunny_temperature” that – in turns – will fire “sunny_temperature_humidity”)
such “status-holder” may contain informations/partial result of evaluation, to be eventually used where combination of results is needed
missing value strategy may be implemented inside the status holder or as exploded rules

Testing

For each model there will be a set of standard unit tests to mostly verify individual units of code. Beside that, inside the model-specific module (yes, it is a tongue twister) there will be an integration-test submodule. This latter will verify the overall correct execution of different, more or less complex, PMML files, to simulate as much as possible what may happen in real-world scenarios.

Regression

Regression model is the first one to have been implemented. Due to its inherent simplicity, we choose to provide a pure java-based implementation for it. For the moment being it is still under PR, and new full tests are being added.

Tree

After evaluating all the pros/cons, we decided that this model could be a good candidate to be implemented with a drools-based approach. Being also a simple model to follow, we choose to use it as first test for drools approach.

TO-DOs

This is a list of missing features that are not implemented, yet, and not strictly-related to a specific model. It will be (well, it should be) updated during the development:

Setup Benchmarking skeleton project (see Drools Benchmark)
Manage Extension tags (see xsdElement_Extension)
Manage SimpleSetPredicate tags (see SimpleSetPredicate)
Implement VariableWeight inside Segment (dynamic alternative to static “weight” value)

Needless to say that any comment (especially nice ones) and suggestion will be greatly appreciated.

Come back in the following days and see what’s next!

Bye!

Introducing jBPM’s Human Task recommendation API

by Rui Vieira - October 22, 2019 AI Process Article

In this post, we’ll introduce a new jBPM API which allows for predictive models to be trained with Human Tasks (HT) data and for HT to incorporate model predictions as outputs and complete HT without user interaction. This API will allow you to add Machine Learning capabilities to your jBPM project by being able toRead more →

In this post, we’ll introduce a new jBPM API which allows for predictive models to be trained with Human Tasks (HT) data and for HT to incorporate model predictions as outputs and complete HT without user interaction.

This API will allow you to add Machine Learning capabilities to your jBPM project by being able to use, for instance, models trained with historical task data to recommend the most likely output. The API also gives developers the flexibility to implement a “recommendation-only” service (which only suggests outputs) as well as automatically completing the task if the prediction’s confidence meets a user-defined prediction confidence threshold.
This API exposes the HT handling to a recommendation service.
A recommendation service is simply any third-party class which implements the org.kie.internal.task.api.prediction.PredictionService interface.

This interface consists of three methods:

getIdentifier() – a method which returns a unique (String) identifier for your prediction service
predict(Task task, Map<String, Object> inputData) – a method that takes task information and the task’s inputs from which we will derive the model’s inputs, as a map. The method returns a PredictionOutcome instance, which we will look in closer detail later on
train(Task task, Map<String, Object> inputData, Map<String, Object> outputData) – this method, similarly to predict, takes task info and the task’s inputs, but now we also need to provide the task’s outputs, as a map, for training

This class will consist of:

A Map<String, Object> outcome containing the prediction outputs, each entry represents an output attribute’s name and value. This map can be empty, which corresponds to the model not providing any prediction.
A confidence value. The meaning of this field is left to the developer (e.g. it could represent a probability between 0.0 and 1.0). It’s relevance is related to the confidenceThreshold below.
A confidenceThreshold – this value represents the confidence cutoff after which an action can be taken by the HT item handler.

As an example, let’s assume our confidence represents a prediction probability between 0.0 and 1.0. If the confidenceThreshold is 0.7, that would mean that for confidence > 0.7 the HT outputs would be set to the outcome and the task automatically closed. If the confidence <= 0.7, then the HT would set the prediction outcome as suggested values, but the task would not be closed and still need human interaction. If the outcome is empty, then the HT life cycle would proceed as if no prediction was made.
By defining a confidence threshold which is always higher than the confidence, developers can create a “recommendation-only” service, which will assign predicted outputs to the task, but never complete it.

The initial step is then, as defined above, the predict step. In the scenario where the prediction’s confidence is above the threshold, the task is automatically completed. If the confidence is not above the threshold, however, when the task is eventually completed both the inputs and the outputs will then be used to further train the model by calling the prediction service’s train method.

Example project

An example project is available here. This project consists of a single Human Task, which can be inspected using Business Central. The task is generic and simple enough in order to demonstrate the working of the jBPM’s recommendation API.

For the purposes of the demonstration, this task will be used to model a simple purchasing system where the purchase of a laptop of a certain brand is requested and must be, eventually, manually approved. The tasks inputs are:

item – a String with the brand’s name
price – a Float representing the laptop’s price
ActorId – a String representing the user requesting the purchase

The task provides as outputs:

approved – a Boolean specifying whether the purchase was approved or not

This repository contains two example recommendation service implementations as Maven modules and a REST client to populate the project with tasks to allow the predictive model training.

Start by downloading, or alternatively cloning, the repository:

$ git clone git@github.com:ruivieira/jbpm-recommendation-demo.git

For this demo, two random forest-based services, one using the SMILE library and another as a Predictive Model Markup Language (PMML) model, will be used. The services, located respectively in services/jbpm-recommendation-smile-random-forest and services/jbpm-recommendation-pmml-random-forest, can be built with (using SMILE as an example):

$ cd services/jbpm-recommendation-smile-random-forest
$ mvn clean install

The resulting JARs files can then be included in the Business Central’s kie-server.war located in standalone/deployments directory of your jBPM server installation. To do this, simply create a WEB-INF/lib, copy the compiled JARs into it and run

$ zip -r kie-server.war WEB-INF

The PMML-based service expects to find the PMML model in META-INF, so after copying the PMML file in jbpm-recommendation-pmml-random-forest/src/main/resources/models/random_forest.pmml into META-INF, it should also be included in the WAR by using

$ zip -r kie-server.war META-INF

jBPM will search for a recommendation service with an identifier specified by a Java property named org.jbpm.task.prediction.service. Since in our demo, the random forest service has the identifier SMILERandomForest, we can set this value when starting Business Central, for instance as:

$ ./standalone.sh -Dorg.jbpm.task.prediction.service=SMILERandomForest

For the purpose of this documentation we will illustrate the steps using the SMILE-based service. The PMML-based service can be used by starting Business Central and setting the property as

$ ./standalone.sh -Dorg.jbpm.task.prediction.service=PMMLRandomForest

Once Business Central has completed the startup, you can go to http://localhost:8080/business-central/ and login using the default admin credential wbadmin/wbadmin. After choosing the default workspace (or creating your own), then select “Import project” and use the project git URL:

https://github.com/ruivieira/jbpm-recommendation-demo-project.git

The repository also contains a REST client (under client) which allows to add Human Tasks in batch in order to have sufficient data points to train the model, so that we can have meaningful recommendations.

NOTE: Before running the REST client, make sure that Business Central is running and the demo project is deployed and also running.

The class org.jbpm.recommendation.demo.RESTClient performs this task and can be executed from the client directory with:

$ mvn exec:java -Dexec.mainClass="org.jbpm.recommendation.demo.RESTClient"

The prices for Lenovo and Apple laptops are drawn from Normal distributions with respective means of 1500 and 2500 (pictured below). Although the recommendation service is not aware of the deterministic rules we’ve used to set the task outcome, it will train the model based on the data it receives. The tasks’ completion will adhere to the following logic:

The purchase of a laptop of brand Lenovo requested by user John or Mary will be approved if the price is around $1500
The purchase of a laptop of brand Apple requested by user John or Mary will be approved if the price is around $2500
The purchase of a laptop of brand Lenovo requested by user John or Mary will be rejected if the price is around $2500

The client will then simulate the creation and completion of human tasks, during which the model will be trained.

SMILE-based service

As we’ve seen, when creating and completing a batch of tasks (as previously) we are simultaneously training the predictive model. The service implementation is based on a random forest model a popular ensemble learning method.

When running the RESTClient, 1200 tasks will be created and completed to allow for a reasonably sized training dataset. The recommendation service initially has a confidence threshold of 1.0 and after a sufficiently large number (arbitrarily chosen as 1200) of observations are used for training, the confidence threshold drops to 0.75. This is simply to demonstrate the two possible actions, i.e. recommendation without completing and completing the task. This also allows us to avoid any cold start problems.

After the model is trained with the task from RESTClient, we will now create a new Human Task.

If we create a HT requesting the purchase of an “Apple” laptop from “John” with the price $2500, we should expect it to be approved.

If fact, when claiming the task, we can see that the recommendation service recommends the purchase to be approved with a “confidence” of 91%.

If he now create a task for the request of a “Lenovo” laptop from “Mary” with the price $1437, he would expect it to be approved. We can see that this is the case, where the form is filled in by the recommendation service with an approved status with a “confidence” of 86.5%.

We can also see, as expected, what happens when “John” tries to order a “Lenovo” for $2700. The recommendation service fills the form as “not approved” with a “confidence” of 71%.

In this service, the confidence threshold is set as 1.0 and as such the task was not closed automatically.

The minimum number of data points was purposely chosen so that after running the REST client and completing a single task, the service will drop the confidence threshold to 0.75.

If we complete one of the above tasks manually, the next task you create will be automatically completed if the confidence is above 0.75. For instance, when creating a task we are pretty sure will be approved (e.g. John purchasing a Lenovo $1500) you can verify that the task is automatically completed.

PMML-based service

The second example implementation is the PMML-based recommendation service. PMML is a predictive model interchange standard, which allows for a wide variety of models to be reused in different platforms and programming languages.

The service included in this demo consists of pre-trained model (with a dataset similar to the one generated by RESTClient) which is executed by a PMML engine. For this demo, the engine used was jpmml-evaluator, the de facto reference implementation of the PMML specification.

There are two main differences when comparing this service to the SMILE-based one:

The model doesn’t need the training phase. The model has been already trained and serialised into the PMML format. This means that we can start using predictions straight away from jBPM.
The train API method is a no-op in this case. This means that whenever the service’s train method is called, it will not be used for training in this example (only the predict method is needed for a “read-only” model), as we can see from the figure below.

You can verify that the Business Central workflow is the same as with the SMILE service, although in this case no training is necessary.

The above instructions on how to setup the demo project are also available in the following video (details are in the subtitles):

In conclusion, in this post we’ve shown how to use a new API which allows for predictive models to suggest outputs and complete Human Tasks.

We’ve also shown a project which can use different recommendation service backends simply by registering them with jBPM without any changes to the project.

Why not create your own jBPM recommendation service using your favourite Machine Learning framework, today?

Webinar: Re-imagining business automation: Convergence of decisions, workflow, AI/ML, RPA — vision and futures

by Mark Proctor - June 19, 2019 AI Process Rules Article

WEBINAR Title: Re-imagining business automation: Convergence of decisions, workflow, AI/ML, RPA—vision and futures Time: June 20, 2019, 5:00 p.m. BST (UTC+ 1) Registration https://www.redhat.com/en/events/webinar/re-imagining-business-automation-convergence-decisions-workflow-aiml-rpa%E2%80%94vision-and-futures

New feature overview : PMML

by Sotty - April 22, 2014 AI Article

Today, I’ll introduce a new 6.1 experimental feature, just being released from our incubator: Drools-PMML. I’ll spend the next days trying to describe this new module from the pages of this blog. Some of you, early adopters of Drools-Scorecards, will probably have heard the name. Thanks to the great work done by Vinod Kiran, PMMLRead more →

Today, I’ll introduce a new 6.1 experimental feature, just being released from our incubator: Drools-PMML.

I’ll spend the next days trying to describe this new module from the pages of this blog. Some of you, early adopters of Drools-Scorecards, will probably have heard the name. Thanks to the great work done by Vinod Kiran, PMML was already living inside that module. However, the Predictive Model Markup Language (www.dmg.org) is much more than that. It is a standard that can be used to encode and interchange classification and regression models such as neural networks or decision trees. These quantitative models complement nicely the qualitative nature of business rules.

So, how does it work? Exactly like with all other KIE assets such as processes, rules or decision tables. First, you have to create the model: there are plenty of statistical/data mining softwares that generate or consume PMML. In the future, even Drools might be able to do that!

Once you have your model, just deploy it in your Kie Module and let it become part of your Kie Base. Betting you are now familiar with the kmodule.xml configuration, let me show an example using the programmatic APIs:


String pmmlSource = // ... path to your PMML file

KieServices ks = KieServices.Factory.get();
KieFileSystem kfs = ks.newKieFileSystem();
kfs.write( ResourceFactory.newClassPathResource( pmmlSource )
                          .setResourceType( ResourceType.PMML ) );
ks.newKieBuilder( kfs ).buildAll().getResults();
KieSession kSession = ks.newKieContainer( 
  ks.getRepository().getDefaultReleaseId() )
                        .newKieSession();

Let’s imagine that you have a predictive model called “MockColdPredictor”. It is used to predict the probability of catching a cold given the environmental conditions. It has one input called “temperature” and one output “coldProbability”. The most basic way to invoke the model is to insert the input value(s) using a generated entry-point:

ksession.getEntryPoint( "in_Temperature" ) // "in_" + input name (capitalized)
        .insert( 32.0 );                   // the actual value
ksession.fireAllRules();

The result will be generated and can be extracted, e.g., using a drools query:

QueryResults qrs = kSession.getQueryResults(
                       "ColdProbability",   // the name of the output (capitalized)
                       "MockColdPredictor", // the name of the model
                       Variable.v );        // the Variable to retrieve the result
Double probability = (Double) qrs.iterator().next().get( "$result" );

In the future posts, we’ll discuss in detail how PMML defines models, input and output fields. Based on this, we’ll see how to integrate models and which options are available.

At the moment, these model types are supported:

Clustering
Simple Regression
Naive Bayes
Neural Networks
Scorecards
Decision Trees
Support Vector Machines

The version of the standard is 4.1. The support for these models is being consolidated, and more will be added soon.

Behind the scenes: the models are interpreted: that is, they are converted to an appropriate combination of rules and facts that emulate the calculations. A compiled version, where the models are evaluated directly, is possible and will be added in the future. So, the evaluation is slower than a “native” engine. The goal is not to prove that production rules can outperform matrix operations at… doing matrix math 🙂 Rather, the idea is to provide a uniform abstraction of a hybrid knowledge base, making it easier to integrate rule and non-rule based reasoning.

So, my next post will describe the structure of a PMML model.

Stay tuned!
— Davide

Disclaimer: as a new feature, it is likely to suffer from bugs and issues. Feedback will be welcome.

Acknowledgments :
Thanks to the University of Bologna (Bologna, Italy), the KMR2 Project and Arizona State University (Scottsdale, AZ) which, over time, have supported this project.

Publications (more to follow) :
– D. Sottara, P. Mello, C. Sartori, and E. Fry. 2011. Enhancing a Production Rule Engine with Predictive Models using PMML. In Proceedings of the 2011 workshop on Predictive markup language modeling (PMML ’11). ACM, New York, NY, USA, 39-47. DOI=10.1145/2023598.2023604 http://doi.acm.org/10.1145/2023598.2023604

Scorecards and PMML4.1 support for Drools 5.5

by Mark Proctor - October 20, 2012 AI Rules Tools Article

Thanks to our super star community contributor, Vinod Kiran, score cards are coming to Drools 5.5. Initially the PMML4.1 standard is embedded for the Scorecards module. We have a full standalone PMML implementation coming for 6.0, being worked on by Dr Davide Sottara. I hope that Vinod will write a full tutorial in this blogRead more →

Mythic Game Project Addition Artificial Intelligence and Quest System Components (Christopher Alan Ballinger)

by Mark Proctor - January 10, 2011 AI Article

Google Alerts brought this extensive masters paper to my attention, by Christopher Alan Ballinger. The paper explains what expert systems are and has a lot of DRL examples to follow.http://www.csci.csusb.edu/turner/690/example_projects/chris_ballinger_masters_project.pdf I’d be interested to see this code published online for others to play with. “In this project, we describe the design decisions and principles behindRead more →

Lisp Language of the Gods

by Mark Proctor - October 27, 2010 AI General Article

Update!!!Must see video Land of Lisp

KIE

KIE

Archive

Type

Featured Posts: AI

New feature overview : PMML
by Sotty

Mythic Game Project Addition Artificial Intelligence and Quest System Components (Christopher Alan Ballinger)
by Mark Proctor

Lisp Language of the Gods
by Mark Proctor

AI Research Overview
by Mark Proctor

TrustyAI meets Kogito: decision monitoring

How To Use It

Trusty AI Aspects

Trusty AI Introduction

PMML revisited

Background

Requirements

Approach

Models

KiePMMLModel

Components

Compiler

Assembler

Executor

Model implementations

Drools-based models

DRL details

Testing

Regression

Tree

TO-DOs

Introducing jBPM’s Human Task recommendation API

Example project

SMILE-based service

PMML-based service

Webinar: Re-imagining business automation: Convergence of decisions, workflow, AI/ML, RPA — vision and futures

New feature overview : PMML

Scorecards and PMML4.1 support for Drools 5.5

Mythic Game Project Addition Artificial Intelligence and Quest System Components (Christopher Alan Ballinger)

Lisp Language of the Gods

KIE

KIE

Type

Authors

Featured Posts: AI

New feature overview : PMMLby Sotty

Mythic Game Project Addition Artificial Intelligence and Quest System Components (Christopher Alan Ballinger)by Mark Proctor

Lisp Language of the Godsby Mark Proctor

AI Research Overviewby Mark Proctor

How To Use It

Background

Requirements

Approach

Models

KiePMMLModel

Components

Compiler

Assembler

Executor

Model implementations

Drools-based models

DRL details

Testing

Regression

Tree

TO-DOs

Example project

SMILE-based service

PMML-based service

New feature overview : PMML
by Sotty

Mythic Game Project Addition Artificial Intelligence and Quest System Components (Christopher Alan Ballinger)
by Mark Proctor

Lisp Language of the Gods
by Mark Proctor

AI Research Overview
by Mark Proctor