RAG systémy vysvetlené

Čo je RAG? Jasná definícia

Retrieval-Augmented Generation (RAG) označuje metódu, pri ktorej Large Language Model (LLM) pred generovaním odpovede cielene vyhľadá externý obsah znalostí (Retrieval) a vloží ho do promptu (Augmentation), aby sa generovanie opieralo o overiteľné zdroje. Pôvodná definícia pochádza od Lewis et al. (Facebook AI Research, NeurIPS 2020) a opisuje RAG ako kombináciu parametrickej pamäte (natrénovaného jazykového modelu) a neparametrickej pamäte (externého prehľadávateľného indexu).

Naprieč rôznymi kanonickými definíciami sa dá zachytiť spoločné minimum: RAG systém pozostáva z troch povinných prvkov, (i) externého úložiska znalostí s indexom, (ii) retrievera, ktorý nájde relevantné pasáže, a (iii) generátorového LLM, ktorého prompt sa doplní o nájdený obsah. Hlavný prínos: RAG poskytuje odpovede podložené zdrojmi a dohľadateľné, merateľne znižuje halucinácie a udržiava znalosti aktuálne bez toho, aby sa model musel nanovo trénovať.

Prečo RAG? Problém, ktorý rieši

LLM majú tri štrukturálne slabiny: halucinujú, ich znalosti sú zamrznuté na stave z trénovania a ich odpovede nie sú dohľadateľné. RAG rieši všetky tri. Namiesto trénovania modelu na nových dátach nákladným fine-tuningom sa relevantné znalosti načítajú za behu pri každej požiadavke. Aktualizácia je tak jednoduchá ako nová indexácia; zdrojové odkazy (citations) sú natívne možné cez ID chunkov; a odpoveď zostáva viazaná na overiteľný materiál.

Práve tieto vlastnosti robia z RAG de facto štandardný vzor pre podnikovú AI v regióne DACH, kde dohľadateľnosť, aktuálnosť a kontrola nad dátami nie sú voliteľné, ale vyžaduje ich regulácia aj dôvera.

RAG pipeline: indexovacia a dopytová cesta

Produkčný RAG systém má dve cesty. Indexovacia cesta (offline/batch) spracúva zdroje znalostí: konektory načítajú dokumenty zo SharePointu, S3, Confluence alebo z databáz; parser (napr. Docling) extrahuje text, tabuľky a štruktúry so zachovaním layoutu; chunker rozdelí obsah; embedding model vytvorí vektory a upsert ich zapíše s metadátami (tenant ID, ACL, zdroj, časová pečiatka) do vektorovej databázy, voliteľne spolu s paralelným indexom BM25.

Dopytová cesta (online) začína dopytom používateľa, voliteľne preformulovaným (query rewriting, HyDE). Potom prebehne hybridný retrieval (typicky top_k = 50–100) a po ňom re-ranker, ktorý výber zúži na 5–10 najrelevantnejších pasáží. Tie sa vložia do šablóny promptu s citovaním zdrojov a odovzdajú sa LLM; kontrola vernosti (faithfulness check) môže odpoveď overiť voči zdrojom.

Embeddingy a vektorové databázy

Embeddingy sú numerické vektorové reprezentácie textu, v ktorých sa sémantická blízkosť zobrazuje ako geometrická blízkosť (kosínusová podobnosť ako predvolená metrika pre normalizované vektory). Pre nemeckojazyčné korpusy platí dôležité pravidlo: poradie v anglickom MTEB nie je poradie v nemčine. Modely, ktoré vedú v angličtine, často strácajú na nemeckých zložených slovách, odbornom jazyku a dlhých slovách 5–15 bodov nDCG@10. Smerodajné sú nemecké, resp. multilingválne benchmarky (MMTEB, MIRACL-de, MTEB-DE). Nemecké zložené slová navyše vedú k väčšiemu počtu tokenov; orientačné pravidlo: nemčina je podľa modelu zhruba 1,3–1,7× náročnejšia na tokeny než angličtina.

