Кастомный сентимент-классификатор: fine-tuning до 95% F1

Fine-tuning анализ тональности: где ломается готовая модель

Готовая модель обучена на общем корпусе и уверенно различает «нравится / не нравится» в нейтральных текстах. На отраслевых данных точность классификатора проседает до 60–70%: модель не знает, что «горячий» в отзывах на технику — это плюс, а «холодный» в клиентских историях — минус. Доменная лексика меняет знак оценки, а универсальный словарь этого не видит.

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

Fine-tuning анализ тональности решает это за счёт дообучения модели на вашей разметке отзывов. Мы собираем корпус из реальных обращений, размечаем спорные случаи — сарказм, отрицания, смешанные оценки — и дообучаем модель на этих примерах. Модель перестаёт опираться на общий словарь и учится на ваших формулировках: жаргоне отрасли, названиях товаров, типовых претензиях.

Ключевой этап — качество разметки. Если два разметчика ставят разные метки на один текст, модель выучит шум вместо сигнала. Поэтому мы фиксируем правила разметки, прогоняем спорные примеры через согласование и держим отдельную выборку для проверки — она не участвует в обучении и показывает реальную точность классификатора, а не подогнанную под обучающий набор.

На выходе — модель с F1 до 95% на вашем домене вместо 60–70% у универсальной. Разбираем, как это закрывается на ваших данных.

Что даёт дообучение под ваш корпус текстов

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

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

Что меняется в цифрах

Метрика F1 — сводная точность и полнота — на общем корпусе держится в районе 0,7–0,8, на вашем после дообучения выходит к 0,93–0,95. Практический смысл в другом: доля обращений, уходящих на ручную модерацию, падает с большинства до единичных процентов. Остаток — это как раз спорные кейсы, где решение человека действительно нужно, а не механическая перепроверка очевидного.

Устойчивость к реальному тексту

Отдельный этап — проверка на «грязных» данных: опечатки, транслит, латиница вперемешку с кириллицей, растянутые гласные, эмодзи вместо слов. Классификатор, не видевший такого на обучении, теряет точность на 15–20 пунктов; дообученный с аугментацией — держит качество классификации в пределах пары пунктов от чистого текста. Это и есть разница между демо и системой, которая работает на живом потоке.

Подходы к обучению: сравнение по задаче и данным

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

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

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

Как проходит внедрение классификатора

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

Дальше фиксируем схему разметки: список классов, правила отнесения, спорные случаи с примерами. Это документ, по которому размечают люди и по которому потом проверяют модель, — без него метрики на валидации ничего не значат.

1. Аудит данных и текущей разметки. Сводим источники, считаем распределение классов, находим дубли и шум, оцениваем, хватает ли примеров на каждый класс.
2. Схема разметки и инструкция для аннотаторов. Формализуем классы, правила, пограничные случаи; согласуем с вашей командой, что именно считается нужной тональностью.
3. Доразметка и чистка корпуса. Дополняем редкие классы, снимаем противоречия, проверяем согласованность между разметчиками на контрольной выборке.
4. Разделение данных. Откладываем валидацию и тест так, чтобы в них не попали дубли из обучения, — иначе метрика завышается и на реальных данных модель проседает.
5. Fine-tuning и подбор параметров. Обучаем на размеченном корпусе, сравниваем с базовой моделью и простыми правилами, отбираем конфигурацию по F1 на отложенной выборке, а не по accuracy.
6. Валидация модели. Смотрим F1 по каждому классу отдельно, матрицу ошибок, поведение на редких категориях и на текстах вне обучающего распределения.
7. Передача в эксплуатацию. Разворачиваем inference, настраиваем мониторинг доли и уверенности предсказаний, документируем, как дообучать модель на новых данных.

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

Артефакты: что остаётся у вашей команды

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

