RAG, tedy Retrieval-Augmented Generation, je architektura umělé inteligence, která kombinuje vyhledání relevantních informací s generováním odpovědi. Model tedy neodpovídá jen podle toho, co se naučil při trénování, ale nejprve si z externích zdrojů načte potřebné podklady a teprve potom z nich vytvoří odpověď.

Na první pohled může RAG působit jako obyčejné vyhledávání nad dokumenty. Uživatel se zeptá, systém něco najde a jazykový model odpoví. Ve skutečnosti jde ale o důležitou architekturu, která řeší jeden z hlavních problémů velkých jazykových modelů – jejich omezený přístup k aktuálním, interním nebo přesně ověřitelným informacím.

Co RAG v praxi skutečně znamená

Běžný velký jazykový model umí velmi dobře pracovat s textem.

Dokáže odpovídat na otázky, psát články, shrnovat dokumenty, překládat, vysvětlovat složité pojmy nebo vytvářet návrhy e-mailů. To ale neznamená, že má automaticky přístup ke všem aktuálním a konkrétním informacím.

Model nezná interní dokumentaci firmy, pokud mu ji někdo nedodá. Nemusí znát nejnovější ceník, aktuální obchodní podmínky, poslední verzi smlouvy, konkrétní produktová data ani obsah firemní znalostní báze. A pokud odpovídá bez těchto podkladů, může odpovědět obecně, zastarale nebo nepřesně.

RAG tento problém řeší tak, že mezi uživatelský dotaz a odpověď modelu vloží vyhledávací vrstvu. Ta najde relevantní informace a model je použije jako podklad pro odpověď.

Prakticky to může vypadat takto:

• uživatel se zeptá, jak postupovat při reklamaci poškozeného zboží,
• systém najde příslušnou část reklamačního řádu,
• vybere několik relevantních pasáží,
• vloží je modelu do kontextu,
• model z nich připraví srozumitelnou odpověď,
• uživatel ideálně vidí i zdroj, ze kterého odpověď vychází.

Bez RAG by model mohl odpovědět jen obecně. S RAG má šanci odpovědět podle konkrétního dokumentu.

Proč RAG vznikl

Velké jazykové modely mají jednu zásadní výhodu: umějí dobře generovat jazyk. Zároveň ale mají několik omezení.

Model může mít zastaralé znalosti, protože jeho trénování proběhlo v určitém období. Nemusí znát soukromé firemní dokumenty. Nemusí vědět, která verze dokumentu je platná. A pokud nemá dostatek podkladů, může si chybějící část odpovědi domyslet.

Právě tady dává RAG smysl. Nesnaží se všechno „naučit“ přímo do modelu. Místo toho modelu v okamžiku dotazu dodá relevantní informace z externího zdroje.

Co znamená zkratka RAG

Zkratka RAG znamená Retrieval-Augmented Generation. Každá část názvu popisuje jednu důležitou fázi.

• Retrieval – systém vyhledá relevantní informace z externích zdrojů, například z dokumentů, znalostní báze, databáze, interní wiki nebo webu.
• Augmented – nalezené informace se přidají k dotazu jako rozšířený kontext pro model.
• Generation – jazykový model z dotazu a dodaných podkladů vygeneruje odpověď.

Zjednodušeně: RAG nejdřív hledá, potom doplňuje kontext a nakonec generuje odpověď.

Jak RAG funguje krok za krokem

RAG se dá vysvětlit jako několik navazujících kroků. Některé probíhají předem při přípravě dat, jiné až ve chvíli, kdy se uživatel zeptá.

