从调度到推荐：优化算法应用的隐形边界与破局方向

上个月在南京见了个做城配物流的技术负责人，一坐下就开始吐槽。团队花了小半年，从高校挖了博士，改了七八版算法，号称能把配送成本降15%的新系统，上线第一周就被老调度们集体弃用。算出来的最优路线，要么要求司机闯禁行，要么逼着人连轴干到半夜，真按系统派单，不出三天司机就得跑完辞职。

没人会在项目需求里写“司机每天加班不能超过1小时”“主城区晚六点不能进小巷”这种细碎规则，可这些规则才决定了方案能不能用。

目标函数从来都不是天然正确的

多数人碰到问题，第一反应是找个最新的优化算法套上去，却很少停下来想，我们要优化的到底是什么？90%的优化项目落地失败，根源都在目标定义错了。

内容推荐领域，早年大家都优化点击率，结果算法疯狂推标题党内容，点进去转化率掉了一半，用户留存跌了快两成，这就是把“点击率”当成了唯一优化目标，漏了用户长期体验这个核心约束。

工业生产排程，很多项目把“设备利用率最高”当成优化目标，算出来的方案设备确实不停转，但成品堆在仓库里卖不出去，占用了几千万的流动资金，算下来反而亏了。这不就是捡了芝麻丢了西瓜？

说实话，很多做算法的人，都习惯把业务问题抽象成干巴巴的数学题，把所有约束都当成硬条件写进公式，可真实的业务里，大多数约束都是弹性的，大多数目标都是矛盾的。你要成本低，就得牺牲点时效；你要核心客户满意，就得让小客户等一等。这些妥协，不是算法能自己悟出来的。

工程落地要的是“可用”，不是“最优”

我之前跟电网的工程师聊过，他们做故障后的切负荷优化，理论上全局最优解能把负荷损失降到最低，可算一次最优解要三四十秒。电网故障是什么概念？一秒钟都能出大事故，三四十秒够整条线路瘫痪了。

最后他们用了什么？分层分区的启发式优化，每次得到的解只是次优，负荷损失只比最优解高不到一个百分点，响应时间压到了100毫秒以内，刚好满足安全要求。

不过话说回来，这种“非最优妥协”，才是工程落地的常态。你给共享单车做车辆调度优化，要是等到把全城所有单车的位置都统计完，算出一个最优的调运方案，大半天都过去了，早高峰都结束了。还不如分区计算，每个区算出来的方案不是全局最优，但一两个小时就能落地调运，反而盘活了车辆，提升了周转率。

很多人觉得，算法越复杂，结果越好，算力堆得越多，越能出效果。其实不是。很多场景对延迟的要求，就是比精度重要。对成本的敏感，就是比几个百分点的误差重要。我见过一个创业团队，给工厂做排程优化，上来就用大模型搭配复杂的全局优化，光服务器成本一个月就要十几万，工厂一年从优化里省的钱都不够付电费，最后只能项目下线。真的挺无奈的。

给人留位置，才是长期能用的核心

现在很多人都在说人机协同，放在优化这个领域，真不是喊口号。优化算法擅长的，是在给定的规则和约束下，快速遍历所有可能，把最接近目标的方案筛出来。可规则是谁定的？约束是谁调的？永远都是人。

就说开头那个城配的例子，后来那个技术负责人改了方案，算法不直接出最终派单结果了，只给老调度出十几个满足核心约束的候选方案，把距离、成本、时效都标清楚，老调度只需要根据今天的实际情况，点两下选一下，半小时就能做完以前一天的活，成本也降了快10%，皆大欢喜。

这里有个很容易被忽略的应用边界：优化算法永远只能解决“已知规则内的寻优”，解决不了“规则本身的定义问题”。哪个客户的订单优先级更高，今天哪个司机家里有事要提前走，哪个仓库今天只能半开门收货，这些动态变化的信息，不可能全都实时同步到算法系统里。给人留好调整的口子，不是算法能力不够，是对业务规律的基本尊重。

现在很多企业一窝蜂上全自动化的优化系统，什么都不让人碰，说出了问题就是算法的锅，可算法哪能背这个锅？你没把隐性约束给它，它怎么能算出符合要求的解？最后出了问题，互相甩锅，项目不了了之，钱打了水漂。其实换个思路，别想着让算法包办一切，让算法做脏活累活，让人做决策，反而成功率高很多。

我上周翻之前的会议笔记，看到当年在南京听一个老教授讲的话，他说做优化，从来不是求那个数学上的极值，是求业务里的平衡。那时候没太懂，现在见多了起起伏伏的项目，才明白这句话是什么意思。很多东西，从来都不是技术本身的问题，是我们怎么用技术的问题。