RAG versus fine-tuning: wat heeft jouw product nodig?

Deze keuze wordt verrassend vaak achterstevoren gemaakt. Fine-tuning klinkt als de serieuze engineeringoptie (je traint tenslotte een model) en retrieval als een omweg. In de praktijk is het voor de meeste productfeatures precies andersom.

Wat verandert elk van de twee écht?

Retrieval-augmented generation verandert wat het model kan zien. Op het moment van de request zoek je in je eigen data, zet je de relevante passages in de prompt, en vraag je het model daaruit te antwoorden. De gewichten van het model blijven onaangeroerd. In de kern is het een zoekprobleem met een taalmodel aan het eind.

Fine-tuning verandert hoe het model zich gedraagt. Je laat het een paar honderd of een paar duizend voorbeelden van input en gewenste output zien, en het schuift zijn gewichten naar dat patroon. Het leert vorm: de structuur van jouw output, jouw toon, de onderscheidingen die jouw domein belangrijk vindt.

Het onderscheid dat telt: retrieval voegt kennis toe, fine-tuning voegt gedrag toe. Bijna elke klacht “de AI kent ons bedrijf niet” is een kennisprobleem, en kennisproblemen reageren niet op fine-tuning.

Waarom retrieval de standaard is

Jouw data verandert. Een klant past een adres aan, een beleid wordt herzien, een document wordt vervangen. Met retrieval pikt de volgende request de nieuwe versie op, omdat die uit de bron leest. Met een fine-tuned model zit het oude feit in de gewichten tot je opnieuw traint.

Retrieval laat je ook je bronnen tonen, en dat doet meer voor vertrouwen dan welke nauwkeurigheidswinst dan ook. Een gebruiker die drie passages en een samenvatting ziet, kan het antwoord zelf controleren. Een gebruiker die een zelfverzekerde alinea uit het niets krijgt, moet het slikken of laten.

En permissies werken. Retrieval volgt de toegangsregels die al in je applicatie zitten, omdat jouw query de context ophaalt. Een fine-tuned model dat op alles is getraind, weet alles, en kun je voor één gebruiker niet laten vergeten. Dat is een complianceprobleem dat nog ontdekt moet worden.

Wanneer fine-tuning écht zijn plek verdient

Er zijn echte gevallen, en die hebben dezelfde vorm: het gedrag dat je wilt is lastig in woorden te vangen, maar makkelijk te laten zien.

Starre outputformats. Als elk antwoord een bepaalde structuur moet hebben en prompting je tot 95% compliance brengt, brengt fine-tuning je dichterbij, op een kleiner en goedkoper model.

Domeinclassificatie. Supporttickets sorteren in jouw eigen tweeëntwintig categorieën, waarvan de grenzen institutionele kennis zijn en geen definitie. Een paar duizend historische voorbeelden leren dat beter dan welke prompt ook.

Stem, consistent. Een specifiek register, volgehouden over duizenden outputs, zonder een stijlprompt van 600 woorden aan elke call.

Kosten en latentie op volume. Een fine-tuned klein model dat de prestatie van een groot model evenaart op jouw ene smalle taak, voor een fractie van de prijs per call. Dat is een echte en onderbenutte reden, maar het is een optimalisatie, en die komt nadat iets werkt.

Hoe je concreet kiest

Vraag hoe een fout eruitziet.

Als de fout is “dat is niet waar”, “dat is verouderd” of “hij weet niks van onze klant”: retrieval. Elke keer.

Als de fout is “dat klopt, maar het format is fout”, “hij blijft twijfelen terwijl we een besluit nodig hebben”, of “hij zette dit in de verkeerde categorie en een mens zou dat niet gedaan hebben”: fine-tuning ligt op tafel, zodra je de voorbeelden hebt die bewijzen dat het patroon consistent is.

Als de fout is “het is te traag” of “het kost te veel”, kijk dan eerst naar de grootte van je context. Teams sturen routinematig veel meer opgehaalde tekst mee dan het antwoord nodig heeft, en dat inkorten is een middag werk in plaats van een trainingspipeline.

De volgorde waarin je bouwt

Eerst retrieval, altijd, omdat dat antwoorden correct maakt en correctheid het enige is dat je niet kunt veinzen. Krijg de nauwkeurigheid waar je die nodig hebt, tegen een echte evalset. Pas daarna, als de resterende klachten over vorm gaan en niet over feiten, overweeg fine-tuning, en hergebruik diezelfde evalset om te bewijzen dat het getunede model écht beter is, niet alleen anders.

De teams die dit omdraaien besteden een maand aan een trainingsdataset, shippen een model dat prachtig geformatteerde foute antwoorden schrijft, en concluderen dat AI niet klaar is voor hun domein. Dat was het meestal wel. De kennis kwam alleen nooit in de prompt.