Miért más a helyi és a felhő-alapú RAG?

Egy csendes hiba, amelyről szinte senki nem beszél

Mi az a RAG, és miért fontos?

A RAG (Retrieval-Augmented Generation), azaz visszakereséssel bővített szöveggenerálás az egyik leggyakrabban alkalmazott módszer arra, hogy egy AI-rendszer ne csupán általános tudásból válaszoljon, hanem konkrét, feltöltött dokumentumokból dolgozzon. Az ügyvédi irodában ez a saját szerződéseket, törvényszövegeket, belső irányelveket jelenti. A könyvelőnél a jogszabályokat, adóköröket, ügyféldossziékat. Az orvosnál a protokollokat, kezelési irányelveket, kórtörténeteket.

A RAG-rendszer két egymásba kapcsolódó részből áll. Az első a visszakereső egység: ez a dokumentumokat vektoros formában tárolja – úgynevezett beágyazásokként -, és egy beérkező kérdéshez megkeresi a leginkább illő szövegrészleteket. A második a generáló modell: ez a visszakeresett részletek alapján összefüggő, természetes nyelvű választ állít össze. Mindkét részt AI-modell hajtja – és ez az a pont, ahol a felhőalapú és a helyi megoldás között egy kevéssé tárgyalt, mégis döntő különbség keletkezik.

Amikor valaki azt hallja, hogy ‘RAG-alapú rendszer’, általában az AI-t látja maga előtt: a generáló modellt, amely a kérdésre válaszol. A visszakereső rész – a beágyazó modell és a vektoros adatbázis – szinte soha nem kerül előtérbe. Ez a figyelmetlenség az, amely a felhőalapú rendszereknél egy konkrét, mérhető, de nehezen észrevehető kockázatot hoz létre.

A felhő-RAG rejtett kockázata: model version drift

Ha egy RAG-rendszer felhőalapú API-ra épül (az OpenAI, Anthropic, Google vagy bármely más nagyobb szolgáltató valamely végpontjára), akkor a rendszer mögött futó modellek bármikor, a fejlesztő tudta és hozzájárulása nélkül megváltozhatnak. Ez nem elméleti veszély: a nagy szolgáltatók rendszeresen frissítik a modelleket a háttérben. A ‘-latest’ vagy ‘legújabb’ jelzésű végpontok nem garantáltan ugyanazt a modellverziót futtatják hétről hétre.

Ennek neve a szakirodalomban: model version drift, azaz modellverzió-sodródás. Ez a jelenség a generáló modellnél is problémát okozhat, de a beágyazó modellnél különösen veszélyes, mert következménye egy másik, sokkal nehezebben észrevehető hibamód: az embedding drift.

A RAG-rendszer a dokumentumokat vektoros formában tárolja. Ezeket a vektorokat – más szóval beágyazásokat – egy beágyazó modell hozza létre: ez alakít egy mondatot vagy bekezdést egy több száz dimenziós számvektorrá. A vektortér geometriájában egymáshoz közel elhelyezkedő szövegek tartalmilag is hasonlónak számítanak: ez az alapja annak, hogy a rendszer megtalálja a kérdéshez leginkább illő dokumentumrészleteket.

Ha a beágyazó modellt a felhőszolgáltató frissíti – akár csak egy apró hangsúlyeltolódással -, az ugyanarra a szövegre (többé-kevésbé) más vektort fog adni, mint korábban. Ez azt jelenti, hogy a januárban feltöltött és beágyazott dokumentumok más geometriai ‘térben élnek’, mint a szeptemberben feltöltöttek, ha a beágyazó modell közben megváltozott. A vektortér belsőleg inkonzisztenssé válik: a régi dokumentumok régi koordinátákon találhatók, az újak egy kicsit eltolt koordinátákon.

A rendszer ettől nem áll le, sőt, semmiféle hibaüzenetet nem ad. Egyszerűen csak a visszakeresési pontosság romlik csendesen. Olyan kérdésekre, amelyekre korábban pontosan a releváns dokumentumrészletet hozta vissza, most kevésbé illő szövegeket talál. A generáló modell ezt a pontatlan bemenetet kapja, és ennek megfelelő, pontatlan választ ad. A felhasználó esetleg hónapokig észre sem veszi: egészen addig, amíg egy téves összefoglalón, egy hibás hivatkozáson vagy egy kihagyott szerződéses kikötésen nem ütközik ki a következmény.

Hogyan védekeznek ez ellen a felhőalapú rendszerek?

A komoly, produkciós felhő-RAG-rendszerek fejlesztői ismerik ezt a problémát, és próbálnak is védekezni ellene. A legelterjedtebb módszer: minden egyes dokumentum-chunk metaadataiban tárolják, hogy melyik beágyazó modellverzióval lettek feldolgozva. Lekérdezéskor a rendszer ellenőrzi, hogy az aktuálisan futó modell verziója megegyezik-e a tároláskor használtéval. Ha nem egyezik, az érintett dokumentumokat újra be kell ágyazni az aktuális modellel.

Ez a védekező mechanizmus technikai szempontból helyes megközelítés, de van egy mellékköltsége, amelyet ritkán kommunikálnak. Az újrabeágyazás időt, számítási kapacitást és – API-alapú rendszernél – közvetlen pénzügyi költséget jelent. Egy nagy, több ezer dokumentumból álló jogi vagy orvosi korpusznál az újrabeágyazás nem percek, hanem órák kérdése. Eközben a rendszer vagy leáll, vagy a régi, inkonzisztens vektortérrel dolgozik tovább – mindkét esetben kompromisszummal.

