Het contextvenster is het maximale aantal tokens dat een Large Language Model in één verzoek kan verwerken, inclusief zowel de invoer (systeemprompt, gebruikersbericht, opgehaalde documenten, gespreksgeschiedenis) als de gegenereerde output. Moderne contextvensters variëren van 8K tokens voor lichtgewicht modellen tot meer dan 1 miljoen tokens voor frontier-modellen zoals Claude en Gemini. Het contextvenster definieert het werkgeheugen van het model — alles wat het moet overwegen bij het genereren van een antwoord moet binnen deze limiet passen. Wanneer inhoud het venster overschrijdt, is het simpelweg onzichtbaar voor het model, waardoor contextbeheer een kritieke engineeringdiscipline is voor elke niet-triviale AI-applicatie.
Waarom het belangrijk is
Het contextvenster bepaalt wat een LLM kan 'zien' tijdens een enkele interactie. Een venster van 200K tokens klinkt enorm totdat je berekent dat een technische handleiding van 100 pagina's ongeveer 25K tokens verbruikt, een dag klantengespreksgeschiedenis misschien 50K tokens gebruikt, en instructies plus voorbeelden nog eens 2K tokens innemen. Voor applicaties met lange documenten, meerdere gespreksrondes of multi-source RAG beperkt de context-windowgrootte direct wat mogelijk is. Kosten schalen ook met contextlengte — het verwerken van 100K tokens kost ruwweg 12× meer dan 8K tokens verwerken. Dit creëert de fundamentele afweging in AI-applicatieontwerp: meer context opnemen voor betere kwaliteit, of agressief comprimeren voor lagere kosten. Context-compressietechnieken zijn specifiek als kritieke optimalisatiediscipline ontstaan om de waarde per token context te maximaliseren.
Hoe het werkt
De transformer-architectuur van het model verwerkt alle tokens in het contextvenster gelijktijdig via aandachtsmechanismen. Elk token let op elk ander token, waarbij de computekosten kwadratisch schalen — het verdubbelen van de context van 50K naar 100K tokens verviervoudigt ruwweg de aandachtsberekening. Dit is waarom grotere contextvensters meer compute vereisen en meer kosten. In de praktijk wordt het contextvenster op volgorde gevuld: eerst de systeemprompt, dan eventuele geïnjecteerde context (RAG-documenten, toolresultaten), vervolgens gespreksgeschiedenis, en tot slot het huidige bericht van de gebruiker. Als het totaal het venster overschrijdt, moet eerdere inhoud worden ingekort of samengevat. De meeste applicaties implementeren een contextbeheerstrategie — sliding windows die alleen recente beurten bewaren, samenvatting van oudere context, of prioriteitsgebaseerde inclusie waarbij de meest relevante inhoud altijd behouden blijft.
Voorbeeld
Een onderzoeksteam bouwt een AI-assistent die wetenschappelijke papers analyseert. Elk paper is gemiddeld 12K tokens. Het team wil dat het systeem drie papers tegelijk vergelijkt met een gedetailleerde analyseprompt (2K tokens) en gesprekscontext behoudt (3K tokens). Totaal benodigd: 39K tokens — ruim binnen een venster van 200K tokens maar duur op schaal. Ze implementeren een tweelaagse strategie: voor de initiële analyse worden de volledige papers in de context geladen. Voor vervolgvragen worden alleen de relevante secties (geïdentificeerd via semantisch zoeken op embeddings) opgenomen, waardoor de context wordt teruggebracht tot 8K tokens per verzoek. Deze context-compressiebenadering verlaagt de kosten met 80% bij vervolgvragen met behoud van antwoordkwaliteit, doordat het model alleen de passages ziet die het daadwerkelijk nodig heeft in plaats van hele papers.