Статья создана

15 минут на прочтение

Обновлена 16 декабря 2025 г.

Транскрибация видео с корпоративных совещаний. Как работают системы распознавания речи на примере платформы Таймлист

Главная

→

Блог

→

Транскрибация видео с корпоративных совещаний

Технологическая база распознавания речи

Когда мы начинали работу над платформой Таймлист, оказалось, что базовые технологии транскрибации далеки от идеала в корпоративной среде. На первый взгляд всё просто: берём высокотехнологичную модель распознавания речи (например, Whisper от OpenAI) и пускаем её на запись совещания. Но в реальности все намного сложнее, если задача не просто транскрибировать видео или аудио в текст, а получить качественную расшифровку совещания, которую будут читать сотрудники и использовать в работе для протоколов и корпоративных отчетов.

Во‑первых, корпоративные записи часто хранятся под жесткой защитой-отправлять конфиденциальные данные в публичное облако в большинстве организаций запрещено. Мы сразу поняли, что сервис должен уметь работать on-premise, то есть полностью внутри сети компании. Это означает, что модели распознавания (особенно большие и требовательные по ресурсам, как Whisper) приходится запускать на внутренних серверах. А это требует либо мощного железа (GPU), либо тщательной оптимизации. Железо под ИИ в организациях в основной своей массе отсутствует, поэтому путь на оптимизацию – тернистый, но необходимый.

Во‑вторых, сами аудиозаписи корпоративных встреч очень отличаются от бытовых диалогов. Часто совещание записывается через два канала - на микрофоны комнаты и на микрофон удалённого участника. Кроме того, на фоне звучат шумы офисов, уведомления, музыка на звонках. Стандартная модель распознавания не «понимает» эти особенности: она пытается перевести всё подряд в текст, даже если микрофон ловит эхо или фоновые звуки. Мы тестировали Whisper и другие ASR-модели, и заметили: если аудиофайл не соответствует формату (например, неправильная частота дискретизации или неожиданный кодек), распознавание срывается. Пришлось добавить конвертацию разных форматов (mp3, wav, mp4 и др.) в единый стандарт, чтобы модель хотя бы «чистый» звук слышала.

В-третьих, корпоративные записи часто неидеальны: разговоры с бизнес-жаргоном, массивные названия продуктов, собственные аббревиатуры. Whisper изначально обучался на огромном количестве разнообразной речи в интернете, но даже он «спотыкается» на специфической лексике компании. Мы убедились: когда в записи появляются названия внутренних проектов, модели не хватало таких слов в обучении. В результате «из коробки» мы получали не разумные варианты, а не нужные термины. И, конечно, приходилось учитывать вычислительные задержки и нагрузку: называть сервис простым «нажимая кнопку – получаешь протокол» - это миф. Каждый компонент (speech-to-text, сегментация, диаризация) требует тонкой настройки и иногда больших доработок.

Задачи перевода аудио в текст, которые нам пришлось решать

1.     STT (speech-to-text) - сделать из аудио текст (распознавание речи).
2.     TTS (text-to-speech) - преобразовать текст в речь.
3.     Audio classification - классифицировать звук. Это когда мы на похожих аудио выделяем паттерн или группу определённых звуков. Например, можно по пению птицы узнать её вид.
4.     Source Separation - разделить звуки по источникам. Например, когда играет оркестр и нужно выделить какой-то конкретный инструмент.
5.     Diarization - разделить диалог на речь отдельных спикеров.
6.     Voice Activity Detection - определить наличие речи на каком-то участке аудиозаписи.
7.     Audio Enhancement - улучшить качество звука.

В русскоязычном сегменте интернета не так много информации о том, как устроены системы распознавания речи.

Как работают системы распознавания речи

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

1. Зависимость от:

разные дикторы;
«акустический» канал записи звука: кодеки, искажения;
разное окружение: шум в телефоне, в городе, фоновые дикторы;
разный темп и подготовленность речи;
разная стилистика и тематика речи.

2. Большие и «неудобные» наборы данных.
3. Не всегда интуитивно понятная метрика качества.

Метрика качества

