Fine-tuning LLM na danych firmy - kiedy warto, jak zacząć i czego unikać

Fine-tuning warto robić gdy masz problem ze stylem, terminologią lub głosem marki - nie z wiedzą. Jeśli model nie zna Twoich danych (cennik, produkty, procedury), rozwiązaniem jest RAG, nie fine-tuning. Jeśli model zna, ale wyraża to w "asystenckim" języku zamiast w Twoim - fine-tuning ma sens, pod warunkiem że masz co najmniej 500 par treningowych (wejście/wyjście). W 80% przypadków lepszy prompt z przykładami rozwiązuje problem szybciej i taniej.

Praktyczny przewodnik po fine-tuningu modeli językowych: kiedy wybrać FT zamiast RAG lub lepszego promptu, jak przygotować dane JSONL, QLoRA na RTX 4090 z Unsloth i jak ocenić, czy trening naprawdę poprawił model.

Twój model GPT-4o odpowiada poprawnie - ale pisze jak "ogólny asystent", nie jak ekspert twojej firmy. Terminologia z systemu promptu jest ignorowana. Nazwy produktów przekręcane. Masz 50 000 archiwalnych zgłoszeń supportu, które odzwierciedlają dokładnie taki styl i merytorykę, jakiej chcesz. Fine-tuning?

Może. Właściwe pytanie brzmi inaczej: czy masz problem ze stylem (model wie, ale wyraża to inaczej) - czy problem z wiedzą (model nie wie czegoś, czego powinien)? Od odpowiedzi zależy, czy potrzebujesz fine-tuningu, RAG-a, lepszego promptu - a może żadnego z powyższych.

Kiedy fine-tuning naprawdę ma sens?

Fine-tuning to dobry wybór, gdy spełniony jest co najmniej jeden z poniższych warunków:

• Stały styl i ton marki - model powinien zawsze pisać jak twój najlepszy specjalista, nie jak ogólny asystent; dobry prompt nie gwarantuje tego konsekwentnie przy dłuższych rozmowach
• Specjalistyczna terminologia branżowa - nazwy własne, skróty i procedury, które bazowy model systematycznie przekręca lub nie rozpoznaje
• Ściśle zdefiniowany format wyjścia - raport zawsze w 5 sekcjach, JSON zawsze z polami X i Y; prompt "pisz w formacie..." jest niewystarczający gdy zero błędów struktury to warunek biznesowy
• Redukcja kosztów tokenów - 3000-tokenowy system prompt w każdym wywołaniu kosztuje; fine-tuning "wbudowuje" instrukcje, skracając prompt o 60-80%
• Prywatność przez destylację - kopiujesz zachowanie modelu komercyjnego do self-hosted open-source, który nie wysyła danych poza infrastrukturę firmy
• Szybka klasyfikacja lub routing - fine-tunowany model 7B do jednego zadania jest 10× tańszy i szybszy od GPT-4o na tym samym zadaniu

Kiedy fine-tuning to zły wybór?

• Potrzebujesz aktualnych informacji - model ma cutoff treningowy; dane z ostatnich 6 miesięcy wymagają RAG, nie fine-tuningu
• Chcesz dodać wiedzę faktyczną - "naucz model naszej bazy produktów" to zadanie dla RAG; fine-tuning uczy formatu odpowiedzi, ale fakty z małego datasetu są podatne na halucynacje
• Masz mniej niż 300 przykładów - za mało danych prowadzi do catastrophic forgetting i overfittingu; model traci ogólne umiejętności
• Lepszy prompt nie był próbowany - zacznij od optymalnego system promptu z 5-10 few-shot examples; to rozwiązuje 80% problemów ze stylem bez kosztów GPU
• Wymagania zmieniają się co tydzień - aktualizacja fine-tuned modelu to nowy cykl treningowy; prompt można zmienić w 5 minut

Rodzaje fine-tuningu w 2025 roku

Ekosystem fine-tuningu ma pięć głównych podejść:

• Full fine-tuning - aktualizacja wszystkich wag modelu; najlepsza jakość, ale wymaga dziesiątek GB VRAM na wielu kartach GPU; zarezerwowane dla laboratoriów AI z infrastrukturą wartą miliony dolarów
• SFT (Supervised Fine-Tuning) - uczenie na parach instrukcja→odpowiedź; standard dla zastosowań biznesowych; prawie zawsze stosowany z LoRA lub QLoRA zamiast pełnego FT
• LoRA (Low-Rank Adaptation) - dodaje małe macierze A×B do warstw attention zamiast aktualizować wszystkie wagi; trenuje 0.1-1% parametrów przy jakości zbliżonej do full FT i 90% mniejszym zużyciu VRAM
• QLoRA (Quantized LoRA) - LoRA z kompresją modelu bazowego do 4 bitów; pozwala trenować 7B na RTX 4090 (24 GB) i 13B na A100 (40 GB); standard przemysłowy 2025 dla firm bez GPU data center
• DPO (Direct Preference Optimization) - uczenie z par dobra/zła odpowiedź zamiast nagród RLHF; eliminuje niechciane zachowania modelu; stosowany do alignment i bezpieczeństwa

