Научили ИИ перестраивать расписание авиарейсов в непредсказуемых ситуациях: реальный кейс

Разработали AI-инструменты для известной российской авиакомпании, которые помогают сотрудникам принимать решения, когда что-то идет не по плану. Рассказываем, как отработала система, когда мы прогнали её на реальном сбое.

Когда аэропорт временно прекращает принимать и отправлять самолёты, авиакомпании приходится оперативно перестраивать расписание. Просто перенести или отменить несколько рейсов — не вариант. Нужно учитывать, где находятся самолёты, какие рейсы они должны выполнить дальше, сколько пассажиров уже купили билеты и можно ли пересадить их на другие вылеты.

Вместе с командой одной из российских авиакомпаний мы решили проверить, можно ли часть этой работы доверить искусственному интеллекту ^[1]. Разобрали процессы коммерческой службы, разработали восемь AI-скиллов и объединили их в систему, которая помогает выбирать варианты изменения расписания. А затем прогнали на реальных данных. Расскажу обо всем по порядку.

С чего все началось

Я — Сергей Ершов, AI-энтузиаст. Вместе с партнёром мы проводим тренинги и внедряем AI в бизнес-процессы разных компаний. И эта история началась совсем не с расписания.

Авиакомпания пришла с запросом на обучение ^[2] топ-менеджмента. А тренинги мы обычно проводим довольно прикладные, чтобы сотрудники сразу могли попробовать нейросети на рабочих задачах и понять, где и как всё это можно применять. И таких тренингов у нас было несколько: один для топ-менеджмента, второй для финансовой службы и третий — для коммерческой службы, той что занимается расписаниями и разруливает непредвиденные ситуации.

Так совпало, что тренинг для коммерческой службы проходил 20 августа — на следующий день после масштабного сбоя ^[3] 18–19 августа, когда временные ограничения затронули более 230 рейсов авиакомпании.

К тренингу мы уже собрали первую рабочую версию системы и в теории она умела по готовым данным собрать общую картину сбоя и выдавать решение: какие рейсы отменять, какие переносить, куда пересаживать пассажиров. 

Мы прогнали систему на свежих данных, выяснилось, что логика ^[4] принятия решений намнооооого сложнее, чем нам казалось изначально. Стали разбираться.

Как авиаперевозчик действует во время сбоев в расписании

Разберем на примере: аэропорт закрывают или один из самолётов выходит из строя. Информация попадает в систему расписания, и сначала за задачу берётся центр оперативного управления. 

Если ограничение кратковременное, можно просто подождать. Для «ковра» ориентир — примерно час: если за это время ограничение не сняли, расписание уже нужно перестраивать.

Сначала оперативное управление пытается решить проблему без отмен

Команда переставляет рейсы между бортами, меняет последовательность их выполнения, ищет свободный самолёт. Но у каждой перестановки есть последствия: самолёт, который мы забрали с одного рейса, через несколько часов должен был выполнить следующий, потом ещё один. Поэтому одна замена может потянуть за собой целую цепочку — и меняются борта связанных рейсов.

Когда одних перестановок недостаточно, подключается коммерческая служба

Задача этих ребят — оперативно пересобрать расписание таким образом, чтобы:

1. как можно больше пассажиров благополучно добрались до места назначения,

2. как можно меньше терять в деньгах из-за отмены рейсов и перестановок.

Здесь начинается самая трудоёмкая часть — собрать картину происходящего. Нужно посмотреть:

• текущее расписание и статусы вылетов, 

• загрузку и выручку рейсов, 

• свободные места на соседних датах, 

• ограничения конкретных самолётов, 

• режим работы аэропортов 

• и ещё ряд факторов. 

Причём данные лежат в разных системах: расписание — в одной, бронирования — в другой, часть коммерческих показателей — в BI, ограничения флота и другие параметры — в отдельных справочниках.

После этого специалисты отбирают рейсы, которые теоретически можно перенести или отменить, и сравнивают несколько сценариев. 

Спойлер: формула «отменяем самый пустой или наименее прибыльный рейс» здесь не работает.

Например, один рейс может быть менее доходным, но заполненным почти полностью, и пересадить пассажиров некуда. Другой приносит больше денег, но его пассажиров можно распределить на соседние вылеты. В такой ситуации иногда выгоднее отменить более доходный рейс.

Плюс есть рейсы, которые вообще не попадают в обычный список кандидатов на отмену. Например, чартеры. Также учитываются ограничения по допускам конкретных бортов, трансферные пассажиры, частотность рейсов.

Перед окончательным решением данные о бронированиях ещё раз перепроверяют — за время расчёта пассажиры продолжают покупать билеты, а сама ситуация может измениться.

