RAG vs fine-tuning: wat bedrijven echt nodig hebben

Bijna elk AI-project dat we met klanten bespreken begint met dezelfde vraag: ‘Moeten we een model fine-tunen op onze data?’ Soms is het antwoord ja. Vaker is de werkelijke behoefte iets anders: een assistent die je actuele documenten kent, zijn bronnen vermeldt en op een dinsdagmiddag kan worden bijgewerkt zonder trainingsrun. Dit artikel legt de belangrijkste opties in gewone taal uit, wanneer welke past, en hoe je kiest zonder maanden te verbranden aan de verkeerde aanpak.

De vier gereedschappen in de kist#

Als mensen zeggen ‘leer het model hoe ons bedrijf werkt’, bedoelen ze meestal een van vier verschillende technieken. Ze lossen verschillende problemen op en je kunt ze combineren.

Retrieval-augmented generation (RAG)#

RAG laat het model ongewijzigd. In plaats daarvan doorzoekt het systeem bij een binnenkomende vraag eerst je eigen content, zoals handleidingen, contracten, tickets of een productcatalogus, en geeft het de meest relevante passages samen met de vraag door aan het model. Het model antwoordt vervolgens op basis van die passages.

Drie ideeën zijn hier van belang:

• Retrieval: de juiste passages vinden. Meestal is dat een mix van semantisch zoeken over embeddings en klassiek zoeken op trefwoorden, vaak gevolgd door een rerankingstap.
• Grounding: het model opdragen te antwoorden vanuit het aangeleverde materiaal, en het te zeggen wanneer het antwoord daar niet in staat.
• Bronvermelding: verwijzen naar het exacte document, de pagina of de passage waar een antwoord vandaan komt, zodat een mens het kan controleren.

RAG komt tot zijn recht als kennis vaak verandert, als het corpus groot is en als mensen antwoorden moeten kunnen verifiëren.

Fine-tuning#

Bij fine-tuning train je een model verder op je eigen voorbeelden, zodat zijn gedrag verschuift. Het is goed in aanleren hoe er geantwoord moet worden: een consistente toon, een strikt outputformaat, een domeinspecifiek classificatieschema of een smalle taak die duizenden keren per dag wordt uitgevoerd. Het is een slechte manier om aan te leren wat er op dit moment waar is. Feiten die via fine-tuning zijn geleerd, zijn lastig bij te werken, lastig naar een bron te herleiden en kunnen door elkaar lopen of verkeerd worden onthouden.

Met fine-tuning kun je een smalle taak ook naar een kleiner, goedkoper en sneller model verplaatsen, wat bij hoge volumes veel kan uitmaken.

Long-context prompting met prompt caching#

Moderne modellen van Anthropic, OpenAI en verschillende open-sourcefamilies accepteren zeer lange inputs. Als je kennisbank bescheiden van omvang is, bijvoorbeeld een producthandboek, een set beleidsdocumenten of een set FAQ's, kun je die vaak in haar geheel direct in de prompt zetten. Geen index, geen retrievalpipeline, geen beslissingen over chunking.

Het voor de hand liggende bezwaar is kosten en latency: bij elke request hetzelfde grote document meesturen is verspilling. Prompt caching lost dat op. Providers kunnen een stabiele prefix van de prompt cachen, zodat herhaalde requests de al verwerkte content hergebruiken en efficiënter worden afgerekend en afgehandeld. Voor een stabiele, afgebakende hoeveelheid kennis is een lange context met caching vaak het eenvoudigste dat werkt.

Structured outputs#

Veel ‘AI’-projecten zijn eigenlijk extractieprojecten: lees een factuur, een cv, een contract of een e-mail en lever schone velden op. De cruciale capaciteit is hier structured outputs, waarbij het model wordt gedwongen data terug te geven die voldoet aan een schema dat jij definieert, bijvoorbeeld JSON met specifieke velden en types. Dit gaat helemaal niet over kennis. Het gaat over betrouwbaarheid van het formaat, en het maakt fine-tuning bij extractietaken meestal overbodig.

Wanneer welke aanpak past#

Een nuttige manier om ernaar te kijken: scheid kennis van gedrag.