Jak przygotować dane treningowe?

Jakość danych jest ważniejsza niż ich ilość. 500 perfekcyjnych przykładów pokona 10 000 byle jakich.

Format JSONL:

• Każda linia to jeden przykład JSON z polami: system (instrukcja systemowa), input (pytanie lub zadanie), output (oczekiwana odpowiedź)
• Alternatywnie: format messages-based z rolami (kompatybilny z OpenAI fine-tuning API)
• Kodowanie: UTF-8, bez BOM, polskie znaki bez eskapowania

Ile przykładów potrzebujesz:

• Klasyfikacja prosta (2-5 klas): 100-300 przykładów wystarczy
• Zmiana stylu i tonu: 300-1000 przykładów
• Złożone generowanie wieloetapowe: 1000-5000 przykładów
• Destylacja zachowania GPT-4 do mniejszego modelu: 5000-50 000 przykładów

Jak zebrać dane:

• Eksport i filtrowanie historycznych odpowiedzi supportu ocenionych przez QA - najlepsze źródło, bo odzwierciedla realne wzorce konwersacji
• Generowanie syntetyczne przez GPT-4o z instrukcją "generuj 50 par input/output dla zadania X w stylu Y" z weryfikacją człowieka na 20% próbce
• Ręczna anotacja przez ekspertów domenowych dla zastosowań krytycznych (prawo, medycyna, finanse)
• Augmentacja: parafrazy tych samych pytań zwiększają odporność modelu na wariacje wejścia

Czego unikać w danych:

• Duplikaty i quasi-duplikaty (podobieństwo > 30%) - prowadzą do overfittingu na konkretnych frazach
• Sprzeczne przykłady (identyczne wejście, różne wyjście) - dezorientują model podczas gradientu
• Brak podziału train/validation (90/10) - bez holdout setu nie wykryjesz overfittingu w porę

LoRA i QLoRA - fine-tuning na jednej karcie GPU

LoRA to matematyczny trick: zamiast modyfikować macierz wag W (np. 4096×4096 = 16 mln parametrów), dodaje dwie małe macierze: A (4096×rank) i B (rank×4096). Trenowane są tylko A i B. Przy rank=16 liczba parametrów spada z 16 mln do 131 tysięcy - 122× mniej - przy jakości zbliżonej do full fine-tuningu na wąskich zadaniach.

QLoRA dodaje kwantyzację modelu bazowego do 4 bitów (format NF4 z biblioteki bitsandbytes). Efekt: model 7B zajmujący normalnie 14 GB w bf16 zajmuje 4 GB skwantyzowany, plus ~0.5 GB na adaptery LoRA. RTX 4090 z 24 GB VRAM obsługuje trening z batch 2 i sekwencją 2048 tokenów bez problemów.

# finetune_qlora.py - QLoRA z Unsloth (2-3x szybciej niz standardowy HF Trainer)from unsloth import FastLanguageModelfrom trl import SFTTrainerfrom transformers import TrainingArgumentsfrom datasets import load_datasetMAX_SEQ_LEN = 2048RANK = 16model, tokenizer = FastLanguageModel.from_pretrained(    model_name="unsloth/llama-3-8b-bnb-4bit",    max_seq_length=MAX_SEQ_LEN,    load_in_4bit=True,)model = FastLanguageModel.get_peft_model(    model,    r=RANK,    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],    lora_alpha=RANK * 2,    lora_dropout=0.05,    bias="none",    use_gradient_checkpointing=True,)dataset = load_dataset("json", data_files="train.jsonl", split="train")TEMPLATE = "<|system|>\n{system}\n<|user|>\n{input}\n<|assistant|>\n{output}"def format_chat(ex):    return {"text": TEMPLATE.format(**ex)}dataset = dataset.map(format_chat)trainer = SFTTrainer(    model=model,    tokenizer=tokenizer,    train_dataset=dataset,    dataset_text_field="text",    max_seq_length=MAX_SEQ_LEN,    args=TrainingArguments(        output_dir="./output",        num_train_epochs=3,        per_device_train_batch_size=2,        gradient_accumulation_steps=4,        learning_rate=2e-4,        fp16=True,        logging_steps=10,        save_steps=200,        warmup_ratio=0.03,        lr_scheduler_type="cosine",        report_to="none",    ),)trainer.train()model.save_pretrained_merged("./my-model", tokenizer, save_method="merged_16bit")