Качество распознавания измеряется по метрике WER (Word Error Rate):
1) Insertions - вставки слов, которых нет в исходной аудиозаписи.
2) Substitutions - замены слов на некорректные.
3) Deletions - система слово не распознала и сделала пропуск.

Небольшой пример расчета.

Исходные данные:
Стационарный (неразборчивая речь) телефон зазвонил поздней ночью.

Гипотеза:

Стационарный синийi айфонs прозвонилs поздней ночью.
WER = 100*(1+2+0)/5 = 60% (т.е. ошибка равна 60%).
При этом есть как простые заблуждения при подсчете метрики, так и более сложные.

Пример простых заблуждений при подсчете метрики:

Е/е с точками. Система переводит речь в текст и везде использует букву Е без точек, в то время как эталон, с которым сравнивается транскрипция, содержит Е с точками. Это неправомерно увеличивает количество Substitutions и увеличивает WER на 1%;
разное написание таких слов, как алло, але, алле и т.д.;
строчные и заглавные буквы;
усреднение по текстам, а не подсчет общего количества слов. Бывает, что в одном тексте WER 0,6, в другом 0,5, а в третьем - 0,8. Неверно будет вывести WER как среднее арифметическое из этих значений. Правильнее -подсчитать общее количество слов на всех текстах и на основе этого рассчитать WER. Более сложные заблуждения могут быть вызваны тем, что на разных тестовых выборках WER будет разным. Иногда на одной конкретной аудиодорожке испытываемое решение работает лучше или хуже, чем решения конкурентов. Но делать из этого общий вывод о качестве работы решения - некорректно. Необходимы результаты на большом объеме данных.

Типы систем распознавания речи

Системы распознавания речи бывают двух видов - гибридные и end2end.

End2end переводят последовательность звуков в последовательность букв.

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

Галлюцинации моделей на специализированной лексике и пути их устранения

Одна из главных проблем, которую приходилось решать Таймлист - это борьба с галлюционациями в базовой модели. Упрощённо говоря, нейросеть подменяет незнакомые ей слова похожими по звучанию. Помню случай: на одной технической встрече обсуждался «серверный GPU H100», а в результатах распознавания это превратилось в «эй сто» или «эйч сто». То же случилось с названием медицинского препарата - вместо слова модель выдала набор бессмысленных звуков. Это типичная «игра в испорченный телефон»: к концу расшифровки смысл был искажён, и ключевая информация терялась. Похоже, что на обычной речи WER (процент ошибок на слово) был относительно низок, но как только разговор уходил в узкопрофильную тему, он резко вырастал.

Мы осознали: нельзя просто взять базовую модель, например, и рассчитывать на стопроцентную точность в бизнес-задачах. Чтобы с этим справиться, мы организовали дообучение модели на наших данных. Сначала собрали собственный датасет: записи корпоративных совещаний, интервью с сотрудниками и их дословные расшифровки. Затем провели тонкую настройку (fine-tuning), добавив пару сотен часов специфической речи. Благодаря этому почти исчезали грубые замены терминов. Ещё мы применили «инъекцию знаний» - добавляли в аудио шум, имитировали разную громкость и акценты, чтобы модель стала стабильнее на реальных записях.

Команда Таймлист ввела предобработку аудио - детектирование активности речи (VAD) с отбрасыванием длинных пауз и нормализацию звука. Вычищать шум и выравнивать громкость помогают готовые модули аудио-препроцессинга. Также в систему встроили пост-фильтры: одни и те же «малозвучные» слова, предсказанные на пустых фрагментах, просто удаляют. Важным приёмом стало фрагментирование «по громкости»: например, зная, что модель галлюцинирует на тишине, Таймлист разрезает поток в предсказуемых местах (падение амплитуды) и перезапускает базовую модель ИИ на каждом чанке. Это помогло избежать повторов, хотя полностью «убрать» галлюцинации не получилось.

