Wat is RAG? Retrieval-Augmented Generation voor het mkb uitgelegd

Een algemeen taalmodel kent uw interne documenten niet. Het is getraind op openbare data en eindigt op een bepaalde datum. Vraagt een medewerker naar de actuele leveringsovereenkomst met een bepaalde toeleverancier, dan heeft het model twee mogelijkheden: het zegt dat het het antwoord niet kent, of het verzint een aannemelijk klinkend antwoord. De tweede mogelijkheid is de gevaarlijke.

RAG dicht dat gat. Voor elk antwoord doorzoekt het systeem uw eigen bronnen, zoals contracten, handleidingen, tickets of een wiki, en geeft de relevante fragmenten door aan het model. Het model formuleert vervolgens een antwoord dat op die concrete plekken berust en ze kan citeren. Van een model dat moet gokken, wordt een systeem dat opzoekt. De verdere zakelijke meerwaarde hebben wij beschreven in Discover the Potential of AI in Business.

Een RAG-pipeline bestaat uit vijf stappen die zich netjes van elkaar laten scheiden.

1. Indexering. Uw documenten worden opgedeeld in kleine fragmenten en vertaald naar numerieke vectoren die hun betekenis weergeven. Deze vectoren staan in een vectordatabase.
2. Retrieval. Bij een vraag berekent het systeem de passende vector en haalt de meest gelijkende fragmenten uit de database. Hier wordt de kwaliteit van het latere antwoord bepaald.
3. Augmentatie. De gevonden fragmenten worden samen met de vraag in de prompt van het model geplaatst.
4. Generatie. Het model formuleert het antwoord op basis van de meegeleverde context, niet uit zijn geheugen.
5. Bronvermelding. Het systeem noemt de documenten waaruit het antwoord afkomstig is, zodat een mens ze kan controleren.

Belangrijk is het derde punt van de scheiding: u kunt het model vervangen zonder uw data opnieuw te verwerken, en u kunt uw data actualiseren zonder het model aan te raken.

De meeste energie gaat in de praktijk naar de keuze van het model. Naar onze ervaring ligt de hefboom vaker bij de retrieval. Wij hebben dezelfde vakinhoudelijke vraag voorgelegd aan een groot gehost model en aan een kleiner lokaal model met een zorgvuldig afgestemde retriever. Bij eenduidige vragen presteerden beide gelijk. Bij de dubbelzinnige gevallen, dus de minderheid die er echt toe doet, bepaalde de retrievalkwaliteit het bruikbare antwoord, niet de modelgrootte.

De reden is simpel: een groter model formuleert een fout antwoord alleen welsprekender als het het juiste fragment mist. Een goed afgestemde retriever levert daarentegen de passende plek, en dan volstaat een kleiner model. Dezelfde observatie hebben wij al uitvoeriger beschreven in ons eerdere artikel over Retrieval-Augmented Generation.

RAG past goed bij een privacybewuste architectuur, omdat alle bouwstenen in eigen huis kunnen draaien. Retriever, vectordatabase en model kunnen on-premise draaien, zodat noch de vraag, noch de gevonden documenten naar een externe dienst gaan. Voor bedrijven die met persoonsgegevens, contracten of constructiedocumenten werken, is dat vaak de voorwaarde om een project überhaupt te starten.

Welk model geschikt is voor lokale werking en met welke hardware, behandelen wij in Lokale LLM in het bedrijf: hardware, kosten, realiteit. De fundamentele afweging tussen lokale werking en cloud staat in On-premise versus cloud-LLM: wanneer lokale AI de juiste keuze is.

RAG loont wanneer uw kennis in documenten zit, regelmatig verandert en door veel mensen wordt geraadpleegd. Typische gevallen zijn interne kennisbanken, support, offertecontrole en het zoeken in technische documentatie.

RAG loont minder wanneer het antwoord een exacte berekening uit een database is, want daarvoor is een klassieke query preciezer. Het vervangt ook geen zorgvuldig databeheer: zijn de brondocumenten tegenstrijdig of verouderd, dan levert ook een goede retrieval tegenstrijdige antwoorden op. De eerste stap van een RAG-project is daarom meestal de eerlijke doorlichting van de aanwezige kennis, niet de keuze van het model.