Architektúra RAG: Ingestion, Retrieval, Generation, 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 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, 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. 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. Š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-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. 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 š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

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 navrhuje a prevádzkuje takéto pipeline end-to-end, vrátane RAGAS evaluácie a pipeline mazania podla orientacnej pomôcky DSK. Oslovte nás, ked sa má z KI pilota stat produkcný, overitelný znalostný systém.