RAG vs Fine-Tuning: Wanneer Gebruik Je Wat? (Met Echte Cijfers)

RAG vs Fine-Tuning: Wanneer Gebruik Je Wat? (Met Echte Cijfers)

De meeste rag vs fine tuning-adviezen slaan het enige experiment over dat beide op dezelfde taak mat. Balaguer et al. duwden in arXiv:2401.08406 (162 keer geciteerd) een landbouw-QA-set door beide pijplijnen: fine-tuning kocht meer dan 6 nauwkeurigheidspunten, en RAG stapelde daar nog 5 bovenop. Hun Tabel 18 zet GPT-4 op 75% rauw, 81% fine-tuned, 86% fine-tuned met retrieval. Waarom raden we de meeste teams dan toch aan om met RAG te beginnen? Omdat versheid, citaties en de kostenrekensom hieronder meer projecten beslissen dan een nauwkeurigheidsverschil van 1 punt.

Belangrijkste punten

• RAG is de standaard wanneer kennis vaak verandert of antwoorden bronnen moeten citeren; fine-tuning wint op consistent formaat en latency.
• Fine-tuning-kosten vallen vooraf (training); RAG-kosten vallen per query (embeddings plus extra input-tokens).
• Gepubliceerd bewijs op dezelfde taak: fine-tuning voegde 6 nauwkeurigheidspunten toe, RAG nog 5 erbovenop, en de hybride versloeg beide alleen.
• Doe de vijf checks (dataversheid, gelabelde voorbeelden, latency, citaties, teamvaardigheid) voordat je ook maar één regel trainingscode schrijft.

Wanneer Gebruik Je RAG vs Fine-Tuning? (Snel Oordeel)

Kies RAG als je kennis vaak verandert of je antwoorden citaties moeten bevatten. Kies fine-tuning als je een consistent uitvoerformaat en lage latency nodig hebt, en je honderden gelabelde voorbeelden bezit. Gebruik beide zodra een deployment volwassen is. RAG bewerkt de context die het model leest; fine-tuning bewerkt het model zelf. De meeste teams hebben het eerste nodig, niet het tweede.

Eén regel om te onthouden: RAG verandert wat het model leest; fine-tuning verandert wat het model is. Kies op basis van wat je taak daadwerkelijk nodig heeft.

NVIDIA's RAG-woordenlijst definieert de retrieval-kant helder als je de leerboekversie wilt. Definities kiezen je architectuur niet. Bewijs wel, dus begin daar.

Wat Toont het Bewijs? Eén Taak, Beide Aanpakken, Gemeten

De enige gemeten vergelijking op dezelfde taak in de top vijf van Google voor deze query is Balaguer et al. 2024, een Microsoft Research-studie die 162 keer geciteerd is. Het team draaide één landbouw-QA-taak door een RAG-pijplijn, een fine-tuned model en een hybride van beide, en liet GPT-4 de antwoorden beoordelen. In hun opstelling versloeg fine-tuning alleen RAG alleen nipt, en het stapelen van beide versloeg elk afzonderlijk met een grotere marge.

De landbouw-case-study (arXiv:2401.08406)

De studie, ingediend in januari 2024 door Angels Balaguer en 15 co-auteurs, onderzoekt wat ervoor nodig is om boeren locatiespecifieke inzichten te geven. Hun pijplijn extraheert informatie uit PDF's, genereert vraag-antwoordparen en evalueert Llama2-13B, GPT-3.5 en GPT-4 met en zonder retrieval.

Balaguer et al. rapporteren een nauwkeurigheidsstijging van meer dan 6 procentpunten door fine-tuning, cumulatief met RAG, dat er nog 5 punten bovenop voegde. De hybride pijplijn versloeg beide aanpakken alleen. Hun Tabel 18 toont de volgorde voor GPT-4: 75% zonder hulp, 80% met RAG, 81% fine-tuned, 86% fine-tuned plus RAG. Let op hoe dicht 80% en 81% bij elkaar liggen; het verschil tussen RAG alleen en fine-tuning alleen is één punt, terwijl de hybride vijf punten los zit van beide. In één experiment putte het fine-tuned model kennis uit andere regio's om regio-specifieke vragen te beantwoorden, waardoor de antwoordgelijkenis steeg van 47% naar 72%.

Het economische bewijs

