optaplanner学习笔记(十）约束配置：动态调整约束权重

概要

为每个约束确定正确的权重和级别并不容易。因为各个约束之间存在优先级平衡的情况。此外，量化软约束的影响对我们来说通常是一种全新的体验，因此他们需要多次调整才能找到一个适合的权重和级别。

提供一个 UI 来调整约束权重，并将求解的结果可视化，以便可以自己调整约束条件的权重：

5.1。创建约束配置

首先，创建一个新的类来保存约束权重和其他约束参数。用@ConstraintConfiguration注解。

@ConstraintConfiguration
public class ConferenceConstraintConfiguration {...
}

每个PlanningSolution规划解决方案将有一个这个类的实例。规划解决方案和约束配置具有一对一的关系，但它们有不同的目的，因此它们不会合并到一个类中。一个@ConstraintConfiguration类可以扩展一个父@ConstraintConfiguration类，这在许多例子中是很有用。

在PlanningSolution规划解决方案上添加ConstraintConfig约束配置，并用@ConstraintConfigurationProvider在该字段或属性上添加注释，

@PlanningSolution
public class ConferenceSolution {@ConstraintConfigurationProviderprivate ConferenceConstraintConfiguration constraintConfiguration;...
}

@ConstraintConfigurationProvider注解自动将constraintConfiguration作为一个ProblemFact，所以不需要添加@ProblemFactProperty注解。

ConstraintConfiguration类持有Constraint的权重，但它也可以持有Constraint的参数。例如，在会议安排中，最小会议间隔时间约束有一个约束权重（像其他约束一样），但它也有一个约束参数，定义了同一发言人的两个演讲之间的最小间隔时间。这个间隔时间长度取决于会议：在一些大型会议中，20分钟还不够从一个房间走到另一个房间。这个间隔时间长度是约束配置中的一个field字段，没有@ConstraintWeight注解。

5.2. 为每个约束添加一个约束权重

在ConstraintConfiguration类中，为每个约束添加一个@ConstraintWeight字段或属性。

@ConstraintConfiguration(constraintPackage = "...conferencescheduling.score")
public class ConferenceConstraintConfiguration {@ConstraintWeight("Speaker conflict")private HardMediumSoftScore speakerConflict = HardMediumSoftScore.ofHard(10);@ConstraintWeight("Theme track conflict")private HardMediumSoftScore themeTrackConflict = HardMediumSoftScore.ofSoft(10);@ConstraintWeight("Content conflict")private HardMediumSoftScore contentConflict = HardMediumSoftScore.ofSoft(100);...
}

ConstraintConfiguration的类型必须与PlanningSolution的Score相同的分数类。例如在会议安排例子中，ConferenceSolution.getScore()和ConferenceConstraintConfiguration.getSpeakerConflict()都返回HardMediumSoftScore。

一个ConstraintWeight不能为null。给每个ConstraintWeight一个默认值，但在界面中可以修改，以便对它们进行调整。上面的例子使用ofHard()·、ofMedium()和ofSoft()方法来实现。
每个约束都有一个ConstraintPackage约束包和一个ConstraintName约束名称，它们共同构成了ConstraintID约束的ID。它们将约束的Weight与约束的实现联系起来。对于每个ConstraintWeight，必须有一个具有相同包和相同名称的约束实现。

@ConstraintConfiguration注解有一个constraintPackage属性，默认为约束配置类的包。大多数使用Drools 分数计算的情况需要覆盖它，因为 DRL 使用另一个包。比如下面的 DRL 使用了 package …conferencescheduling.score，所以上面的约束配置指定了一个constraintPackage. 具有约束流的情况，通常不需要指定它。
@ConstraintWeight注释有一个这值，是约束名称（例如“扬声器冲突”）。它从 @ConstraintConfiguration继承约束包，但它可以覆盖它，例如@ConstraintWeight(constraintPackage = “…region.france”, …) 来使用与其他一些权重不同的约束包。

所以每个ConstraintWeight约束权重最后都有一个ConstraintPackage约束包和一个ConstraintName约束名称结束。每个ConstraintWeight约束权重都与一个约束实现相关联，例如在Drools 分数计算中：

package ...conferencescheduling.solver;rule "Speaker conflict"when...thenscoreHolder.penalize(kcontext);
endrule "Theme track conflict"when...thenscoreHolder.penalize(kcontext, ...);
endrule "Content conflict"when...thenscoreHolder.penalize(kcontext, ...);
end

每个ConstraintWeight都定义了其约束的ScoreLevel和ScoreWeight。约束的实现调用reward()或policize()，约束的权重就会自动匹配。

如果约束实现提供了一个匹配权重，那么该MatchWeight匹配权重将与ConstraintWeight约束权重相乘。例如， content conflict 约束权重默认为100soft，约束实现根据共享内容标签的数量来惩罚每个匹配的结果：

@ConstraintWeight(“Content conflict”)
private HardMediumSoftScore contentConflict = HardMediumSoftScore.ofSoft(100);

rule "Content conflict"when$talk1 : Talk(...)$talk2 : Talk(...)thenscoreHolder.penalize(kcontext,$talk2.overlappingContentCount($talk1));
end

因此，当2个冲突内容只共享1个内容标签时，得分会受到-100soft的影响。但是，当2个冲突内容共享3个内容标签时，匹配权重为3，所以分数会受到-300soft的影响。