SFT, DPO, GRPO: trzy sposoby dostrajania modelu i kiedy każdy stosować

Gdy firma przystępuje do dostrajania własnego modelu językowego, pierwszym pytaniem jest zwykle: „Ile danych potrzebujemy?" Trafniejsze pytanie brzmi: „Co chcemy zmienić w modelu — i jakiemu celowi treningowemu to odpowiada?" SFT, DPO i GRPO to trzy różne odpowiedzi na trzy różne problemy. Wybór właściwej metody zanim zaczniesz zbierać dane przesądza o tym, czy projekt za sześć miesięcy działa, czy nie.

Ten artykuł nie wyjaśnia, jak zainstalować framework treningowy. Wyjaśnia, co robi każda metoda, kiedy ją wdrożyć, ile danych naprawdę potrzeba i dlaczego kolejność SFT → DPO → GRPO nie jest przypadkowa.

Podstawy: czym jest LoRA i czym jest cel treningowy — dwa różne pojęcia

Przed właściwym porównaniem metod warto rozróżnić dwie rzeczy, które w dyskusjach często się mieszają.

LoRA (Low-Rank Adaptation) i QLoRA (wariant skompresowany kwantyzacją) to *mechanizmy* — sposoby fizycznej modyfikacji modelu bez konieczności aktualizowania wszystkich wag. Zamiast tego trenujesz małe macierze adaptacyjne, które nakładają się na istniejące wagi modelu. Dzięki temu mieszczysz się w znacznie mniejszej pamięci GPU: typowy model 7B możesz dostroić z QLoRA na GPU z ~9 GB VRAM, podczas gdy pełny fine-tuning wymagałby ~70–120 GB. Szczegółowe porównanie tych mechanizmów znajdziesz w artykule LoRA vs QLoRA vs pełny fine-tuning.

SFT, DPO i GRPO to natomiast *cele treningowe* — definiują, czego model się uczy. Podobnie jak LoRA, pełny fine-tuning jest mechanizmem. Możesz robić SFT z LoRA, SFT z pełnym fine-tuningiem, DPO z QLoRA — kombinacje są dowolne. W praktyce większość projektów domenowych wykonuje się dziś z LoRA lub QLoRA po prostu ze względów ekonomicznych, ale cel treningowy pozostaje kluczową decyzją.

SFT — supervised fine-tuning: nauczyć model formatu i zachowania

SFT (supervised fine-tuning, douczanie z nauczycielem) to podstawowa metoda. Podajesz modelowi wejście i oczekiwane wyjście, a model uczy się imitować te pary. Jest to w istocie rozszerzenie pre-treningu: model uczy się ze wzorców formatu (prompt → odpowiedź).

SFT odpowiada na pytanie: *„Jak model powinien reagować na ten typ zadania?"*

Kiedy stosować SFT

SFT jest właściwym wyborem, gdy:

• Model posiada odpowiednią wiedzę, ale odpowiada w złym formacie (za długo, za krótko, zły język, zła struktura)
• Chcesz nauczyć model żargonu branżowego, terminologii lub stylu komunikacji
• Masz jasno zdefiniowane zadanie z konsekwentnymi wzorcami — na przykład klasyfikacja dokumentów, ekstrakcja encji, generowanie raportów według szablonu
• Chcesz w sposób destylacyjny przenieść zachowanie silniejszego modelu do mniejszego (przykłady generuje model teacher, trenuje się model student)

SFT pełni też rolę fundamentu dla wszystkich pozostałych metod. Base model bez SFT nie nadaje się do niezawodnego dalszego dostrajania z DPO lub GRPO — do tego wrócę poniżej.

Ile danych potrzebuje SFT

Badania wykazały, że 1 000 wysokiej jakości przykładów może dawać znacznie lepsze wyniki niż 100 000 próbek niskiej jakości. Jednak dla systemów produkcyjnych typowa wielkość zbioru danych to raczej 10 000–100 000 par, ponieważ chcesz pokryć długi ogon wariantów wejść, które pojawią się w rzeczywistej eksploatacji.