• Verse of veranderende kennis, en antwoorden die mensen moeten verifiëren: gebruik RAG, of een lange context als het materiaal klein genoeg is. Bij beide werk je kennis bij door documenten bij te werken, en beide ondersteunen bronvermelding.
• Stabiele, afgebakende kennis die in het contextvenster past: begin met een lange context en prompt caching. Stap over op RAG wanneer het materiaal eruit groeit of wanneer je fijnmazige toegangscontrole per document nodig hebt.
• Consistente stijl, toon of vorm over veel outputs: probeer eerst duidelijke instructies en een paar goede voorbeelden in de prompt. Als dat bij jouw volume niet genoeg is, is fine-tuning een legitieme optie.
• Smalle classificatie of routing op grote schaal: een kleiner model fine-tunen, of simpelweg een kleiner algemeen model gebruiken met een goed ontworpen prompt, is vaak de voordeligste weg.
• Extractie van velden uit documenten: structured outputs, eventueel gecombineerd met documentinputs en bronvermelding, zodat elke geëxtraheerde waarde te herleiden is.

Deze opties sluiten elkaar niet uit. Een volwassen systeem kan RAG gebruiken voor kennis, structured outputs voor het antwoordformaat en een klein gefinetuned model om binnenkomende requests te routeren.

Vergelijking naast elkaar#

Een praktische beslischecklist#

Beantwoord deze vragen eerlijk voordat je een architectuur kiest:

1. Wat is de taak precies? Vragen beantwoorden, tekst opstellen, classificeren of extraheren? Schrijf vijf echte voorbeelden van input en ideale output op.
2. Hoe vaak verandert de onderliggende kennis? Dagelijkse of wekelijkse wijzigingen wijzen sterk weg van fine-tuning.
3. Moeten gebruikers antwoorden kunnen verifiëren? In juridische, financiële, compliance-, support- of zorgcontexten is bronvermelding meestal niet onderhandelbaar.
4. Hoe groot is de kennisbank? Als die ruim in een contextvenster past, probeer dan eerst een lange context met caching.
5. Wie mag wat zien? Als verschillende gebruikers toegang hebben tot verschillende documenten, heb je retrieval met filtering op rechten nodig, niet één gedeelde prompt of een model dat op alles is getraind.
6. Welk volume en welke latency verwacht je? Een hoog volume op een smalle taak is waar kleinere of gefinetunede modellen zichzelf terugverdienen.
7. Heb je gelabelde voorbeelden? Fine-tuning zonder een flinke set goede voorbeelden wint zelden van een goed geschreven prompt.
8. Hoe ga je succes meten? Als je hier geen antwoord op hebt, stop dan en bouw eerst een evaluatieset.

Wijzen de meeste antwoorden op ‘veranderende kennis, bronvermelding nodig, gemiddeld volume’, dan wil je RAG of een lange context. Wijzen ze op ‘stabiele taak, strikt formaat, zeer hoog volume’, overweeg dan fine-tuning of een kleiner model.

Veelvoorkomende valkuilen#

Dit zijn de problemen die we het vaakst zien bij het reviewen van AI-systemen die ‘bijna werken’.

• Slechte chunking. Documenten in willekeurige stukken van vaste grootte knippen hakt tabellen doormidden, scheidt koppen van hun inhoud en verliest context. Chunk langs de structuur van het document en bewaar nuttige metadata zoals titel, sectie en datum.
• Geen evaluaties. Zonder testset is elke wijziging een gok. Teams sleutelen aan prompts, wisselen modellen en veranderen chunkgroottes zonder te weten of het beter of slechter is geworden.
• Verouderde indexen. De brondocumenten zijn bijgewerkt, de index niet. De assistent citeert vol zelfvertrouwen het beleid van vorig jaar. Herindexeren moet onderdeel zijn van de contentworkflow, geen handmatige bijzaak achteraf.
• Hallucinatie zonder bronvermelding. Als het systeem niet laat zien waar een antwoord vandaan komt, kunnen gebruikers een onderbouwd antwoord niet onderscheiden van een verzonnen antwoord. Eis bronvermelding en leer het model ‘dat weet ik niet’ te zeggen als de bronnen zwijgen.
• Privacy en AVG. Persoonsgegevens in documenten, prompts en logs blijven persoonsgegevens. Weet welke provider ze verwerkt, in welke regio, onder welke verwerkersovereenkomst en hoelang logs worden bewaard. Fine-tuning op persoonsgegevens verdient extra voorzichtigheid, omdat ze er later weer uit halen moeilijk is.
• Prompt injection vanuit documenten. Opgehaalde content is onvertrouwde input. Een document kan tekst bevatten die het model probeert te instrueren, bijvoorbeeld om zijn regels te negeren of andere data prijs te geven. Behandel opgehaalde tekst als data, beperk wat het model met tools kan doen en laat de inhoud van een document nooit rechten toekennen.

