Firma wdraża RAG nad wewnętrzną dokumentacją, wyniki są przyzwoite, ale model nadal popełnia dziwne błędy — nie rozumie skrótów, myli pojęcia z branży, a w formułowaniu odpowiedzi zachowuje się ogólnikowo. Zespół próbuje SFT (supervised fine-tuning) na kilkuset przykładach. Poprawia się, lecz pogłębionej wiedzy domenowej wciąż brakuje. Pada propozycja: „A gdyby tak douczyć model na całej firmowej dokumentacji? Na wszystkich tych 800 plikach PDF?"
To dokładnie sytuacja, w której wkracza continued pretraining — metoda plasująca się między trenowaniem modelu od zera a klasycznym domenowym fine-tuningiem. Jest potężniejsza, droższa i mniej zbadana niż SFT. I właśnie dlatego warto ją zrozumieć, zanim się ją wdroży lub odrzuci.
Czym jest continued pretraining, a czym nie jest
Continued pretraining (nazywany też domain-adaptive pretraining, DAPT lub second-stage pretraining) to proces, w którym bierzesz gotowy pretrenowany model i kontynuujesz jego trenowanie w stylu pretrainingu — czyli na dużym korpusie nieoznaczonych tekstów, z wykorzystaniem causal language modeling (przewidywanie następnego tokenu).
Różnica względem klasycznego fine-tuningu (SFT) jest fundamentalna:
- SFT trenuje model na oznaczonych parach wejście–wyjście (pytanie–odpowiedź, instrukcja–wynik). Uczy model *jak się zachowywać* i *jak odpowiadać*. Wymaga relatywnie małych, lecz starannie oznaczonych datasetów.
- Continued pretraining trenuje model na surowych tekstach bez ustrukturyzowanych odpowiedzi. Uczy model *czego się nauczył* — rozkładu języka, pojęć, wzorców i faktografii konkretnej domeny. Wymaga dużej ilości tekstu, ale bez ręcznego labelowania.
Kolejne częste nieporozumienie: continued pretraining to nie to samo co full fine-tuning. Full fine-tuning opisuje, *ile wag jest trenowanych* (wszystkie, w odróżnieniu od LoRA). Continued pretraining opisuje, *jaki typ trenowania* jest wykonywany (dalszy pretraining vs. instrukcyjny fine-tuning). Continued pretraining można prowadzić przez LoRA, QLoRA i przez pełną aktualizację parametrów — to ortogonalne wymiary.
Kiedy continued pretraining ma sens
Nie każdy problem domenowy wymaga continued pretrainingu. Z praktyki widzimy, że ma sens w trzech głównych scenariuszach:
1. Nowa domena o wysokiej gęstości technicznej i własnym języku
Gdy Twoja domena używa terminologii, skrótów i fraz rzadko spotykanych lub nieobecnych w standardowych danych treningowych. Przykłady: dokumentacja przemysłowa z dziesiątkami tysięcy skrótów, wąskie subdyscypliny medyczne, firmowy język regulacyjny, normy techniczne. Model po SFT potrafi co prawda *formatować* odpowiedzi, ale nie rozumie głęboko pojęć — i to widać przy konkretnych pytaniach.
2. Brak oznaczonych danych, ale nadmiar surowego tekstu
Labelowanie danych pod SFT jest drogie i czasochłonne. Jeśli masz 500 GB dokumentacji technicznej, ale tylko 500 starannie oznaczonych przykładów Q&A, continued pretraining pozwala wykorzystać cały korpus tekstowy bez konieczności labelowania. Potem następuje SFT jako „nastrojenie zachowania" na tej nowej bazie wiedzy.
3. Inny język lub mieszanie języków
Większość popularnych modeli open-weight jest zdominowana przez angielski. Jeśli potrzebujesz silnych możliwości w języku polskim, słowackim, czeskim lub innych językach słabiej reprezentowanych w oryginalnym pretrainingu, continued pretraining na dużym korpusie językowym znacząco poprawi możliwości w danym języku — w tym gramatykę, idiomy i kontekst kulturowy.
Z kolei continued pretraining *nie ma sensu*, gdy: - Masz wystarczająco dużo dobrych przykładów Q&A, a domena nie różni się radykalnie od oryginalnego pretrainingu - Twoją główną potrzebą jest zmiana *zachowania* (format, ton, odmawianie, struktura odpowiedzi) — to zadanie dla SFT lub DPO - Masz ograniczony budżet obliczeniowy i potrzebujesz szybkiego rezultatu
Typowy pipeline: jak to wygląda w praktyce
Gdy zdecydujesz się na continued pretraining, masz przed sobą proces wielofazowy. Skróty nie popłacają.
Faza 1 — Przygotowanie korpusu
To najdłuższa i najważniejsza faza. Tekst źródłowy musi być wyczyszczony: bez duplikatów, bez artefaktów OCR, bez nieistotnych treści (stopki, nawigacja, pola formularzy). Zalecana jest też deduplikacja na poziomie n-gramów — model nie powinien widzieć tego samego zdania sto razy, bo prowadzi to do memoryzacji zamiast generalizacji.
Rozmiar korpusu: dla zauważalnego efektu mówimy w praktyce o *setkach milionów tokenów*, idealnie *miliardach*. Standardowy dokument techniczny w formacie PDF to po przetworzeniu rzędu 50–200 tysięcy tokenów. Pięćset takich dokumentów daje więc rzędu 25–100 milionów tokenów — co sytuuje się na dolnej granicy sensownego continued pretrainingu.
Ważny szczegół: mixed pretraining jest lepszy niż czysto domenowy. Jeśli trenujesz wyłącznie na tekstach domenowych, model zapomina ogólne umiejętności, a jego język „tężeje" na jeden rejestr. Dobra recepta to miks 80–90% danych domenowych i 10–20% tekstu ogólnego (np. quality web corpus). Ogranicza to katastrofalne zapominanie.
Faza 2 — Konfiguracja trenowania
Kluczowa różnica względem SFT: learning rate musi być znacznie niższy niż przy pretrainingu od zera. Typowo stosuje się wartości rzędu 1e-5 do 1e-4, czyli zwykle 10–100× niższe niż przy oryginalnym pretrainingu. Za wysoki learning rate — model „zapomina" to, co wiedział; za niski — brak adaptacji domenowej.
W kwestii architektury trenowania: większość zespołów sięga po LoRA lub QLoRA nawet przy continued pretrainingu, ponieważ pełna aktualizacja parametrów jest ekstremalnie kosztowna. LoRA przy continued pretrainingu działa — nie tak dobrze jak pełne wagi, ale w praktyce wystarczająco dla większości adaptacji domenowych.
Faza 3 — SFT jako finalizacja
Continued pretraining sam w sobie nie wytworzy modelu „rozmówczego". Wytworzy model, który głęboko rozumie domenę, ale potrafi jedynie generować swobodny tekst. Dlatego po continued pretrainingu niemal zawsze wykonuje się SFT (a niekiedy DPO), aby model nauczył się poprawnie reagować na instrukcje, odpowiadać na pytania i przestrzegać formatu. Więcej o tym pipeline znajdziesz w artykule o wyborze między SFT, DPO i GRPO.
Koszty i wymagania sprzętowe
Trzeba tu być szczerym: continued pretraining jest *droższy* od SFT — i to odczuwalnie.
W przypadku SFT na 10 000 przykładach mówimy o godzinach trenowania na jednej A100 — rzędu dziesiątek dolarów. Continued pretraining na 500 milionach tokenów może trwać dni nawet na kilku GPU — i to przy LoRA. Pełna aktualizacja parametrów na korpusie miliardowym może wymagać dziesiątek godzin A100, co w chmurze przekłada się na koszty od setek do tysięcy euro.
Orientacyjne dane z praktyki: - LoRA continued pretraining modelu 7B na ~200M tokenach: rzędu 10–30 godzin na jednej A100 80 GB - QLoRA 4-bit continued pretraining modelu 7B na tym samym korpusie: dłużej (dequantyzacja spowalnia), ale zmieścisz się na konsumenckim GPU z 24 GB VRAM - Pełna aktualizacja parametrów modelu 13B: multi-GPU praktycznie konieczne
Ceny A100 w chmurze wynoszą dziś rzędu od ~$0.60/h (ceny spot u mniejszych dostawców) do ~$3–4/h u dużych hyperscalerów. Zaplanuj bufor — pierwszy run zwykle ujawnia problemy z danymi i trenowanie trzeba uruchomić ponownie.
Ryzyka, które widzimy w praktyce
Katastrofalne zapominanie to realne zagrożenie. Model po zbyt agresywnym continued pretrainingu może zdegradować swoje ogólne możliwości — gorszy angielski, gorsze śledzenie instrukcji, gorsza logika. Rozwiązania: niski learning rate, mixed training (patrz wyżej), ewentualnie regularyzacja. Oceniaj nie tylko wydajność domenową, ale też ogólne benchmarki przed i po trenowaniu.
„Model tylko zapamiętuje" — jeśli korpus jest mały i zawiera wiele powtarzających się dokumentów, model uczy się cytować teksty zamiast je rozumieć. Deduplikacja i różnorodność danych są obowiązkowe.
Naiwne dane = naiwny model — w 2026 roku znaczna część nowego tekstu w sieci jest generowana przez AI, co przy web crawlingu niesie ryzyko trenowania na syntetycznej, rozproszonej generacji. W przypadku przemysłowej dokumentacji firmowej zwykle nie jest to problem, ale uważaj przy pozyskiwaniu zewnętrznych źródeł.
Ryzyka regulacyjne i związane z danymi — continued pretraining na dokumentacji firmowej może niechcący „wymazać" guardrails z oryginalnego modelu instruction-tuned. Po continued pretrainingu następuje SFT i alignment fine-tuning (DPO lub GRPO), które przywracają te mechanizmy. Jeśli ten krok pominiesz, masz model bez wbudowanych zachowań bezpieczeństwa. Dla branż regulowanych jest to krytyczne.
O innych przyczynach niepowodzeń adaptacji domenowej piszemy szczegółowo w artykule o najczęstszych przyczynach nieudanego fine-tuningu.
Alternatywa: kiedy RAG zastępuje continued pretraining
Dla wielu firm continued pretraining jest złą odpowiedzią na właściwe pytanie. Gdy celem jest, żeby model „znał treść dokumentów", RAG (Retrieval-Augmented Generation) rozwiązuje to taniej, szybciej i z lepszą aktualizowalnością. Model nie musi dokumentów „wiedzieć" — wystarczy, że dostanie je do kontekstu w chwili zapytania.
Continued pretraining jest lepszym wyborem, gdy: - Język domenowy jest na tyle specyficzny, że retrieval nie wystarczy (model nie rozumie pojęć nawet po ich dostarczeniu do kontekstu) - Potrzebujesz niskich opóźnień bez kroku retrieval (wdrożenie edge, procesy real-time) - Chcesz, żeby model generował treść w języku domenowym, nie tylko odpowiadał na pytania
RAG i continued pretraining nie wykluczają się wzajemnie — najlepsze wyniki w praktyce osiąga kombinacja: model zaadaptowany domenowo z RAG nad aktualną dokumentacją. Więcej o wyborze między tymi podejściami znajdziesz w porównaniu RAG vs fine-tuning.
Praktyczne ramy decyzyjne
Gdy klient przychodzi z pytaniem „czy douczyć model, czy nie", przechodzimy przez następujące kroki:
- 1.Co dokładnie nie działa? — zły format/ton → SFT; model nie rozumie pojęć → continued pretraining; model cytuje nieaktualne informacje → RAG; model halucynuje fakty → kombinacja
- 2.Ile nieoznaczonego tekstu masz? — mniej niż 10 milionów tokenów? Continued pretraining prawdopodobnie się nie opłaca; 100M+ tokenów? Warto rozważyć
- 3.Jaki jest Twój budżet obliczeniowy? — jeśli nie masz dostępu do A100+ lub cloud GPU, zacznij od SFT; continued pretraining jest dla zespołów z ugruntowaną infrastrukturą ML
- 4.Czy domena jest naprawdę specyficzna? — jeśli Twój język branżowy można znaleźć też w zwykłym tekście webowym, SFT na dobrych przykładach wystarczy
Najczęstsze pytania
Czy continued pretraining to to samo co domain-adaptive pretraining?
W zasadzie tak — terminy są używane zamiennie. „Domain-adaptive pretraining" (DAPT) to termin akademicki ze środowiska badawczego, „continued pretraining" jest częstszy w przemyśle. Oba opisują to samo: kontynuację pretrainingu na domenowo specyficznym korpusie nieoznaczonych tekstów.
Czy mogę prowadzić continued pretraining przez LoRA, czy potrzebna jest pełna aktualizacja parametrów?
LoRA (a także QLoRA) działa przy continued pretrainingu i większość zespołów preferuje je właśnie ze względu na oszczędność pamięci. Pełna aktualizacja parametrów daje nieznacznie lepsze wyniki, ale różnica jest zwykle mniejsza niż różnica w kosztach. Dla większości adaptacji domenowych LoRA jest wystarczające.
Ile tekstu potrzebuję, żeby uzyskać zauważalny efekt?
Z praktyki: poniżej 50 milionów tokenów efekt jest zwykle marginalny. Wyraźna adaptacja domenowa zaczyna być widoczna od setek milionów tokenów. Jeśli masz mniej, lepiej zainwestuj w jakość danych SFT — prawdopodobnie uzyskasz lepszy wynik za niższą cenę.
Czy model po continued pretrainingu straci zdolność do śledzenia instrukcji?
Tak — i to częsta pułapka. Continued pretraining przeprowadzasz typowo na modelu *bazowym* (nie wariancie instruction-tuned), albo jeśli na instruction-tuned — ryzykujesz osłabienie wbudowanych zachowań. Dlatego po continued pretrainingu następuje SFT (i ewentualnie DPO) jako obowiązkowa faza. Nigdy nie wdrażaj modelu po samym continued pretrainingu do produkcji bez warstwy instruction-finetuning.
Czy continued pretraining sprawdza się też dla małych modeli (1B–4B)?
Tak, a niekiedy nawet skuteczniej. Małe modele mają ograniczoną pojemność wiedzy ogólnej, więc domenowe „przepisanie" jest relatywnie większe. Fine-tuned model 4B w wąskiej domenie może w jej ramach przewyższyć generyczny model wielokrotnie większy. Więcej o tym temacie znajdziesz w porównaniu małego fine-tuned modelu z dużym modelem bazowym.
Podsumowanie
Continued pretraining nie jest uniwersalną odpowiedzią na problemy z domenowym LLM — ale dla firm z obszerną dokumentacją techniczną, specyficznym językiem branżowym lub potrzebą głębokiej adaptacji językowej to narzędzie, którego SFT po prostu nie zastąpi. Kluczem jest wiedza, kiedy go użyć: gdy model nie rozumie domeny na fundamentalnym poziomie, a nie tylko gdy źle formatuje odpowiedzi.
*Jeśli zastanawiasz się, czy continued pretraining jest właściwym rozwiązaniem dla Twojego przypadku, lub szukasz ram do podjęcia decyzji między RAG, SFT a adaptacją domenową, chętnie to wspólnie przeanalizujemy. MP Industrial Solutions ma doświadczenie we wdrażaniu lokalnych LLM w środowisku przemysłowym — w tym przypadki, w których odradziliśmy continued pretraining i zaproponowaliśmy prostsze rozwiązanie.*