Typy RAG: od základního vyhledávání po GraphRAG a AI agenty

RAG dává jazykovému modelu před odpovědí podklady z dokumentů, databází nebo webu. Jednoduchá verze zvládne interní FAQ, ale složitější otázky mohou potřebovat přepis dotazu, více zdrojů, kontrolu kvality nebo několik kol hledání. Proto dnes existují různé typy a vzory RAG — a ne všechny řeší stejný problém.

Co je RAG a proč vůbec vznikl

Zkratka RAG znamená Retrieval‑Augmented Generation, česky přibližně generování rozšířené o vyhledávání. Model nemusí spoléhat jen na znalosti uložené ve svých vahách. Nejdřív vyhledá relevantní podklady a teprve potom z nich sestaví odpověď. Díky tomu může pracovat s firemními dokumenty, novými informacemi i zdroji, které při tréninku neviděl.

RAG ale sám o sobě nezaručuje pravdu. Pokud vyhledávač přinese starý nebo nesouvisející dokument, model z něj může vytvořit přesvědčivě znějící chybu — dobré podklady riziko halucinací snižují, ale neodstraní. Moderní varianty proto vylepšují nejen generování, ale hlavně práci před ním: přípravu dokumentů, formulaci dotazu, výběr zdroje, řazení výsledků a kontrolu důkazů.

Tři hlavní paradigmata: Naive, Advanced a Modular RAG

Odborné přehledy často popisují vývoj RAG ve třech stupních. Nejde o produktové edice ani o ostré hranice. Jsou to užitečné názvy pro to, kolik řízení a zpětné vazby kolem základní linky vyhledat → odpovědět přidáváme.

1. Naive RAG: nejlepší výchozí bod

Dokumenty rozdělíte na úryvky, vytvoříte jejich embeddingy a uložíte je do indexu. Uživatelský dotaz projde stejným embeddingovým modelem, systém vezme například pět nejpodobnějších úryvků a přidá je do promptu. To často stačí pro příručku k produktu, interní směrnice nebo znalostní bázi s dobře napsanými otázkami.

Slabina se projeví u nejasných formulací, přesných kódů produktů, dlouhých dokumentů a otázek spojujících více faktů. Jeden dotaz, jedno pořadí výsledků a jedno generování nedávají systému prostor opravit špatný první krok.

2. Advanced RAG: kvalita v každé fázi

Advanced RAG stále může být lineární, ale každou část potrubí promýšlí samostatně. Před hledáním doplní kontext k úryvkům, filtruje podle metadat nebo přepíše otázku do podoby vhodnější pro vyhledávač. Při hledání kombinuje sémantickou podobnost s přesnými klíčovými slovy. Po hledání širší sadu kandidátů znovu seřadí a do modelu pustí jen nejlepší důkazy.

Právě zde bývá největší praktický přínos. Špatnou odpověď často nezpůsobí „slabý model“, ale chybějící správný úryvek. V testech Contextual Retrieval od Anthropic snížila kombinace kontextových embeddingů a BM25 počet neúspěšných nalezení v jejich sadách o 49 % oproti výchozímu RAG; s rerankingem o 67 %. Nejde o univerzální záruku, ale o dobrý příklad, proč má smysl měřit retrieval odděleně od generování.

3. Modular RAG: komponenty a rozhodování

Modular RAG opouští představu jediné pevné linky. Router může poslat dotaz do dokumentů, relační databáze nebo na web. Kontrolní modul může výsledek odmítnout, přepsat dotaz a hledat znovu. Paměť doplní kontext rozhovoru a nástroj pro citace naváže věty odpovědi na konkrétní zdroje.

Modularita usnadňuje kombinování vzorů, které následují. Stejný systém může používat hybridní hledání pro přesné termíny, GraphRAG pro vztahy a agentní smyčku jen u složitých otázek. Cenou je více komponent, složitější ladění a větší prostor pro chyby v řízení.

Osm pokročilých typů a vzorů RAG

Následující názvy nejsou jedna plochá taxonomie. Popisují různé vlastnosti: způsob vyhledávání, zdroj znalostí, kontrolní mechanismus nebo orchestrace. V produkčním řešení se běžně překrývají.

Tři kroky RAG v kódu

