Lotook
Om documenten effectief in chunks op te delen voor RAG, splitst u bestanden eerst langs de bestaande documentstructuur, past u op te grote secties een limiet in tokens toe met overlap op zinsniveau en voegt u aan elke passage bronmetadata toe. De keuze tussen chunking op basis van tokens, betekenis en structuur hangt af van de vraag of uw corpus bestaat uit gelijkvormige lopende tekst, wisselende onderwerpen of opgemaakte tabellen en koppen.
Waarom bepaalt RAG-chunking de kwaliteit van het ophalen?
Retrieval-Augmented Generation (RAG) splitst brondocumenten in kleinere passages voordat die worden omgezet in embeddings en opgeslagen in een zoekindex. Bij een zoekopdracht haalt het systeem de meest relevante chunks op en geeft die samen met de vraag van de gebruiker aan een taalmodel. Chunking bepaalt de eenheid die wordt opgehaald, omdat een volledig document doorgaans te breed is om goed bij een specifieke vraag te passen en te groot om samen met andere kandidaten in het contextvenster van het model te passen.
Toen Patrick Lewis en collega’s het raamwerk introduceerden in hun NeurIPS-paper uit 2020 (Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks), splitste hun experiment elk Wikipedia-artikel in niet-overlappende chunks van ongeveer 100 woorden, wat ongeveer 21 miljoen passages opleverde. Die opdeling in stukken van 100 woorden was een experimentele instelling voor Wikipedia uit 2020, geen productiestandaard voor 2026. Moderne RAG in productie werkt per november 2026 meestal als een modulaire technische pijplijn (opdelen, embeddings maken, indexeren, ophalen en genereren), in plaats van de oorspronkelijke end-to-end differentieerbare opzet met DPR en BART.
Wat zijn de drie belangrijkste methoden voor RAG-chunking?
Methoden voor RAG-chunking vallen uiteen in drie groepen: splitsen op basis van tokens, betekenis en structuur. Elke groep bepaalt aan de hand van lengte, betekenis of documentopmaak waar een passage begint en eindigt.
| Chunkingmethode | Splitsingssignaal | Meest geschikt voor | Belangrijkste risico | Indexeringskosten |
|---|---|---|---|---|
| Tokenchunking (of chunking op lengte) | Vast venster van tokens of tekens met verschuivende overlap | Gelijkvormige lopende tekst, platte tekst of een lengtelimiet na splitsing op structuur | Breekt zinnen, tabelrijen, codeblokken of definities doormidden | Laag |
| Semantische chunking | Daling van de overeenkomst tussen embeddings van aangrenzende zinnen | Onopgemaakte tekst waarin onderwerpen midden in het document zonder koppen wisselen | Tragere, duurdere indexering; ongelijke chunkgroottes | Hoog |
| Chunking op basis van structuur | Koppen, alinea’s, lijsten, tabellen, codeblokken of pagina’s | Markdown, HTML, API-documentatie, juridische clausules en gestructureerde handleidingen | Zwakke structuur in gescande PDF’s; afzonderlijke secties kunnen nog steeds enorm zijn | Laag tot gemiddeld |
1. Chunking op basis van tokens en tekens
Tokenchunking verdeelt tekst in vensters met een vaste lengte, gemeten in tokens of tekens, vaak met verschuivende overlap. Meten in tokens sluit aan bij de werking van modellen: embeddingmodellen en LLM’s hebben strikte tokenlimieten, API’s worden per token afgerekend en dezelfde alinea kan per modelfamilie anders worden getokeniseerd. Het aantal tekens is slechts een ruwe benadering.
Teams beginnen meestal met een venstergrootte die binnen de limiet van hun embeddingmodel past (tutorials beginnen vaak bij enkele honderden tokens) en passen die aan na onderzoek van mislukte zoekopdrachten. Het grootste risico van een vast venster is dat het syntaxis en opmaak negeert, een zin, tabelrij, codeblok of definitie doorsnijdt en de zinsnede met het antwoord op de vraag weglaat.
2. Semantische chunking
Semantische chunking splitst tekst wanneer de betekenis verandert, bijvoorbeeld wanneer de overeenkomst tussen embeddings van aangrenzende zinnen afneemt of een grens in het betoog verschijnt, in plaats van bij een vast aantal tokens. Een volledig idee in één chunk houden helpt bij het ophalen wanneer onderwerpen midden in een document zonder koppen veranderen.
Semantische chunking is echter trager en duurder om te indexeren, omdat de splitsing zelf aanroepen voor embeddings kan vereisen. Een ruisgevoelige overeenkomstsdrempel kan tekst ook te veel of te weinig opsplitsen in ongelijke groottes; overeenkomst tussen zinnen is niet automatisch beter voor tabellen, formulieren of code.
3. Chunking op basis van structuur
Chunking op basis van structuur gebruikt de bestaande documentstructuur voor de eerste splitsing: koppen in Markdown of HTML, alinea’s, lijsten, secties, pagina’s, afgebakende codeblokken of tabelgrenzen. Zoals vermeld in AWS Prescriptive Guidance over RAG, blijft logisch samenhangende context intact door de documentstructuur te behouden. Een chunk die bij een kop over het restitutiebeleid begint en de hele sectie bevat, is gemakkelijker op te halen en te citeren dan een venster dat midden in een zin begint.
Omdat veel PDF’s en scans geen duidelijke koppen hebben (en één kop toch 20 pagina’s kan beslaan), combineren productiepijplijnen meestal methoden:
- Splits eerst hiërarchisch op structuur: Verdeel het document op sectie of kop en vervolgens op alinea of blok; houd codeblokken, tabellen en lijsten intact.
- Pas daarna een limiet in tokens toe: Als een sectie te groot blijft, splits die dan met een tokenvenster.
- Gebruik alternatieve splitsingen voor ongestructureerde tekst: Val bij gescande PDF’s of lange ongestructureerde secties terug op pagina’s, tokenvensters of semantische grenzen.
Hoe stelt u chunkoverlap en RAG-metadata in?
Chunkoverlap en passagemetadata voorkomen dat zinsdelen op grenzen verloren gaan en verbinden opgehaalde fragmenten met hun brondocumenten.
Chunkoverlap instellen
Chunkoverlap herhaalt het einde van een chunk aan het begin van de volgende, zodat een zin of definitie op een grens in ten minste één opgehaalde passage volledig voorkomt. Dit is een eenvoudige voorzorg wanneer vaste vensters of alternatieve splitsingen midden in een gedachte snijden.
Maak de overlap groot genoeg voor een of twee typische zinnen in uw corpus, maar klein genoeg om niet bijna dezelfde chunk twee keer op te slaan. Overlap verhoogt het aantal tokens dat u omzet in embeddings, opslaat en ophaalt, vergroot de index en voegt bijna dubbele resultaten toe. Als zoekopdrachten vaak bijna identieke chunks opleveren, verklein dan de overlap of chunkgrootte, of voeg na het ophalen een deduplicatiestap toe.
RAG-metadata toevoegen
RAG-metadata bestaat uit gestructureerde velden die naast elke chunk worden opgeslagen, waaronder:
- ID of URL van het brondocument en titel
- Sectie- of koppad en paginanummer
- Aanmaak- of wijzigingsdatum en documenttype (beleid, ticket, API-referentie)
- Labels voor toegang en rechten, taal en een stabiele chunk-ID
Teams kunnen metadata buiten de embedding houden wanneer ruwe ID’s of tijdstempels de overeenkomst zouden verstoren, of geselecteerde velden (zoals een sectietitel) vooraan de tekst voor de embedding plaatsen wanneer ze het ophalen verbeteren. Metadata ondersteunt drie behoeften in productie:
- Bronvermeldingen: Uw gebruikersinterface of model kan een bestand, kop en paginanummer citeren in plaats van alleen een passage.
- Filters voor rechten en versies: Haal alleen de nieuwste versie van een beleid, een specifiek product of documenten op die de gebruiker mag zien. Rechten horen in indexfilters en niet alleen in de prompt, omdat privédocumenten in een ongefilterde RAG-index toegankelijk zijn voor iedereen die het systeem kan bevragen.
- Foutopsporing en updates: Als een brondocument verandert, deel het dan opnieuw op, maak opnieuw embeddings en verwijder oude chunk-ID’s zodat verouderde feiten geen feitelijke fouten veroorzaken.
Hoe weet u of uw chunks te groot of te klein zijn?
Door opgehaalde chunks bij echte gebruikersvragen te bekijken, ziet u of uw passages te groot of gefragmenteerd zijn.
Signalen dat uw chunks te groot zijn
- Verborgen antwoorden: De zoekopdracht levert een lange sectie op die de zoekterm noemt maar het werkelijke antwoord verbergt, zodat het model moet zoeken of het mist.
- Overvolle prompts: Er passen maar enkele chunks in de prompt, waardoor een matige overeenkomst betere verdringt.
- Hogere kosten en latentie: Veel irrelevante tokens versturen verhoogt de uitgaven en responstijd.
- Meer afleiding: Extra ruis verergert context rot: het model heeft het juiste feit in een grote prompt, maar vertrouwt op trainingsgeheugen of een aangrenzende onjuiste zin.
Signalen dat uw chunks te klein zijn
- Losse fragmenten: Een opgehaalde chunk is zonder de vorige zin niet te begrijpen (zoals een zin over een uitzondering voor zakelijke abonnementen zonder de regel te noemen).
- Opgesplitste antwoorden met meerdere onderdelen: Een definitie en de uitzondering, een functie en haar parameters, of een beleid en de ingangsdatum komen in afzonderlijke chunks terecht en top-k geeft maar één deel terug.
- Bijna identieke fragmenten: U haalt veel herhaalde fragmenten op maar mist nog steeds een volledige gedachte, terwijl bronvermeldingen onoverzichtelijk worden omdat elke zin een eigen bron is.
Bekijk voor praktische afstemming echte vragen en de opgehaalde chunks, en vraag u af of iemand met alleen die passages kan antwoorden. Staat de benodigde zin in een niet-opgehaalde aangrenzende chunk, pas dan de overlap, structuurregels of grootte aan. Staat de benodigde zin in de opgehaalde chunk tussen niet-gerelateerde tekst, splits dan kleiner of haal minder, gerichtere chunks op.
Welke invloed heeft RAG-chunking op context rot?
RAG-chunking is een directe manier om context rot tegen te gaan: de afname van redeneerkwaliteit, het opvolgen van instructies en het terughalen van informatie door een model naarmate een prompt langer of rommeliger wordt, zelfs ruim onder de opgegeven contextlimiet.
RAG bestaat zodat u niet het hele corpus in de prompt hoeft te stoppen. Maar door te grote chunks op te halen, of top-k voor de zekerheid te verhogen en veel vaag vergelijkbare chunks in de prompt te stoppen, ontstaat opnieuw een lange, ruisrijke context. Meer context is niet automatisch nauwkeuriger. Gerichte chunks verminderen de hoeveelheid ruis in de prompt, maar goede chunking alleen kan een slecht embeddingmodel niet repareren of AI-hallucinaties wegnemen wanneer een model opgehaalde tekst negeert.
FAQ
Moet ik de grootte van RAG-chunks meten in tokens of tekens?
Meet de grootte van RAG-chunks waar mogelijk in tokens. Embeddingmodellen en taalmodellen hanteren contextlimieten in tokens en API-gebruik wordt per token afgerekend. Het aantal tekens is slechts een ruwe benadering, omdat dezelfde alinea afhankelijk van taal, codeblokken en modelfamilie in verschillende aantallen tokens kan worden opgesplitst. De tokenizer van uw embeddingmodel voorkomt onverwachte afkapping tijdens indexering.
Is semantische chunking altijd beter dan tokenchunking?
Semantische chunking is niet automatisch beter dan tokenchunking of chunking op basis van structuur. Splitsen wanneer de overeenkomst tussen zinnen afneemt helpt ideeën in ongestructureerde tekst bijeen te houden, maar vereist extra werk voor embeddings tijdens indexering, levert ongelijke chunkgroottes op en kan bij een ruisgevoelige drempel te veel of te weinig splitsen. Bij opgemaakte documenten is splitsen langs koppen, tabellen en codeblokken sneller en volgt het de door de auteur bedoelde grenzen.
Hoe moet ik tabellen en codeblokken opdelen voor RAG?
Tabellen, facturen, juridische clausules en code vereisen structuurregels die blokken intact houden. Een eenvoudige splitsing op tekens of tokens dwars door een Markdown-tabel of functiebeschrijving levert onbruikbare chunks op die waarden van kolomkoppen scheiden of de syntaxis breken. Houd codeblokken, tabellen en lijsten waar mogelijk heel en pas alleen alternatieven op basis van structuur toe als één blok de modellimieten overschrijdt.
Moeten metadata in de embedding van een chunk worden opgenomen?
Metadata opnemen in de tekst voor de embedding is een ontwerpkeuze die van het veld afhangt. Een documenttitel of pad van sectiekoppen vooraan de chunktekst plaatsen helpt vaak bij het ophalen wanneer alinea’s voor context afhankelijk zijn van de kop. Ruwe identificaties, tijdstempels en toegangslabels moeten in afzonderlijke filterbare metadatavelden blijven, zodat ze de overeenkomst tussen embeddings niet verstoren.
Wat gebeurt er als een brondocument verandert?
Als een brondocument verandert, moet uw opnamepijplijn dat document opnieuw opdelen en embeddings maken en de oude chunk-ID’s uit de index verwijderen. Als verouderde chunks naast bijgewerkte chunks actief blijven, haalt het zoeksysteem achterhaald beleid of tegenstrijdige passages op. Zo wordt een verzuim in indexonderhoud een feitelijke fout in het uiteindelijke antwoord.
