Co je architektura RAG? Úplná definice s podrobnými praktickými příklady

RAG (retrieval-augmented generation, tedy generování rozšířené o vyhledávání) je proces, při kterém LLM využívají externí informace k rozšíření a zlepšení svých výstupů. Architektura RAG je soubor komponent a propojení, které RAG umožňují.

Existuje několik různých kategorií RAG a každá z nich běží na vlastní jedinečné architektuře. Architektura systému RAG v podstatě určuje, jakým konkrétním způsobem se informace ukládají, vyhledávají a předávají LLM.

Co je architektura RAG?

Architektura RAG je základní konfigurace komponent (a jejich souvisejících schopností), na které daný systém RAG funguje. Všechny tyto architektury vycházejí ze základní šablony, často označované jako „jednoduchý“ nebo „naivní“ RAG.

Zde je obecný přehled základní architektury RAG:

• Zdroj informací: Zde jsou uložené externí informace. Může jít o vyhledávací index, vektorovou databázi reprezentující velké množství informací nebo nezpracované úložiště dokumentů.
• Vyhledávací komponenta: Jde o mechanismus, pomocí kterého se posílají dotazy do zdroje informací. Systém RAG může například použít jednoduché vyhledávání podle klíčových slov k nalezení relevantních úseků textu nebo složitější vektorové dotazy k vyhledávání podle podobnosti.
• Orchestrační komponenta: Tato vrstva je částí aplikace založené na LLM, která spouští pipeline RAG pro prompt uživatele, a to buď ve spolupráci s LLM, nebo samostatně. Získané informace také sestavuje do rozšířeného promptu.

Komponenty architektury RAG jsou obvykle uspořádány do dvou cest. Cesta příjmu dat vezme data a uspořádá je do prohledávatelného zdroje informací. Jednou z nejrozšířenějších aplikací jsou vektorové databáze, v nichž se velké množství textu převádí na prohledávatelné úložiště vektorových embeddingů.

Vyhledávací cesta přijme prompt uživatele a vygeneruje dotaz, pomocí kterého se prohledá zdroj informací. Orchestrátor pak získané informace přidá do vstupního kontextu pro LLM. U agentních a hybridních architektur RAG může existovat více vyhledávacích cest.

Typy architektury RAG

Představa RAG jako souboru zcela oddělených architektur je zavádějící. Většina inženýrů volí modulární přístup a implementuje samostatné komponenty pro konkrétní případy použití. Přestože lze vést přibližné hranice, je důležité si uvědomit, že se jednotlivé architektonické modely výrazně překrývají.

1. Základní RAG

Základní RAG, nazývaný také „naivní“ nebo „jednoduchý“ RAG, je architektonickou šablonou pro ostatní typy RAG.

Základní proces je poměrně přímočarý: uživatel zadá prompt, orchestrátor (samostatně nebo ve spolupráci s LLM) určí, zda jsou potřeba externí informace, a podle toho sestaví a odešle vyhledávací dotaz.

Externím zdrojem informací bývá nejčastěji vektorová databáze, ale může jím být také databáze SQL, webové API, znalostní graf, nebo dokonce „nezpracované“ úložiště dokumentů. Tyto doplňující informace se pak přidají do vstupního kontextu LLM.

Kromě dotazů SQL a rozhraní API existují dva hlavní typy metod vyhledávání:

• Lexikální vyhledávání (vyhledávání podle klíčových slov): Jde o jednoduchou formu RAG, při níž se z uživatelského dotazu extrahují klíčová slova a porovnávají se s pasážemi textu, které tato klíčová slova obsahují. V moderních pipelinách k tomu orchestrátor může použít takzvaný řídký vektorový dotaz (sparse vector query), který nezachycuje význam.
• Husté vektorové vyhledávání (sémantické vyhledávání): Husté vektorové embeddingy zachycují význam. Orchestrátor může posílat dotazy do husté vektorové databáze tak, aby se zachytil význam jak uživatelského promptu, tak zdrojových informací.

