--- title: "RAG systémy vysvetlené" description: "Ako RAG systémy dodávajú LLM externé znalosti, retrieval, embeddingy, vektorové databázy a presné odpovede." locale: "sk" canonical: "https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system" category: "AI agenti" updated: "2026-07-29T08:53:27.479Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # RAG systémy vysvetlené Ako RAG systémy dodávajú LLM externé znalosti, retrieval, embeddingy, vektorové databázy a presné odpovede. ## Čo je RAG? Jasná definícia Retrieval-Augmented Generation (RAG) označuje metódu, pri ktorej [Large Language Model](/sk/slovnik/large-language-model) ([LLM](/sk/slovnik/llm)) pred generovaním odpovede cielene vyhľadá externý obsah vedomostí (Retrieval) a vloží ho do promptu (Augmentation), aby sa generovanie oprelo o overiteľné zdroje. Pôvodná definícia pochádza od Lewis et al. (Facebook AI Research, NeurIPS 2020) a opisuje [RAG](/sk/slovnik/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 možno zachytiť konsenzuálne minimum: RAG systém pozostáva z troch povinných prvkov, (i) externého úložiska vedomostí s indexom, (ii) retrievera, ktorý nájde relevantné pasáže, a (iii) generator-LLM, ktorého [prompt](/sk/slovnik/prompt) sa doplní o nájdený obsah. Centrálny úžitok: RAG poskytuje odpovede podložené zdrojmi a sledovateľné, merateľne znižuje halucinácie a udržiava vedomosti 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 vedomosti sú zamrznuté na stave trénovania a ich odpovede nie sú sledovateľné. RAG adresuje všetky tri. Namiesto trénovania modelu nákladným fine-tuningom na nových dátach sa relevantné vedomosti donačítajú za behu pri každej požiadavke. Aktualizácie sú tak také jednoduché ako re-indexácia; zdrojové odkazy (citations) sú natívne možné cez chunk-ID; a odpoveď zostáva viazaná na overiteľný materiál. Práve tieto vlastnosti robia z RAG de-facto štandardný pattern pre [enterprise-AI v DACH priestore](/sk/sluzby/integracia-ai-agenta), kde sledovateľnosť, aktuálnosť a kontrola dát nie sú voliteľné, ale sú vyžadované regulačne a z hľadiska dôvery. ## RAG pipeline: indexing- a query-cesta Produkčný RAG systém má dve cesty. **Indexing-cesta** (offline/batch) spracúva zdroje vedomostí: connectory načítajú dokumenty zo SharePointu, S3, Confluence alebo databáz; parser (napr. Docling) extrahuje layout-verne text, tabuľky a štruktúry; chunker rozloží obsah; [embedding-model vytvorí vektory](/sk/vedomosti/ai-agenti/co-je-rag-system/embedding-modelle-vergleich); a upsert ich zapíše s metadátami (tenant-ID, ACL, zdroj, časová pečiatka) do vektorovej databázy, voliteľne sprevádzaný paralelným BM25-indexom. **Query-cesta** (online) začína používateľskou požiadavkou, voliteľne prepísanou (query rewriting, HyDE). Potom prebehne hybrid-retrieval (typicky top\_k = 50–100), nasledovaný re-rankerom, ktorý zhustí na najrelevantnejších 5–10 pasáží. Tie sa vložia do prompt-template so zdrojovou citáciou a odovzdajú LLM; faithfulness-check môže odpoveď preveriť oproti 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ť (cosine similarity ako default pre normalizované vektory). Pre nemeckojazyčné korpusy platí dôležité pravidlo: anglické MTEB-poradie nie je nemecké poradie. Modely, ktoré vedú v angličtine, na nemeckých kompozitách, odbornom jazyku a dlhých slovách často strácajú 5–15 nDCG@10-bodov. Smerodajné sú nemecké, resp. multilingválne benchmarky (MMTEB, MIRACL-de, MTEB-DE). Nemecké kompozitá navyše vedú k viac tokenom, pravidlo palca: DE je podľa modelu zhruba 1,3–1,7× náročnejšie na tokeny než EN. **Vektorové databázy** ukladajú embeddingy a odpovedajú na dopyty podobnosti cez approximate-nearest-neighbour indexy. Štandardný algoritmus 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](/sk/vedomosti/ai-agenti/co-je-rag-system/vector-databases-vergleich) až po SAP HANA. Praktická orientačná hodnota: HNSW poskytuje 95–99 % recall a je komfortný do \~100 mil. vektorov; nad tým pomáha kvantizácia (halfvec, SQ8) alebo disk-based metódy ako DiskANN. | Vektorová DB | Pôvod | Licencia | Hybrid Search | DACH-/EU-hosting | | --- | --- | --- | --- | --- | | **Qdrant** | Berlín (DE) | Apache 2.0 | áno (BM25/SPLADE) | áno (on-prem, STACKIT, air-gapped) | | **Weaviate** | Amsterdam (NL/EU) | BSD-3 | áno | áno (EU-región) | | **pgvector** | OSS (Postgres) | PostgreSQL-licencia | cez tsvector/ParadeDB | všade, kde beží Postgres | | **SAP HANA Vector** | DE (SAP) | komerčná | s full-text | áno (BTP, Sovereign Cloud, Delos) | | **Pinecone** | New York (US) | proprietárny SaaS | áno | EU-región, ale žiadny on-prem | Pre DACH stredne veľké podniky pod \~10–50 mil. vektorov je **pgvector na managed Postgrese** (IONOS, STACKIT, OTC, Hetzner) pragmatický suverénny default: jedna databáza, jeden backup-príbeh, jeden reťazec AVV. Koncerny typicky prevádzkujú dva alebo tri story paralelne, SAP HANA Vector pre dáta rezidentné v SAP plus [dedikovaná vektorová DB](/sk/vedomosti/ai-agenti/co-je-rag-system/pinecone-vs-weaviate-vs-qdrant) (Qdrant, Weaviate) pre neštruktúrované dokumenty. ## Chunking: ako sa vedomosti rozkladajú Chunking rozhoduje rozhodujúcou mierou o kvalite retrievalu. Naivný fixed-size-chunking (napr. 512 tokenov, 50 tokenov overlap) je robustný, ale rozseká vety, tabuľky a zoznamy, častý anti-pattern. Lepšie stratégie: - **Recursive/Semantic Chunking** rešpektuje štruktúru dokumentu, resp. seká na obsahových zlomoch. - **Hierarchical (Parent-Child)** využíva malé chunky na retrieval a veľké parent-chunky ako generátorový kontext. - **Contextual Retrieval (Anthropic, 09/2024)** predradí každému chunku pred embeddingom krátky, LLM-generovaný kontextový header. Výsledok: −49 % chýb retrievalu, −67 % s dodatočným rerankerom. Cenou je jeden LLM-call na chunk v čase ingestu. - **Late Chunking (Jina, 2024)** obracia poradie: najprv sa celý dokument vloží long-context embedderom, potom sa [token](/sk/slovnik/token)-embeddingy spriemerujú cez hranice chunkov, chunk-vektory si tak zachovajú kontext dokumentu. Late chunking je v čase ingestu prakticky zadarmo (žiadny dodatočný LLM-call) a v Jina-štúdii \~24 % lepší než naivný chunking. Pre nákladovo disciplinované DACH projekty je late chunking s Jina v3/v4 alebo BGE-M3 často výnosnejším defaultom. Pri layout-náročných PDF (zmluvy, korešpondencia s úradmi, IFRS-správy) vyhrávajú layout-aware parsery (Docling, Marker), a perspektívne multimodálne prístupy ako ColPali/ColQwen alebo Jina v4, ktoré renderujú každú stranu ako obrázok a obchádzajú tak OCR- a layout-chyby. ## 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 fúzuje výsledky, obvykle cez Reciprocal Rank Fusion (RRF). Dôvod: čisté embeddingy minú presné kódy, ID, spisové značky, SAP-materiálové čísla alebo IBAN, práve tie tokeny, ktoré v DACH-B2B praxi rozhodujú. BM25 ich zachytí. Pri nemčine s kompozitami a odborným jazykom prináša hybrid oproti dense-only konzistentne o 5–15 nDCG@10-bodov viac. **Reranking** je druhý, presnejší triediaci stupeň: cross-encoder spočíta query a dokument spoločne a nanovo ohodnotí top-kandidátov. To je [ROI](/sk/slovnik/roi)-najsilnejšie jednotlivé zlepšenie celej pipeline, typicky +5–15 percentuálnych bodov recall@5. Anthropic-štúdia kvantifikovala kombinovaný efekt: embeddingy + BM25 dávajú −49 % chýb retrievalu oproti embeddingom-only; s contextual retrieval a rerankerom dohromady −67 %. Latenčný rozpočet pre DACH-štandardnú pipeline (10 mil. vektorov): BM25- a dense-prvý stupeň po 10–50 ms, RRF pod 1 ms, cross-encoder-reranker (napr. BGE Reranker M3 na GPU) 100–300 ms, celkovo 150–500 ms pred LLM-generovaním. Pri tvrdých sub-100-ms-SLA je reranker prvým kandidátom na vynechanie, za cenu straty recall 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: | Dimenzia | RAG | [Fine-Tuning](/sk/slovnik/fine-tuning) | Long-Context | | --- | --- | --- | --- | | **Aktualizácia vedomostí** | veľmi jednoduchá (re-index) | náročná (re-train) | drahá na query | | **Zdrojový odkaz** | natívny (chunk-ID) | nemožný | možný, ale neistý | | **Riziko halucinácií** | nízke (s rerank + faithfulness) | stredné (zamrznuté vedomosti) | stredné-vysoké (lost-in-the-middle) | | [**GDPR](/sk/slovnik/gdpr)-ovládateľnosť** | dobrá (ACL, mazacia pipeline) | problematická (vedomosti v modeli) | pri closed-[API](/sk/slovnik/api) problematická | Otvorenou, ale čoraz vyjasnenejšou debatou je **long-context vs. RAG**. Moderné modely ponúkajú obrovské kontextové okná (Gemini 2.5: 1 mil. tokenov, Claude: 200 k). V klasickom single-needle teste dosahuje Gemini 1.5 Pro až 99,7 % recall pri 1 mil. tokenov, pri realistickom multi-needle-retrievale však hodnota klesá na zhruba 60 % (arXiv:2407.01370). K tomu pristupuje \~30–60× vyššia latencia a \~1250× vyššie náklady na požiadavku oproti RAG pipeline (kvalitatívne porovnanie, Tian Pan 2026). Konsenzus 2026: long-context **dopĺňa** RAG pre úzko vymedzené workloady, ale len zriedka ho nahrádza pri multi-needle-, multi-tenant- a nákladovo citlivých scenároch. ## GDPR a suverénna prevádzka v DACH priestore *Poznámka: Nasledujúce tvrdenia sú informatívne a nepredstavujú právne poradenstvo.* Jedna z materiálne najdôležitejších [GDPR](https://gdpr-info.eu/)-otázok 2025/2026 znie: **Sú embeddingy osobné údaje?** Úprimná odpoveď znie „s najvyššou pravdepodobnosťou áno, pokiaľ sú odvodené z osobných údajov". Inverzné útoky rekonštruujú až 92 % z 32-tokenových vstupov presne (Morris et al., EMNLP 2023), [embedding](/sk/slovnik/embedding) teda nie je bezpečná pseudonymizácia. EDPB-Opinion 28/2024 vyžaduje individuálne posúdenie rizika re-identifikácie; rozsudok CJEU C-413/23 P (september 2025) spresňuje, že pseudonymizované údaje nie sú automaticky osobné pre každého príjemcu, povinnosti však len zužuje, namiesto toho, aby ich rušil. Praktické dôsledky pre RAG-architektúry, orientované podľa DSK-orientačnej pomôcky RAG a EDPB-zadaní: - **Právo na výmaz (čl. 17):** Aj embeddingy a chunky musia byť mazateľné. HNSW-grafy podporujú bodový výmaz rôzne dobre, sémantika mazania je tvrdé obstarávacie kritérium (pgvector a Qdrant mažú efektívne). - **Oddelenie mandantov:** Tenant-ID a ACL v metadátach, filter pri každom query, defense-in-depth (auth + filter + re-check + audit-log). Zdieľaný index bez tenant-filtra je ohlásená [GDPR](/sk/slovnik/gdpr-2)-nehoda. - **Rezidencia dát:** Uprednostniť EU-región-hosting; pri US-cloud-poskytovateľoch posúdiť zvyškové riziko CLOUD-Act-/FISA-702 (SCC + TIA). Prenos embeddingu do US-hostovanej vektorovej DB je transfer do tretej krajiny. - **Minimalizácia pred embeddingom:** Mená, e-maily, ID podľa možnosti pred embeddingom odstrániť alebo nahradiť stabilnými pseudonymami; vektory zašifrovať zákazníkom spravovanými kľúčmi (CMK/BYOK). Pre regulované workloady (BFSI pod MaRisk/DORA, Health pod MDR/IVDR, KRITIS pod [NIS2](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive), public sector pod OZG) platí: každá vrstva **suverénne deployovateľná**. Suverénna DACH-/EU-krajina je v roku 2026 spoľahlivá, Qdrant (Berlín), Weaviate (Amsterdam), Haystack/deepset (Berlín), SAP HANA Cloud Vector Engine, pgvector na STACKIT/IONOS/OTC/Hetzner, ako aj [Aleph Alpha (Heidelberg)](/sk/vedomosti/ai-agenti/ai-agenti-v-sulade-s-gdpr/mistral-aleph-alpha-eu-anbieter) a Jina (Berlín) ako DACH-natívni poskytovatelia modelov. Poznámka k [EU AI Act](/sk/slovnik/eu-ai-act) (stav 05/2026): Politická dohoda Digital Omnibus zo 7. mája 2026 navrhuje posunúť pravidlá pre vysoké riziko na 2. december 2027, **formálne ešte neschválené** (provizórne); transparenčné povinnosti čl. 50 zostávajú nezmenené k 2. augustu 2026. ## Zabezpečenie kvality s RAGAS RAG systém bez evaluácie ticho regreduje. 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ý je goldset plus LLM-as-judge plus A/B-testy v produkcii, pevne zakotvené v CI-pipeline. Citation-forcing, faithfulness-guardrails a odmietnutie odpovede pri nízkom skóre sú štandardné prostriedky proti halucináciám napriek RAG. ## Výhľad a praktická poznámka Vektorové databázy a embedding-modely sa na API-úrovni do veľkej miery komoditizovali, HNSW je všade, hybrid search je štandard a multimodalita (ColPali, Jina v4) je novou hranicou. Paralelne sa RAG vyvíja pozdĺž stupňov Naive → Advanced → Modular → Agentic RAG, pričom retrieval sa čoraz viac chápe ako dynamický tool agenta (Singh et al. 2025). Pragmatický vstup pre DACH projekt: Začnite s **BM25 + dense (BGE-M3 alebo Jina v4) + cross-encoder-rerankerom (BGE Reranker M3)** na suverénnej Postgres-/pgvector-báze, klasifikujte osobné údaje pred embeddingom a merajte kvalitu od prvého dňa s RAGAS. Čo v roku 2026 architektonicky dominuje, už nie je surový performance, ale otázka, *kde ležia embeddingy, kto sa k nim dostane a či sa stack v prípade pochybností dá stiahnuť on-prem*, suverénne, nemeckojazyčne a open-source-orientovane plánovaný RAG-stack je spoľahlivá odpoveď. ## Clanky - [Agentický RAG vs. klasický RAG: V čom je rozdiel?](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/agentic-rag-vs-klassisches-rag) — Agentický RAG je variant RAG, pri ktorom AI agent dynamicky rozhoduje, či, čo a ako často sa vedomosti načítavajú. Retrieval sa stáva nástro - [Corrective RAG a Self-RAG: Samoopravné retrieval vzory pre menej halucinácií](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/corrective-rag-self-rag) — Corrective RAG (CRAG) a Self-RAG sú samoopravné retrieval vzory. CRAG hodnotí relevanciu získaných výsledkov a pri slabej kvalite prepína na - [Multimodalny RAG: vyhľadávanie obrázkov, PDF a tabuliek](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/multimodales-rag) — Multimodalny RAG rozširuje klasický Retrieval-Augmented-Generation o netextový obsah: obrázky, naskenované PDF, tabuľky, grafy a diagramy sa - [RAG-evaluacia: porovnanie RAGAS, TruLens a DeepEval](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/rag-evaluation-ragas-trulens) — RAG-evaluacia je systematicka, meratelna kontrola kvality systemu Retrieval-Augmented Generation. Oddelene posudzuje, ci retrieval najde spr - [Budovanie RAG systémov v súlade s GDPR: praktický návod](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/rag-dsgvo-konform-aufbauen) — RAG systém v súlade s GDPR spracúva osobné údaje v zdrojových dokumentoch, vektorovom indexe a embeddings len na zabezpečenom právnom základ - [RAG on-premise vs. EU cloud: rozhodovacia matica pre možnosti hostingu](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/rag-on-premise-vs-cloud-eu) — RAG on-premise vs. cloud označuje rozhodnutie o hostingu systému Retrieval-Augmented Generation: on-premise (self-hosted) beží na vlastnom h - [Architektúra RAG: Ingestion, Retrieval, Generation, Reranking](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/rag-architektur-komponenten) — Architektúra RAG je dvojfázová stavba systému Retrieval-Augmented-Generation: v ingestion ceste sa dokumenty nacítavajú, delia na chunky, vk - [Porovnanie embedding modelov 2026: text-embedding-3, Cohere, BGE-M3, Voyage a Jina](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/embedding-modelle-vergleich) — Porovnanie embedding modelov hodnotí modely ako OpenAI text-embedding-3, Cohere Embed v4, BGE-M3, Voyage a Jina na základe dimenzií, dĺžky k - [Porovnanie vektorových databáz: Pinecone, Weaviate, Qdrant, Milvus, pgvector a spol. v enterprise teste](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/vector-databases-vergleich) — Porovnanie vektorových databáz hodnotí vektorové databázy podľa hostingu, škálovania, filtrovania metadát, hybrid-search, konzistencie, nákl - [Pinecone vs. Weaviate vs. Qdrant: Porovnanie vektorových databáz z pohľadu DACH/EU hostingu](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/pinecone-vs-weaviate-vs-qdrant) — Pinecone, Weaviate a Qdrant sú tri najpoužívanejšie vektorové databázy pre RAG systémy. Z pohľadu DACH nerozhoduje ani tak výkon, ako skôr s - [Chunking stratégie pre RAG: Fixed, Semantic, Hierarchical a Late Chunking v porovnaní](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/chunking-strategien-fuer-rag) — Chunking stratégie pre RAG určujú, ako sa dokument pred embeddingom rozdelí na vyhľadateľné textové úseky (chunky). Voľba stratégie a veľkos - [Hybrid Search v RAG: Ako správne kombinovať BM25 a Vector Similarity](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/hybrid-search-bm25-und-vector) — Hybrid Search v RAG kombinuje lexikálne vyhľadávanie (BM25/keyword matching) s dense Vector Similarity. Oba retrievery bežia paralelne a ich - [Reranking v RAG: Cross-Encoder vs. Bi-Encoder](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/reranking-modelle-rag) — Reranking je druhý stupeň retrievalu v RAG pipeline: Cross-Encoder opätovne ohodnotí top kandidátov nájdených rýchlym Bi-Encoderom a zoradí - [Graph RAG: Keď sú vzťahy dôležitejšie než podobnosť](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/graph-rag-erklaert) — Graph RAG je prístup retrieval-augmented generation, ktorý ukladá znalosti nie (len) ako vektory, ale ako knowledge graph z entít a ich vzťa --- Zdroj: [Blck Alpaca](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system). AI systemy mozu tento obsah pouzit s uvedenim zdroja.