Caching voor AI: welke antwoorden mag je hergebruiken?
AI-antwoorden mag je vooral hergebruiken wanneer dezelfde vraag onder dezelfde omstandigheden hetzelfde geldige antwoord hoort op te leveren. Tijdgevoelige, gepersonaliseerde of creatieve antwoorden meestal niet — en semantische caching heeft zijn eigen risico's.
AI-antwoorden kun je vooral hergebruiken wanneer dezelfde of vrijwel dezelfde vraag onder dezelfde omstandigheden hetzelfde geldige antwoord hoort op te leveren. Veelgestelde feitelijke vragen, classificaties en samenvattingen van onveranderde documenten zijn daarom goede kandidaten. Actuele, gepersonaliseerde, creatieve of contextafhankelijke antwoorden zijn dat meestal niet.
Caching bij AI vraagt daardoor meer voorzichtigheid dan caching bij een traditionele API. Een klassieke API-call naar een product-ID of postcode levert doorgaans een voorspelbaar resultaat op zolang de achterliggende data niet verandert. Een taalmodel kan bij dezelfde prompt verschillende formuleringen of zelfs inhoudelijke nuances produceren. Bovendien kunnen systeemprompts, modelparameters, gespreksgeschiedenis, gebruikersrechten en opgehaalde RAG-context allemaal bepalen welk antwoord correct is.
Waarom AI-caching anders is dan gewone API-caching
Bij een traditionele API is een cache-key vaak eenvoudig: dezelfde endpoint, parameters en versie kunnen hetzelfde antwoord uit de cache krijgen. Bij generatieve AI bestaat die zekerheid niet automatisch.
Taalmodellen zijn vaak niet volledig deterministisch. Een vraag als "Vat dit document samen" kan bij twee uitvoeringen twee verschillende maar allebei acceptabele samenvattingen opleveren. Caching maakt één van die mogelijke antwoorden vervolgens tot het vaste resultaat.
Daar komt context bij. De zichtbare gebruikersprompt is meestal niet alles wat naar het model gaat. Een applicatie kan een systeemprompt toevoegen, eerdere berichten meesturen, documenten ophalen via RAG of gebruikersspecifieke informatie invoegen. Twee identieke vragen kunnen daardoor terecht verschillende antwoorden vereisen. Exact dezelfde prompttekst vergelijken is daarom onvoldoende als andere onderdelen van de modelinput verschillen.
Exact-match caching versus semantische caching
Exact-match caching is de eenvoudigste vorm. De applicatie maakt bijvoorbeeld een cache-key van de prompt, modelconfiguratie, systeemprompt en relevante context. Alleen wanneer die combinatie identiek is, wordt een eerder antwoord hergebruikt. Dat is relatief veilig, maar levert minder cache-hits op. Kleine verschillen in formulering zorgen al snel voor een nieuwe modelaanroep.
Semantische caching probeert dat probleem op te lossen. Daarbij wordt een vraag meestal omgezet naar een embedding. Komt een nieuwe vraag semantisch voldoende dicht bij een eerdere vraag, dan kan het systeem het bijbehorende gecachte antwoord teruggeven. Dat kan efficiënter zijn, maar introduceert een nieuw risico: semantisch vergelijkbaar betekent niet noodzakelijk inhoudelijk uitwisselbaar.
"Kan ik een factuur na 30 dagen verwijderen?" en "Moet ik een factuur 30 dagen bewaren?" kunnen bijvoorbeeld sterk op elkaar lijken in embeddingruimte terwijl ze iets wezenlijk anders vragen. Hoe groter de tolerantie voor overeenkomst, hoe groter de kans dat het systeem een antwoord hergebruikt dat niet bij de nieuwe vraag past. Semantische caching vereist daarom conservatieve drempels en bij risicovolle toepassingen vaak aanvullende controles.
Welke antwoorden zijn goede kandidaten?
Caching werkt het beste wanneer antwoorden weinig afhankelijk zijn van tijd, gebruiker of generatieve variatie. Veelgestelde kennisbankvragen zijn een logisch voorbeeld, zolang de onderliggende informatie stabiel is. Ook een samenvatting van een PDF kan worden hergebruikt wanneer het document zelf niet is gewijzigd.
Classificatietaken zijn eveneens geschikt. Als hetzelfde stuk tekst steeds moet worden ingedeeld volgens dezelfde categorieën en dezelfde instructies, is opnieuw inferentie uitvoeren meestal weinig zinvol. Andere voorbeelden zijn het genereren van embeddings voor onveranderde tekstfragmenten en bepaalde documentanalyses waarvan de input exact gelijk blijft. De belangrijkste vraag is niet of twee prompts op elkaar lijken, maar of het inhoudelijk verantwoord is dat beide verzoeken hetzelfde resultaat krijgen.
Welke antwoorden moet je meestal niet cachen?
Tijdgevoelige informatie is een slechte kandidaat. Een antwoord over voorraad, prijzen, beschikbaarheid, regelgeving, nieuws of operationele status kan minuten of dagen later al achterhaald zijn.
Ook gepersonaliseerde antwoorden vragen extra voorzichtigheid. Wanneer gebruikers verschillende dossiers, contracten, voorkeuren, rechten of klantgegevens hebben, mag een antwoord van gebruiker A niet via een gedeelde cache bij gebruiker B terechtkomen.
Creatieve en open vragen passen eveneens slecht bij volledige antwoordcaching. Wanneer iemand om een nieuwe slogan, brainstorm, ontwerpvariant of tekstconcept vraagt, is variatie vaak juist onderdeel van de gewenste functionaliteit. Hetzelfde geldt voor verzoeken die actuele databases, zoekresultaten of externe API's gebruiken. Een eerder antwoord hergebruiken kan betekenen dat de actuele databron helemaal niet meer wordt geraadpleegd.
Prompt-caching is iets anders
Prompt-caching bij LLM-providers wordt soms verward met response caching, maar het zijn verschillende mechanismen. Bij prompt-caching wordt doorgaans een eerder verwerkte prefix of een groot stuk herhaalde context opnieuw gebruikt. Denk aan een omvangrijke systeemprompt, instructies of een document dat bij veel requests steeds opnieuw wordt meegestuurd.
De provider hoeft dat gedeelde gedeelte dan niet iedere keer volledig opnieuw te verwerken. Dat kan het tokengebruik en de latency van de verwerking beperken, afhankelijk van hoe de gebruikte dienst dit implementeert. Het uiteindelijke antwoord wordt echter nog steeds opnieuw gegenereerd. Prompt-caching zegt dus niet: "geef hetzelfde antwoord als vorige keer". Het zegt eerder: "dit deel van de input heb je al verwerkt". Dat maakt het bruikbaar in veel situaties waarin volledige response caching juist ongewenst zou zijn.
Caching binnen een RAG-architectuur
In een RAG-systeem kan caching op verschillende lagen plaatsvinden. Embeddings zijn vaak de meest voor de hand liggende laag. Een documentchunk die niet verandert, hoeft niet steeds opnieuw naar een embeddingmodel.
Ook retrieval-resultaten kunnen tijdelijk worden gecachet. Wanneer dezelfde zoekvraag meerdere keren tegen exact dezelfde versie van een kennisbank wordt uitgevoerd, kan een eerder gevonden set documenten mogelijk opnieuw worden gebruikt.
Een derde niveau is het volledige gegenereerde antwoord. Dat levert potentieel de grootste besparing op, maar heeft ook het grootste invalidatierisico. Zelfs wanneer de vraag gelijk blijft, kan een gewijzigd brondocument betekenen dat het oude antwoord niet langer geldig is. Hoe hoger in de keten je cachet, hoe sterker je daarom moet nadenken over afhankelijkheden.
Het gevaar van een overtuigend verkeerde cache
Caching kan fouten hardnekkiger maken. Een hallucinerend modelantwoord dat één keer wordt gegenereerd, is vervelend. Als dat antwoord vervolgens wekenlang uit de cache wordt geserveerd, verandert een eenmalige modelmisser in systematisch fout gedrag.
Ook verouderde bronnen vormen een risico. Een kennisbank kan inmiddels zijn bijgewerkt terwijl de applicatie nog een ouder gegenereerd antwoord serveert. Privacy is minstens zo belangrijk. Cache-keys moeten rekening houden met gebruikersscope, organisatie, tenant, rechten en andere beveiligingscontext. Alleen de prompttekst als cache-key gebruiken in een multi-useromgeving kan ernstige datalekken veroorzaken. Een cache is daarmee niet alleen een performancecomponent, maar ook onderdeel van het beveiligings- en datagovernancemodel.
Praktische regels voor cache-invalidatie
Begin met de veranderingssnelheid van de brondata. Informatie die nauwelijks wijzigt kan een langere TTL krijgen dan data die ieder uur wordt bijgewerkt. Er bestaat geen universeel correcte TTL: die moet aansluiten op hoe lang een antwoord inhoudelijk betrouwbaar blijft.
Bij RAG is versiegebonden invalidatie vaak sterker dan alleen tijdgebonden invalidatie. Wanneer een brondocument verandert, kunnen caches die daarvan afhankelijk zijn direct ongeldig worden gemaakt. Neem ook relevante configuratie op in de cache-key. Een nieuwe systeemprompt, gewijzigde modelinstellingen, ander model of aangepaste retrievalstrategie kan betekenen dat een oud antwoord niet meer representatief is. En houd gebruikersscope strikt gescheiden. Een gepersonaliseerd antwoord hoort alleen binnen dezelfde toegestane context hergebruikt te worden. Wanneer je niet overtuigend kunt aantonen dat cross-user caching veilig is, moet je het niet doen.
Conclusie
AI-caching is vooral verstandig wanneer de applicatie kan aantonen dat een eerder antwoord nog steeds inhoudelijk correct, actueel en passend is voor de huidige gebruiker en context. Exact-match caching is meestal eenvoudiger te beheersen dan semantische caching, terwijl prompt-caching een nuttige manier kan zijn om verwerking te besparen zonder antwoorden zelf te hergebruiken. Cache daarom selectief, koppel invalidatie aan je databronnen en behandel gebruikerscontext als onderdeel van de cache-key. Een snelle cache die het verkeerde antwoord serveert, is uiteindelijk duurder dan een extra modelaanroep.