Semantische cache

Wat is een semantische cache?

Een semantische cache staat voor je taalmodel en houdt bij welke vragen het al beantwoord heeft. Een nieuwe vraag wordt eerst tegen die lijst gelegd. Zit er al een vraag in die er genoeg op lijkt, dan krijgt de gebruiker het bewaarde antwoord en wordt het model niet aangeroepen. Zo niet, dan gaat de vraag naar het model en bewaart de cache vraag en antwoord voor de volgende keer.

Het woord semantisch maakt het verschil met een gewone cache. Een gewone cache helpt enkel als twee aanvragen letterlijk identiek zijn, en bij vrije tekst gebeurt dat zo goed als nooit. "Hoe pas ik mijn leveradres aan", "kan ik het adres van mijn bestelling nog wijzigen" en "verkeerd adres ingevuld, help" zijn drie verschillende zinnen met één antwoord. Een semantische cache vergelijkt de betekenis, dus alle drie kunnen op hetzelfde bewaarde antwoord uitkomen.

Denk aan de collega aan de supportdesk die zich herinnert dat die vraag gisteren ook al binnenkwam en het antwoord uit dat ticket kopieert in plaats van het opnieuw op te zoeken.

Hoe werkt een semantische cache?

1. De vraag omzetten in een embedding. De binnenkomende tekst wordt een embedding, een rij getallen die gelijkaardige betekenissen dicht bij elkaar legt. Dat is een aparte en goedkope modeloproep, geen oproep naar het chatmodel.

2. Zoeken tussen de bewaarde vragen. Een nearest-neighbour search over de bewaarde embeddings geeft de dichtstbijzijnde eerdere vraag terug, met een score voor hoe dicht ze bij elkaar liggen.

3. Vergelijken met een drempel. Haalt die score de drempel die jij instelt, dan is het een hit en krijgt de gebruiker het bewaarde antwoord. De gateway van Portkey rekent bijvoorbeeld standaard vanaf een cosine similarity van 0,95 een hit; de RedisVL-bibliotheek van Redis werkt standaard met een cosine distance van 0,1, hetzelfde idee maar dan als afstand uitgedrukt.

4. Bij een miss: model aanroepen en bewaren. De vraag gaat gewoon naar het model, en de cache slaat de embedding samen met het antwoord op, zodat de volgende gelijkaardige vraag wel een hit wordt.

De meeste implementaties vergelijken enkel het bericht van de gebruiker en negeren de systeemprompt, want die is bij elke aanvraag dezelfde en zou alles op elkaar doen lijken. De embedding en de zoekopdracht voegen bij elke aanvraag een kleine vertraging toe, die je bij elke hit ruimschoots terugwint.

Waar een semantische cache opbrengt

Het patroon werkt waar veel mensen hetzelfde vragen in andere woorden, en waar het juiste antwoord voor iedereen hetzelfde is. Supportchatbots en FAQ-verkeer zijn het voor de hand liggende geval: openingsuren, retourvoorwaarden, een wachtwoord resetten, wat een levering kost. Interne assistenten over stabiele documenten zijn het andere: het personeelsreglement, de onkostenpolicy, de productcatalogus, waar dezelfde collega's elke maand dezelfde vragen stellen en de documenten zelden veranderen.

Voor alles wat een gesprek is, werkt het niet. LiteLLM zegt het letterlijk in de documentatie van zijn proxy: semantische caching is bedoeld voor losse vragen, en bij gesprekken met meerdere beurten of bij agents speelt ze verouderde antwoorden opnieuw af. Beurt vijf van een gesprek lijkt bijna identiek op beurt vier, dus de cache blijft het antwoord van beurt vier geven.

Een rekenvoorbeeld

Stel dat de assistent van een webshop 10.000 vragen per maand verwerkt, elk door een prompt met opgehaalde product- en beleidstekst, en dat een volledige modeloproep ongeveer 2 cent kost, antwoord inbegrepen. Zonder cache is dat 200 euro per maand.

