Geheugen in LLM-apps: wat de model onthoudt en wat jij moet doen

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

Een veelvoorkomende misvatting bij beginnende softwareontwikkelaars is dat een groot taalmodel (LLM) leert van de gesprekken die ermee worden gevoerd. Wanneer een gebruiker vraagt: "Weet je nog wat ik net zei?", lijkt het model zich dit feilloos te herinneren. In werkelijkheid bezit een LLM uit zichzelf geen enkel geheugen tussen twee API-aanroepen door. Elk taalmodel is inherent een zuivere, wiskundige functie die invoertokens omzet in uitvoertokens: volledig staatloos (stateless).

De illusie van een doorlopend gesprek ontstaat uitsluitend doordat de omringende applicatie de volledige gespreksgeschiedenis opnieuw inpakt en meestuurt bij elke nieuwe interactie. Naarmate applicaties complexer worden — van simpele klantenservicebots tot autonome software-agents — schiet het domweg meesturen van alle eerdere tekst tekort. Contextvensters lopen vol, latentietijden stijgen exponentieel en API-kosten exploderen. In dit artikel behandelen we waarom taalmodellen staatloos zijn en hoe ontwikkelaars externe geheugensystemen construeren om continuïteit, personalisatie en betrouwbaarheid te garanderen.

De fundamentele illusie: stateless inference en parameters

Om te begrijpen wat een applicatie moet oplossen, kijken we eerst naar wat het model wél en niet bewaart. Een getraind taalmodel bestaat uit honderden miljarden statische gewichten. Deze gewichten bevatten 'parametrisch geheugen': gecondenseerde representaties van patronen, feiten, grammatica en redeneerstructuren uit de trainingsdataset. Zodra het model in productie draait, zijn deze gewichten bevroren.

Wanneer een verzoek (inference request) naar de model-API wordt gestuurd, gebeurt het volgende:

1. De invoertekst wordt omgezet in numerieke tokens.
2. De transformer voert matrixvermenigvuldigingen uit over deze tokens via het aandachtsmechanisme.
3. Het model berekent kansverdelingen voor de volgende tokens en genereert een antwoord.
4. Zodra het antwoord is voltooid, worden alle tussenliggende activatietoestanden gewist uit het videogeheugen (VRAM).

Het model slaat niets op op schijf en past zijn eigen gewichten niet aan. Wie een minuut later een nieuw bericht stuurt zonder context, begint bij het model met een volkomen schone lei. Als applicatiebouwer ben je daarom zelf verantwoordelijk voor het ontwerpen van een 'niet-parametrisch geheugen': een externe datalaag die relevante informatie bewaart, structureert en op het juiste moment selectief in het contextvenster injecteert. Voor wie de stap wil maken naar geavanceerde autonome systemen, is dit een kernvaardigheid; lees daarover meer in de gids over hoe je een succesvolle AI-agent engineer kunt worden en robuuste softwarelussen opbouwt.

Korte-termijn contextbeheer: sliding windows en tokenbudgetten

De meest basale vorm van applicatiegeheugen is het opslaan van de chatgeschiedenis in een traditionele database (zoals PostgreSQL of Redis) en deze lijst van berichten bij elke beurt injecteren in het berichtenveld van de API. Dit noemen we het korte-termijn sessiegeheugen. Dit stuit echter direct op de limiet van het contextvenster.

Om te voorkomen dat de tokenlimiet wordt overschreden, gebruiken ontwikkelaars sliding-window strategieën. Hierbij worden alleen de meest recente $k$ interacties bewaard. Hoewel dit eenvoudig te implementeren is, kent het grote nadelen: informatie die $k+1$ beurten geleden is genoemd, verdwijnt abrupt uit het zicht van het model. Om die reden werken moderne systemen met dynamische tokenbudgetten.

In een dynamisch tokenbudget wijzen we harde limieten toe aan verschillende componenten in de prompt. Een typische budgetverdeling ziet er als volgt uit:

# Voorbeeld van een tokenbudget-configuratie in Python
TOTAL_CONTEXT_LIMIT = 8192
SYSTEM_PROMPT_RESERVE = 1000
OUTPUT_GENERATION_RESERVE = 1500
DYNAMIC_MEMORY_BUDGET = TOTAL_CONTEXT_LIMIT - SYSTEM_PROMPT_RESERVE - OUTPUT_GENERATION_RESERVE
# Beschikbaar voor sessiegeschiedenis en opgevraagde feiten: 5692 tokens

Wanneer de gespreksgeschiedenis het budget van 5692 tokens overschrijdt, moet de applicatie keuzes maken: welke oude berichten worden verwijderd, gecomprimeerd of verplaatst naar een langetermijnarchief? Dit raakt direct aan geavanceerd contextontwerp; zie het verdiepende artikel over hoe context-engineering werkt in productieomgevingen voor concrete patronen om tokens optimaal te benutten.

Samenvattingsstrategieën: incrementele compressie

