Вы наконец записываете встречи через ИИ. Неожиданная проблема: он приписывает вам чужие слова

Недавно у нас был звонок-знакомство с новым потенциальным клиентом. С его стороны трое: основатель, операционный директор и менеджер по продажам. Все сидели в одной переговорке и зашли в Zoom с одного ноутбука. Сервис, который записывает и расшифровывает все наши звонки, выдал транскрипт, в котором эти три человека слились в одного «спикера» с названием компании вместо имени. А несколько их фраз он и вовсе приписал нам.

Дальше интереснее: из транскрипта автоматически собираются резюме встречи и список задач. Исполнителем задач стала «компания», а не конкретный человек. У нас такие заметки дальше уезжают в CRM и в таск-менеджер, и неверная атрибуция расползлась бы по всей системе: не тот человек в задаче, не та договорённость в карточке сделки. Один незаметный сбой на входе портит всю цепочку «звонок, транскрипт, резюме, CRM».

Мы разобрались, почему так происходит. Спойлер: это не баг, это механика, и о ней стоит знать каждому, кто записывает встречи через ИИ. Разбираем на примере Fireflies, одного из самых популярных сервисов записи, но логика касается и его аналогов.

Живой звонок и загруженный файл обрабатываются по-разному

Разделение записи по голосам называется диаризацией (нет, с диареей ничего общего: термин произошёл от английского diary, «дневник». Алгоритм как бы ведёт дневник звонка: кто и когда говорил. А та самая неприятность происходит от греческого «протекать насквозь», корни даже не родственники).

Документацией Fireflies подтверждено: живые звонки и загруженные файлы идут по разным конвейерам. Загруженный аудиофайл проходит настоящую акустическую диаризацию: сервис анализирует голоса и режет запись на Speaker 1, Speaker 2, Speaker 3, а имена вы проставляете вручную. В живом звонке с ботом реальные имена появляются только в Zoom и Google Meet, где бот присутствует как участник встречи.

Показательная деталь из той же документации: десктопное приложение Fireflies, которое пишет тот же самый звонок как системный звук (один смешанный аудиопоток, без данных платформы), имён не даёт. Только Speaker 1 и Speaker 2. Вывод: именованные метки берутся из данных платформы об участниках, а не из анализа голоса.

Это не баг: Zoom сообщает, кто говорит, по участнику, а не по голосу

Внутренний механизм Fireflies не опубликован, поэтому честно пометим: дальше обоснованное предположение, которое совпадает с наблюдаемым поведением и с общей практикой митинг-ботов. Платформа сообщает боту: «сейчас говорит участник с таким-то именем». У Zoom нет способа узнать, что за одним подключением сидят три человека. Для него это один участник с одним микрофоном, и бот добросовестно подписывает все реплики именем этого участника.

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

Как починить уже записанный звонок: два способа

Способ первый, обычно быстрее. Скачайте аудио звонка и загрузите его в Fireflies как файл. Загрузки всегда проходят акустическую диаризацию, и сервис разделит запись по голосам на Speaker 1, 2, 3. Дальше кликните по каждой метке, впишите реальное имя, выберите «Apply to all» и перегенерируйте заметки (меню из трёх точек, затем Regenerate notes), чтобы резюме и задачи пересобрались с правильными людьми. Если звонок записан в несколько частей, файлы сначала нужно склеить. В нашем случае это сработало: 46-минутная склейка двух частей разделилась по голосам корректно.

Способ второй: править метки прямо в исходном транскрипте, пофразово, через «Apply to current speaker». Работает, но на длинном звонке это десятки ручных правок. Мы сначала пошли этим путём и потратили время зря: перезагрузка аудио решила ту же задачу в разы быстрее.

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

Три правила, чтобы проблема не возникала

• Каждый участник заходит в звонок со своего устройства под своим именем. Единственное решение, закрывающее проблему полностью: у платформы появляется отдельный аудиопоток на каждого человека.
• Общая переговорка неизбежна? Не меняйте процесс записи. Пусть бот пишет как обычно, просто знайте заранее, что спикеры из переговорки слипнутся, и после звонка перезалейте аудио файлом, как описано выше. Отдельный диктофон имеет смысл только на полностью очной встрече, где онлайн-звонка нет вообще.
• Меньше перебиваний на важных звонках. Наложение речи остаётся слабым местом любой диаризации: и по документации, и по независимым тестам.

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

Что подтверждено документацией, а что нет

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

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

Мы в Laplas AI строим для клиентов AI-агентов и связки «звонок, транскрипт, резюме, CRM» и постоянно упираемся в такие особенности инструментов: половины из них нет в документации, их приходится находить на практике. Автоматизация, собранная без понимания этой механики, продолжает выглядеть исправной, хотя данные в ней уже некорректные. Если хотите, чтобы записи ваших звонков превращались в правильные задачи и документы, напишите нам в Telegram.