Научили информационную систему понимать речь и открывать ворота. А попутно выяснили, какие технологии для этого бесполезны. Кейс ЕГДС

Главное о кейсе

К нам обратилась Единая городская диспетчерская служба (ЕГДС) — компания, которая управляет доступом к закрытым территориям в Москве и Московской области через шлагбаумы и ворота.
Это не первое наше сотрудничество. Раньше мы уже помогали дорабатывать их информационную систему: ускорили подготовку актов, устранили проблемы с автоплатежами, добавили возвраты и автоматическое отключение барьеров при остановке услуг, сделали удобные инструменты для технических специалистов. К моменту новой задачи мы знали систему досконально.

Как проект изменил жизнь пользователей

Автоматизация диспетчерской службы с акцентом на голосовое управление решила важные повседневные проблемы людей. Ранее пользователь попадал на автоответчик и выбирал нужный пункт меню кнопками, что вызывало неудобства, особенно если человек за рулём, спешит или за ним уже собралась очередь машин. С новым решением будет достаточно сказать: «открыть ворота» или «номер заявки 12345», а система самостоятельно распознаёт команду и выполняет действие. Таким образом, въезд станет быстрее и безопаснее, а для самих жителей — проще и понятнее.

Бизнес-задача и ее решение

Заказчик поставил задачу: пользователь просто говорит вслух — «открыть ворота», «приостановить услугу», «номер заявки 12345» — а система сама распознает фразу и выполняет команду. Фактически требовалось встроить полноценное распознавание речи в телефонные звонки.
Похожие голосовые боты давно используются в сервисах с большим количеством клиентов: в банковской поддержке (помните Олега из Т-Банка?), у операторов связи, в авиакомпаниях. Пользователи ЕГДС тоже ожидали такого уровня сервиса.
Для ЕГДС и управляющих компаний это выгодно: простые сценарии уменьшают поток жалоб, снижают нагрузку на диспетчеров и экономят ресурсы. Комплекс получает современный имидж — «умные» сервисы становятся аргументом при выборе квартиры или офиса. Голосом удобно не только открывать шлагбаумы, но и уточнять статус обращения, добавлять гостевой доступ — всё без участия оператора.
Перед внедрением мы подробно расписали новый сценарий. Когда клиент звонит в диспетчерскую, система сначала определяет входной параметр — к какой очереди относится звонок. У ЕГДС разные группы клиентов, и в некоторых случаях запрос нужно сразу перенаправить опытным операторам.
Если звонок остается в автоматическом сценарии, система задает уточняющий вопрос: «У вас проезд по заявке?» Если пользователь отвечает «Да», «Да-да», «По заявке» — система принимает это как подтверждение. Если «Нет» — звонок переводится оператору.
При подтверждении система просит продиктовать номер заявки, проверяет его в базе и, если номер корректный, открывает шлагбаум. Если неправильный — клиент получает сообщение об ошибке и может попробовать снова. Если автоматический сценарий не срабатывает, оператор может переключить абонента на IVR (Interactive Voice Response — интерактивный голосовой модуль).

Крафт (мастерство), реализация, технические детали

За телефонию у заказчика отвечал Asterisk — система для IP-звонков с открытым кодом. Но готовых решений под распознавание речи в связке с Asterisk не существовало — пришлось идти путем экспериментов.
Первой библиотекой стала Vosk. Мы собрали простую цепочку:

Asterisk → AGI-скрипт на Python → Vosk → обработка результата

Записали аудиофайл, передали в скрипт — всё сработало, Vosk вернул текст. Но главный показатель — время отклика — не подошел. Даже в идеальных условиях Vosk выдавал результат через 6 секунд. Для реального звонка это слишком долго: пользователь терпит максимум 1–3 секунды, после чего диалог кажется зависшим.
Нужно было решение, которое распознает речь меньше чем за секунду и не сбоит даже при нагрузке в 50 одновременных звонков.


Почему не облачные сервисы

Облачные решения выглядят привлекательно: не нужно ничего настраивать, просто подключи API. Но у них два серьезных минуса:
Скорость: передача аудио в облако и обратно дает лишние задержки — вместо нужной секунды получаем еще больше времени отклика.
Цена: тарификация по секундам и количеству запросов для постоянного потока звонков слишком дорога.
Собственный сервер требует больше усилий: нужно арендовать железо, настроить CPU/GPU и окружение, развернуть сервис и обернуть его в REST API. Зато это дает контроль над скоростью и оптимизацией, а стоимость аренды мощных серверов в долгую выгоднее платы за облако.


Переход на Whisper

После тестов с Vosk стало понятно: нужна более производительная модель. Мы попробовали Whisper от OpenAI — систему автоматического распознавания речи (ASR), обученную на 680 тысячах часов речевых данных.
Whisper требует мощного железа, зато качественнее и быстрее работает под нагрузкой. Заказчик арендовал сервер с GPU — графические процессоры позволяют обрабатывать речь в реальном времени, тогда как CPU с такой нагрузкой не справляются. На сервере мы установили Whisper, обернули его в REST API и доработали скрипт: он научился принимать параметры, нарезать аудио и передавать фрагменты для транскрибации.


Нагрузочные тесты: поиск баланса

Чтобы понять, как система справится с реальной нагрузкой, мы провели стресс-тест. Взяли 10-секундный аудиофайл и запустили его обработку сразу 50 раз — смоделировали ситуацию одновременных звонков.
Один обработчик: половина запросов обрабатывалась за 20 секунд, видеокарта загружена на 50%. Ресурсы простаивают, скорость не подходит.
Два обработчика: половина запросов — за 13 секунд, 95% — за 14 секунд. Загрузка GPU выросла до 90%. Поток запросов стабилизировался на уровне ~2,5 RPS (requests per second), но скорость всё еще далека от идеала.
Четыре обработчика: нагрузка выросла до 6 RPS, время отклика сократилось. Для большинства пользователей задержка составила ~8 секунд, максимум — 10 секунд. Ошибок не было.

Важный момент: задержка зависит от количества параллельных запросов. При обработке одного файла результат готов через 500–700 мс. При 50 одновременных запросах время распределяется: половина завершается до 8 секунд, почти все остальные — в пределах 8–11 секунд.
Четыре обработчика вывели систему на баланс: она выдерживает большую нагрузку и дает приемлемое время отклика.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

В процессе разработки мы убедились: внедрение распознавания голоса в телефонных сценариях — это всегда вопрос тонкой настройки и оптимизации. Простого «подключения библиотеки» мало, каждый этап потребовал тестов и многократных доработок логики диалогов, маршрутизации и технических деталей передачи аудио. Работа строилась на тесном диалоге с заказчиком: регулярные демонстрации, живая обратная связь и оперативные доработки привели к результату, который полностью соответствует задаче. Именно так создаются сервисы нового поколения — удобные, быстрые и отвечающие реальным потребностям пользователей.

6 ноября 2025 года система была запущена в экспериментальную эксплуатацию и успешно прошла первые испытания. По словам заказчика: «Ребята сделали и вроде работает)) Получен результат, который хотелось. Задачи можно закрывать». Полноценный боевой запуск запланирован на начало 2026 года.

Скриншоты