Rozdíl mezi typy RAG je nejlépe vidět na kódu. Následující ukázky jsou zjednodušené — funkce jako hledej nebo rerank zastupují vaši implementaci — ale ukazují přesně to místo, kde jednotlivé vzory přidávají práci navíc.

Naive RAG má jádro na dvacet řádků

Celý baseline je hledání nejbližších sousedů plus jeden prompt. Nepotřebujete framework ani vektorovou databázi; u pár tisíc úryvků stačí pole v paměti. Právě tuhle verzi si postavte jako první a změřte ji, než začnete přidávat vrstvy.

from openai import OpenAI
import numpy as np

client = OpenAI()
chunks = nacti_uryvky("dokumentace/")          # seznam textovych uryvku

def embed(texty):
    odpoved = client.embeddings.create(
        model="text-embedding-3-small", input=texty
    )
    return np.array([polozka.embedding for polozka in odpoved.data])

index = embed(chunks)                          # tvar (pocet_uryvku, dimenze)

def odpovez(dotaz, k=5):
    # embeddingy OpenAI maji jednotkovou delku, skalarni soucin = kosinova podobnost
    skore = index @ embed([dotaz])[0]
    podklady = [chunks[i] for i in skore.argsort()[-k:][::-1]]
    instrukce = (
        "Odpovidej vyhradne z dodanych podkladu. "
        "Kdyz odpoved v podkladech neni, rekni to.\n\n"
        + "\n---\n".join(podklady)
    )
    return client.responses.create(
        model="gpt-4.1-mini",
        input=[
            {"role": "system", "content": instrukce},
            {"role": "user", "content": dotaz},
        ],
    ).output_text

Všimněte si systémové instrukce. Už v nejjednodušší verzi patří k RAG explicitní pokyn odpovídat jen z podkladů a přiznat, když informace chybí.

Hybridní hledání a RAG‑Fusion přidávají žebříčky

Hybrid RAG a RAG‑Fusion dělají v podstatě totéž: pustí víc hledání a výsledky sloučí. Reciprocal Rank Fusion přitom nepotřebuje porovnávat skóre z různých systémů, což je jeho hlavní výhoda — pracuje jen s pořadím. Konstanta k (obvykle 60) tlumí vliv prvních míst, takže jeden sebejistý vyhledávač nepřebije ostatní.

def rrf(zebricky, k=60):
    """Reciprocal Rank Fusion: slouci vic serazenych seznamu do jednoho."""
    skore = {}
    for zebricek in zebricky:
        for poradi, doc_id in enumerate(zebricek, start=1):
            skore[doc_id] = skore.get(doc_id, 0.0) + 1 / (k + poradi)
    return sorted(skore, key=skore.get, reverse=True)

kandidati = rrf([
    vektorove_hledani(dotaz, k=20),   # semanticka podobnost
    bm25_hledani(dotaz, k=20),        # presna klicova slova, kody, nazvy
    vektorove_hledani(prepis(dotaz), k=20),   # RAG-Fusion: druha formulace
])

podklady = rerank(dotaz, kandidati[:20])[:5]  # cross-encoder vybere finalni petici

Široký retrieval následovaný rerankingem je nejčastější recept Advanced RAG: hledejte dvacet kandidátů, ale do modelu pusťte pět nejlepších.

Korekční smyčka je jen podmínka navíc

CRAG, Adaptive i Agentic RAG stojí na stejné myšlence — mezi hledání a odpověď vložit rozhodnutí. Nejjednodušší podoba je jedna kontrola relevance a maximálně jedno další kolo.

def odpovez_s_kontrolou(dotaz, max_pokusu=2):
    for pokus in range(max_pokusu):
        podklady = hledej(dotaz)
        hodnoceni = ohodnot_relevanci(dotaz, podklady)   # LLM nebo maly klasifikator

        if hodnoceni.relevantni:
            return generuj(dotaz, podklady)

        if pokus + 1 == max_pokusu:
            break
        dotaz = preformuluj(dotaz, hodnoceni.duvod)      # druhe kolo s lepsim dotazem

    # Cesta "nevim" je soucast navrhu, ne selhani.
    return "V dostupnych podkladech jsem odpoved nenasel."

Limit pokusů tam patří od začátku. Bez něj se ze smyčky snadno stane drahý nekonečný cyklus, a to je nejčastější způsob, jak se agentní RAG prodraží.

Srovnání typů RAG v praxi