Důležitou součástí architektury RAG je také využití paměti. Jde o to, jak LLM využívá kontext z předchozích chatů k sestavení vyhledávacího dotazu, a tím ho ukotvuje v širším kontextu diskuze (nebo více diskuzí). Konverzační RAG je standardem u většiny chatbotů, i když některé případy použití, například odpovědi na tikety podpory, mohou využívat RAG pro jednotlivé dotazy.

2. Hybridní RAG

Hybridní RAG kombinuje dva různé typy vyhledávání, obvykle vyhledávání podle klíčových slov a sémantické vyhledávání. Vyhledávání podle klíčových slov najde odpovídající výrazy a vektorové vyhledávání najde pasáže s příbuzným významem.

Mohou se použít i jiné formy vyhledávání, například procházení znalostního grafu nebo dotazy do databáze SQL. Proces se často řídí logikou směrování, a to buď v podobě naprogramovaných pravidel, nebo klasifikace otázky modelem (může však současně běžet také více pipeline).

Orchestrátor výsledky sloučí a před předáním LLM je může znovu seřadit. Opětovné seřazení (reranking) je proces přiřazování skóre relevance získaným částem textu, aby LLM upřednostnil nejpoužitelnější informace.

3. Adaptivní RAG

U adaptivního RAG vybírá směrovací komponenta strategii vyhledávání podle požadavků uživatelského promptu a orchestrátor pak zvolený pracovní postup provede.

V původním frameworku (Adaptive-RAG) fungoval menší model jako klasifikátor a vybíral mezi žádným vyhledáváním, jednokrokovým vyhledáváním a vícekrokovým vyhledáváním. Některé architektury dnes místo toho používají generativní modely nebo heuristiky založené na pravidlech.

Jde o oblíbenou architekturu, protože přiděluje výpočetní výkon podle složitosti a požadavků promptu, čímž u jednodušších promptů omezuje zbytečné kroky vyhledávání. Běžně se používá v asistentech, kteří pracují s více typy otázek.

4. Korektivní RAG (CRAG)

Korektivní RAG vyhodnocuje získané informace dříve, než je přidá do vstupního kontextu LLM. Vyhodnocovač vyhledávání posuzuje, zda jsou získané informace relevantní a užitečné. Jedinečným architektonickým prvkem je explicitní fáze vyhodnocení a opravy před generováním odpovědi.

Pokud se zjistí, že jsou informace neúplné nebo se k promptu nevztahují, spustí se další požadavky. Ty mohou využívat jiné metody vyhledávání než původní požadavek, například webové vyhledávání nebo procházení znalostního grafu.

Korektivní RAG je běžný v oborech, kde záleží na přesnosti, jako je medicína a právo. Vyžaduje však další zdroj informací, který dokáže doplnit původně získané pasáže.

5. Self-RAG

U self-RAG může model iniciovat požadavky po obdržení počátečního vstupního kontextu. Vygenerované odpovědi se pomocí reflexních tokenů vyhodnocují vůči získaným důkazům a další požadavky se podle potřeby odesílají přes orchestrátor. LLM může naopak také usoudit, že vyhledávání není vůbec potřeba.

Od korektivního RAG se liší tím, že LLM posuzuje své vlastní výstupy, určuje, zda je vyhledávání potřeba a zda je získaný text užitečný, a sleduje své vlastní odpovědi, které podle potřeby upravuje. Korektivní RAG naopak vyhodnocuje kvalitu získaných informací ještě před generováním.

Tato architektura je užitečná zejména pro složité prompty ve stylu hloubkového výzkumu. Protože do generování odpovědí začleňuje posouzení relevance (získaných informací), je dobrou volbou pro prompty, které vyžadují odpovědi podložené důkazy.

6. Agentní RAG

