Contextvenster: hoeveel een AI-model in 2026 in één keer kan lezen

Contextvenster is de maximale hoeveelheid tekst, gemeten in tokens, die een groot taalmodel in één keer kan meenemen bij het genereren van een antwoord. Alles telt mee: de systeeminstructies, het bericht van de gebruiker, de gespreksgeschiedenis, opgehaalde documenten en het antwoord dat het model produceert. Als de limiet is bereikt, moet oudere content worden weggelaten of samengevat.

Zie het als het werkgeheugen van het model en niet als langetermijnopslag. Alles buiten het venster is voor het model bij dat verzoek simpelweg onzichtbaar, en daarom bepalen de grootte en het beheer van het contextvenster wat een AI-assistent daadwerkelijk kan.

Wat is een contextvenster?

Een contextvenster bepaalt hoeveel informatie een model tegelijk in beeld kan houden. Het is geen blijvend geheugen; het is de actieve werkruimte voor één verzoek. Zodra het gesprek of de set documenten het venster overschrijdt, kapt het systeem de oudste delen af of comprimeert het ze tot een samenvatting, omdat de ruwe tokens niet meer passen.

Daarom kan een chatbot het begin van een lang gesprek lijken te vergeten. De vroegste berichten zijn uit het venster weggescrold, tenzij ze expliciet zijn behouden. Als je deze grens begrijpt, verklaart dat veel van hoe en waarom AI-assistenten zich gedragen zoals ze doen.

Tokens: de eenheid van het contextvenster

Contextvensters worden gemeten in tokens, niet in woorden of tekens. Een token kan een teken, een deel van een woord, een heel woord of een kort symbool zijn, voortgebracht door een tokenizer die doorgaans byte-pair encoding gebruikt. Als vuistregel is één token ongeveer vier tekens of ongeveer driekwart woord in het Engels, al verschilt dit per taal en tokenizer.

Omdat facturatie en limieten in tokens zijn uitgedrukt, kost hetzelfde idee beknopt verwoord minder van het venster dan een wijdlopige versie. Bij lange documenten en lange chats bepaalt tokenefficiëntie direct hoeveel er past en hoeveel ruimte er overblijft voor het redeneren en het antwoord van het model.

Hoe contextvensters samenwerken met attention

Transformermodellen verwerken alle tokens in het venster tegelijk met een attention-mechanisme, waarbij elk token in principe naar elk ander token kan kijken. Dat is krachtig maar duur: attention schaalt met het kwadraat van de reekslengte, dus 10000 tokens betekent ongeveer 100 miljoen vergelijkingen en 100000 tokens ongeveer 10 miljard.

Twee verdere beperkingen bepalen het praktische plafond. De key-valuecache groeit met elk gegenereerd token en gebruikt GPU-geheugen, en de geheugenbandbreedte tussen snel en traag geheugen wordt een knelpunt. Samen verklaren deze factoren waarom contextvensters begrensd zijn en waarom grotere vensters meer kosten om te draaien. Het onderliggende ontwerp komt aan bod bij transformerarchitectuur.

Hoe groot zijn contextvensters in 2026?

De venstergroottes zijn snel gegroeid. Eerdere GPT-4-configuraties boden 8192 tokens, terwijl GPT-4o 128000 haalt. Claude-modellen boden 200000 tokens en in nieuwere versies tot 1000000, en van Gemini 1.5 Pro zijn tot 2000000 tokens gedocumenteerd. Open modellen als Llama 3.1 ondersteunen gewoonlijk 128000.

Deze cijfers zijn geadverteerde maxima en geen garanties voor kwaliteit over het hele bereik. Met een groter venster past er meer in, maar zoals de volgende sectie laat zien, is meer laten passen niet hetzelfde als dat het model alles goed gebruikt. De cijfers hier komen uit gepubliceerde bronnen van leveranciers en analisten en zijn geen schattingen.

Beperkingen: het lost-in-the-middle-probleem

Grotere vensters verslechteren op een gedocumenteerde manier. Het lost-in-the-middle-effect betekent dat modellen goed letten op het begin en het einde van hun invoer, maar nauwkeurigheid verliezen bij informatie in het midden. Analyses melden meetbaar kwaliteitsverlies bij modellen met lange context vanaf ongeveer 32000 tokens, en een model met 200000 tokens kan al ruim voor zijn limiet verslechteren.

De praktische les, zoals praktijkmensen het zeggen, is om de specificatietabel niet blind te vertrouwen en je eigen gebruiksgeval te benchmarken bij de lengte die je beoogt. Kleine, gerichte contexten houden de aandacht stabieler vast dan zeer grote contexten die vol zitten met marginaal relevante tekst. Meer tokens kunnen zelfs ruis toevoegen die de kwaliteit van het redeneren verlaagt.

Context beheren: RAG en geheugensystemen

Omdat grotere vensters duur en onvolmaakt zijn, leunen productiesystemen er zelden alleen op. Retrieval augmented generation haalt alleen de meest relevante passages op en voegt ze in, waardoor de prompt klein en gericht blijft. Semantische caching hergebruikt antwoorden op vergelijkbare zoekopdrachten, en geheugensystemen voor agents scheiden kortetermijngesprekken van langetermijnkennis.

Daarom is content chunking ook belangrijk voor uitgevers. Door content op te delen in schone, zelfstandige secties kan een retrievalsysteem makkelijker de juiste passage in een beperkt venster halen, in plaats van het model door een hele pagina te laten ploegen.

Waarom contextvensters ertoe doen voor SEO en GEO

Voor generative engine optimization is het contextvenster de ruimte waarvoor jouw content concurreert binnen een AI-antwoord. Wanneer een assistent als ChatGPT, Perplexity of Gemini bronnen ophaalt, komt maar een beperkt aantal tokens in het venster terecht, dus beknopte, goed gestructureerde passages die de vraag direct beantwoorden worden vaker gebruikt.

Dit beloont duidelijke chunking, schrijven waarbij het antwoord voorop staat en strakke relevantie: dezelfde instincten achter LLM-ready content. Content die tokens verspilt aan opvulling heeft minder kans om retrieval en synthese te overleven, terwijl content die het antwoord compact levert haar plek in het venster verdient en daarmee een kans op een citatie.

Conclusie

Een contextvenster is het tokenbudget dat een model gebruikt om een prompt te lezen en een antwoord te schrijven, en fungeert als werkgeheugen en niet als permanente opslag. Het wordt begrensd door de kosten van attention, cachegeheugen en bandbreedte, en zelfs grote vensters hebben last van het lost-in-the-middle-effect, dus meer laten passen is niet hetzelfde als meer gebruiken.

Voor uitgevers is de les om compacte, goed gechunkte content te schrijven met het antwoord voorop, die retrieval in een beperkt venster overleeft, ondersteund door technieken als retrieval augmented generation en schone content chunking. Bronnen: Redis en Bitfern.