Mi az a RAG és miért szükséges?

Nyereség:

• Annak elmagyarázása, hogy a RAG a modell súlyainak megváltoztatása nélkül szúrja be a kontextust, és „nyílt könyves vizsga” logikával működik
• A RAG összehasonlítása finomhangolási és hosszú kontextusos megközelítésekkel a költségek, az időszerűség és a használati forgatókönyv szerint
• Egy tipikus RAG-folyamat lépéseinek felsorolása, amely indexelési és lekérdezési fázisokból áll

Bármilyen erős is egy nyelvi modell (a szöveget megértő és előállító mesterséges intelligencia; ezentúl röviden modellnek nevezzük), nem ismeri a cége tegnap aláírt szerződését, a belső wiki (belső tudásbázis) oldalát vagy a ma reggel közzétett kiadási megjegyzést. A modell a betanítás időpontjáig általános ismeretekre korlátozódik; Ezt nevezik "oktatási határidőnek". A RAG (Retrieval-Augmented Generation) pontosan ezt a hiányt pótolja: megkeresi a kérdéshez kapcsolódó vállalati dokumentumokat, kontextusként megadja a modellnek (vagyis azt a kiegészítő szöveget, amelyet a válasz elkészítése közben olvas), és ennek alapján készíti el a választ.

Ebben az egységben világosan látni fogjuk, mi az a RAG, mikor részesítik előnyben az alternatívákkal szemben, valamint egy tipikus RAG-csővezeték lépéseit. Minden további egység egyenként mélyíti el a térkép részeit.

A RAG alapötlete: Nyílt könyves vizsga

Magyarázzuk el a RAG-t egy mondatban: "Először keresse meg a megfelelő dokumentumot, majd olvassa el a modellt, és ennek megfelelően nyomtassa ki a választ."

A leghasznosabb hasonlat a következő: A RAG a modellt „zárt könyves vizsgáról” „nyílt könyves vizsgára” helyezi át. A zárt könyvvizsgán a hallgató csak fejből válaszol; Nagy a kockázata annak, hogy kitalálja, amire nem emlékszik. A nyílt könyvvizsgán a hallgató az elé helyezett forrásra nézve válaszol. A RAG-ban a modell már nem a saját memóriájából válaszol, hanem az általad adott aktuális és konkrét szövegből.

Kritikus pont: A RAG nem változtatja meg a modell súlyát, vagyis a modell által megtanult numerikus paraméterek milliárdjait. Nem tanítod át a modellt. Minden kérdésnél az adott kérdésre vonatkozó szövegrészeket kell beilleszteni a promptba (a modellnek elküldött utasításszöveg). Így nem kell áttanítania a modellt a dokumentum frissítésekor; egyszerűen frissíti a megfelelő rekordot a keresési adatbázisban.

Tipp: Két kérdés határozza meg a RAG minőségét: (1) Megtalálta a megfelelő dokumentumot? (2) Helyesen olvasta a modell? Az első a "visszakeresési minőség", a második a "generációs minőség". A kettőt külön mérik és javítják.

RAG, finomhangolás vagy hosszú kontextus?

Három út gyakran összekeveredik, amikor egy szervezeti problémára keresünk megoldást. Tisztázzuk a különbségeiket. A finomhangolás a modell súlyainak frissítése az Ön adataival, és új viselkedésre/stílusra tanítja. A hosszú kontextus azt jelenti, hogy az összes dokumentumot közvetlenül a promptba kell kitölteni, kijelölés nélkül.

Megközelítés

Mit tesz

Mikor megfelelő?

Költség/kockázat

RAG

Kontextusként beszúrja a vonatkozó dokumentumot

Gyakran változó, kiterjedt, konkrét információk

Alacsony; könnyen frissíthető, a forrásra hivatkozni lehet

Finomhangolás

Frissíti a súlyokat új adatokkal

Rögzített stílus/formátum/nyelvtanítás

Magas; Minden frissítésnél átképzés szükséges

Csak hosszú kontextus

Minden dokumentumot kitölt a promptba

Kicsi, helyhez kötött iratkészlet

Növekszik a token költsége és a "középső rész elvesztésének" kockázata

