Klient mówi: „Chcemy wgrać naszą dokumentację firmową do GPT-5 / Claude / Llama, żeby odpowiadał na pytania naszych pracowników / klientów / partnerów." Połowa wyobraża sobie fine-tuning, druga połowa RAG, a trzecia połowa niepewną mieszaninę obu. Ten artykuł to ramy decyzyjne dla pierwszego warsztatu: kiedy RAG, kiedy fine-tuning, kiedy kombinacja, a kiedy powinni Państwo poczekać pół roku i nie wdrażać nic.
Dwa światy, dwa cele
RAG (Retrieval-Augmented Generation): - Dane są zewnętrzne, model ich nie zobaczy przy treningu - Przy inference model dostaje pytanie + odpowiednie kawałki danych jako kontekst - „Daj mi 5 najbardziej odpowiednich ustępów z dokumentacji, które odpowiadają na pytanie X" → wysyłamy modelowi - Model odpowiada uwzględniając dokładną dokumentację, może cytować źródło
Fine-tuning: - Dane są zapieczone w wagach modelu podczas treningu - Przy inference model „pamięta" dane (albo przynajmniej ich statystyczne odbicie) - Model odpowiada ze stylem / formatem / wiedzą domenową, której go uczyliśmy - Pierwotne źródło danych NIE JEST dostępne przy inference, tylko jego parametryczna reprezentacja
Te dwa światy nie rozwiązują tego samego problemu. Najczęstszy błąd klientów: decydują się na fine-tuning, gdy ich realny problem wymaga RAG.
Test: które jest Państwa zadanie?
Odpowiedzcie na te cztery pytania:
1. Szukacie w danych FAKTÓW czy uczycie STYLU?
- Fakty („Jaka jest nasza cena za godzinę dla klienta X?", „Jakie są parametry maszyny Y?") → RAG. Fakt musi być precyzyjnie wczytany z autorytatywnego źródła. Fine-tunowany model sobie fakt wymyśla (halucynacja jest nieprzewidywalną funkcją danych treningowych).
- Styl („Pisz formalnym językiem prawniczym", „Odpowiadaj w ustrukturyzowanym formacie naszych raportów technicznych") → fine-tuning może pomóc. RAG z właściwym system prompts często osiąga 80–90 % tego samego wyniku.
2. Jak często zmieniają się dane?
- Dziennie / tygodniowo → RAG. Re-trenować model przy każdej zmianie danych kosztuje $50–500 i 2–8 godzin. Re-indeksować RAG knowledge base = 5 minut, 0,5 EUR.
- Miesięcznie / kwartalnie → którekolwiek. RAG jest równie wygodny.
- Raz na 2+ lat → fine-tuning można rozważyć, jeśli to stabilna wiedza domenowa (protokoły medyczne, kodeksy prawne, normy techniczne).
3. Musi odpowiedź być audytowalna?
- Tak (branże regulowane) → RAG jest niemal obowiązkowy. Klient musi móc udowodnić: „Model powiedział X, bo widział Y w dokumencie Z." Fine-tuned model „powiedział X" bez możliwości udowodnienia, skąd to wie.
- Nie → fine-tuning wchodzi w grę.
4. Jaką ilość danych macie?
- < 100 k tokenów → ani RAG ani fine-tuning. Wstawcie je wprost w system prompt modelu z 200k context window (Claude Sonnet 4.6, Gemini 2.5 Pro). Najprościej, najszybciej.
- 100 k – 10 M tokenów → RAG jest optymalne. Wektorowy index nad 1–10 M tokenami to 200 MB pamięci, sub-100ms latencja.
- 10 M – 1 B tokenów → RAG działa, ale potrzebuje bardziej wyrafinowanej architektury (multi-stage retrieval, hybrid search, reranking). Fine-tuning jako pomoc, nie jako zastąpienie.
- > 1 B tokenów → fine-tuning jako pre-training step + RAG na szczycie.
Kiedy fine-tuning jednoznacznie wygrywa
1. Język domenowy / terminologia
Słowacka judykatura, łacina medyczna, skróty techniczne w Państwa firmie („PVRZ" = nazwa protokołu produkcyjnego, którego nawet Google nie odgadnie). Bazowy model nie zna. Fine-tuning go nauczy.
Przykład: Mistral 7B fine-tunowany na 5 000 przykładach słowackiej dokumentacji prawnej → odpowiada we właściwym języku prawniczym, zna terminologię „odporca", „navrhovateľ", „dohodárenstvo", „zmiernenie sankcie" we właściwym kontekście. Bazowy model pisze stylem Wikipedii.
Koszt: SFT na 5 000 przykładach, RTX 4090, ~6 godzin, ~10 EUR energia. Realnie w praktyce.
2. Ustrukturyzowane wyjścia z surowym formatem
„Zawsze odpowiadaj JSON z tym schema." System prompt osiąga 95 % precyzji. Fine-tuning osiąga 99,5+ % precyzji. W systemach produkcyjnych różnica 95 % vs. 99,5 % jest życiowo ważna — przy 95 % macie 5 % parse errors, które przelewa całą downstream pipeline.
3. Prędkość (latencja + cost) w high-throughput
RAG = embedding (50 ms) + retrieval (100 ms) + LLM z rozszerzonym promptem (8 000 tokenów × 100 RPS = expensive). Fine-tuned model = LLM z krótkim promptem (500 tokenów × 100 RPS).
Przy >100 RPS workloads fine-tuning jest 5–10× tańszy. Przy <10 RPS nie ma znaczenia.
4. Off-line / on-device wdrożenie
Klient mobilny nie może wywołać RAG knowledge base. Fine-tuned model 1B–4B działający na urządzeniu (CoreML, ExecuTorch, llama.cpp) — ma wszystkie wiedze domenowe zapieczone, żaden internet potrzebny.
Kiedy RAG jednoznacznie wygrywa
1. Dane zmieniają się szybko
Customer support knowledge base, FAQ, product documentation, internal wikis. Dodanie nowego dokumentu = re-index (sekundy). Fine-tuning oznaczałby nowy trening każdego dnia.
2. Cytacje są obowiązkowe
Compliance, prawo, medycyna, doradztwo finansowe. Klient musi widzieć: „Model myśli X, ponieważ artykuł 12 paragraf 3 ustawy Y tak mówi." Fine-tuning nie wyprodukuje cytatów — wyprodukuje sparafrazowaną odpowiedź bez audit trail.
3. Personalizacja per-user
User A widzi swoje dane, user B widzi swoje. Model jest taki sam, ale knowledge base filtruje per-user. Fine-tuned model nie może zmieniać tego, co wie, według usera.
4. Multi-language / multi-domain
Klient ma dokumentację w SK, EN, DE i chce odpowiadać w języku pytania. RAG: jeden model, 3 knowledge bases (lub 1 base z metadanymi języka). Fine-tuning: 3 modele lub bardziej złożony multi-task training.
Podejście hybrydowe — najczęstsza produkcyjna rzeczywistość
W rzeczywistych wdrożeniach w 2026 typowo łączy się:
- 1.Model bazowy: Claude Sonnet 4.6 lub Llama 3.3 70B (open-weight)
- 2.Light fine-tuning (LoRA): na 1–5 k przykładach domain-specific Q&A, uczy model „jak odpowiadać" w stylu i formacie Państwa firmy
- 3.RAG: nad żywymi danymi (dokumenty, baza danych, ticket system)
- 4.System prompt: podsumowuje kontekst, identity, guardrails
- 5.Reranker: BGE-Reranker, Cohere Rerank — po retrieval przestawia kawałki, by najbardziej odpowiednie były najwyżej
Ten stack rozwiązuje: model zna „jak odpowiadać" (fine-tune), zna „aktualne dane" (RAG), zna „kim jesteśmy i jakie są zasady" (system prompt). Plus cytacje źródeł, plus audytowalność.
Konkretne tooling 2026
RAG stack — nasz domyślny wybór
- Wektorowa DB: Qdrant (self-hosted) lub Weaviate. PostgreSQL + pgvector dla małych use-cases (< 1 M wektorów).
- Embedding model: BGE-M3 (open, SK/EN/DE multilingual) lub OpenAI text-embedding-3-large dla setupów cloud-only.
- Reranker: BGE-Reranker-Large lub Cohere Rerank 3.
- Orchestration: LangChain lub LlamaIndex dla quick PoC, własny kod Python dla produkcji (warstwa abstrakcji LangChain staje się tax przy większych systemach).
- Document parsing: Docling (IBM, open) lub Unstructured.io dla PDF/DOCX/HTML.
- Chunking strategy: semantic chunking (250–500 tokens per chunk), 10–20 % overlap, metadata-rich.
Fine-tuning stack — kiedy go używamy
- Framework: Unsloth (2–5× szybszy niż vanilla TRL), HuggingFace TRL dla standardowych workflows.
- Method: LoRA (rank 16–32) lub QLoRA dla VRAM-constrained setupów. Full fine-tuning tylko przy >100 k przykładach.
- Base model: Llama 3.3 70B, Mistral Small 3 (22B), Qwen 2.5 32B według licencji + języka.
- Eval: Custom eval set z 200+ pytaniami + standard benchmarks (MMLU, HellaSwag) na wykrywanie regression.
- Serving: vLLM lub SGLang dla throughput, llama.cpp dla lokalnego / on-device.
Koszty — realne liczby 2026
RAG wdrożenie (typowa B2B knowledge base)
- 50 k dokumentów, 10 M tokenów, 500 RPS peak
- Wektorowa DB: Qdrant na 32GB VPS, $80/miesiąc
- Embedding (BGE-M3 self-hosted): RTX 4090 server, $200/miesiąc amortyzacja
- LLM (Claude Sonnet 4.6): ~$3/M input tokens, ~$15/M output tokens. Przy 500 RPS ze średnio 8 k input + 500 output → $4 500–6 000 miesięcznie
- Total: ~$5 500–6 500/miesiąc plus jednorazowa inicjalizacja $5–15 k
Albo w pełni lokalny stack z Llama 3.3 70B na 2× H100: hardware $80–120 k jednorazowo, eksploatacja $300/miesiąc energia + utrzymanie. Zwrot w porównaniu do cloud-only: 12–18 miesięcy.
Fine-tuning wdrożenie
- Jednorazowy trening (LoRA, 5 000 przykładów, Llama 3.3 70B): $30–80 cloud GPU, lub $5 energii na RTX 4090, jeśli macie własny
- Eval + iteration cycle: 3–6 iterations × $50 = $150–300
- Hosting fine-tuned modelu: taki sam jak bazowy (przewaga LoRA jest zero przy merged weights)
- Utrzymanie: re-trenować co 3–6 miesięcy, gdy zmienia się domena
Realny koszt fine-tuningu przy produkcyjnym systemie: < $1 000 rocznie, jeśli macie zespół zdolny go utrzymywać. Hidden cost to „człowiek, który umie zrobić eval i interpretuje wyniki" — nie GPU.
Kiedy nie wdrażać ani jednego
- Dane są małe (< 50 dokumentów) → użyjcie cloud LLM (Claude Project, GPT Custom GPT, Gemini Workspace) bezpośrednio, żadnej custom infra.
- Zespół nie ma kapacity MLOps i nie są Państwo skłonni zainwestować w data engineera na 6+ miesięcy.
- Domena zmienia się rapidnie (start-up MVP, eksperymentowanie z produktem) → poczekajcie, aż dane się stabilizują.
- Dane klientów są wysoko regulowane i nie macie gotowego DPIA (GDPR impact assessment) — najpierw rozwiążcie compliance, potem wdrażajcie.
---
*Robimy RAG i fine-tuning jako część integracji AI. Jeśli rozważają Państwo wdrożenie LLM nad firemną bazą, pierwsza konsultacja (90 minut) przejdzie te cztery decyzyjne pytania na Państwa rzeczywistym use-case i da Państwu orientacyjną architekturę i budżet zanim zobowiążą się do jednej lub drugiej drogi.*