A helyi rendszernél erre a védekező mechanizmusra nincs szükség. Nem azért, mert jobb a védekezés, hanem mert a probléma strukturálisan nem létezik: a modell verziója nem változik magától.

A helyi RAG: ami egyszer letöltődik, az statikus marad

Az ArkeoAI-rendszer teljesen helyi (offline) modelleket futtat. A modellsúlyok (mind a visszakereső beágyazó modellé, mind a generáló modellé) egyszer letöltődnek, és a gépen maradnak. Nincs mögöttük API-kapcsolat, nincs háttérfrissítés, nincs verzióváltás a rendszer tulajdonosának tudta nélkül.

Ez azt jelenti a gyakorlatban, hogy ha ma pontosan az adott beágyazó modellt, az adott generáló modellt futtatja a rendszer, akkor holnap, jövő héten és akár jövőre is pontosan ugyanezt fogja futtatni, hacsak a tulajdonos maga nem dönt a frissítésről. Szaknyelven kifejezve a “dokumentumok vektorai konzisztensek maradnak”. Az a vektortér, amelybe januárban feltöltötték a szerződéseket, szeptemberben pontosan ugyanolyan koordinátarendszert jelent, mint januárban. A visszakeresési minőség nem romlik el csendben.

Ez azonban nem feltétlenül azt jelenti, hogy a helyi modell minden tekintetben felülmúlja a felhőalapút. Csak azt jelenti, hogy kiszámíthatóbb. Egy ügyvédi vagy orvosi munkafolyamatban, ahol az eredmény minőségének stabilitása nem kívánság, hanem szakmai követelmény, ez döntő különbség és ezt a különbséget szinte soha nem emelik ki a felhőszolgáltatók marketinganyagaiban.

Egy szemléletes hasonlat az irodai valóságból

Képzelje el, hogy az iroda évek óta ugyanabban az épületben működik, és mindenki pontosan tudja, melyik polcon, melyik szekrényben találhatók az egyes ügyfelek dossziéi. Egy nap – anélkül, hogy bárki szólna – valaki átrendezi a szekrényeket. Nem feltűnően, csak kicsit: a polgári jogi ügyek polca egy emelettel feljebb kerül, a kereskedelmi jogi ügyeké egy emelettel lejjebb. A dosszié megvan, csak kicsit máshol.

Az ügyvéd vagy az asszisztens ezt eleinte nem veszi észre, megszokásból nyúl a régi helyre, és általában talál is valamit. De nem mindig pontosan azt, amit keres. Egyes esetekben a legfontosabb precedenst tartalmazó mappa egy másik szekrénybe került, és nem kerül elő a kereséskor. Az iroda dolgozik tovább, de a visszakeresési pontosság csendben romlott.

Ez pontosan az, ami egy felhőalapú RAG-rendszerben bekövetkezhet, ha a beágyazó modell frissítés után kicsit másképp ‘rendezi el’ a dokumentumokat a vektortérben. A helyi, offline rendszerben a ‘szekrények’ soha nem mozdulnak el maguktól – épp ez az a garancia, amelyet az architektúra nyújt.

A kontextusablak: a másik tényező, amelyről senki nem kérdez

A RAG-rendszer teljesítményét nemcsak a beágyazó modell stabilitása befolyásolja, hanem a generáló modell kontextusablakának mérete is és ez szintén egy olyan tényező, amelyet a felhőszolgáltatók ritkán kommunikálnak előre.

A kontextusablak azt határozza meg, hogy a generáló modell egyszerre hány szöveg-tokent képes ‘látni’ és feldolgozni. Ha a visszakereső egység egy hosszú dokumentumból több releváns részletet hoz vissza, de azok együttes hossza meghaladja a kontextusablak méretét, a modell egyszerűen levágja a felesleget – megint csak csendben, figyelmeztetés nélkül. A felhasználó azt hiszi, hogy a modell az összes releváns anyag alapján válaszolt, miközben valójában csak a dokumentum egy részét ‘látta’.

Az ArkeoAI-rendszernél a kontextusablak méretét mi magunk határozzuk meg és rögzítjük – az ügyfél munkafolyamatának megfelelően, nem a szolgáltató alapértelmezett beállítása szerint. Ez is a kontroll egyik vetülete: nem az a kérdés, hogy ‘mit enged meg a szolgáltató’, hanem az, hogy ‘mire van szüksége ténylegesen az ügyfélnek’.

Miért nem hallani erről?

Az embedding drift és a model version drift jelensége nem titkos, a RAG-szakirodalomban jól dokumentált, a komolyabb fejlesztői közösségekben ismert probléma. Mégsem kerül szóba a felhőszolgáltatók ügyféltájékoztatóiban, értékesítési prezentációiban vagy marketinganyagaiban.

Ennek oka egyszerű: a probléma láthatatlan. Nem generál hibaüzenetet, nem okoz leállást, nem küld figyelmeztetést. Csak lassan, fokozatosan rontja a rendszer visszakeresési minőségét egészen addig, amíg valaki rá nem jön, hogy az AI ‘másképp viselkedik, mint régen’. Addigra azonban rendszerint már hetek vagy hónapok teltek el, és a visszaesés okát és pontos kezdetét nehéz visszakövetni.

Az ArkeoAI megközelítése ennek a problémának a tudatos elkerülésén alapul: nem szofisztikált monitoring-eszközökkel, hanem architektúrával. Ami nem csatlakozik a hálózathoz, az nem tud felülírni egy modellt. Ez nem kompromisszum a kényelem és a biztonság között, hanem egy olyan döntés, amelyet az ügyfél szakmai követelményei indokolnak.