Mi az a RAG-architektúra? Teljes körű definíció részletes gyakorlati példákkal

A RAG (retrieval augmented generation, azaz visszakereséssel kiegészített generálás) olyan folyamat, amelyben az LLM-ek külső információkat használnak fel a kimeneteik bővítésére és javítására. A RAG architektúrája azoknak a komponenseknek és kapcsolatoknak az összessége, amelyek lehetővé teszik a RAG működését.

A RAG-nek több különböző kategóriája létezik, és mindegyik saját, egyedi architektúrára épül. Lényegében egy RAG-rendszer architektúrája határozza meg, hogy az információkat milyen egyedi módon tárolja, keresi vissza és juttatja el az LLM-hez.

Mi az a RAG-architektúra?

A RAG-architektúra a komponensek (és a hozzájuk tartozó képességek) azon alapvető konfigurációja, amely egy adott RAG-rendszert működtet. Mindezek az architektúrák egy alapsablonra épülnek, amelyet gyakran „egyszerű” vagy „naiv” RAG-nek neveznek.

Íme az alapvető RAG-architektúra átfogó áttekintése:

• Információforrás: Itt tárolódnak a külső információk. Ez lehet egy keresési index, egy nagy mennyiségű információt reprezentáló vektoradatbázis vagy egy nyers dokumentumtár.
• Visszakeresési komponens: Ez az a mechanizmus, amellyel az információforrás lekérdezése történik. Egy RAG-rendszer például egyszerű kulcsszavas keresést használhat a releváns szövegrészletek megtalálásához, vagy összetettebb vektoros lekérdezéseket a hasonlósági kereséshez.
• Orkesztrációs komponens: Ez a réteg az LLM-alapú alkalmazásnak az a része, amely egy felhasználói prompt esetén elindítja a RAG-folyamatot, akár az LLM-mel együttműködve, akár attól függetlenül. Emellett a visszakeresett információkat egy kibővített promptba foglalja.

A RAG-architektúra komponensei általában két útvonalba szerveződnek. A betöltési útvonal az adatokat kereshető információforrássá rendezi. Az egyik legszélesebb körben használt megoldás a vektoradatbázis, amelyben nagy mennyiségű szöveget vektorbeágyazások kereshető tárává alakítanak.

A visszakeresési útvonal a felhasználó promptjából lekérdezést generál, amellyel az információforrásban keres. Ezután az orkesztrátor hozzáadja a visszakeresett információkat az LLM bemeneti kontextusához. Az ügynöki és hibrid RAG-architektúrákban több visszakeresési útvonal is lehet.

A RAG-architektúra típusai

Félrevezető a RAG-et teljesen különálló architektúrákként elképzelni. A legtöbb mérnök moduláris megközelítést alkalmaz, és az adott felhasználási esetekhez illeszkedő, különálló komponenseket valósít meg. Bár laza határokat meg lehet húzni, fontos megjegyezni, hogy az architektúramodellek között jelentős az átfedés.

1. Alapszintű RAG

Az alapszintű RAG, más néven „naiv” vagy „egyszerű” RAG, a többi RAG-típus architekturális sablonja.

A mögöttes folyamat viszonylag egyszerű: a felhasználó megad egy promptot, az orkesztrátor (önállóan vagy az LLM-mel együttműködve) eldönti, hogy szükség van-e külső információra, majd ennek megfelelően megfogalmaz és elküld egy visszakeresési lekérdezést.

A külső információforrás általában vektoradatbázis, de lehet SQL-adatbázis, webes API, tudásgráf vagy akár „nyers” dokumentumtár is. Ezek a kiegészítő információk ezután bekerülnek az LLM bemeneti kontextusába.

Az SQL-lekérdezéseken és az API-kon kívül a visszakeresési módszereknek két fő típusa van:

• Lexikális keresés (kulcsszavas keresés): Ez a RAG egyszerű formája, amelyben a felhasználói lekérdezésből kulcsszavakat nyernek ki, és ezeket az adott kulcsszavakat tartalmazó szövegrészekkel vetik össze. A modern folyamatokban az orkesztrátor ehhez úgynevezett ritka vektoros lekérdezést végezhet, amely nem ragadja meg a jelentést.
• Sűrű vektoros keresés (szemantikus keresés): A sűrű vektorbeágyazások megragadják a jelentést. Az orkesztrátor úgy kérdezhet le egy sűrű vektoros adatbázist, hogy a felhasználói prompt és a forrásinformációk jelentése egyaránt megragadható legyen.