RAG, fine‑tuning, nebo dlouhý kontext?

Než začnete vybírat typ RAG, ověřte, že RAG je vůbec správný nástroj. Tři přístupy řeší tři různé problémy a v praxi se často kombinují.

Praktické pravidlo: znalosti řešte retrievalem, chování fine‑tuningem a dlouhý kontext berte jako doplněk pro pár desítek stran na jeden dotaz. I s modelem, který zvládne milion tokenů, se vyplatí nejdřív vybrat relevantní pasáže — kratší a čistší kontext bývá levnější i přesnější než nacpat do promptu celý archiv.

Jak vybrat správný typ RAG

Začněte povahou otázek a chyb, ne názvem frameworku. Praktický router může vypadat takto:

U regulovaných nebo kritických odpovědí přidejte nezávisle na zvoleném typu oprávnění, citace, kontrolu čerstvosti, možnost odpověď odmítnout a lidské schválení tam, kde chyba může způsobit škodu. Složitější RAG není náhradou za správu dat ani bezpečnost.

Čím RAG postavit

Konkrétní nástroje se mění rychleji než principy, takže je berte jako výchozí rozcestník. Pro orientaci pomůže rozdělit je podle role v systému:

Při výběru se ptejte na čtyři věci: zvládne to hybridní hledání, filtrování podle metadat a oprávnění, vrácení citací a napojení na evaluaci? Zbytek je většinou otázka provozních preferencí.

Co měřit, než přidáte další vrstvu

Hodnotit jen výsledný text nestačí. Oddělte, zda systém našel správný důkaz, zda ho model použil a kolik celý proces stojí. Jinak můžete měnit generátor kvůli chybě v indexu.

Začněte sadou reálných otázek uživatelů včetně nejasných, neřešitelných a oprávněním omezených případů. Teprve když například zjistíte, že systém nenachází přesná označení, přidejte BM25. Když selhává u vztahů přes více dokumentů, zvažte graf nebo iterativní retrieval. Architektura tak roste z dat, ne z módních názvů.

Časté chyby při stavbě RAG

• Příliš velké nebo příliš malé chunky. První přinášejí šum, druhé ztrácejí význam. Dělení testujte podle typu dokumentů a otázek.
• Více kontextu za každou cenu. Desítky průměrných pasáží mohou správný důkaz utopit. Pomůže širší retrieval následovaný rerankingem a menším top‑k.
• Žádné metadata a oprávnění. Oddělení zákazníků, platnost dokumentu, jazyk a přístupová práva patří do filtru před generováním.
• Jedna metrika pro celý systém. Bez samostatné evaluace retrievalu nepoznáte, zda chybuje hledání, prompt nebo model.
• Chybějící cesta „nevím“. RAG musí umět přiznat, že důkaz nenašel, místo aby chybějící informaci doplnil z domněnky.
• Agent hned v první verzi. Smyčky a nástroje násobí cenu i možné poruchy. Nejprve postavte jednoduchý baseline, logování a evaluační sadu.
• Ignorování aktualizací. Sledujte původ, verzi a datum dokumentů, mažte neplatné embeddingy a testujte, že nový obsah je skutečně dohledatelný.

Co si odnést

Naive, Advanced a Modular RAG popisují rostoucí pružnost celé architektury. Hybridní hledání, RAG‑Fusion, Adaptive RAG, CRAG, Self‑RAG, GraphRAG, Agentic RAG a multimodální RAG jsou konkrétní způsoby, jak řešit různé slabiny nebo zdroje dat. Lze je skládat, ale každá vrstva musí mít měřitelný důvod.

Pro většinu týmů je nejlepší cesta postupná: kvalitní dokumenty, jednoduchý retrieval, citace a evaluační sada; potom hybridní hledání a reranking. Router, graf nebo agenta přidejte až ve chvíli, kdy baseline prokazatelně nestačí.

Autor článku

Zdeněk Vais

Zakladatel · Senior Principal Software Engineer, Oracle

Zdeněk programuje už od střední školy. Od té doby si prošel cestou od programátora přes team leadera až k architektovi. Vyvíjel velké finanční systémy, vědecké aplikace i IoT řešení pro letadla. V současnosti pracuje jako senior principal software engineer ve společnosti Oracle, kde staví cloud pro mediální služby.

Poznat náš tým →

← Zpět na blog