Unsloth przyspiesza trening 2-3× względem standardowego HuggingFace Trainer i redukuje zużycie VRAM o kolejne 50-60%. Gotowy model można załadować przez Ollama (lokalne wdrożenie i testy), vLLM (produkcyjne API z wysoką przepustowością) lub Hugging Face Inference Endpoints.

Gdzie i za ile trenować?

Jak ocenić, czy fine-tuning poprawił model?

Subiektywne "wygląda lepiej" nie wystarczy w środowisku produkcyjnym. Potrzebujesz mierzalnych metryk:

• LLM-as-judge - GPT-4o ocenia w skali 1-5 każdą odpowiedź fine-tuned modelu vs bazowego na 100-przykładowym holdout secie; metoda tania, skalowalna i wysoko korelująca z ocenami ludzkimi
• Task accuracy - dla klasyfikacji: accuracy i F1; dla ekstrakcji danych: precyzja i recall kluczowych pól
• Regression test - 50 przykładów poza domeną fine-tuningu; sprawdź, że model nie utracił ogólnych umiejętności (catastrophic forgetting)
• Latency i koszt - czy krótszy system prompt po fine-tuningu faktycznie redukuje czas i koszt wywołania o planowane 40-60%?
• Hallucination rate - jeśli model podaje fakty: jaki procent odpowiedzi zawiera wymyślone informacje przed i po fine-tuningu?

Najczęstsze błędy przy fine-tuningu

• Fine-tuning zamiast dobrego promptu - 80% problemów ze stylem i formatem rozwiązuje optymalny system prompt z 5 few-shot examples; sprawdź to zanim wydasz czas i pieniądze
• Za mało danych = overfitting - model perfekcyjnie odtwarza dane treningowe, ale pada na nowe wejścia; symptom: validation loss rośnie gdy training loss spada
• Za dużo epok - 3-5 epok to zazwyczaj optimum dla SFT; 10+ epok = overfitting i degradacja ogólnych umiejętności modelu
• Trening na danych bez QA - model nauczy się błędów z danych; każdy przykład wymaga weryfikacji człowieka lub LLM-judge
• Brak testów regresji - fine-tuning na wąskiej domenie może skrzywić odpowiedzi poza domeną; zawsze testuj pytania ogólne po treningu
• Vendor lock-in danych - dane treningowe to zasób strategiczny; zachowaj je w formacie JSONL niezależnie od platformy; trenuj równoległe modele open-source jako backup
• Brak monitoringu po wdrożeniu - fine-tuned model może degradować się gdy rozkład wejść się zmienia; monitoruj quality metrics regularnie i zaplanuj cykl retrainingu

Lista kontrolna przed fine-tuningiem

1. 1.Sprawdź, czy lepszy prompt lub few-shot examples rozwiązuje problem - zainwestuj 2-4 godziny przed przejściem dalej
2. 2.Sprawdź, czy RAG nie rozwiązuje problemu lepiej i taniej (jeśli to problem wiedzy faktycznej - użyj RAG)
3. 3.Zbierz minimum 500 par input/output z QA na każdym przykładzie w formacie JSONL
4. 4.Podziel dane: 90% trening, 10% walidacja, plus 50-100 przykładów holdout poza podziałem
5. 5.Wybierz platformę według budżetu i wymagań prywatności danych (szczególnie GDPR i HIPAA)
6. 6.Zacznij od modelu 7B - fine-tuning 7B jest 3× tańszy niż 13B przy podobnej jakości na wąskich zadaniach
7. 7.Po treningu zrób A/B test na holdout secie z LLM-as-judge: fine-tuned vs bazowy vs model z lepszym promptem
8. 8.Zaplanuj cykl retrainingu co 3-6 miesięcy w miarę jak zmienia się domena i wzorce wejść

---

Pomagam firmom ocenić, czy fine-tuning to właściwy krok - i jeśli tak, przeprowadzam cały proces: od audytu i przygotowania danych przez trening QLoRA po deployment i monitoring jakości. Napisz do mnie - zaczynam od bezpłatnej 30-minutowej analizy twojego przypadku użycia.

Powiązane artykuły

• Jak wybrać model LLM
• Self-hosted LLM - Ollama, vLLM
• Ewaluacja LLM - jak mierzyć jakość