RAG of fine-tuning? Wat echte klantprojecten ons leerden over de keuze

Bijna elk gesprek over AI in het bedrijfsleven komt binnen het eerste uur op hetzelfde keuzemoment uit. De klant heeft een groot taalmodel dat in een demo indrukwekkend is, maar niets weet over diens producten, beleid of schrijfstijl. Iemand in de ruimte vraagt: moeten we het model fine-tunen met onze gegevens, of er retrieval-augmented generation (RAG) omheen bouwen?

Het eerlijke antwoord is dat de vraag meestal verkeerd wordt gesteld. RAG en fine-tuning lossen verschillende problemen op. Teams die ze als concurrerende opties beschouwen, besteden vaak maanden en een flink GPU-budget aan het oplossen van het verkeerde probleem. Zo maken we in de praktijk onze keuze, en dit hebben we goed en fout zien gaan.

Begin met wat het model mist

Wanneer een model een slecht antwoord geeft op een zakelijke taak, ontbreekt het aan een van twee dingen.

Het mist kennis. Het kent je meest recente prijslijst niet, noch de clausule in je leverancierscontract uit 2025 of de stappen voor probleemoplossing van een product dat vorige maand op de markt is gekomen. Dit is een feitenprobleem.

Het mist bepaald gedrag. Het weet genoeg, maar reageert niet zoals jij nodig hebt. Het houdt zich niet aan het gewenste uitvoerformaat, schrijft in de verkeerde toon, interpreteert je interne codes verkeerd of kan een afgebakende, terugkerende taak niet uitvoeren, zoals tickets indelen in je 40 categorieën. Dit is een vaardigheidsprobleem.

RAG is geschikt voor het eerste probleem. Fine-tuning is geschikt voor het tweede. De meeste verwarring die ik zie, ontstaat doordat mensen feiten met fine-tuning proberen aan te leren.

Waarom fine-tuning een slechte manier is om kennis toe te voegen

Het is verleidelijk te denken dat een model je documenten zal ‘kennen’ als je het ermee traint. In de praktijk leert het de stijl van die documenten veel betrouwbaarder dan de feiten die erin staan. Onderzoekers van Microsoft vergeleken de twee benaderingen rechtstreeks voor kennisintensieve vragen en ontdekten dat RAG consequent beter presteerde dan onbegeleide fine-tuning, zowel voor feiten die het model tijdens de training had gezien als voor geheel nieuwe feiten.

Er zijn ook praktische problemen. Feiten veranderen. Elke keer dat je beleid of catalogus verandert, is een gefinetuned model verouderd totdat je het opnieuw traint. Ook verlies je de traceerbaarheid: wanneer een gefinetuned model een getal noemt, kun je niet verwijzen naar het document waar dat vandaan komt. Voor klanten in gereguleerde sectoren zoals verzekeringen en gezondheidszorg is dat meestal al genoeg om de discussie te beëindigen.

RAG, voor het eerst beschreven in het artikel uit 2020 van Lewis et al., houdt kennis buiten het model. Op het moment dat iemand een vraag stelt, haal je de relevante passages op en geef je die als context aan het model. Om kennis bij te werken, hoef je alleen een index bij te werken; opnieuw trainen is niet nodig. Bovendien kan elk antwoord naar de bron verwijzen.

Een logistieke klant van ons is een goed voorbeeld. Diens klanten wilden direct antwoord op de vraag waar hun zendingen zich bevonden en welke documenten ontbraken. Die informatie verandert elke paar minuten. Hoeveel training je een model ook geeft, het zou daardoor niet actueel blijven. Daarom beantwoordt de assistent die we hebben gebouwd vragen op basis van actuele tracking- en IoT-gegevens, in plaats van uit het geheugen. Alleen met retrieval kon dit ontwerp werken.

Wanneer fine-tuning wel van pas komt

Fine-tuning is niet achterhaald. Het toepassingsgebied is alleen beperkter dan mensen verwachten. We zetten het in drie situaties in:

• Strikte, terugkerende uitvoerformaten. Wanneer een model duizenden keren per dag dezelfde gestructureerde uitvoer moet produceren, bijvoorbeeld door gegevens uit facturen te halen en in een vast JSON-schema te zetten, is een gefinetuned klein model vaak betrouwbaarder en veel goedkoper dan een groot model via prompts aan te sturen.
• Vaktaal. In sommige vakgebieden komen afkortingen voor die het basismodel verkeerd interpreteert. Veelvoorkomende voorbeelden zijn statuscodes in de logistiek, klinische afkortingen en interne productcodes. Een beperkte fine-tuning kan dit verhelpen.
• Kosten en latency op grote schaal. Zodra een taak goed is afgebakend, kan een gefinetuned klein model een groot algemeen model vervangen. Methoden zoals LoRA maken dit betaalbaar, omdat je een kleine set extra gewichten traint in plaats van het hele model.

Let op: geen van deze toepassingen draait om feiten. Ze gaan over een model leren hoe het zich moet gedragen bij een taak die je al goed begrijpt.

De meeste problemen met RAG zijn problemen met het ophalen van informatie

Wanneer een team me vertelt: ‘We hebben RAG geprobeerd, maar het werkte niet’, ligt het probleem zelden bij het model. Het zit in de stap waarin informatie wordt opgehaald. De kwaliteit van het model kan nooit beter zijn dan die van de passages die het krijgt aangereikt.

De oplossingen zijn niet spectaculair, maar wel effectief:

• Verdeel tekst op basis van betekenis, niet op basis van het aantal tekens. Als je een contract elke 500 tekens opknipt, worden clausules doormidden gesneden. Door tekst op te delen aan de hand van secties en koppen blijft de context intact.
• Voeg context toe aan elk tekstfragment. Een fragment met de tekst ‘de limiet is 30 dagen’ is nutteloos als je niet weet bij welk beleid het hoort. Anthropic meldde dat het toevoegen van een korte documentcontext aan elk fragment vóór indexering — een aanpak die het contextuele informatieophaling noemt — het aantal mislukte zoekopdrachten met 49% verminderde, en met 67% wanneer dit werd gecombineerd met herordening van de resultaten.
• Combineer zoeken op trefwoorden met vectorzoeken. Vectorzoeken is goed in het vinden van informatie op basis van betekenis, maar minder geschikt voor exacte termen zoals onderdeelnummers. Hybride zoeken combineert beide.
• Test de informatieophaling afzonderlijk. Stel een reeks echte vragen samen waarvoor de juiste bronpassages bekend zijn, en meet of de juiste passage bij de eerste resultaten staat voordat je de uiteindelijke antwoorden beoordeelt.

Wanneer gebruik je beide?

In productie combineren de sterkste systemen vaak beide. RAG levert de feiten. Een licht gefinetuned model verzorgt de vorm, toon en domeinspecifieke taal. Ook onderzoek gaat die kant op: de RAFT-aanpak van UC Berkeley finetunet een model specifiek om opgehaalde documenten beter te benutten en irrelevante documenten te negeren.

Maar de volgorde is belangrijk. We bouwen bijna altijd eerst RAG, meten waar het tekortschiet en bepalen pas daarna of finetuning de moeite waard is. Als je begint met finetuning, betaal je voor training voordat je weet waar het probleem werkelijk zit.

Een eenvoudige checklist om een keuze te maken

1. Is de taak afhankelijk van feiten die vaker dan eens per kwartaal veranderen? Gebruik RAG.
2. Moeten gebruikers of auditors kunnen zien waar een antwoord vandaan komt? Gebruik RAG.
3. Ligt het probleem bij de vorm, toon of woordenschat van de antwoorden, en niet bij de feiten? Overweeg finetuning.
4. Gaat het om een afgebakende taak die op grote schaal wordt uitgevoerd, waarbij kosten of snelheid belangrijk zijn? Overweeg dan een kleiner model te finetunen.
5. Heb je de kwaliteit van de informatieophaling afzonderlijk gemeten? Zo niet, doe dat dan eerst.

De belangrijkste les

RAG en finetuning zijn geen tegenpolen. Het ene geeft een model de juiste informatie, het andere bepaalt hoe het zich gedraagt. Bepaal goed welk probleem je daadwerkelijk hebt, verbeter de informatieophaling voordat je het model de schuld geeft, en beschouw finetuning als een optimalisatie die je pas inzet als het systeem werkt, niet als een kortere weg om het aan de praat te krijgen.