Книга: Инжиниринг искусственного интеллекта
Назад: Д.4 TTS: как компьютер говорит
Дальше: Е.1 Проблема: нейросеть не возвращает 2+2

Д.8 Будущее голосовых ассистентов

Эмоциональный интеллект.

Модели научатся распознавать эмоции по голосу (злой, грустный, радостный) и адаптировать ответ. «Я вижу, вы расстроены. Давайте я помогу вам спокойно разобраться.»



Разговор по ролям.

Ассистент будет запоминать, кто с ним говорит (ребёнок или взрослый, постоянный пользователь или гость), и менять стиль общения. С ребёнком - проще и веселее, с начальником - формальнее.



Проактивность.

Ассистент не будет ждать команды. Он сам предложит: «Через 15 минут у вас встреча. Напомнить?» или «На улице дождь, не забудьте зонт».



Генерация голоса в реальном времени.

TTS станет настолько быстрым, что ассистент сможет перебивать пользователя, уточнять, договаривать фразы - как человек. Это требует стримингового TTS и отказа от подхода «сначала сгенерировали весь ответ, потом произнесли».



Полное объединение в одну модель.

Одна нейросеть будет и слушать, и понимать, и думать, и говорить. SpeechGPT и Google USM - первые шаги. Через 5–7 лет конвейер из трёх моделей уйдёт в историю, как ушли HMM из ASR.



РЕЗЮМЕ К ГЛАВЕ Д

1. Голосовой ассистент чат-бот. Это конвейер из трёх моделей: ASR (речь текст), NLU/LLM (понимание), TTS (текст речь). Каждый этап - отдельная точка отказа.



2. ASR (распознавание речи) превращает звук в текст. Лучшее соотношение качества и доступности - Whisper (OpenAI). Для офлайн и экономии - Vosk.



3. NLU для голоса может быть разным: маленький классификатор для простых команд (быстро, дёшево) или LLM для сложных диалогов (медленно, дорого). Гибридный подход - золотая середина.



4. TTS (синтез речи) прошёл три поколения: конкатенативный (реалистично, но негибко), параметрический (гибко, но роботизированно), нейросетевой (реалистично и гибко, но требует GPU).



5. Клонирование голоса позволяет синтезировать речь любого человека по 5–10 секундам образца. Это мощный инструмент и серьёзный риск (deepfake-атаки).



6. Латентность - главный враг. Человек ожидает ответ за 0.5–1 секунду. 3 секунды - уже «задумался». 5 секунд - диалог сломан. Стриминг ASR, кэширование и маленькие модели помогают сокращать задержки.



7. Конвейер трёх моделей медленный и хрупкий, но пока стандарт. Единые мультимодальные модели (Google USM, SpeechGPT) - будущее, но до них ещё 3–5 лет.



8. Безопасность голосовых ассистентов требует особого внимания: запрет клонирования голоса без согласия, логирование аудиозаписей, стоп-слово для прерывания.



9. Мониторинг голосового ассистента должен включать: ASR-текст (что услышали), NLU-интент (что поняли), TTS-текст (что сказали), латентность каждого этапа.



10. Будущее голосовых ассистентов: эмоциональный интеллект (распознавание эмоций по голосу), разговор по ролям (ребёнок vs взрослый), проактивность (сам предлагает действия), полное объединение в одну модель.



Вопросы для самопроверки

1. Из каких трёх этапов состоит работа голосового ассистента? Что делает каждый этап?



2. Какие проблемы могут возникнуть при распознавании речи (ASR) и как их решать?



3. Чем отличается подход «выделение намерения и сущностей» от использования LLM для голосовых команд? Когда что выбирать?



4. Назовите три поколения TTS. Какое из них используется в современных ассистентах и почему?



8. Что такое клонирование голоса и в чём его риски?



9. Почему конвейер из трёх моделей может давать неудовлетворительную латентность? Как её сокращать?



10. Что такое единая мультимодальная модель? Приведите примеры. Почему они пока не вытеснили конвейер?



11. Какие метрики нужно мониторить в голосовом ассистенте, чтобы понимать, где происходит сбой?



