Авиакомпании работают по строгому расписанию, где даже минутная задержка может вызвать цепную реакцию по всей сети. Ключевым моментом в борьбе за пунктуальность является время между прибытием самолета и его следующим вылетом, известное как «разворот». Каждая минута простоя на гейте обходится авиакомпании примерно в 20 долларов, учитывая расходы на топливо, экипаж, сборы за использование гейтов и упущенные стыковки. Для перевозчика среднего размера, выполняющего 200 рейсов в день, сокращение среднего времени разворота всего на 2 минуты может принести экономию около 240 000 долларов в месяц. AvioBook, входящая в Thales Group, разрабатывает программное обеспечение для управления полетами и наземными операциями. Их платформа AvioBook Connect, запущенная в 2018 году, а обновленная API-платформа — в 2025 году, служит центральным узлом для координации разворотов между летным и кабинным экипажем, диспетчерами и наземными службами. Платформа организует работу вокруг «полетных комнат» — чатов для каждого рейса, где участники получают уведомления об изменениях самолетов, задержках, новых планах полетов и ходе посадки. AvioBook Connect хранит как структурированные данные автоматических сообщений, так и неструктурированные данные переписки экипажей, при этом все данные обрабатываются в собственной среде авиакомпании под ее контролем. Однако сбор данных — это лишь половина дела; превращение этого архива в инструмент для принятия решений в реальном времени стало отправной точкой для разработки AvioBook Connected Analytics.
Проблема: богатые данные, доступные только по запросу
AvioBook Connect организует каждый рейс в отдельную «полетную комнату», где фиксируются все события разворота: автоматические уведомления через API (изменения самолетов, задержки, новые планы полетов, ход посадки) и сообщения операционных команд. Однако сбор данных и их эффективное использование — это разные вещи, и здесь возникали три основные проблемы. Во-первых, операции часто оставались «черным ящиком». Команды, работающие над одним и тем же разворотом, редко имели единую картину происходящего, и часто описывали одну и ту же задержку по-разному. При последующих проверках информация основывалась на устных показаниях, что затрудняло точное восстановление событий. Во-вторых, коды задержек давали лишь частичную картину. Кодирование происходило под давлением времени, обычно одним человеком, и в основном фиксировало доминирующую задержку. Даже если допускалось несколько кодов, первопричина доминирующей задержки часто не кодировалась вовсе. Код задержки мог быть правильно заполнен по правилам, но при этом вводить в заблуждение относительно произошедшего, что создавало проблемы не только для аналитики, но и для соблюдения нормативов. В-третьих, для получения ответов требовалась команда аналитиков, которой у многих авиакомпаний не было. Исторические данные за пределами короткого периода были труднодоступны, и каждый запрос требовал ручного поиска или запроса на извлечение данных. В условиях низкой рентабельности немногие авиакомпании могли позволить себе содержать специализированную аналитическую команду.
Различные потребности пользователей
В авиакомпаниях аналитическая работа обычно ложится на две основные роли с разными потребностями. Менеджеры авиакомпаний, отвечающие за пунктуальность (OTP), должны понимать причины задержек, соблюдаются ли наземные процедуры, и как отчитываться при проверках. Они работают с историческими данными и паттернами, задавая вопросы типа: «Каковы вероятные источники задержек для рейса X?», «Каковы наиболее распространенные не связанные с погодой источники задержек?» и «Соблюдаются ли процедуры для процесса X?». Диспетчеры центра управления операциями (OCC) сталкиваются с той же проблемой в масштабах всей сети: задержка на одном гейте может распространиться на все стыковки в течение дня. Они работают с данными в реальном времени и должны видеть сбои в самом начале, а также понимать их влияние на весь флот. Они задают вопросы типа: «Каковы будут последствия сбоя в аэропорту X?», «Есть ли рейсы с более чем 250 пассажирами, находящиеся под угрозой?», и «Какие рейсы с самым высоким индексом VaR (Value at Risk) выполняются сегодня?». Обеим ролям необходим быстрый, удобочитаемый, основанный на доказательствах ответ с возможностью углубиться в детали и проверить обоснованность кода задержки, что является не автоматическим вердиктом, а поддержкой принятия решений, на которую менеджер авиакомпании может уверенно опираться. Именно этот пробел призвана заполнить AvioBook Connected Analytics.
Подход: многоагентная архитектура на базе Amazon Bedrock AgentCore
AvioBook Connected Analytics разработана для предоставления двух ключевых возможностей: диалога на естественном языке с операционными данными и автоматизированной проверки кодов задержек. Вместо одного универсального помощника система использует двух специализированных агентов. Агент, ориентированный на менеджеров авиакомпаний, занимается историческим анализом и проверкой кодов задержек. Агент, ориентированный на диспетчеров OCC, обрабатывает оперативные запросы в реальном времени и оценивает влияние сбоев. Каждый агент настроен под свою роль, поэтому пользователь взаимодействует только с агентом, авторизованным для его функций. Amazon Bedrock AgentCore предоставляет управляемую основу для развертывания и оркестровки этих агентов без необходимости создания инфраструктуры агентов с нуля. Агенты работают на AgentCore runtime — полностью управляемой вычислительной среде для развертывания ИИ-агентов и серверов Model Context Protocol (MCP). Они используют AgentCore memory, что позволяет ИИ-агентам запоминать прошлые взаимодействия и поддерживать контекст разговора между сеансами пользователя. Доступ к инструментам осуществляется через AgentCore Gateway, который предоставляет единую, безопасную точку входа для агентского трафика. AgentCore Gateway предоставляет цели MCP, что дает агентам согласованный и управляемый способ вызова функций, обращающихся к данным AvioBook. AgentCore runtime настроен на использование JSON Web Token (JWT) для входящей аутентификации. На стороне AvioBook Connect Amazon API Gateway настроен с функцией AWS Lambda в качестве цели.
Источник: Artificial Intelligence
