Geheugen in LLM-toepassingen uitgelegd: Hoe AI leert onthouden en vergeten

Wie voor het eerst een Large Language Model (LLM) gebruikt, merkt al snel op dat de AI schijnbaar moeiteloos teruggrijpt naar eerdere uitspraken in hetzelfde gesprek. Toch is dit een illusie. Een fundamentele eigenschap van LLM's is dat ze van nature volkomen stateless (staatloos) zijn. Elke keer dat je een verzoek indient, verwerkt het model uitsluitend de tekst die op dat exact moment als invoer wordt meegegeven. Het model onthoudt niets van het vorige verzoek, laat staan van een gesprek van gisteren.

Het bouwen van applicaties waarin een AI wel over een functionerend geheugen lijkt te beschikken, vereist daarom slimme architectuur rondom het eigenlijke model. In dit artikel ontdek je hoe geheugen in LLM-toepassingen werkt, welke varianten er zijn, waarom te veel geheugen soms schadelijk is, en hoe je gecontroleerd vergeten inbouwt.

Waarom een LLM zelf niets onthoudt

Om te begrijpen hoe geheugen in software wordt opgelost, moeten we kijken naar de werking van het model zelf. Een LLM is in wezen een complexe wiskundige functie die tekst omzet in een voorspelling voor het volgende stukje tekst (een token). Het model slaat geen persoonlijke gebruikershistorie op in zijn gewichten nadat een inferentietak is afgerond. Zodra de server de respons heeft gegenereerd, is het gesprek voor het model direct vergeten.

Dit betekent dat de illusie van een gesprek volledig tot stand komt doordat de applicatie bij elk nieuw bericht de complete gespreksgeschiedenis opnieuw meestuurt in de prompt. Stuur je bericht nummer tien? Dan krijgt het model jouw eerste tot en met jouw negende bericht plus alle antwoorden in één keer voorgeschoteld.

De verschillende lagen van geheugen in LLM-apps

Omdat het meesturen van een oneindige geschiedenis onpraktisch en onbetaalbaar is, maken geavanceerde toepassingen gebruik van verschillende typen geheugenlagen. Elk type heeft zijn eigen doel, voor- en nadelen.

1. Het contextvenster (Kortetermijngeheugen)

Het contextvenster is de maximale hoeveelheid tokens die een model tegelijkertijd kan verwerken. Moderne modellen ondersteunen vaak contextvensters van 32.000 tot wel miljoenen tokens. Dit fungeert als het directe kortetermijngeheugen. Zolang het gesprek binnen dit venster past, kan het model alle informatie direct raadplegen.

Hoewel grotere vensters handig lijken, brengt het nadelen met zich mee. Modellen vertonen soms het fenomeen dat ze informatie in het midden van een gigantische context over het hoofd zien (het zogenaamde 'lost in the middle'-probleem), en de kosten en rekentijd schieten omhoog naarmate de invoer groeit.

2. Gespreksgeschiedenis (Conversational Buffer)

Dit is de meest basale vorm van applicatiegeheugen: een chronologische lijst van alle uitgewisselde berichten in de huidige sessie. De applicatie beheert deze lijst in een externe database (zoals PostgreSQL of Redis) en voegt deze bij elke interactie toe aan de prompt. Vaak wordt hier een limiet op gezet, bijvoorbeeld door alleen de laatste tien berichten te behouden.

3. Samenvattend geheugen (Compressie)

Wanneer een gesprek te lang wordt voor het comfortabele bereik van het model, kan een achtergrondtaak de oudere berichten automatisch samenvatten. In plaats van de volledige dialoog van uur één mee te sturen, stuurt de applicatie een compacte alinea mee die de kern van het eerdere gesprek beschrijft, gecombineerd met de meest recente losse berichten. Dit bespaart tokens en houdt de essentie vast.

4. Opgeslagen feiten en profielen (Persistent geheugen)

Voor toepassingen die gebruikers over meerdere sessies willen herinneren, volstaat een gespreksgeschiedenis niet. Hier komt persistent geheugen om de hoek kijken. De applicatie gebruikt het LLM om specifieke feiten over de gebruiker te extraheren (bijvoorbeeld: "gebruiker heeft een hond genaamd Max" of "prefereert code in Python") en slaat deze op in een gestructureerde database of via embeddings. Bij een nieuwe sessie worden alleen de relevante feiten dynamisch opgehaald.

5. Externe kennisbanken via RAG

Soms wordt geheugen verward met kennis. Als een applicatie bedrijfsdocumenten moet onthouden, gebruikt men doorgaans geen geheugenstructuur, maar Retrieval-Augmented Generation. Hierbij doorzoekt het systeem externe bronnen op basis van de vraag van de gebruiker en plakt de relevante documenten tijdelijk in de prompt. Meer hierover lees je in onze gids over RAG voor beginners.

Wanneer geheugen schaadt: Het gevaar van vervuiling

Meer geheugen is niet per definitie beter. Er kleven serieuze nadelen aan het ongelimiteerd vasthouden van informatie in een LLM-toepassing:

• Verouderde feiten: Als een gebruiker in januari aangeeft in Utrecht te wonen, maar in juni verhuist naar Rotterdam, en het systeem blijft dit hardnekkig onthouden via een verouderd profiel, krijg je inconsistente adviezen.
• Contextvervuiling: Irrelevante details uit eerdere sessies kunnen het model afleiden. Het model kan gewicht gaan toekennen aan meningen of grappen die uren geleden zijn gemaakt.
• Privacyrisico's: Het opslaan van te veel persoonlijke data vergroot de impact van datalekken en compliceert het naleven van privacywetgeving zoals de AVG (het recht om vergeten te worden).

Hoe je vergeten inbouwt in AI-systemen

Het bewust inbouwen van vergeten (ook wel 'garbage collection' voor AI-geheugen genoemd) is net zo belangrijk als het onthouden van data. Robuuste LLM-toepassingen passen verschillende technieken toe om het geheugen schoon te houden:

1. Tijdsgebonden verval (TTL): Gegevens in de gespreksgeschiedenis of tijdelijke profielen krijgen een houdbaarheidsdatum. Na bijvoorbeeld 30 dagen inactiviteit wordt de sessie gearchiveerd of gewist.
2. Explicit forget-opdrachten: De gebruiker de optie geven om specifieke herinneringen te wissen ("Vergeet mijn dieetwensen"). Dit kan via een API-aanroep die specifieke rijen uit de geheugendatabase verwijdert.
3. Validatie en scorende relevantie: Systeemprompts kunnen het LLM instrueren om periodiek opgeslagen feiten te controleren op geldigheid en tegenstrijdigheden weg te poetsen.

Voor complexere aanpassingen aan het gedrag van een model kun je eventueel kijken naar finetuning versus prompting en RAG, al is finetuning zelden de juiste oplossing voor dynamisch gespreksgeheugen.

Keuzeschema: Welk geheugen past bij jouw toepassing?

Niet elke chatbot of AI-tool heeft dezelfde geheugenstructuur nodig. Onderstaand schema helpt je de juiste keuze te maken op basis van het type toepassing:

Conclusie

Geheugen in LLM-toepassingen is geen ingebouwde eigenschap van het taalmodel zelf, maar een zorgvuldig ontworpen applicatielaag. Door slim gebruik te maken van contextvensters, gespreksbuffers, samenvattingen en persistente databases kun je systemen bouwen die contextueel en natuurlijk aanvoelen. Tegelijkertijd is het cruciaal om grenzen te stellen door gecontroleerd vergeten toe te passen, zodat je applicatie relevant, snel en privacyvriendelijk blijft.