RAG (Retrieval-Augmented Generation):
Je eigen data ontsluiten met AI

RAG is een techniek waarbij een taalmodel eerst relevante informatie uit jouw bronnen ophaalt, en vervolgens daarop een antwoord formuleert. Het model verzint niets uit zijn eigen hoofd. Het put uit wat het op dat moment aangereikt krijgt.

Een vergelijking: een nieuwe collega die bij elke vraag eerst het juiste dossier uit de kast haalt, het relevante stuk leest, en daarna in zijn eigen woorden antwoord geeft. Geen gegok, geen onderbuikgevoelens, wel snelheid, want hij hoeft niet het hele dossier uit zijn hoofd te leren.

Onder de motorkap gebeurt het volgende. De vraag wordt omgezet naar een wiskundige representatie (een embedding), die vergeleken wordt met een vooraf opgebouwde index van alle brondocumenten. De paar meest relevante stukjes brontekst worden vervolgens samen met de oorspronkelijke vraag aan het taalmodel gegeven. Dat formuleert een antwoord dat strikt gebaseerd is op die stukjes. Als er geen goede match is, kan het gewoon zeggen: dit weet ik niet.

Hallucinaties voorkomen

Een van de belangrijkste redenen dat RAG de standaard is geworden voor AI-toepassingen in een zakelijke context, is dat het hallucinaties voorkomt. Hallucinaties zijn AI-antwoorden die plausibel klinken maar feitelijk onjuist zijn. Omdat een RAG-systeem antwoorden baseert op concrete bronnen in plaats van op wat het model 'denkt te weten', beperkt het dit risico aanzienlijk.

Een RAG-systeem bestaat in de kern uit vier onderdelen. Elk onderdeel kent zijn eigen afwegingen, en juist die afwegingen bepalen of het systeem straks goed of middelmatig werkt.

1. Content extractie. Voordat je iets kunt doorzoeken, moet je bepalen wat er in de index komt. Welke bronnen tellen mee? Welke metadata hang je eraan? Hoe schoon is de brontekst, staan er navigatie-elementen of boilerplate tussen die het signaal verdunnen? Hier wordt al de helft van de kwaliteit bepaald. Garbage in, garbage out geldt voor AI net zo hard als voor elk ander systeem.

2. Chunking. Je embed geen hele pagina of PDF in één keer, want dan verdwijnt de specifieke inhoud in een te algemeen gemiddelde. Je knipt de tekst in overlappende stukken van meestal een paar honderd tot een paar duizend karakters, zodat elke chunk een samenhangend onderwerp bevat. Waar je precies knipt (op zinsgrens, alinea, natuurlijke sectie) is een balans tussen precisie en context.

3. Embeddings en vector database (semantisch zoeken). Elk stukje tekst wordt door een embedding-model omgezet naar een vector van een paar duizend getallen. Stukken tekst die semantisch op elkaar lijken, krijgen vectoren die dicht bij elkaar liggen. Die vectoren sla je op in een vector database zoals Qdrant, Pinecone of pgvector. Bij een vraag zet je diezelfde vraag ook om naar een vector, en zoekt de database de dichtstbijzijnde brontekst-vectoren.

4. Retrieval en prompt. De gevonden stukken gaan samen met de oorspronkelijke vraag in een zorgvuldig opgebouwde prompt naar het taalmodel. De kunst zit in de instructies: antwoord uitsluitend op basis van de aangeleverde context, geef toe wanneer je het niet weet, formuleer natuurlijk. Een relevantie-drempel zorgt er daarnaast voor dat vragen die helemaal buiten de kennisbank vallen het model niet eens bereiken. Die krijgen direct een eerlijk "dit weet ik niet"-antwoord terug.

Het klinkt overzichtelijk, en qua architectuur is het dat ook. Maar de kwaliteit van het eindresultaat hangt volledig af van hoe je elk van deze vier onderdelen invult voor jouw specifieke situatie.

Een Umbraco-omgeving heeft een paar eigenschappen die de toepassing van RAG eenvoudig maken. De techniek voor een RAG-systeem is overal hetzelfde, maar de praktische haalbaarheid staat of valt met hoe toegankelijk je broncontent is. En juist daar ligt de kracht van Umbraco.

Makkelijk toegankelijke, gestructureerde content. Content in Umbraco staat niet verstopt in losse HTML-bestanden of diep genest in een database. Elk document-type, elk veld en elke block list is via de Content Delivery API of direct vanuit code uit te lezen. Daarnaast is content vaak al logisch gestructureerd: een FAQ-accordion bestaat uit aparte items, een content-pagina uit herkenbare componenten. Die structuur vertaalt zich natuurlijk naar chunks, waardoor de retrieval-stap scherpere resultaten oplevert.

Strongly typed access. Umbraco's ModelsBuilder genereert typed modellen voor alle content. Je hoeft geen HTML te parsen of XPath-queries te schrijven. Je loopt typed door de properties en weet precies welk veld welke betekenis heeft. Block lists en block grids laten zich recursief uitlezen, inclusief geneste componenten.

Eén ecosysteem. Omdat Umbraco, Hangfire, Qdrant-clients en de OpenAI SDK allemaal binnen .NET leven, is de hele keten één oplossing in één repository, met één deployment-pipeline en één monitoring-omgeving. Geen losse Python-service ernaast, geen extra hostingcomponent.

Umbraco HQ heeft zelf een AI-strategie ingezet langs twee sporen: een Umbraco.AI-packagesuite met een Copilot in de backoffice, en een Umbraco MCP-server waarmee externe tools zoals Claude of GitHub Copilot direct met een Umbraco-installatie kunnen praten. Die richting bevestigt waar we al langer in geloven: Umbraco is een natuurlijk fundament voor AI-toepassingen. Waar die packages zich richten op productiviteit binnen het CMS, blijft een maatwerk RAG-oplossing de aangewezen aanpak om eigen content te ontsluiten richting bezoekers of medewerkers, met volledige controle over indexering, bronnen en hosting.

Een bestaande Umbraco-omgeving is daarmee een uitstekende startpositie voor een RAG-implementatie, of de kennisbank nu op de publieke website komt, op een afgeschermd intranet, of als interne medewerkers-assistent.