Vraag een algemene AI-assistent naar het terugbetalingsbeleid van uw bedrijf, en hij kan alleen maar raden. Het heeft uw documenten nooit gezien. RAG, een afkorting van Retrieval-Augmented Generation, lost dit op door de juiste informatie op te zoeken en deze samen met de vraag aan het model te geven.

Deze handleiding legt elke fase in duidelijke taal uit en bouwt vervolgens een kleine versie met alleen de standaardbibliotheek van Python. We hebben die code uitgevoerd op Python 3.13 en de weergegeven scores zijn afkomstig van die run. Er wordt geen taalmodel gebruikt, dus het demonstreert het ophalen en snel bouwen, en we hebben de laatste antwoordstap niet getest.

Wat is RAG?

Retrieval-augmented generatie is een techniek die een zoekstap combineert met een taalmodel. Wanneer er een vraag binnenkomt, doorzoekt het systeem een ​​kennisbron, voegt de beste resultaten toe aan de prompt en vraagt ​​het model om te antwoorden op basis van dat materiaal.

Denk aan een openboekexamen. Een leerling met een gesloten boek vertrouwt op zijn geheugen en kan zich vol vertrouwen verkeerd herinneren. Een leerling met een open boek kan eerst de juiste pagina opzoeken. RAG geeft het model dat boek en laat het ook verwijzen naar welke pagina het gebruikte.

Het probleem dat RAG oplost

Een taalmodel op zichzelf heeft drie beperkingen voor zakelijk gebruik:

• Het kent uw privégegevens niet. Uw polissen, tickets en contracten maakten geen deel uit van de training.
• De kennis heeft een grenswaarde. Het systeem kan niet op de hoogte zijn van een prijs die u vanochtend heeft gewijzigd.
• Het kan antwoorden bedenken. Als het niet zeker is, kan het iets plausibels en toch vals opleveren.

RAG pakt ze alle drie aan, en je hoeft niets om te scholen. Werk een document bij, indexeer het opnieuw, en het volgende antwoord kan het gebruiken.

Hoe RAG werkt, stap voor stap

Een RAG-systeem heeft twee pijpleidingen. De ene bereidt uw gegevens van tevoren voor en de andere loopt voor elke vraag.

Indexeren: uw gegevens voorbereiden

1. Laden: verzamel inhoud uit pdf’s, wiki’s, databases of tickets.
2. Opschonen en opdelen: verwijder rommel en verdeel documenten vervolgens in kleine passages.
3. Insluiten: zet elke passage om in een lijst met cijfers, een zogenaamde insluiting, die de betekenis ervan vastlegt.
4. Opslaan: sla de insluitingen op in een doorzoekbare index, vaak een vectordatabase.

Vragen stellen: een vraag beantwoorden

1. Ophalen: sluit de vraag in en zoek de passages die de betekenis het dichtst benaderen.
2. Augment: voeg deze passages in de prompt in.
3. Genereren: het model schrijft een antwoord met behulp van die context.

Bij het ophalen hoeven geen vectoren te worden gebruikt. Het kan een zoekopdracht op trefwoord zijn of zelfs een SQL-query, afhankelijk van welke informatie de juiste informatie voor uw gegevens vindt.

Een klein werkend voorbeeld

Om de bewegende delen duidelijk te kunnen zien, is hier een kleine retriever zonder bibliotheken. Het geeft tekst weer zoals het aantal woorden telt, een veel eenvoudigere vervanging voor echte inbedding, en het scoort gelijkenis met behulp van de cosinusmaat.

import math, re
from collections import Counter

DOCS = {
    "refunds": "Refunds are paid within 7 days to the original payment method.",
    "shipping": "Standard shipping takes 3 to 5 working days across India.",
    "warranty": "All keyboards include a 2 year warranty against defects.",
}

def vectorize(text):
    return Counter(re.findall(r"[a-z0-9]+", text.lower()))

def similarity(a, b):
    dot = sum(a[word] * b[word] for word in a)
    size = math.sqrt(sum(v * v for v in a.values()))
    size *= math.sqrt(sum(v * v for v in b.values()))
    return dot / size if size else 0

def retrieve(question, k=1):
    q = vectorize(question)
    scored = [(similarity(q, vectorize(t)), name) for name, t in DOCS.items()]
    return sorted(scored, reverse=True)[:k]

def build_prompt(question):
    (score, name), = retrieve(question)
    return (
        "Answer using only the context. If it is not there, say you do not know.\n"
        f"Context: {DOCS[name]}\n"
        f"Question: {question}"
    )

Vragen naar terugbetalingen vindt de juiste passage en bouwt deze prompt op:

print(retrieve("How many days until refunds are paid?"))
# [(0.4558..., 'refunds')]

print(build_prompt("How many days until refunds are paid?"))
# Answer using only the context. If it is not there, say you do not know.
# Context: Refunds are paid within 7 days to the original payment method.
# Question: How many days until refunds are paid?

In een compleet systeem zou u die prompt nu naar een taalmodel sturen. Het belangrijke detail is de instructie om toe te geven wanneer het antwoord ontbreekt. Hierover kunt u meer lezen in onze gids voor prompt engineering.

