Geheugen en context: het verschil
Wanneer je interactie hebt met een taalmodel, ontstaat al snel een intuïtieve indruk dat de assistent een eigen bewustzijn en een persoonlijke herinnering heeft. Het model lijkt zich feilloos te herinneren wat je vorige week besprak, of bouwt naadloos voort op een opmerking die je een halfuur geleden maakte. Toch is deze indruk fundamenteel anders dan de werkelijkheid achter de schermen. Wie wil begrijpen hoe taalmodellen functioneren, moet een scherp onderscheid maken tussen de stateless aard van het onderliggende model, de manier waarop de omliggende software de context beheert, en de losstaande systemen die als extern geheugen dienen.
Dit artikel gaat diep in op de technische en architectonische verschillen tussen deze concepten. Wie de diepere technische opbouw van de programmeerkant wil bestuderen, kan terecht bij het achtergrondstuk over geheugen in LLM-apps. Om de specifieke grenzen en de capaciteit van het onderliggende venster volledig te doorgronden, is er de uitgebreide analyse over het contextvenster.
De fundamentele verwarring: geheugen versus stateless berekening
De verwarring over geheugen begint bij de menselijke neiging om software te antropomorfiseren. Mensen onthouden ervaringen, bouwen een gedeelde geschiedenis op en passen hun gedrag permanent aan op basis van eerdere interacties. Een taalmodel werkt echter op een compleet andere manier. Het onderliggende model is in de basis volledig stateless, wat betekent dat het geen enkele staat of herinnering bewaart van de ene berekening naar de volgende.
Bij elke afzonderlijke aanroep die naar het model wordt gestuurd, gebeurt er exact hetzelfde proces. Het model ontvangt een tekstbestand, voert ingewikkelde wiskundige berekeningen uit over de waarschijnlijkheid van het volgende woord, genereert een antwoord, en wist vervolgens direct alle sporen van die berekening uit zijn actieve staat. Technisch gezien begint elk gesprek en elke nieuwe vraag van jouw kant altijd weer bij nul. Het model weet niet wie je bent, wat je een seconde geleden hebt gevraagd, of welke antwoorden het zelf zojuist heeft gegenereerd.
Waarom een gesprek toch samenhangend voelt
Als het model zelf niets onthoudt, rijst de logische vraag waarom een gesprek met een digitale assistent toch zo natuurlijk en vloeiend aanvoelt. Het antwoord hierop ligt niet bij het model zelf, maar bij de toepassing of de gebruikersomgeving waarin het model draait. Deze softwarelaag fungeert als de regisseur van het gesprek.
Telkens wanneer jij een nieuwe reactie typt, pakt de toepassing de volledige geschiedenis van het lopende gesprek erbij. Vervolgens plakt de toepassing al die eerdere berichten — zowel jouw vragen als de antwoorden van de assistent — achter elkaar in één grote tekstbundel. Deze bundel wordt bij elke nieuwe druk op de verzendknop opnieuw integraal naar het model gestuurd. Het model leest dus in één keer het hele verleden opnieuw in, berekent op basis van die totale tekst een logisch vervolg, en stuurt dat terug. Je kunt dit zien alsof je bij elke vraag een steeds dikker wordend script aan een acteur overhandigt, waarin het volledige script tot dan toe opnieuw wordt uitgeschreven.
Deze constante manier van meesturen brengt echter directe gevolgen met zich mee die elke gebruiker vroeg of laat in de praktijk zal merken. Omdat de totale hoeveelheid tekst bij elke beurt groeit, stijgen de verwerkingskosten per beurt aanzienlijk. Bovendien is de capaciteit van deze tekstbundel niet eindeloos. Op een gegeven moment is de grens bereikt en past de geschiedenis simpelweg niet meer in de beschikbare ruimte.
Wat er gebeurt als de geschiedenis te lang wordt
Wanneer een gesprek zo lang duurt dat de totale geschiedenis het maximale limiet overschrijdt, moet de toepassing ingrijpen. Er zijn grofweg drie verschillende strategieën die zo'n systeem kan hanteren om met dit overschot om te gaan, en elke aanpak heeft zijn eigen consequenties voor wat je als gebruiker kwijtraakt.
De meest rigoureuze aanpak is het simpelweg weglaten van de oudste beurten. De software snijdt het begin van het gesprek af alsof het nooit heeft plaatsgevonden. Het nadeel hiervan is dat specifieke instructies, afspraken of context die helemaal in het begin zijn gemaakt, opeens uit het zicht van het model verdwijnen.
Een tweede strategie is het samenvatten van de geschiedenis. De toepassing laat een model (soms hetzelfde model, soms een kleiner model) een compacte samenvatting schrijven van de oudere gespreksdelen. Hierdoor merk je als gebruiker dat details uit het begin van het gesprek langzaam vervagen of verdwijnen, terwijl de grote hoofdlijn van het gesprek wel overeind blijft. Je kunt nog steeds praten over het hoofdonderwerp, maar de specifieke zijsprongen of kleine details van een uur geleden zijn weggezakt.
De derde aanpak is selectief opzoeken. De toepassing bewaart eerdere fragmenten in een externe database en zoekt alleen die stukken op die op basis van je huidige vraag relevant lijken. Dit is een vorm van opzoeken die sterk lijkt op de technieken die worden gebruikt binnen RAG voor beginners, waarbij externe kennis gericht wordt opgehaald.
De derde laag: opgeslagen feiten in de applicatie
Naast de directe conversatiegeschiedenis binnen de context en de stateless berekeningen van het model, is er nog een derde laag die vaak door elkaar wordt gehaald met geheugen: de expliciet opgeslagen feiten over de gebruiker.
Sommige toepassingen bieden de mogelijkheid om vaste voorkeuren, je beroep, je woonplaats of specifieke instructies te onthouden. Dit soort informatie wordt niet bewaard in het brein van het model zelf, en ook niet in de tijdelijke tekstgeschiedenis van het lopende gesprek. In plaats daarvan slaat de applicatie deze feiten op in een gewone database of een gebruikersprofiel. Zodra je een nieuw gesprek start, haalt de software deze opgeslagen feiten op en voegt ze automatisch toe aan de vaste instructies (de system prompt) die met elke aanroep worden meegestuurd.
Dit onderscheid is van cruciaal belang voor de privacy en de controle over je gegevens. Wat er op deze manier wordt 'onthouden', staat ergens fysiek opgeslagen in een database, en het is volledig afhankelijk van de keuzes van de bouwer van de software of en hoe deze gegevens worden beveiligd, ingezien of gewist. Wie dieper wil duiken in hoe je dit soort dynamische context optimaal inricht en beheert, kan terecht bij de inzichten over context engineering.
Het verschil met het bijstellen van het model zelf
Het is belangrijk om dit type applicatiegeheugen scherp te scheiden van het aanpassen van het model zelf. Het manipuleren van de meegestuurde context of het toevoegen van feiten in een database verandert namelijk niets aan de onderliggende gewichten van het taalmodel. Het model blijft exact hetzelfde; het krijgt alleen andere informatie voorgeschoteld.
Het daadwerkelijk veranderen van het model zelf gebeurt via andere methoden, zoals het permanent trainen op nieuwe datasets of het aanpassen van specifieke parameters. Wie de verschillen wil begrijpen tussen het aanpassen van het model via training, het sturen via prompts, of het koppelen van externe bronnen, leest het artikel over finetuning versus prompting versus RAG.
Om deze fundamentele verschillen helder tegenover elkaar te zetten, volgt hieronder een overzicht:
| Laag of concept | Waar bevindt de data zich? | Wat is de impact op het model? |
|---|---|---|
| Onderliggend model | De vaste modelgewichten (stateless) | Geen enkele herinnering na de berekening |
| Gesprekscontext | De meegestuurde tekstbundel in de app | Tijdelijke sturing zolang het gesprek duurt |
| Applicatiegeheugen | Een externe database of profiel | Structurele toevoeging aan elke nieuwe start |
| Finetuning | Permanent aangepaste modelgewichten | Blijvende wijziging van het basismodel zelf |
Beperkingen binnen het contextvenster
Zelfs wanneer alle informatie netjes in het contextvenster van het model wordt gepropt, betekent dit niet automatisch dat het model alles even goed verwerkt. Binnen de computerwetenschap is al vaak aangetoond dat de positie van informatie in de tekst enorm uitmaakt voor de aandacht die het model eraan besteedt.
Informatie die zich exact in het midden van een heel lang document bevindt, krijgt in de praktijk vaak beduidend minder gewicht dan informatie die helemaal vooraan of helemaal achteraan staat. Dit fenomeen zorgt ervoor dat modellen belangrijke instructies of details uit het midden van een lang gesprek over het hoofd kunnen zien, zelfs als die tekst feitelijk binnen de technische limieten valt. Testmethoden zoals de needle in a haystack testmethode zijn specifiek ontworpen om te meten hoe goed modellen erin slagen om op verschillende posities binnen grote hoeveelheden tekst specifieke informatie terug te vinden.
Een groter contextvenster verzacht dit probleem weliswaar doordat er simpelweg meer tekst past, maar het lost het fundamentele aandachtsprobleem niet op. Meer tekst meesturen is in de praktijk lang niet altijd beter; het vergroot de kans op afleiding en vermindert de scherpte van het model.
Praktische gevolgtrekkingen voor de gebruiker
Al deze technische mechanismen hebben directe consequenties voor hoe je efficiënt en effectief gebruikmaakt van taalmodellen in je dagelijkse praktijk. Wie zich bewust is van de achterliggende werking, kan zijn eigen gedrag hierop aanpassen:
- Herhaal belangrijke informatie: Wordt een gesprek erg lang? Grote kans dat oudere instructies zijn wegbezuinigd of naar de achtergrond zijn verdrukt. Herhaal cruciale kaders of criteria daarom expliciet in je nieuwe berichten.
- Start tijdig een nieuw gesprek: Als je van onderwerp wisselt, sleep dan niet de oude context mee. Door een schone lei te beginnen, voorkom je dat het model wordt afgeleid door verouderde informatie uit een eerdere discussie.
- Begrijp de grenzen van onthouden: Vertrouw er niet blind op dat de assistent al je eerdere voorkeuren feitelijk paraat heeft, tenzij deze expliciet zijn vastgelegd in een extern profiel of in de huidige prompt worden meegeleverd.
Voor wie dieper wil duiken in hoe teams en ontwikkelaars dit soort uitdagingen in de praktijk proberen op te lossen, is het nuttig om de discussies en inzichten te volgen via de specialistische hoeken van het netwerk, zoals de bijdragen over context management.
