RAG systémy vysvetlené
Ako RAG systémy dodávajú LLM externé znalosti — retrieval, embeddingy, vektorové databázy a presné odpovede.
Retrieval-Augmented Generation (RAG) je metóda, pri ktorej jazykový model pred generovaním odpovede cielene vyhľadá relevantný obsah z externého zdroja vedomostí (Retrieval) a vloží ho do promptu (Augmentation). RAG systém pozostáva z troch povinných prvkov: externého úložiska vedomostí s indexom, retrievera a generator-LLM, ktorého prompt sa doplní o nájdené pasáže. Odpovede sú tak podložené zdrojmi, overiteľné a udržiavané aktuálne bez nutnosti re-trainingu.
Na prvý pohľad
- ✓RAG kombinuje generatívny jazykový model s retrieverom, ktorý pred každou odpoveďou cielene získava vedomosti z externého zdroja; pôvodná definícia pochádza od Lewis et al. (Facebook AI, NeurIPS 2020) ako kombinácia parametrickej a neparametrickej pamäte.
- ✓Anthropic Contextual Retrieval znižuje mieru chybovosti retrievalu o 49 percent, v kombinácii s rerankingom o 67 percent (Anthropic, 09/2024) - reranker je tým ROI-najsilnejším jednotlivým zlepšením pipeline.
- ✓Hybrid Search kombinuje dense-retrieval (vektory) so sparse-retrievalom (BM25) a zachytáva presné kódy, ID a názvy, ktoré čisté embeddingy minú; pri nemčine hybrid typicky prináša o 5-15 nDCG@10-bodov viac než samotný dense.
- ✓HNSW (Malkov a Yashunin, 2016) je štandardný indexovací algoritmus v takmer všetkých produkčných vektorových databázach a poskytuje 95-99 percent recall pri dobrej latencii zhruba do 100 mil. vektorov.
- ✓Long-context modely RAG nenahrádzajú: Gemini 1.5 Pro dosahuje v single-needle teste až 99,7 percent recall pri 1 mil. tokenov, pri realistickom multi-needle však klesá na zhruba 60 percent - pri 30-60x vyššej latencii a približne 1250x vyšších nákladoch na požiadavku (Tian Pan 2026; arXiv:2407.01370).
- ✓Pri nemeckojazyčných korpusoch rozhoduje nemecká kvalita embeddingov, nie anglické MTEB-poradie; multilingválne modely ako Cohere Embed v4, BGE-M3 (MIT, MIRACL-SOTA) a Jina v4 (Berlín, Apache 2.0) vedú v roku 2026.
- ✓Súvislosť s GDPR (informatívne, nie právne poradenstvo): Embeddingy osobných údajov sa podľa EDPB-Opinion 28/2024 s najvyššou pravdepodobnosťou považujú za osobné údaje; inverzné útoky rekonštruujú až 92 percent z 32-tokenových vstupov (Morris et al., EMNLP 2023), preto sa čl. 17 musí uplatňovať aj na embeddingy a chunky.
- ✓Suverénne DACH-/EU-možnosti umožňujú on-prem prevádzku: Qdrant (Berlín), Weaviate (Amsterdam), Haystack/deepset (Berlín), SAP HANA Cloud Vector Engine, pgvector na STACKIT/IONOS/OTC, ako aj Aleph Alpha a Jina ako DACH-natívni poskytovatelia.
Č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 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 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 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, 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; 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 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 (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-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-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 | 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-ovládateľnosť | dobrá (ACL, mazacia pipeline) | problematická (vedomosti v modeli) | pri closed-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-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 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-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, 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) a Jina (Berlín) ako DACH-natívni poskytovatelia modelov. Poznámka k 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ď.
Všetky články v tejto téme
14 ČlánkyArchitektú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.
Porovnanie embedding modelov 2026: text-embedding-3, Cohere, BGE-M3, Voyage a Jina
Porovnanie embedding modelov hodnotí modely ako OpenAI text-embedding-3, Cohere Embed v4, BGE-M3, Voyage a Jina na základe dimenzií, dĺžky kontextu, benchmarkov MTEB/MMTEB, viacjazyčnosti, nákladov, self-hostingu a licencie. Pre nemecky hovoriace RAG systémy nerozhoduje anglické poradie v MTEB, ale doložená kvalita na MMTEB, MIRACL a MTEB-DE.
Porovnanie vektorových databáz: Pinecone, Weaviate, Qdrant, Milvus, pgvector a spol. v enterprise teste
Porovnanie vektorových databáz hodnotí vektorové databázy podľa hostingu, škálovania, filtrovania metadát, hybrid-search, konzistencie, nákladov a vyspelosti. V DACH enterprise prostredí je voľba v roku 2026 primárne rozhodnutím o suverenite a GDPR: pgvector pokrýva väčšinu prípadov pod približne 50 miliónmi vektorov, Qdrant platí za DACH-blízkeho šampióna.
Pinecone vs. Weaviate vs. Qdrant: Porovnanie vektorových databáz z pohľadu DACH/EU hostingu
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 suverenita hostingu: Qdrant (Berlín, Apache 2.0) a Weaviate (Amsterdam, BSD-3) sú self-hostovateľné a EU-natívne, Pinecone je US-Managed-SaaS bez možnosti On-Prem.
Chunking stratégie pre RAG: Fixed, Semantic, Hierarchical a Late Chunking v porovnaní
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ľkosti chunku rozhodujúcim spôsobom ovplyvňuje kvalitu retrievalu: určuje, či jazykový model nájde správnu pasáž a či táto obsahuje dostatok kontextu pre správnu, zdrojmi podloženú odpoveď.
Hybrid Search v RAG: Ako správne kombinovať BM25 a Vector Similarity
Hybrid Search v RAG kombinuje lexikálne vyhľadávanie (BM25/keyword matching) s dense Vector Similarity. Oba retrievery bežia paralelne a ich zoznamy zásahov sa cez rank fusion (najčastejšie Reciprocal Rank Fusion) zlúčia do jedného výsledku. Systém tak nájde sémanticky podobné pasáže aj presné pojmy, vlastné mená a kódy, ktoré samotné embeddings nezachytia.
Reranking v RAG: Cross-Encoder vs. Bi-Encoder
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í ich podľa skutočnej relevancie voči query. Podľa Anthropic reranking výrazne znižuje chybovosť retrievalu oproti čistému vektorovému retrievalu – za cenu vyššej latencie.
Graph RAG: Keď sú vzťahy dôležitejšie než podobnosť
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ťahov. Namiesto čisto sémantickej podobnosti využíva systém štruktúru grafu na zodpovedanie multi-hop otázok a na prepájanie súvislostí naprieč mnohými dokumentmi.
Agentický RAG vs. klasický RAG: V čom je rozdiel?
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ástrojom, ktorý agent volá reflexívne, viacstupňovo a z viacerých zdrojov. Klasický RAG naopak sleduje pevnú, jednorazovú pipeline bez rozhodovacej logiky.
Corrective RAG a Self-RAG: Samoopravné retrieval vzory pre menej halucinácií
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 web-search fallback. Self-RAG necháva model cez reflection tokens samostatne rozhodnúť, či vôbec vyhľadáva a či je jeho vlastná odpoveď podložená zdrojmi.
Multimodalny RAG: vyhľadávanie obrázkov, PDF a tabuliek
Multimodalny RAG rozširuje klasický Retrieval-Augmented-Generation o netextový obsah: obrázky, naskenované PDF, tabuľky, grafy a diagramy sa indexujú a sprístupňujú na vyhľadávanie. Namiesto prehľadávania len čistého textu systém získava vizuálne a štruktúrované informácie cez multimodalne embeddings, popisy z Vision-LLM alebo layout-aware parsing a vkladá ich so zdrojovým podložením do prompt-u odpovede.
RAG-evaluacia: porovnanie RAGAS, TruLens a DeepEval
RAG-evaluacia je systematicka, meratelna kontrola kvality systemu Retrieval-Augmented Generation. Oddelene posudzuje, ci retrieval najde spravne dokumenty a ci generovana odpoved verne vychadza z tychto zdrojov. Klucovymi metrikami su Faithfulness, Answer Relevance, Context Precision a Context Recall, merane frameworkmi ako RAGAS, TruLens, DeepEval alebo LangSmith.
Budovanie RAG systémov v súlade s GDPR: praktický návod
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áklade, s minimalizáciou údajov, EU hostingom, oddelením mandantov a mazacou pipeline, ktorá odstraňuje chunks a embeddings spoločne. Embeddings sa pritom podľa praxe dozorných orgánov považujú za pseudonymné osobné údaje, nie za anonymné.
RAG on-premise vs. EU cloud: rozhodovacia matica pre možnosti hostingu
RAG on-premise vs. cloud označuje rozhodnutie o hostingu systému Retrieval-Augmented Generation: on-premise (self-hosted) beží na vlastnom hardvéri s maximálnou kontrolou nad dátami a s nákladmi typu CapEx, EU cloud využíva spravované služby v dátových centrách v EÚ s nákladmi typu OpEx a rýchlejším škálovaním. Voľba sa riadi citlivosťou dát, súladom s predpismi, nákladmi a prevádzkovým know-how.