Agentní RAG označuje jakoukoli formu RAG, která se provádí v kontextu agentní platformy. Model využívá své schopnosti uvažování k určení, jaký typ informací je potřeba, a vybírá z dostupných možností vyhledávání.

Vyhledávání lze podle potřeby spustit vícekrát a model má možnost přidělit složitější dotazy agentům. LLM může například požádat o vyhledání v databázi k identifikaci dodavatele, spustit vyhledávání v dokumentech k nalezení relevantních smluv a nakonec provést webové vyhledávání, aby ověřil kontaktní údaje z veřejných zdrojů.

Agentní RAG je hlavní architekturou implementovanou v běžných chatbotech, jako jsou Perplexity, ChatGPT, Claude a další. Protože tyto platformy poskytují hlavnímu modelu přístup k více nástrojům a pipeline RAG, může model zvolit, která forma vyhledávání se pro daný prompt hodí nejlépe.

7. Multimodální RAG

Multimodální RAG získává kontext z různých typů médií. Jde o důležitou formu RAG, protože zpřístupňuje LLM informace, jako jsou grafy a zvukové nahrávky, které by jinak byly nedostupné.

Základní architektura je stejná jako v jakémkoli jiném systému. Indexovací pipeline může například připravit obrázky pro vyhledávání tím, že je převede na přímé embeddingy. Agentní systém RAG by pak mohl tyto obrázky získat společně se sémanticky relevantním textem a předat je vizuálně-jazykovému modelu ke kombinovanému zpracování.

8. GraphRAG

GraphRAG používá vedle vektorového vyhledávání znalostní grafy k získávání informací o entitách. Orchestrátor obvykle najde relevantní výchozí entity, nazývané také uzly, pomocí extrakce klíčových slov nebo někdy předběžného vektorového vyhledávání. Grafový vyhledávač (graph retriever) pak prochází znalostní graf a sestavuje širší kontext.

Například v reakci na požadavek na podrobný rozbor určité kategorie produktů může LLM spustit vektorové vyhledávání k identifikaci konkrétních entit (produktů). Orchestrátor pak spustí vyhledávání ve znalostním grafu, aby našel související entity, jako jsou dodavatelé, prodejní místa, recenze a podobně.

9. Větvený RAG

Zatímco hybridní architektura RAG dokáže používat různé metody vyhledávání, větvený RAG označuje proces souběžného spouštění více dotazů, nazývaných větve. Každá větev může posílat dotazy do samostatného zdroje informací, nebo mohou větve prohledávat stejný zdroj souběžně s různými dotazy či filtry. Architektura agentního RAG často využívá větvený RAG.

10. HyDE (Hypothetical Document Embeddings – embeddingy hypotetických dokumentů)

HyDE je inovativní forma RAG, při níž LLM vytvoří hypotetický textový dokument, který ukazuje, jak by mohla vypadat optimální odpověď. Tento „hypotetický dokument“ se pak použije k vytvoření dotazu pro přesnější vyhledávání. I když relevantní znalosti nejsou v parametrech LLM zastoupeny, vychází se z předpokladu, že pasáž podobná odpovědi může relevantním dokumentům odpovídat lépe než krátká otázka nebo nejednoznačný prompt.

Příklad jednoduché architektury RAG: vektorová databáze

Základní RAG tvoří základ pro složitější typy architektury. V případě jednoduchého systému RAG, který využívá vektorovou databázi, se zdrojová dokumentace rozdělí na menší části (chunky) a převede na husté embeddingy. Když uživatel zadá prompt, orchestrátor vygeneruje dotaz, zakóduje ho a prohledá databázi, aby našel relevantní pasáže.

Zde je rozpis procesu krok za krokem:

1. Velké množství textu se převede na vektory pomocí automatizované pipeline pro příjem dat a embeddingového modelu, jako je BERT.
2. Databázová aplikace vektory uspořádá, indexuje a uloží pro rychlé vyhledávání.
3. Uživatel zadá prompt do chatbota (například Perplexity).
4. Orchestrátor aplikace zakóduje prompt (pomocí embeddingového modelu), aby z vektorové databáze získal relevantní informace.
5. Vektorová databáze vrátí relevantní části a orchestrátor je přidá do vstupního kontextu („velkého promptu“), který předá LLM.
6. LLM využije doplňující kontext k vygenerování odpovědi s využitím svých interních znalostí (uložených v jeho parametrických vahách).

Zvětšit

Příklad pokročilé architektury RAG: agentní RAG

Agentní RAG označuje základní architekturu systémů RAG v rámci agentní platformy. Toky agentního RAG bývají složité, protože AI agenti mohou v závislosti na povaze promptu volat různé nástroje a pipeline a v případě potřeby nasadit více agentů.

Zde je praktický příklad tohoto procesu:

1. Uživatel zadá složitou otázku, která vyžaduje hloubkový výzkum tématu. Pro tento příklad řekněme, že prompt zní: „Vytvoř prognózu zisku společnosti na příštích šest měsíců s ohledem na významné geopolitické dění.“
2. LLM usoudí, že bude potřeba kombinace dotazů RAG napříč různými typy obsahu.
3. Nasadí se tři různí agenti pro (a) vektorové vyhledávání, (b) ukotvení ve webových zdrojích a (c) vyhledávání obrázků (multimodální).
4. Agenti prostřednictvím orchestrátoru vyhledávají relevantní informace, například zpravodajské články a interní finanční data, pomocí dostupných vyhledávacích nástrojů.
5. LLM porovná získané výsledky s výzkumnou otázkou každého agenta a seřadí je podle relevance.
6. LLM vyhodnotí informace a tam, kde chybějí, spustí prostřednictvím jednotlivých agentů další vyhledávání.
7. Jakmile se získá dostatek informací, LLM vygeneruje prognózy scénářů na základě existujících finančních údajů (získaných z interní dokumentace) a zavolá nástroj kalkulačky, aby pro každý z nich předpověděl zisk.
8. LLM vygeneruje konečnou odpověď na základě získaných informací a výpočtů a podle potřeby uvede zdroje.

Zvětšit

Co čeká RAG dál?

Aktuální inovace se zaměřují na prohloubení a zrychlení stávajících architektur RAG, zlepšení přesnosti multimediálního vyhledávání a budování systémů navržených pro práci s nejaktuálnějšími informacemi.

Zde jsou tři trendy, které v současnosti určují směr výzkumu:

• Hloubkový výzkum napříč více zdroji: Jde o architekturu RAG, která dokáže plánovat vyhledávání, spouštět více větví napříč nesourodými zdroji, vyhodnocovat získané důkazy a samostatně optimalizovat vygenerované odpovědi. Agentní RAG schopný provádět všechny tyto úlohy je stále rychlejší a nákladově efektivnější.
• Multimodální aplikace: Vyhledávací pipeline si s obrázky a videem poradí stále lépe. Dokážou čím dál přesněji určit konkrétní typy informací ve složitých multimodálních datech, jako jsou dlouhá videa a pokročilé diagramy.
• Ukotvení odpovědí v neustále se měnících informacích: Aplikace založené na LLM mohou jako vstupní kontext využívat živé zdroje informací (například videopřenosy a senzory). Systémy mohou také k interpretaci těchto dat vytvářet mnohovrstevnaté sítě informací, například pomocí GraphRAG.

RAG je základem fungování aplikací založených na LLM. Umožňuje celé řadě různých uživatelů, od běžných spotřebitelů po podniky působící ve specializovaných oborech, překonat problémy spojené s halucinacemi, neúplnými trénovacími daty a nedostatečným přístupem ke specializovaným interním znalostem.

Proto systémy RAG a jejich základní architektura představují jednu z nejrychleji se vyvíjejících a nejzajímavějších oblastí výzkumu AI.