Ich baute eine KI, um Airline-IROPS-Crew-Recovery zu übertrumpfen. Ein reifer CBC-Solver schlug sie — also wurde die Behauptung zu Legalität konstruktionsbedingt und Sekunden statt Gerangel.
AirlinesAviationOptimization

Ich habe eine KI gebaut, um den Solver bei der Airline-Crew-Recovery zu schlagen. Sie hat verloren — und aus dieser Niederlage wurde das Produkt.

Ashutosh SinghalAshutosh Singhal5. Juli 202611 min

Der Benchmark, den ich zum Gewinnen gebaut habe — und verloren

Ich habe die erste Version von StormCrew gebaut, um den Solver zu schlagen. Das war der ganze Pitch in meinem Kopf. Die Operations Control von Fluggesellschaften läuft auf jahrzehntealten Optimierungsengines, also wenn ich etwas Klügeres trainieren könnte, hätte ich eine Geschichte, die es wert wäre zu erzählen. Ich habe Wochen damit verbracht. Dann habe ich meine Recovery-Engine im Benchmark gegen CBC, einen ausgereiften Open-Source-Mixed-Integer-Solver, der schon im Kampfeinsatz war, bevor ich eine for-Schleife schreiben konnte, und CBC hat gewonnen. Nicht um einen Rundungsfehler.

Ich erinnere mich, wie ich auf die zwei Zahlenspalten starrte und diese spezifische Leere spürte, die man fühlt, wenn das Experiment, das man entworfen hat, um sich selbst recht zu geben, einem stattdessen Unrecht beweist. Der Solver war schneller. Seine Pläne waren billiger. Er hat kein einziges Mal einen unzulässigen Flugplan zurückgegeben. Meine clevere Version hat in allen drei Punkten verloren.

Also habe ich das Einzige getan, was mir ehrlich erschien. Ich habe die Behauptung geändert, nicht die Zahlen.

Ich habe die KI gebaut, um den Solver zu schlagen. Der Solver hat gewonnen. Der interessante Teil war alles, was dieser Kampf verdeckt hatte.

Diese Umkehr ist das Rückgrat dessen, was StormCrew tatsächlich geworden ist, und ich halte sie für die nützlichere Geschichte als die, die ich ursprünglich erzählen wollte. Sie können das Ganze selbst ausprobieren unter veriprajna.com/de/demos/stormcrew-airline-irops-crew-recovery-in-sekunden-legal-durch-konstruktion, aber lassen Sie mich durchgehen, was meine Meinung geändert hat — denn genau dieser Pivot ist der Kern.

Was bricht eigentlich, wenn ein Sturm einen Hub lahmlegt?

Ich bin zurückgegangen und habe die Post-Mortems der Kernschmelzen gelesen, nachdem CBC mich demütigt hatte, und das Scheitern lag fast nie daran, dass „die Mathematik etwas suboptimal war“. Unregelmäßiger Betrieb, das Branchenwort IROPS, kostet Fluggesellschaften rund 60 Mrd. $ pro Jahr (IATA). Die kanonische Katastrophe, Southwest im Dezember 2022, lag bei etwa 1,2 Mrd. $, mit rund 16.900 Annullierungen und grob 2 Millionen gestrandeten Passagieren. Als ich nachzeichnete, wie solche Tage tatsächlich auseinanderfallen, war der Optimizer nie der Bösewicht.

Stattdessen brechen drei Dinge. Die Recovery ist zu langsam: wenn ein Sturm einen Hub lahmlegt, ist das Neu-Crewing der nachgelagerten Kaskade immer noch weitgehend ein 4- bis 12-stündiges manuelles Gerangel (ein belegter Benchmark, keine Zahl, die ich mir ausgedacht habe). Sie ist zu riskant: jedes Neu-Crewing unterliegt FAA Part 117-Dienst- und Ruhezeiten sowie einem carrier-spezifischen Gewerkschafts-CBA, und eine einzige Verletzung ist ein Compliance-Ereignis, keine Fußnote. Und sie ist zu undurchsichtig: die Kaskade nachgelagerter Flüge, die gerade ihre Crew verloren haben, bleibt unsichtbar, bis diese Flüge bereits annulliert werden.

Genau das Letzte ist es, was die Legacy-Tools verfehlen, und es ist das Erste, was ich die Demo zeigen ließ. Injizieren Sie einen Sturm am geschäftigsten Hub, und die App hebt den Explosionsradius hervor: die gegroundeten Flüge plus die um eine Stufe nachgelagerten Flüge, die ihre Crew über die Rotation verlieren. Im geseedeten Szenario sind 53 Flüge im Netzwerk gefährdet.

