RAG vs. LLM: technikai áttekintés (meghatározások, különbségek, használati esetek)

Az LLM-ek válaszokat generálnak a képzési adataik mintázataiból tanult paraméterek segítségével. Mivel ezek a paraméterek nem feltétlenül tükrözik a legfrissebb vagy teljes információt, a RAG, vagyis a visszakeresésen alapuló generálás, úgy egészíti ki a folyamatot, hogy külső forrásokból származó adatokat ad az LLM bemeneti kontextusához. Egy AI-eszköz visszakeres külső információt, hogy kibővítse az LLM generálási folyamatát.

A valóságban a választásod nem a RAG és az LLM között van. Hanem egy hibrid megközelítés és egy olyan megoldás között, amely csak LLM-et használ.

A RAG-ra akkor van szükség, amikor egy LLM-nek hozzá kell férnie vállalati dokumentációhoz, adatbázisokhoz vagy gyorsan változó információkhoz. Az LLM-only megközelítés bizonyos adminisztratív, adatfeldolgozási és tartalomkészítési feladatokhoz megfelelő, ahol minden bemenetet megadhat a felhasználó.

RAG vs. LLM: Mik a fő különbségek?

• A RAG és az LLM-ek egymást kiegészítő rendszerek. AI-modellt használhatsz RAG nélkül is (ilyenkor kizárólag a meglévő paramétereire támaszkodik), de RAG-rendszert modell nélkül nem tudsz használni.
• A RAG-ot azért vezették be, hogy áthidalja az LLM-ek három kulcsproblémáját: az elavult információkat, a hallucinált válaszokat és a harmadik fél forrásaival való ellenőrzés hiányát.
• A RAG sokkal hatékonyabbá teszi az MI-t valós üzleti helyzetekben, mert összekapcsolja az LLM-eket hitelesített belső dokumentációval, adatbázisokkal és API-végpontokkal.
• A legfontosabb RAG-használati esetek közé tartoznak az ügyféltámogatási chatbotok, a gyorsan változó adatokon alapuló lekérdezések (például az iparági hírek), valamint a speciális területek, mint az orvostudomány és a jog, ahol a pontosság és a források ellenőrzése fontos.
• A RAG három fő típusa létezik: a naiv RAG, a moduláris RAG és az advanced RAG. A naiv RAG a legegyszerűbben úgy érthető meg, mint az egyszerű információ-visszakeresés, míg a moduláris és az advanced RAG további funkciókat ad hozzá, például lekérdezés-átírást és szegmensoptimalizálást.

Mi az a nagy nyelvi modell (LLM)?

Az LLM, vagyis a nagy nyelvi modell olyan rendszer, amely finomhangolt paraméterek használatával generál tartalmat. Ezek a paraméterek határozzák meg az LLM szókincsének összes tokenjéhez rendelt valószínűségeket, jelezve, hogy egy adott sorozatban melyik token következik a legnagyobb valószínűséggel.

Ahhoz, hogy jobban megértsük, hogyan működik a RAG (és miben különbözik az LLM-ektől), hasznos alapvető szinten megnézni, hogyan működik a generatív MI:

1. Tokenizálás: A felhasználó promptja tokenekre bomlik, amelyek lehetnek szavak, szórészek vagy akár egyetlen karakterek is.
2. Beágyazás: A tokenek beágyazásokká, numerikus reprezentációkká (számsorokká) alakulnak, amelyeket vektoroknak neveznek, és amelyeket a dekódert is tartalmazó neurális hálózat képes feldolgozni.
3. Dekódolás: A dekóder rétegei (amelyek az LLM neurális hálózatának nagy részét alkotják) manipulálják ezeket a vektorokat, egy attention nevű folyamatot használva a jelentés megragadására. Ez a folyamat határozza meg, hogy az egyes tokenek mennyire kapcsolódjanak a sorozat többi tokenjéhez.
4. Pontozás: A modell kompatibilitási valószínűséget rendel a meglévő szókincsének minden tokenjéhez, és kiválaszt egy valószínű következő tokent a sorozatban.

A lényeg az, hogy az LLM csak a meglévő paraméterei és a kontextusablakában lévő tokenek alapján tud kimenetet előállítani. A tanítás során az LLM-et több milliárdszor késztetik arra, hogy befejezzen hiányos szövegrészeket, és a paramétereit addig állítják, amíg megbízhatóan nem rendel valószínűségeket a tokenekhez (és így nem fejezi be a szöveget).