Практика показала: что после обучения обычно появляются дополнительные галлюцинации, например, если на записи щелчки или какие-то шумы, то модель может выдавать слова и даже целые предложения, которых не существовало. Из-за чего приходится прибегать к постообработке дообученной модели. И только после этого процент ошибок на технических терминах снижается примерно в 2–3 раза. Разумеется, модель всё ещё ошибается - мы это признаём честно - но ошибки стали менее «фантазийными» и более похоже на реальные слова. Это помогает системе лучше угадывать редкие названия. В итоге сочетание наших данных и дополнительных правил позволило сделать распознавание терминов гораздо более качественным.

Схема работы ASR

Сегментация аудио: потоковая обработка и задержки

Одна из ASR, моделей, используемая в Таймлист, рассчитана на фрагменты ~30 с, и, если скармливать ей слишком короткое аудио, точность падает. Поэтому команда ввела ручное чанкирование: объединять запись в 20–30-секундные фрагменты, чтобы модель использовала окно эффективно. Но это привело к задержкам: при реальном совещании протокол получается «с отставанием» на эти же 20–30 с. Компромисс нашли путем настраивания длины чанков и перекрытия. При этом Таймлист отказался от идеи трансляции одного долгого потока в модель, вместо этого голосовое событие распознаётся пачками, как описано выше. Более того, модель ИИ сама умеет разбивать аудио на сегменты, но команда обнаружила «подводный камень»: она может неожиданно«переключиться» на другой язык или начинать зацикливаться на одном слове. Это заставило строго контролировать разбиение и добавлять меры безопасности (например, искусственные «заглушки» фраз перед конвертацией).

Входные и выходные форматы данных

Корпоративный сервис транскрибации должен принимать самые разные форматы и выдавать удобные результаты. Сразу выяснилось: пользователи загружают аудиофайлы и видео самых разных типов. Популярны MP3 и WAV, но часто это оказывается видеозапись собрания (MP4), запись конференц-звонка (например, файл Zoom) или даже файл с несжатым PCM. Поначалу мы поддерживали только базовые форматы, и несколько раз сталкивались с тем, что запрос пользователя завершался с ошибкой из-за неподдерживаемого кодека. Придётся добавить конвертацию.

Например, один клиент прислал нам файл в формате AAC (часто используют в Mac) - наша система сначала его не «понимала». Мы узнали, что многие записывают встречу на iPhone или в Teams, и файл там может иметь расширение M4A или M4V. После этого мы сделали внутреннюю обёртку: любой входной формат предварительно перекодируется в стандартный WAV с нужной частотой, а потом идёт в распознавание. Конечно, такая конвертация добавляет время, но без неё не распознаешь корректно.

Таймлист пришлось учить систему «понимать» всё это. Первым этапом любой записанный файл автоматически конвертируется в стандартизованный WAV 16 кГц (моноканал). Затем аудио фильтруется: удаляется фоновый шум, нормализуется громкость. Такая унификация облегчает дальнейшую обработку. Гибридные системы записи (несколько микрофонов, веб-камеры, записи удалённых участников) приводили к перекрытию каналов и эхопотокам. Команда заметила: open source модели из интернета плохо «делят» смешанный звук. Поэтому для гибридных встреч Таймлист использует дополнительные правила: например, если в одной комнате есть микрофон, они пытаются отделить локальную и удалённую речь через VAD/AGC или даже используя API конференц-системы (которые часто могут вернуть тайм-коды речи каждого участника). Любые сторонние инструменты требуют on-premise-деплоя. Таймлист полностью отказался от сторонних облачных API: из соображений безопасности и конфиденциальности они запускают модели только локально, «за фаерволом». Это сильно усложнило инфраструктуру: теперь нужны GPU/серверы внутри компании, и часть усилий ушла на разворачивание контейнеров и организацию очередей задач.

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

Формат текста транскрипта: читабельность и разметка

Получив текст из нейросети, мы поняли: его нужно привести в удобную форму, иначе обычный plain text как «стена слов» окажется мало пригодным для бизнес-протоколов.

Во-первых, у заказчиков требовался структурированный вывод: разделение по спикерам, хронология событий, пометка решений и задач. Голый текст без временных меток трудно «сверять» с видео или аудиозаписью.

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