1. Připraví se zdroje dat – systém musí mít kde hledat. Může jít o PDF dokumenty, články, interní návody, znalostní bázi, technickou dokumentaci, produktová data, smlouvy, databázi nebo obsah webu. Pokud jsou zdroje nekvalitní, zastaralé nebo duplicitní, RAG bude vracet horší výsledky.
2. Dokumenty se rozdělí na menší části – dlouhý dokument se obvykle nerozebírá jako jeden celek. Systém ho rozdělí na menší úseky, kterým se často říká chunky. Smyslem je, aby se při dotazu nehledal celý dokument, ale konkrétní pasáž, která odpovídá otázce.
3. Obsah se uloží do vyhledávacího indexu – aby bylo možné v dokumentech rychle hledat, systém si nad nimi vytvoří index. Index může být založený na klíčových slovech, významové podobnosti, metadatech nebo kombinaci více přístupů.
4. Texty se často převedou na embeddingy – embedding je číselná reprezentace obsahu. Díky ní lze porovnávat významovou podobnost dotazu a dokumentu i tehdy, když nepoužívají stejná slova. Například dotaz „Co dělat, když zákazník nezaplatil?“ může souviset s dokumentem nazvaným „Postup při prodlení s úhradou faktury“.
5. Uživatel položí dotaz – ve chvíli, kdy se uživatel zeptá, systém nejprve nepošle dotaz rovnou modelu k volnému generování. Nejdříve se pokusí najít relevantní podklady.
6. Retrieval najde nejvhodnější pasáže – vyhledávací vrstva porovná dotaz s uloženými dokumenty a vybere části, které s dotazem nejvíce souvisejí. Může jít o několik odstavců, části tabulek, úseky dokumentace nebo konkrétní záznamy.
7. Nalezené informace se vloží do promptu – systém vytvoří rozšířené zadání pro model. Obsahuje původní dotaz uživatele, nalezené pasáže a často také instrukci, aby model odpovídal pouze podle dodaných zdrojů.
8. Model vytvoří odpověď – jazykový model dostane dotaz i kontext a z těchto informací vytvoří odpověď. Tady nastává generační část RAG.
9. Odpověď může obsahovat zdroje – dobře navržený RAG systém umožňuje dohledat, z jakých dokumentů odpověď vznikla. To je důležité hlavně ve firmách, právu, technické podpoře, zdravotnictví, financích a dalších oblastech, kde nestačí jen hezky napsaná odpověď.

RAG versus běžný chatbot

Rozdíl mezi běžným chatbotem a RAG chatbotem je nejlépe vidět ve chvíli, kdy se uživatel neptá na obecnou znalost, ale na konkrétní pravidlo, dokument nebo aktuální interní informaci.

Představte si například zákaznickou podporu e-shopu. Zákazník se zeptá:

„Přišlo mi poškozené zboží. Jak mám postupovat při reklamaci?“

Běžný chatbot bez RAG může odpovědět jen obecně. Vychází hlavně z toho, co má model ve svých natrénovaných znalostech a v aktuální konverzaci. Může tedy napsat například:

„Poškozené zboží obvykle vyfoťte, kontaktujte prodejce a počkejte na další instrukce.“

Taková odpověď může být jazykově správná, ale nemusí odpovídat konkrétním pravidlům daného e-shopu. Neví, zda firma vyžaduje fotografii obalu, jaká je lhůta pro nahlášení škody, jestli má zákazník vyplnit formulář, poslat zboží zpět nebo čekat na svoz.

RAG chatbot postupuje jinak. Nejprve v interních podkladech vyhledá aktuální reklamační řád, pravidla pro poškozené zásilky nebo článek ze znalostní báze. Teprve potom odpoví podle nalezeného dokumentu.

Může tedy odpovědět například:

„Podle reklamačního postupu pro poškozené zásilky nejprve vyfoťte poškozený produkt i vnější obal, číslo objednávky uveďte do reklamačního formuláře a reklamaci odešlete nejpozději do 48 hodin od převzetí. Zboží zatím neposílejte zpět, dokud vás nekontaktuje zákaznická podpora.“

Rozdíl tedy není jen v tom, že druhá odpověď zní konkrétněji. Hlavní rozdíl je v podkladu. Běžný chatbot odpovídá obecně. RAG chatbot odpovídá podle konkrétního dokumentu, který systém před odpovědí dohledal.

RAG versus fine-tuning

RAG se často zaměňuje s fine-tuningem. Fine-tuning znamená dodatečné trénování modelu na konkrétních datech nebo úloze. RAG znamená, že model zůstává obecnější, ale při odpovědi dostane relevantní externí podklady.

Rozdíl je zásadní.

• Fine-tuning – mění chování modelu nebo ho přizpůsobuje určitému typu úlohy.
• RAG dodává modelu informace v okamžiku dotazu.

Pokud firma mění ceník, obchodní podmínky, technickou dokumentaci nebo interní pravidla, bývá RAG praktičtější. Stačí aktualizovat zdrojové dokumenty a index. Není nutné model znovu trénovat.

