Навчання моделі класифікації тексту (BERT, RoBERTa, DeBERTa)

Чому донавчання BERT на власних даних буксує

Модель на правилах зберігає передбачуваність на шаблонних зверненнях, але ламається на перефразуваннях і помилках друку. Донавчання BERT на власних даних має закрити саме цей розрив — і саме тут найчастіше просідає якість класифікації. Причина зазвичай не у виборі архітектури, а в тому, на якому матеріалі модель учиться.

Власна розмітка майже завжди надходить сирою. Різні виконавці читають інструкцію по-своєму, і та сама скарга потрапляє то до «оплати», то до «доставки»; дублікати отримують різні мітки, а довгі тексти розмічають по одному реченню з п'яти.

Модель бачить суперечливі приклади й учиться їх усереднювати — на пограничних формулюваннях точність не зростає, скільки епох не додавай.

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

Третя — перевірка на тій самій розмітці, що й навчання: цифра гарна, а на живому потоці якість падає, бо спірні та складні випадки до набору просто не потрапили.

Розбираємо, як це закривається: спочатку схема класів і правила розв'язання спірних випадків, потім контроль згоди розмітників на перехресній вибірці, балансування рідкісних категорій і окремий відкладений набір, зібраний із реального трафіку. Тільки після цього має сенс донавчання BERT — інакше модель акуратно вивчить шум.

Який ефект дає модель, навчена на власних даних

Донавчання BERT на вашому листуванні змінює не абстрактну «якість моделі», а частки в потоці звернень. Розмічаємо за вашою таксономією кілька тисяч реальних тікетів, листів і повідомлень із чату й одразу бачимо, які пари категорій плутаються найчастіше.

Далі донавчання на власній розмітці: класи стають вашими, а не «загальними» — претензія щодо доставки, запит доступу й збій оплати перестають злипатися в один мішок.

Запускаємо на актуальній гілці — Hugging Face дає готові ваги й обв'язку, тому час іде на дані та розмітку, а не на складання архітектури з нуля.

Частка звернень, розібраних без людини, зазвичай піднімається з половини до трьох чвертей.

Залишок не падає на оператора «як є», а йде в чергу з готовою категорією та пріоритетом: людина підтверджує або виправляє, і кожне виправлення повертається до набору даних для наступної ітерації.

Метрики якості моделі вважаємо за класами, а не однією загальною цифрою: точність і повнота за проблемними категоріями, матриця помилок, поріг впевненості, нижче якого звернення йде на перевірку. Так видно, що виправляти далі — дані, розмітку чи межі класів.

Зниклий клас помилок — впевнені відповіді «не туди», коли текст формально схожий, а сенс інший. Час на розмітку теж падає: модель сама підсвічує спірні приклади на межі класів, і наступна ітерація потребує менше ручної роботи.

Підходи до донавчання BERT: порівняння режимів

Перед стартом фіксуємо три параметри: скільки розмічених прикладів на клас реально є, наскільки лексика предметної області розходиться із загальною мовою і що важливіше — якість на рідкісних класах чи час відповіді.

Від них залежить режим, і майже завжди він не один: частину задачі закриває модель, частину — детерміновані правила.

Межа між режимами перевіряється на тій самій відкладеній вибірці, а не на око.

Донавчання зазвичай виграє за десятків класів і обмеженої розмітки, навчання з нуля виправдане лише за справді далекого домену, а гібрид дає найбільший приріст там, де частину сигналу можна формалізувати.

Етапи впровадження: від аудиту розмітки до передачі

Порядок етапів не довільний: кожен наступний спирається на артефакт попереднього. Якщо пропустити аудит розмітки й одразу запустити донавчання BERT, модель вивчить помилки розмітників, і налаштуванням це вже не виправити. Нижче — шлях, яким іде робота.