После этого решение возвращается в центр оперативного управления. Там меняют расписание, а сотрудники службы бронирования вручную вносят изменения в Leonardo и пересаживают пассажиров.

Весь этот алгоритм мы решили переложить на AI, чтобы коммерческая служба авиакомпании в пару кликов могла получить новое расписание с учётом всех ограничений.

Разработали восемь AI-скиллов, которые повторяли действия сотрудников коммерческой службы

Мы взяли ручной процесс авиаперевозчика и разложили его на последовательные задачи. Для каждой задачи создали свой скилл. Результат работы одного скилла → входные данные для другого. 

Сотруднику коммерческой службы оставалось лишь загрузить данные на вход и подтверждать каждый следующий этап, убедившись, что система корректно завершила предыдущий.

Изначально разбили процесс на пять этапов, но в процессе поняли, что этого недостаточно, и добавили еще три

По сути наши скиллы повторяют ^[5] всё то, что обычно делали сотрудники коммерческой службы — те же задачи, в той же последовательности:

1. Разобрать сообщение о сбое. Скилл получает свободный текст, скрин или список рейсов и превращает их в подтверждённые параметры: дату, аэропорты, рейсы, тип сбоя, борта и другие вводные.

2. Определить закрытия и ограничения аэропортов. Скилл разбирает выгрузку публикаций Росавиации, восстанавливает интервалы ограничений и определяет аэропорты, где ограничения превысили заданный порог.

3. Собрать картину по затронутым рейсам. Система берёт затронутые рейсы и подтягивает по ним ёмкость, букинги, загрузку, выручку и приоритет отмены. Здесь же появляется первичная очередь кандидатов, из которой исключаются чартеры, уже отменённые рейсы и другие позиции, не требующие коммерческого решения.

4. Посчитать варианты размещения пассажиров. Скилл проверяет свободные места на том же направлении на соседних датах и считает, удастся ли разместить всех пассажиров. При этом места расходуются из общего пула.

5. Определить, какие рейсы снимать первыми. Скилл собирает кандидатов в пары или цепочки, ранжирует их по заданным правилам и формирует обоснование, почему одна связка должна рассматриваться раньше другой.

6. Проверить цепочку движения самолёта. Система определяет, какие рейсы физически невозможно выполнить из-за положения борта, и считает, как сбой повлияет на следующие рейсы этого самолёта.

7. Найти возможную замену борта. Скилл проверяет, можно ли сохранить рейс, поставив другой борт или тип воздушного судна, с учётом вместимости, допусков по направлениям и ограничений аэропортов.

8. Собрать общий сценарий сбоя. Последний скилл работает как оркестратор: последовательно запускает остальные инструменты, передаёт результат одного этапа следующему и собирает общий результат.

При этом мы специально ограничили свободу AI. Языковая модель использовалась там, где нужно было разобрать сообщение человека или сформулировать объяснение результата. Все расчёты — загрузку рейсов, свободные места, вероятности, ранжирование — выполняли обычные Python-скрипты.

К рабочим системам авиакомпании мы тоже напрямую не подключались. Сотрудник сам выгружал данные из системы расписания, Leonardo и BI и загружал файлы в сценарий. 

Прогнали систему на реальном сбое 

При подготовке скиллов мы опирались на реальный сценарий сбоя 7 июля 2026 года ^[6] в Краснодаре, по которому у нас было известно, какое решение в итоге приняла коммерческая служба.

То есть мы знали исходные данные, знали логику сотрудников и знали правильный ответ. Значит, можно было прогнать через систему те же данные и посмотреть, придёт ли она к тому же решению. И всё получилось.

Система собрала картину по затронутым рейсам, проверила возможность рассадки пассажиров и в первых позициях на отмену поставила те же рейсы, которые отменили сотрудники авиакомпании.

20 августа на тренинге мы дали ей задачу намного сложнее — свежий сбой 18–19 августа ^[3], который сотрудники коммерческой службы буквально только что пережили. Тогда в течение нескольких суток неоднократно вводили план «ковёр» сразу в нескольких аэропортах: Домодедово, Шереметьево, Сочи, Краснодар, Нижний Новгород, Самара. Ограничения снимали на пару часов, затем снова вводили — и так по кругу.

Участники загружали реальные выгрузки и прогоняли разные участки сбоя. И начали всплывать нюансы, которых в наших правилах не было.

Система преждевременно отнесла один рейс к вынужденным отменам

Мы выяснили, почему: его прилёт в Домодедово попадал во временной интервал ограничения. В этот момент аэропорт работал в режиме «по согласованию». Это значит, что рейс ещё нельзя считать невозможным.

Правило поправили прямо на тренинге: разделили полное ограничение и режим «по согласованию», после чего пересчитали сценарий. Рейс перестал попадать в отмены по этой причине.

