我們打造了更快的航空公司機組求解器，它只是敗得更快
我第一次在真正的連鎖崩潰期間坐在某家航空公司的營運控制中心裡，那時剛過凌晨三點，一場冬季風暴在數小時前關閉了一個關鍵站點。房間前方的視訊牆上一片紅——一個接一個的取消——而我印象最深的是，沒有人在使用那套航空公司花了數百萬美元購買的機組排班求解器。調度員們把鍵盤推到一旁，正用手工處理斷裂的機組配對，靠著試算表和一塊白板，而那正是這套軟體本該證明自身價值的時刻。
這個畫面最終促使我們打造出用於 IROPS 復原的航空公司機組排班 AI——但方式與我預期的不同，而且是在我支持了錯誤的解法並眼睜睜看著它失敗之後。IROPS，如果你不曾有幸體驗過，是業界對不正常營運的稱呼：那些風暴、關閉，以及當班表瓦解時的連鎖混亂。它讓航空業損失估計達每年 600 億美元，根據 IATA，約占全球航空業營收的 8%。全球大約每五個航班就有一個受其影響。而我那晚學到的骯髒祕密是：航空業中最精密的最佳化軟體，本質上就是被設計成在那些代價最高的事件期間毫無用處。
求解器正在為一家已不存在的航空公司做最佳化
了解傳統機組求解器實際上做什麼會有幫助。它們執行列生成（column generation）——一種分支定價（branch-and-price）最佳化技術，在為一份已知班表尋找成本最低的合法人員配置方式上確實非常出色。問題就出在一個詞上：已知。求解器擷取網路的一張快照，凍結時間，並為那個凍結的世界計算出最佳的機組派遣。它以批次週期執行，通常每 30 到 60 分鐘一次。
在正常營運下，這沒問題。世界在兩個週期之間幾乎不動。但在連鎖崩潰期間，網路狀態每隔幾分鐘就改變一次。機組移動。銜接中斷。飛機滯留。等到求解器傳回一個解時，它拿到的輸入已經錯了——所以那個答案是為一家已不存在的航空公司所擬定的完美計畫。
我開始把這稱為最佳化與執行的落差：求解器所假設的世界，與停機坪上真正存在的世界之間的距離。在孤立的延誤期間，這道落差無害。但在連鎖崩潰期間，它是致命的，因為求解器是為效率而打造的——已知世界中成本最低的班表——而你在凌晨三點迫切需要的是韌性：一份在未知世界中能撐得下去的班表。
傳統機組求解器最殘酷的地方在於，在崩潰期間它照樣運作——平靜地遞給你一份完美無瑕的計畫，而那個網路早在它計算的過程中就已瓦解。
我們為什麼不能乾脆讓求解器變快就好？
這是我並不引以為傲的部分，卻也是真正重要的部分。
當我的團隊第一次審視這個問題時，我們的診斷是工程師顯而易見的那種診斷：求解器太慢了。世界每五分鐘就在改變，而最佳化器要花三十分鐘到一小時，所以就把落差補上——讓它變快。我們投入了實實在在的時間去打造一個更快的復原引擎，靠著成本較低的啟發式方法，在營運決策視窗之內得出一個可行的答案，而不是苦等一個可證明為最佳的解。
而它確實奏效了，就「傳回答案更快」這個狹隘意義而言。然後我們拿真實的中斷資料來測試它，我眼睜睜看著它信心滿滿地產出一份份早已失效的復原計畫，只不過來得更早罷了。我們打造出的是一台以更高速度為一家幻影航空公司做最佳化的機器。
錯誤在於把速度當成瓶頸。它並不是。瓶頸在於那些輸入全是虛構。求解器——包括我們的在內——需要確鑿的事實：「Smith 機長在丹佛的 B7 登機門。」但在連鎖崩潰期間，Smith 機長可能在飯店，可能在員工接駁車上，也可能租了一輛車正開到往科羅拉多泉的半路上。對世界誠實的描述是「大概在丹佛」，而列生成求解器根本無法拿大概來做任何事。我們一直在為一個資料根本是垃圾的問題把答案磨得更精準。
那次失敗正是這項產品存在的原因。如果我們當初把那個快速求解器推出去，我們賣給航空公司的不過是一條更快犯下同樣昂貴錯誤的途徑。
那個 12 億美元的資料黑洞
如果你想看看這種失敗在最大規模下的樣子，就看看 2022 年 12 月西南航空（Southwest）發生了什麼。那場崩潰讓這家航空公司損失了大約12 億美元，取消了大約16,900 個航班，並在假期期間讓將近兩百萬名旅客滯留。
流行的說法是「軟體太老舊」。真實的故事則更具體、也更有用。西南航空的機組排班系統 SkySolver 遭遇了它無法算穿的組合爆炸。但在那底下，這家航空公司弄丟了自己飛行員和空服員實際身處何方的掌握。機組位置回報主要透過電話進行——滯留在外站的機組打電話給排班中心，而那裡的等候時間攀升到數小時。那樣的延遲造就了我心目中的資料黑洞：系統正在為一群並不在它以為位置上的機組產生班表。它是在為一個幻影網路做最佳化，而點對點的航線結構意味著沒有樞紐這種讓機組和飛機自然重新匯聚的「再生點」，於是波及範圍就一站接一站地不斷擴散。
這並不是大家早已修復的陳年往事。2024 年 7 月，精神航空（Spirit）的排班系統為其 43% 的可用飛行機組製造了相互衝突的派遣，這是一起估計損失 5,000 萬至 1 億美元的事件，因為該系統缺乏在中斷期間乾淨俐落地重新指派機組的彈性。這種模式一再重演，是因為底層架構——為一張凍結的快照做最佳化、要求確定的輸入——在整個業界都是一樣的。
值得肯定的是，西南航空以砸錢作為回應：大約在 2024 年於技術上投入 17 億美元，作為一項更龐大的多年期計畫的一部分，包括一次大幅縮減其資料中心規模的 AWS 遷移，以及一套速度提升約 30% 的排班演算法。這種直覺是對的。但同一套架構的更快版本——正是我們自己差點掉進去的陷阱——補上的是速度落差，卻讓資料確定性落差大敞著。
如今當延誤超過三小時會發生什麼？
在航空史上的大多數時候，緩慢的復原讓你付出的是商譽。憤怒的旅客、負面報導、一些兌換券。這道算式在 2024 年 10 月 28 日改變了。
那天，美國運輸部（DOT）的自動退款規定生效了——史上第一個強制性的自動退款要求。任何超過三小時的國內延誤（國際航班為六小時）現在都會觸發現金退款，並在七個工作日內支付，旅客甚至無需開口要求。不是兌換券。不是改訂。是現金。
為一家每天執飛 300 個起飛航班的中型航空公司算一算。在真正糟糕的一天，如果其中哪怕只有六分之一——50 個航班——滑過三小時的門檻，以平均票價 280 美元、每班 150 名旅客計算，你面對的大約是單單一天就有 210 萬美元的強制退款風險敞口。緩慢的 IROPS 復原過去是一個聲譽問題。如今它是一筆在同一週就見帳的支出項目。
如今，你的復原每落後一小時，就有一個計費表在跳動，而且自去年十月起，它會以現金、自動地，付給每一位受影響的旅客。
這正是為我重新定義了整場討論的部分。最佳化與執行落差的代價不再抽象。它以美元計、隨著一座在風暴開始那一刻就啟動的時鐘不斷累加。
增強求解器，而非取代它
以下這個決定定義了我們的作法，而它是刻意選擇的、毫不花俏的一個：我們不取代你的求解器。
現有的求解器編碼了數十年來針對特定航空公司的領域知識，而它們周遭的這個領域正在整併，而非崩解。Jeppesen——業界標準，擁有超過一百家航空公司客戶——由波音（Boeing）賣給了 Thoma Bravo，價格為105.5 億美元，時間是 2025 年 4 月，是航太史上規模最大的技術資產剝離之一，此後更推出了 Stratosphere，一個用於預測性中斷管理的 AI 層。IBS Software 的 iFlight 平台正贏得現代化、雲端原生的部署——大韓航空（Korean Air）於 2026 年初上線，Aeroitalia 和 Groupe Dubreuil 旗下的航空公司等業者也正轉移到它上面——並有與 AWS 的共同工程合作作為後盾。Optym 的 CrewSolver 在規劃端帶來有據可查的 3–7% 機組成本降低。
這些都不是敵人。但請注意它們各自擅長的地方：規劃階段的最佳化與預測性分析——那個已知的世界，被漂亮地計算出來。即時的、輸入不確定的復原問題，才是那道始終敞開的落差。一次完整的平台替換也是一個為期 12 到 18 個月的專案，而沒有任何一位營運主管願意為了修好那不管用的 15 天，把一年運作 350 天的系統整個拆掉。對真正簽下合約的資訊長（CIO）來說，這筆帳比行事曆更難算：把一套編碼了數十年特定航空公司 CBA 邏輯的系統拆掉——而且正好是在 Jeppesen 自身的所有權剛以 105.5 億美元易主、其長期路線圖還是個未知數的當口——這是大多數技術組織不會下的賭注。坐在既有安裝環境的旁邊、消化它的資料饋送而非替換它的資料綱要，才是他們唯一會放行的整合方式。
於是我們打造了一個由機器學習驅動的 IROPS 復原引擎，它就緊挨著一套既有的 Jeppesen 或 IBS 安裝環境運作，處理核心求解器辦不到的事：機組位置不確定的連鎖中斷、覆蓋全網路的波及範圍分析，以及在數分鐘內產出的復原計畫——而人工復原通常要花 4 到 12 小時。區域案例資料顯示，自動化可將該復原時間縮短約 78%。重點不在於比現有系統更聰明，而在於能在現有系統從未被設計來應對的那種確切情況下派上用場。
教一個模型與「大概在丹佛」共處
一旦我們不再試圖讓求解器變快，真正的工程問題就變得清晰起來：打造某種在不確定性中如魚得水、而非被它噎住的東西。
第一塊是機組位置情報。我們不再要求一個確定的位置，而是餵給模型機率性的位置——把現有的任何即時訊號與歷史行為融合起來，讓系統能推理出某個機組可能所在之處，而不是苦等一通已在等候佇列裡排了四小時的電話。這單單一個轉變——從「非確定即無」到「機率分布」——正是讓一份復原計畫在與真實連鎖崩潰接觸後仍能倖存的關鍵。
第二塊是把網路當成一張圖（graph），並在故障擴散之前就分析它們將往哪裡蔓延——也就是波及範圍，對應到這家特定航空公司的航線結構，讓你能看出哪一個站點的關閉會在兩小時後悄悄取消六個下游航班。
第三塊是一個情境模擬器，實際上就是這套營運的數位孿生（digital twin），讓營運團隊能事先預演一場冬季風暴情境，並在沒有真正風暴、沒有真正時鐘壓力的情況下測試復原策略。在資料豐富的地方，航空業已經信任數位孿生——漢莎航空（Lufthansa）的 AVIATAR 平台每天在 34 家航空公司的整合中吸收 23.7 TB 的資料，並在維修故障預測上達到 93.6% 的準確率。機組與排班的孿生仍處於萌芽階段，而那正是機會所在。
而貫穿這一切的是約束引擎。每一項建議都必須在 FAA Part 117 疲勞規定之下合法——8 到 9 小時的飛行時間上限、9 到 14 小時的執勤時段——以及在航空公司工會合約之下合法，而後者往往更為嚴苛，超出法規的規定。大多數供應商把那些規則當成「設定」。我們則把按機隊、按駐地編碼一家航空公司特定的集體談判協議（CBA）視為核心工程，因為一份違反 CBA 條款的復原計畫根本不是計畫——而是一樁申訴案。
為什麼我們先以影子模式運行
這個行業裡的人不信任一個在凌晨三點告訴他們如何調動飛行員的黑盒子，這很合理。所以我要告訴你我最常聽到的反對意見，因為我自己也曾這麼想。
早期有一位營運副總大致對我們說，他們才剛向現有供應商授權了 AI 中斷附加模組，看不出為什麼還需要我們。合理。然後下一場風暴來了，那個附加模組給了他們預測，卻沒有可執行的機組復原，於是調度員又回到白板前。那場對話教會我的區別是：以下兩者之間有著天壤之別——一邊是用於面向旅客聊天的代理式 AI（agentic AI）——2026 年會議圈的流行語——另一邊則是替機組與飛機做出營運決策的 AI。一個為旅客重新安排行程的聊天機器人是個好東西。但它與復原一個網路並不是同一個工程問題。
這就是為什麼任何一家航空公司第一次運行我們的引擎時，它並不會碰觸實際營運。它運行於影子模式：我們模型的建議擺在人類調度員實際做出的決策旁邊，而我們就在這家航空公司自己的中斷事件上，日復一日地衡量兩者的落差。信任不是在銷售簡報裡宣稱出來的。它是在一張對照表上、在毫無營運風險的情況下贏得的，直到營運團隊自己認定這些建議比白板更好。
你不會靠一個基準測試就贏得為別人重新調度飛行員的權利。你是靠著默默地、在一個人類身旁、連續數週都做對，在任何人不得不相信你之前，才贏得它的。
老實說，正是在觀看影子模式運行時，我才明白我們真正在賣的是什麼。不是一個最佳化器。不是速度。我們賣的是一種能讓營運主管在他們一年中最糟的那個夜晚相信一台機器的方法——而這份信念必須在風暴來臨之前建立，而不是在風暴之中。
那 15 天究竟值多少
如果你經營一家中型航空公司的營運，你的機組求解器一年有 350 天運作良好。我不是來反駁這一點的。問題在於那不管用的 15 天會發生什麼——而那些正是製造出十億美元頭條、43% 機組被錯誤指派的稽核，以及如今自去年十月起按小時計費的自動現金退款的日子。
整個業界一再犯下的錯誤——也是我最先犯下的、用我自己那個更快求解器犯的錯誤——是把那 15 天當成一個靠更用力計算就能解決的速度問題。它們不是。它們是一個確定性問題，而你無法藉由向一個正在主動瓦解的世界索取更多確定性，來解決一個確定性問題。你要解決它，得靠打造某種能在不確定性下推理、在災難來臨之前先預演、並在被攤到陽光下信任之前先於暗處證明自己的東西。那正是我們打造的引擎，並在我們的航空公司機組排班 AI 解決方案中有完整的說明。
今夜某處有一個營運控制中心，那裡的視訊牆平靜而翠綠，一台機組求解器正完全按照設計嗡嗡地跑著它的批次週期。我們所做的工作，是為了那個房間轉紅的夜晚——當電話塞爆、配對斷裂的速度快到沒有人來得及把它們寫下來，而一位調度員伸手去拿白板，因為軟體所要求的那份確定性已經悄悄離場。整件事的重點在於確保，在那個夜晚，這台機器仍然誠實地推理著一家它再也無法完全看清的航空公司。
