Как создать готовый к продакшену голосовой ИИ-агент

Фото: Jacek Dylag (Unsplash) — https://unsplash.com/photos/silver-microphone-near-audio-mixer-xPugU5J5ePc?utm_source=dev48&utm_medium=referral

Источник: LiveKit•

Как создать готовый к продакшену голосовой ИИ-агент

Опыт архитекторов решений и инженеров по внедрению LiveKit в переводе голосового агента из POC в продакшен: естественный разговор, наблюдаемость, надежность и стоимость.

Учитывая количество существующих сегодня решений (включая LiveKit) и то, насколько простым стал код с использованием ИИ, практически каждый может запустить демо-голосовой агент за считанные минуты. На самом деле, десятки тысяч разработчиков (и некоторые неразработчики) запускают агенты на LiveKit каждый месяц.

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

Готовность голосового ИИ-агента к продакшену сводится к 3 вопросам#

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

  • Достаточно ли агент умный и звучит ли он естественно, чтобы общаться с нашими пользователями?
  • Сможем ли мы понять, как он работает в продакшене?
  • Создали ли мы его так, чтобы масштабировать надежно и экономично?

7 способов создать умный и естественно звучащий голосовой агент#

1. Максимально оптимизируйте первый ответ агента#

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

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

Наши рекомендации сводятся к следующему:

Измеряйте первый ход отдельно. Отслеживайте время от поднятия трубки до первого слова агента как отдельную метрику, отдельно от задержки ответов p50 и p95. Когда мы разбирались с медленным началом у одной из команд, модели оказались не при чем. Перед тем как заговорить, агент ожидал HTTP-запрос для выбора приветствия, который сам по себе занимал почти целую секунду. Избавление от этого стало одним из самых дешевых способов снижения задержки, которые мы когда-либо находили.

Загружайте только то, что нужно агенту для приветствия, а остальное подгружайте во время разговора. Разделите контекст на две части. Первая содержит минимум, необходимый для хорошего приветствия, часто это просто имя звонящего. Передайте его вместе со звонком через метаданные задания, метаданные комнаты или SIP-заголовок, чтобы агент никогда не ждал поиска. Тем временем вторая часть содержит всё остальное и начинает загружаться, пока агент приветствует звонящего.

Совет

Сделайте первое предложение коротким, а самую важную часть поставьте на первое место.

2. Обрабатывайте смену реплик и прерывания как человек#

Ужасно раздражает общаться с голосовым ИИ-агентом (да и с человеком тоже), если он постоянно перебивает вас в неподходящий момент или продолжает разглагольствовать о том, что вам неинтересно. Чтобы исправить этот неприятный опыт, большинство команд, выводящих агент в продакшен, используют модель смены реплик, такую как детектор смены реплик LiveKit, в паре с адаптивной обработкой прерываний, чтобы дежурное «угу» не обрывало агента.

Это всего одна строка кода: turn_detection=inference.TurnDetector(). Она также используется по умолчанию, поэтому AgentSession включает ее, даже если вы пропустите эту строку, и добавляет адаптивную обработку прерываний везде, где ее поддерживает ваша модель распознавания речи.

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

Полный список опций и описание того, какой симптом каждая из них исправляет, см. в руководстве по настройке смены реплик или в разделе «Настройка определения реплик и прерываний в LiveKit Agents».

Совет

Если у вас нет под рукой носителя языка для тестирования пауз, полезным инструментом для начала станут симуляции агентов LiveKit с поддержкой голоса.

3. Избегайте неестественных пауз#

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

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

Три наиболее распространенных способа сделать это:

Используйте быстрые ИИ-модели, которые справляются со своей задачей. Использование привычных LLM (например, новейших от OpenAI или Anthropic) не всегда является правильным выбором. На самом деле, во многих случаях наши архитекторы решений не рекомендуют их использовать. Например, Gemma 4 31B на базе LiveKit Inference часто выдает правильные ответы и вызовы инструментов с гораздо меньшим временем размышлений и задержкой, чем более универсальные модели. Парочка наших клиентов перешла с GPT-4.1 на Gemma и увидела экономию 300–500 мс на p50, при этом агент успешно прошел все тесты. Вы можете самостоятельно сравнить модели в бенчмарках задержки LiveKit Inference.

