Architektúra RAG: ingestion, retrieval, generovanie, reranking

Architektúra RAG opisuje technickú stavbu systému Retrieval-Augmented Generation v dvoch jasne oddelených fázach. Prvá fáza, ingestion (tiež indexing), beží offline a prevedie zdrojové dokumenty do prehľadávateľného indexu. Druhá fáza, query-time, beží online pri každom dopyte: vyhľadá vhodný obsah, znovu ho zoradí a odovzdá jazykovému modelu na generovanie. Kto chce RAG prevádzkovať produkčne, musí obe cesty chápať a prevádzkovať oddelene.

• Dve cesty, nie jedna: ingestion (loading, chunking, embedding, upsert) beží v dávkach; cesta dopytu (embedding, retrieval, filtering, reranking, generovanie) beží pri každom dopyte.
• Reranking je povinnosť, nie nadštandard: cross-encoder po hrubom vyhľadávaní merateľne znižuje chybovosť retrievalu (až o 67 percent v kombinácii s Contextual Retrieval, stav k septembru 2024).
• Metadáta rozhodujú o compliance: tenant_id, ACL a odkaz na zdroj pri každom chunku sú technickým základom pre multi-tenancy, oddelenie klientov a vymazateľnosť.

Fáza 1: Ingestion / Indexing (offline)

Cesta ingestion 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. Už tu sa pre každý dokument zaznamenajú stabilné ID a metadáta (zdroj, časová pečiatka, klient, prístupové práva).

2. Parsing. Surové dokumenty, predovšetkým PDF a zmluvy, sa prevedú na štruktúrovaný text. Layout-aware parsery zachovajú štruktúru tabuliek, zoznamov a nadpisov, čo 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. Text sa rozdelí na jednotky, ktoré sa dajú vyhľadať. Naivný fixed-size chunking (napr. 512 tokenov, overlap 50) je jednoduchý, ale rozsekáva vety a tabuľky. Lepšie sú recursive/semantic chunking (rez pri cosine drifte medzi vetami) alebo hierarchický parent-child chunking (malé chunky na retrieval, veľké parent chunky ako kontext). Orientačné pravidlo: 200 až 800 tokenov, 10 až 20 percent overlap.

4. Embedding. Embedding model premení každý chunk na vektor. Pri nemeckojazyčných korpusoch dominujú viacjazyčné modely ako Cohere Embed v4, modely Voyage, Gemini Embedding 2 alebo BGE-M3. Suverénne sa dajú prevádzkovať predovšetkým open-weight modely ako BGE-M3 alebo embeddingy Jina, on-prem alebo u hostingového poskytovateľa v EÚ. Jina AI však od októbra 2025 patrí spoločnosti Elastic a pred komerčným nasadením musíš overiť licenciu príslušnej verzie modelu. Mistral Embed pochádza od parížskeho poskytovateľa Mistral AI. Aleph Alpha z Heidelbergu sa zlučuje s kanadským poskytovateľom Cohere. Pri podpise zmluvy v septembri 2026 ešte chýbalo schválenie úradov. Dôležité: nemčina je podľa tokenizéra približne 1,3- až 1,7-krát náročnejšia na tokeny ako angličtina.

5. Indexovanie / upsert. Vektory sa spolu s metadátami zapíšu do vektorovej databázy. Š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 a rýchlosť. Voliteľne sa paralelne vytvorí BM25 index pre Hybrid Search a pred každý chunk sa vloží kontextová hlavička vygenerovaná LLM (Contextual Retrieval).

Fáza 2: Query-Time (online)

Cesta dopytu beží pri každej jednotlivej otázke používateľa. Query embedding, retrieval, filtering a reranking trvajú spolu orientačne okolo 100 až 800 milisekúnd, v závislosti od veľkosti indexu a od rerankera. Voliteľné predspracovanie pomocou LLM, napríklad HyDE alebo query rewriter, si vyžiada ďalšie volanie modelu. Záverečné generovanie v LLM trvá podľa dĺžky odpovede väčšinou jednu až niekoľko sekúnd. Jednotlivé kroky:

1. Predspracovanie dopytu (voliteľné). 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 premení na vektor tým istým embedding modelom ako chunky. Paralelne vznikne BM25 dopyt.

3. Retrieval / Vector Search. Vektorová DB vráti najpodobnejšie chunky (typicky top_k = 50 až 100). Pri Hybrid Search bežia dense a sparse vyhľadávanie paralelne a spoja sa cez rank fusion (Reciprocal Rank Fusion).

