Локальная транскрибация и диаризация рабочих звонков

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

Транскрибация отвечает на вопрос «что было сказано», диаризация – «кто говорил в каждый момент». Бизнес-сценарий начинается после них: нужно связать вывод с клиентом, отделить факт от предположения и безопасно продолжить процесс.

Из каких этапов состоит обработка звонка

Одна модель редко закрывает всю цепочку. Рабочий процесс включает:

1. получение разрешённой записи;
2. проверку формата и качества аудио;
3. обнаружение участков с речью;
4. транскрибацию;
5. диаризацию спикеров;
6. согласование текста и таймкодов;
7. выделение структуры разговора;
8. сопоставление с карточкой CRM;
9. экран проверки;
10. подтверждённую запись и создание задач.

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

Транскрибация: текст и таймкоды

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

На качество влияют:

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

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

Диаризация: кто именно говорил

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

Открытые системы, например pyannote Community-1, поддерживают локальную обработку и публикуют долю ошибок разделения собеседников. Разброс между наборами данных показывает, почему качество нужно измерять на собственных записях, особенно при наложении голосов.

Ошибки диаризации:

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

Как из текста получить суть разговора

После распознавания AI получает не исходный аудиофайл, а текст с таймкодами и метками участников. Он заполняет заранее определённую структуру:

Тема разговора
Запрос клиента
Принятые решения
Обещания менеджера
Обещания клиента
Сроки
Следующий контакт
Предлагаемые задачи
Фрагменты-основания

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

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

Автозаполнение CRM и создание задач

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

Экран подтверждения показывает:

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

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

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

Что можно автоматизировать без подтверждения

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

Практичная граница первой версии:

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

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

Как измерять качество

Одна оценка «расшифровывает хорошо» недостаточна. Нужны показатели для разных уровней.

Для транскрибации распространён word error rate, для диаризации – diarization error rate. Но бизнес-ошибка может не совпасть с технической. Неверная запятая обычно безвредна, а одна ошибочная цифра в стоимости или сроке критична.

Поэтому тестовый набор должен отдельно содержать:

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

Хранение и доступ

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

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

Юридические основания записи и обработки разговоров зависят от процесса компании и должны проверяться отдельно. Локальное размещение само по себе не решает этот вопрос.

Когда сценарий подходит

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

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

Вывод

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

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