Донавчання LLM: де базова модель дає збій
Готова мовна модель бадьоро відповідає на загальні запитання й розсипається, щойно розмова переходить у вашу предметну область.
Вона плутає внутрішні абревіатури, підставляє схожий за звучанням термін замість вашого, впевнено називає неіснуючі пункти регламенту або посилається на документ, який було скасовано.
Механіка збою передбачувана: рідкісне слово розпадається на фрагменти, яких майже немає в навчальних текстах, і модель добудовує його за частотною аналогією з відкритих джерел.
Те, що прийнято називати галюцинацією моделі, тут не випадковий шум, а статистично найімовірніше продовження — просто неправильне для вашого контексту. Чим специфічніша галузева термінологія, тим менше опори має модель.
Виправлення підказок цього не закриває. Інструкції в підказці керують форматом і тоном, але не додають знань: перелічіть десять термінів в описі — на одинадцятому, у новому оточенні, модель знову піде в узагальнення.
Подовження контексту допомагає лише частково: відповідь стає повільнішою й дорожчою, а увага до середини довгого набору фактів розмивається.
Робочий шлях інший — розмітка даних за вашою лексикою та донавчання LLM на парах «реальне запитання — еталонна відповідь», включно з прикладами типових помилок і заборонених формулювань.
Ваги зміщуються до вашої термінології, і якість відповідей моделі перестає залежати від того, чи здогадався автор підказки перелічити все потрібне заздалегідь. Розбираємо, як це влаштовано і що саме визначає результат.
Ефект у метриках: точність, стійкість, швидкість відповіді
Метрики знімаємо на відкладеній вибірці — тих самих запитах, що надходять у промисловій експлуатації, з розміткою ваших експертів. Так відокремлюємо реальний приріст якості від підгонки під навчальні приклади, яка на нових формулюваннях обнуляється.
Точність на відкладеній вибірці після адаптації малої частини ваг зростає на 8–15 процентних пунктів на вузьких доменних задачах — цей порядок відтворюється в галузевих вимірюваннях (LoRA: Low-Rank Adaptation of Large Language Models).
Дивимося не на абсолютну цифру, а на розрив із базовою моделлю: він показує, скільки предметного знання система не добирала.
Стійкість відповідей рахуємо окремо: кожне формулювання проганяємо в кількох перефразуваннях і вимірюємо розкид. Після адаптації частка відповідей, що втрачають сенс під час переказу запитання, падає — модель тримається фактів домену, а не збігу формулювань.
Саме цей показник найчастіше провалює пілот: середня точність хороша, а на рідкісних кейсах відповіді непередбачувані.
Швидкість випуску змін вимірюємо циклом «нова порція даних → оновлена модель в експлуатації».
Адаптери навчаються кратно швидше за повне донавчання й не потребують повторного складання базової моделі: цикл скорочується з тижнів до годин, а відкат до попередньої версії залишається в одну команду.
Закриття звернень без оператора — підсумковий показник, він зростає як наслідок попередніх трьох. За ним і ухвалюється рішення, яка конфігурація адаптації йде в експлуатацію: решта метрик пояснюють, чому вийшло саме так.
Формати донавчання LLM: повний цикл, адаптери, квантування
Вибір формату донавчання — це компроміс між доступним обладнанням, обсягом розмічених даних і тим, наскільки сильно нова задача відрізняється від базової.
Якщо даних мало і потрібно лише підлаштувати стиль відповідей, повне оновлення ваг надлишкове: достатньо налаштування підказок або адаптерів. Коли задача потребує нової предметної логіки, оновлювати частину ваг уже необхідно — але не обов’язково всі.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Повне оновлення ваг | Задача далека від вихідної, даних багато | Високі вимоги до пам’яті, модель втрачає базові навички |
| Адаптери низького рангу (LoRA) | Потрібно підлаштувати формат відповідей, доменну лексику, тон | Якість упирається в якість і обсяг прикладів |
| Квантування моделі з адаптерами | Пам’яті мало, навчання йде на одній карті | Частина точності втрачається, потрібен акуратний підбір режиму |
| Адаптивні ранги | Заздалегідь неясно, які шари важливі для задачі | Довше налаштування, складніше відтворювати результат |
| Налаштування підказок замість навчання | Швидка перевірка гіпотези, даних майже немає | Гнучкість низька, нової навички модель не вивчить |
Ми не вибираємо формат за звичкою: спочатку проганяємо базову модель на вашому наборі й дивимося, де вона помиляється. Якщо помилки знімаються формулюванням запиту — навчання не потрібне взагалі.
Якщо ні — рахуємо, який варіант дає потрібну якість за ваших ресурсів, і лише після цього запускаємо цикл.
Етапи робіт: від аудиту даних до передачі моделі
Донавчання LLM — це не одне тренування, а послідовність кроків, де кожен спирається на результат попереднього. Сенс порядку простий: спочатку зрозуміти, на чому вчити й як вимірювати, і тільки потім вибирати режим і запускати навчання. Нижче — маршрут, яким іде проєкт.
- Аудит даних. Зводимо корпус в єдиний формат, прибираємо дублі й перетини між майбутніми вибірками, перевіряємо якість розмітки та права на використання. На виході — звіт про склад даних і перелік прогалин, які закриваємо розміткою.
- Постановка метрики. Фіксуємо до навчання, що вважаємо успіхом саме на вашій задачі: точність на цільовому зрізі, частка відмов, дотримання формату відповіді, час відповіді. Без цього результат неможливо прийняти об’єктивно.
- Схема навчання. Вибираємо режим донавчання — LoRA, QLoRA або AdaLoRA — за доступною пам’яттю та обсягом корпусу, визначаємо цільові шари, ранг адаптера й порядок розбиття прикладів.
- Валідаційна вибірка. Відкладаємо стратифікований набір за складними й рідкісними випадками, який не бере участі в навчанні. На ньому перевіряємо кожну проміжну версію адаптера, а не лише фінальну.
- Перевірка на відкладених даних. Порівнюємо результат із базовою моделлю та поточним рішенням, розбираємо помилки за категоріями й окремо дивимося, чи не підлаштувалася модель під стиль розмітки замість суті.
- Приймання результату. Проганяємо модель на ваших сценаріях разом із вашими експертами, звіряємо із зафіксованими метриками та порогом відмов, оформлюємо протокол приймання.
- Передача в експлуатацію. Віддаємо адаптери, конфігурації запуску, скрипти відтворення та інструкцію з перенавчання на нових даних, допомагаємо підключити модель до вашого контуру.
Артефакти передачі: конфігурації, схеми та регламенти
Передача не закінчується на вагах адаптерів: якщо разом із ними не передаються конфігурації та регламенти, команда через місяць не відтворить навчання й не зрозуміє, чому модель відповідає саме так.
Тому комплект передачі фіксуємо як інженерний документ — за ним роботу продовжує людина, яка не брала участі в проєкті.
- Конфігурації навчання — гіперпараметри, розбивка даних, зерно генератора, цільові модулі адаптерів: повторний прогін дає той самий результат.
- Картка моделі — базова модель та її редакція, склад і обсяг вибірки, відомі обмеження й типи запитів, де якість просідає.
- Регламент оновлень — тригери перенавчання, порядок прогону, критерії приймання й точка відкату на попередній адаптер.
- Моніторинг якості — перевірки та метрики, які рахуються на потоці, пороги спрацювання й порядок ескалації при просіданні.
- Інструкція для підтримки — розгортання, перемикання версії адаптера, відкликання невдалого релізу й що додати до звернення.
- Схема архітектури — шлях запиту до відповіді моделі, місця зберігання артефактів і залежності між сервісами.
- Журнал рішень — чому вибрано такий ранг адаптерів і спосіб квантування, які альтернативи відхилили й з якої причини.
Кожен пункт перевіряємо на прийманні: якщо сторонній інженер за цими документами піднімає навчання й відкочує реліз без питань до нас — передача відбулася.
Кейс: точність відповідей зросла на реальних зверненнях
Замовник — сервісна служба з потоком звернень у чат. Базова модель загального призначення відповідала виразно приблизно на 6 запитань із 10, але плутала умови двох схожих послуг, зліплювала їх в одну відповідь і впевнено називала терміни, яких у регламенті не було. Оператор перевіряв кожну відповідь вручну, і швидкість відповіді трималася тільки завдяки людям.
Ми зібрали історію листування, прибрали дублі й суперечливі приклади, розмітили еталонні відповіді та донавчили модель адаптерами LoRA.
Ваги самої моделі залишилися недоторканими: оновлення займало хвилини, а не години, і відкат на попередню ревізію робився однією командою — без повторного складання й випуску.
Після впровадження частка відповідей, прийнятих без редагування, зросла з 58% до 89%, а звернення, що йшли до оператора, скоротилися з 34% до 11%.
Середній час першої відповіді впав із трьох хвилин до 25 секунд, навантаження на зміну знизилося майже втричі — оператори зайнялися складними випадками замість типових.
Розбір помилок показав, де залишилися провали: питання на стику двох послуг і винятки з умов. Їх ми винесли в окремий набір перевірок і перенавчаємо адаптер у міру накопичення розібраних звернень.
Точність на контрольній вибірці тримається на одному рівні й не просідає після чергового оновлення — це й стало головним критерієм приймання.
Чим адаптери відрізняються від повного оновлення ваг?
Адаптери й повне оновлення ваг розв’язують одну задачу — змістити поведінку моделі під конкретні дані, — але по-різному витрачають ресурси.
За повного донавчання змінюються всі параметри: у пам’яті тримають ваги, градієнти й стани оптимізатора, а результат живе окремою копією моделі.
Звідси головна відмінність за ресурсами: повне оновлення потребує кратно більшого запасу відеопам’яті й розтягує навчання пропорційно до розміру моделі.
LoRA навчає низькорангові добавки до заморожених шарів — частка параметрів, що навчаються, падає до відсотків, вимоги до заліза знижуються.
QLoRA додатково квантує базові ваги й дозволяє донавчати великі моделі на одній машині, а AdaLoRA перерозподіляє ранг між шарами, віддаючи ємність важливим.
Адаптер — компактний файл, який підключається до незмінної базової моделі. Можна тримати кілька адаптерів під різні домени — підтримку, юридичні тексти, технічну документацію — і перемикати їх на льоту. Повне оновлення так не масштабується: кожен варіант — самостійний набір ваг.
Адаптери зачіпають менше параметрів, тому базові знання й логіка моделі страждають слабше — катастрофічне забування проявляється рідше. Зворотний бік — обмежена ємність: зміна предметної області цілком або нова мова потребують повного донавчання.
Метод вибираємо від задачі: правка стилю й формату — LoRA, велика модель за жорстких обмежень пам’яті — QLoRA, неоднорідні дані, де шари важливі по-різному, — AdaLoRA.
Єдиний інтерфейс до них дає бібліотека Hugging Face PEFT: конфігурація адаптера описується декларативно й однаково відтворюється під час навчання та під час виведення.
Технічні сумніви, з якими приходять перед стартом
Перед стартом донавчання LLM зазвичай звучать ті самі запитання: чи вистачить даних, де будуть лежати приклади, скільки чекати першого результату й хто відповідає за модель після розгортання. Нижче — короткі відповіді по суті; нестандартний випадок розберемо окремо.
Прикладів лише кілька тисяч — навчання має сенс?
Так. LoRA і QLoRA правлять невелику частку параметрів, тому домен підхоплюється на корпусі, у рази меншому за попереднє навчання. Вирішує не обсяг, а покриття: важливі крайові випадки, де модель помиляється зараз.
Розмітку збирали роками й різні люди — їй можна довіряти?
Рахуємо узгодженість на подвійній розмітці й розбираємо розбіжності. Спірні класи переформулюємо, за рештою навчаємо й перевіряємо на відкладеній вибірці. Якість розмітки дає більше приросту, ніж зміна методу навчання.
Дані не можуть покидати наш контур. Це здійсненно?
Так. Навчання розгортаємо на вашій інфраструктурі: датасет і адаптери залишаються всередині, доступ — за ролями, дії записуються в журнал. Назовні йдуть лише метрики якості та версії артефактів.
Скільки часу до першого результату?
Робочий адаптер — тижні, а не місяці: підготовка корпусу, базова лінія, навчання, оцінка на відкладеній вибірці. Терміни частіше зсуває не навчання, а узгодження критеріїв якості.
Хто відповідає за модель після запуску?
Ми. Ведемо метрики якості, стежимо за дрейфом даних і перенавчаємо за тригером. Кожен адаптер версіонується, тому відкат до попередньої робочої версії — одна команда.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Щоб повернутися з оцінкою термінів і планом робіт, а не із загальними формулюваннями, нам потрібен мінімум контексту про вашу задачу.
Розкажіть, яку модель і на яких даних плануєте донавчати та що саме має змінитися в її відповідях — цього достатньо, щоб назвати діапазон трудовитрат і порядок етапів.
Що надіслати для оцінки:
- опис задачі та приклади запитів, на яких поточна модель помиляється;
- вибірку прикладів у тому вигляді, у якому вона у вас зберігається, — навіть кілька сотень рядків уже інформативні;
- де рішення працюватиме: ваш контур чи зовнішнє середовище;
- очікуване навантаження — скільки запитів на добу й яка швидкість відповіді вважається прийнятною;
- критерії приймання: що вважаємо успіхом, крім «відповідає краще».
На дзвінку уточнимо схему розмітки й обсяг вибірки під вибраний метод, чи потрібно донавчати всю модель або достатньо адаптерів, як поділимо дані на навчання й перевірку та чим будемо виявляти деградацію на рідкісних сценаріях.
План робіт збираємо з етапів: підготовка й очищення даних, базова лінія на поточній моделі, навчання, порівняння на відкладеній вибірці, пакування й передача з документацією.
Пілот на ваших даних іде до основного етапу — він показує реальний приріст якості та знімає питання щодо термінів. Опишіть задачу — повернемося з оцінкою та планом.
