Как разделить расшифровку по спикерам: диаризация Whisper и готовое решение через API

Вы загрузили запись разговора в 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 <NA> <NA> speaker_0 <NA> <NA>
SPEAKER call_102 1 6.00 3.10 <NA> <NA> speaker_1 <NA> <NA>

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

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

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

{
  "dialogue": [
    {
      "speaker": "Менеджер",
      "start": 0.5,
      "text": "Добрый день. Чем могу помочь?"
    },
    {
      "speaker": "Клиент",
      "start": 6.0,
      "text": "Хочу уточнить статус заказа."
    }
  ]
}

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

Как получить расшифровку с разделением спикеров через Speech2Text

Вместо самостоятельной настройки Whisper, pyannote.audio, VAD и сопоставления интервалов можно передать запись в Speech2Text и получить готовый результат с диаризацией.

Сценарий обработки выглядит так:

  1. Аудио или видео отправляется в сервис.
  2. Система распознает речь и определяет границы реплик.
  3. Фрагменты распределяются между спикерами.
  4. Результат возвращается в виде структурированного текста.
  5. Расшифровку можно использовать в интерфейсе, выгрузить или передать в другую систему.

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

Для интеграции используется Speech2Text API. Через него можно автоматизировать обработку записей из АТС, CRM, личного кабинета, облачного хранилища или внутренней системы компании.

В прикладном сценарии процесс выглядит так:

Запись звонка из АТС
|
v
Speech2Text API
|
v
Диалог со спикерами и таймкодами
|
+--> CRM
+--> контроль качества
+--> резюме разговора
+--> поиск возражений
+--> отчет по менеджеру

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


Попробуйте разделить расшифровку по спикерам бесплатно

Загружайте ваши файлы в один клик
Перетащите файлы сюда
или нажмите, чтобы загрузить
Загрузить файл

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

Качество исходной записи часто влияет на результат сильнее, чем замена одной модели на другую.

Используйте отдельные каналы, когда они доступны

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

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

Не перекодируйте запись несколько раз

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

Убирайте длинную музыку и служебные сигналы

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

Указывайте предполагаемое число спикеров

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

Проверяйте результат на собственных данных

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

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

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

Что выбрать: локальный стек или готовый API

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

Преимущества локального стека:

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

Вместе с этим команда берет на себя GPU-инфраструктуру, обновление зависимостей, мониторинг качества и обработку ошибок.

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

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

Расшифровка, с которой можно работать дальше

Сплошной текст подходит для хранения содержания записи, но почти не подходит для анализа разговора. Как только в аудио участвуют несколько человек, важно сохранить не только слова, но и структуру диалога.

Собственный пайплайн на Whisper, pyannote.audio или NeMo дает полный контроль, однако требует разработки и поддержки. End-to-end модели вроде VibeVoice ASR сокращают количество этапов, но также нуждаются в тестировании на реальных данных.

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

Подробности подключения доступны на странице Speech2Text API.

Частые вопросы

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

Обычная диаризация присваивает условные метки. Для имен нужны дополнительные данные: каналы АТС, список участников, голосовые образцы или ручное переименование.

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

Да. Это один из основных сценариев применения. При наличии раздельных каналов лучше использовать их как источник ролей.

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

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