Привет, Хабр! Меня зовут Азик, я старший ML‑инженер в NLP‑лаборатории Центра ИИ Контура. В прошлом году я занимался запуском автоматической суммаризации встреч в Толке — нашем сервисе для видеозвонков.

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

А если вам удобнее смотреть, а не читать, то вот ссылка на мой доклад на Saint HighLoad++ 2025.

Архитектура решения: путь от звонка к смыслу

Когда мы начали работать над автоматической суммаризацией встреч, всё звучало просто: распознать речь, прогнать через LLM, получить текст.

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

Обзор компонентов

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

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

Ниже два основных сервиса пайплайна:

• LongRunning отвечает за распознавание речи,

• Summarization — за генерацию итогового саммари.

Они получают задачи, обрабатывают их через пул воркеров и возвращают результат обратно. В основе всего этого лежат AI‑модели: автоматическое распознавание речи (ASR), постобработка текста, LLM для суммаризации.

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

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

Распознавание речи

После того как Transcript получил запись новой встречи, он ставит задачу на распознавание речи.

Давайте посмотрим, что происходит дальше на этом этапе:

Transcript.Worker создаёт задачу на распознавание и отправляет её в LongRunning.

Далее LongRunning:

• Декодирует аудио,

• Применяет VAD (удаляет тишину и разбивает аудио на сегменты,

• Подаёт каждый из них в ASR (модель распознавания речи).

• Полученный текст отправляется на постобработку:

  • PCR (восстановление пунктуации и регистра),

  • ITN (преобразование чисел и очистка от шумов/междометий).

Готовая транскрипция возвращается обратно в Transcript и становится доступной для дальнейших шагов.

Про модель распознавания речи (ASR)

Мы используем FastConformer, дообученный на наших доменных данных (до этого применяли Conformer). Для обучения использовали сотни часов аудиозаписей встреч из Толка и телефонных звонков.

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

Качество модели измеряем по WER, сейчас держим её в диапазоне 11–17% в зависимости от домена.

После распознавания добавляем постобработку:

• PCR — модель на основе BERT, которая расставляет пунктуацию и регистр,

• ITN преобразует текстовые представления чисел в цифры.

Про масштабирование

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

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

• у каждого продукта своя очередь задач и отдельные лимиты

• задачи ранжируются по приоритету: например, распознавание для робота, говорящего с клиентом, важнее, чем асинхронная речевая аналитика

• количество воркеров масштабируется автоматически: один воркер обрабатывает в среднем 30 задач, а автоскейлинг срабатывает на основе метрик загрузки и длины очереди.

По нашему SLO, транскрипция должна быть готова не дольше, чем за 1,5 часа. На практике мы укладываемся в среднем в ~30 минут, даже при высокой нагрузке.

Генерация саммари

Когда транскрипция уже готова, начинается вторая часть пайплайна. Сервис Transcript передаёт текст встречи в Summarization — отдельный сервис, который отвечает за генерацию итогового саммари с помощью LLM.

На схеме выше видно, как устроен процесс: Summary.Worker ставит задачу, API Summarization сохраняет её в базу и публикует сообщение в брокер. Воркеры подписаны на очередь, получают задачи, выполняют препроцессинг и передают чанки текста в LLM. Результаты собираются и возвращаются пользователю.

Важная особенность: весь текст встречи в LLM не влезет, поэтому мы делим его на фрагменты. Мы рассматривали два подхода:

• Наивный — просто разбить по длине, не разрывая предложения.

• Семантический — обучить модель, которая выделяет логически завершённые фрагменты.

На практике наивный подход оказался достаточно качественным при минимальных трудозатратах, поэтому остановились на нём.

Каждый чанк оборачивается в промпт и отправляется в LLM. Ответы модели мы очищаем от артефактов (вроде переключения на английский) и объединяем в итоговую выжимку — читаемое, лаконичное саммари всей встречи.

Про LLM 

Для генерации саммари мы используем open‑source LLM без дообучения. Подходящую модель мы подбирали поэтапно.

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

Затем провели ручную проверку: для оставшихся кандидатов сгенерировали саммари на фиксированном наборе примеров и сравнили с эталонами.

Мы тестировали модели до 30B параметров, и в итоге выбрали Gemma 2 (27B) — она показала хорошее соотношение качества, устойчивости и скорости.

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

Про масштабирование

LLM — самая ресурсоёмкая часть пайплайна. Чтобы система выдерживала нагрузку, мы заранее провели performance‑тесты и определили пропускную способность модели. На основе этих замеров и прогноза по числу задач рассчитали необходимое количество реплик модели.

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

Формальное SLO пока в работе, но в среднем генерация саммари занимает около 10 минут от момента поступления транскрипции до готового результата.

Результаты: работает ли это?

Работает. И главное — люди этим реально пользуются.

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

Сразу после релиза средняя оценка функции держится на уровне 4.5 из 5, можно видеть на картинке выше.

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

На третьем месте — скачивание полной выжимки.

Если бы саммари были бесполезны, их бы не копировали, не читали и не сохраняли. А значит, модельный пайплайн выполняет свою задачу — помогает людям быстро восстановить, о чём была встреча.

Адаптация: можно ли повторить это у вас?

Если вы узнали свою проблему и теперь думаете, «а можно ли нам сделать такое же?», то у нас для вас хорошие новости: да, можно. Именно на переиспользуемость и адаптируемость мы и делали ставку при проектировании архитектуры.

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

Например:

• Вместо нашей LLM вы можете использовать любую open‑source модель или подключиться к внешнему API. Для небольших объёмов это даже выгоднее, чем разворачивать модель у себя.

• Чанкинг и промптинг — модули, которые легко заменить или доработать. Есть готовые open‑source решения, которые можно просто встроить.

• ASR тоже можно заменить на свою модель или использовать внешние движки, если не хотите или не можете передавать данные наружу.

Мы описали минимальный стек, который легко воспроизвести, и он отлично масштабируется. А самое главное — вы не привязаны к конкретной модели или фреймворку.

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

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

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