Wat ons voorbeeld mist

Probeer nu een vraag die hetzelfde betekent, maar met andere woorden:

print(retrieve("When can I get my money back?", k=3))
# [(0.0, 'warranty'), (0.0, 'shipping'), (0.0, 'refunds')]

Elke score is nul, omdat de vraag met geen enkel document overeenkomt. “Geld terug” betekent terugbetaling aan een mens, maar het aantal woorden kan dit niet uitwijzen. Deze enkele uitvoer verklaart waarom echte systemen insluitingen gebruiken, die zo zijn ontworpen dat tekst met een vergelijkbare betekenis vergelijkbare getallen krijgt, zelfs als er geen woorden gemeenschappelijk zijn.

Maar ga er niet van uit dat inbedding alles oplost. Ze kunnen worstelen met exacte termen zoals productcodes en foutnummers, die bij het zoeken op trefwoorden heel goed worden afgehandeld. Dit is de reden waarom veel productiesystemen gebruik maken van hybride zoeken, waarbij de twee benaderingen worden gecombineerd.

Chunking: de stap die mensen onderschatten

Documenten worden in stukjes opgesplitst omdat hele bestanden te lang en onnauwkeurig zijn om op te halen. De maat die u kiest, brengt een echte afweging met zich mee:

Een paar honderd woorden met enige overlap tussen de stukjes is een gebruikelijk uitgangspunt, maar beschouw dat als een eerste gok om te testen. Splits indien mogelijk langs natuurlijke grenzen, zoals koppen. En voeg metagegevens toe, zoals de documenttitel, datum en afdeling, zodat u resultaten kunt filteren en bronnen kunt citeren.

Verbetering van het ophalen

Als de antwoorden slecht zijn, zijn dit de upgrades die het proberen waard zijn, grofweg in deze volgorde:

• Schoon de gegevens op. Verwijder eerst verouderde en dubbele documenten. Geen enkel algoritme lost tegenstrijdige bronnen op.
• Gebruik hybride zoeken. Combineer op betekenis gebaseerde resultaten en zoekwoordresultaten.
• Voeg een nieuwe rangschikking toe. Haal meer kandidaten op en gebruik vervolgens een gespecialiseerd model om ze opnieuw te ordenen op relevantie.
• Filteren op metadata. Beperk de resultaten op product, regio of datum voordat je gaat zoeken.
• Herschrijf de vraag. Zet een vage vervolgvraag in de vorm van ‘hoe zit het met de tweede?’ tot een volledige vraag.

RAG versus fijnafstemming

Ze sluiten elkaar niet uit. Onze vergelijking van RAG versus verfijning versus snelle engineering laat zien hoe u dieper kunt kiezen.

Hoe een RAG-systeem te testen

RAG is software en vereist tests zoals elke andere software. Creëer een reeks echte vragen, samen met de passages en antwoorden die u verwacht, en meet vervolgens de twee fasen afzonderlijk:

Voeg ook lastige gevallen toe: vragen zonder antwoord in uw gegevens, vragen met andere bewoordingen en vragen met tegenstrijdige bronnen. Voer deze set opnieuw uit wanneer u chunking, modellen of aanwijzingen wijzigt, net als bij een regressiesuite. Onze pytest-tutorial laat zien hoe u veel invoer via één test kunt uitvoeren.

Waarom RAG-systemen falen

• Het antwoord staat niet in de gegevens. Het model kan het nog steeds proberen, dus vertel het hoe het moet weigeren.
• Het juiste segment is niet opgehaald. Dit is vaak een probleem met het segmenteren of zoeken.
• Te veel context. Irrelevante passages kunnen het model afleiden en de kosten verhogen.
• Verouderde documenten. Een oud beleid kan net zo veilig worden opgehaald als het huidige beleid.
• Tabellen en pdf’s worden slecht geparseerd. Als de extractie de tekst vervormt, wordt het ophalen nooit hersteld.
• Alleen testen met demovragen. Echte gebruikers verwoorden de zaken heel anders.

Beveiliging en machtigingen

RAG brengt twee risico’s met zich mee die gemakkelijk te missen zijn. Ten eerste de toegangscontrole: als de index HR-bestanden bevat, mag de vraag van een juniormedewerker deze niet ophalen. Pas de machtigingen van elke gebruiker toe tijdens het ophalen, omdat het instrueren van het model om geheimen te bewaren geen betrouwbare beveiliging is.

Ten tweede: een snelle injectie. Een opgehaalde webpagina of document kan tekst bevatten zoals “negeer uw instructies”. Behandel opgehaalde inhoud als niet-vertrouwde gegevens, beperk de acties die het model kan ondernemen en eis dat een mens gevoelige acties goedkeurt.

Tot slot

RAG is een eenvoudig idee met veel praktische details: zoek de juiste informatie en vraag het model vervolgens om deze te gebruiken. Begin met een kleine, duidelijke set documenten en ongeveer twintig echte vragen. Zorg ervoor dat het ophalen goed werkt voordat u complexiteit toevoegt, omdat een bescheiden pijplijn met goede gegevens doorgaans beter is dan een geavanceerde pijplijn met slechte gegevens.

Veelgestelde vragen

Blijf leren