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

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

Расшифровка звонков колл-центра решает только первый уровень задачи. Она переводит разговор в текст, но бизнесу нужны более прикладные результаты:

  • краткое содержание звонка;
  • договоренности и следующие действия;
  • причина обращения или отказа;
  • оценка работы менеджера;
  • признаки недовольства;
  • упоминания конкурентов;
  • автоматически заполненные поля CRM;
  • теги для фильтрации и отчетов.

Для этого используется речевая аналитика: запись разговора переводится в структурированный текст, разделяется по спикерам и передается на дальнейший AI-анализ.

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

Есть более короткий маршрут: подключить готовый speech to text API или CRM-виджет и сосредоточиться на бизнес-правилах.

Как внедряют речевую аналитику лидеры рынка и почему не каждый подход подходит отделу продаж

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

Кастомная платформа под один бизнес-процесс

В кейсе Technokratos для HT Lab была разработана система анализа интервью. Она принимала запись, расшифровывала ее через Whisper Large 3, распределяла ответы по компетенциям и формировала заключение с помощью языковой модели. Рабочий сервис собрали за три недели.

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

Такой вариант оправдан, если процесс уникален, а готовый сервис не покрывает требования. Использовать его только ради транскрибации звонков CRM обычно невыгодно.

Python, Whisper и Google Colab

Команда ВкусВилл Бизнес пошла от практической задачи: в CRM находились тысячи звонков, которые невозможно было прослушать вручную. Записи скачивали скриптом, обрабатывали через Whisper в Google Colab, очищали от персональных данных и отправляли на анализ. Для первого теста применялась модель base, автор отдельно отметил ошибки в специальных терминах.

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

Для ежедневной автоматизации отдела продаж возникают ограничения:

  • среда Colab временная;
  • загрузка и выгрузка файлов требуют дополнительных сценариев;
  • при сбое часть заданий приходится перезапускать;
  • результаты нужно самостоятельно возвращать в CRM;
  • очистка персональных данных становится отдельным этапом;
  • нет гарантированного времени обработки;
  • сложно контролировать параллельный поток.

Прототип работает. Продакшен-сервис требует другой архитектуры.

Локальный стек из Whisper, NeMo, Ollama и Gemma

В материале Альфа-Банка показан локальный конвейер: ffmpeg готовит аудио, Whisper делает транскрипт, NVIDIA NeMo разделяет реплики по спикерам, Gemma через Ollama формирует саммари, а результаты сохраняются в Obsidian.

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

Для колл-центра появляется другой масштаб. Нужно обновлять несколько библиотек, следить за совместимостью CUDA и драйверов, хранить модели, управлять очередью, распределять нагрузку и контролировать качество диаризации. Если утром одновременно завершились 200 звонков, локальная видеокарта не увеличит производительность автоматически.

Телеком-API с базовой транскрибацией

Exolve показывает сценарий, в котором приложение создает звонок, получает идентификатор записи и запускает транскрибацию через SDK. В статье 2024 года приводилась стоимость 0,60 рубля за минуту. Автор прямо описывал этот пример как базу для собственной механики.

Телеком-API удобно использовать, когда телефония уже работает у того же поставщика. Но текст звонка еще не является речевой аналитикой. Отдельно потребуются:

  • распределение реплик между клиентом и менеджером;
  • нормализация текста;
  • саммари;
  • оценка скрипта;
  • тегирование;
  • запись результата в нужные поля CRM;
  • отчеты для руководителя.

Сравнение подходов

Три ловушки самописной STT-системы

Самостоятельный прототип часто выглядит как один вызов Whisper. Реальный конвейер сложнее. Основные проблемы становятся заметны после загрузки первых сотен записей.

Ловушка 1. Диаризация спикеров

Распознавание речи отвечает на вопрос, какие слова прозвучали. Диаризация определяет, кто и когда говорил.

Без нее получается текст, в котором реплики клиента и менеджера перемешаны. На таком материале трудно проверять скрипт. Система может приписать вопрос менеджера клиенту, а обещание клиента оплатить счет посчитать обязательством сотрудника.

Диаризация строится из нескольких компонентов. Например, каскадный сценарий NVIDIA NeMo включает детектор речевой активности, извлечение голосовых признаков и кластеризацию спикеров.

На результат влияют:

  • одновременная речь;
  • фоновый шум;
  • музыка ожидания;
  • переадресация;
  • громкая связь;
  • разная громкость каналов;
  • короткие реплики;
  • соединение нескольких разговоров в одном файле.

Даже после разделения на Спикера 1 и Спикера 2 нужно определить роли. В стереозаписи телефонии задача проще: менеджер и клиент могут находиться на разных каналах. В монофайле роли приходится устанавливать по контексту или дополнительным данным CRM.

Ловушка 2. Границы чанков и галлюцинации

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

На границе могут возникнуть три типа дефектов:

  • фраза делится между двумя сегментами;
  • часть слова или реплики пропускается;
  • предыдущий контекст вызывает повторение.

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

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

Ловушка 3. Инфраструктура под неравномерную нагрузку

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

Кроме GPU потребуются:

  • API-шлюз;
  • объектное хранилище;
  • база заданий;
  • очередь сообщений;
  • обработчики повторных попыток;
  • журналирование;
  • контроль лимитов;
  • мониторинг времени обработки;
  • резервирование;
  • механизм удаления файлов.

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