Eerst evalueren, dan optimaliseren#

De meest waardevolle stap in elk AI-project is ook de minst glamoureuze: bouw een evaluatieset voordat je een architectuur kiest.

Een goede startset is simpelweg een paar dozijn tot een paar honderd echte vragen of inputs, elk met het verwachte antwoord of de documenten die geciteerd zouden moeten worden. Meet daarna:

• Kwaliteit van de retrieval: heeft het systeem de juiste passages gevonden?
• Kwaliteit van het antwoord: is het antwoord correct, volledig en onderbouwd met de bronnen?
• Nauwkeurigheid van de bronvermelding: onderbouwen de geciteerde passages de bewering ook echt?
• Weigergedrag: zegt het systeem ‘dat weet ik niet’ wanneer dat zou moeten?
• Naleving van het formaat: voldoet bij extractie elke output aan het schema?

Als dit staat, worden vergelijkingen feitelijk. Je kunt een lange context testen tegen RAG, het ene model tegen het andere, of een gefinetuned model tegen een model met alleen een prompt, op je eigen data in plaats van op generieke benchmarks. Vaak blijkt de goedkoopste oplossing betere retrieval of een duidelijkere prompt te zijn, niet een groter model of een trainingsrun.

Automatisch beoordelen met een model kan dit versnellen, maar controleer het steekproefsgewijs met menselijke reviewers, zeker in het begin.

Hoe onze eigen demo's de patronen laten zien#

We proberen zelf te doen wat we aanraden, en twee demo's op deze site laten de patronen in actie zien.

De sigmacode Assistant beantwoordt vragen over onze diensten en onze aanpak. De kennisbank is klein en bewust bevroren, dus in plaats van een retrievalpipeline gebruikt hij long-context prompting met prompt caching: de hele kennisbank staat in een gecachte promptprefix, en het model heeft de instructie om alleen daaruit te antwoorden. Voor een afgebakende hoeveelheid kennis is dat eenvoudiger te bouwen en makkelijker correct te houden dan een vectorindex.

De demo Document-Q&A met bronvermelding laat de andere kant zien. Je levert een document aan, stelt vragen, en elk antwoord komt met bronvermeldingen die verwijzen naar de passages waarop het steunt. Dat is de kernbelofte van grounded AI: elke bewering is te controleren aan de hand van haar bron.

Voor geen van beide demo's was fine-tuning nodig. Dat is typerend. Bij de meeste kennisproblemen van bedrijven doen grounding en goede evaluatie er meer toe dan training op maat.

De korte versie#

• Gebruik RAG als de kennis omvangrijk is, vaak verandert, toegangscontrole vraagt of van een bron moet worden voorzien.
• Gebruik een lange context met prompt caching als de kennis stabiel is en in het venster past.
• Gebruik fine-tuning of kleinere modellen voor consistent gedrag of smalle taken op hoog volume, niet voor feiten.
• Gebruik structured outputs voor extractie en voor elke output die een systeem moet parsen.
• Evalueer eerst en optimaliseer daarna wat de cijfers aanwijzen.

Weeg je deze opties af voor een echt project, dan kan ons team voor AI & automatisering, geleid door een tech lead met meer dan 20 jaar ervaring, je helpen de scope te bepalen, een evaluatieset te bouwen en een eerste versie op te leveren die je ook echt kunt meten. Neem contact op en vertel ons wat je probeert op te lossen.