---
title: "Architektúra RAG: Ingestion, Retrieval, Generation, Reranking"
description: "Architektúra RAG je dvojfázová stavba systému Retrieval-Augmented-Generation: v ingestion ceste sa dokumenty nacítavajú, delia na chunky, vkladajú do vektorov (embedding) a indexujú; v query ceste sa k otázke vyhladajú vhodné pasáže, znovu zoradia (reranking) a odovzdajú ako kontext LLM na generovanie odpovede."
locale: "sk"
canonical: "https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/rag-architektur-komponenten"
category: "AI agenti"
topic: "RAG systémy vysvetlené"
updated: "2026-07-29T08:22:43.500Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Architektúra RAG: Ingestion, Retrieval, Generation, Reranking

Architektúra RAG je dvojfázová stavba systému Retrieval-Augmented-Generation: v ingestion ceste sa dokumenty nacítavajú, delia na chunky, vkladajú do vektorov (embedding) a indexujú; v query ceste sa k otázke vyhladajú vhodné pasáže, znovu zoradia (reranking) a odovzdajú ako kontext LLM na generovanie odpovede.

## Klucove body

- RAG pipeline pozostáva z dvoch oddelených ciest: offline bežiacej ingestion/indexing cesty (loading, chunking, embedding, upsert do vektorovej DB) a online bežiacej query cesty (query-embedding, retrieval, filtering, reranking, context-assembly, generation).
- Reranking pomocou cross-encodera nie je volitelný doplnok: Contextual Retrieval od Anthropic znižuje chybovost retrievalu o 49 percent, v kombinácii s rerankingom o 67 percent (stav september 2024).
- Hybrid Search kombinuje dense vektorové vyhladávanie (HNSW index) so sparse BM25 a zachytáva presné kódy, ID a vlastné mená, ktoré cisté embeddingy minú.
- Metadátové filtre (tenant_id, ACL) patria do každého chunku: sú technickým predpokladom pre multi-tenancy a pre oddelenie mandantov a vymazatelnost, ktoré požaduje DSK.
- Najcastejšie architektonické chyby sú naivný fixed-size chunking, chýbajúci reranking, chýbajúca evaluácia a chýbajúce citácie zdrojov.
- DACH suverénne stavebné prvky pre EU hosting sú Qdrant (Berlín), Weaviate (Amsterdam) a Haystack/deepset (Berlín), ako aj embeddingy od Jina, Mistral alebo Aleph Alpha.

Architektúra [RAG](/sk/slovnik/rag) opisuje technickú stavbu systému [Retrieval-Augmented-Generation](/sk/slovnik/rag) v dvoch jasne oddelených fázach. Prvá fáza, ingestion (tiež indexing), beží offline a prevádza zdrojové dokumenty do prehladávatelného indexu. Druhá fáza, query-time, beží online pre každú otázku a vyhladáva vhodný obsah, znovu ho zoraduje a odovzdáva jazykovému modelu na generovanie. Kto chce RAG prevádzkovat produkcne, musí obe cesty chápat a prevádzkovat oddelene.

- **Dve cesty, nie jedna:** ingestion (loading, chunking, [embedding](/sk/slovnik/embedding), upsert) beží v dávke; query cesta (embedding, retrieval, filtering, reranking, generation) beží pre každú otázku.
- **Reranking je povinnost, nie nadštandard:** cross-encoder po hrubom vyhladávaní merane znižuje chybovost retrievalu (až o 67 percent v kombinácii s Contextual Retrieval, stav september 2024).
- **Metadáta rozhodujú o compliance:** tenant\_id, ACL a referencia zdroja pre každý chunk sú technickým základom pre multi-tenancy, oddelenie mandantov a vymazatelnost.

## Fáza 1: Ingestion / Indexing (offline)

Ingestion cesta je prípravná práca, ktorá vopred rozhoduje o kvalite a latencii neskoršej prevádzky. Pozostáva zo štyroch až piatich krokov:

**1. Loading / konektory.** Zdroje ako SharePoint, S3, Confluence alebo databáza sa pripoja cez konektory. Pre každý dokument sa už tu zachytávajú stabilné ID a metadáta (zdroj, casová peciatka, mandant, prístupové práva).

