一、前言
今年开年那会还在做一个课题的实验，那时候想用large neighborhood search来做一个问题，但是后来发现常规的一些repair、destroy算子效果并不是很好。后来才知道，large neighborhood search以及它的衍生算法，这类框架给人一种非常通用的感觉，就是无论啥问题都能往里面套。
往往的结果是套进去效果也是一般。这也是很多刚入行的小伙伴经常喜欢干的事吧，各种算法框架套一个问题，发现结果不好了就感觉换下一个。最后复现了N多个算法发现依然no process，这时候就会怀疑人生了。其实要想取得好的performance，肯定还是要推导一些问题特性，设计相应的算子也好，邻域结构也好。
好了，回到正题。当时我试了好几个large neighborhood search算子，发现没啥效果的时候，心里难受得很。那几天晚上基本上是转辗反侧，难以入眠，当然了是在思考问题。然后一个idea突然浮现在我的脑瓜子里，常规的repair算子难以在问题中取得好的performance，是因为约束太多了，插入的时候很容易违背约束。在不违背约束的条件下又难以提升解的质量，我就想能不能插入的啥时候采取branch and bound。遍历所有的可能插入方式，然后记录过程中的一个upper bound用来删掉一些分支。
感觉是有搞头的，后来想想，这个branch的方法以及bound的方法似乎是有点难设计。然后又搁置了几天，最后没进展的时候突然找了一篇论文，是好多年前的一篇文章了。里面详细讲解了large neighborhood search中如何利用branch and bound进行插入，后来实现了以下感觉还可以。感觉这个方法还是有一定的参考价值的，因此今天就来写写（其实当时就想写了，只不过一直拖到了现在。。。）
二、large neighborhood search
关于这个算法，我在此前的推文中已经有过相应的介绍，详情小伙伴们可以戳这篇的链接进行查看：
自适应大邻域搜索(Adaptive Large Neighborhood Search)入门到精通超详细解析-概念篇
我把其中的一段话摘出来：
大多数邻域搜索算法都明确定义它们的邻域。 在LNS中，邻域是由(destroy)和(repair)方法隐式定义的。(destroy)方法会破坏当前解的一部分，而后(repair)方法会对被破坏的解进行重建。(destroy)方法通常包含随机性的元素，以便在每次调用(destroy)方法时破坏解的不同部分。
那么，解(x)的邻域(N(x))就可以定义为：首先通过利用(destroy)方法破坏解(x)，然后利用(repair)方法重建解(x)，从而得到的一系列解的集合。LNS算法框架如下：
有关该算法更详细的介绍可以参考Handbook Of Metaheuristics这本书2019版本中的Chapter 4
Large Neighborhood Search（David Pisinger and Stefan Ropke），文末我会放出下载的链接。
关于destroy算子呢，有很多种，比如随机移除几个点，贪心移除一些比较差的点，或者基于后悔值排序移除一些点等，这里我给出文献中的一种移除方式，Shaw (1998)提出的基于(relateness)进行移除：
假设需要从解中所有的(Customers)移除(n)个，它首先随机选择一个(Customer)放进(S)（已经移除的(Customer)列表）（第1行），然后迭代地（3–6行）移除剩下的(n-1)个(Customer)。 每次这样的迭代都会先从(S)中随机选择一个(Customer)，并根据相关标准对其余未移除的(Customer)进行排序（第3-4行）。 在第5行中计算要插入的新(Customer)的下标，然后插入到(S)中（第6行），直到迭代结束。 关联度的定义如Shaw（1998）所述：
其中，customer (i)和 (j)在不同的路径中时(v_{ij}=1)，否则为0。
三、branch and bound
上面讲了Large Neighborhood Search以及介绍了一个(destroy)方法，下面就是重头戏，如何利用branch and bound进行插入了。
3.1 branch
其实插入的分支方式还是挺好设计的，这玩意儿呢我将也比较难讲清楚，我就画图好了，还是基于VRP问题示例，其他问题类似，假如我们现在有这样一个解(s)：
为了演示我就不画太多点太多路径了，免得大家看得心累。
红色箭头就是能够插入的位置。现在，假如我们插入(2)（由于branch and bound是需要遍历所有可能的插入组合，因此先插入哪个后插入哪个都是可以的，但是分支定界的速度可能会受到很大的影响，这个咱们暂时不讨论）：
为了让大家看得更加清楚，我把(2)的位置用粉红色给标记出来了，一共有3条分支，有个候选的位置就有多少条分支。
现在，还剩下(4)，插入(4)的时候，我们需要继续进行分支：
55画分支树真是画死我啦（大家一定要给个赞，点个在看呀），可以看到，最后每条路径就是一个完成的解。在两个点的(partial\, solution)插入两个点最后分支完成的(completed\, solution)居然有12个！！！大家可以自行脑补下，在90个点的(partial\, solution)中插入10个点最终形成的分支会有多少。毫无疑问会很多很多，多到你无法想象。下面是DFS搜索分支树的过程：
如果要插入的客户组为空，则可以认为所有客户已经插入到solution中，形成了一个(completed\, solution)，因此判断找到的一个upper bound是否比最优的upper bound还要好，是的话就对upper bound进行更新。 否则，它会选择插入效果最好的客户，这会使目标函数下降得最大（Shaw 1998中也使用了这种启发式方法）。 然后，对所有插入客户后形成的分支按照lower bound进行排序，从lower bound低的分支开始继续往下分支（可以算是一种加速的策略）。 同样，请注意，该算法仅探索其lower bound比upper bound更好的分支。
3.2 bound
开始之前大家想想bound的难点在哪里呢？首先想想bound中最重要的两个界：upper bound和lower bound：
- lower bound是指搜索过程中一个partial solution（比如上图插入(2)后形成的3个(partial\, solution)）的目标值，因为(partial\, solution)并不能算完整的一个解，继续往下的时候只可能增加（最小化问题）或者减少（最大化问题），因此它的意思是说当前支路的最终形成解的目标值下界（最终目标值不可能比这个lower bound更好）。
- upper bound是指搜索过程中找到的一个feasible solution（比如上图插入(4)后形成的12个(completed\, solution)中满足所有约束的就是(feasible\, solution)）的目标值，如果存在某支路的lower bound比upper bound还要差，那么该支路显然是没有继续往下的必要了，可以剪去。
显然可以使用LNS在destroy之前的解的目标值作为upper bound，因为我们总是期望找到比当前解更好的解，才会去进行destroy和repair。现在的问题是如何对一个(partial\, solution)的lower bound应该怎样计算。下面讲讲几种思路：
(1) 文献中给出的思路，利用最小生成树：
这个方案我试了，但是找到的lower bound实在是太低了，这个lower bound只考虑了距离因素，但问题中往往还存在时间窗等约束。因此这个方法在我当时做的问题中只能说聊胜于无。
(2) 按照greedy的方法将所有未插入的Customer插入到他们最好的位置上，形成一个(completed\, solution)，然后该(completed\, solution)的目标值作为lower bound。
但是这个lower bound是有缺陷的，因为很难保证不会错过某些比较有潜力的分支。
(3) 直接利用当前的(partial\, solution)的目标值作为lower bound，也比较合理。但是该值往往太低了，这可能会导致要遍历更多的分支，消耗更多时间。
以上就是一些思路，至于有没有更好的bound方法，我后面也没有往下深究了。当时实现出来以后效果是有的，就是时间太长了，然后也放弃了。
当然这篇paper后面也给了一个利用LDS进行搜索以加快算法的速度，这里就不展开了，有空再说。感兴趣的小伙伴可以去看看原paper，我会放到留言区的。
四、代码环节
代码实现放两个，一个是我当时写的一个DFSEXPLORER，采用的是思路2作为bound的，（代码仅仅提供思路）如下：
private void DFSEXPLORER5(LNSSolution node, LNSSolution upperBound, int dep) {
Queue<LNSSolution> queue = new LinkedList<LNSSolution>();
LNSSolution s_c_ = node;
queue.add(s_c_);
int es = 1;
while (!queue.isEmpty()) {
s_c_ = queue.remove();
//v是一个完整的解
if(s_c_.removalCustomers.isEmpty()) {
if(s_c_.cost < upperBound.cost && Math.abs(s_c_.cost-upperBound.cost)>0.001) {
//System.out.println("new found > "+s_c_.cost+" feasible = "+s_c_.feasible());
upperBound.cost = s_c_.cost;
upperBound.routes = s_c_.routes;
}
}else {
//System.out.println("l > "+s_c_.removalCustomers.size() + " cost = "+s_c_.cost);
double minIDelta = Double.POSITIVE_INFINITY;
int minIndex = -1;
Customer c=null;
for(int i = 0; i < s_c_.removalCustomers.size(); ++i) {
Customer cu = s_c_.removalCustomers.get(i);
double d1 = s_c_.minInsertionDeltas[cu.getCustomerNo()];
if(minIDelta > d1) {
minIDelta = d1;
c = cu;
minIndex = i;
}
}
ArrayList<LNSSolution> neighborI_c = new ArrayList<LNSSolution>();
for( int i = 0; i < s_c_.routes.length; ++i) {
Route route = s_c_.routes[i];
if(!MyUtil.checkCompatibility(c, route.getAssignedVehicle())) {
continue;
}
for (int j = 0; j <= route.getCustomersLength(); j++) {
LNSSolution s_i = s_c_.solClones();
s_i.insertCustomer(s_i.routes[i], s_i.removalCustomers.get(minIndex), j, minIndex);
//updateIDAfterOneInserted(s_i, s_i.routes[i]);
//s_i.calcLowerBound();
double o_c = s_i.lb;
updateInsertionDelta(s_i);
double n_c = s_i.lb;
//if(o_c != n_c)System.out.println("o = "+o_c+" n = "+n_c);
neighborI_c.add(s_i);
}
}
Collections.sort(neighborI_c);
for(LNSSolution s:neighborI_c) {
//System.out.println("lBound "+s.lb+" upperBound = "+upperBound.cost);
//updateInsertionDelta(s);
//s.calcLowerBound();
if(s.lb < upperBound.cost /*&& dep > 0*/) {
//System.out.println("lBound "+s.lb+" upperBound = "+upperBound.cost);
//System.out.println(s.removalCustomers.size());
queue.add(s);
es++;
dep--;
}
}
}
}
//System.out.println(es);
}
第二个是GitHub上找到的一个人复现的，我已经fork到我的仓库中了：
https://github.com/dengfaheng/vrp
这个思路bound的思路呢没有按照paper中的，应该还是用的贪心进行bound。看起来在R和RC系列的算例中效果其实也一般般，因为用了LDS吧可能。下面是运行的c1_2_1的截图：
导入idea或者eclipse后等他安装完依赖，运行下面的文件即可，更改算例的位置如图所示：
这个思路是直到借鉴的，大家在用LNS的时候也可以想想有什么更好的bound方法。
欲下载本文相关的完整代码及算例，请关注公众号【程序猿声】，查看相应推文留言区即可