Fine-tuning se hodí spíše tam, kde chcete upravit styl odpovědí, formát výstupu, specializované chování nebo naučit model opakovaný typ úlohy. RAG je vhodnější tam, kde se často mění znalosti a záleží na konkrétních zdrojích.

RAG versus dlouhé kontextové okno

Některé moderní modely zvládají zpracovat velmi dlouhý kontext. To ale neznamená, že RAG přestává dávat smysl.

Dlouhé kontextové okno umožňuje vložit modelu více textu najednou. RAG řeší něco trochu jiného: vybírá z velkého množství dokumentů jen ty pasáže, které jsou pro dotaz skutečně relevantní.

Pokud má firma tisíce dokumentů, nelze je všechny pokaždé poslat modelu. Bylo by to drahé, pomalé a často i méně přesné. RAG slouží jako filtr, který vybere jen potřebné části.

Prakticky řečeno:

• dlouhé kontextové okno zvětšuje prostor, se kterým model pracuje,
• RAG pomáhá rozhodnout, co se do tohoto prostoru má dostat,
• dobrý systém často používá obojí – dostatečný kontext i kvalitní retrieval.

RAG a retrieval

Retrieval je první a často nejdůležitější část RAG. Pokud systém najde špatné podklady, model z nich může vytvořit špatnou odpověď. Pokud najde příliš málo informací, model může odpovědět neúplně. Pokud najde příliš mnoho nesouvisejícího textu, odpověď může být zmatená.

Retrieval tedy rozhoduje o tom, co model uvidí.

U RAG systému se proto často řeší:

• jak rozdělit dokumenty na části,
• jak vytvořit index,
• zda hledat podle klíčových slov, významu nebo obojího,
• jak pracovat s datem a verzí dokumentu,
• jak seřadit výsledky podle relevance,
• kolik pasáží vložit modelu do kontextu,
• jak citovat zdroje,
• jak poznat, že systém žádný dobrý zdroj nenašel.

RAG a embeddingy

Embeddingy jsou důležité hlavně u sémantického vyhledávání. Umožňují systému hledat podobný význam, ne jen stejná slova.

Příklad:

• uživatel se zeptá: „Jak vyřešit pozdní platbu?“
• dokument používá formulaci: „Postup při prodlení s úhradou faktury“,
• slova nejsou stejná,
• významově ale dotaz a dokument patří k sobě.

Klasické vyhledávání podle klíčových slov nemusí podobný vztah najít. Sémantické vyhledávání přes embeddingy má větší šanci.

To ale neznamená, že embeddingy jsou vždy lepší než klíčová slova. U přesných identifikátorů, jako je číslo objednávky, IČO, SKU nebo název produktu, může být klasické vyhledávání přesnější. Proto se v praxi často používá hybridní vyhledávání.

RAG a tokeny

Tokeny jsou u RAG důležité proto, že nalezené pasáže se vkládají modelu do kontextu. A tento kontext má omezenou kapacitu.

Pokud retrieval najde deset dlouhých pasáží, spotřebuje mnoho tokenů. Model pak může mít méně prostoru pro samotnou odpověď a zároveň se může ztratit v nepodstatných informacích.

Dobrý RAG systém proto neřeší jen to, jestli něco našel, ale také kolik toho modelu předá.

Příklad:

• špatný RAG předá modelu dlouhý dokument, ve kterém je relevantní jen jeden odstavec,
• lepší RAG předá modelu přímo ten odstavec a několik okolních vět,
• model má jasnější podklad a odpověď může být přesnější i levnější.

RAG a prompt engineering

RAG není oddělený od prompt engineeringu. Nalezené podklady se obvykle skládají do promptu, který model dostane.

Nestačí tedy jen najít dokument. Je potřeba ho modelu správně předat.

Prompt může obsahovat například instrukce:

• odpověz pouze podle dodaných podkladů,
• pokud v podkladech odpověď není, napiš, že ji nelze ověřit,
• nepřidávej domněnky,
• odděl fakta od interpretace,
• uveď zdrojovou pasáž, ze které vycházíš.

Bez těchto instrukcí může model nalezené informace špatně zobecnit nebo doplnit něčím, co ve zdroji není.

RAG a grounding

Grounding znamená ukotvení odpovědi v konkrétních zdrojích. RAG je jeden z hlavních způsobů, jak grounding v AI aplikacích zajistit.

