Čo je architektúra RAG? Úplná definícia s podrobnými praktickými príkladmi

Architektúra RAG je súbor komponentov, ktoré ukladajú, vyhľadávajú a odovzdávajú externé informácie LLM; táto príručka rozoberá 10 typov, od základného a hybridného RAG až po agentický RAG a GraphRAG, a ponúka dva podrobné príklady krok za krokom.

Diagram of the types of RAG architecture branching from a central hub: basic, hybrid, adaptive, corrective (CRAG), self-RAG, multimodal, agentic, GraphRAG, HyDE, and branched.

RAG (retrieval augmented generation, teda generovanie rozšírené o vyhľadávanie) je proces, pri ktorom veľké jazykové modely (LLM) využívajú externé informácie na rozšírenie a zlepšenie svojich výstupov. Architektúra RAG je súbor komponentov a prepojení, ktoré RAG umožňujú.

Existuje niekoľko rôznych kategórií RAG a každá z nich funguje na vlastnej jedinečnej architektúre. Architektúra systému RAG v podstate určuje, akým jedinečným spôsobom sa informácie ukladajú, vyhľadávajú a odovzdávajú LLM.

Čo je architektúra RAG?

Architektúra RAG je základná konfigurácia komponentov (a ich príslušných schopností), na ktorej je daný systém RAG postavený. Všetky tieto architektúry vychádzajú zo základnej šablóny, ktorá sa často označuje ako „jednoduchý“ alebo „naivný“ RAG.

Tu je stručný prehľad základnej architektúry RAG:

  • Zdroj informácií: Tu sú uložené externé informácie. Môže ísť o vyhľadávací index, vektorovú databázu reprezentujúcu veľké množstvo informácií alebo úložisko nespracovaných dokumentov.
  • Komponent vyhľadávania: Ide o mechanizmus, ktorým sa zdroj informácií dopytuje. Systém RAG môže napríklad použiť jednoduché vyhľadávanie podľa kľúčových slov na nájdenie relevantných častí textu alebo zložitejšie vektorové dopyty na vyhľadávanie podľa podobnosti.
  • Orchestračný komponent: Táto vrstva je tá časť aplikácie založenej na LLM, ktorá spúšťa pipeline RAG pre prompt používateľa, a to buď v spolupráci s LLM, alebo nezávisle. Zároveň zostavuje získané informácie do rozšíreného promptu.

Komponenty architektúry RAG sú zvyčajne usporiadané do dvoch ciest. Cesta príjmu dát preberá dáta a usporadúva ich do prehľadávateľného zdroja informácií. Vektorové databázy, v ktorých sa veľké množstvo textu konvertuje na prehľadávateľné úložisko vektorových embeddingov, patria k najpoužívanejším riešeniam.

Cesta vyhľadávania preberá prompt používateľa a generuje dopyt, ktorým sa prehľadá zdroj informácií. Orchestrátor potom pridá získané informácie do vstupného kontextu pre LLM. V agentických a hybridných architektúrach RAG môže existovať viacero ciest vyhľadávania.

Typy architektúry RAG

Je zavádzajúce uvažovať o RAG ako o úplne odlišných architektúrach. Väčšina inžinierov volí modulárny prístup a implementuje samostatné komponenty prispôsobené konkrétnym prípadom použitia. Hoci je možné vymedziť približné hranice, treba poznamenať, že medzi jednotlivými modelmi architektúr existuje výrazný prekryv.

1. Základný RAG

Základný RAG, nazývaný aj „naivný“ alebo „jednoduchý“ RAG, je architektonickou šablónou pre ostatné typy RAG.

Základný proces je pomerne jednoduchý: používateľ zadá prompt, orchestrátor (samostatne alebo v spolupráci s LLM) určí, či sú potrebné externé informácie, a podľa toho sformuluje a odošle vyhľadávací dopyt.

Externým zdrojom informácií je zvyčajne vektorová databáza, ale môže ním byť aj databáza SQL, webové API, znalostný graf alebo dokonca úložisko „nespracovaných“ dokumentov. Tieto dodatočné informácie sa potom pridajú do vstupného kontextu LLM.

