Chunking: hoe knip je een document op zonder de betekenis te slopen?

Goede chunking betekent dat je een document opdeelt in stukken die klein genoeg zijn om gericht terug te vinden, maar groot genoeg om zelfstandig betekenis te houden. Je wilt dus niet simpelweg elke 500 woorden een knip zetten. De grens hoort waar mogelijk samen te vallen met de structuur van de inhoud: een alinea, sectie, tabel, functie of logisch onderwerp.

Bij RAG is chunking belangrijk omdat retrieval niet zoekt in het oorspronkelijke document, maar meestal in de afzonderlijke chunks die daarvan zijn gemaakt. Als een antwoord over twee slecht gekozen chunks is verspreid, kan zelfs een goed embeddingmodel het verkeerde fragment ophalen. Te grote chunks leveren juist veel irrelevante context op. De juiste chunkingstrategie hangt daarom af van documentstructuur, zoekvragen en het soort informatie dat je wilt terugvinden.

Wat is chunking?

Chunking is het opdelen van bronmateriaal in kleinere eenheden voordat je het indexeert in een RAG-systeem.

Stel dat je een handleiding van zestig pagina's hebt. Je zou de hele handleiding als één embedding kunnen opslaan, maar dan vertegenwoordigt één vector tientallen onderwerpen tegelijk. Een zoekvraag over het resetten van een wachtwoord moet dan concurreren met informatie over installatie, facturatie, gebruikersrechten en foutmeldingen.

Daarom maak je kleinere stukken, bijvoorbeeld:

• één paragraaf per chunk;
• een paar samenhangende alinea's;
• een sectie onder één tussenkop;
• één tabel met de bijbehorende toelichting;
• één functie of klasse uit een codebestand.

Iedere chunk krijgt vervolgens meestal een eigen embedding en metadata zoals documentnaam, paginanummer, hoofdstuk of URL. Het doel is niet om chunks zo klein mogelijk te maken. Het doel is om een zinvolle retrieval-eenheid te maken.

Waarom chunking vaak misgaat

De meest voorkomende fout is chunken zonder rekening te houden met betekenis. Neem bijvoorbeeld deze tekst:

"Voor accounts met tweefactorauthenticatie geldt een andere resetprocedure. Neem bij verlies van het authenticatieapparaat contact op met de beheerder."

Als precies tussen die twee zinnen een chunkgrens valt, kan een zoekopdracht naar "telefoon met authenticator kwijt" alleen de tweede zin terugvinden. Zonder de eerste zin ontbreekt de context dat dit specifiek over tweefactorauthenticatie gaat.

Het tegenovergestelde probleem ontstaat bij te grote chunks. Stel dat een chunk een volledig hoofdstuk bevat met installatie-instructies, rechtenbeheer, logging en back-ups. De relevante passage staat er wel in, maar de embedding vertegenwoordigt meerdere onderwerpen. Bovendien stuur je na retrieval veel tekst naar het taalmodel die niets met de vraag te maken heeft.

Slechte chunking veroorzaakt daarom twee verschillende problemen:

• relevante informatie wordt uit elkaar getrokken;
• relevante informatie raakt begraven in te veel irrelevante tekst.

Beide verlagen de kwaliteit van retrieval.

Chunkgrootte en overlap

Er bestaat geen universele ideale chunkgrootte. Een goede waarde hangt af van de documenten en de vragen die gebruikers stellen. Kleine chunks zijn nuttig als gebruikers naar heel specifieke feiten zoeken: hoge precisie, maar sneller te weinig context. Grotere chunks houden meer verbanden intact, maar bevatten ook sneller meerdere onderwerpen.

Daarom wordt vaak overlap gebruikt: een deel van het einde van chunk A wordt herhaald aan het begin van chunk B. Een chunk die eindigt met "Het systeem bewaart auditlogs gedurende de ingestelde bewaartermijn. Beheerders kunnen deze termijn per omgeving aanpassen." kan die laatste zin laten terugkomen als opening van de volgende chunk, vóór nieuwe informatie over bijvoorbeeld compliance-eisen. De overlap verkleint de kans dat een betekenisvolle overgang precies op een grens verloren gaat.

Maar overlap is geen oplossing voor slechte segmentatie. Als je willekeurig door koppen, tabellen en paragrafen heen knipt, zorgt meer overlap vooral voor duplicatie in je vectorstore. Een betere volgorde is: eerst natuurlijke documentgrenzen gebruiken, daarna alleen waar nodig overlap toevoegen.

Vast chunken versus semantisch chunken

Bij fixed-size chunking verdeel je tekst op basis van een vaste lengte, bijvoorbeeld een maximumaantal tokens of tekens. Dat is eenvoudig en voorspelbaar — voor uniforme tekst zoals lange rapporten kan het een bruikbare baseline zijn. Het nadeel is dat de inhoud geen invloed heeft op de grens: een chunk kan midden in een redenering eindigen.