Vektorové databázy ukladajú embeddingy a odpovedajú na dopyty podobnosti cez indexy typu approximate nearest neighbour. Štandardným algoritmom je HNSW (Hierarchical Navigable Small World, Malkov & Yashunin 2016), ktorý beží takmer vo všetkých produkčných systémoch, od Qdrantu cez Weaviate, Milvus a pgvector až po SAP HANA. Praktická orientačná hodnota: HNSW dosahuje recall 95–99 % a pohodlne zvláda do ~100 mil. vektorov; nad touto hranicou pomáha kvantizácia (halfvec, SQ8) alebo diskové metódy ako DiskANN.

Pre stredné podniky v regióne DACH s menej ako ~10–50 mil. vektorov je pgvector na spravovanom Postgrese (IONOS, STACKIT, OTC, Hetzner) pragmatickou suverénnou predvolenou voľbou: jedna databáza, jeden koncept zálohovania, jeden reťazec zmlúv o spracúvaní osobných údajov (DPA). Koncerny typicky prevádzkujú dve alebo tri úložiská paralelne: SAP HANA Vector pre dáta uložené v SAP plus dedikovanú vektorovú DB (Qdrant, Weaviate) pre neštruktúrované dokumenty.

Chunking: ako sa znalosti delia na časti

Chunking zásadne rozhoduje o kvalite retrievalu. Naivný chunking s pevnou veľkosťou (napr. 512 tokenov, prekryv 50 tokenov) je stabilný, ale rozsekáva vety, tabuľky a zoznamy; ide o častý anti-pattern. Lepšie stratégie:

• Recursive/Semantic Chunking rešpektuje štruktúru dokumentu, resp. delí text v miestach, kde sa mení obsah.
• Hierarchical (Parent-Child) používa malé chunky na retrieval a veľké nadradené (parent) chunky ako kontext pre generátor.
• Contextual Retrieval (Anthropic, 09/2024) pred embeddingom pridá na začiatok každého chunku krátku kontextovú hlavičku vygenerovanú LLM. Výsledok: −49 % chýb retrievalu, −67 % s dodatočným rerankerom. Cenou je jedno volanie LLM na chunk v čase ingestu.
• Late Chunking (Jina, 2024) obracia poradie: najprv long-context embedder vytvorí embedding celého dokumentu, potom sa token embeddingy spriemerujú podľa hraníc chunkov; vektory chunkov si tak zachovajú kontext dokumentu. Late chunking je v čase ingestu prakticky zadarmo (žiadne dodatočné volanie LLM) a v štúdii Jina je o ~24 % lepší než naivný chunking. Pre DACH projekty s prísnou kontrolou nákladov je late chunking s Jina v3/v4 alebo BGE-M3 často výnosnejšou predvolenou voľbou.

Pri PDF s náročným layoutom (zmluvy, korešpondencia s úradmi, správy podľa IFRS) vyhrávajú parsery, ktoré rozpoznávajú layout (Docling, Marker), a v budúcnosti multimodálne prístupy ako ColPali/ColQwen alebo Jina v4, ktoré renderujú každú stranu ako obrázok, a tak obchádzajú chyby OCR a layoutu.

Hybrid Search a reranking

Hybrid Search kombinuje dense retrieval (embeddingy, sémantická blízkosť) so sparse retrievalom (BM25 alebo naučené sparse modely ako SPLADE/ELSER) a spája výsledky, obvykle cez Reciprocal Rank Fusion (RRF). Dôvod: čisté embeddingy minú presné kódy, ID, spisové značky, materiálové čísla SAP alebo IBAN, teda práve tie tokeny, na ktorých v B2B praxi v regióne DACH záleží. BM25 ich zachytí. Pri nemčine so zloženými slovami a odborným jazykom prináša hybrid oproti samotnému dense retrievalu konzistentne o 5–15 bodov nDCG@10 viac.

Reranking je druhý, presnejší stupeň triedenia: cross-encoder spracuje dopyt a dokument spoločne a nanovo ohodnotí najlepších kandidátov. Je to jednotlivé vylepšenie s najvyšším ROI v celej pipeline; typicky +5–15 percentuálnych bodov recall@5. Štúdia Anthropic (09/2024) meria efekt na chybovosti pri top-20 retrievale: samotné Contextual Embeddings ju znižujú o 35 %, Contextual Embeddings plus Contextual BM25 (dohromady Contextual Retrieval) o 49 % a s dodatočným rerankerom o 67 %. Krok rerankera pritom znižuje chybovosť z 2,9 % na 1,9 %.

