Rework ML components

Summary

(Summarise what the new feature should be)

Component

surrogate.*

Expected Behavior

The machine learning capabilities of EvoAl are limited at the moment. EvoAl should support more ML algorithms and data pre- and post-processing capabilities. The pre- and post-processing capabilities should be extensible, and their task is data normalisation, data filtering, data validation, data manipulation, and so on. Thus, this is similar to the data generation problem. Therefore, extracting this to some data pipeline meta-algorithm that can be used in both use cases would be a great idea. Parts of such a pipeline must also be used in the surrogate use case since data normalisation has to be used before the learning (to normalise data), before the prediction (to normalise the data in the same way), and after the prediction to denormalise the data again.

/cc @berber

added feature discussion labels

We have two students working on ML-algorithms at the moment. @sghosh is supposed to add two types of neural networks, and @maubur is still deciding on two techniques, he will add (e.g. Gaussian Processes and Random Forest). @phikla is researching the parameter constraints on different ML-algorithms and will use them for internal semantic checking.

The rework will not fundamentally change the framework. It's more about making things explicit. For instance, the SVR code does an automatic data normalisation. This is some "magic" I don't like as it means that it cannot be reused for, e.g., neural nets. But it is great that all of us are part of the planning and communication channel.

mentioned in issue #120 (closed)

marked this issue as related to #120 (closed)

What pipeline components do we need? @berber already listed some of them, maybe we can extend the list to specify the necessary tasks for this issue.

• generate data according to some distribution
• compute data, given some function and some input data (include benchmark generation, but also noise addition (also a function)
• perform operation on data (e.g. normalise data)
• validate data (check against descriptions) - do you see that as valid component?

Model training is missing, but I am not quite sure, whether this could be part of "perform operation on data". Please feel free to add aspects that might be missing.

I have made some notes on my sketch book on this topic. If we define the pipeline model properly, we can make the training (and prediction) part of the pipeline. We have to separate the application and the technical domain. The training part would then be a sink that consumes the domain data and produce the model as some technical domain artifact.

I didn't mean that model training and prediction could not be part of the pipeline. It was more of a question, whether prediction isn't the same as 'compute data' (because a function is applied to a value) and training isn't the same as 'perform operation on data'.

Yes, that's correct. That's the nice part of a good model: Everything is getting very simple. ;)

added componentgenerator label

added componentmachine-learning label and removed componentgenerator label

mentioned in issue #132 (closed)

A possible model of the pipeline idea:

changed milestone to %EvoAl Release 2025.4.0

added componentoptimisation workflowplanned labels and removed componentmachine-learning workflowdiscussion labels

One downside of our scoped labels: We cannot add multiple components: "componentgenerator" "componentmachine-learning" and "componentmachine-learning" are related to this issue.