做生产计划时，模型里填了原料和设备工时，求解日志却指向某个产品变量，提示无界。回头翻建模代码，那条产能约束也确实写了，只是生成约束时漏掉了这个产品。理解“CPLEX模型无界是什么意思CPLEX模型无界怎么排查”，可以从一个具体问题入手：哪些变量还能继续变化，模型里又有没有一条有效的限制能把它们拦住？

　　一、CPLEX模型无界是什么意思

　　对已经确认可行的模型，无界表示目标还能一直改善，没有有限的最优值。利润最大化时，目标值可以不断增大；成本最小化时，目标值则可以不断减小。

　　1、用一个变量看懂无界

　　拿产量做例子。产量可以是零，也可以增加。如果每多生产一件都能增加目标收益，模型里又没有资源、需求或产量上限，求解器就找不到该在哪个产量停下来。

　　①在测试模型中建立连续变量【x】，下界设为【0】，不设有限上界，将目标设为【最大化x】，运行求解。

　　②给测试模型补上【x≤100】，保留原目标，再次求解。对照两次的求解状态和目标值。

　　2、区分无界和不可行

　　①查看完整求解日志。使用Concert接口时，也可通过【getStatus】读取状态，区分【Unbounded】、【Infeasible】和【InfeasibleOrUnbounded】。

　　②若还没确认原模型是否可行，在副本里把【目标函数】改为常数【0】，保留约束、变量边界和整数要求，再求解一次。

　　不可行表示没有任何一组变量取值能同时满足要求。无界状态则说明CPLEX找到了可以持续改善目标的方向，但这个状态本身不保证求解器已经证实存在可行点。原模型报无界或不可行或无界时，零目标副本找到可行解，可以确认约束本身允许解；若副本被证明不可行，就转查约束冲突。副本若只是超时且没找到解，还不能据此判断。

　　二、CPLEX模型无界怎么排查

　　排查时优先看本次实际提交给CPLEX的模型。建模代码里有某条约束，不代表每个产品、仓库或时段都生成了对应的约束行。

　　1、导出本次求解用的模型

　　①在触发异常的数据和参数下导出【.lp】文件。使用Concert接口时，可调用【exportModel】导出，再把同一次运行的日志留在旁边。

　　②如果日志点名了某个变量，在【.lp】文件中搜索完整变量名，把它在目标函数、约束和【Bounds】中的位置都找出来。变量带有产品或时段索引时，按完整名称查，避免查到相邻变量。

　　2、沿着能改善目标的方向查边界

　　变量出现在约束里，也可能没有被那条约束限制住。比如产量越大收益越高，而模型只要求产量不低于订单量，那么超过订单量之后仍可以继续增加。

　　①在【.lp】文件的目标段核对求解方向和该变量的系数符号，再到【Bounds】检查对应方向的边界。若变量标为【free】，正负两个方向都要查。

　　②逐条查看含有该变量的约束，核对不等号、系数正负和右端数据。遇到【x≥100】这类约束时，回到业务定义，确认它表达的是保底产量还是产量上限。

　　3、检查多个变量是否能一起增长

　　①在【.lp】文件中找到与可疑变量出现在同一条平衡约束里的变量，核对它们各自的目标系数与边界。

　　②检查变量一起增加或减少时，是否仍满足平衡约束，并计算这组变化对【目标函数】的净影响。

　　例如采购量等于销量，这条等式只能让两者同步。如果每多卖一件的收入超过采购成本，采购和销售又都没有上限，两者一起增加就能持续抬高利润。遇到这种情况，要回到采购能力和市场需求找缺失的限制，单看等式是否写对还不够。

　　4、在线性模型中查看无界方向

　　①如果原问题是混合整数线性模型，复制一份，将整数变量放宽为连续变量，保留原有边界，求解【线性松弛模型】。

　　②当单纯形法确认该线性模型无界，且求解结果可提供无界方向时，使用C接口的【CPXgetray】读取方向向量，再按变量列顺序核对非零分量对应的变量。

　　方向向量记录的是哪些变量可以一起变化，不是某个可直接执行的生产计划。线性松弛无界也不能单独证明原整数模型无界，原模型的可行性和求解状态仍需单独确认。

　　三、CPLEX模型修正后怎么验证约束加对了

　　看到求解状态恢复，还要检查产量和目标值是否符合业务。特别大的临时上限可以挡住某个方向，但也可能让结果贴着一个没有实际依据的数字。

　　1、把限制补在对应的业务对象上

　　①回到建模代码，将遗漏的【产能约束】、【需求上限】或【变量边界】补在对应产品、设备或时段上。多种产品共用一台设备时，按各自耗用的工时合计限制。

　　②重新导出【.lp】文件，检查出问题的索引是否进入约束、工时单位是否一致，以及右端容量是否取自本次运行的数据。

　　2、用原数据和小算例交叉验证

　　①用原先报错的数据重新求解，对照【求解状态】和【目标值】，检查曾被怀疑的变量是否落在业务允许的范围内。

　　②另选一组可以手算的数据，只改变一项容量或需求，再比较求解结果。例如产品每件占用两小时，设备只有十小时可用，没有其他限制时，产量应受五件这一上限约束。

　　原数据用来确认故障是否消失，小算例用来判断新增约束到底管住了什么。若结果总贴着排查时临时加上的边界，还要回去查对应的业务规则是否已经进入模型。

　　总结

　　无界日志提供了一条实用线索：模型允许某些决策不断扩大收益或降低成本，却没有写清可用资源、市场需求或变量之间的限制。把求解时的模型、输入数据和日志一起留存，往往比单独记下报错更有用。后续换一批数据再出问题，也能分清是约束没有生成，还是约束读到了错误的值。有相关需求，欢迎交流。