Stel dat vier vragen op de tien een match vinden. Dan komen 4.000 antwoorden uit de cache en gaan er nog 6.000 naar het model, dus de modelfactuur zakt naar ongeveer 120 euro. De cache kost zelf ook iets, een embedding voor elk van de 10.000 vragen, maar embeddings worden per miljoen tokens in centen afgerekend, dus bij korte vragen valt dat in het kleingeld. Wat je er wel bij betaalt, is de opslag die je draait. Netto bespaar je een kleine 80 euro per maand, of 40 procent van de factuur.

Daar volgen twee dingen uit. De besparing groeit mee met het volume en met de kost per oproep, dus een cache op goedkoop verkeer met weinig volume is de operationele aandacht niet waard. En het tweede voordeel weegt vaak zwaarder dan het eerste: een hit komt in milliseconden terug in plaats van in seconden, en de veelgestelde vragen krijgen nog altijd een antwoord als de modelaanbieder traag is of platligt.

Semantische cache versus prompt caching

De namen lijken op elkaar en de twee lossen een ander probleem op. Prompt caching gebeurt bij de modelaanbieder en werkt op een identieke prefix; de documentatie van Anthropic stelt dat een cache hit 100 procent identieke promptsegmenten vereist. Het model draait nog altijd en schrijft nog altijd een nieuw antwoord, en wat je uitspaart is het opnieuw inlezen van dezelfde lange instructies, tegen ongeveer een tiende van de gewone inputprijs. Een semantische cache draai je zelf, ze werkt op een gelijkaardige vraag in plaats van op een identieke prefix, en bij een hit draait het model helemaal niet.

Je kan ze combineren. Prompt caching maakt elke modeloproep goedkoper; een semantische cache vermindert het aantal modeloproepen. Een supportassistent met een lange vaste beleidsprompt haalt voordeel uit allebei.

Waar moet je op letten bij een semantische cache

Azure API Management zet de waarschuwing bovenaan zijn policyreferentie: omdat semantische caching antwoorden teruggeeft op basis van gelijkenis, kan ze antwoorden opleveren die fout, verouderd of onveilig zijn voor de huidige aanvraag. Dat gebeurt op twee manieren.

Valse hits. "Hoe zeg ik mijn abonnement op" en "hoe voorkom ik dat mijn abonnement opgezegd wordt" delen bijna elk woord en scoren als heel gelijkaardig. Hetzelfde geldt voor "leveren jullie in Nederland" en "leveren jullie in Frankrijk". De cache geeft een zelfzeker, goed geschreven antwoord op de verkeerde vraag, en niets in het antwoord verraadt dat. Zet de drempel dus streng en meet hem op je eigen verkeer in plaats van een standaardwaarde over te nemen. Azure raadt aan streng te beginnen, rond 0,05 op zijn schaal, en waarschuwt dat je boven 0,2 mismatches krijgt.

Verouderde hits. Je retourtermijn gaat van 14 naar 30 dagen, het beleidsdocument wordt aangepast, en de cache blijft het antwoord van vorige maand geven omdat de vraag niet veranderd is. Elk bewaard antwoord heeft een time-to-live nodig, en de getroffen entries moeten uit de cache zodra de brondocumenten veranderen. Bij de store-policy van Azure is die duur om precies die reden verplicht.

De controles die beide in de hand houden:

• Cache nooit antwoorden die gepersonaliseerd zijn of afhangen van wie de vraag stelt. "Waar blijft mijn bestelling" heeft voor elke klant een ander juist antwoord, en een hit is hier een datalek.

• Scheid de cache per gebruiker, klant of tenant als antwoorden terecht van elkaar verschillen. Het element vary-by van Azure en de tagfilters van RedisVL bestaan daarvoor.

• Log elke hit met de oorspronkelijke vraag, de gematchte vraag en de score, zodat je valse hits kan nakijken en de drempel bijstelt op basis van bewijs.

• Zet een korte TTL op alles wat een document volgt, van enkele minuten tot een dag, en maak de cache leeg als dat document verandert.

Waar vind je een semantische cache?

Zelf bouwen doe je zelden. LLM-gateways zoals Portkey, LiteLLM en Azure API Management bieden een semantische cache aan als instelling, GPTCache van het team achter de vector database Milvus voegt er een toe in je eigen code, en vector stores zoals Redis of Qdrant leveren er een bovenop hun zoekfunctie.