В первой версии Таймлист результат выводился как один сплошной абзац - огромный блок слов без знаков препинания. Отзыв сотрудников был прост: «Невозможно читать». Поэтому мы добавили автоматическую пунктуацию и разбиение на предложения.
Таймлист ввёл собственный формат протокола: каждое высказывание оформляется по шаблону [время начала -время конца] (Имя Спикера): текст. Такой формат позволяет при необходимости быстро перемещаться по запись, автоматически собирать повестку и вопросы. Для тех, кому нужен «сырой» текст, система всё же предоставляет и его, но в большинстве случаев коммерсы заказали интеграцию через JSON-документ с полями speaker, time_start, time_end, text. Наша система научилась определять паузы и вставлять точки, а также. Разделяет реплики спикеров по смысловым абзацам.

Кроме того, мы внедрили разметку спикеров. На выходе указываем, кто что говорил: «Игорь: …», «Дина: …». Это сильно повышает читабельность. Пользователи стали быстрее ориентироваться в тексте и легко копировать нужные фразы вместе с атрибуцией. Пример: в одном протоколе у нас была длинная дискуссия, а документ выглядел разбитым на краткие фрагменты с именами участников - это значительно упрощает проверку информации.
Также мы предусмотрели выделение ключевых моментов. Таймлист автоматически подсказывает, где приняты решения или сформулированы задачи. В тексте появились метки типа «Задача: …», «Решение: …» - они автоматически распознаются по контексту. Конечно, полностью автоматически точный протокол никак не заменить, но такая разметка помогает сконцентрироваться на сути.

Наконец, мы обратили внимание на форматирование для «копируемости». Обычные транскрипты могут получиться неудобно при вставке в документы - длинные строки, нет переносов. Мы ввели переносы по словам, предусмотрели нормальный шрифт и отступы, чтобы при копировании текст не слетал в одну непрерывную строку. Таким образом пользователи могут брать любой абзац и вставлять его в отчёт без лишних правок. Мы даже сделали экспорт в Word-формате: там отдельными стилями отмечены заголовки (дата встречи, название проекта), диалоги и итоги. Всё это - требования, которые стали понятны на практике.

Формирование именно структурированного и помеченного протокола оказалось ключевым отличием Таймлист от «просто ещё одного ASR-сервиса». Фрагмент протокола совещания с метками времени и именами спикеров (пример из внутреннего проекта ТаймЛист). Формат позволяет быстро найти нужный фрагмент в записи.

Готовые решения (Voice Activity Detection) часто не справляются с некачественным или нестандартным звуком. Приходится либо доучивать свою модель, либо использовать более продвинутые методы, что добавляет сложности в пайплайн.

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

Но тут свои грабли:

Контекст. LLM имеют ограничение на длину входного текста. Длинную расшифровку приходится резать на части, теряя общую связность.
Качество саммари. Оно очень субъективно. Какие метрики использовать? ROUGE- технический, но не всегда отражает полезность для человека.
Извлечение структурированных данных. «Вытащить все задачи» - звучит просто. Но в живой речи задачи формулируют по-разному: «Максим, разберись», «Надо бы к пятнице подготовить отчет», «Давайте это в приоритет». Научить модель стабильно это находить - отдельный проект.

Диаризация и сегментация аудиоданных

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

В реальных совещаниях часто говорят сразу несколько человек, пересекаются голоса, появляются пересвисты и эхо. Некоторые популярные ASR модели сами внутри предсказывают токен «смена говорящего», но его нельзя считать надёжной diarization-системой.

Адаптация ASR модели для корпоративного контекста

Таймлист изначально брала ASR-модель «из коробки», но быстро настроила гиперпараметры и обучила на профразах компании. Например, в базовой модели был параметр initial_prompt, позволяющий задать специфическую лексикографию проекта. Команда заполнила его частыми терминами из переговоров (брендовыми названиями, именами, служебными сокращениями), чтобы модель не «галлюцинировала» их. Установка точного language и использование condition_on_previous_text=True для учёта контекста предыдущих чанков позволила снизить логические ошибки. Во многих случаях Таймлист дополнительно тонко-тюнингует ASR-модель на «озвученных» протоколах из своей базы (фраз с корпоративным жаргоном) - так постепенно адаптировали модель под корпоративный сленг. Для ускорения работы применяют более лёгкие ASR-модели. Исследования показывают, что даже уменьшенная модель может выдавать близкую к качеству транскрипцию при хорошей акустике, и в Таймлист сделали на этом ставку, чтобы транскрипция была оперативной без потери качества.

