Pyannote — открытая библиотека для диаризации: она делит запись на отрезки и помечает, кто говорил в каждом, а сами слова оставляет другому инструменту. На выходе список с началом, концом и меткой вроде speaker_0, которую человек потом заменяет именем. Она годится для записей, которые компания вправе обрабатывать на своём компьютере или сервере, и рассчитана на сверку разметки человеком до того, как реплики попадут в протокол.
Что делает Pyannote
Pyannote возвращает отрезки времени с метками говорящих; текст расшифровки даёт отдельная модель, а имена участников подставляет человек.
Возьмём запись созвона с подрядчиком: двое сотрудников со своей стороны и двое со стороны подрядчика. Распознавание речи превращает звук в сплошной текст, и по нему видно, что было сказано, но разобрать, кто принял обязательство, уже сложно. Диаризация закрывает именно этот пробел: по голосам она отделяет одного говорящего от другого и отдаёт сегменты с временем.
В репозитории проекта описано то же самое: набор нейросетевых блоков для определения активности речи, смены говорящего, перекрытия голосов и эмбеддингов спикеров, а расшифровки речи в нём нет. Если вам нужна именно расшифровка, ориентируйтесь на статью про Whisper, а коммерческий вариант с готовой разметкой спикеров разобран в материале про AssemblyAI.
Для бизнеса из этого следует простая раскладка ролей. Pyannote отвечает за вопрос «чей голос», модель расшифровки — за вопрос «какие слова», а языковая модель получает уже собранные реплики и предлагает из них протокол. Каждый слой можно заменить отдельно: сменить распознавание речи, оставив разметку, или проверить разметку, оставив остальную цепочку нетронутой.
- Вход: аудиофайл записи. Конвертировать его вручную необязательно: по карточке модели многоканальный звук усредняется до моно, а частота приводится к 16 кГц при загрузке.
- Выход: объект с сегментами и метками, который сохраняется в формате RTTM или в таблицу.
- Чего в выходе нет: слов, имён и должностей участников.
Доступ и запуск
Модели Pyannote лежат на Hugging Face с условием доступа: пока условия на странице модели ждут вашего согласия, загрузить файлы нельзя. Токен нужен для загрузки весов, дальше разметка идёт на вашей машине, как сказано в карточке модели. Токен держите в переменной окружения сервера, а в код и репозиторий его класть нельзя.
- Создайте токен в настройках аккаунта Hugging Face и сохраните его в переменной окружения.
- Откройте страницу выбранной модели и примите условия использования; без этого загрузка вернёт отказ.
- Установите библиотеку и загрузите пайплайн вызовом
Pipeline.from_pretrainedс названием модели и токеном. В README репозитория актуальной названа модельpyannote/speaker-diarization-community-1, предыдущаяspeaker-diarization-3.1описана как прежняя версия. - Запустите пайплайн на файле записи и получите сегменты со временем и метками.
- Сохраните результат в RTTM рядом с исходной записью, чтобы разметку можно было открыть повторно.
По умолчанию пайплайн работает на процессоре, и для длинных записей его переводят на видеокарту через pipeline.to(torch.device("cuda")). Если число говорящих известно заранее, в карточках обеих версий есть параметры num_speakers, min_speakers и max_speakers: они сужают подсчёт и уменьшают ошибки вида «один человек разбит на двоих». Если вы переходите с 3.1 на community-1, сравните разметку на тех же записях: на странице community-1 заявлено лучшее определение числа говорящих, но свои записи проверяет человек.
Сшивка с текстом
Чтобы получить реплики с авторами, нужны два результата по одной записи: сегменты Pyannote и слова с отметками времени от модели распознавания. Скрипт сопоставляет их по времени: слово попадает к тому говорящему, чей отрезок накрывает его начало. Полные данные записи обрабатывает скрипт, модель дальше видит уже собранный текст реплик.
| Шаг | Что получаем | Кто отвечает |
|---|---|---|
| Диаризация | Отрезки со временем и метками speaker_N | Pyannote |
| Распознавание речи | Слова с отметками времени | Модель расшифровки |
| Сшивка | Реплики с автором по пересечению времени | Скрипт |
| Имена | Соответствие метки и человека | Организатор встречи |
| Протокол | Решения и поручения как предложение | Языковая модель, утверждает человек |
Результат удобно держать в таблице с колонками «начало», «конец», «метка», «имя» и «проверено». Колонку «имя» заполняет человек, колонку «проверено» ставит тот, кто прослушал спорные места. Тогда протокол собирается только из строк с отметкой, а спорные отрезки остаются на виду у организатора, до их разбора.
Имена участников подставляют двумя способами. Первый: организатор после запуска сопоставляет метки с людьми, прослушав по одной реплике каждого. Второй: скрипт берёт список приглашённых, а организатор подтверждает соответствие. Во втором случае ошибка повторится на каждой записи, если голоса двух участников похожи, поэтому подтверждение остаётся обязательным.
Реплики, где говорят одновременно, скрипт помечает отдельно: слова из такого места нельзя уверенно отнести к одному автору. Готовую схему сборки протокола вместе с доступом и правками описывает статья про транскрибацию встреч для команды; здесь важна только разметка по голосам.
Проверка смены спикеров
Типичные ошибки диаризации повторяются от записи к записи, поэтому проверку можно сделать регулярной. Сначала прослушайте места, где метка меняется, и оставьте запись целиком на потом: именно в этих местах ломается атрибуция.
- Короткие реплики вроде «да» и «согласен» часто приписываются соседу: слушайте их отдельно.
- Один человек может получить две метки, если менялась громкость или микрофон; двое похожих голосов, наоборот, склеиваются в одну.
- Смена говорящего посреди фразы чаще означает перекрытие голосов, и новой репликой её считать рано.
- Решения и поручения переносите в протокол только после прослушивания фрагмента, где они прозвучали.
| Симптом в разметке | Вероятная причина | Что делает человек |
|---|---|---|
| Лишняя метка в конце записи | Один голос разбит из-за смены микрофона | Объединяет метки в таблице имён |
| Две реплики под одной меткой | Похожие голоса или тихий второй участник | Прослушивает фрагмент и делит вручную |
| Реплика «да» у другого автора | Слишком короткий отрезок для оценки | Слушает фрагмент и правит автора |
Когда число участников известно, сравните его с числом меток в результате: расхождение сразу показывает, где разметку надо править руками. Именно с этой сверки проще начинать работу над новым типом записей, а разбор разных форматов встреч добавляйте после. Для записей из переговорной с одним микрофоном разметка может получаться хуже, чем для раздельных дорожек, поэтому тип записи фиксируйте в журнале рядом с результатом проверки.
Сколько говорящих обычно участвует в ваших записях?
Данные и границы
Голос участника — персональные данные, и запись встречи требует предупреждения участников и понятного срока хранения. Процессу достаточно хранить аудио и RTTM на своём сервере, а в языковую модель отправлять только сшитый текст, из которого убраны лишние персональные сведения. Права доступа к записям и протоколам проверяет сервер, а модель отвечает на вопросы только по переданному фрагменту и ничего в хранилище изменить ей нельзя. Если запись содержит сведения о здоровье, финансах или частной жизни, её исключают из автоматической обработки до решения ответственного за данные.
Разметка остаётся подсказкой, а подтверждает автора человек: если по протоколу кому-то поручили задачу, организатор встречи сверяет автора реплики с записью. Модель может ошибиться с границей отрезка, и тогда чужие слова оказываются приписаны сотруднику. Для регулярных встреч закрепите правило: протокол выходит с пометкой «разметку проверил» и именем проверяющего. Дальше этот процесс можно встроить в общую автоматизацию бизнес-процессов.
Возьмите одну запись с двумя-тремя говорящими, прогоните её через пайплайн и прослушайте каждую смену метки. Посчитайте, сколько границ пришлось поправить: эта доля решит, нужна ли ручная сверка на каждой встрече или хватит выборочной.