Een RAG chatbot bouwen

Je wilt een AI maken die alles weet van jouw documenten. Bijvoorbeeld voor je bedrijf, klantenservice of andere taak. Dan heb je een RAG chatbot nodig. Retrieval Augmented Generation is LLM output die is gegenereerd op basis van het zoeken (retrieval) van specifieke externe kennis.

De aanpak klinkt simpel. Je zoekt eerst de juiste passage op en laat het model op basis daarvan antwoorden. Tot je er 300 documenten in gooit. Hoe vind je dan die ene alinea die klopt? Ctrl+F strandt op synoniemen: de klant vraagt naar "geld terug", jouw document zegt "restitutie". Je moet zoeken op betekenis. Daar begint het echte werk.

Eerst hak je alles in stukken

Een taalmodel slikt geen handboek van 400 pagina's in één keer. Het contextvenster is te klein, en te veel tekst maakt elk antwoord vager. Dus knip je je documenten in kleinere brokken, chunks.

Hoe je knipt bepaalt wat je terugvindt. De ruwe methode telt gewoon tokens (delen van woorden) af, zeg 500, met wat overlap zodat een zin niet middenin breekt. Slimmer is knippen op natuurlijke grenzen: alinea's, kopjes, een wisseling van onderwerp. Onderzoek naar bedrijfsdocumenten laat zien dat zulke structuurbewuste chunking beter scoort en goedkoper is dan puur op betekenis knippen. Dat betekent dat je bijvoorbeeld chunks maakt op basis van hoofd en sub koppen, zodat je niet midden in een tekst een knip maakt.

De afweging zit altijd tussen scherpte en samenhang. Kleine chunks geven precieze treffers maar verliezen hun context. Grote chunks bewaren het verhaal maar brengen ruis mee. Eén ideale maat bestaat niet. Het hangt af van wat er in je documenten staat.

Betekenis wordt een rijtje getallen

Om op betekenis te zoeken, zet je elke chunk om in een vector: een rij van honderden getallen, vaak 768 of 1536 lang. Chunks die iets soortgelijks zeggen krijgen vectoren die dicht bij elkaar liggen, ook zonder één gedeeld woord. "Factuur betalen" en "openstaande rekening voldoen" belanden zo naast elkaar.

Dit is dé oplossing voor synoniemen, vaag taalgebruik in je bron documenten en het verschil met gewoon zoeken op een vaste zoekterm.

Vector search alleen laat je in de steek

Zoeken is nu kort gezegd: maak een vector van de vraag, pak de 5 dichtstbijzijnde chunks. Bij een handjevol documenten vergelijk je ze allemaal. Wij hebben technieken die dit schalen tot duizenden documenten.

Vectoren hebben één zwakke plek: exacte termen. Zoekt iemand op een ordernummer, een productcode of "artikel 7.3", dan draagt die term nauwelijks betekenis en zakt hij weg in de ranglijst. Ouderwets zoeken op trefwoorden, BM25, pakt zulke dingen wel feilloos.

Daarom draait een goed zoeksysteem allebei tegelijk. Dat heet hybride zoeken. Het probleem: de twee methodes geven onvergelijkbare scores. Je gebruikt twee compleet verschillende systemen en je wilt toch met een selectie documenten komen uit beide. De oplossing is Reciprocal Rank Fusion, dat de ruwe scores negeert en alleen naar de rangpositie kijkt. Een chunk die in beide lijsten bovenaan staat, wint. Zo dekt het ene gat het andere.

Wie stelt eigenlijk de zoekvraag?

Het verschil tussen een matige en een sterke RAG chatbot zit vaak in wie de zoekopdracht formuleert.

Op het laagste niveau is het bericht de zoekvraag. Je neemt letterlijk wat de gebruiker typt en zoekt daarop. Snel en goedkoop, maar een vage vraag geeft een vage treffer.

Een stap hoger geef je het model de zoekfunctie als tool. Het beslist zelf of het zoekt, herschrijft de vraag in één of meer gerichte queries, en zet filters op datum, afdeling of documenttype. "Verlofregeling voor deeltijders in 2024" wordt zo een strak afgebakende zoekopdracht in plaats een lang bericht “Kan je mij meer vertellen over verlofregeling, want ik hoorde laatst (…). Dat schiet niet op.

Het neusje van de zalm: multi agent RAG

Een team van agents die tegelijk samenwerken. De een doorzoekt het CRM, de ander je documenten, de derde het web. Een samenvat-agent maakt er een geheel van met kernpunten voordat die naar het hoofdmodel gaan. Dat scheelt flink in tokens en houdt het contextvenster leeg voor wat telt.

Een RAG chatbot leunt zelden op RAG alleen

In klantenservice wordt het pas bruikbaar als je de kennisbank koppelt aan live data. "Waar blijft mijn pakket?" beantwoord je niet uit een handleiding. Je haalt het ordernummer uit het CRM, het retourbeleid uit de documenten, en de bezorgstatus via een koppeling met de vervoerder. RAG levert het beleid, het CRM de context, de webkoppeling de actuele stand.

Bij interne documenten telt vooral vertrouwen. HR-beleid, technische handboeken, contracten. Daar verdient hybride zoeken zich terug, want een collega zoekt tegelijk op begrip ("thuiswerken") en op exacte verwijzing ("artikel 7.3"). Een filter op datum houdt verouderd beleid onderaan.

Zet die onderdelen goed neer en je chatbot doet iets wat een taalmodel alleen nooit kan. En die ene alinea, ergens tussen je 300 documenten? Die ligt binnen een halve seconde boven op de stapel.

Conclusie

Nu weet je hoe een RAG Chatbot werkt. Een hoop techniek om te zorgen dat de juiste info de LLM bereikt. Wil jij een AI die alles weet van jouw bedrijf? Laat een AI op maat bouwen of doe een snelle kickstart om te snel te zien wat werkt!