Je weet meer dan je onthoudt

Elk bedrijf heeft een berg eigen kennis liggen die niemand meer paraat heeft: klantprofielen, factuurgeschiedenis, handleidingen, interne procedures, oude offertes. RAG staat voor Retrieval Augmented Generation en laat een AI antwoorden op basis van precies díe eigen kennis. In plaats van dat jij of een collega alles zelf moet opzoeken, stel je de vraag aan het systeem. Zo houd je grip op een groeiend bedrijf zonder dat alle kennis in iemands hoofd hoeft te zitten — en zonder dat je afhankelijk bent van de ene collega die "het altijd weet".

Hoe RAG werkt: retrieval, dan generation

Het principe werkt in twee stappen. Eerst worden relevante documenten opgehaald via embeddings (de retrieval-stap), daarna worden ze aan het taalmodel gegeven dat een antwoord formuleert (de generation-stap). Een embedding-model zet tekst om in vectoren, zodat teksten met een vergelijkbare betekenis dicht bij elkaar liggen in die vectorruimte. Deze vectoren worden opgeslagen in een vectordatabase zoals ChromaDB of FAISS, die geoptimaliseerd is voor snel semantisch zoeken — zoeken op betekenis in plaats van op exacte trefwoorden.

Het verschil met een gewone zoekfunctie (ctrl+F of een trefwoordzoekopdracht) is dat RAG ook vindt wat er bedoeld wordt, zelfs als de exacte woorden niet overeenkomen. Een vraag als "wat is ons beleid bij een kapotte levering" vindt dan ook een document getiteld "retourprocedure beschadigde artikelen", ook al staat het woord "kapot" er nergens letterlijk in.

MKB-case: je eigen documentatie doorzoekbaar maken

Een veelvoorkomende toepassing: een installatiebedrijf heeft tientallen handleidingen, garantievoorwaarden en interne werkinstructies verspreid over mappen, e-mails en een gedeelde schijf. Nieuwe medewerkers (of de eigenaar zelf, onder tijdsdruk) zoeken vaak lang naar het juiste antwoord. Met een eigen RAG-systeem:

1. Verzamel alle relevante documenten (PDF's, Word-bestanden, geëxporteerde e-mails) in één map.
2. Splits elk document op in kleinere stukken (chunking, zie hieronder) en zet ze om in embeddings.
3. Sla de embeddings op in een vectordatabase.
4. Bouw een simpel zoekscherm (of koppel het aan een chatbot) waarin een medewerker een vraag typt in gewone taal.
5. Het systeem haalt de meest relevante fragmenten op en het taalmodel formuleert daarmee een antwoord, met verwijzing naar het brondocument.

Zo'n systeem is voor de meeste MKB-bedrijven met beperkte technische middelen te bouwen met bestaande open-source bouwstenen (een embedding-model via Ollama, een lokale vectordatabase, en een eenvoudige interface), zonder dat er gevoelige bedrijfsdocumentatie naar een externe partij hoeft.

Waar de kwaliteit op staat of valt: chunking

De kwaliteit van een RAG-systeem hangt sterk af van de chunking-strategie: hoe je documenten in stukken verdeelt voordat je ze embedt. Te grote stukken (chunks) leveren ruis op — het model krijgt te veel irrelevante tekst mee naast het antwoord. Te kleine stukken verliezen context — een losse zin zonder de omliggende alinea kan verkeerd worden geïnterpreteerd. Een veelgebruikte vuistregel is een chunkgrootte van 300 tot 500 woorden met een kleine overlap tussen opeenvolgende chunks, zodat de context aan de randen niet verloren gaat. De juiste grootte hangt af van je documenttype: korte procedurele instructies vragen om kleinere chunks dan uitgebreide contracten.

Daarnaast verhoogt re-ranking de precisie: na de eerste ophaalronde worden de gevonden resultaten opnieuw gerangschikt op relevantie, zodat de beste fragmenten bovenaan komen te staan voordat het taalmodel ze gebruikt. Dit is vooral nuttig als je vectordatabase in eerste instantie tien tot twintig kandidaat-fragmenten teruggeeft — re-ranking filtert daaruit de drie tot vijf die er echt toe doen.

• RAG = relevante documenten ophalen via embeddings en aan het taalmodel geven.
• Chunking bepaalt de kwaliteit: niet te groot (ruis), niet te klein (contextverlies).
• Vectordatabases (ChromaDB, FAISS) slaan embeddings op voor snel semantisch zoeken.
• Re-ranking herschikt opgehaalde resultaten op relevantie.

Een woord over onderhoud

Een RAG-systeem is geen eenmalig project. Nieuwe documenten, gewijzigde procedures en verouderde handleidingen moeten periodiek opnieuw worden ingelezen en ge-embed, anders geeft je systeem na verloop van tijd verouderde antwoorden — en een verkeerd antwoord uit een verouderd document is soms erger dan geen antwoord. Plan daarom een vast moment (bijvoorbeeld maandelijks) om de documentenset te controleren op verouderde of ontbrekende informatie, net zoals je een website of boekhouding periodiek bijwerkt.

Samenvatting

RAG maakt je eigen bedrijfskennis doorzoekbaar op betekenis in plaats van op exacte woorden, door documenten op te delen, om te zetten in embeddings en op te slaan in een vectordatabase. De kwaliteit staat of valt met een doordachte chunking-strategie en, waar nodig, re-ranking van de gevonden resultaten. Voor MKB-bedrijven is dit een van de meest directe manieren om "wat weten we eigenlijk al" om te zetten in een systeem dat iedereen zelf kan raadplegen.

Verder lezen: de documentatie van ChromaDB (trychroma.com) en FAISS (Facebook AI Similarity Search) voor concrete implementatievoorbeelden, en de eerdere les over Ollama voor het lokaal draaien van een embedding-model.