RAG zonder hype: wanneer retrieval het lange prompt verslaat

Vrijdagmiddag. Je plakt het hele leveranciershandboek van 180 pagina's in het prompt, hangt de vraag eraan en wacht. Het model antwoordt vol vertrouwen en citeert sectie 4.2. Sectie 4.2 bestaat niet. Sectie 4.1 gaat over betaaltermijnen; jij wilde clausule 7.3 over aansprakelijkheid. Het model heeft alles gelezen en niets specifieks onthouden.

Dit gebeurt vaker dan mensen toegeven. De oplossing is zelden een groter context window. De oplossing is meestal een kleine retrieval-laag voor het model. RAG (retrieval-augmented generation) wordt steeds afgeschreven als patroon van vorig jaar, nu er context windows van een miljoen tokens uitkomen. Voor het werk dat je team echt doet, klopt die afschrijving niet.

De valkuil van 200k tokens

Lange context werkt. Wij gebruiken het. Voor één contract, één onderzoeksrapport, één onboarding-document is het hele stuk plakken prima. Het model kan een samenhangend argument vasthouden over het document, omdat niets anders om aandacht vecht.

De valkuil zit in wat er gebeurt na één document. Drie dingen stapelen zich op:

• Kosten. Een input prompt van 180k tokens kost bij de huidige Sonnet-tarieven ongeveer $0,54 per call, exclusief output. Draai dat 4.000 keer per maand en je hebt een factuur met vijf cijfers voor een functie die je team nu nog zelf afhandelt.
• Latency. Time-to-first-token loopt op met de lengte van het prompt. Een strakke retrieval-query komt meestal onder de 200ms terug; de warm-up van een prompt van 180k tokens meet je in seconden.
• Verdunde aandacht. Het bekende "lost in the middle"-effect. Modellen onthouden het begin en het einde van een lange context beter dan het midden. Plak 80 documenten en kijk hoe het model zich vastbijt in de eerste drie en de laatste twee.

Wat retrieval echt doet

Haal het acroniem weg en RAG is één zin. Je hakt je bronmateriaal in kleine stukken, zet elk stuk om naar een vector, en op het moment van de query trek je de paar chunks die het dichtst bij de vraag liggen. Het model ziet alleen die paar chunks. Het leest minder. Het antwoordt op basis van geciteerd bewijs.

Het werk zit niet in de embedding-call. Het werk zit in beslissen wat een "chunk" is, wat je corpus eigenlijk bevat, en hoe je meet of de juiste chunks terugkomen.

Wanneer het langere prompt wint

Beoordeel het werk eerlijk voordat je naar vectoren grijpt. Lange context is het juiste gereedschap als:

• Het hele corpus uit één document bestaat en het antwoord kruisverwijzingen nodig heeft die de chunker aan flarden zou scheuren. Bijvoorbeeld een contract van 60 pagina's dat je van begin tot eind nakijkt.
• Je de taak één of twee keer draait. Een index opzetten voor eenmalig werk is een verspilde middag.
• De bron onder de 100k tokens past en één keer per sessie wordt gelezen.

Als dat op jouw situatie slaat, plak het document erin en ga verder. Bouw geen infrastructuur die je nooit meer gebruikt.

Wanneer retrieval ruim wint

De andere kant van de streep:

• Het corpus verandert. Productdocumentatie, ticketgeschiedenis, interne wiki, verzendvoorwaarden die wekelijks worden bijgewerkt. Bij elke query opnieuw plakken is onwerkbaar.
• Je hebt honderden documenten en geen idee vooraf welke de vraag raakt.
• Kosten per query tellen omdat de functie duizenden keren per dag draait.
• Je hebt citaties nodig waar de gebruiker op kan klikken. Antwoorden uit lange context vertellen niet uit welke pagina ze komen. Retrieval doet dat van nature.

Een minimale retrieval-setup

Je hebt geen leverancier van een vector database nodig. Postgres met de pgvector-extensie dekt de eerste twee jaar van de meeste projecten. Eerst het schema:

create extension if not exists vector;

create table docs (
  id        bigserial primary key,
  source    text     not null,
  chunk     text     not null,
  embedding vector(1536)
);

create index docs_embedding_idx
  on docs using ivfflat (embedding vector_cosine_ops)
  with (lists = 100);

