🤖 AI

Memory in the Loop: In-Process Retrieval as ExtendedWorking Memory for Language Agents

Dit artikel betoogt dat het verplaatsen van geheugenretrieve van een trage, externe netwerkopslag naar een snelle, in-process opslag het transformeert tot effectief uitgebreid werkgeheugen voor taalagenten, waardoor de door latentie veroorzaakte prestatieverslechtering die agenten momenteel dwingt om retrieve te beperken tot één keer per beurt, wordt geëlimineerd.

Oorspronkelijke auteurs: Yusuf Khan, Carlo Lipizzi

Gepubliceerd 2026-07-08

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Yusuf Khan, Carlo Lipizzi

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Het Kernprobleem: De "Trage Bibliothecaris" vs. Het "Notitieboekje"

Stel je voor dat je een complexe puzzel probeert op te lossen. Je hebt een briljante assistent (de AI-agent) die erg slim is, maar een heel kort concentratievermogen heeft. Om hen te helpen, geef je ze een notitieboekje (het "context window") waarin ze belangrijke feiten kunnen opschrijven.

De Oude Manier (Huidige AI):
Momenteel, als de assistent iets vergeet of een feit moet controleren dat niet in hun directe notitieboekje staat, moeten ze stoppen, naar een enorme bibliotheek verderop in de straat lopen (een clouddatabase), een bibliothecaris vragen om het boek, wachten tot de bibliothecaris het heeft gevonden, en weer teruglopen.

Het Probleem: Deze reis duurt lang (ongeveer 100 milliseconden). Als de assistent bij elke nieuwe stap die ze bedenken even naar de bibliotheek moet lopen, komt het hele proces tot stilstand. Omdat de reis zo traag is, zeggen ingenieurs tegen de assistent: "Ga slechts één keer aan het begin van de taak naar de bibliotheek, en raad de rest maar." Dit leidt tot fouten omdat de assistent dingen vergeet die tijdens de taak zijn gebeurd.

Het Nieuwe Idee (Memory in the Loop):
De auteurs van dit paper vroegen zich af: "Wat als de bibliotheek niet verderop in de straat stond, maar direct op het bureau van de assistent?"
Ze bouwden een klein, supersnel geheugensysteem dat binnenin het brein van de assistent leeft (in-process). Het controleren van dit geheugen duurt slechts 0,0001 seconden (100 microseconden).

Het Resultaat: De assistent kan nu bij elke stap hun geheugen controleren, zonder dat het proces vertraagt. Het is also wordt een notitieboekje dat zichzelf direct bijwerkt, in plaats van dat je naar een bibliotheek moet lopen.

De Grote Ontdekking: Snelheid Verandert Hoe We Denken

Het paper betoogt dat snelheid niet alleen over het besparen van tijd gaat; het verandert de aard van het geheugen.

De Analogie van het "Gereedschap" vs. Het "Brein":
- Als je 10 minuten moet lopen om een gereedschap te pakken, is dat gereedschap een extern object. Je moet van tevoren plannen om het te gebruiken, en je kunt vergeten het mee te nemen.
- Als het gereedschap in je zak zit en je het direct kunt pakken, wordt het onderdeel van jouw lichaam. Je gebruikt het automatisch zonder erbij na te denken.
- Het paper beweert dat omdat dit nieuwe geheugen zo snel is, het niet langer een "database waar de AI advies bij vraagt" is, maar "werkgeheugen dat de AI heeft". Het stelt de AI in staat om continu te redeneren zonder de flow te onderbreken.

De Experimenten: Bewijzen Dat het Werkt

De onderzoekers testten dit met twee hoofdscenario's:

1. De "Reisplanner"-test (Kan het feiten onthouden?)

De Opzet: De AI moest een reis plannen op basis van 5 specifieke regels (bijv. "Geen honden", "Moet goedkoop zijn"). Het gesprek was lang, waardoor de regels uiteindelijk uit het kortetermijnnotitieboekje (het context window) van de AI zouden "vallen".
Het Resultaat:
- Zonder het snelle geheugen vergat de AI de regels volledig (0 van de 5 correct).
- Met het snelle geheugen onthield de AI de meeste regels (3,6 tot 4,8 van de 5 correct).
- Noot: De onderzoekers ontdekten ook dat als je de AI simpelweg zou vragen om "de regels in elke zin te herhalen", dit perfect zou werken. Maar dit is duur (alsof je een heel boek telkens opnieuw schrijft wanneer je een pagina toevoegt). Het snelle geheugen bereikte vergelijkbare resultaten zonder die zware kosten.