Система ранжировала отдельные рейсы, а решение нужно было принимать парами

Сотрудники объяснили, что во многих случаях решение принимается сразу по паре встречных плеч одного борта. Значит, и загрузку, и рассадку пассажиров, и последствия для расписания нужно считать для пары целиком. Правило сразу применили в расчёте и пересчитали сценарий.

Похожие уточнения появлялись в течение всего дня. Где-то неправильно считала свободные места, где-то данные расписания расходились, а система продолжала считать, когда должна была остановиться и адресовать вопрос специалисту.

Получается, базовую логику процесса мы смогли построить. Но когда за инструмент сели сотрудники, которые каждый день разруливают такие ситуации, начали всплывать десятки мелких правил и исключений.

В некоторых ситуациях даже внутри компании нет одного универсального правила. Решение зависит от профессионального суждения. Поэтому спорные моменты превратили в развилки: система предлагает вариант по умолчанию, а специалист подтверждает его или выбирает другой.

Переписали систему и провели 164 теста

После тренинга мы собрали замечания сотрудников в одну версию и начали отдельно проверять каждый скилл и всю цепочку целиком. Вскрыли еще много нюансов, которые не могли учесть ранее.

Например, скилл, который собирал ограничения аэропортов из публикаций Росавиации, однажды неверно посчитал длительность ограничения. Причина оказалась в фильтрации сообщений: в расчёт попадало сообщение о введении ограничения, а публикация о его снятии могла оказаться за границей выбранного периода и отрезаться. В одном из прогонов из-за этого интервал для аэропорта посчитался как 1093 минуты вместо 1346.

Мы переделали сбор интервалов так, чтобы введение и снятие ограничения рассматривались как связанная пара событий и граница периода не обрывала такую пару. После этого добавили отдельные тесты на переходящие интервалы — например, когда ограничение ввели поздно вечером, а сняли уже на следующие сутки.

И таких мелочей оказалось много. В итоге мы прогоняли один и тот же августовский сценарий 164 раза, а финальный прогон состоял уже из 13 последовательных шагов: от разбора сообщения о сбое до итогового Excel, проверки результата и журнала расчёта. Система проходила его целиком и сама проверяла готовую выгрузку перед тем, как показать её сотруднику.

Система пришла к тому же решению, что и специалист коммерческой службы

Во время тренинга 20 августа одна из сотрудниц коммерческой службы вручную рассчитала один из сценариев сбоя и пришла к решению отменить конкретную пару рейсов.

Ее логика была такой:

• на этих рейсах было 296 пассажиров;

• всех можно было разместить на других вылетах в ближайшие два дня;

• после отмены пары самолёт оставался в том же городе и мог выполнить следующие рейсы по расписанию;

• если сохранить исходную связку, борт возвращался слишком поздно;

• из-за этого два следующих рейса пришлось бы сдвинуть примерно на два часа.

После всех доработок мы дали системе тот же набор исходных данных и прогнали сценарий заново. Она прошла все 13 шагов и выбрала ту же пару рейсов.

Совпало и обоснование: отмена этой пары позволяла сохранить следующие рейсы и избежать их примерно двухчасового сдвига.

Для нас это был важный контрольный результат. Специалист пришёл к этому варианту, опираясь на свой опыт ^[7] и понимание всей полётной программы. После того как мы переложили эти правила в скиллы и код, система на тех же данных воспроизвела то же решение и ту же логику его выбора.

Что получилось в итоге

За время проекта мы разобрали реальный процесс коммерческой службы, вытащили часть правил из опыта сотрудников и собрали из них рабочую систему. Сейчас она может пройти весь сценарий сбоя, как человек, и выдать специалисту проверяемый результат.

Но, пожалуй, самый ценный для нас результат оказался шире. Проект начинался как обучение сотрудников работе с нейросетями. В процессе они сами стали разбираться в скиллах, менять правила под свои задачи и думать уже не отдельными промптами, а целыми AI-инструментами.

Например, ещё на первом тренинге мы рассказывали, как через MCP можно дать AI-агентам стандартный доступ к корпоративным данным и функциям. Позже команда авиакомпании уже без нашего участия создала собственный MCP-сервер. 

Смысл MCP в том, что сотруднику или AI-агенту не нужно отдельно интегрироваться с каждым сервисом авиакомпании. Он подключает MCP один раз и дальше может обращаться к доступным через него функциям прямо из привычного AI-инструмента.

Условно, сотрудник может написать в Claude: «Покажи статус этого рейса» или «Найди рейсы на такую-то дату». Claude сам понимает, какой инструмент авиакомпании нужно вызвать через MCP, получает данные и возвращает ответ в диалоге. 

На тот момент свой MCP среди авиакомпаний был только у Turkish Airlines.