StormCrew-Dashboard nach Injektion eines Sturms am Hub DEN, mit 53 nachgelagerten Flügen in Bernstein als Explosionsradius hervorgehoben
Injizieren Sie den Sturm, und der Explosionsradius leuchtet auf: 53 Flüge im Netzwerk haben gerade ihre Crew verloren — die Kaskade, die Legacy-Tools erst sehen, nachdem Annullierungen beginnen.

Seit der DOT-Automatik-Erstattungsregel (Okt. 2024) ist jede kaskadierende Verspätung von drei Stunden und mehr jetzt auch ein automatischer finanzieller Schlag. Die Kosten, langsam, illegal oder blind zu sein, stiegen also genau in dem Moment, in dem die Tools gleich blieben. Keines dieser drei Probleme wird durch eine bessere Zielfunktion behoben. Ich hatte das Eine optimiert, das bereits in Ordnung war.

Warum habe ich aufgehört, CBC schlagen zu wollen, und angefangen, ihn zu füttern?

Ich habe mich mit der Niederlage gegen CBC abgefunden, indem ich ihm einen anderen Job gab. Statt mit dem Solver zu konkurrieren, habe ich ihn ummantelt. Die Pipeline ist durchweg echter, deterministischer, geseedeter Code: ein synthetisches Airline-Netzwerk und Crew-Zustand, ein Störungsinjektor, der den Explosionsradius per Graph-Erreichbarkeit über die Rotation berechnet, ein Duty-Generator, dann CBC als Engine, die den Plan wählt, dann ein Shadow-Compare gegen Nichtstun, dann ein signiertes Zertifikat.

Wenn ich es auf dem geseedeten Sturm laufen lasse, erzeugt der Generator 1.762 legale Recovery-Duties (52 davon Deadhead-Repositionierungen, um Crew dorthin zu bringen, wo sie gebraucht wird), plus 53 Cancel-Fallbacks, für 1.815 Kandidaten-Spalten insgesamt. CBC löst die resultierende 1.815-Variablen-, 115-Constraints-Minimum-Cost-Set-Partition bis OPTIMAL und liefert einen Plan in etwa 0,11 Sekunden. Ergebnis in diesem Szenario: 52 von 53 Flügen neu besetzt (98 Prozent), 1 Annullierung, 34 Crews eingesetzt (25 Line und 9 Reserve).

CBC-Solve-Stufe mit 1.815 binären Variablen, 115 Constraints und Solver-Status OPTIMAL
Die Engine auf dem Bildschirm ist CBC, offengelegt, nicht getarnt: eine 1.815-Variablen-, 115-Constraints-Set-Partition gelöst bis OPTIMAL. Ich nutze den Solver. Ich behaupte nie, ihn zu schlagen.
Das Problem der Fluggesellschaft war nie, dass der Solver zu schwach war. Es war, dass die Recovery zu langsam, zu riskant und unsichtbar war, bis es zu spät war.

Beachten Sie die Ehrlichkeit dieses Screenshots. Die Recovery-Engine ist CBC, namentlich auf dem Panel. Die dauerhafte Behauptung ist nicht, dass mein Code einen Solver übertrumpft. Es ist, dass der Plan in deutlich unter einer Sekunde ankommt, wo der belegte manuelle Prozess 4 bis 12 Stunden braucht, und die App diese Lücke offen misst. Ich will beim Scope präzise sein, denn das ist eine Demo und ich weigere mich, sie zu mehr aufzubauschen, als sie ist: diese exakten Zahlen sind die Ergebnisse eines geseedeten synthetischen Netzwerks, keine Open-World-Garantie. Die Geschwindigkeit-versus-manuell-Behauptung ist die, die trägt.

Die Legalitätsgarantie gehört in den Code, nicht in das Urteil eines Modells

Ich habe eine starke Meinung, die ich mir erst durch den Bau verdient habe, also sage ich sie klar. Eine Legalitätsgarantie kann nicht im Urteil eines Modells leben. Sie muss im deterministischen Code leben, konstruktionsbedingt. Die Art, eine illegale Crew-Duty davor zu bewahren, jemals empfohlen zu werden, besteht nicht darin, ein Modell zu trainieren, sie zu vermeiden, und auch nicht darin, einen Strafterm zur Zielfunktion hinzuzufügen und zu hoffen, dass der Optimizer darum herum navigiert. Es besteht darin, die illegale Duty von vornherein unmöglich zu generieren.

Also werden die Constraints zur Generierungszeit erzwungen, nicht danach bewertet. Part 117 begrenzt eine Duty-Periode auf 780 Minuten, die Flugzeit auf 480 Minuten, und verlangt eine minimale Sit von 30 Minuten; der Beispiel-CBA begrenzt eine Duty auf 4 Segmente. Nur Duties, die all das erfüllen, werden jemals zu Kandidaten-Spalten. Das ist Action Masking. Eine illegale Zuweisung wird nicht bestraft, sie ist nicht darstellbar. Was immer CBC mit den Spalten macht, die ihm übergeben werden, und was immer der optionale Copilot später über den Plan sagt — keines von beiden kann eine illegale Duty wieder zum Leben erwecken, denn sie war nie in der Menge.