Bij semantisch of structureel chunken kies je grenzen op basis van de inhoud: hoofdstukken, tussenkoppen, paragrafen, opsommingen, veranderingen van onderwerp, of documentstructuur uit HTML of Markdown. Een sectie als ## Wachtwoord herstellen gevolgd door de uitleg eronder wil je meestal als eenheid behandelen in plaats van de kop los te trekken van de tekst die erbij hoort.

Semantische chunking is echter niet automatisch beter. Als secties extreem lang zijn, moet je ze alsnog verder opdelen. In de praktijk werkt daarom vaak een hybride aanpak: eerst splitsen op natuurlijke structuur, vervolgens te grote blokken verder verdelen.

Chunking per documenttype

PDF's. Bij pdf's begint chunking eigenlijk al vóór het chunken: bij extractie. Een pdf is primair een visueel formaat — tekst kan in de verkeerde volgorde worden geëxtraheerd, kop- en voetteksten kunnen telkens terugkomen en kolommen kunnen door elkaar raken. Een verstandige volgorde is daarom:

pdf → tekst en structuur reconstrueren → koppen, paragrafen en tabellen herkennen → chunks maken → embeddings genereren

Als de extractie fout is, kan geen chunkingstrategie dat achteraf volledig repareren. Bewaar bovendien metadata zoals documentnaam, pagina en sectietitel — dat maakt bronvermelding en debugging veel eenvoudiger.

Tabellen. Tabellen moet je niet behandelen als gewone doorlopende tekst. Een tabel verliest betekenis als de kolomkoppen in een andere chunk terechtkomen dan de waarden:

Product	Bewaartermijn	Regio
A	30 dagen	EU
B	90 dagen	EU

Een tabelchunk moet daarom meestal de kolomnamen én de relevante rijen bevatten. Bij grote tabellen kun je rijen opdelen, maar herhaal dan de headers of voeg ze structureel toe. Ook context rond de tabel telt mee: een tabel met de titel "Bewaartermijnen voor afgesloten accounts" betekent iets anders dan dezelfde waarden zonder titel.

Code. Code vereist weer een andere grens. Een Python-functie halverwege doorknippen omdat een maximumaantal tokens is bereikt, maakt de chunk vaak nauwelijks bruikbaar. Natuurlijke eenheden voor code zijn bijvoorbeeld een functie, methode, klasse, module of configuratieblok — bewaar indien mogelijk ook de context erboven: bestandsnaam, klasse, imports of functie-signature. Voor codebases kan taalbewuste parsing daarom veel betere chunks opleveren dan een generieke tekstsplitter.

Hoe test je of je chunking goed is?

Chunking moet je niet beoordelen door alleen naar gemiddelde chunklengte te kijken. Test of gebruikersvragen de juiste informatie terughalen. Maak daarvoor een kleine set representatieve vragen waarvan je weet waar het antwoord in de bron staat — bijvoorbeeld "hoe reset een gebruiker zijn account als hij geen toegang meer heeft tot zijn authenticator?" met als verwachte bron Handleiding > Accountbeheer > Tweefactorauthenticatie. Voer vervolgens retrieval uit zonder eerst naar het uiteindelijke antwoord van het taalmodel te kijken.

Controleer:

• staat de juiste chunk in de eerste zoekresultaten?
• bevat de chunk voldoende context om de vraag te beantwoorden?
• staat er veel irrelevante tekst omheen?
• is cruciale informatie over meerdere chunks verdeeld?
• worden bijna identieke chunks door overlap meerdere keren teruggegeven?

Vergelijk daarna verschillende strategieën: kleinere chunks, grotere chunks, minder overlap, structurele splitsing of andere metadata. Dat is belangrijk omdat chunking en retrieval samen één systeem vormen — een theoretisch nette chunker die op jouw echte vragen slechte resultaten geeft, is geen goede chunker.

Chunking is onderdeel van retrieval, niet alleen preprocessing

Chunking lijkt een simpele voorbereidende stap, maar bepaalt uiteindelijk wat je retriever überhaupt kan vinden. Een embeddingmodel kan geen relatie herstellen die tijdens het chunken volledig uit elkaar is getrokken. Begin daarom met de natuurlijke structuur van het document, houd betekenisvolle informatie bij elkaar en gebruik vaste limieten vooral als bovengrens. Test vervolgens met echte zoekvragen in plaats van één chunkgrootte als universele standaard te behandelen.

Voor het bredere proces van bron ophalen en antwoorden genereren kun je verder lezen bij RAG uitgelegd. Als je chunks wel worden gevonden maar de beste passages niet bovenaan komen, is Wat is reranking en wanneer heb je het nodig? de logische vervolgstap.