RAG: je eigen kennisbank koppelen aan AI

Je hebt een map met documentatie die je zelf hebt geschreven, een wiki die je drie jaar hebt bijgehouden, of een stapel PDF's die je nooit meer terugvindt. Je stelt een vraag aan een lokaal taalmodel en krijgt een antwoord dat zelfverzekerd klinkt en nergens op slaat. Dat is het probleem dat Retrieval-Augmented Generation oplost.

RAG is geen model en geen product. Het is een architectuur: je zoekt eerst in je eigen bronnen, stopt de gevonden tekst in de prompt, en laat het model pas daarna antwoorden. Het model hoeft dus niets te "weten" over jouw projectplanning of je Flatpak-configuratie. Het hoeft alleen te kunnen lezen wat je het voorhoudt.

De vraag is niet of je RAG wilt. De vraag is hoe je het inricht, en die vraag heeft meer dan één goed antwoord.

Waarom je model niets van jou weet

Een groot taalmodel is getraind op een afgesloten corpus. Dat corpus heeft een einddatum, meestal ergens in het verleden, en bevat niets van wat jij op je eigen schijf hebt staan. Je interne notities, je meetingverslagen, je PostgreSQL-backup-procedure van vorig jaar — het model heeft ze nooit gezien.

Je kunt dat oplossen door het model opnieuw te trainen op jouw data. Dat is duur, traag, en je moet het overdoen zodra je documenten veranderen. Fine-tuning leert een model een toon of een stijl, niet een feit dat volgende week verandert.

RAG doet iets anders. Het laat het model met rust en verplaatst het probleem naar het zoeken. Bij elke vraag haalt het systeem relevante fragmenten op uit jouw verzameling, plakt die aan de prompt, en genereert een antwoord dat op die fragmenten is gebaseerd. Verander je een document, dan verandert het antwoord mee. Geen hertraining nodig.

De prijs: je moet je documenten doorzoekbaar maken, en dat zoeken moet goed genoeg zijn om de juiste passage te vinden. Daar zit het echte werk.

De drie delen, en waar het misgaat

Elke RAG-pijplijn heeft drie stappen. Retrieval: zoek de relevante stukken tekst. Augmentatie: stop die stukken in de prompt. Generatie: laat het model antwoorden.

De generatie is het makkelijke deel. Moderne modellen van 7B parameters en up kunnen een redelijk antwoord formuleren op basis van meegegeven context. Daar hoef je weinig aan te doen.

De augmentatie is een kwestie van format. Je plakt de gevonden fragmenten boven of onder de vraag, met een duidelijke scheiding, en hoopt dat het model ze gebruikt in plaats van zijn eigen paraat kennis. Werkt meestal.

De retrieval is waar het fout gaat. Zoeken op exacte woorden werkt niet als je vraag anders geformuleerd is dan je document. Je vraagt "hoe krijg ik Flatpak aan het hostnetwerk" en je document zegt "network namespace access voor sandboxed apps". Nul treffers.

Daarom gebruiken de meeste RAG-systemen embeddings: een model dat tekst omzet in een vector, zodat zoeken op betekenis kan in plaats van op woorden. Een vector-database zoals Chroma of Weaviate slaat die vectoren op en zoekt de dichtstbijzijnde buren.

Dat werkt verrassend goed. En het voegt een laag toe die je moet begrijpen als je wilt weten waarom je antwoorden soms net naast zitten.

Wat het kost, in drie smaken

Je kunt RAG op drie niveaus inrichten, en elk niveau ruilt gemak in voor controle.

De eerste smaak: een applicatie die het al ingebouwd heeft. LM Studio doet dit met "Documenten Chat" — je sleept bestanden erin, het programma indexeert ze, en je stelt vragen. Geen vector-database om te beheren, geen embedding-model om te kiezen. De prijs is dat je vastzit aan wat die applicatie ondersteunt. Wil je een andere chunkgrootte, een andere zoekstrategie, of meerdere bronnen combineren, dan loop je tegen de muur.

