Cache semantica: quando riusare le risposte degli LLM

La cache semantica può evitare chiamate ripetute al modello, ma solo quando richieste formulate in modo diverso possono ricevere la stessa risposta senza rischi. Il percorso si articola in 4 passaggi: creare l'embedding del prompt, cercare gli elementi più vicini, applicare una soglia e infine restituire una risposta memorizzata oppure chiamare il modello. La parte difficile è capire quando una corrispondenza molto simile porta comunque alla risposta sbagliata.

Conviene partire da un centro assistenza con contenuti stabili o dalle FAQ pubbliche di un prodotto. Un modello linguistico di grandi dimensioni (LLM), cioè il sistema che genera la risposta, non dovrebbe dover spiegare la stessa policy pubblicata ogni volta che qualcuno riformula la domanda. Saldi dei conti, stato degli ordini e azioni come l'emissione di rimborsi devono restare fuori da questa cache condivisa.

I dettagli implementativi descritti di seguito sono stati verificati sulla documentazione ufficiale il 21 ottobre 2026. L'esempio del negozio è inventato: i punteggi di similarità servono a illustrare una decisione e non derivano da misurazioni degli embedding.

Cache semantica, cache esatta e prompt caching: cosa cambia?

Una cache semantica riutilizza una risposta precedente quando una nuova richiesta sembra avere lo stesso significato. Si può immaginare un addetto all'assistenza che recupera una risposta approvata da uno schedario: formulazioni diverse possono rimandare alla stessa scheda, ma l'addetto deve comunque verificare a quale policy e a quale cliente si applichi.

Un embedding è una rappresentazione numerica del testo usata per confrontarne il significato. La cache memorizza l'embedding di un prompt precedente insieme alla risposta e al contesto che lo identifica. Il nuovo prompt viene trasformato in un altro embedding e una ricerca vettoriale individua le voci vicine. La documentazione di Microsoft sulla cache semantica descrive questo schema di riutilizzo delle risposte e spiega perché il contesto della conversazione conta.

Questi livelli di cache evitano operazioni diverse:

Con una cache esatta delle risposte, «Posso restituire queste cuffie?» e «Queste cuffie possono essere restituite?» hanno normalmente chiavi diverse. La cache semantica può collegare le parafrasi. Nessuno dei due approcci rende sicura una risposta obsoleta o riferita all'ambito sbagliato.

Il prompt caching del provider non recupera una vecchia risposta perché la domanda suona simile. La documentazione di Anthropic sul prompt caching descrive il riutilizzo di prefissi del prompt corrispondenti e lo distingue esplicitamente dalla generazione dell'output. L'applicazione continua a chiedere al modello di produrre una risposta. La guida alla KV cache spiega lo stato interno al modello alla base di questa distinzione.

I livelli possono coesistere: prima si controlla la cache esatta delle risposte, poi quella semantica, infine si chiama il modello usando il prompt caching del provider, quando disponibile. È rispetto a questa configurazione già ottimizzata che va misurato il beneficio della cache semantica.

Come funziona il caching semantico delle risposte LLM: quattro passaggi

La ricerca deve individuare una risposta riutilizzabile entro un contesto consentito. Quel contesto va stabilito prima di cercare: l'utente o il tenant autenticato, la policy applicabile, la lingua e qualsiasi altro elemento che possa cambiare ciò che la risposta può contenere.

1. 1

   1. Creare l'embedding del prompt

   Convertire la domanda in arrivo in un embedding, usando lo stesso modello di embedding e una configurazione compatibile con quella delle voci memorizzate. Includere il contesto della conversazione necessario a interpretare la richiesta oppure limitare la cache alle domande comprensibili da sole.

   «E il mio?» non è una chiave di cache completa. Se per capire a cosa si riferisce «il mio» servono dati privati di un ordine, la cache condivisa delle risposte va saltata.

2. 2

   2. Cercare gli elementi vicini

   Cercare tra gli embedding dei prompt memorizzati i candidati più vicini, all'interno dell'ambito consentito. Per ogni candidato, recuperare la risposta e i metadati, cioè i campi che ne descrivono il titolare, la versione della fonte e la scadenza.

   Il vicino più prossimo è semplicemente la voce più vicina tra quelle trovate. Può comunque non essere pertinente. Trovare qualcosa non significa aver trovato una risposta riutilizzabile.