**2. Parsing.** Surové dokumenty, predovšetkým PDF a zmluvy, sa prevádzajú do štruktúrovaného textu. Layout-aware parsery zachovávajú štruktúru tabuliek, zoznamov a hlaviciek, co neskôr predchádza halucináciám. Nástrojmi sú okrem iného Docling (IBM, Open Source), Unstructured.io, LlamaParse alebo Azure Document Intelligence.

**3. [Chunking](/sk/vedomosti/ai-agenti/co-je-rag-system/chunking-strategien-fuer-rag).** Text sa rozdelí na vyhladatelné jednotky. Naivný fixed-size chunking (napr. 512 tokenov, overlap 50) je jednoduchý, ale prerezáva vety a tabulky. Lepšie sú recursive/semantic chunking (rez pri cosine drifte medzi vetami) alebo hierarchický parent-child chunking (malé chunky na retrieval, velké parent chunky ako kontext). Pravidlo: 200 až 800 tokenov, 10 až 20 percent overlap.

**4. Embedding.** Každý chunk premení embedding model na vektor. Pre nemeckojazycné korpusy dominujú multilingválne modely ako Cohere Embed v4, Voyage-3, Gemini Embedding 002 alebo BGE-M3; suverénne možnosti sú jina-embeddings-v3 (Berlín), Mistral Embed (EU) a Aleph Alpha Pharia-1-Embed (on-prem). Dôležité: nemcina je podla tokenizéra približne 1,3- až 1,7-krát náárocnejšia na tokeny ako anglictina.

**5. Indexovanie / upsert.** Vektory sa spolu s metadátami zapíšu do [vektorovej databázy](/sk/slovnik/vektorova-databaza). Štandardným indexovým algoritmom je takmer všade HNSW (Malkov & Yashunin 2016) s parametrami M, ef\_construction a ef\_search, ktoré vyvažujú recall oproti rýchlosti. Volitelne sa paralelne buduje BM25 index pre Hybrid Search a pred každý chunk sa predradí [LLM](/sk/slovnik/llm)-generovaný kontextový header (Contextual Retrieval).

## Fáza 2: Query-Time (online)

Query cesta spracúva každú jednotlivú používatelskú otázku v milisekundách až niekolkých stovkách milisekúnd:

**1. Predspracovanie otázky (volitelné).** Query-rewriter, HyDE alebo decomposer preformulujú komplexné otázky alebo ich rozložia. V multi-tenant systémoch tu navyše prebieha AuthN/Z a tenant resolution.

**2. Query-embedding.** Otázka sa rovnakým embedding modelom ako chunky premení na vektor. Paralelne vzniká BM25 query.

**3. Retrieval / Vector Search.** Vektorová DB poskytne najpodobnejšie chunky (typicky top\_k = 50 až 100). Pri Hybrid Search bežia dense a sparse vyhladávanie paralelne a spájajú sa cez rank fusion (Reciprocal Rank Fusion).

**4. Filtering.** Metadátové filtre (tenant\_id, ACL, dátum) zúžia kandidátov. To nie je len výkon, ale aj compliance: orientacná pomôcka DSK RAG požaduje oddelenie mandantov a koncept práv a rolí.

**5. [Reranking](/sk/vedomosti/ai-agenti/co-je-rag-system/reranking-modelle-rag).** Cross-encoder (Cohere Rerank v3, BGE-Reranker, Jina Reranker v2) hodnotí query a dokument spolocne a redukuje 50 až 100 kandidátov na najrelevantnejších top\_k = 5 až 10. Cross-encodery sú presnejšie, ale pomalšie ako bi-encodery hrubého vyhladávania, preto bežia až po lacnom recalle.

**6. Context-assembly & prompting.** Finálne chunky sa s referenciami na zdroje vložia do [prompt](/sk/slovnik/prompt) šablóny. Dôležité pasáže patria dopredu, aby sa predišlo problému lost-in-the-middle.

**7. LLM-generation.** Jazykový model vytvorí odpoved, ideálne s citation-forcingom a následným faithfulness guardrailom, ktorý overí, ci je odpoved krytá zdrojmi.

## Tabulka: RAG pipeline podla fázy, úlohy a nástrojov

