Почему дообучение BERT на своих данных буксует
Модель на правилах держит предсказуемость на шаблонных обращениях, но ломается на перефразировках и опечатках. Дообучение BERT на своих данных должно закрыть именно этот разрыв — и здесь чаще всего проседает качество классификации. Причина обычно не в выборе архитектуры, а в том, на каком материале модель учится.
Своя разметка почти всегда приходит сырой. Разные исполнители читают инструкцию по-своему, и одна и та же жалоба попадает то в «оплату», то в «доставку»; дубликаты получают разные метки, а длинные тексты размечают по одному предложению из пяти. Модель видит противоречивые примеры и учится их усреднять — на пограничных формулировках точность не растёт, сколько эпох ни добавляй.
Вторая ловушка — дисбаланс. Если редкая категория занимает доли процента корпуса, модели выгоднее всегда отдавать мажоритарную метку: агрегированная точность выглядит прилично, а нужный класс не находится вообще, и потери прячутся в среднем. Третья — проверка на той же разметке, что и обучение: цифра красивая, а на живом потоке качество падает, потому что спорные и трудные случаи в набор просто не попали.
Разбираем, как это закрывается: сначала схема классов и правила разрешения спорных случаев, затем контроль согласия разметчиков на пересечённой выборке, балансировка редких категорий и отдельный отложенный набор, собранный из реального трафика. Только после этого имеет смысл дообучение BERT — иначе модель аккуратно выучит шум.
Какой эффект даёт модель, обученная на своих данных
Дообучение BERT на вашей переписке меняет не абстрактное «качество модели», а доли в потоке обращений. Размечаем по вашей таксономии несколько тысяч реальных тикетов, писем и сообщений из чата и сразу видим, какие пары категорий путаются чаще всего.
Дальше дообучение на своей разметке: классы становятся вашими, а не «общими» — претензия по доставке, запрос доступа и сбой оплаты перестают слипаться в один мешок. Запускаем на актуальной ветке — Hugging Face даёт готовые веса и обвязку, поэтому время уходит на данные и разметку, а не на сборку архитектуры с нуля.
Доля обращений, разобранных без человека, обычно поднимается с половины до трёх четвертей. Остаток не падает на оператора «как есть», а уходит в очередь с готовой категорией и приоритетом: человек подтверждает или исправляет, и каждая правка возвращается в набор данных для следующей итерации.
Метрики качества модели считаем по классам, а не одной общей цифрой: точность и полнота по проблемным категориям, матрица ошибок, порог уверенности, ниже которого обращение уходит на проверку. Так видно, что исправлять дальше — данные, разметку или границы классов.
Ушедший класс ошибок — уверенные ответы «не туда», когда текст формально похож, а смысл другой. Время на разметку тоже падает: модель сама подсвечивает спорные примеры на границе классов, и следующая итерация требует меньше ручной работы.
Подходы к дообучению BERT: сравнение режимов
Перед стартом фиксируем три параметра: сколько размеченных примеров на класс реально есть, насколько лексика предметной области расходится с общим языком и что важнее — качество на редких классах или время ответа. От них зависит режим, и почти всегда он не один: часть задачи закрывает модель, часть — детерминированные правила.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Готовая модель без изменений | Классы совпадают с её разметкой, своих данных для обучения нет | Не различает внутренний сленг и аббревиатуры; уверенность не откалибрована под вашу выборку |
| Дообучение на своих данных | Есть хотя бы сотни размеченных примеров на класс | Требует чистого набора данных; редкий класс проседает без перевзвешивания |
| Обучение с нуля | Язык и разметка принципиально далеки от общих корпусов, данных очень много | Дороже по времени и вычислениям; на малых выборках устойчиво проигрывает дообучению |
| Гибрид с правилами | Есть жёсткие форматы: артикулы, номера, регламентные шаблоны | Правила нужно сопровождать; при конфликте с моделью порядок приоритетов задаётся вручную |
Граница между режимами проверяется на одной и той же отложенной выборке, а не на глаз. Дообучение обычно выигрывает при десятках классов и ограниченной разметке, обучение с нуля оправдано только при действительно далёком домене, а гибрид даёт наибольший прирост там, где часть сигнала формализуема.
Этапы внедрения: от аудита разметки до передачи
Порядок этапов не произвольный: каждый следующий опирается на артефакт предыдущего. Если пропустить аудит разметки и сразу запустить дообучение BERT, модель выучит ошибки разметчиков, и настройкой это уже не исправить. Ниже — путь, по которому идёт работа.
- Аудит корпуса и разметки — доля противоречивых примеров, дубли, дисбаланс классов, согласие разметчиков, принадлежность текстов целевому домену.
- Постановка метрики — что критичнее: полнота по редкому классу или точность по массовому. Фиксируем базовый уровень на простой модели, чтобы у нейросети был честный ориентир.
- Схема классов — иерархия рубрик, правила для спорных случаев, минимум примеров на класс. Согласуем её с теми, кто будет разбирать предсказания вручную.
- Дообучение — выбор предобученной модели и длины окна под типичный текст, балансировка классов, остановка по валидационной выборке, а не по числу проходов.
- Проверка модели — отложенная стратифицированная выборка, разбор ошибок по классам и отдельный прогон на текстах другого периода: так виден сдвиг данных, который средняя метрика скрывает.
- Внедрение в процесс — сервис с версионированием модели, логированием предсказаний и порогом уверенности: спорные случаи уходят человеку, а не в автоматику.
- Передача — код дообучения, конфигурации, чек-лист повторного запуска, документация схемы классов и инструкция оператору по разбору сомнительных выводов.
Артефакты проекта: веса модели, регламент разметки
Клиенту остаётся не «модель в архиве», а комплект, по которому команда может повторить обучение, проверить качество и продолжить разметку своими силами. Передаём четыре группы артефактов: веса и конфигурацию запуска, документацию по модели, регламент разметки и инструкции для операторов.
- Веса дообученной модели и конфигурация вывода: порог уверенности, соответствие меток классам, ветка базовой архитектуры — разворачивается на новом сервере без обращения к нам.
- Документация по модели: схема классов, объём и источники обучающей выборки, подобранные параметры обучения, зафиксированные ограничения по домену и типу текстов.
- Отчёт по качеству на отложенной выборке: точность и полнота по каждому классу, матрица ошибок, перечень типовых ложных срабатываний с примерами.
- Регламент разметки: определение каждого класса, разбор пограничных случаев, правило разрешения расхождений между операторами.
- Инструкции для операторов: пошаговый порядок разметки, короткий набор с эталонными ответами для обучения новичков, контрольный список самопроверки.
- Скрипты подготовки и проверки данных: поиск дублей, оценка дисбаланса классов, отсев битых и слишком коротких текстов.
- Порядок повторного обучения: от сырых данных до новой версии модели, с теми же метриками для сравнения версий.
- Протокол приёмки: зафиксированные пороги качества, порядок отката на предыдущую версию, ответственные за приёмку.
Такая передача снимает главный риск — зависимость от подрядчика. Заказчик видит, на каких данных модель училась, где проходит граница её применимости и по какой процедуре обучать новый класс, когда меняется поток обращений.
Классификация обращений поддержки: метрики до и после
Поток обращений в поддержку шёл через одну очередь: операторы вручную распределяли их по темам, и срочные сообщения о сбоях стояли в общей массе. Доля ручной сортировки держалась около 100%, а время до первого ответа зависело от того, кто первым разберёт очередь.
Мы начали с разметки: собрали историю обращений за несколько периодов, свели темы к устойчивому словарю классов и убрали пересечения, из-за которых одно обращение подходило к двум категориям. Базовая модель на BERT давала macro-F1 0.61 на отложенной выборке — для маршрутизации без человека этого мало, поэтому дообучение шло на сбалансированных классах с отдельным контролем качества на редких темах.
Что меняли по ходу проекта
Ключевые улучшения дали не настройки обучения, а данные: устранение противоречий в разметке, добавление примеров на редкие темы и порог уверенности, ниже которого обращение уходит оператору. Ошибочные срабатывания стали предсказуемыми — модель помечает сомнительные случаи, а не молчит о них.
Что показали метрики после внедрения
macro-F1 на отложенной выборке вырос с 0.61 до 0.88, доля автоматически маршрутизируемых обращений — до 74% потока. Время до первого ответа в срочных категориях сократилось примерно втрое, а ручная сортировка свелась к единичным случаям: поддержка клиентов перестала быть узким местом на входе.
Что делать, если уже работает модель на правилах и словарях
Полный переход не нужен и почти всегда вреден. Рабочая схема — гибридный подход: словари и правила продолжают закрывать простые случаи, а обучаемая модель подключается к тому, что они не покрывают. Обе ветки живут на одном входе, и решение о том, кому отдать текст, принимается по порогу уверенности.
Маршрут строится так: сначала отрабатывает словарь — точное совпадение по шаблону или стоп-листу закрывает вопрос без модели. Всё, что правила не разобрали или разобрали с низкой уверенностью, уходит на модель. Каждое расхождение логируется — это готовый материал для следующей итерации обучения.
Отдельно готовить корпус обычно не требуется: история прогонов правил уже содержит разметку по классам. На ней обучается первая версия, а спорные случаи, где правило и модель расходятся, уходят на ручной разбор и возвращаются в выборку. Так качество растёт там, где оно критично, а не по всему словарю сразу. Дообучение BERT и родственных архитектур здесь — не переписывание системы, а замена одного из решающих блоков.
Перевод без остановки процесса делается теневым режимом. Новая модель какое-то время считает на живом трафике, но её ответы только сравниваются с правилами и не влияют на выдачу. Когда расхождение с эталоном укладывается в заданный порог, открываем долю трафика — сначала малую, затем всю. Откат — переключение флага, словари остаются на месте и продолжают работать.
В итоге правила превращаются в страховку для редких классов и жёстких требований, а основную нагрузку несёт модель. Доля ручных разборов падает в разы, словари сжимаются до действительно критичных случаев — без остановки и без потери уже достигнутого качества.
Технические сомнения: разметка, объём данных, качество
Объём разметки определяется не «магическим» числом, а числом классов, их балансом и разнообразием формулировок. Для двух-трёх устойчивых категорий обычно хватает нескольких сотен примеров на каждую; когда классов десятки и они пересекаются по смыслу, счёт идёт на тысячи, а часть корпуса дешевле добирать слабой разметкой с ручной проверкой спорных случаев.
Разрыв между качеством на отложенной выборке и на реальном потоке — чаще следствие расхождения данных, а не ошибки обучения. Поэтому мы фиксируем правила разметки до старта, вычищаем дубликаты и почти одинаковые примеры, а контроль качества строим на разборе ошибок: какие пары классов модель путает и на каких формулировках это происходит.
Сколько примеров нужно, чтобы вообще начать?
Ориентир считаем от задачи: достаточно нескольких сотен размеченных примеров на класс, чтобы получить первую рабочую модель и увидеть, где именно не хватает данных. Дальше объём наращиваем по разбору ошибок — добавляем те формулировки, на которых модель ошибается, а не просто «ещё данных».
Что делать, если разметчики противоречат друг другу?
Противоречия не сглаживаем, а выносим в отдельный набор: фиксируем правило для спорного случая и переразмечаем пограничные примеры. Если два класса действительно неразличимы по тексту, их объединяют — иначе модель учится угадывать шум, и качество на потоке падает.
Как понять, что модель переобучилась?
Признак — метрика на обучающей выборке растёт, а на отложенной перестаёт улучшаться. Тогда останавливаем обучение по отложенной выборке, уменьшаем сложность модели и проверяем перекрёстной проверкой по разным срезам данных. Отдельно смотрим устойчивость на коротких и нетипичных текстах — там переобучение проявляется раньше всего.
Обсудим задачу: какие данные есть и что нужно на выходе
Чтобы оценка была предметной, а не «на глаз», для первого разговора достаточно трёх вещей: примеров ваших текстов с разметкой или без неё, списка целевых классов и понимания, как результат будет использоваться — разовая обработка накопленного архива или постоянный поток документов. Этого хватает, чтобы оценить объём, выбрать базовую модель для дообучения BERT-семейства и назвать сроки без догадок.
С чем мы возвращаемся после разбора:
- оценка задачи: сколько размеченных примеров не хватает до устойчивого качества и какие классы модель путает чаще всего;
- план работ по этапам с точками контроля — от подготовки корпуса до передачи модели;
- требования к данным заказчика: формат, объём, схема разметки, правила обезличивания;
- режим работы: где размещается модель, как обновляется словарь классов, что происходит при появлении нового класса;
- критерии приёмки в цифрах: доля верных ответов и матрица ошибок по каждому классу на отложенной выборке;
- состав команды и разделение зон ответственности на время проекта.
Старт проекта не требует, чтобы данные были уже подготовлены: разбор корпуса и разметку мы закладываем в план, а не выносим за его рамки. Опишите задачу — какие тексты классифицируете, сколько классов и где должен жить результат, — и мы вернёмся с оценкой и планом работ.