Képzeljük el például, hogy egy AI-modellt a következő kérdéssel keresel meg: „Mit mond a cégünk 2026-os visszatérítési szabályzata?” Az LLM csak a meglévő paraméterei alapján tudja előrejelezni a következő tokeneket, amelyeket nem hangoltak finomra a támogatási dokumentációdon. Ha ezt a kérdést minden további kontextus nélkül teszed fel, egyszerűen képtelen lesz érdemben válaszolni, vagy helytelen választ hallucinál.

Mi az a visszakeresésen alapuló generálás (RAG)?

A RAG (visszakeresésen alapuló generálás) az a folyamat, amelynek során külső rendszerekből származó információk bekerülnek az LLM promptjába.

A mögöttes LLM-folyamat, amely beágyazást és valószínűségi tokenegyeztetést foglal magában, változatlan marad. A RAG egy előzetes lépést vezet be, amelyben a felhasználói prompt további adatokkal bővül.

Íme egy áttekintés arról, hogyan működik a RAG:

1. Tudás-előkészítés: Előkészítenek egy tudásforrást. Ez lehet dokumentumkészlet, vektoradatbázis, tudásgráf vagy élő index (például AI-kereséshez).
2. Promptolás: A felhasználó megad egy promptot, például: „Elmenjek-e ma sétálni Londonban?”
3. Visszakeresés: A külső információforrást az AI-eszköz visszakereső komponense kérdezi le. Előfordulhat, hogy beágyazza a promptot, vektorrá alakítva azt, majd lekérdez egy vektoradatbázist. Alternatívaként használhat más módszert is, például API-hívást, kulcsszavas egyeztetést vagy tudásgráf-bejárást.
4. Beszúrás: Ez az információ hozzáadódik a felhasználó eredeti promptjához. A londoni sétáról szóló kérdés példájában ez magában foglalhatja a londoni időjárást és a népszerű sétaútvonalak aktuális járhatóságát.
5. Válaszgenerálás: Az LLM a szokásos módon, a kibővített promptot használva generál választ.

A színfalak mögött a visszakeresett szöveg hozzáadódik a bemeneti kontextushoz, tokenizálódik és beágyazásra kerül. A modell ezután a dekóderén keresztül feldolgozza ezt a további kontextust, ami megváltoztatja a kimeneti tokenvalószínűségeket.

Általánosságban a RAG három altípusra bontható. A Naive RAG az alapvető RAG-folyamatot követi, információt kér le és azt a promptba táplálja. Az Advanced RAG további funkciókat ad hozzá, például lekérdezés-átírást és több lekérdezési menetet. A Modular RAG olyan architektúrát jelöl, amelyben a különböző fejlett funkciók komponensekként kezelhetők és igény szerint kombinálhatók.

RAG vs. LLM: a használati esetek áttekintése

A RAG hozzáférést biztosít a felhasználóknak a naprakész adatokhoz. Ennek eredményeként az LLM kimenetei kisebb valószínűséggel tartalmaznak hallucinációkat és információhiányokat. Ha látni szeretnéd a kimenetben felhasznált információk forrásait, a RAG szintén elengedhetetlen, mivel az alátámasztás nélküli LLM-válaszok nem tartalmaznak hivatkozásokat.

Nagyítás

RAG használati esetek

• Időszerű információkra irányuló kérések: Minden olyan információs lekérdezés, amely gyorsan elavul, legyen az olyan egyszerű, mint egy időjárás-előrejelzés, vagy olyan összetett, mint egy kialakulóban lévő hírtörténet részletes elemzése, megerősített harmadik fél forrásaira kell hogy épüljön.
• Vállalati dokumentáció: Azok a belső vagy ügyfélfelületű AI-chatbotok, amelyekben a felhasználók a vállalat vagy a termék dokumentációjával kapcsolatos kérdéseket tesznek fel, RAG-képesek kell hogy legyenek, különösen, ha a dokumentációt gyakran frissítik.
• Ügyféltámogatás: Az ügyfélchatbotoknak hozzá kell férniük a naprakész, részletes támogatási dokumentációhoz ahhoz, hogy pontos válaszokat adhassanak.
• Speciális területek (orvostudomány, jog, pénzügy stb.): Azok az LLM-ek, amelyeket nem képeztek domain-specifikus korpuszokon (különösen a mainstream modellek), jellemzően nehezen boldogulnak a speciális promptok árnyalataival.

