Fine-tuning to jeden z najczęściej powtarzanych terminów w każdym dokumencie AI roadmap. „Wytrenujemy własny model, który będzie rozumiał naszą domenę." W teorii eleganckie. W praktyce widzieliśmy, jak ten sam projekt rozpadał się w siedmiu różnych miejscach — i za każdym razem z innego powodu. Ten artykuł nie jest o tym, jak zrobić fine-tuning — jest o tym, dlaczego większość prób nie dociera do produkcji, i jak unikać tych pułapek zanim pochłoną czas i budżet.
Jeśli dopiero rozważają Państwo, czy w ogóle sięgnąć po fine-tuning czy raczej po RAG, przeczytajcie najpierw RAG vs. fine-tuning — ramy decyzyjne. Przyczyny niepowodzeń, które opisujemy poniżej, zaczynają się bowiem właśnie tam.
---
1. Za mało danych — albo dane niskiej jakości
To najczęstsza przyczyna porażki. Zespół zbiera to, co ma pod ręką — kilkaset dokumentów wewnętrznych, eksport z CRM, kilka wyeksportowanych e-maili — i uruchamia trening. Efekt to model, który z wysoką pewnością odpowiada błędnie: gorszy od modelu bazowego, który przynajmniej potrafi powiedzieć „nie wiem".
Badania wykazały (LIMA i inne prace), że stosunkowo niewielka liczba bardzo wysokiej jakości przykładów — rzędu tysiąca — potrafi wyprodukować lepszy model niż dziesiątki tysięcy przykładów niskiej jakości. Ilość bez jakości jest w tym przypadku aktywnie szkodliwa.
Praktyczne minima:
- SFT (supervised fine-tuning): minimum ~1 000 wysokiej jakości par pytanie–odpowiedź lub par zadanie–rozwiązanie, z pokryciem głównych tematów Państwa domeny. Systemy produkcyjne pracują typowo na 10 000–100 000 przykładach.
- DPO (preference tuning): ~2 000 par preferencyjnych z winner/loser, zweryfikowanych przez człowieka.
- GRPO (RL-based tuning): ~1 000 ocenionych trajektorii z weryfikowalnymi nagrodami.
Oprócz liczby liczy się pokrycie — jeśli Państwa baza wiedzy (knowledge base) nie ma wystarczającej liczby przykładów z konkretnej poddomeny, model będzie w tym obszarze produkował halucynacje. Przed uruchomieniem treningu zalecamy przeprowadzenie audytu pokrycia tematycznego: wypiszcie główne kategorie pytań, z którymi model będzie się mierzył, i sprawdźcie, czy macie wystarczającą próbkę w każdej z nich.
---
2. Overfitting — model wie tylko to, co widział
Gdy dataset jest zbyt mały albo zbyt wąski, a model trenuje się na nim zbyt długo, dochodzi do overfittingu. Model znakomicie radzi sobie z przykładami treningowymi, ale przy jakimkolwiek odchyleniu — nieco inaczej sformułowane pytanie, inny kontekst, nieznane wejście — całkowicie zawodzi lub produkuje halucynacje.
Objawy overfittingu w praktyce:
- Model dosłownie cytuje próbki treningowe zamiast generalizować.
- Na danych treningowych wysokie wyniki, na nowych przykładach wyraźnie niższe.
- Model odmawia odpowiadania na pytania spoza rozkładu danych treningowych zamiast przyznać niepewność.
Środki techniczne: monitorujcie validation loss podczas treningu i zatrzymajcie go, gdy zaczyna rosnąć (early stopping). Śledźcie metryki ewaluacyjne na hold-out secie, nie tylko na danych treningowych. Dla małych datasetów odpowiedniejsze jest niższe rank adaptera LoRA (np. rank=8 zamiast rank=64) i regularyzacja.
---
3. Catastrophic forgetting — model zapomina, co wiedział
Fine-tuning na wąskich danych domenowych może degradować ogólne zdolności modelu — zdolność do analizy, podsumowywania, rozumowania w języku angielskim i innych językach, podstawową logikę. To zjawisko nazywane jest catastrophic forgetting (katastroficznym zapominaniem) i jest dobrze udokumentowane.
W praktyce wygląda to tak: przez fine-tuning na wewnętrznych dokumentach technicznych uzyskujecie model, który znakomicie odpowiada na pytania z Państwa dziedziny — ale przestaje działać przy ogólnych zadaniach, z którymi wcześniej radził sobie bez problemu. Klienci, którzy nie znają tego zjawiska, interpretują to jako „model się popsuł".
Co łagodzi, choć nie eliminuje problemu:
- LoRA / QLoRA — adaptery zmieniają tylko niewielką liczbę parametrów, oryginalne wagi pozostają zamrożone. To najskuteczniejszy praktyczny sposób na ograniczenie forgettingu.
- Merging — fine-tuned model łączy się z modelem bazowym za pomocą narzędzi takich jak
mergekit(SLERP, TIES). Wynik balansuje wiedzę domenową i zdolności ogólne. - Dywersyfikacja datasetu — włączenie przykładów ogólnego przeznaczenia do datasetu treningowego obok przykładów domenowych.
W branżach regulowanych (medycyna, prawo, farmacja) zapominanie jest szczególnie krytyczne — model, który utracił logikę i wzorce bezpieczeństwa, może produkować treści brzmiące wiarygodnie, lecz faktycznie błędne.
---
4. Zły dobór metody — pełny fine-tuning tam, gdzie wystarczyłoby LoRA, albo odwrotnie
Zespoły zaczynające przygodę z fine-tuningiem mają tendencję do popadania w skrajności: albo decydują się na pełny fine-tuning wymagający ogromnych zasobów GPU, albo wybierają najtańszy wariant bez zastanowienia się nad kompromisami.
Orientacyjne zapotrzebowanie na VRAM dla modelu 7B:
- Pełny fine-tuning (BF16): ~70–120 GB — wymaga serwera multi-GPU
- LoRA (16-bit): ~15 GB — A100 lub jedna RTX 4090 (24 GB VRAM)
- QLoRA (4-bit): ~5 GB — mieści się na RTX 3090 z 24 GB VRAM
LoRA osiąga typowo ~90–95 % jakości pełnego fine-tuningu przy 10–20× mniejszym zapotrzebowaniu na pamięć. Dla większości domenowych przypadków użycia jest to w zupełności wystarczające — sięganie po pełny fine-tuning bez wyraźnego uzasadnienia to marnotrawstwo zasobów.
Z drugiej strony istnieją przypadki, gdzie LoRA nie wystarcza: gdy zmienia się tokenizer, gdy mamy do czynienia z językami o morfologii bardzo różniącej się od danych treningowych, albo przy głębokim „continued pretraining" (budowaniu wiedzy domenowej z nieetykietowanych tekstów). Wybór metody powinien wynikać z konkretnego celu, a nie z tego, co przypadkiem uruchomiono jako pierwsze. Szczegółowy przegląd znajdziecie w artykule LoRA vs QLoRA vs pełny fine-tuning.
---
5. Fine-tuning zamiast RAG — niewłaściwe narzędzie do niewłaściwego zadania
To prawdopodobnie najdroższy błąd, z którym się spotykamy. Zespół chce, żeby model „wiedział" o produktach firmy, dokumentach, wewnętrznych procesach. Fine-tuning wydaje się naturalną odpowiedzią. Uruchamiają go, wlewają dane do treningu i po kilku tygodniach odkrywają, że model nadal produkuje halucynacje — bo fine-tuning zawodnie dodaje fakty do modelu.
Fine-tuning jest odpowiednim narzędziem dla:
- Zmiany formatu i stylu odpowiedzi (np. zawsze zwracaj JSON z konkretnym schematem).
- Zmiany zachowania (np. model ma zawsze odmawiać obsługi określonych typów żądań, albo przestrzegać konkretnego tonu komunikacji).
- Dostosowania do wyspecjalizowanej domeny, w której model bazowy nie ma wystarczających danych treningowych (np. wąski żargon branżowy, zastrzeżone formaty).
RAG (Retrieval-Augmented Generation — generowanie wzbogacone wyszukiwaniem) to właściwe narzędzie dla:
- Dostępu do aktualnych lub zmieniających się informacji.
- Odpowiadania na pytania na podstawie konkretnych dokumentów.
- Identyfikowalności odpowiedzi do źródła (cytowanie, grounding).
W praktyce: jeśli Państwa celem jest „model ma umieć odpowiadać na pytania z naszego katalogu produktów" — to jest przypadek użycia RAG, nie fine-tuningu. Fine-tuning wdrożylibyście wtedy, gdy chcecie, żeby model używał Państwa specyficznego formatu odpowiedzi lub branżowej terminologii.
---
6. Brak ewaluacji — nie wiemy, czy coś zyskaliśmy, czy straciliśmy
Zaskakująco częsty scenariusz: zespół uruchamia fine-tuning, model się trenuje, sprawia wrażenie „lepszego" na kilku ręcznie przetestowanych przykładach i trafia do produkcji. Miesiąc później pojawiają się skargi na regresję — model przestaje działać na przypadkach, z którymi wcześniej radził sobie bez problemu.
Bez systematycznej ewaluacji (oceny jakości modelu) nie wiemy:
- 1.Czy fine-tuning w ogóle pomógł — porównanie z modelem bazowym.
- 2.Czy nie spowodowaliśmy regresji — wydajność na wcześniej działających przypadkach.
- 3.Gdzie dokładnie model zawodzi — w jakich kategoriach pytań.
Minimalny framework ewaluacyjny przed wdrożeniem produkcyjnym obejmuje:
- Hold-out test set — ~10–20 % danych, które nie znajdowały się w zestawie treningowym ani walidacyjnym. Mierzymy na nim po zakończeniu treningu.
- Porównanie z baseline — te same pytania do modelu bazowego i fine-tuned wersji. Regresja = jeśli fine-tuned model osiąga niższe wyniki na przypadkach, gdzie model bazowy działał poprawnie.
- Metryki specyficzne dla zadania — nie tylko perplexity (techniczna metryka uczenia maszynowego), ale metryki istotne dla Państwa przypadku użycia: dokładność ekstrakcji, poprawność formatu, ocena jakości przez eksperta domenowego.
Więcej o konfiguracji ewaluacji: Jak zmierzyć, czy fine-tuning pomógł.
---
7. Nierealistyczne oczekiwania — fine-tuning to nie jest magia
Ostatnia, ale pod wieloma względami najważniejsza przyczyna. Fine-tuning jest często prezentowany w wewnętrznych prezentacjach jako rozwiązanie, które z generycznego LLM zrobi eksperta w Państwa dziedzinie. W praktyce jest to bardziej subtelne:
- Fine-tuned model 4B–8B może przewyższyć generyczny model 70B+ na wąsko zdefiniowanym zadaniu — ale tylko jeśli zadanie jest rzeczywiście wąsko zdefiniowane, dane są wysokiej jakości i ewaluacja to potwierdza.
- Fine-tuning nie poprawia reasoning — jeśli model bazowy nie potrafi rozwiązywać określonego rodzaju zadań logicznych, fine-tuning na danych domenowych tego nie zmieni. Do reasoning odpowiednie są metody takie jak GRPO z weryfikowalnymi nagrodami. Więcej w artykule SFT, DPO, GRPO — która metoda kiedy.
- Fine-tuning to nie jest projekt jednorazowy — dane się zmieniają, model starzeje, regresje narastają. Bez infrastruktury zapewniającej powtarzalne cykle trening–ewaluacja–wdrożenie projekt stopniowo się rozpada.
- Halucynacje pozostają — fine-tuning może je zredukować w konkretnej domenie, ale ich nie eliminuje. Guardrails, RAG grounding i human-in-the-loop są nadal potrzebne wszędzie tam, gdzie poprawność ma znaczenie.
Zespoły, które znają te ograniczenia przed rozpoczęciem projektu, kończą z użytecznymi modelami. Zespoły, które dowiadują się o ograniczeniach po sześciu miesiącach pracy, zazwyczaj projekt zatrzymują.
---
Podsumowanie: checklist przed uruchomieniem projektu
Zanim zdecydują się Państwo na uruchomienie projektu fine-tuningu, zalecamy przejście przez te siedem pytań:
- 1.Czy macie wystarczający dataset? — liczba przykładów, pokrycie tematyczne, zweryfikowana jakość.
- 2.Czy fine-tuning to właściwe narzędzie? — czy RAG lub prompt engineering by wystarczyły?
- 3.Czy macie skonfigurowaną ewaluację? — hold-out set, baseline, metryki specyficzne dla zadania.
- 4.Czy macie infrastrukturę GPU? — albo realistyczny plan treningu w chmurze z szacunkiem kosztów.
- 5.Czy jesteście gotowi na iteracje? — jeden przebieg fine-tuningu nie wystarczy, pipeline musi być powtarzalny.
- 6.Czy macie eksperta domenowego w pętli? — kto zweryfikuje, że model odpowiada poprawnie, a nie tylko płynnie.
- 7.Czy macie plan na forgetting i regresje? — monitoring, rollback, ewaluacja po każdym nowym przebiegu treningowym.
Jeśli któreś z tych pytań nie ma jasnej odpowiedzi, projekt nie jest gotowy do uruchomienia — jedynie do przygotowania.
---
Najczęstsze pytania
Dlaczego mój fine-tuned model odpowiada gorzej niż model bazowy?
Najczęstszą przyczyną jest overfitting na małym lub niskiej jakości datasecie. Model nauczył się „wzorców" z danych treningowych, ale generalizacja na nowe wejścia zawodzi. Rozwiązanie: podnieść jakość danych, zastosować early stopping, obniżyć rank adaptera LoRA — albo całkowicie przemyśleć projekt pod kątem RAG vs fine-tuning.
Ile przykładów naprawdę potrzebuję do fine-tuningu?
Dla SFT funkcjonalny wynik jest możliwy od ~1 000 wysokiej jakości przykładów, ale systemy produkcyjne pracują typowo na 10 000–100 000. Ważniejsze od ilości jest pokrycie — jeśli brakuje wystarczającej próbki w kluczowych kategoriach, model będzie w tych obszarach zawodny bez względu na łączną liczbę przykładów.
Czy fine-tuning nadaje się do aktualizowania wiedzy modelu (nowe produkty, ceny, zapisy)?
Nie. Fine-tuning zawodnie przechowuje fakty — model może sygnalizować informacje z treningu, ale miesza je z halucynacjami. Dla wiedzy, która się zmienia lub musi być weryfikowalna, właściwym narzędziem jest RAG z aktualną bazą dokumentów.
Czy mały fine-tuned model może przewyższyć duży generyczny model?
Tak — przy określonych warunkach. Fine-tuned model 4B–8B może na wąsko zdefiniowanym zadaniu przewyższyć generyczny model 70B+, jeśli zadanie jest dobrze ograniczone, dataset jest wysokiej jakości i ewaluacja to potwierdza. Na szerokich, ogólnych zadaniach większy model zazwyczaj wygrywa.
Co to jest catastrophic forgetting i jak mu zapobiegać?
Catastrophic forgetting to zjawisko, w którym fine-tuning na wąskich danych degraduje ogólne zdolności modelu — języki, logikę, rozumowanie. Najskuteczniejszym środkiem zaradczym jest LoRA lub QLoRA, które zmieniają tylko niewielką liczbę parametrów i zachowują oryginalne wagi. Pomocne jest również łączenie fine-tuned modelu z modelem bazowym za pomocą narzędzia mergekit.
---
*MP Industrial Solutions pomaga firmom ocenić, kiedy fine-tuning naprawdę ma sens, a kiedy istnieje prostsza i tańsza droga. Jeśli rozważają Państwo domenową adaptację LLM, chętnie ocenimy Państwa przypadek użycia — od datasetu po infrastrukturę i ewaluację.*