Snorkel AI's gepubliceerde studie (november 2022) dekt de kostenkant. Op een 100-weg juridische classificatiebenchmark (LEDGAR, 80.000 contractbepalingen) evenaarde een fine-tuned RoBERTa-model een fine-tuned GPT-3, terwijl het 1.400× kleiner was, minder dan 1% van de ground-truth labels gebruikte en draaide op 0,1% van de productie-inferentiekosten van het fine-tuned GPT-3-model, ruwweg een duizendste. Totale bouwkosten: $1.915 met programmatisch labelen versus $7.418 voor handmatige annotatie plus GPT-3 fine-tuning. Eén kanttekening: dat is classificatie, geen generatieve QA, dus beschouw de verhoudingen als directioneel.

Onze interpretatie

Onze lezing: hun opstelling is het vriendelijkste geval dat fine-tuning ooit krijgt, en toch won het maar met één punt. Balaguer et al. trainden op een vast PDF-corpus en evalueerden tegen datzelfde bevroren corpus, dus niets wat de gewichten leerden kon verouderen tijdens het experiment. De meeste productie-kennisbanken staan niet zo stil. Een supportbot die vragen beantwoordt over de release van vorige week verdient de 6 punten opnieuw bij elke hertrainingscyclus, terwijl de index die RAG voedt dezelfde middag nog bijgewerkt is. Daarom lezen we een nauwkeurigheidsvoordeel van 1 punt als de zwakste input voor deze beslissing, en versheid als de sterkste. Waar het bewijs niet generaliseert: Snorkel's resultaat is een classificatiebenchmark, en geen van beide studies test toon of formaatcontrole, wat het sterkste argument voor fine-tuning blijft.

Fine-tuning is minder vaak het juiste antwoord dan teams denken; de meeste projecten die "fine-tune" zeggen, bedoelen eigenlijk "retrieve."

Hoe Werkt RAG, en Wanneer Wint Het?

RAG (retrieval-augmented generation) beantwoordt vragen vanuit documenten die jij beheert, in plaats van wat het model tijdens de training onthouden heeft. Voor het eerst voorgesteld door Lewis et al. in 2020, werd het de standaard voor kenniswerk omdat de kennis buiten het model leeft: update de index, en elk antwoord verandert morgen zonder hertraining.

De pijplijn bestaat uit vier stappen:

1. Innemen. Parse je documenten (PDF's, wiki's, tickets) naar een corpus.
2. Chunk en embed. Split in chunks van een paar honderd tokens en converteer elk naar een vector met een embedding-model.
3. Ophalen. Vind op query-tijd de top-K meest vergelijkbare chunks, plus keyword-matches voor exacte strings zoals SKU's en foutcodes.
4. Verrijken en genereren. Stop die chunks in de prompt en laat de LLM antwoorden met bronnen erbij.

RAG wint op drie assen: versheid (herindexeren in plaats van hertrainen), citities (elk antwoord verwijst naar de chunk waar het vandaan komt) en datacontrole (klantdata komt nooit in een trainingsrun terecht). Als je de volledige bouwuitleg wilt, hier is hoe je een RAG-applicatie stap voor stap bouwt.

Eén waarschuwing over retrieval-kwaliteit: de pijplijn is zo goed als zijn embedding- en retrieval-mix. Anthropic's Contextual Retrieval mat een 5,7% top-20 retrieval-faalpercentage op gewone opstellingen, dalend naar 2,9% met contextuele embeddings plus BM25, en naar 1,9% zodra een reranker werd toegevoegd. Als exact-match queries blijven falen, dan is hybride zoeken (BM25 vs vector) de oplossing.

Wanneer Wint Fine-Tuning? (En Wat Is PEFT?)

Fine-tuning wint wanneer het probleem zit in hoe het model antwoordt, niet in wat het weet: consistent uitvoerformaat, merktoon, of een hard latency-budget zonder retrieval-ronde. Het is ook de hefboom voor kleine-model-economie. Snorkel's GPT-3-kwaliteit-tegen-0,1%-van-de-kosten resultaat hierboven bestaat alleen omdat iemand een klein model fine-tunede in plaats van een groot model te serveren.

Volledige fine-tuning vs PEFT (LoRA / QLoRA)

