Verizon Connect масштабировала agentic AI для 100000 пользователей и превратила fleet data в actionable insights

Отдельная благодарность команде Verizon Connect, которая очень много работала над проектом: Matteo Simoncini, Luca Bravi, Alberto Rossettini, Martin Villarruel, Ceyhun Unlu, Adriel Zuquini, Andrea Benericetti.

Fleet-менеджеры сегодня сталкиваются с непростой задачей: превращать избыток данных в actionable insights. Когда вы управляете тысячами автомобилей, каждый из которых ежедневно генерирует сотни точек данных, выявлять критические закономерности вручную становится почти невозможно. Verizon Connect, глобальный поставщик решений для fleet management, обслуживающий компании по всему миру через платформу Reveal, столкнулась с этой проблемой в масштабе.

При более чем 1,2 миллиона активных подписок на транспортные средства, которые ежедневно генерируют свыше 500 миллионов точек данных по 80 000 уникальных индикаторов, fleet-менеджеры буквально тонут в информации и вынуждены искать аномалии в разрозненных бумажных журналах и реактивных таблицах. Такой объем делал невозможным раннее выявление проблем с безопасностью, потребностей в обслуживании или операционной неэффективности до того, как они становились дорогими. Вместо того чтобы строить очередную статическую панель или rule-based систему автоматизации, которая ловит только заранее определенные шаблоны, Verizon Connect выбрала agentic AI, чтобы заменить ручные догадки централизованной системой анализа. Agentic AI динамически исследует новые шаблоны, задает уточняющие вопросы и адаптирует анализ по мере обнаружения новых фактов, что особенно подходит для непредсказуемой природы fleet operations.

В этом материале мы показываем, как Verizon Connect построила и масштабировала agentic AI-решение, которое превращает поток fleet data в понятные actionable insights для 100 000 пользователей каждый день. Мы разберем архитектурные решения, сложности внедрения и измеримые результаты, которые могут помочь и в вашей трансформации данных в инсайты.

Построение масштабируемой архитектуры

Решение обрабатывает данные в большом масштабе, сохраняя cost-efficiency. На следующем рисунке показаны ключевые компоненты. Ниже мы последовательно разберем составные части решения и свяжем их в разделе «Общая архитектура».

Рисунок 1 — Высокоуровневая архитектура решения

Высокоуровневое описание компонентов и логики работы выглядит так.

1. Запуск оркестрации — ежедневный триггер инициирует workflow, активируя модуль обнаружения аномалий в слое анализа.
2. Сбор данных — модуль извлекает структурированную информацию из хранилища сырых данных. Именно здесь выполняется основная вычислительная работа.
3. Целевые результаты — вместо того чтобы просить large language model (LLM) «искать иголки в стоге сена», модуль определяет конкретные аномалии и записывает их в отдельную таблицу аномалий. Перенося численный анализ на специализированный код, мы избегаем проблем с масштабом и точностью, с которыми LLM сталкиваются на сырых табличных данных.
4. Активация AI-агентов — после подготовки аномалий менеджер запускает AI-агентов. Чтобы повысить производительность, несколько агентов могут работать параллельно, каждый — по своему клиенту или сегменту данных.
5. Рассуждение и контекст — AI-агент выполняет финальный анализ. Он обращается к аномалиям, чтобы понять что произошло, и возвращается к сырым данным, чтобы выяснить почему, используя LLM для синтеза этих вводных в связный рассказ.
6. Доставка инсайтов — итоговое рассуждение сохраняется как сгенерированные инсайты, которые затем передаются конечному пользователю через приложение Reveal.

Компоненты решения

Обнаружение аномалий

Типичная ошибка в AI engineering — просить LLM выполнять численный анализ на больших объемах сырых табличных данных. Как отмечает AWS Prescriptive Guidance, LLM могут испытывать трудности со сложными табличными структурами и извлечением числовых данных в масштабе. Чтобы решить эту проблему, мы построили serverless статистическую модель с использованием AWS Step Functions и AWS Lambda (см. рисунок 4). Эта модель выполняет вычислительно тяжелую часть обнаружения аномалий в структурированных данных. Она определяет, что именно является аномалией, чтобы AI-агент мог сосредоточиться на том, почему она возникла и как с ней работать.

AI-агент

Мы выбрали Strands Agents — open source SDK для создания и выполнения AI-агентов, работающий в serverless-среде AWS Lambda. Такой вариант развертывания горизонтально масштабируется в зависимости от нагрузки. AI-агент работает в рамках динамического reasoning loop, самостоятельно определяя путь расследования, а не следуя фиксированному набору шагов. Из следующего описания видно, что AI-агент stateless: контекст, необходимый для генерации инсайтов, каждый раз заново извлекается во время анализа.

AI-агент использует специальные инструменты, чтобы:

• получать заранее вычисленные аномалии из Amazon Simple Storage Service (Amazon S3);
• запрашивать дополнительный контекст из Amazon Aurora для сырых данных и Amazon DynamoDB для исторических инсайтов;
• записывать итоговые инсайты обратно в Amazon S3;
• отслеживать статус запроса задачи в Amazon DynamoDB.