Время до первого токена для идентичных запросов по результатам бенчмарков выпуска Gemma 4 (июль 2026 г.). Меньше значение — выше скорость.

  • Gemma 4 31B · LiveKit192 мс

Gemma 4 31B · LiveKit

192 мс

  • GPT-5.5966 мс

GPT-5.5

966 мс

  • GPT-4.11 006 мс

GPT-4.1

1 006 мс

  • Gemini 3.0 Flash1 095 мс

Gemini 3.0 Flash

1 095 мс

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

Будьте внимательны к размеру промптов и кэшированию. Одно из самых простых исправлений для медленных ответов, с которым помогают наши архитекторы решений и инженеры по внедрению, — это оптимизация размера промпта и его правильное кэширование. Для контекста, разница между небольшим промптом (~2 тыс. токенов) и большим (>15 тыс. токенов) может составлять до ~500 мс на p50 и целый сеанс на p95. Кэширование может быть таким простым, как изменение порядка промпта: один из наших внутренних тестов показал улучшение задержки на 38% просто за счет перемещения статического контента в верхнюю часть системного промпта.

4. Помогите своему агенту слушать клиента, не отвлекаясь на фоновый шум#

Человеку довольно легко понять, говорит ли собеседник на другом конце провода или это фоновый шум из шоу Love Is Blind: Sweden на его телевизоре. Для голосового агента это не всегда очевидно, и мы сталкивались с ситуациями, когда агент вел крайне запутанный разговор с фоновым телевизором или вовсе полностью заглушал голос пользователя. Существует множество способов защититься от этого в продакшене, и мы описали их в статье «Шумоподавление в LiveKit: что это такое и как оно работает».

Совет

Одна из проблем, с которыми мы сталкиваемся, когда команды выходят в продакшн, заключается в том, что они не тестируют агента в условиях фонового шума. Вы можете запустить свои сценарии с фоновым шумом в LiveKit с помощью команды lk agent simulate audio --scenarios scenarios.yaml --background-noise.

5. Наделите своего голосового агента правильным акцентом для вашего региона и выражениями, подходящими по контексту#

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

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

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

TTS-провайдерВыражение

Сообщите ему хорошую или плохую новость и послушайте, как изменится манера речи.

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

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

Совет

В некоторых случаях помогает согласование всего конвейера STT, LLM и TTS с правильным языком и локалью. Например, номер телефона, произнесенный на британском английском, может расшифровываться иначе, чем на американском английском, что влияет на то, как агент воспроизводит номер обратно.

6. Интеллектуальная очистка произнесенной по буквам информации#

Ключевое слово здесь — «интеллектуальная». Нет ничего хуже панического посимвольного надиктовывания: «М как Мария, И как искра, С как солнце?». Получение нужной информации от вашего агента не должно занимать пять минут взаимных переспросов.

Подход нашей команды обычно состоит из трех частей:

Правильное распознавание по буквам без прерывания звонящего. Произношение по буквам изобилует паузами, и агент, который воспринимает каждую паузу как конец реплики, вмешается уже после «М-И-К». Детектор реплик LiveKit понимает, что звонящий еще не закончил говорить, и вы можете дать ему немного больше терпения (более высокое значение min_delay) для моментов, когда это необходимо.

Очистка с помощью специального этапа вместо основного промпта. Не заставляйте ваш основной промпт выполнять эту работу. Готовые задачи LiveKit (GetNameTask, GetEmailTask, GetPhoneNumberTask, GetAddressTask и другие) созданы именно для этого: они превращают фразу «джон точка доу собака джи мейл» в john.doe@gmail.com и запоминают то, что звонящий уже сказал, чтобы никогда не переспрашивать дважды. Кроме того, вы можете добавить инструмент агента, который выполняет нечеткий поиск по вашим записям для некоторых случаев.