Wanneer een gesprek langer duurt dan een paar dozijn interacties, is het weggooien van oude berichten via FIFO (First In, First Out) vaak onacceptabel. Als een gebruiker in beurt 2 meldt dat hij allergisch is voor noten, mag een recepten-assistent dat in beurt 40 niet vergeten zijn. De oplossing hiervoor is incrementele samenvatting (rolling summarization).

Bij incrementele compressie draait er op de achtergrond een aparte LLM-taak zodra het aantal tokens een drempelwaarde passeert. Deze taak neemt de bestaande samenvatting en de oudste onverwerkte berichten, en distilleert hieruit een nieuwe, bijgewerkte samenvatting. Het actuele contextvenster bevat dan:

[Systeemprompt met kerninstructies]
[Lopende samenvatting van het eerdere gesprek (bijv. 250 tokens)]
[Recente interacties woordelijk (bijv. de laatste 5 berichten)]
[Nieuwste gebruikersvraag]

Dit mechanisme brengt echter specifieke trade-offs met zich mee. Ten eerste kost het genereren van de samenvatting extra tokens en tijd. Ten tweede treedt er 'informatie-erosie' op: details die niet direct relevant lijken voor de samenvattende LLM, worden weggelaten en zijn daarmee definitief verloren voor het actieve geheugen. Daarom is het cruciaal om het verschil tussen sessiecontext en persistent geheugen scherp te houden. In het artikel over het conceptuele verschil tussen geheugen en context wordt dieper ingegaan op waarom compressie niet hetzelfde is als herinneren.

Lange-termijn geheugen: vector databases en semantisch ophalen

Voor applicaties die over dagen, weken of maanden heen moeten functioneren, volstaat een lineaire samenvatting niet. Hier introduceert de software-architectuur een vector database (zoals Qdrant, Chroma of pgvector) als extern langetermijngeheugen. Dit proces lijkt sterk op Retrieval-Augmented Generation (RAG), maar met een belangrijk verschil: in plaats van statische documenten indexeert het systeem interacties, feiten en voorkeuren van de gebruiker zelf.

Het opslag- en ophaalproces verloopt in drie fasen:

1. Extractie en Chunking: Na elke interactie analyseert een extractie-prompt of er duurzame feiten zijn genoemd (bijvoorbeeld: "Gebruiker prefereert TypeScript boven Python"). Deze feiten worden losgeknipt van de conversatie-ruis.
2. Embedding: Het feit wordt door een embedding-model omgezet in een vector (een lijst getallen) en opgeslagen in de vector database, voorzien van metadata zoals een tijdstempel en gebruikers-ID.
3. Semantisch ophalen (Retrieval): Bij een nieuwe vraag zoekt de applicatie naar vectoren in de database die semantisch dicht bij de huidige gebruikersvraag liggen via cosinus-overeenkomst. De top-k meest relevante herinneringen worden geïnjecteerd in de prompt.

// Voorbeeld van een JSON-geheugenrecord in een vector database
{
  "id": "mem_982341",
  "user_id": "usr_4402",
  "timestamp": "2026-08-15T10:14:22Z",
  "fact": "Klant wil uitsluitend communiceren in het Nederlands en heeft voorkeur voor beknopte antwoorden.",
  "category": "preference",
  "importance_score": 0.85,
  "embedding": [0.0124, -0.0841, 0.0512, ...]
}

Het grote voordeel van semantisch ophalen is schaalbaarheid: een vector store kan miljoenen interacties bevatten zonder dat het contextvenster van het LLM volloopt. Het nadeel is dat semantische gelijkenis niet altijd gelijk staat aan relevantie. Als een gebruiker vraagt: "Wat aten we gisteren?", zoekt een naïef vectorgeheugen naar berichten over eten, maar mist het mogelijk de temporele context als de datum niet expliciet in de zoekopdracht is meegenomen.

Gestructureerd entiteitsgeheugen en Knowledge Graphs

Vectoren zijn uitstekend in het vinden van vage concepten, maar zwak in exacte relaties. Als een gebruiker meldt: "Mijn zus Marieke heeft twee katten, Tom en Jerry", en drie weken later vraagt: "Hoeveel dieren heeft mijn zus?", kan een vectorzoekopdracht falen als de semantische afstand tussen de chunks te groot is.

Geavanceerde architecturen combineren daarom vectoropslag met gestructureerde entiteitsgeheugens of Knowledge Graphs. Hierbij parseert een model expliciet entiteiten en hun onderlinge relaties naar triples:

(Gebruiker) — [HEEFT_ZUS] —> (Marieke)
(Marieke) — [BEZIT] —> (Tom: Kat)
(Marieke) — [BEZIT] —> (Jerry: Kat)

Door relationele gegevens op te slaan in een graafdatabase (zoals Neo4j) of een gestructureerde relationele tabel, kan de applicatie deterministische queries uitvoeren voordat de context aan het taalmodel wordt overhandigd. Dit voorkomt hallucinaties over harde feiten en zorgt voor consistente personalisatie over lange tijdlijnen.

