Az ügynök memóriája és a Redis

Mi a Redis

A Redis egy memóriában futó, nagyon gyors kulcs-érték adattároló. A neve a Remote Dictionary Server rövidítése, és nagyjából ezt is csinálja. Kulcsokhoz rendel értékeket, ahogy egy szótár a szavakhoz a jelentést, csak ezeket az adatokat nem a lassú lemezen, hanem a szerver memóriájában tartja. Ezért egy olvasás vagy egy írás töredék másodperc alatt lezajlik. Egy AI rendszerben ez a sebesség nem luxus, hanem alapkövetelmény, mert az ügynök szinte minden lépésénél újra és újra el kell érnie a folyamat aktuális állapotát, és ha ez lassú, az egész rendszer lassú lesz.

A Redis-t szokták a modern stack unalmas, de nélkülözhetetlen részének nevezni. Nem látványos, nem róla szólnak a bemutatók, mégis rengeteg AI alkalmazás épít rá a háttérben. Pontosan azért, mert egy egyszerű, jól bevált eszköz egy nagyon konkrét feladatra. Amikor gyorsan kell elérni egy kis adatot, ami éppen most fontos, de holnap már nem, a Redis erre való.

Miért van szükség külön memóriára

Sokan azt gondolják, hogy a nyelvi modell emlékszik a beszélgetésre. Nem emlékszik. A modell minden egyes híváskor csak azt látja, amit abban a hívásban megkap, és amint válaszolt, a saját szempontjából elfelejti az egészet. Ha egy ügynök három vagy tíz lépésen keresztül dolgozik egy feladaton, akkor a korábbi lépések eredményét, a felhasználó korábbi kérdéseit és a köztes döntéseket valahol tárolni kell, majd a következő lépésnél visszaadni a modellnek. Ez a valahol az ügynök memóriája, és ez nem a modell belsejében van, hanem egy külön rendszerben mellette.

Erre a feladatra elvileg sok minden megfelelne. A gond az, hogy ezt az állapotot nagyon gyakran és nagyon gyorsan kell elérni. Ha minden lépésnél egy hagyományos, lemezre író adatbázishoz fordulnánk, az lassabb lenne, mint amennyit az élmény elbír. A Redis pont ezt oldja meg, mert a memóriában tart mindent, és így a válaszidő alacsony marad akkor is, ha egyszerre sok beszélgetés fut párhuzamosan.

Érdemes tisztázni, mi tartozik ide és mi nem. A modell egy adott híváskor egy bizonyos mennyiségű szöveget lát, ez a kontextusablak, és ebbe véges mennyiség fér bele. Az ügynök memóriája ennél tágabb fogalom. A Redis-ben az az állapot van, amiből lépésről lépésre összeállítjuk, hogy a modell éppen mit lásson. Nem a modell gondolkodik tovább a háttérben, hanem mi adjuk vissza neki minden körben a lényeget abból, ami korábban történt. Ez a különbség fontos, mert világossá teszi, hogy az emlékezés nem a modell képessége, hanem a köré épített rendszer feladata.

A Redis három szerepe az ügynök körül

A gyakorlatban a Redis nem egyetlen dolgot csinál, hanem több, egymáshoz közeli szerepet tölt be ugyanabban a rendszerben. Érdemes ezeket külön néven ismerni, mert a tervezéskor eldönteni, hogy egy adott adat melyik szerephez tartozik, sok későbbi hibát megelőz. Az alábbi három a leggyakoribb.

Egy több lépéses ügyfélszolgálati ügynök

Nézzünk egy fiktív magyar példát. Legyen egy webáruház, nevezzük Rétközi Bolt Kft.-nek, és a honlapján egy AI ügyfélszolgálati ügynök válaszol a vevőknek. Egy vevő beír, hogy hol van a csomagja. Az ügynök először visszakérdez a rendelésszámra, majd amikor megkapja, lekérdezi a szállító rendszerét, végül tájékoztatja a vevőt a várható időpontról. Ezután a vevő visszakérdez, hogy át tudja-e irányítani a csomagot egy másik címre.

