Het korte antwoord
Wil je dat een taalmodel antwoordt vanuit de documenten, data of het beleid van je organisatie, dan heb je bijna altijd retrieval-augmented generation (RAG) nodig. Wil je dat een model zich anders gedraagt, dan kan fine-tuning helpen. Denk aan een strikt outputformaat volgen, schrijven in een huisstijl of goedkoop een smalle classificatietaak uitvoeren. Veel teams kiezen eerst voor fine-tuning, omdat het klinkt alsof je het model alles over je bedrijf leert. Daarna merken ze dat het slecht met feiten omgaat.
Dit artikel is voor business- en productleiders die beslissen hoe ze een LLM aanpassen, en voor engineers die de afweging moeten uitleggen. We behandelen wat elke aanpak doet, een beslistabel, wanneer je ze combineert en wat elke aanpak kost om te draaien.
Wat RAG en fine-tuning elk doen
RAG laat het model ongewijzigd. Op het moment van de vraag doorzoekt je systeem je documenten, zet de meest relevante passages in de prompt en vraagt het model om daaruit te antwoorden. Pas je een document aan, dan zie je dat terug in het volgende antwoord. Elk antwoord kan zijn bron noemen, en je kunt tijdens het zoeken per gebruiker toegangsbeheer toepassen.
Fine-tuning verandert de gewichten van het model door het verder te trainen op voorbeelden van inputs en gewenste outputs. Het model neemt patronen over: opmaak, toon, terminologie en de manier waarop het een type taak aanpakt. Het leert feiten niet betrouwbaar op een manier die je kunt bijwerken, citeren of afschermen. Wat het wel opneemt, ligt vast op het moment van trainen.
Een handige manier om erover na te denken:
- RAG verandert wat het model weet op het moment dat het antwoordt.
- Fine-tuning verandert hoe het model meestal reageert.
- Prompting, met duidelijke instructies en voorbeelden, verschuift allebei een beetje en kost het minst. Probeer dat eerst.
Een beslistabel
| Wat je nodig hebt | RAG | Fine-tuning |
|---|---|---|
| Antwoorden uit interne documenten, beleid of productdata | Past goed | Past slecht |
| Inhoud verandert wekelijks of dagelijks | Past goed: indexeer opnieuw wat is gewijzigd | Past slecht: vraagt om opnieuw trainen |
| Antwoorden moeten bronnen noemen | Past goed | Geen ingebouwde ondersteuning |
| Verschillende gebruikers mogen verschillende inhoud zien | Past goed: filter bij het ophalen | Geen ingebouwde ondersteuning |
| Strikt outputformaat of huisstijl | Meestal haalbaar met prompting | Past goed als prompting niet genoeg is |
| Smalle taak met veel volume, zoals classificatie | Voegt weinig toe | Past goed: een kleiner getraind model kan goedkoper en sneller zijn |
| Vakjargon waar het basismodel slecht mee omgaat | Helpt door definities in de context te zetten | Kan helpen, met genoeg goede voorbeelden |
Bij de meeste zakelijke toepassingen, zoals interne kennisassistenten, klantenservice, beleidscontroles en vragen over documenten, wegen de bovenste rijen van de tabel het zwaarst. Daarom is RAG ons standaard startpunt. Fine-tuning overwegen we later, om specifieke redenen die we kunnen meten.
Wanneer je RAG en fine-tuning combineert
De twee aanpakken werken samen. Combineren is zinvol als de retrieval al werkt en er een meetbaar probleem met het gedrag overblijft. Bijvoorbeeld:
- Een supportassistent vindt de juiste artikelen, maar de antwoorden moeten een strikte structuur volgen die het model met prompting niet consequent aanhoudt.
- Een pipeline met veel volume classificeert documenten vóór de retrieval, en een klein gefinetuned model doet die stap voor een fractie van de kosten van een groot algemeen model.
- Een embeddingmodel of reranker wordt gefinetuned op paren van je eigen zoekvragen en documenten, zodat de retrieval je terminologie beter begrijpt.
Die laatste optie wordt vaak over het hoofd gezien. Fine-tuning van de retrieval-onderdelen kan een RAG-systeem meer verbeteren dan fine-tuning van het model dat de antwoorden schrijft, omdat de kwaliteit van de retrieval het plafond voor de antwoordkwaliteit bepaalt. Onze gids over embeddings en semantisch zoeken behandelt die kant.
Kosten en onderhoud
De bouwkosten zijn maar een deel van het verhaal. Over een paar jaar telt vooral hoeveel moeite het kost om elke aanpak correct te houden.
| Kostenpost | RAG | Fine-tuning |
|---|---|---|
| Werk vooraf | Inlezen, chunking, zoeken, bronvermelding en rechten | Honderden tot duizenden gelabelde voorbeelden verzamelen en opschonen, plus trainingsruns |
| Inhoud actueel houden | Incrementeel opnieuw indexeren, grotendeels automatisch | De dataset opnieuw opbouwen en opnieuw trainen |
| Modelupgrades | Wissel het model en draai de evaluaties opnieuw | Opnieuw trainen op het nieuwe basismodel, of op het oude blijven |
| Kosten van draaien | Zoekinfrastructuur en langere prompts | Hosting of prijs per token voor het getrainde model |
| Debuggen | Bekijk de opgehaalde passages om te zien waar een antwoord vandaan komt | Lastiger, omdat het gedrag over de gewichten verspreid zit |
Let vooral op de rij over modelupgrades. Algemene modellen worden snel beter, en een RAG-systeem kan meestal een beter model gebruiken door de configuratie aan te passen en de testset opnieuw te draaien. Een gefinetuned model bindt je aan zijn basismodel, tot je investeert in opnieuw trainen.
Beide aanpakken hebben na de livegang een eigenaar nodig. Bij RAG houdt die de jobs voor het inlezen in de gaten, bekijkt mislukte vragen en houdt de testset actueel. Bij fine-tuning verzamelt die nieuwe trainingsvoorbeelden als de taak verschuift, en beslist wanneer opnieuw trainen de moeite waard is.
Een praktische beslisgids
- 01Schrijf het probleem op als uitkomsten: welke vragen of taken, voor wie, en hoe je een goed antwoord beoordeelt.
- 02Probeer goede prompting met een sterk algemeen model en een kleine testset, en meet.
- 03Hebben antwoorden jouw kennis nodig, bouw dan RAG en meet retrieval en antwoorden apart, zoals beschreven in hoe je RAG evalueert.
- 04Faalt een specifiek gedrag daarna nog steeds en kun je goede voorbeelden verzamelen, fine-tune dan voor dat gedrag en vergelijk de resultaten op dezelfde testset.
- 05Bekijk het besluit opnieuw als basismodellen veranderen. Wat vorig jaar fine-tuning nodig had, heeft dat nu misschien niet meer nodig.
Als we AI-werk met klanten afbakenen, volgen we deze volgorde, en de meeste projecten eindigen met RAG en goede evaluaties. Onze gids voor een RAG-chatbot in productie gaat dieper in op het bouwen, en je kunt een gesprek plannen om je eigen situatie door te nemen.