2. De "Loop Guard"-test (Kan het stoppen met het herhalen van fouten?)

De Opzet: De AI moest een lijst met beveiligingsmeldingen controleren. Sommige meldingen waren duplicaten van meldingen die hij al eerder had gezien. Het doel was om de AI te stoen om niet twee keer hetzelfde onderzoek te doen.
De Test: Ze vertraagden de geheugensnelheid kunstmatig om te zien wat er gebeurde.
- Snel Geheugen (0,0001s): De AI controleerde elke melding tegen zijn geheugen. Hij maakte nul fouten.
- Traag Geheugen (0,1s): De AI kon het zich niet veroorloven om elke melding te controleren omdat dit te lang zou duren. Hij sloeg controles over en herhaalde acties 7 van de 12 keer.
- De Les: De AI werd niet "dommer". Hij kon het simpelweg niet veroorloven om zijn geheugen snel genoeg te controleren. Wanneer het geheugen instant was, stopte de AI met het maken van redundante fouten.

De Verborgen Bottleneck: De "Vertaler"

De onderzoekers ontdekten één addertje onder het gras. Hoewel het geheugen zelf instant was, moest de AI nog steeds "vertalen" wat hij dacht naar een formaat dat het geheugen kon begrijpen (dit heet "embedding").

Als deze vertaling via het internet verliep, was het traag.
De Oplossing: Door een kleine, lokale vertaler te gebruiken (een klein AI-model dat op dezelfde computer draait), maakten ze het gehele proces (denken + vertalen + geheugen controleren) slechts 0,00004 seconden snel. Dit is snel genoeg om op elke stap van de redenering van de AI te gebeuren.

Samenvatting van de Claims

Snelheid is de Poortwachter: De reden dat AI-agents hun geheugen niet constant controleren, is niet omdat het een slecht idee is; het is omdat huidige clouddatabases te traag zijn.
In-Process is de Oplossing: Door het geheugen naar dezelfde computer als de AI te verplaatsen (in-process), neemt de snelheid met 1.000 keer toe.
Het Verandert Gedrag: Wanneer het geheugen instant is, stopt de AI met het maken van "redundante" fouten (het twee keer doen van hetzelfde) omdat hij zijn geschiedenis op elke stap kan controleren.
Het Is Geen Magie: De AI werd niet slimmer; het systeem rondom de AI werd slimmer. De AI maakt nog steeds fouten als de geheugencontrole te traag is, maar met het snelle geheugen voorkomt het systeem deze fouten automatisch.

Kortom: Dit paper bewijst dat als je een AI een "supersnel notitieboekje" geeft dat in zijn eigen brein leeft, de AI kan stoppen met dingen vergeten en stoppen met het herhalen van fouten, waardoor externe opslag effectief verandert in een echt onderdeel van zijn denkproces.

Technische Samenvatting: Memory in the Loop

Probleemstelling

Taalagenten opereren volgens een standaardlus: observeren, redeneren, handelen, herhalen. Echter, de geheugenbron waarover zij redeneren, wordt doorgaans behandeld als een externe bron die maximaal één keer per beurt wordt geraadpled (per-turn retrieval). Dit ontwerp is gebaseerd op de aanname dat de ophaallatentie (retrieval latency) prohibitief is. Gekoppelde vectorstores reageren doorgaans in 50–200 ms; als een agent bij elke redeneerstap een dergelijke store raadpleegt, kan de end-to-end latentie met factor 83 toenemen. Bijgevolg adviseren huidige industriestandaarden ("memory-first") en systeemontwerpen om retrieval te beperken tot één keer per beurt of de kosten te verbergen in de serving-laag via scheduling.

Het paper betoogt dat deze latentiebeperking geen fundamentele wet van agent-ontwerp is, maar een artefact van de vraag waar de store zich bevindt. Netwerklatentie (tientallen tot honderden milliseconden) maakt in-loop retrieval duur, terwijl een in-process store in ongeveer 100 µs kan antwoorden. Het centrale probleem is of het verplaatsen van geheugen binnen de redeneerlus—het lezen en schrijven ervan bij elke stap—haalbaar en voordelig is wanneer de latentiebarrière wordt weggenomen.