Okrem dopytov SQL a API existujú dva základné typy metód vyhľadávania:

  • Lexikálne vyhľadávanie (vyhľadávanie podľa kľúčových slov): Ide o jednoduchú formu RAG, pri ktorej sa z dopytu používateľa extrahujú kľúčové slová a porovnávajú sa s pasážami textu, ktoré tieto kľúčové slová obsahujú. V moderných pipelinoch na to môže orchestrátor použiť takzvaný riedky vektorový dopyt (sparse vector query), ktorý nezachytáva význam.
  • Vyhľadávanie pomocou hustých vektorov (sémantické vyhľadávanie): Husté vektorové embeddingy zachytávajú význam. Orchestrátor môže dopytovať databázu hustých vektorov tak, aby sa zachytil význam promptu používateľa aj zdrojových informácií.

Dôležitou súčasťou architektúry RAG je aj využívanie pamäte. Ide o to, ako LLM využíva kontext z predchádzajúcich chatov na zostavenie vyhľadávacieho dopytu, čím ho ukotví v širšom kontexte diskusie (alebo viacerých diskusií). Konverzačný RAG je štandardom pre väčšinu chatbotov, hoci niektoré prípady použitia, napríklad odpovede na tikety podpory, môžu využívať RAG s jednou otázkou.

2. Hybridný RAG

Hybridný RAG kombinuje dva rôzne typy vyhľadávania, zvyčajne vyhľadávanie podľa kľúčových slov a sémantické vyhľadávanie. Vyhľadávanie podľa kľúčových slov nájde zhodné výrazy a vektorové vyhľadávanie nájde pasáže s príbuzným významom.

Môžu sa použiť aj iné formy vyhľadávania, napríklad prechádzanie znalostného grafu alebo dopyty do databázy SQL. Proces často riadi smerovacia logika, a to buď v podobe naprogramovaných pravidiel, alebo klasifikácie otázky modelom (hoci viacero pipelinov môže bežať aj súčasne).

Orchestrátor zlúči výsledky a pred ich odovzdaním LLM ich môže znovu zoradiť. Toto opätovné zoradenie (reranking) je proces priraďovania skóre relevantnosti získaným častiam textu, aby LLM uprednostnil najrelevantnejšie informácie.

3. Adaptívny RAG

Pri adaptívnom RAG smerovací komponent vyberie stratégiu vyhľadávania podľa požiadaviek promptu používateľa a orchestrátor potom vykoná zvolený pracovný postup.

V pôvodnom frameworku (Adaptive-RAG) slúžil menší model ako klasifikátor a vyberal medzi žiadnym vyhľadávaním, jednokrokovým vyhľadávaním alebo viackrokovým vyhľadávaním. Niektoré architektúry dnes namiesto toho používajú generatívne modely alebo heuristiky založené na pravidlách.

Ide o obľúbenú architektúru, pretože prideľuje výpočtový výkon podľa zložitosti a požiadaviek promptu, čím pri jednoduchších promptoch obmedzuje zbytočné kroky vyhľadávania. Bežne sa používa v asistentoch, ktoré pracujú s viacerými typmi otázok.

4. Korektívny RAG (CRAG)

Korektívny RAG vyhodnocuje získané informácie predtým, ako ich pridá do vstupného kontextu LLM. Hodnotiteľ vyhľadávania posudzuje, či sú získané informácie relevantné a užitočné. Jedinečným architektonickým prvkom je explicitná fáza vyhodnotenia a opravy pred generovaním odpovede.

Ak sa zistí, že informácie sú neúplné alebo sa na prompt nevzťahujú, spustia sa ďalšie požiadavky. Môžu zahŕňať iné metódy vyhľadávania, než aké sa použili pri pôvodnej požiadavke, napríklad vyhľadávanie na webe alebo prechádzanie znalostného grafu.

Korektívny RAG je bežný v oblastiach, kde záleží na presnosti, napríklad v medicíne a práve. Vyžaduje však ďalší zdroj informácií, ktorý dokáže doplniť pôvodne získané pasáže.

5. Self-RAG

Pri self-RAG môže model iniciovať požiadavky po prijatí počiatočného vstupného kontextu. Vygenerované odpovede sa pomocou reflexných tokenov vyhodnocujú voči získaným dôkazom a ďalšie požiadavky sa podľa potreby odosielajú cez orchestrátor. LLM však môže naopak rozhodnúť aj o tom, že vyhľadávanie vôbec nie je potrebné.

Od korektívneho RAG sa líši tým, že LLM posudzuje vlastné výstupy, určuje, či je vyhľadávanie potrebné a či je získaný text užitočný, a monitoruje vlastné odpovede, ktoré podľa potreby upravuje. Korektívny RAG naopak vyhodnocuje kvalitu získaných informácií ešte pred generovaním.