Volledige fine-tuning werkt elk gewicht in het model bij. Het is duur, traag en zeldzaam buiten grote labs. Bijna iedereen scheept PEFT (parameter-efficient fine-tuning) uit. LoRA (Hu et al. 2021) bevriest de basisgewichten en traint een kleine low-rank adapter, doorgaans 0,1-1% van het aantal parameters. QLoRA voegt daar 4-bit kwantisatie aan toe, zodat een 13B-model op één consumenten-GPU past. Eén verwante term die goed is om te kennen: continuous pretraining, waarbij een model blijft voortrainen op een rauw domeincorpus (niet-begeleid) voordat het begeleid fine-tuned op gelabelde voorbeelden.

Een minimale LoRA-configuratie, volgens de Hugging Face PEFT-documentatie:

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,                          # low-rank dimension; 8-64 typical
    lora_alpha=32,                 # scaling factor, commonly 2x r
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19

Voor datasetvoorbereiding, epoch-aantallen en evaluatie, zie onze stap-voor-stap fine-tuning-gids.

De risico's zijn reëel: overfitting op kleine datasets (een paar honderd voorbeelden kunnen onthouden in plaats van leren), veroudering (gewichten bevriezen je kennis op de training-cutoff) en geen bronverwijzing (een fine-tuned model kan zijn bewijs niet tonen). Als een van die drie een dealbreaker is, heb je jezelf zojuist teruggepraat naar RAG.

RAG vs Fine-Tuning vs Prompt Engineering: Waar Passen de Andere?

De drie zijn een ladder, geen rivalen. Prompt engineering verandert de instructies, RAG verandert de context die het model leest, en fine-tuning verandert de gewichten. OpenAI's eigen fine-tuning-gids plaatst fine-tuning als laatste in de lus: eerst evals, dan prompts, pas trainen wanneer prompten niet meer voldoende is. Twee nieuwere opties maken de gereedschapskist compleet.

Eén verwarring die benoemd moet worden: MCP-servers en agent-frameworks zijn orkestratie, geen maatwerk. Ze bepalen welke tools en bronnen het model kan bereiken; ze veranderen niet hoe het model antwoordt. Je kunt een RAG-pijplijn in een agent draaien en het model eronder fine-tunen, en veel productiesystemen doen beide. De autocomplete-oorlogen ("vs mcp", "vs agents") zijn categoriefouten.

Is RAG Goedkoper dan Fine-Tuning? Het Echte Kostenmodel

Kort antwoord: bij realistische query-volumes, ja. De rekening van fine-tuning valt vooraf (gelabelde data plus training), terwijl de rekening van RAG per query komt (embeddings plus extra input-tokens). OpenAI's fine-tuning-documentatie rekent training per token af, maar tokenkosten zijn kleingeld naast de menselijke kosten van gelabelde voorbeelden. Hier is de rekensom op openbare lijstprijzen.

De break-even-vraag: hoeveel queries totdat RAG's cumulatieve belasting per query gelijk is aan de fine-tuning-investering?

break_even = training_cost / per_query_retrieval_delta
           = $1,915 / $0.0003
           ≈ 6.4 million queries

Bij 50.000 queries per maand is dat meer dan tien jaar. Voor de meeste producten verdient de fine-tuning-investering zich nooit terug via tokenbesparingen alleen; je fine-tuned voor formaat en latency, niet om RAG te verslaan op kosten. De som kantelt voorbij miljoenen queries per maand of met zeer grote opgehaalde contexten. En let op de asymmetrie: de fine-tuning-rekening vernieuwt elke keer dat dataverschuiving een hertraining afdwingt, terwijl RAG lineair schaalt met volume maal chunkgrootte. Als de kosten per query de echte zorg zijn, begin dan met het verlagen van LLM-API-kosten per query; als je toch de trainingsroute op gaat, vergelijk dan eerst fine-tuning-tools voordat je de cheque uitschrijft.

Eén versheidsnotitie: vanaf juli 2026 vermeldt OpenAI's fine-tuning-documentatie dat het hosted-platform wordt afgebouwd voor nieuwe gebruikers, waarbij bestaande gebruikers de komende maanden trainings toegang behouden. Het is een reden te meer waarom teams naar open-model PEFT of gewone RAG neigen.

5 Checks Voordat Je Kiest

Doe deze vijf ja-of-nee checks voordat je ook maar één regel trainingscode schrijft; het patroon van antwoorden wijst betrouwbaarder naar RAG, fine-tuning of hybride dan welke benchmark dan ook. Antwoord eerlijk, en tel dan.