3. 3

   3. Applicare la soglia e i controlli di ammissibilità

   Confrontare la similarità o la distanza del candidato con la soglia calibrata. Richiedere poi una corrispondenza esatta dei campi che cambiano la risposta, come le condizioni del prodotto, la versione della policy e l'ambito di accesso.

   Se il punteggio supera il controllo ma il contesto non corrisponde, trattare il risultato come un miss, cioè una ricerca senza esito utile. Lo stesso vale se non è possibile stabilire con affidabilità il contesto richiesto.

4. 4

   4. Restituire la risposta o chiamare il modello

   In caso di hit accettato, restituire la risposta memorizzata senza una nuova chiamata di generazione. In caso di miss, eseguire il normale flusso del modello o di recupero delle informazioni, restituirne il risultato e memorizzarlo solo se soddisfa le regole di ammissione alla cache.

   Non trasformare automaticamente ogni output del modello in una risposta riutilizzabile. Errori, dettagli personali e risposte legate a risultati temporanei dei tool potrebbero non essere adatti.

La differenza decisiva rispetto alla ricerca semantica riguarda ciò che accade dopo il recupero. La ricerca presenta materiale pertinente; una cache delle risposte può presentare direttamente una risposta precedente come risposta alla richiesta attuale. Per questo una falsa corrispondenza ha conseguenze più rilevanti.

Un hit valido e una quasi corrispondenza da rifiutare

Basta che cambi una condizione per invalidare una corrispondenza altrimenti convincente. Immaginiamo un negozio la cui policy consenta il reso di cuffie con confezione ancora chiusa ed escluda quelle con confezione aperta. Sono dati a scopo didattico, non la descrizione della policy di un rivenditore reale.

La cache contiene:

• Domanda memorizzata: «Posso restituire delle cuffie con la confezione ancora chiusa?»
• Risposta memorizzata: «Sì. La policy sui resi di questo negozio ammette il reso delle cuffie con confezione ancora chiusa.»
• Contesto memorizzato: la versione corrente della policy del negozio, la categoria cuffie, la lingua inglese e condition=unopened.

Solo per questo esempio, supponiamo che la similarità coseno minima sia 0.90. La similarità coseno confronta la direzione dei vettori: non è la probabilità che una risposta sia corretta. I punteggi seguenti sono inventati per illustrare la decisione.

Entrambi i candidati superano la soglia numerica. Solo la parafrasi può riutilizzare la risposta. La quasi corrispondenza condivide prodotto, azione e gran parte della formulazione, ma cambia il fatto che determina la risposta.

Quando la condizione è nota, l'applicazione dovrebbe conservarla in un campo strutturato. Se deve estrarla dal testo, un'estrazione incerta deve far proseguire sul normale percorso di risposta. Un ulteriore confronto tra embedding non sostituisce la conoscenza del fatto che la confezione sia stata aperta o meno.

I parametri che rendono sicuro il riutilizzo

Soglia, durata di validità e ambito agiscono insieme. Regolare solo la soglia lascia la cache esposta a richieste perfettamente simili che richiedono risposte diverse.

Soglia di similarità: calibrarla sulle risposte sbagliate

Una soglia più severa sacrifica alcuni hit utili per ridurre le false corrispondenze. Una soglia più permissiva aumenta il riutilizzo e può aumentare anche quello scorretto. Partendo dal proprio traffico, costruire un insieme etichettato di parafrasi e di negativi difficili: domande simili che devono ricevere risposte diverse.

Includere variazioni di date, versioni del prodotto, negazioni, valute, ruoli degli account e cronologie delle conversazioni. Valutare se la risposta memorizzata sia valida per la nuova richiesta, non soltanto se i prompt trattino lo stesso argomento.

Prima di regolare la soglia, capire quale metrica si sta usando. Redis Vector Library (RedisVL), una libreria per sviluppare applicazioni con la ricerca vettoriale di Redis, documenta distance_threshold in unità di distanza COSINE di Redis, da 0 a 2: valori più bassi rendono la corrispondenza più restrittiva. Una soglia minima di similarità funziona di solito nella direzione opposta. Riferimento API di RedisVL.

Non esiste una soglia universale da trasferire tra modelli di embedding, dataset o prodotti. Cambiare modello di embedding richiede anche una migrazione pianificata dell'indice e una nuova calibrazione: i vettori vecchi e nuovi non vanno mescolati senza criterio.

Time to live: la scadenza è solo una misura di riserva

Il time to live (TTL) indica per quanto tempo una voce resta utilizzabile prima di scadere. Va scelto in base a quanto a lungo si può tollerare una risposta vecchia, non a quanto a lungo la cache può conservarla.

