Введение
Знакомая ситуация: созвон закончился, всё обсудили, о чём-то договорились и разошлись работать дальше. А через пару дней начинается: «Подождите, а кто вообще должен был этим заниматься?» В лучшем случае у кого-то сохранились хаотичные заметки, в худшем - всё держится на человеческой памяти. А ведь встречи бывают не только онлайн, но и очные с десятком участников и часами обсуждений.
В компании Софрос мы столкнулись с этой проблемой в полный рост. Внутренние планёрки, встречи с клиентами, технические синхронизации - контекст терялся постоянно. Кто-то записывал аудио на телефон, кто-то конспектировал в блокноте, а потом всё это нужно было как-то собрать в единый протокол. На расшифровку часовой встречи вручную уходит около трёх часов - непозволительная роскошь, когда встреч десятки.
Так родился SOFROS AI Секретарь - система, которая автоматически превращает любую встречу в структурированный протокол с задачами и ответственными. Расскажу, как мы это сделали и что из этого вышло.
Проблема: контекст умирает после «Завершить звонок»
Встреча - это не просто разговор. Это:
решения, которые кто-то должен запомнить;
задачи, которые нужно кому-то назначить;
договорённости, которые легко забыть через неделю;
идеи, которые теряются в потоке речи.
Мы пробовали разные подходы. Диктофонные записи - расшифровывать их вручную долго и муторно. Стенографирование во время встречи - почти невозможно: человек говорит в три раза быстрее, чем мы печатаем. Полагаться на память - плохая идея.
Нужно было решение, которое:
записывает встречу (и онлайн, и офлайн);
расшифровывает речь и переводит в текст;
понимает, кто что сказал;
выделяет главное и формирует задачи;
делает всё это автоматически и быстро.
Решение: SOFROS AI Секретарь
Мы построили систему, которая берёт на себя всю рутину по ведению протоколов. Всё, что нужно пользователю - загрузить файл или вставить ссылку на видеоконференцию и дождаться готового протокола. Система автоматически:
расшифровывает речь (транскрибирует);
определяет, кто и что говорил;
выделяет ключевые темы;
формирует список задач и ответственных;
создаёт готовый протокол в форматах MD, DOCX, PDF.
отправляет сформированные файлы на электронную почту участникам рабочей группы проекта.
Но давайте по порядку.
Проекты: контейнеры для встреч
Первое, что мы сделали - ввели понятие проекта. Это контейнер, в котором хранятся все встречи, относящиеся к одной теме, команде, направлению или проекту внедрения.
Проект-контейнер позволяет:
группировать встречи по темам;
назначать участников, которые имеют доступ к встречам проекта;
указывать email группы для рассылки уведомлений.
Каждый проект имеет рабочую группу - список пользователей с доступом. Есть роли: Владелец (полный доступ), Участник (доступ к проекту, создание встреч, просмотр протоколов) и Администратор (глобальный доступ ко всем проектам). Любой участник рабочей группы может опубликовать встречу в проекте, и её результаты станут тут же доступны всем участникам проекта.
Важный нюанс: у каждого пользователя есть виртуальный проект «Проект не указан». Это автоматическая «корзина» для встреч, созданных без привязки к проекту. Встречи оттуда можно перетащить мышкой в любой другой проект.
Встречи: от загрузки до готового протокола
Создать встречу можно тремя способами:
нажать кнопку «Новая встреча» в верхней панели;
выбрать «Новая встреча» в меню проекта;
перетащить файл на карточку проекта.
Форма создания встречи позволяет загрузить контент одним из способов:
Файлы - аудио (MP3, WAV, OGG, FLAC, AAC, M4A, WMA, OPUS), видео (MP4, AVI, MKV, MOV, WMV, WEBM) или текстовые файлы (TXT, MD, JSON, MASHA, CSV). Можно загрузить несколько файлов - они склеятся в указанном порядке.
Ссылка - URL-адрес файла или ссылка на видеоконференцию (Zoom, Google Meet, Microsoft Teams и др.). Система автоматически определит источник.
Транскрипция - готовый текст расшифровки.
После загрузки встреча попадает в список со статусом:
В очереди - ожидает начала обработки;
Выполняется - идёт обработка (показывается процент и этап);
Завершено - протокол готов;
Ошибка - во время обработки произошла ошибка;
Остановлено - обработка остановлена вручную.
Гибкие пайплайны обработки
Одна из ключевых особенностей системы - гибкие пайплайны обработки. Мы не зашивали жёсткий алгоритм, а сделали возможность выбора схемы обработки в зависимости от типа контента и потребностей пользователя.
При создании встречи система автоматически определяет доступные схемы (пайплайны) в зависимости от типа загружаемого контента (файл/ссылка, аудио/текст). Пользователь может выбрать нужную схему из выпадающего списка. Если для данного источника доступна только одна схема, она будет выбрана автоматически.
Например, при выборе варианта «С исправлением ошибок» обработка займёт столько же времени, сколько шла встреча. Вариант «Без исправления ошибок» - в два раза быстрее. Это даёт пользователю гибкость: можно пожертвовать скоростью ради качества или наоборот.
В настройках встречи всегда можно посмотреть, какой пайплайн используется. А в чат-ассистенте отображается название текущего пайплайна, и если доступно несколько - их можно переключать прямо из интерфейса чата.
Протокол: всё, что нужно, в одном месте
Когда встреча завершена, пользователь видит страницу протокола со следующими секциями (их можно сворачивать и разворачивать):
Краткое содержание - основные итоги встречи.
Темы встречи - перечень обсуждавшихся тем с временными метками.
Задачи встречи - список задач с исполнителями, сроками и приоритетами.
Протокол совещания - полный текст протокола.
Транскрипция - полная расшифровка речи с временными метками, именами спикеров и кнопками воспроизведения для каждого фрагмента.
Каждую секцию можно скачать отдельно в форматах MD, DOCX или PDF. Аудиозапись доступна для скачивания из секции транскрипции.
Чат-ассистент: задай вопрос протоколу
Одна из самых востребованных функций - чат-ассистент. Справа от протокола находится панель чата, где можно задавать вопросы по содержанию встречи. AI-ассистент отвечает на основе данных из протокола и транскприпта встречи.
Например:
«Какие задачи были назначены Иванову?»
«Что решили по поводу бюджета?»
«Кто выступал за это решение?»
Ассистент использует данные из протокола, поэтому ответы всегда релевантны и точны. Также мы работаем над RAG-системой, чтобы в будущем стали возможны вопросы: «Кому и когда была поставлена эта задача? Была ли она выполнена?»
Доступна статистика запроса: нажмите на иконку в верхней части чата, чтобы увидеть метрики - количество отправленных/полученных токенов, скорость обработки (токенов в секунду), время формирования ответа, использованную модель и пайплайн. Это особенно полезно для технических специалистов, которые хотят понимать производительность системы.
Выбор AI-моделей: никаких ограничений
Мы понимаем, что разные задачи требуют разных моделей. Поэтому в SOFROS AI Секретарь пользователь может выбирать модель для работы с протоколом. В чат-ассистенте доступен выпадающий список с локальными и облачными моделями. Пользователь может переключать модели прямо во время работы - перед отправкой вопроса выбрать ту, которая лучше подходит для конкретной задачи. Это даёт возможность экспериментировать и находить оптимальный баланс между скоростью и качеством ответов.
Расширение для браузера: запись встреч локально
Для онлайн-встреч мы сделали браузерное расширение AI-ассистент секретаря (работает в Chrome, Edge, Яндекс.Браузере и других на базе Chromium).
Как это работает:
Устанавливаете расширение (загружается из личного кабинета на сайте сервиса).
Открываете вкладку со встречей (Zoom, Яндекс телемост, MS Teams).
Нажимаете кнопку «Запись» в расширении.
Расширение записывает аудио с активной вкладки, автоматически включает субтитры если они возможны, собирает транскрипцию с именами спикеров.
Останавливаете запись - файл автоматически уходит на сервер для обработки.
Важно: расширение работает локально - запись ведётся прямо в браузере, без передачи данных на сторонние серверы во время записи. Все данные отправляются только после остановки записи и только на ваш корпоративный сервер.
Расширение AI-ассистент секретаря автоматически останавливается через 4 часа (ограничение браузера). При закрытии браузера запись останавливается и загружается на сервер. Если сервер недоступен, файл сохраняется локально - можно загрузить вручную позже.
Публичная ссылка и отправка по email
Протоколом нужно делиться. Мы сделали две возможности:
Публичная ссылка - нажмите кнопку «Поделиться ссылкой», и система сгенерирует уникальную ссылку с защитным хешем. Ссылка действительна неограниченное время, показывает все секции протокола (включая транскрипцию и задачи), но скрывает кнопки управления. Аудиофрагменты доступны для воспроизведения даже без авторизации.
Отправка по email - кнопка «Email» открывает форму, где можно выбрать получателей (из списка участников проекта или ввести вручную), тему письма, формат вложений (PDF, DOCX или MD) и конкретные документы для отправки.
Фильтры, поиск и горячие клавиши
Когда встреч становится много, нужны удобные инструменты навигации. Мы добавили:
«Мои встречи» / «Доступные мне» - переключение между встречами, где вы автор, и теми, где вы участник проекта.
Поиск по названию - мгновенная фильтрация списка.
Фильтр по дате - выбор диапазона дат проведения встреч.
Фильтр по статусу - можно показать только завершённые, только в очереди и т.д.
Для администраторов - фильтры по пользователю и по компании.
Локальное развертывание и контроль данных
Мы сделали SOFROS AI Секретарь решением для локального развертывания. Все компоненты системы - серверная часть, база данных, модели AI - могут быть установлены на локальной инфраструктуре. Это даёт полный контроль над данными: никакая информация не покидает контур компании. Также решение весьма нетребовательно к ресурсам и позволяет запустить его на серверах без GPU.
Расширение для браузера также работает локально: запись ведётся прямо в браузере пользователя без передачи на сторонние серверы. Файлы загружаются только на ваш корпоративный сервер.
Что в итоге?
SOFROS AI Секретарь решил нашу главную проблему: контекст встреч больше не теряется. Каждая встреча - онлайн или офлайн, с файлом или по ссылке - превращается в структурированный протокол с задачами, ответственными и возможностью задавать вопросы AI-ассистенту.
Мы перестали тратить часы на расшифровку и конспектирование. Вместо этого мы просто загружаем запись и через несколько минут получаем готовый результат. Гибкие пайплайны позволяют выбирать между скоростью и качеством. Возможность переключать AI-модели даёт свободу экспериментировать. А локальное развертывание гарантирует, что все данные остаются под нашим контролем.
Встречи стали прозрачнее, задачи чётче, а команда эффективнее.
Нам интересно понять, насколько эта задача актуальна для других компаний. Если у вас есть буквально минута — ответьте, пожалуйста, на три коротких вопроса. Мы хотим понять, насколько подобные инструменты востребованы и как компании решают эту задачу сегодня. Если вы хотите узнать как создаются подобные приложения, мы будем рады продолжить статьи по данной тематике.
Комментарии (5)
ToxaBes
03.08.2026 07:24Отличная статья, спасибо, что поделились!
Нам интересно понять, насколько эта задача актуальна для других компаний.
Позвольте поделиться собственным опытом создания подобных систем, исходя из реалий внедрений. Думаю, это будет интересно и вам для улучшения собственной системы, и другим читателям.
Ваша система выглядит как хороший, крепкий базовый вариант, но есть несколько моментов, которые требуют улучшения для использования в других компаниях. Я затрону только основные, иначе комментарий станет размером со статью.
Компании сейчас хотят локальный контур, полностью. Т.е. не только бэкенд, но и саму модель. Это сразу отсекает любые облачные решения.
Далее, вы пишете о том, что решение весьма нетребовательно к ресурсам и позволяет запустить его на серверах без GPU. Без GPU вы не добьетесь требуемой скорости и качества. Конечно, базовый Whisper для транскрибации можно запустить и на CPU, а диаризацию сделать какой-нибудь моделью с открытыми весами, и это сработает на получасовом совещании с двумя участниками.
Наиболее частая длительность совещаний (из того, с чем я сталкиваюсь) составляет 1 час, количество участников в среднем 4-6 человек. Базовые модели с трудом переваривают такое, путаясь в ролях спикеров и коверкая слова. Назовем это базовым качеством. На такое базовое качество можно посмотреть, например, в Контур Толк, проведя часовое совещание и скачав транскрибированный протокол с диаризацией.
Сразу скажу по скорости: на GPU часовое совещание 4-6 человек транскрибируется, диаризуется и суммаризируется примерно за 4-5 минут. Вы не указали цифры в статье, но, думаю, понятно, что на CPU это будет происходить гораздо дольше.
Качество разберу чуть детальнее, разбив на 4 этапа:
-
Качество исходного материала.
Звуковой ряд нужно подготавливать, очищая от шумов собеседников, которые участвуют в совещании, находясь в машине, идя по улице или спускаясь в метро. Модели разделения голосов сильно зависят от соотношения сигнал/шум. Далее нужно выравнивать громкость, т.к. люди всегда говорят с разной силой: кто-то сидит прямо перед микрофоном, а кто-то бубнит с другого конца переговорки.
Если голос слишком тихий, модель (например, Whisper) может принять его за фоновый шум, проигнорировать и мы получим выпадение слов. Слишком громкий голос может давать клиппинг, что тоже искажает слова. Причем обычной нормализации тут недостаточно, нужно применять компрессию динамического диапазона или автоматическую регулировку усиления (AGC), чтобы подтянуть тихие голоса и слегка приглушить резкие всплески.
-
Качество транскрибации.
Тот же Whisper хорош в диалогах на общие темы, но теряется в специальных терминах и при дефектах дикции собеседников, а ведь от этого критически зависит и диаризация, и итоговое качество данных в RAG-системе.
Нужно дообучать модели и на распознавание русской речи с дефектами, и на предметную область компании (юриспруденция, медицина, нефтегазовый сектор и т.д.), хотя для торговых компаний это менее актуально. Если для диалогов с дефектами речи можно подготовить общие датасеты, то специфику конкретного предприятия придется собирать и дообучать самостоятельно.
-
Качество диаризации.
В реальных корпоративных условиях (те самые часовые совещания на 4–6 человек) разделение аудиозаписи на фрагменты в зависимости от того, какому спикеру принадлежит голос являются, пожалуй, самым слабым местом базовых open-source решений. Во-первых, живой диалог зачастую содержит перебивания, фоновые согласия (угу, да-да) и одновременную речь. Базовые модели крайне плохо справляются с такими перекрытиями.
В лучшем случае они сливают голоса в одного “Спикера Х”, в худшем же просто выбрасывают куски текста. Во-вторых, акустика типичной переговорки (эхо) и схожесть голосов (например, несколько мужчин с похожим баритоном, говорящих в один всенаправленный микрофон по центру стола) приводят к тому, что простые алгоритмы кластеризации начинают либо хаотично плодить ложных спикеров (создавая “Спикера 5” и “Спикера 6” там, где их нет), либо склеивать разных людей в одного спикера.
Для бизнеса и итогового качества RAG-системы путаница в ролях критична: алгоритм должен четко понимать, кто задал вопрос, а кто утвердил решение или взял на себя задачу. Добиться этого “из коробки” на CPU-серверах просто невозможно. Требуются пайплайны на базе NVIDIA NeMo / Pyannote Audio, которые умеют детектировать перекрытия речи и строить точные векторные эмбеддинги голосов. А это, как я уже говорил выше, вновь возвращает нас к жесткой необходимости использования GPU.
-
Качество саммаризации.
Это самая простая часть, большинство моделей отлично саммаризуют текст, поэтому тут будет достаточно любой открытой модели, которая понимает русский язык, размером ~8B параметров. Тут весь секрет заключается в написании качественных инструкций в системный промпт.
Это вкратце о том, как можно поднять качество (т.е. конкурентоспособность) вашего продукта. Есть еще много нюансов и деталей, втом числе следующий шаг с правильным контекстуальным чанкингом для RAG, но это уже выходит за рамки одного комментария.
stentor123 Автор
03.08.2026 07:24Спасибо за столь подробный комментарий. Мы используем локальную GigaAM на тестах она показала гораздо лучший результат по сравнению с Whisper. Плюс очень нетребовательна к ресурсам. Также в качестве диаризатора используются разные решения в зависимости от пайплайна. Есть Payannote, Onnx, Senko. Качество распознавания спикеров очень высокое. При записи через ассистента микрофон участника пишется в отдельный именованный канал, что дает дополнительное преимущество. Плюс на шаге исправления ошибок удаляются дискурсивы (слова паразиты), ошибки орфографии и распознавание брендов + дополнительно корректируются спикеры (если встречу выстраивать по определенному шаблону то определение спикеров происходит поименно и даже с проектными ролями). У нас реализована многоэтапная идентификация и постобработка. При этом работает полностью локальная модель. На этапе суммаризации мы используем облачную модель, так как локальные небольшие модели очень плохо следуют инструкциям и имеют низкую скорость инференса. При этом ничто не мешает заменить провайдера или саму модель (вплоть до полностью локального решения при наличии GPU). Мы используем Openrouter, Openmodel, Ollama. Технически, так как шаги разделены реализовать любого другого провайдера - вопрос нескольких минут. Что касается скорости обработки, если в пайплайне нет обработки ошибок, то часовое совещание обрабатывается около 20 мин, если есть обработка ошибок - 50-60 мин. Напомню, данный результат получен на системе без GPU. В целом нас такая скорость вполне устраивает. На сервере реализована многопоточная обработка и очередь с брокером. Пользователи получают результат на электронную почту и в целом не отвлекаются на его ожидание результата. Ассистент поднимает запись на сервер сразу же после записи в браузере. Реализована возможность загружать запись через локальные или интернет-ссылки (например с Яндекс-диска), приглашать бота на встречу. Возможность делиться записями позволяет быстро предоставить результат всем заинтересованным участникам. Идея контейнеров-проектов позволяет использовать различные RAG решения для выстраивания зависимостей из нескольких протоколов. Сервер взаимодействия имеет свой API и позволяет подключать к нему любого клиента в том числе и интегрироваться в состав существующего решения. Также поддерживается возможность горизонтального масштабирования. Клиент может выбирать доступный наименее загруженный сервер или переключать его в случае недоступности. Весь проект был реализован с использованием Spec-Driven-Development и написан на OpenSource решениях. Если будет интерес, расскажем какие технологии и подходы мы использовали для прототипирования и разработки. Там тоже все очень интересно. Мы решали свою локальную задачу. Основное требование - локальное хранение всех записей и возможность горизонтального и вертикального масштабирования.
ToxaBes
03.08.2026 07:24Спасибо за столь развернутый и техничнески грамотный ответ! Приятно видеть живую инженерную дискуссию и практические находки.
GigaAM действительно отличный выбор для русского языка, а вот использование OpenRouter на шаге суммаризации как раз то самое узкое место для компаний. Для ИБ в банках или на производстве отправка расшифровки встречи (где звучат NDA, коммерческие цифры и персональные данные) на внешние API автоматически обнуляет локальность системы. Но архитектура у вас модульная, так что при появлении GPU можно будет использовать локальную LLM и полностью закрыть этот вопрос.
Решение с поканальной записью через браузерный ассистент очень изящное, вы просто устранили проблему акустической диаризации на корню. Поканальная запись отлично закрывает онлайн, но для очных встреч (один спикерфон по центру стола на 6 человек) проблема диаризации на CPU вернется. Там без GPU алгоритмам вроде Pyannote все же трудно удержать баланс точности и адекватного времени обработки.
В любом случае, для решения внутренних задач вы собрали очень практичный, продуманный и рабочий продукт. Я лишь поделился своим опытом в ответ на ваш призыв:
Мы хотим понять, насколько подобные инструменты востребованы и как компании решают эту задачу сегодня.
-
keelai
Хороший практический кейс. Я бы в такой системе жёстко разделял «получили расшифровку» и «получили протокол, которому можно доверять». Ошибка на первом слое легко превращается на втором в уверенно сформулированную, но неверную задачу.
Для продакшена полезно хранить рядом с каждым пунктом протокола не только ответственного и срок, но и ссылку на исходный фрагмент с таймкодом, уверенность распознавания и статус подтверждения человеком. Тогда спорную задачу можно быстро проверить, а не переслушивать весь час встречи.
И метрики я бы считал не только по WER: полнота извлечения action items, доля ложных задач, время до готового протокола и процент пунктов, которые пришлось исправлять вручную, лучше показывают реальную ценность локального контура.
stentor123 Автор
Спасибо за интересный насыщенный комментарий. В действительности система реализована в виде настраиваемых пайплайнов. на каждом шаге получаем строго определенное действие (загрузили файл, расшифровали, исправили ошибки, получили протокол, сформировали документы, выполнили рассылку). Каждый шаг получает свой артефакт и пайплайн может быть перезапущен на любом шаге при возникновении ошибки. Таймкод + возможность прослушать фрагмент реализована. Транскрипция встречи отправляется вместе с протоколом и доступна в том числе и по постоянной ссылке для незарегистрированных пользователей системы.