Általános szabály: A finomhangolás megtanítja a modellt beszélni; A RAG elmondja a modellnek, hogy mit kell tudnia. A legtöbb vállalati forgatókönyvben először a RAG-t próbálják ki, mert olcsó, frissíthető, és megmutatja a válasz forrását. A hosszú szövegkörnyezet akkor indokolt, ha a dokumentumkészlet nagyon kicsi és rögzített (pl. egyetlen 20 oldalas kézikönyv); De több ezer oldal miatt drága, és előfordulhat, hogy a modell kihagyja az információkat a hosszú szöveg közepén.

Egy tipikus RAG-csővezeték

A RAG két fő fázisból áll: az indexelésből (előkészítés, egyszer vagy időszakosan) és a lekérdezésből (minden felhasználói kérdésre fut).

Indexelés lépésről lépésre (offline, felhasználói várakozás nélkül):

1. Gyűjtés: Dokumentumok lehívása forrásokból (PDF, wiki, jegyrendszer, adatbázis, e-mail).
2. Feldarabolás: A hosszú szöveget kisebb kezelhető darabokra bontja.
3. Beágyazás: Konvertálja az egyes részeket beágyazássá (a szöveg jelentését hordozó számvektor).
4. Mentés: Írja be a vektorokat a szöveggel és a metaadatokkal (forrás, dátum, jogosultsági információk) a vektoradatbázisba.

Lépésről lépésre lekérdezés (online, amíg a felhasználó vár):

1. A felhasználó kérdésének konvertálása beágyazássá.
2. Keresse ki a leginkább hasonló részeket a vektoradatbázisból.
3. Helyezze ezeket a darabokat + kérdést egy prompt sablonba.
4. Szerezze meg a kontextuális választ és annak forrásait a modellből.

# A kérdezősködési szakasz fogalmi vázlata (nem függ a nyelvtől)question = "Hány nap az éves szabadság?"question_vektor = embed(question)parts = vektor_db.search(question_vektor, top_k=4) # leghasonlóbb partsprompt = f"""Válaszoljon a KÉRDÉSRE a következővel, ha a KONTEXTUS nincs információval az alábbiakban. Fitting.CONTEXT:{parts}KÉRDÉS: {question}"""válasz = model.uret(prompt) # pl. modell: claude-opus-4-8

Ez a folyamat az egyes szakaszok térképe, amelyet a következő egységekben egyenként bontunk ki.

Gyenge felszólítás / Erős felszólítás

Még ugyanazzal a RAG-kontextussal is, a prompt minősége megváltoztatja a választ.

Gyenge prompt (nyitva a modellillesztésre, nem igényel erőforrást):

Használja ezt az információt, és mondja ki az éves szabadságot: {parts}. Kérdés: {question}

Hatékony prompt (földelés + "Nem tudom" engedély + erőforráskérés):

Csak az alábbi KONTEXTUS alapján válaszoljon. Ha a szövegkörnyezetben nincs egyértelmű válasz, írja be, hogy "Nem találtam erről információt a dokumentációban"; Ne találgass. Adja hozzá annak a darabnak a [Source: file_name] címkéjét, amelyre támaszkodik a válasz végén. CONTEXT: {pieces} KÉRDÉS: {question}

Három mini tok

1. eset – HR-asszisztens (emberi erőforrás). Egy cégnek 340 oldalas HR kézikönyve van, és az alkalmazottak naponta átlagosan 90 kérdést tesznek fel. Finomhangolással próbálkoztak, de mivel a kézikönyvet havonta frissítették, minden alkalommal újraképzésre volt szükség; A költség elérte a több ezer dollárt havonta. A RAG-ra váltás után a frissítés a "dokumentum újraindexelése" lépésre (perc) csökkent, a helyes válaszok aránya pedig 71%-ról 93%-ra nőtt kézi mérésnél.

2. eset – Ügyfélszolgálat. A támogatási csapatnak 12 000 megoldott jegye és 800 súgócikkje van. Átlagosan 4 percet vesz igénybe, amíg a képviselő manuálisan megkeresi a választ. Amikor a RAG asszisztens elhozta az 5 legrelevánsabb rekordot, és választervezetet készített, az idő 40 másodpercre csökkent; Ám a csapat felismerte annak kockázatát, hogy "rossz cikket hozva elbizonytalanodik", és kötelezővé tette a forrásra való hivatkozást.