Команда Таймлист проверила стандартные библиотеки: Pyannote-Audio (наиболее известная) требовала дообучения на корпоративных данных, IBM Watson или Azure часто «сливали» два близких голоса в один. На практике они выявили несколько принципиальных сложностей:

Перекрывающаяся речь. В офлайн-диаризации есть понятие overlap, но в реальном времени без меток многомикрофонной записи распознавать пересекающиеся голоса почти невозможно. Таймлист старается минимизировать перекрытие голосов по времени (когда слышен хор, переносит фрагмент на отдельный тракт).
Гибридные встречи. Если в офисе есть микрофоны, а кто-то подключается удалённо (по Zoom/Teams), то их голоса смешиваются. Команда вручную привязывала аудиодорожки конференций: например, получали двунаправленную запись Zoom (зеленый и красный каналы) и распределяли её по источникам. Простых библиотек для такой аудиомикшированной diarization нет - приходилось самим сопоставлять локальные и удалённые каналы по временным меткам и привязкам аккаунтов.

Пример работы диаризации: два спикера (СПИКЕР 1, СПИКЕР 2) чередуются по времени. В реальности Таймлист заменяет метки номерами на настоящие имена

Процесс такой:

Отдельная модель решает задачу предсказывания следующего спикера. Это позволяет нам удобно задизайнить собственную диаризацию.
Далее мы делаем voice embeddings (эмбеддинги голоса) из каждого чанка и кластеризацию. В задачах обработки речи существует несколько подходов к извлечению признаков. Одним из них является получение мел-частотных кепстральных коэффициентов (Mel Frequency Cepstral Coefficients).

Исходный сигнал нарезают на фреймы длиной 16-40 мс. Далее, применив к фрейму окно Хемминга, делают быстрое преобразование Фурье и получают спектральную плотность мощности. Затем специальной «гребёнкой» фильтров, расположенных равномерно по мел-шкале делают мел-спектрограмму, к которой применяют дискретное косинусное преобразование (DCT) - широко используемый алгоритм сжатия данных. Полученные таким образом коэффициенты представляют из себя некую сжатую характеристику фрейма, при этом, поскольку фильтры, которые мы применяли, расположены были в мел-шкале, коэффициенты несут больше информации в диапазоне восприятия человеческого уха. Как правило, используют от 13 до 25 MFCC на фрейм. Поскольку помимо самого спектра индивидуальность голоса формируется скоростью и ускорениями, MFCC комбинируют с первой и второй производными.

Нам нужно понять, кто говорит в каждой части встречи. Мы это делали так: разбивали аудио на короткие фрагменты (например, по 20 мс), извлекали для каждого «характеристики голоса» (MFCC, LPC или современные эмбеддинги) и пытались сгруппировать фрагменты по голосам и пробовали подходы с гауссовыми смесями (GMM) и универсальной фоновый моделью (UBM) с последующей адаптацией под говорящих (MAP), как описано в некоторых исследованиях. Также использовали спектральную кластеризацию. На тестовом интервью (двое участников) система в целом работала: распределяла сегменты на двух людей.
Вообще, MFCC - это самый распространённый вариант работы с речью, но помимо них существуют и другие признаки - LPC (Linear Predictive Coding) и PLP (Perceptual Linear Prediction), а еще иногда можно встретить LFCC, где вместо мел-шкалы используется линейная.

Однако при реальных записях возникаю сложности. Самый частый - одновременная речь. Если двое говорят «нахлёстом», наши алгоритмы часто путались: такой фрагмент мог оказаться неактивным (потому что несколько голосов) или отнесён к кому-то неправильно. В итоге такие фрагменты выпадали или оказывались «серой зоной». Пример: в одном совещании выступал ведущий, ему постоянно прерывали разные участники. В результате автоматическая диаризация не смогла чётко различить их фразы и смешала несколько слов одного с другим.