Latenčný rozpočet pre štandardnú pipeline v regióne DACH (10 mil. vektorov): prvý stupeň BM25 a dense po 10–50 ms, RRF pod 1 ms, cross-encoder reranker (napr. BGE Reranker M3 na GPU) 100–300 ms; spolu 150–500 ms pred generovaním v LLM. Pri prísnych SLA pod 100 ms je reranker prvým kandidátom na vynechanie, za cenu straty recallu o 5–15 bodov.

RAG vs. alternatívy: kedy čo?

RAG nie je jediná stratégia. Voľba oproti fine-tuningu, long-contextu a prompt engineeringu závisí od cieľa:

Otvorenou, ale čoraz jasnejšie rozhodnutou debatou je long-context vs. RAG. Aktuálne modely spracujú kontext s rozsahom zhruba 1 mil. tokenov, napríklad Gemini 3.1 Pro (Preview) a aktuálne modely Claude. V klasickom single-needle teste dosiahol už Gemini 1.5 Pro recall vyše 99,7 % pri 1 mil. tokenov; ak model hľadá 100 needles súčasne, hodnota klesne na niečo vyše 60 % (správa o Gemini 1.5, arXiv:2403.05530). K tomu sa pridáva ~30–60× vyššia latencia a o rády vyššie náklady na požiadavku oproti RAG pipeline (odhad Tiana Pana, 2026). Konsenzus roku 2026: long-context dopĺňa RAG pri úzko vymedzených workloadoch, no pri scenároch s viacerými needles, viacerými tenantmi a citlivosťou na náklady ho nahrádza len zriedka.

GDPR a suverénna prevádzka v regióne DACH

Poznámka: Nasledujúce informácie majú informatívny charakter a nepredstavujú právne poradenstvo.

Jedna z vecne najdôležitejších otázok GDPR v rokoch 2025/2026 znie: Sú embeddingy osobné údaje? Úprimná odpoveď znie „s najväčšou pravdepodobnosťou áno, ak sú odvodené z osobných údajov“. Inverzné útoky dokážu presne rekonštruovať až 92 % 32-tokenových vstupov (Morris et al., EMNLP 2023); embedding teda nie je bezpečná pseudonymizácia. Stanovisko EDPB 28/2024 vyžaduje posúdenie rizika reidentifikácie v každom jednotlivom prípade; rozsudok SDEÚ C-413/23 P (september 2025) spresňuje, že pseudonymizované údaje nie sú automaticky osobnými údajmi pre každého príjemcu, povinnosti však len zužuje, neruší ich.

Praktické dôsledky pre architektúry RAG, ktoré vychádzajú z orientačnej príručky k RAG nemeckej konferencie orgánov ochrany údajov (Datenschutzkonferenz, DSK) a z usmernení EDPB:

• Právo na výmaz (čl. 17): Aj embeddingy a chunky musia byť vymazateľné. Grafy HNSW podporujú výmaz jednotlivých bodov rôzne dobre; sémantika mazania je tvrdým kritériom pri obstarávaní (pgvector a Qdrant mažú efektívne).
• Oddelenie tenantov: tenant ID a ACL v metadátach, filter pri každom dopyte, defense in depth (autentifikácia + filter + opätovná kontrola + audit log). Zdieľaný index bez filtra na tenanta je vopred ohlásená nehoda z pohľadu GDPR.
• Rezidencia dát: Uprednostniť hosting v regióne EÚ; pri amerických cloudových poskytovateľoch posúdiť zvyškové riziko CLOUD Act/FISA 702 (SCC + TIA). Prenos embeddingov do vektorovej DB hostovanej v USA je prenosom do tretej krajiny.
• Minimalizácia pred embeddingom: Mená, e-maily a ID podľa možnosti pred embeddingom odstrániť alebo nahradiť stabilnými pseudonymami; vektory šifrovať kľúčmi spravovanými zákazníkom (CMK/BYOK).

