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

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

Мы уже сотрудничали раньше:

— помогали дорабатывать их информационную систему;
— ускорили подготовку актов с восьми часов до двух;
— устранили проблемы с автоплатежами;
— добавили возвраты и автоматическое отключение барьеров при остановке услуг;
— сделали удобные инструменты для тех. специалистов и многое другое.
Так что к моменту новой задачи мы знали эту систему буквально как свои пять пальцев.

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

Заказчик захотел упростить процесс, так чтобы человек просто говорил вслух: «открыть ворота», «приостановить услугу», «номер заявки 12345» — а система сама распознавала фразу и выполняла команду. Фактически требовалось встроить в звонки полноценное распознавание речи.

Похожие голосовые боты давно используются в сервисах с большим количеством клиентов: в банковской поддержке (помните Олега из Т-Банка?), у операторов связи, в авиакомпаниях, доставке еды и такси. Логично, что пользователи ЕГДС ожидали такого же уровня удобства и скорости.

В Москве и Подмосковье почти все дворы закрыты шлагбаумами. Управляющие компании конкурируют за внимание жителей, и низкой цены уже недостаточно. Люди хотят простого и быстрого доступа домой — без поиска кнопок и лишних действий.

Голосовое управление решает эту задачу. Сказал «открыть ворота» — и система сработала. Это быстрее и безопаснее, чем копаться в телефоне за рулем, а значит — меньше аварийных ситуаций и меньше очередей на въезде, что критично для больших комплексов с сотнями машин.

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

Дальше — больше. Голосом удобно не только открывать шлагбаумы, но и уточнять статус обращения, добавлять гостевой доступ — все это без участия оператора. Это снижает расходы на поддержку и почти исключает ошибки.

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

Если звонок остается в автоматическом сценарии, система задает уточняющий вопрос: «У вас проезд по заявке?» и ждет ответа.

Если пользователь говорит «Да» или что-то близкое по смыслу: «Да-да», «По заявке» и т. д. — система принимает это как подтверждение. Если же ответ «Нет» — звонок переводится оператору.

При подтверждении система просит абонента продиктовать номер заявки, а после проверяет его в базе. Если номер корректный, воспроизводится сообщение: «Сейчас будет открыт шлагбаум», и подается команда на открытие. Если неправильный — клиент получает сообщение об ошибке и может попробовать снова.

В случае повторного ввода процесс идет по той же цепочке: система снова ждет голосовой ответ, распознает его и проверяет.

Если система определяет, что речь все же идет о проезде по заявке, но автоматический сценарий выполнить не удается, оператор может переключить абонента на IVR (интерактивный голосовой модуль). Ну а дальше процесс продолжается в том же режиме, как если бы все шло автоматически.

У заказчика за телефонию отвечал Asterisk — система для IP-звонков с открытым кодом. «Открытый код» означает, что любая компания или разработчик может подстроить систему телефонии под себя: добавить новые функции, интегрировать с другими сервисами или изменить логику работы.

Для доработки системы на этом этапе хватало базовых знаний Python. Но сложность заключалась в том, что готовых решений под задачу распознавания речи в связке с Asterisk в открытом доступе просто не существовало — поэтому нам пришлось идти путем экспериментов.

Первой библиотекой, которую мы взяли на пробу, стала Vosk, и на ее основе мы собрали простую цепочку:

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

Мы записали короткий аудиофайл, передали его в скрипт и посмотрели, как библиотека справится с распознаванием. По сути, все сработало: Vosk вернул текст, и базовый сценарий оказался реализуемым.

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

Пришлось искать другое решение — такое, которое сможет распознавать речь меньше чем за секунду и не сбоить даже при нагрузке в пятьдесят одновременных звонков.

Они на первый взгляд выглядят привлекательно: не нужно ничего настраивать, просто подключи API. Но у них есть два серьезных минуса:

1. Скорость. Передача аудио в облако и обратно дает лишние задержки. Для живого звонка это критично: вместо нужной секунды мы получаем еще большее время отклика.

2. Цена. Облачные сервисы тарифицируются по секундам и количеству запросов. Для постоянного потока звонков выходит слишком дорого.

Собственный сервер требует больше усилий: нужно арендовать «железо», настроить CPU/GPU и окружение, развернуть сервис и обернуть его в REST API.

Зато это дает два ключевых преимущества: мы полностью контролируем скорость и оптимизацию под свои сценарии, плюс стоимость аренды мощных серверов в долгую оказывается заметно выгоднее, чем платить за облако.

Итак, после тестов с Vosk стало понятно: для задачи нужна более тяжелая и быстрая модель. Мы решили попробовать Whisper от OpenAI.

Тяжелая и быстрая здесь — отнюдь не антонимы. Если сказать проще: Whisper прожорливее, но умнее. Он требует мощного железа, зато качественнее и быстрее работает под нагрузкой — впрочем, об этом позже.

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

Чтобы понять, как система справится с реальной нагрузкой, мы устроили стресс-тест. Для этого взяли 10-секундный аудиофайл и с помощью кода запустили его обработку сразу 50 раз. Так мы смоделировали ситуацию, когда одновременно звонят пятьдесят человек, и замерили, за какое время Whisper выдаст результат в каждом из потоков.

Сначала мы попробовали запустить систему с одним обработчиком. Результаты оказались неудовлетворительными: половина запросов обрабатывалась за 20 секунд, почти все остальные — за 21 секунду. При этом видеокарта была загружена всего на 50%. Получалось, что ресурсы простаивают, а скорость явно не подходит для реального времени.

Тогда мы подключили второго обработчика. Это сразу дало заметный эффект: половина запросов стала выполняться за 13 секунд, 95% — за 14 секунд. Загрузка GPU выросла до 90%, то есть ресурсы начали использоваться почти на полную.

На графиках ниже видно, что поток запросов стабилизировался на уровне около 2,5 RPS, а время отклика стало предсказуемым — даже самые долгие запросы не превышали 22 секунд. Система стала стабильной, но скорость работы все еще была далека от идеала.

Чтобы добиться лучших результатов, мы увеличили число обработчиков до четырех. Здесь система показала себя еще лучше: нагрузка выросла более чем в два раза — до 6 RPS, но при этом время отклика значительно сократилось. Для большинства пользователей задержка составила около 8 секунд, а даже для «тяжелых» запросов она не превышала 10 секунд. Ошибок снова не было.

Если сравнить все конфигурации, картина становится очевидной. Один обработчик давал слишком большие задержки при неполной загрузке ресурсов. Два обработчика позволили ускорить работу почти на треть и приблизиться к приемлемым значениям. А четыре обработчика вывели систему на баланс: она одновременно выдерживает большую нагрузку и дает приемлемое время отклика.

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

Python Whisper

Все эти тесты показали: распознавание голоса в режиме телефонного разговора требует очень быстрых вычислений. Для такой задачи CPU уже не подходят — необходимы GPU и оптимизация распределения нагрузки.

Скрипт запущен в систему и успешно прошел первые испытания. Боевой запуск планируется в начале следующего года.

Комментарий заказчика: Ребята сделали и вроде работает)) Получен результат, который хотелось. Задачи можно закрывать.
Петр Петрович Осипов

Если вы не знаете, какая технология подойдет под вашу задачу — приходите к нам. Мы сами разберемся, подберем лучшее решение и соберем рабочий вариант под ваши условия. Не нужно будет тратить время на эксперименты вслепую — мы уже прошли тот путь, который вы только намечаете.