Praktyczne minimum dla wiarygodnych wyników w projekcie domenowym to około 5 000 jakościowych przykładów pokrywających większość obszarów tematycznych, z którymi model się zetknie. Poniżej tej granicy model może co prawda poprawić zachowanie na danych, które widział, ale zawodzi na wariantach, których nie widział.

Dla branż regulowanych (prawo, medycyna, farmacja) obowiązuje surowsza zasada: zbiór danych musi pokrywać każdą jurysdykcję i każdy typ dokumentu, z którym model będzie pracować. Częściowe pokrycie produkuje model, który z wysoką pewnością odpowiada również w obszarach, gdzie nie ma wystarczającej liczby przykładów treningowych — to gorsze niż nierozwiązywanie problemu w ogóle.

Czego SFT nie rozwiązuje

SFT nie uczy modelu *oceniania* — nie wie, że jedna odpowiedź jest lepsza od drugiej, wie jedynie, że taka odpowiedź istnieje. Jeśli model ma tendencję do odpowiadania w sposób nieodpowiedni, bycia zbyt zwięzłym tam, gdzie to szkodzi, lub unikania pewnych typów pytań — SFT samo w sobie tego nie naprawi. Do tego służy DPO.

DPO — direct preference optimization: nauczyć model, co jest lepsze

DPO (direct preference optimization) trenuje się przez pary preferencyjne — dla każdego promptu masz dwie odpowiedzi: winner (preferowaną) i loser (mniej preferowaną). Model uczy się, aby jego rozkład odpowiedzi kierował się ku winner i od loser.

DPO jest uproszczoną wariantą oryginalnego RLHF (reinforcement learning from human feedback) — nie wymaga oddzielnego modelu nagrody, co czyni go znacznie tańszym i stabilniejszym w treningu.

DPO odpowiada na pytanie: *„Jak model powinien podejmować decyzje, gdy istnieje kilka możliwych odpowiedzi?"*

Kiedy stosować DPO

DPO jest właściwym wyborem, gdy:

• Masz zdefiniowane preferencje: co jest lepszą odpowiedzią, a co gorszą (zweryfikowane przez człowieka lub zautomatyzowanym procesem)
• Chcesz zmniejszyć tendencję modelu do odpowiadania w niechciany sposób — zbyt pasywnie, zbyt długo, z nadmierną liczbą fraz hedgingowych
• Chcesz dopracować ton komunikacji bez konieczności przepisywania całych danych treningowych
• Masz już bazę SFT i chcesz dalej poprawiać alignment modelu

Ile danych potrzebuje DPO

Minimalna zalecana liczba to ~2 000 par preferencyjnych z oceną winner/loser zweryfikowaną przez człowieka. Nie jest to arbitralna liczba — poniżej tej granicy sygnału preferencyjnego nie można wiarygodnie oddzielić od szumu w rozkładzie, a model może się pretrenować na artefaktach konkretnych oceniających.

Dla dobrej generalizacji potrzebna jest większa pokrywalność: 5 000–10 000 par obejmujących różne typy promptów i scenariuszy to typowy produkcyjny cel.

Ważniejsza niż liczba jest jakość oceny. Jeśli pary winner/loser są oceniane niespójnie lub według niejasnych kryteriów, model uczy się niespójnej polityki. Przed zbieraniem danych niezbędne jest posiadanie jasnej rubryki — co konkretnie sprawia, że odpowiedź jest lepsza.

Kolejność: SFT przed DPO jest konieczne

DPO stosuje się na modelu, który przeszedł SFT — nie bezpośrednio na base modelu. Powód jest praktyczny: base model produkuje zbyt dużą zmienność odpowiedzi, a sygnał DPO się „rozmywa" — model nie ma stabilnej bazy, względem której gradient preferencyjny mógłby zadziałać.

W praktyce wygląda to tak:

1. 1.Base model → SFT → model dostrojony do instrukcji (umie konsekwentnie odpowiadać na określone typy zadań)
2. 2.Model dostrojony do instrukcji → DPO → model wyrównany (preferuje lepsze odpowiedzi nad gorszymi)

