Голосовое общение в реальном времени предлагает принципиально новый способ взаимодействия с приложениями на базе ИИ. Вместо набора текста и переходов по меню пользователи говорят естественно и получают ответы с живым темпом и эмоциональным контекстом.
Чтобы голосовое общение в реальном времени было качественным, необходимо координировать живое взаимодействие. Именно здесь начинается настоящая работа над продуктом. Общение в реальном времени воспринимается как мгновенное и живое, но создать приложение, способное постоянно поддерживать такое ощущение, — отдельная инженерная задача.
Модель — лишь часть системы. Рабочим приложениям нужны ориентированная на голос инфраструктура, чёткое разделение между ходом разговора и глубокими рассуждениями, а также событийное управление развивающимся сеансом.
Защитные механизмы и оценка остаются основными источниками сложностей. Проверки безопасности должны поспевать за живым звуком, а такие неуловимые качества разговора, как темп, тон и плавность, трудно оценивать традиционными методами.
Сегодня большинство голосовых ИИ-приложений по-прежнему работает одинаково: речь преобразуется в текст, модель формирует ответ, а синтезированный голос зачитывает его пользователю. Это работает. Но взаимодействие и ощущается как конвейер, а не как разговор.
Голосовое общение в реальном времени меняет ситуацию. Пользователи говорят естественно и получают ответы с подходящими темпом, тоном и эмоциональным контекстом. Такое взаимодействие быстрее и естественнее последовательных конвейеров распознавания речи: оно больше похоже на разговор с человеком, чем на управление системой.
По нашему опыту, это открывает возможности для продуктов, с которыми конвейерные архитектуры справляются плохо. Голосовые агенты реального времени могут обслуживать клиентов без длинных и неудобных меню IVR и переводов между отделами. Они могут обучать, знакомить с продуктом, повышать доступность разных каналов взаимодействия и решать многие другие задачи. Голосовое общение в реальном времени стоит внедрять везде, где разговор удобнее текстового интерфейса.
Большинство голосовых приложений использует так называемый «последовательный подход»: конвейер из отдельных моделей для преобразования речи в текст, языковой обработки и синтеза речи. Такие системы хорошо работают и открывают множество возможностей, но звук присутствует лишь на краях конвейера. Отдельные этапы создают жёсткую структуру и задержки, поэтому взаимодействие ощущается менее естественным, чем живой разговор.
В голосовых системах реального времени применяется другой подход. Вместо отдельных моделей для восприятия, мышления и речи всеми тремя задачами занимается одна модель, которая одновременно понимает и создаёт как звук, так и расшифровки. Ввод и вывод происходят непрерывно, поэтому система отвечает с естественными интонациями и темпом, сохраняя живой ритм разговора. В результате темп, тон и обработка перебиваний становятся центральными элементами продукта.
Взаимодействие в реальном времени привлекает мгновенной реакцией, но реализовать его сложно, поскольку никто не ждёт своей очереди. Для его поддержки недостаточно быстро и точно создавать аудио. Сложность заключается во всём остальном. Модель работает внутри живого сеанса, поэтому всё вокруг неё — состояние, безопасность, оркестрация и управление — должно идти параллельно с разговором и в том же темпе.
В последовательном голосовом приложении пошаговый разговор имеет чёткую структуру обмена репликами. Пользователь говорит, система отвечает, затем начинается следующий этап. Голосовое общение в реальном времени не предоставляет такой структуры. Обе стороны могут говорить одновременно — или молчать. Пользователь может перебить систему посреди ответа или задать следующий вопрос, пока она ещё говорит. Перебивания перестают быть редкими исключениями и становятся одним из основных сценариев взаимодействия.
Поэтому приложения реального времени — это прежде всего задача координации, а окружающая модель система не менее важна, чем сама модель.
Для масштабной поддержки такой системы необходимо проектировать её специально для живого взаимодействия. В системах, успешно вышедших в рабочую среду, регулярно встречаются три ключевых компонента.
Голосовые сеансы реального времени должны поддерживать потоковую передачу аудио, очерёдность реплик, перебивания, жизненный цикл подключения и выполнение агента. В зависимости от среды развёртывания приложению также может потребоваться поддержка телефонии. Это основа пользовательского опыта и масштабирования приложения.
Первое требование — ориентированный на голос сеансовый уровень. Платформы связи в реальном времени (RTC) позволяют приложению управлять участниками, транслировать аудио и запускать агентов в среде телефонии. По нашему опыту, особенно полезна платформа Livekit: она предлагает готовый стек WebRTC с низкой задержкой, качественным шумоподавлением и сглаживанием джиттера. Дополнительная сложность самостоятельной реализации этого уровня редко себя оправдывает.
Мультиагентная архитектура голосовых систем реального времени прежде всего разделяет зоны ответственности.
Голосовые модели реального времени отлично справляются с потоковым разговорным аудио, но не оптимизированы для глубоких рассуждений. Вызов инструментов, поиск информации и структурированное принятие решений лучше поручать другой модели.
Эффективный шаблон — архитектура «ответчик — мыслитель».
Ответчик — это голосовой агент реального времени. Он поддерживает живое взаимодействие: слушает, говорит, обрабатывает перебивания и сохраняет плавность разговора. Его архитектура ставит во главу угла скорость реакции, ясность и эмоциональную непрерывность.
Мыслитель — это отдельный агент на базе модели, способной к рассуждениям. Он работает вне основного канала и выполняет такие задачи, как использование инструментов, поиск информации и планирование. Ответчик может обращаться к нему при необходимости и включать полученные результаты в разговор.
В одних случаях мыслитель может самостоятельно выполнять рассуждения. В других он может координировать набор специализированных агентов. Главное, что эту работу выполняет модель, лучше приспособленная к задачам на рассуждения.
Преимущество очевидно: ответчик остаётся быстрым, сосредоточенным на разговоре и естественным, а мыслитель выполняет работу, требующую больше времени, контекста или структуры.
В будущем развитие передовых моделей может сделать этот подход ненужным, но пока, по нашему опыту, он стабильно превосходит архитектуры с одним агентом.
Голосовые системы реального времени естественным образом создают непрерывный поток событий.
Пользователи начинают говорить, делают паузы и перебивают. Расшифровки обновляются по мере поступления данных. Ответы создаются и передаются потоково. Поступают результаты внешних операций. Условия внутри сеанса меняются. Всё это можно фиксировать, передавать и хранить как ключевые события, сформировавшие текущее состояние разговора. Без них мы теряем возможность точечного и целенаправленного вмешательства.
Событийный подход предлагает понятный способ управления этим процессом. Система фиксирует события по мере их возникновения, обновляет состояние сеанса и запускает необходимые последующие действия.
Легковесные обработчики обеспечивают быструю реакцию в реальном времени, а более сложные операции — обновление конечных автоматов, запись метрик, удаление конфиденциальных данных, обновление баз данных и завершение сеанса — запускаются асинхронно в фоновом режиме.
По мере добавления функций количество таких фоновых задач может быстро расти. Даже небольшие изменения продукта могут создавать новые потоки событий и зависимости. Грамотно спроектированная архитектура параллельной обработки помогает сохранять понятность и надёжность системы по мере её развития.
Событийный подход также помогает решать важную продуктовую задачу — управлять ходом самого разговора. Аудиосистема реального времени не просто создаёт ответы: она управляет темпом, обрабатывает паузы и перебивания, а также решает, как и когда завершить сеанс. Эти особенности поведения влияют на восприятие продукта, поэтому их следует проектировать целенаправленно.
Когда состояние сеанса меняется с учётом количества реплик, прошедшего времени или поведения пользователя, система может передавать ответчику целевые указания. Например, она может подсказать агенту, что пора помочь пользователю завершить разговор при приближении к лимиту сеанса, или предложить уточнение, если взаимодействие застопорилось. Такие вмешательства не требуют больших ресурсов, но делают взаимодействие продуманным и целостным.
Хорошо спроектированная система сохраняет чёткое представление о состоянии сеанса: кто говорит, как развивается разговор и какие условия уже выполнены. Это состояние непрерывно обновляется потоком событий и позволяет давать нужные указания в нужный момент.
В пользовательских ИИ-системах защитные механизмы обязательны. Они отвечают за безопасность, соответствие требованиям, предотвращение злоупотреблений и надёжность. В пошаговой системе понятно, когда их запускать: после реплики пользователя или перед выдачей ответа.
При голосовом общении в реальном времени большинство этих удобных контрольных точек исчезает. Ввод пользователя поступает непрерывно. В этот момент аудиоответ уже может транслироваться. Готовые расшифровки часто отстают от звука. Если система будет ждать полных сообщений и лишь затем проверять их, разговор перестанет восприниматься как происходящий в реальном времени.
Поэтому защитные механизмы должны работать параллельно с разговором, сохраняя ощущение живого общения. Один из подходов — передавать аудио в буфер и асинхронно анализировать доступные фрагменты расшифровки. Это позволяет выполнять проверки безопасности почти в реальном времени, не блокируя взаимодействие.
При срабатывании защитного механизма система может отреагировать с учётом контекста: перенаправить разговор, скорректировать поведение или при необходимости завершить сеанс. Так защитные механизмы работают в реальном времени, не ухудшая пользовательский опыт.
Главная сложность оценки разговорной системы реального времени заключается в том, что важнейшие характеристики — темп, перебивания, плавность и тон — невозможно проверить по одной лишь расшифровке.
В стандартных процессах оценки системе предлагают реалистичные сценарии, наблюдают за результатами и выставляют баллы. Для текстовых систем и последовательных аудиосистем всё просто: отправить текст и проверить полученный текст. В системе реального времени на вход поступает живой звук, а важнейшие аспекты динамики разговора зависят от времени: как агент справляется с одновременной речью, насколько быстро отвечает и как продолжает разговор после перебивания.
Ручное тестирование — непосредственный разговор с агентом — позволяет оценить эти качества, но плохо масштабируется. Автоматическая оценка по расшифровкам масштабируется, но исключает именно те сигналы, которые отличают качественное голосовое общение в реальном времени от неудачного.
Одного метода недостаточно. На практике нужен комплексный подход:
Оценка в формате «агент — агент»: второй агент реального времени получает указание играть роль пользователя с заданным образом и общается с тестируемой системой. Третья LLM выступает в роли судьи и оценивает взаимодействие. Это позволяет массово тестировать весь аудиотракт, включая темп и обработку перебиваний.
Нефункциональные метрики: время до начала аудиоответа и анализ тональности расшифровки служат количественными показателями качества разговора.
Ручная качественная оценка: она по-прежнему необходима для выявления проблем, которые не замечают автоматические метрики, особенно связанных с тоном и естественностью речи.
Ни один метод не охватывает всё. Для запуска агентов реального времени в рабочей среде необходимо сочетать все три метода. Но даже тогда инструменты оценки звука в реальном времени остаются менее зрелыми, чем инструменты для текстового ИИ.
Голосовое общение в реальном времени меняет сам продукт. На восприятие пользователей влияют не только слова, но и темп, перебивания, паузы и возвращение к разговору.
Поэтому модель — лишь часть системы. Для рабочего голосового сервиса реального времени нужны ориентированный на голос сеансовый уровень, чёткое разделение речи и рассуждений, а также событийное управление текущим сеансом. Защитные механизмы остаются главным источником задержки, но нестандартные подходы позволяют во многом сохранить взаимодействие в реальном времени.
Самым слабым звеном системы по-прежнему остаётся оценка. Пока нет общепринятого способа оценивать то, что делает голосовое общение в реальном времени качественным: темп, тон, обработку перебиваний и плавность разговора. До появления такого способа разработчикам придётся сочетать автоматические тесты, прогоны в формате «агент — агент» и ручную оценку.