Een taalmodel verwerkt tekst niet woord voor woord, maar in tokens binnen een begrensd contextvenster. Lees hoe die limieten werken en welke gevolgen tokenisatie, lange invoer, samenvatten en tekst opdelen hebben voor de verwerking van je gegevens.
Wat tokens zijn en hoe een taalmodel tekst opdeelt
Een token is een eenheid die een taalmodel tijdens verwerking gebruikt. Dat kan een volledig woord zijn, maar ook een woorddeel, leesteken of combinatie van tekens. De tokenizer zet tekst om in zulke eenheden voordat het model ermee rekent. De tekst die het model teruggeeft, wordt met dezelfde soort bouwstenen weer omgezet naar leesbare tekst. Daardoor is het aantal tokens niet gelijk aan het aantal woorden of tekens.
Veelvoorkomende woorden worden vaak efficiënt gecodeerd, terwijl zeldzame namen, samengestelde woorden, spelfouten en technische identifiers uit meerdere tokens kunnen bestaan. Een Nederlandse tekst kan daarom een andere tokenlengte hebben dan een vergelijkbare Engelse tekst. Ook code, tabellen en tekst met veel leestekens kunnen relatief veel tokens innemen. Een globale vuistregel zoals een vast aantal woorden per token is hooguit bruikbaar voor een eerste schatting; de werkelijke verhouding hangt af van taal, onderwerp en tokenizer.
Dit verschil is relevant zodra een applicatie een invoerlimiet heeft of verbruik per token meet. Een document van tienduizend woorden kan niet betrouwbaar worden beoordeeld op basis van het aantal pagina's alleen. Gebruik voor een precieze inschatting de tokenizer die hoort bij het gekozen model. Bij productieprocessen is het verstandig invoer en uitvoer daadwerkelijk te tellen, zeker wanneer documenten sterk uiteenlopen in opmaak of vaktaal.
Hoe een contextvenster de ruimte voor een gesprek begrenst
Het contextvenster is de hoeveelheid informatie die een model tijdens één generatie kan meenemen. Die ruimte wordt doorgaans uitgedrukt in tokens en is een grens voor de verwerkte context, niet voor de lengte van een bestand of gesprek in pagina's. Afhankelijk van de toepassing kan het venster bestaan uit systeeminstructies, gebruikersberichten, eerdere gespreksbeurten, opgehaalde documenten en de ruimte die wordt gereserveerd voor het antwoord.
Een veelvoorkomende misvatting is dat een model met een groot contextvenster alle eerdere informatie in een lange conversatie vanzelf blijft onthouden. In werkelijkheid moet een applicatie doorgaans bepalen welke berichten opnieuw worden meegestuurd. Als de volledige gespreksgeschiedenis bij elke beurt wordt toegevoegd, neemt die invoer geleidelijk toe. Zodra de beschikbare ruimte krap wordt, moet het systeem berichten weglaten, samenvatten of de aanvraag anders verdelen.
De precieze limiet verschilt per model en kan veranderen tussen modelversies. Ook kunnen API's aparte grenzen hanteren voor invoer en uitvoer, naast een totale contextlimiet. Een ontwerp moet daarom niet uitgaan van één generieke maximumwaarde. Controleer de modeldocumentatie en tel alle onderdelen van de aanvraag mee. Houd bovendien ruimte achter de hand voor het antwoord: als invoer vrijwel het volledige venster gebruikt, kan het model weinig tekst genereren of kan de aanvraag worden afgewezen.
Invoer, instructies en antwoord delen hetzelfde tokenbudget
Een modelaanvraag bestaat zelden alleen uit de tekst die een gebruiker heeft ingevoerd. De systeemprompt, taakomschrijving, gesprekshistorie, opmaakregels en eventuele documenten gebruiken eveneens tokens. Het model heeft daarnaast ruimte nodig om een antwoord te genereren. De beschikbare capaciteit is dus een verdeling tussen meerdere onderdelen, niet een onbeperkte hoeveelheid voor de brontekst.
Stel dat een applicatie een lang rapport toevoegt, een uitgebreide instructie meestuurt en ook eerdere conversaties bewaart. Dan kan de effectieve ruimte voor het antwoord aanzienlijk kleiner zijn dan het modelvenster op papier doet vermoeden. Een uitvoerlimiet kan bovendien apart zijn ingesteld. Een aanvraag kan daardoor stoppen voordat alle gewenste informatie is behandeld, ook wanneer de totale contextgrens nog niet is bereikt. Omgekeerd kan een aanvraag het venster overschrijden voordat het model überhaupt begint te antwoorden.
Maak bij het ontwerpen van prompts een expliciet budget per onderdeel. Bepaal hoeveel ruimte nodig is voor vaste instructies, dynamische context en antwoord. Houd rekening met variatie: een uitzonderlijk lang document of een uitgebreide conversatie kan de normale verdeling doorbreken. Log in een applicatie de tokenaantallen per categorie, niet alleen het totaal. Dat maakt zichtbaar of groei vooral ontstaat door chatgeschiedenis, opgehaalde passages of instructies. Wanneer een budget wordt overschreden, kan het systeem gericht oude berichten verwijderen of bronnen selecteren in plaats van willekeurig tekst af te kappen.
Waarom lange invoer meer verwerking en kosten vraagt
Een langere invoer bevat meer tokens die het model moet verwerken. In veel toepassingen hangt het tokenverbruik samen met de hoeveelheid aangeleverde context én met de gegenereerde uitvoer. Daardoor heeft het toevoegen van complete documenten gevolgen voor het gebruik van een model, zelfs wanneer het uiteindelijke antwoord kort is. De concrete kostenstructuur verschilt per dienst en model, maar tokenvolume is vaak een belangrijke factor om te monitoren.
Meer invoer kan ook de responstijd verhogen. Het model moet de context verwerken voordat het antwoord verschijnt, en bij een grotere aanvraag neemt die voorbewerking doorgaans toe. De precieze relatie is afhankelijk van architectuur, hardware, batchverwerking en implementatie; het is dus niet verstandig om een universele lineaire rekensom te hanteren. Wel geldt praktisch dat herhaaldelijk dezelfde lange context meesturen vaak vermijdbare verwerking veroorzaakt.
Langere invoer levert niet automatisch een beter antwoord op. Een document kan irrelevante passages, herhalingen en conflicterende versies bevatten. Die tekst gebruikt capaciteit en maakt het voor het model moeilijker om de relevante informatie te onderscheiden. Dat kan leiden tot antwoorden die belangrijke details missen of gegevens uit verschillende passages door elkaar halen. Selecteer daarom context op basis van de vraag, in plaats van standaard het hele archief mee te sturen. Meet per taak hoeveel tokens nodig zijn en beoordeel de uitkomstkwaliteit naast verbruik en wachttijd. Een kleinere, goed gekozen context kan functioneler zijn dan een maximaal gevulde aanvraag.
Tokenaantallen schatten voor Nederlands, code en opmaak
Een snelle woordtelling is handig voor redactionele planning, maar niet voldoende om te bepalen of tekst binnen een contextvenster past. Tokenisatie reageert op woordfrequentie en schrijfwijze. Een gewoon Nederlands woord kan als één token worden verwerkt, terwijl een specialistische term, productcode of lang samengesteld woord uit meerdere delen bestaat. Namen, URL's, e-mailadressen en willekeurige identificatoren zijn eveneens lastig vooraf in te schatten.
Opmaak speelt mee. Markdown-tabellen, JSON, HTML-tags en lijsten bevatten structuurtekens die tokens kunnen innemen. Bij broncode zijn inspringing, variabelenamen en herhaalde syntax relevant. Een logbestand met veel tijdstempels of unieke waarden kan daardoor veel groter uitvallen dan een lopende tekst van vergelijkbare lengte. Bij meertalige toepassingen kan één taal bovendien een groter aandeel van het budget gebruiken dan een andere taal, ook als het aantal woorden vergelijkbaar is.
Voor experimenteel werk kun je een representatieve steekproef gebruiken en die met de tokenizer van het doelmodel tellen. Neem daarin niet alleen nette voorbeeldtekst op, maar ook de lastigste invoer die in de praktijk voorkomt: tabellen, afkortingen, foutieve tekst, code of scans die via OCR zijn omgezet. In een applicatie hoort de schatting plaats te maken voor meting op de uiteindelijke aanvraag, inclusief vaste prompts en metadata. Stel eventueel een veiligheidsmarge in voor variatie. Zo voorkom je dat een proces alleen werkt voor gemiddelde documenten en onverwacht faalt op een afwijkende bron.
Lange documenten opdelen in bruikbare tekstfragmenten
Wanneer een document niet in één aanvraag past, is opdelen in fragmenten een gangbare aanpak. Een eenvoudige methode splitst tekst na een vast aantal tokens. Dat maakt de grootte voorspelbaar, maar kan een alinea, tabel of redenering middenin afbreken. Een inhoudelijke splitter probeert eerst grenzen te vinden bij hoofdstukken, paragrafen of zinnen en past daarna de fragmentgrootte aan het tokenbudget aan. Zo blijven betekenisvolle eenheden vaker bij elkaar.
Een fragment moet genoeg context bevatten om zelfstandig bruikbaar te zijn, zonder zoveel omliggende tekst mee te nemen dat het budget onnodig groeit. Overlap tussen opeenvolgende fragmenten kan informatie op een grens behouden. Te veel overlap leidt echter tot dubbele passages, hogere verwerking en antwoorden die dezelfde informatie herhalen. De juiste hoeveelheid hangt af van de bron en de taak. Bij contracten kan een clausule samen met definities nodig zijn; bij technische documentatie kan een codevoorbeeld afhankelijk zijn van de voorafgaande uitleg.
Bewaar bij elk fragment metadata zoals documenttitel, sectie, paginanummer en versie. Die gegevens helpen om passages later te selecteren en antwoorden te herleiden. Test de splitter op vragen waarvan het antwoord precies over een grens loopt. Controleer ook tabellen en opsommingen, die bij een naïeve tekenlimiet onleesbaar kunnen worden verdeeld. Fragmenteren is geen puur technische stap: de gekozen grenzen bepalen welke verbanden het model later kan zien en welke informatie afzonderlijk beschikbaar komt.
Documenten samenvatten zonder belangrijke details te verliezen
Samenvatten kan de hoeveelheid context verkleinen wanneer een bron te lang is om volledig mee te sturen. Het model maakt dan een compactere representatie die later als context kan dienen. Dat is bruikbaar voor achtergrondinformatie, voortgang van een gesprek of een overzicht van een omvangrijk dossier. De samenvatting is echter een afgeleide tekst: details die niet zijn opgenomen, zijn voor een volgende stap niet vanzelf beschikbaar.
Een algemene samenvatting kan juist de gegevens weglaten die een specifieke vraag vereist, zoals uitzonderingen, exacte datums, voorwaarden of tegengestelde standpunten. Een alternatief is doelgericht samenvatten. Vraag bijvoorbeeld om afzonderlijke velden voor betrokken partijen, verplichtingen, termijnen en onzekerheden, of maak per hoofdstuk een beknopt overzicht. Gestructureerde samenvattingen zijn eenvoudiger te vergelijken en te combineren, maar vragen om een schema dat past bij de taak. Een te strikt schema kan nuance verliezen of relevante informatie in geen enkel veld laten passen.
Bij zeer lange bronnen kan een hiërarchische aanpak werken: vat passages samen, combineer die samenvattingen per hoofdstuk en bouw daaruit een overzicht op documentniveau. Elke samenvattingsstap kan fouten of interpretaties doorgeven. Bewaar daarom waar mogelijk verwijzingen naar de oorspronkelijke passage en gebruik de samenvatting niet als enige bron voor beslissingen die precieze formulering vereisen. Laat het systeem bij een concrete vraag zo nodig teruggaan naar de relevante brontekst. Zo blijft een compacte context gekoppeld aan controleerbare details.
Relevante passages ophalen in plaats van alles meesturen
Bij grote verzamelingen documenten is het vaak efficiënter om alleen passages op te halen die bij de vraag passen. Een zoeklaag kan documenten indexeren en vervolgens een selectie toevoegen aan de prompt. Dat verlaagt de hoeveelheid irrelevante tekst in de context en maakt het mogelijk bronnen te gebruiken die groter zijn dan één modelaanvraag. De aanpak wordt vaak aangeduid als retrieval-augmented generation, of RAG.
De kwaliteit hangt sterk af van de voorbereiding. Documenten moeten zorgvuldig worden opgesplitst, voorzien van metadata en geïndexeerd met een passende zoekmethode. Vectorzoekopdrachten vinden inhoudelijke verwantschap, terwijl zoekopdrachten op trefwoorden nuttig blijven voor exacte termen, artikelnummers en productcodes. Hybride zoeken combineert die signalen. Vervolgens bepaalt een rangschikker welke fragmenten vooraan komen. Een zwakke splitter of ontbrekende metadata kan relevante informatie onvindbaar maken, hoe krachtig het taalmodel ook is.
Ook het aantal opgehaalde passages vraagt een afweging. Te weinig fragmenten kunnen een antwoord onvolledig maken; te veel fragmenten vullen het venster met ruis en vergroten de kans op verwarring. Stel daarom een tokenbudget in voor de opgehaalde context en rangschik passages op relevantie, actualiteit en bronkwaliteit. Neem bronverwijzingen mee in de prompt en laat het antwoord onderscheid maken tussen onderbouwde informatie en ontbrekende gegevens. Test met echte vragen, inclusief vragen waarop geen passend document bestaat. Een systeem dat altijd een antwoord probeert te formuleren, kan ontbrekende context verhullen.
Lange contexten en de kwaliteit van modelantwoorden
Een model kan technisch een lange context accepteren zonder elk detail daarin even goed te benutten. Informatie op verschillende posities kan uiteenlopend worden opgepakt, en veel concurrerende passages maken het moeilijker om het juiste detail te verbinden aan de vraag. Dit effect wordt soms beschreven als een probleem waarbij informatie in het midden van een lange context minder goed wordt benut. De omvang van het effect hangt af van model, taak, formulering en opbouw van de invoer.
Een groter contextvenster verandert ook niet automatisch de manier waarop een model redeneert. Als documenten elkaar tegenspreken, zijn duidelijke bronlabels, datums en versienummers belangrijk. Zonder die signalen kan een antwoord verouderde en actuele informatie combineren. Bij instructies die op meerdere plekken terugkomen, kan herhaling bovendien onbedoeld conflicten veroorzaken. Plaats cruciale taakregels op een duidelijke, stabiele plek en structureer bronmateriaal met koppen en herkenbare metadata.
Beoordeel lange-contextgedrag met testgevallen die verder gaan dan een vraag naar één letterlijk detail. Test bijvoorbeeld informatie die verspreid staat over meerdere hoofdstukken, tegenstrijdige versies en een vraag die niet door de bron wordt beantwoord. Meet niet alleen of het antwoord plausibel klinkt, maar controleer of het de juiste passages gebruikt en relevante beperkingen noemt. Bij hoge nauwkeurigheidseisen kan een zoek- en verificatiestap beter werken dan het volledige document in één keer aanbieden. Zo wordt contextlengte een ontwerpkeuze die je met meetbare resultaten kunt onderbouwen.
Afbeeldingen, audio en andere invoer in het contextvenster
Bij multimodale modellen bestaat de context niet uitsluitend uit leesbare tekst. Een aanvraag kan afbeeldingen, audio, video of andere gestructureerde gegevens bevatten. Die invoer wordt intern omgezet naar representaties die capaciteit gebruiken, maar de precieze verwerking verschilt per model en modaliteit. Een afbeelding is daarom niet betrouwbaar te schatten als een vast aantal teksttokens. Resolutie, uitsnedes, aantal beelden en de manier waarop een API media verwerkt kunnen allemaal verschil maken.
Voor afbeeldingen kan een model bijvoorbeeld delen op verschillende schaalniveaus analyseren. Een grote afbeelding met kleine tekst of veel details kan daardoor meer verwerkingsruimte vragen dan een eenvoudige afbeelding. Audio kan als transcript worden aangeleverd, maar ook als audio-invoer worden verwerkt; die keuzes leveren niet dezelfde context of fouttypen op. Bij video tellen onder meer het aantal geselecteerde frames en de bijbehorende tijdsinformatie mee. Een prompt die korte tekst lijkt te bevatten, kan dus toch een zware multimodale aanvraag zijn.
Beperk media tot wat de taak vereist. Snijd een afbeelding bij rond relevante onderdelen, kies representatieve videoframes en gebruik een transcript wanneer gesproken inhoud voldoende is. Controleer of metadata zoals tijdstempels of paginanummers behouden moet blijven. Houd bij tokenmetingen rekening met media die niet als gewone tekst zichtbaar zijn in een log. Als een aanvraag onverwacht tegen een contextgrens aanloopt, onderzoek dan niet alleen de tekstlengte maar ook de meegestuurde bestanden en hun omzetting. Zo wordt duidelijk welk onderdeel de beschikbare capaciteit werkelijk gebruikt.
Veelgestelde vragen
Kan een model informatie in een lang contextvenster toch missen?
Ja, een model kan informatie missen, ook als die binnen het contextvenster staat. De maximale contextlengte geeft aan hoeveel informatie het model kan verwerken, maar garandeert niet dat elk detail even goed wordt teruggevonden of gebruikt. Prestaties kunnen afhangen van de positie van informatie, de hoeveelheid afleidende tekst en de vraag die wordt gesteld. Test daarom met realistische voorbeelden, waarbij belangrijke details op verschillende plekken in lange invoer staan. Controleer niet alleen of het antwoord aannemelijk klinkt, maar ook of het aantoonbaar door de bron wordt ondersteund.
Gebruiken afbeeldingen en audio ook ruimte in het contextvenster?
Ja, afbeeldingen en audio kunnen ruimte in het contextvenster gebruiken, maar ze worden niet noodzakelijk geteld als gewone teksttokens. Een afbeelding kan intern worden verwerkt als meerdere beeldonderdelen; audio kan afhankelijk van de taak worden omgezet in tekst of in andere modelrepresentaties. De precieze verwerking verschilt per model en API. Daardoor kun je de benodigde ruimte niet betrouwbaar afleiden uit de bestandsgrootte of uit een gewone woordentelling. Controleer de documentatie van het multimodale model en meet de uiteindelijke aanvraag met de bijbehorende API.
Tellen toolaanroepen mee voor het contextvenster van een taalmodel?
Ja, toolaanroepen en de resultaten ervan kunnen meetellen zodra ze als onderdeel van de modelconversatie worden meegestuurd. Denk aan een zoekopdracht die het model formuleert, de opgehaalde resultaten en eventuele instructies over het gebruik van een tool. Een volgende modelstap kan die informatie nodig hebben om een antwoord te maken. Welke onderdelen precies worden meegerekend, hangt af van de API en de manier waarop de applicatie de conversatie opbouwt. Houd daarom ook toolverkeer bij wanneer je een tokenbudget controleert.
Maakt prompt caching het contextvenster groter?
Nee, prompt caching vergroot het contextvenster niet. Caching kan bij sommige modellen of diensten herhaalde delen van een aanvraag efficiënter verwerken, bijvoorbeeld een vaste instructie die bij veel verzoeken terugkomt. De gecachte tekst blijft doorgaans wel onderdeel van de context die het model voor de aanvraag gebruikt. Of caching beschikbaar is en invloed heeft op kosten of snelheid, verschilt per aanbieder en model. Behandel de contextlimiet dus als afzonderlijke grens en controleer de specifieke voorwaarden in de API-documentatie.
Hoe test ik of een model lange documenten goed kan doorzoeken?
Test een model met vragen waarvan het antwoord op vooraf bekende plekken in lange documenten staat. Plaats relevante feiten bijvoorbeeld aan het begin, in het midden en aan het einde, en neem ook documenten op met afleidende of vergelijkbare informatie. Beoordeel vervolgens of het antwoord het juiste feit vindt en of het naar de juiste passage verwijst. Herhaal de test met verschillende documentlengtes en vraagtypen. Zo ontdek je niet alleen of de invoer binnen de limiet past, maar ook of het model de inhoud betrouwbaar benut.