Geheugenarchitecturen in de praktijk: MemGPT en agentic loopback

In 2023 en 2024 ontstonden baanbrekende benaderingen zoals MemGPT (Memory-GPT), die de werking van het traditionele computerbesturingssysteem nabootsen voor LLM's. In dit paradigma wordt het contextvenster van het model beschouwd als het werkgeheugen (RAM), terwijl externe databases functioneren als de harde schijf (Disk Storage).

In een dergelijk systeem krijgt het model speciale tools (functies) waarmee het zijn eigen geheugen actief kan beheren. In plaats van dat de middleware passief probeert te raden wat belangrijk is, beslist het model zelf:

• core_memory_append(key, value): voeg een kernfeit toe aan het altijd aanwezige werkgeheugen.
• archival_memory_insert(content): sla een gedetailleerde herinnering op in de externe vectoropslag.
• archival_memory_search(query, page): zoek doelgericht in het archief wanneer meer achtergrondkennis nodig is.

Dit verschuift de regie naar het model zelf. Het model herkent wanneer een instructie cruciaal is voor de toekomst en roept autonoom een functie aan om dit vast te leggen. De uitdaging hierbij is betrouwbaarheid: kleine modellen vergeten soms functies aan te roepen, of vervuilen hun geheugen met irrelevante details als de sturende systeemprompt niet zorgvuldig is geoptimaliseerd.

Privacy, dataretentie en vergeten: TTL en GDPR-naleving

Een aspect dat vaak over het hoofd wordt gezien bij het ontwerpen van geheugen in AI-apps, is databeheer en privacy. Zodra een applicatie persoonsgegevens extraheert en opslaat in externe vector- of graafdatabases, valt dit onder wetgeving zoals de Algemene Verordening Gegevensbescherming (AVG / GDPR).

Een robuust geheugensysteem moet daarom over de volgende mechanismen beschikken:

• Recht op vergetelheid (Right to be Forgotten): Gebruikers moeten de mogelijkheid hebben om hun geheugenprofiel in te zien, te corrigeren en volledig te wissen. In een vector database vereist dit dat elk embedding-record gekoppeld is aan een unieke user_id en eenvoudig via metadata te verwijderen is.
• Time-to-Live (TTL) en geheugenverval: Net als het menselijk brein moet een AI-applicatie minder relevante herinneringen na verloop van tijd laten vervagen. Door een 'decay function' toe te passen op basis van de ouderdom en gebruiksfrequentie van een herinnering, voorkom je dat verouderde feiten (zoals een oud tijdelijk adres) actuele antwoorden vervuilen.
• Scheiding van gevoelige data: Medische gegevens, wachtwoorden of betalingsinformatie moeten worden gefilterd vóórdat ze in een permanent geheugenarchief belanden.

Evaluatie en kwaliteitsborging van geheugenmechanismen

Hoe weet je of een geheugensysteem daadwerkelijk presteert zoals bedoeld? Het evalueren van geheugen in LLM-applicaties vereist een systematische aanpak. Een veelgemaakte fout is het handmatig testen van een paar prompts, wat een vals gevoel van zekerheid geeft.

Voor een betrouwbare werking meet men drie kernstatistieken:

1. Retrieval Precision & Recall: Haalt het systeem bij een specifieke vraag precies die historische feiten op die nodig zijn om de vraag te beantwoorden, zonder overbodige ballast?
2. Memory Retention Rate: Blijft een feit correct opgeslagen na 10, 50 en 100 opeenvolgende gespreksbeurten, of treedt er degradatie op in de samenvatting?
3. Latency & Token Overhead: Wat is de extra vertraging en kostentoename die de geheugenlaag toevoegt aan elke gebruikersbeurt?

Om te bepalen welke geheugenprompt of zoekinstelling het beste presteert, is experimenteren noodzakelijk. Lees in het overzicht over het systematisch A/B-testen van prompts hoe je statistisch valide vergelijkingen opzet om regressie in je applicatie te voorkomen.

Conclusie en implementatie-afwegingen

Een taalmodel onthoudt uit zichzelf niets. Het is een zuiver wiskundige rekenmachine die bij elke aanroep vanaf nul begint. De magie van langdurige interacties, consistente assistenten en lerende agents ontstaat volledig in de architectuur die jij als ontwikkelaar om het model heen bouwt.

Begin bij het bouwen van een applicatie altijd met de eenvoudigste oplossing: een dynamisch berekend tokenbudget met een recente berichtenbuffer. Pas wanneer de use case expliciet vraagt om continuïteit over meerdere sessies, voeg je een geautomatiseerde samenvattingslaag of een externe vector database toe. Zorg daarbij altijd voor strikte metadata-filtering, respecteer privacy-richtlijnen en meet continu of de opgehaalde herinneringen daadwerkelijk bijdragen aan een beter antwoord.