Как строить realtime voice AI, который звучит как живой собеседник

Краткое содержание

• Realtime voice дает пользователю другой способ взаимодействия с AI-продуктом: не печатать и не ходить по меню, а говорить естественно и получать ответ с живым темпом, интонацией и эмоциональным контекстом.
• Хороший голосовой realtime-опыт - это не просто быстрый ответ модели. Это управление живым взаимодействием, где разговор идет в реальном времени и не всегда укладывается в очередность "пользователь сказал - система ответила".
• Модель - только часть системы. Для production нужны voice-native инфраструктура, разделение разговорного слоя и глубокого reasoning, а также event-driven управление состоянием сессии.
• Guardrails и evals остаются самыми сложными зонами. Проверки безопасности должны успевать за живым аудио, а такие качества, как тон, тайминг и flow разговора, плохо оцениваются обычными текстовыми тестами.

Realtime voice как продуктовая поверхность

Большинство voice-enabled AI-приложений до сих пор устроены как цепочка: речь превращается в текст, текст отправляется в модель, модель думает, затем синтезатор озвучивает ответ. Это работает, но ощущается как pipeline, а не как разговор.

Realtime voice меняет механику. Пользователь говорит естественно, а система отвечает с учетом темпа, тона и эмоционального контекста. Опыт становится быстрее и ближе к общению с человеком, чем к управлению интерфейсом.

Такие агенты особенно полезны там, где голос лучше текста: клиентская поддержка, онбординг, коучинг, accessibility-сценарии, замена длинных IVR-меню и переключений между отделами. Если разговорная форма сама по себе снижает трение, realtime voice стоит рассматривать как отдельную продуктовую поверхность, а не как "озвученный чат".

Chained voice vs realtime voice

В классическом chained-подходе используются отдельные модели для speech-to-text, language processing и text-to-speech. Аудио находится только на входе и выходе. Между ними есть дискретные шаги, которые добавляют задержку и делают взаимодействие менее естественным.

Realtime voice работает иначе: одна модель нативно слушает, понимает и говорит, одновременно работая с аудио и транскриптом. Ввод и вывод идут непрерывно. Поэтому тайминг, интонация и обработка перебиваний становятся не техническими деталями, а частью продукта.

System note

сравнительная схема двух архитектур. Слева chained-пайплайн с отдельными блоками speech-to-text, LLM и text-to-speech, между которыми возникает задержка. Справа realtime voice-модель, которая одновременно принимает аудио, понимает контекст и генерирует голосовой ответ в живом потоке.

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

В chained-системе есть понятная очередность: пользователь сказал, система ответила, затем начался следующий шаг. В realtime voice такой структуры нет. Собеседники могут говорить одновременно, может возникнуть тишина, пользователь может перебить агента в середине ответа или задать уточнение до завершения фразы.

Поэтому realtime voice - это не только задача генерации ответа. Это задача координации живого взаимодействия.

Что нужно для production

Чтобы realtime voice работал в масштабе, архитектуру нужно проектировать специально под живое взаимодействие. В статье выделены три обязательных слоя.

Voice-native инфраструктура

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

Первый базовый слой - voice-native session layer. RTC-фреймворки дают место, где можно управлять участниками, стримить аудио и запускать агентов в телефонии или WebRTC-среде. В оригинальной статье отдельно упоминается LiveKit как практичный вариант: он дает низколатентный WebRTC-стек, noise cancellation и jitter reduction из коробки. Самостоятельно строить такой слой обычно невыгодно из-за сложности.

Разделить "говорение" и "мышление"

Для realtime voice полезна multi-agent архитектура с разделением ответственности.

Realtime voice-модели сильны в разговорном аудиостриминге, но не всегда оптимальны для глубокого reasoning. Tool calling, retrieval, планирование и структурное принятие решений часто лучше отдавать отдельной модели.

Практичный паттерн - responder-thinker architecture.

Responder - это realtime voice-агент. Он поддерживает живое взаимодействие: слушает, говорит, обрабатывает перебивания и сохраняет flow разговора. Его приоритеты - скорость, ясность и эмоциональная непрерывность.

System note

схема responder-thinker. Realtime responder находится в живом голосовом диалоге с пользователем, а отдельный thinker работает вне основного аудиопотока: вызывает инструменты, делает retrieval, планирует и возвращает responder-у результат для естественного включения в разговор.

Thinker - отдельный агент на reasoning-capable модели. Он работает out-of-band и берет на себя инструменты, поиск, планирование и сложные решения. Responder может обращаться к нему при необходимости и затем возвращать результат в разговор.

Иногда thinker сам делает reasoning, иногда оркестрирует набор специализированных агентов. Главное - не заставлять realtime voice-слой выполнять всю тяжелую работу. Тогда responder остается быстрым и разговорным, а thinker занимается задачами, которым нужны время, контекст и структура.

