TB
T.C. Bos
info
Please Note
<p>This page displays the records of the person named above and is not linked to a unique person identifier. This record may need to be merged to a profile.</p>
2 records found
1
Domain-Knowledge-Driven Explainable Product Quality Prediction
Using prior knowledge to improve explanations of quality prediction models
Explainable artificial intelligence has in recent years allowed us to investigate how many machine learning methods are creating its predictions. This is especially useful in scenarios where the goal is not to predict a variable, but to explain what influences that variable. However, the methods that have been created thus far do not focus on specific domains and only give scientific relations between variables. In the case of a production process, there exist a multitude of related variables, constrained in different ways, thus requiring a more sophisticated method than those which are universally applicable. The target of this research is a bottle filling machine at a large carbonated drink manufacturer, of which a great amount of data has been stored. The product quality, in this case the amount of CO2 in the filled bottles, is subject to high amounts of fluctuation, leading to a lot of waste. To further contextualize the problem of bottle filling, an artificial dataset is created to serve as a basis for visualization and evaluation. Using literature on carbonated drink filling, multiple hypotheses were then formulated, independently from the thesis company, as a target for the evaluation process. To address the problem of determining what factors influence bottle CO2, a methodology is proposed which aims to provide explainable quality prediction of production process output, while using available domain knowledge to increase the plausibility of explanations. The methodology makes use of counterfactual explanations for tree ensembles and process state forecasting to show how a process state can be changed to yield better product quality. Evaluation on the artificial and real datasets show that the methodology is able to effectively predict the amount of CO2 in a bottle, while giving changes to the current process state which improve the product quality. It is also shown that the results produced by the methodology are in line with the formulated hypotheses. Bottle CO2 is influenced greatly by temperature changes in the filler and these temperature changes are caused by flow of cooled lemonade through the process. As these flows are dependent on the filling speed, irregular filling is suspected to be the root cause for the bottle CO2 fluctuations.
...
Explainable artificial intelligence has in recent years allowed us to investigate how many machine learning methods are creating its predictions. This is especially useful in scenarios where the goal is not to predict a variable, but to explain what influences that variable. However, the methods that have been created thus far do not focus on specific domains and only give scientific relations between variables. In the case of a production process, there exist a multitude of related variables, constrained in different ways, thus requiring a more sophisticated method than those which are universally applicable. The target of this research is a bottle filling machine at a large carbonated drink manufacturer, of which a great amount of data has been stored. The product quality, in this case the amount of CO2 in the filled bottles, is subject to high amounts of fluctuation, leading to a lot of waste. To further contextualize the problem of bottle filling, an artificial dataset is created to serve as a basis for visualization and evaluation. Using literature on carbonated drink filling, multiple hypotheses were then formulated, independently from the thesis company, as a target for the evaluation process. To address the problem of determining what factors influence bottle CO2, a methodology is proposed which aims to provide explainable quality prediction of production process output, while using available domain knowledge to increase the plausibility of explanations. The methodology makes use of counterfactual explanations for tree ensembles and process state forecasting to show how a process state can be changed to yield better product quality. Evaluation on the artificial and real datasets show that the methodology is able to effectively predict the amount of CO2 in a bottle, while giving changes to the current process state which improve the product quality. It is also shown that the results produced by the methodology are in line with the formulated hypotheses. Bottle CO2 is influenced greatly by temperature changes in the filler and these temperature changes are caused by flow of cooled lemonade through the process. As these flows are dependent on the filling speed, irregular filling is suspected to be the root cause for the bottle CO2 fluctuations.
Akka Decision Engine
An actor based decision engine on the DMN 1.1 specifications
Decision engines can decide from a certain input what the output should be. This is done in a table with columns for inputs and outputs and rows for a combination of inputs together with its corresponding output. A row is also called a rule. A simple program to decide such a decision table can easily be made, like Camunda. However, when the output of one table is also the input of another table and so on and the amount of rules get enormously big, the problem gets more complicated and Camunda takes a very long time to solve such structures.
We created a decision engine in Scala that can decide the output when there are thousands of tables linked together in less than a minute with the help of Akka. Akka is an actor model, which means that it can create multiple actors, which each can perform a certain task. Actors can run in parallel, which speeds up the decision engine. Actors send messages to each other and an actor will only start working when they receive a message. The decision engine reads DMN files and parses it to tables. For better performance the decision tables get parsed into a tree structure with for every table the input tables are its children. In this way the decision engine is very quick in solving tables, however the parsing into trees still takes some time. This is not a big problem, since the parsing is only done once and the tree can be saved and the solving can be done very often. Also the deciding of a single table is improved, because we created our own FEEL-expressions that can decide the rules very fast. The result is that after a very large table with 50,000 rules is parsed, the solving that took Camunda 400 milliseconds only takes 9 milliseconds for the new decision engine and when the parsing is left out, the new engine is faster in computing 500,000 rules than Camunda with 1 rule. Also when the parsing is included in the time, the difference gets only bigger. For 50,000 rules, Camunda takes 20 seconds to parse the file and solve the table, while the new decision engine takes only a little more than 1 second to do this all. When the files get larger, so does the difference. ...
We created a decision engine in Scala that can decide the output when there are thousands of tables linked together in less than a minute with the help of Akka. Akka is an actor model, which means that it can create multiple actors, which each can perform a certain task. Actors can run in parallel, which speeds up the decision engine. Actors send messages to each other and an actor will only start working when they receive a message. The decision engine reads DMN files and parses it to tables. For better performance the decision tables get parsed into a tree structure with for every table the input tables are its children. In this way the decision engine is very quick in solving tables, however the parsing into trees still takes some time. This is not a big problem, since the parsing is only done once and the tree can be saved and the solving can be done very often. Also the deciding of a single table is improved, because we created our own FEEL-expressions that can decide the rules very fast. The result is that after a very large table with 50,000 rules is parsed, the solving that took Camunda 400 milliseconds only takes 9 milliseconds for the new decision engine and when the parsing is left out, the new engine is faster in computing 500,000 rules than Camunda with 1 rule. Also when the parsing is included in the time, the difference gets only bigger. For 50,000 rules, Camunda takes 20 seconds to parse the file and solve the table, while the new decision engine takes only a little more than 1 second to do this all. When the files get larger, so does the difference. ...
Decision engines can decide from a certain input what the output should be. This is done in a table with columns for inputs and outputs and rows for a combination of inputs together with its corresponding output. A row is also called a rule. A simple program to decide such a decision table can easily be made, like Camunda. However, when the output of one table is also the input of another table and so on and the amount of rules get enormously big, the problem gets more complicated and Camunda takes a very long time to solve such structures.
We created a decision engine in Scala that can decide the output when there are thousands of tables linked together in less than a minute with the help of Akka. Akka is an actor model, which means that it can create multiple actors, which each can perform a certain task. Actors can run in parallel, which speeds up the decision engine. Actors send messages to each other and an actor will only start working when they receive a message. The decision engine reads DMN files and parses it to tables. For better performance the decision tables get parsed into a tree structure with for every table the input tables are its children. In this way the decision engine is very quick in solving tables, however the parsing into trees still takes some time. This is not a big problem, since the parsing is only done once and the tree can be saved and the solving can be done very often. Also the deciding of a single table is improved, because we created our own FEEL-expressions that can decide the rules very fast. The result is that after a very large table with 50,000 rules is parsed, the solving that took Camunda 400 milliseconds only takes 9 milliseconds for the new decision engine and when the parsing is left out, the new engine is faster in computing 500,000 rules than Camunda with 1 rule. Also when the parsing is included in the time, the difference gets only bigger. For 50,000 rules, Camunda takes 20 seconds to parse the file and solve the table, while the new decision engine takes only a little more than 1 second to do this all. When the files get larger, so does the difference.
We created a decision engine in Scala that can decide the output when there are thousands of tables linked together in less than a minute with the help of Akka. Akka is an actor model, which means that it can create multiple actors, which each can perform a certain task. Actors can run in parallel, which speeds up the decision engine. Actors send messages to each other and an actor will only start working when they receive a message. The decision engine reads DMN files and parses it to tables. For better performance the decision tables get parsed into a tree structure with for every table the input tables are its children. In this way the decision engine is very quick in solving tables, however the parsing into trees still takes some time. This is not a big problem, since the parsing is only done once and the tree can be saved and the solving can be done very often. Also the deciding of a single table is improved, because we created our own FEEL-expressions that can decide the rules very fast. The result is that after a very large table with 50,000 rules is parsed, the solving that took Camunda 400 milliseconds only takes 9 milliseconds for the new decision engine and when the parsing is left out, the new engine is faster in computing 500,000 rules than Camunda with 1 rule. Also when the parsing is included in the time, the difference gets only bigger. For 50,000 rules, Camunda takes 20 seconds to parse the file and solve the table, while the new decision engine takes only a little more than 1 second to do this all. When the files get larger, so does the difference.