Chunking

Wat is chunking?

Chunking is het opknippen van een document in kleinere stukken voor je die laat embedden en indexeren voor een RAG-systeem. In plaats van een volledig rapport van vijftig pagina's als één geheel te bewaren, splits je het in overzichtelijke fragmenten van een paar honderd woorden. Elk fragment, of chunk, wordt apart omgezet in een vector en apart teruggevonden bij een zoekopdracht.

Je kan het vergelijken met steekkaarten. Zet je de inhoud van een dik handboek op losse kaartjes met telkens één afgerond idee, dan vind je snel terug wat je nodig hebt. Een taalmodel krijgt zo enkel de kaartjes die er echt toe doen.

Het is een vaste stap in elke Retrieval-Augmented Generation-pipeline. Het gebeurt vooraf, bij het klaarzetten van je kennisbank.

Waarom moet je documenten chunken?

Twee harde redenen maken chunking noodzakelijk.

Embedding-modellen hebben een limiet. Een embedding-model kan maar een beperkte hoeveelheid tekst in één keer verwerken. Het model text-embedding-3-small van Azure OpenAI stopt bijvoorbeeld rond 8.000 tokens, goed voor ongeveer 6.000 woorden. Een lang document past daar niet in. En zelfs als het net past, krijg je één vector voor tientallen pagina's. Die vector is zo'n gemiddelde van alles dat hij nergens echt scherp op matcht.

Het context window van het taalmodel is beperkt. Bij een vraag stuur je de gevonden fragmenten mee naar het taalmodel. Dat model heeft een begrensd context window, dus je wil enkel de meest relevante stukken meegeven, niet je hele archief.

Retrieval werkt daarom het best op gerichte stukken. Een chunk over één onderwerp geeft een scherpe vector, en een vector database vindt die veel betrouwbaarder terug dan een fragment dat vijf onderwerpen door elkaar behandelt.

De belangrijkste manieren om te chunken

Er is geen enkele juiste methode. Deze vier komen het vaakst terug en je combineert ze vaak.

• Vaste grootte. Je knipt de tekst in stukken van een vast aantal tokens of tekens, bijvoorbeeld elke 500 tokens. Simpel en voorspelbaar, maar de knip valt soms midden in een zin of een tabel.

• Op natuurlijke grenzen. Je splitst op een paragraaf, een titel, een Markdown-hoofding of een sectie in een PDF. Zo blijft een afgerond stuk tekst samen en respecteer je de structuur van het document.

• Met overlap. Je laat elk stuk een beetje overlappen met het vorige, bijvoorbeeld de laatste paar zinnen. Zo gaat een zin op de grens tussen twee chunks niet verloren. Microsoft raadt aan te starten met chunks van rond 500 tokens en een overlap van ongeveer een kwart daarvan.

• Semantisch chunken. Hier bepaalt de betekenis de knip: het systeem zet zin per zin om in een vector en knipt net waar het onderwerp verschuift. Dat levert de meest samenhangende chunks op, maar vraagt meer rekenwerk vooraf.

Een voorbeeld: een personeelsbeleid chunken

Stel dat je een RAG-chatbot bouwt op het personeelsbeleid van je bedrijf, een document van dertig pagina's met secties over verlof, ziekte, thuiswerk en onkosten.

Knip je dat in blokken van een vaste grootte, dan riskeer je dat de regel "Bij meer dan drie dagen afwezigheid is een doktersattest verplicht" halverwege wordt doorgesneden. Vraagt een medewerker dan naar dat doktersattest, dan matcht geen van beide helften goed en krijgt hij een half antwoord.

Knip je in plaats daarvan op de kopjes van elke sectie, dan blijft het stuk over ziekteverlof samen in één chunk. Voeg je daar wat overlap aan toe, dan overleeft ook die ene zin op de grens. De chatbot vindt de juiste sectie terug en antwoordt met de volledige regel plus de bron.

De juiste chunkgrootte kiezen

De kern van chunking is een afweging tussen te groot en te klein.

Te grote chunks stoppen te veel onderwerpen in één vector. De match met een specifieke vraag wordt vager, en je vult het context window met tekst die er niet toe doet. Dat kost tijd en geld zonder dat het antwoord er beter op wordt.

Te kleine chunks verliezen dan weer hun context. Een losse zin zonder de paragraaf errond matcht misschien op woordniveau, maar het model mist de omkadering om er een juist antwoord uit te bouwen.

Als vuistregel zie je in de praktijk vaak chunks tussen 256 en 1.000 tokens. Kleinere stukken van rond 128 tot 256 tokens geven scherpe matches, grotere stukken van 512 tot 1.000 tokens bewaren meer context. Dit zijn startpunten, geen vaste regels. De ideale grootte hangt af van je content: korte productfiches vragen andere chunks dan lange juridische contracten. Test met een set echte vragen en meet wat de beste antwoorden geeft.

Waar moet je op letten bij het gebruik van chunking

Geef elke chunk wat context mee. Een fragment uit het midden van een document weet niet meer uit welk hoofdstuk het komt. Voeg de titel van het document of de sectie aan elke chunk toe, zodat een los stuk zijn plaats in het geheel niet kwijtraakt.

Kies je chunkstrategie voor je de embeddings berekent. Verander je later van chunkgrootte of methode, dan moet je alle vectoren opnieuw aanmaken. Dat is vervelend op een grote index, dus test je aanpak op een staal voor je alles in productie zet.