
本文旨在探讨OptaPlanner在面对无法为所有规划实体找到可行解时,如何避免强制分配并允许某些实体保持未分配状态。核心解决方案是利用OptaPlanner的“过约束规划”能力,通过配置“可空规划变量”来明确允许规划实体不被赋值,并结合适当的约束和评分策略,确保生成满足业务逻辑且高质量的解决方案。
在资源调度和分配场景中,我们经常会遇到这样的需求:将一组资源(例如销售代表)分配给一组任务(例如预约)。然而,由于各种限制(如时间冲突、技能不匹配、容量限制等),可能并非所有任务都能被成功分配到资源。OptaPlanner作为一个强大的自动规划引擎,其默认行为是尝试为所有规划实体(Planning Entity)的规划变量(Planning Variable)赋值。当没有可行解时,它可能会强制分配一个值,导致最终解决方案中出现硬约束(Hard Constraint)违规,从而使整个方案变得不可用。
例如,在一个销售代表与预约的分配场景中,如果某个销售代表在特定时间段内无法接受任何预约,或所有销售代表在该预约的时间段内都已满,我们期望OptaPlanner能够识别这种情况,并选择不为该预约分配任何销售代表,而不是强行分配一个导致冲突的销售代表。
OptaPlanner的核心目标是找到一个最优的解决方案,即满足所有硬约束并最大化软约束分数的解决方案。在默认情况下,当一个规划变量被定义时,OptaPlanner会从其值域中选择一个值进行分配。如果一个规划变量的值域中没有能够满足所有硬约束的值,OptaPlanner仍然会尝试选择一个,这通常会导致硬约束违规。
用户可能会尝试使用 SolverConfig 中的 withBestScoreFeasible(true) 配置。这个配置的目的是确保求解器返回的最终解决方案必须是“可行”的,即不包含任何硬约束违规。然而,它本身并不能解决“不分配”的问题。如果模型中没有明确允许规划变量为 null 或表示“未分配”的状态,withBestScoreFeasible(true) 只能确保在存在硬约束违规的解时,该解不会被认为是最佳解,但它不会主动创造一个“未分配”的状态。
为了解决上述问题,OptaPlanner引入了“过约束规划”的概念,其核心机制是使用可空规划变量(Nullable Planning Variables)。通过将规划变量标记为可空,我们明确告诉OptaPlanner,该变量可以不被赋予任何来自其值域的具体值,而是可以保持为 null,表示“未分配”或“不适用”。
在您的规划实体类中,将 @PlanningVariable 注解的 nullable 属性设置为 true:
import org.optaplanner.core.api.domain.entity.PlanningEntity;
import org.optaplanner.core.api.domain.variable.PlanningVariable;
@PlanningEntity
public class Appointment {
private String uuid;
private long startTime;
private long endTime;
// ... 其他预约属性
// 销售代表是规划变量
private SalesRep salesRep;
// 配置 salesRep 为可空规划变量
@PlanningVariable(valueRangeProviderRefs = {"salesRepRange"}, nullable = true)
public SalesRep getSalesRep() {
return salesRep;
}
public void setSalesRep(SalesRep salesRep) {
this.salesRep = salesRep;
}
// ... getters and setters for other fields
}在上述代码中,@PlanningVariable(valueRangeProviderRefs = {"salesRepRange"}, nullable = true) 告诉OptaPlanner:
注意事项:
当引入可空规划变量后,您的约束逻辑也需要相应调整,以正确处理 null 值,并引导求解器做出合理的分配决策。
对于防止冲突的硬约束,您需要确保它们在处理 null 值时不会抛出异常,并且只对已分配的实体进行检查。
示例:销售代表冲突约束
import org.optaplanner.core.api.score.buildin.hardsoft.HardSoftScore;
import org.optaplanner.core.api.score.buildin.hardmediumsoft.HardMediumSoftScore;
import org.optaplanner.core.api.score.stream.Constraint;
import org.optaplanner.core.api.score.stream.ConstraintFactory;
import org.optaplanner.core.api.score.stream.Joiners;
public class RepSchedulerConstraintProvider implements ConstraintProvider {
@Override
public Constraint[] defineConstraints(ConstraintFactory constraintFactory) {
return new Constraint[]{
repConflict(constraintFactory),
penalizeUnassignedAppointment(constraintFactory) // 新增的软约束
};
}
Constraint repConflict(ConstraintFactory constraintFactory) {
// 一个销售代表不能在同一时间段内处理多个预约。
return constraintFactory
// 选择每对不同的预约...
.forEachUniquePair(Appointment.class,
Joiners.equal(Appointment::getSalesRep)) // 注意这里是 getSalesRep
.filter((appt1, appt2) -> {
// 如果任一预约未分配,则不检查冲突
if (appt1.getSalesRep() == null || appt2.getSalesRep() == null) {
return false;
}
// 检查时间冲突
boolean appt1StartsBeforeAppt2Ends = appt1.getStartTime() < appt2.getEndTime();
boolean appt2StartsBeforeAppt1Ends = appt2.getStartTime() < appt1.getEndTime();
// 如果两个预约的时间段有重叠,则返回 true 表示冲突
return appt1StartsBeforeAppt2Ends && appt2StartsBeforeAppt1Ends;
})
// ...并对每个冲突对施加硬惩罚。
.penalize(HardSoftScore.ONE_HARD)
.asConstraint("SalesRep conflict");
}
}在 repConflict 约束中,我们添加了 if (appt1.getSalesRep() == null || appt2.getSalesRep() == null) { return false; } 逻辑,确保只有当两个预约都被分配了销售代表时,才进行时间冲突检查。
仅仅允许 null 值是不够的,您还需要通过软约束来引导求解器尽可能多地进行分配,或者惩罚那些未被分配的实体。这通常通过一个软约束来实现。
示例:惩罚未分配的预约
// 在 RepSchedulerConstraintProvider 中添加
Constraint penalizeUnassignedAppointment(ConstraintFactory constraintFactory) {
return constraintFactory.forEach(Appointment.class)
.filter(appointment -> appointment.getSalesRep() == null) // 筛选出未分配销售代表的预约
.penalize(HardSoftScore.ONE_SOFT) // 对每个未分配的预约施加软惩罚
.asConstraint("Penalize unassigned appointment");
}这个软约束会使得那些未被分配销售代表的预约导致解决方案的软分数降低。OptaPlanner会努力提高软分数,因此它会优先尝试分配销售代表,但只有在不违反任何硬约束的前提下。如果分配会导致硬约束违规,那么保留 null 并接受软惩罚将是更好的选择。
您也可以使用 reward 方式来奖励成功分配的预约,效果类似:
// 奖励成功分配的预约 (Alternative to penalizing unassigned)
Constraint rewardAssignedAppointment(ConstraintFactory constraintFactory) {
return constraintFactory.forEach(Appointment.class)
.filter(appointment -> appointment.getSalesRep() != null) // 筛选出已分配销售代表的预约
.reward(HardSoftScore.ONE_SOFT) // 对每个已分配的预约施加软奖励
.asConstraint("Reward assigned appointment");
}这两种方法(惩罚未分配或奖励已分配)都可以达到相同的目的:在硬约束允许的范围内,尽可能多地进行分配。
当您使用了可空规划变量并定义了适当的硬约束和软约束后,withBestScoreFeasible(true) 的作用将变得更加清晰和有效。
SolverFactory<RepRoutingSolution> solverFactory = SolverFactory.create(new SolverConfig()
.withSolutionClass(RepRoutingSolution.class)
.withEntityClasses(Appointment.class)
.withConstraintProviderClass(RepSchedulerConstraintProvider.class)
.withTerminationConfig(new TerminationConfig()
.withBestScoreFeasible(true) // 确保最终解是可行的
)
.withTerminationSpentLimit(Duration.ofSeconds(5)));结合 nullable = true 和 withBestScoreFeasible(true):
这样,OptaPlanner将能够智能地在“分配一个销售代表并满足所有硬约束”与“不分配销售代表但接受软惩罚”之间做出权衡,从而生成一个既可行又高质量的解决方案。
处理OptaPlanner中无法分配的规划实体是一个常见的需求,尤其是在资源受限或过约束的场景中。以下是最佳实践总结:
通过遵循这些原则,您可以有效地利用OptaPlanner处理复杂的过约束规划问题,生成既符合业务规则又高度优化的解决方案。
以上就是OptaPlanner处理无法分配的规划实体:实现过约束规划与可空规划变量的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号