Long context versus RAG

Wat is long context versus RAG?

Long context versus RAG is een ontwerpkeuze die je één keer per AI-functie maakt: steek je de volledige set documenten in de prompt, of bouw je een zoekstap die per vraag de relevante stukken ophaalt en enkel die meestuurt?

Tot 2024 beantwoordde die vraag zichzelf, want het context window was te klein voor meer dan een paar bladzijden. Dat is veranderd. In september 2026 neemt elk Claude-model vanaf de 4.6-generatie een miljoen tokens invoer aan het standaardtarief, en de Gemini Pro-modellen van Google nemen een miljoen sinds 2.5 Pro. Een dichtbedrukte bladzijde is zo'n 500 tot 1.000 tokens, dus een miljoen tokens komt neer op duizend tot tweeduizend bladzijden. Een volledig reglement, een jaar aan verslagen van de raad van bestuur of een hele set leverancierscontracten past dus in één aanroep.

Daardoor is RAG optioneel geworden waar het vroeger verplicht was. Overbodig is het niet. De twee aanpakken geven je geld op een andere plaats uit: long context betaalt per vraag, RAG betaalt vooraf.

Waar long context goed in is, en wat het je kost

Long context werkt het best als de set documenten één ding is, of een kleine en stabiele verzameling, en de vragen alles tegelijk nodig hebben. Lees dit contract en lijst elke clausule op die de aansprakelijkheid naar ons verschuift. Vergelijk deze drie offertes op leveringsvoorwaarden. Vat het hele auditrapport samen. Een zoekstap zou moeten raden welke passages ertoe doen, en bij zulke vragen is het eerlijke antwoord: allemaal.

Het tweede voordeel is dat er niets te bouwen valt. Geen pipeline, geen index, geen embeddingstap. Je laadt de documenten, je stelt je vraag, je krijgt een antwoord, en een eerste werkende versie kost een fractie van de moeite die een zoekpijplijn vraagt.

De kost komt in drie vormen. Ten eerste tokens per aanroep. Elke vraag stuurt de volledige set opnieuw mee, dus een set van 300 bladzijden kost telkens diezelfde paar honderdduizend inputtokens, of de vraag nu één clausule nodig heeft of alle. Ten tweede snelheid: de Gemini-documentatie van Google zegt het gewoon, een langere prompt wacht langer op zijn eerste token. Ten derde juistheid, en dat is de kost die mensen vergeten. Een model gebruikt een vol window minder goed dan een kort. De metingen staan in het lemma over context rot; de korte versie is dat het terugvinden van feiten slechter wordt naarmate de invoer groeit, dat feiten in het midden van een lange prompt minder betrouwbaar gevonden worden dan feiten vooraan of achteraan, en dat een prompt die herleid is tot wat ertoe doet meestal wint van de volledige.

Tegen de tokenkost bestaat een remedie: prompt caching. Staat de set documenten vooraan in de prompt en verandert ze niet tussen twee vragen, dan bewaart de aanbieder de verwerkte prefix en rekent hij een fractie aan om die te hergebruiken. Op de API van Anthropic kost een cache read een tiende van de normale inputprijs, en een veertigste op de nieuwste modellen. De documentatie van Anthropic gebruikt precies dit geval als voorbeeld: een juridische overeenkomst van 50 bladzijden in het system message, gecachet, en dan vraag na vraag bevraagd. Voor de juistheid doet caching niets, en de volgende vraag moet binnen de levensduur van de cache binnenkomen, standaard vijf minuten.

Waar RAG goed in is, en wat het je kost

RAG kan wat geen enkel window kan. Een corpus van 20.000 documenten loopt op tot honderd miljoen tokens of meer, en hoe groot windows ook worden, een vraag over één factuur hoort niet elke factuur te lezen.

Los van de omvang zijn er vier dingen die je enkel met RAG krijgt. Toegangsrechten per document, want de zoekstap kan filteren op wie de vraag stelt, en dan krijgt de verkoper nooit het HR-dossier te zien. Actualiteit, want een document dat om negen uur geïndexeerd is, kan om vijf na negen bevraagd worden zonder dat iemand een prompt herbouwt. Bronverwijzingen, want het model heeft enkel specifieke passages gezien en kan er dus naar wijzen. En de kost per vraag: twintig opgehaalde chunks zijn een paar duizend tokens in plaats van een paar honderdduizend, hoe groot het corpus ook wordt.

