使用 Optaplanner 同时满足硬约束和中等约束的难度

Question

我使用 OptaPlanner 6.2 实现了一个传感器调度问题，该问题具有 1 个硬约束、1 个中等约束和 1 个软约束。我遇到的麻烦是，我可以在 30 秒左右后满足一些硬约束，然后求解器在满足它们的约束方面进展甚微，需要额外的终止时间。我认为问题并没有受到过度限制。我也不知道如何帮助本地搜索过程显着提高分数。

我的问题是调度问题，我预先计算了传感器在解决之前可以观察对象的所有可能时间（间隔）。我将问题建模如下：

1. 硬约束 - 间隔不能重叠

    when
      $s1: A( interval!=null,$id: id, $doy : interval.doy, $interval: interval, $sensor: interval.getSensor())
     exists A( id > $id, interval!=null, $interval2: interval, $interval2.getSensor() == $sensor, $interval2.getDoy() == $doy, $interval.getStartSlot() <= $interval2.getEndSlot(), $interval.getEndSlot() >= $interval2.getStartSlot() )
    then
      scoreHolder.addHardConstraintMatch(kcontext,-10000);
   

2. 中等约束 - 每个作业都应该有一个间隔

   when
     A(interval==null)
   then
     scoreHolder.addMediumConstraintMatch(kcontext,-100);
   

3. 软约束 - 最大化 Interval 类中的属性/值

   when
     $s1: A( interval!=null)
   then
     scoreHolder.addSoftConstraintMatch(kcontext,-1 * $s1.getInterval().getSomeProperty())
   

A：实体规划类；每个实例都是对特定对象的赋值（即有一个成员 objectid 与 Interval 类中的一个对应）

间隔：规划变量类，传感器和对象的所有可能间隔（开始时间，停止时间）

在 A 中，我将对 B 实例（间隔）的访问限制为仅与该分配关联的对象的访问。对于我的测试用例，有 40000 个左右的间隔，但每个对象只有几十个。大约有 1100 个 A 实例（因此每个实例有几十个可能的区间）。

@PlanningVariable(valueRangeProviderRefs = {"intervalRange"},strengthComparatorClass = IntervalStrengthComparator.class, nullable=true)
public Interval getInterval() {
    return interval;
}

@ValueRangeProvider(id = "intervalRange")
public List<Interval> getPossibleIntervalList() {
    return task.getAvailableIntervals();
}

在我的解决方案类中： //已尝试将其注释掉，因为整体间隔列表不适用于所有 A @ValueRangeProvider (id="intervalRangeAll") 公共列表 getIntervalList() { 返回间隔； }

@PlanningEntityCollectionProperty
public List<A> getAList() {
    return AList;
}

我查看了文档并尝试了很多方法。我的问题有点像我看过的看护和课程安排示例之间的交叉。我正在使用 FIRST_FIT_DECREASING 构造启发式。

我尝试过的：

1. 在 A.getInterval() 的计划变量注释中打开和关闭可为空
2. 延迟接受，禁忌，两者都有。
3. 基准测试。我没有看到任何问题和平均水平
4. 将 IntervalChangeFactory 添加为 moveListFactory。将自定义 ChangeMove 限制为是否可以接受间隔（即是否强制执行 IntervalChangeMove.isDoable 中的硬约束）。

这是一个示例，其中大多数硬约束不满足，但中等的有：

[main] INFO org.optaplanner.core.impl.solver.DefaultSolver - Solving  started: time spent (202), best score (0hard/-112500medium/0soft), environment  mode (REPRODUCIBLE), random (WELL44497B with seed 987654321).
[main] INFO org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase - Construction Heuristic phase (0) ended: step total (1125), time spent (2296), best score (-9100000hard/0medium/-72608soft).
[main] INFO org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase - Local Search phase (1) ended: step total (92507), time spent (30000), best score (-8850000hard/0medium/-74721soft).
[main] INFO org.optaplanner.core.impl.solver.DefaultSolver - Solving ended: time spent (30000), best score (-8850000hard/0medium/-74721soft), average calculate count per second (5643), environment mode (REPRODUCIBLE).

所以我不明白为什么搜索过程无法处理硬约束。由于我所做的所有修补工作，我每秒的计算次数已降至 10000 以下。

Answer 1

如果不是由于 分数陷阱（请参阅文档，这是首先要解决的问题），可能是因为它陷入了局部最优，并且没有从 1 开始的移动可行解决方案到另一个可行解决方案，除了那些并没有太大变化的解决方案。有几种方法可以解决这个问题：

• 添加粗粒度动作（但仍保留 ChangeMove 等细粒度动作！）。您可以添加通用路线颗粒移动（例如支柱移动）或添加自定义移动。不要开始制作更智能的选择器来尝试只选择可行的移动，这是一个坏主意（因为它会杀死你的 ACC 或会限制你的搜索空间）。只需混合粗粒度的动作（= 多样化）来补充细粒度的动作（= 强化）。
• 更好的域模型也可能会有所帮助。项目作业调度和廉价时间调度示例具有一个域模型，该模型自然会导致更小的搜索空间，同时仍然允许所有可行的解决方案。
• 增加禁忌列表大小、LA 大小或在 SA 起始温度中使用硬约束。但我想你已经用基准测试器尝试过。
• 打开TRACE 日志以查看 optaplanner 的决策。只看局部最优后的部分。
• 将来，我还会添加 Ruin&Recreate 动作，这将比自定义动作或更好的域模型少得多的代码（但效率会更低）。