Przy RAG (Retrieval-Augmented Generation) większość prób debugowania w 2026 skupia się na promptach modelu i system instructions. Klient zmienia prompt 12 razy, siedzi 4 dni i precyzja odpowiedzi poprawia się z 67 % na 70 %. Tymczasem trzy ustawienia w warstwie retrieval — chunking, model embeddingowy, reranking — w pół dnia pracy przesunęłyby precyzję na 84 %. Niniejszy artykuł jest o tych trzech ustawieniach.
Dlaczego retrieval decyduje, nie LLM
Bazowa asymetria architektury RAG: jeśli retrieval zwróci właściwe kawałki dokumentacji, nawet średni model 7B da dobrą odpowiedź. Jeśli retrieval zwróci kawałki nieistotne lub niekompletne, nawet Claude Opus 4.6 nie uratuje odpowiedzi — model po prostu nie ma prawdziwych faktów w kontekście. „Garbage in, garbage out" w RAG to dosłownie prawo fizyczne.
Konkretny przykład: prawny RAG nad polskim ustawodawstwem, 12 000 dokumentów, 8 M tokenów. Z default chunkingiem (500 tokens fixed-size) i OpenAI text-embedding-ada-002 osiągnęliśmy precision@5 = 0,61, recall@10 = 0,72. Po trzech ustawieniach (document-aware chunking, upgrade embeddinga na BGE-M3, Cohere Rerank 3) — precision@5 = 0,84, recall@10 = 0,93. Żadna zmiana LLM, żadna zmiana promptu.
Ustawienie 1: chunk size + chunking strategy
Najczęstsza konfiguracja w projektach PoC: RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) z LangChain default. Działa na 60 % use-case'ów. Dla reszty jest źle.
Dwa wymiary decyzji:
A) Wielkość chunka (tokens)
- 128–256 tokenów — wysoka precyzja, retrieval znajdzie dokładnie ten paragraf, który odpowiada. Ryzyko: kontekstu wokół paragrafu brakuje, model nie widzi całego toku myśli. Odpowiednie dla FAQ, snippetów kodu, danych strukturalnych.
- 256–512 tokenów — najczęstszy kompromis. Paragraf z otoczeniem. Domyślny wybór dla większości wdrożeń B2B knowledge base.
- 512–1024 tokenów — szerszy kontekst, model dostaje więcej powiązań, ale precyzja retrievalu spada (embedding 1 024-tokenowego chunka „rozcieńcza" główny temat). Odpowiednie dla dłuższych dokumentów narracyjnych (orzeczenia prawne, papiery badawcze, manuały techniczne).
- > 1 024 tokenów — rzadko poprawne. Modele embeddingowe mają realnie efektywną długość ~512 tokenów — większość informacji po tym progu „rozpuszcza się" w jeden wektor. Wyjątek: long-context modele embeddingowe (Voyage-3-large, BGE-M3 w pełnym trybie, NV-Embed-v2) radzą sobie efektywnie do 8 192 tokenów.
B) Strategia dzielenia (fixed vs. semantic vs. document-aware)
- Fixed-size chunking — prosty, deterministyczny, ale łamie paragrafy, zdania, nawet słowa na granicy. Utrata kontekstu na ~15 % chunków, co przekłada się na 8–12 % pogorszenia precision@5.
- Semantic chunking — przy pomocy embeddingów wykrywa granice znaczących segmentów (np.
semantic_chunkerw LlamaIndex). Lepiej zachowuje kontekst, ale chunks mają variable size — przy inference trzeba liczyć z rozrzutem 200–800 tokenów. Poprawa precision@5 o 5–8 %. - Document-aware chunking — wykorzystuje strukturę dokumentu (markdown headings, HTML
<section>, PDF sections przez Docling lub Unstructured.io). Chunks odpowiadają jednostkom logicznym autorów dokumentu. Najlepszy wybór dla 80 % use-case'ów B2B, poprawa precision@5 o 12–18 % w porównaniu z fixed-size.
Praktyczna konfiguracja dla prawnego RAG: Docling-parsed PDF → split według <heading> w kolejności sekwencyjnej → jeśli section heading > 800 tokens, sub-split według akapitów (\n\n) → metadata per chunk: {doc_id, section, page, jurisdiction, paragraph_number}. 10–20 % overlap między sąsiednimi chunkami dla ciągłości.
Konkretny benchmark: 12 000 prawnych dokumentów, fixed 500-token vs document-aware chunking. - Fixed: 38 400 chunks, avg 487 tokens, precision@5 = 0,61 - Document-aware: 24 200 chunks, avg 612 tokens, precision@5 = 0,73
Ustawienie 2: model embeddingowy
Najmniej doceniana decyzja. Klient wybiera OpenAI text-embedding-ada-002 z 2022 roku, ponieważ „jest w LangChain quickstart", i traci 15–20 % precyzji, którą zyskałby nowocześniejszym modelem.
Top wybory w 2026 — cost/quality/latency tradeoff
OpenAI text-embedding-3-large - Wymiar: 3 072 (redukowalny przez Matryoshka representation na 256/512/1 024) - MTEB score: ~64,6 - Cena: 0,13 USD / M tokens - Multilingual: dobre, ale nie najlepsze dla PL/SK/CZ — w testach z polskimi tekstami prawnymi precision@5 = 0,77 - Latencja: ~80 ms per request (API) - Kiedy: all-in cloud setup, mieszanka języka angielskiego + popularne języki UE
Cohere embed-multilingual-v3.0 - Wymiar: 1 024 - MTEB score: ~63,8 (multilingual benchmark wyższy) - Cena: 0,10 USD / M tokens - Multilingual: doskonałe dla 100+ języków, szczególnie silne dla języków wschodnioeuropejskich (PL, CZ, SK, HU, RO) - Latencja: ~60 ms per request - Kiedy: multilingual knowledge base, EU compliance (Cohere ma EU region endpoint)
sentence-transformers/all-mpnet-base-v2 - Wymiar: 768 - MTEB score: ~57,8 - Cena: self-hosted (CPU/GPU) - Multilingual: słabe (głównie EN) - Latencja: ~10 ms na CPU, ~3 ms na GPU - Kiedy: budget setup, EN-only, off-line
BGE-M3 (BAAI/bge-m3) - Wymiar: 1 024 (dense), plus sparse + colBERT-style multivector - MTEB score: ~66,1 (multilingual benchmark) - Cena: self-hosted - Multilingual: doskonałe dla 100+ języków łącznie z PL - Latencja: ~15 ms na RTX 4090 - Kiedy: wybór SOTA dla multilingual + self-hosted. Nasz default w 2026 dla klientów UE.
Voyage AI voyage-3-large - Wymiar: 1 024 - MTEB score: ~68,2 (jeden z najwyższych w 2026) - Cena: 0,18 USD / M tokens - Multilingual: doskonałe - Kiedy: premium cloud, gdzie liczy się każdy 1 % precyzji
Konkretny benchmark: ten sam korpus prawny (8 M tokens), document-aware chunking, żaden reranker. - OpenAI text-embedding-3-large: precision@5 = 0,77, latencja 80 ms - Cohere embed-multilingual-v3: precision@5 = 0,79, latencja 60 ms - BGE-M3 (self-hosted): precision@5 = 0,81, latencja 15 ms - Voyage-3-large: precision@5 = 0,82, latencja 95 ms
Dla polskiego prawnego contentu różnica między text-embedding-ada-002 (0,61) a BGE-M3 (0,81) to 20 punktów procentowych precyzji — najprostsza zmiana z najwyższym wpływem.
Ustawienie 3: reranker
Najmniej doceniany komponent pipeline. Architektura: retrieval zwraca top-K kandydatów (typowo K = 20–50) przez embedding similarity, reranker przeskóruje ich modelem cross-encoder (wolniejszym, ale precyzyjniejszym) i wybiera top-N (typowo N = 5) dla kontekstu LLM.
Dlaczego to działa: bi-encoder embedding (szybki retrieval) jest „lossy" — kompresuje dokument do jednego wektora. Cross-encoder reranker (wolniejszy) widzi dokument + query razem i ocenia ich relewancję po tokenach. Przy top-20 reranking dodaje się 50–200 ms latencji, ale precision@5 rośnie typowo o 12–18 %.
Top wybory w 2026
Cohere Rerank 3 - Cena: 2,00 USD / 1 000 search units (1 unit = 1 query + do 100 dokumentów) - Multilingual: doskonałe - Latencja: ~100–150 ms per query (top-20 rerank) - API: proste, EU endpoint dostępny - Kiedy: cloud setup, multilingual content, premium jakość
BAAI/bge-reranker-v2-m3 (BGE Reranker v2 M3) - Cena: self-hosted - Multilingual: doskonałe (ten sam trening co BGE-M3) - Latencja: ~80–120 ms na RTX 4090 dla top-20 - Kiedy: self-hosted setup, wybór SOTA open-source dla multilingual
cross-encoder/ms-marco-MiniLM-L-6-v2 - Cena: self-hosted, mały model (66 M parametrów) - Multilingual: słabe (EN-trained) - Latencja: ~30 ms na GPU - Kiedy: budget setup, EN-only
Żaden reranker (baseline) - Cena: zero - Kiedy: PoC, niski wolumen, latencja poniżej 200 ms jest wymogiem
Konkretny benchmark — dodanie rerankera do istniejącej pipeline
Prawny RAG, BGE-M3 retrieval, top-20 → top-5: - Bez rerankera: precision@5 = 0,81, latencja 250 ms - Cohere Rerank 3: precision@5 = 0,88, latencja 380 ms - BGE-Reranker-v2-m3 (self-hosted): precision@5 = 0,89, latencja 340 ms
Reranker podniesie precision o 7–8 % za cenę 130–150 ms. Dla regulated knowledge base (prawo, medycyna, finanse) zawsze się opłaca. Dla nisko-stake chatbota (FAQ) reranker może być zbędny — zależy od kosztu jednej błędnej odpowiedzi.
Hybrydowy retrieval — gdy chodzi o keywords i o semantykę
Przy treści, gdzie słowa kluczowe mają wagę same z siebie (numery ustaw, paragrafy, GUID-y, numery norm, dokładne nazwy produktów), dominujący dense embedding retrieval może zawieść. Embedding wychwyci podobieństwo semantyczne, ale dosłowny match na „art. 271 ust. 2" może się zgubić w semantycznej normie.
Rozwiązanie: hybrydowy retrieval = równoległy BM25 (sparse, keyword-based) + dense embedding retrieval, wyniki łączą się (typowo reciprocal_rank_fusion).
Stack w 2026: Qdrant 1.10+ z native sparse vectors + dense vectors, lub OpenSearch z warstwą pgvector, lub Weaviate hybrid search API. Konfiguracja: parametr alpha decyduje o wadze (0 = czysty BM25, 1 = czysty dense, default 0,5).
Benchmark hybrydowego retrievalu dla korpusu prawnego: - BM25 only: precision@5 = 0,68 (świetne dla „art. 271", słabe dla „co obowiązuje przy wypowiedzeniu ze względów zdrowotnych") - Dense (BGE-M3) only: precision@5 = 0,81 - Hybrid (alpha=0.5): precision@5 = 0,87
Dla prawnego / medycznego / technicznego normowego contentu hybrid jest znacząco lepszy. Dla konwersacyjnego FAQ contentu różnica zmniejsza się do 1–2 %.
Praktyczne ramy decyzyjne
- 1.Jaki typ treści? Konwersacyjne FAQ / blogposty → dense embedding wystarczy. Strukturalny dokument z sekcjami / paragrafami → document-aware chunking to obowiązek.
- 2.Jaki język? EN-only → MTEB top performer (Voyage, BGE-M3, OpenAI). Multilingual EU języki → BGE-M3, Cohere multilingual-v3.
- 3.Jaki budżet? Cloud-only → OpenAI 3-large + Cohere Rerank 3. Self-hosted → BGE-M3 + BGE-Reranker-v2-m3.
- 4.Jaką latencję Państwo tolerują? < 200 ms → bez rerankera lub mały cross-encoder. 200–500 ms → pełny pipeline z rerankerem.
- 5.Czy keywords są krytyczne? Tak → hybrydowy BM25 + dense. Nie → czysty dense.
- 6.Jaki jest wolumen zapytań? Przy > 100 RPS self-hosted stack zwróci się za 4–8 miesięcy.
Praktyczna iteracja
Strojenie RAG to nie „ustaw raz, zapomnij" projekt. Stack iteracji, który się nam sprawdził:
- 1.Eval set: 200+ realistycznych zapytań + ręcznie zaanotowane „idealne" dokumenty źródłowe. Bez tego nie da się mierzyć poprawy.
- 2.Baseline: najpierw prosty pipeline (fixed chunking + jeden model embeddingowy + żaden reranker). Score = baseline.
- 3.Stopniowo zmieniajcie jeden parametr: chunking → embedding → reranker → hybrid. Po każdej zmianie zmierzcie precision@5, recall@10, latency.
- 4.Stopujcie, gdy marginal cost > marginal benefit. Typowo precision@5 powyżej 0,90 wymaga nieproporcjonalnego wysiłku — fine-tuned embedding lub custom reranker, który nie opłaca się przy use-case z tolerancyjną jakością.
W prawnym RAG dla 12 000 dokumentów w 4 tygodnie pracy przesunęliśmy precision@5 z 67 % na 88 %. Kolejne 4 tygodnie pracy prawdopodobnie doprowadziłyby na 90 %. Klient zdecydował zatrzymać — 88 % było eksploatacyjnie wystarczające, a kolejne 5 tygodni GPU + engineer time nie zwracało się.
---
*Wykonujemy architekturę RAG + tuning dla B2B knowledge base z 1k–10M dokumentów. Jeśli mają Państwo istniejącą pipeline, a precision@5 zatrzymał się poniżej 75 %, przejdziemy w 90-minutowym audycie konkretnie trzy ustawienia dla Państwa contentu i damy liczbową baseline dla tuning roadmap.*