RAG is een datasysteem, geen prompttruc

Retrieval-augmented generation wordt vaak uitgelegd als een eenvoudig recept: verdeel documenten in stukken, maak embeddings, zoek de dichtstbijzijnde resultaten en plaats die in een prompt.

Dat recept volstaat voor een demo. Het volstaat niet voor een betrouwbaar systeem.

RAG in productie is een datasysteem met een taalmodel aan het einde. De kwaliteit hangt af van ingestie, documentstructuur, rechten, ranking, actualiteit, bronvermelding en evaluatie. Een sterker model kan het eindantwoord verbeteren, maar kan ontbrekend of verkeerd opgehaald bewijs niet betrouwbaar herstellen.

De echte pipeline

Een bruikbare RAG-pipeline heeft minstens vijf fasen:

1. Ingestie: documenten verzamelen, metadata bewaren en wijzigingen detecteren.
2. Representatie: bepalen wat voor elk documenttype een opvraagbare eenheid is.
3. Retrieval: kandidaatbewijs vinden via lexicale, semantische of gestructureerde zoekmethoden.
4. Assemblage: bewijs selecteren, ordenen en comprimeren voor het model.
5. Generatie: antwoorden vanuit het bewijs en onzekerheid of bronnen tonen.

Elke fase kan afzonderlijk falen. Alles samenvatten als “vector search” verbergt waar fouten werkelijk ontstaan.

Chunking is een modelleringsbeslissing

Vaste chunks van 500 tokens zijn handig, maar documenten bestaan niet van nature uit gelijke blokken.

Een beleidsdocument heeft secties en uitzonderingen. Broncode heeft symbolen en afhankelijkheden. Een supportgesprek heeft chronologie. Een spreadsheet heeft rijen, kolommen, formules en kopteksten. Alles op tekenaantal splitsen vernietigt waardevolle structuur.

Goede chunking volgt de informatie:

• Houd titels bij de alinea's waarop ze van toepassing zijn.
• Bewaar tabelkoppen samen met relevante rijen.
• Indexeer code per symbool en behoud bestands- en afhankelijkheidsmetadata.
• Houd gespreksturns in tijdsvolgorde.
• Bewaar ouder-kindrelaties zodat retrieval rond een match kan uitbreiden.

Een embedding is slechts zo betekenisvol als de eenheid die ze voorstelt.

Semantische gelijkenis is niet hetzelfde als relevantie

Een embedding vindt tekst met een verwante betekenis. Dat is niet altijd het bewijs dat de gebruiker nodig heeft.

Exacte identificatoren, datums, productcodes, juridische clausules en foutmeldingen werken vaak beter met lexicaal zoeken. Bredere vragen profiteren van semantisch zoeken. Filters kunnen nodig zijn voor klant, taal, datum, documentstatus of rechtengroep.

Daarom gebruiken volwassen systemen vaak hybride retrieval:

Retrieval hoort een beleid te zijn, niet één databasequery.

Meer context kan het antwoord slechter maken

De twintig beste chunks toevoegen voelt veiliger dan de beste vijf. Het kan nuttig bewijs verdunnen, tegenstrijdigheden introduceren, latency verhogen en bronverwijzingen onduidelijk maken.

Het doel is niet maximale context. Het doel is de kleinste set die voldoende bewijs bevat.

Een praktische assembler kan duplicaten verwijderen, passages uit dezelfde bron groeperen, actuele documenten verkiezen en ruimte reserveren voor instructies en toolresultaten. Bij lange bronnen kan het systeem eerst een precieze passage vinden en daarna uitbreiden naar de bovenliggende sectie.

Evalueer retrieval los van generatie

Teams lezen vaak enkele antwoorden en besluiten dat het systeem “goed aanvoelt”. Daarmee vermengen ze twee vragen:

1. Haalde het systeem het bewijs op dat nodig was?
2. Gebruikte het model dat bewijs correct?

Bouw een kleine set echte vragen met gekende relevante bronnen. Meet of die bronnen tussen de kandidaten staan, of ze in de uiteindelijke context komen en of het antwoord erdoor wordt ondersteund.

Bruikbare foutlabels zijn:

• De bron werd nooit ingelezen.
• De juiste chunk bestond, maar werd niet gevonden.
• De juiste kandidaat viel weg tijdens assemblage.
• Opgehaalde bronnen spraken elkaar tegen.
• Het model negeerde of mislas correct bewijs.
• Het antwoord had onzekerheid moeten aangeven.

Die labels vertellen een engineeringteam wat het moet herstellen.

Rechten horen in retrieval

Een gegenereerd antwoord achteraf filteren is te laat. Privé-informatie is dan al in de modelcontext beland.

Autorisatie moet de kandidatenset beperken voordat inhoud wordt opgehaald. De retrievallaag verdient dezelfde ernst als een API of database: tenantgrenzen, gebruikersrollen, auditlogs, verwijdergedrag en rechten per bron.

Onze mening

RAG is nuttig, maar wordt vaak verkocht als een shortcut rond informatiearchitectuur. Het omgekeerde is waar. RAG maakt de kwaliteit van uw informatiearchitectuur zichtbaar.

De systemen die standhouden, zijn niet die met de slimste “chat met uw documenten”-prompt. Het zijn systemen die kunnen uitleggen welke bronnen beschikbaar waren, waarom bepaald bewijs werd gekozen, welke rechten golden en hoe retrievalkwaliteit doorheen de tijd wordt gemeten.