ИИ-система воспроизвела решение авиадиспетчеров для 296 пассажиров

Аэропорт временно закрыт, самолёт застрял, а вечером у него ещё несколько рейсов. Отменить самый пустой вылет кажется разумным решением — пока не выясняется, что его пассажиров некуда пересадить. Более загруженный рейс иногда проще убрать из расписания: на соседних вылетах есть места, а самолёт после отмены останется там, где нужен дальше.

Именно такую задачу команда Сергея Ершова разбирала с неназванной российской авиакомпанией. По описанию авторов, они собрали восемь ИИ-инструментов и после серии исправлений воспроизвели решение сотрудницы коммерческой службы: отменить пару рейсов с 296 пассажирами. Пассажиров можно было разместить на других вылетах в ближайшие два дня, сохранив дальнейшее расписание борта.

Модель читает сообщения, Python считает места

Самая полезная деталь кейса — распределение работы. Языковая модель разбирает текст или скриншот сообщения о сбое и формулирует объяснения. Загрузку рейсов, доступные места, ранжирование и другие расчёты выполняют обычные Python-скрипты. Сотрудник проверяет результат перед переходом к следующему этапу.

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

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

Реальный сбой вскрыл правила, которых не было в задании

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

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

Ошибки нашлись и в обработке времени. При фильтрации публикаций сообщение о снятии ограничения могло выпадать за границу выбранного периода. В одном расчёте система получила 1093 минуты вместо 1346. Авторы связали события введения и снятия ограничения, добавив проверки для интервалов, переходящих через полночь.

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

Что доказывают 164 прогона

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

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

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