RAG és belső AI tudásbázis, hogyan kérdezhetők le a saját dokumentumok?

Az alapprobléma

Miért nem elég egy sima chatbot a belső tudáshoz?

Az általános nyelvi modellek, mint a ChatGPT vagy a Claude, hatalmas mennyiségű nyilvános szöveget láttak a tanítás során, de a te céged belső adatait természetesen nem ismerik. Ha felteszed nekik a kérdést, hogy „Mi a jelenlegi jutalékszabályunk az enterprise ügyfelekre?“, a válasz vagy egy általános sablon lesz, vagy egyenesen kitalált információ. Ez utóbbit a szakma hallucinációnak nevezi. Az egyik ügyfelemnél pontosan ezt tapasztaltam. A generikus ChatGPT válasz szó szerint egy versenytárs szerződési feltételeit idézte vissza, mert az volt a legtöbb ilyenre a legjobb nyilvános sablon. A jelenlévő vezetők döbbenetét ma is élénken emlékszem.

A prompt engineeringgel lehet részben orvosolni a problémát, ha a kontextusba bemásolod a releváns dokumentumrészleteket. Ez kisebb mennyiségű szövegnél működik, de egy 500 oldalas termékkatalógusnál vagy egy 10 éves szerződésállománynál már nem járható út. A modellek kontextusablaka véges, és manuálisan keresni a releváns részeket éppen azt a munkát jelenti, amit az AI-tól várnánk el.

A RAG architektúra erre a problémára adott megoldás. Nem tanítja újra a modellt (ami drága és lassú lenne), hanem a kérdés pillanatában keres rá a releváns dokumentumrészletekre, és azokat adja oda kontextusként az AI-nak. Az eredmény az, hogy a modell a saját dokumentumaidból válaszol, és ha helyes az építés, meg is tudja mondani, melyik forrásból.

Hogyan működik

A RAG rendszer felépítése lépésről lépésre

A Retrieval-Augmented Generation neve pontosan leírja a folyamatot. Először visszakeresés (retrieval), majd válaszgenerálás (generation). A két fázis között egy vektoros keresési réteg van, ami a szemantikai hasonlóság alapján dolgozik, nem kulcsszavak szerint. Amikor ezt először építettem fel egy pénzügyi ügyfelemnél, az volt a legnagyobb meglepetés a csapat számára, hogy mennyire nem szükséges az egzakt kifejezés, hiszen a rendszer a szándékot érti, nem a betűket. Ez az a pillanat, amikor a szkeptikus kollégák is elkezdtek hinni benne.

Az indexelési fázis

Mielőtt bármi kereshető lenne, a dokumentumokat fel kell dolgozni. A folyamat a következő lépésekből áll.

1. Dokumentumbeolvasás. PDF, Word, Excel, HTML, e-mail, SharePoint oldal beolvasása szöveggé. Szkennelt dokumentumoknál OCR szükséges.
2. Darabolás (chunking). A szöveg kisebb, 300-800 tokenes darabokra vágása. A darabolás módja kritikusan befolyásolja a keresés minőségét.
3. Embedding generálás. Minden darabot egy embedding modell szám-vektorrá alakít, ami a szöveg jelentését reprezentálja a matematikai térben.
4. Vektoros adatbázisba mentés. A vektorok és az eredeti szövegrészletek egy speciális adatbázisba kerülnek (pl. Pinecone, Weaviate, pgvector).

A lekérdezési fázis

Amikor egy felhasználó kérdést tesz fel, a rendszer a kérdést is vektorrá alakítja, majd megkeresi az adatbázisban a legközelebb eső, tehát szemantikailag leghasonlóbb dokumentumdarabokat. Ezeket a darabokat aztán beilleszti a promptba, és így adja oda a nyelvi modellnek. A modell a kapott kontextus alapján fogalmazza meg a választ.

A keresés kulcsszóalapú kereséstől eltérően nem szó szerint egyező szövegeket keres. Ha a dokumentumban az áll, hogy „a megbízási díj nem tartalmazza az ÁFÁ-t“, a rendszer ezt a releváns részletet visszaadja a „nettó számla adótartalma“ kérdésre is, mert a két mondat szemantikailag közel van egymáshoz.

Mire jó valójában

Tipikus vállalati alkalmazások és valós példák

A RAG nem elvont technológiai fogalom. Az én tapasztalatom szerint azok a projektek a legmeggyőzőbbek, ahol egy konkrét, napi szintű fájdalompontra keresi a csapat a megoldást. Amikor valaki azt mondja, hogy „általánosan szeretnénk AI bevezetést“, az szinte biztosan lassabb és drágább projektet jelent, mint amikor valaki azt mondja, hogy „a jogászaink napi két órát töltenek szerződéskeresséssel“.

Belső szabályzatok és HR dokumentumok