Bez groundingu může model odpovědět jazykově dobře, ale není jasné, odkud informace pochází. S groundingem je odpověď opřená o konkrétní dokument, záznam nebo pasáž.

To je důležité hlavně u:

• firemních pravidel,
• technické dokumentace,
• zákaznické podpory,
• právních a smluvních podkladů,
• produktových dat,
• interních znalostních bází,
• obsahu, kde je potřeba dohledat zdroj.

RAG ale grounding nezaručuje automaticky. Pokud systém najde špatný zdroj nebo model zdroj špatně interpretuje, odpověď může být stále chybná.

Co RAG umí zlepšit

RAG dává smysl hlavně tam, kde model potřebuje pracovat s konkrétními, aktuálními nebo neveřejnými informacemi.

Může pomoci například s tím, že:

• odpovědi vycházejí z konkrétních dokumentů,
• model může pracovat s aktuálnějšími informacemi, než měl při trénování,
• není nutné model znovu trénovat při každé změně dokumentace,
• výstupy lze lépe kontrolovat přes zdroje,
• AI asistent může fungovat nad firemní znalostní bází,
• odpověď lze přizpůsobit interním pravidlům firmy,
• systém může omezit část halucinací, protože model má k dispozici podklady.

Slovo „omezit“ je důležité. RAG halucinace nesmaže úplně. Jen snižuje riziko, že model bude odpovídat bez podkladů.

Kde se RAG používá

RAG se používá hlavně v aplikacích, kde má AI odpovídat podle konkrétního obsahu.

• Zákaznická podpora – AI asistent může odpovídat podle znalostní báze, reklamačních pravidel, návodů, produktové dokumentace nebo obchodních podmínek. Operátor pak nemusí ručně hledat v desítkách dokumentů.
• Interní firemní asistenti – zaměstnanec se může zeptat na interní postup, pravidlo, proces nebo dokumentaci. RAG systém najde příslušnou pasáž a model ji převede do srozumitelné odpovědi.
• Technická dokumentace – RAG se hodí pro dotazy nad manuály, API dokumentací, servisními postupy, technickými listy nebo znalostními databázemi.
• E-commerce – v e-commerce může RAG pracovat s produktovými parametry, dostupností, kompatibilitou, návody, reklamacemi nebo častými dotazy zákazníků.
• Právní a smluvní dokumenty – RAG může pomoci najít relevantní ustanovení ve smlouvách, obchodních podmínkách nebo interních pravidlech. Výstup ale musí kontrolovat člověk, protože právní interpretace je citlivá.
• Redakce a obsah – RAG může pomoci při práci se zdroji, staršími články, interními poznámkami nebo znalostní bází. Model pak nemusí vycházet jen z obecného povědomí, ale z konkrétních podkladů.

Proč RAG není jen vyhledávání

RAG bývá někdy zjednodušeně popisovaný jako „vyhledávání plus AI“. To není úplně špatně, ale je to neúplné.

Samotné vyhledávání uživateli vrátí dokumenty nebo odkazy. RAG jde dál. Vyhledané pasáže vloží do kontextu modelu a ten z nich vytvoří odpověď.

Rozdíl:

• Vyhledávání – najde dokumenty, které si musí člověk přečíst sám.
• RAG – najde relevantní informace a model z nich připraví odpověď.

To je praktické, ale zároveň rizikové. Jakmile model začne informace přeformulovávat, může něco zjednodušit, vynechat nebo špatně spojit. Proto je důležité zachovat dohledatelné zdroje.

Typy vyhledávání v RAG

RAG může používat různé způsoby vyhledávání. V praxi se často kombinují.

Vyhledávání podle klíčových slov

Vyhledávání podle klíčových slov hledá přesné nebo podobné výrazy. Hodí se u názvů, kódů, čísel, SKU, IČO, názvů produktů nebo konkrétních formulací.

Je rychlé a dobře vysvětlitelné. Slabší je v situaci, kdy se uživatel ptá jinými slovy, než jakými je formulovaný dokument.

Sémantické vyhledávání

Sémantické vyhledávání hledá významovou podobnost. Pracuje s embeddingy a vektorovým porovnáváním.

Hodí se u přirozených dotazů typu:

• „Co dělat, když se zásilka poškodí?“
• „Jak postupujeme při pozdní platbě?“
• „Kde máme napsané, kdo schvaluje výjimky?“

Dotaz a dokument nemusí používat stejná slova, ale systém může poznat, že významově souvisejí.

Hybridní vyhledávání

Hybridní vyhledávání kombinuje klíčová slova a sémantické vyhledávání. V praxi bývá často nejlepší, protože pokrývá jak přesné identifikátory, tak volně formulované dotazy.

Vyhledávání podle metadat

Metadata jsou doplňující informace o dokumentu. Například datum, verze, autor, typ dokumentu, oddělení, jazyk, platnost nebo úroveň oprávnění.

Metadata jsou v RAG velmi důležitá. Pomáhají určit, který dokument je aktuální, platný a dostupný pro konkrétního uživatele.

RAG a oprávnění

Ve firemním prostředí je bezpečnost zásadní. RAG systém nesmí uživateli ukázat informace, ke kterým nemá přístup.

Nestačí tedy jen najít relevantní dokument. Systém musí zohlednit, kdo se ptá a jaká má oprávnění.

Bez správně nastavených oprávnění může RAG omylem vytáhnout citlivé informace z HR, financí, smluv, interních strategií nebo neveřejných obchodních dat.

Bezpečný RAG by měl řešit:

• kdo se ptá,
• k jakým dokumentům má přístup,
• zda se oprávnění kontrolují už při vyhledávání,
• zda odpověď neprozrazuje citlivé informace z nepřístupných zdrojů,
• zda lze zpětně dohledat použité zdroje.

RAG a aktuálnost dat

Jednou z velkých výhod RAG je, že může pracovat s aktuálními daty. Pokud se změní dokumentace, ceník nebo pravidla, není nutné trénovat celý model znovu. Stačí aktualizovat zdroj nebo index.

To ale platí jen tehdy, když je systém dobře nastavený.

Je potřeba řešit:

• jak často se dokumenty aktualizují,
• jak se odstraňují staré verze,
• jak se pozná platný dokument,
• jak se řeší duplicity,
• jak rychle se změna projeví v indexu,
• zda model neodpovídá podle starých podkladů.

RAG nad chaotickou složkou plnou starých dokumentů nebude spolehlivý. Jen rychleji vytáhne chaos, který už ve zdrojích existuje.

RAG a halucinace

RAG se často uvádí jako způsob, jak snížit halucinace u AI. To je pravda jen částečně.

RAG může snížit riziko, že model odpoví úplně bez podkladů. Pokud má model k dispozici relevantní dokumenty, má se čeho držet.

Ale halucinace mohou vzniknout i v RAG systému.

Například když:

• retrieval najde špatný dokument,
• systém najde starou verzi dokumentu,
• model špatně spojí dvě nesouvisející pasáže,
• v podkladech odpověď není, ale model se ji pokusí domyslet,
• prompt neříká, že model má přiznat nejistotu,
• zdroje si navzájem odporují.

RAG tedy není záruka pravdy. Je to způsob, jak odpověď více opřít o zdroje.

Co je špatně navržený RAG

Špatně navržený RAG často vypadá dobře v demu, ale selhává v reálném provozu. Na pár ukázkových otázkách odpovídá přesvědčivě, ale u složitějších dotazů začne vracet nesouvisející, staré nebo nepřesné informace.

Typické problémy:

• v indexu jsou zastaralé dokumenty,
• stejná informace existuje v několika verzích,
• dokumenty jsou rozdělené na špatně velké části,
• nadpis je oddělený od odstavce, ke kterému patří,
• systém neumí pracovat s metadaty,
• retrieval vrací mnoho balastu,
• chybí citace zdrojů,
• neřeší se oprávnění,
• model odpovídá i tam, kde by měl říct, že nemá dost informací.

U RAG tedy nestačí jen připojit dokumenty k modelu. Důležitá je kvalita celého návrhu.

Jak poznat dobrý RAG systém

Dobrý RAG systém by měl odpovídat přesně, dohledatelně a s vědomím vlastních limitů.

Měl by umět:

• najít správný dokument nebo pasáž,
• upřednostnit aktuální a platné zdroje,
• respektovat oprávnění uživatele,
• vrátit zdroje odpovědi,
• neodpovídat bez podkladu, pokud odpověď ve zdrojích není,
• rozlišit fakt ze zdroje a interpretaci,
• nepředávat modelu příliš mnoho nerelevantního textu,
• fungovat na reálných dotazech, ne jen na ukázkových scénářích.