Другой нюанс - разное качество каналов. Гибридные встречи (часть людей в зуме, часть в офисе) сделали задачу ещё сложнее. Запись, которую мы получили, оказалась стереофонической: левый канал - звук из комнаты (с микрофона спикеров), правый - звук звонка (удалённый спикер). Мы сначала запустили модель на обоих сразу, и получилось «двойное» распознавание одного и того же слова. Пришлось вручную разделять каналы и последовательно подавать их на ASR, а потом синхронизировать текст.

Ещё одна проблема - сегментация (разбиение на отрезки) перед распознаванием. Мы внедрили VAD (обнаружение голоса) с помощью WebRTC, чтобы автоматически выделять фрагменты речи. В общем случае это работает: пауза - сегмент кончился. Но в офисе бывают короткие фразы, которых VAD не замечает, или мелкие шумы, которые он воспринимает как речь. Иногда слово обрывается посередине фрейма. Мы сталкивались с ошибкой, когда одна фраза разбивалась на два кусочка: одна с окончанием слова, другая - с началом следующего. Тогда модель выдавала неполное слово, и мы теряли смысл фразы. Чтобы исправить, пришлось тонко подбирать порог VAD и ставить минимальную длину сегмента.

Современные подходы к диаризации предлагают нейросетевые методы: например, извлекать эмбеддинги (x-vector) и кластеризовать их, или вовсе использовать end-to-end архитектуры для всех задач сразу. Мы экспериментировали с такими системами, но они требовали больших ресурсов и надёжных данных. Их точность выше, чем у простого GMM, особенно если нужно распознавать голоса незнакомых людей. Впрочем, и эти системы не панацея - например, какая-то популярная гибридная диаризационная система всё равно рассинхронизирует перекрывающуюся речь.

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

Таймлист неоднократно проверяла, что «собрать всё из коробки» не выйдет. Стандартные решения не рассчитаны на тонкости корпоративного кейса. Например, Whisper-next_speaker внутри не даёт сразу тайм-коды кластерам, поэтому Таймлист написала скрипт для выравнивания результатов распознавания и диаризации по времени. Pyannote из коробки плохо справляется без адаптации: один разработчик ТаймЛист заметил, что даже простая запись с двумя спикерами выдаёт одним «Speaker_00». А готовые ASR-либы (Google, Azure) нельзя деплоить on-premise или тонко настраивать. Поэтому пришлось вносить серьёзные правки: внедрять «горячую» инжекцию своих фильтров шумов, перекомпилировать некоторые модули под наши нужды, писать собственные «ворота» для сохранения тайм-кодов и метаданных. Каждый модуль - от VAD до языка-нейросети - дорабатывался вручную. Как правило, такой объём интеграции требует инженеров, которые понимают, что внутри делают модели, а не только «нажать кнопку», - и ТаймЛист поняла это по опыту.

Из всех подходов в Таймлист нашли «рабочими» два основных.

Во-первых, собственная кластеризация эмбеддингов голоса, получаемых от каждого чанка. ASR-модель при транскрибации с настроенным word_timestamps=True выдаёт эмбеддинг на каждое слово, и их можно усреднить в фрагмент. Затем применяется алгоритм кластеризации (например, agglomerative clustering или k-means). Так команда получала метки фрагментов, после чего в них просто объединяли слова и помечали спикера. Этот подход помогал разнести голоса, если они достаточно различимы по тембру.

Во-вторых, Pyannote-Audio в режиме «speaker-diarization» с предварительным fine-tuning под вэйв-файлы Таймлист давал приемлемую базовую разметку (но, как выяснилось, не всегда корректную). Обычная Pyannote-система нередко склеивала всё как одного спикера. Поэтому ее результаты Таймлист использовали только в связке с собственным алгоритом: если Pyannote выделял несколько turn’ов одного «Speaker_00», команда отправляла их на дополнительную кластеризацию. При тестах выяснилось, что на коротких записях и при двух говорящих Pyannote уже годится «как есть» - этому способствует дообучение на реальных шумных корпоративных записях. Но на длинных совещаниях с четырьмя участниками потребовались гибридные методы, например использование GMM-UBM (классический метод диаризации) и VB-HMM-кластеризации, в том числе и в экспериментальном режиме.