A memória használata szintén fontos része a RAG-architektúrának. Ez arra utal, hogy az LLM hogyan használja fel a korábbi csevegések kontextusát egy visszakeresési lekérdezés összeállításához, így azt a beszélgetés (vagy több beszélgetés) tágabb kontextusába ágyazza. A legtöbb chatbot esetében a beszélgetéses RAG a megszokott, bár egyes felhasználási esetekben, például az ügyfélszolgálati jegyekre adott válaszoknál, egykérdéses RAG is használható.

2. Hibrid RAG

A hibrid RAG két különböző visszakeresési típust kombinál, általában a kulcsszavas és a szemantikus visszakeresést. A kulcsszavas keresés az egyező kifejezéseket, a vektoralapú keresés pedig a rokon jelentésű szövegrészeket találja meg.

Más visszakeresési formák, például a tudásgráf bejárása vagy SQL-adatbázis-lekérdezések is használhatók. A folyamatot gyakran útválasztási logika irányítja, akár programozott szabályok, akár a kérdés modell általi osztályozása formájában (bár több folyamat egyidejűleg is futhat).

Az orkesztrátor egyesíti az eredményeket, és az LLM-nek való továbbítás előtt újrarangsorolhatja azokat. Az újrarangsorolás során a visszakeresett szövegrészletek relevanciapontszámot kapnak, így az LLM a leginkább alkalmazható információkat helyezi előtérbe.

3. Adaptív RAG

Az adaptív RAG-ben egy útválasztó komponens a felhasználói prompt követelményei alapján választ visszakeresési stratégiát, majd az orkesztrátor végrehajtja a kiválasztott munkafolyamatot.

Az eredeti keretrendszerben (Adaptive-RAG) egy kisebb modell osztályozóként működött, és a visszakeresés mellőzése, az egylépéses visszakeresés vagy a többlépéses visszakeresés közül választott. Egyes architektúrák ma már ehelyett generatív modelleket vagy szabályalapú heurisztikákat használnak.

Azért népszerű architektúra, mert a feldolgozási kapacitást a prompt összetettsége és követelményei alapján osztja el, így egyszerűbb promptok esetén csökkenti a szükségtelen visszakeresési lépéseket. Gyakori a többféle kérdéstípust kezelő asszisztensekben.

4. Korrekciós RAG (CRAG)

A korrekciós RAG kiértékeli a visszakeresett információkat, mielőtt hozzáadná őket az LLM bemeneti kontextusához. Egy visszakeresés-értékelő megvizsgálja, hogy a visszakeresett információk relevánsak és hasznosak-e. Sajátos architekturális jellemzője a válaszgenerálás előtti, explicit értékelési és javítási szakasz.

Ha az információk hiányosnak bizonyulnak, vagy nem vonatkoznak a promptra, további kérések indulnak. Ezek az eredeti kéréshez használtaktól eltérő visszakeresési módszereket is alkalmazhatnak, például webes keresést vagy tudásgráf-bejárást.

A korrekciós RAG gyakori azokon a területeken, ahol fontos a pontosság, például az orvostudományban és a jogban. Ugyanakkor szükség van hozzá egy további információforrásra, amely kiegészítheti az eredetileg visszakeresett szövegrészeket.

5. Self-RAG

A Self-RAG-ben a modell a kezdeti bemeneti kontextus megkapása után is kezdeményezhet kéréseket. A generált válaszokat reflexiós tokenek segítségével vetik össze a visszakeresett bizonyítékokkal, és szükség esetén az orkesztrátoron keresztül további kérések indulnak. Ugyanakkor az LLM arra is juthat, hogy egyáltalán nincs szükség visszakeresésre.

Abban különbözik a korrekciós RAG-től, hogy az LLM maga ítéli meg a saját kimeneteit, eldönti, hogy szükség van-e visszakeresésre, és hasznos-e a visszakeresett szöveg, valamint figyeli a saját válaszait, és szükség szerint módosítja azokat. A korrekciós RAG ezzel szemben a generálás előtt értékeli a visszakeresett információk minőségét.

Ez az architektúra különösen hasznos az összetett, mélyreható kutatás jellegű promptoknál. Mivel a visszakeresett információk relevanciájának értékelését beépíti a válaszgenerálásba, jó választás a bizonyítékokon alapuló válaszokat igénylő promptokhoz.

6. Ügynöki RAG

Az ügynöki RAG a RAG bármely olyan formája, amelyet egy ügynöki platform keretében hajtanak végre. A modell az érvelési képességei segítségével meghatározza, milyen típusú információra van szükség, és a rendelkezésre álló visszakeresési lehetőségek közül választ.