Kvalitní RAG se nepozná podle toho, že odpověď zní hezky. Pozná se podle toho, že odpověď vychází ze správného zdroje.

Jak se RAG testuje

Testování RAG není jen testování jazykového modelu. Je potřeba testovat celý řetězec.

Dává smysl sledovat například:

• zda systém našel správné zdroje,
• zda byly správné zdroje mezi prvními výsledky,
• zda odpověď skutečně vychází z nalezených podkladů,
• zda model nepřidal nepodložené informace,
• zda citace odpovídají použitému textu,
• zda systém správně pracuje s dotazy, na které odpověď ve zdrojích není,
• zda se nezobrazují dokumenty, ke kterým uživatel nemá oprávnění.

U firemního nasazení je dobré vytvořit testovací sadu reálných dotazů. Ne jen dotazy, na kterých systém vypadá dobře.

Kde má RAG největší smysl

RAG má největší hodnotu tam, kde existuje konkrétní znalostní základna a uživatelé se nad ní často ptají.

Typické příklady:

• interní dokumentace firmy,
• produktová databáze,
• návody a manuály,
• technická dokumentace,
• reklamační a obchodní podmínky,
• právní dokumenty,
• zákaznická znalostní báze,
• podklady pro obchodní tým,
• firemní wiki,
• archiv článků nebo odborných textů.

RAG má menší smysl tam, kde nejsou kvalitní zdroje, kde se neřeší přesnost nebo kde je úloha čistě kreativní a nepotřebuje se opírat o konkrétní dokumenty.

RAG a multimodální modely

RAG nemusí pracovat jen s textem. U multimodálních modelů může systém vyhledávat také obrázky, stránky PDF, grafy, screenshoty, audio nebo video.

Příklad:

• uživatel nahraje fotografii produktu,
• systém najde podobné položky v produktové databázi,
• model porovná vizuální vstup s textovými a produktovými daty,
• odpoví, o jaký produkt pravděpodobně jde.

Multimodální RAG je složitější než čistě textový RAG, protože musí pracovat s více typy reprezentací. U dokumentů může kombinovat OCR, layout stránky, textové pasáže, obrázky a metadata.

RAG ve firemním prostředí

Ve firmě není RAG jen technická funkce. Je to práce s informacemi.

Pokud firma nemá pořádek v dokumentech, RAG problém nevyřeší. Spíše ho zviditelní. Systém může rychle najít špatný dokument, starou verzi nebo interně rozporné informace.

Před nasazením RAG proto dává smysl řešit:

• které zdroje mají být zapojené,
• kdo za ně odpovídá,
• jak se pozná platná verze,
• jak se dokumenty aktualizují,
• jak se nastaví oprávnění,
• jak se budou měřit chyby,
• kdo bude kontrolovat rizikové odpovědi,
• co se stane, když systém nenajde odpověď.

RAG není zkratka k pořádku ve znalostech. Je to vrstva, která může dobrý informační základ velmi dobře využít. Špatný informační základ ale nezachrání.

RAG a náklady

RAG může snížit náklady oproti tomu, že by model při každém dotazu dostával celé dokumenty. Zároveň ale přidává vlastní náklady na indexaci, embeddingy, vyhledávání, ukládání dat, aktualizace a provoz infrastruktury.

Náklady ovlivňuje hlavně:

• objem dokumentů,
• četnost aktualizací,
• velikost chunků,
• počet nalezených pasáží vkládaných do promptu,
• cena embedding modelu,
• cena jazykového modelu,
• počet uživatelských dotazů,
• požadavek na citace a auditovatelnost,
• bezpečnostní a oprávnění vrstva.

U produkčních systémů se proto RAG nenavrhuje jen podle kvality odpovědi, ale i podle rychlosti, ceny a provozní udržitelnosti.

RAG a AI agenti

RAG často slouží jako znalostní vrstva pro AI agenty. Agent může mít za úkol nejen odpovědět, ale také provést další krok – například založit ticket, připravit e-mail, vyhledat dokument, porovnat smlouvy nebo navrhnout další postup.

RAG mu dodává podklady, podle kterých se může rozhodovat.

