VRP求解器中AddDisjunction使用未达预期效果的问题咨询

你遇到的求解器优先丢弃低需求小节点的问题，核心是节点丢弃惩罚的设置逻辑和其他成本维度没有对齐，OR-Tools的路由求解器会全局最小化所有成本的总和，当丢弃多个小节点的总惩罚低于丢弃单个大节点的惩罚、或是低于容纳小节点需要多付出的行驶/车辆成本时，就会出现你看到的异常结果。

• 校准惩罚值计算逻辑
  不要按节点统一设置固定惩罚，把惩罚值和节点需求绑定：公式参考为 节点惩罚 = 优先级系数 * 节点需求。比如t=0时段的a类节点优先级系数设为10000，需求为1的话惩罚就是10000，需求为8的c类节点优先级系数设为1000的话惩罚就是8000，这样相同容量下丢弃1个c节点的惩罚比丢弃8个a节点还低，求解器自然会优先保留低需求的a、b类节点。
• 调高丢弃成本的全局权重
  调用求解器的成本缩放接口，确保丢弃惩罚的整体量级远高于车辆行驶成本、车辆启用成本，避免求解器为了节省少量行驶里程就主动丢弃节点，匹配你「优先接入更多节点」的优化目标。
• 高优先级节点硬约束兜底
  如果a、b类节点的履约优先级极高，可以先统计所有a、b类节点的总需求，只要总需求小于所有车辆的可用容量总和，就直接移除这类节点的Disjunction设置，改为必须接入的硬约束，从根源避免被求解器丢弃。
• 软约束补充适配多车辆场景
  你之前单车辆场景用的AddSoftSameVehicleConstraint也可以适配多车辆场景，额外给a、b类节点添加接入奖励（相当于设置负的软约束成本），数值和你设置的Disjunction惩罚对齐，双重保障高优先级小节点的接入顺序。

内容的提问来源于stack exchange，提问作者Anupama Sekar