Оптимізація маршрутів польотів: де втрачається час і пальне
Планування маршруту в більшості систем досі спирається на статичний розклад: коридор, ешелон і точки повороту фіксуються заздалегідь, а фактична погода, завантаження повітряного простору та обмеження щодо пального враховуються вже в польоті — вручну або постфактум.
Оптимізація маршрутів польотів ламається саме тут: між розрахунковим і реальним профілем накопичується розбіжність, і кожен рейс добирає зайві хвилини та кілограми пального.
Динамічна маршрутизація підставляє актуальні умови в момент прийняття рішення, а не за добу до вильоту.
Коли зсув вітру на ешелоні або закриття сектора надходить у модель вчасно, маршрут перебудовується до входу в зону, а не після — витрата пального перестає зростати через політ «за інерцією» за застарілим планом.
Вузькі місця планування майже завжди ті самі: дискретність перерахунку, розрив між прогнозом і фактикою, відсутність єдиного критерію вибору між часом і пальним. Затримки рейсів накопичуються не в одному великому збої, а в десятках дрібних рішень, ухвалених за неповними даними. Розбираємо, як це закривається.
Як навчання з підкріпленням змінює планування маршрутів
Навчання з підкріпленням переводить планування з режиму «перерахували розклад раз на добу» в адаптивне планування: агент маршрутизації отримує стан повітряної обстановки, погоди та завантаження коридорів, вибирає дію і вчиться на фактичному результаті рейсу.
Нагорода задається не абстрактно, а інженерно — відхилення від планового часу, витрата палива, кількість конфліктів з іншими бортами, дотримання вікон навігації.
Що дає агент маршрутизації на практиці
Навчена політика перераховує маршрут за секунди і тримає обмеження, які класичний оптимізатор перевіряє окремим проходом.
На тестових сценаріях це скорочує сумарний час у повітрі на 4–9% і знижує кількість перепланувань у польоті: борт рідше йде на запасний ешелон через раптовий фронт.
Де ефект впровадження помітний одразу
Перше — зняття ручної роботи диспетчера: типові рішення агент пропонує сам, людина підтверджує або відхиляє. Друге — стійкість до збоїв: при закритті сектора політика перебудовує не один маршрут, а зв'язку, зберігаючи пріоритети за класами бортів.
Порівняння підходів
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Класичний оптимізатор за фіксованими правилами | Стабільний розклад, рідкісні зміни обстановки | Погано переносить нові обмеження, потребує ручного налаштування правил |
| Навчання з підкріпленням у симуляторі | Багато змінних, потрібна адаптація в реальному часі | Потребує якісної моделі середовища та валідації на історичних даних |
| Гібрид: правила + навчена політика | Потрібен передбачуваний контур з поступовим переходом | Складніше налагодження, потрібен контроль розходження двох контурів |
Ми будуємо гібридний контур: правила залишаються страховкою, агент відповідає за адаптивне планування. Середовище для навчання збирається на історичних даних замовника, тому політика перевіряється на реальних сценаріях, а не на синтетиці. Такий підхід до оптимізації маршрутів польотів дає вимірюваний результат до виведення в продуктив.
Reinforcement Learning
Етапи впровадження: від аудиту даних до передачі моделі
Впровадження оптимізації маршрутів польотів починається не з моделі, а з даних: без чистого джерела телеметрії, метео та обмежень повітряного простору будь-який алгоритм навчається на шумі.
Тому перший етап — аудит: дивимося, які канали телеметрії пишуться безперервно, де пропуски, як зберігається історія рейсів, чи є прив'язка до фактичних умов. За підсумками аудиту фіксуємо, які ознаки взагалі придатні для навчання, а які доведеться відновлювати.
- Аудит даних. Інвентаризація джерел: телеметрія, метеозведення, обмеження зон, історія фактичних маршрутів. Перевіряємо повноту, частоту запису та стикуваність за часом — на виході карта даних з переліком прогалин і способів їх закриття.
- Схема рішення. Визначаємо цільову функцію: що оптимізуємо — витрату пального, час у дорозі, завантаження коридорів. Узгоджуємо обмеження (безпека, диспетчерські правила) та метрику, за якою будемо порівнювати новий маршрут з фактичним.
- Підготовка середовища. Збираємо симулятор польоту, що відтворює реальні умови. Модель навчається в ньому, а не на живих рейсах — помилки на цьому етапі не коштують нічого, крім часу навчання.
- Налаштування моделі. Навчання з підкріпленням: агент отримує нагороду за економію ресурсу та штраф за порушення обмежень. Ітеративно балансуємо ці сигнали, щоб маршрут залишався і вигідним, і здійсненним.
- Перевірка. Проганяємо модель на відкладеній історії рейсів і порівнюємо з фактичними маршрутами за цільовою метрикою. Окремо перевіряємо поведінку на рідкісних сценаріях — зсув вітру, закриття коридору, нештатний запас пального.
- Передача рішення. Розгортаємо модель у контурі замовника, віддаємо документацію щодо ознак, обмежень і процедури перенавчання. Команда замовника повинна вміти оновлювати модель без нас.
- Супровід. Перші тижні роботи на реальних рейсах — контроль розбіжностей між прогнозом і фактом, калібрування при зміні умов.
Кожен етап закінчується артефактом, який можна перевірити: карта даних, специфікація цільової функції, навчена модель зі звітом за метриками, регламент перенавчання. Це дозволяє зупинитися на будь-якому кроці й побачити, що вже працює, а що потребує доопрацювання.
Чим навчання з підкріпленням відрізняється від класичної оптимізації?
Класична оптимізація розв'язує задачу як пошук екстремуму функції за відомих обмежень: маршрут, витрата пального, заборонені зони, ешелони.
Поки модель світу статична, а вхідні дані повні, детерміновані методи дають відтворюваний результат за передбачуваний час — і цього достатньо. Проблема починається, коли середовище змінюється швидше, ніж ми встигаємо перерахувати рішення.
Навчання з підкріпленням перевертає логіку: агент не розв'язує одну задачу, а вчиться політиці поведінки — як діяти в кожному стані. Замість жорсткого плану він отримує функцію, яка на льоту підлаштовує маршрут під вітер, завантаження коридорів і обмеження диспетчерської зони.
Ціна — навчання потребує симулятора, коректно заданої нагороди й тисяч епізодів, перш ніж політика стане надійною.
Ключова відмінність — у тому, що оптимізується. Класика шукає найкращий маршрут за фіксованих умов, навчання з підкріпленням шукає найкращу стратегію за невизначеності.
Якщо середовище стабільне й добре описане математично, детермінований розв'язувач виграє за швидкістю, прозорістю та перевірюваністю. Якщо середовище нестаціонарне й частина параметрів невідома заздалегідь, RL дає адаптивність, яку класика не відтворює.
На практиці вибір рідко буває бінарним. Розумний шлях — гібрид: детермінований шар будує опорний маршрут і гарантує дотримання жорстких обмежень, а навчена політика працює поверх і коригує рішення в реальному часі.
Так зберігається передбачуваність і знімається головний ризик RL — непередбачувана поведінка в рідкісних станах.
Обмеження, які потрібно чесно назвати до старту: RL чутливий до функції нагороди — неправильно задана мета веде до формально оптимальної, але безглуздої поведінки. Симулятор має бути достатньо близьким до реальності, інакше політика не перенесеться.
І будь-який навчений агент потребує валідації на історичних даних і зрозумілих меж, за які він не виходить.
Кейс: скорочення витрати пального на мережі маршрутів
Авіакомпанія з мережею з кількох сотень регулярних маршрутів прийшла з типовим болем: планувальники будували маршрути вручну, спираючись на минулі сезони та усереднені вітрові моделі.
На довгих плечах це давало розкид за витратою пального до 8–12% між екіпажами на одному й тому самому напрямку, а рішення ухвалювалися раз на сезон — надто рідко, щоб реагувати на зміну струминних течій.
Ми перевели задачу в модель послідовного ухвалення рішень: агент на кожному кроці обирає ешелон і точку обходу, отримуючи нагороду за економію пального та штраф за відхилення від розкладу.
Навчання йшло на історичних даних про вітри, завантаження та фактичні треки, а перевірка — на утриманих маршрутах, яких модель не бачила.
Що змінилося в цифрах
Витрата пального на мережі впала на 6,4% у середньому за маршрутами, на окремих довгих плечах — до 9%. Час у дорозі скоротився на 3–5 хвилин на рейс завдяки точнішому вибору ешелону під поточний вітер. Частка маршрутів, де модель пропонувала рішення краще за ручне планування, становила 87%.
Окремо варто відзначити просідання за відмовами: кількість рейсів, що йшли на запасний аеродром через невірну оцінку пального, знизилася майже вдвічі. Це вже не про економію, а про передбачуваність операцій.
Як це влаштовано в експлуатації
Модель не замінює диспетчера — вона видає рекомендацію щодо ешелону та обходу за секунди, а рішення залишається за людиною. Перенавчання йде на свіжих даних, тому модель адаптується до сезонних зсувів вітрів без ручного переналаштування.
| Що порівнювали | До | Після |
|---|---|---|
| Витрата пального на мережі | базовий рівень | −6,4% |
| Час у дорозі на рейс | базовий | −3–5 хв |
| Відходи на запасний | базовий рівень | −48% |
Reinforcement Learning тут працює не як експеримент, а як робочий контур планування: рекомендації вбудовані в наявний процес, а метрики знімаються з фактичних польотів, а не з симуляції.
Сумніви перед впровадженням: сумісність, міграція, відкат
Перед стартом замовники найчастіше запитують одне й те саме: чи не доведеться перебудовувати наявний контур диспетчеризації, і що буде, якщо модель почне видавати маршрути, що розходяться з регламентом.
Відповідаємо по суті: оптимізація маршрутів польотів вбудовується поверх поточних систем планування, а не замість них — модель працює як рекомендаційний шар, а рішення щодо кожного борту залишається за диспетчером або автоматикою з жорсткими обмеженнями.
Що якщо рекомендації моделі розійдуться з чинними обмеженнями щодо зон і ешелонів?
Обмеження задаються декларативно й перевіряються до видачі маршруту: заборонені зони, коридори, ліміти щодо пального та часу в повітрі, пріоритети бортів. Модель пропонує варіант лише всередині допустимої множини, а не «вільний» маршрут.
Якщо жоден варіант не проходить валідацію, система повертає штатне рішення планувальника — відмова деградує в поточний процес, а не в інцидент.
Що якщо потрібен відкат? Конфігурація версіонується, попередній режим роботи повертається перемиканням профілю без перезбирання контуру. Навчена модель зберігається окремим артефактом, тому відкат не зачіпає дані та логіку планувальника.
Як бути з доступами? Ролі розмежовуються за зонами відповідальності: диспетчер бачить рекомендації, інженер — метрики якості, адміністратор — конфігурацію обмежень. Усі дії потрапляють до журналу.
На руки замовник отримує:
- схему інтеграції з наявним контуром планування та точки підключення;
- конфігурацію обмежень: зони, ешелони, ліміти пального та часу;
- політику відкату та профілі режимів роботи;
- матрицю доступів і ролей з описом прав;
- набір метрик якості рекомендацій і правила їх моніторингу;
- документацію з експлуатації та регламент ескалації при розходженнях;
- протокол приймання з перевіркою на історичних даних замовника.
Опишіть ваш контур планування та чинні обмеження — повернемося з оцінкою сумісності, планом міграції та порядком відкату.
Терміни етапів впровадження: орієнтовний план
Впровадження оптимізації маршрутів польотів розбито на етапи так, щоб кожен наступний крок спирався на перевірений результат попереднього.
Спочатку збираємо дані про фактичні траєкторії та обмеження, потім будуємо модель, яка навчається на цих даних, і лише після цього виводимо її в контур прийняття рішень. Такий порядок дозволяє на кожному рубежі бачити вимірюваний ефект і не переробляти вже зроблене.
Терміни залежать від обсягу історичних даних і кількості обмежень, які потрібно врахувати. Якщо дані вже структуровані, етап збору скорочується; якщо маршрутна мережа складна, більше часу йде на побудову середовища та валідацію.
Орієнтовний план впровадження ми уточнюємо після розбору вашої задачі — за фактом даних і вимог до контуру.