Az egyik gyártóipari ügyfelemnél, ahol 400 fő dolgozik, a HR csapat hetente kapott ismétlődő kérdéseket a munkaidő-nyilvántartásról, a szabadság-elszámolásról és a cafeteria rendszerről. Amikor elvégeztük a bevezetést, a hatályos kollektív szerződést és a HR kézikönyvet indexeltük be egy belső chatbotba. Az ismétlődő megkeresések száma 60 százalékkal csökkent az első negyedévben. A HR munkatársak a felszabadult időt tényleges tanácsadásra tudták fordítani, nem email megválaszolásra. Ez a projekt mutatta meg nekem, hogy a RAG értéke sokszor nem az AI-ban van, hanem abban, hogy a szakemberek végre azt csinálhatják, amiért felvették őket.

Termékkatalógusok és műszaki dokumentációk

Egy ipari alkatrész-forgalmazónál az értékesítők napi szinten kerestek műszaki paramétereket és kompatibilitási adatokat több ezer termékoldalon keresztül. Ebben a projektben az ERP adatbázisát és a gyártói PDF-eket egyaránt indexeltük. Az ajánlatadási idő átlagosan 35 percről 8 percre csökkent, mert az értékesítők egyetlen kérdéssel megkapták a szükséges specifikációkat. Ez az a típusú eredmény, ami egy vezető számára azonnal lefordítható bevételre, és amit egy McKinsey elemzés is megerősít, miszerint az információkeresés a tudásmunkás ideje legpazarlóbb felhasználásai közé tartozik.

Szerződéskezelés és jogi szövegek

Szerződésállományok kereshetővé tétele az egyik legelterjedtebb RAG alkalmazás. Egy 200 aktív szerződéssel dolgozó cég jogászainak korábban manuálisan kellett végigböngészniük a dokumentumokat, ha egy felmondási feltételre vagy egy kizárólagossági kikötésre kerestek. A vektoros keresés bevezetése után ez a feladat másodpercek alá csökkent, és az eredmény mellé mindig ott volt a forrásszöveg és az oldalszám is. A jogászok nem az AI-ban bíztak vakon, hanem visszaellenőrizni is tudtak. Az átláthatóság ebben a szegmensben nem opcionális, hanem a rendszer elfogadásának alapfeltétele.

Technikai döntések

Amit az építés előtt el kell dönteni

Egy RAG rendszer megvalósítása több ponton igényel tudatos tervezési döntést. Ezeket az indulás előtt kell végiggondolni, mert utólag nehéz visszamenni és az architektúra alapjait módosítani. Az egyik projektből tanultam meg a legélesebben, hogy az első héten feltett kérdések minősége határozza meg a végeredményt. Ahol ezt kihagytuk, ott három hónappal később kellett mindent újraépíteni.

Zárt vagy nyílt modell?

Az egyik legelső kérdés az adatvédelem szempontjából az, hogy a dokumentumok elhagyhatják-e a vállalat hálózatát. Ha a válasz nem, akkor felhő alapú embedding és generálási API nem jöhet szóba. Ebben az esetben lokálisan futtatható, nyílt forráskódú modellek (pl. Llama 3, Mistral, nomic-embed) jelentik a megoldást, amelyek a saját szerveren vagy privát cloud környezetben működnek. Ha az adat nem érzékeny, az OpenAI, az Anthropic vagy az Azure OpenAI API kényelmesebb és általában jobb minőségű eredményt ad. Az én tapasztalatom szerint a legtöbb magyar nagyvállalatnál ez az egyetlen kérdés, amelyen a projekt sorsa áll vagy bukik, ezért mindig ezzel kezdem a tervezést.

Darabolási stratégia

A chunking módja az egyik leginkább alulbecsült technikai döntés. Fix méretű darabolásnál az a veszély, hogy egy mondat félbe szakad, és a kontextus elvész. Szemantikus darabolásnál a rendszer megpróbálja a természetes gondolati egységeket egyben tartani, de ez számításigényesebb. Egy szerződésnél bekezdésenként célszerű darabolni, míg egy termékkatalógusnál termékenként. Ez az a döntés, ahol a legtöbb projekt minőségi hibáit el lehet kerülni, ha előre foglalkozunk vele. Az általam épített rendszerekben a legtöbb korai kudarcot rossz darabolási stratégia okozta.

Hibrid keresés

A tisztán vektoros keresés nem mindig a legjobb. Ha valaki egy konkrét cikkszámra vagy egy személynévre keres, a kulcsszóalapú (BM25) keresés pontosabb lehet. A legtöbb érett RAG implementáció ma hibrid megközelítést alkalmaz, vagyis a vektoros és a kulcsszó alapú keresés eredményeit rangsorolva kombinálja. Ez a technika re-ranking vagy reciprocal rank fusion néven ismert a szakirodalomban, és az általam épített rendszerekben szinte mindig ez a beállítás adja a legjobb végeredményt.

Minőség és megbízhatóság

Hogyan mérjük, hogy a rendszer valóban jól működik?

