Oke, je wilt GenAI inzetten om je klantcommunicatie te automatiseren. Snap ik. LLMs die e-mails schrijven, chatbots laten antwoorden, webpagina’s genereren. Mooie wereld.
Om dat te doen heb je een bron nodig: een kennisbank, productinformatie, beleidsdocumenten, of gewoon je website (al is dat laatste vaak een bijzonder slecht idee).
Tussen die bron en de output naar de klant zit dan de LLM en een promptEen prompt is de instructie die je aan een AI-model geeft zoals bijvoorbeeld ChatGPT. Het is hoe je communiceert met het systeem: wat je vraagt, hoe je het vraagt en... Meer die stuurt wat die LLM precies moet doen.
Tot zo ver check
Maar dan merk je dat de output niet goed genoeg is. Niet precies genoeg en niet feitelijk correct, dus niet betrouwbaar genoeg voor klantcommunicatie.
Je eerste reactie is dan misschien: laten we aan de prompt sleutelen. En eerlijk, dat helpt soms.
Maar meestal is het gewoon je brondata die niet goed is. Niet goed gemetadateerd en niet gemodelleerd. Met je prompt kun je dan misschien wel het een en ander opstrakken, maar je data-issue krijg je niet strakgeprompt.
Dus zoek je naar andere oplossingen.
De bron
Je bron bestaat meestal uit een mix van structured data (tabellen, databases, gestructureerde velden) en unstructured data (teksten, documenten, beleidsstukken). Daarnaast bestaat het overigens vaak vooral uit zaken die ergens daartussen vallen. Het binaire idee van structured versus unstructured is een realiteit voor slides, niet de dagelijkse handen-uit-de-mouwen-realiteit.
Dat laatste terzijde #sidequest, terug naar de data.
Oke, heb je simpele structured data zoals referenties, definities, key-value pairs, dan gaat dat redelijk gemakkelijk door je GenAI pipeline zonder dat het al te veel semantische integriteit verliest. Oftwel: simpele data kun je kneden en door systemen trekken en het blijft z’n betekenis houden. Niet omdat GenAI hier expliciet goed in is, maar omdat structured data intrinsiek minder relationele kwetsbaarheid heeft (it is structured).
Maar zodra het gaat over unstructured data OF structured data die relationele betekenis bevat, zoals beleidsregels met voorwaarden, productcatalogi met uitzonderingen, regelgeving met verwijzingen naar andere secties enz, loop je tegen problemen aan. Want de betekenis van die data zit in de relaties tussen stukken informatie, niet alleen in de informatie zelf.
Ja, ben je er nog? Want hier gaan we het hebben over RAGRAG (Retrieval-Augmented Generation) is een techniek waarbij een LLM bij het antwoorden op een vraag/uitvoeren van een prompt, informatie opzoekt in bronnen die je vooraf hebt gedefinieerd. Daardoor hoef je... Meer als oplossing voor je betekenis/semantische probleem.
RAG helpt een handje
Retrieval-Augmented Generation (RAG) wordt ingezet om hallucinatiesEr is sprake van een hallucinatie wanneer een AI-model informatie verzint die plausibel klinkt maar die feitelijk onjuist is of volledig verzonnen. Dat gebeurt omdat LLM's zoals ChatGPT woordreeksen voorspellen... Meer te verminderen en om de output te gronden in de kennis van je eigen organisatie.
Met RAG geef je de LLM toegang tot jouw documenten, zodat het niet alleen genereert op basis van zijn training, maar ook op basis van jouw bedrijfsspecifieke informatie.
Het is dan logisch dat RAG ervoor zorgt dat wat de LLM uitspuugt beter wordt en voor specifieke soorten informatie zoals referenties, definities en stabiele feiten, werkt RAG meestal ook uitstekend. Maar voor alles waar betekenis relationeel is, wordt het ingewikkelder.
Wat doet RAG ook alweer?
RAG ziet er ongeveer zo uit:
- Je brondocumenten worden opgedeeld in kleinere stukken. Het gaat dan meestal om paragrafen of secties van een paar honderd woorden.
- Die chunks worden omgezet naar embeddings. Dat zijn numerieke representaties van tekst die het mogelijk maken om te berekenen welke stukken tekst semantisch op elkaar lijken.
- Het systeem berekent welke chunks het beste passen bij wat er gevraagd wordt en haalt die op.
- En alleen die meest relevante stukken krijgt de LLM te zien bij het genereren.
Elke stap in dit proces is een transformatie van wat er uit je bron is gehaald. En bij elke transformatie kan de betekenis van dat stuk uit je bron, zijn semantische integriteit verliezen. Oftewel, de betekenis kan verschuiven en dat kan een subtiele afwijking zijn of gewoon een hele duidelijke.
Dat gebeurt niet omdat de data feitelijk verdwijnt of letterlijk wordt veranderd, maar omdat de context die nodig is om die data correct toe te passen (potentieel) verdwijnt.
Een voorbeeld voor je brein
Laten we door de stappen heen lopen met een voorbeeld:
Stel, je hebt ergens in je documentatie de volgende twee paragrafen staan:
1 paragraaf stelt
“Klanten met een Duurzame Woonlening ontvangen vanaf 2024 automatisch een rentekorting van 0,3%. De korting wordt toegepast op alle bestaande leningen die onder het programma vallen.”
En ergens anders (misschien zelfs verderop in dit document, op die intranetpagina enz)
“Voor klanten die vóór 2022 zijn ingestroomd, geldt dat de korting alleen wordt geactiveerd wanneer het energielabel in de afgelopen 18 maanden opnieuw is geregistreerd. Zonder herregistratie vervalt de korting automatisch.”
Op zichzelf zien die twee er allebei prima uit. Paragraaf 1 is helder. Paragraaf 2 ook. Maar de feitelijke betekenis van je regeling ontstaat pas als je ze sámen leest:
- Ja, er is een automatische rentekorting.
- Maar: voor een deel van de klanten (instroom vóór 2022) geldt die alleen als er recent een energielabel is her-geregistreerd.
Dus als een klant vraagt: “Kom ik in aanmerking voor die 0,3% rentekorting?” dan is het juiste antwoord afhankelijk van beide paragrafen tegelijk: instroomdatum + energielabelregistratie + programma-voorwaarden.
En dat is dus waar het mis kan gaan in een RAG-pipeline.
De RAG pipeline doet dit
We trekken ons voorbeeld er even doorheen:
Stap 1: ingestion, bestaat uit chunking & embedding
Chunking: we hakken de data in stukjes. Het liefst zo slim mogelijke stukjes, maar dat is geen absoluut punt, want wanneer is het slim? Een data scientist zweet o.a. op deze vraag. Maar je snapt misschien wel dat unstructured data, dus niet gestructureerd is en geen voorspelbare opbouw heeft. Dat maakt het chunken op z’n allerminst kwetsbaar, ongeacht welke ingreep/methode (tokenEen token is de kleinste eenheid waarin een LLM tekst verwerkt. Dat kan een heel woord zijn, maar ook een stukje van een woord, een leesteken of zelfs een spatie.... Meer, paragraph, based, semantic of document aware) je ook gebruikt.
Laten we voor het voorbeeld aannemen dat het in de meeste gevallen goed gaat, maar dat in 10% van de gevallen (lage inzet jongens, want ik vermoed hoger) de relatie tussen 2 chunks wordt “doorgeknipt”.
De rentestand en de voorwaarden zijn nu niet meer 1 pakketje, maar worden opgeslagen als 2 lossen vectoren.
Stap 2: retrieval
De losse pakketjes liggen comfortabel te wachten tot iemand (jij, een klant, mijn neef, een systeem) een vraag stelt. De LLM komt dan aan deze pakketjes snuffelen door middel van Semantic Search. Oftewel het systeem kijkt welke stukken tekst, als vectoren, het meest op elkaar lijken.
Een klant vraagt bijv. aan de chatbot:
“Krijg ik rentekorting op de Duurzame woonlening” (al is de kans erg groot dat je klant het veel creatiever vraagt. Met veel meer of veel minder woorden en dat heeft ook nog impact).
De LLM gaat aan de slag, snuffelt aan de vectoren, zoekt naar semantische overeenkomsten: duurzame+woonlening+rentekorting. Waar vindt hij taalpatronen die voldoende overeenkomsten hebben om deze mee te nemen in zijn antwoord.
In paragraaf 1 waarschijnlijk wel: de Duurzame woonlening wordt daar letterlijk genoemd.
Paragraaf 2, die door het chunken geen relatie meer heeft met de Duurzame woonlening, licht echter niet op in zijn zoektocht naar relevante informatie. Soms wordt zo’n tweede paragraaf alsnog opgehaald, maar dat is geluk en geen garantie. En zonder die garantie heb je geen betrouwbare en compliant klantcommunicatie.
De LLM chatbot antwoordt dan ook:
Vanaf 2024 ontvangt u automatisch een rentekorting bij ons. Fijn he!
Maarrrrr, dat is niet waar. De klant ontvangt die korting helemaal niet als hij niet aan de nu verloren voorwaarden voldoet. Oeps.
Maareh, wat als die klant nou zegt: moet ik nog aan voorwaarden voldoen en hij zegt dat in hetzelfde gesprek. Dan komen ze toch wel naar voren?
Nee! Niet per se. Als de relatie verbroken is (nooit teruggaan naar je ex), dan haalt de LLM de voorwaarden niet op bij retrieval. Want hij weet helemaal niet dat het bij dat product hoort. Hij weet namelijk helemaal niks.
En dan hebben we nog extra complicaties
En om het feest extra leuk te maken. Extra leuk leuk. Spelen deze zaken ook nog een rol:
- De LLM antwoordt wél altijd, maar nu gaat hij raden (gebaseerd op wat semantisch dicht bij de vraag ligt uit jouw data of op basis van zijn eigen trainingsdata, maar dat is niet Jouw data). Misschien raadt hij zelfs wel goed. Misschien, maar misschien ook helemaal niet. Verrassingsantwoorden, het type antwoorden waar compliance gek op is.
- Heb je meerdere producten die veel op elkaar lijken? 10 typen leningen bijvoorbeeld? Dan loop je extra risico’s als de relatie tussen informatie verdwijnt: want de taalpatronen lijken in dat geval erg op elkaar, dus de LLM doet er een mooi gokspelletje mee.
Kortom, ook mét RAG speel je met compliance en legal-vuur. Is dat altijd erg? Waarschijnlijk niet bij elke vraag, in elke sector, bij elk product. Maar afhankelijk van de precieze kwaliteit van je brondata, de manier waarop RAG is geimplementeerd en ook niet onebelangrijk wat je tussen retrieval en generatie doet (er is meer, maar dat wordt een ander artikel), is er eigenlijk altijd wel een risico. De vraag is niet zozeer of het risicoloos is, maar hoeveel risico Jij bereid bent om te nemen.
TLDR;
Nou denk je misschien: wat moet ik met deze informatie. Nou ik ga het even platslaan, dat helpt denk ik:
- RAG wordt vaak gebruikt om ontoegankelijke of verspreide kennis beter bruikbaar te maken. Maar het lost onderliggende dataproblemen niet op.
- Hoe complexer je brondata (10 producten die op elkaar lijken, elk met 3 mitsen en maren en een paar met gestapelde afhankelijkheden), hoe minder RAG onder de streep eigenlijk fixt
- Hoe chaotischer je brondata, hoe harder je RAG nodig hebt om het te redden. Maar daar werkt het juist niet.
Voor de puristen: ja, er zijn absoluut mitigaties mogelijk, maar de kern blijft: RAG vervangt geen goede datamodellering
De vraag die je nu zou kunnen stellen is als volgt:
Moet je voor taken die vragen om een precies (deterministisch) antwoord, waarbij de potentiële impact van fouten groot is, gebruik maken van een LLM? Want LLMs werken op basis van taalpatronen in een waarschijnlijkheidsveld: wat is het meest waarschijnlijke volgende token, gebaseerd op de patronen.
Dat dit in die situatie niet goed gaat, kan Stevie Wonder nog zien. Wát er niet goed gaat, is lastig te zeggen. Want niet alleen is het lastig te constateren hoe vaak het niet goed zal gaan (de breedte ervan), maar weet je ook niet hoe erg het dan niet goed gaat (de diepte ervan). Oftwel: geeft de LLM een verkeerde rente of geeft de LLM een verkeerde rentekorting en garandeert hij die onder alle omstandigheden.
Hypothetische beslissingen
Nou ben ik geen CEO, maar in mijn hypothetische multinational gebruik ik geen LLM als chatbot. Ik gebruik een deterministisch systeem, met schone en goed ingerichte data, die exacte antwoorden oplevert. Die geef ik dan wel aan een LLM, zodat hij het aardig kan zeggen.
En ook dat ontslaat me er overigens niet van om het goed in te richten, af te stellen, uit te voeren. Maar die setup geeft me wel een stuk meer vertrouwen.
Overigens: wil je tóch GenAI inzetten voor je klantcommunicatie? Kies dan bij voorkeur kleine en goed-gestructureerde domeinen met beperkte afhankelijkheden. Dat helpt een boel.
Maar dat ben ik he. Misschien zie jij het wel heel anders en zelfs beter. Dat hoor ik dan graag. Leer ik ook van. Gooi je comment erbij!
Don’t stress….it’s just me!
I’ve spent over 25 years working in content strategy and digital transformation, which means I’ve seen enough technology hype cycles to be skeptical and enough genuine innovation to stay curious.
Want to talk shop? Do get in touch!
I have a newsletter and it's bearable. Subscribe to read my (Gen)AI articles!
