RAG a fine-tuning — jak dobrać podejście do LLM w produkcji (2026)

Dwa najczęstsze sposoby „dopasowania” dużego modelu językowego do Twojej firmy to RAG (dokładanie kontekstu z dokumentów przy zapytaniu) oraz fine-tuning (dostrajanie wag na Twoich przykładach). To nie są substytuty — rozwiązują różne klasy problemów. Źle dobrane podejście oznacza zbędne koszty GPU, halucynacje przy faktach albo sztywny ton, którego nie naprawisz samym promptem.

Zanim jednak dotkniesz indeksu wektorowego lub checkpointu LoRA, sprawdź prompt engineering: dobry system prompt, few-shot i format wyjścia (JSON/rama odpowiedzi) często dają 80% efektu w kilku dniach. Do RAG przechodzisz, gdy model potrzebuje faktów z Twojej bazy wiedzy; do fine-tuningu — gdy powtarzalnie potrzebujesz konkretnego stylu, procedury lub struktury wyjścia.

RAG dostarcza aktualnych faktów do kontekstu; fine-tuning koduje nawyki odpowiedzi w parametrach. Najlepsze produkty często używają obu warstw naraz.

Szybkie porównanie — co rozwiązujesz którym podejściem

RAG — co realnie decyduje o jakości

Model bazowy zostaje zamrożony; w czasie rzeczywistym dokładasz fragmenty tekstu pobrane semantycznie z Twojej kolekcji. Jakość końcowej odpowiedzi zależy więc nie tylko od GPT czy Claude, ale od embeddingów, podziału dokumentów na fragmenty (chunking), ewentualnego hybrid search (BM25 + wektory), rerankingu oraz polityki „co robimy, gdy nic nie znajdziemy”.

Chunking i overlap

• Stały rozmiar (np. 512 tokenów) jest prosty, ale często tnie akapity w złych miejscach — na start lepszy jest podział rekurencyjny z nakładką 10–20%.
• Dla dokumentacji technicznej sprawdza się układ „dziecko–rodzic”: małe fragmenty do wyszukiwania, większy blok do pokazania modelowi.
• Metadane (rozdział, produkt, wersja) poprawiają filtrowanie zanim w ogóle dotkniesz embeddingów.

Zaawansowane wzorce

• Przepisanie zapytania (query rewriting) — żargon użytkownika ≠ język dokumentów.
• Większy top-k + reranker krzyżowy — najpierw szeroki recall, potem precyzyjny ranking.
• Self-RAG / krytyk — model ocenia, czy retrieval był potrzebny i czy fragment jest wiarygodny.

Fine-tuning — kiedy ma sens dostrajanie wag

Fine-tuning zmienia zachowanie modelu na poziomie parametrów: mniej „instrukcji w promptcie”, krótsze prompty przy stabilnym formacie i często niższy koszt tokenów na zapytanie po wdrożeniu. Najczęściej spotykamy LoRA i QLoRA zamiast pełnego treningu — mniej GPU, krótsze iteracje, wystarczająca jakość dla klasycznych zadań klasyfikacji, ekstrakcji czy ujednolicenia tonu.

1. 1Spisz specyfikację zachowania: format wejścia/wyjścia, lista zakazów i przykłady „złych” odpowiedzi.
2. 2Zacznij od 50–100 ręcznie przygotowanych par jakościowych — liczy się jakość etykiet, nie liczba śmieci.
3. 3Skaluj np. generacją kandydatów z dużego modelu + recenzją eksperta; deduplikuj i usuwaj sprzeczności.
4. 4Trenuj z walidacją na osobnym zbiorze; obserwuj regresje przy kolejnych wersjach danych.

Ekonomia: RAG vs fine-tuning przy skali zapytań

RAG obciąża każde zapytanie: embedding zapytania, odczyt z bazy wektorowej, często dłuższy prompt z kontekstem. Fine-tuning ma wyższy koszt jednorazowy, ale po przełomowej liczbie żądań krótszy prompt może obniżyć koszt tokenów i opóźnienie. Punkt zwrotny zależy od cen dostawcy, średniej długości kontekstu i tego, ile razy retrenujesz model przy zmianie polityk.

• RAG: typowo szybszy time-to-value dla zmieniającej się wiedzy (produkty, regulacje, oferta).
• Fine-tuning: często zwycięża przy bardzo dużej liczbie podobnych zapytań i stabilnym zadaniu.
• Ukryte koszty RAG: hosting kolekcji, monitoring jakości retrievalu, aktualizacja indeksu.
• Ukryte koszty FT: retrening przy driftcie danych, regresje jakości, utrzymanie benchmarków.

Ewaluacja — bez metryk budujesz na ślepo

• Dla RAG: precyzja/recall retrievalu, relevance fragmentów, „faithfulness” odpowiedzi względem cytatów.
• Dla FT: metryki zadaniowe (np. F1, dokładność ekstrakcji) + ocena ludzka na próbce.
• Zawsze: latencja p50/p95, koszt na zapytanie, część konwersacji eskalowanych do człowieka.
• LLM jako sędzia przyspiesza iteracje — ale okresowo kalibruj wyniki z ekspertami domenowymi.

Strategia hybrydowa w produkcji

Doświadczenie wdrożeniowe: fine-tuning uczy formatu i stylu pracy z dostarczonym kontekstem; RAG dostarcza treści, które zmieniają się częściej niż rozpuszczalny w checkpointach. W ten sposób unikasz „zamułowania” polityk w modelu i jednocześnie nie musisz za każdym razem pisać kilometrowego system promptu.

Bezpieczeństwo i compliance

• Prompt injection i manipulacja retrieval — limity źródeł, walidacja formatów, polityki „brak kontekstu = bezpieczna odmowa”.
• Redakcja PII przed logowaniem; dla regulowanych branż — ścieżka audytu zapytań i odpowiedzi.
• Przy FT: upewnij się, że zbiór treningowy nie zawiera sekretów ani danych osobowych bez podstawy prawnej.

Checklist przed decyzją

1. 1Czy problem da się rozwiązać promptem + narzędziami (JSON schema, funkcje)? Jeśli tak — zostań przy tym.
2. 2Czy wiedza zmienia się częściej niż raz na kwartał? Jeśli tak — mocna strona RAG.
3. 3Czy potrzebujesz cytowań z dokumentów? Jeśli tak — RAG lub hybryda.
4. 4Czy potrzebujesz ultrakonsekwentnego formatu/stylu przy milionach żądań? Rozważ FT lub hybrydę.
5. 5Zaplanuj budżet na eval i monitoring — bez tego ani RAG, ani FT nie są „ukończone”.

Prompt ustala zasady gry. RAG podaje fakty z Twoich materiałów. Fine-tuning uczy nawyku odpowiedzi. W produkcji często potrzebujesz wszystkich trzech warstw.

Projektujecie produkt na LLM — od prototypu RAG po fine-tuning i infrastrukturę inferencji: pomagamy dobrać architekturę, metryki i bezpieczną ścieżkę do produkcji.