Mi az a RAG chatbot?
A RAG chatbot 2026-ban nem attól lesz hasznos, hogy folyékonyan beszél. Attól, hogy a válasz mögött megtalálható dokumentum van. A RAG, vagyis a retrieval-augmented generation, olyan architektúra, amelyben a nyelvi modell először a vállalati tudásbázisban keres, majd a megtalált szövegrészekből fogalmaz. Lewis és munkatársai 2020-ben ezt a mintát úgy írták le, hogy a modell paraméteres memóriáját külső, kereshető dokumentumindexszel egészítik ki. Az eredeti NeurIPS-cikk azóta is ez a kiindulópont.
A Microsoft Foundry dokumentációja ugyanezt a három lépést használja: retrieve, augment, generate. Először releváns tartalmat keres a rendszer egy indexben, aztán a találatot a kérdés mellé teszi a promptba, végül a modell ebből a kiegészített bemenetből ír választ, és hivatkozhat a forrásra. A Foundry RAG-leírása ezt groundingnak, vagyis földelésnek nevezi: a modell kevésbé találgat, ha tényleges céges anyagot kap.
Ezért a céges chatbot nem „okosabb ChatGPT”. Egy kereső és egy fogalmazó együttese, amelyet a saját FAQ-tok, termékleírásaitok, szerződéssablonjaitok és folyamatleírásaitok táplálnak. Az AiSolve RAG chatbot szolgáltatása erre a mintára épül: a modell a ti anyagotokból dolgozik, nem a nyilvános internetből. A tágabb AI megoldások közül épp ezért ezt akkor érdemes választani, ha a kérdésre már van írott, belső válasz, csak lassú megtalálni.
Egy nyíregyházi nagykereskedő példája jól mutatja a különbséget. A vevő azt kérdezi: „a 40 kilós zsákra is érvényes a hétfői akció?” Ha a chatbot a modell általános tudásából válaszol, udvarias lesz, és valószínűleg igent mond. Ha RAG-gal a hétfői akciólevélből és a termékadatlapból dolgozik, vagy megtalálja a 25 kilós korlátot, vagy azt mondja, hogy ebben a levélben nincs 40 kilós tétel. Az első válasz jól hangzik. A második számlát és reklamációt spórol.
Miért számít ez 2026-ban?
2026-ban már kevés vezető kérdezi, hogy „tud-e beszélni egy AI”. A kérdés az, hogy a válasz ellenőrizhető-e, ha egy ügyfél, egy auditor vagy egy belső jogász rákérdez. A NIST 2024 júliusában megjelent generatív AI profilja (NIST AI 600-1) a konfabulációt, közkeletű nevén a hallucinációt külön kockázati kategóriaként kezeli: a rendszer magabiztosan adhat hibás tartalmat, és ezzel félrevezetheti a felhasználót. A NIST AI 600-1 PDF expliciten javasolja a retrieval-augmented generationt, a források ellenőrzését és a kimenet folyamatos mérését.
A Google Cloud ugyanezt a problémát a grounding oldaláról írja le: a nyelvi modell önmagában a betanítási adatán nyugszik, ezért elavulhat, és ténybeli hibát is gyárthat. A RAG friss, saját adatot ad a modellnek. Ugyanakkor a Google is kimondja: ha a visszakeresett anyag irreleváns, a generált szöveg földeltnek tűnhet, mégis mellébeszél. A Google Cloud RAG-összefoglalója szerint a keresés minősége legalább annyira döntő, mint a modellé.
Magyarul: a RAG csökkenti az AI hallucináció kockázatát, de nem törli el. Ha a tudásbázis hiányos, a jogosultság rosszul van beállítva, vagy a rendszer akkor is válaszol, amikor nincs találat, a céges chatbot ugyanúgy jól hangzó mondatot ad, mint egy nyilvános chatablak. A különbség csak az, hogy a hiba most a ti logótok alatt jelenik meg.
Hogyan működik a retrieval, a kiegészítés és a válasz?
A három lépés, amit minden vezetőnek érdemes ismernie
Első lépés a keresés. A kérdésből a rendszer kulcsszavas, vektoros vagy hibrid keresést indít a vállalati tudásbázison. A vektoros keresés jelentés szerint hasonlít, a kulcsszavas a pontos szavakra és kódokra érzékeny. A Microsoft szerint a kettő együtt, tehát a hibrid keresés, gyakran jobb találatot ad, mint bármelyik önmagában.
Második lépés a kiegészítés. A megtalált bekezdéseket a rendszer a kérdés mellé teszi. Itt dől el, hogy a modell friss árlistát, elavult PDF-et vagy egy másik ügyfél szerződését kapja-e. A Foundry biztonsági megjegyzése egyértelmű: a hozzáférést a keresés pillanatában kell érvényesíteni, különben a földelt válasz is kiszivárogtathat olyan tartalmat, amit a kérdező nem láthatna.
Harmadik lépés a generálás. A modell ebből a csomagból ír. Ha a prompt azt mondja, hogy csak a megtalált szöveget használja, és hiányzó adatnál inkább mondja, hogy nem tudja, a válasz szűkebb lesz, de ellenőrizhetőbb. Ha a prompt „legyél hasznos és mindig válaszolj”, a modell kitölti a lyukakat. Az Azure Content Safety groundedness-ellenőrzése épp ezt méri: a válasz a megadott forrásanyagban van-e, vagy a modell hozzátett valamit. A groundedness-leírás szerint a RAG célja, hogy a modell a ti anyagotokból dolgozzon, ne a saját találgatásából.
A forrásmegjelölés nem dísz, hanem ellenőrzőpont
Egy idézhető céges chatbot a válasz mellett megmutatja a dokumentumot, az oldalszámot vagy a cikk címét. A NIST a MEASURE funkcióban külön javasolja a források és hivatkozások ellenőrzését a bevezetés előtt és utána is. Ha a hivatkozott bekezdés nem támasztja alá a mondatot, a rendszer nem „majdnem jó”. Rossz. Ilyenkor a retrieval, a darabolás vagy a generálás csúszott el, és ezt külön kell vizsgálni.
Mikor működik a RAG, és mikor csak jól hangzó választ ad?
Az alábbi táblázat nem marketing-összehasonlítás. Azokat a feltételeket gyűjti, amelyeket a fenti elsődleges források és a gyakorlati üzemeltetés újra és újra visszaigazol.
| Feltétel | Mikor ad valódi választ | Mikor csak jól hangzik |
|---|---|---|
| Retrieval | A kérdéshez tartozó, aktuális bekezdés bekerül a promptba. | Hasonló, de rossz verziójú vagy irreleváns szöveget talál. |
| Tudásbázis minősége | Egy kanonikus, dátumozott, karbantartott dokumentum van a témáról. | Három ellentmondó PDF, hiányzó melléklet, elavult ár. |
| Forrásmegjelölés | A mondat visszavezethető egy konkrét szövegrészre. | Van link, de a hivatkozott oldal nem tartalmazza az állítást. |
| Jogosultságkezelés | A keresés csak azt hozza, amit a kérdező egyébként is láthat. | A modell egy belső szabályzatból válaszol egy külső ügyfélnek. |
| Emberi eszkaláció | Alacsony találati biztonságnál emberhez viszi a beszélgetést. | Minden kérdésre „kész” választ ad, még ár, jog és panasz esetén is. |
| Tartózkodás | Ha nincs elég bizonyíték, kimondja, hogy nem tudja. | A lyukat a modell kitalált, de meggyőző mondattal tölti ki. |
A táblázat lényege egyszerű. A RAG akkor működik, ha a válasz visszavezethető, jogosultság szerint szűrt, és hiány esetén megáll. Minden más esetben csak a stílus javult, a megbízhatóság nem.
A vállalati tudásbázis minősége dönt, nem a modellneve
A Foundry saját korlátlistája kimondja: a RAG minősége a tartalom-előkészítésen, az indexelésen és a prompton múlik. Rossz darabolás, rossz beágyazás vagy rossz keresési mód közvetlenül rontja a választ. Ezért a bevezetés nem azzal kezdődik, hogy melyik nyelvi modellt választjátok. Hanem azzal, hogy melyik dokumentum a hivatalos, ki frissíti, és mi történik a kivont verzióval.
Gyakorlati próba, amit egy operatív vezető is el tud végezni egy délután alatt. Válasszatok ki húsz valós kérdést az ügyfélszolgálatról. Mindegyikhez jelöljetek ki egy „helyes” bekezdést a belső anyagból. Ha a rendszer ezt a bekezdést nem hozza az első találatok között, a modell nem fogja kitalálni helyette a jó választ. Ha hozza, de a válasz mégis más számot vagy más feltételt ír, akkor a generálás vagy a prompt a hibás, nem a keresés.
A tudásbázis akkor alkalmas céges chatbotra, ha a tartalomnak van gazdája, verziója és kivonási szabálya. Árlista, SLA, garancia, adatkezelési tájékoztató, termékkód: ezeknél a régi dokumentumot nem „ott kell hagyni, hátha kell még”. A régi dokumentumot ki kell venni az indexből, vagy verziómezővel kell szűrni. Ellenkező esetben a retrieval tökéletesen megtalálja a 2023-as PDF-et, és a chatbot magabiztosan idézi.
Ha a belső anyagok szétesettek, előbb adatfeldolgozásra és tartalomrendezésre van szükség, nem újabb modellre. A bevezetési folyamat pont ezért nem a widget beillesztésével kezdődik, hanem a forrásanyaggal és a jogosultságokkal.
Jogosultságkezelés: a földelt válasz is lehet adatszivárgás
A Microsoft figyelmeztetése rövid: ha nem kontrolláljátok a forrástartalom hozzáférését, a földelt válasz érzékeny információt szivárogtathat az indexből. A kereséskor kell szűrni, nem utólag a kész szövegben. Az Azure AI Search dokumentumszintű biztonsági szűrőt ajánl erre. A lényeg platformfüggetlen: a bérszámfejtés, az ügyfélszerződés és a nyilvános FAQ nem lehet ugyanabban a korlátlan indexben.
Ugyanez a GDPR-olvasat. Ha a chatbot egy ügyfélnek egy másik ügyfél megrendeléséből válaszol, a hiba nem „AI-furcsaság”. Adatvédelmi incidens. Erről bővebben az adatvédelem és kontextuális integritás cikkünkben írtunk. A RAG itt nem felmentés. A RAG csak akkor véd, ha a retriever a kérdező identitásával keres.
Külön kockázat a dokumentumba rejtett utasítás. A Foundry szerint a visszakeresett tartalmat nem megbízható bemenetként kell kezelni, mert egy PDF is tartalmazhat prompt injectiont. Ezért a rendszerüzenet és az alkalmazáslogika nem bízhat vakon abban, amit az index visszaad. A forrásanyagot is ellenőrizni kell, nem csak a modell kimenetét.
Emberi eszkaláció: hol kell megállnia a chatbotnak
Egy jó céges chatbotnak van olyan kérdéstípusa, amelyre nem válaszol végig. Árváltozás egyedi ajánlatnál, jogi értelmezés, panasz, egészségügyi vagy pénzügyi döntés, hiányzó dokumentum: ezeknél a helyes viselkedés az átadás. Nem azért, mert a modell „buta”, hanem mert a felelősség nem a tokenekben van.
Az eszkaláció akkor működik, ha mérhető. Például: nincs releváns találat; két forrás ellentmond; a felhasználó kétszer javít; a kérdés tiltott témára esik; a felhasználó expliciten ügyintézőt kér. Ezeket nem elég a promptba írni. A beszélgetésnek csatornája kell: jegy, e-mail, élő chat vagy telefonos ügynök. Ehhez a RAG gyakran egyedi automatizálással és, ha kell, AI telefonos ügynökkel kapcsolódik, de a döntési szabály a tiétek marad.
A NIST a human–AI konfigurációt külön kockázatként kezeli: a felhasználó túlzottan bízhat a magabiztos hangnemben. Ha a felület emberi hangon beszél, és soha nem mutat bizonytalanságot, az operatív csapat azt hiszi, hogy a rendszer „már kész”. Pedig csak udvarias. Ezért a válaszban látszódjon a forrás, a dátum és az, ha a rendszer nem biztos.
Gyakori hibák, amik jól hangzó választ gyártanak
Ezek a minták a bevezetéseknél rendre előkerülnek, és mindegyik kikerülhető.
- Az egész megosztott meghajtót indexelitek válogatás nélkül, aztán csodálkoztok a ellentmondó válaszokon.
- A chatbotot arra kéritek, hogy soha ne mondja: „nem tudom.”
- A forrást a válasz végére teszitek dísznek, de nem ellenőrzitek, hogy a mondat benne van-e.
- Ugyanazt az indexet kapja a belső munkatárs és a weboldal látogatója.
- Nincs gazdája a tudásbázisnak, ezért három hónap után minden dokumentum „majdnem aktuális”.
- Csak a modellcserétől vártok javulást, holott a keresés rossz bekezdést hoz.
A Microsoft a hibakereséshez is ezt a sorrendet adja: először a darabolást, a beágyazást és a keresési módot nézzétek, aztán a promptot, és csak utána a modellt. A NIST ehhez hozzáteszi: ne terjesszétek ki a képességet szűk, anekdotikus tesztekből. Tíz szép demókérdés nem üzemeltetési bizonyíték.
RAG vagy finomhangolás: melyik mire való?
A Foundry külön választja a két utat. RAG akkor kell, ha privát vagy gyakran változó adatra kell választ adni. Finomhangolás akkor, ha a modell viselkedését, stílusát vagy egy szűk feladat teljesítményét akarjátok megváltoztatni, nem a friss tudást. Egy céges chatbotnál a heti árlista, az új termékadatlap és a tegnapi folyamatleírás RAG-feladat. A hangnem, a magyar üzleti szóhasználat, a rövid válaszforma lehet prompt vagy finomhangolás. A kettőt összekeverni drága: a finomhangolt modell ugyanúgy elavul, ha a tudás a súlyokban van, nem az indexben.
Van egy harmadik út is, amit 2026-ban egyre többen kérnek: az ügynöki keresés. A Foundry ezt agentic retrievalnek hívja. A modell a bonyolult kérdést több szűk alkérdésre bontja, párhuzamosan keres, és strukturált forráscsomagot ad vissza. Ez akkor segít, ha a felhasználó egyszerre kér árat, szállítási feltételt és garanciát. Akkor sem csodaszer, ha az alkérdések mögött nincs dokumentum. Több rossz találatból nem lesz jobb válasz, csak hosszabb.
A mérésnél érdemes szétválasztani a rétegeket. A keresés akkor jó, ha a helyes bekezdés megjelenik. A generálás akkor jó, ha a mondat nem tesz hozzá feltételt. A hivatkozás akkor jó, ha a megjelölt span tényleg tartalmazza az állítást. A tartózkodás akkor jó, ha a megválaszolhatatlan kérdésre nem születik kitalált ár. Ha ezt a négyet egyetlen pontossági számba gyúrjátok, nem fogjátok tudni, mit javítsatok. A Microsoft a groundedness-ellenőrzést épp ezért külön futtatja a forrásanyagon, nem a modell általános műveltségén.
Összegzés: mikor érdemes belevágni
A RAG chatbot 2026-ban akkor ad valódi választ, ha a vállalati tudásbázis rendezett, a retrieval a helyes bekezdést hozza, a forrás ellenőrizhető, a jogosultság a kereséskor érvényesül, és a rendszer emberhez viszi azt, amit nem szabad kitalálnia. Minden más esetben jól hangzó választ kaptok, csak drágábban és a saját márkátok alatt.
Ha belső dokumentumokra, FAQ-ra vagy terméktudásra építenétek céges chatbotot, és előbb a határokat akarjátok tisztázni, nézzétek meg a RAG chatbot szolgáltatásoldalt, vagy olvassátok el a korábbi, architektúrát bemutató RAG AI chatbot cikkünket. Egyetlen kérésünk: hozd a tíz leggyakoribb kérdést és a hozzájuk tartozó hivatalos dokumentumot. Abból már látszik, hogy a rendszer készen áll-e, vagy előbb a tudásbázist kell rendbe tenni.
Készen állsz a saját weboldaladra?
Ingyenes konzultáció során átbeszéljük, hogyan segíthetünk vállalkozásodnak növekedni egy modern, gyors és konverzióoptimalizált weboldallal. 14 nap alatt kész, 0 Ft induló költséggel.
