RAG versus fine-tuning: wanneer gebruikt u welke aanpak?

Wanneer je wilt dat een LLM goed werkt voor jouw specifieke domein, heb je twee hoofdstrategieën: Retrieval-Augmented Generation (RAG) voegt tijdens inferentie dynamisch relevante kennis toe, terwijl fine-tuning de gewichten van het model bijwerkt om kennis, stijl of voorkeuren voor de indeling in het model vast te leggen. De juiste keuze kan het verschil betekenen tussen een betrouwbaar systeem en maanden aan dure GPU-berekeningen die aan de verkeerde aanpak zijn verspild.

Fine-tuning werkt de gewichten van het model bij door te trainen op voorbeelden van invoer-uitvoerparen. Het is vooral geschikt om gedrag te veranderen: een model leren om altijd in een specifieke JSON-indeling te antwoorden, een merkstem aan te nemen, domeinspecifieke redeneerpatronen te volgen of een type taak uit te voeren waarvoor het niet is geoptimaliseerd. Fine-tuning werkt feitelijke kennis niet betrouwbaar bij — modellen kunnen zich te sterk aanpassen aan trainingsvoorbeelden zonder de onderliggende feiten te generaliseren naar nieuwe queries.

RAG wijzigt de modelgewichten niet. In plaats daarvan verandert het de informatie die tijdens inferentie beschikbaar is voor het model door relevante documenten in het contextvenster te plaatsen. RAG is vooral geschikt voor kennis: vragen over privédocumenten beantwoorden, antwoorden actueel houden met regelmatig bijgewerkte gegevens en antwoorden baseren op controleerbare bronnen. Wat RAG niet eenvoudig verandert, is de aangeboren stijl, voorkeuren voor de indeling of redeneeraanpak van het model.

Voor elk gebruiksscenario waarin informatie in de loop van de tijd verandert, is RAG duidelijk beter. Een vectoropslag opnieuw indexeren wanneer documenten worden bijgewerkt, duurt enkele minuten en vereist geen GPU-middelen. Een model fine-tunen met nieuwe gegevens vereist opnieuw trainen (duur en langzaam), en zelfs dan herinnert het model zich de nieuwe feiten mogelijk niet betrouwbaar. Productcatalogi, wettelijke voorschriften, medische richtlijnen en bedrijfsbeleid zijn allemaal beter geschikt voor RAG dan voor fine-tuning.

Als je wilt dat het model altijd antwoordt in een zeer specifieke stijl, toon of gestructureerde indeling die je met prompt engineering alleen niet betrouwbaar kunt afdwingen, is fine-tuning het juiste hulpmiddel. Voorbeelden zijn een klantenservicebot die altijd de specifieke woordenschat van je merk moet gebruiken, een codegenerator die code moet produceren volgens de interne stijlgids van je bedrijf, of een classificatiemodel dat in duizenden randgevallen betrouwbaar een vaste taxonomie moet uitvoeren.

Fine-tuning heeft hoge aanloopkosten (rekenkracht voor het trainen, tijd voor het voorbereiden van de gegevensset en evaluatie), maar verlaagt de kosten per query als je dankzij fine-tuning een kleiner model kunt gebruiken. RAG heeft lage aanloopkosten (het indexeren van een vectordatabank is goedkoop), maar voegt overhead per query toe: een aanroep van een embedding-API plus iets langere prompts met ingevoegde context. Voor de meeste toepassingen met minder dan 10 miljoen dagelijkse queries is de overhead per query van RAG verwaarloosbaar vergeleken met de ontwikkelkosten van fine-tuning.

Fine-getunede modellen kunnen sneller zijn tijdens inferentie, omdat kortere prompts nodig zijn — de kennis staat in de gewichten en niet in de context. RAG voegt twee retourrondes toe: een aanroep van een embedding-API en een query naar de vectorzoekopdracht. De totale overhead bedraagt meestal 50-200 ms. Voor latentiegevoelige toepassingen, zoals realtime-spraakassistenten, is deze overhead belangrijk. Voor de meeste chat- en vraag-en-antwoordtoepassingen merken gebruikers de extra latentie niet.

RAG biedt een duidelijk controlespoor: voor elk antwoord weet je precies welke documenten zijn opgehaald en kun je die aan de gebruiker tonen. Fine-getunede modellen antwoorden vanuit ondoorzichtige gewichten — er is geen registratie van welk trainingsvoorbeeld een bepaalde uitvoer heeft veroorzaakt. In gereguleerde sectoren zoals financiën, gezondheidszorg en recht, waar antwoorden uitlegbaar en controleerbaar moeten zijn, is de transparantie van RAG een belangrijk voordeel ten opzichte van fine-tuning.

RAG en fine-tuning sluiten elkaar niet uit. Een veelgebruikt patroon in productie is: fine-tune een model voor een consistente uitvoerindeling en domeinwoordenschat en voeg vervolgens RAG toe om actuele feitelijke kennis aan te leveren. Het fine-getunede model verwerkt de stijl en structuur betrouwbaar, terwijl RAG de kennis levert. Deze combinatie presteert beter dan elke afzonderlijke aanpak voor bedrijfstoepassingen met hoge inzet.

Volg deze beslisroute: Gaat het probleem over consistentie van stijl of indeling? → Overweeg fine-tuning. Is de informatie privé of wordt deze vaak bijgewerkt? → Gebruik RAG. Heb je bronverwijzingen nodig? → Gebruik RAG. Is de gegevensset te klein voor fine-tuning (minder dan 500 voorbeelden)? → Gebruik RAG met few-shot prompting. Moet het model een taak uitvoeren die het momenteel weigert uit te voeren? → Fine-tune met RLHF of DPO. Begin bij twijfel met RAG — het is sneller te bouwen, eenvoudiger bij te werken en transparanter.

Gebruik deze scenario's om inzicht op te bouwen: interne HR-chatbot (beleid verandert elk kwartaal, bronverwijzingen zijn vereist) → RAG. Codeaanvulling voor een propriëtair framework (consistente codestijl, patronen van het framework) → fine-tuning. Vraag-en-antwoord over juridische documenten (privédocumenten, nauwkeurige bronverwijzing vereist) → RAG. Klantenservicebot (specifieke toon, product-FAQ verandert wekelijks) → fine-tuning voor de toon + RAG voor de kennis. Samensteller van samenvattingen van medische literatuur (actueel onderzoek, toeschrijving is cruciaal) → RAG.

In deze les heb je geleerd dat fine-tuning het gedrag en de stijl van een model verandert, maar feitelijke kennis niet betrouwbaar bijwerkt, dat RAG dynamisch kennis aanlevert tijdens inferentie met volledige transparantie en bronverwijzingen, en wat het besliskader is om te kiezen — gebruik RAG voor regelmatig bijgewerkte privékennis waarvoor bronvermelding nodig is, gebruik fine-tuning voor een consistente stijl en indeling, en combineer beide voor bedrijfstoepassingen met hoge inzet. Hierna beginnen we met het bouwen van een volledige RAG-pipeline vanaf nul.