Fine-tuning аналіз тональності: де ламається готова модель
Готова модель навчена на загальному корпусі та впевнено розрізняє «подобається / не подобається» в нейтральних текстах.
На галузевих даних точність класифікатора просідає до 60–70%: модель не знає, що «гарячий» у відгуках на техніку — це плюс, а «холодний» у клієнтських історіях — мінус. Доменна лексика змінює знак оцінки, а універсальний словник цього не бачить.
Сарказм і змішані відгуки ламають найсильніше. «Ну спасибі, три дні чекав» формально містить подяку, а за змістом — претензію; відгук «доставка швидка, але товар прийшов м'ятим» несе дві протилежні оцінки в одному реченні, і модель усереднює їх у нейтраль.
На потоці це дає хибні спрацювання: негатив іде в нейтральний кошик, служба підтримки не бачить проблему, а метрики якості виглядають благополучно.
Fine-tuning аналіз тональності вирішує це за рахунок дообучення моделі на вашій розмітці відгуків. Ми збираємо корпус із реальних звернень, розмічаємо спірні випадки — сарказм, заперечення, змішані оцінки — і дообучаємо модель на цих прикладах.
Модель перестає опиратися на загальний словник і вчиться на ваших формулюваннях: жаргоні галузі, назвах товарів, типових претензіях.
Ключовий етап — якість розмітки. Якщо два розмітники ставлять різні мітки на один текст, модель вивчить шум замість сигналу.
Тому ми фіксуємо правила розмітки, проганяємо спірні приклади через узгодження і тримаємо окрему вибірку для перевірки — вона не бере участі в навчанні та показує реальну точність класифікатора, а не підігнану під навчальний набір.
На виході — модель з F1 до 95% на вашому домені замість 60–70% в універсальної. Розбираємо, як це закривається на ваших даних.
Що дає донавчання під ваш корпус текстів
Донавчання починається не з моделі, а з вашого корпусу: вивантаження звернень, відгуків, тікетів і коментарів за період, розмітка класів і прикордонних випадків силами ваших же експертів.
Модель, навчена на загальному масиві текстів, упевнено розрізняє «добре/погано», але ламається на галузевій лексиці — назвах тарифів, внутрішньому сленгу, скороченнях. Донавчання на ваших прикладах переносить розпізнавання саме ваших формулювань, а не усередненої мови інтернету.
Hugging Face і відкриті попередньо навчені моделі дають стартову точку: ми не збираємо класифікатор з нуля, а адаптуємо готову мовну модель під вашу розмітку.
Це скорочує обсяг потрібних прикладів і час до робочої версії — але якість усе одно визначається тим, наскільки акуратно розмічені прикордонні випадки: сарказм, змішана тональність, нейтральні згадки бренду.
Що змінюється в цифрах
Метрика F1 — зведена точність і повнота — на загальному корпусі тримається в районі 0,7–0,8, на вашому після донавчання виходить до 0,93–0,95. Практичний сенс в іншому: частка звернень, що йдуть на ручну модерацію, падає з більшості до одиничних відсотків.
Залишок — це якраз спірні кейси, де рішення людини дійсно потрібне, а не механічна переперевірка очевидного.
Стійкість до реального тексту
Окремий етап — перевірка на «брудних» даних: одруки, трансліт, латиниця впереміш із кирилицею, розтягнуті голосні, емодзі замість слів.
Класифікатор, який не бачив такого на навчанні, втрачає точність на 15–20 пунктів; донавчений з аугментацією — тримає якість класифікації в межах пари пунктів від чистого тексту. Це і є різниця між демо і системою, яка працює на живому потоці.
Підходи до навчання: порівняння за задачею та даними
Вибір між готовою моделлю, донавчанням попередньо навченої моделі та навчанням з нуля визначається не модою, а обсягом корпусу та якістю розмітки даних.
Ми завжди починаємо з оцінки того, що вже є: якщо у замовника накопичені десятки тисяч розмічених відгуків із згодою розмітників, донавчання дає передбачуваний результат швидко.
Якщо корпус маленький і шумний, чесніше сказати про це до старту, ніж обіцяти точність, яку дані не витримають.
Ключовий компроміс — між вартістю розмітки та стелею якості. Донавчання попередньо навченої моделі потребує в рази менше прикладів, ніж навчання з нуля, але успадковує зміщення вихідного корпусу.
Навчання з нуля виправдане лише на вузьких доменах із власною мовою — там, де загальна модель систематично помиляється на термінології.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готова модель без донавчання | Швидкий старт, загальна тональність, немає власних даних | Не знає галузевої лексики, стеля точності низька |
| Донавчання попередньо навченої моделі | Є 1–5 тис. розмічених прикладів, потрібен баланс швидкості та якості | Потребує чистої розмітки, чутливе до дисбалансу класів |
| Навчання з нуля | Вузький домен, власний словник, великий корпус | Потрібні десятки тисяч прикладів, довше та дорожче в підтримці |
На практиці найчастіше виграє донавчання: воно дає прийнятний F1 вже на невеликому корпусі, а якість зростає в міру накопичення розмітки.
Ми закладаємо цикл, у якому модель донавчається на нових прикладах, а метрики відстежуються на відкладеній вибірці — так точність не деградує з часом.
Як відбувається впровадження класифікатора
Впровадження починається не з навчання моделі, а з аудиту того, що вже є: вивантажень звернень, логів підтримки, відгуків, тікетів.
На цьому етапі ми дивимося, яких класів бракує, де розмітка суперечлива, скільки прикладів на рідкісні категорії — зазвичай дисбаланс у 10-20 разів, і без його вирівнювання модель просто вивчить частий клас.
Далі фіксуємо схему розмітки: список класів, правила віднесення, спірні випадки з прикладами. Це документ, за яким розмічають люди і за яким потім перевіряють модель, — без нього метрики на валідації нічого не означають.
- Аудит даних і поточної розмітки. Зводимо джерела, рахуємо розподіл класів, знаходимо дублі та шум, оцінюємо, чи достатньо прикладів на кожен клас.
- Схема розмітки та інструкція для аннотаторів. Формалізуємо класи, правила, прикордонні випадки; узгоджуємо з вашою командою, що саме вважається потрібною тональністю.
- Дорозмітка та чистка корпусу. Доповнюємо рідкісні класи, знімаємо суперечності, перевіряємо узгодженість між розмітниками на контрольній вибірці.
- Розділення даних. Відкладаємо валідацію і тест так, щоб до них не потрапили дублі з навчання, — інакше метрика завищується і на реальних даних модель просідає.
- Fine-tuning і підбір параметрів. Навчаємо на розміченому корпусі, порівнюємо з базовою моделлю і простими правилами, відбираємо конфігурацію за F1 на відкладеній вибірці, а не за accuracy.
- Валідація моделі. Дивимося F1 за кожним класом окремо, матрицю помилок, поведінку на рідкісних категоріях і на текстах поза навчальним розподілом.
- Передача в експлуатацію. Розгортаємо inference, налаштовуємо моніторинг частки та впевненості передбачень, документуємо, як донавчати модель на нових даних.
Контроль якості вбудований у кожен етап: без узгодженої розмітки не буває чесної метрики, без відкладеного тесту — відтворюваного результату.
На виході ви отримуєте не лише модель, а й корпус, інструкцію розмітки та процедуру донавчання — те, що дозволяє утримувати якість, коли змінюється потік звернень.
Артефакти: що залишається у вашої команди
Класифікатор тональності — це не «навчена модель на сервері», а комплект, який ваша команда може запустити, перевірити й перенавчити без нас.
Тому передаємо не лише інференс, а й усе, що потрібно для відтворення результату: від розмічених даних до регламентів, за якими контролюється якість на нових потоках тексту.
- Ваги моделі — навчений сентимент-класифікатор із зафіксованим порогом упевненості, версія прив'язана до набору даних і конфігурації навчання, щоб результат відтворювався однозначно.
- Схема розмітки — інструкція для аннотаторів: категорії тональності, правила для змішаних та іронічних висловлювань, розбір спірних випадків із прикладами, порядок розв'язання розбіжностей між розмітниками.
- Розмічений датасет — навчальна, валідаційна та відкладена вибірки із зафіксованим розбиттям, щоб метрики на нових запусках порівнювалися з вихідними на тих самих даних.
- Скрипти перенавчання — конфігурації fine-tuning, підготовка ознак, контроль перенавчання, розрахунок F1 за класами; запускаються однією командою на ваших даних.
- Регламент контролю якості — періодичність перевірок, метрики та пороги деградації, порядок дій при падінні F1 нижче узгодженого рівня.
- Моніторинг і логування — дашборд за розподілом передбачень і часткою низької впевненості, вивантаження сумнівних прикладів на додаткову розмітку.
- Документація та передача — опис архітектури, інструкції із запуску та оновлення, спільна сесія з вашими інженерами щодо розгортання на вашій інфраструктурі.
Окремо фіксуємо критерії приймання: частка правильних відповідей на відкладеній вибірці, стійкість до зміни формулювань і відсутність просідання на рідкісних класах. Так ви отримуєте не чорну скриньку, а керований актив, який розвивається силами вашої команди.
Кейс: класифікатор тональності для потоку відгуків
Замовник — маркетплейс із потоком відгуків кількома мовами. Базова модель на відкритих даних давала прийнятну якість на «позитиві» та «негативі», але плутала рідкісні класи: сарказм, приховану претензію до доставки, скаргу на конкретного продавця. Ручна розмітка з'їдала ресурс команди підтримки, а частина звернень потрапляла не в ту чергу.
Ми зібрали корпус з історії звернень замовника, розмітили спірні випадки разом з його експертами та донавчили модель на цьому домені.
Окремо попрацювали над рідкісними класами: додали ваги у функцію втрат і синтетичні приклади для недопредставлених категорій, зафіксували поріг впевненості, нижче якого запис іде на ручну перевірку.
Hugging Face використовували як основу для роботи з попередньо навченими моделями та їх донавчання на корпусі замовника.
Метрики до та після
| Клас | F1 до | F1 після |
|---|---|---|
| Позитив | 0.91 | 0.96 |
| Негатив | 0.88 | 0.95 |
| Сарказм | 0.54 | 0.89 |
| Претензія до доставки | 0.61 | 0.92 |
| Скарга на продавця | 0.58 | 0.90 |
Підсумковий F1 за всіма класами зріс з 0.72 до 0.94, частка записів, що йдуть на ручну перевірку, скоротилася з 38% до 9%. На рідкісних класах розкид між запусками звузився — модель перестала «стрибати» на сарказмі та прихованих претензіях, які раніше потрапляли в нейтральні.
Що це дало в роботі
Черга підтримки перестала тонути в ручному сортуванні: інженери розбирають лише пограничні випадки, а не весь потік. Класифікатор оновлюється на нових даних без перезбирання з нуля — донавчання на свіжому зрізі відгуків займає години, а не тижні.
Чим донавчання відрізняється від підказок у запиті
Керування поведінкою через формулювання запиту — це робота з контекстом: ви описуєте правила в промпті, наводите приклади прямо в тексті й сподіваєтеся, що модель їх утримає.
Такий шлях добрий для прототипу: не потрібні дані, розмітка, навчання — змінили інструкцію й одразу побачили результат. Але поведінка моделі залишається ймовірнісною.
На довгих текстах, на змішаній тональності, на іронії та галузевому сленгу інструкція починає «пливти»: модель то дотримується правила, то ігнорує його, а на однакових входах видає різні відповіді.
Відтворюваності немає — при наступному оновленні базової моделі поведінка зсунеться, і вам доведеться заново підбирати формулювання.
Донавчання переносить правила з промпту у ваги. Ви розмічаєте свої приклади — реальні відгуки, звернення, коментарі з вашою лексикою — і модель навчається на них, а не на загальних уявленнях про мову.
Це дає керовану поведінку: класи тональності визначені вами, межі між ними зафіксовані, а результат на одному й тому самому вході повторюваний. Метрика перестає бути «на око» — якість вимірюється на відкладеній вибірці, і ви бачите, де модель помиляється і чому.
Вартість інференсу теж розвертається в інший бік. Промпт з докладними інструкціями та прикладами — це довгий контекст на кожен запит, і платите ви за нього при кожному зверненні. Донавчена модель розв'язує ту саму задачу коротким входом: надходить текст — повертається мітка. На потоці в тисячі документів це різниця в рази за обсягом обробки та за затримкою відповіді.
Практичний висновок: підказки в запиті — для швидкої перевірки гіпотези та рідкісних сценаріїв, донавчання — коли задача повторюється, якість потрібна вимірювана, а поведінка моделі має бути передбачуваною.
Часто розумний шлях — почати з промпту, зібрати на ньому перші розмічені приклади, а потім перейти до fine-tuning на цих самих даних.
Часті технічні сумніви
Скільки розмічених даних реально потрібно для fine-tuning?
Для вузької задачі — відгуки про продукт, звернення до підтримки, коментарі до замовлень — робоча точність досягається на кількох тисячах розмічених прикладів.
Ключове не кількість, а узгодженість розмітки: якщо два розмітники по-різному трактують «нейтрально» та «змішано», модель вивчить шум, і F1 упреться в стелю незалежно від обсягу.
Тому ми спочатку фіксуємо інструкцію розмітки й проганяємо на ній спірні приклади, а вже потім масштабуємо.
Що робити з дисбалансом класів?
У реальних даних негатив майже завжди в меншості, і модель, навчена «як є», просто передбачає мажоритарний клас. Ми працюємо не з однією метрикою accuracy, а з F1 по кожному класу окремо, і вирівнюємо ваги класів під час навчання.
Додатково перевіряємо поріг спрацювання на відкладеній вибірці — так рідкісний, але важливий клас не губиться.
Як підтримувати модель після запуску?
Мова змінюється: з'являються нові формулювання, сленг, товарні назви. Ми налаштовуємо моніторинг дрейфу — відстежуємо розподіл передбачень і частку низької впевненості. Коли метрики просідають, дообучаємо модель на свіжих прикладах, не перезбираючи весь контур з нуля. Версіонування моделей і розмітки зберігає можливість відкату до попередньої версії.
Що якщо якість після запуску виявиться нижчою за очікувану?
Ми заздалегідь домовляємося про цільову метрику та спосіб її вимірювання на незалежній вибірці. Якщо модель не дотягує, розбираємо помилки за класами: де плутанина в розмітці, де бракує прикладів, де потрібна інша ознака. Це інженерна робота зі зрозумілим планом, а не «докрутимо й подивимось».
Обговоримо ваше завдання класифікації
Щоб оцінка була предметною, а не «плюс-мінус порядок», на першій розмові нам потрібні ваші дані та контекст застосування. Надішліть те, що є — навіть сирі вивантаження без розмітки підійдуть: за ними ми зрозуміємо обсяг, класи тональності та реальну складність задачі.
Що корисно підготувати:
- 200–500 реальних прикладів текстів із вашого потоку — відгуки, звернення, коментарі, листи: за ними видно мову, сленг, довжину та змішування тем.
- Поточну розмітку, якщо вона є: скільки класів, хто і за якою інструкцією розмічав, де спірні випадки.
- Цільові метрики: яка частка правильних відповідей вважається робочою і на яких класах помилка критичніша.
- Як результат вбудовується в процес: пакетна обробка вивантажень, відповіді в реальному часі або розбір у панелі.
- Обмеження: мови та діалекти, вимоги до зберігання даних, де дозволено розміщувати модель.
- Що вже пробували: готові сервіси, ручна розмітка, правила за словниками — і чому результат не влаштував.
На дзвінку розберемо, як модель поводитиметься на ваших класах, де знадобиться донавчання на ваших прикладах, а де вистачить налаштування готової моделі. Обговоримо схему розмітки, порядок перевірки якості та точки, де рішення можна скоригувати без переробки. Опишіть задачу — повернемося з оцінкою термінів і планом робіт за етапами.