LLM használati esetek

• Adminisztratív feladatok: Az LLM-ek minimális késleltetéssel képesek alapfeladatokat elvégezni. A RAG szükségtelen az olyan alapvető írási és adminisztratív feladatokhoz, mint a helyesírás-ellenőrzés vagy az összefoglalás, ahol nincs szükség külső információra.
• Kreatív feladatok: Egyes kreatív feladatokhoz, például egy rövid történet vagy egy kép generálásához, csak az eredeti promptban megadott információkra van szükség.
• Érvelési és adat alapú feladatok: Ha egy nagy adathalmazzal dolgozol, az LLM-nek nincs szüksége külső információra az érvelési és elemzési funkciók alkalmazásához.
• Általános kódolás: Bár egy kódolási munkafolyamathoz szükség lehet privát kódbázisra vagy dokumentációra, az LLM-ek rendkívül jól tudnak általános kódolási feladatokat végrehajtani, például hibákat javítani és függvényeket létrehozni külső források igénybevétele nélkül.

RAG vs. hosszú kontextusú LLM, ügynöki MI és alátámasztás

Három kapcsolódó fogalom releváns a RAG és az LLM-ek közötti különbségtétel szempontjából. Ezek a hosszú kontextusú LLM-ek, az ügynöki MI és az alátámasztás.

A hosszú kontextusú LLM-ek néha használhatók a RAG-képes rendszerek helyett, míg az ügynöki MI és az alátámasztás velük szinonim, vagy velük együtt működik.

Hosszú kontextusú LLM-ek

Ezek olyan modellek, amelyek nagy kontextusablakkal rendelkeznek, és egyes széles körben elérhető kereskedelmi modellek akár egymillió tokent is kezelnek.

Ha a releváns anyag belefér egy modell kontextusablakába, és szöveges formátumban rendelkezésre áll, az LLM-only megközelítésnek vannak előnyei. Csökkentheti a visszakeresési hibák esélyét, átfogóbb kontextust biztosíthat, és kiküszöbölheti a kiterjedt RAG-architektúra beállításának szükségességét.

Ügynöki MI

Az ügynök olyan rendszer, amely több eszközre támaszkodik, beleértve a RAG-képességeket is, összetett feladatok végrehajtásához. A RAG az ügynöki MI egyik összetevője, és egy ügynök gyakran különböző típusú visszakeresési módszereket használ (pl. webes keresést vagy vektoros keresést) a prompt tartalmától függően.

Alátámasztás

Az alátámasztás az a tágabb folyamat, amelyben bizonyítékot vagy adatot használunk az LLM válaszának pontosságának javítására, vagyis alátámasztására. A RAG az alátámasztás egyik formája, de az is alátámasztásnak számít, ha egy műszaki dokumentumot adunk hozzá egy kontextusablakhoz.

RAG vs. LLM: valós példák

Ahhoz, hogy jobban megértsük, hogyan működik a RAG az RAG nélküli LLM-használathoz képest, megnézhetünk egy egyszerű, valós példát a Perplexity és egy hipotetikus vállalati eset segítségével, ahol egy vektoradatbázist kérdeznek le.

RAG vs. LLM egyszerű prompttal

Íme a kimenet (két mondatra korlátozva), amikor a Perplexitytől azt kérdezik: „Elmenjek-e ma sétálni Londonban?” az AI webes keresés (a RAG egyik formája) kikapcsolt állapotában:

Igen – ha az időjárás viszonylag száraz, és van időd, egy londoni séta ma üdítő változatosságot jelenthet. Válassz útvonalat a South Bank, a Regent’s Canal vagy a Hyde Park mentén, és vigyél magaddal egy könnyű vízálló kabátot, biztos ami biztos.

Hasonlítsd ezt össze azzal a prompttal, amikor az LLM külső forrásokat is ellenőrizhet:

Igen, jó nap egy londoni sétához: az előrejelzés enyhe, körülbelül 19–21°C-os hőmérsékletet jelez napos időszakokkal és csak igen csekély eséllyel esőre. A részben felhős égbolt és a gyenge szellő kellemes feltételeket biztosít a parkok vagy a folyóparti útvonalak, például a South Bank felfedezéséhez.

A kettő között vannak hasonlóságok, mivel az LLM ugyanazt az alapul szolgáló tokenpontozási folyamatot használja. A második példa azonban részletes időjárási információkat tartalmaz, ami sokkal hasznosabbá teszi.