| Fáza | Úloha | Typické nástroje (stav 2026) |
| --- | --- | --- |
| Ingestion | Loading / konektory | SharePoint, S3, Confluence konektor |
| Ingestion | Parsing | Docling, Unstructured.io, LlamaParse, Azure Document Intelligence |
| Ingestion | Chunking | [LangChain](/sk/slovnik/langchain) splitter, semantic/hierarchical chunking, contextual chunking |
| Ingestion | Embedding | Cohere Embed v4, Voyage-3, Gemini Embedding 002, jina-v3, BGE-M3, Aleph Alpha |
| Ingestion | Indexovanie / upsert | Qdrant, Weaviate, Pinecone, Milvus, pgvector (HNSW + volitelne BM25) |
| Query | Query-embedding | rovnaký embedding model ako ingestion |
| Query | Retrieval / Vector Search | HNSW-ANN vyhladávanie, hybrid (dense + BM25), RRF fúzia |
| Query | Filtering | metadátový filter (tenant\_id, ACL) v Qdrant/Weaviate/pgvector |
| Query | Reranking | Cohere Rerank v3, BGE-Reranker, Jina Reranker v2, LLM-as-Judge |
| Query | Generation | LLM (Claude, [GPT](/sk/slovnik/gpt), Gemini, Mistral, Aleph Alpha Pharia) + faithfulness guardrail |
| Prierez | Evaluation / observability | RAGAS, TruLens, DeepEval, Arize Phoenix, LangSmith |

## Tok dát slovami

Dokument putuje offline cez loader, parser a chunker, embedding model ho vektorizuje a spolu s metadátami pristane ako záznam vo vektorovej DB. Ked online príde otázka, embedduje sa rovnakým modelom, cez HNSW index sa porovná oproti všetkým chunk vektorom a poskytne hrubý výber. Metadátové filtre odstránia to, co používatel nesmie vidiet. Reranker zhustí hrubý výber na najlepšie výsledky. Tie sa s uvedením zdrojov zmontujú do promptu, LLM z nich vygeneruje odpoved a guardrail overí vernost zdroju. Rozhodujúce: ingestion a query embedding musia používat rovnaký model, inak vektory nie sú porovnatelné.

## Konkrétny príklad s císlami

Support bot pre SaaS produkt indexuje 50 000 dokumentov. Pri sémantickom chunkingu s približne 500 tokenmi na chunk vznikne okolo 300 000 vektorov. Indexovanie s Contextual Retrieval stojí podla Anthropic približne 1,02 amerického dolára na 1 milión document tokenov s prompt cachingom (stav september 2024). V prevádzke každá query vyhladá top\_k = 50 kandidátov; Cohere reranker redukuje na top\_k = 5.

Eval od Anthropic ukazuje úcinok stavebných prvkov na chybovosti retrievalu pri top-20: bez optimalizácie bola na úrovni 5,7 percenta. So samotnými Contextual Embeddings klesla na 3,7 percenta (mínus 35 percent), s úplným Contextual Retrieval (embeddingy plus Contextual BM25) na 2,9 percenta (mínus 49 percent) a s dodatocným rerankingom na 1,9 percenta (mínus 67 percent). Hybrid retrieval query vrátane reranku leží z hladiska latencie v rozsahu približne 100 až 800 milisekúnd.

Pseudokód query cesty:

