这两年航空公司对算法的投入肉眼可见地加大不只是IT部门的事而是直接关系到排班、定价、飞机调度、维修计划这些一线业务。我花了大概一个月时间把东航目前公开能看到的算法应用路径、招聘方向、系统建设思路梳理了一遍结合我自己在航空IT和运筹优化领域做过的项目把这份分析整理成了这篇长文。内容不涉及任何内部数据全部基于公开资料和行业通用方案偏重于“算法怎么落地、为什么这么设计、换你来做会踩什么坑”。先说结论东航的算法体系本质上是一个“预测优化决策”的三层结构。底层是用机器学习和深度学习做需求预测、旅客量估计、延误概率评估中间层用运筹学里的线性规划、动态规划、启发式搜索做航班恢复、停机位分配、机组排班上层则是把算法结果嵌入业务流程给签派员、收益管理员、机务工程师提供可执行的决策建议。这套体系里没有太多炫技的新模型更多是在工程化、实时性、可解释性上做文章。如果你正准备切入航空算法这个方向或者想了解航空公司的算法团队每天都在解决什么问题这篇文章应该能给你一个比较完整的坐标系。我会把航班恢复、收益管理、维修预测、机位分配几个典型场景逐一拆开讲清楚里面的核心算法、建模思路、参数调优和落地细节最后再分享一些我在实际项目中踩过的坑。1. 航空业务场景中的算法全景1.1 航班调度与运力网络规划是怎么用算法的航班调度Schedule Planning是航空公司最重资产的决策环节。东航的航线网络覆盖国内外几百个城市每天上千个航班要决定用什么机型飞哪条航线、什么时刻起飞、每周飞几班这背后的约束条件非常多。单纯靠人工经验已经撑不住了必须上优化算法。这个领域用得最多的模型是混合整数线性规划MILP。决策变量是某个航班是否由某架飞机执飞、起飞时刻是否需要调整目标函数是最大化预估收益或者最小化总成本约束条件包括飞机利用率、维修窗口、起降时刻资源Slot、机场过站时间、机组值勤期限制等。模型规模一大求解时间会爆炸式增长所以实际工程里很少直接追求全局最优解而是采用“列生成 分支切割 启发式加速”的组合策略。这里解释一个很多人容易误解的地方航班计划不是“每天算一次”就完事了而是滚动优化。航班换季、临时的空域管制、机场跑道检修、突发天气都会导致计划失效。这时候就要切换到“航班恢复”Disruption Recovery模式这比日常排班更考验算法能力我在第2节会详细展开。1.2 运行控制与航班恢复运行控制是航空公司的中枢神经。一旦出现大面积延误签派员要在极短时间内决定哪些航班该延误、哪些该取消、哪些该换飞机执飞。这个场景对算法的要求非常苛刻数据更新快分钟级、约束复杂机组超时、旅客接续、飞机定检窗口、决策可解释性要求高签派员得知道为什么这么调整。东航在这块的投入方向我能看到的公开信息集中在智能决策支持系统。核心算法是“航班恢复模型”学术上有个专门名称叫Airline Recovery Problem常见解法包括动态规划对单架飞机的航段序列做局部优化、约束传播对机队航网做全局剪枝、禁忌搜索和模拟退火处理大规模组合爆炸问题。一个我印象很深的细节航班恢复算法不能只算“最少延误时间”还要把旅客的联程中转接续算进去。很多延误其实是“一个航班晚点后面一串航班跟着遭殃”。只优化飞机不优化旅客算出来的恢复方案经常不受业务部门认可。所以现在的做法是把旅客换乘关系建模成一张有向图算法以“旅客延误总人分钟数”最小化为目标这个指标比单纯的航班准点率更贴近用户体验。1.3 收益管理与动态定价收益管理Revenue Management是航空算法里最成熟也最赚钱的方向之一。东航作为全服务航司定价策略比低成本航司复杂得多要考虑舱位等级、淡旺季、提前购票天数、竞争对手票价、节假日效应等因素。这个领域的算法演进有几个代际。最早是Earley模型加期望边际座位收入EMSR方法后来升级为动态规划求解最优舱位开放组合现在东航这类航司已经在用机器学习模型替代传统的统计模型做需求预测。具体来说用随机森林或梯度提升树预测每一个OD起讫点每天的需求曲线再用强化学习做实时调价让收益管理系统从“拍脑袋给折扣”变成“数据驱动微调价格”。东航在收益管理上的一个特点是“精细化”。因为它的航线网络呈枢纽辐射式大量旅客是中转旅客所以调价时不能只看单段航线的剩余座位要考虑整个行程组合的期望收益。这对算法提出了更高的要求需要在网络层面计算“腾出这个座位可能带来的增量收入”本质上是一个机会成本评估问题。1.4 机务维修与预测性维护维修工程领域这几年最火的词是预测性维护Predictive Maintenance东航也在往这个方向走。原理很好理解飞机部件比如发动机的运行数据通过传感器实时采集算法根据振动、温度、油耗等特征判断部件剩余使用寿命RULRemaining Useful Life提前安排换件或维修而不是等到故障发生了再停场。这里用到的算法主要是时间序列分析和异常检测。常见的有LSTM网络建模传感器数据的时序依赖孤立森林做异常点识别Weibull分布拟合部件失效规律。还看到过关于东航维修部门引入AR辅助排故和智能维修工卡系统的公开报道说明算法不只是停留在后台已经开始嵌入一线作业流程。需要注意的是预测性维护最怕的是误报和漏报。漏报意味着安全风险误报意味着白白换件、增加停场时间。所以工程上会设定一个非常保守的预警阈值宁可早换也不能漏这个阈值一般通过历史故障数据和维修成本曲线来标定。1.5 旅客服务与个性化营销算法东航在旅客端的算法应用也很明显。通过APP、小程序收集到的用户行为数据结合常旅客计划东方万里行历史记录构建用户画像。这里的技术栈比较标准用户聚类用K-Means或高斯混合模型偏好预测用逻辑回归和GBDT推荐系统用协同过滤加内容召回。相对有航空特色的是“航班恢复时的服务预案算法”。当航班取消算法要自动判断哪些旅客需要安排住宿、哪些需要改签到后续航班、哪些需要补偿积分。这个判断要考虑旅客的会员等级、联程情况、紧急程度比如是否有身体不便的旅客本质上是一个轻量级的优化分配问题东航在这块做得比较早体验也确实比其他航司好一些。2. 航班恢复中的动态规划与蒙特卡洛模拟2.1 为什么航班恢复是最难啃的骨头如果说日常航班计划是“厨师按菜谱备菜”航班恢复就是“顾客已经到店、后厨突然着火了”的应急场面。大面积延误发生时几十架飞机、上百个航段、上千名机组和几万名旅客同时陷入混乱任何一个决策都会牵一发而动全身。复杂性的来源之一是“耦合约束”。飞机执行完一个航班必须完成过站检查才能执行下一个航班机组飞完一段必须休息值勤期上限卡得很死旅客如果接续不上中转航班航司要负责改签和赔偿。这些约束不是独立的它们互相嵌套随便调一个航班就会引发连锁反应。所以航班恢复算法本质上是一个“大规模组合优化下的实时决策问题”。数学模型里有三种决策变量航班延迟时间连续变量、航班取消与否0-1变量、飞机和机组重新指派离散变量。三者组合起来解空间大得吓人常规求解器根本跑不完。2.2 动态规划建模过程我以单个飞机路径恢复为例讲一下动态规划在这个场景里的用法。假设一架飞机当天原本要执行5个航段A→B→C→D→E→F结果第一个航段因天气延误了3小时这时候后续航段全部面临连锁延误。动态规划的状态定义为“飞机当前所在机场 当前时刻 已执行的航段集合”。转移动作是“下一段执行哪个可用航段”转移成本是“执行该航段带来的延误人分钟数”。状态转移方程可以写成f(s_t) min{ f(s_{t-1}) cost(action_t) }这里的优化目标是累积旅客延误最小不是飞机延误最小。“为什么”是因为航班恢复的最终目标是保障旅客权益飞机端的成本可以通过后续调整再优化。这套动态规划看起来优雅实机上会遇到状态空间爆炸的问题。因此工程上一般不追求全局最优而是先用动态规划生成一个较好的初始解再用大邻域搜索LNS或者模拟退火去扰动优化。每次扰动只改一两架飞机的路径评估目标函数是否变优如果变优就接受否则按一定概率接受避免陷入局部最优。我实测下来这个“DP小扰动”的组合方案能在10到20秒内给出一个让签派员满意的恢复预案。2.3 蒙特卡洛模拟评估延误风险航班恢复里还有一个隐藏的难题你做出一个恢复方案未来几个小时的天气、流控、机场保障能力仍然充满不确定性。这时候就需要蒙特卡洛模拟来兜底——把不确定因素当作随机变量反复采样模拟看方案的鲁棒性。举个例子你决定让某架飞机先飞A→B再飞B→C。但B机场的流控是动态变化的有时候放行率只有每小时10架次。蒙特卡洛的思路是对B机场未来3小时的放行率做1000次随机采样每次采样都重放一遍飞机执行任务的过程统计“方案在1000次模拟中的平均延误”和“延误超过90分钟的概率”。这个评估结果非常重要因为签派员需要知道方案的风险边界。很多恢复方案在“均值”上很好看但尾部风险巨大。我写过类似下面的核心逻辑import numpy as np def simulate_delay(effective_rate, mean_delay45, std_delay15, n_sims1000): 蒙特卡洛模拟航班恢复方案的延误风险 effective_rate: 机场流控放行率(架次/小时) mean_delay、std_delay: 单班平均延误及其波动 results [] for _ in range(n_sims): temp_delay np.random.normal(mean_delay, std_delay) flow_delay max(0, (60 / max(effective_rate, 1) - 1) * 8) results.append(temp_delay flow_delay) results np.array(results) p99 np.percentile(results, 99) return {mean_delay: results.mean(), p99_delay: p99, risk_prob: (results 90).mean()}这个代码非常简化真正的工程实现要考虑航段间的前后置依赖、机组衔接、地面保障资源的排队模型。但这个思路是对的算法给出的不是一个“确定的最优答案”而是一个“概率分布下的最优选择”。签派员拿到的不只是一句话“建议您延误50分钟”而是一张表延误50分钟的期望成本是X99%分位数的成本是Y比备选方案高还是低。这样才真正把算法变成了决策辅助工具。2.4 从算法到工程落地航班恢复算法写出来是一回事部署到运行控制中心又是另一回事。工程上的核心难点在于数据对接速度和计算时效性。AOC运行控制中心里的信息和外部气象、空管数据是分钟级更新的算法必须能做到“数据一来模型马上重算”而且要保证计算过程可中断、可回滚。东航这类航司的典型架构是实时数据通过消息队列Kafka等汇聚到数据平台恢复算法作为微服务定时触发或事件触发计算结果写入决策工作台签派员确认后自动分发到各业务子系统。算法服务的性能要求比较苛刻一般要求在5到15分钟内给出可行方案超过这个窗口价值就大打折扣了。我在实操中的经验是把“精确求解模块”和“快速启发式模块”拆开。如果情况不紧急允许求解器跑30分钟找全局较优解如果有红色预警、需要分钟级响应就切换到启发式模式用规则加贪心加禁忌搜索先出一个方案。用一句话概括就是算得慢的方案再漂亮延误场景下没人等得起。3. 预测类算法在收益管理与运行决策中的应用3.1 随机森林构建旅客量预测模型旅客需求预测是所有收益管理动作的前提。舱位开放、折扣计算、超售比例全都依赖“这趟航班大概能卖出去几张票”的准确估计。简单用历史同期均值肯定不行因为需求变化的非线性因素太多了。随机森林在这个场景里很有优势。它对非线性关系天然友好能处理离散和连续混合特征不容易过拟合而且能输出特征重要性方便业务团队理解模型的判断依据。我用它做过类似项目效果比线性回归和单一决策树好不少。关键特征我一般选这几类时间特征起飞月份、星期几、节假日距离、距起飞剩余天数航段特征航线历史平均客座率、航距、经停与否价格特征当前最低票价、折扣舱位开放状态、竞对价格宏观特征目的地当天的天气预警等级、大型展会赛事信息一个容易踩的坑是特征泄漏。比如把“当天实际订座数”当作特征放进去预测“当天最终旅客量”这在训练时准确率爆表上线后彻底失效。真实业务中到预测截止时间点为止的所有数据是可以用的之后的就不行。这个“时间边界”必须在特征工程里定义清楚。3.2 PCA降维在准点率分析里的应用东航会经常分析航班准点率的影响因素这里用到的技巧是PCA主成分分析。准点率的影响因子太多了起飞机场放行效率、目的机场天气、空域流量、前序航班是否晚到、机组衔接时间余量、过站保障速度等。十几个特征堆在一起很多之间高度相关直接建模容易共线性过强。PCA的作用是先对特征矩阵做线性变换找到少数几个互不相关的主成分用它们替代原始特征进入后续模型。这样做的好处是模型更稳定、训练更快、解释起来更聚焦。但PCA也有明显代价主成分是原始特征的线性组合业务人员很难直接理解“这个主成分代表什么”。所以我在实际项目中不会直接用PCA的结果去跟业务汇报而是把它作为建模前的预处理步骤最终产出时用特征重要性排序和SHAP值去给业务讲人话。3.3 强化学习在动态调价中的尝试动态调价是收益管理领域的前沿方向。传统方法基于需求预测加EMS R模型但预测是分段的调价也是离散的本质上是个“固定策略”。强化学习可以做到把调价当成一个连续的决策过程每个航班每一天都是一个决策点根据当前的市场状态做出“提价、降价、维持”的动作然后根据后续的销售表现拿到奖励信号。东航在这块的探索方向主要是环境模拟器加策略优化。环境模拟器负责模拟不同价格下的旅客购买概率强化学习智能体通过与模拟器交互学到定价策略。这里的难点有两个一是环境模拟器本身不一定准直接导致策略学习失真二是航空公司定价受太多约束协议价、政府指导价、竞对反应自由度没有想象中那么高。我的判断是强化学习真正在东航这类全服务航司大规模落地还需要时间但作为辅助模块它已经能在部分航线上做“价格微调建议”而且效果在逐步被验证。想入门的朋友可以关注PPO算法和DDPG算法这两个是目前业界用得最多的连续控制算法。4. 配套运筹算法停机位分配与排班优化4.1 匈牙利算法解决停机位分配停机位分配是我觉得最有意思的运筹学落地场景之一。一个枢纽机场每天有几百个航班要停靠停机位数量却有限而且不同机位能停的机型不同有的靠廊桥、有的需要摆渡车有的离航站楼特别远。分配得好旅客体验和运行效率双赢分配得差旅客在机坪上绕圈子是常事。经典解法之一是匈牙利算法Kuhn-Munkres算法解决的是“指派问题”有N项任务、N个资源如何一一指派使总成本最小。放到停机位场景里就是把航班看成是“待指派的任务”把机位看成是“资源”成本矩阵里填入每个航班放在每个机位的广义成本旅客步行距离、摆渡成本、机位冲突概率等。但实际落地有一个经典坑航班数不等于机位数而且缓冲区、相邻机位冲突、航班过站时间交集这些约束一加入匈牙利算法的标准形式就不够用了。所以工程上通常先做预处理把物理条件不满足的航班机位组合直接置成无穷大成本再用匈牙利算法求初始指派最后用局部搜索修正时间窗冲突。4.2 混合整数线性规划与机组排班机组排班是另一个“算法重镇”。乘务员和飞行员飞什么航班、怎么轮休、怎么过夜直接影响航空安全和人力成本。机组排班问题分成两块一个月前的“人员排班”和当天的“人员替补与调配”。人员排班的核心是覆盖约束每个机型的每个航班都必须配备满足资质要求的机组。早班、晚班、过夜基地、训练要求、休假一大堆约束叠在一起复杂度比停机位分配高一个数量级。标准做法是用混合整数线性规划求解目标函数是总成本最小化成本包括基本薪资、过夜住宿、异地津贴、培训费用等。实战里最让人头疼的是“软约束”的处理。比如“尽量让乘务员每个月长航线飞行时间差不多”这种要求写不进严格的线性约束只能通过目标函数加惩罚项来实现。惩罚项的系数怎么定这背后需要和一线业务部门反复沟通太松了分配不均太紧了求解器可能找不到可行解。4.3 关键参数设置经验运筹算法能不能落地参数设置有时比模型选型更重要。以停机位分配为例几个关键参数的调整逻辑我列一下广义成本权重旅客步行距离权重设为0.5摆渡成本权重设为0.3机位摩擦成本设为0.2这个比例是通过历史数据回归出来的不是拍脑袋定的。时间窗粒度放5分钟太细求解会非常慢放15分钟太粗会出现机位占用时间重叠。东航这类枢纽机场用10分钟比较合适。鲁棒性调节分配结果不能“卡得太死”要预留10%左右的机位缓冲应对航班延误造成的连锁反应。这相当于在求解完成后做一个松弛校验把所有航班计划时间统一加一个安全缓冲再检查是否可行。这些参数没有一个“万能组合”核心思路是先用历史数据做离线回放再结合现场运行人员的反馈迭代。算法算法最终落脚点还是在“适配业务”。5. 从算法到系统的工程化落地5.1 数据链路与算法特征工程航空算法对数据质量的要求极其苛刻。我见过太多项目死在了数据链路上报文解析错误、航班号重复、机型编码不一致、机场三字码大小写混用。东航每天的数据量很大但数据清洗和校验规则更是海量。一个我在实际项目里反复踩的坑是“航班号不等于唯一标识”。CA1234这个航班号在不同日期、不同季节可能就对应完全不同的航线。如果建模时只用航班号做关联键新旧航班计划切换期间必然出现脏数据。正确的做法是用“航班日期 航班号 出发机场 出发时间”组合成唯一业务键。特征工程方面航空数据的时空特性非常强。同一个特征比如“距起飞剩余天数”在距离起飞前30天和当天对需求的解释能力完全不同。所以我会把时间特征做成分段桶1天内、1-3天、3-7天、7-14天、14天以上让模型能捕捉不同决策窗口下的需求规律。5.2 算法评估与评估指标体系算法模型的评估绝对不能只盯着离线指标。训练集里的准确率再高上线后面对实时数据性能可能掉得厉害。航空业里常用的一套评估体系是离线回测用过去两年的历史数据回放模型看预测值和真实值的偏差分布影子运行系统不给出最终决策只在后台输出模型建议与人工决策做对比持续一段时间小流量灰度选几条航线、一个维修基地、一个机队做受限试验验证闭环效果这三个阶段缺一不可。我特别强调影子运行因为它能收集到“模型当值与业务当值”之间的差异而这些差异往往是特征没考虑到的业务逻辑。比如某个机长特别偏好早班调度算法不知道这一点排了个晚班航班虽然从数学上看完全可行但实际会被打回重排。5.3 团队组织与算法迭代流程从东航的招聘和公开技术分享来看算法团队的搭配一般是“业务专家 数据工程师 算法工程师 平台开发”。纯算法工程师很难单独完成任务因为不懂签派业务的人写不出可用的航班恢复约束不懂数据链路的人做出来的模型上线后就是空中楼阁。算法迭代的节奏建议是“小步快跑”。不要试图一次性做一个覆盖所有航线的智能决策系统而是先挑一个痛点场景比如“郑州机场的机位分配优化”跑通全链路验证效果再横向复制到其他基地。这种打法见效快、风险低、业务认可度高。还有一点很关键算法迭代要跟业务流程绑定。模型建议不能只出现在系统里还要落实成操作工单、变更通知、绩效反馈。否则业务人员看一眼建议发现和自己的直觉不一致就直接忽略了算法再强也没用。6. 常见问题与实战排查笔记6.1 数据质量问题航班动态数据杂乱航空公司内部系统多航班动态数据散落在AOC系统、离港系统、运价系统、常旅客系统里。同一个“航班延误”在不同系统里定义可能完全不同有的是计划关舱门时间晚于计划起飞时间有的是实际跑道起飞晚于计划有的是撤轮挡时间晚于标准。我的排查经验是先把口径统一。在搭建算法平台的第一天就和业务确认一份“指标字典”写明每个字段的定义、更新频率、来源系统、责任部门。这份字典后面会救你无数次。如果没有这份字典上线前的联调阶段会让你怀疑人生。6.2 样本不平衡与冷启动问题在维修预测场景里样本不平衡非常严重发动机故障是极小概率事件正常运转的数据占99%以上。直接建模会导致模型“什么故障都预测不出来”因为它发现“预测正常”的准确率就已经有99%了。处理办法是重采样加代价敏感学习。对少数类做SMOTE过采样同时对模型的目标函数里给少数类更高的误分代价。但要注意过采样比例不能太过分我建议正负样本比控制在1比10到1比20之间比例太极端会把模型带上歧路。冷启动问题出现在新开航线、新引进机型上。没有历史数据怎么预测需求三个思路类比迁移找相似航线的数据、贝叶斯方法用先验分布加少量观测更新、人为设定保守区间并定期修正。这三招我都在项目里试过组合使用效果最好。6.3 算法上线后的漂移监控模型上线后最怕的就是数据分布漂移。航班恢复模型是基于历史天气、流量规律训练的但今年的天气规律和去年明显不一样模型的预测精度就会下滑。我习惯在模型上线后持续监控两类指标模型预测的分布是否偏移比如健康度指标以及业务结果指标是否劣化比如签派员采纳率。一旦发现飘移信号第一时间做特征分布对比找出变化最大的特征维度然后决定是重新训练还是局部微调。6.4 算力与时效性平衡最后说说算力。很多人以为航空公司算法团队最缺的是GPU其实最缺的是“确定性低延迟的CPU算力”。航班恢复、机位分配这类优化算法对GPU的依赖很小但对多核CPU并行和内存带宽要求极高。我的工程建议是优化求解器和启发式算法做成两套部署方案平时用低配资源跑预警触发时自动扩容。资源不够时优先保“关键场景的计算时效”比如航班恢复永远排在停机位分配前面。这个优先级排序要和业务部门提前达成一致否则半夜三点系统卡住现场打电话来找你场面很不愉快。我在实际项目里还有一个经验想分享算法上线之前一定要做“最坏情况测试”。人为制造一次极端大面积延误也就是假设几百个航班同时异常的情况看系统能不能在规定时间内出方案。不要等到雷雨季节真的来了再让系统第一次接受考验。航空业容不得“第一次就出问题”前期准备多做的每一分都是给运行安全加的一分保险。这类工作做得越多我越觉得真正的算法竞争力从来不在于追新模型、刷高离线精度而在于能不能把模型、数据、业务流程、一线人员的使用习惯完整地捏合成一个别人很难复制的系统。东航给行业的一个启发就是——算法不是一个“IT项目”而是运行体系的一部分。想入局的人建议从最脏最累的数据治理和业务梳理入手那才是真正的护城河。