Чому базова модель не розв'язує задачу на ваших даних
Базова модель навчена на широкому зрізі інтернету й упевнено розмірковує про погоду чи кулінарію, але ваша предметна область у цьому зрізі представлена фрагментарно. Вона не знає вашої номенклатури, внутрішніх регламентів, історії звернень і прийнятих у вас скорочень.
На демо це непомітно: запитання ставлять загальні, відповіді звучать складно. Проблема проявляється на реальних даних — там, де відповідь має спиратися на конкретний документ, а не на усереднене уявлення про тему. Саме на цьому стику й ламається впровадження без fine-tuning Mistral.
Перше, що вилазить, — загальні фрази замість фактів. Модель відповідає «це залежить від умов договору» там, де у вас є однозначне формулювання в регламенті. Вона не помиляється формально, але й не приносить користі: співробітник отримує переказ теми замість відповіді по суті.
Друге — формат. Без дообучення мовної моделі важко втримати структуру відповіді: поля, порядок блоків, обов'язкові застереження, одиниці вимірювання. Модель «пливе» від запиту до запиту, і обв'язка, яка розбирає її вивід, починає падати на несподіваних варіантах.
Третє й найдорожче — термінологія. У вузькій області одні й ті самі слова означають різне, а ваші внутрішні скорочення модель може впевнено трактувати по-своєму.
Адаптація моделі під предметну область потрібна не для «краси складу», а щоб вона розрізняла ваші сутності й не змішувала їх зі схожими із загального корпусу. Промпт-інжиніринг тут допомагає частково: він звужує поведінку, але не додає знань, яких у вагах немає.
Щойно запитання виходить за приклади з інструкції, якість відповідей на доменних даних знову просідає.
Звідси практичний висновок: дообучення — це не заміна пошуку за документами й не спроба «зашити все в модель». Це спосіб закріпити в ній стиль, формат і термінологію, а факти підтягувати з ваших джерел.
Розбираємо, як це закривається: які методи дообучення підходять під різні обсяги даних і заліза, де проходить межа між навчанням і підстановкою контексту та як виміряти, що модель справді стала відповідати по вашій предметній області.
Що дає fine-tuning mistral: режими LoRA та QLoRA
Fine-tuning Mistral через адаптери вирішує головну проблему базової моделі: вона відповідає «в середньому по інтернету», а не в термінах вашої предметної області.
LoRA заморожує вихідні ваги й навчає невеликі низькорангові матриці — кількість налаштовуваних параметрів падає на два-три порядки, тому навчання відбувається на одній відеокарті замість кластера, а сама адаптація займає години, не тижні.
QLoRA додає до цього квантування базових ваг у 4-бітний формат: вимоги до пам'яті знижуються ще приблизно втричі, і дообучення стає можливим на споживчому залізі без втрати якості на цільовій задачі.
Де ефект вимірний
На типових сценаріях — класифікація звернень, витяг сутностей з договорів, відповіді за внутрішньою базою знань — дообучений адаптер піднімає точність на цільовому класі з 60–70% до 85–92% за того самого промпту.
Модель перестає «плисти» у форматі відповіді: частка валідного JSON без повторних спроб зростає з 70% до 98%. Адаптер важить десятки мегабайт, тому версіонується й відкочується як звичайний артефакт, а не як багатогігабайтний чекпоінт.
Порівняння режимів дообучення
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| LoRA | Є GPU із запасом пам'яті, потрібна максимальна точність на складній задачі | Потребує більше пам'яті під базові ваги та оптимізатор |
| QLoRA | Одна відеокарта, обмежений бюджет на залізо, швидкий старт | Квантування дає невелику просадку на рідкісних класах |
| Повне дообучення | Змінюється сама природа задачі, домен далекий від навчального корпусу | Дорого, довго, ризик катастрофічного забування |
| Промпт-інжиніринг без навчання | Задача проста, даних мало, потрібна відповідь за день | Не тягне складні формати й вузьку термінологію |
Вибір між LoRA та QLoRA — це компроміс між запасом за якістю та доступним залізом, а не «найкращий/найгірший». Ми проганяємо обидва режими на вашому датасеті й показуємо метрики на відкладеній вибірці, а не обіцянки.
Працюємо з відкритими вагами через Hugging Face і стек на PyTorch — це дає відтворюваність і перенесення адаптера у ваш контур без прив'язки до чужого API.
Як відбувається впровадження дообученої моделі: етапи робіт
Дообучення — це не «запустити навчання й зачекати». Основний час іде на підготовку даних і перевірку якості, а сам прогін навчання — лише один з етапів.
Нижче — маршрут, яким іде наша команда: від аудиту даних до передачі моделі в експлуатацію, з контролем результату на кожному кроці.
- Аудит даних і постановка задачі. Дивимося, що вже є: логи звернень, листування, база знань, готові пари «питання-відповідь». Визначаємо, який результат вважаємо успішним — точність на тестовій вибірці, частку коректних відмов, формат відповіді. Без цього критерію навчання перетворюється на вгадування.
- Підготовка датасету. Чистимо дублі й сміття, приводимо приклади до єдиного формату, розмічаємо складні випадки. Дані ділимо на навчальну, валідаційну та відкладену тестову частини — остання не бере участі в навчанні й слугує чесним заміром.
- Вибір методу дообучення. Під задачу та обсяг даних підбираємо підхід: повне дообучення, LoRA або QLoRA. Для більшості прикладних сценаріїв достатньо адаптерів — вони дають потрібну якість за менших вимог до обладнання.
- Навчання й підбір параметрів. Прогоняємо кілька конфігурацій, стежимо за перенавчанням за валідаційною вибіркою. Фіксуємо версію даних і параметри, щоб результат можна було відтворити.
- Валідація моделі. Перевіряємо не лише метрики, а й поведінку: стійкість до перефразувань, відсутність вигаданих фактів, коректні відмови на питаннях поза темою. Порівнюємо з базовою моделлю — дообучена має бути кращою, а не просто іншою.
- Передача в експлуатацію. Розгортаємо модель у вашому контурі або в нас, налаштовуємо моніторинг якості та логування запитів. Віддаємо документацію: як оновлювати дані, як перенавчати, як відкотитися на попередню версію.
- Підтримка після запуску. Збираємо зворотний зв'язок із реальних запитів, дорозмічаємо спірні випадки й плануємо наступну ітерацію дообучення.
Кожен етап закінчується артефактом: розмічений датасет, зафіксована конфігурація, звіт за метриками, інструкція з експлуатації. Опишіть задачу й дані, які є на вході, — повернемося з оцінкою та планом робіт.
Чим LoRA відрізняється від QLoRA і що вибрати під навантаження
LoRA навчає невеликі низькорангові матриці-адаптери поверх заморожених ваг базової моделі: самі ваги не змінюються, оновлюється лише доданий шар.
Це знижує обсяг параметрів, що навчаються, на порядки і дозволяє дообучати модель на одній-двох відеокартах, не піднімаючи повний кластер.
Класичний LoRA тримає базові ваги в повній точності — зазвичай 16 біт — і вимагає, щоб вони повністю поміщалися в пам'ять разом із градієнтами адаптерів і активаціями.
QLoRA додає до цього квантування моделі: базові ваги зберігаються в 4-бітному форматі, а адаптери, як і раніше, навчаються в 16 бітах. Пам'ять під ваги падає приблизно вчетверо, і модель, яка раніше вимагала кількох прискорювачів, вкладається в один.
Плата за це — розпакування ваг на кожному кроці прямого та зворотного проходу: навчання йде повільніше, а на довгих послідовностях розрив у швидкості помітніший.
Вибір режиму адаптації впирається у вимоги до ресурсів і в те, наскільки чутлива задача до точності. Якщо прискорювачів достатньо і важлива швидкість ітерацій — беруть класичний LoRA.
Якщо пам'ять обмежена, а модель велика, QLoRA дає можливість запустити дообучення там, де повний варіант просто не вміщується.
На підсумковій якості при акуратно підібраному ранзі та розумній довжині контексту різниця найчастіше лежить у межах похибки, але її варто перевіряти на валідаційній вибірці, а не приймати на віру.
Окремо варто пам'ятати про ранг адаптерів і цільові шари: занадто маленький ранг недоучує задачу, занадто великий — повертає ризик перенавчання і зайву витрату пам'яті.
Наші інженери підбирають ці параметри під конкретний датасет і профіль навантаження, а не за замовчуванням із документації.
Кейс: донавчання Mistral для служби підтримки
Донавчання запускали для служби підтримки з каталогом типових звернень: оператори відповідали за регламентом, але базова модель регулярно переходила у вільний переказ, втрачала обов'язкові поля та плутала категорії.
Ручне виправлення кожної другої відповіді з'їдало час першої лінії, а частка коректних відповідей за регламентом трималася близько 60%.
Зібрали датасет із реальних діалогів із розміткою: еталонна відповідь, категорія звернення, обов'язкові поля.
Навчали адаптери LoRA поверх базової моделі — повний fine-tuning mistral не вимагався, ваги не переписувалися повністю, тому навчання йшло на одній відеокарті й зайняло години, а не добу.
Окремо зафіксували перевірний набір зі звернень, яких не було в навчанні, — щоб метрики відображали поведінку на нових запитах, а не запам'ятовування прикладів.
Що змінилося в метриках
| Метрика | До | Після |
|---|---|---|
| Коректна відповідь за регламентом | ~60% | ~92% |
| Дотримання формату (поля, тон, структура) | ~55% | ~97% |
| Частка відповідей із ручним виправленням | ~50% | ~12% |
| Відповіді з вигаданими умовами | регулярно | поодинокі випадки |
Дотримання формату зросло найбільше, тому що модель навчалася не «правильному тону взагалі», а конкретному шаблону відповіді з обов'язковими полями. Ручні виправлення скоротилися майже вчетверо — оператор тепер перевіряє й підтверджує, а не переписує з нуля.
Як утримали якість
Донавчання не віддає все на відкуп моделі: відповіді проходять перевірку на відповідність регламенту, а спірні випадки йдуть оператору. Ми заклали механізм відкату — якщо якість на нових зверненнях просідає, попередня версія адаптерів повертається без перенавчання.
Для навчання використовували Mistral AI — відкрита архітектура дозволяє тримати модель на своєму контурі, без передачі звернень клієнтів назовні.
Сумісність, доступи та відкат: що обговорити до старту
Дообучення моделі — це не окремий експеримент у вакуумі, а новий артефакт у вашому контурі: його потрібно десь розмістити, до чогось підключити і мати можливість відкотити.
Тому до старту ми фіксуємо три речі: де буде жити модель (ваш закритий контур, хмара або гібрид), які дані та сервіси вона побачить, і як ми повернемо систему в початковий стан, якщо якість відповідей виявиться нижчою за очікувану.
Адаптери важать небагато і зберігаються окремо від базової моделі — це і є точка відкату: перемикання на попередній адаптер повертає попередню поведінку без перезбирання всього контуру.
Що буде, якщо навчена модель почне відповідати гірше, ніж базова?
Ми не замінюємо робочу модель, а підключаємо адаптер поверх неї. Відкат — це перемикання на попередній адаптер або на базову модель, займає хвилини і не зачіпає інші сервіси.
Перед виведенням у роботу проганяємо набір контрольних запитів і порівнюємо відповіді з вихідними — рішення про перемикання приймається за цифрами, а не за відчуттями.
Що якщо у нас закритий контур без виходу назовні? Навчання та інференс розгортаються всередині вашої інфраструктури, дані не залишають периметр. Хто отримає доступ до даних?
Працюємо за принципом мінімальних прав: доступ видається лише інженерам на задачі, логується і закривається після завершення. Що якщо модель уже використовується в проді? Новий адаптер іде окремим маршрутом, переведення трафіку — керований крок з можливістю повернути попередній.
Після здачі ви отримуєте на руки:
- конфігурації навчання та інференсу з описом параметрів;
- схему розміщення моделі у вашому контурі та вимоги до ресурсів;
- політику доступу та розмежування прав на дані й артефакти;
- процедуру відкату з покроковим описом і точками повернення;
- набір контрольних запитів і еталонних відповідей для приймання;
- документацію із супроводу та оновлення адаптерів.
Опишіть вашу інфраструктуру та обмеження щодо даних — повернемося з оцінкою та планом інтеграції.
Терміни впровадження донавченої моделі за етапами
Терміни донавчання складаються не з однієї операції, а з ланцюжка: підготовка даних, налаштування навчання, прогін, оцінка якості, викатка.
Основний час іде не на сам прогін, а на збір і розмітку корпусу та на приймання результату — ці етапи визначають план-графік робіт сильніше, ніж вибір методу.
Тривалість етапів залежить від обсягу корпусу та вимог до точності: невеликий датасет на кілька тисяч прикладів проходить цикл за пару тижнів, корпус на десятки тисяч прикладів з ручною перевіркою розтягує підготовку та приймання.
Паралельно з навчанням іде підготовка інфраструктури викатки — це не подовжує загальний термін, якщо стартує на етапі розмітки.
Ми фіксуємо план-графік робіт після аудиту, коли видно реальний обсяг даних, і тримаємо проміжні контрольні точки: на кожній замовник бачить результат і може скоригувати пріоритети. Опишіть задачу — повернемося з оцінкою та планом за етапами.
