Kiedy fine-tuning ma sens (a kiedy wystarczy RAG)

Kiedy firma decyduje się na wdrożenie własnego modelu, prędzej czy później pada to pytanie: czy wystarczy podać modelowi wiedzę przez RAG, czy trzeba go dotrenować? Obydwa podejścia istnieją od lat, ale w 2026 roku granica między nimi jest ostrzejsza niż kiedykolwiek — a mylenie ich kosztuje tygodnie pracy i dziesiątki tysięcy złotych.

RAG nie zmienia modelu. Wyszukuje trafne fragmenty z Waszej bazy wiedzy i wstrzykuje je do kontekstu przed każdą odpowiedzią. Model czyta te fragmenty i odpowiada na ich podstawie, z cytatem. Wiedza żyje poza modelem, więc jutro możesz zaktualizować bazę bez żadnego retreningu.

Fine-tuning zmienia wagi modelu. Trenujesz go na własnych przykładach wejście-wyjście i zapisujesz wynikające z tego zmiany w samym modelu. Po fine-tuningu model inaczej generuje tekst nawet bez dodatkowego kontekstu. To trwałe i nie da się cofnąć bez ponownego treningu.

Kluczowe zdanie: RAG zmienia co model wie, fine-tuning zmienia jak model się zachowuje.

Poniżej trzy konkretne przypadki, w których fine-tuning dostarcza wartość, której RAG nie odtworzy:

1. Trwały styl i format wyjścia. Gdy Wasz system musi generować raporty w ściśle określonym szablonie (np. określony XML, format prawny, notacja branżowa) i żaden prompt nie utrzymuje tego spójnie przez tysiące wywołań — fine-tuning utrwala format w wagach. Przykład: system generujący opisy techniczne według normy ISO, gdzie odchylenia od szablonu powodują problemy regulacyjne.

2. Specjalistyczny żargon i terminologia domenowa. Ogólny model zna słowo „dekretacja" tylko z kontekstu księgowego. Jeśli Wasz proces używa skrótów, akronimów i terminologii, których model nie widział w pretrainingu, kilkaset przykładów fine-tuningu nauczy go poprawnie je interpretować i generować. RAG może podać definicję, ale nie zmieni głębokiego rozumienia kontekstu użycia.

3. Redukcja kosztu i latencji przez specjalizację. Mały model (7B-14B) wytrenowany na konkretnym zadaniu (np. tylko klasyfikacja intencji obsługi klienta) jest wielokrotnie tańszy w inferencji niż duży model ogólny. Jeśli Wasz system wykonuje miliony wywołań miesięcznie na jednym, wąskim zadaniu — fine-tuning mniejszego modelu może zwrócić się w ciągu kilku miesięcy. Policz to w kalkulatorze inferencji.

Warto wiedzieć, kiedy NIE wybierać fine-tuningu, bo jest to częstszy błąd:

1. „Chcemy, żeby model znał nasze dokumenty." To jest dokładnie zadanie RAG. Fine-tuning na dokumentach nie jest pamięcią faktograficzną — model nadal może halucynować fakty, tyle że teraz w specyficznym dla Was stylu. RAG z wektorową bazą danych i cytowaniem źródeł jest właściwą odpowiedzią.

2. Wiedza zmienia się często. Jeśli Wasze dane aktualizują się co tydzień (cenniki, regulaminy, oferty), fine-tuning jest nieodpowiedni — każda zmiana wymagałaby retreningu. RAG aktualizuje się przez dodanie nowych dokumentów do bazy.

3. Masz mało danych treningowych. Fine-tuning bez dostatecznej ilości dobrych przykładów daje efekt overfittingu lub regresji na ogólnych zdolnościach modelu. Minimum to kilkaset par wejście-wyjście dobrej jakości; realnie kilka tysięcy dla powtarzalnych rezultatów. Jeśli nie masz tyle danych — RAG plus prompt engineering jest tańszym startem.

4. Budżet i czas są ograniczone. Fine-tuning wymaga infrastruktury GPU, danych treningowych, eksperymentów, ewaluacji i utrzymania kolejnych wersji modelu. To nie jest jednorazowy koszt. Pilot RAG można uruchomić w tygodnie przy ułamku tego nakładu.

Reguła praktyczna: zacznij od RAG, zmierz wyniki. Jeśli po dwóch-trzech tygodniach problemem nie jest „co model wie", tylko „jak model się zachowuje" — wróć do rozmowy o fine-tuningu.

Jeśli po analizie powyżej fine-tuning jest właściwą decyzją, proces wygląda następująco:

1. Zbierz pary uczące. Każdy przykład to wejście (prompt, kontekst) i wyjście (poprawna odpowiedź). Jakość ważniejsza od ilości — trzysta precyzyjnych przykładów bije trzy tysiące byle jakich.
2. Wybierz model bazowy. Mniejszy model (7B, 13B) trenuje się szybciej i kosztuje mniej. Duże modele 70B+ do fine-tuningu to rzadkość poza największymi organizacjami.
3. Technika LoRA / QLoRA. Pełny fine-tuning wszystkich wag to marnotrawstwo. LoRA trenuje tylko małą matrycę adapterów, co redukuje koszt GPU o rząd wielkości przy zachowaniu większości efektu.
4. Ewaluacja. Zestaw testowy (hold-out) musi być oddzielony od danych treningowych od początku. Mierz zadaniowe metryki (F1 dla klasyfikacji, ROUGE dla generacji), nie tylko subiektywne wrażenie.
5. Rejestracja wersji. Każdy wytrenowany checkpoint to nowa wersja modelu z datą, zbiorem danych i wynikami ewaluacji. Bez tego nie będziesz wiedział, który model wdrożyć, ani jak wrócić do poprzedniego.
6. Utrzymanie. Model driftuje względem rosnącej bazy faktów. Ustal politykę retreningu — np. raz na kwartał lub gdy wyniki ewaluacji spadną poniżej progu.

Całość łatwiej zaplanować po wypełnieniu blueprintu agenta — pozwala zobaczyć, gdzie w architekturze ląduje fine-tuning a gdzie RAG.

Najlepsze wdrożenia produkcyjne często łączą obydwa podejścia. Schemat, który widzimy najczęściej:

• Fine-tuning odpowiada za styl, format i głos (model mówi jak Wasz brand, generuje w Waszym szablonie).
• RAG wnosi świeże fakty przy każdym wywołaniu (model nie halucynuje aktualnego cennika, bo go po prostu dostaje w kontekście).

Hybryda wymaga starannej architektury routera, który decyduje, kiedy wzbogacać kontekst, a kiedy polegać na wiedzy z fine-tuningu. To jeden z wzorców, które budujemy w ramach własnego asystenta AI dla klientów.

Fine-tuning i inferencja wytrenowanego modelu mają konsekwencje dla bezpieczeństwa i regulacji. Kilka faktów wartych uwagi przed podjęciem decyzji:

Jeśli trenujesz model na danych osobowych, obowiązuje Cię RODO i prawdopodobnie konieczna będzie DPIA. Dane użyte do treningu „wchodzą" w wagi modelu w sposób trudny do audytu — nie możesz tak łatwo wykonać prawa do usunięcia jak przy RAG, gdzie wystarczy usunąć dokument z bazy.

Zgodnie z AI Act, systemy wysokiego ryzyka muszą dokumentować dane treningowe i metodologię. Fine-tuning na danych klientów w systemach klasyfikacyjnych (np. scoring kredytowy, rekrutacja) wymaga dodatkowych kontroli i możliwości audytu.

Dla wrażliwych danych preferujemy self-hosting — model trenuje się i działa w Waszej infrastrukturze, PII nie opuszcza organizacji.

Opisz swój przypadek użycia — model pomoże ocenić, czy to zadanie dla RAG, fine-tuningu czy hybrydy (playground: PII maskowane, zero retencji):

Fine-tuning ma sens, gdy problemem jest stały styl wyjścia, specjalistyczny żargon domenowy lub potrzeba tańszej inferencji na wąskim zadaniu. RAG wystarczy, gdy problemem jest dostęp do świeżej wiedzy faktograficznej — a to jest najczęstszy przypadek w polskich firmach. Zanim zaczniesz trening, sprawdź, czy dobry prompt z kontekstem RAG nie rozwiązuje problemu taniej.

Koszt zależy od rozmiaru modelu, liczby przykładów i wybranej techniki. Trening małego modelu 7B metodą LoRA na kilkuset przykładach to kwestia godzin na GPU i relatywnie niskiego kosztu chmurowego. Duże modele 70B+ i pełny fine-tuning to nakład rzędu wielu tygodni pracy inżynierskiej plus koszt infrastruktury. Policz swój przypadek w kalkulatorze inferencji lub omów go w ramach pilotażu.

Nie. Fine-tuning utrwala styl i zachowanie, ale nie daje modelowi niezawodnej pamięci faktograficznej. Model może „nabyć" fakty z danych treningowych, lecz nadal halucynuje, gdy pyta się o coś spoza nich. To RAG z cytowaniem i progiem pewności (eskalacja do human-handoff, gdy brak trafnego fragmentu) jest główną obroną przed halucynacją w systemach produkcyjnych.

Możesz, ale wymaga to ostrożności prawnej. Dane osobowe w zbiorze treningowym podlegają RODO i wymagają podstawy prawnej oraz prawdopodobnie DPIA. Po treningu usunięcie konkretnych danych z wag modelu jest technicznie trudne, co komplikuje realizację prawa do bycia zapomnianym. Zalecamy przed startem audyt danych z prawnikiem i wybór architektury, w której PII do treningu zostaje w Waszej infrastrukturze. Artykuł AI Act i RODO 2026 opisuje obowiązki szczegółowo.

Zacznij od zebrania dobrych par treningowych, nie od wyboru infrastruktury. Zidentyfikuj 200-500 konkretnych przykładów wejście-wyjście, które ilustrują oczekiwane zachowanie modelu. Oddziel od razu 10-20% jako hold-out do ewaluacji. Dopiero z tymi danymi gotowymi planuj infrastrukturę i harmonogram. Pomocny jest blueprint agenta, który pozwala zmapować architekturę całego systemu przed wejściem w szczegóły treningu.