Das gibt mir eine Invariante statt eines Scores: 0 illegale Zuweisungen, jemals, unit-getestet (die Test-Suite besteht 3/3 und prüft, dass der Explosionsradius nicht leer ist, dass nur legale Spalten generiert werden und dass der Recovery-Plan eine legale Partition ist). Einen Score können Sie regressieren. Eine Invariante können Sie versprechen.

Recovery-Ergebnispanel mit dem Legalitäts-Gate bei 0 illegal, beschriftet als im Code durch Column Masking erzwungen, nicht durch das Modell
Die Zeile, die mir am meisten am Herzen liegt: 0 illegal, im Code durch Column Masking erzwungen, nicht durch das Modell. Part 117 und der CBA sind konstruktionsbedingt garantiert, nicht dadurch, dass ein Modell sich gut benimmt.

Das ist auch der Grund, warum ich „autonome KI-Ops“-Pitches nicht mehr überzeugend finde, wenn die Safety-Story lautet „das Modell hat gelernt, es nicht zu tun.“ Ich habe einem Modell während dieses Baus genau einmal vertraut, eine harte Regel einzuhalten — früh —, und es war in Ordnung, bis zu dem einen Input, bei dem es nicht war. In einer Domäne, in der eine einzige Verletzung ein regulatorisches Ereignis ist, ist „meist legal“ dasselbe wie „nicht legal.“ Ich lösche lieber die Möglichkeit, als sie zu beaufsichtigen.

Was passiert am schlimmsten Tag des Jahres?

Ich hätte beinahe eine Version ausgeliefert, die alles automatisch freigeben würde, und ich bin froh, dass ein Szenario mich gestoppt hat. Schalten Sie die Demo auf severe, wo das Ereignis so schlimm ist, dass die Reserven erschöpft sind und nur noch etwa 30 Prozent der Crews übrig bleiben. CBC findet trotzdem einen vollständig legalen Plan, in etwa 0,05 Sekunden, weiterhin 0 illegal. Aber dieser Plan bedeutete die Annullierung von 20 von 53 Flügen, das sind 38 Prozent des Radius, deutlich über der 15-Prozent-Auto-Freigabe-Schwelle des OCC.

Der richtige Schritt dort ist nicht, stillschweigend einen Plan abzustempeln, der mehr als ein Drittel des betroffenen Netzwerks annulliert. Also wechselt der Status auf ESCALATE, menschliche Freigabe erforderlich, mit angezeigtem Grund. Der Plan wird trotzdem berechnet, bleibt legal und wird dem Controller angezeigt (33 Flüge recovered, 62 Prozent des Radius). Er wird nur nicht automatisch freigegeben.

Severe-Szenario-Ergebnis mit ESCALATE an den Controller, weil die Recovery 20 von 53 Flügen annulliert, 38 Prozent, über der 15-Prozent-Schwelle
Der ehrliche harte Fall: Ein legaler Plan, der trotzdem 38 Prozent des Radius annulliert, wechselt auf ESCALATE, menschliche Freigabe erforderlich. Der Plan wird gezeigt und markiert, nie durchgewinkt.
Der Teil, den die meisten „autonomen“ Pitches überspringen, ist zu wissen, wann die korrekte Handlung darin besteht, nicht zu handeln und den Tag einem Menschen zu übergeben.

Dieses Gate zu bauen hat verändert, wie ich über die ganze Kategorie denke. Eskalation ist nicht das Scheitern des Systems. Es ist die Ehrlichkeit des Systems über einen schlechten Tag. Ein Advisor, der immer eine selbstsichere Antwort zurückgibt, ist leicht zu demonstrieren und gefährlich zu vertrauen. Der, der gelegentlich sagt „dieser Fall liegt über Ihrer Linie, Sie entscheiden“, ist der, den ich tatsächlich neben einen Controller um 3 Uhr morgens stellen würde.

Das Artefakt, das ich wollte, wenn ich der Controller wäre

Ich habe mich immer wieder gefragt, was ein Operations Controller am nächsten Morgen brauchen würde, und die Antwort war kein Dashboard, sondern eine Aufzeichnung. Also versiegelt jede Recovery in ein signiertes recovery_plan.json: die Störung, der gewählte Plan Aktion für Aktion mit Crew und Flug, die spezifische Part 117- und CBA-Klausel, die pro Aktion gegen ihre Obergrenze geprüft wurde, die Recovery-Wall-Clock und die Savings-Zahlen. Es ist der Audit-Record des OCC darüber, warum diese Recovery empfohlen wurde, mit einem Klick exportierbar.