Повторное чтение в удобном для проверки звонящим виде. Во многих случаях одно четкое подтверждение лучше трех раундов угадывания, поэтому наша команда часто рекомендует заставлять агента перечитывать информацию по буквам, произнося «точка» и «собака» вслух: «Это д ж о н точка д о е собака gmail точка com, верно?»

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

7. Держите агента в рамках сценария#

В марте 2026 года кто-то опубликовал информацию о том, что чат-бот Chipotle с удовольствием пишет код на Python. Его попросили развернуть связанный список перед оформлением заказа, и бот объяснил алгоритм, написал рабочий код, а затем вежливо поинтересовался, что пользователь хочет на обед.

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

Вот четыре способа, с помощью которых мы помогали командам справляться с этим:

Пишите промпт под ту модель, которую вы используете. Каждая модель сбивается с пути по-своему, поэтому промпт, который работает на одной, не всегда подойдет для другой. По нашему опыту, быстрые модели вроде Gemma лучше справляются с явными предписывающими правилами («делай это, никогда не делай то»), в то время как более крупные модели общего назначения работают лучше, когда вы описываете цель и позволяете им самим определить шаги. Что бы вы ни использовали, четко укажите те вещи, которые модель категорически не должна произносить вслух. Для более тонких сбоев, таких как переключение языков, используйте инструменты наблюдения LiveKit Observability (LiveKit Observability), чтобы отслеживать моменты возникновения сбоев, частоту их появления и дорабатывать промпт с учетом этих ситуаций.

Совет

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

Проверяйте данные в коде, а не в системном промпте (когда это целесообразно). Чем больше правил вы закладываете в промпт, тем выше вероятность того, что модель совершит ошибку. Все, что имеет однозначный правильный ответ, должно обрабатываться в коде. Проверка даты рождения — хороший пример: языковые модели откровенно плохо справляются с датами, поэтому вместо того, чтобы просить модель сравнить «3 марта 1985 года» с записью в базе данных, поручите ей вызов инструмента verify_date_of_birth и позвольте вашему коду вернуть «да» или «нет». То же самое касается проверок на право на участие, поиска по аккаунтам и бизнес-правил.

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

Для критически важных звонков задействуйте вторую модель для наблюдения. В редких случаях, когда вам нужно, чтобы разговор происходил очень быстро, но при этом нельзя жертвовать интеллектуальными возможностями умной модели, наши инженеры по внедрению рекомендуют использовать паттерн «наблюдатель»: быстрая модель ведет беседу, в то время как более умная модель слушает в фоновом режиме и при необходимости незаметно направляет следующий ответ агента. Наблюдатель не блокирует речь, поэтому собеседники никогда не слышат процесс проверки. Тем не менее, здесь есть важные компромиссы, которые следует учитывать. Например, наблюдатель может исправить только следующий ответ, но не текущий; запуск двух моделей стоит дороже; а дополнительная сложность обычно является временным решением, а не долгосрочным дизайном.

3 способа подготовиться к успешному наблюдению за вашим голосовым агентом в продакшене#

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

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

1. Определите, что вам разрешено записывать, еще до начала записи#

Убедитесь, что то, что вы записываете, соответствует вашим требованиям к локализации данных, персональным данным (PII) и срокам их хранения.

Перепроверьте свой регион наблюдаемости (если применимо). Если вы используете LiveKit Cloud для наблюдаемости, регион данных вашего проекта определяет, где хранятся трассировки, логи, метрики, стенограммы и записи. На сегодняшний день это Соединенные Штаты (по умолчанию) или Европейский Союз (Франкфурт). Он задается при создании проекта.

Включите маскирование персональных данных (при необходимости). LiveKit может удалять личную информацию из стенограмм, аудио и телеметрии перед их сохранением: произнесенные детали заменяются звуковым сигналом, а текст превращается в маркер скрытия. Эта функция отключена по умолчанию и входит в состав LiveKit Observability без дополнительной оплаты.

