Learning
Cursussen → AI in je bedrijf → Week 8 → Les 31 / 33

Case 3: kennisbank met RAG

Je eigen documenten doorzoekbaar maken voor AI

Je hebt een archief aan documenten: producthandleidingen, interne procedures, e-mailarchieven, oudere offertes, wikipedia's van klantafspraken. Ergens daarin staat het antwoord op bijna elke vraag die iemand in je bedrijf kan stellen. Tot nu toe was die kennis alleen bruikbaar als je wist waar hij stond. Met een RAG-kennisbank maak je hem doorzoekbaar met natuurlijke taal, en laat je AI-antwoorden geven die onderbouwd zijn met jouw bronnen.

Wat RAG werkelijk is

Retrieval-Augmented Generation. Drie stappen. Eén: je documenten worden opgeknipt in brokjes en elk brokje krijgt een vector-representatie (embedding). Twee: wanneer een vraag binnenkomt, bereken je de embedding van de vraag en haal je de meest gelijkende brokjes op uit je vector-database. Drie: die brokjes gaan samen met de vraag naar het taalmodel, dat zijn antwoord daarop baseert.

Het verschil met "gewoon aan Claude vragen" is radicaal. Het model hallucineert niet over jouw documenten, want het krijgt ze letterlijk mee. De antwoorden zijn verifieerbaar, want je weet precies uit welk document ze komen. En je kennisbank kan in zeldzame uren groeien zonder dat je een model opnieuw hoeft te trainen.

De stack — concreet, PHP-vriendelijk

Voor een solo-bouwer in 2026 is dit een rustige stack:

Je zit met één extensie in je database, één embeddings-API, en één LLM-call per vraag. Geen Kubernetes, geen framework-soep.

✦ Waarom pgvector voor solo

Als je al Postgres draait voor je applicatie, is pgvector de minst ingewikkelde keuze. Eén CREATE EXTENSION vector;, een embedding vector(1024)-kolom, een HNSW-index en je hebt een vector-database die draait naast je gewone tabellen. Voor tot enkele miljoenen chunks prestaat dit uitstekend zonder extra infrastructuur.

Chunking — waar veel fout gaat

Chunking is geen technische detail, het is de ruggengraat. Te kleine brokjes (100 tokens) verliezen context; te grote (3.000 tokens) maken retrieval onscherp en generatie duur. De sweet spot voor Nederlands is meestal 500 tot 800 tokens per chunk met 100 tokens overlap tussen opeenvolgende chunks.

Structuur-bewust chunken is het verschil tussen een middelmatige en een goede kennisbank. Knip op paragraafgrenzen, niet midden in een zin. Bij producthandleidingen: hou kopjes bij hun secties. Bij PDF's met tabellen: parse tabellen apart en stop ze als geheel in één chunk. Bij code-documentatie: één functie, één chunk. Dit vraagt een paar honderd regels PHP, maar het tilt je retrieval-kwaliteit van 60% naar 85%.

Embeddings — wat kiezen

In 2026 zijn er vier serieuze families van embeddings-modellen voor zakelijk gebruik. Voor Nederlandstalige content is Cohere Embed v3 multilingual of Voyage AI's multilingual variant meestal de sterkste. OpenAI's text-embedding-3-large werkt ook, maar is wat meer Engels-biased. Anthropic levert zelf geen embeddings — je combineert Claude dus met een embeddings-provider naar keuze.

Prijs: ongeveer 0,10 tot 0,20 dollar per miljoen tokens ingevoerd. Voor een kennisbank van 10.000 chunks van elk 600 tokens (6 miljoen tokens) is dat eenmalig één tot twee dollar voor de volledige index. Herindexatie bij veranderingen is een kwestie van centen.

Retrieval-kwaliteit tunen

Eerste versie: vector search, top-5, klaar. Werkt redelijk, maar je gaat merken dat sommige vragen slecht scoren. Een paar kneepjes:

Niet alles tegelijk invoeren. Begin simpel, meet waar het mis gaat, voeg alleen toe wat helpt. Reranking is vaak de grootste stap.

✦ Evalueer met echte vragen

Verzamel twintig à vijftig echte vragen uit je support-inbox en hun correcte antwoorden. Run je retrieval-stack erop en meet: in hoeveel procent van de gevallen zit het juiste antwoord in de top-5? Dit simpele getal is je RAG-kwaliteitscijfer. Elke verandering in chunking, embeddings of reranking kun je ertegen testen.

Source-attributie

De kracht van RAG is verifieerbaarheid. Gebruik die. Bij elke retrieved chunk bewaar je de bron: document-id, bestandsnaam, pagina- of sectienummer, URL als publiek. Laat Sonnet in zijn antwoord nummers [1], [2] plaatsen die terugverwijzen naar de chunks die hij gebruikte. In je UI toon je die citaties als klikbare links naar de bronnen.

De systeem-prompt: "Beantwoord uitsluitend op basis van de genummerde context-fragmenten. Verwijs bij elke feitelijke uitspraak naar het fragmentnummer. Als het antwoord niet in de fragmenten staat, zeg dat het antwoord niet in de beschikbare bronnen is gevonden." Simpele regel, enorm effect op vertrouwen en debugbaarheid.

Updates en consistentie

Je kennisbank verandert. Nieuwe producten, nieuwe procedures, gewijzigde garantietermijnen. Een robuuste ingestie-pijplijn heeft drie eigenschappen. Één: elk brondocument heeft een versie-hash. Bij heringest, als de hash gelijk is, gebeurt niets; anders worden oude chunks verwijderd en nieuwe gemaakt. Twee: oude chunks worden markeert als verouderd (soft delete) voor een week, zodat je terug kunt rollen. Drie: een cronjob draait nachtelijk over alle bronnen en synchroniseert.

Zonder deze discipline krijg je binnen een half jaar een kennisbank vol achterhaalde informatie, en dan gaat de RAG gebruikers tegenwerken in plaats van helpen.

Het kostenplaatje

Voor een kennisbank van 10.000 chunks en 500 queries per maand, elk met 3.000 tokens retrieved context en 500 tokens output via Sonnet:

Totale lopende kosten onder de tien dollar per maand voor een fatsoenlijke, bruikbare kennisbank. Plus wat tijd om de ingestie-pijplijn neer te zetten — een weekend werk voor een solo-ontwikkelaar die PHP gewend is.

Valkuilen

Eerste: te veel tegelijk willen indexeren. Begin met één bronsoort (bijvoorbeeld je markdown-handleidingen). Kwaliteit boven kwantiteit. Tweede: retrieval-fouten niet zichtbaar maken. Als je model op basis van niet-relevante chunks antwoordt, ziet de gebruiker een plausibele maar off-topic reactie. Toon altijd de bronnen. Derde: vergeten dat RAG ook AVG-implicaties heeft — als je klantdossiers indexeert, vallen die vectors en chunks onder dezelfde regels als de brondata. Toegangsrechten per chunk is echte werk, maar onvermijdelijk bij multi-tenant setups.

Drie dingen om mee te nemen

  1. RAG maakt AI honest. Antwoorden komen uit jouw bronnen, citaten verwijzen terug, hallucinaties nemen drastisch af.
  2. Chunking en reranking zijn de grote hefbomen. Niet exotische tech. Goede brokken en een heroverweging van top-k brengt je retrieval van middelmatig naar sterk.
  3. Meet wat je retrieved. Twintig echte vragen met verwachte bronnen = je eigen eval-set. Zonder meetlat weet je niet of een "verbetering" er een was.

In de volgende les kijk je vooruit: wat komt er in 2026 en 2027, en wat moet je er nu mee? Zonder hype, met de hand op de AVG.

Tot dan. Blijf scherp.

Cursus
↑ Overzicht