Pominięcie SFT i bezpośrednie DPO z base modelu typowo daje niestabilne wyniki lub model, który nie przestrzega instrukcji.

GRPO — group relative policy optimization: nauczyć model rozumowania

GRPO (group relative policy optimization) to metoda z rodziny RL-from-rewards (reinforcement learning z nagrodami). Zamiast par preferencyjnych model otrzymuje zadanie weryfikowalne — równanie matematyczne, problem logiczny, zadanie kodowania — i dostaje nagrodę w zależności od tego, czy jego wynik jest obiektywnie poprawny.

GRPO zyskało rozgłos po wydaniu DeepSeek R1, gdzie użyto go do fine-tuningu zorientowanego na rozumowanie. Kluczowa zaleta nad starszym PPO (proximal policy optimization): GRPO nie wymaga oddzielnego modelu krytyka, co obniża wymagania VRAM i upraszcza pipeline treningowy.

GRPO odpowiada na pytanie: *„Jak nauczyć model lepszego rozumowania na zadaniach, gdzie poprawna odpowiedź jest weryfikowalna?"*

Kiedy stosować GRPO

GRPO jest właściwym wyborem, gdy:

• Masz zadania z weryfikowalnymi odpowiedziami — matematyka, kod, logika, zapytania SQL, ekstrakcja danych strukturalnych ze złotą adnotacją
• Chcesz poprawić reasoning — zdolność modelu do przechodzenia przez wiele kroków bez utraty kontekstu
• Chcesz, aby model generował chain-of-thought (łańcuch rozumowania) na zadaniach, gdzie jest to wartościowe
• Masz środowisko, w którym można automatycznie ocenić poprawność wyjścia bez ludzkiego oceniającego

GRPO jest typowo trzecim krokiem pipeline, nie pierwszym. Model musi mieć solidną bazę SFT i idealnie również alignment DPO, zanim trening RL zadziała efektywnie.

Ile danych potrzebuje GRPO

Minimum to ~1 000 scorowanych trajektorii — promptów z weryfikowalną odpowiedzią i działającym sygnałem nagrody. Nacisk kładziony jest na „weryfikowalną": nagroda musi być spójna i obliczalna automatycznie. Jeśli nagroda zależy od subiektywnej oceny, trening RL daje niestabilne wyniki.

W praktyce GRPO wykonuje się na mniejszych, celowanych zbiorach danych (tysiące, nie setki tysięcy) — ponieważ sygnał nagrody jest intensywniejszy niż sygnał nadzorowany. Z drugiej strony zebranie weryfikowalnych nagród jest kosztowne: trzeba zdefiniować metrykę, napisać ewaluator i upewnić się, że sam ewaluator nie popełnia błędów.

Eksperymentalny charakter GRPO

GRPO to aktywna przestrzeń badawcza. Istnieje wiele wariantów (DAPO i inne), a społeczność aktywnie bada, gdzie dokładnie leżą jego granice. Dla większości projektów domenowych w środowisku B2B GRPO jest istotne tylko jeśli:

• Pracujesz na zadaniach wymagających intensywnego rozumowania (złożona analiza, wieloliniowy kod, diagnostyka techniczna)
• Masz zdolność napisania i walidacji funkcji nagrody
• Zespół ma doświadczenie z treningiem RL — debugowanie RL jest znacznie trudniejsze niż debugowanie SFT

Dla większości adaptacji domenowych (styl, terminologia, format) SFT + DPO jest wystarczające i znacznie stabilniejsze.

Trzy metody obok siebie — szybkie porównanie

SFT — supervised fine-tuning: - Wejście: pary (prompt, oczekiwana odpowiedź) - Uczy: formatu, stylu, terminologii, zachowania przy określonych zadaniach - Minimum danych: ~5 000 jakościowych par dla domenowego systemu produkcyjnego - Kolejność: zawsze pierwszy krok

