Pri RAG (Retrieval-Augmented Generation) sa väčšina debugovacích pokusov v 2026 sústredí na prompty modelu a system instructions. Klient zmení prompt 12-krát, presedí 4 dni a precíznosť odpovedí sa zlepší zo 67 % na 70 %. Medzitým tri nastavenia v retrieval vrstve — chunking, embedding model, reranking — by za poldňa práce posunuli precíznosť na 84 %. Tento článok je o tých troch nastaveniach.
Prečo retrieval rozhoduje, nie LLM
Bázová asymetria RAG architektúry: ak retrieval vráti **správne kúsky dokumentácie**, aj priemerný 7B model dá kvalitnú odpoveď. Ak retrieval vráti irelevantné alebo neúplné kúsky, ani Claude Opus 4.6 nezachráni odpoveď — model jednoducho nemá pravdivé fakty v kontexte. „Garbage in, garbage out" je v RAG-u doslovne fyzický zákon.
Konkrétny príklad: právny RAG nad slovenskou legislatívou, 12 000 dokumentov, 8 M tokenov. S default chunking-om (500 tokens fixed-size) a OpenAI text-embedding-ada-002 sme dosiahli precision@5 = 0,61, recall@10 = 0,72. Po troch nastaveniach (document-aware chunking, embedding upgrade na BGE-M3, Cohere Rerank 3) — precision@5 = 0,84, recall@10 = 0,93. **Žiadna zmena LLM, žiadna zmena promptu.**
Nastavenie 1: chunk size + chunking strategy
Najčastejšia konfigurácia v PoC projektoch: `RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)` z LangChain default-u. Funguje na 60 % use-cases. Pre zvyšok je zle.
**Dva rozmery rozhodnutia:**
A) Veľkosť chunk-u (tokens)
- **128–256 tokens** — vysoká precíznosť, retrieval nájde presne ten paragraf, ktorý odpovedá. Riziko: kontextu okolo paragrafu chýba, model nevidí celý myšlienkový tok. Vhodné pre FAQ, kódové snippets, štruktúrované dáta.
- **256–512 tokens** — najbežnejší kompromis. Paragraf s okolitým kontextom. Default voľba pre väčšinu B2B knowledge base nasadení.
- **512–1024 tokens** — širší kontext, model dostane viac súvislostí, ale precíznosť retrievalu klesá (embedding 1 024-tokenového chunku „rozriedi" hlavnú tému). Vhodné pre dlhšie naratívne dokumenty (právne rozhodnutia, výskumné papiere, technické manuály).
- **> 1 024 tokens** — málokedy správne. Embedding modely majú reálnu efektívnu dĺžku ~512 tokens — väčšina informácie po tomto threshold-e sa „rozpúšťa" v jeden vektor. Existuje výnimka: long-context embedding modely (Voyage-3-large, BGE-M3 v plnom móde, NV-Embed-v2) zvládnu efektívne až 8 192 tokens.
B) Stratégia delenia (fixed vs. semantic vs. document-aware)
- **Fixed-size chunking** — jednoduchá, deterministická, ale láme paragrafy, vety, dokonca slová na hranici. Strata kontextu na ~15 % chunk-ov, čo sa premieta do 8–12 % zhoršenia precision@5.
- **Semantic chunking** — pomocou embeddings detekuje hranice zmysluplných segmentov (napr. `semantic_chunker` v LlamaIndex). Lepšie zachováva kontext, ale chunks majú variable size — pri inference treba počítať s rozptylom 200–800 tokens. Zlepšenie precision@5 o 5–8 %.
- **Document-aware chunking** — využíva štruktúru dokumentu (markdown headings, HTML `<section>`, PDF sections cez Docling alebo Unstructured.io). Chunks korešpondujú s logickými jednotkami autorov dokumentu. **Najlepšia voľba pre 80 % B2B use-cases**, zlepšenie precision@5 o 12–18 % oproti fixed-size.
Praktická konfigurácia pre právny RAG: Docling-parsed PDF → split podľa `<heading>` v sériovom poradí → ak heading section > 800 tokens, sub-split podľa odsekov (`\n\n`) → metadata per chunk: `{doc_id, section, page, jurisdiction, paragraph_number}`. 10–20 % overlap medzi susednými chunkmi pre kontinuitu.
**Konkrétny benchmark:** 12 000 právnych dokumentov, 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
Nastavenie 2: embedding model
Najpodceňovanejšie rozhodnutie. Klient si vyberie OpenAI `text-embedding-ada-002` z roku 2022, pretože „je to v LangChain quickstart-e", a stratí 15–20 % precíznosti, ktorú by získal modernejším modelom.
Top voľby v 2026 — cost/quality/latency tradeoff
**OpenAI text-embedding-3-large** - Dimenzia: 3 072 (znížiteľné cez Matryoshka representation na 256/512/1 024) - MTEB skóre: ~64,6 - Cena: 0,13 USD / M tokens - Multilingual: dobré, ale nie najlepšie pre SK/CZ — v testoch s slovenskými právnymi textmi precision@5 = 0,77 - Latencia: ~80 ms per request (API) - **Kedy:** all-in cloud setup, anglická + bežná EU jazyková zmes
**Cohere embed-multilingual-v3.0** - Dimenzia: 1 024 - MTEB skóre: ~63,8 (multilingual benchmark vyšší) - Cena: 0,10 USD / M tokens - Multilingual: výborné pre 100+ jazykov, špeciálne silné pre východoeurópske jazyky (SK, CZ, HU, RO) - Latencia: ~60 ms per request - **Kedy:** multilingual knowledge base, EU compliance (Cohere má EU region endpoint)
**sentence-transformers/all-mpnet-base-v2** - Dimenzia: 768 - MTEB skóre: ~57,8 - Cena: self-hosted (CPU/GPU) - Multilingual: slabé (primárne EN) - Latencia: ~10 ms na CPU, ~3 ms na GPU - **Kedy:** budget setup, EN-only, off-line
**BGE-M3 (BAAI/bge-m3)** - Dimenzia: 1 024 (dense), plus sparse + colBERT-style multivector - MTEB skóre: ~66,1 (multilingual benchmark) - Cena: self-hosted - Multilingual: výborné pre 100+ jazykov vrátane SK - Latencia: ~15 ms na RTX 4090 - **Kedy:** SOTA voľba pre multilingual + self-hosted. **Náš default v 2026 pre EU klientov.**
**Voyage AI voyage-3-large** - Dimenzia: 1 024 - MTEB skóre: ~68,2 (jeden z najvyšších v 2026) - Cena: 0,18 USD / M tokens - Multilingual: výborné - **Kedy:** premium cloud, kde sa každý 1 % precíznosti počíta
**Konkrétny benchmark:** rovnaký právny korpus (8 M tokens), document-aware chunking, žiadny reranker. - OpenAI text-embedding-3-large: precision@5 = 0,77, latencia 80 ms - Cohere embed-multilingual-v3: precision@5 = 0,79, latencia 60 ms - BGE-M3 (self-hosted): precision@5 = 0,81, latencia 15 ms - Voyage-3-large: precision@5 = 0,82, latencia 95 ms
Pre slovenský právny content je rozdiel medzi `text-embedding-ada-002` (0,61) a BGE-M3 (0,81) **20 percentuálnych bodov precíznosti** — najjednoduchšia zmena s najvyšším dopadom.
Nastavenie 3: reranker
Najpodceňovanejší komponent pipeline. Architektúra: retrieval vráti top-K kandidátov (typicky K = 20–50) cez embedding similarity, **reranker** ich preskóruje cross-encoder modelom (pomalším, ale presnejším) a vyberie top-N (typicky N = 5) pre LLM kontext.
Prečo to funguje: bi-encoder embedding (rýchly retrieval) je „lossy" — komprimuje dokument do jedného vektoru. Cross-encoder reranker (pomalší) vidí dokument + query spolu a vyhodnotí ich relevanciu po tokenoch. Pri top-20 reranking sa pridáva 50–200 ms latencie, ale precision@5 rastie typicky o 12–18 %.
Top voľby v 2026
**Cohere Rerank 3** - Cena: 2,00 USD / 1 000 search units (1 unit = 1 query + až 100 documents) - Multilingual: výborné - Latencia: ~100–150 ms per query (top-20 rerank) - API: jednoduché, EU endpoint dostupný - **Kedy:** cloud setup, multilingual content, premium kvalita
**BAAI/bge-reranker-v2-m3 (BGE Reranker v2 M3)** - Cena: self-hosted - Multilingual: výborné (rovnaký tréning ako BGE-M3) - Latencia: ~80–120 ms na RTX 4090 pre top-20 - **Kedy:** self-hosted setup, SOTA open-source voľba pre multilingual
**cross-encoder/ms-marco-MiniLM-L-6-v2** - Cena: self-hosted, malý model (66 M parametrov) - Multilingual: slabé (EN-trained) - Latencia: ~30 ms na GPU - **Kedy:** budget setup, EN-only
**Žiadny reranker (baseline)** - Cena: zero - **Kedy:** PoC, nízky objem, latencia pod 200 ms je požiadavka
Konkrétny benchmark — pridanie rerankeru k existujúcej pipeline
Právny RAG, BGE-M3 retrieval, top-20 → top-5: - Bez rerankeru: precision@5 = 0,81, latencia 250 ms - Cohere Rerank 3: precision@5 = 0,88, latencia 380 ms - BGE-Reranker-v2-m3 (self-hosted): precision@5 = 0,89, latencia 340 ms
**Reranker zvýši precision o 7–8 % za cenu 130–150 ms.** Pre regulated knowledge base (právo, medicína, financie) je to vždy splatné. Pre nízko-stake chatbot (FAQ) môže byť reranker zbytočný — záleží na náklade jednej chybnej odpovede.
Hybridné retrieval — keď ide o keywords aj sémantiku
Pri obsahu, kde **kľúčové slová majú váhu samé o sebe** (čísla zákonov, paragrafy, GUID-y, číslice noriem, presné názvy produktov), prevažujúci dense embedding retrieval môže zlyhať. Embedding zachytí sémantickú podobnosť, ale doslovný match na „§ 271 ods. 2" sa môže stratiť v sémantickej norme.
**Riešenie: hybridné retrieval** = paralel BM25 (sparse, keyword-based) + dense embedding retrieval, výsledky sa zlúčia (typicky `reciprocal_rank_fusion`).
Stack v 2026: Qdrant 1.10+ s native sparse vectors + dense vectors, alebo OpenSearch s pgvector layer, alebo Weaviate hybrid search API. Konfigurácia: alpha parameter rozhoduje váhu (0 = čistý BM25, 1 = čistý dense, default 0,5).
**Benchmark hybridného retrieval pre právny korpus:** - BM25 only: precision@5 = 0,68 (skvelé pre „§ 271", slabé pre „čo platí pri výpovedi zo zdravotných dôvodov") - Dense (BGE-M3) only: precision@5 = 0,81 - Hybrid (alpha=0.5): precision@5 = 0,87
Pre právny / medicínsky / technický normový content je hybrid signifikantne lepší. Pre konverzačný FAQ obsah sa rozdiel zmenšuje na 1–2 %.
Praktický rozhodovací rámec
1. **Aký typ obsahu?** Konverzačný FAQ / blogposty → dense embedding stačí. Štruktúrovaný dokument so sekciami / paragrafmi → document-aware chunking je povinnosť. 2. **Aký jazyk?** EN-only → MTEB top performer (Voyage, BGE-M3, OpenAI). Multilingual EU jazyky → BGE-M3, Cohere multilingual-v3. 3. **Aký rozpočet?** Cloud-only → OpenAI 3-large + Cohere Rerank 3. Self-hosted → BGE-M3 + BGE-Reranker-v2-m3. 4. **Akú latenciu tolerujete?** < 200 ms → bez rerankeru alebo malý cross-encoder. 200–500 ms → full pipeline s rerankerom. 5. **Sú keywords kritické?** Áno → hybridné BM25 + dense. Nie → čistý dense. 6. **Aký je objem dotazov?** Pri > 100 RPS sa self-hosted stack vráti za 4–8 mesiacov.
Praktická iterácia
Ladenie RAG-u nie je „nastav raz, zabudni" projekt. Stack iterácie, ktorý sa nám osvedčil:
1. **Eval set:** 200+ realistických dotazov + ručne anotované „ideálne" zdrojové dokumenty. Bez tohto sa nedá merať zlepšenie. 2. **Baseline:** najprv jednoduchá pipeline (fixed chunking + jeden embedding model + žiadny reranker). Skóre = baseline. 3. **Postupne meňte jeden parameter:** chunking → embedding → reranker → hybrid. Po každej zmene zmerajte precision@5, recall@10, latency. 4. **Stopnite, keď marginal cost > marginal benefit.** Typicky precision@5 nad 0,90 vyžaduje neproporcionálne úsilie — fine-tuned embedding alebo custom reranker, ktorý sa neoplatí pri use-case s tolerantnou kvalitou.
V právnom RAG-u pre 12 000 dokumentov sme za 4 týždne práce posunuli precision@5 zo 67 % na 88 %. Nasledujúce 4 týždne práce by sme pravdepodobne dostali na 90 %. Klient sa rozhodol stopnúť — 88 % bolo prevádzkovo dostatočné a ďalších 5 týždňov GPU + engineer time-u sa nevracalo.
---
*Robíme RAG architektúru + tuning pre B2B knowledge base s 1k–10M dokumentmi. Ak máte existujúcu pipeline a precision@5 sa zasekol pod 75 %, prejdeme za 90-minútový audit konkrétne tri nastavenia pre váš content a dáme číselnú baseline pre tuning roadmap.*