Fine-tuning відкриває рівень контролю над моделлю, недоступний при промптингу чи RAG. Але саме через цю ілюзію контролю більшість проектів зупиняються на неочікуваному місці: модель погіршилась, гроші витрачено, час втрачено.

За останні кілька років fine-tuning перестав бути привілеєм великих лабораторій. Llama, Mistral, Qwen — всі вони доступні для налаштування за розумного бюджету. Але доступність інструменту не означає, що більшість команд користуються ним правильно.

Зібрали найпоширеніші помилки, які повторюються в реальних проектах — від стартапів до корпоративних ML-команд.

Почати з моделі, а не з даних

Найбільша помилка — починати fine-tuning із вибору архітектури, а не з аудиту даних. Дані вирішують 80% результату; решта — деталі реалізації.

Недостатній обсяг і погана якість. Для supervised fine-tuning зазвичай потрібно від 500 до 5000 якісних прикладів залежно від складності завдання. Але кількість не рятує, якщо приклади суперечать одне одному або містять шум. Один суперечливий приклад на сотню здатний нейтралізувати ефект десяти правильних. Перевіряйте дані вручну — хоча б 5–10% вибірки перед запуском тренування.

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

Витік даних між train і eval. Типова помилка при зборі з виробничих логів: один і той самий запит потрапляє і в тренувальну, і у валідаційну вибірку. Модель «запам'ятовує» конкретний приклад, а не узагальнює патерн. Виключайте точні дублікати та семантично схожі приклади до розподілу на train/val.

Fine-tuning там, де достатньо промптингу

Не кожне завдання потребує fine-tuning. Якщо проблему вирішує якісний system prompt із кількома few-shot прикладами — немає сенсу платити за тренування і утримання окремої моделі.

Fine-tuning виправданий, коли:

Fine-tuning надмірний, коли:

LoRA та QLoRA знизили поріг входу — але не до нуля. Навіть для Llama 3 8B потрібен GPU з 16+ GB VRAM і правильно підібраний learning rate.

Гіперпараметри та оцінка: де тонко — там і рветься

Learning rate — найчастіша причина провалу. Занадто великий — і модель «забуває» базові знання (catastrophic forgetting). Занадто малий — тренування не дає ефекту. Стартові орієнтири: 1e-5 до 5e-5 для full fine-tuning; 1e-4 до 3e-4 для LoRA. Це лише початкові точки для першого запуску, а не готові відповіді.

Ігнорування overfitting. Validation loss перестає падати або починає рости — класичний сигнал перенавчання. Але команди часто продовжують тренування, бо train loss виглядає чудово. Правило просте: якщо val loss і train loss розходяться більш ніж на 15–20% — зупиніться. Раннє зупинення (early stopping) повинно бути стандартною практикою, а не опцією.

Оцінка лише за технічними метриками. Loss і perplexity відображають статистику, а не якість відповідей. Тестуйте модель на реальних use case'ах із реальними запитами. Для класифікації — F1 та confusion matrix. Для генерації — ручна оцінка або LLM-as-judge: Claude чи GPT-4o як незалежний арбітр.

Catastrophic forgetting. Якщо тренувальний датасет вузькоспеціалізований, модель може втратити загальні можливості. Рішення: додати в тренувальну вибірку 10–20% прикладів із загального розподілу. Або зберегти базову модель як окремий ендпоінт і маршрутизувати запити залежно від типу завдання.

Висновок AiiN

Fine-tuning — це не магія і не срібна куля. Це інженерна дисципліна, де якість результату прямо залежить від якості підготовки: даних, гіпотез і метрик оцінки.

Мінімальний чеклист перед запуском тренування:

Якщо пропустити хоч один пункт — шанс отримати результат гірший за baseline суттєво зростає. Fine-tuning виправданий лише тоді, коли є чіткий контроль над кожним етапом пайплайну.