\`\`\`
q\_vec   = embed(query)                         # rovnaký model ako ingestion
dense   = vdb.search(q\_vec, top\_k=50, filter={tenant\_id})
sparse  = bm25.search(query, top\_k=50)
cands   = rrf\_fuse(dense, sparse)              # Hybrid Search
top5    = rerank(query, cands)[:5]             # Cross-Encoder
prompt  = template(query, top5, cite=True)
answer  = llm.generate(prompt)
assert faithfulness(answer, top5) > 0.8        # Guardrail
\`\`\`

## Castéé architektonické chyby

- **Naivný fixed-size chunking** ignoruje hranice viet a tabuliek a vedie k chýbajúcemu obsahu a halucináciám.
- **Nesprávny embedding model pre jazyk** (EN embeddingy pre DE korpus) nicí recall pri nemeckých query.
- **Žiadny reranking:** výsledky sú sémanticky podobné, ale nie relevantné.
- **Lost-in-the-chunks:** bez kontextového headera chunk ako „Zvýšil sa o 12 percent“ nevie, o co ide.
- **Cistá sémantika bez BM25:** presné kódy a ID sa nenájdu.
- **Žiadne metadátové filtre:** žiadna multi-tenant ochrana, žiadna ACL ochrana, chunk od mandanta A môže byt vyhladaný pre mandanta B.
- **Prílis velké top\_k pre LLM:** lost-in-the-middle a vyššie náklady.
- **Žiadna evaluácia a žiadne citácie zdrojov:** tichá regresia kvality a riziko compliance.
- **Embedding drift pri zmene modelu:** bez version stringu a úplného re-indexovania sú staré a nové vektory nekompatibilné.

## Pre agentúry a B2B

Cistá architektúra RAG nie je víkendový prototyp, ale pipeline s ingestion, hybrid retrievalom, rerankingom, evaluáciou a konceptom mazania. Pre agentúry to znamená: hodnota neleží v LLM, ale v dátovej stratégii, v chunkingu a v oddelení mandantov. Pre DACH B2B rozhodovatelov navyše zaváži suverenita: Qdrant, Weaviate, Haystack a EU hosting robia RAG vyhovujúcim DSGVO. [Blck Alpaca](/sk) navrhuje a prevádzkuje takéto pipeline end-to-end, vrátane [RAGAS evaluácie](/sk/vedomosti/ai-agenti/co-je-rag-system/rag-evaluation-ragas-trulens) a pipeline mazania podla orientacnej pomôcky DSK. Oslovte nás, ked sa má z KI pilota stat produkcný, overitelný znalostný systém.

## FAQ

### Aký je rozdiel medzi ingestion a query fázou v architektúre RAG?

Ingestion fáza beží offline a v dávke (batch): zdroje sa pripoja, parsujú, rozdelia na chunky, embedding modelom sa premenia na vektory a zapíšu sa do vektorovej databázy (upsert). Query fáza beží online pre každú otázku: používatelská otázka sa embedduje, vhodné chunky sa vyhladajú, vyfiltrujú, rerankerom znovu zoradia, vložia do promptu a LLM ich spracuje na odpoved.
### Je reranking v RAG pipeline naozaj nutný?

V produkcných systémoch prakticky vždy. Vektorové vyhladávanie poskytuje sémanticky podobné, ale nie nutne relevantné výsledky. Cross-encoder reranker hodnotí query a dokument spolocne a preusporiada top-50 na najlepších top-5 až top-10. Podla Anthropic to v kombinácii s Contextual Retrieval znižuje chybovost retrievalu až o 67 percent (stav september 2024). Bez rerankingu sa do promptu dostane prílis vela šumu.
### Aká velkost chunku je správna pre RAG systém?

Neexistuje univerzálna hodnota. Ako pravidlo platí 200 až 800 tokenov s 10 až 20 percent overlapom. Dôležitejšie ako presné císlo je layout-aware parsing, ktorý zachováva tabulky, zoznamy a nadpisy, ako aj sémantický alebo hierarchický chunking namiesto strnulého fixed-size rezu. Pri nemeckojazycných korpusoch treba zohladnit, že nemcina je podla modelu približne 1,3- až 1,7-krát náárocnejšia na tokeny ako anglictina, co znižuje efektívnu kapacitu chunku.
### Co je Hybrid Search a preco cisté vektorové vyhladávanie nestací?

Hybrid Search kombinuje dense retrieval (sémantické vektorové vyhladávanie cez HNSW index) so sparse retrievalom (klasický BM25 keyword matching) a obidva zoznamy výsledkov fúzuje, typicky cez Reciprocal Rank Fusion. Cisté vektorové vyhladávanie casto minie presné kódy, císla clánkov, vlastné mená alebo ID ako TS-999, pretože tie nesú sotva nejaký sémantický signál. BM25 zachytí práve tieto prípady.
### Aké nástroje potrebujem pre EU suverénnu architektúru RAG?

Pre vektorovú databázu Qdrant (Berlín) alebo Weaviate (Amsterdam/EU), ako framework Haystack od deepset (Berlín), ako embedding jina-embeddings-v3 (Berlín), Mistral Embed (EU) alebo Aleph Alpha Pharia-1-Embed (Heidelberg, on-prem schopný) a pre hosting STACKIT, IONOS, OVHcloud alebo Open Telekom Cloud. Tak ostávajú dáta v EU a oddelenie mandantov i vymazatelnost podla orientacnej pomôcky DSK sa dajú zrealizovat.

---

Zdroj: [Blck Alpaca](https://blckalpaca.at/sk/vedomosti/ai-agenti/co-je-rag-system/rag-architektur-komponenten). AI systemy mozu tento obsah pouzit s uvedenim zdroja.