Standaard RAG-pijplijnen gaan kapot wanneer bedrijven ze proberen te gebruiken voor langdurige inzet van LLM-agenten met meerdere sessies. Dit is een cruciale beperking naarmate de vraag naar aanhoudende AI-assistenten groeit.
xGeheugeneen nieuwe techniek ontwikkeld door onderzoekers van King’s College London en het Alan Turing Institute lost dit op door gesprekken te organiseren in een doorzoekbare hiërarchie van semantische thema’s.
Experimenten tonen aan dat xMemory de antwoordkwaliteit en het redeneren op lange termijn in verschillende LLM’s verbetert, terwijl de inferentiekosten worden verlaagd. Volgens de onderzoekers daalt dat tokengebruik van ruim 9.000 naar ongeveer 4.700 tokens per zoekopdracht, vergeleken met bestaande systemen voor sommige taken.
Voor zakelijke toepassingen in de praktijk, zoals gepersonaliseerde AI-assistenten en beslissingsondersteunende tools voor meerdere sessies, betekent dit dat organisaties betrouwbaardere, contextbewuste agenten kunnen inzetten die in staat zijn om een samenhangend langetermijngeheugen in stand te houden zonder de rekenkundige overhead te exploderen.
RAG is hier niet voor gebouwd
Bij veel zakelijke LLM-toepassingen is de kritische verwachting dat deze systemen consistentie en personalisatie zullen behouden tijdens lange interacties die meerdere sessies duren. Om deze langetermijnredenering te ondersteunen, is een gebruikelijke aanpak het gebruik van standaard-RAG: eerdere dialogen en gebeurtenissen opslaan, een vast aantal topmatches ophalen op basis van geneste gelijkenis, en deze samenvoegen in een contextvenster om antwoorden te genereren.
Traditioneel wordt RAG echter gebouwd voor grote databases waarbij de opgehaalde documenten heel verschillend zijn. De grootste uitdaging is het eruit filteren van volledig irrelevante informatie. Het geheugen van een AI-agent is daarentegen een begrensde en continue stroom van gesprekken, wat betekent dat de opgeslagen stukjes gegevens sterk gecorreleerd zijn en vaak bijna duplicaten bevatten.
Om te begrijpen waarom simpelweg het contextvenster vergroten niet werkt, kun je overwegen hoe standaard RAG omgaat met een concept als citrusvruchten.
Stel je voor dat een gebruiker veel gesprekken heeft gevoerd waarin dingen zijn gezegd als ‘Ik hou van sinaasappelen’, ‘Ik hou van mandarijnen’, en diverse andere gesprekken over wat telt als citrusvrucht. Traditionele RAG kan deze allemaal als semantisch compact behandelen en soortgelijke “citrusachtige” extracten blijven ophalen.
“Als het ophalen wordt ingeklapt op het cluster dat zich het dichtst bij de nestruimte bevindt, kan de agent veel zeer vergelijkbare passages over voorkeuren krijgen, terwijl hij de categorie feiten mist die nodig zijn om de eigenlijke vraag te beantwoorden,” vertelde Lin Gui, co-auteur van het artikel, aan VentureBeat.
Een veel voorkomende oplossing voor technische teams is het toepassen van bijsnijden of compressie na het ophalen om de ruis weg te filteren. Deze methoden gaan ervan uit dat de gevonden passages zeer divers zijn en dat irrelevante ruispatronen netjes kunnen worden gescheiden van bruikbare feiten.
Deze aanpak schiet tekort in het geheugen van de gesprekspartner, omdat de menselijke dialoog ‘temporeel complex’ is, schrijven de onderzoekers. Het gespreksgeheugen is sterk afhankelijk van kernreferenties, ellipsen en strikte tijdlijnafhankelijkheden. Vanwege deze onderlinge verbondenheid verwijderen traditionele bijsnijdtools vaak per ongeluk belangrijke delen van een gesprek, waardoor de AI geen essentiële context meer heeft die nodig is om nauwkeurig te redeneren.
Waarom de oplossing die de meeste teams zoeken de zaken alleen maar erger maakt
Om deze beperkingen te overwinnen, stellen de onderzoekers een verschuiving voor in de manier waarop het geheugen van agenten wordt opgebouwd en doorzocht, wat zij omschrijven als ‘ontkoppeling naar aggregatie’.
In plaats van gebruikersvragen rechtstreeks te vergelijken met onbewerkte, overlappende chatlogboeken, organiseert het systeem het gesprek in een hiërarchische structuur. Ten eerste ontkoppelt het de gespreksstroom in afzonderlijke, op zichzelf staande semantische componenten. Deze individuele feiten worden vervolgens samengevoegd tot een structurele hiërarchie van thema’s op een hoger niveau.
Wanneer de AI informatie moet oproepen, zoekt hij top-down door de hiërarchie, van thema’s tot semantiek en uiteindelijk naar ruwe fragmenten. Deze aanpak vermijdt redundantie. Als twee dialoogfragmenten vergelijkbare inbedding hebben, is het onwaarschijnlijk dat het systeem ze samen ophaalt als er verschillende semantische componenten aan zijn toegewezen.
Om deze architectuur te laten slagen, moet deze twee essentiële structurele eigenschappen in evenwicht brengen. De semantische componenten moeten voldoende gedifferentieerd zijn om te voorkomen dat de AI overtollige gegevens ophaalt. Tegelijkertijd moeten aggregaties op een hoger niveau semantisch trouw blijven aan de oorspronkelijke context om ervoor te zorgen dat het model nauwkeurige antwoorden kan genereren.
Een hiërarchie met vier niveaus die het contextvenster verkleint
De onderzoekers ontwikkelden xMemory, een raamwerk dat gestructureerd geheugenbeheer combineert met een adaptieve top-down zoekstrategie.
xMemory organiseert de ruwe gespreksstroom voortdurend in een gestructureerde hiërarchie van vier niveaus. Onderaan staan de onbewerkte berichten, die eerst worden samengevat in aaneengesloten blokken die ‘afleveringen’ worden genoemd. Uit deze episoden distilleert het systeem herbruikbare feiten als semantiek die de centrale langetermijnkennis scheidt van herhaalde chatlogs. Ten slotte wordt de gerelateerde semantiek gegroepeerd in thema’s op hoog niveau, zodat ze gemakkelijk doorzoekbaar zijn.
xMemory gebruikt een speciale objectieve functie om voortdurend te optimaliseren hoe deze elementen worden gegroepeerd. Dit voorkomt dat categorieën te uitgebreid worden, wat het zoeken vertraagt, of te gefragmenteerd raken, wat het vermogen van het model om bewijsmateriaal te verzamelen en vragen te beantwoorden belemmert.
Wanneer xMemory een prompt ontvangt, voert xMemory een top-down-ophaalactie uit in deze hiërarchie. Het begint op thematisch en semantisch niveau en selecteert een gevarieerde, compacte reeks relevante feiten. Dit is van cruciaal belang voor toepassingen in de echte wereld, waarbij voor zoekopdrachten van gebruikers vaak beschrijvingen over meerdere onderwerpen moeten worden verzameld of gerelateerde feiten aan elkaar moeten worden gekoppeld voor complexe, multi-hop redeneringen.
Als het systeem eenmaal over dit hoogwaardige skelet van feiten beschikt, beheert het de redundantie door middel van wat de onderzoekers ‘Uncertainty Gating’ noemen. Er wordt alleen dieper ingegaan op het fijnere, ruwe bewijsmateriaal op episode- of berichtniveau als dat specifieke detail de modelonzekerheid meetbaar vermindert.
“Semantische gelijkenis is een signaal voor het genereren van kandidaten; onzekerheid is een beslissingssignaal”, zei Gui. “Overeenkomst vertelt je wat er in de buurt is. Onzekerheid vertelt je wat de moeite waard is om voor te betalen in het snelle budget.” Het stopt met uitbreiden wanneer het ontdekt dat het toevoegen van meer details niet langer helpt bij het beantwoorden van de vraag.
Wat zijn de alternatieven?
Bestaand geheugensystemen voor agenten vallen over het algemeen in twee structurele categorieën: platte ontwerpen en gestructureerde ontwerpen. Beide kampen met fundamentele beperkingen.
Platte benaderingen zoals MemGPT log onbewerkte dialoog of minimaal verwerkte tracks. Dit legt het gesprek vast, maar zorgt voor enorme redundantie en verhoogt de kosten voor het ophalen naarmate de geschiedenis langer wordt.
Gestructureerde systemen zoals A-MEM en MemoryOS probeert dit op te lossen door herinneringen in hiërarchieën of grafieken te organiseren. Ze vertrouwen echter nog steeds op onbewerkte of minimaal verwerkte tekst als primair zoekinstrument, waarbij ze vaak putten uit uitgebreide, opgeblazen contexten. Deze systemen zijn ook sterk afhankelijk van door LLM gegenereerde geheugenrecords die strikte schemabeperkingen hebben. Als de AI iets afwijkt in zijn opmaak, kan dit geheugenfouten veroorzaken.
xMemory pakt deze beperkingen aan via het geoptimaliseerde geheugenconstructieschema, hiërarchisch ophalen en dynamische herstructurering van het geheugen naarmate het groter wordt.
Wanneer moet u xMemory gebruiken?
Voor enterprise-architecten is het van cruciaal belang om te weten wanneer deze architectuur moet worden overgenomen in plaats van standaard RAG. Volgens Gui is “xMemory het meest overtuigend als het systeem coherent moet blijven gedurende weken of maanden van interactie.”
Klantenservicemedewerkers profiteren bijvoorbeeld enorm van deze aanpak omdat ze stabiele gebruikersvoorkeuren, gebeurtenissen uit het verleden en accountspecifieke context moeten onthouden zonder herhaaldelijk bijna dubbele ondersteuningstickets op te halen. Persoonlijke coaching is een ander ideaal gebruiksscenario waarbij de AI duurzame gebruikerskenmerken moet onderscheiden van episodische, dagelijkse details.
Omgekeerd, als een bedrijf een AI bouwt om te chatten met een opslagplaats van bestanden, zoals beleidshandleidingen of technische documentatie, “is een eenvoudigere RAG-stack nog steeds de betere technische keuze”, zei Gui. In deze statische, documentgerichte scenario’s is het corpus zo divers dat het standaard ophalen van de dichtstbijzijnde buur perfect werkt zonder de operationele overhead van hiërarchisch geheugen.
De schrijfkosten zijn het waard
xMemory vermindert het latentieknelpunt dat gepaard gaat met het genereren van de uiteindelijke respons van LLM. In standaard RAG-systemen wordt de LLM gedwongen een opgeblazen contextvenster vol overbodige dialogen te lezen en te verwerken. Omdat xMemory’s nauwkeurige top-down ophalen een veel kleiner, zeer gericht contextvenster opbouwt, besteedt de LLM-lezer veel minder tijd aan het ontleden van de prompt en het genereren van de uiteindelijke uitvoer.
In hun experimenten met taken met een lange context presteerden zowel open als gesloten modellen uitgerust met xMemory beter dan andere basislijnen, waarbij ze aanzienlijk minder tokens gebruikten terwijl de taaknauwkeurigheid toenam.
Aan dit efficiënt ophalen zijn echter kosten vooraf verbonden. Voor een bedrijfsimplementatie is het voordeel van xMemory dat het een enorme leesbelasting inruilt voor een voorafgaande schrijfbelasting. Hoewel het uiteindelijk het beantwoorden van gebruikersvragen sneller en goedkoper maakt, vereist het aanzienlijke achtergrondverwerking om de geavanceerde architectuur te behouden.
In tegenstelling tot standaard RAG-pijplijnen, die op goedkope wijze ruwe tekstinsluitingen in een database dumpen, moet xMemory meerdere aanvullende LLM-aanroepen uitvoeren om gespreksgrenzen te detecteren, afleveringen samen te vatten, semantische feiten op de lange termijn te extraheren en algemene thema’s te synthetiseren.
Bovendien voegt het herstructureringsproces van xMemory extra rekenvereisten toe, aangezien de AI zijn eigen interne archiveringssysteem moet beheren, koppelen en bijwerken. Om deze operationele complexiteit in de productie te beheersen, kunnen teams deze zware refactoring asynchroon of in microbatches uitvoeren in plaats van de zoekopdracht van de gebruiker synchroon te blokkeren.
Voor ontwikkelaars die graag een prototype willen maken, is de xMemory-code openbaar beschikbaar op GitHub onder een MIT-licentie, waardoor het levensvatbaar is voor commercieel gebruik. Als je dit probeert te implementeren in bestaande orkestratietools zoals LangChain, raadt Gui aan om je eerst te concentreren op de kerninnovatie: “Het belangrijkste om eerst te bouwen is niet een meer geavanceerde retriever-prompt. Het is de geheugendecompositielaag. Als je maar één ding eerst goed doet, maak er dan de indexerings- en decompositielogica van.”
Afhalen is niet het laatste knelpunt
Hoewel xMemory een krachtige oplossing biedt voor de hedendaagse beperkingen op het gebied van contextvensters, maakt het de weg vrij voor de volgende generatie uitdagingen op het gebied van de workflow van agenten. Omdat AI-agenten over een langere horizon samenwerken, zal het vinden van de juiste informatie niet voldoende zijn.
“Ophalen is een knelpunt, maar zodra het ophalen verbetert, lopen deze systemen al snel tegen levenscyclusbeheer en geheugenbeheer aan als de volgende knelpunten”, aldus Gui. Navigeren hoe gegevens moeten vervallen, omgaan met de privacy van gebruikers en het onderhouden van gedeeld geheugen tussen meerdere agenten is precies “waar ik verwacht dat veel van de volgende golf van werk zal gebeuren”, zei hij.
