Je plakt honderd pagina's aan documentatie in de prompt en stelt een simpele vraag. Het antwoord is fout. Of het negeert de opmaakregel die je bovenaan hebt gegeven. Je hebt het alles gegeven. Het had moeten werken. Maar dat deed het niet.
Dit is de contextval. De meeste ontwikkelaars gaan ervan uit dat het voeden van een AI met meer informatie automatisch betere resultaten oplevert. Vaak is het tegendeel waar. Het bouwen van betrouwbare AI-applicaties vereist begrip van drie kernmechanismen: hoe modellen tekst tellen, hoeveel ze tegelijkertijd kunnen vasthouden en wat er met informatie gebeurt zodra een gesprek eindigt.
Tokens: De echte munteenheid
Een token is de kleinste eenheid die een taalmodel verwerkt. Het kan een enkel teken zijn, een fragment van een woord, of een heel gebruikelijk woord in zijn geheel. Het woord “purchase” wordt vaak opgesplitst in twee tokens, terwijl een kort woord als “cat” intact blijft. Interpunctie en spaties verbruiken ook tokens. Code is bijzonder hongerig. Een blok Python met geneste inspringing en speciale tekens kan opzwellen tot drie of vier keer het aantal tokens dat je op basis van een snelle blik zou verwachten.
Waarom zouden bouwers dit moeten weten? API-prijzen worden per token berekend. Dat geldt ook voor de verwerkingstijd. Een prompt die eruitziet als twee pagina's tekst kan centen of dollars kosten, afhankelijk van de inhoud. Erger nog: tokens tellen op aan beide kanten van de uitwisseling. Je betaalt voor elk token in je prompt, en je betaalt voor elk token dat het model terug genereert. Ongecontroleerde contextgroei holt op stille wijze de marges uit.
Het contextvenster is een whiteboard
Het contextvenster bepaalt de bovengrens van wat een model in één keer kan zien. Stel je een whiteboard voor dat in een kleine kamer hangt. Je kunt het vullen met systeeminstructies, gebruikersvragen, opgehaalde documenten en eerdere gesprekken. Maar het bord wordt nooit groter. Wanneer er nieuwe tekst binnenkomt, valt de oude tekst van de rand af.
Dit is belangrijk omdat modellen je niet waarschuwen wanneer ze beginnen met het weglaten van inhoud. Als je systeeminstructie bovenaan een lang gesprek staat en je blijft berichten toevoegen, dan scrollt die instructie uiteindelijk uit beeld. Het model kan terugvallen op standaardgedrag, je opmaakregels negeren of eerdere instructies tegenspreken. Verschillende modellen bieden verschillende limieten; sommige verwerken enkele duizenden tokens en andere honderdduizenden, maar de mechanica blijft identiek. Input en output delen hetzelfde budget. Een model dat een antwoord van tweeduizend tokens genereert, heeft tweeduizend tokens minder beschikbaar om te onthouden wat je erover hebt verteld.
Geheugen is een hack, geen functie
Er is geen persistent geheugen binnen de modelgewichten tijdens inferentie. Geen enkele. Wanneer je het tabblad sluit en morgen terugkomt, herkent het model je niet. Elke API-aanroep is een cold start.
Wat aanvoelt als geheugen, is slechts slimme boekhouding door de applicatielaag. De frontend slaat je berichten op in een database. Wanneer je een nieuwe query verstuurt, pakt de software de relevante geschiedenis, voegt deze samen in een nieuwe prompt en stuurt het hele pakket naar het model. Het model zelf heeft er geen weet van.
Dit onderscheid is cruciaal voor productteams. Als je vertrouwt op het model om een gebruikersvoorkeur te “onthouden”, bouw je op drijfzand. Je moet zelf state management bouwen. Beslis wat je cachet. Beslis hoe je het ververst. En besef dat elke byte aan geschiedenis die je opnieuw verstuurt, ruimte op je whiteboard opeet.
Wanneer context ruis wordt
Het overladen van de prompt werkt op voorspelbare manieren averechts.
Ruis doodt het signaal. Als je een volledige codebase dumpt om een vraag te stellen over één bug, krijgt het model te maken met een naald-in-een-hooiberg-probleem. Het kan naar het verkeerde bestand verwijzen, wijzigingen voorstellen in dode code, of een generiek antwoord geven omdat het niet kan