• Веса модели — обученный сентимент-классификатор с зафиксированным порогом уверенности, версия привязана к набору данных и конфигурации обучения, чтобы результат воспроизводился однозначно.
• Схема разметки — инструкция для аннотаторов: категории тональности, правила для смешанных и ироничных высказываний, разбор спорных случаев с примерами, порядок разрешения расхождений между разметчиками.
• Размеченный датасет — обучающая, валидационная и отложенная выборки с зафиксированным разбиением, чтобы метрики на новых запусках сравнивались с исходными на тех же данных.
• Скрипты переобучения — конфигурации fine-tuning, подготовка признаков, контроль переобучения, расчёт F1 по классам; запускаются одной командой на ваших данных.
• Регламент контроля качества — периодичность проверок, метрики и пороги деградации, порядок действий при падении F1 ниже согласованного уровня.
• Мониторинг и логирование — дашборд по распределению предсказаний и доле низкой уверенности, выгрузка сомнительных примеров на доразметку.
• Документация и передача — описание архитектуры, инструкции по запуску и обновлению, совместная сессия с вашими инженерами по развёртыванию на вашей инфраструктуре.

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

Кейс: сентимент-классификатор для потока отзывов

Заказчик — маркетплейс с потоком отзывов на нескольких языках. Базовая модель на открытых данных давала приемлемое качество на «позитиве» и «негативе», но путала редкие классы: сарказм, скрытую претензию к доставке, жалобу на конкретного продавца. Ручная разметка съедала ресурс команды поддержки, а часть обращений уходила не в ту очередь.

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

Hugging Face использовали как основу для работы с предобученными моделями и их дообучения на корпусе заказчика.

Метрики до и после

Итоговый F1 по всем классам вырос с 0.72 до 0.94, доля записей, уходящих на ручную проверку, сократилась с 38% до 9%. На редких классах разброс между запусками сузился — модель перестала «прыгать» на сарказме и скрытых претензиях, которые раньше уходили в нейтральные.

Что это дало в работе

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

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

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

Воспроизводимости нет — при следующем обновлении базовой модели поведение сдвинется, и вам придётся заново подбирать формулировки.

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

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

Практический вывод: подсказки в запросе — для быстрой проверки гипотезы и редких сценариев, дообучение — когда задача повторяется, качество нужно измеримое, а поведение модели должно быть предсказуемым. Часто разумный путь — начать с промпта, собрать на нём первые размеченные примеры, а затем перейти к fine-tuning на этих же данных.

Частые технические сомнения

Что делать с дисбалансом классов?

В реальных данных негатив почти всегда в меньшинстве, и модель, обученная «как есть», просто предсказывает мажоритарный класс. Мы работаем не с одной метрикой accuracy, а с F1 по каждому классу отдельно, и выравниваем веса классов при обучении. Дополнительно проверяем порог срабатывания на отложенной выборке — так редкий, но важный класс не теряется.

Как поддерживать модель после запуска?

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

Что если качество после запуска окажется ниже ожидаемого?

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

Обсудим вашу задачу классификации

Чтобы оценка была предметной, а не «плюс-минус порядок», на первом разговоре нам нужны ваши данные и контекст применения. Пришлите, что есть — даже сырые выгрузки без разметки подойдут: по ним мы поймём объём, классы тональности и реальную сложность задачи.

Что полезно подготовить:

• 200–500 реальных примеров текстов из вашего потока — отзывы, обращения, комментарии, письма: по ним видно язык, сленг, длину и смешение тем.
• Текущую разметку, если она есть: сколько классов, кто и по какой инструкции размечал, где спорные случаи.
• Целевые метрики: какая доля верных ответов считается рабочей и на каких классах ошибка критичнее.
• Как результат встраивается в процесс: пакетная обработка выгрузок, ответы в реальном времени или разбор в панели.
• Ограничения: языки и диалекты, требования к хранению данных, где разрешено размещать модель.
• Что уже пробовали: готовые сервисы, ручная разметка, правила по словарям — и почему результат не устроил.

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