RAG vs. LLM vállalati vektoradatbázissal

Képzeld el, hogy egy felhasználó a banki alkalmazás beépített chatbotjának a következő kérdést teszi fel: „Hol tudom letölteni a legfrissebb számlakivonatomat?”

Az alkalmazást kezelő bank olyan adatbázist hozott létre, amely a naprakész termékdokumentációjának beágyazásait tartalmazza, és összekapcsolta a chatbot RAG-folyamatával. A dokumentáció körülbelül 1 000 forrásdokumentumból áll, amelyeket kisebb szegmensekre bontottak, majd vektorokká alakítottak visszakereséshez.

A felhasználó lekérdezése elküldésre kerül a beágyazási modellnek, az alkalmazás pedig elküldi ezt a vektort az adatbázisnak, amely visszaadja a releváns szegmenseket.

A beágyazási modell egy ilyen kérést kapna:

A beágyazási modell a következő vektoros beágyazást adja vissza:

A vektoradatbázis ezután egy ilyen kérést kap:

Ebben a (sokkal leegyszerűsített) példában az adatbázis visszaadja a felhasználó lekérdezése szempontjából legrelevánsabb öt szegmenst, amelyeket elküld az alkalmazásnak, és belefoglal az LLM promptjába.

Mikor válasszunk RAG-ot az LLM helyett, és mikor kombináljuk őket

Az LLM-ek és a RAG egymást kiegészítő rendszerek. Emiatt a „Mikor válasszak LLM-et és mikor RAG-ot?” kérdés félrevezető. Helyette azt kellene kérdezned: „Mikor elegendő egy LLM, és mikor optimális a RAG?”

Mikor használjunk RAG nélkül működő LLM-et

• Az általad választott AI-modellnek nagy kontextusablaka van: Ha egyszerűbb minden, a pontos válaszhoz szükséges információt vagy adatot belefoglalni a promptba, például egy dokumentum feltöltésével, az csökkentheti a késleltetést és megelőzheti a visszakereséssel kapcsolatos problémákat.
• Érvelési és adatelemzési munkafolyamatok: Az olyan elemzési és érvelési munkafolyamatokhoz, amelyek kizárólag a promptban megadott adatokra támaszkodnak, nincs szükség RAG-képességekre.
• Kódgenerálás: Az általános kódolási munkához a RAG-ra jellemzően nincs szükség, bár projekt-specifikus feladatoknál általában használják, például korábbi javítások vagy szállítói API-k és dokumentációk lekérésére.

Mikor használjunk RAG-képes LLM-et

• Naprakész információkhoz van szükséged hozzáférésre: Ha egy AI-alkalmazásnak külső, naprakész információforrásokhoz kell hozzáférnie ahhoz, hogy pontos választ generáljon, mindig gondoskodj arról, hogy a RAG-képességek be legyenek kapcsolva.
• Speciális területen dolgozol: Az olyan szakterületeken, mint az orvostudomány, a jog, az oktatás és hasonlók, ahol fontos a pontosság, a részletesség és a forrásellenőrzés, az LLM-only használat gyakran nem elegendő.
• A kimeneteknek belső vállalati fájlokra kell hivatkozniuk: Ha AI-t használsz, akár belső, akár ügyfélfelületű alkalmazásban, hogy belső vállalati dokumentumok, legyenek azok adatok, brand kit, dokumentáció vagy fájlok alapján generálj tartalmat, a RAG hozzáférést biztosít ezekhez az információkhoz.

A RAG és az LLM-ek egymást kiegészítő, fejlődő technológiák

A RAG jelentős újítást jelentett az MI fejlődésében. Három fő problémára kínált megoldást: az elavult információkra, a korlátozott modellmemóriára és a releváns képzési adatok hiánya miatti információhézagokra, amelyek gyakran hallucinációkhoz vezettek. Természetesen az LLM-ek ezeket nem oldották meg teljesen, de a RAG megjelenésével az előfordulásuk jelentősen csökkent.

A RAG nem statikus technológia. Várhatóan sok területen fejlődik majd, beleértve az újrarangsorolást, a visszakeresés alatti késleltetést és a tokenhasználatot, a veszélyes adatforrások elleni biztonsági védelmet, a különböző forrásokból visszakeresett adatok integrálását és még sok mást. Ahogy az LLM-ek és az ügynöki MI tovább fejlődik, úgy fejlődnek majd a mögöttük álló RAG-rendszerek is.