AWS показала, как собрать AI-хоста для ресторанов на Bedrock и Nova 2 Sonic
AWS опубликовала детальный гайд по созданию голосовой системы для приёма заказов в ресторанах через телефон. Система использует Amazon Bedrock AgentCore и модель Nova 2 Sonic для речевого взаимодействия в реальном времени, подключается к бэкенду ресторана через Model Context Protocol и обрабатывает звонки через SIP-шлюз на AWS Fargate. Решение включает прогрев сессии агента во время звонка, чтобы клиент не слышал тишину.
Это практический пример enterprise-grade голосового AI на собственной инфраструктуре AWS, показывающий, как избежать типичных проблем (холодный старт, тишина в начале звонка, связь с бэкендом) и построить масштабируемое решение для реального бизнеса.
Проблема пропущенных звонков
Рестораны пропускают в среднем 150 звонков в месяц на локацию, причём 60% из них — попытки заказать еду или забронировать стол. Большинство звонков приходится на час пик, когда хостес рассаживает гостей, официанты обслуживают столы, и телефон становится последним приоритетом.
Архитектура решения
AWS предлагает трёхслойную систему:
Телефонный слой обрабатывает звонки через Amazon Chime SDK Voice Connector (SIP-транк и бесплатный номер), а SIP-шлюз на Amazon ECS и AWS Fargate стримит аудио агенту через подписанное WebSocket-соединение.
Агентский слой работает на Amazon Bedrock AgentCore Runtime — каждый звонок выполняется в отдельной микроVM для изоляции. Amazon Nova 2 Sonic обрабатывает речевое взаимодействие в реальном времени, включая транскрипцию, управление репликами и прерывания в едином двунаправленном потоке.
Бэкенд-слой хранит меню, корзины, заказы и данные о локациях. AgentCore Gateway через Model Context Protocol (MCP) предоставляет агенту доступ к бэкенд-API как к инструментам, которые агент может вызывать по имени. Backend работает через Amazon API Gateway с IAM-авторизацией, AWS Lambda обрабатывает бизнес-логику, DynamoDB хранит данные, а Amazon Location Service занимается геокодингом и расчётом маршрутов.
Ключевые особенности
Система прогревает сессию агента пока телефон ещё звонит — звонящий никогда не слышит тишину. Использование MCP как открытого стандарта позволяет менять бэкенд без переделки агента, а модульная архитектура даёт возможность подключать новые каналы (мобильное приложение, киоск) к тому же агенту без переписывания логики.
Развёртывание выполняется через AWS CDK, что упрощает воспроизведение решения.
Ключевые выводы
- Рестораны теряют до 60% звонков от потенциальных клиентов именно в час пик, когда персонал занят обслуживанием
- Использование MCP как открытого стандарта для подключения инструментов позволяет менять бэкенд независимо от агента
- Прогрев микроVM агента во время звонка устраняет холодный старт и улучшает пользовательский опыт
- Каждый звонок изолирован в отдельной микроVM, что обеспечивает безопасность и стабильность системы
- Модульная архитектура позволяет использовать одну и ту же логику заказа для разных каналов взаимодействия
Автор: Sergio Barraza · Источник: aws.amazon.com
Это типичный enterprise-туториал от AWS: детальный, работающий, но жёстко привязанный к экосистеме. Всё сделано добротно — прогрев сессий, чтобы клиент не слышал тишину, изоляция звонков в микроVM, использование MCP для разделения слоёв. Решение явно спроектировано инженерами, которые понимают, как работают продакшен-системы.
Но давайте честно: это витрина возможностей AWS, а не агностичный гайд по построению голосовых агентов. Каждый слой завязан на проприетарные сервисы — Bedrock, Chime SDK, Fargate, Location Service. Если завтра решите мигрировать или просто сравнить затраты, переписывать придётся почти всё. Для тех, кто уже в экосистеме AWS, это отличный референс. Для остальных — напоминание, что "облачные решения" часто означают "наши решения в нашем облаке".
Погодите, а разве это плохо? AWS не скрывает, что это их стек — в этом весь смысл платформы. Они дают готовую интеграцию с телефонией, изоляцию на уровне микроVM, автоматический масштаб и IAM из коробки. Попробуйте собрать аналог на open source — получите зоопарк из Asterisk, Kubernetes, каких-нибудь самописных прокси, проблемы с сертификатами и бесконечный debugging SIP-протокола. Да, vendor lock-in реален, но enterprise платит именно за то, чтобы НЕ разбираться в этих деталях. Если решение работает и экономит 90 часов инженерного времени, привязка к платформе — разумная цена.
Комментарии