Methodologie

Kernarchitectuur

De auteurs implementeren "Memory in the Loop" met behulp van een efemere, in-process semantische store (vxdb) die is ingekapseld als een WorkingMemory primitief. Deze store ondersteunt add, recall, en match operaties. Cruciaal is dat de store per agent/taak wordt gealloceerd en niet verbonden is met een netwerkdienst, met als doel microseconde-responstijden.

Experimentele Opzet

De studie hanteert twee primaire experimentele regimes:

Windowed Recall Task (End-to-End Prestaties):
- Scenario: Een zes-beurten gesprek over het plannen van een reis waarbij de gebruiker vroeg in het gesprek vijf duurzame restricties vermeldt. De agent moet aan het einde alle vijf de restricties opsommen.
- Restrictie: Het contextvenster is beperkt tot $w=4$ berichten, waardoor vroege restricties uit het zichtbare venster rollen.
- Condities:
  - Baseline/Aware: Geen geheugentools (Aware wordt geïnformeerd dat de geschiedenis kort is).
  - Notes: De instructie om in elk antwoord alle restricties te herhalen (een "no-tools" bovengrens).
  - Memory: Uitgerust met remember/recall tools ondersteund door de in-process store.
- Modellen: Getest over een "GPT-5 ladder" (gpt-5-nano, gpt-5-mini, gpt-5, gpt-5.5).
Causal Loop-Guard Task (Latentie vs. Resultaat):
- Scenario: Een agent verwerkt een stroom beveiligingsmeldingen en besluit of hij een INVESTIGATE of SKIP actie uitvoert bij duplicaten.
- Mechanisme: Een code-guard controleert de store vóór elke actie om redundante onderzoeken te voorkomen.
- Variabele: De store-latentie wordt gemanipuleerd door round-trip vertragingen te injecteren (0 µs tot 200 ms) terwijl het geheugenbudget per beurt vast blijft (100 ms).
- Armen:
  - In-process: Real-time snelheid (~17.5–85 µs).
  - Delayed Ladder: Identieke logica met geïnjecteerde vertragingen (+5, +15, +30, +50, +110 ms).
  - Per-turn RAG: De industriestandaard (retrieval één keer per beurt).
- Metriek: Aantal redundante acties uitgevoerd (van de 12 duplicaten).

Kostenmodellering

De auteurs definiëren een haalbaarheidsfront waarbij in-loop geheugen levensvatbaar is als de kosten van retrieval ( $f \cdot c$ ) verwaarloosbaar zijn ten opzichte van de redeneerstap-tijd ( $r$ ). Ze meten de volledige operationele kosten (embedding + store) om te bepalen of toegang per stap "gratis" is ten opzichte van een LLM-stap.

Belangrijkste Resultaten

1. Haalbaarheid en Latentiebelasting

In-Process Snelheid: De in-process store opereert met een mediane latentie van 80–165 µs.
Latentiebelasting: Met 20 in-loop retrievals per beurt is de totale blokkeringstijd ~1.7 ms voor de in-process store. In tegenstelling hiermee brengt een cloud vectorstore (110 ms RTT) een belasting van 2.2 seconden per beurt met zich mee.
Haalbaarheid: Bij in-process snelheden kan een agent ~953 retrievals per stap verwerken (uitgaande van een latentiebudget van 10% ), terwijl networked stores minder dan 1 lookup per stap kunnen uitvoeren, wat dwingt tot rantionering.

2. Taakprestaties (Windowed Recall)

Baseline Falen: Alle baseline en "aware" runs scoorden 0/5 bij de herinnering van restricties. De beperking van het contextvenster veroorzaakte totaal falen, ongeacht de modelgrootte.
Restatement Baseline: Een geïnstrueerde baseline die restricties in elk antwoord herhaalde, behaalde 5/5, wat aantoont dat de taak oplosbaar is als de agent de context actief beheert, hoewel dit een token "huur" met zich meebrengt die schaalt met de werkset.
Memory in the Loop: De in-loop geheugenconditie behaalde 3.6–4.8/5 herinnering over de modellen heen.
- Falen Analyse: De store verloor nooit een feit (244/244 writes behouden). Missers waren uitsluitend read-policy failures: agenten overschreven restricties (creëerden duplicaten) en lazen vervolgens slechts één keer per run door een vaste $k=8$ window, die overvol was met redundante entries. Het falen lag in het gebruik van de tools door de agent, niet in de geheugen-substraat.