Táto architektúra je obzvlášť užitočná pri zložitých promptoch v štýle hĺbkového výskumu. Keďže do generovania odpovedí začleňuje posudzovanie relevantnosti (získaných informácií), je vhodnou voľbou pre prompty, ktoré si vyžadujú odpovede podložené dôkazmi.

6. Agentický RAG

Agentický RAG označuje akúkoľvek formu RAG, ktorá sa vykonáva v kontexte agentickej platformy. Model využíva svoje schopnosti uvažovania na určenie potrebného typu informácií a vyberá z dostupných možností vyhľadávania.

Vyhľadávanie sa môže spustiť viackrát podľa potreby a model má možnosť priradiť zložitejším dopytom agentov. LLM by napríklad mohol vyžiadať vyhľadanie v databáze na identifikáciu dodávateľa, spustiť vyhľadávanie dokumentov na nájdenie relevantných zmlúv a nakoniec vyhľadávaním na webe overiť kontaktné údaje z verejných zdrojov.

Agentický RAG je hlavnou implementáciou architektúry v bežne používaných chatbotoch, ako sú Perplexity, ChatGPT, Claude a ďalšie. Keďže tieto platformy poskytujú základnému modelu prístup k viacerým nástrojom a pipelinom RAG, model si môže vybrať, ktorá forma vyhľadávania sa na daný prompt hodí najlepšie.

7. Multimodálny RAG

Multimodálny RAG získava kontext z rôznych typov médií. Je to dôležitá forma RAG, pretože sprístupňuje LLM informácie, ako sú grafy a zvukové nahrávky, ktoré by inak boli nedostupné.

Základná architektúra je rovnaká ako v akomkoľvek inom systéme. Indexovací pipeline môže napríklad pripraviť obrázky na vyhľadávanie tak, že ich prevedie na priame embeddingy. Agentický systém RAG by potom mohol tieto obrázky získať spolu so sémanticky relevantným textom a odovzdať ich vizuálno-jazykovému modelu na spoločné spracovanie.

8. GraphRAG

GraphRAG využíva popri vektorovom vyhľadávaní znalostné grafy na získavanie informácií o entitách. Orchestrátor zvyčajne nájde relevantné východiskové entity, nazývané aj uzly, pomocou extrakcie kľúčových slov alebo niekedy pomocou predbežného vektorového vyhľadávania. Grafový vyhľadávač (graph retriever) prechádza znalostný graf a vytvára širší kontext.

Napríklad v reakcii na požiadavku o podrobný rozpis produktovej kategórie môže LLM spustiť vektorové vyhľadávanie na identifikáciu konkrétnych entít (produktov). Orchestrátor potom spustí vyhľadávanie v znalostnom grafe na nájdenie súvisiacich entít, ako sú dodávatelia, predajné miesta, recenzie a podobne.

9. Vetvený RAG

Zatiaľ čo hybridná architektúra RAG dokáže používať rôzne metódy vyhľadávania, vetvený RAG označuje proces súbežného spúšťania viacerých dopytov, nazývaných vetvy. Každá vetva môže dopytovať samostatný zdroj informácií, alebo môžu vetvy súčasne dopytovať ten istý zdroj s rôznymi dopytmi či filtrami. Agentická architektúra RAG často využíva vetvený RAG.

10. HyDE (Hypothetical Document Embeddings)

HyDE je inovatívna forma RAG, pri ktorej LLM vytvorí hypotetický textový dokument znázorňujúci, ako by mohla vyzerať optimálna odpoveď. Tento „hypotetický dokument“ sa potom použije na vytvorenie dopytu na presnejšie vyhľadávanie. Hoci relevantné znalosti nie sú zastúpené v parametroch LLM, myšlienka spočíva v tom, že pasáž podobná odpovedi sa môže s relevantnými dokumentmi zhodovať lepšie než krátka otázka alebo nejednoznačný prompt.

Príklad jednoduchej architektúry RAG: vektorová databáza

Základný RAG slúži ako základ pre zložitejšie typy architektúry. V prípade jednoduchého systému RAG, ktorý používa vektorovú databázu, sa zdrojová dokumentácia rozdelí na menšie časti (chunky) a prevedie sa na husté embeddingy. Keď používateľ zadá prompt, orchestrátor vygeneruje dopyt, zakóduje ho a prehľadá databázu, aby našiel relevantné pasáže.