Una risposta tratta da documentazione stabile e una sulla disponibilità in tempo reale di un articolo hanno esigenze di aggiornamento diverse. Per la seconda può essere preferibile evitare la cache. Una correzione urgente della policy deve invalidare subito le voci interessate, anche se il loro TTL non è ancora scaduto.

Includere la versione della fonte o della policy nei controlli di ammissibilità. Quando quella versione cambia, le vecchie voci smettono di corrispondere. RedisVL offre sia un TTL predefinito sia la possibilità di modificarlo per singola voce, ma spetta all'applicazione decidere la durata appropriata. API della cache di RedisVL.

Ambito per utente: l'identità richiede un confine esatto

Usare una cache condivisa solo per risposte destinate a essere condivise. Un tenant è un'organizzazione cliente; il solo confine tra tenant non basta quando i dipendenti della stessa organizzazione hanno diritti di accesso diversi.

Una risposta specifica di un account richiede un ambito che rispecchi l'utente autenticato e i suoi permessi attuali. «Qual è la mia data di rinnovo?» non deve avviare una ricerca tra tutti coloro che hanno posto la stessa domanda. L'identità deve provenire dal sistema di autenticazione affidabile dell'applicazione, non da una frase fornita dall'utente o da un embedding.

Applicare i filtri di ambito prima di selezionare il candidato, poi verificarne l'autorizzazione prima di restituirlo. Le modifiche ai permessi e le cancellazioni devono invalidare il percorso di riutilizzo interessato. filterable_fields e filter_expression di RedisVL forniscono gli strumenti di base per filtrare; non definiscono automaticamente la policy di autorizzazione dell'applicazione. Parametri di filtro.

Contesto e versioni: conservare i presupposti della risposta

Delimitare l'ambito delle voci in base al prompt di sistema che influenza la risposta, ai requisiti del modello, allo schema di output, alla lingua e alla versione della fonte. Un paragrafo in cache non può soddisfare una nuova richiesta che impone una risposta strutturata diversa.

Nella cache delle conversazioni, la stessa frase finale può riferirsi ad argomenti precedenti diversi. La spiegazione di Microsoft sulla finestra di contesto evidenzia proprio questo errore. Conviene iniziare con domande autonome, a meno di poter rappresentare e verificare la cronologia rilevante.

Come implementarla: gateway, architettura Redis o libreria

Il punto di integrazione va scelto in base a dove è possibile far rispettare i vincoli della risposta. Quelli che seguono sono esempi di implementazione, non una classifica di prodotti intercambiabili.

Funzionalità nel gateway: Kong AI Semantic Cache

Kong AI Semantic Cache, un plugin dell'offerta AI Gateway Enterprise di Kong, colloca la cache semantica delle risposte nel gateway, il punto di ingresso attraverso cui passano le richieste ai modelli. La documentazione descrive la ricerca basata su embedding con configurazioni Redis o pgvector. Il riferimento della configurazione espone cache_ttl, message_countback e vectordb.threshold.

È adatto a flussi di richieste ripetibili e gestiti centralmente. Il limite principale è il contesto applicativo: un gateway può far rispettare solo le distinzioni presenti nella configurazione e nelle richieste. Prima di attivarlo per chat personalizzate, verificare l'isolamento degli utenti e la gestione della cronologia.

C'è anche un dettaglio di denominazione da controllare: la panoramica del plugin di Kong specifica che attivare l'opzione di cache esatta non disabilita le corrispondenze basate sulla similarità. Quel comando non va interpretato come una modalità di sicurezza che accetta soltanto corrispondenze esatte.

Cache semantica con Redis

Redis, un archivio dati con funzionalità di ricerca vettoriale, lascia all'applicazione il controllo della ricerca e del percorso da seguire in caso di miss. Il componente SemanticCache documentato da RedisVL offre le operazioni check e store, metadati, filtri e controlli del TTL. Documentazione di RedisVL.

Questo schema è indicato quando l'applicazione conosce già tenant, policy e versioni dei record e deve verificarli prima di restituire un risultato. La stessa architettura può essere costruita attorno a un altro archivio vettoriale adatto: i vettori dei prompt individuano i candidati, mentre risposte memorizzate e metadati determinano cosa si può riutilizzare.

Il compromesso riguarda le responsabilità. Un indice vettoriale non fornisce regole di ammissione alla cache, invalidazione, autorizzazione o una risposta corretta. Occorre implementare e monitorare questi comportamenti, oltre a gestire un'installazione che supporti le query vettoriali utilizzate.

