Standaard RAG-pijplijnen breken wanneer bedrijven ze proberen te gebruiken voor langdurige, multi-sessie LLM-agentimplementaties. 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 over lange afstanden in verschillende LLM’s verbetert, terwijl de inferentiekosten worden verlaagd. Volgens de onderzoekers daalt het tokengebruik van meer dan 9.000 naar ongeveer 4.700 tokens per zoekopdracht, vergeleken met bestaande systemen voor sommige taken.
Voor zakelijke toepassingen in de echte wereld, zoals gepersonaliseerde AI-assistenten en tools voor beslissingsondersteuning 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 computerkosten op te blazen.
RAG is hier niet voor gebouwd
Bij veel zakelijke LLM-toepassingen is de kritische verwachting dat deze systemen de samenhang en personalisatie zullen behouden tijdens lange interacties die meerdere sessies duren. Om deze langetermijnredenering te ondersteunen, is een veel voorkomende aanpak het gebruik van standaard-RAG: het opslaan van dialogen en gebeurtenissen uit het verleden, het ophalen van een vast aantal topmatches op basis van het inbedden van gelijkenis, en het samenvoegen ervan in een contextvenster om antwoorden te genereren.
Traditionele RAG is echter gebouwd voor grote databases waarbij de opgehaalde documenten zeer divers zijn. De grootste uitdaging is het 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 gegevensbrokken 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 citrusfruit.
Stel je voor dat een gebruiker veel gesprekken heeft gevoerd waarin dingen zijn gezegd als ‘Ik hou van sinaasappelen’, ‘Ik hou van mandarijnen’, en afzonderlijk andere gesprekken over wat telt als citrusvrucht. Traditionele RAG kan deze allemaal als semantisch dichtbij beschouwen en soortgelijke “citrusachtige” fragmenten blijven ophalen.
“Als de retrieval instort op het cluster dat het dichtst in de inbeddingsruimte zit, kan de agent veel zeer vergelijkbare passages over voorkeur 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 snoeien 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 duidelijk kunnen worden gescheiden van bruikbare feiten.
Deze benadering schiet tekort in het geheugen van gespreksagenten, omdat de menselijke dialoog ‘tijdelijk verstrikt is’, schrijven de onderzoekers. Het gespreksgeheugen is sterk afhankelijk van kernreferenties, ellipsen en strikte tijdlijnafhankelijkheden. Vanwege deze onderlinge verbondenheid verwijderen traditionele snoeitools 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 waar de meeste teams naar streven 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 wordt de gespreksstroom ontkoppeld 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 van boven naar beneden door de hiërarchie, gaande van thema’s tot semantiek en uiteindelijk tot onbewerkte fragmenten. Deze aanpak voorkomt redundantie. Als twee dialoogfragmenten vergelijkbare inbedding hebben, is het onwaarschijnlijk dat het systeem ze samen ophaalt als ze aan verschillende semantische componenten 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 de aggregaties op een hoger niveau semantisch trouw blijven aan de oorspronkelijke context om ervoor te zorgen dat het model nauwkeurige antwoorden kan geven.
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 met vier niveaus. Aan de basis 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 kernkennis op lange termijn uit repetitieve chatlogs ontwart. 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 items worden gegroepeerd. Dit voorkomt dat categorieën te uitgebreid worden, wat het zoeken vertraagt, of te gefragmenteerd raken, wat het vermogen van het model verzwakt om bewijsmateriaal te verzamelen en vragen te beantwoorden.
Wanneer het een prompt ontvangt, voert xMemory een top-down-ophaalactie uit in deze hiërarchie. Het begint op thema- en semantisch niveau, waarbij een gevarieerde, compacte reeks relevante feiten wordt geselecteerd. 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 verbonden feiten aan elkaar moeten worden gekoppeld voor complexe, multi-hop redeneringen.
Als het systeem eenmaal over dit hoogwaardige skelet van feiten beschikt, controleert het de redundantie via 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 onzekerheid van het model meetbaar vermindert.
“Semantische gelijkenis is een signaal voor het genereren van kandidaten; onzekerheid is een beslissingssignaal”, zei Gui. “Overeenkomst vertelt je wat in de buurt is. Onzekerheid vertelt je wat daadwerkelijk de moeite waard is om voor te betalen in het snelle budget.” Het stopt met uitbreiden als het merkt dat het toevoegen van meer details niet langer helpt de vraag te beantwoorden.
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 sporen. Hierdoor wordt het gesprek vastgelegd, maar ontstaat er enorme redundantie en stijgen de ophaalkosten naarmate de geschiedenis langer wordt.
Gestructureerde systemen zoals A-MEM en MemoryOS proberen 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 hun primaire ophaaleenheid, waarbij ze vaak uitgebreide, opgeblazen contexten binnenhalen. Deze systemen zijn ook sterk afhankelijk van door LLM gegenereerde geheugenrecords die strikte schemabeperkingen hebben. Als de AI enigszins afwijkt in de opmaak, kan dit geheugenstoringen 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, incidenten uit het verleden en accountspecifieke context moeten onthouden zonder herhaaldelijk bijna dubbele ondersteuningstickets op te halen. Gepersonaliseerde coaching is een ander ideaal gebruiksscenario, waarbij de AI duurzame gebruikerskenmerken moet scheiden van episodische, dagelijkse details.
Omgekeerd, als een onderneming 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”, aldus Gui. In deze statische, documentgerichte scenario’s is het corpus zo divers dat het standaard ophalen van de dichtstbijzijnde buur prima werkt zonder de operationele overhead van hiërarchisch geheugen.
De schrijfbelasting is de moeite waard
xMemory vermindert het latentieknelpunt dat gepaard gaat met het genereren van definitieve antwoorden door de 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 rekentijd aan het analyseren 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 schrijfbelasting vooraf. Hoewel het uiteindelijk het beantwoorden van gebruikersvragen sneller en goedkoper maakt, vereist het behoud van de geavanceerde architectuur aanzienlijke achtergrondverwerking.
In tegenstelling tot standaard RAG-pijplijnen, die op goedkope wijze ruwe tekstinsluitingen in een database dumpen, moet xMemory meerdere aanvullende LLM-oproepen uitvoeren om gespreksgrenzen te detecteren, afleveringen samen te vatten, semantische feiten op de lange termijn te extraheren en overkoepelende 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 herstructurering 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 geen mooiere retriever-prompt. Het is de geheugendecompositielaag. Als je maar één ding eerst goed doet, maak er dan de indexerings- en decompositielogica van.”
Ophalen is niet het laatste knelpunt
Hoewel xMemory een krachtige oplossing biedt voor de hedendaagse beperkingen van contextvensters, maakt het de weg vrij voor de volgende generatie uitdagingen in agentische workflows. Omdat AI-agenten over een langere horizon samenwerken, is het simpelweg vinden van de juiste informatie niet voldoende.
“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.
