A National University of Singapore kutatói egy új megközelítést mutattak be a hosszú horizontú problémák memóriakezelésére: a MRAgent (Memory Reasoning Architecture for LLM Agents) nem a hagyományos, statikus "retrieve-then-reason" sémát követi, hanem aktív, asszociatív memóriarekonstrukciót épít be magába a nagy nyelvi modell (LLM) érvelési folyamatába. A cél az, hogy a hagyományos lekérdező pályák hamar megtelnek irreleváns információval és értelmezési zajjal, míg az MRAgent dinamikusan gyűjt és finomít nyomokat, ezáltal csökkentve a tokenfelhasználást és a futtatási költségeket.
Miért buknak meg a passzív visszakeresők hosszú távon?
A klasszikus pipeline-okban dokumentumokat vektoros kereséssel vagy gráfotérképen keresztül hozzák be, majd az LLM-en hozzák meg a döntést. A kutatók három jelentős szűk keresztmetszetre hívták fel a figyelmet:
- A rendszer nem tud közben módosítani lekérdezési stratégiáján: ha az ügynök egy dokumentumban hiányzó, de kritikus jelre akad, nem tud új, célzott lekérdezést indítani.
- A rögzített hasonlósági pontszámok és előre definiált gráfbővítések felületes találatokat hoznak, amelyek elárasztják az LLM kontextusablakát zajjal.
- A rendszerek erősen támaszkodnak előre felépített struktúrákra (top-k, statikus relevanciafüggvények), ami rugalmatlanságot eredményez hosszú, előre nem látható interakciók feldolgozásában.
A szerzők szerint a megoldás egy "aktív és asszociatív rekonstrukciós folyamat" lehet, amelyet a kognitív idegtudomány inspirált: a memóriahelyreállítás sorozatos lépésekből áll, kezdetben kis, specifikus nyomokkal (például név, hely, esemény), majd ezek alapján egymás után gyűjtött bizonyítékok építik fel a teljes emlékképet.
Hogyan valósítja meg az MRAgent az aktív memóriarekonstrukciót?
Az MRAgent memóriát nem statikus adattárként kezeli, hanem interaktív környezetként. Bonyolult lekérdezés feldolgozásakor az LLM-et használja arra, hogy több jelölti lekérdezési útvonalat fedezzen fel a strukturált memóriagráfon. Minden lépésben az LLM értékeli a begyűjtött közbenső bizonyítékokat, és ezek alapján iteratívan optimalizálja a keresést: új lekérdezési kényszereket következtet, a leginformatívabb utakra fókuszál, és eltávolítja az irreleváns ágakat. Ennek köszönhetően mélyebben eltemetett információkat tud előhívni anélkül, hogy megtöltené a kontextusablakot felesleges adatokkal.
A hatékony, skálázható feltáráshoz az MRAgent egy "Cue-Tag-Content" szerkezetet használ, amely három típusú csomópontból épül fel:
- Cues: finomgranuláris kulcsszavak, entitások vagy kontextuális attribútumok, amelyeket felhasználói interakciókból vonnak ki.
- Tags: szemantikai hidak, amelyek összegzik a Cues és a Content közötti relációkat.
- Content: a tényleges tárolt memóriaegységek, több granularitási szinten (például epizodikus események és szemiantikai, tartós tények vagy preferenciák).
Ez a struktúra egy kétlépcsős lekérdezési folyamatot tesz lehetővé: az LLM először a Cues–>Tags kapcsolatokon navigál, és a Tag-ek rövid összegzései alapján dönti el, mely ágak érdemesek részletes tartalom-lekérésre. Így a költséget és a prompt tokeneket jelentős mértékben meg lehet takarítani.
Példaként a cikk bemutat egy tipikus lekérdezést: "Hogyan használta Nate a nyeremény pénzét, amikor megnyerte a harmadik videojáték-bajnokságát?". Az MRAgent először kinyeri a kezdő cue-kat (például "Nate", "video game tournament", "win"), majd a gráfon keresztül Tag-eket vizsgál (például "Tournament Victory" vs. "Tournament Participation"), kiválasztja a releváns Tag-et, lekéri a kapcsolódó epizodikus tartalmak közül a releváns epizódot, frissíti cue-jait (például "tournament earnings") és újraindul a feltárás, amíg elegendő bizonyítékot nem gyűjt a válaszhoz (például: "Nate megtakarította a pénzt").
Teljesítmény ipari benchmarkokon
Az MRAgent-et más agentikus memóriakeretrendszerekkel vetették össze, köztük A-MEM, MemoryOS, LangMem és Mem0 rendszerekkel. A tesztek a LoCoMo és a LongMemEval benchmarkokra irányultak, amelyek hosszú távú feladatokra és több tucat munkameneten, több száz dialógusfordulón átívelő lekérdezésekre mérik az ügynökök képességeit. A háttérmodellek Gemini 2.5 Flash és Claude Sonnet 4.5 voltak.
Az eredmények szerint az MRAgent minden összehasonlított alappal szemben jelentős előnyt mutatott mindkét modell és minden kérdéstípus esetén. Különösen a költséghatékonyság terén volt kiemelkedő: a LongMemEval tesztekben az MRAgent prompt token fogyasztása mindössze 118 ezer token volt minta-enként, míg A-MEM 632 ezer token, a LangMem pedig 3,26 millió tokent használt fel egy-egy lekérdezésre. A futtatási idő tekintetében az MRAgent körülbelül megfelezte az A-MEM futási idejét: 1 122 másodpercről 586 másodpercre csökkent.
A hatékonyság alapja az on-demand működés: a Tag-ek értékelése és az irreleváns utak korai elvetése előtt megakadályozza a nagyméretű tartalmak felesleges lehívását. Emellett az ügynök magától eldönti, mikor gyűjtött elegendő kontextust, így elkerüli a redundáns feltárást.
Megvalósítási szempontok és fejlesztői munka
Az MRAgent hatékonysága ellenére a Cue-Tag-Content szerkezetet fel kell építeni, mielőtt az ügynök lekérdezhetné azt. A fejlesztőknek meg kell tervezniük a memóriadatbázis architektúráját úgy, hogy az LLM hatékonyan tudjon asszociatív elemek között navigálni és irreleváns ágakat elvetni anélkül, hogy a számítási költségek exponenciálisan növekednének.
A kutatók azonban hangsúlyozzák, hogy a fejlesztőknek nem kell kézzel címkézniük vagy strukturálniuk az adatokat. Az MRAgent egy automatikus distillációs csővezetéssel érkezik, amely LLM-eket használ a nyers interakciós előzmények feldolgozására és a memóriagráf automatikus feltöltésére. A fejlesztő feladata így inkább az automatizált beolvasó pipeline implementálása és üzemeltetése: háttérfeladatok vagy streaming munkafolyamatok, amelyek prompt-sablonokkal dolgozzák fel a nyers felhasználói interakciókat és kinyerik a metadata-kat, majd elmentik azokat a grádadatbázisba. A szerzők szerint ez a beépítési fázis viszonylag könnyű és szándékosan egyszerűen tartották.
Hozzáférés
A kutatók közzétették a kódot GitHubon, lehetővé téve a fejlesztők számára, hogy megismerjék a keretrendszer részleteit és kiinduló pontot kapjanak a saját implementációikhoz.
További részletek és a kód GitHubon érhetők el a szerzők közzétételével.
