简介一套聚焦航班登机口分配优化的机器学习项目资料面向航空运输管理、数据建模与算法学习人群。包内除完整数据集与最终方案报告外还提供可运行的Python主程序、遗传算法参数配置脚本及多表合并脚本完整覆盖数据预处理、特征工程、模型训练、优化求解和结果可视化的全部环节。通过实际数据与代码对照可直观掌握换乘时间计算、登机口使用率分析及遗传算法调优等核心思路。压缩包共20个文件包括7个xlsx数据表、6张png结果分析图、3个py脚本、2个xml配置和1个md项目说明整体大小仅1.6MB编排清晰。已有124人学习下载适合需要参考完整建模流程的初学者也可作为机场资源调度相关课题的入门案例。1. 航班登机口分配为什么这个机器学习项目值得跑一遍每到雷雨季航班大面积延误登机口调度员的电话就被打爆。人工排班在正常天气下还能应付延误一旦叠加很容易出现两架飞机抢同一个登机口、旅客坐着摆渡车绕圈的场面。基于机器学习的航班登机口分配就是把“哪个航班停哪个登机口、什么时候空出来”这套决策从经验规则升级成数据驱动的预测与排序。这个 zip 里有航班数据集和方案报告适合正在学建模与数据分析、或者想接触航空场景的工程师直接复现。下文按数据、特征、模型、避坑、验证的顺序把一条能跑的流程完整拆给你。2. 先把问题讲清楚数据字段、任务边界与三个评价指标2.1 从人工排班到机器学习任务本质与 ML 的切入点登机口分配在运筹学里叫 Gate Assignment ProblemGAP目标是把每个航班映射到一个登机口和一个时间窗同时满足一组约束。最常见的硬约束有四条同一登机口同一时刻只能停一个航班宽体机不能停进窄体机位国际航班和国内航班必须物理分区相邻机位之间要留安全间距不能同时停靠大翼展机型。这些约束用大白话说就是不是所有登机口对所有航班都可用。传统做法是把它建成整数规划模型交给求解器去跑。问题在于航班延误之后计划全部失效求解器要重新算一遍几十个航班重新分配可能要几分钟而现场每耽误一分钟滑行道就会多堵一架飞机。所以在实际运营里大部分机场仍然靠调度员人工判断经验成分很高这恰恰是机器学习能介入的地方。ML 在登机口分配里通常有两个切入点。一是预测层预测航班会不会延误、延误多久把预测结果当作分配器的输入。二是排序层从历史分配记录里学“哪些航班适合远机位、哪些必须靠桥”输出一个优先级排序再由规则或优化器做最终决定。这份资源里的方案报告走的也是这个套路先用数据分析摸清延误规律再训练模型输出风险标签最后接一个显式约束的分配器。这个定位极其重要。模型可以预测得不够准但最终分配结果必须满足硬约束所以 ML 不是替代调度员而是给调度员和规则系统提供更好的信息。这决定了后续三件事特征不能碰未来信息标签要用运营结果来定义评估不能只看准确率。理解了任务本质再看数据集就不会一头扎进特征堆里出不来。2.2 数据集字段拆解航班表、登机口属性、时间窗这类数据集一般由三个逻辑表组成。航班信息表记录每个航班的时间、机型、航站楼和分配结果登机口属性表记录每个登机口能停什么机型、在哪个航站楼、是近机位还是远机位航班-登机口使用记录表则是历史运行留下的时间窗占用明细。三张表靠 flight_no 和 gate_id 关联缺一张表整个问题就没法定量。下面以航班信息表为例把建模时真正要用的字段过一遍。不要以为字段越多越好很多字段是给业务系统看的对建模不是噪音就是陷阱。字段名类型含义建模用途flight_nostring航班号分组与去重不做数值特征scheduled_dep / scheduled_arrdatetime计划起飞/到达时间时间特征的基础注意时区actual_arrdatetime实际到达时间构造延误标签预测目标aircraft_typestring机型如 A330/B738映射成宽体/窄体分类特征is_internationalint是否国际航班分区约束特征passenger_cntint旅客数密度、步行距离权重transfer_cntint转机人数衔接约束特征gate_assignedstring历史分配的登机口监督学习的标签来源登机口属性表相对简单核心就四个字段gate_id、terminal、gate_typeN 表示近机位、R 表示远机位、S 表示小机位、max_aircraft_class。这个表真正的坑在于 gate_type 的编码不统一有的数据集用 A/B/C有的用 N/R/S解压后第一件事是看取值分布而不是看文档怎么说。使用记录表则是 flight_no、gate_id、start_time、end_time 四列用来还原登机口占用情况也是后面算冲突次数的数据来源。import pandas as pd flights pd.read_csv(flights.csv, parse_dates[scheduled_dep, scheduled_arr, actual_arr]) gates pd.read_csv(gates.csv) usage pd.read_csv(gate_usage.csv, parse_dates[start_time, end_time]) print(flights.shape, gates.shape, usage.shape) print(flights.isnull().sum()) print(flights.groupby(aircraft_type).size().sort_values(ascendingFalse).head(10))这段代码做了三件事把时间字段解析成 datetime输出三表规模检查缺失看机型分布。parse_dates 最容易漏漏了之后所有时间差计算都会变成字符串运算。机型分布要重点看宽体机比例宽体机太少模型很容易偏向多数类太多则说明机场本身以宽体机为主宽窄分类特征的取值会失衡。2.3 评价指标准点率、冲突次数、摆渡车使用率排班类项目最忌讳只盯准确率。登机口分配的效果要放在运营指标下看否则模型指标和现场感受永远对不上。方案报告里通常给出一组指标核心是下面四个。指标计算方式关注点准点率 OTP实际起飞时间 - 计划起飞时间 15 分钟的比例航班运行整体质量登机口冲突次数同一登机口时间窗重叠的航班对数硬约束违反程度越低越好摆渡车使用率被分配到远机位的航班数 / 总航班数运营成本与旅客体验旅客步行距离按登机口到主楼距离加权求和体验类指标常与摆渡车率互斥冲突次数是红线指标。预测得再漂亮只要出现两个航班在同一个登机口时间窗重叠分配结果就落不了地运行系统会直接报警。所以我在所有回测脚本里都会把冲突数单独拎出来当硬指标不达标就是流程有 bug而不是模型差。摆渡车使用率和旅客步行距离是一对矛盾指标。远机位用得多摆渡车率就高旅客反而不用走太远全用近机位步行距离短但远机位资源闲置。方案报告里一般会给出基线规则下的数值再给出用 ML 之后的数值两套数字对比才有说服力。单看一个指标都是耍流氓。评估口径从第一天起就要和业务对齐。如果你只做延误预测用 MAE 或 AUC如果做完整分配就需要把模型输出接进分配器再统计冲突和摆渡车率。我见过不少方案把分类准确率写得很高一接到分配器就翻车就是因为没做闭环验证。这个闭环会在最后一章给出具体做法。3. 解压 zip 之后数据清洗与特征工程的完整流程3.1 数据质量审计缺失、重复、时区三件套把 zip 解压出来第一眼看到的往往是很规整的 CSV但规整只是表象。航班数据有三类问题几乎每次都会出现时间字段缺失、同一航班号重复出现、时区混用。经验是别急着建模先写一个质量审计函数把问题量化。这一步花二十分钟后面少踩三天坑。def audit_flight_data(df): print(缺失率:) print(df.isnull().mean().sort_values(ascendingFalse)) print(\n重复检查:) dup df.duplicated(subset[flight_no, scheduled_dep]).sum() print(f重复航班记录数: {dup}) print(\n时区检查:) tz_unified df[scheduled_dep].dt.tz is None print(时区已统一:, tz_unified)输出要看三样东西。缺失率超过 20% 的字段直接弃用航班数据里强行填充时间只会制造假信号比如把实际到达时间填成计划时间等于给模型灌输了“航班一定准点”的错误先验。重复记录要按 flight_no 加 scheduled_dep 去重但注意补班航班会用新航班号不会和原记录撞在一起如果出现完全重复的两行优先怀疑是上游导出时做了多次 union。时区是这里最阴的坑。国内数据集一般直接存北京时间但有些来自开放数据源的包把时间存成 UTC甚至两种混着存。我处理这类数据有个固定习惯所有时间字段统一转成 Asia/Shanghai再保留一列 UTC 备份后续所有时间窗计算都基于统一时区。差 8 个小时不只是数字差而是高峰时段、延误窗口这些核心特征全部错位模型可能把凌晨的航班当成中午。提示时区统一这步建议写进数据加载函数而不是在特征工程里反复处理否则每新增一个特征都要记得转时区。3.2 特征工程时间特征、机型、延误窗口特征工程只回答一个问题从现有字段里提炼出哪些信号能帮助判断航班延误风险以及适合哪种登机口。我常用四组特征时间特征、机型特征、运行状态特征、上下文密度特征。这四组不是拍脑袋每一组都对应一类真实的运行逻辑。时间特征不是简单取小时而是拆成星期几、高峰时段标记、计划起飞时刻距当日高峰的偏移。机场一天内航班密度呈双峰分布早高峰和晚高峰的登机口竞争完全不同。机型特征的核心是宽体机和窄体机的二分宽体机可选登机口少分配自由度低这类样本天然更难预测。运行状态特征里计划经停时长是一个容易忽略但很有用的信号经停时间越短延误缓冲越小航班越容易被波及。上下文密度特征则统计目标航班前后一小时同航站楼的航班总量密度越高冲突概率越大登机口越紧张。这里要特别注意所有特征只能使用计划数据和历史统计数据不能碰实际运行后的字段否则就是典型的标签泄漏。def build_features(flights): df flights.copy() df[route] df[origin] - df[dest] df[dep_hour] df[scheduled_dep].dt.hour df[dep_date] df[scheduled_dep].dt.date df[is_weekend] (df[scheduled_dep].dt.dayofweek 5).astype(int) df[is_rush_hour] df[dep_hour].isin([7, 8, 9, 17, 18, 19]).astype(int) df[is_widebody] df[aircraft_type].isin( [A330, A350, B747, B777, B787] ).astype(int) df[scheduled_ground_time] ( df[scheduled_dep] - df[scheduled_arr] ).dt.total_seconds() / 60 df[route_daily_count] df.groupby([route, dep_date])[flight_no].transform(count) df[terminal_load] df.groupby([terminal, dep_hour])[flight_no].transform(count) return df train build_features(flights) print(train[[is_rush_hour, is_widebody, scheduled_ground_time, terminal_load]].describe())这段特征工程的逻辑说明先把航线拆成 route 字段用于分组统计计划经停时长用计划到达减计划起飞得到反映航班在机场停留的缓冲同航线当日航班量和航站楼小时级密度都属于上下文特征用 transform 保证每一行拿到的是所在组的总数而不是聚合之后的对齐错位。很多人在这里用 merge 或 groupby 后直接赋值结果要么错位要么行数不对这是特征工程里最常见的低级事故。一个必须说的禁忌不要把实际到达时间直接当特征。预测登机口分配时实际到达时间是未知的你只能把前序延误当作待预测目标或者用前序航班的预计延误。我之前在这上面吃过亏把 actual_arr 算进去之后模型在验证集上 AUC 接近 0.99一上线就废具体的泄漏机制后面有一个坑专门讲。3.3 构造训练集的正确姿势时间片窗口切分登机口分配数据天然是时序结构训练集和验证集不能随机打散。随机打散会把早上的航班和晚上的航班混在一起模型学到的其实是整个机场的日期分布一旦上线预测当天数据就失灵。正确做法是按时间片切分只用历史数据训练在未来的数据上验证。一般按天切数据覆盖一个月用前四周训练后一周验证最后留两三天做最终测试。数据量够大就用滚动窗口每滚一次丢掉最老的数据让模型贴近最近的运行规律。窗口大小没有标准答案但航空数据有周周期性至少要覆盖完整的一周否则模型没见过周末周五晚上就露馅。from sklearn.model_selection import TimeSeriesSplit X train[[dep_hour, is_weekend, is_rush_hour, is_widebody, scheduled_ground_time, route_daily_count, terminal_load]] y (train[actual_arr] - train[scheduled_arr]).dt.total_seconds() / 60 15 tscv TimeSeriesSplit(n_splits4, gap24) for fold, (tr_idx, va_idx) in enumerate(tscv.split(X)): print(ffold {fold}: 训练 {tr_idx.min()}~{tr_idx.max()}, 验证 {va_idx.min()}~{va_idx.max()})这段代码的要点是 gap 参数。gap24 表示训练集和验证集之间空出 24 个样本避免相邻时间点产生信息泄露。对于航班数据我一般把 gap 设成一天对应的样本量让两边在时间上真正隔开。标签 y 在这里是“是否延误超过 15 分钟”这个二分类结果后面会直接作为分配器的风险信号。4. 建模与训练从基线模型到 LightGBM 的参数要点4.1 为什么先跑基线多数类与规则下界任何排班类项目第一步都不是上复杂模型而是先跑一个无脑基线。基线有两个作用验证数据管道从特征到标签没有断提供所有后续模型必须超过的下界。如果复杂模型连多数类都打不过问题几乎都出在特征或标签上不在模型复杂度上。在这个场景里多数类基线就是“所有航班都不延误”把样本全部预测成 0。航空数据的延误率通常低于 30%所以多数类基线准确率能到 70% 以上这给不少初学者一种“已经够准”的错觉。真正要盯的是正类的查全率和查准率延误航班查全率低分配器拿到的延误信号全是噪音。from sklearn.dummy import DummyClassifier from sklearn.metrics import precision_recall_fscore_support for tr_idx, va_idx in tscv.split(X): dummy DummyClassifier(strategymost_frequent) dummy.fit(X.iloc[tr_idx], y.iloc[tr_idx]) y_pred dummy.predict(X.iloc[va_idx]) p, r, f, _ precision_recall_fscore_support(y.iloc[va_idx], y_pred, averagebinary) print(fprecision{p:.3f} recall{r:.3f})这段代码把多数类基线的 precision 和 recall 打出来。你会发现 recall 基本接近 0因为正类样本几乎一个都没被预测出来。这个下界一旦确认后面模型要挑战的不是准确率而是让 recall 在不牺牲太多 precision 的前提下明显抬升这才是做这个任务的实际意义。4.2 模型选型为什么优先试 LightGBM 而不是深度模型航班登机口数据通常是几十万行级别的表格数据特征以类别型和数值型混合为主这种场景下梯度提升树几乎总是最优选择。LightGBM 和 XGBoost 都能用我偏好 LightGBM训练快、省内存、原生支持类别特征。深度模型不是不行而是几十万样本喂给神经网络调参成本远高于收益至少先把树模型跑完再说。LightGBM 在排班场景里的参数设置有几个点和其他二分类任务不一样。max_depth 控制在 6 到 10太深会过拟合到某些特定航线的模式上极端延误样本会被当成预测依据。num_leaves 默认 31要跟着 max_depth 调否则限制深度没意义。learning_rate 设 0.05 左右配合多一点迭代次数比大学习率少迭代更稳。类别不平衡用 scale_pos_weight让模型对少数类更敏感。import lightgbm as lgb from sklearn.model_selection import cross_val_score pos_weight (y 0).sum() / (y 1).sum() model lgb.LGBMClassifier( objectivebinary, max_depth7, num_leaves31, learning_rate0.05, n_estimators500, scale_pos_weightpos_weight, colsample_bytree0.8, subsample0.8, random_state42 ) cv_score cross_val_score(model, X, y, cvtscv, scoringroc_auc) print(cv_score, cv_score.mean())scale_pos_weight 是关键参数一般按负类样本数除以正类样本数来设。比如延误率 20%这个值大约为 4模型训练时每遇到一个延误样本相当于给它 4 倍权重召回率会明显上升。注意不要设得太大否则模型会疯狂报延误把准点航班全拖下水分配器反而因为过度保守浪费近机位资源。colsample_bytree 和 subsample 都设 0.8防止模型对某些机型或时间段过度聚焦。还有一个细节cross_val_score 的 cv 用的是 TimeSeriesSplit 而不是 KFold这是时序项目里最常见的分水岭。用 KFold 的代码即使跑通指标也没有参考价值因为同一天的航班天然高度相似随机打散后模型等于在用邻居预测邻居。4.3 训练与验证时序交叉验证与特征重要性模型训练完不能只看 roc_auc 就收工。排班场景里我还会做两件事看特征重要性是否合理按延误高发时段分层看预测效果。晚高峰的延误预测难度和凌晨完全不同一个平均 AUC 掩盖了太多细节。LightGBM 的 feature_importance 输出我习惯用 gain 而不是 split。gain 反映特征分裂时带来的信息增益总和比计数更接近“哪个特征真正有用”。如果你构造了前序延误特征它几乎总是排第一其次是计划经停时长和起飞小时这个结果符合业务直觉前序晚到必定顺延经停时间短的航班没有缓冲。如果 actual_arr 排进前三基本可以认定发生了标签泄漏。tr_idx, va_idx list(tscv.split(X))[-1] model.fit(X.iloc[tr_idx], y.iloc[tr_idx]) importance pd.DataFrame({ feature: X.columns, gain: model.booster_.feature_importance(importance_typegain) }).sort_values(gain, ascendingFalse) print(importance.head(10))特征重要性的用处不是自动删特征而是排查泄漏和冗余。几个特征排序都靠后删掉后指标不大幅下跌那它们就是冗余的。最重要的几个特征要在业务上解释得通解释不通的排在前面十有八九是造特征时引入了未来信息。这一步做完模型侧的闭环就结束了剩下的是把预测结果接回分配器。5. 避坑指南登机口分配最常见的五个坑5.1 坑一把登机口分配做成多分类模型输出一堆不可用答案现象我见过不止一个项目想一步到位让模型直接输出“这个航班应该去哪个登机口”把几十个登机口当成分类标签。验证集准确率看着很高团队也很兴奋一接进真实的分配流程结果几乎全废根本没有一个调度员敢用。这类方案在论文里常见在工程里基本落不了地。原因登机口编号是离散且每天都在变化的集合直接分类学到的其实是“航班号和登机口的绑定记忆”而不是“当前约束下哪个登机口可用”。准确率高是因为同一航班号在历史数据里反复出现模型背下了答案换一批未来航班立刻失效。解决把目标改成预测航班属性比如延误概率、远机位倾向、宽体机候选集合再把预测结果交给显式约束的分配器做最终选择。我后来做这类项目一律不直接预测门号只预测标签和排序这个边界划清楚之后方案才真正能落地。5.2 坑二时间泄漏训练指标漂亮上线就翻车现象验证集 roc_auc 高达 0.97团队都很兴奋真实运行数据上表现连多数类基线都不如甚至不如直接使用人工规则。这种项目我拆过不止一个问题几乎都出在同一个地方特征里混进了未来信息。原因特征里包含了实际到达时间、实际起飞时间这类只有航班运行结束后才知道的字段。模型在用未来信息预测未来验证集当然无解地准。航班数据里带 actual 前缀的字段都是高危对象一个不留神就被当成特征放进去。解决把特征清单里所有带 actual 前缀的字段全部审查只保留 scheduled 类字段和基于历史统计的特征。我的习惯是维护一份特征白名单每次造新特征都对照检查白名单里出现 actual 开头的字段直接拒绝入库。从那以后我跑时序项目第一步不是调参而是跑泄漏检查已经成了固定动作。5.3 坑三类别不平衡被忽略模型全预测准点现象延误标签正类只占两成模型训练完几乎全输出 0准确率不低但延误航班全被漏掉分配器拿不到任何风险信号。很多初学者看到 75% 的准确率觉得已经不错实际方案完全没用。原因没做任何不平衡处理模型用多数类策略就能拿到高准确率当然不愿意冒险把样本判成延误。梯度提升树对不平衡天生敏感正类样本少模型学到的延误模式就少预测自然偏向负类。解决用 scale_pos_weight 或 class_weight 把正类权重加上评估以查全率为主而不是准确率。注意别为召回率猛过头把模型调到疯狂报延误那样分配器会因为过度保守浪费近机位资源。理想状态是延误查全率明显提升同时准点误报率控制在一个能接受的范围。5.4 坑四模型输出后没有约束校验同一登机口出现两个航班现象分配结果里同一登机口同一时段出现两个航班运行系统直接报警报告里写的指标和实际运行完全对不上。这种情况往往发生在模型输出的预测结果被直接当成最终分配方案时。原因模型或分配器只做了预测没把“同一登机口时间窗不能重叠”当硬约束做后置校验。很多方案报告里的指标是在忽略约束的假设下算出来的相当于在理想世界里做评估落地必然冲突。解决输出前加一道约束校验器扫描三类问题时间窗重叠、机型超限、国际国内混排。任何一条不满足就拒绝该方案。这个校验器不复杂但必须强制执行尤其当 ML 输出接进自动化流程时它是最后一道防线。5.5 坑五zip 解压后编码和路径问题脚本直接崩溃现象Windows 上解压后跑脚本pandas 读 CSV 报 UnicodeDecodeError或者提示文件路径过长无法打开。还有个别 zip 存在伪加密标记双击解压会要求输密码实际上里面根本没有加密内容。原因这类资源包多数在 Linux 环境下打包文件名带 UTF-8 编码、嵌套路径很深Windows 的默认编码和路径长度限制把它拦住了。伪加密则是 zip 格式里一个特殊标记解压软件看到标记就弹密码框实际数据并没有被加密。解决统一用 Python zipfile 或 7-Zip 解压读取 CSV 时显式指定 encodingutf-8乱码再试 gbk。路径过长就先把包解压到盘符根目录比如 D:\gate_project别放在桌面那串很长的目录下。伪加密文件用 zipfile 检查加密标记假的去掉标记就能正常解压不用找什么密码工具。6. 验证与进阶怎么判断模型真的能用6.1 离线回测必须带上约束校验模型好不好不能只看 roc_auc要把预测结果接回分配流程里跑一遍离线回测。我会把验证集的预测输出交给一个最简单的贪心分配器按计划时间排序逐个航班选当前满足约束的最近登机口然后统计冲突次数和摆渡车使用率。如果模型预测延误更准贪心分配器就能提前预判把近机位留给准点概率高的航班远机位留给不确定的航班。def check_constraints(assignments, usage): conflicts 0 for gate, group in assignments.groupby(gate_id): times group[[start_time, end_time]].sort_values(start_time) conflicts (times[end_time].shift(1) times[start_time]).sum() widebody_in_small assignments[ (assignments[is_widebody] 1) (assignments[gate_type] S) ].shape[0] return conflicts, widebody_in_small这段校验脚本的核心是两行判断同一登机口的相邻航班时间窗是否重叠宽体机是否被分到小机位。回测时把冲突数、超限数和基线方案对比如果 ML 方案这两项不为零说明流程有问题不是模型问题就是分配器问题。离线回测通过之后模型才算真的能见人。6.2 进阶把模型预测接到启发式排序里如果只停在“预测延误”这一步价值有限。真正的进阶是把延误概率作为排序权重接进登机口分配的启发式调度。常见做法对每个待分配航班按延误概率从高到低排延误概率高的优先固定到近机位概率低的、远机位接受度高的往后放。这个改动不大但能明显降低摆渡车使用率和旅客步行距离方案报告里最有价值的往往就是这一层设计。我从这套流程里学到最大的教训是排班类项目里模型只是链条上的一环约束校验和数据管道才是决定成败的地方。时序切分没做、特征混进实际值、输出后不查冲突三个问题任何一个出现模型再先进也白搭。从那以后我每跑一个排班项目都先写约束校验器再回头调模型参数这个顺序再没反过。这套 zip 里的数据集和方案报告适合照着这条链路完整复现一遍把流程跑通比把准确率调高一个点更有价值。希望帮到你。本文还有配套的精品资源点击获取