Zertifikatsstufe mit dem signierten recovery_plan.json, Status RECOVERED, regulatorischen Limits und Legalitätsgarantie
Jede Empfehlung exportiert ein signiertes recovery_plan.json: Status, die geprüften Part 117-Limits und die Legalitätsgarantie als durch Action Masking erzwungen. Der Audit Trail ist der Punkt.

Es gibt auch einen optionalen Plan-Copilot, und ich will klarstellen, wo er sitzt. Er ist ein dünner Adapter zu einem LLM (Standard Claude, Provider austauschbar, oder eine lokale Bridge ohne Key), der den Plan in einfachem Englisch erklärt. Er enthält sich vollständig ohne Key, alles andere läuft offline und keyless, und er lebt außerhalb des Entscheidungskerns. Die deterministische Maske, CBC und das Eskalations-Gate entscheiden. Das Modell erzählt nur hinterher. Ich habe ihn absichtlich dort platziert, denn in dem Moment, in dem das Sprachmodell beeinflusst, ob eine Duty legal ist, habe ich die Garantie verloren, die ich den ganzen Build lang verdient habe.

Beim Thema Savings gilt dieselbe Disziplin. Im Normal-Szenario zeigt der Shadow-Compare 52 vermiedene Annullierungen und rund 2,37 Mio. $ vermiedenes DOT-Erstattungsrisiko (ein 300-$-pro-Passagier-Modell) gegenüber Nichtstun. Das ist die schmeichelhafteste mögliche Rahmung, denn die Baseline ist, den gesamten Explosionsradius stranden zu lassen, und sie ist als illustrativ für genau dieses eine Szenario gekennzeichnet. Es ist keine Headline und erst recht kein Beweis, dass mein Code irgendetwas übertrumpft. Dieses Argument habe ich an CBC am ersten Tag verloren. Ich werde es nicht still in einer Marketing-Zahl zurückgewinnen.

Was bedeutet „erweitern, nicht ersetzen“ also wirklich?

Früher dachte ich, Erweiterung sei die zaghafte Wahl, das, was man sagt, wenn man das Mutige nicht bauen kann. Jetzt denke ich das Gegenteil. Der Käufer hier besitzt bereits einen guten Solver-Stack, Jeppesen oder IBS, und kann Rip-and-Replace, Lock-in oder eine unerklärte Empfehlung am schlimmsten Tag seines Jahres nicht tolerieren. Diesem Käufer zu sagen „werft ihn raus für mein klügeres Modell“ ist nicht mutig — es ist eine Behauptung, die ich mir selbst schon mit einem Benchmark widerlegt habe.

Was ich ehrlich anbieten kann, ist die operative Schicht um den Solver herum, dem sie bereits vertrauen. Die Kaskade sichtbar machen, bevor sie zubeißt. Illegale Moves unmöglich zu erzeugen statt nur abzuschrecken. Stunden in Sekunden kollabieren. Und wissen, wann der Tag schlecht genug ist, dass die richtige Antwort Eskalation ist, nicht automatische Freigabe. Alles in der Demo ist synthetisch und geseedet — das Netzwerk, die Crews, die Störung, die Dollar-Zahlen —, nirgendwo echte Airline-Daten. Was real ist, ist der Mechanismus, und Sie können ihn End-to-End laufen sehen unter veriprajna.com/de/demos/stormcrew-airline-irops-crew-recovery-in-sekunden-legal-durch-konstruktion.

Und wenn Sie es lieber sehen als mich es beschreiben hören, hier läuft das Ganze End-to-End.

Hier ist die Frage, die ich nicht mehr loswerde, seit CBC mich geschlagen hat. Wenn der Solver, gegen den Sie antreten, bereits gut ist und der Käufer ihn schon besitzt, bleibt nicht eine bessere Antwort zu bauen. Es bleibt eine bessere Beziehung zur Antwort: schneller, beweisbar legal, sichtbar und demütig genug zu eskalieren. Also: Wie viel von der KI, die Ihnen dieses Jahr verkauft wird, löst tatsächlich den harten Teil — und wie viel löst den Teil erneut, der nie kaputt war?

Verwandte Forschung

Auch veröffentlicht auf

Entwickeln Sie Ihre KI mit Zuversicht.

Arbeiten Sie mit einem Team zusammen, das über umfassende Erfahrung im Aufbau der nächsten Generation von Unternehmens-KI verfügt. Wir helfen Ihnen, eine KI-Strategie zu entwerfen, zu entwickeln und einzuführen, der Sie vertrauen können.

Veriprajna Deep-Tech-Beratung ist auf die Entwicklung sicherheitskritischer KI-Systeme für die Bereiche Gesundheitswesen, Finanzen und Regulierung spezialisiert. Unsere Architekturen werden anhand etablierter Protokolle validiert und mit umfassender Compliance-Dokumentation belegt.