«Там всё уже работает. Надо только немного допилить и дотащить до прода», — с этих слов мне передали сервис голосовых ИИ‑интервью. Его навайбкодил тимлид‑фронтендер, а сервис к тому моменту уже начали продавать. Оставалось, как казалось со стороны, только задеплоить. И сервис действительно работал: можно было открыть браузер, поговорить с ИИ‑аватаром и получить вполне осмысленные ответы.

Потом я пошёл смотреть подробнее. Задержки были слишком большими, ИИ‑аватар иногда «обижался» и переставал говорить, если его перебить, а качество транскрибации сильно скакало. Логов и метрик синтеза и распознавания речи (TTS и STT) не было, поэтому любые новые провайдеры и подходы приходилось проверять живым разговором. На демо всё выглядело классно, но технически мы ещё не могли нормально ответить, как сервис устроен, какую задержку и какое качество можем обещать.

Как было раньше

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

Тут же мы пошли не с конца, а скорее сбоку. Как будто эту задачу до нас уже кто‑то делал, только не совсем эту и не совсем профессионально. Мы запускали то, что уже есть, находили конкретное ограничение или баг, делали его воспроизводимым, добавляли тесты и бенчмарки, а уже из них получали новые требования и архитектурные решения. Большая часть работы оказалась удалением и упрощением сервиса, а по ходу возникло много задач на исследование: какие технологии выбрать для интервью на русском и английском, каково их качество, задержки, цены и доступность из России.

Один баг, который оказался исследованием

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

С паузами та же история. При короткой паузе бот перебивает длинный ответ, при длинной после каждой реплики все сидят и ждут. В обычном вызове программного интерфейса (API) лишняя секунда может быть не важна, а в разговоре она очень хорошо чувствуется. Поэтому мы перестали крутить параметры руками и начали собирать нормальные тестовые записи: обычную речь, длинные паузы внутри ответа, перебивания, шум и эхо.

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

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

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

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

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

Где начинается проблема

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

Для стартапа такой прототип может быть единственным способом быстро проверить гипотезу и что‑то показать клиентам. Можно сразу посадить человека перед ботом, посмотреть, нужен ли он вообще, где он раздражает пользователя и какие сценарии действительно важны. Для меня главный вопрос в другом: в какой момент перестать считать это быстрым прототипом и начать относиться к нему как к неизвестной системе, которую ещё надо исследовать.

Что здесь изменил ИИ

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

Сейчас прототип за несколько дней может научиться разговаривать, ходить во внешние API и полностью решать основные бизнес‑задачи. Снаружи он выглядит как продукт, хотя требования, ограничения и иногда даже понимание того, как он устроен, появляются уже после него. Я пока не понял, лучше ли такой процесс, чем классический. В одном случае работающий сервис экономит месяцы, в другом вся сложность просто переезжает на этап, когда продукт уже продан и отступать поздно.

Вместо вывода

Интересно, было ли у вас что‑то похожее: сначала появился сервис, собранный с помощью ИИ, а требования, тесты и архитектура начали появляться уже потом? Расскажите, как вы решали, что в нём допиливать, а что проще написать заново. Особенно интересно, по каким признакам вы понимаете, что прототип пора перестать чинить и начать проектировать заново.