Příklad:

• agent dostane dotaz zákazníka,
• RAG najde relevantní pravidla a předchozí dokumentaci,
• model připraví odpověď,
• agent založí případ do helpdesku,
• člověk výstup zkontroluje.

U agentů je ale ještě důležitější bezpečnost. Pokud agent nejen odpovídá, ale také něco provádí, musí mít jasně nastavené limity.

Časté chyby při návrhu RAG

Nejčastější chybou je myslet si, že RAG vznikne tím, že se „nahrají dokumenty do AI“. To je jen začátek.

Chyby bývají hlavně tyto:

• Nekvalitní zdroje – systém hledá v dokumentech, které jsou staré, duplicitní nebo neúplné.
• Špatné dělení dokumentů – relevantní část se oddělí od nadpisu, definice, tabulky nebo výjimky.
• Chybějící metadata – systém neví, která verze dokumentu je platná.
• Příliš mnoho kontextu – model dostane moc textu a ztrácí se v něm.
• Příliš málo kontextu – model nedostane dost informací a začne hádat.
• Žádné citace – uživatel neví, odkud odpověď pochází.
• Ignorování oprávnění – systém může vytáhnout citlivá data nesprávnému uživateli.
• Chybějící testy – systém se hodnotí jen podle dojmů, ne podle reálných dotazů a správných zdrojů.

Kdy RAG nepomůže

RAG není vhodný na všechno. Nepomůže tam, kde nejsou dobré zdroje. Nepomůže tam, kde je dotaz čistě kreativní a není potřeba opora v dokumentech. Nepomůže ani tam, kde zdroje obsahují rozpory a nikdo neurčil, co má přednost.

RAG také automaticky nevyřeší špatně napsanou dokumentaci. Pokud je interní znalostní báze nepřehledná, neaktuální nebo plná nejasných formulací, model z ní může vytvářet nepřehledné odpovědi.

V takové situaci je potřeba nejprve zlepšit zdroje, ne jen přidat AI vrstvu.

Jak by měl vypadat dobrý RAG prompt

Kvalitní RAG prompt by měl modelu jasně říct, jak má s nalezenými podklady pracovat.

Může obsahovat například instrukce:

• odpovídej pouze podle dodaného kontextu,
• pokud odpověď v kontextu není, napiš, že ji nelze z podkladů ověřit,
• nepřidávej informace, které nejsou ve zdrojích,
• pokud si zdroje odporují, upozorni na rozpor,
• uveď, ze které části dokumentu odpověď vychází,
• odpověď formuluj srozumitelně pro konkrétní cílovou skupinu.

To je důležité, protože model sám od sebe nemusí vždy správně poznat, kdy má mlčet a kdy může odpovědět.

Proč má smysl RAG rozumět i mimo technické obory

RAG není jen pojem pro vývojáře. Je důležitý i pro marketéry, obchodníky, redaktory, produktové manažery, zákaznickou podporu, HR, právní oddělení nebo vedení firmy.

Pomáhá pochopit, proč některé AI nástroje odpovídají obecně a jiné podle konkrétních dokumentů. Vysvětluje také, proč kvalita AI asistenta nezávisí jen na modelu, ale i na tom, jaké zdroje má k dispozici a jak dobře je umí najít.

Kdo chápe RAG, lépe rozumí tomu, proč nestačí říct „napojíme AI na dokumenty“. Důležité je, jak se dokumenty připraví, rozdělí, indexují, vyhledávají, citují a kontrolují.

Kde jsou rizika a neznámé

Rizika a neznámé uvádíme kvůli transparentnosti – ukazují, kde má analýza limity a co může změnit závěry.