Двухэтапная agentic-архитектура

Генерация инсайтов строится по двухэтапному подходу, и на каждом этапе LLM использует свои reasoning-способности по-разному:

Этап 1: генерация сводки (агрегация аномалий и приоритизация). На этом первом этапе агент получает набор сырых аномалий, обнаруженных по всему fleet. Вместо обработки каждой аномалии по отдельности LLM самостоятельно решает, как агрегировать их в связные кандидаты на инсайты. Он может группировать аномалии по:

• общим первопричинам (например, когда несколько автомобилей демонстрируют одинаковый паттерн поведения);
• временной корреляции (события сосредоточены на определенных датах);
• категориальному сходству (связанные метрики безопасности или эффективности).

И логика группировки, и критерии отбора полностью остаются на усмотрение LLM. Система не навязывает жесткие правила объединения аномалий. После агрегации агент присваивает каждому кандидату на инсайт оценку релевантности на основе таких факторов, как серьезность, повторяемость, влияние на весь fleet и применимость к действиям. Из этих оцененных кандидатов агент выбирает четыре наиболее релевантных инсайта для дальнейшей детализации. Такой подход позволяет приоритизации подстраиваться под конкретный контекст fleet каждого пользователя, а не полагаться на статические business rules, которые могут пропустить возникающие закономерности.

Этап 2: детальная генерация (agentic-исследование с использованием инструментов). На втором этапе критически проявляется agentic-природа системы. Для каждого сводного инсайта запускается отдельный экземпляр агента с доступом к инструментам получения данных. Агент самостоятельно решает, какие инструменты вызывать, в каком порядке и сколько раз, повторяя цикл до тех пор, пока не соберет достаточно доказательств для data-backed инсайта. Теперь, когда работа агента объяснена, посмотрим, почему agentic-подход необходим для этого сценария. Fleet management включает бесконечное число переменных и непредсказуемых сценариев, которые требуют динамического расследования, а не заранее заданной логики, и это создает два фундаментальных ограничения:

• Ограниченное покрытие паттернов: код может находить только те шаблоны, которые были явно запрограммированы. Краевые случаи, новые корреляции или неожиданные распределения данных остаются незамеченными.
• Жесткие сценарии расследования: скрипт следует предопределенным шагам независимо от того, что данные показывают в середине анализа.

Напротив, AI-агент может обнаруживать паттерны любой природы, включая edge cases, которые не были предусмотрены на этапе разработки. Если данные указывают на неожиданную корреляцию — например, жесткое торможение связано с определенными паттернами времени суток, или поведение автомобиля меняется после конкретной даты, — агент может в реальном времени изменить стратегию расследования и сделать дополнительные вызовы инструментов, чтобы проверить возникающие гипотезы. Такая гибкость особенно ценна в fleet management, где:

• поведение водителей меняется непредсказуемо;
• внешние факторы (погода, трафик, дорожные условия) создают неочевидные корреляции;
• состав fleet и сценарии использования со временем меняются;
• могут появляться новые типы аномалий, которых не было в исторических данных.

Пример оркестрации потока

• Первичное обнаружение: агент находит сводный инсайт о 30-процентном росте числа случаев резкого торможения по всему fleet.
• Определение базы: он самостоятельно решает получить fleet-wide историческое среднее за последние 30 дней, чтобы понять, является ли всплеск настоящей аномалией или это обычный сезонный тренд.
• Распознавание паттерна: увидев, что всплеск сосредоточен на конкретных датах, агент переключается на дневную детализацию. Он обнаруживает, что большинство этих safety-событий произошло в один и тот же двухдневный период.
• Таргетированный анализ: на основе этих дат агент определяет, что автомобили 1015, 1142 и 1032 отвечали почти за 70% событий.
• Сравнительный анализ: затем он делает финальный точечный запрос, чтобы сравнить историческую производительность Vehicle 1015 с его текущим поведением и понять, изменился ли профиль водителя принципиально.
• Синтез: только после того, как агент «свяжет все эти точки», он завершает цикл и генерирует итоговый data-backed инсайт, который выделяет конкретных водителей и даты.

Large language model

Чтобы оптимизировать соотношение цены и производительности, сначала мы использовали более мощный Claude 4.5 Sonnet для проверки логики и качества инсайтов. После валидации мы перешли на более экономичный Claude 4.5 Haiku для production-сценария. Дальнейшая оптимизация привела нас к Amazon Nova 2 Lite — быстрому мультимодальному модели, которая обеспечивает сопоставимое качество инсайтов и при этом снижает стоимость input tokens на 70% по сравнению с Claude 4.5 Haiku. Такая экономия особенно важна, поскольку основную долю нагрузки составляют input tokens (telematics data, аномалии, контекст). Эффективность Nova 2 Lite позволяет Verizon Connect поставлять AI-insights всей пользовательской базе заметно дешевле. Качество поддерживалось автоматизированным тестовым набором и gold-standard dataset, что обеспечило проверенное решение к моменту полного запуска. LLM размещаются в масштабе в Amazon Bedrock — fully managed service с широкими возможностями generative AI, а также функциями безопасности, конфиденциальности и ответственного ИИ.