1. Verandert de kennis sneller dan je kunt hertrainen? Ja → RAG. Een hertraining per documentupdate is geen ops-plan.
2. Heb je een paar honderd gelabelde voorbeelden? Nee → RAG of prompt engineering. Fine-tuning op 40 voorbeelden onthoudt; het leert niet.
3. Is er een hard latency-budget? Strak → fine-tuning neigt. Het overslaan van de retrieval-ronde bespaart 50-200ms.
4. Moeten antwoorden citaties of een audit-trail bevatten? Ja → RAG. Fine-tuned modellen kunnen niet naar de bronchunk verwijzen.
5. Heeft het team ML-vaardigheid plus GPU- of API-budget voor training? Nee → RAG. Een index die je kunt herbouwen verslaat gewichten die je niet kunt hertrainen.

Meestal ja op 1, 4, 5 → RAG. Meestal ja op 2 en 3 met een stabiel domein → fine-tuning. Verdeelde antwoorden, of een volwassen product met echt verkeer → hybride (volgende sectie). Het punt van de checklist is beslissen op basis van bewijs, niet op basis van welke techniek deze maand trending is in je feed.

Kun Je RAG en Fine-Tuning Samen Gebruiken?

Ja, en voor volwassen deployments is het hybride patroon de norm, niet de uitzondering. Fine-tune voor domeinvaardigheid en uitvoerformaat (het hoe), retrieve voor feiten op inferentie-tijd (het wat). Balaguer et al. rapporteren precies dit op hun landbouwtaak: de hybride pijplijn versloeg beide aanpakken alleen, met RAG's 5-punts winst die bovenop de 6 van fine-tuning stapelde.

Het volwassenheidspad dat we aanraden: begin met prompt engineering, voeg RAG toe op het moment dat antwoorden privé of verse data nodig hebben, en voeg fine-tuning pas toe wanneer formaatinconsistenties of latency pijn gaan doen in productie. Spring direct naar fine-tuning en je betaalt de trainingsbelasting voordat je weet of retrieval het probleem al opgelost heeft.

Het hybride patroon is geen compromis; voor volwassen deployments is het de standaard: fine-tune voor formaat, retrieve voor feiten.

Hoe Evalueer Je Je Winnaar?

Kies de winnaar zoals je een database zou kiezen: meet op je eigen workload, niet op gevoel. Het recept past in één alinea en dekt de vier cijfers die er werkelijk toe doen.

• Apart gehouden vraagset. 100-300 echte gebruikersvragen. Geen synthetische, nooit iets dat tijdens training of indexering gezien is.
• Faithfulness en antwoordcorrectheid. Faithfulness vraagt of het antwoord gegrond is in de opgehaalde context; antwoordcorrectheid vraagt of het daadwerkelijk klopt. Het paar, gepopulariseerd door RAGAS, vangt zowel hallucinatie als retrieval-missers.
• Latency op p95, niet het gemiddelde. Retrieval voegt een ronde toe; meet de staart.
• Kosten per 1.000 queries, tokens plus infrastructuur, gemeten in plaats van geraden.
• Herhaal bij verschuiving. Nieuwe documenten, nieuwe model-snapshot, nieuw kwartaal: draai de set opnieuw.

De volledige metrics-uitwerking, inclusief tooling, staat in onze LLM-evaluatiegids.

Veelgestelde Vragen

Kun je RAG en fine-tuning samen gebruiken?

Ja. Fine-tune voor uitvoerformaat en domeinvaardigheid, en houd retrieval voor feiten op inferentie-tijd. Balaguer et al. maten deze hybride op een landbouw-QA-taak en vonden dat het beide aanpakken alleen versloeg, waarbij de nauwkeurigheidswinsten zich opstapelden. De meeste volwassen productiesystemen komen hier uit: gewichten voor het hoe, retrieval voor het wat.

Wanneer geen fine-tuning gebruiken?

Sla fine-tuning over wanneer je kennis sneller verandert dan je kunt hertrainen, wanneer je minder dan een paar honderd gelabelde voorbeelden hebt, wanneer antwoorden citaties of audit-trails moeten bevatten, of wanneer er geen budget is om te hertrainen als data verschuift. Die vier voorwaarden beschrijven de meeste early-stage producten, wat de reden is dat RAG gewoonlijk de juiste eerste zet is.

