运筹优化算法在工业场景中的应用流程

工作两年了,结合一篇综述文献(A Tutorial on the Design, Experimentation and Application of Metaheuristic Algorithms to Real-World Optimization Problems, 2021),谈谈自己对运筹优化算法在工业场景中应用的流程理解。

算法研发

文章概述了做元启发式算法研发的主要流程:数学建模->算法设计->性能评估->代码部署。
事实上,各类运筹算法,甚至其他类型的算法模型在应用时,基本都遵循以上的流程。

在数学建模阶段,目标函数、决策变量和约束条件这三要素自然是必不可少的。
类似算法耗时、解的最优性和鲁棒性等非函数式需求(non-functional requirements),也是需要明确的。
除此之外,还需要分析清楚优化模型的问题类型和复杂度,从而确定使用元启发式算法是最佳的解决方案,而不是盲目使用该类算法。

在算法设计阶段,要关注的方面包括:解编码的形式、种群形式(单点或种群)和操作算子。
如果使用现有算法框架,比如遗传算法、模拟退火算法,那么种群形式和操作算子方面可以省去一些工作。
至于最适合问题的算法框架,可以通过测算对比得到,或者根据已有经验直接给出;如果想要在此基础上做改进,甚至原创一个算法,那么操作算子才需要被认真对待。
种群形式的选择方面,也比较好判断:基于单点操作的算法,普遍速度快,适用于对计算耗时比较敏感的场景;基于种群操作的算法,更可能得到一个最优性更好的结果,更适用那些对解的质量有更高要求的场景。
最困难的应该是解编码的形式,即使针对同一个问题,也可以有很多种解编码方案,至于如何找到最佳的编码方案,目前我自己也没总结清楚,未来再琢磨吧。

在性能评估阶段,需要考虑的内容有:测试算例、评估指标、多角度多层次对比、统计检验、结果可重复。
关于测试算例,可以使用公开的测试算例,也可以自行设计测试算例。
具体评估算法性能时,除了基本的性能指标外,算法耗时、存储空间、得到可行解需要的时间等因素都应该被考虑在内。
此外,评估角度和层次也要足够充分,比如结果的最大值、最小值、平均值,结果的可视化,算法平衡全局探索(exploration)和局部开发(exploitation)的方式,算法复杂度,算法中的相关参数如何变化等。
如果算法中用到了随机函数,那么还需要通过统计的方式,如t检验或wilcoxon检验,来判断算法的性能。
不过,这一步在工业场景中,被极度简化了。
只要所开发的算法能在历史算例上得到令人满意的指标,就已经可以理解为通过性能评估了。

到了代码部署阶段,需要考虑以下因素:编程能力、使用已有优化框架、编程语言、第三方软件的版权等。
事实上,这些因素在算法设计时,大概率都已经被考虑了。
如果到了这一步才开始分析这些事项,估计项目的进度会被各种延期。

业务支持

如果扩展到对于业务场景的支持,算法研发便只是其中一个步骤。更完整的流程应该包括:明确需求->确定接口->算法研发->联调测试->局部上线->迭代扩量。

明确需求:和产品、业务沟通,明确优化问题的具体需求、了解清楚包含哪几个落地阶段,每个阶段的问题规模。只有清楚了这些,才能对算法的研发和迭代路线有个基本的方案。

确定接口:确定算法需要和哪些系统做对接,包括输入数据从哪里拿,算法结果如何透出,各类数据的数据类型等。

算法研发:包括上一节中的数学建模、算法设计、代码开发和效果评测等内容。一般情况下,除了主策略模型外,还需要设计一个兜底策略,从而保证流程的稳定性。

联调测试:测试同学加入,针对算法的各项功能进行测试,判断算法是否能够在各种极端输入数据下,正常返回结果。测试同学如果只关心是否透出了结果,我们还需要自行确认结果的合理性。

局部上线:首次研发的算法,不太可能直接在全量场景下应用。产品会选择在某个局部范围内做上线测试。

迭代扩量:算法上线后,算法人员还会继续对算法做迭代优化,可能的层面包括:提升算法的稳定性,如修复线上出现的badcase;提升算法优化性能,如解的质量、计算的速度等;同时产品推动算法从局部试点到全量应用。

业务驱动

如果说算法研发和业务支持更偏向被动完成任务,那么业务驱动更像是主动推动。
举个例子吧,算法本来仅在左下图中的黄色圆角矩形中做功,那么业务驱动可以是调整做功是模式,比如将圆角矩形变为矩形;或者将圆角矩形和前面的三角形组合在一起做功。
不过这一层次对我来说,也超纲了。

猜你喜欢

转载自blog.csdn.net/taozibaby/article/details/127355348