Libreria: GPTCache

GPTCache, una libreria per costruire cache semantiche, separa la generazione degli embedding, la memorizzazione delle risposte, la ricerca vettoriale e la valutazione della similarità in componenti configurabili. La sua documentazione avverte esplicitamente che non tutte le combinazioni di moduli sono compatibili.

È adatta a chi vuole sperimentare con i componenti di recupero e valutazione all'interno di un'applicazione. Il limite principale è la responsabilità dell'integrazione: occorre verificare gli adattatori scelti rispetto all'SDK del modello e all'ambiente di esecuzione in uso, mantenendo gli stessi controlli su ambito e aggiornamento dei dati. L'astrazione offerta da una libreria non rende corretto un hit semantico.

Se si sta scegliendo anche il livello di instradamento delle richieste, il confronto tra gateway AI e LiteLLM vs OpenRouter aiutano ad affrontare questa decisione più ampia. La cache è uno dei requisiti, insieme a instradamento, credenziali e osservabilità.

Calcolare il risparmio sul proprio traffico

Una cache fa risparmiare solo se i costi di generazione evitati superano quelli di embedding, ricerca, archiviazione e gestione operativa. Vanno conteggiati anche i miss: comportano il costo aggiuntivo della cache e richiedono comunque una chiamata al modello.

Usare un unico periodo di misurazione e una sola valuta. Sia N il numero di richieste ammissibili che arrivano al livello semantico, dopo gli eventuali hit della cache esatta; H il numero di hit semantici accettati; G il costo di generazione per richiesta, nell'ipotesi semplificatrice di un costo uguale per tutte; E il costo di embedding e ricerca per ogni richiesta ammissibile; W il costo di scrittura nella cache per ogni miss; e F il costo fisso di infrastruttura e gestione operativa nel periodo.

Il calcolo è il seguente:

• Senza il livello semantico: N × G
• Con il livello semantico: (N − H) × G + N × E + (N − H) × W + F
• Risparmio netto: H × G − N × E − (N − H) × W − F

Applicarlo ai propri log: moltiplicare gli hit accettati per il costo del modello che hanno evitato, sottrarre i costi di ricerca per tutte le richieste ammissibili, sottrarre le scritture dovute ai miss e infine i costi fissi. Usare i costi di generazione al netto degli eventuali benefici del prompt caching del provider, non la tariffa di listino senza cache.

Con queste ipotesi, la condizione per superare il punto di pareggio è:

H > [N × (E + W) + F] / (G + W)

Per un carico di lavoro misto, sostituire H × G con la somma dei costi di generazione effettivamente evitati dalle richieste che hanno prodotto un hit. Se alcune risposte non vengono ammesse alla cache, contare le scritture reali. Includere nuovi tentativi, chiamate di valutazione e lavoro operativo nei rispettivi totali. La sola percentuale di hit non dice se il riutilizzo abbia ripagato i propri costi.

Lo stesso ragionamento vale per la latenza. Gli hit eliminano la generazione dal proprio percorso; i miss aggiungono embedding e ricerca prima della generazione. Misurare entrambi i percorsi, comprese le latenze dei casi più lenti. Un carico composto soprattutto da richieste uniche può diventare più lento, anche se i rari hit sono rapidi.

Quali aspettative sulla cache semantica sono eccessive?

Un significato simile non garantisce risposte equivalenti. La cache seleziona una risposta esistente; non stabilisce che sia ancora corretta, autorizzata o aggiornata.

La metrica più ingannevole è una percentuale di hit in crescita senza una verifica parallela degli hit sbagliati. Una soglia più permissiva può far apparire migliori i dati della dashboard e, allo stesso tempo, aumentare il lavoro da rifare per l'assistenza. Confrontare le risposte in cache con le nuove richieste, soprattutto quelle più vicine al limite di accettazione.

La cache delle risposte non sostituisce nemmeno la generazione aumentata tramite recupero di informazioni (RAG), in cui un modello riceve materiale recuperato dalle fonti per produrre una risposta. Una cache può precedere quel flusso, ma saltarlo significa anche rinunciare a una nuova consultazione delle fonti. Collegare le risposte in cache alle versioni delle fonti oppure evitare il riutilizzo quando i fatti sottostanti devono essere aggiornati.

«Annulla il mio ordine» va trattato come un'azione, non come una domanda riutilizzabile. Una conferma precedente non dimostra che una nuova azione sia stata autorizzata o eseguita. L'esecuzione e il suo risultato attuale devono restare nel normale flusso applicativo.

