ProblemFactCollectionProperty 中事实的顺序对于 Optaplanner 中的解决方案很重要

Question

我遇到问题，我需要将 java Money 值分配给我的实体，并在我的

PlanningEntity

中使用这个非常基本的想法：

@ProblemFactCollectionProperty
@ValueRangeProvider(id = "amountFacts")
private Set<Money> amountFacts;

@PlanningVariable(valueRangeProviderRefs = "amountFacts")
private Money amount;

大多数时候这工作得很好，但是，我遇到了一个特定的问题，即规划者未能找到（可能的）工作解决方案。

奇怪的部分： 如果我用

Set

替换

List

，Optaplanner 确实找到了解决方案。 我已经仔细检查过，事实保持不变。如果我对

List

进行排序，它再次无法找到解决方案。因此，是否找到解决方案有时似乎取决于事实集合中事实的顺序。

不幸的是，增加超时时间以给计划者更多时间并没有帮助。

Answer 1

OptaPlanner（以及 Timefold Solver，OptaPlanner 的延续）在其默认配置下是完全可重现的。如果您在同一数据集上使用相同的配置运行两次，您应该得到两个相同的结果。然而，Java 中存储的数据却并非如此

Set

。

在 Java 中，

Set

具有未定义的迭代顺序。这意味着，对于 A 和 B 的集合，有时 A 会先出现，有时会是 B。求解器按顺序读取这些项，并且它在搜索空间中选择的方式将由此迭代顺序定义。特定的迭代顺序可能会找到一个好的解决方案，而不同的迭代顺序可能会在稍后找到相同的解决方案，或者可能永远不会。

即使配置为完全可重现的求解器实际上也是不可重现的，因为

Set

的迭代顺序是不可重现的。有了

List

，你就有了一个可重现的迭代顺序，并且在你的特定情况下纯粹是巧合，该迭代顺序会带来一个好的解决方案，而其他一些迭代顺序则不会。

这实际上与为求解器选择不同的随机种子是一样的。如果您尝试这样做，您会发现某些种子比其他种子产生更好的结果。也就是说，无法预测哪种种子最好。最小化此问题的方法是信任算法 - 使用多种选择的移动配置求解器，确保约束中没有分数陷阱，并给它足够的时间进行搜索。