A RAG rendszer bevezetésének egyik nehézsége, hogy a minőség nem nyilvánvaló. A felhasználó kap egy választ, de honnan tudja, hogy az helyes? Azt tapasztaltam, hogy ez az a pont, ahol a legtöbb belső projekt elveszíti a felhasználók bizalmát. A rendszer magabiztosan válaszol, de senki sem tudja, mennyire bízhat meg benne. Erre az értékelésre külön módszertan létezik, amit az iparágban RAG evaluation vagy RAGAS (Retrieval Augmented Generation Assessment) keretrendszerként ismernek.

Az értékelés négy fő dimenziója a következő.

• Kontextus-relevancia. A visszakeresett dokumentumdarabok tényleg kapcsolódnak-e a kérdéshez?
• Hűség (faithfulness). A generált válasz tényleg az adott kontextusból következik-e, vagy a modell „kitalál” valamit?
• Válasz-relevancia. A végső válasz tényleg megválaszolja-e az eredeti kérdést?
• Kontextus-visszahívás. Minden releváns információt megtalált-e a rendszer, vagy kihagyott lényeges részeket?

A gyakorlatban azt javaslom, hogy állíts össze egy tesztkészletet 50-100 kérdésből, amelyeknek ismert a helyes válasza. Ezt a tesztkészletet rendszeresen lefuttatva objektív képet kapunk arról, hogy az indexelési vagy prompt változtatások javítottak-e a minőségen. Ez a lépés sok projektnél kimarad, és aztán a rendszer „jól érzi magát“, de valójában nem mérhető, mennyire megbízható. Ahol elvégeztük ezt az értékelési lépést, ott mindig kiderült valami meglepő gyengeség, amit korán orvosolni tudtunk.

Tipikus buktatók

Hol csúszik félre a legtöbb belső tudásbázis-projekt?

A RAG projektek egy jelentős része nem technikai okokból vall kudarcot, hanem szervezeti és adatminőségi problémák miatt. Ezekkel szembenézni az indulás előtt sokkal olcsóbb, mint a bevezetés után. Az alábbi három buktató szinte minden projektnél előkerült, amelynél részt vettem.

Rossz minőségű forrásadatok

Ha a dokumentumok elavultak, inkonzisztensek vagy rosszul struktúráltak, a RAG rendszer is rossz válaszokat fog adni. Az egyik ügyfelemnél feltérképeztük a potenciális dokumentumállományt, és kiderült, hogy a szabályzatok 30 százaléka 3 évnél régebbi volt, és már nem volt érvényes. Az AI ezekből az elavult verziókból is válaszolt volna, ha nem szűrjük ki őket. A „garbage in, garbage out“ elve itt is pontosan érvényes, és ezt az auditot mindig az indexelés előtt kell elvégezni.

Nincs dokumentumkezelési folyamat

A RAG rendszer nem egyszeri projekt, hanem élő infrastruktúra. Ha nincs meghatározva, ki és mikor frissíti az indexet egy új szabályzat kiadásakor, a rendszer fokozatosan elavul. Ez a felelős kijelölése és az automatikus szinkronizálás beállítása nélkül nem működik hosszú távon. Az egyik ügyfélnél fél évvel a bevezetés után derült ki, hogy az indexben még a régi bérezési szabályzat szerepelt. Ez a fajta meglepetés rombolja a bizalmat, és utólag sokkal nehezebb helyreállítani.

Túl tág hatókör az első körben

A legsikeresebb bevezetések általában egyetlen, jól körülhatárolható dokumentumcsoporttal indulnak. Például csak a HR kézikönyvvel, vagy csak az aktív szerződésekkel. Ha valaki az összes vállalati dokumentumot egyszerre akarja indexelni, a projekt elnyúlik, a minőségbiztosítás elvész, és a felhasználók bizalma megrendül, mielőtt a rendszer valóban használhatóvá válik. Az általam levont tanulság az, hogy jobb egy területen tökéletesen teljesíteni, mint öt területen közepesen.

Következő lépés

Hogyan érdemes elkezdeni?

Egy RAG projekt nem igényel fél éves előkészítést. Egy jól körülhatárolt dokumentumcsoporton prototípus szinten 2-4 hét alatt lehet éles eredményt mutatni. Azt tapasztaltam, hogy az induláshoz ezek a kérdések a legkritikusabbak, és aki ezeket előre megválaszolja, az a projekt felét már le is tudta.

• Melyik az a dokumentumgyűjtemény, ahol a legtöbb időt veszítik most a munkatársak keresésre?
• Kik lennének a rendszer napi szintű felhasználói, és milyen kérdéseket tennének fel?
• Az adatok elhagyhatják-e a vállalat rendszerét, vagy csak lokálisan szabad dolgozni?
• Ki felelős a dokumentumok naprakészségéért jelenleg?

Ha ezekre vannak válaszok, a technikai megvalósítás már jóval tisztább lesz. A legtöbb vállalatnál nem a technológia a szűk keresztmetszet, hanem az, hogy pontosan melyik problémát akarják megoldani és kinek. Amikor ezt a négy kérdést az első workshopon megválaszoljuk, rendszerint már a teremben látszik, hogy ki fog a projekt élére állni, és mi lesz az első valódi win.