Chi può iniziare subito e da dove partire

Chi sviluppa applicazioni che ricevono domande pubbliche ripetute può iniziare subito, con un ambito ristretto. Scegliere un intento stabile, definirne l'ambito consentito e mantenere la cache esatta come riferimento per il confronto. Il beneficio consiste nel ridurre le chiamate di generazione ripetute senza ampliare i tipi di risposta che l'applicazione è autorizzata a riutilizzare.

Chi gestisce il sistema dovrebbe prima eseguire una valutazione in modalità shadow. Registrare quale risposta in cache sarebbe stata restituita, continuando a fornire la risposta normale. Etichettare le parafrasi effettive e le quasi corrispondenze, poi regolare la soglia in funzione degli errori inaccettabili. Misurare il costo aggiuntivo della cache, il comportamento alla scadenza e la qualità della risposta memorizzata.

Chi acquista una soluzione dovrebbe chiedere prove di isolamento e invalidazione. Una casella spuntata alla voce «cache semantica» non basta. Occorre chiedere come il sistema gestisca domande identiche provenienti da utenti diversi e cosa accada subito dopo una modifica della policy.

Meglio aspettare se la maggior parte delle domande dipende da record che cambiano o da un contesto di conversazione su più turni che non si riesce a isolare. Se le ripetizioni esatte coprono già il traffico riutilizzabile, la ricerca semantica potrebbe aggiungere poco. Il prompt caching del provider può comunque aiutare con i prefissi di input ripetuti, senza richiedere il riutilizzo di una risposta completa.

Il primo passo per lunedì: scegliere un intento del centro assistenza, raccogliere le sue parafrasi e alternative volutamente ambigue, definire l'ambito della cache e la regola di invalidazione, poi riprodurre le richieste in modalità shadow. Attivare il riutilizzo delle risposte solo dopo aver verificato che i casi che porterebbero a risposte sbagliate vengano respinti in modo sicuro.

Domande frequenti

Che cos'è la cache semantica?

Memorizza risposte precedenti e le recupera in base alla similarità di significato. Il riutilizzo dovrebbe richiedere anche un contesto corrispondente, permessi validi e dati sufficientemente aggiornati.

Quali sono i tre tipi di cache?

Per questa scelta relativa agli LLM, è utile distinguere tra cache esatta delle risposte, cache semantica delle risposte e prompt caching del provider. È un confronto utile per questo articolo, non una classificazione universale di tutte le cache informatiche.

Come si implementa una cache semantica?

Definire l'ambito consentito, creare gli embedding dei prompt in arrivo, recuperare i candidati, applicare una soglia calibrata e i controlli di ammissibilità, quindi restituire la risposta memorizzata oppure chiamare il modello. Prima di attivare il riutilizzo, aggiungere scadenza, invalidazione e monitoraggio degli hit sbagliati.

Una CDN è soltanto una cache?

No. Una rete di distribuzione dei contenuti (CDN) distribuisce l'erogazione dei contenuti tra più località; la cache è uno dei meccanismi che utilizza. Si veda l'architettura CDN di Cloudflare.

Cloudflare è una CDN o un WAF?

Cloudflare offre sia servizi CDN sia un web application firewall (WAF), che filtra il traffico applicativo. Nessuna delle due definizioni, da sola, implica una cache semantica delle risposte LLM. Architettura di Cloudflare.

Qual è la differenza tra una CDN e Redis?

Una CDN distribuisce contenuti attraverso una rete edge. Redis è un archivio dati che un'applicazione può usare per la cache, anche implementando uno schema di cache semantica. Occupano parti diverse del sistema.

Cloudflare è solo una CDN?

No. Nella sua architettura di riferimento, Cloudflare documenta anche DNS, firewall e altri servizi edge.

Kafka è migliore di Redis?

Risolvono problemi diversi. Apache Kafka è una piattaforma di streaming di eventi. Non è un sostituto diretto dello schema di cache semantica delle risposte con Redis descritto qui.

Netflix usa Redis?

Sì. Redis documenta l'uso di Redis da parte di Netflix per le code con priorità, con un link all'articolo di Netflix su Timestone. Questo esempio storico non dimostra l'uso di una cache semantica per LLM e non è un motivo per attivarla nella propria applicazione.

Per consigli pratici sullo sviluppo di applicazioni AI affidabili, iscriviti alla newsletter.