Как мы дистиллировали Qwen для автоматического протоколирования совещаний

Задача протоколирования

Протокол помогает восстановить содержание встречи без повторного прослушивания. Система ВТБ распознаёт речь через Wav2Vec 2.0 и передаёт стенограмму в Qwen 2.5 Instruct. Модель выбрали за работу с длинным контекстом, инструкциями и ошибками распознавания.

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

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

Почему понадобилась оптимизация

По описанию команды, для Qwen 2.5 32B в её конфигурации требовалось 80 ГБ видеопамяти. В рабочей системе были A100 с 40 ГБ. Качество протоколов уже устраивало авторов: искать решение пришлось из-за ограничений оборудования.

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

Какие варианты сравнивали

• Qwen 2.5 14B.
• Qwen 2.5 32B с AWQ INT4.
• Qwen 2.5 32B со SmoothQuant INT8.

Два варианта уменьшают точность хранения чисел в большой модели. AWQ учитывает активации при выборе того, как сжать веса, и требует калибровки; не все слои одинаково подходят для такого преобразования. SmoothQuant перераспределяет масштаб между весами и активациями, чтобы уменьшить влияние выбросов, но требует изменений в модели. Третий вариант — обучить меньшую модель на ответах большой.

Данные и обучение

Команда подготовила более 4000 стенограмм и более 8000 обучающих пар: инструкция и стенограмма на входе, протокол от Qwen 32B на выходе. Структуру данных привели к единому виду, ошибки распознавания речи исправили. Для Qwen 14B использовали LoRA, а для квантизованных вариантов — QLoRA.

Здесь дистилляция означает передачу поведения через примеры: большая Qwen 32B составляет эталонные протоколы, на которых учится более экономичная модель. LoRA обучает небольшие добавочные матрицы при замороженных исходных весах; QLoRA совмещает такой подход со сжатыми весами.

Как оценивали результат

Содержание протоколов переводили в векторы через Universal Sentence Encoder и измеряли их косинусную близость к эталону. Это оценка сходства текстов; правильность деталей проверяли вручную. Температура генерации — 0.

Числа в таблице — значения метрики в записи авторов, а не процент фактически правильных протоколов. Время относится к их измерению: размер проверяемого набора, длины стенограмм и подробная конфигурация замера в статье не приведены. Поэтому 20–43 минуты нельзя читать как задержку ответа на одну встречу.

Почему выбрали 14B, хотя метрика была ниже

SmoothQuant лидировала по метрике, но работала дольше без заметной содержательной выгоды. AWQ иногда искажала смысл. 14B лучше сохраняла детали, таймкоды и хэштеги — в том числе полезную информацию, отсутствовавшую в эталоне. Её выбрали для рабочей системы; ручную проверку сохранили.

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

Итог: как получают протокол и почему выбрали 14B

В этой статье исходная проблема была связана с эксплуатацией: Qwen 32B уже хорошо составляла протоколы, но конфигурация команды требовала больше видеопамяти, чем было доступно в рабочей системе. Мы разобрали три варианта оптимизации — меньшую модель, AWQ и SmoothQuant — и то, как обучение на протоколах большой модели помогло сохранить полезное содержание.

Качество проверяли двумя способами. Автоматически сравнивали векторные представления нового протокола и эталона через Universal Sentence Encoder; вручную смотрели на смысл и полноту деталей. SmoothQuant получила лучшую автоматическую оценку, но авторы выбрали 14B: она лучше сохраняла полезные детали, включая то, что мог пропустить сам эталон.

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