Ez négy külön lépés, és mindegyiknél emlékezni kell arra, ami korábban történt. Amikor a vevő az átirányításról kérdez, az ügynöknek tudnia kell, melyik rendelésről beszélgetnek, hogy nem kell újra elkérnie a rendelésszámot. Ezt a köztes tudást a Redis tárolja a session-ben, a beszélgetés kulcsához rendelve. Ha ugyanaznap több vevő is ugyanarról a futárszolgálati késésről kérdez, a szállító rendszerének korábbi válaszát a cache-ből lehet visszaadni, nem kell újra lekérdezni. A várható időpontról szóló értesítő emailt pedig egy feladatsorba lehet tenni, ahonnan egy másik komponens a maga idejében elküldi.

Mi kerüljön a gyors tárba és mi a tartós adatbázisba

A legfontosabb tervezési döntés az, hogy melyik adat kerül a gyors, mulandó tárba, és melyik a tartós adatbázisba. A Redis a memóriában tart mindent, ezért nagyon gyors, de ez azt is jelenti, hogy ami itt van, azt alapból nem szabad örökre megtartandónak tekinteni. Ide az kerül, ami éppen most fontos és utána eldobható, vagy bármikor újraszámolható. Ami viszont hosszú távon kell, amit vissza kell tudni keresni, vagy amit egyszerűen nem szabad elveszíteni, az a tartós adatbázisba való, például a maradandó PostgreSQL táblákba. A kettő nem verseng egymással, hanem együtt dolgozik.

Mire figyelj a tervezésnél

Néhány kérdésre érdemes már az elején jó választ adni. Az első az adatmegőrzés. A Redis a memóriában dolgozik, így alapesetben ami ott van, az elveszhet egy újraindításnál, hacsak nem állítunk be tudatosan mentést a lemezre. Ezért fontos, hogy semmi olyat ne bízzunk kizárólag rá, aminek a végleges helye máshol van. Ehhez kapcsolódik a lejárat is. A Redis-ben minden kulcshoz megadható, hogy meddig éljen, és ez az egyik legerősebb tulajdonsága. Egy beszélgetés állapotát például beállíthatjuk úgy, hogy egy idő után magától eltűnjön, így a memória nem tömődik el a régi, már senkit sem érdeklő adattal.

A második a méretezés. A memória véges és drágább, mint a lemez, ezért nem tehetünk bele mindent korlátlanul. Végig kell gondolni, mennyi párhuzamos beszélgetést szolgál ki a rendszer, mekkora egy-egy session, és mennyi ideig kell megtartani. A harmadik pedig a szereptisztaság. Ha egy adatról nem tudjuk megmondani, hogy mulandó vagy tartós, akkor valószínűleg még nem gondoltuk végig, hova való. Ez a döntés eleinte apróságnak tűnik, később viszont sokba kerülhet, ha rosszul dőlt el.

A vezetői tanulság

Nem kell kódot írni ahhoz, hogy egy vezető jól döntsön ebben a témában. Elég egyetlen dolgot megjegyezni. Amikor egy AI ügynök arról szól, hogy több lépésen keresztül, egy beszélgetés vagy egy folyamat során emlékezzen a korábbi lépésekre, akkor a rendszer memóriája nem magától adódik a modellből. Ezt külön meg kell tervezni és külön kell építeni, jellemzően egy egyszerű, gyors infrastruktúrával, mint a Redis. Ez az a fajta láthatatlan alkatrész, ami nem kerül bele a bemutatóba, mégis nélküle az egész széteshet.

Ha a szervezet AI ügynökön gondolkodik, érdemes már a tervezés elején feltenni a kérdést, hogy hol lesz a memória, mi kerül a gyors tárba, mi a tartós adatbázisba, és meddig élnek az adatok. Ezek nem technikai apróságok, hanem olyan döntések, amelyek meghatározzák, mennyire lesz megbízható és mennyibe kerül majd üzemeltetni a rendszert.