Query-kant, in Node:

import { Client } from 'pg';
import OpenAI from 'openai';

const db = new Client({ connectionString: process.env.DATABASE_URL });
const ai = new OpenAI();
await db.connect();

async function retrieve(question, k = 5) {
  const { data } = await ai.embeddings.create({
    model: 'text-embedding-3-small',
    input: question,
  });
  const vec = `[${data[0].embedding.join(',')}]`;

  const { rows } = await db.query(
    `select source, chunk
       from docs
       order by embedding <=> $1
       limit $2`,
    [vec, k]
  );
  return rows;
}

const hits = await retrieve(
  'What is the liability cap in the EU supplier contract?'
);
console.log(hits.map(r => `[${r.source}] ${r.chunk.slice(0, 120)}`).join('\n\n'));

Vijf chunks. Eén database. Geen nieuwe leverancier op de factuur. Het model krijgt de vraag plus de vijf meest relevante snippets, met de opdracht om alleen vanuit die snippets te antwoorden. Die laatste regel geeft je betrouwbare citaties.

Chunking is waar de meeste setups stranden

Naïeve chunking knipt de tekst om de N tekens. Het hakt een zin doormidden. Het scheidt een tabelkop van zijn rijen. Het scheidt een clausule van zijn definitie. De retrieval ziet er prima uit in tests, en breekt op het moment dat een echte vraag op een knipgrens valt.

Twee patronen die overeind blijven:

• Recursief splitsen op structuur. Eerst op koppen, dan alinea's, dan zinnen. Zet het pad (Sectie 4 > Clausule 3) in de metadata van de chunk, zodat het model ernaar kan verwijzen.
• Overlap. Elke chunk deelt ongeveer 15% van zijn inhoud met de buur. Goedkope verzekering tegen slechte knipgrenzen.

Heeft je corpus structuur (Confluence, Notion, een docs-site met H2's en H3's), gebruik die. Generieke vensters van 500 tokens zijn het laatste redmiddel, niet de standaard.

Voorbij het basispatroon

Als pure vector-search tegenvalt, is de volgende stap meestal hybride retrieval: combineer BM25 (keyword) en vector-scores. Een aantal van de interessantere resultaten die we hebben gezien, komt uit graph-aware retrieval. Het FastGraphRAG-project op Hacker News (457 punten, november 2024) legt PageRank over de chunk-graph om chunks te vinden die structureel belangrijk zijn, niet alleen lexicaal. De moeite waard voordat je besluit dat je basis-setup "goed genoeg" is.

Meten of het werkt

De vaakst gemaakte RAG-fout is uitleveren zonder evals. Je voegt retrieval toe, de antwoorden voelen beter, je noemt het klaar. Twee maanden later zegt een collega "de AI hallucineert weer" en heb je niets om mee te debuggen.

De minimale lat: een CSV met 50 echte vragen en per vraag de chunk-ID die opgehaald hoort te worden. Draai je retrieval er 's nachts overheen. Volg hit@5 (zit de juiste chunk in de top vijf) en MRR (mean reciprocal rank). Zakt één van beide, dan weet jij het voordat de gebruiker het merkt. Kun je niet zeggen wat je hit@5 vorige week was, dan heb je geen RAG-systeem. Dan heb je een demo.

Van theorie naar een echt corpus

Toen we dit voorjaar een knowledge-agent bouwden voor een Nederlandse logistiekklant, was waar we steeds over struikelden dat hun verzendbeleid in drie versies rondzwierf. Het model haalde de verkeerde op met veel zelfvertrouwen. We hebben het opgelost door een supersedes-veld aan elke chunk toe te voegen en te filteren vóór de similarity, niet erna. Werk met AI-agents is voor het grootste deel het debuggen van het corpus, niet van het model.

Audit van vijf minuten die je vandaag kunt draaien: open welke AI-functie je vorig kwartaal hebt opgeleverd, pak het prompt en tel de tokens. Plakt die per request meer dan 20k tokens aan bronmateriaal mee, dan zit er een retrievalprobleem te wachten om ontdekt te worden. Schrijf de drie meest gestelde vragen op. Kun je niet aanwijzen uit welk document elk antwoord zou moeten komen, dan heeft je team eerst een retrieval-laag nodig, en pas daarna een groter model.