Чтобы подготовить голосового ИИ к работе на входящей линии, недостаточно загрузить FAQ и написать несколько демонстрационных сценариев. Команде нужны реальные записи контакт-центра: они показывают, какими словами клиенты описывают проблему, где перебивают оператора, какие данные называют не полностью и в какой момент требуют человека. Аудио, расшифровки и результаты разговоров помогают настроить распознавание речи, сформировать карту интентов, определить необходимые уточнения, сократить ответы и установить правила перевода оператору.
Это особенно важно при создании виртуального контакт-центра на базе ИИ, который должен обрабатывать не подготовленные демонстрационные вопросы, а реальный поток обращений.
При этом записи не нужно механически загружать в модель. Сначала их отбирают, при необходимости обезличивают, расшифровывают, размечают и связывают с фактическим результатом обращения. Только после этого они становятся рабочими данными для проектирования голосового ассистента.
| Источник | Что показывает |
|---|---|
| FAQ и база знаний | Какие факты, правила и условия должна знать система |
| Скрипты операторов | Как компания планирует вести разговор |
| Записи звонков | Как клиенты на самом деле формулируют вопросы |
| Расшифровки | Какие слова, темы и последовательности встречаются в диалогах |
| CRM и статусы обращений | Чем закончился разговор и какое действие было выполнено |
| Причины переводов | Где автоматизации недостаточно или сценарий требует доработки |
Почему одного FAQ недостаточно
FAQ нужен голосовому ассистенту как источник фактов. В нём содержатся правила, условия, статусы, тарифы, сроки и типовые ответы.
Но FAQ обычно написан на языке компании.
Компания формулирует тему так:
Уточнение статуса обращения.
Клиент говорит:
Я уже звонил, мне сказали ждать. Ну и что теперь?
Компания пишет:
Перенос записи.
Клиент спрашивает:
Я завтра не попадаю. Можно не отменять совсем, а прийти потом?
Компания использует формулировку:
Информация о доставке.
Клиент говорит:
А оно вообще едет или потерялось?
Сотрудник контакт-центра понимает такие фразы по контексту. Он слышит, что первый клиент ждёт обратную связь, второй хочет сохранить запись, а третий проверяет статус доставки.
Для голосового ассистента эти связи необходимо описать заранее. Система должна сопоставлять разные разговорные формулировки с одним намерением и учитывать контекст предыдущих реплик.
Если использовать только FAQ, робот будет хорошо знать регламент, но может хуже понимать язык клиентов.
Что записи показывают о реальной речи клиентов
Записи нужны не только для составления списка популярных вопросов. Такие вопросы бизнес обычно знает и без прослушивания тысяч звонков.
Основная ценность аудио — в речевых привычках клиентов.
По записям можно определить:
- с каких фраз люди начинают разговор;
- какие слова используют вместо внутренних терминов компании;
- как описывают одну проблему разными способами;
- где теряют мысль;
- какие данные называют не полностью;
- как формулируют отказ;
- как выражают согласие без прямого «да»;
- в какой момент перебивают;
- когда начинают раздражаться;
- почему просят оператора;
- как продолжают предыдущую коммуникацию.
Например, клиент может ни разу не сказать:
Хочу узнать статус заявки.
Вместо этого он повторяет:
Мне обещали перезвонить, но никто не связался.
Для сотрудника смысл очевиден. При подготовке ассистента такую формулировку нужно связать с проверкой статуса и истории обращения.
Другой распространённый случай:
Я уже вчера звонил.
Для клиента это продолжение начатой истории. Если система воспринимает звонок как новое обращение и снова задаёт все вопросы, человек быстро теряет терпение.
Записи показывают реальный порядок, в котором клиент приносит проблему в контакт-центр. Под этот порядок и должна проектироваться логика диалога.
Аудио и расшифровка решают разные задачи
Расшифровки удобны для поиска тем, повторяющихся фраз и вариантов формулировок. Но они не заменяют исходное аудио.
В тексте остаются слова. В аудиозаписи дополнительно слышны:
- шум;
- темп речи;
- паузы;
- перебивания;
- плохая связь;
- проглоченные окончания;
- эмоциональная окраска;
- речь нескольких людей;
- неуверенность;
- самоисправления.
Для голосового ИИ это часть рабочего потока, а не случайный фон.
Упрощённо обработка выглядит так:
- Клиент произносит реплику.
- ASR преобразует аудио в текст.
- Система определяет смысл и намерение.
- Диалоговая логика выбирает действие.
- Ассистент формирует и озвучивает ответ.
- Результат передаётся в CRM или другую систему.
Подробнее о первом и последнем речевых этапах можно прочитать на странице технологий распознавания и синтеза речи ASR/TTS.
Если ошибка возникла на этапе распознавания, она влияет на всю дальнейшую цепочку.
Клиент говорит:
Хочу перенести запись.
Система распознаёт:
Хочу принести записку.
После этого даже качественная языковая модель будет анализировать неправильный текст.
Поэтому при подготовке проекта необходимо работать одновременно с аудио, транскрипциями и результатами диалогов.
Какие данные нужно собрать перед запуском
Для проектирования входящего голосового ассистента полезно подготовить несколько связанных наборов данных.
Записи разговоров
Нужны реальные диалоги с разным качеством связи, продолжительностью и результатом.
В выборку включаются:
- успешно закрытые обращения;
- переводы оператору;
- повторные звонки;
- сбросы;
- длинные разговоры;
- нестандартные вопросы;
- негативные обращения;
- звонки в часы пик;
- диалоги с плохой связью;
- обращения разных клиентских сегментов.
Расшифровки
Текстовые версии нужны для поиска:
- частых формулировок;
- вариантов одного намерения;
- внутренних и клиентских терминов;
- последовательностей вопросов;
- причин непонимания;
- повторяющихся возражений.
Транскрипцию необходимо сопоставлять с аудио. Автоматическая расшифровка тоже может содержать ошибки.
Метаданные звонка
При наличии доступа полезно учитывать:
- дату и время;
- продолжительность;
- направление звонка;
- очередь;
- тему;
- оператора или группу;
- результат;
- перевод;
- повторное обращение;
- клиентский сегмент;
- статус в CRM.
Метаданные помогают понять не только содержание разговора, но и его место в бизнес-процессе.
Итог обращения
Для каждого диалога желательно знать, чем он закончился:
- вопрос закрыт;
- выполнено действие;
- создана заявка;
- произведён перевод;
- клиент отказался;
- звонок прерван;
- потребовался повторный контакт;
- клиент обратился снова.
Без результата сложно определить, была ли реплика оператора или ассистента эффективной.
Записи диалогов, ответы операторов, таблицы и корпоративные документы могут становиться основой для настройки прикладных ИИ-продуктов. Подробнее этот подход раскрыт на странице Product AI от Neuro.net.
Как сформировать репрезентативную выборку
Универсального количества записей для всех проектов нет.
Объём зависит от:
- количества тем;
- сложности сценария;
- числа клиентских сегментов;
- разнообразия формулировок;
- качества связи;
- используемой телефонии;
- регионов;
- языков;
- сезонности;
- доли повторных обращений.
Для узкой задачи может быть достаточно ограниченного набора диалогов. Для многотематической входящей линии понадобятся сотни или тысячи записей.
Но состав выборки важнее одного установленного числа.
Если большая часть аудио относится к одному простому сценарию, система хорошо подготовится именно к нему. Остальные обращения принесут проблемы уже после запуска.
В выборке должны быть представлены:
| Категория | Зачем она нужна |
|---|---|
| Частые типовые обращения | Сформировать основной контур автоматизации |
| Редкие, но важные запросы | Определить границы системы |
| Переводы оператору | Найти причины эскалации |
| Повторные звонки | Обнаружить незакрытые вопросы |
| Сбросы | Найти неудачные реплики и длинные паузы |
| Плохая связь | Проверить устойчивость распознавания |
| Перебивания | Настроить управление очередностью реплик |
| Негативные обращения | Определить правила безопасного перевода |
| Разные часы нагрузки | Проверить влияние инфраструктуры |
| Разные клиентские группы | Учесть различия в лексике и поведении |
Выборку нужно формировать по бизнес-логике, а не только по удобству выгрузки.
Что размечают в звонках
После отбора записи превращают в структурированные данные.
Для этого команда размечает не только тему обращения, но и ход разговора.
Намерение клиента
Например:
- проверить статус;
- перенести запись;
- отменить услугу;
- уточнить стоимость;
- изменить данные;
- оформить заказ;
- получить консультацию;
- соединиться с оператором.
Варианты формулировок
Для каждого намерения собираются реальные фразы клиентов.
Например, намерение «перенести запись» может звучать так:
- «Я завтра не смогу приехать»;
- «Можно на другой день?»;
- «Давайте не отменять, а перенесём»;
- «У меня планы поменялись»;
- «Есть время после выходных?».
Значимые данные
Отмечаются сведения, необходимые для выполнения действия:
- номер заказа;
- дата;
- адрес;
- ФИО;
- услуга;
- сумма;
- филиал;
- желаемое время;
- причина обращения.
Контекст
Нужно учитывать:
- что клиент уже сообщил;
- исправлял ли данные;
- ссылался ли на прошлый звонок;
- отказывался ли от предложенного варианта;
- менял ли тему;
- просил ли оператора.
Результат
Фиксируется, чем завершился разговор:
- задача решена;
- выполнен перевод;
- действие не выполнено;
- клиент прекратил разговор;
- создано повторное обращение.
Причина проблемы
Для сложных диалогов полезно указывать:
- ошибку распознавания;
- неверно определённое намерение;
- отсутствие данных;
- длинную реплику;
- лишнее уточнение;
- ошибку интеграции;
- неправильную маршрутизацию;
- ограничение сценария.
Такая разметка позволяет связать слова клиента с реальным бизнес-результатом.
Как записи помогают настроить ASR
ASR — технология автоматического распознавания речи, которая преобразует голос клиента в текст.
Общая модель может хорошо распознавать обычную речь, но хуже работать с:
- названиями продуктов;
- брендами;
- адресами;
- медицинскими терминами;
- финансовой лексикой;
- аббревиатурами;
- артикулами;
- именами;
- региональными особенностями речи.
Записи помогают определить, какие слова система путает чаще всего.
Например:
- название услуги распознаётся как обычное слово;
- номер договора разбивается неправильно;
- фамилия заменяется похожей;
- сокращение воспринимается как несколько отдельных слов;
- отраслевой термин исчезает из транскрипции.
После анализа можно:
- расширить словари;
- добавить варианты произношения;
- настроить подсказки распознаванию;
- изменить подтверждение критичных данных;
- добавить повторный вопрос;
- предусмотреть перевод оператору при низкой уверенности.
При этом показатель уверенности распознавания нельзя использовать изолированно. Система может быть уверена в неправильном варианте. Поэтому техническую оценку нужно сопоставлять с реальными ошибками в диалогах.
Как формируется карта интентов
Интент — это цель, с которой клиент обращается в компанию.
На старте бизнес часто предлагает карту, основанную на внутренней структуре:
- доставка;
- оплата;
- гарантия;
- возврат;
- запись.
Записи показывают, что реальный поток может быть устроен иначе.
Например, клиент говорит о доставке, но его настоящая задача — изменить адрес. Спрашивает о гарантии, но хочет оформить возврат. Начинает с оплаты, а затем выясняется, что платёж уже прошёл, но заказ не отображается.
Поэтому интенты необходимо строить не только по отдельным словам, но и по тому, какое действие требуется выполнить.
Хорошая карта интентов:
- соответствует реальному потоку;
- не содержит слишком похожих категорий;
- учитывает разговорные формулировки;
- допускает изменение намерения;
- определяет следующий шаг;
- связана с бизнес-процессом;
- содержит понятные правила перевода.
Слишком подробная карта усложняет классификацию. Слишком общая не позволяет выполнить нужное действие. Записи помогают найти рабочий уровень детализации.
О том, как голосовой агент связывает намерение клиента с дальнейшим сценарием, можно подробнее прочитать в материале о принципах работы виртуальных агентов.
Как аудио влияет на логику диалога
Анализ разговоров помогает определить не только то, что должен понимать ассистент, но и то, как он должен вести себя.
По записям видно:
- сколько клиент готов ждать;
- где нужна короткая реплика;
- какие вопросы можно пропустить;
- что уже есть в CRM;
- когда необходимо переспросить;
- когда лучше не продолжать автоматический сценарий;
- как подтвердить результат;
- какую информацию передать оператору.
Например, оператор может не спрашивать номер заказа сразу. Сначала он выясняет тему, а затем понимает, действительно ли номер понадобится.
Если робот начинает разговор с длинной анкеты, клиент воспринимает это как лишнюю нагрузку.
Записи позволяют построить диалог вокруг реального порядка действий:
понять проблему → проверить доступные данные → задать минимальное уточнение → выполнить действие → подтвердить результат.
Шум и перебивания нельзя исключать из выборки
Клиенты звонят:
- с улицы;
- из автомобиля;
- из торгового центра;
- из помещения с телевизором;
- с плохой связью;
- рядом с другими людьми.
Они говорят быстро, тихо, эмоционально или с паузами.
Если отобрать только чистые записи, система будет подготовлена к условиям, которые редко встречаются на настоящей линии.
Отдельно нужно анализировать перебивания.
Клиент может остановить длинную реплику, сразу назвать нужный вариант или задать новый вопрос. Система должна определить:
- действительно ли человек начал говорить;
- нужно ли остановить синтез;
- какое намерение появилось;
- следует ли вернуться к предыдущей теме;
- не был ли звук фоновым шумом.
Паузы тоже имеют разный смысл. Клиент может искать документ, вспоминать дату, разговаривать с человеком рядом или просто ждать продолжения.
Записи помогают установить правила:
- сколько ждать ответа;
- когда мягко уточнить;
- когда повторить вопрос;
- когда сократить реплику;
- когда предложить перевод.
Что записи могут показать о самом контакт-центре
В процессе анализа часто выясняется, что проблема находится не только в технологии.
Например:
- регламент не совпадает с реальными действиями операторов;
- разные сотрудники отвечают по-разному;
- в CRM используются несколько названий одной темы;
- база знаний не содержит частого вопроса;
- клиент звонит после неудачной попытки решить проблему на сайте;
- оператор вручную ищет данные в нескольких системах;
- причина повторных обращений не фиксируется.
В таком случае голосовому ассистенту передают неустойчивый процесс.
Если автоматизировать его без изменений, система воспроизведёт те же проблемы быстрее и на большем объёме.
Поэтому анализ записей может изменить постановку задачи. Компания планировала автоматизировать один сценарий, но фактический поток показывает, что больше нагрузки создаёт другой участок.
Это один из самых полезных результатов подготовительного этапа.
Как записи влияют на архитектуру ассистента
Работа с данными кажется методической задачей, но её результаты напрямую влияют на техническую архитектуру.
Записи помогают определить:
- требования к ASR;
- необходимость отраслевого словаря;
- структуру интентов;
- объём контекста;
- правила работы с паузами;
- настройки перебиваемости;
- допустимую длину ответов;
- источники данных;
- сценарии обращения к CRM;
- правила эскалации;
- формат резюме для оператора;
- требования к хранению аудио и транскрипций;
- метрики контроля после запуска.
Например, если клиенты регулярно начинают с фразы «я уже звонил», ассистенту может понадобиться доступ к истории обращений.
Если люди часто меняют дату после первого выбора, сценарий должен поддерживать исправление, а не начинаться заново.
Если большое количество обращений связано с состоянием заказа, потребуется интеграция с системой статусов, а не только статический FAQ.
Данные определяют, какие компоненты действительно нужны проекту.
Как организовать подготовку данных
Работу можно разделить на несколько этапов.
Этап 1. Определить задачу
Необходимо сформулировать:
- какой поток автоматизируется;
- какие результаты ожидаются;
- какие действия может выполнять робот;
- какие обращения остаются оператору.
Этап 2. Собрать выборку
В неё включаются разные темы, результаты, типы клиентов и условия связи.
Этап 3. Проверить данные
Команда оценивает:
- качество аудио;
- полноту метаданных;
- наличие результата;
- возможность использования записей;
- необходимость обезличивания.
Этап 4. Подготовить расшифровки
Автоматические транскрипции проверяются на ключевых участках, особенно там, где распознаются отраслевые термины и критичные данные.
Этап 5. Создать разметку
Определяются:
- намерения;
- формулировки;
- сущности;
- результаты;
- причины переводов;
- типовые ошибки.
Этап 6. Спроектировать логику
На основе данных формируются:
- карта интентов;
- сценарии;
- правила уточнений;
- условия эскалации;
- интеграции;
- финальные подтверждения.
Этап 7. Подготовить тестовый набор
Часть записей и фраз не используется при настройке, а сохраняется для независимой проверки.
Этап 8. Провести пилот
Система запускается на ограниченном потоке. Команда сравнивает результаты с исходными данными и корректирует сценарий.
Какие показатели проверять на пилоте
После запуска необходимо оценивать не только общую долю автоматизации.
Распознавание
- ошибки в ключевых словах;
- качество распознавания имён и номеров;
- влияние шума;
- доля повторных запросов;
- участки с низкой уверенностью.
Понимание
- правильно ли определено намерение;
- сколько запросов попадает в неопределённую категорию;
- понимает ли система разговорные формулировки;
- сохраняет ли контекст;
- корректно ли обрабатывает изменение намерения.
Диалог
- число уточнений;
- длина реплик;
- паузы;
- перебивания;
- возвраты к предыдущим вопросам;
- корректность финального подтверждения.
Операционный результат
- доля закрытых обращений;
- причины переводов;
- количество повторных звонков;
- выполнение целевого действия;
- время оператора после перевода;
- качество переданного контекста.
Нормативы устанавливаются отдельно для каждого сценария. Подтверждение записи и сложная консультация не могут оцениваться одинаково.
Когда данных пока недостаточно
Подготовку нужно продолжить, если:
- в выборке представлены только успешные звонки;
- отсутствуют разговоры с плохой связью;
- нет данных о результате обращения;
- темы в CRM не совпадают с реальным содержанием;
- большое количество транскрипций не проверено;
- интенты различаются только по внутренним терминам;
- неизвестны причины переводов;
- нет примеров повторных обращений;
- система тестируется на тех же фразах, которые использовались при настройке.
В такой ситуации пилот может выглядеть убедительно, но не покажет готовность к реальному потоку.
Подробнее о том, почему быстрый запуск без анализа данных, интеграций и ограничений создаёт риски, — в статье «Голосовой робот за 10 минут»: почему быстрые обещания ведут к большим убыткам.
Как Neuro.net работает с данными голосового проекта
Подготовка голосового ассистента начинается с анализа задачи, потока обращений и доступных данных.
В рамках проекта команда определяет:
- Какие звонки включить в выборку.
- Какие темы и результаты размечать.
- Какие клиентские формулировки учитывать.
- Какие требования предъявлять к распознаванию.
- Какие данные получать из внутренних систем.
- Какие вопросы ассистент может закрыть самостоятельно.
- Когда необходим оператор.
- Какой контекст передавать при переводе.
- Какие метрики контролировать на пилоте.
- Как обновлять сценарий после запуска.
ASR, NLU, LLM и база знаний работают не изолированно. Их необходимо связать с бизнес-логикой, интеграциями и данными реального контакт-центра.
Так система готовится не к идеальному демонстрационному вопросу, а к разнообразию реальной входящей линии.
Подробнее о создании кастомных ассистентов для звонков и клиентской поддержки — на странице разработки голосовых чат-ботов на базе ИИ.
Часто задаваемые вопросы
Нужно ли загружать все записи контакт-центра в языковую модель
Нет. Записи сначала отбираются, расшифровываются и размечаются. Затем команда определяет, какие данные нужны для настройки распознавания, интентов, сценариев, базы знаний и тестирования. Механическая загрузка всех разговоров не гарантирует качества.
Сколько записей нужно для подготовки голосового ассистента
Единого числа нет. Объём зависит от количества тем, разнообразия формулировок, клиентских сегментов и сложности процесса. Важнее, чтобы выборка содержала не только частые и успешные, но и проблемные, редкие и нестандартные диалоги.
Можно ли работать только с расшифровками
Расшифровки удобны для анализа тем и формулировок, но не показывают паузы, шум, перебивания и качество связи. Для голосового проекта необходимо сопоставлять текст с исходным аудио.
Для чего размечать результат разговора
Результат показывает, привёл ли диалог к решению задачи. Без него невозможно понять, какая формулировка действительно помогла клиенту, почему потребовался оператор и что стало причиной повторного обращения.
Помогут ли записи улучшить распознавание отраслевой лексики
Да. Они показывают, какие названия, термины, аббревиатуры и данные система распознаёт неправильно. На этой основе можно настроить словари, варианты произношения, подтверждение критичных сведений и правила повторного вопроса.
Заменяет ли большая языковая модель анализ звонков
Нет. LLM помогает работать со свободными формулировками, но ей всё равно нужны актуальные данные, правила бизнеса, ограничения, интеграции и примеры реальных обращений. Без анализа потока модель может говорить естественно, но выполнять процесс неточно.
Вывод
Голосовой ИИ должен быть подготовлен не только к тем вопросам, которые компания записала в FAQ, но и к тому, как реальные люди формулируют эти вопросы.
Клиенты сбиваются, перебивают, используют разговорные слова, продолжают старые обращения и называют данные в неожиданном порядке. Записи звонков позволяют увидеть это до промышленного запуска.
Аудио, расшифровки, разметка и результаты обращений помогают:
- адаптировать распознавание;
- сформировать карту интентов;
- сократить лишние уточнения;
- настроить интеграции;
- определить правила перевода;
- подготовить тестовый набор;
- установить метрики пилота.
Самая важная работа по подготовке голосового ИИ редко выглядит эффектно. Это отбор записей, проверка транскрипций, разметка ошибок и пересмотр процессов.
Но именно она определяет, будет ли ассистент работать только в демонстрационном сценарии или справится с реальной входящей линией.
Оставьте заявку, чтобы обсудить подготовку данных, архитектуру голосового ассистента и требования к пилотному запуску.