De prijs is een pipeline. Je moet de documenten parsen, een strategie voor chunking kiezen, een embedding-model draaien, een vector database of zoekindex up-to-date houden, en de rechten in de index gelijk houden met de rechten in het bronsysteem. Dat is software, en software moet onderhouden worden.

De andere prijs is een mislukte zoekstap. Zit de juiste passage niet in wat opgehaald werd, dan antwoordt het model op basis van wat het wel kreeg, vlot en fout. Anthropic heeft dat in 2024 gemeten op eigen testcorpora: een gewone zoekopdracht op embeddings miste de nodige chunk in de top twintig in ongeveer zes procent van de gevallen, en met contextbeschrijvingen per chunk en een reranker zakte dat naar ongeveer twee procent. Twee procent is goed. Het is ook een fout die long context gewoon niet kan maken.

Long context versus RAG: wat je per vraag betaalt en wat je één keer bouwt

De zuiverste manier om de twee te vergelijken is de terugkerende kost scheiden van de eenmalige.

Long context heeft een eenmalige kost van bijna nul en een terugkerende kost die meegroeit met de grootte van de set. Elke vraag draagt de hele set mee, aan het volle tarief zonder caching en aan een tiende of minder ermee. Ook het risico op fouten groeit met de set, want meer tokens in het window betekent meer context rot.

RAG heeft een echte eenmalige kost, de pipeline en de index, plus een onderhoudskost die meegroeit met hoe vaak de documenten veranderen. De terugkerende kost per vraag is klein en groeit niet mee met het corpus. Het risico op fouten zit in de zoekstap in plaats van in het window: het model leest een korte, relevante prompt, maar enkel als de zoekstap de juiste passages gevonden heeft.

Een team van Google DeepMind en de University of Michigan vergeleek in 2024 beide aanpakken op dezelfde vragen en vatte het in één zin samen: met genoeg context scoorde long context gemiddeld hoger, en de veel lagere kost bleef het duidelijke voordeel van RAG. Het verschil liep van grofweg 4 tot 13 procentpunten, afhankelijk van het model. Je koopt dus juistheid op vragen over meerdere documenten met tokens, of je koopt goedkope vragen met bouwwerk en een zoekrisico.

De hybride waar de meeste productiesystemen op uitkomen

In de praktijk kiezen de systemen die goed draaien geen kamp. Ze halen ruim op en geven het model daarna een grote maar begrensde context.

Het patroon: gebruik een zoekstap om het corpus te herleiden tot de vijftig of honderd passages, of de vijf of tien documenten, die er redelijkerwijs toe kunnen doen, en geef dat allemaal aan een model met een groot window. Dus niet de drie chunks die RAG-systemen vroeger meestuurden toen windows klein waren. De zoekstap doet waar ze goed in is, miljoenen tokens terugbrengen tot tienduizenden, en het window doet waar het goed in is, over die overblijvers heen lezen en ze combineren.

Hetzelfde team van DeepMind stelde een routingversie hiervan voor: probeer eerst de opgehaalde passages, laat het model zeggen of ze volstaan, en val enkel terug op de volledige context als dat niet zo is. Op hun cijfers bleef de juistheid dicht bij die van volledige long context, aan 40 tot 65 procent lagere kost naargelang het model. Anthropic beschrijft dezelfde vorm in zijn technische richtlijnen voor agents: een paar referentiebestanden vooraf in de context, al de rest just in time opgehaald via zoektools. Claude Code werkt zo, met zijn instructiebestanden altijd aanwezig en de codebase bereikbaar via grep.

Begrensd is het woord dat het werk doet. Databricks draaide die test in 2024 over dertien modellen en zag de kwaliteit van de antwoorden stijgen naarmate er meer opgehaalde context bijkwam, tot op een punt, en daarna terugvallen. Dat kantelpunt verschoof met het model en met de documentenset, van enkele duizenden tokens tot ruim boven de honderdduizend. De hybride is dus niet alles ophalen en dumpen. Het is ruim ophalen, en dan meten waar jouw model stopt met beter worden.

