Does OptaPlanner have a "built-in" way to perform multi-unit score normalization?

Question

At the moment, my problem has four metrics. Each of these measures something entirely different (each has different units, a different range, etc.) and each is weighted externally. I am using Drools for scoring.

I only have only one score level (SimpleLongScore) and I have to find a way to appropriately combine the individual scores of these metrics onto one long value

The most significant problem at the moment is that the range of values for the metrics can be wildly different.

So if, for example, after a move the score of a metric with a small possible range improves by, say, 10%, that could be completely dwarfed by an alternate move which improves the metric with a larger range's score by only 1% because OptaPlanner only considers the actual score value rather than the possible range of values and how changes affect them proportionally (to my knowledge).

So, is there a way to handle this cleanly which is already part of OptaPlanner that I cannot find?

Is the only feasible solution to implement Pareto scoring? Because that seems like a hack-y nightmare.

So far I have code/math to compute the best-possible and worst-possible scores for a metric that I access from within the Drools and then I can compute where in that range a move puts us, but this also feel quite hack-y and will cause issues with incremental scoring if we want to scale non-linearly within that range.

I keep coming back to thinking I should just just bite the bullet and implement Pareto scoring.

Thanks!

Answer 1

Take a look at @ConstraintConfiguration and @ConstraintWeight in the docs.

Also take a look at the chapter "explaning the score", which can exactly tell you which constraint had which score impact on the best solution found.

If, however, you need pareto optimization, so you need multiple best solutions that don't dominate each other, then know that OptaPlanner doesn't support that yet, but I know of 2 cases that implemented it in OptaPlanner by hacking BestSolutionRecaller.

That being said, 99% of the cases that think of pareto optimization, are 100% happy with @ConstraintWeight instead, because users don't want multiple best solutions (except during simulations), they just want one in production.