DPO — direct preference optimization: - Wejście: trójki (prompt, odpowiedź winner, odpowiedź loser) - Uczy: preferowanej odpowiedzi, alignmentu, poprawy tonu i podejmowania decyzji - Minimum danych: ~2 000 par preferencyjnych zweryfikowanych przez człowieka - Kolejność: po SFT, nie z base modelu

GRPO — group relative policy optimization: - Wejście: prompt + automatyczny sygnał nagrody (weryfikowalna poprawność) - Uczy: rozumowania, chain-of-thought, precyzji na weryfikowalnych zadaniach - Minimum danych: ~1 000 scorowanych trajektorii z działającym ewaluatorem - Kolejność: po SFT (i idealnie DPO) jako trzeci krok

Katastroficzne zapominanie — ukryty koszt każdego fine-tuningu

Każda metoda niesie ryzyko katastroficznego zapominania (catastrophic forgetting): model intensywnie trenowany na wąskiej domenie może tracić zdolności, których nie widział w danych treningowych. W praktyce oznacza to: model doskonały w generowaniu raportów technicznych może zacząć gorzej radzić sobie z pytaniami konwersacyjnymi lub rozumowaniem logicznym poza dziedziną.

Mechanizmy PEFT jak LoRA łagodzą ten efekt, ponieważ modyfikują jedynie niewielką część wag — ale go nie eliminują. Łagodzenie w praktyce:

1. 1.Do zbioru treningowego domieszaj dane domenowe z ogólnymi próbkami (5–15 % ogólnego miksu)
2. 2.Po każdym przebiegu treningowym oceniaj model poza dziedziną — nie tylko na benchmarkach domenowych
3. 3.Zachowaj wersję modelu sprzed fine-tuningu jako fallback

Szczegółowe spojrzenie na to, jak mierzyć, czy fine-tuning pomógł czy zaszkodził, znajdziesz w artykule Jak zmierzyć, czy fine-tuning pomógł.

Pipeline w praktyce: od base modelu do wdrożenia produkcyjnego

W projektach B2B, gdzie wdrażaliśmy model domenowy, typowy przebieg wygląda następująco:

Faza 1 — wybór bazy. Wybierasz odpowiedni model open-weight (rodzina Qwen, Llama, Mistral) według pojemności VRAM i wymaganego kontekstu. Dla większości zadań domenowych model 7B–14B to optymalny stosunek wydajności do kosztu. Jeśli dysponujesz GPU z 24 GB VRAM (np. RTX 3090/4090), QLoRA 7B działa komfortowo; dla modelu 13B zmieścisz się z trudem. Więcej o wyborze modelu i wymiarowaniu GPU znajdziesz w artykule Jakie GPU do inferencji LLM.

Faza 2 — zbieranie danych SFT. Identyfikujesz typy zadań, format oczekiwanych odpowiedzi, terminologię. Zbierasz lub generujesz 5 000–50 000 par. Dla projektów domenowych sprawdzona recepta to: 150–200 wysokiej jakości przykładów seed tworzonych przez człowieka, rozszerzonych 10–100× przez silny model frontier (Claude, GPT jako teacher). Wynik weryfikujesz ręczną adnotacją próbki.

Faza 3 — przebieg SFT. Trening z LoRA lub QLoRA, typowo kilka epok. Na GPU A100 trwa godziny, nie dni. Szacunkowe koszty w chmurze wynoszą rzędu kilkudziesięciu euro za przebieg przy modelu 7B i 10 000 przykładach — zależy od dostawcy i użytego GPU.

Faza 4 — ewaluacja i decyzja. Zestaw testowy pokrywający wszystkie typy zadań. Jeśli wyniki są zadowalające, model trafia do produkcji. Jeśli nie — analizujesz, gdzie zawodzi, zamiast ślepo dodawać dane.

Faza 5 (opcjonalna) — DPO. Jeśli masz zdolność zbierania par preferencyjnych, a model wykazuje konkretne zachowanie, które chcesz zmienić (nie tylko braki wiedzy), DPO jest właściwym kolejnym krokiem.