Een beslisregel die je in een vergadering kan gebruiken

Afgeronde cijfers, bedoeld om over te discussiëren, niet om blind toe te passen.

• Minder dan een paar honderd bladzijden, stabiele set, iedereen mag alles zien: long context met prompt caching. De richtlijn van Anthropic zelf is sinds 2024 dat een kennisbank onder grofweg 200.000 tokens, een paar honderd dichtbedrukte bladzijden, gewoon in de prompt kan. Sla de pipeline over.

• Meer dan dat, of rechten per gebruiker, of documenten die dagelijks veranderen: RAG. Eén van die drie volstaat. Rechten alleen al sluiten een gedeelde prompt uit, en een set die elke dag verandert breekt sowieso de cache.

• Vragen die over veel documenten tegelijk gaan: allebei. Haal ruim op en geef het model daarna tienduizenden tokens in plaats van een handvol chunks.

Een rekenvoorbeeld uit het soort bedrijf waar we meestal voor werken.

Een producent heeft veertig bladzijden leverancierscontracten, vijf documenten, één keer per jaar heronderhandeld. Aankoop stelt misschien tweehonderd vragen per maand: opzegtermijnen, clausules over prijsherziening, wie het transportrisico draagt. Veertig dichtbedrukte bladzijden zijn zo'n 40.000 tokens. Op Claude Sonnet 5 aan 2 dollar per miljoen inputtokens is dat ongeveer 8 cent per vraag, dus zo'n 16 dollar per maand, en met caching minder dan een cent per vraag. De hele functie is een system prompt met vijf pdf's erin. Een zoekpipeline bouwen voor dit geval kost meer dan tien jaar aan vragen.

De SharePoint van datzelfde bedrijf bevat 20.000 documenten: offertes, leveringsbonnen, kwaliteitsrapporten, HR-dossiers. Aan een paar duizend tokens per document kom je vlot aan honderd miljoen tokens, honderd keer eender welk window, en de helft ervan is niet voor iedereen bestemd. Dit is RAG, met een index die filtert op de rechten van wie de vraag stelt. Elke vraag stuurt misschien twintig opgehaalde chunks van 500 tokens, ongeveer 10.000 tokens, of 2 cent op hetzelfde model. De eenmalige kost is de pipeline: parsen, chunking, een index, en een synchronisatie die wijzigingen in documenten en in rechten volgt.

En als kwaliteit vraagt welke leveranciers het voorbije kwartaal een leveringsklacht hadden én een prijsherziening in hun contract, dan is dat een vraag over meerdere documenten. Haal de klachten en de contractclausules op, en laat een groot window ze samen lezen.

Waar moet je op letten bij long context versus RAG

Het window is een limiet, geen doel. Google meldt bijna perfecte scores als een model één verstopt feit moet terugvinden in een lange prompt, en voegt eraan toe dat de juistheid zakt zodra de vraag meerdere feiten tegelijk nodig heeft. Echte vragen hebben meerdere feiten nodig. Test op de lengte waarop je echt gaat draaien.

Een wijziging in de set breekt de cache. Eén aangepast document vooraan in de prompt en de volgende aanroep betaalt het volle tarief voor de hele set. Veranderen de documenten vaker dan de levensduur van de cache, dan cache je niet, dan betaal je bij elke aanroep de meerprijs voor een write.

Bij sommige aanbieders verspringt het tarief op 200.000 tokens. Anthropic rekent het volledige miljoen aan één tarief. Google rekent op Gemini Pro het dubbele per inputtoken boven 200.000 tokens. Kijk op de prijspagina van het model dat je echt gebruikt voor je de set dimensioneert.

RAG geeft je de rechten er niet gratis bij. Filteren op de identiteit van de vraagsteller werkt enkel als de index de rechten kent, en de synchronisatie die dat juist houdt is het stuk dat de meeste projecten te licht bouwen.

Meet allebei voor je beslist. Neem vijftig echte vragen, draai ze tegen de volledige set in één prompt en tegen een zoekprototype, en vergelijk de antwoorden. De regel hierboven is een vertrekpunt; jouw documenten en jouw model beslissen.