Goede context geven aan een LLM betekent dat je het model precies de informatie meegeeft die het nodig heeft om jouw vraag relevant te beantwoorden, en niet meer dan dat. Een Large Language Model heeft geen idee wie je bent, wat je probeert te bereiken of in welke organisatie je werkt, tenzij je dat vertelt. De kwaliteit van je context bepaalt voor een groot deel de kwaliteit van het antwoord. Dit artikel beschrijft hoe je context opbouwt, waarom contextkwaliteit belangrijker is dan contextgrootte, en welke fouten je in de praktijk wilt vermijden.
Wat is context bij een LLM en waarom telt het zo zwaar
Context is bij een LLM alle tekst die je samen met je vraag meestuurt: achtergrondinformatie, voorbeelden, documenten, eerdere berichten in het gesprek en eventuele instructies over toon of formaat. Het model gebruikt die tekst om de betekenis van je vraag te bepalen en een passend antwoord te genereren. Zonder context valt het model terug op generieke aannames, en dat zie je terug in het antwoord.
Een eenvoudig voorbeeld: het woord “model” betekent iets anders in een gesprek over machine learning dan in een gesprek over fotografie. De omliggende tekst stuurt de interpretatie. Voor professionals werkt dit precies zo, alleen dan op een hoger niveau. Een vraag over “een goede strategie voor onze nieuwe campagne” levert een ander antwoord op afhankelijk van of het model weet dat je een B2B-SaaS verkoopt aan HR-managers of een lokale fysiotherapiepraktijk runt.
Context bestaat uit verschillende lagen die elkaar aanvullen. De directe vraag is één laag, maar daaromheen heb je doelgroep, branche, eerder werk dat als referentie dient, gewenste toon, en harde randvoorwaarden zoals woordaantal of opmaak. Hoe duidelijker je die lagen scheidt, hoe beter het model erop reageert. Een goede inleiding op het bredere onderwerp staat in het artikel over wat een prompt is.
Hoe het contextvenster werkt
Het contextvenster van een LLM is de hoeveelheid tekst die het model in één keer kan verwerken, gemeten in tokens. Een token is een stukje tekst van gemiddeld drie tot vier letters; een Nederlandse zin van tien woorden is grofweg vijftien tot twintig tokens. Moderne modellen zoals Claude Sonnet 4.5 en GPT-5 werken met contextvensters van honderdduizenden tokens, ruim genoeg voor lange documenten of complete gesprekken.
Belangrijk om te beseffen: het contextvenster is geen geheugen. Een chatmodel onthoudt geen eerdere gesprekken; bij elk nieuw gesprek begint het opnieuw. In een doorlopende chatsessie wordt de hele gespreksgeschiedenis opnieuw meegestuurd zodat het model de samenhang ziet. Naarmate dat gesprek langer wordt, vult het venster zich vanzelf, ook als jij niets nieuws toevoegt.
Bij API-gebruik werkt dit nog explicieter. In de Python-integraties die ik bouw met de Claude API moet bij elk verzoek de volledige relevante context worden meegestuurd, inclusief eerdere uitwisselingen die voor de huidige vraag van belang zijn. Dat dwingt tot keuzes: wat geef je mee en wat laat je weg. Diezelfde discipline helpt ook bij gewoon gebruik via de chat-interface.
Waarom contextkwaliteit zwaarder weegt dan contextgrootte
Een groot contextvenster is geen vrijbrief om alles erin te gooien. Een veelvoorkomende denkfout is dat meer context altijd tot betere antwoorden leidt. In de praktijk zie je vaak het tegenovergestelde: hoe meer ruis je toevoegt, hoe meer moeite het model heeft om de relevante signalen eruit te halen.
Onderzoek uit Stanford, UC Berkeley en Samaya AI heeft aangetoond dat LLM’s informatie vooraan en achteraan in de context het beste verwerken. Wat in het midden van een lange context staat, wordt minder goed gebruikt in het antwoord. Dit fenomeen staat bekend als het “lost in the middle”-probleem en is zichtbaar bij meerdere modelfamilies. Praktisch gevolg: als je een lang document meegeeft en een specifieke vraag stelt, kan kritieke informatie die in het midden van dat document staat onderbelicht blijven, ook al staat de letterlijke tekst in het venster.
De les voor dagelijks gebruik: zet je belangrijkste instructies en de kerninformatie aan het begin of aan het einde van je prompt, en houd de context tussen die punten zo kort mogelijk. Dat klinkt eenvoudiger dan het is. Wie eenmaal een lang document of een grote dataset bij de hand heeft, voelt de neiging om “voor de zekerheid alles maar mee te sturen”. Die reflex levert zelden betere antwoorden op.
Een tweede reden om context strak te houden is kostenbeheersing bij API-werk. Een Python-script dat honderden keren per dag een prompt verstuurt met onnodig veel tokens loopt sneller op dan je verwacht. In de Claude API e-learning komt dit punt expliciet terug, omdat het verschil tussen een efficiënte en een verspillende prompt direct doorwerkt in je rekening.
Een werkbare structuur voor je context
Een werkbare structuur voor context bestaat uit vier blokken die je in deze volgorde meegeeft. Eerst de rol of het kader: tegen wie praat het model en waarvoor wordt het ingezet. Daarna de achtergrondinformatie: wie is de doelgroep, wat is het doel, welke randvoorwaarden gelden. Vervolgens de eigenlijke taak: wat moet het model concreet doen. En tot slot het gewenste outputformaat: lengte, opbouw, toon, eventueel een voorbeeld.
Deze volgorde is geen wet, maar het werkt in de praktijk omdat het model bij het lezen van de prompt steeds verder inzoomt. Eerst plaats je het in de juiste situatie, dan geef je het de bouwstenen, dan de opdracht, dan de verpakking. In dezelfde volgorde leest een collega ook een briefing.
Voor langere taken loont het om context in fasen op te bouwen in plaats van alles in één prompt te dumpen. Een techniek die hierbij helpt is prompt chaining, waarbij je het model eerst laat samenvatten of analyseren en die output gebruikt als input voor de volgende stap. Voor opdrachten waarin redenering belangrijk is, werkt chain-of-thought prompting goed: je vraagt het model expliciet om stap voor stap te denken voordat het tot een antwoord komt.
Wanneer RAG een betere keuze is dan een grote prompt
Soms is je relevante informatie te groot voor één prompt: een complete kennisbank, een productdocumentatie van duizenden pagina’s, of een archief van klantcontacten. In dat soort situaties wordt Retrieval-Augmented Generation (RAG) interessant. Bij RAG bouw je een systeem dat eerst de meest relevante stukken uit een grote dataset ophaalt, en die selectie als context aan het LLM meegeeft. Het model krijgt dus niet alles, maar wel de juiste fragmenten.
Dit werkt goed voor situaties waarin de onderliggende informatie regelmatig verandert (kennisbanken, documentatie, intranet) of waarin de totale dataset gewoonweg te groot is om te laden. Het is geen oplossing voor alles. Wie een eenmalige analyse doet op een document van honderd pagina’s, heeft geen RAG-systeem nodig; dat past prima in het contextvenster van een modern model.
RAG vereist technische infrastructuur: een vectorzoekmachine, een embedding-model, en logica die bepaalt welke fragmenten worden opgehaald. Voor de meeste kenniswerkers is RAG bouwen niet de eerste stap. Beter beheersen wat je in een gewone prompt kunt doen, levert eerder rendement op. Pas wanneer je tegen de grenzen aanloopt — meer informatie dan in één venster past, of informatie die te vaak verandert om handmatig mee te sturen — wordt RAG een serieuze overweging.
Veelgemaakte fouten bij context geven
Goede context geven aan een LLM gaat in de praktijk vaak mis op een paar terugkerende punten. De meest voorkomende fout is te vaag zijn. Een prompt als “schrijf iets over onze nieuwe dienst” geeft het model geen kader, geen doelgroep en geen format. Het antwoord is voorspelbaar generiek. De oplossing is niet langer schrijven, maar specifieker schrijven: wie leest dit, wat is de gewenste actie, welke toon past bij ons merk.
Een tweede fout is context en instructies door elkaar heen schrijven. Wanneer achtergrondinformatie en opdracht in één lange alinea zitten, moet het model raden welk deel beschrijft en welk deel vraagt. Scheid die twee. Een blok “context” gevolgd door een blok “taak” werkt beter dan een lopend verhaal waarin alles vermengd is.
Een derde fout is alle beschikbare informatie meesturen “voor de zekerheid”. In de content engine die ik voor LearnLLM heb gebouwd, was dit een vroeg leermoment. Hoe meer ik in een prompt propte, hoe inconsistenter de output werd. De versie die uiteindelijk in productie ging, geeft per stap precies de informatie die voor die stap nodig is en niets meer. Dat leverde stabielere resultaten op dan alle eerdere varianten met meer context.
Een vierde fout is irrelevante context laten staan uit eerdere stappen. Bij langere chatsessies blijft alles wat je eerder hebt gevraagd in het venster zitten. Als je halverwege overstapt op een nieuw onderwerp, sleur je de oude context mee. Soms is een nieuw gesprek starten effectiever dan doorgaan in dezelfde sessie. Een uitgebreidere uitleg van prompt-discipline staat in het artikel over how ChatGPT works.
Context als onderdeel van een herhaalbare werkwijze
Context geven aan een LLM is geen losse vaardigheid maar een onderdeel van een bredere werkwijze. Wie elke prompt opnieuw verzint, krijgt elke keer een ander resultaat. Wie vaste sjablonen bouwt voor terugkerende taken, en die sjablonen blijft verbeteren op basis van de output, bouwt een werkwijze op die voorspelbare resultaten oplevert. Dat is precies het verschil tussen losse promptbeheersing en professioneel AI-gebruik.
In mijn eigen werkwijze ben ik van losse prompts naar workflows gegaan toen ik fouten in productie zag belanden. Een goed gestructureerde context met heldere randvoorwaarden voorkomt een groot deel van die fouten. Het andere deel vang je op met controlepunten achteraf: terugleessessies, eindredactie, en bij API-werk geautomatiseerde validatie van de output.
Wie deze aanpak systematisch wil leren toepassen op het eigen werk, vindt in de ChatGPT course van LearnLLM een werkwijze met vaste stappen, voorbeelden uit de praktijk en een eindopdracht waarin je een eigen workflow bouwt. Schrijf je in voor de e-learning Professioneel werken met ChatGPT en zet context geven in als een vaste discipline in plaats van een toevallige vaardigheid.
