RAG vs fine-tuning voor domeinspecifieke chatbots: hoe te kiezen

Welk probleem lossen we met een domeinspecifieke chatbot?\n\nEen domeinspecifieke chatbot beantwoordt vragen met behulp van de kennis van jouw organisatie, niet algemene internetfeiten. Denk aan HR-beleid, producthandleidingen, prijsregels, supportplaybooks, SOP's en interne how-to-gidsen.\n\nDe meeste teams proberen het model niet “alles te leren”. Ze willen snellere, consistente antwoorden op alledaagse vragen zoals “Wat is onze terugbetalingsregel voor jaarabonnementen?” of “Welk formulier gebruik ik voor een leverancieraanvraag?” zonder door mappen en PDF's te hoeven graven.\n\nHet moeilijke is vertrouwen. Een algemeen model kan zelfverzekerd klinken ook als het fout zit. Als je beleid “7 werkdagen” zegt en het model antwoordt “10 kalenderdagen”, kan het antwoord er mooi uitzien en toch schade veroorzaken: verkeerde goedkeuringen, foutieve klantreacties of complianceproblemen.\n\nHoe vaak je documenten veranderen is net zo belangrijk als nauwkeurigheid. Als documenten wekelijks worden bijgewerkt, moet de chatbot nieuwe tekst snel en betrouwbaar weerspiegelen, anders wordt hij een bron van verouderde richtlijnen. Als documenten jaarlijks veranderen kun je langzamere updates toestaan, maar de chatbot moet nog steeds kloppen omdat mensen erop vertrouwen.\n\nBij het vergelijken van RAG en fine-tuning voor domeinspecifieke chatbots is het doel praktisch: behulpzame antwoorden gebaseerd op jouw documenten, met duidelijke bronnen of citaten, en een veilige reactie wanneer de chatbot het niet zeker weet.\n\nEen goede probleemstelling bestrijkt vijf dingen: welke documenten de bot mag gebruiken (en welke hij moet vermijden), de meest voorkomende vraagtypen, hoe een “goed” antwoord eruitziet (juist, kort, inclusief bron), hoe een “slecht” antwoord eruitziet (zelfverzekerde gissingen, verouderde regels) en wat te doen als bewijs ontbreekt (stel een vervolgvraag of zeg dat het niet weet).\n\n## RAG en fine-tuning in gewone taal\n\nRAG en fine-tuning zijn twee verschillende manieren om een chatbot goed te laten functioneren op het werk.\n\nRetrieval augmented generation (RAG) is alsof je de chatbot een openboekexamen geeft. Wanneer een gebruiker een vraag stelt zoekt het systeem in jouw documenten (beleid, handleidingen, tickets, FAQ). Het geeft dan de meest relevante fragmenten aan het model en instrueert het om die materialen te gebruiken bij het antwoorden. Het model memoriseert je documenten niet; het leest geselecteerde passages op het moment van antwoorden.\n\nFine-tuning is alsof je het model coacht met voorbeelden totdat het jouw gewenste gedrag leert. Je levert veel input-output-paren (vragen en ideale antwoorden, toon, opmaak, niet-te-zeggen regels). De gewichten van het model veranderen, zodat het consistenter reageert, zelfs wanneer geen document wordt meegegeven.\n\nEen simpel denkmodel:\n\n- RAG houdt kennis fris door uit je huidige documenten te halen.\n- Fine-tuning maakt gedrag consistent: stijl, regels en beslispatronen.\n\nBeide benaderingen kunnen falen, maar op verschillende manieren.\n\nBij RAG is de zwakke schakel retrieval. Als de zoekstap de verkeerde pagina haalt, verouderde tekst of te weinig context, kan het model nog steeds een zelfverzekerd antwoord geven, maar het is gebaseerd op slechte bewijsvoering.\n\nBij fine-tuning is de zwakke plek overgeneralisatie. Het model kan patronen uit trainingsvoorbeelden leren en die toepassen wanneer het juist een verduidelijkingsvraag had moeten stellen of “ik weet het niet” had moeten zeggen. Fine-tuning blijft ook niet bij met frequente doc-wijzigingen tenzij je blijft retrainen.\n\nEen concreet voorbeeld: als je reisbeleid verandert van “managergoedkeuring boven $500” naar “boven $300”, kan RAG hetzelfde dag nog correct antwoorden als het de bijgewerkte policy ophaalt. Een fijngetuned model kan blijven het oude nummer herhalen tenzij je het opnieuw traint en het nieuwe gedrag verifieert.\n\n## Welke past het beste bij vaak veranderende bedrijfsdocumenten?\n\nAls je documenten wekelijks (of dagelijks) veranderen, komt retrieval meestal beter overeen met de werkelijkheid dan training. Met retrieval augmented generation voor bedrijfsdocumenten houd je het model grotendeels hetzelfde en update je in plaats daarvan de kennisbasis. Zo kan de chatbot nieuw beleid, prijs- of productnotities reflecteren zodra de broninhoud verandert, zonder te wachten op een nieuwe trainingscyclus.\n\nFine-tuning kan werken wanneer de “waarheid” stabiel is: een consistente toon, een vaste set productregels of een smal taakgebied. Maar als je fine-tuned op inhoud die blijft bewegen, loop je het risico het antwoord van gisteren te leren. Frequent genoeg retrainen om bij te blijven wordt duur en is makkelijk fout te doen.\n\n### Governance: updates en eigenaarschap\n\nEen praktische vraag is wie verantwoordelijk is voor content-updates.\n\nBij RAG kunnen niet-technische teams een document publiceren of vervangen en pakt de bot het op na re-indexering. Veel teams voegen een goedkeuringsstap toe zodat alleen bepaalde rollen wijzigingen mogen doorvoeren.\n\nBij fine-tuning vereisen updates meestal een ML-workflow. Dat betekent vaak tickets, wachten en minder frequente vernieuwingen.\n\n### Compliance en audit\n\nWanneer mensen vragen “waarom zei de bot dat?”, heeft RAG een duidelijk voordeel: het kan de exacte passages tonen die het gebruikte. Dit helpt bij interne audits, supportreviews en gereguleerde onderwerpen.\n\nFine-tuning bakt informatie in gewichten, dus het is lastiger om voor een specifieke zin een specifieke bron aan te tonen.\n\nKosten en inspanning zien er ook anders uit:\n\n- RAG heeft upfront werk om documenten te verzamelen, te chunk-en, te indexeren en de ingestie betrouwbaar te houden.\n- Fine-tuning vereist voorbereidende arbeid om trainingsdata te maken en te evalueren, plus herhaalde training wanneer kennis verandert.\n- Als contentupdates frequent zijn, heeft RAG meestal lagere doorlopende kosten.\n\nVoorbeeld: een HR-chatbot die antwoordt vanuit beleid dat elk kwartaal verandert. Met RAG kan HR het beleids-PDF vervangen en begint de bot snel de nieuwe tekst te gebruiken, terwijl hij de alinea waarop hij zich baseerde nog steeds toont. AppMaster kan je helpen het admin-portaal te bouwen voor het uploaden van goedgekeurde docs en het loggen welke bronnen werden gebruikt, zonder de hele app vanaf nul te schrijven.\n\n## Wanneer gebruik je RAG, wanneer fine-tuning en wanneer combineer je ze?\n\nAls je doel betrouwbare antwoorden zijn die overeenkomen met wat je bedrijfsdocumenten vandaag zeggen, begin dan met retrieval augmented generation voor bedrijfsdocumenten. Het haalt relevante passages op het moment van de vraag, zodat de bot het exacte beleid, specificatie of SOP kan aanwijzen dat het antwoord onderbouwt.\n\nRAG is de betere standaardkeuze wanneer content vaak verandert, wanneer je moet tonen waar een antwoord vandaan komt, of wanneer verschillende teams verschillende documenten beheren. Als HR de verlofregels maandelijks bijwerkt, wil je dat de chatbot automatisch de nieuwste versie gebruikt, niet wat het weken geleden leerde.\n\nFine-tuning op bedrijfsdata heeft zin wanneer de documenten niet het grootste probleem zijn. Fine-tuning is het beste voor stabiel gedrag: een consistente stem, strikte opmaak (bijv. altijd in een template antwoorden), betere intentrouting of betrouwbare weigerregels. Zie het als het aanleren van hoe de assistent zich gedraagt, niet wat je laatste handboek zegt.\n\nCombineren komt veel voor: RAG levert de feiten en een kleine fine-tune (of sterke system-instructies) houdt de assistent consistent en voorzichtig. Dit past ook bij productteams die de chatbot in een app bouwen, waar UX en toon dezelfde moeten blijven terwijl kennis verandert.\n\nSnelle signalen om te kiezen:\n\n- Kies RAG wanneer antwoorden actueel moeten blijven, exacte bewoording moeten citeren of bronnen uit de nieuwste documenten moeten bevatten.\n- Kies fine-tuning wanneer je een vaste stijl, herhaalde outputformaten of strengere do/geen-do regels nodig hebt.\n- Combineer ze wanneer je document-onderbouwde antwoorden plus consistente toon en veilig weigergedrag wilt.\n- Herzie je plan als je constant aan het bijtunen bent om nieuwe documenten bij te houden, of als retrieval vaak faalt omdat content rommelig of slecht gechunked is.\n\nEen eenvoudige manier om de verkeerde aanpak te herkennen is onderhoudspijn. Als elke beleidsupdate een modelretrain-aanvraag triggert, gebruik je fine-tuning om een documentversheidsprobleem op te lossen. Als RAG de juiste pagina teruggeeft maar de bot nog steeds risicovol antwoordt, heb je waarschijnlijk betere guardrails nodig (soms helpt fine-tuning).\n\nAls je dit in een echt product bouwt (bijvoorbeeld in AppMaster), is een praktische aanpak eerst RAG, en voeg dan alleen fine-tuning toe voor gedrag dat je duidelijk kunt testen en meten.\n\n## Stapsgewijs: een betrouwbaar uitgangspunt opzetten (voordat je een model kiest)\n\nDe meeste chatbot-fouten komen door rommelige documenten en onduidelijke doelen, niet door het model.\n\nBegin met een documentinventaris: wat je hebt, waar het staat en wie wijzigingen kan goedkeuren. Leg het type en formaat vast (PDF's, wiki's, tickets, spreadsheets), de eigenaar en bron van waarheid, updatefrequentie, toegangsregels en waar duplicaten vaak voorkomen.\n\nDefinieer daarna de taak van de chatbot in eenvoudige termen. Kies 20 tot 50 echte vragen die hij goed moet beantwoorden (bijv. “Hoe vraag ik een terugbetaling aan?” of “Wat is de on-call-escalatie?”). Definieer ook wat hij moet weigeren, zoals juridisch advies, HR-beslissingen of alles buiten je goedgekeurde docs. Een weigering is een succes als het een fout antwoord voorkomt.\n\nMaak vervolgens de documenten schoon en structureer ze zodat antwoorden makkelijk te onderbouwen zijn. Verwijder duplicaten, houd één actuele versie bij en label oudere versies duidelijk. Voeg duidelijke titels, datums en sectiekoppen toe zodat de chatbot het exacte deel kan aanwijzen dat het antwoord ondersteunt. Als een beleid vaak verandert, houd dan één pagina up-to-date in plaats van veel kopieën.\n\nStel ten slotte een outputcontract op. Vereis een kort antwoord, een citaat naar de gebruikte bronsectie en een volgende actie indien nodig (bijv. “Open een ticket bij Finance”). Als je dit in een intern hulpmiddel bouwt met AppMaster, helpt het ook om de UI consistent te houden: antwoord eerst, dan het citaat, vervolgens de actieknop. Die structuur maakt problemen tijdens testen zichtbaar en vermindert later zelfverzekerde verkeerde antwoorden.\n\n## Hoe kwaliteit te evalueren zonder te gokken\n\nBegin met een kleine offline testset. Verzamel 30 tot 100 echte vragen die mensen al stellen in tickets, e-mails en chatthreads. Bewaar de originele formulering, neem een paar vage vragen op en een paar die makkelijk verkeerd gelezen worden. Dit geeft je een stabiele manier om RAG vs fine-tuning te vergelijken voor domeinspecifieke chatbots.\n\nVoor elke vraag schrijf je een kort verwacht antwoord in eenvoudige taal en de exacte bronsectie die het ondersteunt. Als de chatbot “Ik weet het niet” mag zeggen, neem dan gevallen op waar dat correct is.\n\n### Beoordeel antwoorden op een paar eenvoudige dimensies\n\nHoud de scorekaart klein genoeg dat je hem echt gebruikt. Deze vier checks dekken de meeste business chatbot-fouten:\n\n- Juistheid: is het feitelijk juist, zonder verzonnen details?\n- Volledigheid: behandelt het de sleutelpunten die gebruikers nodig hebben om te handelen?\n- Kwaliteit van citatie: ondersteunen de citaten of verwijzingen de bewering echt?\n- Duidelijkheid: is het leesbaar en specifiek, of vaag en omslachtig?\n\nAls je retrieval gebruikt voeg dan nog een check toe: haalde het de juiste chunk op en gebruikte het antwoord dat fragment echt in plaats van het te negeren?\n\n### Houd veranderingen in de tijd bij, niet éénmalige indrukken\n\nMaak kwaliteit routine:\n\n- Draai dezelfde testset na elke prompt-, retrieval- of modelwijziging.\n- Houd een enkele scorekaart bij en registreer totalen per datum.\n- Tag fouten (ontbrekende beleidsdetails, verkeerd nummer, verouderd doc, onduidelijke bewoording).\n- Review de slechtste 5 vragen eerst en pak de oorzaak aan.\n\nVoorbeeld: als een HR-chatbot een vraag over vergoedingen correct beantwoordt maar een verouderde PDF citeert, moet je score dalen. Dat vertelt je wat te verbeteren: documentversheid, chunking of retrievalfilters, niet per se de schrijfstijl van het model.\n\nAls je de chatbot in een app bouwt (bijvoorbeeld in AppMaster), sla testvragen en resultaten op naast releases zodat je regressies vroeg kunt ontdekken.\n\n## Het voorkomen van zelfverzekerde foute antwoorden (hallucinaties) in de praktijk\n\nZelfverzekerde foutieve antwoorden komen meestal uit drie bronnen: het model kreeg niet de juiste context, het kreeg de verkeerde context, of je moedigde het per ongeluk aan te gokken. Dit risico bestaat bij zowel RAG als fine-tuning, maar het uit zich anders. RAG faalt als retrieval zwak is; fine-tuning faalt wanneer het model patronen leert en gaten opvult met aannemelijke tekst.\n\nDe meest effectieve oplossing is bewijs eisen. Behandel elk antwoord als een klein rapport: als de ondersteunende tekst niet in de meegeleverde bronnen staat, mag de bot dat niet beweren. In de praktijk betekent dat dat je app opgehaalde fragmenten in de prompt stopt en het model verplicht dat alleen die fragmenten te gebruiken.\n\nVoeg duidelijke weiger- en escalatieregels toe zodat de bot een veilige fallback heeft. Een goede chatbot beantwoordt niet alles; hij weet wanneer hij het niet kan.\n\n- Als bronnen het onderwerp niet noemen, zeg dan “Ik heb niet genoeg info in de docs om te antwoorden.”\n- Als de vraag onduidelijk is, stel één verduidelijkingsvraag.\n- Als het antwoord geld, toegang of compliance raakt, routeer dan naar een mens of een ticket.\n- Als documenten conflicteren, wijs het conflict aan en vraag welke beleid of versie van toepassing is.\n\nBeperkingen verminderen ook gissingen en maken fouten makkelijker zichtbaar. Voor beleid-achtige antwoorden eis je de documentnaam en datum en citeer je 1–2 sleutelzinnen die het antwoord rechtvaardigen.\n\nVoorbeeld: een medewerker vraagt “Wat is de laatste limiet voor reiskostenvergoeding?” Als het opgehaalde beleidsfragment van vorig jaar is, moet de bot die datum tonen en weigeren een “laatste” limiet te noemen zonder een nieuwere bron.\n\nAls je dit in AppMaster bouwt, maak de regels onderdeel van het Business Process: retrievalstap, bewijscontrole, dan óf antwoord met citaten óf escalatie. Zo is het veiligheidsgedrag consistent, niet optioneel.\n\n## Veelgemaakte fouten en valkuilen om te vermijden\n\nDe meeste chatbot-fouten gaan niet over het model. Ze komen door rommelige documenten, zwakke retrieval of trainingskeuzes die het systeem ertoe brengen zelfverzekerd te klinken terwijl het moet vertragen. Betrouwbaarheid is meestal eerst een data- en procesprobleem.\n\nEen veelvoorkomend RAG-probleem is chunking die betekenis negeert. Als chunks te klein zijn verlies je context (wie, wanneer, uitzonderingen). Als chunks te groot zijn haalt retrieval niet-relevante tekst binnen en wordt het antwoord een mix van halve waarheden. Een simpele test: als je één chunk op zichzelf leest, is het dan nog steeds begrijpelijk en bevat het een complete regel?\n\nEen andere val is versie-mixing. Teams indexeren policies uit verschillende maanden, de bot haalt tegenstrijdige passages op en kiest er dan willekeurig één. Behandel documentversheid als een feature: label bronnen met datums, eigenaren en status (concept vs goedgekeurd) en verwijder of demote verouderde inhoud.\n\nDe meest schadelijke fout is het forceren van een antwoord wanneer niets relevants is opgehaald. Als retrieval leeg is of lage confidence heeft, moet de bot zeggen dat hij geen ondersteuning vindt en een verduidelijkingsvraag stellen of naar een mens sturen. Anders creëer je zelfverzekerde onzin.\n\nFine-tuning heeft zijn eigen valkuil: over-tunen op een smalle set Q&A. De bot begint jouw trainingsformuleringen te echoën, wordt breekbaar en kan basale redeneer- of taalvaardigheden verliezen.\n\nWaarschuwingssignalen tijdens testen:\n\n- Antwoorden noemen geen brontekst of citeren de verkeerde sectie.\n- Dezelfde vraag krijgt verschillende antwoorden afhankelijk van de formulering.\n- Beleidsvragen krijgen definitieve antwoorden terwijl docs daarover zwijgen.\n- Na fine-tuning worstelt de bot met simpele, alledaagse vragen.\n\nVoorbeeld: als je reisbeleid vorige week veranderde maar beide versies zijn geïndexeerd, kan de bot vol vertrouwen een uitgave goedkeuren die niet langer is toegestaan. Dat is geen modelprobleem; het is een content control-probleem.\n\n## Snelle checklist voordat je live gaat\n\nVoordat je een domein-chatbot voor echte gebruikers uitrolt, behandel hem als elk ander bedrijfsmiddel: hij moet voorspelbaar, testbaar en veilig zijn wanneer hij het niet zeker weet.\n\nGebruik deze checklist als laatste poort:\n\n- Elk beleidachtig antwoord is onderbouwd. Voor beweringen zoals “Je kunt dit declareren” of “De SLA is 99,9%” moet de bot laten zien waar het vandaan komt (docnaam + sectiekop of een uittreksel). Als hij geen bron kan aanwijzen, mag hij de bewering niet als feit presenteren.\n- Hij vraagt door bij onduidelijke vragen. Als het verzoek twee redelijke betekenissen kan hebben, stelt hij één korte verduidelijkingsvraag in plaats van te gokken.\n- Hij kan netjes “Ik weet het niet” zeggen. Wanneer retrieval zwak of leeg is, weigert hij beleefd, legt uit wat ontbreekt en suggereert wat te leveren (document, beleidsnaam, datum, team).\n- Documentupdates veranderen antwoorden snel. Wijzig een zin in een sleuteldocument en controleer dat het antwoord van de bot verandert na re-indexering. Als hij het oude antwoord blijft geven is je update-pijplijn onbetrouwbaar.\n- Je kunt fouten reviewen. Log de gebruikersvraag, opgehaalde fragmenten, uiteindelijke antwoord en of gebruikers op “helpvol/niet-helpvol” klikten. Zo wordt kwaliteitswerk mogelijk zonder te gokken.\n\nEen concreet test: kies 20 echte vragen uit supporttickets of interne chat, inclusief lastige met uitzonderingen. Draai ze voor de lancering en daarna opnieuw nadat je één beleidsdocument hebt bijgewerkt. Als de bot antwoorden niet betrouwbaar onderbouwt, verduidelijkingsvragen stelt en weigert wanneer bronnen ontbreken, is hij nog niet productierijp.\n\nAls je de bot in een echte app zet (bijv. een intern portaal), zorg dat bronnen makkelijk zichtbaar zijn en houd een “meld een probleem”-knop naast elk antwoord.\n\n## Voorbeeldscenario: een chatbot voor veel bijgewerkte interne documenten\n\nJe HR-team heeft beleid en onboarding-docs die elke maand veranderen: PTO-regels, reiskostenlimieten, datums voor benefits-inschrijving en onboardingstappen voor nieuwe medewerkers. Mensen stellen nog steeds dezelfde vragen in chat en antwoorden moeten overeenkomen met de nieuwste versie van de docs, niet wat vorig kwartaal waar was.\n\n### Optie A: alleen RAG, geoptimaliseerd voor actualiteit\n\nMet een RAG-opzet doorzoekt de bot eerst de actuele HR-kennisbank en antwoordt alleen met wat hij ophaalt. De sleutel is om “laat je werk zien” de standaard te maken.\n\nEen eenvoudige flow die meestal werkt:\n\n- Indexeer HR-docs volgens een schema (of bij elke goedgekeurde update) en sla documenttitel, sectie en laatst-bijgewerkt-datum op.\n- Antwoord met korte citaten (doc + sectie) en een “laatst bijgewerkt”-notitie wanneer dat relevant is.\n- Voeg weigerregels toe: als niets relevants is opgehaald, zegt de bot dat hij het niet weet en suggereert wie je kunt vragen.\n- Routeer gevoelige onderwerpen (ontslag, juridische geschillen) standaard naar een mens.\n\nDit blijft accuraat naarmate docs veranderen omdat je oude tekst niet in het model bakt.\n\n### Optie B: lichte fine-tune voor formaat, nog steeds gegrond in RAG\n\nAls je een consistente toon en gestructureerde antwoorden wilt (bijv. “In aanmerking komen,” “Stappen,” “Uitzonderingen,” “Escaleren naar HR”), kun je licht fine-tunen op een kleine set goedgekeurde voorbeeldantwoorden. De bot gebruikt nog steeds RAG voor de feiten.\n\nDe regel blijft streng: fine-tuning leert hoe te antwoorden, niet wat het beleid is.\n\nNa 2–4 weken ziet succes eruit als minder HR-escalaties voor basisvragen, hogere nauwkeurigheid in steekproeven en minder zelfverzekerde foute antwoorden. Meet dit door te kijken naar citatie-dekking (antwoorden met bronnen), het percentage weigeringen bij ontbrekende info en een wekelijkse steekproef-audit door HR.\n\nTeams bouwen dit vaak als intern hulpmiddel zodat HR content kan bijwerken, antwoorden kan reviewen en regels kan aanpassen zonder op engineering te wachten. AppMaster is één manier om die volledige applicatie (backend, webapp en mobiele app) met rollen en admin-workflows te bouwen.