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.*