Is fine-tuning ontkracht?

Nee, maar zijn terrein is gekrompen. Lange contextvensters en goedkope RAG absorbeerden use cases die in 2023 fine-tuning vereisten. Wat overblijft is reëel: strikt uitvoerformaat, merktoon, latency-budgetten zonder retrieval-ronde, en kleine-model-economie. Als je probleem zit in hoe het model antwoordt in plaats van wat het weet, dan is fine-tuning nog steeds het gereedschap.

Wanneer gebruik je RAG vs fine-tuning?

Gebruik RAG wanneer antwoorden afhangen van privé of vaak bijgewerkte kennis, of wanneer je citaties nodig hebt. Gebruik fine-tuning wanneer je consistent formaat, toon of latency nodig hebt en je genoeg gelabelde voorbeelden hebt. Gebruik beide zodra het product volwassen is. Bij twijfel, begin met RAG: het is goedkoper om terug te draaien dan een trainingsrun.

Is RAG goedkoper dan fine-tuning?

Vooraf, ja. De kosten van RAG zijn per query (embeddings plus extra input-tokens), terwijl fine-tuning eenmalig rekent voor training en gelabelde data, en dan vernieuwt bij elke hertraining. Op openbare lijstprijzen valt de break-even rond de 6,4 miljoen queries in ons uitgewerkte voorbeeld, dus bij typische volumes blijft RAG goedkoper voor de levensduur van het product.

Is RAG beter dan fine-tuning voor hallucinaties?

Meestal, maar niet gratis. RAG grondt antwoorden in opgehaalde chunks, zodat je bronnen kunt citeren en fouten kunt auditen. Slechte retrieval vergiftigt echter het antwoord: Anthropic mat een 5,7% top-20 retrieval-faalpercentage op gewone opstellingen, teruggebracht naar 1,9% met contextuele retrieval plus reranking. Fine-tuning kan ondertussen fouten in de gewichten bakken zonder manier om ze te traceren.

RAG vs fine-tuning vs prompt engineering: wat is het verschil?

Prompt engineering verandert de instructies die je stuurt. RAG verandert de context die het model leest op query-tijd. Fine-tuning verandert de gewichten van het model. Elk is een grotere ingreep dan de vorige: probeer eerst prompts, voeg retrieval toe wanneer kennis de bottleneck is, en train pas wanneer formaat, toon of latency nog steeds pijn doet.

Hoe evalueer je RAG vs fine-tuning prestaties?

Bouw een apart gehouden set van 100-300 echte gebruikersvragen en score beide aanpakken erop: faithfulness (is het gegrond?), antwoordcorrectheid (klopt het?), p95 latency en kosten per 1.000 queries. Herhaal de set telkens wanneer je documenten of model-snapshot veranderen. Synthetische vragen vleien beide systemen; echte vragen onderscheiden ze.

Fine-tuning vs RAG voor multi-hop vragen over nieuwe kennis?

RAG, met betere retrieval. Het mechanisme beslist deze: een fine-tuned model kan alleen redeneren over wat zijn gewichten geabsorbeerd hebben, dus kennis die het nooit gezien heeft is onbereikbaar, hoe goed het ook getraind is. Retrieval overhandigt de ontbrekende stukken op query-tijd. De valkuil is dat één retrieval-ronde zelden elke hop verzamelt, dus plan voor query-decompositie of iteratieve retrieval plus een reranker, niet een enkele top-K lookup.

Conclusie

De samenvatting, zonder het hedgen:

• RAG is de standaard voor veranderende kennis en geciteerde antwoorden. Fine-tuning is de specialist voor formaat, toon en latency.
• Het bewijs op dezelfde taak (Balaguer et al.) geeft fine-tuning +6 p.p. en RAG nog +5 p.p. erbovenop, met de hybride als beste van de drie. Ons begin-met-RAG-advies rust op versheid, citaties en kosten, niet op dat scorebord.
• De kostenrekensom valt in RAG's voordeel bij realistische volumes: break-even lag rond de 6,4 miljoen queries in ons uitgewerkte voorbeeld.
• Beslis met de vijf checks, niet met gewoonte.

RAG gekozen? Zie onze gerangschikte RAG-tooling-lijst voor de stack rond de pijplijn.