4. Filtering. Metadátové filtre (tenant_id, ACL, dátum) zúžia okruh kandidátov. Týka sa to aj compliance: orientačná pomôcka DSK ku generatívnym AI systémom s metódou RAG (október 2025) uvádza oddelenie klientov a koncept práv a rolí ako opatrenia na zabezpečenie dôvernosti a obmedzenia účelu.

5. Reranking. Cross-encoder (Cohere Rerank, BGE-Reranker, Jina Reranker) hodnotí dopyt a dokument spoločne a zredukuje 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 vyhľadávania, preto bežia až po lacnom hrubom vyhľadávaní.

6. Context assembly & prompting. Výsledné chunky sa s odkazmi na zdroje vložia do šablóny promptu. Dôležité pasáže patria dopredu, aby sa predišlo problému lost-in-the-middle.

7. Generovanie pomocou LLM. Jazykový model vytvorí odpoveď, ideálne s citation forcingom a následným faithfulness guardrailom, ktorý overí, či je odpoveď podložená zdrojmi.

Tabuľka: RAG pipeline podľa fázy, úlohy a nástrojov

Tok dát opísaný slovami

Dokument putuje offline cez loader, parser a chunker, embedding model ho vektorizuje a dokument potom spolu s metadátami skončí ako záznam vo vektorovej DB. Keď online príde otázka, embedduje sa tým istým modelom, cez HNSW index sa porovná so všetkými vektormi chunkov a vráti hrubý výber. Metadátové filtre odstránia to, čo používateľ nesmie vidieť. Reranker zúži hrubý výber na najlepšie výsledky. Tie sa s uvedením zdrojov poskladajú do promptu, LLM z nich vygeneruje odpoveď a guardrail overí vernosť voči zdroju. Rozhodujúce: embedding pri ingestion aj pri dopyte musí používať rovnaký model, inak vektory nie sú porovnateľné.

Konkrétny príklad s číslami

Zákaznícky chatbot 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í podľa spoločnosti Anthropic približne 1,02 USD za 1 milión tokenov dokumentov s prompt cachingom (stav k septembru 2024). V prevádzke každý dopyt vyhľadá top_k = 50 kandidátov; reranker Cohere ich zredukuje na top_k = 5.

Evaluácia spoločnosti Anthropic ukazuje účinok jednotlivých stavebných prvkov na chybovosť retrievalu pri top-20: bez optimalizácie bola 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 dodatočným rerankingom na 1,9 percenta (mínus 67 percent). Dopyt s hybridným retrievalom vrátane rerankingu má latenciu približne 100 až 800 milisekúnd.

Pseudokód cesty dopytu:

```
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, filter={tenant_id})
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
```

Časté 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 daný jazyk (EN embeddingy pre DE korpus) zničí recall pri nemeckých dopytoch.
• Žiadny reranking: výsledky sú sémanticky podobné, ale nie relevantné.
• Lost-in-the-chunks: bez kontextovej hlavičky chunk ako „Zvýšil sa o 12 percent“ nevie, o čo ide.
• Čistá sémantika bez BM25: presné kódy a ID sa nenájdu.
• Žiadne metadátové filtre: žiadna multi-tenant ochrana ani ochrana cez ACL, chunk klienta A sa môže vyhľadať pre klienta B.
• Príliš veľké 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 pre compliance.
• Embedding drift pri zmene modelu: bez reťazca s verziou modelu a bez úplného reindexovania sú staré a nové vektory nekompatibilné.

Pre agentúry a B2B

Dobre navrhnutá architektúra RAG je pipeline s ingestion, hybridným retrievalom, rerankingom, evaluáciou a konceptom mazania. Pre agentúry spočíva hodnota v dátovej stratégii, v chunkingu a v oddelení klientov. Pre B2B rozhodovateľov v regióne DACH je navyše dôležitá suverenita: Qdrant, Weaviate, Haystack a hosting v EÚ sú dobrým základom pre prevádzku v súlade s GDPR. Blck Alpaca navrhuje a prevádzkuje takéto pipeline end-to-end, vrátane evaluácie pomocou RAGAS a pipeline na mazanie podľa orientačnej pomôcky DSK. Ozvi sa nám, keď sa má z pilotného AI projektu stať produkčný, overiteľný znalostný systém.