A visszakeresés szükség szerint többször is elindítható, és a modell összetettebb lekérdezésekhez ügynököket is kijelölhet. Egy LLM például adatbázis-lekérdezést kérhet egy beszállító azonosításához, dokumentumkeresést indíthat a releváns szerződések megtalálásához, végül webes kereséssel, nyilvános források alapján ellenőrizheti a kapcsolattartási adatokat.

Az ügynöki RAG a fő architektúra-megvalósítás az olyan elterjedt chatbotokban, mint a Perplexity, a ChatGPT, a Claude és társaik. Mivel ezek a platformok több eszközhöz és RAG-folyamathoz is hozzáférést biztosítanak az alapmodellnek, a modell ki tudja választani, hogy a visszakeresés melyik formája illik legjobban egy adott prompthoz.

7. Multimodális RAG

A multimodális RAG különböző médiatípusokból keres vissza kontextust. A RAG fontos formája, mert olyan információkat tesz elérhetővé az LLM-ek számára, például diagramokat és hangfelvételeket, amelyek egyébként hozzáférhetetlenek lennének.

A mögöttes architektúra ugyanaz, mint bármely más rendszerben. Egy indexelési folyamat például úgy készítheti elő a képeket a kereséshez, hogy közvetlen beágyazásokká alakítja őket. Egy ügynöki RAG-rendszer ezután ezeket a képeket a szemantikailag releváns szöveggel együtt keresheti vissza, és egy látás-nyelvi modellnek adhatja át kettős feldolgozásra.

8. GraphRAG

A GraphRAG a vektoros keresés mellett tudásgráfokat is használ az entitásokra vonatkozó információk visszakereséséhez. Az orkesztrátor jellemzően kulcsszó-kinyeréssel vagy esetenként előzetes vektoros kereséssel találja meg a releváns kiinduló entitásokat, más néven csomópontokat. Egy gráf-visszakereső bejárja a tudásgráfot, hogy tágabb kontextust építsen fel.

Ha például egy termékkategória részletes lebontását kérik, az LLM vektoros keresést indíthat a konkrét entitások (termékek) azonosításához. Az orkesztrátor ezután tudásgráf-keresést indít a kapcsolódó entitások, például beszállítók, kiskereskedelmi helyszínek, értékelések és hasonlók megtalálásához.

9. Elágazó RAG

Míg a hibrid RAG-architektúra képes különböző visszakeresési módszereket használni, az elágazó RAG több lekérdezés, úgynevezett ág egyidejű futtatását jelenti. Mindegyik ág külön információforrást kérdezhet le, vagy az ágak párhuzamosan, eltérő lekérdezésekkel vagy szűrőkkel is lekérdezhetik ugyanazt a forrást. Az ügynöki RAG-architektúra gyakran alkalmaz elágazó RAG-et.

10. HyDE (Hypothetical Document Embeddings – hipotetikus dokumentumbeágyazások)

A HyDE a RAG innovatív formája, amelyben az LLM egy hipotetikus szöveges dokumentumot hoz létre arról, hogyan nézhetne ki egy optimális válasz. Ezt a „hipotetikus dokumentumot” ezután egy pontosabb visszakeresést lehetővé tevő lekérdezés létrehozására használják. Bár a releváns tudás nem jelenik meg az LLM paramétereiben, az elgondolás az, hogy egy válaszszerű szövegrész jobban illeszkedhet a releváns dokumentumokhoz, mint egy rövid kérdés vagy egy kétértelmű prompt.

Példa egyszerű RAG-architektúrára: vektoradatbázis

Az alapszintű RAG szolgál az összetettebb architektúratípusok alapjául. Egy vektoradatbázist használó egyszerű RAG-rendszer esetében a forrásdokumentációt kisebb darabokra (szövegrészletekre) bontják, és sűrű beágyazásokká alakítják. Amikor a felhasználó megad egy promptot, az orkesztrátor lekérdezést generál, kódolja azt, és lekérdezi az adatbázist a releváns szövegrészek megtalálásához.

Íme a folyamat lépésről lépésre:

1. Nagy mennyiségű szöveg vektorokká alakítása automatizált betöltési folyamattal és egy beágyazási modellel, például a BERT-tel.
2. Az adatbázis-alkalmazás rendszerezi, indexeli és tárolja a vektorokat a gyors keresés érdekében.
3. A felhasználó beír egy promptot egy chatbotba (például a Perplexitybe).
4. Az alkalmazás orkesztrátora (egy beágyazási modell segítségével) kódolja a promptot, hogy releváns információkat keressen vissza a vektoradatbázisból.
5. A vektoradatbázis visszaadja a releváns szövegrészleteket, az orkesztrátor pedig hozzáadja ezeket a bemeneti kontextushoz (a „nagy prompthoz”), és átadja az LLM-nek.
6. Az LLM a kiegészítő kontextus és a belső tudása (amelyet a parametrikus súlyai tárolnak) felhasználásával generál választ.

Nagyítás

Példa fejlett RAG-architektúrára: ügynöki RAG

Az ügynöki RAG a RAG-rendszerek mögöttes architektúráját jelenti egy ügynöki platformon belül. Az ügynöki RAG-folyamatok általában összetettek, mivel az MI-ügynökök a prompt jellegétől függően különböző eszközöket és folyamatokat hívhatnak meg, és szükség esetén több ügynököt is bevethetnek.

Íme egy gyakorlati példa a folyamatra:

1. A felhasználó feltesz egy összetett kérdést, amely egy téma mélyreható kutatását igényli. Ebben a példában tegyük fel, hogy a prompt így szól: „Készíts előrejelzést a vállalat eredményeiről a következő hat hónapra a jelentős geopolitikai események fényében.”
2. Az LLM arra következtet, hogy különböző tartalomtípusokra kiterjedő RAG-lekérdezések kombinációjára lesz szükség.
3. Három különböző ügynök indul: (a) vektoros keresésre, (b) webes megalapozásra és (c) (multimodális) képkeresésre.
4. Az ügynökök a rendelkezésre álló visszakeresési eszközökkel, az orkesztrátoron keresztül keresnek releváns információkat, például híreket és belső pénzügyi adatokat.
5. Az LLM összeveti a visszakeresett eredményeket az egyes ügynökök kutatási kérdésével, és relevancia szerint rangsorolja azokat.
6. Az LLM kiértékeli az információkat, és ahol információ hiányzik, az egyes ügynökökön keresztül további kereséseket indít.
7. Miután elegendő információt keresett vissza, az LLM a meglévő (belső dokumentációból visszakeresett) pénzügyi adatok alapján forgatókönyv-előrejelzéseket készít, és egy számológép-eszközt hív meg, hogy mindegyik forgatókönyvhöz kiszámítsa a várható eredményt.
8. Az LLM a visszakeresett információk és a számítások felhasználásával elkészíti a végső választ, szükség szerint megjelölve a forrásokat.

Nagyítás

Mi vár a RAG-re?

A jelenlegi innovációk középpontjában a mai RAG-architektúrák mélységének és sebességének növelése, a multimédiás visszakeresés pontosságának javítása, valamint a percre kész információk kezelésére tervezett rendszerek kiépítése áll.

Íme három trend, amely jelenleg a kutatás irányát alakítja:

• Mélyreható kutatás több forrásból: Olyan RAG-architektúra, amely képes kereséseket megtervezni, több ágat futtatni egymástól eltérő forrásokban, kiértékelni a visszakeresett bizonyítékokat, és önállóan optimalizálni a generált válaszokat. Az összes ilyen feladat végrehajtására képes ügynöki RAG egyre gyorsabbá és költséghatékonyabbá válik.
• Multimodális alkalmazások: A visszakeresési folyamatok egyre jobban kezelik a képeket és a videókat. Egyre inkább képesek pontosan azonosítani bizonyos típusú információkat az összetett multimodális adatokban, például a hosszú videókban és a bonyolult diagramokban.
• Válaszok megalapozása folyamatosan változó információkkal: Az LLM-alapú alkalmazások élő információforrásokra (például videofolyamokra és érzékelőkre) támaszkodhatnak a bemeneti kontextus biztosításához. A rendszerek az adatok értelmezéséhez sokrétű információs hálózatokat is létrehozhatnak, például a GraphRAG segítségével.

A RAG alapvető szerepet játszik az LLM-alapú alkalmazások működésében. Lehetővé teszi a legkülönfélébb felhasználók számára – a hétköznapi fogyasztóktól a speciális területeken működő vállalatokig –, hogy leküzdjék a hallucinációkkal, a hiányos tanítóadatokkal és a speciális belső tudáshoz való hozzáférés hiányával kapcsolatos problémákat.

Ezért a RAG-rendszerek és a mögöttük álló architektúra az MI-kutatás egyik leggyorsabban fejlődő és legizgalmasabb területét jelentik.