12. Голосовой ассистент собрали. Теперь вопрос: а как его тестировать?



Юнит-тесты не работают - ответы не детерминированы. Ручное тестирование не масштабируется - диалогов миллион. А ошибка в голосе может стоить не просто «плохого ответа», а реальных денег или репутации.



Глава Е - про тестирование LLM-приложений. Методология, метрики, инструменты. LLM-as-a-Judge, shadow mode, canary-релизы, nightmare library. И главное -почему ваш CI/CD сломался, как только вы добавили нейросеть.



ГЛАВА Е. КАК ТЕСТИРОВАТЬ ТО, ЧТО НЕЛЬЗЯ ЗААССЕРТИТЬ

«В классической разработке тест падает, если сломался код. В LLM-разработке тест падает, если модели просто не повезло с температурой. Или если сегодня четверг. Или если промт стал на три слова длиннее.»



Голосовой ассистент собран. Агент настроен. Мультимодальные модели подключены.

Теперь вопрос: а как проверить, что всё это работает надежно?

Юнит-тесты не работают - ответы недетерминированы. Ручное тестирование не масштабируется - диалогов миллион. А ошибка в голосе или действие агента может стоить не просто "плохого ответа", а реальных денег или репутации.

Классический QA сломался, как только вы добавили нейросеть. Глава Е - про новую методологию тестирования. LLM-as-a-Judge, shadow mode, nightmare library. И главное - как построить страховочную сетку, которая не даст вам выкатить галлюцинацию в продакшен.



Вступление: почему ваш CI / CD cломается, как только вы добавили LLM



Представьте себе обычное утро в классической IT-компании, которая решила «добавить нейросетку».

Вы - продакт или инженер-лид. Ваша команда идеально настроила CI/CD: запушили код → прогнали юнит-тесты → прогнали интеграционные → зелёная сборка → деплой в прод. Всё предсказуемо, всё работает как часы. sum(2,2) возвращает 4 миллион раз подряд.



А потом вы добавили LLM.

Первый тест вы написали гордо, по привычке:

python

def test_agent_math():

response = agent.ask("Сколько будет 2+2?")

assert response == "4"

Тест упал. Вы в шоке открываете лог, а там: "2+2 = 4". Ваш assert не прошёл, потому что модель поставила пробел перед знаком равенства.

«Ну, ерунда», - думаете вы. - «Сейчас поправим».

Вы исправляете:

python

assert "4" in response

Тест зелёный. Вы выдыхаете.



Через неделю приходит новый разработчик, меняет температуру модели с 0.7 на 0.8 «чтобы было креативнее». Теперь на «2+2» модель отвечает: «Четыре. Если вы имеете в виду арифметику, то ответ - четыре». assert "4" in response сработал. Вы довольны.

Но через две недели приходит багрепорт от клиента: «Ваш ассистент не умеет считать!» Вы смотрите в логи случайной выборки и находите:



Пользователь: Сколько будет 2+2?

Ассистент: 2+2 = 5, если мы округляем в большую сторону, но обычно это 4.

Модель сгаллюцинировала. assert "4" in response прошёл бы и здесь. Но ответ - мусор. Пользователь уже написал в поддержку.



В чём проблема?



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

В LLM-разработке тест должен проверять поведение модели в вероятностном пространстве. Модель не «делает то, что вы сказали». Она делает то, что статистически вероятно на основе её весов, промпта, температуры и фазы луны. Поведение недетерминированно - один и тот же промпт может дать десять разных ответов.

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

Эта глава - о том, как построить систему оценки и тестирования LLM-приложений, которая не сойдёт с ума и не разорит вас на ручной проверке.

Мы пройдём путь от абсолютного недоверия (модель всегда врёт) через выборочное доверие (LLM-судья ставит оценки) к автоматизированному контролю (канареечные релизы и shadow mode).

Но сначала - разберёмся, почему привычные assert не работают, и что с этим делать.



Назад: Д.4 TTS: как компьютер говорит
Дальше: Е.1 Проблема: нейросеть не возвращает 2+2