В 2021 году один крупный медицинский центр пустил записи разговоров своих пациентов через популярное публичное облако для распознавания речи. Через два месяца куски диалогов с фамилиями и диагнозами всплыли в датасете для дообучения сторонней нейросети. Так закончилась их попытка быстро и дешево автоматизировать первую линию. Голосовой робот для контакт-центра on-prem: ASR и TTS без утечки разговоров клиентов — это не прихоть параноидального директора по ИБ. Это суровая база для любого бизнеса, где цена утечки выше стоимости стойки с GPU.
Индустрия завалена красивыми презентациями облачных провайдеров. Они показывают 98% точности распознавания и синтез, который неотличим от живого диктора. Проблема в том, что эти цифры получены на тепличных данных. Как только облачная модель сталкивается с реальным миром — шипящим каналом, бабушкой с плохой дикцией или сложной интеграцией с самописной CRM в закрытом контуре — магия исчезает. Задержки растут до двух секунд, клиент бросает трубку, а бизнес считает убытки.
Анатомия задержки: почему телефония убивает облачные API
Когда вы звоните в колл-центр, звук не летит в формате 16-битного FLAC. Это жестко сжатый аудиопоток в формате G.711 (a-law/u-law) с частотой дискретизации 8 кГц. Половина акустических признаков, на которых обучаются огромные трансформеры вроде Whisper, здесь просто физически срезана.
Плюс сетевые задержки. Живой диалог возможен, только если время ответа системы (latency) укладывается в 600–800 миллисекунд. Человек делает паузу, и если в течение секунды он не слышит реакции, он начинает говорить снова. Робот и человек перебивают друг друга. Возникает классический эффект рации.
В облачной архитектуре вы отправляете RTP-поток наружу, ждете окончания фразы (Endpointing), ждете ответа ASR (Speech-to-Text), потом NLU обрабатывает текст и дергает webhook вашей CRM, потом текст уходит в облачный TTS (Text-to-Speech), и аудио возвращается к вам. На каждом сетевом хопе вы теряете десятки миллисекунд. В пиковые часы нагрузки на облако провайдера latency улетает в космос. Вы не контролируете этот процесс.
On-prem инсталляция решает это радикально. Все компоненты крутятся на соседних серверах или вообще на одной машине, общаясь через gRPC или разделяемую память. Вы контролируете очередь инференса на GPU. Вы ставите жесткие таймауты. Вы отсекаете сетевую непредсказуемость.
Голосовой робот для контакт-центра on-prem: ASR и TTS без утечки разговоров клиентов
Сердце любого внедрения внутри контура — это кастомные модели. Облачные движки универсальны: они одинаково средне распознают и рецепт пирога, и банковские термины. При on-prem развертывании вы дообучаете ASR исключительно на вашем домене.
Для ASR критически важна архитектура акустической модели. Тяжелые трансформеры с глобальным контекстом дают лучшую метрику WER (Word Error Rate), но они не умеют работать в потоке. Для робота нужен потоковый инференс (streaming ASR) на базе RNN-T (Recurrent Neural Network Transducer) или потоковых конформеров. Такая модель выдает текст по мере поступления аудио чанков в 20-50 миллисекунд, а не ждет конца фразы.
Здесь же возникает самая недооцененная проблема — VAD (Voice Activity Detection). Детектор активности голоса определяет, когда человек начал и закончил говорить. Глупый VAD ждет двух секунд тишины, чтобы понять, что фраза окончена. Умный VAD анализирует просодику и интонацию. Когда мы в MoranaLabs катили on-prem робота для коллекторского агентства, главной проблемой были не маты должников, а фоновый шум: телевизоры, кричащие дети, улица. Пришлось жестко тюнить VAD и дообучать акустику на отбраковку шума, иначе робот постоянно реагировал на диктора в новостях на фоне. Облачное API на таком трафике генерировало бесконечный словесный салат.
# Архитектура стримингового инференса с кастомным VAD и агрессивным endpointing
import webrtcvad
from asr_engine import StreamingRNNT
vad = webrtcvad.Vad(3) # Режим максимального подавления шума
asr = StreamingRNNT(model_path="/models/bank_8khz_domain.pt")
def process_rtp_stream(audio_generator):
buffer = b''
silence_frames = 0
for chunk in audio_generator: # Ожидаем 8kHz, 20ms чанки
is_speech = vad.is_speech(chunk, sample_rate=8000)
if is_speech:
buffer += chunk
silence_frames = 0
yield asr.infer_chunk(chunk)
elif len(buffer) > 0:
silence_frames += 1
# Endpointing: 400ms тишины достаточно для прерывания
if silence_frames > 20:
yield asr.finalize()
buffer = b''
silence_frames = 0
break
Потоковый синтез (TTS) и контроль интонаций
С генерацией речи похожая история. Исторически синтез работал батчами: подали текст, подождали, получили аудиофайл. Для живого диалога это неприемлемо. Современный on-prem TTS генерирует аудио фрагментами. Пока GPU просчитывает конец длинного предложения, клиент уже слышит первые слова. Time-to-First-Audio (TTFA) в нормальной системе не превышает 150 миллисекунд.
Но скорость не отменяет специфики телефонии. Робот должен уметь перебиваться (Barge-in). Если клиент понял суть на середине фразы робота и сказал «да, согласен», система должна мгновенно оборвать RTP-поток синтеза и переключить state-машину диалога. В облаке синхронизация обрыва аудио и старта нового распознавания — это боль из-за асинхронности API. На своем железе вы рубите поток на уровне SIP-стека (Asterisk/FreeSWITCH) без задержек.
Интеграция с ядром: CRM и NLU
Зарубежные SaaS-конструкторы диалогов красивы, пока дело не доходит до интеграции с тяжелой энтерпрайз-CRM в закрытом контуре. Регулятор (ЦБ, Минздрав) запретит вам пробивать туннели из внутреннего сегмента сети к внешним вебхукам. ПДн не должны покидать периметр.
Развертывание NLU (Natural Language Understanding) локально позволяет напрямую ходить в базы данных. Вы мгновенно проверяете баланс, статус заказа или свободные слоты в расписании. Раньше для NLU писали монструозные регулярные выражения или тренировали узкие классификаторы намерений (Intents). Сейчас индустрия переходит на локальные LLM (размера 7B-8B параметров, квантованные до 4-bit), которые крутятся на тех же GPU, что и акустика. Они извлекают сущности из грязного текста гораздо надежнее, чем классические intent-движки, и могут вести свободный диалог (RAG по базе знаний компании).
Где робот окупается, а где раздражает
Технология — это инструмент, а не магия. Желание сэкономить на живых операторах часто приводит к созданию монстров, с которыми невозможно разговаривать. Бизнес должен четко разделять сценарии.
- Идеально для робота: Маршрутизация звонков по сложному дереву, сбор показаний счетчиков, подтверждение записи на прием, проверка статуса доставки, FAQ по жесткому регламенту.
- Убийство лояльности: Сложные претензии, реструктуризация долгов, нестандартные технические сбои.
- Абсолютное зло: Попытка скрыть, что звонит робот. Поддельные вздохи, кашель, слова-паразиты и фразы вроде «Ой, меня тут отвлекли». Клиент раскусывает это за 10 секунд, и изначальная лояльность сменяется агрессией из-за того, что его держат за идиота.
Грамотный робот сразу обозначает себя, дает четкие инструкции («Скажите Да или Нет», «Назовите номер договора») и главное — обеспечивает прозрачный путь эскалации. Если ASR выдает низкий confidence (неуверенность в распознавании) дважды подряд, звонок должен быть моментально переведен на живого человека с передачей всего контекста диалога на экран оператора.
Внедрение on-prem решений требует инженерной дисциплины. Вам придется разбираться с балансировкой видеокарт под пиковые нагрузки, тюнить Garbage Collector в сервисах оркестрации, настраивать мониторинг деградации акустических моделей со временем. Это сложнее, чем купить подписку по API. Но когда наступает момент пиковой нагрузки или приходит аудит ИБ, автономная инфраструктура — это единственное, что отделяет работающий бизнес от простоя и миллионных штрафов за утечку.