Pre regulované workloady platí: každá vrstva suverénne nasaditeľná. V EÚ sa to týka napríklad finančného sektora podľa DORA (v Nemecku navyše MaRisk), zdravotníckych pomôcok a diagnostických pomôcok in vitro podľa MDR/IVDR, základných a dôležitých subjektov podľa národnej transpozície smernice NIS2 (v Rakúsku NISG 2026) a v Nemecku verejného sektora podľa OZG. Vo Švajčiarsku platí revidovaný zákon o ochrane údajov (revDSG), ktorý je koncipovaný tak, aby bol kompatibilný s GDPR.

Suverénna infraštruktúra v regióne DACH a v EÚ je v roku 2026 spoľahlivá: Qdrant (Berlín), Weaviate (Amsterdam), Haystack/deepset (Berlín), SAP HANA Cloud Vector Engine a pgvector na STACKIT/IONOS/OTC/Hetzner. Pri poskytovateľoch modelov sa situácia zmenila. Spoločnosť Aleph Alpha (Heidelberg) sa odklonila od vlastných frontier modelov a ponúka okrem iného platformu PhariaAI. V apríli 2026 spoločnosť Cohere oznámila spojenie so spoločnosťou Aleph Alpha, 16. septembra 2026 obe spoločnosti podpísali zmluvu o fúzii. Spoločná firma má vystupovať pod názvom Cohere so sídlami v Toronte a Berlíne, pracovisko v Heidelbergu sa má sústrediť na výskum. Uzavretie transakcie ešte podlieha schváleniu úradmi. Jina AI (Berlín), poskytovateľ embedding a reranker modelov, patrí od októbra 2025 k spoločnosti Elastic.

Poznámka k EU AI Act (stav 10/2026): Digital Omnibus pre AI, nariadenie (EÚ) 2026/1744, je v platnosti od 27. júla 2026. Povinnosti pre vysokorizikové systémy podľa prílohy III sa tak uplatňujú od 2. decembra 2027, pre vysokorizikovú AI v produktoch podľa prílohy I od 2. augusta 2028. Povinnosti transparentnosti podľa čl. 50 platia od 2. augusta 2026. Iba na strojovo čitateľné označovanie podľa čl. 50 ods. 2 majú poskytovatelia systémov, ktoré boli na trhu už pred týmto dátumom, čas do 2. decembra 2026.

Zabezpečenie kvality s RAGAS

RAG systém bez evaluácie nenápadne degraduje. De facto štandardom je RAGAS s kľúčovými metrikami faithfulness (vernosť zdroju), answer relevancy, context precision a context recall, doplnený o TruLens („RAG Triad“) alebo DeepEval. Zmysluplný postup je goldset plus LLM-as-judge plus A/B testy v produkcii, pevne zakotvené v CI pipeline. Vynútené citovanie (citation forcing), guardraily na faithfulness a odmietnutie odpovede pri nízkom skóre sú štandardné prostriedky proti halucináciám, ktoré sa vyskytujú aj napriek RAG.

Výhľad a praktická poznámka

Vektorové databázy a embedding modely sa na úrovni API do veľkej miery stali komoditou; HNSW je všade, hybrid search je štandard a multimodalita (ColPali, Jina v4) je novou hranicou. Paralelne sa RAG ďalej vyvíja v stupňoch Naive → Advanced → Modular → Agentic RAG, pričom retrieval sa čoraz častejšie chápe ako dynamický nástroj agenta (Singh et al. 2025).

Pragmatický začiatok pre projekt v regióne DACH: Začni s BM25 + dense (BGE-M3) + cross-encoder rerankerom (BGE Reranker M3) na suverénnej báze Postgres/pgvector, klasifikuj osobné údaje pred embeddingom a meraj kvalitu od prvého dňa pomocou RAGAS. To, čo v roku 2026 architektonicky dominuje, už nie je hrubý výkon, ale otázka, kde sú embeddingy uložené, kto k nim má prístup a či sa stack dá v prípade pochybností presunúť on-prem. RAG stack plánovaný suverénne, s dôrazom na nemčinu a open source je spoľahlivou odpoveďou.