De tweede smaak: een framework zoals LangChain of LlamaIndex. Hiermee bouw je de pijplijn zelf. Je kiest je embedding-model, je kiest je vector-store, je bepaalt hoe je documenten in stukken hakt en hoe je de resultaten rangschikt. Dit is waar de meeste productie-RAG-systemen leven. De prijs is dat je een programmeertaal moet kunnen lezen, meestal Python, en dat je moet snappen wat een chunk is voordat je er een kunt debuggen.

De derde smaak: alles zelf. Je draait je eigen embedding-model via Ollama of sentence-transformers, je zet je eigen Chroma of Qdrant op, en je schrijft de retrieval-logica met de hand. Volledige controle, volledige verantwoordelijkheid. Dit is de route als je eisen hebt die geen framework je geeft, of als je simpelweg wilt weten hoe het werkt voordat je een abstractie vertrouwt.

De vuistregel: begin bij de eerste smaak. Als je er niet uitkomt, is dat een teken dat je eisen hebt die de tweede of derde rechtvaardigen. Niet andersom.

Chunken is het halve werk

Een document van twintig pagina's past niet in één keer in een prompt. Je moet het opknippen in stukken — chunks — die elk apart doorzocht kunnen worden.

Hoe je knipt, bepaalt wat je terugvindt. Knip je te grof, dan bevat een chunk drie onderwerpen en vindt het model ruis. Knip je te fijn, dan verlies je context en vindt het model losse zinnen zonder verband.

De standaardaanpak: chunks van 500 tot 1000 tokens, met een overlap van 50 tot 100 tokens zodat een zin die over de grens valt in beide stukken terugkomt. Dat werkt voor de meeste documentatie.

Maar het is geen wet. Een technische handleiding met duidelijke secties kun je beter per sectie knippen dan per tokenaantal. Een transcript van een vergadering kun je beter per sprekerbeurt knippen. De structuur van je document is informatie, en als je die weggooit bij het chunken, moet je retrieval het later goedmaken.

Slechte chunks zijn de meest voorkomende reden dat een RAG-systeem domme antwoorden geeft. Het model doet meestal wat het kan met wat het krijgt.

De vraag die je jezelf moet stellen

Voordat je kiest hoe je RAG inricht, is er één vraag die alles bepaalt: waar mogen je documenten staan?

Draai je alles lokaal, dan verlaat niets je machine. Dat is de reden dat tools als LM Studio populair zijn in omgevingen waar data niet naar buiten mag. Je verwerkt je vergaderingen, je wachtwoorden, je interne documentatie — niets daarvan gaat over een netwerk. De prijs is dat je zelf verantwoordelijk bent voor back-ups, voor updates, en voor het moment dat je GPU het niet meer trekt.

Gebruik je een cloud-embedding-API, dan is je indexering sneller en je retrieval vaak nauwkeuriger, want de grote embedding-modellen zijn beter dan wat je lokaal in een paar GB kwijt kunt. De prijs is dat je documenten naar een derde partij gaan. Voor sommige organisaties is dat een absolute blokkade. Voor andere is het een afweging van kosten en kwaliteit.

Er is geen verkeerd antwoord. Er is alleen een antwoord dat niet past bij wat je opslaat.

Waar het naartoe gaat, en waarom dat je niet moet haasten

Je ziet RAG nu al opduiken in editors, in bestandbeheerders, en in besturingssystemen. De kans is groot dat je over twee jaar een vraag intypt in je terminal en het antwoord krijgt uit je eigen notities, zonder dat je een vector-database hebt opgezet.

Dat is mooi, en het is ook een reden om nu niet te veel te bouwen. De abstracties die vandaag de standaard zijn, zijn dat over een jaar misschien niet meer. Wat blijft, is je data: de documenten die je hebt, de manier waarop je ze hebt gestructureerd, en de metadata die je eraan hebt gehangen. Daar zit je investering.

Begin met een map die je vertrouwt en een tool die je begrijpt. Meet of de antwoorden kloppen. Voeg pas een laag toe als je een concrete klacht hebt die de huidige laag niet oplost.

RAG is geen vervanging van je kennis. Het is een interface erop. En zoals bij elke interface geldt: als de onderliggende data rommelig is, maakt geen enkele architectuur dat goed.