第2章数学建模基础

数学建模基础：目标函数、约束条件与决策变量

说实话，很多刚入行的朋友一听到「数学建模」就头大。我当年也一样，觉得这东西太抽象了。但做了十几年调度系统后，我慢慢发现——建模其实就是把业务语言翻译成数学语言。你只要掌握了这个翻译技巧，剩下的就是套公式了。

今天咱们就聊聊调度建模的三个核心要素：目标函数、约束条件和决策变量。这三者构成了调度问题的骨架，缺一不可。

决策变量，说白了就是你要「决定」的东西。在调度问题里，最常见的决策变量就两种：

举个例子，一个简单的作业车间调度问题：

# 决策变量定义
x[i][j][k] = 1  # 任务i的第j道工序在机器k上加工
s[i][j]        # 任务i的第j道工序的开始时间
c[i][j]        # 任务i的第j道工序的完成时间

我个人习惯把决策变量分成两类：排班变量和时序变量。排班变量决定「谁来做」，时序变量决定「什么时候做」。这样分开思考，建模会清晰很多。

小技巧： 决策变量越少，模型求解越快。我见过有人把每个时间片都设成一个变量，结果模型跑了一天还没出结果。能用连续变量就别用整数变量，能用整数变量就别用0-1变量。

目标函数就是你的「KPI」。不同的业务场景，目标函数天差地别。我整理了几种常见的：

嗯，这里要注意一点：多目标优化在实际项目中很常见。比如既要快又要省钱，怎么办？我常用的方法是加权求和，或者把其中一个目标转成约束条件。

举个例子，我曾经帮一家物流公司做配送调度。他们的目标是「准时送达率最高」和「运输成本最低」。这两个目标其实是冲突的——想准时就得加车，加车就费钱。最后我们用了ε-约束法：把成本控制在某个预算内，然后最大化准时率。效果还不错。

约束条件就是「不能做什么」。调度问题里，约束条件通常分三类：

每个任务都有最早开始时间和最晚完成时间。这在物流配送里特别常见——客户说「上午9点到12点之间送货」，这就是时间窗。

# 时间窗约束
e[i] ≤ s[i] ≤ l[i]  # 开始时间必须在时间窗内
s[i] + p[i] ≤ d[i]  # 完成时间不能晚于截止时间

我在项目中遇到过一个问题：时间窗太紧，导致无解。后来我们引入了软时间窗——允许超时，但超时要罚款。这样模型就有解了，而且能给出一个「最优的妥协方案」。

资源是有限的。机器一次只能加工一个工件，工人一次只能做一件事，仓库的容量是固定的。这些都要建模进去。

# 资源容量约束
Σ x[i][k] ≤ Cap[k]  # 分配给资源k的任务不能超过其容量

你想想看，如果忽略资源容量，调度方案就是空中楼阁。我见过一个案例，某工厂的排程系统排出来的方案，一天需要100个工人，但工厂只有50个。这种方案根本没法执行。

任务之间有先后关系。比如「先粗加工，再精加工」，「先下单，再付款，再发货」。这些顺序约束决定了调度的可行性。

# 顺序约束
s[i][j+1] ≥ c[i][j]  # 下一道工序必须在上一道完成后开始

顺序约束还有一种特殊情况——互斥约束。两个任务不能同时进行，比如两个工序都需要同一台机器。这种约束通常用「大M法」来处理：

# 互斥约束（大M法）
s[i] ≥ c[j] - M * y[i][j]  # 如果y=1，则i在j之后
s[j] ≥ c[i] - M * (1 - y[i][j])  # 如果y=0，则j在i之后

避坑指南： 我曾经在建模时把M设得太小，结果约束失效了。M一定要大于所有可能的时间差。我一般取所有任务总时长的两倍，这样既不会太小，也不会太大影响求解效率。

说了这么多，咱们用一张图来总结一下调度建模的核心逻辑：

最后分享几个我在实战中总结的经验：

先建模，再求解：别一上来就想着用什么算法。先把模型建好，哪怕手算一个小例子验证一下。模型错了，算法再牛也没用。
从简单到复杂：先忽略一些次要约束，跑通一个简化模型。然后逐步添加约束，看看求解时间的变化。这样能快速定位瓶颈。
验证模型的可解性：我见过太多人建了一个无解的模型。最简单的验证方法：把所有约束都去掉，看看能不能得到一个解。如果能，再一条一条加约束，看哪条导致了无解。
善用对称性：很多调度问题有对称性——比如两台相同的机器，交换它们的任务分配，解是一样的。这种对称性会让求解器浪费大量时间。我一般会加一些打破对称的约束，比如让机器1的任务数不少于机器2。

核心要点回顾：

好了，数学建模这块就聊到这儿。说白了，建模就是「把业务问题翻译成数学问题」的过程。你翻译得越准确，后面的求解就越顺利。下次遇到调度问题，不妨先花点时间把模型建好——相信我，这步省不了。