3. eset – Jog. Egy szerződő csapat megkérdezte, hogy "mely szerződésekben érvényes a titoktartási záradék 5 évre?" teszi fel a kérdést. A hosszú kontextusos próba során 60 szerződést töltöttek ki egyetlen promptba; a modell kihagyta a középső két szerződést. Amikor csak a releváns tételeket vezették be a RAG-val, a token költsége 80%-kal csökkent, és a hiányzó kihagyást visszaállították.

Miért van szükség a RAG-ra?

• Aktuálisság: Az információkhoz a képzés határideje után fér hozzá.
• Különleges információk: Az Ön belső dokumentumai egyetlen modell képzésében sem szerepelnek; Csak te tudsz adni.
• Ellenőrizhetőség: Megjelölheti a válasz forrását (idézet) – ez elengedhetetlen az ellenőrzéshez és a bizalomhoz.
• Hallucinációkontroll: Az előtte elhelyezett szövegre támaszkodik, nem pedig modellt alkot.
• Költség: Sokkal olcsóbb és gyorsabb üzembe helyezés, mint a finomhangolás.

Figyelem: A RAG nem varázslat. Ha rossz darabot visz be, a modell rossz választ kap, „magabiztosnak”. Tartsa szem előtt a "Letöltés minősége = RAG minőség" kifejezést.

Gyakori hibák

• A RAG összetévesztése a finomhangoláshoz: A RAG nem változtatja meg a súlyokat; Csak hozzáadja a kontextust. A kettő összekeverése a rossz architektúra kiválasztásához vezet.
• Nem engedélyezi a „nem tudom” lehetőséget: Ha a prompt szabadon hagyja a modellt, hogy kitöltse az üres helyet, akkor az kipótolja.
• Forrásra nem hivatkozva: A forrás nélküli válasz nem ellenőrizhető; A felhasználó nem tudja észrevenni a hibát.
• Mindent egy promptba tömörítve: A hosszú kontextus olcsónak tűnik, de drága, és hiányzik a középső információ.
• Elakadás a generálásban a visszakeresés mérése nélkül: Ha rossz a válasz, először kérdezze meg: "Megérkezett a megfelelő alkatrész?" meg kell kérdezni.

Összefoglalva

• A RAG egy olyan megközelítés, amely a kérdés szempontjából releváns dokumentumokat kontextusként illeszti be a modellbe; nem változtat a súlyokon ("nyílt könyves vizsga").
• A finomhangolás stílust/formátumot tanít, a RAG aktuális és konkrét információkat; a hosszú kontextus jól működik kis rögzített halmazoknál. A legtöbb esetben először a RAG-t próbálják ki.
• A folyamatnak két fázisa van: offline indexelés (darab + beágyazás + mentés) és online lekérdezés (lekérés + prompt + generálás).
• A RAG időszerűséget, konkrét információkat, ellenőrizhetőséget, hallucinációk elleni védekezést és alacsony költséget biztosít.
• A rendszer minősége közvetlenül függ a visszakeresés minőségétől: rossz darab rossz választ jelent.

Pályázati feladat

Válasszon valódi információforrást saját csapatától (például eljárási dokumentumot vagy GYIK oldalt). (1) Írj 5 tényszerű kérdést erről a forrásról! (2) Jegyezze fel, hogy a dokumentum melyik része tartalmazza a helyes választ az egyes kérdésekre – ez lesz az „arany válasz” listája. (3) A fenti „erős prompt” sablon használatával manuálisan illessze be a megfelelő részt kontextusként, és kérjen modellt. (4) Hasonlítsa össze a modell által adott választ az aranyszínű válasszal, és jelölje meg igaznak/hamisnak! Ez az értékelés első manuális verziója, amelyet a jövőbeni egységekben automatizálni fog.

ellenőrző lista

• [ ] Egy mondattal el tudom magyarázni, hogy a RAG nem változtat a súlyokon, csak kontextust ad hozzá.
• [ ] Meg tudom különböztetni a RAG-t, a finomhangolást és a hosszú kontextust, és azt, hogy mikor melyik a megfelelő.
• [ ] Meg tudom számolni sorrendben az indexelés (összegyűjtés-feldarabolás-beágyazás-mentés) és a lekérdezés (beágyazás-lehívás-prompt-generálás) fázisokat.
• [ ] Tudom, miért adtam hozzá a "ha nincs összefüggésben, mondd, hogy nem tudom" és "hivatkozz forrásra" utasításokat a prompthoz.
• [ ] A "Retrieval quality = RAG quality" elvet saját esetemre tudom igazítani.