Развертывание кода в продакшен: 31 сбой в прототипе, который уже продавали

Статья разбирает реальный кейс: как команда получила голосовой ИИ-сервис, который «уже работал», и почему развертывание кода в продакшен потребовало не доработки, а полноценного исследования, от настройки детектора голосовой активности под русскую речь до пересборки архитектуры.

Материал основан на подробном разборе разработчика, который принял в работу голосовой сервис, навайбкоженный (то есть быстро собранный с помощью ИИ-инструментов) тимлидом-фронтендером. Сервис уже начали продавать, но задержки были слишком большими, ИИ-аватар замолкал при перебивании, качество транскрибации (перевода речи в текст) скакало, а логов и метрик синтеза и распознавания речи (TTS и STT) попросту не существовало. Вместо классического пути «требования, архитектура, разработка, прод» команда пошла от обратного: запускали то, что есть, находили конкретное ограничение, делали его воспроизводимым и только потом принимали архитектурные решения.

Почему «подкрутить настройки» превратилось в исследование?

Типичный пример: задача «бот иногда перебивает человека» выглядела как обычный баг. Есть VAD (Voice Activity Detection, детектор голосовой активности, он определяет, говорит сейчас человек или нет), надо подкрутить параметры. Но настройки оказались в конфликте друг с другом:

• Быстрая реакция бота приводила к тому, что он принимал за речь шум, эхо и даже собственный голос
• Низкая чувствительность означала, что бот не замечал, когда человек начинал говорить поверх него
• Короткая пауза заставляла бота перебивать длинный ответ, длинная превращала разговор в мучительное ожидание

В обычном вызове API (программного интерфейса) лишняя секунда может быть незаметна. В живом разговоре она ощущается мгновенно.

Как тестировали и что получилось?

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

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

Дальше выяснилось главное: VAD вообще отвечает не на тот вопрос. Он определяет, есть ли сейчас речь, а команде нужно было понять, закончил человек отвечать или просто задумался. Так задача «подкрутить VAD» доехала до определения конца реплики (end-of-turn), многоступенчатого VAD и отдельных бенчмарков (тестовых наборов для измерения качества). Многоступенчатый VAD на тренировочных данных выглядел отлично, но на отложенном интервью результат разваливался. В прод это не поехало.

Что пришлось переделать в самом сервисе?

Работа шла почти вся по одному сценарию: чтобы сравнить разные системы распознавания и синтеза речи, сначала пришлось сделать так, чтобы их можно было менять. Отдельно измерить задержки. Понять, на каком этапе сервис ждёт.

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

Требования и архитектура не были первым этапом. Они вытаскивались из уже работающего сервиса: нашли проблему, научились её повторять, поняли ограничение, и только после этого решили, что менять.

Что понадобится

• Тестовые аудиозаписи на русском: обычная речь, паузы, перебивания, фоновый шум
• Логирование TTS и STT: без метрик синтеза и распознавания речи любое сравнение провайдеров превращается в «поговорил и показалось»
• Возможность быстро менять провайдера распознавания и синтеза речи без переписывания всего сервиса
• Бенчмарки для VAD: набор записей, на которых вы измеряете число ложных срабатываний
• Время: это не доработка на пару дней, а цикл «баг, воспроизведение, исследование, решение»

Пошаговая инструкция

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

2. Добавьте логирование. Каждый вызов STT (распознавание речи) и TTS (синтез речи) должен записывать задержку, текст и статус. Без этого развертывание кода в продакшен превращается в гадание.

3. Измерьте базовую линию. Прогоните тестовые записи через текущие настройки VAD. Посчитайте число преждевременных завершений реплики: это ваша отправная точка.

4. Разделите вопросы. VAD отвечает «есть ли сейчас речь», а вам нужен ответ «закончил ли человек мысль». Это разные задачи. Проверьте, не пытаетесь ли вы решить вторую, подкручивая первую.

5. Итерируйте на данных, не на ощущениях. Меняйте параметры, прогоняйте тот же набор записей, сравнивайте числа. Результат, который работает на тренировочных данных, обязательно проверяйте на отложенном наборе.

6. Упрощайте перед добавлением. Перед тем как подключать нового провайдера или менять архитектуру, удалите дублирующий и мёртвый код. По опыту автора исходного разбора, большая часть работы оказалась удалением, а не дописыванием.

7. Фиксируйте решения. Каждое изменение, которое прошло бенчмарк, записывайте с контекстом: какие данные, какие параметры, почему выбрали именно этот вариант. Иначе через неделю вы не вспомните, почему откатили предыдущий.

Что делать с этим прямо сейчас?

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

Разработчикам и техническим предпринимателям. Прежде чем обещать клиенту конкретные задержки, убедитесь, что вы можете их измерить. Логирование TTS и STT, это не «потом допилим», а условие честного разговора о качестве.

Маркетологам. Если ваш продукт использует голосовой ИИ, не продавайте демо как продукт. Разница между «поговорил с ботом и получил осмысленный ответ» и «бот стабильно работает при шуме, перебиваниях и паузах» может стоить репутации.

Главный урок этого кейса укладывается в одну фразу: если прототип уже продают, перестаньте считать его прототипом и начните относиться к нему как к неизвестной системе, которую надо исследовать. Не «допилить», а понять.