Tu je podrobný rozpis procesu krok za krokom:

  1. Veľké množstvo textu sa prevedie na vektory pomocou automatizovaného pipelinu na príjem dát a embeddingového modelu, ako je BERT.
  2. Databázová aplikácia vektory usporiada, indexuje a uloží na rýchle vyhľadávanie.
  3. Používateľ zadá prompt do chatbota (napríklad Perplexity).
  4. Orchestrátor aplikácie zakóduje prompt (pomocou embeddingového modelu), aby z vektorovej databázy získal relevantné informácie.
  5. Vektorová databáza vráti relevantné časti a orchestrátor ich pridá do vstupného kontextu („veľkého promptu“), ktorý odovzdá LLM.
  6. LLM na základe dodatočného kontextu vygeneruje odpoveď pomocou svojich interných znalostí (uložených v parametrických váhach).

Príklad pokročilej architektúry RAG: agentický RAG

Agentický RAG označuje základnú architektúru systémov RAG v rámci agentickej platformy. Toky agentického RAG bývajú zložité, pretože agenti AI môžu v závislosti od povahy promptu volať rôzne nástroje a pipeliny a v prípade potreby nasadiť viacerých agentov.

Tu je praktický príklad procesu:

  1. Používateľ zadá zložitú otázku, ktorá si vyžaduje hĺbkový výskum témy. V tomto príklade povedzme, že prompt znie: „Poskytni prognózu ziskov spoločnosti na nasledujúcich šesť mesiacov vzhľadom na významné geopolitické dianie.“
  2. LLM vyhodnotí, že bude potrebná kombinácia dopytov RAG naprieč rôznymi typmi obsahu.
  3. Nasadia sa traja rôzni agenti na (a) vektorové vyhľadávanie, (b) ukotvenie vo webových zdrojoch a (c) vyhľadávanie obrázkov (multimodálne).
  4. Agenti prostredníctvom orchestrátora a dostupných vyhľadávacích nástrojov hľadajú relevantné informácie, napríklad spravodajské články a interné finančné údaje.
  5. LLM porovná získané výsledky s výskumnou otázkou každého agenta a zoradí ich podľa relevantnosti.
  6. LLM vyhodnotí informácie a tam, kde chýbajú, spustí ďalšie vyhľadávania prostredníctvom jednotlivých agentov.
  7. Keď sa získa dostatok informácií, LLM vygeneruje scenáre prognóz na základe existujúcich finančných údajov (získaných z internej dokumentácie) a zavolá nástroj kalkulačky, aby pre každý scenár vypočítal projekciu ziskov.
  8. LLM vygeneruje finálnu odpoveď na základe získaných informácií a výpočtov a podľa potreby uvedie zdroje.

Čo čaká RAG v budúcnosti?

Súčasné inovácie sa sústreďujú na zvyšovanie hĺbky a rýchlosti existujúcich architektúr RAG, zlepšovanie presnosti multimediálneho vyhľadávania a budovanie systémov, ktoré dokážu pracovať s informáciami v reálnom čase.

Tu sú tri trendy, ktoré v súčasnosti formujú smerovanie výskumu:

  • Hĺbkový výskum naprieč viacerými zdrojmi: Ide o architektúru RAG, ktorá dokáže plánovať vyhľadávania, spúšťať viacero vetiev naprieč rôznorodými zdrojmi, vyhodnocovať získané dôkazy a samostatne optimalizovať vygenerované odpovede. Agentický RAG schopný vykonávať všetky tieto úlohy je čoraz rýchlejší a nákladovo efektívnejší.
  • Multimodálne aplikácie: Vyhľadávacie pipeliny čoraz lepšie pracujú s obrázkami a videom. Čoraz presnejšie dokážu v zložitých multimodálnych dátach, napríklad v dlhých videách a pokročilých diagramoch, nájsť konkrétne typy informácií.
  • Ukotvenie odpovedí v neustále sa meniacich informáciách: Aplikácie založené na LLM môžu pri poskytovaní vstupného kontextu čerpať zo živých zdrojov informácií (napríklad z videostreamov a senzorov). Systémy dokážu na interpretáciu týchto dát vytvárať aj mnohovrstvové siete informácií, napríklad pomocou GraphRAG.

RAG je základom fungovania aplikácií založených na LLM. Umožňuje širokému spektru používateľov, od bežných spotrebiteľov až po podniky pôsobiace v špecializovaných oblastiach, prekonať problémy súvisiace s halucináciami, neúplnými trénovacími dátami a nedostatočným prístupom k špecializovaným interným znalostiam.

Preto systémy RAG a ich základná architektúra predstavujú jednu z najrýchlejšie sa rozvíjajúcich a najzaujímavejších oblastí výskumu AI.