Саммаризация

На этапе саммаризации у нас есть информация о том, что говорил каждый спикер. Эту информацию необходимо передать в большую языковую модель (LLM). Но из-за ограниченного input-контекста LLM мы не всегда можем передать всё, поэтому нужно разрезать текст на небольшие фрагменты, стараясь при этом сохранить суть абзаца в пределах одного чанка (использовать семантическое разбиение).
Каждый чанк отправляется в LLM с системным запросом на саммаризацию. Затем собираем все саммари и просим LLM сделать на их основе одно общее.
На выходе мы получили полную стенограмму (расшифровку) аудио.

Метрики

Мы отслеживаем три основных показателя:

Транскрибация: измеряем WER (Word Error Rate, процент ошибок на уровне слов) и CER (Character Error Rate, процент ошибок на уровне символов). Пример: есть предложение: «Маша ела кашу». Попробуем транскрибировать его с ошибкой в первом слове: «Маши ела кашу. В этом случае WER = 1/3, так как одно слово из трёх транскрибировано неверно. CER при этом будет равен 1/12.
Саммаризация: используем метрику ROUGE-N, где N означает N-грамм - это скользящее окно по символам или словам. Пример: для фразы из предыдущего примера про маму при размере N-граммы 2 мы получим три N-граммы: МА, АМ и МА. При размере N-граммы 3 получим две N-граммы - МАМ и АМА. Таким образом, у нас есть эталонная саммаризация, которую сделали асессеры, заказчики или даже мы сами. Мы только меряем пересечение N-грамм между сгенерированной и эталонной саммаризацией.
Классификация (для идентификации): используем стандартные метрики F-score, accuracy, precision и recall.

А что на выходе?

Текст в Блокноте никому не нужен. Допустим, мы чудом решили все предыдущие проблемы. Распознали, разделили. Что мы даем пользователю? Сплошная простыня текста с таймкодами - это не продукт, это сырые данные. Это неудобно.

Что нужно:

Четкая визуальная сегментация. Каждая реплика - отдельный блок. Хорошо, если с аватаром или инициалами спикера.
Копируемость. Пользователь должен иметь возможность легко скопировать один ответ, абзац или весь текст целиком, не прибегая к форматированию.
Таймкоды-ссылки. Кликнул на время - аудио/видео перемоталось на этот момент. Это базовое удобство для проверки.
Поиск по тексту. Обязательно. И не только по словам, но и, возможно, по спикерам.
Экспорт. В DOCX. Причем с сохранением разметки.
Вывод в обычном текстовом редакторе без этого - это полуфабрикат, который ещё придется долго обрабатывать вручную. А цель-то как раз в экономии времени.

Иллюзия «готовых решений на коленке»

В процессе разработки мы убедились: нельзя просто «склеить» несколько готовых библиотек и получить готовый продукт. Такое впечатление, что сервис можно собрать за вечер - установить Whisper, подключить модуль диаризации и выдавать текст. На деле, если цель – сделать продукт, а не «прототип на коленке», то приходится делать большой пазл из большого количества кусочков.
В одном случае мы интегрировали популярный модуль для перевода аудио в текст, думая сэкономить время. Но после нескольких часов тестов выяснилось: он отлично работает на стандартизированных записях, но абсолютно «фейлится» на живых звонках. Например, при разной громкости в каналах он часть фразы терял. Пришлось отказаться от готового скрипта и написать свой процесс-менеджер, который дробит запись и подаёт в ASR фрагмент за фрагментом.

Всё это привело к пониманию: нужен не просто «шейкер» из модулей, а тонкая инженерная работа. Легко представить: «мы используем открытые решения, так это быстро!» Но сколько скрытого кода и настроек требуется - недооцениваем обычно. Мы учились на собственных ошибках: потратили месяцы на попытку подключить один диаризатор, а потом сделали проще - реализация с базовым VAD и небольшим кластером дала примерно такую же точность на наших записях.