1. Аудит корпусу й розмітки — частка суперечливих прикладів, дублі, дисбаланс класів, згода розмітників, належність текстів до цільового домену.
2. Постановка метрики — що критичніше: повнота за рідкісним класом чи точність за масовим. Фіксуємо базовий рівень на простій моделі, щоб у нейромережі був чесний орієнтир.
3. Схема класів — ієрархія рубрик, правила для спірних випадків, мінімум прикладів на клас. Узгоджуємо її з тими, хто розбиратиме передбачення вручну.
4. Донавчання — вибір попередньо навченої моделі та довжини вікна під типовий текст, балансування класів, зупинка за валідаційною вибіркою, а не за кількістю проходів.
5. Перевірка моделі — відкладена стратифікована вибірка, розбір помилок за класами й окремий прогін на текстах іншого періоду: так видно зсув даних, який середня метрика приховує.
6. Впровадження в процес — сервіс із версіюванням моделі, логуванням передбачень і порогом впевненості: спірні випадки йдуть людині, а не в автоматику.
7. Передача — код донавчання, конфігурації, чек-ліст повторного запуску, документація схеми класів та інструкція оператору з розбору сумнівних висновків.

Артефакти проєкту: ваги моделі, регламент розмітки

Клієнту залишається не «модель в архіві», а комплект, за яким команда може повторити навчання, перевірити якість і продовжити розмітку власними силами.

Передаємо чотири групи артефактів: ваги й конфігурацію запуску, документацію з моделі, регламент розмітки та інструкції для операторів.

• Ваги донавченої моделі та конфігурація виходу: поріг впевненості, відповідність міток класам, гілка базової архітектури — розгортається на новому сервері без звернення до нас.
• Документація з моделі: схема класів, обсяг і джерела навчальної вибірки, підібрані параметри навчання, зафіксовані обмеження за доменом і типом текстів.
• Звіт про якість на відкладеній вибірці: точність і повнота за кожним класом, матриця помилок, перелік типових хибних спрацювань із прикладами.
• Регламент розмітки: визначення кожного класу, розбір пограничних випадків, правило розв'язання розбіжностей між операторами.
• Інструкції для операторів: покроковий порядок розмітки, короткий набір з еталонними відповідями для навчання новачків, контрольний список самоперевірки.
• Скрипти підготовки й перевірки даних: пошук дублів, оцінка дисбалансу класів, відсів битих і занадто коротких текстів.
• Порядок повторного навчання: від сирих даних до нової версії моделі, з тими самими метриками для порівняння версій.
• Протокол приймання: зафіксовані пороги якості, порядок відкату на попередню версію, відповідальні за приймання.

Така передача знімає головний ризик — залежність від підрядника. Замовник бачить, на яких даних модель навчалася, де проходить межа її застосовності й за якою процедурою навчати новий клас, коли змінюється потік звернень.

Класифікація звернень підтримки: метрики до і після

Потік звернень до підтримки йшов через одну чергу: оператори вручну розподіляли їх за темами, і термінові повідомлення про збої стояли в загальній масі. Частка ручного сортування трималася близько 100%, а час до першої відповіді залежав від того, хто першим розбере чергу.

Ми почали з розмітки: зібрали історію звернень за кілька періодів, звели теми до стійкого словника класів і прибрали перетини, через які одне звернення підходило до двох категорій.

Базова модель на BERT давала macro-F1 0.61 на відкладеній вибірці — для маршрутизації без людини цього мало, тому донавчання йшло на збалансованих класах з окремим контролем якості на рідкісних темах.

Що змінювали під час проєкту

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

Що показали метрики після впровадження

macro-F1 на відкладеній вибірці зріс з 0.61 до 0.88, частка автоматично маршрутизованих звернень — до 74% потоку.

Час до першої відповіді в термінових категоріях скоротився приблизно втричі, а ручне сортування звелося до поодиноких випадків: підтримка клієнтів перестала бути вузьким місцем на вході.

Що робити, якщо вже працює модель на правилах і словниках

Повний перехід не потрібен і майже завжди шкідливий. Робоча схема — гібридний підхід: словники й правила продовжують закривати прості випадки, а навчана модель підключається до того, що вони не покривають.

Обидві гілки живуть на одному вході, і рішення про те, кому віддати текст, ухвалюється за порогом впевненості.