3. Causale Impact van Latentie (Loop Guard)

Monotone Dose-Response: Redundante acties namen monotoon toe met de store-latentie onder een vast budget.
- In-process (0 ms): 0.0 redundante acties.
- +15 ms: 1.4–1.6 redundante acties.
- +110 ms (Cloud): 7.2 van de 12 redundante acties.
Statistische Significantie: Het verschil tussen in-process en 110 ms latentie was statistisch significant ( $p=0.0079$ ) voor beide geteste modellen.
Mechanisme: Bij 110 ms kon het budget (100 ms) geen enkele lookup meer bekostigen, waardoor de guard effectief werd uitgeschakeld. De "fouten" waren geen retrieval-fouten, maar de afwezigheid van controles.
Per-Turn RAG: De industriestandaard per-turn retrieval presteerde goed (0.4–0.6 redundante acties) maar faalde structureel om duplicaten te vangen die binnen een enkele beurt ontstonden, terwijl de in-process guard alle duplicaten ving.

4. De Embedding Bottleneck

De dominante kosten in de in-loop stack komen niet van de store, maar van de embedding. Netwerk embedding API's duren 200–400 ms.
Door de in-process store te koppelen aan een kleine lokale embedder (32M parameters, 32 µs), daalt de volledige operatie (embed + store) naar **40 µs**. Dit verwijdert de laatste barrière voor in-loop geheugen.

Betekenis en Claims

Theoretische Bijdrage: Uitgebreid Werkgeheugen

Het paper fundeert de technische bevindingen in de Extended-Mind Thesis (Clark & Chalmers, 1998). Het betoogt dat een externe bron pas "constitutief" wordt voor cognitie (d.w.z. deel uitmaakt van het werkgeheugen van een agent) als deze:

Constante beschikbaarheid heeft.
Direct toegankelijk is zonder moeilijkheden.
Automatisch wordt aanvaard (endorsed).

De auteurs interpreteren de eerste twee criteria als een latentiebudget. Een 100 ms netwerkoproep is een tool die een agent raadpleegt; een 100 µs in-process store is een bron die de agent heeft. Wanneer de latentie laag genoeg is om transparant te zijn voor de redeneerstap, transformeert de store van een externe database naar uitgebreid werkgeheugen.

Engineering Bijdrage

Latentie als Ontwerpvariabele: Het paper verschuift de frequentie van retrieval van een serving-laag beperking naar een agent-niveau ontwerp-as. Het demonstreert dat de latentie van de store, en niet het in-loop patroon zelf, de bepalende factor is.
Causaal Verband: Het levert causaal bewijs dat de store-latentie alleen de taakuitkomsten bepaalt (redundante acties) wanneer het budget vaststaat, onafhankelijk van de modelcapaciteit.
Architecturale Verschuiving: Het stelt voor dat geheugen moet worden behandeld als een loop-primitief (zoals een scratchpad) die per taak wordt gealloceerd, in plaats van een verbonden dienst.

Bescheidenheid en Beperkingen

De auteurs zijn expliciet over de reikwijdte:

Zij beweren niet dat de store het model "slimmer" maakt; de modellen herkenden nog steeds geen duplicaten zonder de guard. Het systeem slaagde omdat de scaffold de tijd kon missen om het geheugen te controleren.
De "Notes" baseline (herformulering) presteerde beter dan de geheugentools op de kleine 5-fact taak, wat benadrukt dat herformulering een per-turn kostenpost met zich meebrengt die groeit met de werkset, iets wat de store op schaal vermijdt.
De studie richt zich op het temporele aspect van geheugen (wanneer het deelneemt aan redeneren). Vragen over wat te bewaren, hoe te organiseren en lifecycle management (vergeten/prioritering) worden geïdentificeerd als toekomstig werk.

Concluderend stelt het paper dat het "in-loop" regime niet alleen haalbaar is, maar ook causaal superieur voor taken die consistentie van de staat binnen een beurt vereisen, mits de geheugen-substraat in-process is en gekoppeld wordt aan een lokale embedder om netwerklatentie te elimineren.