Управление ежедневным триггером и конкуренцией

Чтобы к началу рабочего дня 100 000 пользователей уже были готовы инсайты, мы используем Amazon Simple Queue Service (Amazon SQS) для управления выполнением. Контролируя максимальную конкуренцию триггера SQS-to-Lambda, мы можем:

• сглаживать всплески API-нагрузки;
• оставаться в пределах квот Amazon Bedrock: Tokens Per Minute (TPM) и Requests Per Minute (RPM);
• обеспечивать надежную доставку без избыточного резервирования ресурсов.

Для наглядности рассмотрим сценарий, в котором инсайты доставляются клиентам по всей территории США. Целевая доставка — 8:00 AM ET, на основе данных, сгенерированных до Midnight PT предыдущего дня. Учитывая трехчасовую разницу во времени, весь end-to-end процесс должен укладываться в пятичасовое окно. Если выделить один час на обнаружение аномалий, то на AI Agent и LLM остается четырехчасовое окно для генерации инсайтов. При скорости 1 500 RPM (настраиваемой) этап генерации инсайтов займет примерно 1,25 часа, что вполне укладывается в наши операционные требования.

Рисунок 2 — Детали максимальной конкуренции SQS-to-Lambda

Сгенерированные инсайты

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

Рисунок 3 — На самой посещаемой странице Reveal есть ссылки на результаты Operational Insights.

Общая архитектура

Общая архитектура объединяет четыре компонента: обнаружение аномалий, параллелизацию запросов, движок генерации инсайтов и хранение сгенерированных инсайтов для их потребления приложением Reveal.

Рисунок 4 — Общая архитектура

Чтобы понять, как эти компоненты работают вместе, рассмотрим следующий workflow: запускается запрос на инсайты, включая список customer IDs, по которым нужно вычислить инсайты. Статистическая модель выполняет обнаружение аномалий и сохраняет результаты в Amazon S3.

1. Как описано ранее, запускаются N параллельных запросов.
2. N агентов анализируют данные, создают инсайты и сохраняют их в Amazon S3. На этом этапе агенты вызывают Amazon Bedrock APIs, чтобы обратиться к выбранной модели.
3. Приложение Reveal получает доступ к инсайтам, сохраненным в Amazon S3.

Результат: actionable intelligence

Функция Operational Insights была запущена для пользователей Verizon Connect в ноябре 2025 года и уже дает fleet-менеджерам четкие narrativе в natural language, например:

• Обнаружение паттернов безопасности: «У вашего fleet на этой неделе число резких торможений выросло на 100%. Интересно, что это совпало со снижением резких ускорений, что может указывать на усталость водителей или более плотный трафик».
• Операционная эффективность: «Vehicle #90000 проводит в холостом ходу 50% времени работы двигателя, что значительно выше среднего по fleet. Это означает лишние затраты на топливо».
• Производительность fleet: «Средний дневной пробег снизился на 59%, но число событий превышения скорости выросло на 54%. Это говорит о том, что автомобили проезжают меньшие расстояния на более высокой скорости — стоит рассмотреть оптимизацию маршрутов».

Заключение и дальнейшие планы

В этом материале мы показали, как Verizon Connect построила масштабируемое Agentic AI-решение на AWS, которое превращает сырые IoT telematics data в actionable fleet insights для более чем 100 000 пользователей. Архитектура объединяет Amazon Bedrock, Strands Agents, AWS Step Functions, Amazon SQS и многоуровневый слой данных, чтобы обеспечивать надежные и cost-efficient инсайты в масштабе.

По мере развития ландшафта ИИ мы планируем перейти от развертывания агентов на основе AWS Lambda к Amazon Bedrock AgentCore Runtime, чтобы еще сильнее упростить выполнение в AWS Lambda, а также использовать Model Context Protocol (MCP) для более быстрой интеграции инструментов.

Чтобы эффективно внедрить agentic AI-решение, начните с небольшого пилота, чтобы проверить базовый use case и подтвердить cost-efficiency. После того как начальная ценность доказана, расширяйте систему за счет автоматизированных workflow и персонализации на основе данных. Финальный этап — переход к полноценному enterprise-развертыванию, поддерживающему продвинутую оркестрацию и обработку в реальном времени по всей организации. Начните строить уже сегодня:

• Начните с основы: Amazon Bedrock для managed AI services и AWS Lambda для serverless-хостинга агентов
• Добавьте оркестрацию: AWS Step Functions для управления workflow и Amazon SQS для масштабируемых очередей
• Храните и извлекайте данные: Amazon S3 для объектного хранения, Amazon Aurora для структурированных данных и Amazon DynamoDB для быстрых поисков
• Изучите agent frameworks: документацию Strands Agents для разработки open source агентов

Материал — перевод статьи с английского.

Оригинал: From data overload to actionable insights: How Verizon Connect scaled agentic AI to 100,000 users