Вы загрузили запись разговора в Whisper, дождались обработки и получили точный, но почти бесполезный текст:

добрый день вы оставляли заявку на подключение телефонии да нам нужно записывать звонки менеджеров сколько человек работает в отделе сейчас восемь но планируем расширяться

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

После разделения по голосам та же запись выглядит иначе:

Менеджер: Добрый день. Вы оставляли заявку на подключение телефонии?

Клиент: Да, нам нужно записывать звонки менеджеров.

Менеджер: Сколько человек работает в отделе?

Клиент: Сейчас восемь, но планируем расширяться.

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

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

Почему Whisper возвращает сплошной текст

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

На выходе обычно есть:

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

Информации о том, кто произнес фразу, в стандартном результате нет.

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

Особенно заметна проблема на длинных записях:

  • телефонных разговорах;
  • интервью;
  • совещаниях;
  • консультациях;
  • подкастах;
  • переговорах;
  • фокус-группах.

Поэтому Whisper с разделением спикеров обычно представляет собой не одну модель, а связку распознавания речи и отдельной системы диаризации.

Что такое диаризация спикеров

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

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

00:00:01 Speaker_0: Добрый день. Чем могу помочь?

00:00:04 Speaker_1: Хочу уточнить статус заказа.

00:00:08 Speaker_0: Назовите, пожалуйста, номер заявки.

Метки Speaker_0 и Speaker_1 не являются именами людей. Они показывают, что фразы произнесли разные участники.

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

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

Где разделение по голосам приносит практическую пользу

Диаризация нужна не ради красивого оформления текста. Она позволяет использовать расшифровку как структурированные данные.

Аналитика звонков отдела продаж

Когда реплики клиента и менеджера разделены, можно автоматически определить:

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

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

Интервью и исследования

Журналисту или исследователю важно отделить вопросы от ответов. После диаризации проще готовить публикацию, искать цитаты и сравнивать позиции нескольких участников.

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

Совещания и рабочие встречи

Структурированная расшифровка помогает восстановить ход обсуждения:

  • кто предложил решение;
  • кто взял задачу;
  • какие возражения возникли;
  • кто назвал срок;
  • по какому вопросу не пришли к согласию.

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

Подкасты и видеоконтент

Разделение по спикерам упрощает монтаж, подготовку субтитров, создание таймкодов и публикацию текстовой версии выпуска.

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

Консультации

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

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

Можно ли добавить диаризацию к Whisper

Да, но сама модель Whisper не решает эту задачу полностью.

Для локальной обработки обычно используют следующую схему:

Аудиофайл

    |

    +--> Whisper: распознает слова и ставит таймкоды

    |

    +--> Модель диаризации: определяет интервалы спикеров

    |

    +--> Сопоставление результатов по времени

    |

    +--> Готовый диалог

В качестве модели диаризации часто используют pyannote.audio или компоненты NVIDIA NeMo. В 2026 году появились и end-to-end решения, например VibeVoice ASR, которые объединяют распознавание, временную разметку и определение спикеров в одном проходе.

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

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

Почему локальная диаризация сложнее, чем кажется

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

Участники перебивают друг друга

Когда два человека говорят одновременно, системе нужно обнаружить overlapping speech и решить, какие слова относятся к каждому голосу.

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

Метки могут поменяться местами

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

Поэтому результаты отдельных частей нельзя просто объединить без дополнительного сопоставления голосов.

Короткие реплики определяются хуже

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

Шум меняет голосовые признаки

Телефонная компрессия, музыка, эхо, громкая улица и слабый микрофон ухудшают не только качество текста. Они мешают системе сравнивать голоса и объединять фрагменты одного человека.

Длинные записи требуют инфраструктуры

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

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

RTTM: зачем нужен этот формат

Системы диаризации часто сохраняют результат в формате RTTM. В нем указываются начало фрагмента, его длительность и идентификатор спикера.

Упрощенный пример:

SPEAKER call_102 1 0.50 4.20 speaker_0

SPEAKER call_102 1 6.00 3.10 speaker_1

Первая строка означает, что speaker_0 говорил с отметки 0,5 секунды в течение 4,2 секунды. Вторая строка описывает интервал другого участника.

Проблема в том, что RTTM хранит временную разметку, но не создает готовый диалог. Текст Whisper и интервалы спикеров приходится сопоставлять по таймкодам.

Для исследовательской работы формат RTTM удобен. В бизнес-приложении обычно нужен другой результат:

{

  "dialogue": [

    {

      "speaker": "Менеджер",

      "start": 0.5,

      "text": "Добрый день. Чем могу помочь?"

    },

    {

      "speaker": "Клиент",

      "start": 6.0,

      "text": "Хочу уточнить статус заказа."

    }

  ]

}

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