• Nekvalitní zdroje – pokud jsou dokumenty zastaralé, duplicitní nebo chybné, RAG bude vycházet ze špatných podkladů. Mitigace: pravidelně čistit znalostní bázi a označovat platné verze.
• Špatný retrieval – systém může najít pasáž, která se dotazu podobá jen povrchně. Mitigace: testovat retrieval na reálných dotazech a kombinovat klíčové, sémantické a metadatové vyhledávání.
• Chybné dělení dokumentů – pokud se dokument rozdělí nevhodně, model může dostat odpověď bez důležitého kontextu. Mitigace: dělit dokumenty podle nadpisů, významových celků a struktury obsahu.
• Staré verze dokumentů – systém může odpovědět podle neplatné verze. Mitigace: používat metadata, datum platnosti a pravidla priority zdrojů.
• Halucinace nad zdroji – model může nalezené informace špatně spojit nebo doplnit. Mitigace: vyžadovat citace, omezit odpověď na dodané podklady a testovat výstupy.
• Porušení oprávnění – RAG může vytáhnout citlivý dokument uživateli, který ho nemá vidět. Mitigace: kontrolovat přístupy už při vyhledávání, ne až při zobrazení odpovědi.
• Příliš mnoho kontextu – model může dostat mnoho nesouvisejících pasáží a odpovědět zmateně. Mitigace: používat reranking a omezit počet pasáží na skutečně relevantní části.
• Konfliktní zdroje – různé dokumenty mohou tvrdit něco jiného. Mitigace: nastavit pravidla, který zdroj má přednost, a nechat model na konflikty upozorňovat.
• Přehnaná důvěra v AI odpověď – uživatel může brát výstup jako pravdu jen proto, že zní jistě. Mitigace: u důležitých rozhodnutí zachovat lidskou kontrolu.
• Provozní náklady – indexace, embeddingy, vyhledávání a generování odpovědí mohou být dražší, než se na začátku zdá. Mitigace: měřit spotřebu tokenů, optimalizovat retrieval a sledovat reálné náklady.

Související pojmy

• Retrieval – vyhledání a načtení relevantních informací, které se modelu předají jako podklad pro odpověď.
• Velký jazykový model (LLM) – model, který zpracovává a generuje text na základě vstupu, kontextu a naučených jazykových vzorů.
• Token – základní jednotka textu nebo vstupu, se kterou jazykový model pracuje.
• Prompt engineering – návrh zadání a instrukcí pro model tak, aby výstup odpovídal požadovanému cíli, formátu a omezením.
• Embedding – číselná reprezentace obsahu, která umožňuje porovnávat významovou podobnost dotazů a dokumentů.
• Vektorová databáze – databáze určená k ukládání embeddingů a vyhledávání podobných vektorů.
• Chunking – rozdělení dlouhého dokumentu na menší části, se kterými se lépe vyhledává a pracuje v kontextu modelu.
• Hybridní vyhledávání – kombinace vyhledávání podle klíčových slov a významové podobnosti.
• Reranking – dodatečné seřazení nalezených výsledků podle relevance před tím, než se předají modelu.
• Grounding – ukotvení odpovědi modelu v konkrétních zdrojích nebo datech.
• Znalostní báze – soubor dokumentů, pravidel, návodů nebo dat, nad kterými může RAG systém vyhledávat.
• Strojové učení – širší oblast AI, ve které se modely učí vzory z dat.
• Deep Learning – podmnožina strojového učení založená na vícevrstvých neuronových sítích.

Odkazy a zdroje

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks – arxiv.org – květen 2020 – původní výzkumný text, který popisuje RAG jako spojení parametrické paměti předtrénovaného modelu a neparametrické paměti v podobě externího indexu dokumentů.
• What is RAG? – ibm.com – duben 2026 – přehledový článek vysvětluje, proč se RAG používá k propojení jazykových modelů s externími znalostními bázemi a jak pomáhá vytvářet relevantnější odpovědi.
• Vertex AI RAG Engine overview – docs.cloud.google.com – duben 2026 – dokumentace ukazuje, jak Google Vertex AI používá RAG Engine jako datový rámec pro aplikace, které rozšiřují LLM o vlastní data a kontextové vyhledávání.
• Retrieval-Augmented Generation in Azure AI Search – learn.microsoft.com – leden 2026 – dokumentace popisuje RAG v prostředí Azure AI Search, práci s indexy, groundingem, proprietárním obsahem a praktickými problémy produkčního nasazení.
• Retrieval augmented generation and indexes – learn.microsoft.com – únor 2026 – článek vysvětluje tříkrokový tok RAG: vyhledání relevantního obsahu, doplnění dotazu o grounding data a vygenerování odpovědi podle dodaného kontextu.
• Retrieval-Augmented Generation – pinecone.io – červen 2025 – praktický průvodce popisuje typickou RAG pipeline, roli externích autoritativních dat, embeddingů, vektorového vyhledávání a předávání nalezených pasáží modelu.