Faza 6 (specjalistyczna) — GRPO. Tylko jeśli pracujesz na przypadku użycia wymagającym intensywnego rozumowania i dysponujesz weryfikowalnym sygnałem nagrody.

Kiedy nie robić fine-tuningu

Fine-tuning nie jest odpowiedzią na każdy problem. Widzieliśmy projekty, gdzie firma zainwestowała tygodnie w SFT, a wynik był gorszy niż prosta pipeline RAG z dobrym promptem. Przed fine-tuningiem zapytaj:

• Czy problem polega na tym, czego model nie wie (fakty, dokumenty) — wtedy RAG jest efektywniejszy i tańszy. Fine-tuning nie nauczy modelu niezawodnie nowych faktów, jedynie zmieni zachowanie.
• Czy problem polega na tym, że model odpowiada w złym formacie lub stylu — wtedy może wystarczyć lepszy prompt systemowy przed inwestycją w zbiór danych.
• Czy masz wystarczającą ilość jakościowych danych pokrywających dziedzinę — jeśli nie, fine-tuning produkuje model, który z pewnością odpowiada nawet tam, gdzie nie ma podstaw.

Ramę decyzyjną RAG vs fine-tuning szczegółowo omawia oddzielny artykuł RAG vs fine-tuning — kiedy co.

Najczęstsze pytania

Czy można robić DPO bezpośrednio z base modelu bez SFT?

Technicznie tak, ale wynik jest zwykle niestabilny. Base model produkuje zbyt zmienne wyjścia — gradient DPO nie może zadziałać efektywnie, bo model nie ma konsekwentnej bazy zachowania. W praktyce niemal zawsze potrzebny jest przynajmniej minimalny przebieg SFT przed DPO.

Czy GRPO nadaje się do projektów firmowych poza technologią?

GRPO jest silne tam, gdzie masz weryfikowalne odpowiedzi — matematyka, kod, ustrukturyzowane ekstrakcje ze złotą adnotacją. Dla większości przypadków użycia B2B (obsługa klienta, asystent dokumentacyjny, raportowanie) SFT + DPO jest wystarczające i znacznie prostsze w implementacji i debugowaniu. GRPO polecamy tylko jeśli zespół ma doświadczenie z treningiem RL.

Ile kosztuje fine-tuning w chmurze dla modelu 7B?

Przybliżone szacunki: przebieg SFT na 10 000 przykładach trwa na GPU A100 rzędu godzin, koszty wynoszą kilkadziesiąt euro (u tańszych dostawców) do kilkuset euro (hyperscalerzy). Rzeczywisty koszt projektu zależy od liczby iteracji, wielkości zbioru danych i tego, ile razy trening jest powtarzany po korektach danych. Większym kosztem bywa zwykle zbieranie i adnotacja danych, nie sam trening.

Czym jest katastroficzne zapominanie i jak mu zapobiec?

Katastroficzne zapominanie następuje, gdy fine-tuning na wąskiej dziedzinie degraduje ogólne zdolności modelu — na przykład rozumowanie logiczne lub zdolności konwersacyjne poza dziedziną. Łagodzysz je przez mieszanie danych domenowych z ogólnymi (5–15 % ogólnego miksu w zbiorze danych), mechanizm LoRA/QLoRA (mniej agresywna modyfikacja wag) oraz regularną ewaluację poza dziedziną po każdym przebiegu treningowym.

Jaki model open-weight polecacie jako bazę do domenowego SFT?

Dla większości projektów domenowych w 2026 roku dobrą bazą są modele z rodzin Qwen, Llama lub Mistral w przedziale 7B–14B. Wybór zależy od długości kontekstu, licencji i tego, który base model jest kompatybilny z twoim frameworkiem treningowym. Konkretne rekomendacje z liczbami znajdziesz w artykule Jak wybrać model LLM.

*Jeśli rozważają Państwo dostrojenie własnego modelu i nie wiedzą, od czego zacząć — SFT, DPO czy inna metoda — chętnie omówimy konkretny przypadek użycia i zaproponujemy realistyczny plan. Skontaktuj się z nami na mp-is.eu lub umów konsultację bezpośrednio.*