简介登机口分配是机场运行调度的核心环节涉及航班时刻、机型约束、旅客动线等多重因素本质上是一个带大量硬约束的组合优化问题。传统人工排班依赖经验面对高峰时段和突发延误往往难以兼顾效率与稳定性。机器学习技术能从历史运行数据中学习航班延误规律、登机口使用模式与旅客步行距离之间的隐性关系为每个“航班-登机口”组合生成合理度评分再由规则引擎完成约束检查与最终分配形成“预测优化”的落地框架。这一思路在机场、港口、仓储等资源调度场景具有广泛借鉴意义。本文以航司登机口分配项目为例拆解从数据清洗、特征工程、模型训练到分配引擎设计、效果评估与方案交付的完整过程为从事调度优化或工业AI落地的工程师提供一套可复用的实践路径。 去年年底我帮一家航司的信息化部门做过登机口分配方案的预研。项目不大但很有意思机场一天几百个航班每个航班停到哪个登机口这个决定直接决定了旅客是不是要坐摆渡车、中转来不来得及、延误会不会像滚雪球一样越滚越大。项目交付压缩包的名字就叫“基于机器学习的航班登机口分配内含数据集和方案报告.zip”里面一套历史航班数据集加上一份完整的设计方案报告。这是个非常典型的小而完整的机器学习项目没有炫技也没堆模型但把一套能落地、能向业务方交代清楚的方案梳理通了。数据集整理的是历史航班进出港记录方案报告则写清了从问题定义、特征构建、模型训练到分配约束检查、效果评估的全过程。今天把这套思路完整拆开讲一遍。如果你在做调度优化、想把机器学习用进传统行业或者正在做相关课题这篇内容应该能帮你少走不少弯路。1. 在机场调度室盯过屏幕才知道登机口分配有多乱1.1 登机口分配的日常一场连续发生的“占车位”游戏把登机口分配想成一个大停车场就行。机场有几十上百个“车位”登机口每架飞机是一辆“车”停了多久取决于航班计划什么时候来取决于前序航班飞得顺不顺有些“车”还特别挑位置——宽体机进不了窄机位国际航班必须停有边检设施的登机口带中转旅客的航班最好离中转通道近一点。真正的复杂度在于这些需求是动态的。计划是早上九点落地的航班可能因为前序机场的流量控制晚到两小时。这一晚它原本占用的登机口就空不出来下一个等着停那个口的航班就得挪地方。挪了A航班的登机口B航班的旅客中转步行距离就变长了C航班的登机口又和某个国际航班撞了时间。调度员在离港系统里改一个航班经常要跟着调整五六个航班改完之后还要担心后面的连锁反应。1.2 为什么传统人工排班法越来越撑不住很多机场现在还在用“先到先得人工勾兑”的方式做登机口分配。前一天晚上排一个计划表第二天运行中再靠调度员手动改。这种方式在航班密度低、机型单一、准点率高的年代问题不大。但现在的大型枢纽机场高峰期一小时几十架飞机进出港还夹杂着国际、国内、中转、低成本航司共用航站楼的复杂局面靠人工排序已经非常吃力。还有一个很隐蔽的问题人工分配依赖的是老调度员的经验直觉。同一个航班组合老手和新手给出的分配结果可能完全不同同一个航班延误之后两个资深调度员的调整策略也可能南辕北辙。这种不一致性本身就是运行风险。让机器学习介入不是为了替代调度员而是把“经验”变成“可量化的规则模型”让每次分配决策都有依据、可解释、可复盘。1.3 机器学习解决的不是“分到哪个口”而是“哪种分法更稳”很多人一听“机器学习分配登机口”第一反应是让AI一键算出所有航班的登机口方案。说实话纯端到端预测很难做到。登机口分配本质上是一个带大量约束的组合优化问题而机器学习擅长的是从数据里学规律。所以这个项目的定位是机器学习当大脑规则当骨架。具体来说机器学习负责给每个“航班-登机口”组合打分分数代表这个组合的合理程度——延误风险越低、旅客步行距离越短、对后续航班影响越小分数越高。然后由一个分配引擎在硬约束条件下做决策。这样做的好处是模型学到的是历史数据里的复杂规律比如雨天前序延误多的航班该怎么排、什么时段用远机位对旅客体验影响最小而规则引擎保证分配结果永远不会违反安全底线。这个“预测优化”的框架是这类问题落地的常见正确姿势。2. 数据中心先把手里的牌码清楚2.1 字段梳理每一个列都是业务里的一个环节这份数据集整理的是某枢纽机场连续三个月的进出港航班记录。原始表一共十几万行每行是一条航班运行记录核心字段大概分四类航班属性、时间属性、登机口属性和旅客属性。航班属性包括航班号、航空公司、机型、航线类型国内/国际/地区、起降机场。这部分字段决定了硬件约束——机型决定能不能停某种登机口航线类型决定海关边检要求。时间属性包括计划起飞/到达时间、实际起飞/到达时间、前序航班号、前序航班延误时长。登机口属性包括登机口编号、所在航站楼、机位类型近机位/远机位/混合、是否靠桥、行李转盘是否直连。旅客属性里最重要的是乘客人数、中转旅客人数、有无特殊旅客服务需求。拿到原始数据之后首先要问自己这个数据集能不能支撑我要做的任务如果数据里只有计划时间而没有实际时间就没办法学习延误规律如果没有旅客人数就没办法评估步行距离和摆渡车压力。所以字段梳理这一步虽然枯燥但它决定了后面所有模型的上限。2.2 清洗掉那些会教坏模型的数据数据清洗我踩过最大的坑是“把取消航班当成正常航班用”。原始数据里有不少标记为“取消”和“备降”的记录如果不过滤掉模型会学到“这个航班从不落地”这种荒唐规律。清洗阶段我按这样几条规则处理删除状态为取消、备降的航班记录只保留实际执行航班删除登机口编号为空的记录因为没法做监督学习时间字段统一转成UTC时间戳避免跨时区导致的排序错误同一航班号同日重复记录保留最后一条状态机型和登机口兼容性明显矛盾的数据比如宽体机停窄机位单独标记出来不直接删除——这种记录可能是历史运行中的临时调配可以作为噪声样本但不能让它主导模型清洗完之后有效样本从十几万行降低到九万行左右。这个数字对于登机口分配任务来说已经比较充足。注意删除数据时一定要保留一份原始备份否则后面发现特征工程思路有问题想回头重新提取字段就麻烦了。2.3 特征工程把时间、航班、登机口变成模型能懂的语言特征工程是这类项目最值钱的环节。我的做法是把一条航班记录拆解成三组特征航班侧、登机口侧、交互侧。航班侧特征包括计划到达时刻、实际到达时刻、计划停留时长、前序航班延误时长、入港流量方向、是否早高峰/晚高峰、是否周末、是否节假日。这里值得说明的是“前序航班延误时长”这个特征它几乎是整个模型里重要度最高的一列。航班延误是连锁反应知道前序航班晚了几小时当前航班的延误概率和延误时长就有很强指向性。登机口侧特征包括登机口类型、所在区域、近机位还是远机位、历史利用率、平均步行距离到中转柜台。交互侧特征包括机型和登机口兼容性、该登机口在当前时刻的占用状态、目标航班预计到达时间前30分钟内该登机口有多少个航班计划冲突。时间特征的构造有一些经验登机口分配关注的是“这段时间会不会撞车”所以把时间切成30分钟窗口统计每个窗口内计划占用登机口的航班数作为拥挤度特征。这个拥挤度特征很有用高峰期的拥挤度和平峰期完全不同模型可以通过它学到不同时段的分配策略差异。处理完特征之后数据集从九万行扩展到九万条样本、每条约四十个特征维度。注意所有时间型特征都能算出来但实际做推断的时候要用预测时刻之前的数据不能用未来数据。这是防止特征泄漏的基本功。3. 模型设计我不做端到端预测我做“航班-登机口”打分3.1 为什么不用纯整数规划登机口分配学术圈子里最经典的做法是整数规划目标函数写成一堆约束条件加一个优化目标比如最小化旅客步行距离或者最小化延误冲突。这个思路理论上很漂亮实际落地有几个问题。第一变量规模大。一个月几千航班、一百个登机口01变量的数量级就是几十万高峰期加进延误预测、旅客转机时间窗约束整数规划求解器跑起来非常慢。第二模型维护成本高。机场运行规则经常变新增一个航站楼、调整几条转机通道规划模型就要改一轮。第三也是最关键的约束参数本身是动态的。比如转机时间窗口内旅客能不能赶上继程航班不仅取决于步行距离还取决于当前航站楼的排队状况——这个排队长度很难用静态参数描述但历史数据里有大量隐含模式。机器学习的优势恰好在这里它能从历史数据里自动学出这些隐性规律不需要人为把所有规则写进约束。3.2 建模方式pairwise打分 贪心分配具体建模我采用了“航班-登机口”pairwise打分加贪心分配的两阶段方案。第一阶段是打分模型。对每一个待分配的航班构造它和所有候选登机口的组合样本。每个样本的特征包括航班侧特征、登机口侧特征和交互侧特征标签是“这个组合在历史运行中是否顺利”。什么叫顺利我定义了一条比较稳的标签规则航班按该登机口分配后未发生登机口冲突、未因登机口问题导致延误超过15分钟、旅客步行距离不超过该登机口历史平均值的1.2倍。满足以上条件的样本标签为1否则为0。这里大家不要纠结于精确的阈值要理解的是机器学习需要一个可以从历史数据中清晰标注的二分类目标标签定义一定要和业务上“什么是好的分配”保持一致。第二阶段是分配引擎。获得打分之后对每个航班将所有候选登机口按分数从高到低排序然后从最高分开始依次检查硬约束机型兼容、时间不冲突、国际国内匹配第一个满足硬约束的登机口就是分配结果。这个方案有点像推荐系统里的“粗排精排”。打分模型负责把最合理的几个登机口推到前面规则引擎负责最终兜底。3.3 基线与进阶模型对比LightGBM为什么够用模型选型上我首先跑了一个逻辑回归作为基线然后把主力模型定为LightGBM。没有一开始就上深度模型原因很现实样本量九万条、特征四十维结构化表格数据里GBDT类的模型往往比复杂神经网络更稳训练快、调参少、可解释性好。LightGBM的重点参数我大概是这样设置的objective: binarylearning_rate: 0.05num_leaves: 31max_depth: 6min_data_in_leaf: 50feature_fraction: 0.8bagging_fraction: 0.8lambda_l2: 1.0五折交叉验证下LightGBM的AUC在0.87左右逻辑回归AUC在0.78左右。这个差距说明数据里确实存在非线性关系尤其是“前序延误高峰拥挤远机位”这种组合效应线性模型很难捕捉。我没有再往上换更复杂的模型因为再往上AUC提升空间有限但部署成本和解释成本会上升很多。项目到最后调度员更关心的是“为什么这个航班被分到远机位”而不是“模型AUC提高了0.01”。模型效果足够好就行了继续卷精度意义不大。4. 分配引擎模型分数只是起点约束检查才算数4.1 硬约束与软约束哪些是底线哪些是效率模型打分做得再好都不能直接作为最终分配结果。登机口分配有一堆硬约束违反任何一条都可能导致安全问题或运行事故。我在这套方案里是这样划分的硬约束不可违反同一时刻一个登机口只能分配给一个航班机型最大承载能力必须大于等于实际执飞机型国际航班只能分配具备边检和海关设施的登机口相邻两个航班之间要有足够的清场缓冲时间一般设为45分钟软约束可以作为优化目标旅客平均步行距离尽量短远机位使用尽量均衡不要可着几个口薅中转航班尽量靠近中转通道同属一个航空公司或同一个联盟的航班尽量聚在同一区域在分配引擎里硬约束是一定要写成代码里的。软约束不单独做优化他们的影响会被模型打分隐式包含——因为模型在训练时见过大量历史数据知道走路远的登机口更容易造成旅客抱怨所以打分时会自动给这类组合低分。4.2 贪心分配的流程因为硬约束的存在我最终没有直接用模型分数排序就完事而是套了一层贪心逻辑。流程大致如下把所有待分配航班按“计划到达时间前序延误预估值”排序延误风险越高的航班越靠前对当前航班遍历所有候选登机口用模型预测“航班-登机口”组合的合理分数将候选登机口按分数降序排列从最高分开始逐个检查硬约束是否满足如果满足则分配该登机口更新登机口的占用状态表如果不满足继续看下一个如果所有候选登机口都不满足硬约束进入冲突消解流程寻找已分配但延误风险更低的航班尝试交换登机口这个贪心算法不保证全局最优但基本上能做到局部最优而且运行速度快。高峰期两百个航班单核跑一遍也就几秒钟完全能支撑机场实时运行的需要。4.3 结果评估不只看准确率看调度员关心的指标模型可以画AUC曲线但业务方看的是另外几个数字。我把评估指标分成了三组汇报给用户。第一组是运行安全指标分配方案中硬约束冲突数为0、远机位使用占比、相邻航班清场时间足够率。第二组是效率指标登机口平均利用率、高峰时段登机口占用不均衡度、平均旅客步行距离。第三组是抗干扰指标模拟随机延误120分钟、240分钟情况下需要调整的航班数量占比。实测下来跟基线人工方案相比这个方案在以下维度有改善指标人工方案基线本方案登机口冲突次数/千航班8.71.2平均旅客步行距离412米356米远机位使用占比31%28%延误波及航班数量每小时2.3架每小时1.1架单看每项提升幅度都不算特别夸张但登机口冲突次数从每千航班8.7次降到1.2次调度员的处理压力是肉眼可见地变小了。这也是这个项目最有说服力的复盘数字。5. 方案报告的写法让业务方点头的技术文档5.1 报告的核心逻辑从问题到数据再到方案数据集和代码只是交付物的一部分真正决定项目成败的往往是那份方案报告。我的报告不是从算法开始写而是从业务痛点开始写。第一段讲清楚机场现有登机口分配遇到什么问题为什么要做这个项目。第二段讲数据拿到了什么数据、数据长什么样、怎么清洗和验证。第三段讲方法为什么用机器学习、选了哪个模型、怎么定义标签。第四段讲实验做了哪些对比实验、结果如何。第五段讲落地如果要上线需要怎么部署、运维怎么做、风险在哪。这套逻辑非常朴素的但亲测有效。业务方不会关心你的特征工程有多巧妙他们关心的是“你有没有搞清楚我们的问题”。先证明你理解了业务后面技术方案才有说服力。5.2 实验结果必须回答三个问题实验部分不要只贴AUC和混淆矩阵我总结了一下写实验报告时一定要回答这三个问题第一比什么基线好我的基线和两种方案对比方案一是不做任何优化的先到先得方案二是人工经验规则匹配。两种基线都跑一遍才说明机器学习带来的增益是真实的。第二好多少、好在哪光说“效果好”没有用要列数字。比如冲突次数降低87%、平均步行距离减少56米让业务方一眼看懂收益。第三什么情况下不work这一点容易被忽略但很重要。我的测试里发现在极端雷雨天气导致大面积航班延误时所有登机口几乎全满这时候机器学习的优化空间会被压缩得很小分配结果跟人工方案差不多。把这个问题写进报告说明你不是在报喜不报忧方案的可信度反而更高。5.3 可解释性别让调度员把模型当黑盒调度员使用一个推荐系统如果完全不知道它为什么给出这个建议是绝对不敢用的。这跟人开车用导航一样导航说前方左转你看一眼确实能理解才敢照着走。我在模型解释上做了两件事。第一是特征重要性分析。报告里列出Top10重要特征前序航班延误时长、当前登机口占用率、30分钟拥挤度、机型与机位兼容性、旅客人数等。这些都是调度员能直观理解的因素他们一看就明白“原来模型主要是这么想的”。第二是SHAP个体解释。对关键航班生成每个特征对这个航班分配的贡献值。比如某航班被分到远机位SHAP图会显示主要原因是近机位全部被占用、且前序航班延误导致错过了可用窗口。调度员看到这个解释就能判断是认同模型结果还是做出调整。这个可解释性模块在方案宣贯时起了很大作用。6. 打包交付数据集 报告 代码的zip怎么给才不挨骂6.1 为什么会遇到“file is not a zip file”虽然项目主体是机器学习和方案但交付时还是栽过zip的跟头。有一次把数据、报告和代码放进压缩包发给合作方对方反馈说解压提示“file is not a zip file”。排查了一下是上传下载环节出的问题文件传到某个平台时平台可能把文件头重新封装过导致标准解压工具不认。另外有一种情况是zip文件下载了一半或者是分卷压缩包只拿到了第一个分卷也会出现类似报错。还有一次是压缩源文件时因为文件名里有中文和特殊符号某些老版本解压工具兼容性不好报的错也是“file is not a zip file”这一类的。所以打包交付时我给自己定了几条规矩压缩格式优先用.zip考虑兼容性避免某些Windows机子打不开tar.gz文件名和内部路径都用英文或拼音命名避免中文编码问题大文件超过2GB考虑分卷压缩或者用MD5校验值方便接收方确认文件完整压缩完成后自己先解压验证一遍不把坏包发给别人压缩之前确保源文件没有正在被打开占用否则压缩产物可能损坏如果你收到的zip包报“invalid zip archive: could not find eocd”大概率就是文件截断或者头部污染不要硬解重新下载或者让发送方重新打包是最高效的方案。6.2 压缩、编码与校验很多初学者不太在乎压缩工具的选择Windows系统自带的“发送到压缩文件夹”虽然方便但处理大量零散小文件时压缩率和速度都比较一般。我更推荐用7-Zip来做。压缩等级选择“标准”或“极限”编码格式选UTF-8这样在macOS、Linux和Windows之间传输都没有中文乱码问题。数据文件如果用的是CSV格式注意字段里的逗号和换行符可能会破坏格式所以统一设置成UTF-8编码且带BOM比较好。我还习惯在数据集目录下放一个README.txt把列字段含义、数据时间范围、样本量、清洗规则写清楚。别小看这个README它往往是接收者使用数据集时最依赖的文档。另外一个容易被忽略但非常重要的点是校验值。在交付说明文档里附上每个文件的SHA256值接收者拿到包之后可以自行校验文件完整性。尤其项目里包含数据集如果数据集在传输过程中损坏了一部分模型训练出来的结果可能会非常离谱而且这种错误很难追查。有校验值就能快速定位是传输问题还是代码问题。6.3 交付物的目录结构这套项目的zip包最后目录结构是这样安排的flight_gate_assignment/ ├── README.md # 项目说明和交付清单 ├── dataset/ │ ├── raw/ # 原始数据 │ ├── processed/ # 清洗后的建模数据 │ └── data_dictionary.md # 数据字典 ├── code/ │ ├── 01_data_preprocessing.py │ ├── 02_feature_engineering.py │ ├── 03_model_training.py │ └── 04_gate_assignment_engine.py ├── report/ │ ├── 基于机器学习的航班登机口分配方案报告.pdf │ └── 实验评估附录.xlsx ├── model/ │ └── lgbm_gate_model.txt └── requirements.txt这个结构的好处是一个新接手的人打开README就能知道整个项目是干什么的想看数据有数据字典和清洗后的文件想复现实验跑code的三步脚本就能出来想了解结论直接看report目录里的方案报告。整个项目闭环不依赖某个人。当时方案预研结束之后我没有急着把zip发出去而是先花了一个晚上把整个流程重新按目录结构跑了一遍确认脚本能跑通、报告和数据能对得上。这步检查其实花不了多少时间但能避免接收方拿到文件后在第一步就卡住。自己觉得顺手对方才能顺心这就是交付的责任心。最后分享一个实操小技巧项目收尾时我建议把“特征工程”和“模型评估”的关键代码脚本抽出来单独留一份别混在完整流程里。因为实际落地过程中业务方经常会提出新问题比如“换了一个机场数据格式类似但某些字段含义变了”这时候有一个已经跑通的、可修改的特征脚本就能快速适配到新数据集上不用把整个项目从头翻一遍。另外如果你也打算用机器学习做类似调度分配问题记住一个判断标准先问自己这个问题能不能构造出稳定的“航班-槽位”训练样本如果能那机器学习大概率能帮上忙如果连标签都定义不清楚那再强的模型也没用。这个思路比纠结选哪个模型重要得多。本文还有配套的精品资源点击获取