2. Сформулируйте гипотезу о том, что такое «хорошо», перед запуском (и убедитесь, что вы настроены это измерять)#

Голосовые агенты могут быть сложными системами, и после развертывания легко «заблудиться в логах». Чтобы помочь вам сосредоточиться на первых днях в продакшене, мы рекомендуем уделить внимание нескольким вещам.

Насколько быстро это ощущается. Наши инженеры обычно смотрят на задержку «от конца до конца» (end-to-end latency) на уровне p50 и p95, а также на первый ход разговора. LiveKit Observability сообщает значение e2e_latency для каждого ответа агента. Вы можете изучать его звонок за звонком в Agent Insights (это задержка под каждым ответом агента на скриншоте выше), смотреть показатели p50/p95/p99 в аудиосимуляциях перед запуском, чтобы получить приблизительное представление, и экспортировать их в инструменты, которые вы уже используете для отслеживания процентилей по всем вашим продакшн-звонкам.

Справляется ли он со своей задачей. Выберите результат, который соответствует тому, что вы создали. Цели для исходящего агента, агента службы поддержки и ИИ-интервьюера различаются, поэтому универсального ответа не существует. Что бы вы ни выбрали, наши FDE-инженеры советуют сделать это чем-то измеримым, а не тем, что можно оценить исключительно по стенограммам. Если успех означает передачу квалифицированного лида человеку, вызов инструмента transfer_to_human станет вашим событием конверсии. Также отслеживайте то, что происходит после передачи, например, является ли лид «теплым» или «холодным».

Совет

Если вы действительно используете LLM для оценки звонков, сохраняйте шкалу небольшой. Мы заметили, что модели дают противоречивые оценки по шкале от 0 до 100, но они, как правило, справляются лучше с шкалой от 0 до 7 или бинарной шкалой.

3. Убедитесь, что вы можете находить и классифицировать краевые случаи (edge cases) по вашим стенограммам#

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

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

3 способа создать надежного и рентабельного голосового агента в продакшене#

1. Исходите из того, что любая модель рано или поздно даст сбой#

У каждого провайдера моделей случаются сбои; вопрос не в том, «если», а в том, «когда». При развертывании в масштабах продакшена мы рекомендуем предусматривать резервный вариант для каждой модели. Если вы используете конвейер STT-LLM-TTS, это означает наличие фоллбэка для каждого этапа. В фреймворке LiveKit Agents с использованием LiveKit Inference это обычно реализуется одной-двумя строками кода. И не останавливайтесь на конвейере STT-LLM-TTS: учитывайте также свои инструменты, если они совершают вызовы LLM.

Совет

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

2. Убедитесь, что ваш бэкенд готов к работе под нагрузкой#

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

LiveKit Cloud масштабируется вместе с вами, поэтому нагрузочное тестирование уровней медиа и агентов может оказаться пустой тратой бюджета. Вместо этого они рекомендуют протестировать каждый из ваших собственных компонентов и убедиться, что они настроены правильно и с нужными лимитами: ваши бэкенд-базы данных могут обрабатывать множество подключений, ваши API справляются с объемом запросов, а если вы не используете LiveKit Inference, ваши провайдеры моделей настроены с учетом ваших ожиданий по одновременным подключениям.

3. Знайте стоимость разговора до того, как масштабировать его#

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

Не позволяйте этому списку помешать вам запуститься#

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

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

Если по пути вы столкнетесь с чем-то, что не сможете решить, мы с радостью поможем. Наши инженеры по поддержке разработчиков, архитекторы решений и выездные инженеры каждый день помогают командам переводить голосовые агенты из стадии пилотного проекта в продакшен. Пообщайтесь с нашей командой или изучите документацию по LiveKit Agents, чтобы начать работу.

Ссылки: fallbacks

О чём эта статья

Ещё в разделе «Телеком и сети»

Все →

Ещё от LiveKit