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_chunker` w 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.*