OptaPlanner：匹配权重得分平方化的适用场景与原因

我在OptaPlanner（简称OP）的示例中发现，匹配权重被做了平方处理，比如这段代码：

private Constraint minimizeMakespan(ConstraintFactory constraintFactory) {
        return constraintFactory.forEach(Employee.class)
                .penalize(BendableScore.ofSoft(BENDABLE_SCORE_HARD_LEVELS_SIZE, BENDABLE_SCORE_SOFT_LEVELS_SIZE, 1, 1),
                        employee -> employee.getEndTime() * employee.getEndTime())
                .asConstraint("Minimize makespan, latest ending employee first");
    }

我知道评分函数的作用是减少或避免分数陷阱，但想搞清楚：什么时候需要考虑对得分做平方处理？有没有可以遵循的经验法则？

何时使用平方处理评分？ #

平方处理的核心是给「更大的偏差」施加非线性的惩罚/奖励权重，让优化算法优先聚焦影响更大的问题，适用场景主要有三类：

• 优先压缩极端值：比如上述任务分配示例，目标是最小化最大完工时间（Makespan）。线性惩罚（直接用employee.getEndTime()）会让算法倾向于均匀缩短所有员工的完工时间；而平方后，完工时间越长的员工，惩罚力度呈指数级增长，算法会优先优化最晚下班的员工，更贴合「最小化最大完工时间」的真实目标。

• 打破局部最优陷阱：当线性评分容易让算法卡在局部最优时，平方的非线性权重能打破平衡。比如某些调度场景，线性评分下调整小偏差的收益和调整大偏差的收益差距不大，算法可能会停滞；平方后，大偏差的调整收益被放大，算法会主动去优化这些关键点，跳出局部最优。

• 匹配非线性的业务规则：如果业务中偏差造成的损失/收益是非线性增长的（比如延迟1天损失100，延迟2天损失400而非200），平方评分就能精准贴合这种业务逻辑。

经验法则 #

• 先线性后非线性：不要一开始就用平方处理，先尝试线性评分，观察算法输出是否符合预期。只有当线性评分无法聚焦极端值或陷入局部最优时，再考虑引入平方。

• 测试权重平衡：平方会放大数值差异，要测试不同数据规模下，平方后的约束权重是否会过度压制其他重要约束。如果出现这种情况，可以通过调整系数（比如给平方结果乘以一个小于1的系数）来平衡各约束的优先级。

• 对齐业务目标的非线性程度：如果业务损失/收益和偏差是线性关系，就没必要用平方；只有当业务规则明确是非线性时，再对应使用平方或更高次幂的处理。

内容的提问来源于stack exchange，提问作者Justin Phillips