Авторы допускают, что будущие frontier-модели могут сделать такое разделение менее нужным. Но сейчас, по их опыту, этот паттерн стабильно лучше одиночного агента.

Event-driven control

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

Все эти события нужно фиксировать, стримить и хранить как основу текущего состояния разговора. Без этого система теряет возможность точно вмешиваться в нужный момент.

Event-driven подход решает эту задачу. Система ловит события по мере возникновения, обновляет session state и запускает нужные действия.

Легкие обработчики должны оставаться в realtime-пути, чтобы не ломать отзывчивость. Более тяжелые задачи - обновление state machine, логирование метрик, удаление чувствительных данных, запись в базы, завершение сессии - лучше выносить в асинхронный фон.

По мере роста продукта количество фоновых задач быстро увеличивается. Даже небольшое изменение фичи может добавить новые event flows и зависимости. Поэтому concurrency и структура событий должны быть спроектированы заранее, иначе систему станет сложно понимать и надежно развивать.

Event-driven слой нужен не только для инженерной надежности. Он помогает управлять самим разговором: темпом, тишиной, перебиваниями, моментом завершения сессии. Например, если пользователь приближается к лимиту времени, система может мягко подсказать responder-у помочь завершить разговор. Если взаимодействие застряло, можно дать уточняющую инструкцию.

Хорошая realtime-система всегда понимает, кто говорит, как развивается диалог и какие условия уже выполнены. Это состояние непрерывно обновляется потоком событий и позволяет давать агенту правильную подсказку в правильный момент.

Guardrails должны работать со скоростью realtime

Guardrails обязательны для пользовательского AI-продукта: они отвечают за безопасность, compliance, защиту от misuse и надежность. В turn-based системе есть удобные точки проверки: после реплики пользователя или перед выдачей ответа.

Realtime voice убирает эти комфортные checkpoint-ы. Пользовательский ввод приходит непрерывно. Аудиоответ уже может стримиться. Финальный транскрипт часто появляется позже звука. Если ждать полных сообщений, realtime-ощущение ломается.

Поэтому safety-проверки должны идти параллельно разговору. Один из подходов - стримить аудио в буфер и асинхронно проверять фрагменты транскрипта по мере появления. Так guardrails работают почти в реальном времени и не блокируют interaction.

System note

схема realtime guardrails. Аудиопоток идет через буфер и транскрипцию, фрагменты параллельно проверяются safety-слоем, а при срабатывании guardrail система перенаправляет разговор, меняет поведение агента или завершает сессию без резкой задержки для пользователя.

Если guardrail срабатывает, система должна реагировать в контексте: перенаправить разговор, скорректировать поведение или завершить сессию. Цель - сохранить безопасность без заметного ухудшения пользовательского опыта.

Realtime evals сложнее обычных evals

Самая трудная часть оценки realtime voice-системы в том, что ключевые качества нельзя увидеть только в транскрипте. Тайминг, перебивания, flow и тон существуют во временном измерении.

Обычные eval-пайплайны хорошо работают для текста: подать реалистичный сценарий, получить ответ, оценить результат. В realtime input - это живое аудио, а важные свойства проявляются в динамике: как агент реагирует на overlapping speech, насколько быстро отвечает, как восстанавливается после перебивания.

Ручное тестирование голосом хорошо ловит эти качества, но плохо масштабируется. Тестирование по транскриптам масштабируется, но теряет главный сигнал, который отличает хороший realtime-опыт от плохого.

Практичный ответ - комбинировать несколько уровней:

• Agent-to-agent evaluations: второй realtime-агент играет заданную пользовательскую персону и разговаривает с тестируемой системой, а третий LLM-as-a-judge оценивает взаимодействие.
• Non-functional metrics: time-to-first-audio и sentiment analysis по транскрипту дают количественные proxy-метрики качества разговора.
• Manual qualitative review: ручная оценка все еще нужна, чтобы ловить проблемы тона, естественности и нюансов, которые автоматические метрики пропускают.

Ни один метод не покрывает все. Для production нужны все три слоя, и даже тогда инструменты оценки realtime audio пока заметно менее зрелые, чем инструменты для текстового AI.

Вывод

Realtime voice меняет форму продукта. Пользователь воспринимает не только слова, но и паузы, перебивания, скорость восстановления, тон и общий flow.

Поэтому модель - лишь часть системы. Production-ready realtime voice требует voice-native session layer, разделения разговорного и reasoning-слоев, event-driven контроля вокруг живой сессии и guardrails, которые не ломают realtime-ощущение.

Самое слабое место стека - оценка качества. Пока нет единого способа надежно тестировать то, что делает realtime voice "живым": тайминг, тон, обработку перебиваний и естественность разговора. Поэтому командам придется сочетать автоматические тесты, agent-to-agent прогоны и ручную проверку.