В итоге проект Таймлист воплощает идею ready-made click-en-transcribed (готовый текст с расшифровкой пощелчку мыши), но этот (готовый…) появился после огромной проделанной работы. Сейчас, конечно, нам проще, потому что часть кода уже написана и отлажена. Но первые версии продукта были настоящим «студенческим проектом», полный компромиссов. Из этого опыта выросла важная мысль: критически важно тестировать каждую «коробочку» на реальных данных. Только так можно избежать сюрпризов на продакшене.

Внутренняя конкуренция и командная работа

Над разработкой Таймлист работала не одна голова, и внутри команды иногда возникали разногласия. Иногда казалось, что есть несколько «рабочих групп» в одной команде. Кто-то предлагал сосредоточиться на новых функциях, другие - на глубоком улучшении текущей технологии. Например, один из разработчиков настаивал: давайте перепишем весь движок диаризации на другую библиотеку. А продакт-менеджер под давлением руководства хотел «быстрей выпустить», пока конкуренты не обогнали. В такие моменты проект замедлялся.
Мне запомнился эпизод: мы долго спорили, какую часть обработчика сборки использовать - тот, который лучше зарекомендовал себя на публичном датасете, или тот, который более привычен нашему DevOps. В результате мы протестировали оба варианта на реальных записях Таймлист и убедились: формально выигрыш был у одной, но она давала сбои в продакшене. Уступили: выбрали надёжность над «круче-мудрённее».

Команда вышла из этого за счёт прозрачной приоритизации задач и так называемого «конкурентного программирования» (когда разные участники пилят аналогичные фичи и выбирают лучшее). Проект развернул технические митинги, где каждый представлял прототип своих разработок.

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

Через эту борьбу мы поняли: без дружной работы и разделения ролей выпустить продукт невозможно. Каждый в команде - и программист, и дата-инженер, и тестировщик - должен идти навстречу друг другу.

В конечном счёте мы (команда IT-специалистов Таймлист) научились учитывать все вызовы: от технических (специфика речевого ввода, качество аудио, вычислительные ресурсы) до организационных (сроки, внутренняя конкуренция за время разработчиков). Открытость и честность помогли нам решить многие вопросы. Например, мы фиксировали список известных ошибок и регулярно устраивали митинги для обмена опытом. Благодаря этому продукт постепенно становился стабильнее: мы перестали удивляться, почему на одной встрече всё прошло гладко, а на другой - «сбой», а просто находили корень проблемы и исправляли его.

Вывод

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

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

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

Так что же в итоге?

Чтобы сделать качественный продукт для корпораций, нужно отвечать на неудобные вопросы и решать инженерные, а не только научные задачи:

1.     Как дообучать модель на своей терминологии, минимизируя «галлюцинации»? Вероятно, нужна комбинация осторожного дообучения, создания специального словаря и пост-обработки правилами. Скорее всего, гибридный же подход: для онлайн-участников использовать метаданные (если есть), для офлайн-группы - современные нейросетевые методы, а потом сшивать логику.
2.     Какой вывод будет удобен? Нужно проводить UX-исследования с реальными секретарями, проектировщиками, менеджерами. Их рабочий процесс диктует требования.
3.     Какие форматы поддерживать в первую очередь? Самые популярные (MP3, WAV, MP4, Zoom-выгрузки), но архитектура должны быть расширяемой.

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

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

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

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

Сейчас Таймлист продолжает улучшать модели - в том числе экспериментирует с новыми вариантами диаризации (например, голосовые сети с перекрытием) и обучает ASR-модель на корпоративных данных. Ближайшее направление- интеграция моделей распознавания для групп поддержки (чтобы звонки колл‑центра обрабатывались тем же ядром) и расширение голосового банка сотрудников для более надёжной идентификации. Но главное достижение – это понимание, что «идеального» тулкита не существует. Таймлист учится соединять кусочки: комбинировать open-source, настраивать гиперпараметры, придумывать собственные инженерные патчи. Такой гибридный подход, подкреплённый честной оценкой ограничений технологий, на пути, полном граблей и сложных выборов, и рождаются продукты Таймлист, которые действительно меняют работу к лучшему, а не просто становятся ещё одной строчкой в списке корпоративных подписок.

Оставить заявку