Маршрут будується так: спочатку відпрацьовує словник — точний збіг за шаблоном або стоп-листом закриває питання без моделі. Усе, що правила не розібрали або розібрали з низькою впевненістю, йде на модель. Кожна розбіжність логується — це готовий матеріал для наступної ітерації навчання.

Окремо готувати корпус зазвичай не потрібно: історія прогонів правил уже містить розмітку за класами. На ній навчається перша версія, а спірні випадки, де правило й модель розходяться, йдуть на ручний розбір і повертаються до вибірки.

Так якість зростає там, де вона критична, а не за всім словником одразу. Донавчання BERT і споріднених архітектур тут — не переписування системи, а заміна одного з вирішальних блоків.

Перехід без зупинки процесу робиться тіньовим режимом. Нова модель якийсь час рахує на живому трафіку, але її відповіді лише порівнюються з правилами й не впливають на видачу.

Коли розбіжність з еталоном укладається в заданий поріг, відкриваємо частку трафіку — спочатку малу, потім усю. Відкат — перемикання прапорця, словники залишаються на місці й продовжують працювати.

У підсумку правила перетворюються на страховку для рідкісних класів і жорстких вимог, а основне навантаження несе модель. Частка ручних розборів падає в рази, словники стискаються до справді критичних випадків — без зупинки й без втрати вже досягнутої якості.

Технічні сумніви: розмітка, обсяг даних, якість

Обсяг розмітки визначається не «магічним» числом, а кількістю класів, їхнім балансом і різноманіттям формулювань.

Для двох-трьох стійких категорій зазвичай вистачає кількох сотень прикладів на кожну; коли класів десятки і вони перетинаються за змістом, рахунок іде на тисячі, а частину корпусу дешевше добирати слабкою розміткою з ручною перевіркою спірних випадків.

Розрив між якістю на відкладеній вибірці та на реальному потоці — частіше наслідок розходження даних, а не помилки навчання.

Тому ми фіксуємо правила розмітки до старту, вичищаємо дублікати й майже однакові приклади, а контроль якості будуємо на розборі помилок: які пари класів модель плутає і на яких формулюваннях це відбувається.

Що робити, якщо розмітники суперечать один одному?

Суперечності не згладжуємо, а виносимо в окремий набір: фіксуємо правило для спірного випадку й перерозмічаємо пограничні приклади. Якщо два класи справді не відрізняються за текстом, їх об'єднують — інакше модель учиться вгадувати шум, і якість на потоці падає.

Як зрозуміти, що модель перенавчилася?

Ознака — метрика на навчальній вибірці зростає, а на відкладеній перестає покращуватися. Тоді зупиняємо навчання за відкладеною вибіркою, зменшуємо складність моделі й перевіряємо крос-валідацією за різними зрізами даних.

Окремо дивимося стійкість на коротких і нетипових текстах — там перенавчання проявляється найраніше.

Обговоримо задачу: які дані є і що потрібно на виході

Щоб оцінка була предметною, а не «на око», для першої розмови достатньо трьох речей: прикладів ваших текстів із розміткою або без неї, списку цільових класів і розуміння, як результат використовуватиметься — разова обробка накопиченого архіву чи постійний потік документів.

Цього достатньо, щоб оцінити обсяг, вибрати базову модель для донавчання BERT-сімейства й назвати терміни без здогадок.

З чим ми повертаємося після розбору:

• оцінка задачі: скільки розмічених прикладів не вистачає до стійкої якості та які класи модель плутає найчастіше;
• план робіт за етапами з точками контролю — від підготовки корпусу до передачі моделі;
• вимоги до даних замовника: формат, обсяг, схема розмітки, правила знеособлення;
• режим роботи: де розміщується модель, як оновлюється словник класів, що відбувається при появі нового класу;
• критерії приймання в цифрах: частка правильних відповідей і матриця помилок за кожним класом на відкладеній вибірці;
• склад команди та розподіл зон відповідальності на час проєкту.

Старт проєкту не вимагає, щоб дані вже були підготовлені: розбір корпусу й розмітку ми закладаємо в план, а не виносимо за його межі. Опишіть задачу — які тексти класифікуєте, скільки класів і де має жити результат, — і ми повернемося з оцінкою та планом робіт.